Treat it as an exception with two approvals: the customer's written request and your own internal sign-off. Record exactly what is being switched off, for whom, for how long, and who accepted the risk. Do not agree in a call and move on. If it cannot be written down, it cannot be defended later.
Requests like this are real. A customer wants a firewall rule opened, an old protocol kept on, or a gate bypassed to meet their own deadline. Saying no every time is not always possible, and saying yes with no record is worse.
Decide who owns the risk
Ask which party carries the consequence. If the change affects only that customer's tenant or environment, the customer can accept the risk for their own data, and your job is to make sure they understand it. If it affects other customers or shared infrastructure, the answer is almost always no, since one customer cannot accept risk on behalf of others.
What to capture
- The request. In the customer's own written words, with the requester's name and role.
- The control. What it protects and what disabling it exposes.
- Scope. Which tenant, environment, or integration, and nothing wider.
- Duration. A date, and an exit plan to restore the control.
- Risk statement. A plain sentence the customer acknowledges, for example that traffic on the old protocol can be read by an attacker on the network path.
- Your approval. A named internal approver independent of the account team.
Keep sales out of the approval
Account teams are motivated to say yes. They should present the request, but the approver should be someone who does not share the revenue outcome, such as the security owner. This is the same independence rule as for engineering exceptions.
Offer alternatives first
Before granting, try to meet the real need another way. A customer who wants a block lifted may only need a narrow allow rule for one address. A customer who wants to stay on an old version may accept a mitigation instead. Often the request is a symptom, and the alternative solves the actual problem.
Track it like any other exception
Put it in the same register, labeled as customer-requested. Review on the expiry date and confirm with the customer whether it is still needed. Many such exceptions last far past their purpose because nobody asked.
What not to promise
Do not promise that the customer's accepted risk removes your responsibility for your shared systems, and do not word it as legal protection. If contracts are involved, ask counsel to review the language. This post describes engineering practice, not legal advice.
Where Safeguard fits
Safeguard policies and gates can scope a deviation to a specific asset or tenant and give it an expiry, so a customer-specific exception does not widen by accident.
Quick check
Can a customer waive a control that protects other customers?
No. They can only accept risk for what they own. Shared controls need your own decision.
Should the request come by email or a call?
Write it down. If it starts on a call, send a summary and ask the customer to confirm it in writing.
Last reviewed: 19 October 2026.
