qodiqa
SpecificationRun a simulation
ISO/IEC 27001 (identification only)

Frameworks · Standards and guidance

qodiqa and ISO/IEC 27001

qodiqa checks each AI request before the call and keeps tamper-evident, offline-verifiable evidence. This page shows where that evidence relates to ISO/IEC 27001, and where it does not.

  • Standard
  • ISO/IEC
  • Current edition ISO/IEC 27001:2022.
  • Verified 2026-11-03
Read the official textBack to all frameworks

Overview

What it is

ISO/IEC 27001 (identification only)
Issuer
ISO/IEC
Type
Standard
Status
ISO/IEC 27001:2022 (current edition)
Official text
www.iso.org

ISO/IEC 27001, Information security management systems. ISO/IEC 27001 specifies requirements for an information security management system and lists controls (Annex A) in themes for organisational, people, physical and technological measures. Organisations can be audited against it by accredited certification bodies.

Who it applies to. Any organisation that wants to run and demonstrate a managed approach to information security.

Where it meets qodiqa

The parts of ISO/IEC 27001 where the evidence matters.

Record-keeping and logging

Tamper-evident logs for the logging theme.

Robustness and security

Cryptography, key separation and access control are concrete, documented controls.

Accountability

Evidence an auditor can check without trusting the operator.

Traceability

A request hash and id tie every logged event to one request.

Risk management

Counts, reasons and alerts feed the monitoring theme.

Human oversight

Revocation and a kill switch support access-removal and emergency-stop procedures.

Mapping

What qodiqa provides, and what stays with you.

Requirement or controlWhat qodiqa providesWhat stays with you
A.5.15 Access controlConsent and tenant policy are checked before each call; role-based operator access with MFA step-up; tenant-scoped data access.Access control for the rest of your estate.
A.5.16 Identity managementCaller identity from signing keys, an API-key lifecycle with revocation, and delegation tokens that only narrow.Your identity lifecycle for people and systems outside the gateway.
A.5.17 Authentication informationAPI keys, signing keys, key rotation and expiry monitoring, and published public key sets.Your own secrets handling and password policy.
A.5.3 Duty segregationApprover who is not the requester, separation of duties for policy changes and last-administrator protection.Segregation of duties in the rest of the organisation.
A.8.2 Privileged accessPrivileged operator access, MFA step-up and lockout after repeated failures.Privileged access to servers, cloud accounts and databases.
A.8.3 Access restrictionTool-call authorization under policy, tenant separation with PostgreSQL row-level security, and execution bound to an approved decision.Access restriction on your applications and data stores.
A.8.5 Secure authenticationSigned single-use consent artifacts, operator sessions with lockout, and OIDC, SAML 2.0 and LDAP single sign-on.Authentication for your own users and services.
A.8.15 LoggingHash-chained audit entries, a transparency log, signed receipts and structured logs with automatic sanitization.Logging for the rest of your systems, and review of the logs.

Identifiers verified against ISO/IEC 42001:2023 and ISO/IEC 27001:2022 on 2026-11-03. The standards are sold; their text is not reproduced here and the descriptors are the authors’ own. This is a mapping, not a certification.

Cross-check: the Regulatory Alignment Matrix, section 6

How it fits

What ISO/IEC 27001 asks, and what qodiqa produces.

  1. Logging (Technological theme) is supported by Hash-chained audit entries (Transparency log).
  2. Cryptography (Technological theme) is supported by Key domains and rotation (Ed25519 only).
  3. Audit evidence (Management system) is supported by Signed receipts and proofs (Checkable offline).

Evidence

Evidence you can hand to an auditor.

Five artifacts, each checkable on its own

  • Consent artifact Signed with Ed25519, bound to one request, single use.
  • INTENT entry The audit entry written before the provider call.
  • Receipt A signed decision record that checks offline.
  • Audit export Hash-chained entries with a Merkle inclusion proof.
  • Anchor proof A signed checkpoint pinned outside the gateway.
Verify offline, from a clone of qodiqa-verify
node bin/verify.bundle.external.js \
  --keys examples/front-half/keys.json \
  --transparency-keys examples/front-half/transparency-keys.json \
  examples/front-half/bundle-with-proof.json

The example files ship with the repository and are signed with throwaway keys. The command exits 0 and prints "valid": true. For your own evidence, take keys and anchors from a source other than the gateway that wrote it.

Scope and limits

Scope and limits

Technical evidence, not a compliance outcome

qodiqa provides technical evidence that relates to parts of ISO/IEC 27001. This is a mapping, not a certification: it is not a compliance certification, it is not legal advice, and no regulator or standards body has endorsed it.

What qodiqa does not address:

  • The ISMS itself: scope, risk assessment, Statement of Applicability and management review.
  • Physical, people and organisational controls.
  • The organisation’s own management system, risk assessment, audits and certification are outside what a gateway can supply.
  • Only requests that pass through the gateway are checked, and a receipt proves a decision was recorded, not that it was correct.

Sources

Sources

The first link is the standard’s catalogue page on iso.org. The remaining links are qodiqa’s own documents. Checked on 2026-11-03; editions change, so read the current standard.

Next steps

See the evidence for yourself.

Read the spec sectionRun a simulationQuickstart