Grant an SDK exception only in writing, with a named owner, a stated reason, compensating controls and an expiry date no more than a quarter or two away. Record it in the register and let CI fail when it expires. An exception without an end date is a policy change nobody approved.
When exceptions are legitimate
Real examples: a launch date that cannot move while a security review finishes, an abandoned SDK that needs time to replace, a vendor fix that is not out yet, or a version rule that conflicts with another library. A process with no exception route gets bypassed. A process with a loose route gets ignored. The goal is a route that is easy to use and hard to forget.
The exception record
| Field | Example content |
|---|---|
| SDK and version | Name and exact version |
| Requester and owner | Two names, owner closes the exception |
| Policy being waived | Approval, version rule, tier review, or privacy mapping |
| Reason | One or two sentences, plain words |
| Risk accepted | What could go wrong |
| Compensating controls | Pinned version, wrapper, reduced permissions, extra monitoring |
| Approver | Named person with authority |
| Expiry | A date, not "when ready" |
| Exit plan | What happens at expiry |
Who approves
The approver should be the same person who owns SDK decisions, which is why our RACI names one accountable owner. If a high tier SDK is involved, bring security into the decision. The requester must not approve their own exception.
What to refuse
- Exceptions for privacy mapping when the SDK collects personal data and nobody knows what. Apple's guidance says developers must declare data collected by third-party partners, so an unknown here is a gap you cannot defer safely.
- Open ended exceptions.
- Exceptions that bundle several SDKs into one record. One record per SDK.
- Exceptions renewed more than once without a change of plan. A second renewal should escalate to the next level.
Reviewing exceptions
Keep a list of open exceptions with dates. Look at it in the quarterly review and in release readiness. Report the count and the oldest age to leadership. A rising count says the policy is too hard or the migration work is not being funded, and both are worth knowing.
Automate the expiry. The CI allowlist can mark an exception expired and fail the nightly build. People take a date seriously when a build depends on it.
Close the loop
At expiry, one of three things happens: the SDK is approved properly, it is replaced or removed, or the exception is renewed with a new reason and a stronger control. Write which one and why.
Safeguard's policies and evidence automation can help record these decisions and show who approved what. This post gives governance practice, not legal advice.
Quick check
How long should an exception last?
Short enough to force a decision, commonly a quarter or less. Match it to the exit plan.
Can the requester approve their own exception?
No. Use the SDK owner or another named approver.
Sources
Last reviewed: 19 October 2026.
