If…, then how…
If a system is past vendor support and can't be replaced yet, then what?
Add to board memoOpen the memo
The short answer
- Recommendation
- Put the system in an end-of-life register and work through the options in order: retire it, upgrade or replace it, or buy the vendor's extended security updates. If none is possible yet, isolate it, add tested compensating controls, and request an exception with an expiry and a retirement date.
- Reasoning
- Past support, the vendor releases no more security patches, so every new flaw stays open for good and the normal patch deadline cannot be met. Retiring or replacing the system is the only lasting answer; everything else buys time. Extended updates let you patch as normal while replacement happens. Without them, isolation and compensating controls carry the risk, and a control counts only once it has been tested. The exception gives the arrangement an expiry, so a system that keeps slipping becomes a management decision.
- Considerations
- The 12-month register horizon, quarterly reviews and the 90-day cap are the defaults in the CISO Times packs. Your own standards may set different ones.
- The exception's band sets its approver. A Critical band goes to the board, or a board risk committee it has delegated this to; in a two-tier structure, the management board; where there is no board, executive management.
- Where the risk left is outside appetite, the risk approver signs the exception as well, and the stricter of the two applies.
- An untested control does not lower the exception's risk score, so it can push the decision to a more senior approver.
The decision, step by step
Select any step for the reasoning behind it and where the pack covers it.
- Start
- Step
- Decision
- Outcome
Keyboard: Tab to a step, arrow keys move along the flow, Enter pins its explanation, + and − zoom, 0 fits the diagram, Esc closes. The text version below has the same content.
Where a step quotes a number, it is the default in the CISO Times pack. Your own standard may set a different one.
Read as text
The same flow written out: each step, its reasoning and where the pack covers it. 16 steps.
Start
A system is past vendor support and can't be replaced yet
Past support means the vendor no longer releases security patches for that product or version. Every new flaw in it stays open for good, so the normal patch deadline cannot be met and the risk has to be managed another way until the system goes.
In the pack
- P17-A02 Patch Management StandardEnd-of-life software and unsupported systems (rule PM-17)
- P17-A02 Patch Management StandardDefinitions
Step
Enter it in the end-of-life register, with owner and end date
In the pack, every system within 12 months of the end of support, or past it, is in the register with its owner, end date and plan, and reviewed at least quarterly. One row per product is enough where many devices run it. The monthly report counts systems past support that have neither an unexpired exception nor a retirement date; the target is none.
In the pack
- P17-A07 End-of-Life Software & Unsupported System RegisterRegister
- P17-A02 Patch Management StandardMeasures and reporting (rule PCM-04)
- P01-A02 Vulnerability & Exposure Management Standard6. Remediation and verification (rule VM-15)
Decision
Is the system still needed?
Ask the owner, and if the system is no longer needed, retire it now. Often only one function keeps it alive: in the pack's example a storage appliance was still needed only until its scanned delivery notes moved to a share on a supported file server.
- No: Retire it now
- Yes, or not known: Can it move to a supported version or product now?
In the pack
- P17-A07 End-of-Life Software & Unsupported System RegisterOptions (rule EO-1)
- P17-A09 Patch Deferral Request FormA second example: a system past vendor support
Outcome
Retire it now
If it is no longer needed, retire it now rather than protect it. Close its row in the register once it is switched off.
In the pack
- P17-A07 End-of-Life Software & Unsupported System RegisterOptions (rule EO-1)
Decision
Can it move to a supported version or product now?
Upgrading or replacing is the only lasting answer; everything else buys time. Version upgrades are best planned well before support ends: the pack's default is 6 months before, with the system in the register from 12 months before.
- Yes: Upgrade or replace it: the only lasting answer
- Not yet: Does the vendor sell extended security updates for it?
In the pack
- P17-A07 End-of-Life Software & Unsupported System RegisterOptions (rule EO-2)
- P17-A02 Patch Management StandardUpdates with no security content (rule PM-18)
Outcome
Upgrade or replace it: the only lasting answer
Plan the move with a date and an owner, and keep the row in the register until the old version is gone. If the move will take months, answer "Not yet" instead and protect the system until the move is done.
In the pack
- P17-A07 End-of-Life Software & Unsupported System RegisterOptions (rule EO-2)
- P17-A02 Patch Management StandardEnd-of-life software and unsupported systems
Decision
Does the vendor sell extended security updates for it?
Some vendors still release security patches after normal support ends, usually for a fee and for a limited time. Take the dates from the vendor's published lifecycle, not from memory. If you do not know whether it is offered, treat it as unavailable until you have the answer.
- Yes: Buy extended updates for the time replacement takes
- No, or not known: Isolate it: own segment, only the connections it needs
In the pack
- P17-A07 End-of-Life Software & Unsupported System RegisterOptions (rule EO-3)
- P17-A02 Patch Management StandardDefinitions
Outcome
Buy extended updates for the time replacement takes
With extended support the vendor still releases security patches, so patch it as normal. It stays in the register, with its replacement date and the date the extended support is paid to. In the pack's example a weighbridge PC's updates are bought a year at a time until its new software is in.
In the pack
- P17-A07 End-of-Life Software & Unsupported System RegisterOptions (rule EO-3)
- P17-A07 End-of-Life Software & Unsupported System RegisterRegister
Step
Isolate it: own segment, only the connections it needs
Give it its own network segment with only the connections it needs, no internet, no email or browsing, and its administration interfaces off. In the pack's example the storage appliance was reachable only from three goods-in PCs, with its administration interface off, and the isolation was tested before the exception was requested.
In the pack
- P17-A07 End-of-Life Software & Unsupported System RegisterOptions (rule EO-4)
- P17-A07 End-of-Life Software & Unsupported System RegisterControls
Step
Add compensating controls, and test each one
Use application allow-listing, closer monitoring, checked backups and the fewest accounts possible. A control counts only once it has been tested, and it is retested at each quarterly review. An untested control does not lower the exception's risk score, so it can push the decision to a more senior approver.
In the pack
- P17-A07 End-of-Life Software & Unsupported System RegisterOptions (rule EO-5)
- P17-A07 End-of-Life Software & Unsupported System RegisterControls
- P17-A09 Patch Deferral Request FormField guidance
Step
Request an exception, and set a retirement date
Use the patch deferral form with the reason that no patch exists. It is scored as an exception: the band sets the approver, and the expiry is no later than the shorter of the band's maximum and 90 days, which is 30 days for a Critical band. The form's own example ran to the appliance's retirement date. A Critical band decision goes to the board, or a board risk committee it has delegated this to; in a two-tier structure, the management board; where there is no board, executive management.
In the pack
- P17-A09 Patch Deferral Request FormA second example: a system past vendor support
- P17-A07 End-of-Life Software & Unsupported System RegisterOptions (rule EO-6)
- P17-A02 Patch Management StandardWho approves, and for how long
Decision
Is the risk left outside appetite?
Compare the risk that remains after the tested controls with the appetite your risk management process sets for its category. A broken rule is an exception, not a risk acceptance; but where the exception leaves a risk outside appetite, the approver that process requires for that position signs as well, and the stricter of the two applies. If you cannot tell, ask the risk owner before the decision.
- Yes, or not known: The risk approver signs the exception as well
- No: At each quarterly review, will it retire before the exception ends?
In the pack
- P17-A02 Patch Management StandardEnd-of-life software and unsupported systems (rule PM-17)
- P17-A09 Patch Deferral Request FormWho approves, and for how long (rule DA-2)
Step
The risk approver signs the exception as well
The risk approver for that position adds a signature to the same exception. Record the date in the end-of-life register beside the exception's reference and expiry.
In the pack
- P17-A07 End-of-Life Software & Unsupported System RegisterRegister
- P17-A07 End-of-Life Software & Unsupported System RegisterDefinitions
Decision
At each quarterly review, will it retire before the exception ends?
Review every row at least once a quarter, and whenever a vendor announces a new end-of-support date. Retest the controls, and check the exception's expiry against the retirement date. The pack's register warns 30 days before an exception expires.
- Yes: Retire it on its date, and close the exception
- No, or not known: Renew before expiry on a fresh assessment, or escalate
In the pack
- P17-A07 End-of-Life Software & Unsupported System RegisterReviews
- P17-A07 End-of-Life Software & Unsupported System RegisterSummary
Outcome
Retire it on its date, and close the exception
Switch it off or replace it on the retirement date, and close the exception and the register row. The register flags a retirement date that has passed with the system still listed; a system still in use past support without an unexpired exception breaks the pack's rule.
In the pack
- P17-A07 End-of-Life Software & Unsupported System RegisterSummary
- P17-A07 End-of-Life Software & Unsupported System RegisterDefinitions
Outcome
Renew before expiry on a fresh assessment, or escalate
A renewal is a new decision on a new score, made before the exception expires. Each band allows only so many renewals by the same approver; beyond that it goes up a level, so a system that keeps slipping becomes a management decision: fund the replacement, or change the rule.
In the pack
- P17-A09 Patch Deferral Request FormHow to use this form
- P02-A02 Security Exception & Waiver StandardRenewal (rule EX-08)
Practical checklist
- Enter the system in the end-of-life register with its owner, end-of-support date and plan.
- Ask the owner whether it is still needed, and retire it now if not.
- Plan an upgrade or replacement with a date and an owner.
- Check the vendor's published lifecycle for extended security updates, and buy them for the time replacement takes.
- Otherwise isolate it on its own segment with only the connections it needs, and test the isolation.
- Add compensating controls, test each one, and request an exception with an expiry and a retirement date.
- Get the risk approver's signature too if the risk left is outside appetite.
- Review it at least quarterly, retesting the controls, and renew the exception before expiry or retire the system.
Evidence to have ready
- The end-of-life register row, with the options considered, the end-of-support date and the retirement date.
- The isolation details and the test result for each compensating control, retested at each review.
- The approved exception with its band, approver and expiry, and the risk approver's signature where needed.
- The quarterly review records, and the retirement record that closed the row.
Assumptions
- You know the vendor's support dates. The pack takes them from the vendor's published lifecycle, not from memory, and asks for them when a system is bought.
- You have an exception process with risk bands and approvers, and a risk appetite to compare the remaining risk against. The durations shown are the CISO Times packs' defaults; your own standards may set different ones.
- The system's owner can decide whether it is still needed and set a retirement date.
Not covered here
- A supported system whose patch is late, and who approves the delay. That is “Who can approve deferring a patch, and for how long?”.
- A supplier who will not fix a flaw in a product it still supports. That is “If the fix depends on a supplier who won't patch, then how do we manage it?”.
- An exception that has expired with the system still running. That is “If an exception expires and the gap is still there, then what?”.
Related questions
- If the fix depends on a supplier who won't patch, then how do we manage it?
- If an exception expires and the gap is still there, then what?
- How do we score an exception and set how long it lasts?
- If the scanner reports a critical finding on a system nobody owns, then who fixes it?
- Who can approve deferring a patch, and for how long?