When acquired code cannot meet your dependency policy soon, ring fence it. Isolate it from sensitive systems, limit who and what can reach it, add compensating controls such as extra monitoring, record it as a named exception with an owner, and set a date to upgrade or retire it.
When ring fencing makes sense
Not every system can be brought up to standard in a quarter. An old service may depend on an unsupported framework, a library that is no longer maintained, or a component with no available upgrade. Rewriting it may cost more than it earns. Ring fencing is a way to accept that for a bounded time, with open eyes, instead of pretending the policy applies or letting the system sit unmentioned.
It is not a permanent answer. If the plan has no end date, it is just neglect with a label.
Step 1: Describe the system
Write a short record: what the code does, what data it touches, who depends on it, which policy rules it fails, and why it cannot be fixed now. Include the dependencies that cause the failure, by name and version.
Step 2: Cut the blast radius
Reduce what an attacker could reach through this system.
- Put it in its own network segment or account.
- Give it only the credentials it needs, scoped narrowly and rotated.
- Remove outbound access it does not use.
- Block it from reaching production data stores unless essential.
- Keep it out of shared build pipelines where a compromise could spread.
Step 3: Add compensating controls
Pick controls that match the specific weakness. If a library has a known flaw that is reachable only through one endpoint, restrict or filter that endpoint. If the framework no longer gets fixes, consider adding monitoring for unusual behavior and a tested way to take the service offline quickly.
Check whether the vulnerable code is actually reachable. Reachability analysis can show that a flagged function is never called, which changes the risk and the plan.
Step 4: Record it as an exception
An entry in the exception register, with an owner, a reason, the controls in place, and an expiry date. Review it on schedule. See how long should a vulnerability exception last and keep an exemption register.
Step 5: Choose the exit
Pick one and put a date on it:
| Exit | Fits when |
|---|---|
| Upgrade in place | The path is clear and tests exist |
| Rewrite or replace | The code is small or the function is available elsewhere |
| Retire | Few users remain, or the function is duplicated by your own product |
| Wrap | You can place a maintained layer in front and migrate behind it |
Keep it visible
Report ring fenced systems as their own line in security reporting. Leaders should see how many there are and how many dates have slipped. A list that only ever grows signals a funding problem, not a technical one.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how a finding is judged by whether it can actually be exploited in context.
Safeguard's reachability analysis and policies can help you show which findings in a ring fenced system are reachable, and keep the exception recorded next to the rule.
Quick check
Is ring fencing the same as accepting the risk forever?
No. It is a time limited arrangement with controls and an exit date. Without the date it becomes permanent neglect.
Who signs off a ring fence?
The policy owner or a delegated approver, with the system owner named in the record.
Last reviewed: 19 October 2026.
