No. The person who benefits from an exception should not be the one who approves it. Separation of duties means a second person, with authority over the risk, reviews the request. Small teams can meet this with a rotating reviewer or an outside approver, and the system should enforce it.
Why self-approval fails
The owner of a service knows the most about it, which makes them the best source of facts. That same closeness gives them reasons to approve: a deadline, a launch, a long backlog. An exception approved by the person who asked for it records an intention, not a decision.
The point is also practical. Reviewers catch the things requesters miss, such as an unlisted internet-facing path or a compensating control that does not apply to this build.
What separation of duties looks like
| Role | Does | Does not |
|---|---|---|
| Requester | Writes the case, owns the fix plan | Approve, extend or close |
| Reviewer | Checks facts and controls | Request on the same finding |
| Approver | Accepts the risk, sets the end date | Be the requester |
| System | Enforces the roles, logs each step | Allow a role override without a record |
One person may fill different roles on different exceptions. Not on the same one.
Making it work in a small team
- Cross-review. Two leads approve each other's exceptions, never their own.
- Founder or CTO as approver for anything high risk, with the engineer as requester.
- External advisor as approver of last resort, for teams with a single engineer.
- Enforce it in tooling. Block approval when the approver matches the requester. A policy no one can click past is worth more than a written reminder.
If the system cannot enforce it, add a detective step. Review the log monthly for self-approved items and treat each as a finding.
Edge cases
Requester leaves, approver stays. The exception remains valid, but it needs a new owner. See orphaned exceptions when an owner leaves.
Approver is also the code owner of a different service. That is fine, provided they do not own the affected one.
Automated approvals. A bot can apply a pre-approved rule, such as a low risk exception under a set duration, but a person must have approved the rule. The same logic is used when asking whether an AI review counts as a required approval.
Where Safeguard fits
Safeguard policies can require a separate approver and record who requested, reviewed and approved each waiver, which feeds compliance evidence automation.
Quick check
Is a peer review enough, or does a manager need to approve?
For low risk items, a peer plus security review is reasonable. Anything exposed to the internet or rated high should go to someone with authority over the risk.
What if there is only one engineer?
Use an outside approver, such as a founder, advisor or contracted reviewer, and keep the written record. The independence matters more than the title.
Last reviewed: 19 October 2026.
