A residual risk register should show more than a rating. It should explain the disruption being assessed, which controls are operating, what evidence supports those controls, what exposure remains, and what the organization decided to do about it.
The five hypothetical residual risk register examples below show how those elements can fit into one maintainable record. They are designed for business continuity teams that need to explain decisions clearly without reconstructing the reasoning from scattered plans, test results, emails, and spreadsheets.
A complete residual risk record connects:
ISO 31073 defines residual risk as the risk remaining after treatment. NIST uses similar language in an information-security context, describing it as the portion remaining after controls or other risk responses have been applied.
Each organization still needs to define its own scoring method, evidence requirements, tolerance levels, and decision authority.
The examples use a simple illustrative model:
Risk score = likelihood from 1 to 5 × impact from 1 to 5
These numbers demonstrate record structure. They are not recommended thresholds or industry benchmarks. A score of 8 is not automatically moderate or acceptable. That depends on the organization’s approved rating bands and tolerance criteria.
The inherent and residual ratings must also describe the same scenario. If one rating concerns a complete outage and the other concerns delayed recovery, the comparison does not clearly show how controls affected the original exposure.
A recovery control may reduce the likelihood of a prolonged interruption without reducing the likelihood of the initiating event. The residual statement should make that distinction clear.
For a deeper explanation of scoring methods, read What Is Residual Risk and How Do You Calculate It?
The decisions below are hypothetical. Where an example refers to acceptance, assume the organization has determined that the exposure falls within its documented tolerance and that someone with the required authority has approved the decision. An actual record should state those conditions explicitly.
| Scenario | Controls and evidence | Inherent and residual exposure | Decision, ownership, and review |
|---|---|---|---|
| Financial services: payment-platform outage during the daily settlement cutoff | Secondary processing path, recovery runbook, and completed failover test. The test did not include one external settlement dependency. | Inherent: 5 × 5 = 25. Payment processing stops during a time-sensitive window. Residual: 2 × 5 = 10. Controls reduce the likelihood of a prolonged interruption, but missing the cutoff would still have severe consequences. |
Treat further. Technology services owns adding the external dependency to the next failover test. Reassess after that test or after a material platform change. |
| Healthcare: electronic health-record outage affecting clinical workflows | Documented downtime procedures and completed drills for emergency and inpatient care. Outpatient departments have not validated their procedures. | Inherent: 4 × 5 = 20. Loss of system access could affect patient-care workflows. Residual: 3 × 4 = 12. Manual procedures provide some continuity, but coverage remains incomplete. |
Temporary acceptance with further treatment. An authorized clinical leader approves the interim exposure. Clinical operations owns the remaining departmental drills. Review when validation is complete or after a failed exercise. |
| Manufacturing: interruption at a single-source supplier | Safety stock, supplier monitoring, and a qualified alternate supplier. Full production volume has not been tested with the alternate. | Inherent: 4 × 4 = 16. Production could stop after available inventory is consumed. Residual: 2 × 4 = 8. Controls provide more time to respond, but a long disruption could still stop production. |
Accept only if within approved tolerance. Procurement owns alternate-capacity validation. Review annually and after changes to the supplier, inventory level, or production demand. |
| SaaS provider: cloud-region outage | Multi-region backups, recovery runbook, and completed recovery test. The latest test identified a data-reconciliation gap. | Inherent: 3 × 5 = 15. Customers could lose access to the service. Residual: 2 × 4 = 8. Recovery controls reduce expected outage duration, but the reconciliation issue may delay complete restoration. |
Treat further. The platform owner manages remediation. Reassess after the fix is tested and after material architecture changes. |
| Corporate services: payroll-processing outage | Vendor escalation process, emergency-pay procedure, and completed walkthrough. The procedure depends on a current employee-data file. | Inherent: 3 × 4 = 12. Payroll could miss a scheduled payment date. Residual: 2 × 3 = 6. Most employees could receive emergency payments, but delays and corrections may remain. |
Accept with documented approval. Payroll owns the record. Review annually and after vendor, employee-file, or payment-calendar changes. |
These examples intentionally reach different decisions. A residual risk record should not force every exposure into the same treatment path.
A practical residual risk record should make the reasoning understandable without requiring a separate explanation from the person who created it.
The rating and decision should remain separate. Residual risk describes what remains. Risk acceptance is the deliberate decision to retain that exposure under the organization’s approved rules.
For the governance considerations behind that decision, read Risk Acceptance vs. Residual Risk.
A well-written record can still become unreliable when its evidence, controls, or operating assumptions change.
Do not rely only on an annual review date. Reassess the record when:
The review should update the evidence and residual assessment, not simply extend the next review date.
For more detail on evidence, owners, approvals, and review cadence, read Residual Risk Documentation for Audit.
A spreadsheet can hold a residual risk rating. The harder part is keeping the assessment, supporting documents, open actions, and reporting history connected as conditions change.
BCMMetrics Compliance Confidence supports standards-based assessments, supporting documents, assigned actions, assessment history, and reporting. It does not make the risk decision for the team or replace a dedicated enterprise risk register. It gives practitioners a more consistent way to maintain the information behind the decision.
If you want to examine how clearly your current evidence supports your compliance position, evaluate your compliance readiness.
To see how Compliance Confidence handles assessments, actions, and reporting, take our virtual tour.
A residual risk register is a structured record of exposures that remain after current controls or treatments are considered. It typically documents the scenario, controls, evidence, residual rating, decision, owner, approver, and review requirements.
A manufacturer may maintain safety stock and qualify an alternate supplier. Those controls provide more time and another sourcing option, but an extended interruption could still stop production. That remaining exposure is residual risk.
Assess the same scenario before and after current controls using the organization’s approved method. Likelihood multiplied by impact is one common approach, but the scale definitions, rating bands, evidence rules, and treatment thresholds must be defined by the organization.
No. Residual risk is the exposure that remains after controls or treatment. Risk acceptance is an authorized decision to retain some or all of that exposure.
Evidence may include recovery-test results, exercise records, current procedures, training records, supplier confirmations, assessment findings, remediation status, and approval records. The evidence should demonstrate that the credited controls operate as described.