How a decision is taken between treating, accepting, avoiding and sharing a risk, and how the resulting plan is approved and verified.
27001 Clause 6.1.327001 Clause 8.342001 Clause 6.1.342001 Clause 8.3Review. Reviewed whenever a treatment decision is taken that the four options above do not cleanly describe, and otherwise at least once every 90 days.
Treat — apply or strengthen a control. This is the default where the score is fifteen or above, and it is mandatory where the consequence is five, under the overriding rule in the assessment method.
Accept — the Owner records the residual risk and the reason for living with it. Available at score twelve and below. Acceptance has to be written into the treatment plan to count; inaction is not acceptance, and a risk nobody wrote down has not been accepted by anyone.
Avoid — remove the feature, the route or the scope that carries the risk. Under a five dollar ceiling this is a real option rather than a rhetorical one: a control that costs more than the thing it protects is worth is a reason to delete the thing.
Share — available only where the infrastructure provider already carries the risk under its own certification, and the register marks those rows as supplier for exactly that reason. Sharing is not a way to move a risk this service actually holds. A supplier marking means nothing until the supplier's certificate is held on file, and the register says so on every one of those rows.
A control that materially raises metered consumption is itself a risk, because measured spend reaching the hard limit closes the game. Every proposed treatment is checked against the cost and capacity meters before it ships, and a treatment that would move a meter noticeably is recorded with that cost rather than adopted quietly.
This is the one place where the constraint that dominates the whole design shows up as a process step instead of a background fact.
Once controls are chosen they are compared, control by control, against Annex A of both standards, to check that necessary controls were not omitted. The conformance register is that comparison: all ninety-three controls of ISO/IEC 27001 Annex A and all thirty-eight of ISO/IEC 42001 Annex A appear with a decision.
The comparison is why exclusions carry a justification rather than a blank. A control left out without a reason is indistinguishable from a control nobody thought about, and an assessor cannot tell the difference either.
The treatment decisions become the risk treatment plan. The Owner approves the plan and, in the same act, accepts the residual risk it names.
Approval is evidenced by the deployment that publishes it. Each publication is a change entry with its own identifier in the change record, and a control action leaves a receipt in the append-only chain whose head is anchored outside the table it summarises. There is no approval step that leaves no trace, because there is no path to production that leaves no trace.
Each treatment ships as a recorded change naming the finding it closes, the fix, and the evidence it produces. That is already how every finding closed to date has been handled; this document states the rule the practice was already following.
Verification is deliberately mechanical: the evidence route named on the row is fetched, and it either returns what the row claims or the row is wrong. Public routes must answer 200, operator routes 401 without a credential. A row whose evidence link is dead is treated as a finding in its own right rather than as a broken link.
Treatment happens on one person's schedule and against one person's judgement. There is no second opinion in the loop, and the process above cannot manufacture one.
That limitation is why the independent review and internal audit rows on the register stay open rather than being asserted here. A treatment process that claimed independent challenge it does not have would be the first thing to fail under examination.