Your SaaS Incident Plan Needs More Than a Restore Button

Connect business continuity, disaster recovery and security response, with tested controls for cloud dependencies and AI agents.

If we had to disconnect an important part of your SaaS platform right now, who could authorise it? Could we show users a clear status message while we contain the incident, or would they simply hit an error page? And how would we decide it was safe to reconnect?

Those questions go further than "do we have backups?" A restore procedure is useful. It does not decide whether an attacker still has access, whether a supplier can help, or who tells customers what is happening. Incident readiness is about making those decisions work together, before the pressure is on.

A useful reminder from a specialised publication

On 16 October 2026, NIST, NSA and CISA published Key Practices for Incident Readiness and Response in Super Intelligence Training and Evaluation. It describes ten voluntary practices across preparation, detection, response, recovery and reporting. The primary audience is organisations training or evaluating highly capable agents on long-running tasks with limited human supervision, not ordinary SaaS teams.

This is not a new legal requirement for your product, and using a coding assistant does not turn you into a frontier-model laboratory. But some principles transfer responsibly: know what activity is allowed, test how to stop it, protect the evidence and verify the controls before resuming. The broader foundation is NIST SP 800-61r3, published in April 2025, which integrates cybersecurity incident response with ongoing risk management and explicitly calls for synchronising continuity and response plans.

Three different jobs, one coordinated response

I would keep the following distinctions clear when discussing readiness with a SaaS team. These are practical descriptions, not interchangeable names for the same document.

These activities can run in parallel. A cloud outage may activate continuity and recovery without a security compromise. Stolen credentials may require security response even while the website remains online. If an AI agent exceeds its authority, that is an incident scenario needing an appropriate playbook, not a fourth replacement for BCP, DRP or security response.

NIST's contingency-planning guidance also separates related plans and stresses coordination. Its older federal terminology is narrower in places, particularly for alternate-site disaster recovery. Here, DRP refers to the practical technical-recovery capability your SaaS business needs.

Start with the service, not the template

Decide what the business must keep doing and what can wait. A read-only product may be preferable to allowing writes you cannot trust. Manual support may be workable; manually processing thousands of payments probably is not. Agree acceptable interruption and data loss with the people who own the customer commitments, then test whether recovery can meet them. Recovery time and recovery point objectives are targets to validate, not promises created by writing them in a policy.

Map the dependencies behind those activities: cloud accounts, identity, DNS, payment and email providers, deployment pipelines and key people. Include the dependencies of your response itself. Can you reach the cloud administrator if SSO is unavailable? Is the incident runbook trapped inside the service you are trying to recover? Can you contact the supplier without using the affected mailbox? Our article on hidden cloud dependencies explains why the supplier register needs more than contract dates and certificates.

Rehearse the hand-offs

Imagine a deployment credential is exposed and a background worker starts changing customer records unexpectedly. Engineering wants to roll back. Support needs an update. The security owner needs access history before a rebuild removes it. Leadership must decide whether to pause the affected feature. Restoring yesterday's database immediately could lose valid transactions while leaving the compromised credential usable.

A useful exercise follows those competing needs through to a decision. It does not end when someone finds the restore button. For a small team, the same person may hold several roles, but the responsibilities and backup person still need to be clear. This is where leadership involvement becomes practical rather than ceremonial.

A practical SaaS readiness checklist

• Ownership and escalation: name the incident lead, deputy and people allowed to isolate systems, pause a feature and approve recovery. Test the contact route outside normal office hours and when your usual identity or chat provider is unavailable.
• Detection: route availability alerts and suspicious activity to someone who can act. An uptime failure is a symptom, not a diagnosis; successful HTTP responses do not prove tenant data is safe.
• Supplier readiness: record emergency contacts, support coverage, access requirements and who can request provider action or export useful logs. Check actual contractual responsibilities rather than assuming "the cloud handles recovery".
• Evidence: preserve relevant audit trails, timestamps, configuration, affected identifiers and a decision log. Record who collected material and protect its integrity and access. Plan safe collection before destructive cleanup where feasible, but do not prolong active harm just to obtain a perfect forensic image. Apply retention rules and avoid copying secrets or personal data unnecessarily.
• Containment: test credential revocation, isolation and feature shutdown. Confirm what actually stops, including sessions, queued work, scheduled jobs and retries. A request to revoke access is not proof that access ended. The same distinction appears in our offboarding guidance.
• Communications: prepare a safe internal channel and a customer-update template covering known impact, uncertainty, workarounds and the next update time. Name who assesses contractual, privacy and sector-specific notification duties, records awareness and decisions, and contacts the relevant parties. Do not wait for a final root-cause report to start that assessment.
• Recovery and post-mortem: agree return-to-service gates, validate critical customer journeys and arrange extra monitoring. After recovery, hold a blameless post-mortem: what happened, why, and how well did the response work? Give each incident or exercise finding an owner, a due date and a retest, then check the changes work.

Semonto's lightweight incident workflow includes practical questions for that post-mortem, from detection and escalation to customer updates and follow-up tickets.

Reporting clocks do not wait for the root-cause report

Early reporting is not just good communication. Depending on your legal scope and the event, it can be a duty while the investigation is still under way:

• Belgian NIS2: essential and important entities must report significant incidents to the CCB without undue delay: an early warning within 24 hours and an incident notification within 72 hours of awareness. Trust service providers have a 24-hour incident-notification deadline. See the CCB's reporting guidance. Applicability follows the law, not whether registration is complete.
• Cyber Resilience Act (CRA): since 11 September 2026, manufacturers of in-scope products with digital elements must report actively exploited vulnerabilities and severe product-security incidents. The initial stages are an early warning within 24 hours and a fuller notification within 72 hours of awareness, without undue delay. Not every SaaS service is in scope; our CRA reporting article explains the distinction.
• GDPR: a controller must notify a personal data breach to the competent supervisory authority, such as Belgium's Data Protection Authority (GBA/APD), without undue delay and, where feasible, within 72 hours of awareness, unless the breach is unlikely to create a risk to people's rights and freedoms. Personal data being involved does not, by itself, make every incident reportable.

For the 24/72-hour sequences, both limits run from awareness of the relevant reportable event, not another 72 hours after the warning. GDPR also allows missing information to follow in phases without undue further delay. A processor must inform its controller without undue delay; it does not have its own general 72-hour allowance. Final reports, notices to customers or affected individuals, and other sectoral or contractual duties need their own assessment. Report what is known, label uncertainty and update the report as the facts develop.

Keep investigation material out of public status updates. Be equally deliberate about the tools used to analyse it, including AI assistants. Our guide to handling logs with AI tools covers that boundary.

When an agent can take action, test the controls outside it

A coding or operations agent can create incidents without training a frontier model. It might change production configuration, trigger a deployment, send an unauthorised message or keep executing through a background worker after its visible session stops. Treat its real permissions, downstream jobs and external effects as part of the response scope.

Be precise about terminology. The joint publication defines a super intelligence (SI) control incident narrowly around significant uninstructed actions that defeat operator boundaries. It distinguishes those from actions directed by an adversarial prompt injection. The broader SaaS examples here can include either kind of problem; they are not all examples of that specific NIST-defined category.

My practical adaptation is to test whether an authorised human can stop execution and downstream retries, revoke tool credentials and inspect what changed. Protect monitoring and action logs from the agent being monitored. Preserve relevant instructions, tool calls, approvals and configuration under controlled access; do not assume every provider exposes model internals. In a safe test environment, confirm that access is actually denied after revocation and that queued actions do not resume. Asking an agent to stop is not the same as enforcing a stop outside it.

Recovery needs a decision, not just a green homepage

For a suspected compromise, I would make recovery conditional on a few observable checks:

• Affected credentials and known entry points have been addressed, and possible persistence has been investigated.
• The restoration source and rebuilt environment have been checked for integrity and compromise.
• Critical workflows, tenant access boundaries, data consistency and delayed jobs have been tested.
• Logging, monitoring and containment controls work, including controls for any agent being restarted.
• An authorised owner has approved resumption with the remaining uncertainty and residual risk recorded.

These are suggested gates to adapt, not a universal guarantee that a system is clean. Recovery may be phased or limited while investigation continues. Our backup and recovery-testing article covers the restore mechanics. The additional readiness question is whether the right people can justify reopening the service, with agreed monitoring and rollback conditions.

What useful ISO 27001 evidence looks like

ISO/IEC 27001 provides a risk-based management-system framework, not a promise that incidents never happen. Relevant Annex A areas include incident management and evidence (A.5.24 to A.5.28), security during disruption and ICT readiness (A.5.29 and A.5.30), supplier/cloud arrangements (A.5.19 to A.5.23), and backups, redundancy, logging and monitoring (A.8.13 to A.8.16). Select and justify controls through your risk treatment and Statement of Applicability; this is not a claim that every control applies identically to every company.

In an internal audit, I would follow the evidence from intent to operation: an approved response plan, a realistic exercise record, measured restoration results, a tested revocation or shutdown, a recovery decision and completed improvement actions. Check whether the test covered today's architecture and suppliers. A successful test from before an identity-provider migration may no longer answer the important question.

The same joined-up approach appears in ENISA's NIS2 technical implementation guidance for Commission Implementing Regulation (EU) 2024/2690. The regulation applies to specified digital-service entity categories within NIS2's scope, not automatically to all SaaS companies; ENISA's guidance is non-binding. Neither a checklist, monitoring product nor ISO certificate alone establishes legal compliance.

Start with one scenario you can actually test

You do not need a large crisis-management department to start. Pick one important customer workflow, one plausible disruption and the people who would make the decisions. Run a tabletop exercise, then safely test a real control such as restore access, token revocation or a worker stop. Record what failed and retest the improvement. A tabletop validates decisions; it does not prove the technical mechanism works.

Operational resilience is the outcome we want: continuing what matters, limiting harm and recovering deliberately as conditions change. BCP, DRP and security incident response each contribute something different. The value is in the connections between them.

The PHP vulnerabilities disclosed on 21 October 2026 show why this matters. CERT-EU recommended considering temporary isolation where immediate patching was not feasible. The University of Freiburg, for example, took services offline as a precaution and redirected visitors to an explanation.

That is more than a patching task. Someone needs to assess the risk, decide what can remain available, communicate with users and agree when services can safely return.

Through our fractional CISO work, we help SaaS companies make those decisions with their technical teams. Just as importantly, we help prepare and test the procedures beforehand, so the next urgent security advisory is not the first time these questions get asked.