Skip to main content
Cyber Risk Council
Category: Security Policies & Standards

Policy Exception Process

Also known as: Security Policy Exception Process, Risk Exception Management, Information Security Exception Process, Policy, Standards, and Procedures Exceptions Process
Simply put

A policy exception process is a formal way for someone in an organization to request permission to not follow a specific security policy or standard when compliance is not practical. The request is reviewed, the associated risk is assessed, and a decision is documented, often with alternative safeguards put in place to reduce the risk. This keeps deviations visible and controlled rather than allowing people to quietly ignore the rules.

Formal definition

A policy exception process is the formal, documented workflow used to request, risk-assess, approve or deny, and track deviations from a published information security policy, standard, or procedure. In many implementations it defines how requests are submitted and what information is required (such as the justification and scope), designates approvers or an approval body, and requires that compensating controls be identified where the exception increases residual risk. Exception requests are commonly routed to or approved by the CISO or an equivalent governance authority and are typically time-bound and subject to periodic review. In the context of virtual or fractional CISO engagements, a vCISO often designs, advises on, or oversees this process and may participate in reviewing exceptions, but accountability for accepting the residual risk of an approved exception generally remains with the client organization and its officers unless a contract specifies otherwise. The value and rigor of the process depend heavily on organizational maturity, defined scope, and stakeholder cooperation.

Why it matters

Without a formal exception process, deviations from security policy tend to happen informally and invisibly. Teams under deadline pressure quietly skip a control, use an unapproved tool, or postpone a required configuration, and no one records the decision or the risk it introduces. A policy exception process replaces this silent drift with a documented workflow, so that when the organization cannot practically comply with a published policy or standard, the deviation is made visible, the associated risk is assessed, and a deliberate decision is recorded rather than assumed.

The process also supports governance and auditability. Because exception requests typically capture the justification, scope, and any compensating controls, an organization can demonstrate that it understands where it is not meeting its own standards and why. This matters when supporting readiness for frameworks and standards, since being able to show controlled, time-bound, and reviewed exceptions is generally viewed as more mature than either rigid non-compliance or unmanaged deviation. An exception process does not by itself guarantee compliance or certification, but it provides the traceability that reviewers and stakeholders often expect.

Critically, the process keeps accountability where it belongs. An approved exception represents accepted residual risk, and documenting who approved it and under what conditions clarifies that the organization made an informed choice. In virtual or fractional CISO engagements, a common mistake is to assume that because the vCISO designs or reviews the process, they also absorb the liability for approved exceptions. In practice, accountability for accepting residual risk generally remains with the client organization and its officers unless a contract specifies otherwise.

Who it's relevant to

Security and governance leaders
CISOs and equivalent governance authorities frequently serve as the approvers or approval body for exception requests. They rely on the process to keep deviations visible, to assess associated risk, and to ensure compensating controls are considered before residual risk is accepted.
Virtual and fractional CISOs
A vCISO often designs, advises on, or oversees the exception process and may participate in reviewing requests. It is important to clarify in the engagement scope that the vCISO advises and directs the process, while accountability for accepting the residual risk of an approved exception generally remains with the client organization and its officers unless a contract specifies otherwise.
Business and technical teams requesting exceptions
Staff who cannot practically comply with a published policy or standard use the process to submit a request, explain the justification and scope, and obtain a documented decision. The process depends on their cooperation, since its value collapses if teams bypass it and deviate informally instead.
Compliance, audit, and risk functions
These stakeholders use documented, time-bound, and reviewed exceptions to demonstrate that the organization understands where it is not meeting its own standards and why. This supports readiness for frameworks and standards, though an exception process alone does not assert compliance or certification.

Inside Policy Exception Process

Exception Request Submission
A formal mechanism through which a requester documents the specific policy or control they cannot meet, the business justification, and the systems or processes affected. In many engagements a virtual CISO helps design this intake step so requests are captured consistently rather than handled informally.
Risk Assessment and Analysis
An evaluation of the potential exposure created by not adhering to the policy, often considering likelihood, impact, and affected assets or data. A vCISO typically advises on how to assess this risk within a governance and business-risk context rather than performing hands-on technical remediation.
Compensating Controls
Alternative safeguards proposed to reduce the risk introduced by the exception when the original control cannot be applied. These are documented so the residual risk is understood and, where possible, mitigated.
Approval and Authorization
A defined set of approvers, often including business owners, risk owners, and executive leadership, who decide whether to accept the residual risk. A virtual CISO usually advises and directs on the criteria, but accountability for accepting the risk typically remains with the client organization and its officers.
Expiration and Review Date
A time limit after which the exception must be reassessed or expires, preventing exceptions from becoming permanent by default. Review cadence may vary by provider and organization.
Documentation and Recordkeeping
A maintained register of approved exceptions, their justifications, compensating controls, owners, and expiration dates, supporting governance and, where relevant, readiness for frameworks such as ISO 27001 or SOC 2. This supports audit readiness but does not by itself assert certification or compliance.

Common questions

Answers to the questions practitioners most commonly ask about Policy Exception Process.

Does a policy exception mean the security policy simply doesn't apply anymore?
No. A policy exception is a documented, time-bound authorization to deviate from a specific requirement under defined conditions, not a permanent waiver or a signal that the policy is optional. The underlying policy remains in force for everyone else and for the exception holder once the exception expires. A well-run process typically requires a stated business justification, an assessment of the added risk, compensating controls where feasible, an expiration or review date, and formal sign-off by an accountable party. Treating an exception as a blanket removal of the requirement is a common mistake that erodes the control environment over time.
If a virtual CISO approves an exception, does the vCISO take on the risk or liability for it?
Generally no. A virtual CISO often facilitates, advises on, or documents the risk associated with an exception, but legal and organizational accountability for accepting that risk typically remains with the client organization and its officers. In many engagements the vCISO recommends whether an exception is reasonable and what compensating controls to require, while the formal risk acceptance decision is made and signed by an authorized business owner or executive within the client. The specific decision rights and any delegated authority should be defined in the engagement scope; absent a contract stating otherwise, the vCISO advises rather than assumes liability.
Who should be authorized to approve a policy exception?
Approval authority is often tiered by risk level, though the specifics vary by organization. Lower-risk, short-term exceptions may be approved by a security manager or the risk owner, while higher-risk exceptions typically require executive or business-owner sign-off, and in some cases governance or risk committee review. A virtual CISO can help define this authorization matrix so that the person accepting the risk has both the authority and the business context to do so. The key principle is that whoever approves should be accountable for the consequences and independent enough to weigh the request objectively.
How should exceptions be tracked once they are approved?
Exceptions are typically recorded in a central register or risk tracking system that captures the requirement being excepted, the justification, the approving authority, any compensating controls, and an expiration or review date. Maintaining this inventory allows the organization to see cumulative risk, identify recurring gaps that may indicate a policy needs revision, and avoid exceptions that quietly become permanent. In many vCISO engagements, reviewing the exception register is part of periodic governance reporting to leadership so accepted risks stay visible to decision-makers.
How long should a policy exception remain valid?
Exceptions are generally time-bound rather than indefinite, with an expiration or scheduled review date tied to the business need or remediation timeline. The appropriate duration varies by the risk involved and the effort required to reach compliance; higher-risk exceptions often warrant shorter durations and more frequent review. When an exception nears expiration, the request should be re-evaluated rather than automatically renewed. Setting review dates prevents the accumulation of stale exceptions that no longer reflect current risk or business justification.
What role do compensating controls play in an exception request?
Compensating controls are alternative measures intended to reduce the added risk created when a requirement cannot be met as written. When evaluating an exception, it is common practice to ask whether a reasonable compensating control can partially offset the gap, for example, enhanced monitoring, restricted access, or additional review. A virtual CISO can help identify practical compensating controls and document how they mitigate the exposure. The value of this depends on the organization's maturity and its ability to actually implement and sustain the compensating measures rather than merely listing them on paper.

Common misconceptions

A policy exception process transfers accountability for the risk to the virtual CISO who reviews or advises on it.
A vCISO typically advises on and helps structure the process, but legal and organizational accountability for accepting a policy exception generally remains with the client organization and its officers unless a contract specifies otherwise.
Approving an exception makes the associated compliance or certification requirement no longer relevant.
An exception documents accepted residual risk; it does not remove a regulatory obligation. Frameworks and regulations such as PCI DSS, HIPAA, or ISO 27001 may still expect the underlying control, and a documented exception supports readiness and governance rather than guaranteeing compliance or certification.
Once granted, a policy exception is permanent.
Exceptions are typically time-bound and subject to periodic review or expiration so that they are revisited as risk conditions, technology, or business needs change.

Best practices

Require a documented business justification and a clear description of the affected policy or control for every exception request, rather than allowing informal or verbal approvals.
Assess and record the residual risk for each exception, and identify compensating controls where the original control cannot be met.
Define explicit approval authority so that the appropriate business, risk, and executive stakeholders accept the residual risk, keeping accountability with the client organization.
Assign an expiration or mandatory review date to each exception to prevent temporary deviations from becoming permanent by default.
Maintain a central exception register with owners, justifications, compensating controls, and review dates to support governance and audit readiness.
Engage relevant stakeholders and confirm access to decision-makers, since the value of the process depends on organizational maturity, cooperation, and clearly defined scope.