A.5.1 |
Policies for information security |
Show a defined, approved, published and reviewed policy set. |
Evidenced |
The policy set is defined, published and communicated by being a public route, and each document names the clauses it is the record for. |
|
A.5.2 |
Information security roles and responsibilities |
Show roles defined and allocated according to need. |
Evidenced |
Roles are defined and allocated, including which of them may take the game down and which may change what the service does. |
|
A.5.3 |
Segregation of duties |
Show conflicting duties and areas of responsibility are segregated. |
Excluded |
Excluded: the control presumes more than one person, and there is exactly one. No division of conflicting duties is available at any cost, so recording this as a gap would imply a shortfall that could be closed by effort. It re-enters scope on the first hire. What the design substitutes — receipts, a public change record and deterministic replay — is detection rather than separation, and is recorded as accepted residual R-08 rather than offered as compensation here. |
|
A.5.4 |
Management responsibilities |
Show management requires all personnel to apply information security per the policy. |
Evidenced |
The requirement is established in the roles document and discharged through the management review, which is where the Owner reviews conformance against the policy set and records decisions. With one person, requiring personnel to apply the policy and being the personnel are the same act; the record is the review, not an instruction to somebody else. |
|
A.5.5 |
Contact with authorities |
Show maintained contacts with relevant authorities. |
Partial |
The relevant authorities and the circumstances that would trigger contact are now identified: a data protection supervisory authority on a breach or a routed complaint, the national cybercrime reporting route on an intrusion, and the provider's abuse contact for anything originating on the platform. No relationship with any of them is maintained. Identifying who to call is not knowing them, and the standard asks for the second. |
|
A.5.6 |
Contact with special interest groups |
Show contact with security forums and professional associations. |
Gap |
None maintained. The public report intake is inbound only and is not a substitute for participation in a security community, so it is not offered as one. Left as a gap rather than argued into something else. |
|
A.5.7 |
Threat intelligence |
Show threat information collected and analysed to produce intelligence. |
Gap |
No threat intelligence process. Findings arrive through the public report intake rather than being sought. |
|
A.5.8 |
Information security in project management |
Show security integrated into project management. |
Evidenced |
There is no separate security workstream: every change is classified before it is built, the classification states whether it touches authentication, public input, retention or spend, and that answer decides how much of the release gate applies. Where a change alters a recorded treatment, the risk treatment plan is reissued in the same deployment. |
|
A.5.9 |
Inventory of information and other associated assets |
Show an inventory with owners. |
Evidenced |
Eight assets inventoried exhaustively rather than representatively, each with an owner and a classification: the Worker, the per-tank durable class, the shared durable instance, the object storage bucket, the domain, the source repositories, the operator credential and this documentation. The list can be complete because everything in scope is bound in one configuration file the deployment reads — an asset absent from it is not reachable by the running service. |
|
A.5.10 |
Acceptable use of information and assets |
Show rules for acceptable use, documented and implemented. |
Evidenced |
Acceptable use is stated in the policy: play, read the evidence, report problems. Unacceptable use names leaderboard automation, spend exhaustion and impersonating display names — the last of which is enforced in code rather than by request. |
|
A.5.11 |
Return of assets |
Show assets returned on change or termination. |
Excluded |
No personnel and no issued assets. Re-enters scope on the first hire or contractor. |
No evidence held — excluded from scope. |
A.5.12 |
Classification of information |
Show information classified by legal, value, criticality and sensitivity. |
Evidenced |
Three tiers, deliberately few: public, operator-only and secret. There is no confidential-but-not-secret tier, because there is no third party to share anything with and inventing one would be labelling rather than classifying. Each inventoried asset carries its tier, and the state copies inherit the strictest classification of anything inside them. |
|
A.5.13 |
Labelling of information |
Show labelling procedures consistent with the classification scheme. |
Evidenced |
Labelled where a label can be acted on and not otherwise. Every route in the API reference states whether it is public or requires the operations credential, and the register's evidence links carry the same distinction in machine-readable form — which is what lets the link checker assert operator routes answer 401 and public routes 200. The 200 is no longer taken on its own: because the asset fallback answers 200 for any path at all, a public route must also return a marker only the real page emits before the checker counts it as served. Physical and media labelling have no application: no premises, no removable media, every document public. |
|
A.5.14 |
Information transfer |
Show rules and controls for transfer inside and outside the organisation. |
Evidenced |
Every route refuses plaintext; operations routes are never redirected, because a redirect would mean the credential already crossed in clear text. Strict transport security is set on every response, and there are no third-party endpoints in the page delivery path. |
|
A.5.15 |
Access control |
Show rules to control physical and logical access, based on requirements. |
Evidenced |
One list defines every credentialed route, and the same list drives the gate — so a new control route cannot be added without also being gated. |
|
A.5.16 |
Identity management |
Show the full life cycle of identities is managed. |
Evidenced |
There is one identity — the operator, authenticated by one credential — and its life cycle is stated: created as a platform secret, never in tracked configuration, rotated on demand, and required by every gated route. There are no player accounts, no passwords and no registration; the browser-held identifier names a profile row, authenticates nobody and authorises nothing. Adding any credential store would put the service outside the security policy as written. |
|
A.5.17 |
Authentication information |
Show allocation and management of secrets controlled by a management process. |
Evidenced |
The operations credential exists only as a platform secret. With no secret configured the gate denies rather than falling open, comparison is constant-time over digests so no length leaks, and the credential is refused entirely over plaintext. |
|
A.5.18 |
Access rights |
Show access rights provisioned, reviewed, modified and removed against a policy. |
Evidenced |
An access review has been performed and recorded. It enumerated every non-public route against the single list every gate consults, confirmed all require the credential including the three added this version, and confirmed the operations console refuses an unauthenticated request. Two things are explicitly outside it and not implied by it: repository write access, controlled outside the boundary, and the absence of scheduled credential rotation, accepted as R-05. |
|
A.5.19 |
Information security in supplier relationships |
Show processes to manage supplier-related risk. |
Evidenced |
One supplier, total dependency, and the supplier policy states exactly what is entrusted to it — including that the provider holds the credential that guards the service against the provider's other customers. The mitigation recorded is not encryption or a second region, neither of which is available at this scale, but holding nothing that would matter. The dependency is an assessed risk with the residual accepted by the Owner. |
|
A.5.20 |
Addressing security within supplier agreements |
Show security requirements agreed with each supplier. |
Partial |
Five security requirements of the provider are now determined and recorded, with how each is addressed and how far it can be verified. What is missing is the word agreed: this is a free project with no contract, the standard terms are accepted as offered, and nothing has been negotiated. Recording that as an accepted position is honest; recording it as an agreement reached would not be. |
|
A.5.21 |
Managing security in the ICT supply chain |
Show processes to manage risk from the products and services supply chain. |
Partial |
The shipped dependency set is now inventoried by licence in the legal register, the surface is deliberately small and pinned by a lockfile, and the Worker imports only the engine, store and protocol entry points so browser libraries cannot enter the server bundle. Still missing, and it is the same weakness as the technical vulnerabilities row: no advisory process and no scan. Open on the risk treatment plan. |
|
A.5.22 |
Monitoring, review and change management of supplier services |
Show supplier service delivery is monitored, reviewed and changes managed. |
Evidenced |
The ninety-day cycle defined in the supplier policy has been run and recorded: the runtime remains pinned by an explicit compatibility date in tracked configuration so a platform-side change cannot alter behaviour without a deployment, no change to the offered terms was identified, and no provider-attributable incident is recorded. The record restates rather than closes the standing shortfall that the supplier certificates are not held on file. |
|
A.5.23 |
Information security for use of cloud services |
Show processes for acquisition, use, management and exit of cloud services. |
Evidenced |
Acquisition and use are declared in version-controlled configuration and metered against a hard limit; management is the pinned runtime and the defined review; and the exit strategy is written, including the part that hurts. Code, assets and the domain would move; the durable state would not, because no export exists, so an exit today would lose the receipt chain. The same missing engineering closes that and the backup gap. |
|
A.5.24 |
Incident management planning and preparation |
Show planned processes, roles and responsibilities for incident management. |
Evidenced |
Intake, assessment, response, restoration and closure are separate operations with separate routes, separate authorisation and separate records — deliberately so, because reporting must never be the same act as taking the service down. |
|
A.5.25 |
Assessment and decision on information security events |
Show events assessed and classified into incidents or not. |
Evidenced |
A public report records an event and raises it; whether it warrants downtime is a separate authenticated operator decision, and both steps are recorded. |
|
A.5.26 |
Response to information security incidents |
Show response according to documented procedures. |
Evidenced |
Lockdown closes active connections and gates game traffic while every evidence route stays online. Restoring traffic records the end of impact and explicitly does not close the underlying report. |
|
A.5.27 |
Learning from information security incidents |
Show knowledge from incidents used to strengthen controls. |
Evidenced |
Each report produces a published hotfix entry naming the trigger, the closure time and the controls strengthened. The pattern is visible across the whole post-delivery record. |
|
A.5.28 |
Collection of evidence |
Show procedures for identification, collection, acquisition and preservation of evidence. |
Evidenced |
Control decisions are appended to a SHA-256 chain that is re-derived on every read, with the verdict stated on the page. An altered entry is named by sequence number. |
|
A.5.29 |
Information security during disruption |
Show security is maintained during disruption. |
Evidenced |
Continuity here is about not losing the evidence rather than keeping the game up, which is stated to players rather than implied. Two disruptions are planned for: a platform outage, carried by the provider and accepted as R-04, and loss of the shared durable instance, which was untreated until this version and is now covered by a daily digested copy with a proven restore. Security properties survive a restore because the receipt chain is restored with its anchor and re-verified on read. |
|
A.5.30 |
ICT readiness for business continuity |
Show ICT continuity is planned, implemented, tested and reviewed. |
Evidenced |
Planned, implemented and tested: a daily copy to object storage, thirty dated copies retained, each run receipting its own outcome, and a restore drill that reads the stored copy back out of object storage, restores it into a scratch instance and compares digests. Reviewed after every drill and every failed copy. What is deliberately not claimed: no recovery time or recovery point objective is committed to, no real recovery has been executed, and there is no second region or failover. |
|
A.5.31 |
Legal, statutory, regulatory and contractual requirements |
Show requirements identified, documented and kept current. |
Evidenced |
Issued: data protection obligations and the basis on which they attach, the provider's terms and which of them actually bite, the licence obligations of everything shipped, the standards as voluntary criteria with no certification claimed, and an explicit list of what does not apply and why. Kept current by four named triggers plus the 90-day cycle. Three items are recorded as open rather than resolved: no erasure route, no age gate, and which supervisory authority is the lead one. |
|
A.5.32 |
Intellectual property rights |
Show procedures to protect intellectual property. |
Evidenced |
Inventoried rather than assumed. This service and its engine are MIT; every dependency that reaches the shipped artefact is MIT — the renderer, its React binding, React and its DOM package. Build-time tooling adds an Apache 2.0 and a dual-licensed package, neither of which ships. No copyleft licence is present anywhere, so no source-disclosure obligation arises beyond the one taken on voluntarily. Adding a dependency under an unlisted licence is a change to this register, not an ordinary bump. |
|
A.5.33 |
Protection of records |
Show records protected from loss, destruction, falsification and unauthorised access. |
Evidenced |
Retention is enforced in code, public writes are capped so a flood cannot evict recorded evidence, and control receipts are exempt from the action-log retention window. |
|
A.5.34 |
Privacy and protection of PII |
Show identification and implementation of privacy requirements. |
Partial |
The notice is now published and exhaustive: the five fields held, the purpose and basis, and the retention rule stated accurately rather than as a clean 90 days — a profile that never scored is deleted after 90 days unseen, one holding a best score is kept indefinitely so the published leaderboard stays whole. Implementation is strong in code and short in one place: there is no route by which a player can ask for erasure, and clearing the cookie orphans a profile rather than deleting it. Recorded as an open risk, not argued away. |
|
A.5.35 |
Independent review of information security |
Show independent reviews at planned intervals and after significant change. |
Excluded |
Excluded: independence is unavailable at one person and cannot be manufactured by procedure. Recording it as a gap would imply a shortfall closable by effort; it re-enters scope on the first hire or on engaging an external assessor. The evidence being public, machine-readable and checkable by a committed checker makes the review independently repeatable, which is a weaker property than independent and is not claimed as this control. |
|
A.5.36 |
Compliance with policies, rules and standards |
Show compliance with the organisation's own policies is regularly reviewed. |
Evidenced |
A compliance review against this policy set has been performed and recorded, distinct from the register's review against the standards. Method and result are both stated: every evidence link fetched, public routes required to answer 200, operator routes 401, every anchor required to exist as an identifier in the page returned, and no met row permitted an evidence list without a link. Thirty-seven routes, no failures. The weakness — that it is a manual step with no automated gate — is recorded as R-07. |
|
A.5.37 |
Documented operating procedures |
Show procedures documented and available to those who need them. |
Evidenced |
Four issued procedures, each at a route: route-level operation in the API reference, development and release in the secure development document, change control as the processes on this register, and incident handling as the intake and the incident record. Writing the third of those found the first gap in the first: the unauthenticated public write route was operating undocumented, and it is documented now. What is deliberately not given its own entry — slash variants, three noted aliases, a redirect, the operator paths under the register's old prefix, and two proxy routes to a backend not configured here — is listed rather than glossed. |
|
A.6.1 |
Screening |
Show background verification of candidates. |
Excluded |
No personnel are engaged. Re-enters scope on the first hire. |
No evidence held — excluded from scope. |
A.6.2 |
Terms and conditions of employment |
Show security responsibilities in employment agreements. |
Excluded |
No employment agreements exist within the scope. |
No evidence held — excluded from scope. |
A.6.3 |
Security awareness, education and training |
Show an awareness programme and training appropriate to role. |
Excluded |
Excluded: an awareness and training programme presumes people to deliver it to, and there are none. The one person is the author of the policy set rather than an audience for it, so a programme would be a document addressed to its own writer. Re-enters scope on the first hire. Clause-level awareness is discharged separately and is recorded there. |
|
A.6.4 |
Disciplinary process |
Show a formalised, communicated disciplinary process. |
Excluded |
No personnel within the scope. |
No evidence held — excluded from scope. |
A.6.5 |
Responsibilities after termination or change of employment |
Show responsibilities that remain valid after termination, and their enforcement. |
Excluded |
No personnel within the scope. |
No evidence held — excluded from scope. |
A.6.6 |
Confidentiality or non-disclosure agreements |
Show identified, documented, reviewed confidentiality agreements. |
Excluded |
No party other than the infrastructure provider holds access, and that access is governed by the provider's own terms. |
No evidence held — excluded from scope. |
A.6.7 |
Remote working |
Show security measures for remote working. |
Excluded |
Excluded on the scope statement's existing ground: the operator's device is outside the boundary of this management system. Rules for it are stated in the access policy and the repository-side parts are checkable, but the machine's own state is attested rather than evidenced, and no route this service could serve would prove anything about it. Excluded deliberately rather than left permanently partial, and no mobile device policy has been invented to cover it. |
|
A.6.8 |
Information security event reporting |
Show a mechanism for timely reporting of observed events. |
Evidenced |
A public, documented, same-origin intake accepts white-hat reports, records each one with a receipt, raises it to operations, and deliberately changes no service state. Accepted reports are throttled to one per minute. |
|
A.7.1 |
Physical security perimeters |
Show perimeters protecting areas holding information and processing facilities. |
Supplier |
Standing condition for all fourteen supplier rows, restated here because it is not discharged: a supplier marking records where a control lives, not that it has been verified, and it means nothing until the provider's certificate is held on file. It is not. The supplier monitoring record confirms nobody has obtained them, and these rows are excluded from the readiness denominator, so leaving this open costs no percentage — only credibility if it were written otherwise. All processing runs in the provider's data centres. Inherited from the provider's own certified controls; their certificate needs to be held on file. |
- Provider certificate required
|
A.7.2 |
Physical entry |
Show secure areas protected by entry controls. |
Supplier |
Provider-operated. No premises within the scope. |
- Provider certificate required
|
A.7.3 |
Securing offices, rooms and facilities |
Show physical security designed and implemented for facilities. |
Supplier |
Provider-operated. |
- Provider certificate required
|
A.7.4 |
Physical security monitoring |
Show premises continuously monitored for unauthorised access. |
Supplier |
Provider-operated. |
- Provider certificate required
|
A.7.5 |
Protecting against physical and environmental threats |
Show protection against natural and human physical threats. |
Supplier |
Provider-operated. |
- Provider certificate required
|
A.7.6 |
Working in secure areas |
Show security measures for working in secure areas. |
Supplier |
Provider-operated. |
- Provider certificate required
|
A.7.7 |
Clear desk and clear screen |
Show clear desk and clear screen rules are defined and applied. |
Excluded |
Excluded on the scope statement's existing ground: there are no premises, and the operator's device is outside the boundary. The screen half of the control would apply only to that device, whose state cannot be evidenced from any route this service serves. |
|
A.7.8 |
Equipment siting and protection |
Show equipment sited and protected securely. |
Supplier |
Provider-operated. |
- Provider certificate required
|
A.7.9 |
Security of assets off-premises |
Show protection for assets used outside the organisation's premises. |
Excluded |
Excluded on the scope statement's existing ground. There are no premises, so every asset is nominally off-premises; the only physical asset in question is the operator's device, which the scope statement places outside the boundary. The in-scope assets are all platform-hosted and are addressed by the supplier rows. |
|
A.7.10 |
Storage media |
Show management of storage media through its life cycle. |
Excluded |
No removable media are used. All data resides in the provider's managed storage and is deleted by retention rules enforced in code. |
|
A.7.11 |
Supporting utilities |
Show protection from power and utility failures. |
Supplier |
Provider-operated. |
- Provider certificate required
|
A.7.12 |
Cabling security |
Show power and telecommunications cabling protected. |
Supplier |
Provider-operated. |
- Provider certificate required
|
A.7.13 |
Equipment maintenance |
Show equipment correctly maintained. |
Supplier |
Provider-operated. |
- Provider certificate required
|
A.7.14 |
Secure disposal or re-use of equipment |
Show verified removal of data before disposal or re-use. |
Supplier |
Provider-operated. |
- Provider certificate required
|
A.8.1 |
User endpoint devices |
Show information on user endpoint devices is protected. |
Excluded |
Excluded on the scope statement's existing ground: the operator's device and the player's browser are both outside the boundary. Rules for the operator's device are stated in the access policy, and it holds the ability to change the service — which is why they are stated rather than the matter being left silent — but its configuration cannot be evidenced, so the row is excluded rather than marked met on an attestation. |
|
A.8.2 |
Privileged access rights |
Show privileged access restricted and managed. |
Evidenced |
There is exactly one privileged path. It accepts only the minted token, only over transport security, and denies outright when no token is configured — the earlier unauthenticated fallback was removed and the removal is published with its closure time. |
|
A.8.3 |
Information access restriction |
Show access to information restricted per the access control policy. |
Evidenced |
Public and operator views are separated by one shared route list used by both the authentication gate and the availability gate, so the two cannot disagree. |
|
A.8.4 |
Access to source code |
Show read and write access to source appropriately managed. |
Partial |
What can be demonstrated is documented: the source is not reachable from any route, no secret appears in any served response, and the deploy path needs credentials the repository does not contain. What cannot be is stated rather than asserted — who holds write access, and whether anyone reviewed that list, is controlled by a hosting account outside the scope boundary, and no route this service serves could prove it. Left partial for exactly that reason. |
|
A.8.5 |
Secure authentication |
Show secure authentication technologies and procedures. |
Evidenced |
Token-only, transport-secured, constant-time comparison over digests, fail-closed when unconfigured, and refused outright on plaintext rather than redirected. |
|
A.8.6 |
Capacity management |
Show resource use monitored and adjusted against capacity requirements. |
Evidenced |
Seat capacity per tank is enforced where the seat is claimed rather than where the connection opens, and consumption is metered per service against a stated hard limit with a projection and a redline. The limit now closes the two unauthenticated write routes along with the game: it previously exempted every API path, so the routes generating the billable durable writes kept running while the thing they paid for was switched off. Reads and the report intake stay up. Egress is managed as well as writes: the page stylesheet is served once under a content-hashed name and cached, rather than inlined into every no-store response, which took a trust page from 45 KB to 7 KB and a policy document from 49 KB to 11 KB. |
|
A.8.7 |
Protection against malware |
Show malware protection implemented and supported by awareness. |
Evidenced |
The control is the absence of a vector, and it is now documented as such. No route accepts a file, a multipart body or a form upload, and no code path in the Worker reads one; the only content the public can store is a sixteen code point display name and a pattern-checked skin identifier; the runtime executes only the deployed bundle with no shell and no runtime package installation. The awareness half is not claimed — the operator endpoint is outside the scope boundary. |
|
A.8.8 |
Management of technical vulnerabilities |
Show vulnerability information obtained, exposure evaluated, and measures taken. |
Partial |
Evaluation and measures are documented and operated: a report is receipted on arrival, the code path is read, the route or tick is exercised rather than reasoned about, and the fix ships as a change entry with its closure time published. Obtaining information is the half that is missing — nothing scans dependencies, no advisory feed is subscribed to, and there is no automated build to run a scan in. Open on the risk treatment plan; deliberately not marked met. |
|
A.8.9 |
Configuration management |
Show configurations established, documented, implemented, monitored and reviewed. |
Evidenced |
Every binding, variable, route and limit lives in one version-controlled file that is deploy-valid as written; there is no hand-configured state at the edge to drift away from it. |
|
A.8.10 |
Information deletion |
Show information deleted when no longer required. |
Evidenced |
Action records are trimmed at 90 days, tank captures at 24 hours, and a retention generation change wipes the record deliberately and observably rather than by hand. |
|
A.8.11 |
Data masking |
Show data masking used per the access control policy and applicable requirements. |
Evidenced |
Public output is redacted at every depth for the running version identifier and the storage bucket name, and public logs carry no player identifiers. The operator view keeps the full record. |
|
A.8.12 |
Data leakage prevention |
Show measures preventing unauthorised disclosure and extraction. |
Evidenced |
Failures return a generic message while detail goes only to the operator log; build and storage identifiers are stripped from public output; and exported names cannot be interpreted as spreadsheet formulas. |
|
A.8.13 |
Information backup |
Show backups maintained and tested against an agreed policy. |
Evidenced |
State is copied daily to object storage under a digest covering both places it lives — the durable object's keys and the two tables beneath them — with thirty dated copies retained and each run receipting its own outcome, so a failed copy is visible rather than silent. Tested by execution: a drill reads the most recent copy back out of object storage, restores that copy into a scratch instance, exports it and compares digests, which compares every key and row at once rather than sampling. The stored copy is the thing under test: with no bucket bound or no copy in it the drill fails and says so rather than testing the live object instead. The first drill failed for a real reason and is on the public chain before the passes. |
|
A.8.14 |
Redundancy of information processing facilities |
Show facilities implemented with sufficient redundancy for availability requirements. |
Supplier |
Redundancy is the provider's, and the availability it produces is measured and published from project start. |
|
A.8.15 |
Logging |
Show logs recording activities, exceptions, faults and events, and kept protected. |
Evidenced |
Three independent records exist: a 90-day service and action log with reason codes, a 24-hour per-tank capture, and an unexpiring control receipt chain. All three are downloadable and the first two are public. |
|
A.8.16 |
Monitoring activities |
Show networks, systems and applications monitored for anomalous behaviour. |
Evidenced |
Availability, occupancy, request velocity, spend and rate-limit buckets are all observable live, and the authenticated record adds instance residency so an in-memory throttle can be proven to be firing. Both unauthenticated write routes are bucketed the same way — per edge connection and under a global ceiling — including the profile write, which was previously bounded only in how many rows it could create and not at all in how often an existing one could be overwritten. |
|
A.8.17 |
Clock synchronisation |
Show clocks synchronised to approved time sources. |
Supplier |
Time comes from the provider's runtime; every record is timestamped from it and ordered by sequence in the receipt chain. |
|
A.8.18 |
Use of privileged utility programs |
Show restriction and tight control of utility programs capable of overriding controls. |
Evidenced |
The runtime exposes no interactive shell and no administrative utility. The only privileged capability is the authenticated control route set, and every use of it is receipted. |
|
A.8.19 |
Installation of software on operational systems |
Show procedures managing installation on operational systems. |
Evidenced |
The only route to production is a versioned deployment of the entire bundle. There is no in-place editing, no partial upload and no runtime package installation. |
|
A.8.20 |
Networks security |
Show networks and devices secured and managed to protect information. |
Evidenced |
Two listeners exist: transport-secured requests and a same-origin socket upgrade. Plaintext is refused, credentialed paths are never redirected, and socket upgrades check the origin against the request host. One header table is applied to every response the Worker emits rather than per branch — Permissions-Policy was previously set only on the static asset path, so the server-rendered pages shipped without it. |
|
A.8.21 |
Security of network services |
Show security mechanisms and service levels for network services identified and managed. |
Evidenced |
Transport security is mandatory and stated on every response; the availability produced is measured and published rather than asserted. |
|
A.8.22 |
Segregation of networks |
Show groups of services and systems segregated on networks. |
Supplier |
Isolation between tenants and between durable instances is the provider's; within the scope each tank is a separate durable instance with its own state. |
|
A.8.23 |
Web filtering |
Show access to external websites managed to reduce exposure. |
Excluded |
The service performs no user-directed browsing. Outbound requests are limited to one configured same-account origin, validated for scheme and rejected if it resolves back to this origin. |
|
A.8.24 |
Use of cryptography |
Show rules for effective use of cryptography, including key management. |
Evidenced |
Four uses are documented and there are no others: TLS with a year of strict transport security and operations routes refusing plaintext outside loopback; SHA-256 receipt chaining over a versioned canonical serialisation with one hash function shared by writer and verifier; cryptographic randomness for the per-response nonce and the visitor identifier, kept strictly apart from the simulation's seeded generator; and constant-time credential comparison. Key management is complete because it is small: one platform secret, never in tracked configuration, rotated on demand, no key hierarchy and no certificate this service manages. |
|
A.8.25 |
Secure development life cycle |
Show rules for secure development established and applied. |
Evidenced |
Issued as an approved procedure with an owner and named review triggers, covering coding rules, content security policy, cryptography, the release gate, deployment and what happens afterwards. It applies to the Worker, both durable classes and the engine submodule alike, because they ship as one artefact. |
|
A.8.26 |
Application security requirements |
Show security requirements identified, specified and approved for applications. |
Evidenced |
The application enforces a strict content policy with a per-response token and no inline allowance, a full set of transport and framing headers, and same-origin plus explicit action headers on every state-changing operation. |
|
A.8.27 |
Secure system architecture and engineering principles |
Show principles for engineering secure systems established and applied. |
Evidenced |
The simulation is server-authoritative, so no client claim is trusted; gates fail closed; the credentialed route list has one definition used by every gate; and the Worker imports only server-safe entry points so browser code cannot enter the server bundle. |
|
A.8.28 |
Secure coding |
Show secure coding principles applied to software development. |
Evidenced |
The standard is written down: strict type checking as a security rule rather than a tidiness one, one escape helper per module so a review question has one place to look, input validated against a fixed pattern rather than repaired and trusted, exports treated as an injection surface with a formula-injection guard on the text log, constant-time secret comparison, and authorisation with no branch that grants by falling through. |
|
A.8.29 |
Security testing in development and acceptance |
Show security testing processes defined and implemented in the development life cycle. |
Evidenced |
Defined with named acceptance criteria and operated on every release: build, a clean type check across Worker, engine and client, clean trees in both repositories checked separately, then the release exercised against the same runtime production uses on repeated cache-busted requests. Four contract checks run with it — every inline script nonced with no placeholder surviving, the operator console answering unauthorised, the receipt chain verdict verified, and every evidence link resolving. Stated limitation: it is a checklist a person performs, not a pipeline that enforces it. |
|
A.8.30 |
Outsourced development |
Show outsourced development directed, monitored and reviewed. |
Excluded |
No development is outsourced. |
No evidence held — excluded from scope. |
A.8.31 |
Separation of development, test and production environments |
Show environments separated and secured. |
Evidenced |
Development runs the production runtime against its own empty in-memory storage; production is a separate named configuration with its own bucket and its own durable storage. See CM-04. |
|
A.8.32 |
Change management |
Show changes subject to change management procedures. |
Evidenced |
Fourteen documented processes cover classification, request, authorisation, environment separation, verification, release, configuration, rollback, emergency change, post-implementation review, unintended change, supplier change, record integrity and AI change. Every production change carries an identifier, a deployment grouping and its evidence, and the record is public. |
|
A.8.33 |
Test information |
Show test information appropriately selected, protected and managed. |
Evidenced |
No production data is used for testing. The local runtime starts from an empty in-memory store on every run, by design. |
|
A.8.34 |
Protection of information systems during audit testing |
Show audit tests on operational systems planned and agreed to minimise disruption. |
Evidenced |
Every route on this register is safe to exercise: public evidence routes are read-only, and each control mutation needs authentication plus a same-origin request plus an explicit action header. Closing a security report additionally requires an explicit dry-run flag and owner confirmation. |
|