Policy Governance · 13 min read
Policy Exceptions: How to Request, Approve and Record an Exception to Policy
A policy exception is an approved, documented and time-limited departure from a company policy for a specific person, team or situation, and a policy exception process is the short routine that decides who may grant one, for how long and on what conditions. Every growing company makes exceptions, whether or not it calls them that, and the difference between a well-run policy program and a fragile one is usually whether those exceptions are written down. This guide is part of our series on policy governance, and it covers how to request, assess, approve, record and close exceptions without letting them turn into unwritten rules.
Key takeaways
- An exception is approved in advance, narrow in scope and ends on a date, while a violation is a departure nobody approved.
- The approver should match the risk rather than the seniority of the person asking, and should never be the person asking.
- One register entry per exception, with the reason, the compensating steps and an expiry date, is the record auditors look for.
- When the same exception keeps coming back, the policy needs to change, and the change should go through approval and acknowledgment like any other version.
What a policy exception is, and what it isn’t
Policies are written for the normal case, and sooner or later a real case doesn’t fit: a contractor needs access before their company laptop arrives, a site can’t run a quarterly drill during a refit, or a sales team needs a contract clause the template doesn’t allow. An exception is the decision to let that case depart from the policy, made by someone with the authority to make it and written down so it can be checked and closed.
The word gets used loosely, so it helps to separate it from the terms it is often confused with.
| Term | What it means | How it is handled |
|---|---|---|
| Policy exception | An approved, documented and time-limited departure from a policy for a specific case | Requested in advance, decided by the right person, recorded and closed on a date |
| Policy violation | A departure nobody approved | Investigated and dealt with under the relevant policy, and sometimes the trigger for an exception request after the fact |
| Waiver | Often used to mean the same as an exception, though some companies keep it for permanent relief from a requirement | If you use both words, define each in your policy on policies |
| Policy change | A new version of the policy that applies to everyone in scope | Approved like any other version and sent out for acknowledgment |
| Risk acceptance | A decision to live with a known risk rather than reduce it | Often recorded alongside an exception when the departure leaves risk that can’t be fully offset |
The distinction matters because each one is handled differently, and a company that treats every departure as an informal favor ends up unable to tell an approved exception from a quiet violation when an auditor or an investigator asks.
Why a growing company needs an exception process
In a company of 20 people, exceptions are agreed in a hallway and everyone remembers them. By 80 or 150 people the person who agreed the exception has often moved on, the person who received it has changed roles, and nobody can say whether the arrangement was ever approved or when it was meant to end, and three problems follow from that.
Exceptions become the rule. A temporary arrangement that nobody closes becomes the way things are done, and the written policy stops describing reality without anyone deciding that it should.
Audits find them first. Auditors and customers sample practice against policy, and an undocumented departure looks exactly like a control failure, even when someone senior agreed to it for a good reason.
The policy never improves. Repeated requests for the same exception are the clearest signal that a policy is out of step with the business, but only if someone is counting them.
Control frameworks expect a process for this. The Cloud Security Alliance’s Cloud Controls Matrix includes a control that asks organizations to set up and follow an approved exception process whenever someone departs from an established policy, NIST’s security control catalog asks for departures from established configuration settings to be identified, documented and approved, and PCI DSS sets out how compensating controls must be documented when a requirement can’t be met as written.
Sources: Cloud Security Alliance, Cloud Controls Matrix v4.0, GRC-04, NIST SP 800-53 Rev. 5, CM-6, PCI DSS v4.0, Appendix B
The policy exception process, step by step
A workable process fits on one page and has six steps, and the same six steps work whether the exception is about laptops, expenses, safety drills or contract terms.
1. Request in writing, before the departure. The request names the policy and the exact clause, who and what it covers, why the policy can’t be followed, and how long the exception is needed. A request after the fact can still be recorded, but it should be labelled as a retrospective decision so the register stays honest.
2. Assess the risk. The policy owner, or whoever the process names, looks at what could go wrong, how likely it is and how much harm it could do, and at what could be done instead to meet the purpose of the policy, such as limiting access, adding a check or shortening the period.
3. Decide at the right level. The decision can be to approve, to approve something narrower, or to decline, and it is made by someone whose authority matches the risk, as the next section shows.
4. Record it. Every decision, including the declined ones, goes into the exception register with the reason, so the company can show later what it allowed, what it refused and why.
5. Watch it while it is open. Someone is named to check that the compensating steps are actually happening, because an exception approved on conditions that nobody checks is not much better than no process at all.
6. Close or renew it. On the end date the exception closes, or the requester comes back through step 1 with a fresh request and a fresh decision, which stops renewals from happening by default.
Who should approve a policy exception
The most common mistake is letting the approver follow the seniority of the person asking, so that a director’s request is approved by the director’s manager whatever the risk. A better rule ties the approver to the size of the risk, and keeps the requester and the approver as different people.
The policy owner is usually the right first reviewer, because they know why the rule exists and what it protects, and our guide to the policy owner role covers how to assign owners across a growing company. Some requests can’t be granted by anyone, because a company can set aside its own rules but not a requirement set by law, regulation or a binding contract, and the honest answer to those is help finding another way to comply.
What goes in an exception register
The register is the single list of every exception the company has considered, and it can live wherever your team already keeps structured records, as long as it is in one place, has an owner and isn’t a thread of emails. Each entry needs enough detail for someone who wasn’t involved to understand the decision a year later.
| Field | What to record | Why it matters later |
|---|---|---|
| Reference | A simple number such as EX-2026-014 | Lets approvals, emails and audit answers point to one entry |
| Policy and clause | The policy, its version and the exact requirement being set aside | Shows the exception is narrow rather than a blanket pass |
| Requester and scope | Who asked, and which people, systems, sites or contracts it covers | Stops an exception for one contractor quietly covering a whole team |
| Reason | Why the policy can’t be followed in this case | The first thing an auditor reads, and the clue to whether the policy is wrong |
| Risk and level | What could go wrong, and the low, medium or high rating | Decides who must approve and how long it may last |
| Compensating steps | What will be done instead to reduce the risk, and who checks it | Shows the intent of the policy is still met |
| Decision | Approved, narrowed or declined, by whom, on what date, and why | The accountable record of the choice |
| Expiry | The end date, and whether renewal needs a fresh request | Keeps temporary from becoming permanent |
| Closure | The date it ended and what happened, such as the laptop arriving or the policy changing | Closes the loop and feeds the policy review |
Keep the register private to the people who need it, since entries can describe weaknesses, and review it on a schedule, monthly for a busy security program or quarterly for most others, to close what has expired and spot what keeps recurring.
Time limits, renewals and expiry
An exception without an end date is a policy change that skipped approval, so every exception should carry an expiry date when it is granted. The right length depends on the reason: an exception tied to an event, such as a delivery or a project, should end when that event does, while one granted for a lasting reason should run for a short fixed term and then come back for review.
Renewal should never be automatic. When an exception reaches its date, the requester either confirms it has ended or submits a fresh request, and the approver looks at it again with whatever has changed since, including whether the compensating steps worked and whether the policy itself now needs to change.
When the exceptions say the policy is wrong
The register is one of the best inputs to your policy review, because it shows where the written rule and the real business have drifted apart. A pattern of approved requests against the same clause usually means one of three things: the policy is too strict for a legitimate way of working, it was written for a tool or process the company no longer uses, or it is unclear enough that people ask for permission they don’t need.
In each case the fix is to change the policy rather than keep granting exceptions, and the change deserves the same care as the original. The owner drafts the new version, it goes through approval, and it goes out to the people it covers for acknowledgment, so everyone in scope works to the new rule and the register can close the exceptions it replaces.
Writing exceptions into your policy on policies
The exception process belongs in your policy on policies, the master policy that sets how every other policy is written, approved and reviewed, so that the same rules apply whichever department owns the policy. A short section is enough if it covers six points.
- Scope: which policies the process covers, and which requirements can never be excepted because they come from law, regulation or contract.
- Request: how to ask, what information to include, and that requests come before the departure wherever possible.
- Approval: the risk levels and who decides at each one, with the rule that nobody approves their own request.
- Duration: the longest term at each risk level, and that renewal needs a fresh decision.
- Register: where exceptions are recorded, who keeps the register and who may see it.
- Review: how often the register is reviewed, and that repeat exceptions trigger a review of the policy itself.
Because it is a policy like any other, the exceptions procedure needs an owner, an approval, a review date and acknowledgment from the managers who will be asked to approve requests. If your company is building out a wider compliance program, the exception register also gives you a ready source of evidence for how departures from policy are found and handled.
Common mistakes with policy exceptions
Approving by email and forgetting. An approval in an inbox is invisible to the next owner, so the decision should always land in the register, whatever channel the request arrived through.
Open-ended exceptions. Without an end date nobody is prompted to look again, and the exception outlives the reason it was granted.
Blanket wording. “The sales team is exempt from the travel policy” is a policy change in disguise, while an exception should name the clause, the people and the period.
No compensating steps. An exception that simply removes a control, without anything in its place, leaves the risk the policy was written to manage.
Never feeding the review. When the register isn’t read at review time, the same exceptions are granted year after year and the policy never catches up with the business.
How AllyMatter supports the exceptions process
Exception requests and the register itself belong in whatever tool your team already uses for structured records, and what AllyMatter does is keep the policies they relate to approved, current and provable. The exceptions procedure lives in AllyMatter as a policy with its own owner, approval workflow and review date, and the managers who approve exceptions acknowledge it like any other policy.
When the register shows a policy needs to change, the owner edits it, the new version goes through its approval workflow, and it goes out to the people it covers for acknowledgment with automatic reminders. Every version is kept with a word-by-word compare and every approval and acknowledgment is in the audit trail, which you can filter and export as a PDF or CSV, so when an auditor asks what the rule was on the day an exception was granted, you can show it.
For the wider picture of who writes, approves and reviews policies, see our guide to policy management software for small and growing businesses.
Start your 30-day free trial of AllyMatter. No credit card to start, and a 30-day money-back guarantee if you subscribe and change your mind. Free migration.
Questions about policy exceptions
What is a policy exception?
A policy exception is an approved, documented and time-limited departure from a company policy for a specific person, team, system or situation. It differs from a violation, which nobody approved, and from a policy change, which applies to everyone in scope.
What is a policy exception process?
A policy exception process is the set of steps a company follows when someone can’t follow a policy: a written request, a look at the risk, a decision by someone with the authority for that level of risk, a record in an exception register, checks while it is open, and an end date when it expires or comes back for a fresh decision.
Who should approve a policy exception?
Someone other than the person asking, with authority that matches the risk. A low-risk exception can usually be approved by the policy owner, while anything that touches a legal, regulatory or contract obligation, or people’s safety, should go to leadership after advice from legal or the compliance lead.
How long should a policy exception last?
As short as the situation allows, with a fixed end date. Many companies cap low-risk exceptions at about a quarter and higher-risk ones at a few months with regular checks, and require a fresh request rather than an automatic renewal when the date arrives.
Can you grant an exception to a legal requirement?
No. A company can set aside its own rules, but it has no power to waive a requirement set by law, regulation or a binding contract, so the right answer to that request is a different way to comply rather than an exception.
What should an exception register contain?
At minimum a reference number, the policy and clause, the requester and scope, the reason, the risk level, the compensating steps, the decision with the approver and date, the expiry date and the closure. Those fields answer the questions an auditor or a new policy owner will ask months later.
When should an exception become a policy change?
When the same exception keeps being requested and approved, the policy probably no longer fits how the business works. The policy owner should then change the policy itself, take the new version through approval and send it out for acknowledgment, instead of granting the same exception again.
Exceptions are not a sign that a policy program is failing, because every real business needs a few. What matters is that each one is asked for, decided by the right person, written down, watched and closed, and that the pattern they make is read at review time, so the policy keeps up with the company instead of the other way round.
Start your 30-day free trial of AllyMatter. No credit card to start, and a 30-day money-back guarantee if you subscribe and change your mind. Free migration.