The dated records produced by activities this management system defines and now performs: access review, supplier monitoring, compliance review, AI policy review, and the change-management records an assessor samples.
27001 Annex A.5.1827001 Annex A.5.2227001 Annex A.5.3627001 Annex A.5.442001 Annex A.2.4Review. Each record above is reissued when its own cycle next falls due — 90 days for access review, supplier monitoring and compliance review; on the stated trigger for the AI policy review. Reviewed in full as an input to the management review in DOC-29.
A recurring activity that has been defined but never run is not a control. Several rows on this register were partial for exactly that reason: the rule existed, the mechanism existed, and nobody had performed the activity or issued the record an assessor would ask to see.
Each record below is the first performance of one of those activities. They are dated by the deployment that published them, on the same basis as every other document here, and each states what was examined rather than only that an examination happened.
Performed at this version. Scope: every identity that can reach anything non-public in this service.
Findings. There is exactly one privileged identity — the operator — authenticated by one credential, and one authorisation decision in the whole service, which is whether a request carries it. Enumerated against the single route list that every gate consults: the operations console, the unredacted operational record, the ninety-day action log in both formats, the deterministic tank logs, the deterministic replay route, the state export, the copy trigger and the restore drill. All were confirmed to require the credential; the three added in this version were verified as gated, and the operations console was confirmed to refuse an unauthenticated request.
There are no other identities to review. No player account exists, no third party holds access, and no service account authenticates to anything. The browser-held identifier a player carries names a profile row and authorises nothing.
Conclusion: access rights are appropriate, because there is one and it is required in every place it should be. Two things are outside this review and are not implied by it — who holds write access to the source repositories, which is controlled by a hosting account outside the boundary, and the absence of scheduled credential rotation, which is recorded as accepted residual R-05.
Performed at this version, under the cycle DOC-19 defines: the pinned runtime compatibility date, and the provider's published changes, reviewed every ninety days.
Findings. One supplier of consequence: the platform provider, supplying compute, durable storage, object storage and DNS. The runtime remains pinned by an explicit compatibility date in tracked configuration, so a platform-side runtime change cannot alter behaviour without a deployment that changes that date. No change to the terms under which the service is offered was identified, and no incident attributable to the provider is recorded in the incident record.
The standing shortfall is restated rather than closed: the fourteen controls marked supplier on the register are marked on the basis that the provider holds certifications covering them, and those certificates are not held on file. Until they are, the supplier marking records where a control lives, not that it has been verified. This is not softened here because it costs no readiness percentage and would cost credibility.
Change monitoring specifically: platform and supplier changes now have a named owner, a defined trigger and this record. That closes the one process gap in the change-management set, which was that supplier-originated change was the only change class this service did not watch.
Performed at this version. This is the review of whether the service complies with its own policies, as distinct from the register, which records whether it complies with the standards.
Method. Every evidence link on every row of the register was fetched and checked: public routes required to answer 200, operator routes required to answer 401, and any anchor in a link required to exist as an identifier in the page returned. That last check is the one that catches a renamed document anchor, which is the failure this arrangement is most likely to produce. The same pass asserted that no row marked met carries an evidence list without a link in it.
A 200 is not accepted on its own, and this is the correction made at this version. Every unrouted path on this service answers 200 with the game shell, because that is what the single-page-application fallback is for, so the check meant to catch a deleted route could not catch one: a route removed from the service would have gone on passing. Each response must now carry something only the real page emits — the trust navigation landmark for a server-rendered page, a JSON content-type for a data route, the shell itself for the game at the root — and the 401 remains the whole assertion for an operator route. There is deliberately no table of per-route expected strings, which would become a second thing to keep in step with the pages.
Result: 46 distinct routes across 489 rows, no broken links, 142 met rows, none without a route. Those figures are derived from the register at the moment this page is rendered, not transcribed at the date of the review: an earlier version of this record stated them as a fixed result and was still stating the previous version's numbers two versions later. The checker is committed with the service rather than rewritten each time, so this review is repeatable by someone who is not the person who performed it.
Findings requiring action: none at this version. Findings from the previous version were recorded as nonconformities N-01 to N-04 in DOC-17 and corrected there. Weakness in this review, stated: it is a manual step with no automated gate behind it, so it depends on being performed. That is accepted residual R-07.
Performed at this version, against the trigger stated in the AI policy itself: any change to how a computer-controlled shark decides, to the roster size, or to the capability limits.
Findings. No such change has occurred since the policy was published. The policy's central claim — that the computer-controlled sharks are rule-driven, with no learned model, no training data, no inference call and no third-party AI service — was re-verified against the engine source rather than accepted from the previous review. The steering-rule description corrected as N-01 was confirmed to match the implementation. The AI objectives in DOC-08 were confirmed to be measurable from live routes, which is what makes the 42001 monitoring clause answerable at all.
Conclusion: the AI policy remains suitable, adequate and effective, and no change to it is required at this version. It is reissued unchanged.
The change processes on the register have always operated; what was missing was a named record an assessor could sample. Each is named here against the sampling route.
Classification. Every entry in the change record carries a class — feature, hotfix or bonus — assigned before it ships and visible at /status/#delivery and in its JSON. A hotfix is a correction to something already released; a feature adds capability; the classification decides how much of the register a change is expected to move.
Authorisation. Authorisation is the deployment itself, which is a deliberate act by the only role that can authorise one, and the production deploy script refuses to run when a required secret is absent. Every entry carries the deployment batch identifier that shipped it, so authorisation and change are the same record seen twice.
Post-implementation review. Each change record entry carries concrete evidence bullets written after the change shipped, stating what was verified rather than what was intended. Where the review found the change insufficient, the following entry says so — the run of accessibility hotfixes is the clearest sample of that.
Review of unintended change. The receipt chain, the incident record and the metered spend series are the three places an unintended change would show. The chain is re-derived on every read and its verdict published; the spend series is compared against a hard limit that closes the game by itself; the incident record carries a cause for every entry. This version adds a fourth: a daily state copy under a digest, which makes an unintended change to durable state detectable by comparison rather than only by inspection.
None of these is an internal audit. They are the operation of defined activities by the person who defined them, which is what the clauses they discharge actually ask for. The internal audit clause asks for something different and harder, and it is dealt with separately and less comfortably in DOC-29.