Interim Controls and Residual Risk on CloudLedger's Export API
CloudLedger runs a multi-tenant accounting platform for 900 small-business customers. A penetration test found an insecure direct object reference in the data-export API: by changing a tenant identifier, an authenticated user can download another tenant's ledger data. There is no evidence of exploitation. The register rates the scenario 'external attacker / IDOR export' at likelihood 4 and impact 4 on a 5×5 scale; the acceptance threshold is 9. Engineering can ship a code fix in six weeks; a managed WAF rule can be live in two days; the CTO also holds a cyber insurance policy with a €250,000 deductible. After the WAF rule, the engineering lead re-rates likelihood as 2, giving a residual risk of 8, and asks the CTO to sign acceptance. Meanwhile sales has promised a prospective enterprise customer a contract clause requiring 99.99% availability and an annual penetration test, to be signed in four weeks. Customer data processing agreements require notification of a personal data breach within 72 hours.
1. Is the residual rating of 8 defensible? What would you require before the CTO signs acceptance?
Read the worked answer
The 4 → 2 downgrade is a guess presented as analysis, and a residual of 8 should not be signed on the current evidence.
Likelihood 2 assumes the WAF reliably stops authorisation-bypass attacks. That assumption is weak here. IDOR is an application-logic flaw: exploitation uses a legitimate authenticated session and a modified identifier, which looks like ordinary API traffic. A managed WAF rule typically matches known patterns and may not inspect JSON bodies or object-level authorisation. Two further factors work against the downgrade: 900 tenants means 900 potential authenticated attackers, and the vulnerable code stays deployed for six weeks even if the rule holds. ISO/IEC 27005 requires control effectiveness to be assessed together with its uncertainty, not assumed at face value.
Before acceptance, require: (a) the rule tested against the realistic bypass techniques - encoding, alternate headers, batch endpoints, HTTP/2 - with evidence attached; (b) monitoring and alerting on anomalous cross-tenant export volume, with a named owner; (c) likelihood expressed as a range with a confidence level, for example 2–4, giving a residual of 8–16; (d) assessment of secondary risk - false positives blocking legitimate exports for 900 customers; (e) a time-bound acceptance expiring at the code-fix milestone.
Only then can the CTO, as risk owner, decide. If the honest residual range straddles 9, the decision must escalate to whoever the acceptance criteria designate for that band, and the record must state justification, compensating controls and expiry. Acceptance here is a temporary, conditional decision within a treatment programme, not a substitute for the fix.
2. Set out the treatment plan, what must be recorded, who may accept the residual risk, and whether the new contract clause triggers re-assessment.
Read the worked answer
The treatment plan needs three parallel lines, and the insurance line must be described honestly.
- Reduce now (2 days): WAF rule with tested coverage, plus per-tenant export-volume monitoring and an alert threshold.
- Eliminate the root cause (6 weeks): replace client-supplied object references with server-side authorisation checks, with a regression test in the pipeline. Consider temporarily restricting cross-tenant export to manual approval until the fix ships - avoidance is a legitimate option if the business can tolerate it.
- Share: cyber insurance transfers some financial consequence, not likelihood. Regulatory fines, contractual liability to 900 customers and reputational damage are not fully insurable, and the €250,000 deductible leaves the first layer with CloudLedger. Record it as partial risk sharing, never as a reduction of the assessed risk.
Record in the risk treatment plan: risk ID, option chosen, controls and owners, deadlines, expected residual range, the acceptance decision and reviewer, and the monitoring method. The Statement of Applicability should show A.8.8 (management of technical vulnerabilities) and A.8.28 (secure coding) included with this risk as justification, and A.8.26 for the security requirements the API failed.
The contract clause does trigger re-assessment, but of the affected context rather than the whole register. A 99.99% availability commitment creates a new scenario - failure to meet service levels - and increases the impact of existing availability risks through penalties; the annual penetration test becomes an evidence obligation and a required control. Update context and criteria first, since the contract changes impact scoring and may change the thresholds, then re-run only the related scenarios and record the trigger and date. Monitoring and review exist to feed exactly this kind of change back into the process.