Automation you can put in front of an auditor
Handing a system the work your people used to do is a control question before it is a technology question. This is how we answer it.
Every serious buyer asks the same three things: where does our data go, who can reach it, and what happens when the system gets something wrong. We would rather answer those on a public page than in the third meeting.
Nothing below is aspirational. It describes how we build and operate programs today. Where we do not yet hold something a large enterprise might expect, we say so on this page rather than leaving you to discover it during procurement.
How the systems are built and run
Tenancy and residency
Automations run in your cloud account, or in an isolated environment we operate for you, in the region you specify. We do not pool client workloads or client data in a shared environment.
Encryption
Data is encrypted in transit with current TLS and at rest with provider-managed or customer-managed keys, depending on what your policy requires.
Least-privilege access
Every integration uses a dedicated service identity scoped to the specific objects and operations the process needs. Standing human access to production data is the exception and is named in the engagement, not assumed.
Secrets management
Credentials live in a managed secret store, never in code, configuration files or repositories. Keys are rotated on a schedule and on personnel change.
Audit trail
Every automated action records its inputs, the rule or model version that decided it, the confidence where a model was involved, and the outcome. The record is queryable and retained for the period you set.
Change control
All automation is version controlled, reviewed and deployed through a pipeline. Production changes are traceable to a commit, an approver and a ticket.
Monitoring and alerting
Automations are monitored continuously for failure, drift, latency and volume anomalies, with alerting routed to an on-call rotation under the service agreement.
Segregation of duties
The people who build an automation and the people who approve its production changes are not the same, on programs where your control environment requires it.
What the models are and are not allowed to do
The reason most automation programs fail a risk review is not the model. It is that nobody can say what the model was permitted to decide.
Your data is not used to train models
We use enterprise model endpoints under agreements that exclude training on submitted content, and we do not fine-tune shared models on your data. Where a model is tuned for you, the artifact belongs to your program and is not reused elsewhere.
Models read and recommend; rules decide
The default architecture puts deterministic rules and policy checks between a model and any consequential action. That keeps decisions explainable and makes the control testable.
Confidence thresholds are yours to set
Every automated decision has a confidence boundary below which it escalates to a person. You set those boundaries and can move them without a rebuild.
Human review is designed in, not bolted on
Review queues are part of the process design and sized to the real exception rate. Where regulation or policy reserves a decision for a person, the system prepares it and stops.
Prompt and output handling
Inputs and outputs are logged for audit under your retention policy, redacted where they contain sensitive fields, and access to those logs follows the same least-privilege rules as the data itself.
Model changes are tested before they reach you
Model and prompt versions are pinned. Upgrades run against a regression set built from your own historical cases before anything moves to production.
What we do not claim
We are not certified under SOC 2 or ISO 27001, and we do not describe ourselves as HIPAA or GDPR "compliant" as though compliance were a badge a vendor can hold on your behalf. Compliance is a property of your program, and our part in it is contractual: the controls above, the agreements we sign, and the evidence we produce on request.
If your procurement gate requires a certified supplier, that is a real constraint and we will tell you at the first call rather than at the security review. If it requires a supplier who can evidence how every automated decision was made, that is the part we are built for.
What security and procurement teams ask us
Not today, and we will not tell a prospect otherwise. We implement the control practices described on this page, we work inside our clients' existing compliance programs, and we accept the security schedules, audit rights and evidence obligations that come with them. If your procurement process requires a certified supplier, tell us early and we will be straight with you about where that leaves us.
Yes. We sign data processing agreements, confidentiality agreements and client security schedules, and we accept named sub-processor lists and change-notification obligations.
Only the engineers assigned to your program, under named access that is granted for the engagement and revoked at its end. Access is logged. Support staff outside the program do not have standing access.
We notify you within the window agreed in the engagement, contain first, preserve evidence, and deliver a written root-cause analysis with the corrective actions and their dates. We do not wait for certainty before telling you something happened.
You get the automation code, configuration and documentation, we hand over or destroy the data according to your instruction, and we provide written confirmation of destruction. Nothing about the engagement depends on holding your data hostage.
Our delivery team is named in the engagement. Where a specialist is added, they are disclosed in advance and bound by the same agreements and access controls.
Send us your security questionnaire
We answer it before the commercial conversation, not after. Email [email protected] or use the form.