Skip to main content
You are putting your ISMS scope around an AI agent and your auditor wants to know which Annex A controls you can actually evidence on the request path. On a hosted gateway the honest answer is narrow and verifiable: the Annex A clauses that map to a control running on every gateway-crossing request — access, cryptography, and event logging — plus the organizational clauses a proxy can never enforce and must disclose as gaps. This page is the iso 27001 ai walkthrough: which Annex A clauses the ISO/IEC 27001 pack covers, the controls it materializes, and how the evidence is signed. For the install flow and report format in depth, follow the links at the end — this is the 27001-specific map, not the full Compliance reference.

​
1. What the iso 27001 ai pack covers

The ISO/IEC 27001 pack maps the 2022 Annex A controls to guardrails that run on every gateway-crossing request. Three clauses map to live enforcement; two are organizational and are disclosed as gaps rather than claimed.
Annex A clausePlaneControl
A.9 Access controlguardrailKeep PII off the upstream provider, consistent with need-to-know
A.10 CryptographyguardrailBlock private keys and secrets in transit
A.12.4 Logging and monitoringguardrailRecord every guardrail decision as evidence
A.5 Organizational controls and A.6 People controls are governance clauses — policy ownership, screening, and management direction. A proxy cannot enforce them, so the pack surfaces them as disclosed gaps (or owner-attested rows) on both the console and the report, never as automated coverage. The honest gaps are what make the enforced rows trustworthy. See the control matrix.
All three enforcing controls run on the same Guardrails machinery you configure by hand. The pack is the authored mapping that says which existing guardrail satisfies which Annex A clause — it ships no new runtime engine. See Pack contents for the full anatomy.

​
2. Install the pack — one concrete example

Installing materializes the mapping into real guardrail policies in your workspace, each tagged with the pack’s provenance. You do this from the console, not a relay key: Compliance → Catalog → ISO/IEC 27001 → Install That is a workspace-Admin action on a paid plan, and the server enforces both. Under the hood your console session calls: 
POST /api/compliance/packs/iso_27001/install
Never hand a relay sk-orca-… key to a configuration route. The /api/compliance/* routes authenticate with your console session, not the relay key — only /v1/* model calls use sk-orca-…. Browsing the catalog, installed packs, and readiness is free and open to every workspace member; install, go-live, report, and residency are the gated Admin actions.
After install, the Annex A rows stop being prose:
A real pii_block guardrail rule hard-rejects requests carrying personal data (emails, phone numbers, SSNs, card numbers, IPs) on the request stage, so it never reaches the upstream provider — consistent with need-to-know access. You can open it, read it, and tune the entity set like any other rule.
Regex rules that block PEM private keys and cloud tokens, layered with the Secrets Blocker, so cryptographic material never transits the gateway in a prompt.
A flag-action rule records each guardrail decision as evidence without blocking traffic — the logging-and-monitoring clause becomes an actual log line per decision.

​
3. Observe first, then go live

An ISO/IEC 27001 install does not start blocking traffic on day one. Installs land in observe mode: enforcing guardrail actions are coerced to flag, so you collect “would-have-blocked” evidence against real traffic before anything rejects a request. When the evidence looks right, a workspace Admin promotes the pack to go-live, which restores the declared actions — the A.9 and A.10 controls start enforcing, the A.12.4 control keeps recording — and optionally promotes the materialized policy to workspace default. This is the same discipline described in Observe vs enforce.
Request-stage enforcement is live today: a PII-carrying request is rejected before the model sees it, and the A.12.4 logger flags every decision on the request. Live response / streaming scanning is on the roadmap, so for the output side the A.12.4 monitoring evidence is what an auditor reads over the report period.

​
4. Signed evidence your auditor can verify

The point of the pack is the report. ISO/IEC 27001 evidence is generated as an Ed25519-signed report with a SHA256 content hash, exportable as CSV, JSON, or PDF, and publicly verifiable — your auditor checks the signature without an OrcaRouter login.
Each Annex A row carries its status — covered, observe, gap, or attested — and how many times the control actually fired over the period. An A.9 control that masked thousands of requests reads differently to an auditor than one with zero matches, and the report shows both.
Every materialized control records its control_id (e.g. iso27001.access), the verbatim clause (ISO/IEC 27001 A.9 Access control), the plane, and the id of the live policy enforcing it — so the auditor walks clause → control → enforcing policy → matches with no inferred step.
Fetch the signing public key at GET /api/public/compliance/pubkey, submit the report to POST /api/public/compliance/verify, or open a scoped auditor share link at GET /api/public/compliance/share/:token. No account required.
See the signed report for the cover-to-footer layout and Verify a report for the verification walkthrough.

​
5. Region-stamp your ISO 27001 evidence

ISO/IEC 27001 reports are stored and served under your declared residency region — us / eu / uk / ap / cn / global — and a report is only served under a matching region; cross-region reads are withheld. A workspace Admin sets it via PUT /api/compliance/residency.
Residency here is the evidence artifact region — where signed reports live and are served. It is not inference-data geo-pinning. See Data residency and Cross-region for the boundary.
Request logs default to a 30-day retention (server-clamped to a 180-day hard max), and a user deletion runs a 30-day grace window then a PII scrub — both relevant when an auditor probes your A.12.4 retention posture. See Retention and Right to erasure.

​
6. Where to go next

ISO/IEC 42001

The AI-management-system companion — pair 27001’s ISMS scope with 42001’s AIMS controls.

Pack contents

The full anatomy of a pack — plane, statuses, and provenance.

Install a pack

The end-to-end install flow, observe mode, and go-live.

Signed report

What the Ed25519-signed evidence report contains.

Guardrails

The content plane the 27001 pack writes to — PII, secrets, and logging.

Frameworks

The full catalog — SOC 2, HIPAA, GDPR, the EU AI Act, and more.
ISO/IEC 27001 on a hosted gateway is the discipline of being precise: map the Annex A controls a proxy can enforce to live guardrails, disclose the organizational ones it cannot, and sign the evidence so the line between the two holds up under audit.