Intake → ticket and attachment storage
List the forms, APIs, and mailboxes that supply data. Choose the database and durable storage, access policy, backup location, and retention owner.
Security and deployment review
Review the boundary around your ticket data
A ticket may contain account details, supporting documents, and a proposed change in another system. The review needs to follow that data through storage, identity, model requests, integrations, and the resulting evidence.
Run Latch in your environment, define access and independent review, and name the owners of the installation. The operating plan covers network access, backups, retention, and recovery.
Follow the data
Review each connection in the workflow
The deployment boundary depends on the services you configure. Choosing your own server does not determine where a mailbox, model API, or connected application processes data.
Operator → identity and permissions
Document the identity provider, validated sign-in path, user lifecycle, and permissions to read tickets, request actions, review them, and execute them.
Ticket context → model endpoint
Record which data is sent to the selected model service. Local inference and a commercial API have different processing and network boundaries.
Approved request → connected service
Document the permitted destination, credentials, request data, failure handling, and returned evidence for each plugin action.
Activity → history, logs, and backups
Identify where evidence is stored, who can access it, how it is exported, and how retention and recovery are operated.
See model endpoint choices and the connected action path.
Product and operator responsibilities
Give each control an owner
The application, the connected system, and the people operating the installation each have responsibilities. Review the exact workflow and deployment together.
| Area | Product behavior | Your operating responsibility |
|---|---|---|
| Ticket access | Authenticated identity and configured permissions govern supported application requests. | Provision access, review roles, remove access when people leave, and validate the exact routes used by integrations. |
| Sensitive actions | A plugin action can require a different eligible person to review the saved request before a separate execution step. | Select the actions that need review, configure eligible access, and test denial, expiry, changed requests, and downstream outcomes. |
| Action evidence | The ticket connects the saved request, review, and result reported by the plugin. | Set retention and export procedures. Protect database and backup access; define any independent integrity or archive requirements. |
| Operating the installation | The product is deployable in your environment with application releases and database migrations. | Operate TLS, network restrictions, durable storage, patching, monitoring, backups, restore testing, and incident response. |
| Custom integrations and changes | Supported APIs and plugins provide extension points; source access is available on Enterprise under commercial terms. | Maintain credentials, business rules, compatibility tests, and custom code. Agree source-change and support rights in the licence. |
Review and execution
Test the action that carries risk
Use a synthetic transaction reprocess request. Verify that the requester cannot approve or execute it, that another eligible operator can review the saved values, and that execution remains a separate step.
Read the ticketing approval path and what action history records. A reported submission needs downstream reconciliation before it is treated as completed work.
Identity and recovery
Test access after a change
Check a deprovisioned user, a changed permission, and a recovered installation. Restore a synthetic ticket and its attachment into a separate test environment, then verify access and history.
The identity protection walkthrough explains attempt limits, recovery, and operator feedback.
Procurement evidence
Record requirements and observed results
A finance or claims operation may need specific data-location, access, approval, retention, and recovery controls. Document those requirements and the test evidence; installing the product alone does not establish regulatory compliance.
Use the deployment evaluation checklist. Settle Enterprise source-access terms and support options alongside the technical review.
Security review Q&A
Questions to answer with deployment evidence
Use the actual services, permissions, and network policy in the proposed installation.
Where does ticket data live?
In a customer-operated installation, the ticket database and attachment storage run in the environment you operate. Include mail, model endpoints, connected systems, logs, backups, and support access in the data-flow review; those choices can introduce additional processing locations.
Does self-hosting establish regulatory compliance?
A deployment location alone does not establish compliance. Map the requirements for data, access, review, retention, and recovery to the supported product behavior and operating procedures, then record the evidence for each.
Is the audit history tamper-proof?
The ticket keeps request, review, and action-result history. That history is not a claim of independently sealed or WORM storage. Database administrators, backups, retention policies, and any external integrity controls need their own access and operating review.
Can we keep model requests inside our network?
Choose a supported model endpoint in the required environment and verify its data handling and connectivity. A commercial model API is a different boundary from inference your team operates. Include the selected endpoint in the deployment test.
Can a plugin call any internal endpoint?
Connected services must meet the supported endpoint and network policy. Private access needs an approved configuration; some internal destinations remain prohibited. Review the exact service destination and permitted connection before relying on an integration.
Can the installation run on a disconnected network?
Evaluate the complete dependency path against the network restriction. Test installation, identity, email, inference, plugin actions, release import, and recovery with the connections your environment permits.
Workflow review
Bring one request and its data boundary
Review where the data goes, who can act, where independent review applies, and the evidence your team needs to retain.