DraftInternalISO 27001

SW-ISMS-FRM-010

Vulnerability Risk Acceptance Form

Version

1.0

Owner

CISO

Effective Date

2024-01-15

Review Date

2025-01-15

Vulnerability Risk Acceptance Form

Purpose

This form is used to formally document and approve the acceptance of identified security vulnerabilities that cannot be remediated immediately. Risk acceptance requires explicit approval from the risk owner and CISO, with defined compensating controls and acceptance period.

Instructions

  1. Security Team identifies vulnerability and completes Sections 1-3
  2. Risk Assessment conducted to determine actual risk level
  3. Compensating Controls identified and documented
  4. Risk Owner reviews and decides to accept or reject
  5. CISO reviews and approves/rejects risk acceptance
  6. Review risk acceptance at defined intervals or when circumstances change
  7. Remediate vulnerability as soon as feasible; risk acceptance is temporary

Important: Risk acceptance does not eliminate the risk; it acknowledges the residual risk while compensating controls are in place.


Section 1: Vulnerability Information

Field Information
Vulnerability ID (from vulnerability scanner or tracking system)
Request Date
Requested By
Department

Vulnerability Details

Field Information
Vulnerability Title
CVE ID (if applicable)
CWE ID (if applicable)
Discovery Date
Discovery Method ☐ Vulnerability Scan ☐ Penetration Test ☐ Security Audit ☐ Incident Investigation ☐ Vendor Advisory ☐ Other

Vulnerability Description:

[Provide clear description of the vulnerability]








Technical Details:

[Include technical details such as affected components, attack vectors, exploitation requirements]









Affected Systems and Assets

System/Asset Asset ID Environment Classification Criticality Exposure
☐ Prod ☐ Test ☐ Dev ☐ Public ☐ Internal ☐ Confidential ☐ Restricted ☐ Critical ☐ High ☐ Medium ☐ Low ☐ Internet-facing ☐ Internal ☐ Isolated
☐ Prod ☐ Test ☐ Dev ☐ Public ☐ Internal ☐ Confidential ☐ Restricted ☐ Critical ☐ High ☐ Medium ☐ Low ☐ Internet-facing ☐ Internal ☐ Isolated
☐ Prod ☐ Test ☐ Dev ☐ Public ☐ Internal ☐ Confidential ☐ Restricted ☐ Critical ☐ High ☐ Medium ☐ Low ☐ Internet-facing ☐ Internal ☐ Isolated

Total Number of Affected Systems: ___________


Section 2: Risk Assessment

Vulnerability Severity

Base Severity Rating (from scanner/CVE):

  • Critical (CVSS 9.0-10.0)
  • High (CVSS 7.0-8.9)
  • Medium (CVSS 4.0-6.9)
  • Low (CVSS 0.1-3.9)

CVSS Score: __________ (if available)

Vendor/Scanner Severity: __________


Exploitability Assessment

Exploit Available?

  • ☐ Yes - Publicly available exploit code
  • ☐ Yes - Exploit in the wild (active exploitation)
  • ☐ Proof of concept exists
  • ☐ No public exploit (theoretical)
  • ☐ Unknown

Attack Complexity:

  • ☐ Low - Easy to exploit, no special conditions
  • ☐ Medium - Some preconditions or complexity
  • ☐ High - Difficult to exploit, significant barriers

Privileges Required:

  • ☐ None - Unauthenticated attack
  • ☐ Low - Standard user privileges
  • ☐ High - Administrative privileges required

User Interaction Required:

  • ☐ None - No user interaction needed
  • ☐ Required - User must take action (e.g., click link)

Impact Assessment

If exploited, what is the potential impact?

Impact Type None Low Medium High Critical
Confidentiality
Integrity
Availability
Customer Impact
Financial Impact
Regulatory/Compliance
Reputational Impact

Estimated Financial Impact (if exploited): SEK ___________

Potential Data Exposure:

  • ☐ No data exposure
  • ☐ Internal data only
  • ☐ Customer personal data (GDPR applicable)
  • ☐ Sensitive business data
  • ☐ Authentication credentials
  • ☐ Other: _______________________

Number of potentially affected customers/users: ___________


Risk Calculation

Inherent Risk Level (before controls):

  • Critical (Likelihood: High, Impact: Critical/High)
  • High (Likelihood: Medium-High, Impact: High)
  • Medium (Likelihood: Medium, Impact: Medium)
  • Low (Likelihood: Low, Impact: Low-Medium)

Risk Score: __________ (Likelihood x Impact)


Section 3: Reason for Acceptance

Why Can't This Be Remediated Immediately?

Primary Reason for Risk Acceptance:

  • No patch available (vendor has not released fix)
    • Expected patch date: _______________________
  • Patch testing required (cannot apply to production without testing)
    • Expected completion date: _______________________
  • System constraints (patching would break critical functionality)
    • Details: _______________________
  • Business continuity (cannot afford downtime for patching)
    • Next maintenance window: _______________________
  • Legacy system (end of support, no patches available)
    • Planned replacement date: _______________________
  • Resource constraints (lack of staff/time/budget)
    • Expected availability: _______________________
  • Third-party dependency (requires vendor action)
    • Vendor response expected: _______________________
  • Incompatibility (patch incompatible with other systems)
    • Resolution plan: _______________________
  • Cost vs. benefit (remediation cost exceeds risk)
    • Justification: _______________________
  • Other: _______________________

Detailed Explanation:

[Provide comprehensive explanation of why the vulnerability cannot be remediated now]










Remediation Plan:

[What is the plan to eventually remediate this vulnerability?]






Expected Remediation Date: _______________


Section 4: Compensating Controls

Existing Security Controls

What controls are already in place that reduce the risk?

Control Type Control Description Effectiveness Evidence
☐ Network ☐ High ☐ Medium ☐ Low
☐ Access Control ☐ High ☐ Medium ☐ Low
☐ Monitoring ☐ High ☐ Medium ☐ Low
☐ Physical ☐ High ☐ Medium ☐ Low
☐ Other ☐ High ☐ Medium ☐ Low

Additional Compensating Controls

What additional controls will be implemented to mitigate this risk?

Compensating Control Implementation Date Responsible Party Verification Method Status
☐ Implemented ☐ Planned
☐ Implemented ☐ Planned
☐ Implemented ☐ Planned
☐ Implemented ☐ Planned

Examples of compensating controls:

  • Network segmentation/isolation
  • Web Application Firewall (WAF) rules
  • Intrusion Detection/Prevention rules
  • Additional access controls
  • Enhanced monitoring and alerting
  • Process controls (manual reviews, approvals)
  • Reduced functionality (disable vulnerable features)

Residual Risk Assessment

After compensating controls, what is the residual risk?

Residual Risk Level:

  • High (still significant risk despite controls)
  • Medium (risk reduced but not eliminated)
  • Low (risk substantially mitigated)

Residual Risk Score: __________ (Reduced Likelihood x Impact)

Is the residual risk acceptable?

  • ☐ Yes - Risk is acceptable with compensating controls
  • ☐ No - Additional controls or remediation required

Section 5: Risk Owner Approval

System/Asset Owner Review

Field Information
Risk Owner Name
Risk Owner Title
Department
Review Date

Risk Owner Assessment:

I confirm that:

  • ☐ I understand the vulnerability and its potential impact
  • ☐ I acknowledge the risk to my system/business area
  • ☐ I have reviewed the proposed compensating controls
  • ☐ I accept the residual risk for the specified period
  • ☐ I commit to implementing remediation per the plan

Decision:

  • Accept Risk - I accept the residual risk with compensating controls
  • Accept with Additional Controls (specify): _______________________
  • Do Not Accept - Require immediate remediation (explain): _______________________

Risk Owner Comments:

[Additional comments or conditions]




| Risk Owner Signature | | Date | |


Section 6: CISO Approval

CISO Security Review

Field Information
CISO Review Date

CISO Assessment:

Vulnerability severity appropriate? ☐ Yes ☐ No (adjust to: _______)

Compensating controls adequate? ☐ Yes ☐ No

Residual risk acceptable? ☐ Yes ☐ No

Acceptance period reasonable? ☐ Yes ☐ No

CISO Evaluation:

[CISO's assessment of the risk acceptance request, adequacy of compensating controls,
and any additional security concerns or requirements]









CISO Decision

  • Approved - Risk acceptance approved as requested
  • Approved with Conditions (specify below)
  • Approved with Reduced Period (maximum period: _______)
  • Not Approved - Require immediate remediation or additional controls

Conditions or Additional Requirements:

[Specify any conditions, additional controls, or requirements for approval]





Risk Acceptance Period

Acceptance Period: From __________ To __________

Maximum Duration: ☐ 30 days ☐ 60 days ☐ 90 days ☐ Other: _____ days

Review Frequency: ☐ Weekly ☐ Monthly ☐ Quarterly

Next Review Date: __________

Auto-Escalate if Not Remediated by: __________

| CISO Signature | | Date | |


Section 7: Monitoring and Review

Ongoing Monitoring

Monitoring Requirements:

  • ☐ Daily review of system logs
  • ☐ Weekly vulnerability scan
  • ☐ Real-time alerting for exploitation attempts
  • ☐ Monthly status report to CISO
  • ☐ Other: _______________________

Responsible for Monitoring: _______________________


Periodic Review Log

Review Date Reviewed By Status Still Acceptable? Next Review Notes
☐ Open ☐ Remediated ☐ Yes ☐ No
☐ Open ☐ Remediated ☐ Yes ☐ No
☐ Open ☐ Remediated ☐ Yes ☐ No

Status Updates

Date Update Updated By

Section 8: Remediation and Closure

Remediation

Field Information
Remediation Completed Date
Remediation Method ☐ Patch Applied ☐ System Upgraded ☐ Configuration Change ☐ System Replaced ☐ Other
Remediated By

Remediation Details:

[Describe how the vulnerability was ultimately remediated]




Verification:

  • ☐ Vulnerability no longer detected in scan
  • ☐ Patch/fix verified in production
  • ☐ Post-remediation testing completed
  • ☐ Compensating controls removed (if no longer needed)

Verified By: _______________________ Date: _______


Risk Acceptance Closure

Reason for Closure:

  • ☐ Vulnerability remediated
  • ☐ System decommissioned
  • ☐ Risk acceptance period expired (new acceptance required)
  • ☐ Risk no longer acceptable (escalated)
  • ☐ Vulnerability assessment changed (no longer valid)
  • ☐ Other: _______________________

| Closed By | | Closure Date | |


Document Control

Version Date Author Changes
1.0 Initial risk acceptance

Quick Reference - Risk Acceptance Guidelines

When is Risk Acceptance Appropriate?

Scenario Acceptable? Conditions
No patch available yet Yes Vendor committed to patch, compensating controls in place
Patch testing in progress Yes Testing timeline defined, limited duration (< 30 days)
Legacy system, EOL Maybe Replacement plan exists, strong compensating controls, limited duration
Internet-facing critical vulnerability Rarely Only if extraordinary circumstances, enhanced monitoring, limited duration
Internal low-risk vulnerability Yes Risk genuinely low, compensating controls adequate
Cost exceeds benefit Maybe Risk genuinely minimal, business justification strong
Resource constraints alone No Not acceptable reason without other factors

Maximum Acceptance Periods by Severity

Severity Maximum Acceptance Period Review Frequency
Critical 30 days (exceptional circumstances only) Weekly
High 60 days Bi-weekly
Medium 90 days Monthly
Low 180 days Quarterly

Required Compensating Controls by Exposure

Exposure Minimum Compensating Controls
Internet-facing Network controls (WAF, IPS), enhanced monitoring, 24/7 alerting
Internal production Network segmentation, access controls, monitoring
Development/test Network isolation, access controls
Isolated/offline Physical access controls, periodic inspection

Notes

[Additional notes or special circumstances]







Contact Information

For risk acceptance questions: