A reviewer wants two things from a vendor: what is actually enforced, and what is missing.
We provide the technical controls that support your compliance program. Not a certificate, not an attestation, and not a promise that installing software makes an organization compliant. This page states the position precisely enough that your security reviewer can act on it.
org.tech holds no third-party attestation of any kind. No audit firm has examined our controls and issued an opinion about them. We hold no certificate for SOC 2 and none for ISO/IEC 27001. That is on the page a reviewer reads first.
The second half matters more, and almost nobody says it out loud: a vendor's certificate would not discharge your obligation anyway. A report about a service organization describes that organization's controls. It is not a statement about your compliance, your data, or the way your people use a system.
We do not present another party's report as ours, and we do not describe our own design work as an audited outcome. There is a real difference between a control that exists and a control an auditor has tested, and the difference belongs to you, not to us.
Even a vendor with a clean report transfers no compliance to a customer. Your auditor forms an opinion about your controls, in your environment, under your policies. We can make that examination cheaper and better evidenced. We cannot take it off your desk.
Seventeen technical control rows, each mapped to SOC 2 Trust Services Criteria and to ISO/IEC 27001:2022 Annex A, and each carrying one of three verdicts: enforced, partial, or not enforced. A row with an uncomfortable verdict stays in the document.
The standing exceptions recorded against your deployment are rendered to you, signed in, inside the product. They are read from the same machine-readable table the matrix is built from, so the page cannot quietly disagree with the record.
Reviewers use these names interchangeably. They are not interchangeable, and being precise about them is the fastest way to shorten a security review.
A CPA firm holding the relevant practice authority examines a service organization's controls against the Trust Services Criteria and issues a report containing an opinion. The AICPA, which defines the criteria, describes it as exactly that. It reports on the audited organization. It certifies nobody's compliance, least of all the customer's.
The 2022 edition is current, published October 2022, and its Annex A lists 93 controls, down from 114 in the 2013 edition. Unlike SOC 2 it has a formal third-party certification scheme. We map our technical rows to Annex A because your reviewer's checklist is usually built from it.
Published 18 December 2023, it is the first international standard specifying requirements for an AI management system, for any organization providing or using AI. It certifies a management system, not a model and not a product. We make no alignment claim against it.
Designed to align with SOC 2 Trust Services Criteria and ISO/IEC 27001:2022 Annex A. We provide the technical controls that support your program. We hold no third-party attestation, and we say so. Every word in that sentence is doing work, including the ones that limit it.
Below is the shape of the document, not the document. Eight rows of seventeen, with the criteria references stripped out. The real matrix arrives with your deployment's own configuration resolved into it, so a verdict is about your deployment and not about a brochure.
| Technical control | Verdict | Applies at | What stands behind it |
|---|---|---|---|
| Content policy mandatory on every inference call | ✓Enforced | Every deployment | A cloud identity policy deny, not an application setting. A build test fails if the deny is weakened. |
| Inference confined to the configured endpoint regions | ✓Enforced | Every deployment | The same deny file. A call outside those regions does not reach a model. |
| Encryption at rest | ✓Enforced | Every deployment | On everywhere. Key ownership moves by tier: provider-owned, provider-managed, then customer-managed with rotation. |
| Account-level audit logging | △By tier | Standard and Strict | Multi-region, file validation, one-year retention. Absent at Baseline, and a reviewer should ask which tier you bought. |
| Multi-factor authentication enforced | △By tier | Standard and Strict | An optional add at Baseline. Passkeys, TOTP and second factors are self-service at every tier. |
| Per-person usage metering with quotas that fail closed | ✓Enforced | Every deployment | Settled against the provider's own record of each call, not an application counter. Home region today. |
| Model invocation logging | ✓Enforced | Every deployment | Model, caller identity, latency, token counts. Deliberately no prompt or answer text, so do not read it as a transcript. |
| Per-document access control in the knowledge base | ✕Not enforced | Nowhere | Anything loaded into a deployment's knowledge base is readable by every user of that deployment. The control today is what you choose to load. |
Illustrative excerpt. The delivered matrix carries all seventeen rows with their criteria references for both frameworks, plus the standing exceptions recorded against your configuration. A verdict is our judgment about a control as deployed. It is not an auditor's opinion, and it is not offered as one.
Technical controls are the part we can build, test and evidence. They are also the part your auditor spends the least time on, and it is worth knowing that before the fieldwork rather than during it.
Four of the seventeen rows move with the posture tier, which is why we will not publish a single table and call it the product. Baseline is the low-cost entry posture: single-account isolation, encryption in transit and at rest, the mandatory content policy, least-privilege identity policy, everything as code. It has no private networking and no account audit trail. It suits low-sensitivity use and a first evaluation. A security review will usually want Standard.
Standard adds account-level audit logging with multi-region coverage, file validation and one-year retention, a private network endpoint to the managed model service, enforced multi-factor authentication, provider-managed keys, and scoped, session-capped management access for us. Strict adds customer-managed encryption keys with rotation and the residency pin. The tier is decided in the posture questionnaire, recorded as a committed configuration, and reflected in your matrix. It is not a sales tier and there is no discount attached to weakening it.
No. No audit firm has examined our controls and issued an opinion, so there is no report to send you and no certificate to show. What we send instead is the controls matrix with its verdicts, your deployment's committed configuration, and the standing exceptions we have not yet closed.
If your procurement process has a hard requirement for a vendor report, we will tell you at the assessment rather than at contract stage. See what we do not claim.
No, and anyone who says otherwise is selling. The deployment gives you technical controls that are enforced rather than described, plus evidence you can hand to an auditor. It does not write your access-review policy, run your change-management process, or accept your risk.
What it does change is the quality of the answers you can give. Instead of asserting that AI use is controlled, you can show which policy applies, where it is enforced, and what is recorded.
The deployment sits in a cloud account you own, so the decision is yours, subject to your provider's testing policy. We will help scope it and we will fix what it finds. We do not hold an independent penetration-test report today, and we will not imply one exists.
What we do run after every deploy is a set of acceptance scripts against the live deployment over HTTPS: a replayed ticket, a forged session, one module's session presented at another module's host, a corrupted upload. Each must be refused, on the running deployment rather than on a mock.
The platform runs in a cloud account you own and are billed for directly, so your cloud provider is contracted to you, not sub-contracted by us. We do not resell compute and we hold no client data on our own infrastructure. The managed model service processes prompts and returns answers under your account's retention election; by default prompts are not used to train models and are not shared with model vendors.
Our own access is the thing to scrutinise: at Standard and Strict we hold a scoped, session-capped management role in your account, and at Baseline no cross-account role exists at all. The data processing addendum sets out the rest.
ISO/IEC 42001:2023 specifies requirements for an AI management system: an organizational programme with governance, objectives, risk treatment and continual improvement. It certifies a management system, not a model and not a product. It is something your organization would build, with or without us.
We make no alignment claim against it. We do publish the decision rules we work to, which is a smaller and more useful thing: see responsible AI.
The page describing your controls is generated from the same typed object that builds them, and a test fails our build if the two disagree. That is a weaker promise than a certificate and a far more useful one.
Bring your reviewer's checklist to the assessment and we will answer it row by row, including the rows where the answer is no.