The First 72 Hours: How Your Security Data Decides the Speed of Your Incident Response

When an incident lands, your team needs answers fast. They need to know which account the attacker used first, what else they touched and when the activity started. How quickly you answer depends less on the tools in your SOC and more on the state of your security data.

Regulators are tightening the clock too. The UK Cyber Security and Resilience Bill proposes an initial notification within 24 hours of an incident, followed by a fuller report within 72 hours. NIS2 follows a similar pattern, with an early warning inside 24 hours and an incident notification inside 72 hours. DORA sets its own tight deadlines for financial entities. In each case you need facts quickly, and those facts live in your logs.

Why Investigations Stall

Delays in the first 72 hours often trace back to the data rather than the people. The same blockers come up again and again:

• Logs sit in several tools, each with its own query language and field names.
• Key sources were never onboarded or were dropped to save on ingest costs.
• Retention runs out before the investigation reaches the first point of compromise.
• Analysts spend hours converting timestamps and matching usernames across systems before any real analysis begins.

Each of these adds hours. Across a 72-hour window, those hours decide whether your first report to the regulator contains facts or estimates.

Hour 0 to 24: Scope the Incident

The first day is about scope. You need to know what happened, which systems are involved and whether the attacker is still active.

Normalised data makes the biggest difference here. When your logs follow a common schema such as the Open Cybersecurity Schema Framework (OCSF), a single query for a user, host or IP address returns results from identity, endpoint, cloud and network sources together. Your analysts stop translating between formats and start building a timeline.

Federated search helps too. Some data will always sit outside your central store. Querying it where it lives, rather than waiting for a bulk export, keeps the first 24 hours moving.

Before your next incident, put 3 things in place:

• Map your top 10 investigation questions to the data sources needed to answer them.
• Run those queries against live data on a quiet day, so the first attempt doesn’t happen under pressure.
• Confirm who holds access to each data source out of hours.

Hour 24 to 48: Build the Timeline

By day 2 you’re working backwards to the initial access point. This is where retention matters. Attackers often sit in an environment for weeks before anyone notices. If your hot storage holds 30 days of data and the intrusion started 45 days ago, your timeline has a gap at the point you need most.

A tiered approach solves this. Keep recent, high value data in fast storage for daily detection work. Move older data into lower cost storage such as Amazon Security Lake, where analysts still search it during an investigation. You keep the history without paying premium SIEM rates to hold it.

Identity data deserves special attention at this stage. Sign-in logs, privilege changes and MFA events show how the attacker moved between systems. Without them, tracing lateral movement turns into guesswork.

Hour 48 to 72: Report with Confidence

The fuller report asks for more than a description of the attack. Regulators want to understand the impact and the steps you’ve taken to contain it. Every statement in your report should trace back to evidence.

A well-structured security data lake gives you an audit trail for each finding. You show the query, the data source and the result. This makes your report defensible, and it saves time when the regulator comes back with follow-up questions.

What to Do This Quarter

You don’t need a major programme to improve your first 72 hours. Start here:

• Run a tabletop exercise built around a 72-hour reporting deadline and record every point where your team waits for data.
• Check your retention periods against the dwell times seen in your own past incidents.
• Identify any critical log sources you’ve dropped from ingest to cut costs and decide whether a lower cost storage tier would let you keep them.
• Review whether your key sources map to a common schema, starting with identity and endpoint data.

The speed of your response is set long before an incident starts. The work you do on your security data now shapes how your first 72 hours play out.

Get In Touch

If you would like to talk through any of the points in this article, our team is happy to help. Visit hoopcyber.com/contact or email .