Information Security Exception Register

1. Purpose

The Information Security Exception Register provides a controlled method for recording, assessing, approving, monitoring, and closing temporary or justified deviations from information-security requirements.

An exception may arise when the organization cannot fully meet an approved:

Information-security policy
Standard
Procedure
Control requirement
Contractual requirement
Customer security requirement
Technical security standard
Legal or regulatory requirement, where legally permissible

The objective is to ensure that exceptions are visible, risk-assessed, formally approved, time-bound, monitored, and ultimately resolved or formally accepted.

Core Principle

Identify → Justify → Assess Risk → Define Compensating Controls → Approve → Monitor → Review → Close

2. When to Use

Create an exception record when:

A security requirement cannot currently be implemented
A control cannot operate as designed
A temporary deviation is required
A legacy system cannot immediately meet a security standard
A business requirement conflicts with an existing security control
A customer requirement cannot be fully met
A supplier or third party requires a documented deviation
Emergency circumstances require temporary bypass of a control
A technical limitation prevents immediate compliance

An exception should not be used simply to avoid implementing a required security control.

3. Exception Register

Exception ID	Date Raised	Area	Requirement	Exception Description	Risk	Compensating Control	Owner	Approver	Expiry Date	Status

Status Options

☐ Draft
☐ Under Assessment
☐ Approval Pending
☐ Approved
☐ Approved with Conditions
☐ Rejected
☐ Expired
☐ Extended
☐ Closed
☐ Converted to Risk Acceptance

4. Exception Information

Exception ID: ______________________________

Date Raised: ______________________________

Requested By: ______________________________

Business Owner: ______________________________

Security Owner: ______________________________

Department: ______________________________

System / Service: ______________________________

Asset / Application: ______________________________

Supplier / Third Party: ______________________________

5. Requirement Being Exceptioned

Identify the exact requirement from which the organization is requesting an exception.

Policy: ______________________________________

Standard: ____________________________________

Procedure: ___________________________________

Control: ______________________________________

Contractual Requirement: ______________________

Customer Requirement: _________________________

Regulatory Requirement: _______________________

Other Requirement: ____________________________

Requirement

6. Exception Description

Describe exactly what requirement cannot currently be met.

Include:

What should normally happen
What is currently happening
What requirement is not being met
Why the deviation exists
Which systems, information, users, or processes are affected

Description

7. Business Justification

Explain why the exception is required.

Possible reasons include:

Technical limitation
Legacy system
Business continuity requirement
Customer requirement
Implementation dependency
Supplier limitation
Temporary migration
Emergency situation
Cost/business constraint
System replacement planned
Control redesign in progress

Business Justification

8. Scope of Exception

Define exactly what the exception covers.

Systems

Applications

Users / Roles

Locations

Information

Environments

☐ Development
☐ Test
☐ Staging
☐ Production
☐ Corporate
☐ Cloud
☐ Other: __________________

Geographic Scope

9. Exception Duration

Start Date: __________________

Requested Expiry Date: __________________

Maximum Approved Duration: __________________

Is the Exception Temporary?

☐ Yes
☐ No
☐ To be determined

If permanent deviation is being requested, document why the requirement cannot reasonably be implemented and whether formal risk acceptance or control redesign is more appropriate.

10. Risk Assessment

Assess the risk introduced by the exception.

Confidentiality

☐ Low
☐ Medium
☐ High
☐ Critical

Integrity

☐ Low
☐ Medium
☐ High
☐ Critical

Availability

☐ Low
☐ Medium
☐ High
☐ Critical

Privacy

☐ Low
☐ Medium
☐ High
☐ Critical
☐ Not Applicable

Business Impact

☐ Low
☐ Medium
☐ High
☐ Critical

11. Risk Description

Describe the security risk created by the exception.

Consider:

Threats
Vulnerabilities
Assets
Information
Users
Attack paths
Business impact
Regulatory impact
Customer impact
Operational impact

Risk Statement

Example

Because MFA cannot currently be enabled for the legacy administration interface, an attacker obtaining administrator credentials could gain unauthorized access to the system, potentially affecting confidentiality and integrity.

12. Risk Rating

Use the organization’s approved risk methodology.

Factor	Rating
Likelihood
Impact
Inherent Risk
Existing Controls
Residual Risk

Risk Level

☐ Low
☐ Medium
☐ High
☐ Critical

13. Existing Controls

Identify controls that already reduce the risk.

☐ Network restriction
☐ Firewall
☐ VPN
☐ IP allowlisting
☐ Strong password
☐ Privileged access restriction
☐ Logging
☐ Monitoring
☐ Manual review
☐ Encryption
☐ Endpoint security
☐ Backup
☐ Segregation of duties
☐ Security awareness
☐ Other: __________________

Existing Control Description

14. Compensating Controls

Where the required control cannot be implemented, define alternative controls that reduce the risk.

Examples:

Restrict access to approved IP addresses
Require VPN access
Reduce the number of authorized users
Enable additional monitoring
Perform manual reviews
Increase logging
Restrict the affected environment
Limit access to business hours
Require additional approval
Increase security testing
Use temporary credentials
Apply additional network segmentation

Compensating Controls

Control	Description	Owner	Frequency	Evidence

15. Control Effectiveness

Evaluate whether the compensating controls adequately reduce the risk.

Control	Implemented	Operating	Evidence Available	Effective

Effectiveness Assessment

16. Alternative Solutions

Document alternatives considered before requesting the exception.

Alternative	Considered	Reason Not Selected

The organization should demonstrate that the exception is not simply being used because implementing the required control was inconvenient.

17. Remediation Plan

Where possible, the exception should have a plan to eliminate the underlying condition.

Action	Owner	Target Date	Dependency	Status	Evidence

Remediation Objective

18. Exception Conditions

Approval may be subject to specific conditions.

Examples:

Additional monitoring required
Weekly access review required
Exception limited to production system X
No additional users may be added
MFA must be implemented by the expiry date
Security testing required
Management review required
Customer approval required

Conditions

19. Approval

The exception must be approved by an appropriate authority based on the organization’s risk-acceptance process.

Business Owner

Name: ______________________________

Role: ______________________________

Decision: __________________________

Date: ______________________________

Information Security

Name: ______________________________

Role: ______________________________

Decision: __________________________

Date: ______________________________

Risk Owner

Name: ______________________________

Role: ______________________________

Decision: __________________________

Date: ______________________________

Senior Management Approval

Name: ______________________________

Role: ______________________________

Decision: __________________________

Date: ______________________________

20. Approval Decision

☐ Approved
☐ Approved with Conditions
☐ Rejected
☐ Additional Assessment Required
☐ Risk Acceptance Required
☐ Remediation Required Before Approval

Approval Rationale

21. Risk Acceptance

If the residual risk remains outside the normal tolerance level, formal risk acceptance may be required.

Residual Risk: __________________________

Risk Owner: _____________________________

Risk Acceptance Authority: _______________

Acceptance Date: ________________________

Acceptance Expiry: ______________________

Acceptance Statement

Risk acceptance should follow the organization’s defined risk-acceptance authority and methodology.

22. Security Exceptions and Legal/Regulatory Requirements

Special care is required where the exception relates to:

Legal requirements
Regulatory requirements
Privacy obligations
Customer contractual requirements
Security certification requirements
Industry obligations

An internal exception should not automatically be treated as permission to disregard a mandatory legal or regulatory obligation.

Applicability Assessment

☐ No legal/regulatory impact
☐ Legal review required
☐ Regulatory review required
☐ Customer approval required
☐ Contractual review required

Assessment

23. Customer or Contractual Approval

Where the requirement originates from a customer or contract:

Customer: ______________________________

Contract: _______________________________

Requirement: ____________________________

Customer Notification Required: ☐ Yes ☐ No

Customer Approval Required: ☐ Yes ☐ No

Approval Evidence: ______________________

24. Supplier / Third-Party Exceptions

If the exception relates to a supplier:

☐ Supplier identified
☐ Supplier risk assessed
☐ Supplier justification obtained
☐ Compensating controls identified
☐ Contract reviewed
☐ Customer impact assessed
☐ Supplier owner approval obtained
☐ Security approval obtained
☐ Expiry date defined

Supplier Exception Details

25. Emergency Exceptions

Emergency circumstances may require temporary bypass of a security control.

Examples:

Major security incident
Critical service outage
Disaster recovery
Emergency system recovery
Active cyberattack
Critical vulnerability remediation

Emergency exceptions should still be:

Authorized
Time-limited
Logged
Monitored
Reviewed after the emergency

Emergency Exception

Reason: _________________________________

Control Bypassed: _______________________

Authorized By: __________________________

Start Time: ______________________________

Expiry Time: _____________________________

Post-Event Review Required: ☐ Yes ☐ No

26. Exception Monitoring

Approved exceptions should be monitored throughout their validity period.

Review:

☐ Exception remains necessary
☐ Scope has not expanded
☐ Risk has not increased
☐ Compensating controls remain effective
☐ Conditions are being followed
☐ Remediation is progressing
☐ No relevant incidents occurred
☐ Expiry date remains appropriate

Monitoring Record

Review Date	Reviewer	Risk Status	Controls Effective	Action Required

27. Exception Review Triggers

Review the exception before its normal expiry if:

☐ System changes
☐ Business process changes
☐ New information is introduced
☐ New users are added
☐ Privileged access changes
☐ New vulnerabilities are identified
☐ Security incident occurs
☐ Customer requirements change
☐ Regulatory requirements change
☐ Supplier changes
☐ Compensating controls fail
☐ Risk increases
☐ Major technology change occurs

28. Exception Extension

An exception should not automatically continue indefinitely.

If an extension is required:

Original Expiry: __________________

New Expiry: ________________________

Reason for Extension: ______________

Updated Risk Assessment: ☐ Completed

Updated Remediation Plan: ☐ Completed

Approval Required: ☐ Yes

Extension Approval

Approver: __________________________

Date: ______________________________

Comments: __________________________

Repeated extensions should trigger management review to determine whether the underlying security requirement needs to be permanently addressed.

29. Exception Expiry

Before the expiry date:

☐ Requirement implemented
☐ Compensating control no longer required
☐ Exception closed
☐ Risk reassessed
☐ Evidence collected
☐ Access/control restored
☐ Policy/standard updated if required
☐ Register updated

Expiry Action

30. Exception Closure

An exception may be closed when:

The original requirement has been implemented
The affected system has been retired
The process has been redesigned
The risk has been eliminated
The approved exception is no longer required
The compensating control has been replaced by the required control

Closure Evidence

Closure Date

Closed By

31. Exception Conversion to Risk Acceptance

If the organization determines that the underlying requirement cannot reasonably be implemented, consider whether the matter should be formally handled through the organization’s risk-management process rather than repeatedly extending the exception.

Assessment

☐ Requirement can be implemented
☐ Requirement will be implemented later
☐ Permanent alternative control required
☐ Risk acceptance required
☐ Control redesign required
☐ Requirement no longer applicable

Decision

32. Exception Findings

Where monitoring identifies problems:

Finding ID	Exception ID	Finding	Risk	Action	Owner	Due Date	Status

33. Exception Incidents

If a security incident occurs while an exception is active:

Incident ID: ______________________________

Exception ID: _____________________________

Incident Date: _____________________________

Relationship to Exception: _________________

Risk Reassessment Required: ☐ Yes ☐ No

Exception Review Required: ☐ Yes ☐ No

Assessment

34. Exception Metrics

Track exception trends.

Key Metrics

Total active exceptions
New exceptions
Closed exceptions
Expired exceptions
Extended exceptions
Overdue exceptions
High-risk exceptions
Critical exceptions
Exceptions without compensating controls
Exceptions past original expiry
Exceptions related to production
Exceptions related to privileged access
Exceptions related to customer data
Recurring exceptions

Monthly Dashboard

Metric	Current	Previous	Trend
Active Exceptions
High/Critical
Expiring Soon
Overdue
Extended
Closed

35. Exception Aging

Monitor how long exceptions remain open.

Aging	Number
0–30 days
31–60 days
61–90 days
91–180 days
>180 days

Long-running exceptions should receive additional management attention.

36. Exception Trend Analysis

Review recurring patterns.

Consider:

Same control repeatedly exceptioned
Same business unit repeatedly requesting exceptions
Same technology limitation
Repeated legacy-system exceptions
Repeated access exceptions
Repeated supplier exceptions
Repeated policy deviations

Trend Analysis

Improvement Action

37. Management Review

Exception information may be included in management review where relevant.

Management should understand:

Significant security exceptions
High/critical residual risks
Long-running exceptions
Repeated exceptions
Expired exceptions
Exceptions affecting critical systems
Exceptions affecting customer information
Exceptions related to regulatory requirements
Exceptions indicating systemic control weaknesses

Management Review Input

38. Roles and Responsibilities

Role	Responsibility
Requester	Identifies and documents the exception
Business Owner	Provides business justification
Information Security	Assesses security risk and controls
Risk Owner	Owns residual risk
Control Owner	Defines implementation/remediation
Legal/Privacy	Reviews legal, contractual, or privacy implications where applicable
Approver	Approves or rejects the exception
Internal Audit	Independently evaluates exception governance where applicable
Management	Reviews significant or recurring exceptions

39. Exception Evidence

Retain appropriate evidence such as:

☐ Exception request
☐ Requirement being exceptioned
☐ Business justification
☐ Risk assessment
☐ Compensating controls
☐ Security review
☐ Legal/privacy review where applicable
☐ Customer approval where applicable
☐ Risk acceptance
☐ Approval
☐ Monitoring records
☐ Remediation evidence
☐ Extension approval
☐ Closure evidence

Do not store passwords, API keys, private keys, tokens, or other secrets in the exception register.

40. Exception Register – Detailed Record

Exception Record

Exception ID: ______________________________

Requirement: _______________________________

Description: ________________________________

Business Justification: ______________________

Affected Asset/System: _______________________

Information Classification: __________________

Risk: ______________________________________

Likelihood: _________________________________

Impact: ____________________________________

Residual Risk: ______________________________

Existing Controls: ___________________________

Compensating Controls: ______________________

Remediation Plan: ___________________________

Owner: _____________________________________

Approver: __________________________________

Start Date: _________________________________

Expiry Date: _______________________________

Review Frequency: __________________________

Conditions: _________________________________

Risk Acceptance: ____________________________

Status: _____________________________________

Closure Date: _______________________________

Closure Evidence: ___________________________

41. AWS SaaS Startup Example

Scenario

An AWS-based SaaS startup has a legacy internal administration application that does not currently support MFA.

The organization’s security standard requires MFA for privileged access.

Exception

Requirement: MFA for privileged access

Affected System: Legacy administration application

Business Justification: Application replacement is already planned but cannot be completed immediately.

Risk: Compromise of administrator credentials could result in unauthorized administrative access.

Compensating Controls

Access restricted through corporate VPN
Access limited to approved administrator IP addresses
Only two named administrators permitted
Strong unique passwords
Additional authentication at the VPN layer
Administrative activity logged
Weekly access review
Application replacement tracked as corrective action

Expiry

The exception expires when:

The legacy application is replaced or MFA is implemented.

Audit Trail

Requirement → Exception Request → Business Justification → Risk Assessment → Compensating Controls → Approval → Monitoring → Remediation → MFA Implementation → Evidence → Closure

42. Startup-Friendly Exception Model

A startup does not need a complicated exception bureaucracy.

Low-Risk Exception

Require:

Requirement
Reason
Scope
Basic risk assessment
Compensating control
Owner
Expiry
Approval

Medium-Risk Exception

Add:

Detailed risk assessment
Security review
Evidence
Monitoring
Remediation plan

High/Critical Exception

Add:

Formal risk assessment
Security leadership review
Business owner
Risk owner
Compensating controls
Formal risk acceptance where required
Senior management approval
Frequent monitoring
Defined remediation
Short validity period

43. Common Mistakes

Avoid:

Allowing exceptions without expiry dates
Treating exceptions as permanent approvals
Approving exceptions without risk assessment
Using exceptions to bypass legal requirements
Failing to define compensating controls
Allowing unlimited scope
Allowing automatic renewals
Ignoring repeated extensions
Failing to assign an owner
Failing to document risk acceptance
Closing exceptions without evidence
Keeping expired exceptions active
Failing to monitor high-risk exceptions
Storing credentials in the register
Treating business justification as a substitute for risk assessment

44. Relationship With Other ISMS Documents

Document	Relationship
Information Security Policy	Defines security requirements
Security Standards	Define expected security controls
Risk Assessment	Determines security risks
Risk Treatment Plan	Defines risk treatment
Statement of Applicability	Records applicable controls and justification
Risk Register	Records significant risks
Corrective Action Tracker	Tracks remediation
Security Findings Register	Records control weaknesses
Access Review	Identifies access-related exceptions
Supplier Security Review	Identifies supplier exceptions
Incident Management	Handles incidents involving exceptions
Change Management	Controls security-related changes
Internal Audit	Tests exception governance and effectiveness
Management Review	Reviews significant security issues
ISMS Improvement Log	Records systemic improvement opportunities

45. ISO/IEC 27001 Connection

An exception register supports the organization’s risk-based ISMS by providing evidence that deviations from defined requirements are:

Identified
Assessed
Controlled
Approved
Monitored
Reviewed
Corrected or formally accepted

An Information Security Exception Register is not itself a universally prescribed ISO/IEC 27001 form.

The organization should determine how exceptions are governed based on:

ISMS scope
Information-security risks
Applicable controls
Business requirements
Legal and regulatory requirements
Customer requirements
Contractual obligations
Security policies and standards
Risk acceptance criteria

An exception should also not be confused with the justification for excluding an Annex A control from the Statement of Applicability. The SoA and organizational exception/risk processes serve different purposes.

46. Audit Evidence Checklist

For sampled exceptions, an auditor should be able to find:

☐ Defined requirement
☐ Documented deviation
☐ Business justification
☐ Defined scope
☐ Risk assessment
☐ Existing controls
☐ Compensating controls
☐ Residual risk
☐ Risk owner
☐ Approval
☐ Expiry date
☐ Monitoring evidence
☐ Remediation plan
☐ Extension evidence if applicable
☐ Closure evidence
☐ Evidence of effectiveness where applicable

47. Final Exception Audit Trail

For every significant exception, the organization should be able to demonstrate:

What requirement are we not meeting?
Why can we not meet it?
What systems, information, or processes are affected?
What risk does the exception create?
What controls already exist?
What compensating controls are in place?
Who owns the risk?
Who approved the exception?
When does the exception expire?
How is the exception being monitored?
What is the remediation plan?
What evidence shows that the exception has been resolved?

Final Principle

An information-security exception is not permission to ignore a security requirement. It is a controlled, documented, risk-based deviation with an accountable owner, defined safeguards, approval, monitoring, and an expiry or formal risk-acceptance path.