Independent thinking. Informed defence.

CISO Times

Intelligence for the people behind the defence.

The CISO Decision Brief

If…, then how…

If a system is past vendor support and can't be replaced yet, then what?

5 decision pointsThe pack behind this answer: Patch Management

Add to board 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.
  1. 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

  2. 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

  3. 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.

    In the pack

  4. 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

  5. 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.

    In the pack

  6. 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

  7. 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.

    In the pack

  8. 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.

  9. 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.

  10. 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.

  11. 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

  12. 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.

    In the pack

  13. 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.

  14. 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.

  15. 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.

  16. 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

Practical checklist

  1. Enter the system in the end-of-life register with its owner, end-of-support date and plan.
  2. Ask the owner whether it is still needed, and retire it now if not.
  3. Plan an upgrade or replacement with a date and an owner.
  4. Check the vendor's published lifecycle for extended security updates, and buy them for the time replacement takes.
  5. Otherwise isolate it on its own segment with only the connections it needs, and test the isolation.
  6. Add compensating controls, test each one, and request an exception with an expiry and a retirement date.
  7. Get the risk approver's signature too if the risk left is outside appetite.
  8. 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