If your identity platform goes down, staff may lose access to email, payment systems and the recovery plan itself. Backups help, but someone still has to authorize containment, reach the response team and prove that the restored service is safe to reconnect.
The seven steps below cover those decisions and the tests needed to support them. They draw on the UK NCSC’s Preparing for highly disruptive cyber incidents, whose current version is dated October 1, 2026, and joint guidance from CISA and its partners. The examples and exercises apply that guidance to business services and AI agents.
Start with one critical service
Choose a service owner and work through the guide together. In a small team, one person may hold several roles. Assign a deputy for decisions that cannot wait. For organizations operating across Latin America, include each country, legal entity, local service provider and operational time zone in the plan.
What you will have at the end
- A service continuity mapBusiness owners, tolerable downtime, dependencies and manual workarounds.
- A decision matrixAuthority, deputies, escalation thresholds and a decision log.
- A communications packContacts and messages available outside corporate systems.
- A tested recovery pathProtected backups, a timed restore and reconnection criteria.
- An agent containment runbookInventory, credentials, stop mechanisms and restart conditions.
- Agreed decision principlesContainment, ransom demands, public statements and notification duties.
- Exercise recordsThree scenarios, identified gaps, assigned actions and retests.
In the first week, assign decision owners and test the alternative communications channel. Next, map the service’s dependencies and agent access, then schedule a restoration test. Keep the contact sheet and decision matrix available while the technical work continues.
Quick diagnosis: ten questions
Answer yes when you can show a test result, approved decision or current record. Use the gaps to assign work. Even nine positive answers leave a serious problem if the remaining gap is an untested restore.
Where does your preparation need work?
Answer the remaining questions to complete your review list.
Use the result to assign follow-up work. Answers are not saved and reset on reload.
1. Map the services the business must keep running
People: business service owners, operations, technology and supplier managers. Starting effort: two focused workshops, followed by validation with the people who will operate the workarounds.
List services in business terms. “Collect customer payments” is a service. “The ERP” is one of its dependencies. A warehouse may be able to ship using paper delivery notes, but only while it has stock records, approved addresses and a way to prevent duplicate shipments. Capture that detail rather than writing “manual process available.”
- Choose the five services whose loss would cause the most immediate harm. Include safety, statutory and contractual consequences, not just revenue.
- Agree the maximum tolerable downtime with the business owner. Define the minimum capacity that would make the service usable during recovery.
- Set a recovery time objective (RTO) within that tolerance, with time left for validation and unexpected delays.
- Set a recovery point objective (RPO): the amount of recent data the business can afford to lose. Use this to design backup and replication frequency.
- Map identity, network, applications, data, people and suppliers. Record shared dependencies that could stop several services at once.
- Test the workaround with a realistic workload. Measure its capacity, duration, security controls and the reconciliation work it creates.
What happens when identity recovery takes longer?
The service returns on target, with four hours left before the business’s limit.
- RTO · 8 hours
- The target for returning the service.
- RPO · 1 hour
- Acceptable data loss. Determines backup frequency.
- Tolerance · 12 hours
- Maximum outage the business can accept.
Example for an order-processing service. Agree targets and dependency order with the service owner.
Service map: a worked example
| Business service and owner | Collect customer payments · Finance lead |
|---|---|
| Tolerance / objectives | Maximum downtime 12h · RTO 8h · RPO 1h |
| Dependencies | Payment processor, order database, identity service, settlement account and finance staff |
| Manual workaround | Approved bank transfer instructions, a controlled order register and independent payment verification |
| Capacity and exit | Owner records maximum transactions per hour, staffing, expiry and reconciliation procedure |
| Evidence | Dated rehearsal, measured throughput, dependency owners and location of offline instructions |
Prioritize services by business impact, then build a restoration sequence around their dependencies. A lower-priority identity component may have to return before a higher-priority application. Confirm the supplier’s own recovery arrangements and what happens if it cannot meet your requirements.
Deliverable: the service map approved by its business owner, with workarounds stored outside the production systems.
2. Give people the authority to decide
People: executive sponsor, incident lead, security, operations, legal and communications. Decide who can act when the primary owner is unreachable, including at night and on public holidays.
Give each deputy the access, contacts and authority needed to act. Test them during an exercise. Separate the person directing the incident from the person recording decisions, and arrange handovers and rest if the response lasts for days.
Swipe or scroll horizontally to compare all columns.
| Decision | Owner / deputy | Trigger and record |
|---|---|---|
| Isolate affected systems | Incident lead / infrastructure lead | Evidence of active compromise; record safety effects and service impact |
| Restrict or stop agents | Incident lead / platform lead | Abnormal actions, compromised credentials or an affected shared dependency |
| Activate continuity | Operations lead / designated business deputy | Projected disruption threatens the service objective; do not wait for the tolerance limit |
| Reset privileged access | Identity lead / authorized deputy | Independent requester verification and approval recorded through a trusted channel |
| Engage external response | Incident lead / executive delegate | Pre-agreed severity, procurement authority and insurer conditions |
| Public updates and notifications | Communications and legal / named deputies | Verified facts, applicable obligations and an approved next-update time |
| Respond to a ransom demand | Designated executive or board authority | Escalate with legal, response specialists, insurer and appropriate authorities |
For each decision, record the timestamp and time zone, facts available, alternatives considered, approver, executor and the next review point. Mark what was still unknown when the decision was made.
The joint Scattered Spider advisory, updated July 29, 2025, describes help-desk impersonation to reset passwords and MFA. Recovery creates legitimate pressure for resets, which an attacker can exploit. A familiar voice or an urgent message from an internal account is insufficient proof of identity.
Deliverable: written authority for primary owners and deputies, plus a decision log they can access out of hours.
3. Keep coordination outside the affected environment
People: communications, HR, legal, security and the incident lead. Choose and test an alternative channel before an incident. It should not rely on the same single sign-on, directory, managed devices or recovery email accounts as the compromised environment.
Test an independently administered conference bridge, an approved messaging service or a telephone call tree. Check how participants sign in and recover their accounts. Keep a roster and verify each person who joins.
The Scattered Spider advisory describes attackers monitoring internal communications and joining incident response calls. It also documents malicious federation changes. Verify who is present and review identity trust relationships during recovery, rather than assuming a password reset removes all access.
- Keep an encrypted offline contact pack and a controlled printed copy. Include primary and alternate contacts, time zones, deputies, the incident response provider, insurer and critical suppliers.
- Store policy numbers, contract references, emergency support routes and essential network diagrams with the pack. Restrict access because it contains sensitive operational and personal information.
- Agree staff instructions for reporting suspicious activity and handling devices. Whether a device stays powered on depends on containment, evidence and safety considerations; do not preprint a universal shutdown instruction.
- Schedule regular updates even when there is little new information. Identify the official status channel so customers can distinguish it from impersonation.
Three messages to prepare
Customers: acknowledge the affected service
We are responding to a cybersecurity incident affecting [service]. [Describe the confirmed impact]. Customers can currently [safe workaround]. Our next update will be at [time and time zone] through [official channel]. We are still investigating [specific unknown, if relevant].
Staff: give a clear next action
We are responding to a cybersecurity incident. Do not use [affected channels or services] until further notice. Follow [approved device instruction]. Updates are available through [alternative channel]. Report unusual activity to [verified contact]. Do not approve access resets through unsolicited calls or messages.
Suppliers: verify sensitive requests
We are responding to a cybersecurity incident affecting [confirmed scope]. We have [specific precaution]. Verify requests to change bank details, credentials or access through [previously agreed channel]. Our incident contact is [verified contact]. The next update is scheduled for [time and time zone].
Have legal and communications review these before an incident. Do not assert that data is safe, an attacker has been removed or service will return at a particular time without evidence. Adapt the message to the audience while preserving the same underlying facts.
Deliverable: an offline contact sheet, tested channels and approved message templates.
4. Prove you can recover a critical service
People: infrastructure, identity, application and data owners, security and the response provider. The restoration test should finish with a working business transaction, such as an order placed and reconciled.
The joint #StopRansomware Guide recommends offline, encrypted backups and regular testing of availability and integrity. Include data, applications, identity, configuration, certificates and essential software. Plan how to replace compromised keys and secrets during the restore.
Before the restoration test
- Verify that backup deletion and retention administration are separate from compromised production credentials. Test the controls; an “immutable” label is not sufficient.
- Keep recovery documentation, infrastructure definitions, license information and recovery tooling available without the affected systems.
- Confirm backup frequency meets the RPO, and measured restoration time meets the RTO with validation included.
- Establish clean administrative devices and emergency access protected by strong authentication. Log and review use of emergency accounts.
- Centralize relevant logs under independently protected retention. Confirm that an administrator of the affected host cannot erase the only copy.
- Agree who investigates the incident, who rebuilds, and who accepts the recovered service. These may be different teams.
What must be ready before the next step?
Establish trusted access
Use a clean administration path. Validate identity, network, DNS, keys and emergency access. Resolve their dependencies in your environment.
A responder can authenticate from a clean device without relying on the affected environment.
Example sequence. Resolve dependencies in your own environment; investigation and evidence collection continue throughout.
Run a timed restoration
- Select one critical service. Record the recovery point, source backups and the evidence used to judge them trustworthy.
- Build an isolated recovery environment with clean administration. Resolve identity, network and key-management dependencies.
- Restore configuration, data and applications. Record elapsed time and obstacles at each stage, including time waiting for people or suppliers.
- Validate integrity, access controls, application behavior and a representative user transaction. Review persistence and attacker access with the investigation team.
- Practice reconciling transactions created during manual operation. Avoid duplicate charges, shipments, records and automated retries.
- Compare measured time and data loss with the objectives. Record the gap, owner and deadline, then repeat the failed part.
Before reconnecting, the incident lead and service owner should review evidence of attacker persistence, credential changes, identity trust, monitoring and rollback. Record unresolved questions and decide which ones prevent reconnection.
Deliverable: a timed restore accepted by the service owner, with the dependency sequence and reconnection decision recorded. See the NCSC’s technical recovery guidance for the broader preparation framework.
5. Include AI agents in containment and recovery
People: platform or engineering, security and each business process owner. Agents can continue work through schedulers, background jobs, service accounts and external tools while their human operators are occupied with an incident. Closing the chat window may stop none of those paths.
The joint Careful adoption of agentic AI services, published by the Australian Cyber Security Centre on May 1, 2026 with CISA, NSA and other partners, recommends limited access, oversight and controlled adoption. The runbook below applies those principles to incident containment.
Inventory the execution paths
For each agent, record its owner and deputy, business purpose, host or service, tools and MCP servers, identity, credential references, destinations, triggers, queues, subagents, shared dependencies and stop mechanism. Include agents installed by individual teams. Record where evidence is retained and how to invalidate sessions at the destination.
| Owner / process | Support platform lead / classify and summarize customer cases |
|---|---|
| Execution | Managed worker, ticket webhook, retry queue and scheduled backlog job |
| Access | Ticket read and update API; restricted email connector; model provider key |
| Containment | Pause dispatch and schedules, inspect running jobs, restrict tool access, revoke service sessions and tokens |
| Evidence | Input messages, job IDs, tool calls, authorization decisions, target-system results and configuration version |
| Restart approval | Incident lead and support owner; limited queue, verified credentials, observed first actions |
How to contain a compromised agent
Observe the incident
Identify the affected agent, its owner and the services it can reach. Preserve the records of attempted changes.
Match attempted changes to the source message and the tool records.
Illustrative response. Actions already sent may need to be cancelled or corrected at the destination.
A containment runbook to rehearse
- Declare scope and authority. The incident lead identifies the affected agents, environments and dependencies. Broaden containment when a shared credential, tool or host makes isolation unreliable. Consider safety and continuity before disconnecting operational processes.
- Stop new work and restrict available access. Pause dispatch, schedules and retries. Find running workers and spawned agents. Apply restrictions at configured enforcement points and the connected services. Revoke or rotate affected tokens, sessions and credentials with the identity owner.
- Confirm the stop worked. Use an authorized, non-destructive test to verify an old credential fails and an alternate route cannot perform the restricted action. Check the result at the destination, including paths that bypass the configured gateway.
- Preserve evidence in parallel. Retain relevant inputs, prompts, tool arguments, outputs, decisions, destination logs, versions and timestamps. Protect sensitive data and chain of custody. Preserve records covering the suspected intrusion period and expand the window as the investigation develops.
- Investigate the cause and downstream effects. Review suspicious external content, stolen tokens, altered tools and configurations, injected memory and persistence. Check for both malicious instructions and credential misuse. Identify actions already completed and decide how to reverse or reconcile them.
- Rebuild trust before reactivation. Validate dependencies and agent state, replace compromised credentials, reduce permissions to the agreed task and test rollback. Restart one observed workflow at a time after explicit approval.
Set and measure a containment target appropriate to each process. “Within an hour” may be too slow for a payment agent and unrealistic for an unmanaged fleet. In an exercise, record time to decision, time to stop dispatch, time to revoke access and time to confirm the result separately.
Credentials and agents used by responders
Include agent tokens, model provider keys, secrets in MCP configuration, service accounts and chat, email or ticketing integrations in the credential-reset plan. Revoking a model key does not necessarily revoke access to a database or invalidate a session already created elsewhere.
An investigation assistant should have its own identity, a narrowly defined task, expiring access and a record of its actions. Start read-only where feasible. Treat material from compromised systems as untrusted input and require explicit approval for consequential changes. Do not give an agent standing production administrator access just because the incident is urgent.
Deliverable: an agent inventory, credential checklist and tested containment sequence, including background jobs and service identities.
6. Agree the difficult decisions before the incident
People: the executive sponsor or board, incident lead, operations, legal, finance and communications. Record decisions in terms the on-call team can apply, with named owners and escalation routes.
Controlled disruption
Decide which systems the incident lead can isolate immediately, which require coordination with a safety or service owner, and which workarounds are permitted. Model the consequences of disconnecting identity, a supplier integration or an agent that runs a critical process. Set escalation triggers using expected impact and the time needed to contain and recover.
Ransom demands
The NCSC and UK law enforcement do not encourage ransom payments. Its decision guidance describes uncertainty over recovery, continued compromise and legal risks. A decryptor does not repair the access path or prove that stolen information has been deleted.
Record who has authority to assess a demand and who must be consulted. Legal advisers should evaluate applicable law, sanctions exposure, reporting and contractual obligations for the actual jurisdictions and counterparties. Recovery options should be developed before this conversation becomes urgent.
Reporting and communications across Latin America
Maintain a notification register for each legal entity and service: country, sector, data involved, relevant authority, triggering event, applicable deadline, responsible person and evidence of notification. Legal and compliance should validate it and keep it current.
Include the relevant national or sector CSIRT, data protection authority, industry regulator, contractual notification recipients, insurer and incident response provider. Record official contact channels and the language and time zone of the team handling the report. Cross-border incidents may involve several obligations at once.
Deliverable: approved decision rules covering isolation, agent containment, ransom demands and communications.
7. Exercise the plan, then fix what failed
People: decision owners and deputies, business service owners and technical responders. Use a facilitator who can challenge the plan. For a first exercise, allow about three hours including a debrief.
Begin by removing the services that would be unavailable in the scenario. Participants should not quietly look up contacts or diagrams in a system the exercise says is down. Record decisions, missing information, elapsed time and assumptions. Introduce the next development only after the group has committed to an action.
What would your team do next?
Your payment processor reports ransomware. There is no restoration estimate.
Who activates the alternative payment process? What volume can it handle?
Full scenario for the facilitator
Minute 0: Your payment processor reports ransomware. There is no restoration estimate.
Who activates the alternative payment process? What volume can it handle?
Hour 1: Customers cannot complete orders. Sales wants to keep taking payments.
Which promises can you make? Who approves the customer message?
Hour 4: The supplier says its connection to your network may have been used.
Who can revoke that access? Which evidence must be preserved?
Day 1: The outage continues. A journalist asks whether customer data was stolen.
What is confirmed? When is the next update? Which authority or contractual obligation applies?
Fictional scenarios for discussion. Record a decision before revealing the next event.
What to measure
- How long until someone with authority takes command, including when a deputy is needed?
- Can everyone reach a verified alternative channel using the available devices?
- Can operations sustain the minimum service level, and for how long?
- Can the team demonstrate credential revocation and agent containment rather than describe them?
- Does the restored service meet its time and data-loss objectives, including validation and reconciliation?
- Can legal and communications identify the next required action without inventing facts?
Close with an action register. Give each finding an owner, deadline and retest. For example: “Test the alternate bridge with every deputy by Friday and update the printed roster.”
Choose an exercise cadence based on risk and change. As a starting plan, test a critical restoration every six months, exercise agent containment at least annually, and repeat affected tests after material identity, infrastructure, supplier or agent changes. These are suggested intervals, not a substitute for your obligations. The CISA Tabletop Exercise Packages provide material teams can adapt.
What real disruptions show
These incidents show how a disruption can spread through suppliers, online sales and public services.
Jaguar Land Rover
Production disruption affected the manufacturer and its supply chain. The Cyber Monitoring Centre’s October 2025 assessment estimated a £1.9 billion UK financial impact and more than 5,000 organizations affected. These are modeled economy-wide effects, not a reported ransom or JLR’s own accounting loss.
Test: a critical supplier stops for several weeks. Which services can you sustain, and what cash-flow or inventory constraints appear first?
CMC assessment ↗Marks & Spencer
The company paused online operations during its cyber incident and restored the service in phases. In May 2025 it estimated an approximately £300 million effect on annual operating profit before mitigation. Its later half-year report records home delivery returning in June and click and collect in August.
Test: your customer-facing channel is unavailable. What can stores or support teams actually do without it?
M&S recovery account ↗Collins Aerospace and airports
Brussels Airport reported disruption from the cyber attack on Collins Aerospace, its external check-in and boarding systems provider. Airlines and passengers depended on a supplier the airport did not operate.
Test: your supplier cannot provide a trusted service. Can you operate safely without reconnecting it?
Brussels Airport account ↗Costa Rica
The US Department of State documented disruption to Costa Rica’s customs and tax platforms following the Conti ransomware incident. A government service outage can interrupt the work of businesses that were not directly attacked.
Test: a public platform needed for customs, tax or permits is unavailable. Which manual alternatives are actually authorized?
US Department of State account ↗Final preparation checklist
Business continuity and governance
- Critical services, owners, minimum capacity, RTO, RPO and tolerable downtime agreed.
- Manual workarounds rehearsed with real capacity and reconciliation limits.
- Supplier dependencies and emergency contacts recorded.
- Delegated decisions, deputies, out-of-hours access and handovers tested.
- Decision log and action register available offline.
Communications and recovery
- Alternative channels and participant verification tested.
- Protected contact pack and approved customer, staff and supplier messages ready.
- Backups cover necessary data, applications, identity and configuration.
- Deletion controls, emergency access and log retention verified.
- Critical restoration timed and validated by its business owner.
- Dependencies, investigation findings and reconnection criteria documented.
Agents, decisions and exercises
- Agent owners, tools, credentials, queues, schedules and stop mechanisms inventoried.
- Revocation, running-job handling and evidence preservation tested.
- Restart permissions and monitoring approved per workflow.
- Containment, ransom, public communication and reporting principles recorded.
- Jurisdiction and sector obligations reviewed by legal and compliance.
- Three scenarios exercised, gaps assigned and failed controls retested.
Where Oktsec can help
Oktsec can assess the access paths around a critical service, test agent permissions and support practical training. An assessment has an agreed scope and documented evidence. It does not replace a business continuity owner, legal advice or the incident response team investigating an active compromise.
Control can apply policy to supported, configured agent and MCP traffic. Its audit records can support an investigation; signing and integrity verification depend on the deployed configuration and keys. Records show what the integration observed, not every action across the organization. Direct routes, unmanaged agents and already-issued external actions need separate controls.
Signal and Aguara can support review of agent components. A clean scan does not establish that a component is safe. Training can help a business, university or public-sector team rehearse the manipulated-agent scenario and make its decisions concrete.
Start with one critical service and its connected agents. Oktsec can help test their access and containment paths, then document the findings and agree remediation owners.
Sources and scope
Reviewed October 19, 2026. NCSC preparation and recovery guidance, joint CISA advisories and the primary case accounts below inform this guide. The examples, timing suggestions and exercises are Oktsec’s analysis. Jurisdiction-specific obligations must be validated for the affected organization.
- NCSC: Preparing for highly disruptive cyber incidents, current version October 1, 2026.
- NCSC: Prepare your technical recovery capability.
- NCSC: Prepare to make critical decisions.
- NCSC: Recovering from a highly disruptive cyber attack.
- CISA, FBI, NSA and MS-ISAC: #StopRansomware Guide, September 2023.
- Joint advisory AA23-320A: Scattered Spider, updated July 29, 2025, FBI-hosted copy.
- ASD’s ACSC, CISA, NSA and partners: Careful adoption of agentic AI services, May 1, 2026.
- CISA: Tabletop Exercise Packages.
- Cyber Monitoring Centre: JLR assessment, October 2025.
- Marks & Spencer: full-year results, May 21, 2025, and half-year recovery update.
- Brussels Airport: September 2025 operational update.
- US Department of State: Conti and the Costa Rica incident, May 6, 2022.
Contains information adapted from the UK National Cyber Security Centre under the Open Government Licence v3.0. Adaptations and interactive tools are by Oktsec. No agency endorsement is implied.