Security Exception Register Template one ledger for every approved risk acceptance
A free, copy-ready security exception register template. Twelve structured sections covering register scope and review cadence, entry identification with linked finding, plain-language risk summary, original severity and inherent risk, exception type and rationale, compensating controls with verification, residual risk after controls, named risk owner and security approver, hard expiry with review cadence and trigger conditions, lifecycle audit trail, closure or renewal record, and register-level summary metrics. Aligned with ISO/IEC 27001 Annex A 5.36 and Clause 8.3, NIST SP 800-53 RA-3 and PM-9, PCI DSS Requirement 12.3, SOC 2 CC3.1 and CC3.4, and the standard expectations across HIPAA, NIS2, DORA, and FedRAMP.
Run the register inside the workspace, not in a shared drive
SecPortal pairs every exception to its linked finding, captures status transitions on the activity log, and slices the register by framework for audit review. Free plan available.
No credit card required. Free plan available forever.
Twelve sections that turn ad hoc approvals into a defensible register
A security exception register is the org-wide ledger of every approved deviation from a policy, control, or remediation SLA. The twelve sections below cover the durable shape of the artefact across ISO/IEC 27001 Annex A 5.36 and Clause 8.3, NIST SP 800-53 RA-3 and PM-9, PCI DSS Requirement 12.3, SOC 2 CC3.1 and CC3.4, and the standard expectations in HIPAA, NIS2, DORA, and FedRAMP risk acceptance practice. Copy the section that fits your stage and paste the rest as you go.
The register is not a substitute for a per-decision risk acceptance form; it is the aggregate ledger that lists every accepted risk in one place so leadership and audit can read the cumulative residual position. Pair it with the risk acceptance form template for the per-entry detail, the vulnerability remediation worksheet for the per-finding work, the remediation SLA calculator for the policy targets that define when a finding needs an exception in the first place, and the vulnerability SLA policy template for the signed document that names the windows, escalation ladder, and the exception path the register feeds, and the vulnerability management policy template for the umbrella programme document that publishes the exception governance ladder this register operationalises.
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 a reviewer reading any entry knows which estate, which programme, and which framework expectations the register operates under. ISO/IEC 27001 Annex A 5.36, NIST SP 800-53 PM-9, and PCI DSS Requirement 12.3 each expect the register to name its scope so an entry that drifts outside scope is visible.
Every register entry pairs to a persistent finding or control reference rather than to a report ID. Recording against the finding lets the entry survive report regeneration, retest cycles, and version reissues without the lineage breaking. A successor reviewer should be able to reconstruct the entire exception timeline without speaking to anyone who worked on it.
A two-sentence description in business language. The summary is what a non-technical reviewer reads to decide whether the residual risk is acceptable. If the summary needs CVSS jargon to make sense, the finding has not been translated for the approver and the entry will be hard to defend at audit.
Plain-language risk summary:
{{PLAIN_LANGUAGE_SUMMARY}}
Affected assets:
- Systems / applications / repositories: {{AFFECTED_ASSETS}}
- Environment (production, staging, pre-production, development): {{ENVIRONMENT}}
- Data classifications in scope: {{DATA_CLASSIFICATIONS}}
- Business processes impacted: {{BUSINESS_PROCESSES}}
- Internet-facing exposure: Yes / No / Partial
Plain-language consequence if exploited:
{{PLAIN_LANGUAGE_CONSEQUENCE}}
4. Original severity and inherent risk
Capture the severity at detection before any compensating controls apply. The exception does not lower the inherent severity; it records the residual position after the controls in Section 6. ISO/IEC 27005 expects the original risk to be recorded so reviewers can read the gap between inherent and residual.
Original CVSS 3.1 vector: {{CVSS_VECTOR}}
Original CVSS 3.1 base score: {{CVSS_BASE_SCORE}}
Original severity: Critical / High / Medium / Low / Informational
CWE / OWASP mapping (if applicable): {{CWE_OWASP_MAPPING}}
KEV listing (CISA Known Exploited Vulnerabilities): Yes / No / Not applicable
Exploitation prerequisites:
{{EXPLOITATION_PREREQUISITES}}
Inherent likelihood (before controls): Very Low / Low / Medium / High / Very High
Inherent impact (before controls): Very Low / Low / Medium / High / Very High
5. Exception type and rationale
Six exception types cover the durable shape of accepted risk. Use one type per entry. If the entry feels like two types at once, the exception is probably overloaded and the cleaner path is splitting it into two entries.
Exception type (select one):
[ ] Compensating-control acceptance: vulnerability stays in place; layered control reduces residual to a level the business is willing to carry.
[ ] Time-bound deferral: fix is planned but cannot ship inside the current SLA window; expiry tied to a release, sprint, or refresh date.
[ ] Cost-versus-residual acceptance: fix is feasible but cost outweighs residual after compensating controls; retirement or replacement plan named.
[ ] Vendor-dependency acceptance: vulnerability lives inside a vendor product; vendor advisory and case number named.
[ ] Out-of-scope reclassification with residual visibility: finding is outside the engagement scope; residual visibility path to the asset owner named.
[ ] Risk-transferred acceptance: residual risk transferred to a third party through contract, insurance, or SLA; transfer mechanism named.
Business rationale for the exception:
{{BUSINESS_RATIONALE}}
Why remediation cannot proceed in the standard SLA window:
{{REMEDIATION_BARRIER}}
6. Compensating controls in place
Every named compensating control needs a control reference, a named owner, a verification method, and a failure mode. A control named generically without a reference is an aspiration, not a control. The audit read of an exception is the read of its compensating controls; weak controls produce a weak exception even when the rationale is sound.
Control 1
- Description: {{CONTROL_1_DESCRIPTION}}
- Reference (rule ID, segment policy, alert query, configuration excerpt): {{CONTROL_1_REFERENCE}}
- Evidence reference: {{CONTROL_1_EVIDENCE_REFERENCE}}
- Owner: {{CONTROL_1_OWNER}}
- Verification method (how security confirms the control is in place at review time): {{CONTROL_1_VERIFICATION_METHOD}}
- Failure mode (what would cause the control to silently disable): {{CONTROL_1_FAILURE_MODE}}
Control 2
- Description: {{CONTROL_2_DESCRIPTION}}
- Reference: {{CONTROL_2_REFERENCE}}
- Evidence reference: {{CONTROL_2_EVIDENCE_REFERENCE}}
- Owner: {{CONTROL_2_OWNER}}
- Verification method: {{CONTROL_2_VERIFICATION_METHOD}}
- Failure mode: {{CONTROL_2_FAILURE_MODE}}
Detection control that would surface exploitation:
- Description: {{DETECTION_CONTROL_DESCRIPTION}}
- Reference: {{DETECTION_CONTROL_REFERENCE}}
- Owner: {{DETECTION_CONTROL_OWNER}}
7. Residual risk after controls apply
The residual rating is what the entry actually accepts. Record likelihood and impact separately so the rating cannot be quietly compressed into a single severity headline. NIST SP 800-30 and ISO 27005 both expect explicit likelihood and impact as the basis for the residual position.
Residual likelihood (after controls apply): Very Low / Low / Medium / High / Very High
Residual impact (after controls apply): Very Low / Low / Medium / High / Very High
Residual risk rating: Low / Medium / High / Critical
Residual rating rationale (one paragraph in plain language):
{{RESIDUAL_RATING_RATIONALE}}
Risk-tolerance check: residual rating is within the firm risk tolerance for this asset class: Yes / No
If No, escalation path: {{ESCALATION_PATH_IF_OUT_OF_TOLERANCE}}
8. Risk owner and security approver
Every exception names two parties on the entry. The risk owner carries the residual risk on behalf of the business or engineering function. The security approver signs that the residual risk is within the firm risk tolerance. Both parties are named individuals, not teams. ISO 27001 Annex A 5.36 expects an accountable risk owner and an authorising security approver.
Risk owner (named individual, business or engineering leader): {{RISK_OWNER_NAME}}
Risk owner role / business unit: {{RISK_OWNER_ROLE}}
Risk owner sign-off date: {{RISK_OWNER_SIGNOFF_DATE}}
Security approver (named individual; authority depends on residual rating):
- Low residual: Security manager or equivalent
- Medium residual: Head of security or equivalent
- High residual: CISO or risk committee
- Critical residual: CISO and executive sponsor
Selected approver: {{SECURITY_APPROVER_NAME}}
Approver role / authority: {{SECURITY_APPROVER_ROLE}}
Security approver sign-off date: {{SECURITY_APPROVER_SIGNOFF_DATE}}
Other consulted parties (legal, privacy, product, operations, third-party assessor): {{CONSULTED_PARTIES}}
9. Expiry, review cadence, and trigger conditions
Every entry carries a hard expiry, a review cadence, and a list of trigger conditions that would invalidate the exception inside the calendar window. Permanent exceptions are not exceptions; they are control gaps the firm is choosing to live with. Trigger conditions cover the change axes that calendar review alone misses.
Approval date: {{APPROVAL_DATE}}
Hard expiry date: {{HARD_EXPIRY_DATE}}
Default expiry ladder (tune to your risk tolerance):
- Critical residual: 6 months maximum
- High residual: 12 months maximum
- Medium residual: 12 to 24 months
- Low residual: 24 months maximum
Per-entry review cadence: {{ENTRY_REVIEW_CADENCE}}
Next review date: {{NEXT_REVIEW_DATE}}
Trigger conditions that invalidate the exception inside the calendar window (select all that apply):
[ ] Material asset change (system replaced, re-architected, decommissioned, or migrated).
[ ] Material scope change (boundary moves to add a new business unit, geography, tenant, or product line).
[ ] Material control change (compensating control modified, retired, or replaced).
[ ] Material remediation gap (linked finding fix path becomes feasible inside the SLA).
[ ] Material people change (named risk owner or security approver no longer in role).
[ ] Material exploit change (CISA KEV listing, public exploit, active campaign on the underlying issue).
[ ] Vendor advisory change (vendor patch released, vendor case status updated).
[ ] Other: {{OTHER_TRIGGER_CONDITION}}
10. Lifecycle events and audit trail
Every status transition on the entry carries a date, an actor, and a reason. The audit trail is what makes the register defensible at review time. ISO 27001 Clause 9.3, NIST SP 800-53 AU-2 and AU-3, SOC 2 CC4.1, and PCI DSS Requirement 12.3.1 all expect documented review of risk acceptances.
Closure is one of: remediation completed and finding closed, renewal with fresh expiry and fresh approval, escalation because remediation is not feasible at the residual rating, or cancellation because the finding was reclassified. Silent expiry extension is the most common audit failure pattern and is not a closure.
Closure type (select one):
[ ] Closed: linked finding remediated and verified at retest. Original SLA met retroactively.
[ ] Renewed: fresh expiry, fresh compensating controls, fresh approval. Reason for renewal: {{RENEWAL_REASON}}
[ ] Escalated: remediation not feasible at the residual rating; routed to executive risk acceptance. Escalation reference: {{ESCALATION_REFERENCE}}
[ ] Cancelled: finding reclassified as out of scope, false positive, or duplicate. Reason: {{CANCELLATION_REASON}}
Closure date: {{CLOSURE_DATE}}
Closure approver (named individual): {{CLOSURE_APPROVER}}
Closure evidence references:
- Linked retest record (if remediated): {{RETEST_RECORD_REFERENCE}}
- Renewal approval reference (if renewed): {{RENEWAL_APPROVAL_REFERENCE}}
- Escalation acceptance reference (if escalated): {{ESCALATION_ACCEPTANCE_REFERENCE}}
12. Register-level summary metrics
A register without aggregate metrics cannot answer the leadership question. Capture the cumulative position so the 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.
Reporting period: {{REPORTING_PERIOD_START}} to {{REPORTING_PERIOD_END}}
Counts at end of reporting period:
- Open exceptions by residual rating: Low {{COUNT_OPEN_LOW}} / Medium {{COUNT_OPEN_MEDIUM}} / High {{COUNT_OPEN_HIGH}} / Critical {{COUNT_OPEN_CRITICAL}}
- Open exceptions by exception type (compensating-control / time-bound / cost-versus-residual / vendor-dependency / out-of-scope / risk-transferred): {{COUNTS_BY_TYPE}}
- Exceptions approaching expiry within 60 days: {{COUNT_NEAR_EXPIRY}}
- Exceptions past expiry: {{COUNT_PAST_EXPIRY}}
- Exceptions renewed during the period: {{COUNT_RENEWED}}
- Exceptions closed via remediation during the period: {{COUNT_CLOSED_REMEDIATED}}
- Exceptions escalated to executive acceptance during the period: {{COUNT_ESCALATED}}
Trend versus prior period:
- Net change in open exception count: {{NET_CHANGE_COUNT}}
- Net change in cumulative residual rating (qualitative): {{NET_CHANGE_RATING}}
- Outstanding actions from prior register-wide review: {{OUTSTANDING_PRIOR_ACTIONS}}
Report distribution (named recipients, channels, dates):
{{REPORT_DISTRIBUTION_LIST}}
Six failure modes the register has to design against
The register fails the audit read in recognisable patterns. Each failure has a structural fix that 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 an email thread or shared drive
Approvals sit in mail folders, slide decks, and ad hoc spreadsheets that nobody can search at audit time. The first audit question (show me every approved exception across the programme) cannot be answered in a session. The fix is one register, one row per exception, one source of truth.
No expiry, no review cadence
Entries land with no hard expiry and no per-entry review cadence. Findings sit in exception status indefinitely; owners move teams; compensating controls silently disable during a refactor. By the time anyone notices, the residual position bears no relation to the one originally approved. Permanent exceptions are the slowest path to a critical incident.
Generic compensating controls
A control named generically as "WAF blocks the attack" or "monitored in SIEM" without the rule ID, the segment policy, or the alert query is not a control; it is an aspiration. The audit reads the absence of evidence as the absence of the control. Every named control needs a reference, an owner, a verification method, and a failure mode.
Approval routing concentrates on the CISO
A flat routing rule sends every exception to the head of security regardless of residual rating. The CISO becomes the bottleneck, low-residual entries wait weeks for sign-off, and engineering teams stop bothering to file exceptions for genuinely small risks. Tier the routing by residual rating so the CISO authority is reserved for high and critical residual.
Silent expiry extension
An entry approaches expiry, the original approver is unavailable, and the date is quietly pushed out without a fresh review or a new approval. The audit reads the quiet extension as a control failure and the firm carries an unmanaged exception. A breached expiry is a hard control event, not a paperwork slip; the entry either renews on a fresh approval, closes via remediation, or escalates.
Acceptance recorded against the report rather than the finding
The register lists exceptions by report ID rather than by persistent finding ID. Two retests later the finding numbering changes, the lineage breaks, and the audit cannot tie the original exception to the current finding. Record exceptions against persistent finding identifiers so the linked record survives report regeneration.
Ten questions a quarterly register review has to answer
Per-entry review keeps each exception current. Register-wide review answers the cumulative question: is the residual risk position drifting, and is the programme on top of expiries, renewals, and escalations. Run these ten questions at every quarterly review and capture the answers in the register-level summary section.
1.How many exceptions are open at the end of the period, broken out by residual rating and exception type.
2.How many entries are approaching expiry within sixty days, and is the renewal or closure pipeline ready for them.
3.How many entries breached expiry during the period, and what was the resolution path for each (renewal, remediation, escalation, cancellation).
4.Which compensating controls are concentration risks because they support multiple exceptions at once, and how does the firm verify those controls are still in place.
5.Which residual ratings have drifted higher since approval because the underlying CVE catalogue, exploit availability, or threat intelligence has changed.
6.Which exceptions sit in vendor-dependency status with no recent vendor advisory update, and what is the escalation path with the vendor.
7.How does the cumulative open-exception count compare to the prior period, and what is the trend across the last four periods.
8.Which entries are owned by named individuals who are no longer in role, and who is the new owner of each.
9.Which entries have not been reported to the risk or audit committee in the period the register policy expects.
10.Which entries are visible on the client portal (where applicable) and which are not, and is the visibility position still appropriate.
How the register pairs with SecPortal
The template above is copy-ready as a standalone artefact. If your team already runs finding tracking, remediation, and compliance evidence on a workspace, the register becomes the byproduct of the work rather than a separate document. SecPortal pairs every exception to the persistent finding identifier through findings management, so the lineage from the linked finding 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 asks for the residual risk position against a specific control set. The activity log captures status transitions on every entry by user and timestamp, so the lifecycle log in Section 10 is recorded automatically as a side effect of the work.
The team management feature carries the role-based access control that decides who can raise an exception, who can approve at each residual rating, and who can run the register-wide review. The AI report generation workflow can produce a summary view of open exceptions, near-expiry entries, and residual risk trend for risk-committee reporting from the same engagement data.