How a risk to this service is identified, analysed and evaluated, and the criteria that decide whether it is acceptable.
27001 Clause 6.1.127001 Clause 6.1.227001 Clause 8.242001 Clause 6.1.242001 Clause 8.2Review. Reviewed when the acceptance criteria are found to be producing an answer the Owner would not act on, and otherwise at least once every 90 days alongside the assessment it governs.
There is one assessment method and it covers information security and the AI system together. The assets are the same assets: the computer-controlled sharks are a component of the same Worker, running on the same durable storage, under the same spend ceiling. Two methods over one object would produce two answers about it, and the second answer would be the one nobody checked.
Where a risk is specific to the AI system it is marked as such in the risk treatment plan. Nothing else about the method changes.
Four standing sources, each of which is a route on this site rather than a meeting nobody minuted. First, the open rows of the conformance register: every row not marked met is a statement that something is missing, and each one is read as a candidate risk. Second, the public security report intake, which is unauthenticated and accepts a report from anyone. Third, the incident record, because something that has already happened once is the cheapest risk to identify. Fourth, the cost and capacity meters, which show consumption approaching a limit before the limit is reached.
Identification also runs on demand. Any change record entry that adds a binding, adds a class of route, changes a retention window, or touches authentication triggers an identification pass for that change before it ships. The trigger is the change itself, not a calendar.
Every risk has one named owner. With one person running the service that owner is the Owner role in every case, and it is stated once here rather than repeated against each row.
Naming it still does work: acceptance of a risk is an act by the Owner recorded in the treatment plan, not the default that follows from nobody looking. An unrecorded risk is not an accepted one.
Two scales, each one to five, multiplied to a score between one and twenty-five. Consequence is judged against the three things the information security policy protects, in the order it puts them: the integrity of the public evidence, the availability of the game, and the small amount of data held about players.
Likelihood. 1 — remote: no path is known, and one would need a platform failure of the kind the supplier publishes as its own incident. 2 — unlikely: a path exists but needs an unusual combination, such as an operator mistake or a lost credential. 3 — possible: it has nearly happened, or one existing control is all that stands in the way. 4 — likely: expected at least once inside the ninety-day review window. 5 — present: it is the standing condition of the service rather than an event that might occur.
Consequence. 1 — negligible: nothing published becomes untrue and play is unaffected. 2 — minor: a session is disrupted or a published figure is briefly stale. 3 — moderate: the game is unavailable, or a display name can be abused — recoverable, and visible in the public record while it happens. 4 — major: the service is wholly unavailable including the evidence routes, or an attacker can act with the operator's authority. 5 — severe: something this service publishes as true becomes false, or the evidence that would show it is unrecoverable.
Score fifteen and above is not acceptable and is treated before the next production deployment. Score eight to twelve is treated inside the ninety-day review window, or accepted by the Owner with the justification written into the treatment plan. Score six and below is acceptable: recorded, accepted, and looked at again at the next interval.
One rule overrides the score. Any risk whose consequence is five is treated regardless of how unlikely it is. This service holds nothing of value except that what it publishes is true, so a risk that would falsify a published claim or destroy the evidence behind one is not allowed to be argued down by a low likelihood. The treatment plan shows this rule doing real work rather than sitting decoratively at the end of a method.
Repeatability comes from fixing the inputs, not from asserting rigour. Every run uses the same four identification sources, the same asset boundary as the scope statement, and the two scales above with their wording unchanged. The output is the risk treatment plan, published at a route, so a later run can be compared against the earlier one line by line rather than against a memory of it.
The scores are published rather than held. A score that only its author can see is a score nobody can dispute, and the whole point of putting this register on the public internet is that disputing it should be possible.
At least once every ninety days, matching the retention window of the service action log so that a full assessment always has a complete log behind it, and additionally whenever an identification trigger above fires.
The results of each run are the risk treatment plan at its published version. A run that changes nothing still reissues the plan, because a plan that has not been reissued and a plan nobody has looked at are indistinguishable from the outside.