What is a risk acceptance form?

A risk acceptance form is the written record that a named owner has reviewed a vulnerability or security risk, understood the impact and likelihood, considered the available treatments (remediate, mitigate, transfer, accept), and consciously chosen to accept the residual risk for a defined period. NIST SP 800-39 calls this risk response under the "accept" treatment, and ISO/IEC 27005 expects the decision, the rationale, the owner, and the review date to be captured before the risk is left in place.

When should you use a risk acceptance form instead of fixing a finding?

Use a risk acceptance form when fixing the finding is not possible inside the current SLA window, when the cost of remediation is disproportionate to the residual risk, when a compensating control reduces the exploitability to an acceptable level, or when remediation depends on a future change (platform migration, vendor patch, contract renewal). It is not a tool for closing aged findings out of the queue: an accepted risk should still be tracked, reviewed on the agreed cadence, and reopened as soon as the conditions that justified the acceptance change.

Who needs to sign a risk acceptance?

The risk owner who is accountable for the affected system or business process must sign. Depending on severity, the form is countersigned by a security lead (CISO, head of security, or vCISO) and, for high or critical residual risk, by an executive sponsor. ISO/IEC 27005 and NIST SP 800-39 both push the accountability to the level that holds the budget for the affected risk: a developer cannot accept a critical risk on behalf of a business owner who has never seen the finding.

What should a risk acceptance form always include?

At minimum: a unique reference, the linked finding or risk identifier, a plain-language description of the issue, the affected assets, the original CVSS 3.1 vector and severity, any compensating controls that reduce exploitability, the residual likelihood and impact after compensating controls, the rationale for acceptance, the named risk owner and security approver, the review date, the trigger conditions that would cancel the acceptance, and signatures with date.

How long should a risk acceptance be valid?

Tie the validity to the trigger conditions, then cap it with a hard expiry. A common pattern: critical residual risk reviewed every 30 days with a hard expiry of 90 days, high every 90 days with a hard expiry of 180 days, medium every 180 days with a hard expiry of one year, and low every 365 days. Auditors expect to see that an accepted risk did not become a forever-deferral, so the review date should be visible on the form and tracked in the same workspace as the underlying finding.

How is risk acceptance different from a risk exception?

In most programmes the terms are used interchangeably. Where they differ: a risk exception is typically tied to a specific control or policy clause (a deviation from an internal standard, like an exception to the password policy or an out-of-policy network configuration) and runs through a policy waiver process. A risk acceptance is tied to a finding or scenario and runs through the vulnerability management process. Both end in the same place: a written, signed, time-bound decision with a named owner.

How does risk acceptance fit into a remediation SLA programme?

Acceptance and remediation are siblings, not opposites. A defensible programme defines remediation SLAs by severity (often calibrated against PCI DSS, ISO 27001, SOC 2, or CISA KEV), and a risk acceptance is the structured way to record that a finding will not meet its SLA for a stated reason. The acceptance is paired to the original finding so the audit trail still shows the SLA breach and the conscious, signed decision that authorised it. The SLA dashboard then reports remediated, in-progress, overdue, and accepted-with-rationale separately.

What evidence should be attached to a risk acceptance?

Attach the original finding record (with CVSS vector, evidence, and remediation guidance), any threat modelling notes that informed the residual risk, evidence of the compensating controls (configuration excerpt, screenshot, change ticket reference, IPS rule, network ACL), the cost-benefit notes if remediation was rejected on cost grounds, and any third-party advisories or vendor responses that influenced the decision. The point is that a successor reviewer can reconstruct the decision without speaking to anyone who signed it.

Can you accept a risk on behalf of a client?

No. As an external testing firm or vCISO you can recommend acceptance, document the rationale, and produce the form, but the signed acceptance must come from the risk owner inside the client organisation. Accepting risk on behalf of a client confuses the accountability chain and is rejected by every mainstream framework (ISO 27001 Clause 6.1.3, NIST RMF, SOC 2 CC9.1). The pentest deliverable should hand the client a draft acceptance with the supporting evidence, not a signed one.

How does SecPortal track risk acceptance against findings?

SecPortal stores the acceptance against the original finding rather than as a separate document. The finding record holds severity, CVSS vector, evidence, remediation guidance, the assigned owner, the SLA, the acceptance form, the named approver, and the review date in one place. When the review date falls due, the finding surfaces in the SLA dashboard alongside overdue and in-progress items so accepted risks are visible to leadership rather than buried in a folder.

Free Tool

Risk Acceptance Form Template
document residual risk without losing the audit trail

A free, copy-ready risk acceptance form template. Nine structured sections covering the linked finding, plain-language risk summary, original CVSS severity, compensating controls, residual likelihood and impact, rationale, review cadence and cancellation triggers, approvals, and supporting evidence. Aligned with NIST SP 800-39, ISO/IEC 27005, ISO/IEC 27001 Clause 6.1.3, SOC 2 CC9.1, and the PCI DSS compensating control worksheet expectations.

Get Started Free

No credit card required. Free plan available forever.

Full template

Copy the full risk acceptance form

Nine sections, paired to the underlying finding rather than replacing it. Aligned with NIST SP 800-39 risk response (accept), ISO/IEC 27005 risk treatment, ISO/IEC 27001 Clause 6.1.3, SOC 2 CC9.1, and the PCI DSS compensating control worksheet expectations. Replace every {{PLACEHOLDER}} before the form is signed.

1. Acceptance reference and linked finding

Every acceptance is paired to a specific finding or risk in the register. NIST SP 800-39 and ISO/IEC 27005 both expect the source record to be traceable so a successor reviewer can reconstruct the decision.

Risk acceptance reference: {{ACCEPTANCE_REFERENCE}}
Linked finding / risk register ID: {{LINKED_FINDING_ID}}
Engagement reference (if from a pentest): {{ENGAGEMENT_REFERENCE}}
Date raised: {{DATE_RAISED}}
Status: Open for approval / Active / Expired / Cancelled

2. Risk summary

A plain-language summary that a non-security executive could understand. Avoid jargon. The point is that the signing approver can describe the risk back to a board if asked.

Title: {{RISK_TITLE}}
Summary in plain language:
{{PLAIN_LANGUAGE_SUMMARY}}

Affected assets:
- Systems / applications: {{AFFECTED_SYSTEMS}}
- Data classifications in scope: {{DATA_CLASSIFICATIONS}}
- Business process(es) impacted: {{BUSINESS_PROCESSES}}
- Regulatory scope (PCI DSS, ISO 27001, SOC 2, HIPAA, GDPR, NIS2, DORA, other): {{REGULATORY_SCOPE}}

3. Original severity and scoring

Capture the unmodified severity before any compensating controls. Acceptance does not change the inherent severity, it only changes the residual position after the compensating controls in Section 4.

Original CVSS 3.1 vector: {{CVSS_VECTOR}}
Original CVSS base score: {{CVSS_BASE_SCORE}}
Original severity: Critical / High / Medium / Low / Informational
CWE / OWASP mapping (if applicable): {{CWE_OWASP}}
Exploitation prerequisites:
{{EXPLOITATION_PREREQUISITES}}
Original impact statement (confidentiality, integrity, availability):
{{IMPACT_STATEMENT}}

4. Compensating controls in place

List the controls that reduce exploitability or impact today. These are the controls the acceptance relies on. If any of them lapse, the acceptance is invalid and must be re-reviewed.

Compensating controls currently in place:
1. {{CONTROL_1_DESCRIPTION}}
   Evidence reference: {{CONTROL_1_EVIDENCE}}
   Owner: {{CONTROL_1_OWNER}}
2. {{CONTROL_2_DESCRIPTION}}
   Evidence reference: {{CONTROL_2_EVIDENCE}}
   Owner: {{CONTROL_2_OWNER}}
3. {{CONTROL_3_DESCRIPTION}}
   Evidence reference: {{CONTROL_3_EVIDENCE}}
   Owner: {{CONTROL_3_OWNER}}

Detection controls that would surface exploitation:
- {{DETECTION_CONTROL_DESCRIPTION}}

Failure modes:
- If {{CONTROL_FAILURE_MODE_1}} occurs, the residual risk in Section 5 is invalidated and the acceptance must be re-reviewed.
- If {{CONTROL_FAILURE_MODE_2}} occurs, the acceptance is automatically suspended pending review.

5. Residual likelihood, impact, and rating

After compensating controls, what is left? Express the residual position with the same likelihood-impact scale your risk register uses so this entry is comparable to the rest of the register.

Residual likelihood (with controls applied): Very Low / Low / Medium / High / Very High
Residual impact (with controls applied): Very Low / Low / Medium / High / Very High
Residual risk rating: {{RESIDUAL_RISK_RATING}}

Tolerance check:
- Risk appetite tier this risk falls into: {{APPETITE_TIER}}
- Within or outside the documented appetite: {{WITHIN_OR_OUTSIDE_APPETITE}}
- If outside appetite, executive escalation under Section 8 is required.

Residual risk narrative (one paragraph the approver could read aloud):
{{RESIDUAL_NARRATIVE}}

6. Rationale for acceptance

The decision and the reason. Auditors look for a coherent, fact-based rationale. Avoid one-line entries like "low risk" or "accepted by the business". The rationale must explain why remediation was not chosen now.

Treatments considered:
- Remediate: {{REMEDIATE_OPTION_AND_REASON_NOT_CHOSEN}}
- Mitigate further: {{MITIGATE_OPTION_AND_REASON_NOT_CHOSEN}}
- Transfer (insurance, contractual): {{TRANSFER_OPTION_AND_REASON_NOT_CHOSEN}}
- Accept (this form): selected

Cost of remediation versus residual risk:
- Estimated remediation effort: {{REMEDIATION_EFFORT}}
- Estimated remediation calendar time: {{REMEDIATION_CALENDAR_TIME}}
- Cost driver: {{COST_DRIVER}}

Stated rationale for acceptance:
{{ACCEPTANCE_RATIONALE}}

Future remediation plan (if any):
{{FUTURE_REMEDIATION_PLAN}}
Target remediation horizon: {{TARGET_REMEDIATION_DATE}}

7. Review cadence and cancellation triggers

Acceptance without a review date and trigger conditions becomes forever-deferral. Cap the review by severity. Auditors expect to see a hard expiry, not an open-ended acceptance.

Review cadence: {{REVIEW_CADENCE_BY_SEVERITY}}
- Suggested defaults: Critical residual every 30 days with a hard expiry of 90 days, High every 90 days with a hard expiry of 180 days, Medium every 180 days with a hard expiry of 12 months, Low every 365 days.

Next scheduled review: {{NEXT_REVIEW_DATE}}
Hard expiry: {{HARD_EXPIRY_DATE}}

Cancellation triggers (any of which invalidate this acceptance and require re-review):
- A compensating control in Section 4 lapses or fails.
- A new disclosed exploit, public PoC, or KEV listing for the underlying vulnerability is published.
- The affected asset enters a new regulatory scope (PCI DSS, HIPAA, NIS2, DORA, FedRAMP, CMMC, other).
- The data classification of the affected asset changes.
- The threat model for the system changes materially (new attacker class, new entry point, new shared infrastructure).
- The risk owner or security approver changes role and the new owner has not re-affirmed the acceptance.

8. Approvals

Pair the risk owner (accountable for the system or process) with the security approver (CISO, head of security, vCISO). For risk outside appetite, add the executive sponsor.

Risk owner (business or system owner accountable for residual risk):
Name: {{RISK_OWNER_NAME}}
Title: {{RISK_OWNER_TITLE}}
Department / business unit: {{RISK_OWNER_BU}}
Signature: ____________________________
Date: ________________________________

Security approver:
Name: {{SECURITY_APPROVER_NAME}}
Title: {{SECURITY_APPROVER_TITLE}}
Signature: ____________________________
Date: ________________________________

Executive sponsor (required for high or critical residual risk, or for any risk outside appetite):
Name: {{EXEC_SPONSOR_NAME}}
Title: {{EXEC_SPONSOR_TITLE}}
Signature: ____________________________
Date: ________________________________

9. Evidence and references

Attach everything a successor reviewer needs to reconstruct the decision without speaking to anyone who signed it.

Linked records:
- Original finding record: {{LINK_TO_FINDING}}
- Engagement record (pentest, scan, audit): {{LINK_TO_ENGAGEMENT}}
- Compensating control evidence: {{LINKS_TO_CONTROL_EVIDENCE}}
- Threat model or risk assessment: {{LINK_TO_THREAT_MODEL}}
- Vendor advisory or third-party reference: {{LINK_TO_VENDOR_ADVISORY}}
- Cost analysis or change request: {{LINK_TO_COST_ANALYSIS}}

Framework citations supporting this acceptance:
- ISO/IEC 27005 risk treatment: accept
- NIST SP 800-39 risk response: accept
- ISO/IEC 27001 Clause 6.1.3 risk treatment plan reference: {{ISO_27001_RTP_REFERENCE}}
- SOC 2 CC9.1 risk mitigation reference (if applicable): {{SOC2_REFERENCE}}
- PCI DSS compensating control worksheet (if applicable): {{PCI_DSS_CCW_REFERENCE}}

How to use this template

Confirm the underlying finding has a CVSS 3.1 vector, evidence, and remediation guidance recorded against it. The acceptance is the structured exception to the vulnerability remediation SLA you have agreed for that severity, not a substitute for the finding record.
Replace every {{PLACEHOLDER}} with the values for this specific risk. Avoid copy-paste rationale across multiple acceptances: each decision should stand on its own evidence.
Set the residual rating in Section 5 against the same likelihood-impact scale your risk register uses so this entry is comparable to the rest of the register, not floating in isolation.
Tie review cadence and a hard expiry to the residual severity. An acceptance with no end date becomes a forever-deferral that auditors penalise; review the aging pentest findings research for the cost of letting acceptances drift.
Pair the risk owner (accountable for the system or business process) with the security approver. For high or critical residual risk, or any risk outside the documented appetite, add an executive sponsor signature. A developer cannot accept a critical risk on behalf of a business owner who has never seen the finding.
Store the signed form against the original finding record in the same workspace your remediation tracking workflow runs in. Acceptance and remediation should report from one dashboard, not two.
Pair the acceptance form with a per-finding vulnerability remediation worksheet so the audit trail captures both the structured exception and the operating record of the finding it relates to. Acceptance is the outcome; the worksheet is the timeline.
Roll every approved acceptance into a programme-wide security exception register so leadership and audit can read the cumulative residual risk position at a glance. The form is the per-decision artefact; the register is the org-wide ledger.
Tie the residual position back to the parent ledger by linking the acceptance to its cybersecurity risk register entry. The risk register lists every identified risk with inherent and residual scores; this acceptance form is one of the inputs that explains why a register entry sits at its current residual rating.

Framework references

NIST SP 800-39 Managing Information Security Risk: organization, mission, and information system view (risk response: accept).
NIST SP 800-37 Risk Management Framework, authorising official decision making.
ISO/IEC 27005 Information security risk management, risk treatment options. See the SecPortal ISO 27001 framework page for how the risk treatment plan ties back to Annex A controls.
ISO/IEC 27001:2022 Clause 6.1.3 risk treatment plan and Clause 8.3 information security risk treatment.
SOC 2 Trust Services Criteria CC9.1 risk mitigation activities. See the SecPortal SOC 2 framework page for evidence expectations.
PCI DSS v4.0 compensating control worksheet (Appendix B) for the equivalent format inside the cardholder data environment. See the SecPortal PCI DSS framework page for context.
For severity-driven SLA design that this acceptance form sits inside, see the vulnerability remediation SLA calculator and the severity calibration research.
For findings management and CVSS scoring inside the acceptance record, see the SecPortal findings management feature and the CVSS scoring guide.

This template is provided as a starting point for documenting a risk acceptance decision. It is not legal advice and is not a substitute for your organisation's risk policy, internal audit procedures, or regulator-specific compensating control requirements. Have the final form reviewed against the policies and frameworks that govern your programme before it is signed.

Loading tool...

Related features

Vulnerability management software that tracks every finding

Orchestrate every security engagement from start to finish

Compliance tracking without a full GRC platform

Your brand. Your portal. Your clients love it.

Vulnerability acceptance and exception management

Remediation tracking

Cybersecurity risk assessment

Compliance audits

Pentest report delivery

Track acceptance against the original finding, not in a separate folder

SecPortal stores the acceptance form against the finding record so remediation, acceptance, and review dates report from one dashboard. Free plan available.

Get Started Free

No credit card required. Free plan available forever.

Risk Acceptance Form Templatedocument residual risk without losing the audit trail

Copy the full risk acceptance form

1. Acceptance reference and linked finding

2. Risk summary

3. Original severity and scoring

4. Compensating controls in place

5. Residual likelihood, impact, and rating

6. Rationale for acceptance

7. Review cadence and cancellation triggers

8. Approvals

9. Evidence and references

How to use this template

Framework references

Related features

Vulnerability management software that tracks every finding

Orchestrate every security engagement from start to finish

Compliance tracking without a full GRC platform

Your brand. Your portal. Your clients love it.

Vulnerability acceptance and exception management

Remediation tracking

Cybersecurity risk assessment

Compliance audits

Pentest report delivery

Track acceptance against the original finding, not in a separate folder

Copy the full risk acceptance form

1. Acceptance reference and linked finding

2. Risk summary

3. Original severity and scoring

4. Compensating controls in place

5. Residual likelihood, impact, and rating

6. Rationale for acceptance

7. Review cadence and cancellation triggers

8. Approvals

9. Evidence and references

How to use this template

Framework references

Risk Acceptance Form Template
document residual risk without losing the audit trail