How the documents in this set are identified, versioned, approved, published, changed and retained — and why none of that is maintained by hand.
27001 Clause 7.5.127001 Clause 7.5.227001 Clause 7.5.342001 Clause 7.5Review. Reissued by any deployment that changes how documents are published or versioned. Reviewed in full at least once every 90 days, alongside the evidence-link walk recorded in DOC-27.
Two kinds. Documents — this policy set, the conformance register, the API reference and the change record — state what the service does and is meant to do. Records are the evidence that it did: the control receipt chain, the ninety-day service action log, the incident record, the deterministic tank logs, the metered spend history and the operating records in DOC-27.
The distinction matters because the two are controlled differently. A document is superseded when it changes. A record is never edited at all; where a record turns out to be wrong, a further record is written saying so, which is why the receipt chain carries a failed restore drill immediately before the passing one rather than only the pass.
Every document in this set carries a reference of the form DOC-nn, a stable anchor in the page, a title, a purpose, and the explicit list of clauses it is the record for. All four are rendered from the same source object, so a document cannot be published without them.
The format is a web page, and the same content is served as data at /policies.json. A document that exists only as a page an assessor has to read, and not as something a checker can walk, would make the link-checking below impossible.
The version of a document is the deployment that published it. That is not a naming convention; it is the mechanism. These pages are rendered by the Worker from source that ships in the same artefact as the running service, so there is no build in which the published document and the service it describes can disagree. A document is superseded by the next deployment that changes it, and there is no window in which a stale version is being served.
Each document is published at its own route, /policies/<identifier>/, and each section within it carries an anchor derived from its heading, so a clause can be cited down to the paragraph that answers it. The whole set previously rendered as one page with no identifier on any of its headings, which meant nothing in it could be linked to and the register had to point at the whole document.
The consequence, stated plainly because it is unusual: there is no revision history for these documents beyond the change record and the repository. Asking which version of DOC-18 was in force on a given date is answered by asking which deployment was live on that date, and the change record at /status/#delivery answers that with an identifier for every production deployment.
Approval is by the Owner, who is the only role that exists. DOC-03 states the limits of that arrangement and does not pretend it is a separation of duties.
Every document in this set is public and unauthenticated. There is no confidential tier of documentation, no distribution list, and nothing to control access to. Documents of external origin — the two standards themselves, and the provider's published terms and change notices — are not reproduced here; they are cited, because copying them would both breach their licences and create a copy that can go stale.
Protection against unintended alteration is the deployment path, not file permissions. A change to a published document is a change to tracked source, and reaches the public route only by a production deployment that appears in the change record. Records are protected differently and more strongly: the receipt chain is hash-linked with its head anchored outside the table it summarises, and state is copied daily to object storage under a digest, so an altered record is detectable and a lost one is recoverable.
The failure this arrangement is most likely to produce is a renamed anchor: a document keeps its content, its identifier changes, and every register row pointing at it silently stops resolving. Nothing about the page would look wrong.
So it is checked mechanically rather than watched for. A checker committed alongside the service walks the register's own manifest, fetches every evidence link on every row, requires public routes to answer 200 and operator routes to answer 401, and — the part that catches the renamed anchor — requires any fragment in a link to exist as an identifier in the page that comes back. The same pass asserts the honesty rule from the other direction: no row marked met may carry an evidence list with no link in it.
At this version the walk covers 46 distinct routes across every row of the register, with no broken links and no met row lacking a route. That count is re-read from the register whenever this page is rendered rather than written down here, so it cannot fall behind the register it describes.
Documents are retained for as long as the service runs, because the current version is the only version served and the history lives in the repository. Records are retained on stated windows that the service enforces rather than promises: the service action log for ninety days, deterministic tank logs for three days, the receipt chain and the incident record for the life of the service, spend samples for roughly fourteen days, and daily state copies for thirty days.
Those windows are enforced in code by trimming, and the trims are themselves receipted where they remove evidence, so a shrinking record cannot be mistaken for a quiet one.