Why exceptions need a process
Any standard that applies to many units will occasionally fit one of them badly. A site may use equipment that cannot run the standard software version. A team may have a contract that conflicts with a shared supplier arrangement. A project may need to move faster than the normal approval allows.
If there is no sanctioned way to depart from the standard, people do it anyway and say nothing. The standard then exists on paper while real practice drifts, and the central team loses sight of where the gaps are. A standards exception process brings those departures into the open, makes them a deliberate decision and keeps a record.
An exception process is not an invitation to ignore rules. It is the pressure valve that lets rules stay firm.
The stages of a fair process
1. Request
The requester should be able to submit a short, standard form. Useful fields are:
- which standard, and which part of it, the request concerns;
- what the unit proposes to do instead;
- why the standard cannot be met, in plain terms;
- what risks the departure creates, and how they will be reduced;
- how long the exception is needed;
- who in the unit is accountable for it.
Keep the form short. A heavy form discourages honest requests and encourages quiet workarounds.
2. Assessment
A named person or small group reviews the request against agreed criteria. Typical questions are:
- Is the reason genuine, or is it convenience?
- What is the risk to other units, to shared systems or to people the organization serves?
- Is there a compliant alternative that would work?
- Would granting this create pressure for many similar requests?
- Do the owners of the affected systems agree?
For security, privacy or regulatory matters, the assessment should include qualified specialists. A general business forum is not the right place to decide whether a compliance obligation can be relaxed.
3. Decision
Decide within a stated time, and give the answer with reasons. The decision-maker should be defined in advance as part of the decision rights; for low-risk matters this may be the system owner, while higher-risk ones may go to a steering committee. Possible outcomes are approve, approve with conditions, decline or defer pending more information.
Fairness matters here. Similar requests should receive similar answers, and the reasoning should be consistent enough that units can predict it. Declining with a reason is better received than silence.
4. Recording
Every approved exception goes into a register. A simple entry holds the standard, the unit, the reason, the risk accepted, the conditions, the approver, the approval date and the expiry date. The register need not be sophisticated; a shared table is enough for many organizations.
5. Review and expiry
Exceptions should normally have an end date. When it arrives, the exception is renewed, ended or resolved by changing the standard. Without expiry, temporary exceptions become permanent ones.
Reading the pattern
The register is also a source of information. If many units request exceptions to the same standard, the standard may be badly designed, out of date or too broad. Revising it is often better than granting the same exception repeatedly. This feeds naturally into the guidance on writing policies and standards people can follow and into periodic governance reviews.
A count of exceptions is a prompt for investigation, not proof of failure. A low number can mean a good standard or simply that people have stopped asking.
Pitfalls
- One-way ratchet. Each exception is reasonable alone, but together they erode the standard. Review the register as a whole.
- Approval by the requester’s friends. Where possible, the approver should not be the person who benefits.
- Slow approval. If the process takes longer than the problem it addresses, people will bypass it. Set a target time and track it.
- Hidden conditions. Approved exceptions with unstated conditions are not enforced. Write them down.
- Treating emergencies like routine. Some situations need an immediate temporary exception, with retrospective review. Decide in advance who may authorize that.
A short illustration
Suppose a small regional office relies on older equipment that cannot support a newly required software version. It submits a request describing the equipment, the proposed interim measures and a twelve-month replacement plan. The system owner consults the security lead, approves the exception for twelve months on the condition that the interim measures are kept in place, and logs it. At the end of the period the office either has replaced the equipment or applies for renewal with a new justification. The example is illustrative only; real conditions depend on the standard and the risks involved.
How much process is enough
A small organization with a handful of standards might manage with an email to the system owner and a line in a shared log. A larger one, or one in a regulated sector, may need formal forms, defined approvers and audit trails. The process should be proportionate to the risk of the standards it protects. Where compliance obligations are involved, confirm requirements with qualified compliance professionals.