Run the register against the live programme, not against a stale spreadsheet
SecPortal pairs every register entry to the persistent findings, scans, retests, and audit evidence that drive its residual position, so the leadership read and the audit read come from one record. Free plan available.
No credit card required. Free plan available forever.
Twelve sections that turn a spreadsheet into a defensible enterprise risk register
A cybersecurity risk register is the org-wide ledger of every identified information-security and technology risk the programme is tracking, with its inherent score, treatment, residual score, owner, review cadence, and current status. The twelve sections below cover the durable shape of the artefact across ISO/IEC 27001 Clause 6.1.2 and Clause 8.3, ISO 31000 Clause 6, NIST SP 800-30, NIST SP 800-39, NIST SP 800-37, NIST SP 800-53 PM-9 and RA-3, COSO ERM, SOC 2 Trust Services Criteria CC3.1 through CC3.4, and PCI DSS Requirement 12.3. Copy the section that fits your stage and paste the rest as you go.
Copy the full template (all twelve sections) as one block.
1. Register identification and scope
Capture the boundary of the register at the top so any reviewer reading any entry knows which estate, which programme, and which framework expectations the register operates under. ISO/IEC 27001 Clause 6.1.2 and Clause 8.3, ISO 31000 Clause 6, NIST SP 800-30 Section 2, NIST SP 800-39 Section 2, and PCI DSS Requirement 12.3 each expect the register to declare its scope so an entry that drifts outside scope is visible.
Register name: {{REGISTER_NAME}}
Owning function (Risk, Security, GRC, ERM): {{OWNING_FUNCTION}}
Register administrator (named individual): {{REGISTER_ADMINISTRATOR}}
Risk taxonomy version: {{TAXONOMY_VERSION}}
Scope (in-scope business units, geographies, products, asset classes): {{IN_SCOPE_DOMAINS}}
Frameworks the register supports (ISO 27001, ISO 31000, NIST SP 800-30/39/53, SOC 2, PCI DSS, DORA, NIS2, internal policy, other): {{FRAMEWORK_LIST}}
Risk appetite or tolerance reference (link to approved appetite statement): {{RISK_APPETITE_REFERENCE}}
Last register-wide review date: {{REGISTER_REVIEW_DATE}}
Next register-wide review date: {{NEXT_REGISTER_REVIEW_DATE}}
Register review cadence (quarterly default, annual minimum under ISO 27001 Clause 8.3 and PCI DSS 12.3): {{REGISTER_REVIEW_CADENCE}}
2. Risk identification and persistent reference
Every entry pairs to a persistent risk identifier rather than a report ID or a slide-deck number. Recording against a persistent reference lets the entry survive engagement boundaries, framework version changes, and reorganisations without the lineage breaking. A successor reviewer should be able to reconstruct an entry from the reference alone.
Risk identifier (persistent reference, format: RISK-YYYY-NNNN): {{RISK_REFERENCE}}
Short risk title (under twelve words, plain language): {{RISK_TITLE}}
Risk category (operational, technology, cyber, data privacy, third-party, regulatory, fraud, business continuity, people, vendor, supply chain, other): {{RISK_CATEGORY}}
Risk subcategory (e.g. external attack, insider misuse, software defect, vendor outage, control failure, change-management failure, regulatory change): {{RISK_SUBCATEGORY}}
Source (how the risk was identified):
[ ] Finding from internal or external assessment (linked finding identifiers in Section 11)
[ ] Control gap raised by audit, GRC, or self-assessment
[ ] Third-party or supply-chain assessment
[ ] Threat-intelligence input or industry advisory
[ ] Scenario analysis or tabletop exercise
[ ] Incident or near-miss post-event review
[ ] Regulatory change or new framework expectation
[ ] Other: {{OTHER_SOURCE}}
Date identified: {{DATE_IDENTIFIED}}
Identified by (named individual): {{IDENTIFIED_BY}}
3. Plain-language risk statement and consequence
A risk statement is a single sentence in business language that names the threat actor or event, the vulnerability or condition, and the consequence. The plain-language statement is what a non-technical reader uses to decide whether the residual position is acceptable. If the statement needs CVSS jargon to make sense, the entry has not been translated for leadership review and will be hard to defend at audit.
Risk statement (one sentence, format: "If [event/threat], then [consequence], because [vulnerability/condition]"):
{{RISK_STATEMENT}}
Affected assets and processes:
- Systems, applications, repositories, or vendors: {{AFFECTED_ASSETS}}
- Environments (production, staging, pre-production, development): {{ENVIRONMENTS}}
- Data classifications in scope (PII, PHI, payment card, intellectual property, source code, secrets, other): {{DATA_CLASSIFICATIONS}}
- Business processes affected: {{BUSINESS_PROCESSES}}
- Internet-facing exposure: Yes / No / Partial
- Customer or regulator visibility: {{EXTERNAL_VISIBILITY}}
Plain-language consequence if the risk materialises:
- Financial: {{FINANCIAL_CONSEQUENCE}}
- Operational: {{OPERATIONAL_CONSEQUENCE}}
- Regulatory or contractual: {{REGULATORY_CONSEQUENCE}}
- Reputational: {{REPUTATIONAL_CONSEQUENCE}}
- Safety or human (if applicable): {{SAFETY_CONSEQUENCE}}
4. Inherent risk before controls
Inherent risk is the likelihood and impact before any compensating controls. Capturing the inherent score makes the gap between inherent and residual visible, which is what tells a reviewer whether the controls are doing meaningful work. ISO 31000 Clause 6.4 and NIST SP 800-30 Section 3.3 both expect the inherent position to be recorded as a separate score from residual.
Inherent likelihood (before controls): Very Low / Low / Medium / High / Very High
Likelihood basis (qualitative description, percentage band, or quantitative distribution): {{LIKELIHOOD_BASIS}}
Inherent impact (before controls):
- Financial impact band: {{FINANCIAL_IMPACT_BAND}}
- Operational impact band: {{OPERATIONAL_IMPACT_BAND}}
- Regulatory impact band: {{REGULATORY_IMPACT_BAND}}
- Reputational impact band: {{REPUTATIONAL_IMPACT_BAND}}
- Composite inherent impact rating: Very Low / Low / Medium / High / Very High
Inherent risk rating (from likelihood-by-impact matrix): Very Low / Low / Medium / High / Very High
Inherent risk score (numeric, if scoring method requires): {{INHERENT_SCORE}}
Scoring method (qualitative 5x5, semi-quantitative band, quantitative FAIR, or other): {{SCORING_METHOD}}
Threat-intelligence references that informed the inherent score:
- CVE / KEV / EPSS references (if applicable): {{CVE_KEV_EPSS_REFERENCES}}
- MITRE ATT&CK techniques (if applicable): {{ATTACK_TECHNIQUE_REFERENCES}}
- Industry advisories or sector reports (if applicable): {{ADVISORY_REFERENCES}}
5. Treatment decision and rationale
Four treatment decisions cover the durable shape of risk response. Use one decision per entry. ISO/IEC 27001 Clause 6.1.3, ISO 31000 Clause 6.5, and NIST SP 800-30 Section 3.4 all map to this four-way taxonomy. If the entry feels like two treatments at once, split it into two entries so the residual scores stay separable.
Treatment decision (select one):
[ ] Mitigate: reduce likelihood or impact through additional controls or remediation work.
[ ] Transfer: shift residual to a third party through contract, insurance, or service-level transfer.
[ ] Avoid: remove the activity, asset, or condition that creates the risk.
[ ] Accept: leave the residual position in place because cost-versus-benefit, compensating controls, or risk appetite supports the choice.
Treatment rationale:
{{TREATMENT_RATIONALE}}
Risk appetite check:
- Does the residual position sit inside the approved risk appetite for this category: Yes / No / Pending appetite update
- If outside appetite, named escalation path and approver: {{APPETITE_ESCALATION}}
Linked acceptance record (if treatment is Accept and an exception or formal acceptance was raised): {{LINKED_EXCEPTION_REFERENCE}}
Linked transfer record (if treatment is Transfer, name the contract clause, insurance policy, or SLA):
- Mechanism: {{TRANSFER_MECHANISM}}
- Reference: {{TRANSFER_REFERENCE}}
- Counterparty: {{TRANSFER_COUNTERPARTY}}
6. Controls in place and treatment plan
Generic control names without a reference, an owner, and a verification method are aspiration rather than control. Every named control needs a reference into the source system that proves it operates. ISO/IEC 27001 Annex A and NIST SP 800-53 control catalogues provide the reference frame; the verification method is what makes the control evidence reproducible.
Controls in place that reduce inherent to residual:
- Control 1: name = {{CONTROL_NAME_1}}; reference (Annex A, NIST SP 800-53, internal control catalogue) = {{CONTROL_REFERENCE_1}}; owner = {{CONTROL_OWNER_1}}; verification method = {{CONTROL_VERIFICATION_1}}; last verified = {{CONTROL_LAST_VERIFIED_1}}
- Control 2: name = {{CONTROL_NAME_2}}; reference = {{CONTROL_REFERENCE_2}}; owner = {{CONTROL_OWNER_2}}; verification method = {{CONTROL_VERIFICATION_2}}; last verified = {{CONTROL_LAST_VERIFIED_2}}
- Control 3: name = {{CONTROL_NAME_3}}; reference = {{CONTROL_REFERENCE_3}}; owner = {{CONTROL_OWNER_3}}; verification method = {{CONTROL_VERIFICATION_3}}; last verified = {{CONTROL_LAST_VERIFIED_3}}
- Additional controls (append rows as needed): {{ADDITIONAL_CONTROLS}}
Treatment plan (if treatment is Mitigate):
- Action 1: {{ACTION_1}}; owner = {{ACTION_OWNER_1}}; due date = {{ACTION_DUE_1}}; status = Not started / In progress / Completed / Blocked
- Action 2: {{ACTION_2}}; owner = {{ACTION_OWNER_2}}; due date = {{ACTION_DUE_2}}; status = Not started / In progress / Completed / Blocked
- Action 3: {{ACTION_3}}; owner = {{ACTION_OWNER_3}}; due date = {{ACTION_DUE_3}}; status = Not started / In progress / Completed / Blocked
- Plan completion date: {{PLAN_COMPLETION_DATE}}
- Funding or resource constraints that affect plan execution: {{PLAN_CONSTRAINTS}}
Concentration risk note (if multiple register entries depend on the same control or vendor): {{CONCENTRATION_NOTE}}
7. Residual risk after controls and treatment
Residual risk is the position after the controls in Section 6 land. The residual rating is what leadership reads against risk appetite. Recording the residual position separately from inherent is what tells a reviewer whether the firm is carrying acceptable risk or unmanaged risk. ISO/IEC 27001 Clause 6.1.3 and NIST SP 800-53 RA-3 both expect residual to be approved before the entry closes.
Residual likelihood (after controls): Very Low / Low / Medium / High / Very High
Residual likelihood basis: {{RESIDUAL_LIKELIHOOD_BASIS}}
Residual impact (after controls):
- Composite residual impact rating: Very Low / Low / Medium / High / Very High
- Residual impact basis: {{RESIDUAL_IMPACT_BASIS}}
Residual risk rating: Very Low / Low / Medium / High / Very High
Residual risk score (numeric, if scoring method requires): {{RESIDUAL_SCORE}}
Residual approved by (named individual): {{RESIDUAL_APPROVER}}
Residual approval date: {{RESIDUAL_APPROVAL_DATE}}
Approval level (operating committee, risk committee, audit committee, board): {{APPROVAL_LEVEL}}
Sensitivity check:
- If the strongest compensating control failed, the residual rating would move to: {{RATING_WITHOUT_TOP_CONTROL}}
- If the second strongest control failed, the residual rating would move to: {{RATING_WITHOUT_SECOND_CONTROL}}
- Worst-credible scenario rating (for stress-testing leadership view): {{WORST_CREDIBLE_RATING}}
8. Risk owner, review cadence, and triggers
Every entry has one named risk owner who is the accountable individual for the risk and a review cadence that matches the residual rating. Recording the cadence and the trigger conditions on the entry catches the time-driven and event-driven review needs together. ISO/IEC 27001 Clause 8.3 and NIST SP 800-37 Step 6 both expect both cadence and triggers to be defined.
Risk owner (named individual, accountable for the risk): {{RISK_OWNER}}
Risk owner role (executive, business unit head, function head, control owner): {{RISK_OWNER_ROLE}}
Delegated administrator (named individual maintaining the entry): {{DELEGATED_ADMINISTRATOR}}
Review cadence:
- Per-entry review cadence (set by residual rating; quarterly for High and Critical, semi-annually for Medium, annually for Low): {{REVIEW_CADENCE}}
- Last review date: {{LAST_REVIEW_DATE}}
- Next review date: {{NEXT_REVIEW_DATE}}
- Reviewer (named individual): {{REVIEWER}}
- Review outcome (no change, residual revised, treatment plan revised, escalated, closed): {{LAST_REVIEW_OUTCOME}}
Trigger conditions that force an off-cadence review:
[ ] Material asset change (system replaced, re-architected, decommissioned, migrated)
[ ] Material scope change (new business unit, new geography, new product line, new tenant)
[ ] Material control change (control modified, retired, replaced)
[ ] Material exploit change (CISA KEV listing, public exploit, active campaign)
[ ] Vendor advisory or third-party assessment change
[ ] Incident or near-miss involving the risk
[ ] Regulatory or framework change affecting the risk category
[ ] Other: {{OTHER_TRIGGER}}
Trigger response plan: {{TRIGGER_RESPONSE_PLAN}}
9. Lifecycle events and audit trail
Every status transition on the entry carries a date, an actor, and a reason. The lifecycle log is what makes the entry defensible at audit time. ISO/IEC 27001 Clause 9.3, NIST SP 800-53 AU-2 and AU-3, SOC 2 CC4.1, and PCI DSS Requirement 10 all expect a documented record of register lifecycle events. Silent edits are the most common audit failure pattern; the lifecycle log is the structural fix.
A risk register entry without monitoring is static. KRIs (key risk indicators) and KCIs (key control indicators) are the operational signals that surface drift before the next planned review. NIST SP 800-37 Step 7 and SOC 2 CC4.2 both expect continuous monitoring of risk-relevant signals on top of cadence-based review.
Key risk indicators (KRIs) for this entry:
- KRI 1: name = {{KRI_NAME_1}}; source system = {{KRI_SOURCE_1}}; threshold green / amber / red = {{KRI_THRESHOLDS_1}}; current value = {{KRI_CURRENT_1}}; review cadence = {{KRI_CADENCE_1}}
- KRI 2: name = {{KRI_NAME_2}}; source system = {{KRI_SOURCE_2}}; thresholds = {{KRI_THRESHOLDS_2}}; current value = {{KRI_CURRENT_2}}; cadence = {{KRI_CADENCE_2}}
- KRI 3 (append rows as needed): {{ADDITIONAL_KRI}}
Key control indicators (KCIs) verifying the controls in Section 6 are operating:
- KCI 1: control reference = {{KCI_CONTROL_1}}; signal = {{KCI_SIGNAL_1}}; current state = {{KCI_STATE_1}}
- KCI 2: control reference = {{KCI_CONTROL_2}}; signal = {{KCI_SIGNAL_2}}; current state = {{KCI_STATE_2}}
- Additional KCIs: {{ADDITIONAL_KCI}}
Threshold-breach response plan: {{KRI_BREACH_RESPONSE}}
Linked monitoring source (scan schedule, dashboard, log query, vendor report, audit trail): {{MONITORING_SOURCE}}
11. Cross-references to operating records
Risk register entries sit next to the operating records that drive the residual position. Linking each entry to the live finding, engagement, exception, control evidence, and incident keeps the audit narrative one record rather than four. The auditor question "show me the underlying activity that supports this residual rating" can be answered with one query rather than a multi-team evidence-collection sprint.
Linked finding identifiers (canonical record): {{LINKED_FINDINGS}}
Linked engagement reference (assessment, audit, internal review, retest report): {{LINKED_ENGAGEMENT}}
Linked exception register entry (if treatment is Accept): {{LINKED_EXCEPTION_ENTRY}}
Linked risk acceptance form (per-decision rationale): {{LINKED_RISK_ACCEPTANCE}}
Linked remediation worksheet (if treatment is Mitigate and active work is in progress): {{LINKED_REMEDIATION_WORKSHEET}}
Linked audit evidence tracker entries (control evidence supporting the controls in Section 6): {{LINKED_EVIDENCE_TRACKER}}
Linked incident or near-miss reference: {{LINKED_INCIDENT}}
Linked policy or standard clause: {{LINKED_POLICY_CLAUSE}}
Linked vendor advisory or third-party assessment: {{LINKED_VENDOR_REFERENCE}}
12. Register-level summary metrics and reporting
A register without aggregate metrics cannot answer the leadership question. Capture the cumulative position so programme review reads the residual risk picture rather than only the per-entry detail. Review these metrics at every register-wide review and report them to the risk or audit committee. ISO/IEC 27001 Clause 9.3, NIST SP 800-39 Section 2.4, and SOC 2 CC4.1 all expect the leadership view.
Reporting period: {{REPORTING_PERIOD_START}} to {{REPORTING_PERIOD_END}}
Counts at end of reporting period:
- Open entries by residual rating: Very Low {{COUNT_VLOW}} / Low {{COUNT_LOW}} / Medium {{COUNT_MEDIUM}} / High {{COUNT_HIGH}} / Critical {{COUNT_CRITICAL}}
- Open entries by category: technology {{COUNT_TECH}} / cyber {{COUNT_CYBER}} / data privacy {{COUNT_PRIVACY}} / third-party {{COUNT_THIRDPARTY}} / regulatory {{COUNT_REG}} / operational {{COUNT_OPS}} / other {{COUNT_OTHER}}
- Open entries by treatment: Mitigate {{COUNT_MITIGATE}} / Transfer {{COUNT_TRANSFER}} / Avoid {{COUNT_AVOID}} / Accept {{COUNT_ACCEPT}}
- Entries inside risk appetite: {{COUNT_INSIDE_APPETITE}}
- Entries outside risk appetite (with named escalation): {{COUNT_OUTSIDE_APPETITE}}
Period activity:
- Entries raised during the period: {{COUNT_RAISED}}
- Entries closed via remediation: {{COUNT_CLOSED_REMEDIATED}}
- Entries closed via retirement of the activity or asset: {{COUNT_CLOSED_RETIRED}}
- Entries reclassified or merged: {{COUNT_RECLASSIFIED}}
- Entries breaching their next-review date: {{COUNT_OVERDUE_REVIEW}}
- Entries with KRI threshold breaches during the period: {{COUNT_KRI_BREACH}}
Trend versus prior period:
- Net change in open entry count: {{NET_CHANGE_COUNT}}
- Net change in residual position (qualitative): {{NET_CHANGE_RATING}}
- Outstanding actions from prior register-wide review: {{OUTSTANDING_PRIOR_ACTIONS}}
Top-residual view (top ten by residual rating):
{{TOP_TEN_LIST_WITH_OWNERS_AND_TREND}}
Report distribution (named recipients, channels, dates):
{{REPORT_DISTRIBUTION_LIST}}
Six failure modes the register has to design against
The risk register fails the audit and leadership read in recognisable patterns. Each failure has a structural fix the template above is designed to enforce. Read this list before you customise the template so the customisation does not weaken the discipline that makes the register defensible.
The register lives in one analyst’s spreadsheet
Entries sit in a single spreadsheet on the analyst’s laptop, the analyst goes on leave, and nobody can read or update the register until they return. The first audit question (show me every open risk by residual rating) cannot be answered in a session. The fix is one register, one row per risk, one shared system of record, and a delegated administrator separate from the named risk owner.
No inherent score, only residual
Entries record only the residual rating, so a reviewer cannot see what the controls are buying. When a control fails or is decommissioned, there is no baseline to compare against and the residual update becomes guesswork. Recording inherent and residual separately is what makes the entry defensible across control changes and threat-landscape shifts.
Risk statements that are technical findings in disguise
Entries read as "SQL injection on customer portal" or "MFA missing on admin console" rather than as risk statements. Technical findings are inputs to risks; they are not risks themselves. The register entry should read at the risk level (the threat scenario, the consequence, the affected processes) and link down to the findings that drive the residual position. Without that translation, leadership cannot read the register and the entry stays trapped at the operator level.
No named risk owner, or the owner has moved roles
Entries land with a function name (Security, IT, Compliance) instead of a named individual, or the named owner has moved teams and nobody updated the entry. Audit reads ownership ambiguity as a control failure on accountability. Set the owner as a named individual with a role, run a quarterly owner-currency check, and treat ownership reassignment as a hard register event with its own lifecycle log entry.
Generic compensating controls
A control listed as "WAF blocks the attack" or "monitored in SIEM" without the rule reference, the segment policy, or the alert query is aspiration rather than control. The audit reads the absence of a verifiable reference as the absence of the control. Every named control needs a reference, an owner, a verification method, and a last-verified date so the register reads as evidence rather than as memory.
Silent residual drift
The risk landscape moves (new exploit availability, vendor advisory, control decommission, organisational change) and the entry sits unchanged because the trigger conditions were never recorded. By the time the next planned review fires, the residual is wrong and the firm has been carrying unmanaged risk for months. Record the trigger conditions on every entry and treat a fired trigger as a hard review event rather than as a paperwork slip.
Ten questions a quarterly register-wide review has to answer
Per-entry review keeps each risk current. Register-wide review answers the cumulative question: is the residual position drifting, is the treatment pipeline keeping up with new entries, and is the cumulative exposure consistent with the firm’s risk appetite. Run these ten questions at every quarterly register-wide review and capture the answers in the register-level summary section.
1.How many entries are open at the end of the period, broken out by residual rating, treatment decision, and category.
2.Which entries sit outside risk appetite, and is there an active escalation path for each with a named approver and a planned closure date.
3.How many entries are approaching their next-review date within sixty days, and is the review pipeline ready for them.
4.How many entries breached their next-review date during the period, and what was the resolution path for each (review completed, residual revised, escalated, closed).
5.Which controls in Section 6 are concentration risks because they support multiple register entries at once, and how does the firm verify those controls are still in place.
6.Which residual ratings have drifted higher since approval because the underlying CVE catalogue, exploit availability, threat intelligence, or vendor advisory situation has changed.
7.Which entries depend on third-party or vendor controls with no recent vendor advisory update, and what is the escalation path with the vendor.
8.How does the cumulative open-entry count compare to the prior period, and what is the trend across the last four periods by residual rating and by category.
9.Which entries are owned by named individuals who are no longer in role, and who is the new owner of each.
10.Which entries link to active exceptions in the security exception register, and is the cumulative residual position consistent with the cumulative exception view.
How the register pairs with SecPortal
The template above is copy-ready as a standalone artefact. If your team already runs finding tracking, scan execution, and compliance evidence on a workspace, the register becomes the byproduct of the work rather than a separate document. SecPortal pairs every risk entry to the persistent records that drive its residual position through findings management (CVSS 3.1 vector, persistent finding identifiers, retest evidence) and engagement management (engagement scope, attached documents, deliverables), so the lineage from the underlying findings to the register entry to the eventual closure or renewal is one record rather than a spreadsheet glued to a report.
The compliance tracking feature maps findings and controls to ISO 27001, SOC 2, Cyber Essentials, PCI DSS, and NIST frameworks with CSV export, so the register can be sliced by framework when an auditor or risk-committee reader asks for the residual position against a specific control set. The activity log captures status transitions on every entity (finding, engagement, scan, document, comment, invoice, team) by user and timestamp, so the lifecycle log in Section 9 is recorded automatically as a side effect of the work and the residual approver record in Section 7 points to a live audit record rather than to a static screenshot.
The team management feature carries the role-based access control that decides who can raise a register entry, who can approve residual at each rating, and who can run the register-wide review. The multi-factor authentication control gates workspace access at AAL2 so the audit reads the access record as a documented control rather than a hope. The AI report generation workflow can produce a leadership-ready summary view of top-residual entries, near-due reviews, breach-of-appetite entries, and trend across the last four periods from the same engagement data that operators run on.