DraftInternalISO 27001

SW-ISMS-FRM-011

Vulnerability Exception Request Form

Version

1.0

Owner

CISO

Effective Date

2024-01-15

Review Date

2025-01-15

Vulnerability Exception Request Form

Purpose

This form is used to request a permanent or long-term exception from vulnerability remediation requirements. Unlike risk acceptance (temporary mitigation), an exception acknowledges that the vulnerability will not be remediated due to business, technical, or operational constraints.

Instructions

Requester completes Sections 1-4 with detailed business justification
Security Team reviews technical aspects and compensating controls
Business Owner approves business justification
CISO conducts risk assessment and approves/rejects
Management approves exceptions for Critical/High vulnerabilities
Review annually or when circumstances change
Reassess if new exploits emerge or business context changes

Important: Exceptions are for situations where remediation is truly not feasible. They require stronger compensating controls than temporary risk acceptances.

Section 1: Exception Request Information

Field	Information
Exception Request ID	(Auto-assigned)
Request Date
Requester Name
Requester Department
Contact Information	Email: __________ Phone: __________

Section 2: Vulnerability Information

Vulnerability Details

Field	Information
Vulnerability ID	(from vulnerability scanner)
Vulnerability Title
CVE ID (if applicable)
CWE ID (if applicable)
Discovery Date

Vulnerability Description:

[Clear description of the vulnerability]

Affected Systems

Environment	Criticality	Internet-Facing?
☐ Prod ☐ Test ☐ Dev	☐ Critical ☐ High ☐ Medium ☐ Low	☐ Yes ☐ No
☐ Prod ☐ Test ☐ Dev	☐ Critical ☐ High ☐ Medium ☐ Low	☐ Yes ☐ No
☐ Prod ☐ Test ☐ Dev	☐ Critical ☐ High ☐ Medium ☐ Low	☐ Yes ☐ No

Vulnerability Severity

Severity Rating:

☐ 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: __________ Exploitability: ☐ High ☐ Medium ☐ Low

Section 3: Justification for Exception

Why Exception is Required

Primary reason for requesting permanent exception:

☐ End-of-life system with no vendor support
- Replacement not feasible because: _______________________
☐ Business-critical application that will break if patched
- Impact of breakage: _______________________
☐ Legacy technology with no compatible patch
- Migration not possible because: _______________________
☐ Vendor no longer exists or doesn't support product
- Alternative solutions considered: _______________________
☐ Patch incompatibility with other required systems
- Incompatibility details: _______________________
☐ Technical impossibility (cannot be remediated)
- Technical barriers: _______________________
☐ Accepted design limitation (inherent to technology)
- Risk vs. benefit analysis: _______________________
☐ Regulatory or contractual constraint prevents remediation
- Constraint details: _______________________
☐ Cost of remediation significantly exceeds risk
- Cost-benefit analysis: _______________________
☐ Other: _______________________

Detailed Business Justification

Why is this system/vulnerability exception critical to business operations?

[Provide comprehensive business justification including:
- Business processes dependent on this system
- Impact of system replacement or downtime
- Why remediation is not feasible
- Alternatives considered and why they don't work]

Alternative Solutions Considered

What alternatives have been evaluated?

Alternative	Evaluated?	Why Not Viable?
Patch/update the system	☐ Yes ☐ No
Upgrade to supported version	☐ Yes ☐ No
Replace with alternative product	☐ Yes ☐ No
Virtualize/containerize	☐ Yes ☐ No
Cloud migration	☐ Yes ☐ No
Isolate system completely	☐ Yes ☐ No
Disable vulnerable functionality	☐ Yes ☐ No
Decommission system	☐ Yes ☐ No

Why none of the alternatives are feasible:

[Explain why each viable alternative cannot be implemented]

Future Remediation Plan

Is there a plan to eventually remediate or retire this system?

☐ Yes (describe below)
☐ No - system will remain indefinitely

If Yes, what is the plan?

[Describe the plan to eventually eliminate this exception]

Target completion date: _______________

Budget allocated? ☐ Yes: SEK __________ ☐ No ☐ Pending

Section 4: Risk Assessment

Threat and Impact Analysis

Likelihood of exploitation:

☐ High - Exploit publicly available, active exploitation in the wild
☐ Medium - Exploit exists or proof-of-concept available
☐ Low - Theoretical vulnerability, no known exploit

Impact if exploited:

Impact Category	None	Low	Medium	High	Critical
Confidentiality	☐	☐	☐	☐	☐
Integrity	☐	☐	☐	☐	☐
Availability	☐	☐	☐	☐	☐
Customer Impact	☐	☐	☐	☐	☐
Financial Impact	☐	☐	☐	☐	☐
Compliance Impact	☐	☐	☐	☐	☐
Reputation Impact	☐	☐	☐	☐	☐

Estimated financial impact if exploited: SEK ___________

Number of customers/users potentially affected: ___________

Inherent Risk

Inherent Risk Level (without compensating controls):

☐ Critical
☐ High
☐ Medium
☐ Low

Inherent Risk Score: __________ (Likelihood x Impact)

Section 5: Compensating Controls

Existing Controls

Current security controls in place:

Control Category	Control Description	Effectiveness	Evidence/Location
☐ Network Controls		☐ High ☐ Med ☐ Low
☐ Access Controls		☐ High ☐ Med ☐ Low
☐ Monitoring/Logging		☐ High ☐ Med ☐ Low
☐ Physical Security		☐ High ☐ Med ☐ Low
☐ Process Controls		☐ High ☐ Med ☐ Low

Additional Compensating Controls

What additional controls will be implemented specifically for this exception?

Compensating Control	Implementation Date	Owner	Verification	Status
				☐ Implemented ☐ Planned
				☐ Implemented ☐ Planned
				☐ Implemented ☐ Planned
				☐ Implemented ☐ Planned

Minimum required compensating controls for exceptions:

Network isolation/segmentation
Strict access controls (principle of least privilege)
Enhanced monitoring and alerting
Regular security assessments
Intrusion detection/prevention
Application-layer protection (WAF, etc.)
Incident response plan specific to this system

Residual Risk

After all compensating controls, what is the residual risk?

Residual Risk Level:

☐ High (significant risk remains)
☐ Medium (risk reduced but notable)
☐ Low (risk substantially mitigated)

Residual Risk Score: __________ (Reduced Likelihood x Impact)

Is residual risk within acceptable limits?

☐ Yes
☐ No (requires additional controls or escalation)

Section 6: Ongoing Management

Monitoring Requirements

How will this exception be monitored?

☐ Continuous security monitoring
☐ Real-time alerting for anomalies
☐ Daily log review
☐ Weekly vulnerability scan
☐ Monthly penetration testing
☐ Quarterly security assessment
☐ Other: _______________________

Responsible for monitoring: _______________________

Review Schedule

Exception review frequency:

☐ Monthly (for Critical vulnerabilities)
☐ Quarterly (for High vulnerabilities)
☐ Semi-annually (for Medium vulnerabilities)
☐ Annually (for Low vulnerabilities)

Next review date: _______________

Escalation Criteria

Exception will be immediately escalated if:

☐ Active exploitation detected
☐ New exploit published
☐ Compensating control fails
☐ Business context changes
☐ Regulatory requirement changes
☐ Customer/audit concern raised
☐ Other: _______________________

Section 7: Business Owner Approval

Business Owner Review

Field	Information
Business Owner Name
Business Owner Title
Department
Review Date

Business Owner Certification:

I certify that:

☐ I am accountable for this business system/process
☐ I understand the vulnerability and associated risk
☐ Remediation is not feasible for the reasons stated
☐ The business justification is accurate and complete
☐ I accept the residual risk to my business area
☐ I commit to maintaining compensating controls
☐ I will support future remediation efforts

Decision:

☐ Approve - Request exception with proposed controls
☐ Approve with Additional Controls (specify): _______________________
☐ Do Not Approve - Require remediation

Business Owner Comments:

[Additional comments or conditions]

Section 8: CISO Review and Approval

CISO Security Assessment

Field	Information
CISO Review Date

CISO Evaluation:

Business justification valid? ☐ Yes ☐ No ☐ Partially

Alternatives adequately explored? ☐ Yes ☐ No

Compensating controls sufficient? ☐ Yes ☐ No ☐ Additional required

Residual risk acceptable? ☐ Yes ☐ No

Monitoring plan adequate? ☐ Yes ☐ No

CISO Assessment:

[CISO's comprehensive assessment including:
- Validation of business justification
- Adequacy of compensating controls
- Residual risk acceptability
- Recommendations or concerns]

CISO Decision

☐ Approved - Exception granted as requested
☐ Approved with Conditions (specify below)
☐ Approved - Temporary (time limit: _______)
☐ Not Approved - Remediation required
☐ Escalate to Management - Risk too high for CISO to approve alone

Conditions or Requirements:

[Specify any conditions, additional controls, or limitations]

Exception Period

Exception Valid: From __________ To __________

Exception Type:

☐ Permanent (until system retired or context changes)
☐ Long-term (valid for _____ years, then reassess)
☐ Time-limited (valid until specific date/event)

Expiration Trigger:

☐ Time-based (specific date)
☐ Event-based (system replacement, vendor support resumed, etc.)
☐ Condition-based (when specific condition is met)

Section 9: Management Approval (Critical/High Only)

Required for Critical and High severity vulnerabilities

Executive Management Review

Field	Information
Approver Name	(CEO, CTO, or CFO)
Approver Title
Review Date

Management Decision:

☐ Approved - Exception granted
☐ Not Approved - Require remediation or additional risk treatment

Management Comments:

[Executive perspective on risk acceptance]

Section 10: Exception Monitoring and Review

Ongoing Review Log

Review Date	Reviewer	Status	Changes Required?	Next Review	Notes
		☐ Active ☐ Remediated ☐ Expired	☐ Yes ☐ No
		☐ Active ☐ Remediated ☐ Expired	☐ Yes ☐ No
		☐ Active ☐ Remediated ☐ Expired	☐ Yes ☐ No
		☐ Active ☐ Remediated ☐ Expired	☐ Yes ☐ No

Status Updates and Events

Date	Event Type	Description	Action Taken
	☐ New exploit ☐ Control change ☐ Review ☐ Other
	☐ New exploit ☐ Control change ☐ Review ☐ Other
	☐ New exploit ☐ Control change ☐ Review ☐ Other

Section 11: Exception Closure

Closure Information

Field	Information
Closure Date
Closed By

Reason for Closure:

☐ Vulnerability remediated
☐ System decommissioned/retired
☐ Exception period expired
☐ Risk no longer acceptable (exception revoked)
☐ Business justification no longer valid
☐ Other: _______________________

Closure Details:

[How was the exception ultimately resolved?]

Document Control

Version	Date	Author	Changes
1.0			Initial exception request

Quick Reference - Exception vs. Risk Acceptance

Factor	Risk Acceptance	Exception
Duration	Temporary (30-180 days)	Long-term or permanent
Purpose	Bridge until remediation	Acknowledge remediation not feasible
Approval	Risk Owner + CISO	Business Owner + CISO + Management (for Critical/High)
Controls	Compensating controls	Strong compensating controls required
Review	Weekly to monthly	Monthly to quarterly
Use When	Patch testing, temporary constraints	EOL systems, technical impossibility

Quick Reference - Approval Requirements

Vulnerability Severity	Approvers Required	Maximum Exception Period	Review Frequency
Critical	Business Owner + CISO + Management	1 year (renewable)	Monthly
High	Business Owner + CISO + Management	2 years (renewable)	Quarterly
Medium	Business Owner + CISO	3 years (renewable)	Semi-annually
Low	Business Owner + CISO	Until remediated or retired	Annually

Notes

[Additional notes or special circumstances]

Contact Information

For exception requests:

CISO: [Contact details]
Vulnerability Management: vulnerability@swedwise.se
Risk Management: [Contact details]