Something Is Wrong With Your SaaS. What Do You Do First? A Founder's Guide to Security Incident Response

Overview

A security incident in your SaaS product is a founder decision before it is a technical task. This guide covers triage, who decides and who must be told, notification clocks, and safe recovery.

Key Points

• Triage, containment, evidence preservation and communication proceed together: learn enough to act safely, and record every decision.
• Judge severity by availability, confidentiality and integrity, and by whether one customer or all are involved.
• Under UK GDPR, a processor notifies its controller without undue delay; a controller notifies the ICO without undue delay and within 72 hours where feasible, unless it is unlikely to risk people's rights and freedoms.
• Close recovery on verified remediation, trusted assets where needed, monitoring and an authorised return, with unresolved risks recorded and owned.

The short answer

When something looks wrong, several jobs run at once: triage, proportionate containment, evidence preservation and communication. You need enough understanding to choose a safe containment step, not a completed investigation. Name one coordinator, agree the next steps, and write down every decision.

This guide is about response, not prevention. The controls that reduce the chance of an incident are covered in the SaaS data security basics guide. It is general information, not legal advice: check the duties that apply to your customers and data, and take legal advice early.

Limit harm without destroying the evidence

The NCSC's incident management guidance describes incident management as the coordinating function for the whole response.

• Isolate access or connectivity to reduce the chance of spread, without wiping anything yet; isolating is not switching systems off.
• Change suspect credentials and end sessions through trusted administration routes, coordinated with the responders.
• Preserve logs and records before routine rotation deletes them.
• Tell the people who must act first: provider, insurer and legal adviser.
• Write it down as you go: time, observation, decision, owner and reason.

Powering off is not the same as isolating: it can destroy volatile evidence in memory and disrupt customer services, so it is not a universal first step. Coordinate changes with the technical responders, weigh service consequences, and record each decision. NIST's SP 800-61 Revision 3 makes the same point: handlers should choose containment actions, because each carries trade-offs.

Ending sessions matters separately from changing a password, as the login choices guide explains. A hypothetical example: on a Friday evening a founder learns an administrator account signed in from an unfamiliar location and downloaded a customer export. Investigate whether the access was unauthorised and personal data was compromised. Once aware of a personal data breach, a business acting as processor must notify the relevant controller without undue delay.

Work out what kind of incident this is

Alerts need triage, and not every incident is a data breach. Triage prevents both mistakes: a false alarm treated as a crisis, and a genuine breach treated as a routine bug. The NCSC suggests judging severity against three questions.

Three questions that set the severity

• Availability: are data or systems unavailable, and what does that stop customers doing?
• Confidentiality: has sensitive data been accessed, leaked or stolen, and whose data is it?
• Integrity: could data or systems have been altered so they can no longer be trusted?

Add a fourth question for multi-tenant software: is this one customer's problem, or does it cross the boundary between customers? A shared-code or shared-credential fault can affect every customer at once.

Who decides, and who must be told first

An incident stalls when nobody is clearly allowed to make an expensive decision. Agree in advance who can take a critical service offline, authorise outside help, and speak to customers. Escalated decision-makers must hold authority for major-impact decisions, with deputies for when the primary contact is unavailable; the NCSC is explicit on both. In a founder-led team that will often be the founder.

Tell early: the technical team, leadership, legal counsel, your provider where the incident touches their platform, and your insurer. The split of responsibility with a provider belongs in your contract. If a provider that processes data for you suffers the breach, its contract should require it to tell you without undue delay.

The notification clocks you cannot improvise

Your duties depend on the role you hold. A controller decides why and how personal data is processed; a processor processes it only on a controller's behalf. A SaaS business is often both at once: processor for customer-stored data, controller for its own staff and account information.

As a processor, notify the relevant controller without undue delay after becoming aware of a personal data breach, and assist its response, as Article 33 and the processor contract terms require. A processor has no general 72-hour waiting period of its own.

As a controller, notify the ICO without undue delay and, where feasible, not later than 72 hours after becoming aware, unless the breach is unlikely to risk people's rights and freedoms. The ICO's guide to personal data breaches explains this. If you notify late, give reasons. Information may be provided in phases, without undue further delay.

Becoming aware does not require certainty about every affected record: it means a reasonable degree of certainty that a security incident has occurred and personal data has been compromised. The ICO's example treats a controller as aware once it knows personal data was accessed, before it knows how entry happened or whether data was copied.

Informing individuals has a higher test. Where a breach is likely to result in a high risk to their rights and freedoms, communicate it without undue delay in clear and plain language, as Article 34 sets out, subject to exceptions: effective encryption making the affected data unintelligible to unauthorised parties, later measures removing the likely high risk, or disproportionate effort, requiring an equally effective public communication or similar measure. Record every breach — facts, effects and remedial action — and document decisions not to notify.

Other laws and contracts may impose separate notice duties. Take legal advice early.

What to say to your customers

Say what you know, say what you do not yet know, and say what happens next. A message claiming more certainty than the investigation supports will need correcting.

• What happened, in plain terms customers can act on.
• What kinds of data were involved, and whether the scope is confirmed.
• What you have done so far to contain the incident and protect accounts.
• What customers should do now, if anything.
• Where to get updates, and a named contact point.

Do not announce a cause before the investigation supports it, state that no data was affected before the scope is established, or blame a provider, employee or customer. Coordinate lawful disclosure with counsel without delaying required notices or omitting mandatory information.

Getting back to normal, safely

Recovery is broader than restoration, and not every incident needs a backup restored. What you restore or correct depends on what was affected: restoring data differs from fixing account access, configuration or code. NIST's recovery guidance in SP 800-61 Revision 3 stresses verifying backups and other restoration assets before use.

• Verify the weakness or cause has been remediated, rather than assuming it has gone.
• Where data or systems were affected, restore only from trusted assets, checking a selective restore does not expose another customer's data.
• Correct the access, configuration or application weaknesses the incident exposed, not only the data.
• Return to service with authorisation, in stages where needed, and monitor for recurrence.
• Close recovery against recorded criteria, with unresolved risks documented and owned; anything that cannot yet be returned safely stays out of service.

A partial return, with the affected area still isolated, is defensible when the alternative is restoring a system you cannot yet trust. Where a restore is needed, tested backups matter: the software maintenance guide explains why a backup only counts once a restore has been tested.

Review the response and update the plan

Hold the review while memories are fresh. The NCSC asks whether improvements could have prevented it or enabled earlier detection, whether the response worked, and whether the needed data and tools were available. NIST adds: share lessons as soon as they are identified, not only after recovery. Use the review to fix what slowed the response and update the plan and playbooks.

• What went well, and what should be kept for the next response.
• What slowed the response: missing logs, missing contacts or unclear authority.
• What changes to the plan, playbooks and product follow, each with an owner.

Build the plan before you need it

A short plan is a sensible starting point. The NCSC lists a basic plan's ingredients in its incident management guidance: key contacts, an always-available conference route, basic legal and regulatory guidance, checklists, tracking forms and playbooks. It recommends starting with playbooks for the three to five most likely and highest-risk incident types.

• Named roles and deputies, including who can take a service offline.
• Contact details with two routes per person.
• A severity scale in your own terms.
• Playbooks for the three to five most likely incident types, as a starting point.
• Evidence habits: which logs are kept, for how long, and who can retrieve them.
• Provider and insurer contacts, with contract terms defining who does what.

Practical next steps

This week, write the one-page version: coordinator and deputy, severity examples, the first actions list, and the contact sheet. Then walk one playbook through as a tabletop exercise.

Frequently asked questions

Is every alert an incident?

No, but every alert deserves triage. An alert is a signal to check, not proof. Where a signal is credible and the possible impact serious, escalate and take proportionate protective action before certainty arrives. Scale the response to the evidence: a weak signal may need only a logged check, while signs of active access to customer data justify opening the full process at once.

We run on a cloud provider. Is an incident their problem?

Only in part. A provider is responsible for the parts it operates, under your contract. Your duties remain yours: as processor, notify the relevant customer without undue delay; as controller, the regulator and individual tests apply to you. Ask in advance what your provider will do and tell you, and what it cannot do.

Do we need outside help, or can a small team handle this?

It depends on the incident, the access held and the expertise available. A small team may manage coordination, communication and straightforward containment where it has the access and skills to act safely. Outside help is valuable for forensics, legal advice and unclear or large-scale causes. Agree those routes in advance, including out-of-hours.

Sources

Information Commissioner's Office — Personal data breaches: a guide (latest update shown 20 August 2025; accessed 2 November 2026).

UK GDPR (legislation.gov.uk) — Article 33: Notification of a personal data breach and Article 34, with Articles 4 and 28 on roles and processor assistance (accessed 2 November 2026).

National Cyber Security Centre — Incident management: Plan: Your cyber incident response processes (reviewed 19 September 2019; accessed 2 November 2026).

National Cyber Security Centre — Small Business Guide, Step 1: Prepare for incidents (published 10 June 2019, reviewed 8 October 2020; accessed 2 November 2026).

National Cyber Security Centre — Small Business Guide, Step 3: Resolve the incident (published 10 June 2019, reviewed 8 October 2020; accessed 2 November 2026).

National Cyber Security Centre — Small Business Guide, Step 5: Learn from the incident (published 10 June 2019, reviewed 8 October 2020; accessed 2 November 2026).

National Institute of Standards and Technology — SP 800-61 Revision 3: Incident Response Recommendations and Considerations for Cybersecurity Risk Management (April 2025; accessed 2 November 2026).

For scoping a SaaS product, the project cost calculator gives an indicative cost and timeline from scope and complexity. iCodeLTD's SaaS development service covers SaaS architecture, authentication and account management, backend development, testing and ongoing iteration. To talk through your decisions, use the contact page.