A SaaS Data Breach: The First 72 Hours (Engineering Response)

In the first 72 hours of a suspected SaaS breach, work in order: contain the access without destroying evidence, preserve the logs, find how they got in and what they reached, rotate every credential, then close the hole and prove it with a test. Do not wipe and redeploy first; that erases the trail you need.

This is engineering incident response, not legal advice. Confirm any breach-notification duties with your adviser or lawyer, and bring in a certified forensics firm if the scope or the law requires one.

If you need help running the response or closing the hole afterwards, see how RAITHub would help below. This guide is for a founder or small team who has just seen something alarming, a strange login, a data-leak report, an alert, and needs a calm order of operations. It covers the technical response only. It is not legal advice, does not tell you whether or whom you must notify, and the security work it describes is application-level, against OWASP guidance; it is not a CREST- or PCI-certified penetration test, a compliance attestation, or courtroom-grade forensics.

What should you do first in a suspected breach?

Contain the attacker's access without destroying the evidence of how they got in. The instinct to wipe everything and redeploy is the one to resist: it ends the incident and also erases the only record of the entry point, so you cannot prove it is closed.

Containment that preserves evidence looks like this: revoke the specific sessions and API keys that were abused, block the source if you can identify it, take the affected component out of the serving path (a maintenance page beats a rm), and snapshot the database and logs before you change anything. Keep the compromised system running but isolated if you can; you will want to read it. Assign one person to decide and one to write down every action with a timestamp. A quiet, recorded response beats a fast, panicked one.

What order does the first 72 hours follow?

Phase	Do	Do not
Hour 0–2: Contain	Revoke abused sessions and keys, isolate the component, snapshot the database and logs, start a timestamped log of actions	Wipe, redeploy, or delete anything; that destroys the evidence and the timeline
Hour 2–12: Preserve & assess	Copy logs to a safe place, establish what you actually know versus assume, decide if you need a certified forensics firm and legal counsel	Announce a cause you have not confirmed, or promise users specifics you cannot yet prove
Hour 12–48: Investigate	Find the entry point and the blast radius: which accounts, which data, read or also written	Narrow the scope prematurely; assume more was reachable until you can show it was not
Hour 24–72: Remediate	Rotate every credential, close the hole, add a regression test, restore from a clean point if needed	Rotate one secret and stop; attackers reuse anything you miss
Throughout	Confirm notification duties with your adviser/lawyer; keep the incident record	Treat notification timing as an engineering decision; it is a legal one

The phases overlap. The two rules that hold across all of them: preserve before you change, and assume the worst scope until you can prove a smaller one.

How do you find out how they got in?

Read the logs for the window around the first sign of trouble, and work backwards from what the attacker touched to how they reached it. Most SaaS breaches are not exotic; they are a known class of flaw the logs will point at.

The OWASP Top 10:2025 keeps broken access control in first place and reports that it was found in a large share of tested applications (OWASP A01:2025 Broken Access Control). In practice the common entry points are: a missing server-side authorization check letting one user read another's data by changing an ID, a leaked or hard-coded credential or API key, an exposed admin endpoint, or an injection flaw. Look for requests that returned data for IDs the account should not own, logins from unexpected locations, and spikes to one endpoint. A query that pulls the access pattern from a request log, run read-only on your snapshot:

-- Which accounts did one session touch, and how many distinct tenants?
-- Many distinct tenants from one session is a classic access-control breach.
SELECT session_id,
       count(DISTINCT tenant_id) AS tenants_touched,
       count(*)                  AS requests,
       min(created_at)           AS first_seen,
       max(created_at)           AS last_seen
FROM request_log
WHERE created_at BETWEEN $1 AND $2
GROUP BY session_id
ORDER BY tenants_touched DESC
LIMIT 20;

If you lack the logs to answer these questions, that gap is itself a finding to fix afterwards. If the scope looks large, the data is sensitive, or the law may require it, this is the point to engage a certified forensics firm rather than rely on an internal read of the logs.

What is the blast radius, and how do you scope it?

The blast radius is which accounts and which data the attacker could reach, and whether they only read it or also changed it. Scope it from the attacker's access level outward, and assume the worst until the logs prove otherwise.

Ask, in order: which credential or session was compromised; what could that identity see and do; is there a tenant-isolation boundary that held, or one that failed; and is there any sign of writes, not just reads (new users, changed permissions, altered records, planted data). On a multi-tenant SaaS the critical question is whether the breach stayed inside one tenant or crossed between them, because that changes both the technical fix and, separately, the legal picture your adviser will assess. Reading versus writing matters: a read exposes data, a write can mean you can no longer trust the data until you compare it against a clean backup.

How do you remediate without leaving a way back in?

Rotate every secret the compromised system could reach, not just the one you think was used, then close the specific flaw and pin it with a regression test so it cannot silently return.

• Rotate everything reachable: database passwords, API keys, OAuth client secrets, signing keys, webhook secrets and service-account tokens. Attackers reuse anything you miss. Invalidate all active sessions so stolen session tokens stop working.
• Close the actual hole. If it was broken access control, add the missing server-side ownership check in one shared place, not scattered per handler; for multi-tenant data, back it with row-level security as in the PostgreSQL row-level security guide. If it was a leaked secret, remove it from the code and move it to a secret manager.
• Add a regression test that reproduces the attack and now fails if the hole reopens: log in as one tenant and try to read another's record by ID, and assert a 403. A fix with no test is a fix that comes back.
• Restore from a clean point if data was written, comparing against a backup from before the first sign of compromise.

Keeping production data in an account you own, with synthetic data in development, limits what any single compromise can reach, as described in SaaS security best practices.

What is explicitly outside this engineering response?

Three things, and treating them as engineering decisions is the common, serious mistake:

• Breach-notification duties. Whether, when and whom you must notify (regulators, customers, individuals) is a legal question that depends on your jurisdiction, your contracts and the data involved. This is general information, not legal advice; confirm your obligations with your adviser or lawyer, and do it early, because some clocks start at discovery.
• Certified forensics. If you need an investigation that stands up to a regulator, an insurer or a court, engage a specialist forensics firm. The steps here help you respond and preserve evidence; they are not a certified forensic report.
• Compliance attestations. RAITHub holds no SOC 2 or ISO 27001 certification and issues no compliance attestation. Its security testing is application-level, against OWASP guidance, not a certified penetration test.

How RAITHub would help

RAITHub helps with the engineering side of an incident and, more often, with closing the gap that caused it so it cannot recur.

• Scope: help run the containment-and-preservation steps; read the logs to find the entry point and blast radius; rotate secrets and invalidate sessions; close the flaw with the missing authorization check or row-level security; add a regression test that reproduces the attack; and review the surrounding code against OWASP guidance for the same class of flaw elsewhere.
• Timeline: the immediate response is hours to days; a follow-on hardening pass fits a code rescue engagement (2–4 weeks) or a fixed-scope security-testing audit, confirmed in the written quote.
• You receive: an incident write-up for your records, the fixes and tests in your repository gated in CI, and full IP under NDA. Production data stays in your own cloud account.
• Proof and limits: this site has 400+ tests and database-backed rate limiting without Redis; Sundor Skin runs a security suite that tries to read other buyers' data, with CI failing if a buyer-scoped table lacks row-level security (146 tables, 530+ tests). RAITHub's security testing is OWASP-level, not a certified pentest or forensics; it makes no compliance claim. See the security testing service.

When you don't need us

• You have an incident-response retainer or an in-house security team. Use them; this guide can still order the first hour.
• The scope needs certified forensics or legal counsel. Engage those specialists directly; RAITHub is neither.
• You want engineers placed in your team. RAITHub offers fixed-scope work and dedicated teams, not staff augmentation.

If you have a suspected breach and need the hole found and closed with a test that proves it, contact RAITHub for a security-testing audit after you have contained and preserved the evidence.

Engineering guidance, checked on 11 October 2026. Not legal advice; confirm notification obligations with your adviser or lawyer.

Frequently asked questions

What is the first thing to do in a SaaS data breach?

Contain the attacker's access without destroying evidence: revoke abused sessions and keys, isolate the affected component, and snapshot the database and logs before changing anything. Do not wipe and redeploy first; that erases how they got in, which you need to prove the hole is closed.

Should I take the app offline during a breach?

Isolate the affected part, but preserve it. A maintenance page or revoking the abused access is better than deleting systems, because you still need to read the logs to find the entry point and scope. Keep a timestamped record of every action you take.

Do I have to tell my customers about a breach?

That is a legal question, not an engineering one. Whether, when and whom you must notify depends on your jurisdiction, contracts and the data involved. This article is general information, not legal advice; confirm your obligations with your adviser or lawyer early, as some deadlines start at discovery.

How do I know how they got in?

Read the logs for the window around the first sign of trouble and work backwards from what was touched. The common causes are broken access control (one user reading another's data by ID), a leaked credential, an exposed admin endpoint, or injection. If the logs cannot answer this, that gap is itself a finding to fix.

Which secrets should I rotate after a breach?

Every credential the compromised system could reach: database passwords, API keys, OAuth secrets, signing and webhook keys, and service-account tokens, and invalidate all active sessions. Attackers reuse anything you miss, so rotating only the one you think was used often leaves a way back in.

Is RAITHub's security work a certified penetration test?

No. RAITHub's security testing is application-level, against OWASP guidance, and produces no certification or compliance attestation. If you need a CREST- or PCI-certified penetration test or courtroom-grade forensics, engage a certified specialist firm for that part.