If the fix depends on a supplier who won't patch, then how do we manage it?

Start

The fix depends on a supplier who won't patch

'Won't patch' covers several situations: a vendor with no patch yet, one that has ended support for your version, or a service provider that will not apply a patch on your timetable. Each has a different route. In every case the system still has a named owner in your organisation, even when a provider runs it.

• Then: Keep the finding at its priority; the deadline keeps running

Step

Keep the finding at its priority; the deadline keeps running

Rate the finding exactly as you would any other. The supplier's position changes none of the inputs. 'The vendor has promised a patch' is not a compensating control and does not lower the priority or move the deadline.

• Then: Does the vendor still support your version?

Decision

Does the vendor still support your version?

An unsupported version will never get the fix. Check the vendor's support dates, not the supplier's intentions; the pack's model clause asks software suppliers for at least 12 months' notice of end of support. If you cannot confirm support, treat it as unsupported until you can.

• No, or not known: Record it as unsupported, with controls and a retirement date
• Yes: Does the contract set patch deadlines for the supplier?

Step

Record it as unsupported, with controls and a retirement date

The pack's standard requires every unsupported system to be recorded with its compensating controls and a planned retirement date, and reviewed at least quarterly. Upgrading to a supported version or replacing the product is the real fix. Until then, the controls carry the risk.

• Then: Can you block access, disable the feature or isolate it yourself?

Decision

Does the contract set patch deadlines for the supplier?

Look for a vulnerability management clause: how fast the supplier patches, and whether it must tell you when it cannot. The pack's model clause asks for critical patches within 14 days and high within 30 days of release, or an effective mitigation within those periods. If you cannot find such a clause, answer no.

• Yes: Hold the supplier to the clause, through the contract manager
• No, or not known: Ask for a date, and record the missing clause as a gap

Step

Hold the supplier to the clause, through the contract manager

Ask for the patch date and the mitigation it has applied in the meantime. The pack's clause requires notice within 2 working days when a critical weakness cannot be fixed on time. A service provider that misses a deadline is escalated to your supplier or contract manager under the service agreement. Do not accept the provider's own 'closed' status as proof of a fix.

• Then: Can you block access, disable the feature or isolate it yourself?

Step

Ask for a date, and record the missing clause as a gap

Without a clause you rely on goodwill. Ask for a date and a mitigation in writing. A clause the supplier refused, and which you accepted without, is a known gap: record it as an exception. If it leaves the supplier outside appetite or scored Critical, the risk approver also signs and the risk goes on your risk register. Look at it again at the next reassessment. The pack's fallback accepts the supplier's own timescales if they are no longer than yours and it reports exceptions.

• Then: Can you block access, disable the feature or isolate it yourself?

Decision

Can you block access, disable the feature or isolate it yourself?

These controls are in your hands even when the fix is not. Each changes what an attacker can reach and can be confirmed by a scan or a rule export. For a system a provider runs, the provider may have to make the change, but you can still require it.

• Yes: Apply it, confirm it, and ask whether it changes the priority
• No: Use what you have, and record it as exception evidence

Step

Apply it, confirm it, and ask whether it changes the priority

A control that removes internet exposure, confirmed by an external scan, or isolates the system to named management hosts changes an input. The standard owner may then lower the priority, with the reason recorded. The clock does not restart. If the control is later removed, the finding returns at once to its original priority and deadline.

• Then: Will the fix be in place by the deadline?

Step

Use what you have, and record it as exception evidence

A firewall signature, closer monitoring or extra logging still reduce the risk. They do not change the priority. Record them with the evidence that they work: they will carry the exception request.

• Then: Will the fix be in place by the deadline?

Decision

Will the fix be in place by the deadline?

Count from the finding's detection date, not from the supplier's promise. If the supplier's date falls after your deadline, the answer is no.

• Yes: Fixed, confirmed by your own rescan
• No, or not known: Request an exception before the deadline

Outcome

Fixed, confirmed by your own rescan

Close the finding on a scan that no longer reports it, or other objective evidence of the fixed state. A supplier's email saying 'patched' is not enough on its own.

Outcome

Request an exception before the deadline

The pack's exception standard names both a remediation deadline that will be missed and a supplier that cannot meet a contractual security clause as reasons for an exception. Request it before the deadline passes. The request names the requirement, the risk owner, the controls with evidence that they work, a remediation plan with a date, and an expiry. The supplier's patch date or your replacement plan is that remediation plan.

• Then: Has the supplier committed to a fix before the exception expires?

Decision

Has the supplier committed to a fix before the exception expires?

An exception buys time for a plan. It does not replace one. If the supplier gives no date, or the date keeps slipping, the question is no longer about one finding. It is about whether you can keep relying on this supplier. If you don't know, answer no.

• Yes, with a date: Hold the supplier to its date, and keep the controls in place
• No, or not known: Take the supplier decision to the business owner

Outcome

Hold the supplier to its date, and keep the controls in place

Check the controls and the supplier's progress at each review of the exception; the pack's default is the monthly register review. Where the contract provides one, the supplier's regular security report should list open critical and high vulnerabilities, so you can see the date slip before the exception runs out.

Outcome

Take the supplier decision to the business owner

The business owner who relies on the service decides. The pack's supplier example gives three options when a supplier misses a security deadline: enforce the contract, agree a new date recorded as an exception, or plan exit. Whether you can leave without penalty depends on your contract's termination terms. In the pack, rejecting or exiting a Tier 1 supplier is decided by 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.