Northwind Freight: a single 'cloud' risk line and a board minute that says risk is transferred
Northwind Freight runs 340 workloads, 61 of them in a public IaaS tenancy, with a plan to close both data centres within 18 months. The risk register lists cloud as a single asset, with likelihood rated low because the IaaS provider holds an ISO/IEC 27001 certificate and issued a SOC 2 Type II report that the security manager downloaded last year. Every cloud risk line is owned by the IT infrastructure manager, the same person who selected the provider and controls its budget. No entry records subcontractors, the countries where replicas are stored, or what happens to 40 TB of freight-customer data on exit. The board approved the register in a 12-minute session and minuted that cloud risk is transferred to the provider. A new EU customer contract requires notification before any change of subcontractor.
1. Identify the most consequential errors in how likelihood and impact were assessed for the IaaS tenancy, and state what the reassessment must actually produce.
Read the worked answer
Errors in the assessment
- Likelihood was inferred from attestations rather than from control effectiveness. A provider's ISO/IEC 27001 certificate and SOC 2 report describe the provider's side of the shared-responsibility split. They say nothing about the tenancy's identity configuration, key custody, network exposure, or whether logging is switched on. Treating them as evidence of low likelihood hides the customer's own failure modes.
- 'Cloud' as one asset collapses 61 workloads of different classification and criticality into a single rating. A public marketing site and the freight-customer data store cannot share a likelihood.
- Impact was scoped to application availability, ignoring contractual exposure under the new EU clause, notification costs, and the exit/portability problem for 40 TB.
What the reassessment must produce
- Risk entries per workload group by data class, each naming the provider controls credited and the customer controls that must actually be operating.
- A subcontractor and data-residency map, including the country of replicas and any support access.
- A SOC 2 credit decision that records which criteria were in scope, the report period, and any carve-outs.
- An exit-risk line covering data format, transfer time, deletion evidence and parallel-run cost.
- A corrected board minute. Risk in cloud is allocated and shared, not transferred; leaving the minute as written means the board believes it carries no residual risk.
2. Who should own and accept the residual risk for the tenancy, and what conditions must the acceptance record contain?
Read the worked answer
Ownership. The risk owner should be the accountable business owner of the freight service whose data and revenue are exposed, not the IT infrastructure manager. The infrastructure manager is a control owner and a legitimate source of assessment input, but the same person selected the provider, holds its budget and would be judging their own decision. Segregating assessor, control owner and acceptor is the substance of the requirement, not paperwork.
Conditions for a defensible acceptance record
- The residual level stated against the organisation's defined risk criteria, not 'low' standing alone.
- The treatment actions already completed and those still open with dates, so the acceptance covers an identified gap rather than an unknown.
- A time limit and a review trigger set: subcontractor change, a new replica region, a failed control test, or the 18-month data-centre closure.
- Explicit escalation: high residual risk and any acceptance above the business owner's delegated authority goes to the board or risk committee, with the minute recording what was accepted and why.
- The exit plan referenced as a mitigating control, with an owner and a tested restore.
In practice the infrastructure manager may sign as control owner and the business owner as risk owner; both signatures on one record make the split visible at audit.
3. The EU customer requires notification before any change of subcontractor, but the provider's contract permits new subprocessors on 30 days' notice published on a web page. What must Northwind do?
Read the worked answer
Recognise the gap. A published web page is not notification to Northwind, and Northwind cannot pass on a notification it never receives. Read the clause precisely: who is notified, by what channel, how far in advance, and whether there is an objection right. If notice is passive publication, the customer obligation cannot be met through the provider and must be met by Northwind's own monitoring - which is a control, not a contractual nicety.
Actions
- Subscribe to and monitor the subprocessor feed, assign an owner, and record each review in the supplier file, cross-checking the new entity against the risk register and the data-residency map.
- Establish an internal path from subprocessor change to customer notification, with a decision log showing either 'no material change' or an objection raised inside the notice window.
- Attempt a contract amendment: named-channel notice, a minimum notice period, and an objection right with termination for convenience if the objection is refused. If the provider will not move, record that as a residual risk with the customer-notification exposure spelled out.
- Feed the change into the risk assessment - a new subprocessor with console access changes the threat landscape and may change likelihood.
The test of this control is a drill: take a real subprocessor announcement and prove it reached the customer inside the contractual window.