ISO/IEC 27001:2022 — Annex A
Your auditor asks how privileged changes are authorized. Today you answer with a ticket.
A ticket records that someone typed an approval into a system they administer, at a time that system recorded. A.8.32 is satisfiable that way and routinely is. It is also the control where the gap between what you can assert and what you can evidence is widest.
An instrument, not a subject
Most vendors map to Annex A as a subject of controls: here is how we protect your data, here is our own access management. That is table stakes and it belongs in a questionnaire response.
INTYGA also maps as an instrument. Deploying it is how you implement A.8.32 change management, A.8.2 privileged access and A.8.15 logging over your own automation and AI agents — the systems that are hardest to evidence precisely because no person is sitting at them.
That is the reason an ISMS owner cares, and it is a different conversation from vendor due diligence.
const action = {
target: DEPLOY_TARGET, // this pipeline — so the approval can't be replayed against another
actionType: "terraform_apply",
params: { workspace: "prod", change: process.env.GIT_SHA }
};
const approval = await intyga.requireApproval("Terraform apply — prod", action);
if (approval.status !== "APPROVED") throw new Error("not approved");
// nonce and approvers come from YOUR side — a receipt cannot vouch for its own signer.
const anchor = parseTrustAnchorFile(readFileSync(process.env.INTYGA_APPROVERS_FILE!, "utf8"));
const TRUSTED_APPROVERS = trustAnchorApprovers(anchor); // quorum counts PEOPLE, not keys
const check = verifyApprovalReceipt(approval.receipt!, {
...action, nonce: approval.nonce!, approvers: TRUSTED_APPROVERS,
}, {
expectedOrigin: anchor.webauthn?.origin,
expectedRpId: anchor.webauthn?.rpId,
});
if (!check.ok) throw new Error("receipt mismatch: " + check.reason);
await terraformApply("prod");The mapping
Annex A references are to the 2022 revision. Your Statement of Applicability decides which controls apply to you; this is what INTYGA implements and what it lets you evidence.
A change to production is gated on a human signature over its exact parameters, with four-eyes and hardware-key requirements available per action. The evidence is the receipt and the AUTHZ_APPROVED ledger event, not a workflow status field.
A privileged operation cannot execute on a standing credential alone. The credential authorizes requesting; a fresh human signature bound to the parameters authorizes executing.
Per-action rules decide quorum, which approvers are eligible, and which authenticator classes count. The rule in force is frozen onto the challenge when it is created.
INTYGA holds no approval private key. Approvals use a WebAuthn authenticator; synced passkeys are supported unless policy requires a hardware-bound credential. API keys are stored as scrypt hashes and compared in constant time.
WebAuthn with user verification required — a biometric or PIN, not mere possession of the device. Individual actions can demand an attested hardware key by AAGUID.
An append-only, Merkle-anchored witness ledger. The application's database role has UPDATE and DELETE revoked on the ledger tables, which is asserted by a test in CI rather than by a manual script.
Every principal is a typed node — HUMAN, AI_AGENT or SERVICE — with its own DID. Machine identities are distinct from people by construction, not by naming convention.
Where we stand
Bring your auditor the artifact, not the assertion.
The evidence export is available on every plan including the free one, because a control you cannot show an auditor is not worth selling and verifiability is not an upsell.
See the other framework mappings →