Use this exception record
Write the exception so it cannot silently cover a whole platform. Name one asset, one missing control, one business reason, and one owner who accepts the remaining risk. Add a tested temporary measure with an evidence link.
| Item | Check or owner | Evidence |
|---|---|---|
| Control and asset | What is being excepted? | Name exact system |
| Reason | Why can it not be fixed now? | Record blocker |
| Compensating control | What limits exposure? | Link test result |
| Expiry and owner | When is it reviewed? | Set decision date |
Test and retest
At expiry, do not copy the old approval. Check whether the blocker remains, whether the temporary measure still works, and whether the service or threat has changed. Keep the old record and issue a new decision with a date and signer.
Evidence to keep
Test both the temporary guard and its alert. Send one request from the allowed source and one from a blocked source. Confirm the blocked request causes no provider or ledger effect and the alert reaches the named owner. If the guard fails during the exception period, treat that as an early review trigger. The record should say who can revoke the exception outside normal hours. A signed approval does not help if operations cannot act when the risk changes.
Write an exception someone can test
Synthetic exception: the payout export service cannot yet require hardware-backed administrator login. A useful entry names the exact service account, export route, affected environment, owner, expiry date, and reason. It says the temporary control: the account can read only one export bucket, each export needs a second reviewer, and alerts fire on use outside office hours. Attach one test for each claim.
Review the exception after a role change, new route, or incident. If the account can also call a settlement API, the scope is wrong; narrow access or reopen the decision. An expired date should block silent renewal. Record who accepted the remaining risk and what event closes the exception. The NIST Cybersecurity Framework is a way to organize risk work; it does not approve the exception for the firm. The firm’s risk owner makes that decision.
Copy a complete exception row
Use this synthetic row as a field guide: EX-7; payout export service; production; missing hardware-backed administrator sign-in; owner risk lead; blocker vendor cutover; temporary control narrow export role plus second review; proof TEST-44; expiry 15 October 2026; early stop excess access or failed alert; closure new sign-in deployed and retested. Add an incident contact, last alert test, and the person allowed to suspend access.
Test the temporary claims separately. The export role must fail on payment-release APIs and unrelated buckets. A missing second approval must block export. A harmless out-of-hours request must reach the named responder. Store response times and failures with the exception. If any control fails, the owner makes a fresh decision before the service continues under that exception.
For a leaked API secret, do not use source restrictions as proof that rotation is unnecessary. Record emergency revocation and a safe replacement path. At closure, check that the old secret fails and the new one works; remove a temporary network restriction only if the final access design no longer needs it. Keep permanent controls when they remain part of the approved design.