IT Standards Exception Request Form

The idea behind it

Technology standards fix choices such as encryption levels, approved platforms and integration patterns, so that teams do not solve the same problem in different ways. No standard fits every case. A vendor's system may not support the required protocol, or a regulatory deadline may arrive before the standard approach can be built. When a standards regime has no approved way to deviate, teams deviate anyway and do not record it. The organization then carries risks it cannot see. TOGAF, The Open Group's architecture framework, handles this through dispensations: a granted, time-limited exception to an architecture requirement.

An exception process makes deviation visible and temporary. Each request names the standard, explains why it does not fit, limits the scope and sets an expiry date. It states the risk the exception introduces, the controls that reduce it and the risk that remains. Approval scales with that residual risk, so a low-risk exception for one endpoint moves quickly while one that touches regulatory compliance reaches senior approvers and Legal. Every exception has a named owner and a review date. An exception that keeps being renewed is evidence the standard itself needs to change, and the process sends it back to the standard owner.

What's inside

• Exception details: reference, submitter, team and the exception owner.
• The standard: its reference, what it requires and who owns it.
• The exception: the proposed approach, why the standard does not fit, the scope and an expiry date.
• Risk and mitigation: the risks introduced, the controls, whether the exception affects regulatory compliance, the residual risk and the plan to return to the standard.
• Approval: three approver levels, a Legal / Compliance approver for regulatory impact, an approval date and a review date.
• An approval path table matching residual risk to the approvers required and a target turnaround in business days: Level 1 for every exception, Level 2 from Medium, Level 3 for High, and Legal / Compliance for regulatory impact.
• A worked example for a TLS 1.2 exception on a payment gateway integration, rated Medium and approved at Levels 1 and 2. The Word version includes it.

Format: PDF (3 pages) and Word document.

A look inside

Pages 1 and 2 of 3 of the PDF. Select an image to enlarge it.

Who uses it

• Enterprise architects and architecture review boards, to grant deviations without losing track of them.
• CISOs and security architects, to record and time-limit risk accepted against security standards.
• Engineering teams and tech leads, to request a deviation with a known route and turnaround.
• Standard owners, to see which standards draw repeated exceptions and may need revising.

When to use it

• A third-party system cannot meet a standard, such as a partner gateway that does not support the required TLS version.
• A regulatory or contractual deadline falls before the standard approach can be delivered.
• An architecture review finds a system already running outside a standard with no record of approval.
• Teams are working around a standard informally and governance wants the deviations on record.
• A new standard is published and existing systems need time to comply.

How to use it

Give teams the form as the route for any deviation from a standard, and review each approved exception on its review date.

1. Complete Exception Details and name an exception owner who will manage it to closure, not only the submitter.
2. Under The Standard, give the standard's reference, what it requires and who owns it.
3. Under The Exception, describe the alternative approach, the specific reason the standard does not fit, the narrowest scope that works and an expiry date.
4. Under Risk & Mitigation, describe the specific risk introduced, the controls in place, whether the exception affects regulatory compliance, the residual risk as Low, Medium or High with a one-sentence justification, and the plan to return to the standard.
5. Use the Approval Path table to route the request: Level 1 for every exception, Level 2 for Medium and High residual risk, Level 3 for High, and Legal and Compliance for any regulatory impact, each with a target turnaround in business days.
6. Record approvers, the approval date and a review date before the expiry date, and review the exception on that date.

You leave with: A signed, time-limited exception record that states the risk accepted, who accepted it, who owns it and when it will be reviewed or closed.

Where it goes wrong

• Granting exceptions with no expiry date, so temporary deviations become permanent.
• Describing risk in general terms such as "security risk" instead of the specific threat.
• Accepting "it is too hard" as the reason the standard does not fit.
• Renewing the same exception repeatedly instead of asking the standard owner to change the standard.

Get the form and approval path

It is free. Enter your work email and we send the download link.

Questions

Read more on this

• Modern Enterprise Architecture Governance
• Shadow IT is market research you are already paying for