skip to content

In an enterprise security risk register, what does each row record, and why are inherent and residual risk kept separately?

level: juniorimportance: must knowfreq 55%

answer

  1. one row per risk, not per finding
  2. a named owner with authority
  3. before versus after controls
  4. treatment decision and review date

basics

~20 s

Each row names one risk scenario, its accountable owner, the inherent rating, the controls relied on, the chosen treatment, the residual rating and a review date. Keeping inherent and residual apart shows how much the rating depends on controls working.

solid answer

~50 s

A risk register is the organization's living list of assessed risks, one row per **risk scenario** written as cause, event and consequence — not a copy of the scanner backlog. A usable row carries: the scenario and the business process or asset it hits; a **named owner** who has the authority and budget to decide on it; likelihood and impact giving an **inherent** rating; the existing and planned controls; the treatment decision (mitigate, transfer or share, avoid, accept); the **residual** rating after that treatment; status and a **review date**. Inherent and residual are kept separately because the gap between them is the value the controls deliver: a risk that is high inherent and low residual is only low while those controls keep working, so control failures and audit findings must be traced back to it. NIST CSF 2.0 names the risk register as one form of the action plan, and `ID.RA-05` uses inherent risk to prioritise responses.

go deeper

for a junior

Recall the fields of a row: statement, owner, inherent rating, controls, treatment, residual rating and review date. Be able to say what residual risk means in one sentence.

for a middle

Explain why inherent and residual are separate columns and how a failed control moves a risk. Show you can turn a scanner finding into a proper risk statement.

for a senior

Show how you keep a register alive: owners with real authority, review triggers beyond the calendar, and rows that deduplicate many findings into one scenario the business recognises.

for a principal

Discuss how the register feeds governance: how residual spread shows programme value, and how rows roll up into enterprise risk reporting without losing the owner's accountability.

## What a risk register is A **risk register** is the record an organization keeps of the risks it has identified, assessed and decided what to do about. It is the working output of an enterprise risk assessment such as one run under **NIST SP 800-30 Rev. 1** or **ISO/IEC 27005**, and it is where a governance body goes to see which risks exist, who owns them and what was decided. NIST CSF 2.0 names the risk register, alongside a risk detail report and a POA&M, as an example of the prioritized action plan that closes the gap between a Current and a Target Profile, and says progress is shared "through risk registers and progress reports". The unit of a register is a **risk scenario**, not a finding. "Unpatched host 10.1.4.7" is a finding; "ransomware encrypts the payments ledger and halts settlement for several days, causing regulatory reporting failures and customer losses" is a risk. Many findings can feed one risk, and one control can reduce many risks. ## Anatomy of a row | Field | What it holds | Why it matters | |---|---|---| | **Risk ID and statement** | Cause, event, consequence in one sentence | Makes the row assessable and deduplicable | | **Asset or process** | What is harmed: a service, a data set, a business function | Ties the risk to mission impact | | **Risk owner** | A named manager accountable for the outcome | Someone must be able to decide and fund | | **Inherent rating** | Likelihood and impact before the controls being evaluated | Shows raw exposure | | **Controls** | Existing controls relied on, and planned ones | Explains the gap to residual | | **Treatment** | Mitigate, transfer or share, avoid, or accept | The decision the row exists to record | | **Residual rating** | Likelihood and impact after treatment | What the organization is actually living with | | **Target and status** | Where the owner wants it and progress towards it | Tracks open work | | **Review date** | When the row is re-assessed | Keeps the register current | **Inherent** risk has no single agreed definition: some programmes mean "with no controls at all", others "ignoring the controls under evaluation". Either works if the methodology says which, and every assessor uses the same one. **Residual risk** is defined in the SP 800-30 glossary as the "portion of risk remaining after security measures have been applied". ## Why inherent and residual are kept apart - **Control dependence becomes visible.** A high-inherent, low-residual risk is low only while its controls work. When an audit sample fails or a control is switched off, the owner knows which risks just moved. - **Prioritisation.** CSF 2.0 `ID.RA-05` has threats, vulnerabilities, likelihoods and impacts "used to understand inherent risk and inform risk response prioritization". - **Honest acceptance.** An owner accepting a risk should see both what the organization faces and what remains; accepting only a residual figure hides how much trust is placed in controls. - **Value of the programme.** The spread between the two columns across the register is the clearest statement of what security spending bought. ## A worked row at a fintech 1. **Statement:** credential-stuffing against the customer login takes over accounts and drains balances through instant transfers. 2. **Owner:** the head of retail payments, not the security team. 3. **Inherent:** high likelihood, high impact. 4. **Controls:** rate limiting and breached-password screening in place; phishing-resistant MFA for transfers planned. 5. **Treatment:** mitigate; the MFA work tracked as open work with a date. 6. **Residual:** medium today, target low once MFA ships. 7. **Review:** quarterly, and on any significant change to login or transfer flows. ## How registers go wrong - Rows owned by "IT" or "Security", so nobody with budget ever decides. - One row per scanner finding, producing thousands of rows nobody reads. - Residual ratings copied from inherent because no one assessed the controls. - Review dates that pass silently; NIST SP 800-53 `RA-3` expects results to be reviewed at an organization-defined frequency and the assessment updated when significant changes occur. - Accepted risks with no rationale, making the acceptance impossible to revisit. A register is therefore a decision log as much as a list: each row says what the risk is, who decided, what they decided and when it will be looked at again.

  • Why should a register row name a business manager rather than the security team as owner?
    The owner decides whether to spend, change the process or accept what remains, so they need authority over the affected business activity and its budget. The security team usually operates controls and advises on ratings, but if it owns every row, acceptance decisions get made by people who cannot trade the risk off against the business benefit, and nobody with budget is accountable.
  • When should a register row be reviewed outside its scheduled date?
    Whenever something that drives its rating changes: a significant change to the system or process, a failed control test, a new threat pattern, an incident on that scenario, or a change in the organization's tolerance. NIST SP 800-53 `RA-3` asks for review at a defined frequency and an update when significant changes occur, so the schedule is a floor rather than the only trigger.

saying these in an interview costs you the question

  • The register is just the vulnerability scanner's output with owners added.
  • The security team should own every risk in the register.
  • Once a control is in place the residual risk is zero.
  • Inherent risk is pointless to record once controls exist.
  • A register is written for the audit and then filed until next year.