ISO/IEC 27001:2022 Annex A — control readiness view
This page is generated from the requirement table the AiSSAY engine ships for this framework. When the engine produces an evidence pack, each row below gets a status computed from the operator's own records at that moment. This page shows the table, not anyone's results.
Informational mapping prepared by the operator's own tooling. Not a legal opinion, not a certification, and not a substitute for advice of counsel. It organizes the operator's records against the cited requirements; whether those records satisfy the requirements is a determination for the operator, counsel, and the examiner.
ISO 27001 certifies an information security management system, audited by an accredited body. This view maps shipped mechanisms to Annex A themes and names the ISMS gaps plainly.
The requirement table
12 rows: 6 mechanism, 4 organizational, 1 named gap, 1 computed
| Requirement | Mechanism, duty or gap | Type |
|---|---|---|
| A.5.1 — information security policies | organizational: the ISMS document set | organizational |
| A.5.19–5.22 — supplier relationships | organizational: subprocessor register (the self-hosted design keeps the register short by construction) | organizational |
| A.6 — people controls (screening, training, NDAs) | organizational | organizational |
| A.8.15 — logging | hash-chained access log with actor, action and reason; every read of every record lands in it | mechanism |
| A.8.16 — monitoring activities | chain verification, anchor verification including key-swap detection, capture-gap sealing | mechanism |
| A.8.24 — use of cryptography | AES-256-GCM at rest, Ed25519 attestation and approvals, SHA-256 chains; keys never leave the operator's machines | mechanism |
| A.8.13 — information backup | witness-restoration mechanism shipped; backup schedule and testing are organizational | organizational |
| A.8.32 — change management | VERSION stamps, pinned regression suites, signed instrument-profile ledger | mechanism |
| A.5.15/A.8.3 — access control and information access restriction | DELEGATED when the store is sealed by your key manager (the kms provider): whoever your key manager refuses cannot open the store at all, and every open appears in your key manager's own audit log. This store itself has no authentication, roles or permissions and refuses no read: once a key is unwrapped, the process holding it can read every record. Under any other provider, NOT IMPLEMENTED — the operating system's file permissions are the only access control. The status is computed from the provider this store declares, not assumed. | computed |
| A.8.24 — use of cryptography, including key lifecycle | re-key ceremony: a successor key is sealed through the same provider, every record is moved under it with each record declaring its key, and the old key is destroyed only after every record reads back under the new one; grants and custody shares of the retired key open nothing afterwards. Rotating the key manager's own wrapping key is the key manager's. LIMIT: anyone holding both the old key and an old copy of the ciphertext can still read that copy. | mechanism |
| A.8.8 (identification) — known vulnerabilities in Python dependencies | every Python package resolved from requirements.txt and from the optional requirements-aws.txt is checked, each file in its own block, against a public advisory database AT RELEASE, and the report ships with its hash (depscan.py, DEPSCAN.json). It cannot run on your machine, because the advisory database is on the network. Not operating-system packages, not the interpreter, not continuous. | mechanism |
| A.8.8/A.8.29 — remediation, monitoring and security testing | PARTLY IMPLEMENTED, and the parts are named. Present: a release-time dependency scan with an age check that refuses to let a stale scan pass as current; a static checker over this tree for a short, listed set of defect classes, proved each release against a file with one of each planted in it; and mutation fuzzing of the parsers that read input we did not write, proved against a deliberately broken parser. Absent: penetration testing, operating-system package scanning, continuous monitoring between releases, and third-party review of the cryptographic design. Deciding what to do about a finding is a procedure, and the procedure is the operator's. | named gap |
How a status is earned
- Evidenced
- a deterministic check ran against your records and the counts support the row. A store holding no relevant records reads unevidenced — a true statement, not a passing one. Empty never counts as clean.
- Delegated
- the mechanism is enforced by a system you already trust — a store sealed by your own key manager delegates access control to it, and the pack says the enforcing log is your key manager's, not ours. The pack names the endpoint the key manager was reached at. An AWS endpoint other than AWS's own default for the region reads delegated to that endpoint, with a request that you confirm it is your key management service. One backend — AWS KMS — has run against the real AWS KMS service; no other backend has.
- Test seam
- sealed by an in-process test backend — a stub, or a stand-in for the AWS client — and the status names which. No key manager enforces access. The seam is built and tested, and the pack refuses to call that delegation.
- Partially evidenced
- the mechanism is built and some of your runs carry its evidence, but not all — usually because they were sealed before the mechanism existed. The pack says how many runs are in each group, and never counts the missing ones as passing.
- Organizational
- the requirement is a procedure only people can perform. The pack names it as yours instead of dressing a policy up as a mechanism.
- Named gap
- the pack cannot evidence it — either the mechanism is not built, or no software can supply it — and it says which. The gap is printed, because a reviewer should read it here rather than discover it.
No status is typed in by hand: every status is recomputed from the store each time a pack is produced, the requirement and mechanism text is written and reviewed as part of the engine, and the dependency evidence comes from our release scan. A failing mechanism can never be read as evidence that the control works.
Rows marked “computed” are the access-control rows. Their status is computed from the provider your store declares: a gap unless your key manager seals the store, “test seam” under a stub or stand-in backend, “delegated” only under a real one. Today they can never read evidenced, and marking them as a built mechanism would overstate them.