A Risk Register That Justifies Nothing

a) The risk criteria are absent or invisible (6.1.2 a). A 5x5 matrix with no documented definitions of what '5' means for likelihood and consequence is not a criterion, it is a preference. Consequence: scores are not reproducible; two assessors score the same risk differently, and the auditor cannot verify consistency.

b) No defined acceptability threshold (6.1.2 a, 6.1.3 c). Nothing states what residual level is tolerable, so 'accepted' is an opinion rather than a decision. Consequence: three score-25 risks are accepted with no analysis and no route to challenge it.

c) Ownership is fictional. One IT manager owning 214 risks means no business owner is accountable. Under 6.1.3 b) risk owners must approve the treatment plan and accept residual risk; an IT manager cannot accept a payment-gateway outage on behalf of the business. Consequence: acceptance is unauthorised and, at Stage 2, indefensible.

d) No treatment plan for the critical risks (6.1.3 e, 6.2). 'Accepted' without justification is not a treatment decision. Consequence: the ISMS cannot show it is achieving intended outcomes.

e) Assessment not repeated (8.2). Fourteen months and two significant changes with no reassessment. Consequence: the register describes an organisation that no longer exists.

Is it a breach? Not automatically. The standard requires the SoA to state whether each necessary control is implemented, and to justify inclusions and exclusions (6.1.3 d). Claiming all 93 is permitted in principle - many mature organisations do.

Why this SoA still fails:

• No traceability. Each control must be linked to the risk treatment decision that caused it to be selected. A blanket 'applicable' with 'industry best practice' breaks the chain from 6.1.2 → 6.1.3 → Annex A. The auditor's standard test is to pick a control and ask which risk required this; the answer here is 'none'.
• Justification is not a justification. 'Best practice' is a source, not a reason. A defensible entry names the risk or obligation (contract, legal, the retailer's schedule) that drives the control.
• Current-state clarity is missing. The SoA should also state implementation status; claiming applicability says nothing about whether the control is actually operated.

Judgement: the fix is not to delete controls but to re-derive the SoA from the risk assessment and from obligations. Where a control is retained purely as a baseline, say so explicitly and name the obligation or decision behind it. That is a defensible position; 'best practice' is not.

Both are changes that trigger clause 6.3 (planned changes) and clause 8.2/8.3 (risk assessment and treatment at planned intervals or when significant change is proposed). The order matters:

1. Determine whether they are inside the ISMS scope (4.3). If Frankfurt hosts customer data, it is almost certainly in scope; if it does not, document why and how it is segregated. Payroll processing is in scope to the extent that the ISMS covers the people and data involved.
2. Re-run risk assessment for the changed areas (6.1.2, 8.2). New jurisdiction, new data residency questions, new sub-processors, loss of direct control over payroll data.
3. Decide treatment and update the SoA (6.1.3, 8.3). Supplier-related controls become live: supplier relationship security, addressing security in supplier agreements, monitoring and review of supplier services, and management of the ICT supply chain. Frankfurt likely makes cloud-specific controls and jurisdictional/legal controls relevant.
4. Update the risk register with new owners - the payroll risk belongs to HR/Finance, not IT.
5. Record the change and its approval so the auditor can see the ISMS responded to the change rather than discovering it.

Judgement: the cardinal error would be to add both to an asset list and leave the register untouched. The auditor's likely question is 'what changed, and what did your ISMS do about it?'