GOV-013 Exception and Requirement Determination Register
Description
A defined process governs requests for exceptions to information security policies, naming the approval authority for each level of risk accepted and the maximum duration an exception may run. Each entry in the exception register records the policy deviated from, the business justification, the risk accepted, a named approver, the approval date and an expiry date. No exception in the register is past its expiry date without a renewal or remediation record. The register carries a review date within the defined interval. Where a requirement the organisation is bound by permits a measure other than the one it names, a determination record states the requirement, the assessment of why the named measure is not reasonable and appropriate in the organisation's environment, the alternative measure implemented in its place or the finding that none is reasonable and appropriate, and the approver. A determination carries the trigger that brings it back for re-assessment rather than an expiry date, and no determination in the register is past its trigger without a re-assessment record. The register distinguishes a determination from a policy exception.
Rationale
Without a controlled route, a deviation happens anyway and happens invisibly, so the risk is carried without anyone having accepted it. The register is the artefact under test and the expiry date is what makes it self-correcting: an exception that nobody renews becomes a finding rather than a permanent state. GOV-006 holds the risk tolerance that decides who may approve what. APP-009 holds the separate criterion for a change that bypasses the normal change process. A regulatory determination is a different animal in the same register. It is a permitted election under an external requirement rather than a deviation from the organisation's own policy, it does not lapse, and its defining field is the alternative measure, which a policy exception has no place for. Recording it as an exception with an expiry produces a renewal ritual in place of a re-assessment, and an undocumented election reads to an enforcer as inattention rather than as a reasoned choice. The two entry types share one register and one review cadence, which is why this is one control. GOV-010 records that the obligation exists and who is accountable for it; it does not record how the obligation was met.
Applicability (9 profiles)
164.306(d)(3) is now stated. The register holds a determination against an external requirement as its own kind of entry: the specification named, the assessment of why implementing it is not reasonable and appropriate in this environment, the equivalent alternative measure or the finding that none is reasonable and appropriate, the approver and a re-assessment trigger rather than an expiry. Twenty-two addressable specifications of the extract run through it, and they no longer sit in a register that expires them. The control is renamed Exception and Requirement Determination Register.
Art. 2(2) is now stated. The register holds a second kind of entry for a decision that a requirement qualified by 'where appropriate', 'where applicable' or 'to the extent feasible' does not apply: the requirement named, the reasoning written against this environment, the measure implemented in its place or the finding that none is reasonable and appropriate, the approver and a re-assessment trigger rather than an expiry. The control is renamed Exception and Requirement Determination Register.
Framework Mappings (9)
| CCC-08 | Exception Management | informative |
| GRC-04 | Policy Exception Process | full |
| CCC-08 | Exception Management | informative |
| GRC-04 | Policy Exception Process | full |
| HIPAA-164.306.d | Required and Addressable Implementation Specifications | full |
| 5.1 | Policies for information security | informative |
| NIS2-CIR-Art.2.2 | Proportionality and Documented Reasoning for Non-Application | full |
| PM-9 | Risk Management Strategy | informative |
| GV-1.6-002 | AI System Inventory | GV-1.6-002 | informative |
Evidence (3)
Policy exception management procedure defining the request, approval, time-bounding, and periodic review process for policy deviations.
Example: Policy Exception Management Procedure (Confluence / ISMS document), describing: how to submit an exception request, required approval authority by risk level, maximum exception duration, and the review/renewal process.
Test: Request the policy exception management procedure. Verify: (1) a defined submission process is described, (2) approval authority tiers are documented, (3) maximum exception duration is stated (typically 12 months), (4) a periodic review requirement is included, (5) the procedure has an approval date within the last 12 months.
Exception register showing all active and expired policy exceptions with approver, duration, risk acceptance rationale, and review dates.
Example: Policy Exception Register (GRC platform / spreadsheet), with columns for: exception ID, policy deviated from, business justification, risk accepted, named approver, approval date, expiry date, and current status (active/expired/renewed/remediated).
Test: Request the policy exception register. Verify: (1) all active exceptions have a named approver and non-expired approval date, (2) risk acceptance rationale is documented for each, (3) no exceptions are past their expiry date without a renewal or remediation record, (4) the register was reviewed within the defined interval.
Requirement determination entries in the register, covering decisions to meet a binding external requirement by a measure other than the one it names.
Example: Requirement determination register extract, 14 entries, reviewed 12 June 2026.
Test: Verify: (1) the register distinguishes a policy exception from a determination against an external requirement, (2) every determination names the specific requirement it answers rather than the instrument in general, (3) every determination carries the assessment of why the named measure is not reasonable and appropriate in this environment, and that assessment refers to the environment rather than restating the requirement, (4) every determination either names the alternative measure implemented or records the finding that none is reasonable and appropriate, (5) every determination carries an approver holding the authority the process assigns, (6) every determination carries a re-assessment trigger and none is past it without a re-assessment record, (7) the determinations reconcile to the requirements in the compliance inventory that permit an alternative, so a requirement met by an alternative with no entry is visible.
Questions (3)
Does your organisation have a formal process for requesting, approving, and tracking exceptions to information security policies?
The process should require a business justification, named approver, risk acceptance rationale, and a defined maximum exception duration.
How are active policy exceptions tracked and managed?
An exception register should show that no exceptions are past their expiry date without renewal or remediation, and that each carries a named approver.
Which of the following does each determination against an external requirement record?
This covers a regime that permits an alternative measure, not a requirement the organisation has failed to meet: an unmet requirement is a finding, not a determination. The assessment is the item most often thin, because restating the requirement is easier than saying what about this environment makes the named measure unreasonable. A determination that only expires on a date behaves like a policy exception and gets renewed rather than re-assessed.