The First 72 Hours of a SaaS Breach

Most SaaS breaches aren't decided in the first hour. They're decided when someone, usually a customer's security team or your own general counsel, asks a simple question: what did they touch? If you can't answer it with evidence, every later decision gets harder. That includes containment, notification and the conversation with your SOC 2 auditor. A SaaS incident response plan that reads well in a policy binder often falls apart in practice because it was never tested against that question. Below, we walk through how our analysts actually run the first 72 hours of an investigation, and where smaller SaaS teams most often find out their logs can't support them.

What "Hour Zero" Actually Means

We start the clock at the moment of credible detection, not the moment of compromise. That distinction matters. The attacker may have been in your environment for days or weeks before anyone noticed. Your 72-hour window is about how quickly you move from "something is wrong" to a defensible position. That means a scoped incident, preserved evidence, a working timeline and a clear call on who needs to be told.

Credible detection usually takes one of a few forms:

• An alert from your identity provider (IdP) about an impossible-travel login or an MFA factor reset on an admin account
• A customer reporting suspicious activity in their tenant
• A leaked credential or API key surfacing in a public repo or on a criminal forum
• Unexpected cloud spend, new IAM users, or a security group opened to 0.0.0.0/0

From there, our process roughly follows NIST SP 800-61's incident response lifecycle, compressed into four working blocks.

Window	Primary goal	Key output
Hours 0-6	Contain without destroying evidence	Preserved logs, snapshots, revoked sessions
Hours 6-24	Scope the blast radius	Affected identities, systems, tenants
Hours 24-48	Build the timeline from cloud and IdP logs	Attacker actions, data accessed
Hours 48-72	Decide on notification	Legal and customer communication plan

Hours 0-6: Contain Without Destroying Evidence

The instinct in the first hour is to start deleting things. Kill the compromised instance, rotate every key, wipe the suspicious container. We understand the impulse, but it's the single most common way teams erase the evidence they'll need on day two.

Our analysts work in a specific order.

1. Preserve first. Export IdP system logs, cloud control-plane logs (AWS CloudTrail, Azure Activity Logs, GCP Cloud Audit Logs) and application audit logs to a separate, write-restricted storage location. Take disk and memory snapshots of affected compute before you terminate anything.
2. Revoke sessions, not just passwords. Resetting a password doesn't kill an active session token or OAuth grant. Revoke refresh tokens in your IdP, invalidate API keys, and remove suspicious OAuth app consents.
3. Isolate rather than destroy. Move compromised instances into a quarantine security group with no egress. The workload stops, the evidence survives.
4. Open an incident log. One running document with timestamps in UTC, who did what, and why. This becomes your chain of custody and, later, part of your SOC 2 evidence package.

That last point sounds administrative, and it is. It's also the document your auditor, your lawyers and your customers will ask for.

Hours 6-24: Scoping the SaaS Breach

Scoping answers three questions: which identities were compromised, which systems those identities could reach, and which customer tenants sit behind those systems.

We pivot from the initial indicator outward. If the entry point was a stolen engineer credential, we pull every authentication event for that identity across the IdP, cloud console, source control and CI/CD platform. Then we look at what that identity was entitled to do, not just what it did. An engineer with standing admin rights to production databases has a very different blast radius than one who needs a just-in-time approval.

A few patterns we see repeatedly in SaaS environments:

• Shared service accounts used by multiple pipelines, so you can't tell legitimate automation from attacker activity
• Long-lived access keys that were created years ago, are still active, and have broad permissions
• Support tooling with cross-tenant access. An internal admin panel that lets staff impersonate any customer is a gift to an attacker who compromises one support login
• Third-party OAuth integrations with read access to email, file storage or code repositories

Identity is usually the center of gravity. We've covered the broader trend in Identity-Based Attack Surge, but in a live incident the practical point is this: your IdP log is the spine of the investigation.

Hours 24-48: Cloud and IdP Log Triage

With scope defined, our analysts build the attacker timeline. We correlate IdP events (logins, MFA changes, app assignments) with cloud control-plane activity (new IAM roles, snapshot sharing, bucket policy changes) and data-plane events (object reads, database queries, export jobs).

What We Look For First

• Persistence: new users, access keys, OAuth apps, SSH keys, or IdP factors added during the attacker window
• Privilege escalation: role assumptions, policy attachments, group membership changes
• Discovery: bursts of List* and Describe* API calls, often the clearest sign of a human or tool mapping your environment
• Collection and exfiltration: GetObject spikes, database dumps, snapshot copies to external accounts, large export jobs from your own application

The Data-Plane Problem

Here's where most investigations hit a wall. Control-plane logs tell you an attacker could read a storage bucket. Only data-plane logging, such as S3 data events, database query logs or application-level audit trails, tells you whether they did. Many SaaS teams never turned data-plane logging on because of cost or noise. The result is an investigation that can prove access but not prove absence of exfiltration. Legally and contractually, that often means you have to assume the worst.

If you're running workloads in AWS, Azure or GCP and aren't sure which of these logs you're actually collecting, our cloud security services team reviews exactly this before an incident forces the question.

Hours 48-72: Deciding When Customers Must Be Told

By day three you should have enough evidence to make a notification decision. The clock pressure here is real and comes from several directions at once:

• GDPR requires notifying the supervisory authority within 72 hours of becoming aware of a personal data breach, where feasible.
• US state breach laws vary in definitions and deadlines, and several require notice to state regulators as well as individuals.
• SEC rules require public companies to disclose material cybersecurity incidents within four business days of determining materiality.
• Customer DPAs and MSAs frequently impose their own windows, sometimes shorter than any regulation. Pull these contracts early, not on hour 70.

Our analysts don't make the legal call. That belongs to your counsel. What we provide is the evidence that makes the call possible: which data categories were accessible, which were demonstrably accessed, and which tenants are affected. When you're a SaaS processor acting on behalf of customers, the question of who notifies whom gets complicated fast. We unpacked that dynamic in Who Notifies When a Client Gets Breached?.

One practical tip: draft the customer notification in parallel with the investigation, not after it. You'll revise it several times, and that's fine. Starting from a blank page on hour 71 is not.

The Gaps That Leave You Unable to Answer "What Did They Touch?"

Across the investigations our forensic analysis team handles for smaller SaaS companies, the same gaps come up again and again.

Gap	Why it hurts	Fix
Default IdP log retention	Many IdP plans keep sign-in and system logs for weeks, not months. Dwell time often exceeds that	Stream IdP logs to your own SIEM or storage with 12+ months retention
CloudTrail event history only	The console's built-in history covers 90 days and management events only	Create an organization trail to S3 with data events on sensitive buckets
No application audit log	You can't tell which customer records an admin session viewed	Log every admin and support action with actor, tenant and object ID
Shared or generic accounts	Attribution becomes impossible	Individual named accounts, federated through the IdP
Logs writable by admins	An attacker with admin can erase their trail	Separate log account, object lock or immutable storage
Unsynced clocks and time zones	Correlation across sources breaks	Normalize everything to UTC at ingestion

None of these are exotic. They're the kind of thing a SOC 2 auditor will eventually ask about anyway. Fixing them before an incident is cheaper, faster and far less stressful than discovering them during one.

How This Maps to SOC 2 and ISO 27001

If you're pursuing SOC 2 or ISO 27001, your SaaS incident response plan isn't just operational hygiene. It's audit evidence. SOC 2's Common Criteria CC7.3 through CC7.5 cover evaluating security events, responding to incidents and recovering from them. ISO 27001:2022 Annex A addresses the same ground in controls 5.24 through 5.28, including 5.28 on collection of evidence, and control 8.15 on logging.

Auditors increasingly want to see that the plan was exercised: a tabletop, a documented test, or a real incident with a post-incident review. The incident log you opened in hour one is exactly the artifact that satisfies them. For teams building toward a first report, our SOC 2 for SaaS practice ties incident response, logging and evidence collection together so you're not maintaining three parallel spreadsheets.

Where This Week's Vulnerabilities Fit

Three critical disclosures this week illustrate how quickly a SaaS environment can shift from routine to incident, and why the log gaps above matter.

CVE-2026-112346 (CVSS 9.8), OpenHands Software Agent SDK before 1.52.0. The DockerWorkspace and Apptainer workspace launchers bind the sandbox agent server to all network interfaces (0.0.0.0) with an empty session_api_keys list, which disables authentication by default. Anyone who can reach the published container port can send unauthenticated HTTP and WebSocket requests and achieve remote code execution. If your engineering team is experimenting with coding agents on shared dev hosts or cloud VMs, this is exactly the kind of exposure that never makes it into an asset inventory. Remediation: upgrade to 1.52.0 or later. Until then, bind the agent server to localhost, configure non-empty session API keys, and block the published port at the security group or firewall.

CVE-2026-116214 (CVSS 9.1), MacCMS v10 before 2026.1000.4054. The check_msg() function never compares msg_to, so an unauthenticated attacker can request a recovery code to their own mailbox via user/findpass_msg, then submit it to user/findpass_reset with a victim's email or phone number to take over the account. Remediation: upgrade to version 2026.1000.4054 or later, and review password-reset events for mismatched recipients.

CVE-2026-116485 (CVSS 9.8), danmu_api before 1.21.7. When the default TOKEN is used and ADMIN_TOKEN is unset, unauthenticated attackers can POST to /api/env/set, /api/env/add or /api/env/del to set their own admin token, lock out operators, redirect OTHER_SERVER or PROXY_URL for SSRF, and trigger redeployment. Remediation: upgrade to 1.21.7 or later, replace the default token, and explicitly set ADMIN_TOKEN.

All three share a theme we see in real incidents: insecure defaults and broken authentication logic that let an attacker act as a legitimate user. When that happens, the only way to reconstruct what they did is the application and identity logging you put in place beforehand. As of this writing, none of these is listed on CISA's Known Exploited Vulnerabilities catalog, but a CVSS score of 9 or higher with a straightforward attack path is reason enough to patch now rather than wait.

The Takeaway

The first 72 hours of a SaaS breach reward preparation far more than heroics. Teams that come through well aren't necessarily the ones with the biggest security budget. They're the ones who decided months earlier to keep a year of IdP logs, turn on data-plane logging for sensitive stores, give every human a named account, and write down who calls legal. If you can't confidently answer "what did they touch?" for a hypothetical incident today, that's your most important gap, and it's far easier to close now than at hour 48 with a customer on the phone.