Risk Treatment and the Risk Register

Every risk that emerges from a risk assessment must receive one of four treatment decisions. Leaving a risk in the register with no decision is itself a failure of governance, and auditors treat undecided risks as evidence that the management system is not functioning.

Mitigation is the most common treatment, and it is where most of the practical work of information security sits. Mitigation controls can target likelihood (for example, multi-factor authentication reduces the probability that a stolen password enables account takeover) or impact (for example, offline backups do not prevent ransomware but limit the damage it causes). Many risks require multiple controls working together; the risk register should list each control separately so that their individual effectiveness can be tested.

A risk register is only as useful as the information it contains. A register with vague descriptions, no owners, and no review dates provides the appearance of risk management without the substance. Auditors conducting ISO/IEC 27001 certification audits, PCI-DSS qualified security assessor reviews, or SOC 2 examinations will examine the register for completeness, consistency, and evidence that it is actively maintained.

A well-constructed risk register entry contains at minimum: a unique risk identifier; a description of the risk stated as a cause leading to an event with a consequence (for example, "unpatched web application vulnerability exploited by external attacker leading to customer data exfiltration"); the asset or process at risk; the inherent likelihood and impact scores from the risk assessment, cross-referenced to the assessment methodology used; the treatment decision with the date it was taken and the name of the authorising manager; the specific controls selected, each with its own owner and implementation status; the residual likelihood and impact scores after controls; a residual risk rating; and the scheduled review date.

The register can be a spreadsheet, a dedicated GRC (governance, risk, and compliance) platform, or a module within a security management tool. Format matters less than discipline. Organisations that maintain the register in a spreadsheet with inconsistent naming, no version control, and no access log produce registers that cannot be relied on as evidence. Whichever format is chosen, the register must have a clear owner responsible for its accuracy and a defined change process so that every update is traceable.

Every risk in the register must have a named owner. Risk ownership is one of the most commonly mishandled elements of risk management. In organisations where the information security team writes the register, there is a tendency to assign all risks to the Chief Information Security Officer or the security team. This is operationally wrong: the security team does not control the payroll system, the customer relationship management database, or the physical access policy for branch offices. Risks associated with those assets belong to the people who run them.

A risk owner has three responsibilities: ensuring that the chosen treatment is implemented (which may involve funding controls, instructing teams, or changing processes); monitoring whether the treatment remains effective as the environment changes; and escalating if the risk score changes significantly or the treatment fails. Ownership must be accepted explicitly, not assigned without the owner's knowledge. An owner who does not know they own a risk cannot fulfil these responsibilities.

ISO/IEC 27001 Clause 6.1.2 requires that risk owners be identified and that they approve the residual risk before the organisation declares a treatment complete. This requirement creates a formal accountability trail: the register records who accepted what residual exposure and when. If the same risk later causes an incident, the record shows whether the decision was reasonable given what was known at the time.

Residual risk is what remains after controls are applied. It is calculated using the same likelihood and impact scales used in the original risk assessment, applied to the post-control scenario. If a risk is rated likelihood 4, impact 5, giving an inherent score of 20 on a 25-point scale, and the selected controls are expected to reduce likelihood to 2 and impact to 3, the residual score is 6. Whether 6 is acceptable depends on the organisation's risk appetite threshold.

Residual risk scores are estimates, not certainties. Controls may be less effective than designed, may not be implemented correctly, or may address one attack vector while leaving others open. For this reason, ISO/IEC 27001 requires formal management acceptance of residual risk, signed off by a person with authority to take that decision on the organisation's behalf. Formal acceptance does two things: it makes the business consequences explicit (if the residual risk materialises, the organisation knew and accepted it), and it creates a management commitment to fund and maintain the controls that reduce the risk to that level.

Residual risk that exceeds the risk appetite threshold after all practical controls have been applied presents a harder decision. The options are: accept despite exceeding appetite (which requires board-level sign-off and explicit documentation); escalate the control investment; transfer more of the financial exposure; or avoid the activity entirely. The risk register must show which path was chosen and why. Auditors examining a register that shows risks above appetite with no documented exception or escalation will treat this as a material finding.

Risk treatment decisions degrade over time. A control that was adequate last year may be ineffective this year because the threat has changed, the asset has changed, or the control has not been maintained. The risk review cycle is the mechanism that keeps the risk register current and ensures that treatments remain proportionate to the actual risk.

Most frameworks specify two review triggers. The first is a planned interval: ISO/IEC 27001 requires reviews at planned intervals; PCI-DSS Requirement 12.3.1 mandates annual targeted risk analyses for each requirement; NIST CSF and NIST SP 800-37 both require periodic reassessment. Annual reviews are the common baseline, but critical systems or high-rated risks typically need quarterly or six-monthly review cycles. The second trigger is a significant change: a new system, a major business process change, a security incident, a regulatory change, or a material shift in the threat environment. The Digital Personal Data Protection Act 2023 in India, GDPR Article 35, and HIPAA's Security Rule all require risk assessments (and therefore treatment reviews) when processing activities change significantly.

A review does not automatically mean a change in treatment. A review may confirm that the existing treatment is still adequate, update the risk score if the threat has changed, close a risk because the underlying asset or process no longer exists, or open a new risk that was not present at the previous review. Each of these outcomes should be recorded in the risk register with a date and the name of the reviewer, creating the evidence trail that compliance programmes require.

The risk register feeds compliance reporting through a chain: the register shows that risks have been identified, treated, and accepted; the Statement of Applicability (for ISO/IEC 27001) links treatment decisions to specific controls; control testing and audit logs confirm the controls are operating; and management review confirms that the overall system is working. Breaking any link in this chain produces a gap that certification auditors or regulatory inspectors will identify.

Different compliance regimes approach risk treatment with different levels of prescription. Understanding how each maps to the four treatment options avoids the mistake of treating compliance as a box-ticking exercise separate from genuine risk management.

ISO/IEC 27001 is the most structured: it requires a complete risk treatment plan, a Statement of Applicability, and management acceptance of residual risk. Controls are selected from Annex A (which aligns to ISO/IEC 27002) or from elsewhere if justified. The SoA must explain exclusions as well as inclusions. Certification auditors verify that the risk register, the SoA, and the controls in operation are consistent with each other. Learn more about the standard's structure in ISO 27001 Standard and Structure.

GDPR (and India's DPDP Act 2023, which follows a similar risk-based model) requires Data Protection Impact Assessments for high-risk processing activities, which are essentially structured risk assessments with treatment plans. The treatment options map directly: some processing may be stopped (avoid), technical and organisational measures are applied (mitigate), data protection agreements shift some liability to processors (partial transfer), and residual risks may be accepted by the Data Protection Officer and the controller's leadership. HIPAA's Security Rule requires covered entities to conduct a risk analysis and implement security measures sufficient to reduce risks to a reasonable and appropriate level, again mapping directly to the mitigate and accept options.

NIST CSF and CIS Controls provide control catalogues rather than prescriptive requirements, meaning organisations choose controls from the catalogue to address their specific risks. The risk register links each risk to the CIS Control or NIST CSF subcategory that addresses it, making the treatment traceable to an accepted framework. This approach works well for US federal and commercial contexts and is increasingly used internationally as a complement to ISO/IEC 27001. See Security Governance Frameworks Overview for a comparison.