Risk Register — Confluence Page Structure
How to design the 05 · Risk Register page so that a single document simultaneously satisfies ISO 27001 clause 6.1.2, NIST SP 800-171 3.11.1, and DEFSTAN 05-138 Profile 1 §Risk and Profile 2 §Governance requirements.
What each framework actually needs from a risk register
Before designing the page, it is worth being precise about what each framework requires — because the differences are subtle but matter when an assessor is reviewing the document.
ISO 27001 clause 6.1.2 requires documented evidence of a repeatable risk assessment process. The clause lists eight specific things the process must do: define risk acceptance criteria; ensure assessments produce consistent, valid, and comparable results; identify risks associated with loss of confidentiality, integrity, and availability of information; assess likelihood and consequences; determine risk levels; compare risk levels against the acceptance criteria; and prioritise risks for treatment. Clause 6.1.3 then requires a treatment plan and a Statement of Applicability. The register is how you evidence that the 6.1.2 process was applied — an assessor who cannot trace a risk from initial identification through to a documented treatment decision and a residual risk rating will record a nonconformity.
NIST SP 800-171 control 3.11.1 states: "periodically assess the risk to organisational operations (including mission, functions, image, or reputation), organisational assets, and individuals, resulting from the operation of organisational systems and the associated processing, storage, or transmission of CUI." The NIST 800-171A assessment method uses all three approaches: Examine (the risk assessment results and the risk register), Interview (the person who conducted the assessment — can they describe the methodology?), and Test (verify that identified risks are reflected in the control environment). NIST does not prescribe the methodology in detail, but it requires the output to be documented and the documentation to be current.
DEFSTAN 05-138 Profile 1 §Risk requires that the organisation maintains a documented risk assessment for systems handling OFFICIAL information and that a named individual is accountable for managing the risk. Profile 2 §Governance extends this to require a formal risk acceptance process with documented evidence that senior management has reviewed and accepted residual risks. DEFSTAN assessors — typically from the contracting authority or a delegated assurance body — may request to review the risk register as part of a site assessment. They are looking for evidence that the organisation genuinely understands its risk posture, not just that it has a risk register template that was filled in once.
The common thread: all three frameworks want to see a risk that was identified, assessed using a documented and repeatable methodology, treated through a specific decision, and is being actively managed over time. The page structure below builds around that common thread.
Confluence page architecture
The Risk Register is a live operational page, not an archived evidence record. It sits at the top level of the ISMS space rather than in the EV-C evidence filing area, because it needs to be updated continuously and accessed regularly by the CISO, risk owners, and management. The EV-C area holds point-in-time evidence (the annual risk assessment report); the Risk Register page is the ongoing management view.
ISMS Confluence Space
│
├── 05 · Risk Register ← This page
│ ├── Risk Register — Active Risks ← Live table (current open risks)
│ ├── Risk Register — Closed Risks ← Archive table (closed/resolved)
│ └── Risk Methodology ← Supporting reference (linked from header)
│
└── EV-C · Risk Management (evidence filing)
├── Risk Assessments → [YYYY]
│ ├── Initiation Record (EV-C01)
│ ├── Risk Assessment Report (EV-C02)
│ └── Risk Identification Worksheets
└── Risk Treatment Actions → RT-[YYYY]-[NNN]
SCM access restrictions:
- isms-management: read access (risk owners need to view and update their risks)
- isms-security: read and edit access (CISO maintains the register)
- isms-all-staff: no access (the risk register contains threat intelligence detail)
- isms-it-staff: read access (IT Manager and engineers may need context for treatment actions)
Section 1 — Page header block
Place immediately below the page title. This metadata block establishes the framework compliance context for any assessor who opens the page.
Page title: 05 · Risk Register
Parent: ISMS Home
SCM: isms-management (read) · isms-security (edit)
Page owner: CISO
Last reviewed: [DATE]
Next review: [DATE + 12 months or next major event]
Section 2 — Framework compliance header
This section proves to an assessor that the register was designed to satisfy specific requirements — not built generically and then claimed to satisfy them.
FRAMEWORK COMPLIANCE CONTEXT
This register satisfies the following documented information requirements:
ISO 27001:2022
Clause 6.1.2(e): retain documented information about the risk assessment process
Clause 6.1.2(f): produce comparable and reproducible risk assessment results
Clause 6.1.3(c): produce a risk treatment plan
Clause 6.1.3(d): retain documented information about the risk treatment process
Clause 8.2: perform information security risk assessments at planned intervals
Clause 8.3: implement the information security risk treatment plan
NIST SP 800-171 Rev 2
Control 3.11.1: periodically assess the risk to organisational operations
resulting from the operation of organisational systems and the associated
processing, storage, or transmission of CUI
DEFSTAN 05-138
Profile 1 §Risk: documented risk assessment for OFFICIAL-scope systems
with named risk owner accountability
Profile 2 §Governance: formal risk acceptance with senior management review
Methodology reference: Risk Assessment Methodology — [link to methodology document]
Annual risk assessment report: EV-C → Risk Management → Risk Assessments → [YYYY]
Risk treatment actions: EV-C → Risk Management → Risk Treatment Actions
Section 3 — Risk scoring methodology reference
This is a brief reference section, not the full methodology document. The full methodology lives at the linked page. This section gives an assessor enough to understand the scoring without leaving the register.
Why this section is essential: ISO 27001 clause 6.1.2(b) requires that risk assessment criteria are defined before assessments are conducted. NIST 3.11.1 requires that assessments "produce consistent, valid, and comparable results" — which means the methodology must be documented and applied consistently. An assessor who asks "what does a likelihood score of 3 mean?" must be able to find the answer on or from this page.
SCORING REFERENCE
Likelihood × Impact = Inherent Risk Rating
Residual Likelihood × Residual Impact = Residual Risk Rating
LIKELIHOOD SCALE
1 — Very Unlikely: less than once in 10 years; theoretical possibility only
2 — Unlikely: once every 5–10 years; would require multiple failures
3 — Possible: once every 2–5 years; plausible given the threat landscape
4 — Likely: once per year; consistent with sector threat intelligence
5 — Almost Certain: multiple times per year; observed or actively targeted
IMPACT SCALE
1 — Negligible: minimal disruption; no CUI exposure; internal only; <4h recovery
2 — Minor: limited CUI exposure; contained to one system; regulatory reporting unlikely
3 — Moderate: significant CUI exposure; multiple systems affected; regulatory
notification possible; reputational impact to the organisation
4 — Significant: substantial CUI breach; DFARS reportable; DEFSTAN notification required;
contract impact; material financial or reputational consequence
5 — Severe: large-scale CUI breach; extended service disruption; contract loss;
regulatory action; potential criminal liability
RISK RATING MATRIX
Score 1–4: Low Accept with monitoring
Score 5–9: Moderate Treat or accept with documented risk owner sign-off
Score 10–19: High Must treat; CISO sign-off required for any acceptance
Score 20–25: Very High Must treat immediately; senior management sign-off required
for any acceptance; no open-ended timelines
RISK APPETITE (CISO-confirmed annually)
CUI confidentiality risks: Maximum accepted residual: Moderate (score ≤9)
CUI integrity risks: Maximum accepted residual: Moderate (score ≤9)
CUI availability risks: Maximum accepted residual: Moderate (score ≤9)
Compliance risks: Maximum accepted residual: Low (score ≤4)
Any Very High risk: Must be treated — acceptance prohibited without
board/senior management explicit written approval
Treatment options:
Mitigate — implement or enhance controls to reduce likelihood or impact
Accept — tolerate the residual risk within appetite; named risk owner required
Transfer — shift the risk to a third party (insurance, contractual obligation)
Avoid — cease the activity that creates the risk
Section 4 — Risk categories
Categories provide the filter that lets assessors quickly understand your threat model and lets management review risks by domain. ISO 27001 requires risks to be associated with specific assets and their CIA characteristics — categories make this navigable.
RISK CATEGORIES
The following categories structure the register. Each risk is assigned
one primary category. Multi-category risks use the dominant category.
Technical Risks arising from technical vulnerabilities, misconfigurations,
or technology failures affecting CUI systems
Operational Risks from process failures, human error, or resource constraints
Personnel Risks arising from insider threat, social engineering targeting
staff, or skills/dependency gaps
Supply Chain Risks from suppliers, cloud services, or third parties with access
to CUI or OFFICIAL information
Compliance Risks of failing to meet regulatory, contractual, or certification
obligations (DFARS, DEFSTAN, ISO 27001, CE)
Physical Risks from physical security failures, environmental events,
or equipment loss affecting CUI-scope systems
Strategic Risks to the ISMS programme itself — budget, skills, leadership
Section 5 — Active risk register table
This is the operational heart of the page. Every field below satisfies at least one framework requirement. The column sequence is deliberate — it tells the risk story from left to right: what is the risk, how bad, what are we doing, how bad after treatment.
Page design note: In Confluence, this works best as a Table macro with filters enabled, or as a linked Jira/issue tracker if the organisation uses structured risk management tooling. For a pure Confluence implementation, the table below with sorting on the Risk Rating column is the most assessor-friendly format.
ACTIVE RISK REGISTER — last updated [DATE] by [CISO name]
Filter views (use Confluence table filters):
By category, by risk level, by risk owner, by status
Click column headers to sort — recommended sort for management review:
Primary: Inherent Risk Rating (descending) — highest risks at top
Secondary: Status (open before in-treatment)
| Field | Description for the register builder |
|---|---|
| Risk ID | Format: RISK-YYYY-NNN (e.g. RISK-2024-001). Sequential within year. Do not reuse IDs — closed risks retain their ID permanently |
| Risk Title | Brief, searchable label — 5–10 words. Must be meaningful without reading the description |
| Risk Description | Full structured statement: "[Threat source] exploiting [vulnerability] causes [impact] to [asset]." This structure satisfies ISO 27001 clause 6.1.2(c) (identify risks associated with assets) and NIST 3.11.1 (operations, assets, individuals). Generic descriptions like "malware risk" fail this requirement |
| Category | One of the seven categories above |
| Threat Source | External attacker / Nation state / Insider (malicious) / Insider (accidental) / Supplier / Environmental / Regulatory |
| Affected Assets | Named systems or information types from EV-D22 (asset register). Link to asset register entry where possible |
| CIA Impact | C (Confidentiality) / I (Integrity) / A (Availability) / multiple. ISO 27001 clause 6.1.2(c) explicitly requires risks to be identified in relation to CIA loss |
| CUI Exposure | Yes / No / Potential — whether the risk, if realised, would result in CUI exposure or compromise |
| OFFICIAL Exposure | Yes / No / Potential — DEFSTAN-specific field: whether realisation would affect OFFICIAL-classified information |
| Inherent Likelihood | 1–5 (see scale above) — the likelihood before any controls are considered |
| Inherent Impact | 1–5 (see scale above) — the impact before any controls are considered |
| Inherent Risk Rating | Likelihood × Impact. Colour-coded: 1–4 green / 5–9 amber / 10–19 red / 20–25 dark red |
| Existing Controls | Controls currently in place that reduce this risk. Reference the specific AT-[family] page or FC-0X control page where the control is documented. Do not list controls that are aspirational — only implemented controls |
| Treatment Option | Mitigate / Accept / Transfer / Avoid |
| Treatment Actions | For Mitigate: link to RT-YYYY-NNN treatment action entries in EV-C. For Accept: reference the risk acceptance record |
| Residual Likelihood | 1–5 — likelihood after all treatment actions are implemented |
| Residual Impact | 1–5 — impact after all treatment actions are implemented |
| Residual Risk Rating | Residual Likelihood × Residual Impact. Same colour coding |
| Within Risk Appetite | Yes / No. Derived from the appetite table above. Any "No" requires escalation |
| Risk Owner | Named individual (role + name). Not a team — a person. ISO 27001 clause 6.1.2(d)(2) requires risk owners to be identified |
| Date Identified | When this risk was first added to the register |
| Date Last Reviewed | When the risk was last assessed for continued accuracy. Must be within 12 months |
| Status | Open / In Treatment / Treatment Complete / Accepted / Closed |
| POA&M Reference | If treatment actions are in the POA&M (for CMMC/NIST purposes), reference the PM-YYYY-NNN entry |
| Notes | Any additional context, monitoring indicators, or linkage to incidents or findings |
Section 6 — Example risk entries
Three worked examples showing how the description structure and field population look in practice. Use these as templates when populating new risks.
Example risk 1 — Technical / High
Risk ID: RISK-2024-001
Risk Title: Unpatched CUI-scope server exploited via known CVE
Risk Description: An external attacker exploits a publicly known, unpatched
vulnerability (CVSS ≥ 7.0) in a CUI-scope Windows Server
to gain unauthorised access, resulting in confidentiality
loss of stored CUI and potential lateral movement to
adjacent CUI systems.
Category: Technical
Threat Source: External attacker
Affected Assets: SRV-CUIFILE-01, SRV-DB-01 (EV-D22 references)
CIA Impact: C, I (confidentiality and integrity of CUI)
CUI Exposure: Yes
OFFICIAL Exposure: Yes (SRV-CUIFILE-01 processes OFFICIAL contract data)
Inherent Likelihood: 4 — Likely (unpatched high-severity CVEs are actively
exploited within days of publication; CISA KEV confirms
this class of vulnerability is in active use)
Inherent Impact: 4 — Significant (CUI breach; DFARS 72h report required;
DEFSTAN 24h notification required; contract impact likely)
Inherent Risk Rating: 16 — HIGH
Existing Controls: AT-SI (patch management programme — EV-D07/D08);
FC-05 (7-day Critical patch SLA); FC-01 (network
segmentation — external access requires firewall transit)
Treatment Option: Mitigate
Treatment Actions: RT-2024-001: Reduce Critical patch SLA from 7 to 5 days
RT-2024-002: Implement weekly authenticated scan of
internet-facing systems (currently monthly)
Residual Likelihood: 2 — Unlikely (5-day SLA with weekly verification
substantially narrows the exploitation window)
Residual Impact: 4 — Significant (unchanged — if exploitation occurs
the CUI impact does not change; only likelihood reduces)
Residual Risk Rating: 8 — MODERATE
Within Risk Appetite: Yes (≤9 for CUI confidentiality risks)
Risk Owner: IT Manager — [Name]
Date Identified: 2024-03-15
Date Last Reviewed: 2024-09-01
Status: In Treatment (RT-2024-002 complete; RT-2024-001 in progress)
POA&M Reference: PM-2024-007
Notes: Treatment actions linked to EV-C → Risk Treatment Actions.
Weekly scan confirmed active per EV-D06 supplementary.
5-day SLA implementation: target Q4 2024.
Example risk 2 — Personnel / Moderate
Risk ID: RISK-2024-002
Risk Title: Phishing attack leads to credential compromise and CUI access
Risk Description: A staff member with CUI access is deceived by a targeted
phishing email into disclosing their credentials or
executing malicious content, enabling an attacker to
authenticate as the user and access CUI-scope systems
and data.
Category: Personnel
Threat Source: External attacker using social engineering
Affected Assets: All CUI-scope systems accessible by the compromised account
CIA Impact: C, I (CUI access via compromised legitimate account)
CUI Exposure: Yes
OFFICIAL Exposure: Yes
Inherent Likelihood: 4 — Likely (sector-specific spear-phishing is consistently
observed; EV-B07 phishing simulation baseline click rate: 18%)
Inherent Impact: 4 — Significant (legitimate account bypass of network controls;
CUI access possible; DFARS and DEFSTAN reporting likely)
Inherent Risk Rating: 16 — HIGH
Existing Controls: FC-03 (MFA enforced — credential alone insufficient to
authenticate — EV-D05); FC-04 (email gateway with sandbox
detonation and link rewriting); AT-AT (annual phishing
awareness training and quarterly simulation — EV-B05, EV-B07)
Treatment Option: Mitigate
Treatment Actions: RT-2024-003: Move all adm- accounts to FIDO2 hardware
tokens (complete — EV-D05 confirms)
RT-2024-004: Reduce phishing simulation click rate to
<5% through targeted post-click training (in progress)
Residual Likelihood: 2 — Unlikely (MFA blocks credential-only use;
FIDO2 is phishing-resistant; simulation programme
measurably improving user behaviour)
Residual Impact: 3 — Moderate (if authentication is compromised despite
MFA, Conditional Access device compliance still applies;
blast radius is limited to that user's access rights)
Residual Risk Rating: 6 — MODERATE
Within Risk Appetite: Yes (≤9)
Risk Owner: CISO — [Name]
Date Identified: 2024-03-15
Date Last Reviewed: 2024-09-01
Status: In Treatment
POA&M Reference: PM-2024-003
Notes: Phishing simulation click rate trend: Q1 18% → Q2 12% →
Q3 9%. Target: <5% by Q1 2025.
KRI flagged in EV-F02 monthly metrics.
Example risk 3 — Compliance / Accepted
Risk ID: RISK-2024-008
Risk Title: CMMC Level 2 certification gap — two controls partially implemented
Risk Description: Two NIST SP 800-171 controls (3.13.3 and 3.13.14) are partially
implemented — the management VLAN is documented in the SSP but
VoIP system integration is not yet complete. The current state
results in a non-zero POA&M at the C3PAO assessment scheduled
for Q2 2025, creating a risk that conditional certification or
score reduction occurs.
Category: Compliance
Threat Source: Regulatory / Contractual (CMMC programme)
Affected Assets: ISMS programme; existing and future DoD contracts
CIA Impact: N/A (compliance risk, not direct CIA risk)
CUI Exposure: No
OFFICIAL Exposure: No
Inherent Likelihood: 3 — Possible (C3PAO will identify the gap; question is
whether conditional certification or score reduction results)
Inherent Impact: 3 — Moderate (conditional certification delays contract;
score below 110 in SPRS reduces competitive position)
Inherent Risk Rating: 9 — MODERATE
Existing Controls: AT-SC-ARC documents the partially implemented state;
POA&M entry PM-2024-011 tracks remediation
Treatment Option: Mitigate
Treatment Actions: RT-2024-009: Complete VoIP VLAN documentation and
integration with SIEM (target: Q1 2025, before C3PAO)
Residual Likelihood: 1 — Very Unlikely (if RT-2024-009 complete before C3PAO,
the gap will be closed)
Residual Impact: 2 — Minor (minor score variation from 110 is manageable)
Residual Risk Rating: 2 — LOW
Within Risk Appetite: Yes (≤4 for compliance risks)
Risk Owner: CISO — [Name]
Date Identified: 2024-06-20
Date Last Reviewed: 2024-09-01
Status: In Treatment
POA&M Reference: PM-2024-011
Notes: C3PAO assessment scheduled: [Q2 2025].
RT-2024-009 completion must precede C3PAO booking.
CISO to confirm completion and close this risk
on C3PAO assessment confirmation.
Section 7 — Risk acceptance records
Accepted risks require explicit documentation separate from the register row. This section links to those records.
RISK ACCEPTANCE RECORDS
Any risk where Treatment Option = Accept requires a formal risk acceptance
record signed by the appropriate authority:
Residual risk Low (≤4): IT Manager acceptance sufficient
Residual risk Moderate (≤9): CISO acceptance required
Residual risk High (≤19): Senior management acceptance required
(Director or equivalent; not CISO alone)
Residual risk Very High: Board / governing body acceptance required;
Prohibited for CUI/OFFICIAL confidentiality risks
Format for acceptance records:
Stored as child pages of this register OR in EV-C → Risk Management → Risk Acceptance
Each record: risk ID, residual rating, acceptance rationale, compensating
controls in place, review date, named acceptor signature
Current accepted risks:
[Link to acceptance record for each risk where status = Accepted]
[Or: "No risks currently in Accepted status"]
Section 8 — DEFSTAN-specific section
This section exists because DEFSTAN assessors often want to see a dedicated view of risks affecting OFFICIAL information. Having it pre-built avoids creating it under assessment pressure.
DEFSTAN 05-138 — RISKS AFFECTING OFFICIAL-SCOPE SYSTEMS
The following risks in the register have "OFFICIAL Exposure: Yes" and are
specifically relevant to DEFSTAN compliance. This view is maintained for
contracting authority review.
For each: Risk ID | Risk Title | Current Residual Rating | Risk Owner | Status
[Filter the master table by OFFICIAL Exposure = Yes and present here]
DEFSTAN risk acceptance obligations:
Profile 1 §Risk: any High or Very High residual risk affecting OFFICIAL systems
must be reviewed and formally accepted by the named CISO or equivalent
Profile 2 §Governance: senior management must review and accept residual risks
annually — evidenced by the management review minutes (EV-A01)
Contracting authority notification:
If a risk materialises (becomes an incident) affecting OFFICIAL information,
the 24-hour DEFSTAN notification obligation is triggered regardless of whether
the risk was documented here.
See: AT-IR → IRP Document → Reporting Obligations section
Section 9 — Register maintenance and review cadence
This section documents the governance of the register itself — proving to an ISO 27001 auditor that the register is maintained, not just created once.
MAINTENANCE OBLIGATIONS
Continuous updates (CISO or designated risk analyst):
- New risk identified: add to register within 5 business days
- Control implementation changes the residual rating: update within 30 days
- Incident occurs that validates a registered risk: add incident reference
and review whether treatment actions need acceleration
- Incident occurs that represents a risk not in the register: add new entry
Monthly review (CISO):
- Review all risks where status = In Treatment: is treatment progressing?
- Review all risks approaching their "Date Last Reviewed" + 12 months
- Update Key Risk Indicators in EV-F02 (monthly metrics) from this register
- Flag any risk that has exceeded its risk appetite to senior management
Annual review (CISO + risk owners + management):
- Full review of all open risks: are descriptions still accurate?
- Update inherent and residual ratings based on changes to the threat landscape
(reference: annual risk assessment report EV-C02)
- Review and confirm all risk owners are still in role
- Review risk appetite: is it still appropriate given contract scope?
- Present summary to management review (EV-A01 input)
- Archive closed risks to the Closed Risks child page
- Update: Date Last Reviewed for all entries
Trigger-based updates (any time):
- New DEFSTAN contract: add contract-specific OFFICIAL exposure risks
- New CUI system deployed: review Technical risk category for new entries
- Significant security incident: review all related risks
- Major external event (new threat intelligence, sector-wide attack):
review likelihood ratings for affected categories
- CISA KEV entry for technology in our environment: review Technical risks
CISO review sign-off (add after each monthly review):
[YYYY-MM]: Reviewed by [CISO name] — [N] risks active — [N] changes made — [summary]
Section 10 — Risk register metrics
A brief dashboard view at the top or bottom of the page that gives an immediate status overview — useful for management and for assessors who want a summary before reading the full table.
RISK REGISTER SUMMARY — updated [DATE]
Total active risks: [N]
Very High (20–25): [N] ← Must all be in treatment; any "accepted" = finding
High (10–19): [N]
Moderate (5–9): [N]
Low (1–4): [N]
By status:
Open (not yet treated): [N]
In Treatment: [N]
Accepted (within appetite): [N]
Closed this quarter: [N]
By category:
Technical: [N]
Operational: [N]
Personnel: [N]
Supply Chain: [N]
Compliance: [N]
Physical: [N]
Strategic: [N]
OFFICIAL-scope risks (DEFSTAN): [N]
CUI-scope risks (NIST/CMMC): [N]
Risks exceeding risk appetite: [N] ← Must be zero or have senior management acceptance
Risks not reviewed in 12m+: [N] ← Must be zero before any assessment
Closed risk register (child page)
The closed risk register is a separate child page of 05 · Risk Register. Risks are moved here when: - The risk is treated to the point where it no longer represents a meaningful residual risk - The risk is transferred to a third party and is no longer organisationally owned - The underlying threat or vulnerability no longer applies (e.g. a technology was decommissioned) - The affected system is removed from CUI scope
Crucially: risks are never deleted. ISO 27001 clause 7.5.3 requires documented information to be retained in a suitable format. A closed risk register provides the historical trail that shows the organisation's risk posture evolving over time — assessors at surveillance audits compare the current register against prior years.
The closed risk register retains all fields from the active register, plus: - Closure date - Closure reason (treated / transferred / no longer applicable) - CISO sign-off on closure - Final residual risk rating at time of closure
Retention: 3 years from closure date.
The five most common risk register failures at assessment
Descriptions are generic rather than structured. "Malware risk" is not a risk description — it is a risk category. The description must name a threat source, a vulnerability, and an asset, and must state the CIA characteristic affected. An assessor who cannot understand what specifically might happen, to what specifically, and what the consequence would be, cannot verify that the control environment addresses the described risk. Write every description as: "[threat source] exploits [specific vulnerability] in [specific asset] causing [specific impact]."
Residual ratings are identical to inherent ratings. If existing controls are listed but the residual risk rating is the same as the inherent rating, one of three things is true: the controls do not actually reduce the risk (which is possible and should be explained), the ratings were copied without thinking, or the register was created by one person and the treatment actions by another without reconciliation. An assessor who sees inherent 4×4=16 and residual 4×4=16 with MFA listed as a control will ask why MFA does not reduce the likelihood — and expect a substantive answer.
Risk owners are teams or roles rather than named individuals. "IT Department" or "the security team" is not a risk owner. ISO 27001 clause 6.1.2(d)(2) requires risk owners to be identified — meaning a named person who can be interviewed and who is accountable for the treatment actions. When that person changes role, the register is updated. Teams don't have accountability; people do.
The register has not been updated in more than twelve months. An ISO 27001 surveillance auditor will check the "Date Last Reviewed" column and will ask the CISO about any risk not reviewed in the past year. A register that was created during implementation and not touched since reads as a compliance artefact rather than an operational management tool. The monthly review cadence with CISO sign-off in Section 9 is what prevents this.
DEFSTAN risks are not distinguished from general organisational risks. A contracting authority assessor asked to review the risk register as part of a DEFSTAN site assessment wants to quickly identify which risks affect OFFICIAL information. If there is no OFFICIAL Exposure field and no DEFSTAN-specific view, the assessor has to read every entry to find the relevant risks. The DEFSTAN-specific section and the OFFICIAL Exposure field in the register resolve this — they take five minutes to implement and save significant time under assessment conditions.