What this template is for
Compliance exceptions are the lubricant that makes real-world compliance possible. No real system implements every control perfectly; the question is whether the deviations are documented, time-bound, and approved by the right people. Undocumented exceptions are audit findings; documented ones are evidence of a working programme.
This template turns each exception into a tracked ticket: policy referenced, justification captured, compensating controls listed, approvers signed off, expiry recorded. The ticket is the audit trail and the review reminder in one.
When to use it
Use this template:
- When a policy or control cannot be applied to a specific asset or use case
- In response to a pen-test or audit finding when the team chooses Accept Risk
- For temporary deviations during a migration or remediation period
- For any control marked ‘partially implemented’ in a compliance attestation
Routine policy clarifications (the policy was ambiguous; we agreed on an interpretation) belong in a policy update, not an exception.
Sub-task breakdown
The pre-expiry review sub-task is the one that prevents exceptions from drifting into permanent holes in the compliance posture. STM Issue Templates lays down the standard chain - justification, compensating controls, security approval, business approval, expiry, pre-expiry review - on every new exception ticket. The review sub-task is what auditors look for; making it automatic is how compliance programmes stay clean without dedicated headcount.
Fields to add to your Jira create screen
These are the fields a project admin should make sure exist on the Create Issue screen for this issue type (Project settings → Screens). Without these on the screen, reporters can't provide the information triage needs - and STM can't reference them either.
| Field | Example value | Required |
|---|---|---|
Summary | Exception - MFA exemption for legacy SCIM service account | Yes |
Policy / Control (custom) | ACC-002 - MFA required on all human accounts | Yes |
Framework (custom) | SOC 2 / ISO 27001 / HIPAA / Internal | Yes |
Requester | @platform-tl | Yes |
Justification (custom) | SCIM provisioning account; cannot do interactive MFA | Yes |
Risk Assessment (custom) | Medium - account is restricted to SCIM scope only | Yes |
Compensating Controls (custom) | IP allowlist; secret rotation every 30 days; alert on use outside business hours | Yes |
Approver (Security) | @ciso | Yes |
Approver (Business Owner) | @platform-vp | Yes |
Expiry Date (custom) | 2026-08-23 (90 days) | Yes |
Review Cadence (custom) | 30 days | No |
Linked Finding / Ticket | PT-2026-014 (optional - if exception is in response to a finding) | No |
Note on custom fields. STM currently supports up to 5 custom fields per template. You can add as many custom fields as you like to your Jira Create Issue screen - the 5-field limit only applies if you want STM to set or update those custom fields itself.
Sub-tasks STM creates automatically
Build an STM sub-task template containing the items below, then wire it to an On Create Issue Executor scoped to this issue type. Whenever a new issue of this type is created in the project, STM creates the full sub-task set in one step - with assignee, due date, and components inherited from the parent unless you override them.
- Document the policy or control the exception applies to
- Capture business justification and risk assessment
- Define compensating controls that reduce residual risk
- Get security approver sign-off
- Get business-owner approver sign-off
- Set expiry and review cadence on the ticket
- Schedule review sub-task before expiry
- On expiry: re-decide (renew, modify, or let lapse with remediation)
Common questions
What is a compliance exception in Jira?
A compliance exception is a documented, time-bound deviation from a policy or control. The exception ticket captures the policy, the justification, the compensating controls, the approvers, and most importantly the expiry. It is the artefact auditors look at when they see a control marked 'partially implemented' - and the cheapest defence against an exception quietly becoming permanent.
Should you ever grant a permanent exception?
Almost never. Permanent exceptions are policy changes in disguise - if a control cannot be applied to a class of assets indefinitely, the right answer is to update the policy with an explicit carve-out, not to issue an indefinite exception. Exceptions should always have an expiry, even if the expiry is 'review annually.'
How do you make sure exceptions don't outlive their expiry?
Schedule a review sub-task before the expiry date, with the review owner explicitly named. [STM Issue Templates](/stm/) can lay down the standard sub-task chain - including the pre-expiry review - on every exception ticket so the review surfaces in the queue before the expiry passes, not after. Stale exceptions are the most common audit finding and the easiest to prevent.
What is the difference between a compliance exception and a risk acceptance?
Exception is granted to a specific control or policy requirement with compensating controls; risk acceptance is the broader acknowledgement that a residual risk is acceptable to the business. Many exceptions implicitly involve risk acceptance, but the ticket structure is different - an exception names the policy clause it deviates from, while a risk acceptance names the risk itself. Track both, link them when related.
Automate the sub-tasks with STM
STM Issue Templates saves the sub-task list above as a reusable template and creates them on every new issue of this type - via an Executor on issue creation, on status transition, or triggered manually from the issue's "Create bulk sub-tasks" menu. STM does not change the parent issue's create screen (that's a Jira project-settings job) but it removes the manual work of creating the sub-tasks every time.
Try STM on the Atlassian Marketplace ↗ See how STM templates are built →