Five checks to put in front of your technology and security leaders today.
Your backup can restore a database. It cannot reverse a spoiled shipment, recover a missed delivery window or give a customer back the hours your service cost them.
That is why “we have backups” is an incomplete answer to a business risk question.
In October, attackers targeted refrigeration systems at French supermarkets. Cybersecurity Dive reported disrupted cooling and spoiled food. On October 16, France’s national cyber response team warned that attacks were probably still ongoing and identified refrigeration management systems exposed directly to the internet.
The reporting does not establish whether victims had usable backups. The lesson is about the limits of recovery: restoring technology cannot reverse every consequence of its failure.
Before you accept another green security dashboard, ask for evidence of three things: restricted exposure, enforced segmentation and patch deadlines tied to business risk.
Then use these five checks to find the gaps.
1. Find the system that can hurt the business fastest
Start with the consequence, then trace the technology behind it.
For a food business, that might be refrigeration control. For a B2B SaaS company, it might be production administration, identity or the service that processes customer transactions. Different systems require different safeguards. The leadership question is the same: what can go wrong before recovery finishes?
Ask the operating owner and technology lead to identify the few systems where disruption or unauthorized changes would quickly affect customers, revenue or safety.
For each, record:
- Consequence: What happens if it stops or someone changes its settings?
- Tolerance: How long can the business operate before the loss becomes unacceptable?
- Owner: Who can authorize containment, recovery and spending?
“IT handles it” is not an owner. Name a person with decision authority and a technical counterpart who can act.
Include supplier-operated systems. Ask who controls access, who receives security advisories and who must approve a shutdown or emergency change. Put those responsibilities beside the system. If the contract and the operating team give different answers, resolve the gap before an incident forces the decision.
Ask for: A short, ranked system list with consequences and owners. An inventory without business impact does not tell you what to protect first.
2. Prove critical controls are not exposed directly to the internet
Ask: “Which critical control or management interfaces can an outsider reach today, and why?”
For industrial equipment, public internet access to a controller’s management interface should trigger urgent review. CERT-FR recommends removing that exposure and restoring necessary remote access through protected connections.
Have qualified staff reconcile the asset inventory with firewall rules, remote access arrangements and an authorized external exposure assessment. Include vendor connections and equipment maintained outside the central IT team.
Necessary remote access needs an approved, protected route, multifactor authentication at the access gateway where supported, and access limited to the people and systems that require it. Replace default credentials. Remove obsolete accounts.
Check that vendor access can be revoked, sessions are logged and remote connections respect the intended network boundaries. Review the remote access service’s own patch status. A protected doorway still needs maintenance and a working lock.
A public customer application is a different case: internet availability may be its purpose. The question is whether sensitive administrative access has appropriate restrictions.
Ask for: Dated evidence of what is reachable, the reason for each permitted exposure and a remediation owner for anything unjustified.
Coordinate changes with operations and vendors. Disconnecting equipment blindly can create another outage.
3. Test segmentation. A network diagram is not proof
“Separate network” sounds reassuring. Ask what traffic is actually blocked.
CISA’s segmentation guidance describes boundaries that separate systems and restrict communication. The useful question is whether those restrictions work in your environment.
Can an ordinary office device reach a critical controller? Can a vendor account access systems beyond its assignment? Can a compromised administrator reach both production and recovery resources?
Have the responsible engineers review permitted paths and validate the boundaries through controlled, authorized testing. Check both that prohibited access fails and that essential operations still work. For sensitive equipment, use methods approved by operations and the manufacturer.
A VLAN label alone does not establish that access is restricted. Ask which rules enforce the boundary and when someone last checked them.
Ask for: A concise test result showing the systems tested, permitted paths, blocked paths, date and unresolved exceptions.
If an unnecessary path remains open, assign its removal. If it must stay open, document the business reason, safeguards and approval. Do not leave the exception ownerless.
4. Give patch risk a deadline—and exceptions an expiry date
“We patch regularly” tells you almost nothing about the system that matters most.
Ask for its installed version, support status, relevant security advisories and outstanding fixes. Prioritize using exposure, evidence of exploitation and the consequence of compromise. A routine monthly cycle may be too slow for an exposed, actively targeted system.
Set remediation deadlines within your approved risk tolerances. Every overdue item needs a named owner and an escalation decision.
For operational technology, patching also carries operational risk. NIST’s OT security guide recommends testing, planned maintenance and recovery preparation. Qualified personnel should assess safety and compatibility before deployment.
If a patch must wait, require an interim protection plan: restrict access, disable an unnecessary vulnerable function where safe, increase monitoring or use another validated control. Record who accepted the residual risk and when the exception expires.
Ask for: A dated remediation list that includes compensating controls for delayed fixes and a replacement plan for unsupported systems.
“The vendor hasn’t scheduled it” describes a dependency. Leadership still owns the risk decision.
Bring the oldest overdue high-risk item to the review. Show its original deadline, the revised date, the interim safeguards and the person approving the delay. A ticket’s new due date should reflect an explicit risk decision rather than a disappearing obligation.
5. Test the business outcome, not just the restore
A successful restore is valuable. Ask what it actually proves.
Did the test show that a file could be recovered, or that the critical service could operate safely within the business’s tolerance? Were configurations, permissions, dependencies and monitoring included where relevant?
For physical operations, establish how staff detect unsafe conditions and act if the normal control system is unavailable. For SaaS, test the customer journey and dependencies needed to resume service.
Include a decision point: when must the business switch to a fallback, pause operations or notify customers? A fallback that takes two hours to start cannot protect a deadline two minutes away.
Ask for: The latest end-to-end exercise result, the time actually achieved and the gaps still open.
Recovery should also address the weakness that enabled the incident. CERT-FR warns that resetting affected refrigeration equipment while leaving it exposed and vulnerable can lead to reinfection.
Make the next leadership meeting produce decisions
Send these checks to your technology, security and operating leaders today. Ask them to bring one page to the next leadership meeting: the critical systems, evidence for each check, failed or unknown items, owners and due dates.
Unknown does not mean compromised. It means leadership lacks evidence to accept the risk confidently.
Escalate known public exposure of critical controllers and evidence of active compromise for immediate technical triage. Give other gaps deadlines based on their business consequences. This is a checkpoint for decisions, not a demand to rebuild the environment overnight.
For enterprise-serving B2B SaaS leaders, TEEVA vCISO provides advisory security leadership through risk-register maintenance, remediation priorities and executive posture reviews. Your technical team or implementation provider performs the engineering work.
Book a Security Leadership Fit Call to discuss whether that leadership support fits your business.
Keep the backups. Find the loss they cannot undo—and close the preventable paths to it.