Cybersecurity Executive Brief: Four Decisions for Business Resilience

Trusted access, AI authority, recovery, and evidence of readiness.

September 2026 Update

TL;DR: Approving a critical service means accepting a dependency. Decide what it may do, when you would restrict it, and how essential work would continue. Test those choices with the people running the service and someone qualified to assess security. Where the evidence falls short, limit the approval or invest in the missing capability.

If a trusted supplier were compromised, how far could its access reach into your business?

In April, Vercel, a platform used to build and run websites, disclosed an intrusion that began through Context.ai, an artificial intelligence (AI) tool used by an employee. Vercel said the attacker moved through the employee’s connected work account into its environment and reached information associated with a limited subset of customers. Its investigation later identified a small number of additional affected accounts within the same incident.¹

Some exposed information carried the platform’s “non-sensitive” label but could still include credentials: the digital keys to other services. Vercel advised affected customers to replace those keys. Deleting the original connection would not necessarily remove the access they provided (see note 1).

Keeping a connection active may extend an intrusion; cutting it may stop work the business depends on.

1. Plan how to withdraw access #

Before connecting a supplier, establish what it can reach, who can stop it, and what work would be interrupted. Include access obtained through the connection, such as copied credentials or sessions that remain active after someone signs out.

Trivy, a tool used to scan software for security weaknesses, was compromised in March. Aqua reported that attackers retained access after an incomplete credential replacement and later distributed malicious releases.²

CERT-EU, the EU institutions’ cybersecurity service, assessed with high confidence that the compromised tool exposed a European Commission cloud credential. Investigators reported data theft from the affected environment.³ Removing the malicious software alone would not establish that the stolen credential had become unusable.

The team managing the affected systems should trace and revoke exposed credentials, replacing those still needed. Check that retired keys and existing sessions are rejected where access is enforced. Record delays and access that remains usable. A successful check establishes only that the tested path is closed. Whoever assesses security should explain gaps in the evidence and recommend further restrictions.

Consider a hypothetical manufacturer evaluating a supplier’s AI-assisted delivery service. It would update delivery dates when shipment information changes. The proposed connection can read orders and change those dates. The delivery lead can approve its use. The technology team manages the connection, while a security specialist assesses exposure.

Before approval, they examine what would happen if the service made unauthorized changes. Could they block changes while preserving access to the information needed for deliveries? What information would remain exposed?

If the team cannot block unauthorized changes and limit information exposure, plan for full disconnection. Identify which orders could use another process and which would have to pause. Agree who can act immediately and which decisions require escalation, so responders are not negotiating authority during the incident.

2. Give AI permission to act in stages #

Reading an order, suggesting a correction, and changing it are different permissions. The business case should justify each increase in authority.

The delivery lead approves a narrower starting point: the assistant may read only the order and shipment information needed to propose delivery-date updates. Staff verify each proposed date before applying it through the order system. The technology team enforces read-only permissions. Instructions alone would leave that restriction dependent on the assistant’s behaviour.

The manufacturer accepts the cost of manual review while testing whether the assistant improves delivery-date accuracy or saves staff time. Automatic updates remain deferred until the team can demonstrate a worthwhile benefit after review costs, stop unwanted actions, and restore affected records where reversal is possible.

Review effort belongs in that calculation. In May, ISC2 surveyed 856 cybersecurity professionals who used AI in their roles. It found that 65% reported spending more time deciding when to trust recommendations, and 63% more time reviewing or validating outputs.⁴ Those responses do not measure net productivity, but they challenge the assumption that checking work will disappear.

Compare the trial with the current process: correctly updated dates, missed or wrong updates, review time, and rework. Faster suggestions have limited value if staff spend the saved time finding mistakes. Fewer errors may still justify the review cost even without time savings.

Test requests beyond the assistant’s permitted task using controlled systems and test data. Compare its actions with records it cannot alter. A person approving a change needs to see the affected order and the proposed result. Approving a broad task at the start provides less control over later actions.

Keep an explicit stopping mechanism and identify who can use it. Some consequences cannot be reversed, so the decision to automate must also consider what has to be prevented.

3. Measure recovery by what you can deliver #

Containment may interrupt service before a fallback is ready. Recovery planning should identify the customer commitments you can sustain—and those you must reduce or defer.

Stryker’s March incident disrupted enterprise systems and shipping. The medical technology company reported that some patient-specific implant cases were rescheduled because of shipping delays. On April 1, it said its global manufacturing network was fully operational, with production moving toward peak capacity.⁵ Restored systems, available production capacity, and delivery to a customer were distinct milestones.

Boston Scientific’s September disclosures show why the financial assessment can remain open after operations resume. Its filing said the incident was likely to materially affect third-quarter and full-year results, although it did not expect a material effect on its long-term financial condition.⁶ On September 9, it reported restored manufacturing, fulfilment, and shipping, while teams continued clearing backlogs and restoring applications.⁷

For the hypothetical manufacturer, the delivery lead should set the minimum service and expected delays. Follow a representative order from acceptance through production, quality checks, shipping, and delivery confirmation.

Test whether staff can complete that sequence with the affected service unavailable, including any sign-in or data access it normally provides. Verify the records they will use, and test with staffing and workloads realistic for a disruption. A working order screen proves little if the next step depends on unavailable information or authorization.

Include the return to normal work. A manual process may create duplicate entries, missing approvals, or conflicting delivery records. Someone must reconcile them while new orders continue arriving. The delivery lead needs that workload and staffing requirement before promising a recovery timetable. Finance should keep known costs separate from estimates and delayed revenue separate from revenue that may be lost.

Recovery also depends on work a supplier cannot do for you. Canvas is a learning platform used by schools and universities. Its provider, Instructure, described data theft followed by a second incident on May 7 involving altered pages and a precautionary outage.⁸

For an institution using Canvas, the provider’s restoration work addresses only part of the problem. The people responsible for teaching must decide which classes, assignments, and exams can continue during an outage and which must be postponed. IT should confirm that staff can access the required materials through the alternative process. That process also needs a way to transfer work back when the platform returns.

Privacy and security staff have a separate task: establish which institutional information was affected and assess the response required. Reopening a platform does not answer those questions. Request evidence about the institution’s own data, including affected fields, access dates, and relevant logs; make clear what the provider has not established.

4. Revisit approval when the conditions change #

A service can become riskier without gaining new features. A vulnerability, a different connection, or greater dependence on the service may invalidate the assumptions behind its approval.

In September, GreyNoise reported an AI-orchestrated campaign against PaperCut NG/MF, software used to manage printing. At some organizations, it reported administrative access extending beyond the print server.⁹ PaperCut’s September 10 bulletin recommended maintenance releases replacing emergency patches and warned that missing signs of intrusion did not rule out compromise.¹⁰

For an affected organization, installing an update and determining whether an attacker already gained access are separate tasks. Apply the supported remediation and investigate possible access to connected systems. Whoever assesses security should identify remaining exposure and recommend restrictions. If that exposure cannot be addressed promptly, the person accountable for the service must decide whether to restrict or suspend it.

The campaign does not establish that AI defeats every conventional control. It does show why a decision to keep using a service must respond to new evidence.

The manufacturer’s limited approval can also become inadequate without any change to the assistant. If order volumes rise, can the same staff still review proposed dates and run the fallback? If not, the delivery lead needs added capacity or a reduced service commitment.

Compare earlier test conditions with current staffing, workloads, and connections. An exercise shows what worked under the conditions tested; a discussion of a fallback does not demonstrate that staff can operate it. If a live interruption would be unsafe, record the limits of the simulation and what remains untested.

Bring the unresolved issues to someone authorized to decide what happens next. They may accept a demonstrated limitation, fund additional capacity, or narrow the service’s permitted use. Name the person responsible for carrying out the decision and the evidence that would justify reconsidering it.

Start with one service that matters to customers. Ask the people running it to show what would happen if its access had to stop today. Follow the answer far enough to find the first commitment they could no longer meet.

What would you change now to make that commitment achievable?