The controlled cover for the applicability decisions: what is covered, at which version, approved by whom, and the rules by which each status was chosen.
27001 Clause 6.1.3 d)42001 Clause 6.1.3Review. Reissued by every deployment that changes a control status, which is the only way a status can change. Reviewed in full at least once every 90 days alongside the risk assessment.
The Statement of Applicability proper is the conformance register at /audit/. It carries all ninety-three ISO/IEC 27001:2022 Annex A controls and all thirty-eight ISO/IEC 42001:2023 Annex A controls, each with a status, a justification and the evidence for it, alongside the management system clauses of both standards.
This document is the controlled cover for that register: its scope, its approval, its version, and the rules that decide a status. The rows are kept at a route rather than copied into this page on purpose. A Statement of Applicability transcribed into a document can disagree with the service it describes; one rendered from the same source the service ships cannot.
Every control of both Annexes appears. There is no control omitted for being irrelevant: irrelevance is itself a decision, and it is recorded as an exclusion with its justification.
Exclusions here fall into two groups. Controls that presume employed people — screening, terms of employment, return of assets — are excluded because there are none, and each such row says so and says it re-enters scope on the first hire. Controls that presume physical premises, removable media or corporate networks are excluded or marked supplier, because the scope statement puts the operator's device, the player's browser and the underlying platform outside the boundary.
The inclusion side is not a formality either. A control is included wherever the service does anything the control describes, including where what it does is inadequate — an included control with a recorded gap is more useful than a tidy exclusion.
Met — implemented, and provable from a route named on the row. This is the only status that asserts anything, and the rule behind it is strict: a row may not be marked met unless a reader can open a link on that row and see the control working.
Partial — the control operates in the running service, but the record an assessor would sample has not been issued. Implemented-but-unrecorded is never met.
Gap — nothing exists yet. Must be closed before certification, and named plainly rather than softened.
Supplier — delivered by the infrastructure provider under its own certification, which has to be held on file for the marking to mean anything.
Excluded — out of scope, with the justification that belongs in this Statement.
The reason for the strictness is arithmetic rather than principle. An overstated register fails a Stage 2 audit faster than an honest one with open gaps, because a single row that cannot be evidenced makes every other row a candidate for the same fault.
Approved by the Owner and published by the deployment named in the change record entry that shipped this document. The version of this Statement is that deployment: the register renders from the same source the deployment ships, so the document and the running service are the same artefact seen twice and cannot drift apart between releases.
This Statement is superseded by the next deployment that changes any status. There is therefore no separate revision history to maintain, and no window in which the published Statement describes a service that has already moved.
The position at this version, so that a later reader can tell whether the register has moved since: 184 rows across the four sections — 102 evidenced, 42 partial, 15 gaps, 14 inherited from the supplier and 11 excluded, against 159 rows this service has to close itself. The two Annex A sections stand at 93 controls with 4 gaps and 38 controls with none. The live count is rendered at the head of the register and in its JSON, and if the two disagree the register is right and this paragraph is stale.