Imagine the email arrives late on a Friday afternoon. A supplier you rely on has identified a serious security risk and wants you to switch its service off. Not next week. Not at the next maintenance window. Now.
Who receives that message?
Who decides whether to act?
Who actually knows how to switch the service off?
Most importantly, what happens to the people who still need to work when it disappears?
Those questions became very real at the end of September when secure file-transfer provider Kiteworks took the unusual step of recommending a precautionary shutdown of customer systems.
What happened at Kiteworks?
On 25 September 2026, Kiteworks advised customers to facilitate a nine-hour precautionary shutdown following what it described as credible threat intelligence from federal intelligence authorities.
The company stressed at the time that the move was preventative and that it had no indication its own systems or customer systems had been compromised.
The shutdown recommendation was subsequently lifted on 27 September. On 28 September, Kiteworks said it had identified and remediated a critical vulnerability and that continuous monitoring during the period had detected no abnormal activity and no evidence of exploitation or customer compromise.
This was not a confirmed data breach. It appears to have been a supplier taking an unusual precaution because the potential consequences justified it.
For customers, however, the operational problem was much the same:
A service they depended on might suddenly have to disappear.
“Cyber resilience isn’t only about recovering after something goes wrong. Sometimes it is about being able to stop doing something before it goes wrong.”
Would the warning reach the right person?
This is where supplier security becomes much more than a procurement questionnaire. Somebody in your organisation needs to receive security notices from critical suppliers. That sounds obvious, but in a small business, school, charity or care provider, the account may have been created years ago by somebody who has since left. Supplier notifications might go to an old IT address, an individual member of staff, the business owner or even an inbox nobody checks outside normal working hours.
A critical security advisory sent at 5.30pm on Friday is not much use if nobody reads it until Monday morning.
The NCSC recommends defining key contacts, escalation criteria and processes for critical decisions as part of incident-response planning. It also recommends accounting for people being unavailable by having more than one contact method and more than one person who can be reached.
This is particularly important for smaller organisations.
There often isn’t a security operations centre watching supplier feeds around the clock. There may simply be an owner, school business manager, IT technician or outsourced support provider juggling dozens of other responsibilities.
“A security warning only protects you if it reaches somebody who understands what it means and has the authority to do something about it.”
Who has permission to make the call?
Receiving the message is only the first hurdle. Suppose a supplier recommends switching off a system used for payroll, transferring sensitive files, safeguarding, finance or customer communication.
Can the IT provider simply disconnect it?
Does the managing director need to approve the outage?
Does the headteacher?
Does somebody need to speak to the data protection officer?
Who makes that decision at 8pm?
A mature response doesn’t require everybody to be available. It requires somebody to have been given the authority in advance.
The NCSC recommends that organisations define roles and responsibilities and empower specific people to make decisions during an incident. It also says incident-response arrangements should be linked to business continuity and disaster recovery rather than treated as a purely technical exercise.
The same principle runs through modern vulnerability management.
Organisations need defined roles and responsibilities for vulnerabilities as they emerge, alongside processes for assessing, prioritising and responding according to the actual risk involved.
That matters because not every security alert requires the same response.
Sometimes the answer is patch. Sometimes isolate. Sometimes monitor and occasionally, as the Kiteworks example demonstrates, the safest answer may be turn it off.
A vulnerability score cannot make the business decision for you
There is another important lesson here. Cyber security teams are surrounded by severity ratings.
Critical. High. Medium. Low.
CVSS 9.8.
CVSS 10.
Useful information, certainly. But it is not the whole risk assessment.
Modern vulnerability-management thinking increasingly combines technical severity with factors such as whether exploitation is occurring, whether the affected system is internet-facing, how likely exploitation is, and what that system actually does for the organisation.
Effective vulnerability management combines traditional CVSS information with sources such as EPSS and CISA’s Known Exploited Vulnerabilities catalogue rather than relying on a vulnerability score alone.
CISA has made a similar shift, arguing that CVSS represents theoretical severity rather than real-world impact and highlighting factors including exposure, known exploitation, exploit automation and technical impact.
For a small organisation, I would add another question – what happens to the business if we take the system away?
“A vulnerability score can tell you something about the technical weakness. It cannot tell you whether switching the system off stops payroll, teaching, care or tomorrow morning’s customer orders.”
That decision requires technical information and business context.
The dangerous bit can be what happens next
There is another side to shutting a service down that deserves much more attention – people still need to work.
If the approved file-transfer platform is unavailable, somebody still needs to send that document. If the normal system is offline, the deadline does not necessarily disappear with it. Without an agreed alternative, people improvise.
A member of staff sends the document through personal email. Someone creates a free account with a consumer file-sharing service. A colleague puts information onto a USB stick. Someone shares their personal cloud-storage link because “it’s only until the proper system comes back.”
Nobody involved needs to be careless or irresponsible. They are simply trying to keep the organisation running.
The original security problem can then create a second one.
“If your business continuity plan is simply ‘tell staff they can’t use the system’, don’t be surprised when good people invent their own continuity plan.”
This is why cyber security cannot sit in isolation from business continuity. The safe alternative needs to be worked out before it is required.
Know which suppliers would hurt if they disappeared
You don’t need a 70-page third-party risk-management framework to start improving this. You do need to know which suppliers matter.
The NCSC recommends maintaining an understanding of your suppliers and identifying those that deserve the greatest attention based on risk. It also specifically warns organisations to consider over-reliance on individual suppliers.
For a small organisation, I would start with four simple questions:
What would stop if this supplier disappeared for 24 hours?
What data or systems can they access?
Who receives their urgent security notifications?
What would we do instead while the service was unavailable?
You may quickly discover that the software licence costing £50 per month is far more operationally important than something costing thousands.
Supplier criticality isn’t determined by the invoice.
It is determined by dependency.
The NCSC’s supplier-assurance guidance similarly recommends asking suppliers how they would handle and recover from an incident and what business-continuity or disaster-recovery arrangements they have for maintaining minimum service levels.
“Your most important technology supplier isn’t necessarily the one you spend the most money with. It is the one whose disappearance causes the biggest problem.”
Don’t forget the human element
One of the parts of effective vulnerability management is to recognise that vulnerability management isn’t simply a technical discipline.
Behind the scanners, patches, vulnerability feeds and dashboards are people working in complex environments, dealing with issues including alert and decision fatigue. That feels increasingly important.
We cannot keep sending businesses more alerts and assume that equals better security.
A small business owner could receive vulnerability notifications from Microsoft, their firewall supplier, accounting software, website platform, backup provider, email security provider and line-of-business applications.
Which one matters first? Who decides?
A long vulnerability list is not a risk assessment. It is the starting point for one.
The job is to turn technical information into a sensible business decision.
Sometimes a supplier shutting things down is a good sign
There is also a positive point worth making about the Kiteworks response – suppliers will inevitably discover vulnerabilities.
Software changes. New research appears. New exploitation techniques emerge.
Vulnerabilities will inevitably emerge over time, which makes continuous monitoring, disclosure processes and clear remediation responsibilities essential.
The existence of a vulnerability is therefore only part of the story.
How the supplier responds matters too.
Do they communicate clearly?
Do they tell customers what action to take?
Do they explain the risk?
Do they provide updates?
Do they fix the problem?
Do they acknowledge uncertainty rather than pretending it doesn’t exist?
Kiteworks made what it itself described as a difficult decision to recommend a temporary customer-wide shutdown. It subsequently said the vulnerability had been fixed and that the threat window passed without evidence of exploitation.
That is very different from quietly hoping nobody notices.
“The test of a technology supplier isn’t whether they will ever find a vulnerability. It is what they do in the hours after they find one.”
Five questions to ask this week
You don’t need to wait for the next supplier advisory to find out whether your plan works. Ask:
Who receives security warnings from our important suppliers?
Who can authorise a system to be disconnected urgently?
Does our IT provider know who to contact out of hours?
What safe alternative would staff use while the service was unavailable?
Which supplier outage would cause us the biggest problem tomorrow morning?
If the answer to any of those is “I’m not sure”, that is useful information. It gives you something practical to fix before the urgent email arrives. Resilience isn’t having a folder marked Business Continuity Plan.
It is knowing what happens next.
“If an urgent supplier warning arrives on Friday evening, somebody needs to see it, somebody needs authority to act, and everybody else needs a safe way to keep working.”
That doesn’t require a huge cyber security team. It requires a little preparation, clear responsibility and an understanding of which technology your organisation genuinely depends on.
For smaller organisations in particular, that can make the difference between a precautionary shutdown being a manageable inconvenience and becoming another incident entirely.
