Last reviewed: November 2026
No Credit Card Required
Printed from checkflow.io/templates/cybersecurity/security-exception-request-checklist
This free security exception request checklist is for security teams, IT and the people who need to depart from a security policy or standard for a while: an account that cannot use MFA, an unsupported operating system on a machine that runs a lab instrument, unencrypted removable media on one production line, or a firewall rule wider than the standard allows. One run takes one request from the date it is raised to its expiry date. The requester names the policy and the requirement, describes the departure, gives the business reason, lists the assets and data involved and sets out how the departure will end. The security reviewer checks that it is an exception rather than a scanner finding or a policy change, rates the risk with your own method, agrees compensating controls, checks the expiry date against your policy’s own maximum and writes a recommendation. The risk owner accepts or declines the residual risk, with a senior sign-off for a high or critical risk, and the approver, the CISO or the delegate your policy names, decides: approved, approved with changes, more information needed or rejected. An approved exception goes in the register, its compensating controls are checked before it applies and again before it ends, and at the expiry date the system is brought into line or a new request has replaced it.
This checklist runs one request to depart from a security policy or standard, such as no MFA on one account, an unsupported operating system on a lab PC, unencrypted removable media on one production line or a firewall rule wider than the standard allows. It takes the request from the business reason to the risk rating, the compensating controls, the risk owner’s acceptance and the approver’s decision, then keeps the exception in the register until it ends or a new request replaces it.
A scanner finding that cannot be fixed by its deadline is handled inside the monthly cycle of the Vulnerability Management Checklist, which has its own exceptions phase. A requirement that keeps needing exceptions is a question for the Annual Policy Review Checklist, which reads the exception log. The risk method this checklist rates against is set up with the IT Risk Assessment Checklist. Certification and framework programmes run in the ISO 27001 Compliance Checklist, the NIST CSF Checklist and the FISMA Compliance Checklist, and a review of a whole cloud account in the Cloud Security Review Checklist.
Covers: the policy and requirement, the business reason, the assets and data, the risk rating, compensating controls, the risk owner’s acceptance, the decision, the register entry, monitoring and the expiry.
Planned around: the date the request is raised and the expiry date.
Output: a recorded decision and, if approved, an exception that ends on a known date.
Covers: scan coverage, triage, remediation deadlines, exceptions for findings that miss them, rescans and the monthly report.
Planned around: a monthly cycle.
Output: findings fixed or excepted within the cycle. A departure from a policy that is not a scanner finding comes here instead.
Covers: every policy’s triggers, redlines, approval, publication and attestation.
Planned around: the yearly approval deadline.
Output: current policies. This checklist tells the policy owner each exception’s outcome for that review.
Nine phases take one request from the business reason to the end of the exception. The first task records two dates: the date the request is raised, from which the assessment and the decision fall due within about four weeks, and the expiry date asked for, from which the review and the close-out count. The due dates stay in order for an exception of at least three months; for a shorter one, move the due dates in Phases 7 and 8 when you start the run. The decision in Phase 6 is assigned to one person and nothing after it can be completed until they decide. A rejection hides Phases 7 to 9 and shows its own follow-up tasks.
Owned by the requester. Enter the date the request is raised and the expiry date you are asking for on the first task: the work up to the decision counts from the first date, and the review and the end of the exception count from the second. Name the people who review, accept and decide, and say whether the departure is already in place.
The security reviewer checks that this is an exception rather than a scanner finding or a policy change, and looks for related exceptions. A departure that is already in place is contained now; a planned one waits for the decision.
The security reviewer works out what the departure exposes and rates the risk with your own risk method.
The security reviewer agrees compensating controls with the requester, rates the risk that remains, checks the expiry date against the policy’s own maximum and writes a recommendation for the approver. A high or critical residual rating adds a senior sign-off in Phase 5.
The risk owner, not the requester or the security team, accepts the residual risk or declines it. A high or critical residual risk also needs the senior sign-off your policy requires.
The approver decides: approved, approved with changes, more information needed or rejected. Only the person named on the first task can complete the decision, and nothing after it can be completed until they do. A rejection hides the later phases and shows the tasks that follow it.
Applies only when the exception is approved. The exception goes in the register, the compensating controls are put in place and checked, and the teams affected are told when it starts.
Applies only when the exception is approved. The controls and the plan are checked about eight weeks after the request was raised; the review falls five weeks before the expiry date and a renewal request four weeks before it. The due dates stay in order for an exception of at least three months (about 65 working days) from the request; for a shorter one, move the due dates in Phases 7 and 8 when you start the run so they fall between the decision and the expiry date.
Applies only when the exception is approved. On the expiry date the departure ends or a new exception covers it, the register entry is closed and the policy owner hears the outcome.
Each step maps to a NIST control you may already be assessed against. Use your own policy’s words where they differ.
| Step in this checklist | What the source says | Source |
|---|---|---|
| Describe and approve the departure | CM-6(c): identify, document and approve any deviations from established configuration settings. | NIST SP 800-53 Rev. 5, CM-6 |
| Assess the risk | RA-3: identify threats to and vulnerabilities in the system, and determine the likelihood and magnitude of harm. | NIST SP 800-53 Rev. 5, RA-3 |
| Accept the risk, or not | RA-7’s discussion lists accepting risk with appropriate justification or rationale as one response, alongside mitigating, sharing or transferring, and avoiding it, all within the organisation’s risk tolerance. | NIST SP 800-53 Rev. 5, RA-7 |
| Rate against your risk tolerance | PM-9’s discussion: the risk management strategy includes an expression of the organisation’s risk tolerance. | NIST SP 800-53 Rev. 5, PM-9 |
| Record the plan to comply | CA-5: a plan of action and milestones documents planned remediation of weaknesses or deficiencies. | NIST SP 800-53 Rev. 5, CA-5 |
| Check the controls while it runs | CA-7: ongoing control assessments and monitoring, with response actions to the results. | NIST SP 800-53 Rev. 5, CA-7 |
| Who accepts the risk | For US federal systems, the authorizing official cannot delegate the authorization decision (the acceptance of risk). | NIST SP 800-37 Rev. 2 |
The approver’s decision in Phase 6 decides which tasks follow.
| Decision | What the checklist does next |
|---|---|
| Approved | Phases 7 to 9 stay: the register entry, the compensating controls put in place and checked, monitoring, the review and the expiry. |
| Approved with changes | As approved, with a task for the requester to make the changes. A shorter period is set by changing the expiry date on the first task. |
| More information needed | A task for the requester appears above the decision, which stays open until the approver chooses another decision. |
| Rejected | Phases 7 to 9 are hidden. The rejection is sent and recorded, and the system is brought into line or the planned change is stopped. |
Where this comes from. None of the sources on this page sets a process or a maximum period for security exceptions: your own policy defines them. The NIST controls are from SP 800-53 Revision 5 (release 5.2.0 of August 2025, read on 9 November 2026), whose controls are written for US federal systems, and SP 800-37 Revision 2 (December 2018). ISO/IEC 27001:2022 is a paid standard, named here only: it was still the current edition on 9 November 2026, with one amendment (2024). Check the clause your own ISMS uses for approving risk treatment and residual risk. The CIS Controls v8.1 include Control 2 (inventory and control of software assets) and Control 4 (secure configuration of enterprise assets and software); a departure from either can be recorded here. As one example of published practice, GitLab’s public handbook has exceptions approved, logged centrally and reviewed as their expiration date approaches, with any extension needing a new approved request; your own policy sets your rules. This template does not give legal or audit advice.
The policy and requirement, the departure, the business reason, the assets and data, and the plan to comply are captured before the security team starts. The reviewer rates the risk with your own method and agrees compensating controls, so the approver reads the same facts every time.
Only the risk owner named on the first task can accept the residual risk, and only the approver can complete the decision, which locks the later phases until they do. A high or critical residual risk adds a senior sign-off. A rejection hides the approved path and shows the follow-up instead.
The controls and the plan are rechecked during the exception, the next step is decided five weeks before the expiry date, and a renewal is a new request. Track every open exception in the Reports Grid.
CheckFlow does not rate risks or change any system: your security team, your risk owners and your approver do. CheckFlow makes sure every request follows the same steps, by the right people, with the record kept until the exception ends.
Handle scanner findings in the Vulnerability Management Checklist, review the policies themselves with the Annual Policy Review Checklist, and set up your risk method with the IT Risk Assessment Checklist.
Describe the process in a sentence and the AI checklist generator drafts the phases and tasks for you.
It is a formal request to depart from a security policy or standard for a set period, because meeting the requirement is not possible or not practical yet. Examples are an account that cannot use MFA, an operating system past its support date that runs a lab instrument, or a firewall rule wider than the standard allows. The request is assessed, decided by a named approver, recorded in a register and ends on an expiry date.
The policy and the requirement it departs from, exactly what will be different, the business reason and why complying is not possible now, the assets and data involved, the risk rating, the compensating controls, the plan to comply and the expiry date asked for. This template also records the risk owner’s acceptance, the approver’s decision with reasons and the exception register reference.
Your policy decides. In this template the risk owner named on the first task accepts or declines the residual risk, and the approver, the CISO or the delegate your policy names, makes the decision; only they can complete it. A high or critical residual risk also needs the senior sign-off your policy requires. For US federal systems, NIST SP 800-37 says the authorizing official cannot delegate the acceptance of risk, so name the authorizing official as the risk owner or the approver on the first task.
None of the frameworks on this page sets a maximum, so this template asks for the longest period your own policy allows and checks the requested expiry date against it. A renewal is a new request, not an extension. The due dates stay in order for an exception of at least three months; for a shorter one, move the later due dates when you start the run. If your policy says nothing, the security reviewer says so in the recommendation and the approver chooses a period.
A control that reduces the risk the departure opens while the requirement is not met, such as moving the system to its own network segment, removing internet access, limiting who can sign in, extra monitoring and alerts, or more frequent log reviews. In this template, a control the requirement already expects does not count. This template records each control’s owner and date, and the security reviewer checks the evidence before the exception applies and again before it ends.
A security exception is the permission to depart from a specific policy requirement for a set period. Risk acceptance is the decision to live with the risk that remains. In this template the risk owner accepts or declines the residual risk first, then the approver decides the exception; a declined risk leads to Rejected or More information needed, not approval. NIST SP 800-53 RA-7’s discussion lists accepting risk with appropriate justification as one way to respond to risk.
About five weeks before the expiry date this template has the reviewer decide whether the departure will end or is still needed. If it ends, the requester brings the system into line by the expiry date. If it is still needed, the requester raises a new request, which goes through its own assessment and decision. After the expiry date the reviewer confirms which happened and closes the register entry.
No. A scanner finding that cannot be fixed by its deadline is handled in the exceptions phase of the Vulnerability Management Checklist, inside its monthly cycle. This checklist is for a departure from any security policy or standard that is not a scanner finding, such as an MFA, encryption, removable media or firewall requirement, from the request to its expiry.
14-day free trial, no card required. The Business plan is $10 per user per month after the trial. Full details at checkflow.io/pricing.
14-day free trial, no credit cardFull refund in your first 30 daysUS hosting, EU on request
