The incident report was four pages long and marked resolved. The analyst had identified a compromised endpoint in the finance department, isolated it, confirmed the malware had been removed, and submitted the documentation within the required six-hour window. By every procedural measure, the incident was closed.
The CISO read it differently.
In the section describing the timeline, there was a two-hour gap between initial compromise and endpoint isolation. The report noted that the compromised user account had been active during that window but assessed this as "no additional systems affected." What it did not note — because the analyst had not looked — was that the same user account had authenticated to three other systems during those two hours, including the file server where customer contracts were stored.
The incident was not contained. The containment report had simply stopped asking questions before the answers became uncomfortable.
This is not a story about incompetence. It is a story about the boundary between incident response as a process-following exercise and incident response as an investigation discipline. Most security practitioners learn the process first. The investigation discipline — the ability to determine scope accurately rather than optimistically — comes later, if it comes at all.
This article is about what that discipline looks like in practice, why lateral movement is systematically underdetected in post-incident analysis, and what the gap between a closed incident report and a contained incident actually costs.
The Optimism Bias in Incident Scope Assessment
The most consistent error in incident response is not technical. It is cognitive: the tendency to stop investigating once a plausible initial scope has been established, rather than continuing until a definitive scope has been proven.
This bias has structural causes. Incident response timelines create pressure to resolve. Management wants a status update. The process requires documentation. The analyst who has identified the initial compromise and taken containment action has, by every visible process metric, done their job. The question "but have you confirmed there was nothing else?" often has no procedural home — it is not in the playbook, it is not in the SLA, and asking it after containment has been declared can feel like creating more work than the situation warrants.
The result is a systematic gap between what incident reports describe and what actually happened.
A study of post-incident reviews at mid-market organisations consistently finds that in incidents classified as "single endpoint compromise," follow-up forensic analysis identifies additional affected systems in a significant percentage of cases. The additional systems were not mentioned in the original incident report because they were not within the scope of the initial investigation — not because the analyst looked and confirmed they were clean.
There is a meaningful distinction between "no additional systems affected" and "no additional systems detected as affected." Incident reports that use the first formulation when they mean the second are describing a confidence level they do not have.
The CISO who reads incident reports carefully has learned to look for this distinction. When a report says "isolated and contained" without describing the evidence used to determine scope, it reads as incomplete. When a report describes authentication logs reviewed, network connections analysed, and specific systems confirmed clean, it reads as thorough.
The difference in reading is not about experience level. It is about what the report was actually built to answer.
What Lateral Movement Actually Looks Like in Telemetry
The reason lateral movement is missed in post-incident analysis is not that the evidence does not exist. In most environments, it does. The reason it is missed is that the evidence is in a different data source than the one the analyst checked first, and the investigation stopped before all relevant sources were consulted.
Lateral movement leaves traces across multiple telemetry types simultaneously. Understanding where those traces appear — and where they do not — is the foundation of scope assessment.
Authentication logs:
The most reliable indicator of lateral movement is authentication events from the compromised account to additional systems. In Windows environments, Event ID 4624 (successful logon), Event ID 4648 (logon using explicit credentials), and Event ID 4672 (special privilege logon) on non-compromised systems during the dwell window are direct evidence that the compromised account touched those systems.
The critical implementation detail: these events are logged on the target system, not the source system. An analyst who examines only the compromised endpoint's logs will not see authentication to other systems. They will see the logon events that occurred on the compromised system. To detect lateral movement, the analyst must query authentication logs on the systems the compromised account could have reached — which requires a broader scope of log collection than many investigations include.
Network connection logs:
Firewall logs, proxy logs, and network flow data will show connections originating from the compromised endpoint's IP address during the dwell window. A connection from a compromised workstation to an internal server's SMB port, RDP port, or WMI port is a direct indicator of lateral movement attempt regardless of whether it succeeded.
The implementation gap: many organisations collect network logs at perimeter devices but have limited internal network visibility. An attacker moving laterally between endpoints on the same network segment may not generate any log entries at a device that is monitored. Host-based network telemetry — from endpoint detection and response (EDR) tools that log all network connections at the endpoint level — provides visibility that perimeter-only logging cannot.
Process execution logs:
Lateral movement tools — PsExec, WMIExec, Cobalt Strike's jump modules, BloodHound/SharpHound for Active Directory enumeration — generate distinctive process execution patterns. An analyst reviewing Sysmon logs (Event ID 1 — process creation) or EDR process telemetry will see unusual parent-child process relationships, processes spawned from network services, or known lateral movement tool names.
The implementation gap: process execution logging at the required granularity requires Sysmon or equivalent EDR deployment. In environments where this is not deployed, process execution evidence simply does not exist. An analyst in such an environment cannot determine whether lateral movement occurred via process execution — they can only confirm that the logs necessary to detect it were not collected.
Active Directory query logs:
Before moving laterally, attackers typically enumerate the Active Directory environment to identify targets — which systems exist, which users have administrative access, what group memberships are configured. This enumeration is detectable in AD event logs (Event ID 4662 — directory service object access, Event ID 5136 — directory service object modified) but only if AD audit policies are configured to log these events, which is not the default in most deployments.
The Two-Hour Window: Why Dwell Time Determines Scope
In the incident described at the opening of this article, the critical factor was not the compromise itself — it was the two hours between initial compromise and endpoint isolation. Understanding why dwell time is the single most important variable in scope assessment changes how investigations are structured.
Every minute an attacker remains active in an environment is a minute during which they may be taking actions that extend the scope of the incident. The actions that typically occur during dwell time, in roughly the order they occur:
Credential harvesting (0-30 minutes):
The first action most attackers take on a newly compromised endpoint is credential harvesting — dumping cached credentials, reading browser saved passwords, extracting Kerberos tickets. This gives them additional credentials to use for lateral movement and persistence.
The forensic implication: if the dwell time was sufficient for credential harvesting, the incident scope is not limited to what the compromised account could access. It extends to what any harvested credential could access — which may be substantially broader.
Internal reconnaissance (15-60 minutes):
Network scanning, Active Directory enumeration, share discovery — attackers map the internal environment to identify valuable targets before moving to them. This reconnaissance phase generates the AD audit events and network scan signatures described in the previous section.
The forensic implication: reconnaissance does not itself constitute compromise of additional systems, but it tells you what the attacker knew about the environment and therefore where they might have moved.
Lateral movement (30 minutes onward, depending on speed and targets):
Using harvested credentials or built-in tools, the attacker attempts to access additional systems. Not all attempts succeed. Some will leave authentication failures (Event ID 4625) on target systems — which are evidence of lateral movement attempts even when the movement itself did not succeed.
The forensic implication: authentication failures on systems adjacent to the compromised endpoint during the dwell window are strong indicators that lateral movement was attempted. They should trigger investigation of those systems even if no successful authentication occurred.
Data access and staging (variable, depends on dwell time):
If the attacker reaches a file server, SharePoint instance, database server, or other data repository, they will access, compress, and stage data for exfiltration. This phase leaves file access events, unusual data aggregation patterns, and outbound network connections.
The forensic implication: the CISO in the opening scenario was not being paranoid about the file server. They were applying a mental model: two-hour dwell time + user account active + file server accessible = file server should be investigated. The report had not applied this model.
How CISOs Read Incident Reports Differently
The gap between an analyst-written incident report and what a CISO sees when reading it is not about seniority or technical depth. It is about the mental model the CISO applies — a model built on having seen what happens when incidents are declared contained without adequate scope investigation.
The questions a CISO applies to every incident report are rarely stated explicitly. When they read "no additional systems affected," they are mentally asking:
- How was this confirmed? What evidence was reviewed?
- What was the dwell time, and is the scope claim consistent with what could have happened during that dwell time?
- Was the compromised account's activity during the dwell window fully investigated across all systems the account had access to?
- Were adjacent systems — those reachable from the compromised endpoint — examined for authentication events from the compromised account?
- If credential harvesting could have occurred during the dwell time, was the scope extended to cover systems accessible with any credentials that might have been harvested?
An incident report that does not answer these questions in the body of the report has not demonstrated that the investigation was thorough — it has only documented that a process was followed.
The practical consequence: a CISO who does not trust incident report scoping will ask for supplementary investigation, escalate to a third-party forensics engagement, or — in regulated environments — make conservative notification decisions to regulators based on potential scope rather than reported scope.
The analyst who writes thorough reports does not save the CISO's time. They save the organisation from the consequences of being wrong about scope.
What a thorough incident report demonstrates:
- The specific evidence used to establish scope, not just the conclusion
- The systems that were actively investigated and found clean, listed explicitly
- The log sources checked and the time ranges covered
- The dwell time and a specific assessment of what activities were possible during that window
- Any gaps in log coverage that limit the confidence of the scope assessment
- The specific indicators used to identify the initial compromise and whether those indicators were searched for across the broader environment
This level of documentation is not bureaucratic overhead. It is the evidence that the scope assessment was performed rigorously and not optimistically.
The Scope Investigation Framework: What Actually Determines Completeness
Establishing scope in an incident is not the same as investigating the initial compromise. It is a distinct analytical activity that begins after the initial compromise is understood and asks a different question: given what we know about the initial compromise, what is the full set of actions the attacker may have taken?
A structured scope investigation has three components:
Component 1: Affected account analysis.
For every account that was active on the compromised system during the dwell window:
- List every system that account had access to
- Query authentication logs on each of those systems for logon events from that account during the dwell window
- Identify any successful authentications and escalate those systems to active investigation
- Identify authentication failures, which indicate attempted lateral movement even if it did not succeed
Component 2: Network reach analysis.
For the compromised endpoint's IP address during the dwell window:
- Query internal network flow data for all outbound connections
- Identify connections to internal IP addresses, particularly on administrative ports (SMB port 445, RDP port 3389, WMI port 135/DCOM)
- Each identified connection represents a lateral movement attempt and requires investigation of the target system
Component 3: Credential exposure analysis.
Assess whether credential harvesting was possible during the dwell window:
- If sufficient time elapsed (typically 15-30 minutes) for LSASS memory access, assume credential harvesting occurred
- Identify what credentials were accessible on the compromised system — browser saved passwords, cached Windows credentials, Kerberos tickets
- Extend the scope investigation to systems accessible with any of those credentials
The output of this framework is not "scope confirmed: 1 endpoint." The output is either "scope confirmed after investigating X systems, Y accounts, and Z connections with negative results" or "scope extended: additional systems identified for investigation."
The second output is not a failure. It is the correct output of a thorough investigation — and it is significantly better than a false confirmation of containment.
Common Scope Failures and Their Forensic Signatures
Understanding what scope failures look like in the context of a later discovery helps practitioners recognise patterns in their own investigations before the CISO or a forensics team does.
Scope failure pattern 1: The single-system investigation.
The investigation identifies a compromised endpoint and investigates that endpoint thoroughly. Disk forensics, memory analysis, timeline reconstruction — everything about that single system is documented exhaustively. The adjacent systems, accessible from that endpoint during the dwell window, are not examined at all.
The forensic signature of this failure: the investigation report documents extensive analysis of the initial compromise but contains no entries describing examination of adjacent systems. No authentication log queries on other systems. No network flow analysis. No output from queries across the SIEM for account activity during the dwell window.
When a forensics team subsequently examines the environment, they find authentication events on file servers, SharePoint, and Active Directory from the compromised account during the dwell window — events that were in the SIEM the entire time, unqueried.
Scope failure pattern 2: The account-centric blind spot.
The investigation identifies the compromised account and takes appropriate containment action — disabling the account, resetting the password, revoking sessions. The report documents this as comprehensive containment.
What the report misses: if credential harvesting occurred before the account was disabled, the attacker may have harvested additional credentials that are not the compromised account. Disabling one account does not contain an attacker who has harvested and moved with five additional credentials.
The forensic signature: network connections from the compromised endpoint to other internal systems in the period before account containment, followed by authentication events on those systems using different account names but originating from the compromised endpoint's IP.
Scope failure pattern 3: The time-window truncation.
The investigation examines logs for the period from detection to containment but does not examine the period from the initial compromise timestamp backward. Malware on the endpoint may have been present for hours, days, or weeks before detection. The dwell time used in the scope analysis is therefore systematically underestimated.
The forensic signature: endpoint artifacts — prefetch files, registry run keys, file creation timestamps — that indicate the malware was present significantly before the detection timestamp. Authentication events on adjacent systems that predate the detection timestamp, representing lateral movement that occurred during the undetected portion of the dwell time.
Scope failure pattern 4: The log coverage assumption.
The investigation is conducted on the assumption that the log coverage is sufficient to detect lateral movement if it occurred. This assumption is rarely validated. The absence of authentication events in the SIEM is interpreted as evidence that no authentication occurred, when in fact it may mean that authentication events from that system are not being forwarded to the SIEM.
The forensic signature: log forwarding configuration on remote systems shows that the systems the compromised account accessed do not have their Windows Event Logs forwarded to the SIEM. Authentication events exist in the local Security event log on those systems but were never centralised.
Writing the Scope Section of an Incident Report Correctly
The section of an incident report that matters most — and is most commonly written incorrectly — is the scope determination section. Most analysts write this section as a conclusion: "Scope: one endpoint compromised, contained, no additional systems affected." A correct scope section is not a conclusion. It is a documented investigation.
The elements that a scope section must contain to be considered thorough:
The dwell time and its implications:
State the precise dwell time — from the earliest evidence of compromise to the timestamp of effective containment. Then explicitly state what actions were possible during that dwell time and what the scope investigation examined in response.
"The earliest evidence of compromise is [timestamp] based on [evidence]. Containment was achieved at [timestamp]. The dwell time of [N] hours was sufficient for credential harvesting. Accordingly, the scope investigation examined [list of systems] for authentication events from the compromised account and any accounts identifiable from harvested credentials."
The accounts investigated:
List every account that was active on the compromised system during the dwell window. For each account, document what systems it had access to and what authentication activity was identified on those systems during the dwell window.
The systems examined and the evidence reviewed:
Do not just say "adjacent systems were examined." Name them. State what logs were reviewed, what time range was covered, and what was found. "Systems examined: [list]. Authentication logs reviewed on each for the period [timestamp to timestamp]. No logon events from the compromised account were identified."
The network connections investigated:
Describe the network reach analysis — what connections were identified from the compromised endpoint during the dwell window, where they pointed, and what was found when those targets were investigated.
The log coverage limitations:
Any limitations in the scope investigation created by log coverage gaps should be explicitly documented. "Note: [system] does not forward Windows Event Logs to the SIEM. Authentication events on that system during the dwell window could not be confirmed. On-system review confirmed no auth events during the specified window."
This last element — explicitly documenting what could not be confirmed and how that limitation was addressed — is the mark of a thorough investigation. It transforms "no additional systems affected" from an unsupported claim into a documented assessment with appropriate confidence caveats.
The Lateral Movement Indicator Checklist: What to Examine Before Declaring Scope
Practitioners who close incidents accurately have internalised a checklist of lateral movement indicators that they examine before writing the scope assessment. This is not a formal playbook item in most organisations — it is judgment developed through experience and, in many cases, through having been wrong about scope before.
The checklist is organised by log source, which reflects the reality that in time-pressured investigations, knowing where to look quickly is as valuable as knowing what to look for:
Windows Security Event Log (on all systems the compromised account could reach):
- Event ID 4624 — successful logon (look for logon type 3 — network logon, or type 10 — remote interactive)
- Event ID 4625 — failed logon (indicates lateral movement attempts, including where attacker failed)
- Event ID 4648 — logon with explicit credentials (indicates credential reuse or pass-the-hash)
- Event ID 4672 — special privileges assigned (indicates high-privilege access)
Sysmon / EDR telemetry (on the compromised endpoint):
- Event ID 1 — process creation (look for PSExec, WMIExec, net.exe, nltest.exe, mimikatz, procdump)
- Event ID 3 — network connection (shows internal connections from the compromised endpoint)
- Event ID 10 — process access (shows LSASS access — credential harvesting indicator)
Network flow data / firewall internal logs:
- Connections from compromised IP to port 445 (SMB), 3389 (RDP), 135/DCOM (WMI)
- Large data transfers to internal IPs (staging)
- Connections over port 443 to known cloud storage providers (exfiltration)
Active Directory logs (on domain controllers):
- Event ID 4662 — directory service object access (enumeration)
- Event ID 4776 — credential validation (authentication attempts across AD)
- Event ID 4768/4769 — Kerberos TGT/service ticket requests (look for requests from unexpected systems)
Email and file server access logs:
- Mail access by the compromised account during dwell time
- File access and download events on file servers during dwell time
- SharePoint access logs for the compromised account's activity
The completeness of this checklist as actually applied — not in principle but in the specific investigation being conducted — is the determinant of whether the scope assessment can be trusted.
The Regulatory and Legal Consequences of Getting Scope Wrong
For organisations operating under data protection regulations — GDPR, India's DPDPA, RBI guidelines for BFSI entities, HIPAA in healthcare — the scope of an incident is not just an operational question. It is a regulatory one.
Breach notification obligations are typically triggered by whether personal data was actually accessed or exfiltrated, not by whether the incident was categorised as contained. An organisation that declares an incident contained when in fact lateral movement had occurred and data was accessed — and subsequently cannot demonstrate adequate investigation — faces two compounding consequences:
The notification window problem:
GDPR requires notification of supervisory authorities within 72 hours of becoming aware of a breach. The DPDPA in India has its own notification timeline requirements. If an incident is declared contained without adequate scope investigation, the 72-hour clock may have been running from the point the organisation should have known about the broader breach — not from the point they eventually discovered it through supplementary investigation.
An organisation that investigates thoroughly, determines the scope definitively, and notifies appropriately is in a far better regulatory position than one that declares containment, discovers later that the scope was wrong, and must then notify late — because the late notification itself demonstrates that the organisation did not investigate adequately when it had the opportunity.
The "reasonable security" standard:
In regulatory investigations and litigation following data breaches, the standard applied is typically whether the organisation exercised "reasonable security" measures including "reasonable investigation" following an incident. An incident report that declares scope without documenting the investigation methodology used to establish that scope does not demonstrate reasonable investigation.
The organisation that can produce investigation documentation showing every log source checked, every account queried, every adjacent system examined — even if the outcome is that data was accessed — is in a fundamentally better legal position than the organisation whose incident report simply states "no additional systems affected" with no supporting methodology.
This is not just a legal consideration for large enterprises. It applies to any organisation under regulatory oversight that has experienced an incident involving personal data.
Building the Investigation Habit: From Process-Following to Investigation Discipline
The gap between an analyst who follows the incident response process and an analyst who conducts a rigorous scope investigation is not primarily a skills gap. It is a habits gap — specifically, the habit of asking "what else could have happened?" rather than stopping when the initial investigation produces a plausible answer.
This habit is built through deliberate practice in a specific type of scenario: one where the initial finding suggests a limited scope but the full investigation reveals a broader one. Training environments that only expose analysts to single-endpoint compromises — where the "correct answer" is that scope is limited — train analysts to stop when they find the initial compromise. They do not train the investigation muscle of asking what happened next.
The investigation habit has four specific components:
Component 1: The dwell time assessment question.
Before writing any scope statement, ask: what was the dwell time? What actions were possible in that time? Have I investigated the full range of those possible actions? This question should precede any scope conclusion.
Component 2: The "what else could they have used" question.
After identifying the compromised account, ask: what other credentials might have been accessible during the dwell time? Have I extended my scope investigation to cover systems accessible with those credentials, not just systems accessible with the original compromised account?
Component 3: The log coverage validation question.
Before concluding "no lateral movement detected," ask: do I actually have the logs that would show lateral movement? Have I verified that the relevant event sources are collected in the SIEM? Is the absence of evidence here genuine evidence of absence, or is it a logging gap?
Component 4: The hostile reader test.
Before submitting the report, read it as if you were the CISO who does not trust unsupported claims. Does every scope conclusion have documented evidence? Does every "nothing found" statement identify what was looked for and where? Would you trust this report if you had not written it?
These questions do not require additional tools or additional log collection (though those help). They require a change in how the investigation is framed — from "document what I found" to "prove what happened and demonstrate the evidence."
The Incident Report That Changes the CISO's Reading
The analyst in the opening scenario submitted a four-page report. The CISO was not satisfied with it. Consider what a revised report of the same incident would contain that would change that reading.
Same incident. Same underlying facts. Different documentation approach:
"Initial compromise confirmed on [endpoint] at [time] based on EDR alert showing LSASS process access by [malware process]. Endpoint was isolated at [time+2h], establishing a dwell window of 120 minutes.
Scope investigation:
Dwell time assessment: 120 minutes is sufficient for credential harvesting, internal reconnaissance, and lateral movement. Scope investigation was conducted across all three dimensions.
Account analysis: The compromised account [name] was authenticated on the initial endpoint throughout the dwell window. SIEM was queried for logon events (Event IDs 4624, 4648) from this account on all systems to which this account had network access, for the period [time] to [time+2h]. Systems queried: [list of N systems]. Results: no successful authentication events detected on any queried system during the dwell window.
Network reach analysis: Network flow data for [endpoint IP] was reviewed for the dwell window. [N internal connections] identified: [list]. SMB connections to [file server IP] were identified at [time+45min] and [time+67min]. File server [name] was subsequently investigated for authentication and file access events. Authentication events on file server: [specific finding — e.g., 2 successful logons by compromised account]. File access events: [specific finding — e.g., read access to 14 files in contract directory at [time+46min]].
Based on the above, scope is extended to include [file server] as an affected system. Data accessed on file server during dwell window is described in Section 4.
Credential exposure analysis: Sysmon Event ID 10 (LSASS access) confirmed at [time+8min] on initial endpoint. Credential harvesting is assumed. Additionally accessed credentials could not be definitively identified from available telemetry. Scope of systems accessible with potentially harvested credentials was assessed — note in Section 5.
Confidence in scope assessment: Moderate (log forwarding confirmed for all queried systems; one system [name] does not forward auth logs to SIEM, on-system review performed [date] with negative result)."
This report would read very differently to the CISO. Not because it is longer. Because it answers the questions that the first report prompted — and acknowledges the file server finding honestly rather than stopping before the investigation reached it.
Closing: Incident Scope Is One Piece of a Larger Detection Architecture
The ability to determine incident scope accurately — to move from "incident report says contained" to "incident confirmed as contained" — is one critical skill within a broader detection and response capability that defines mature security operations.
The adjacent questions that emerge from a thorough understanding of scope investigation are the ones every security practitioner working in detection and response encounters as their responsibility grows. How do you build a logging architecture that eliminates the log coverage gaps that create false confidence in scope assessments — specifically, what does a logging deployment look like when it is designed for incident investigation rather than just monitoring? When an incident reveals that lateral movement reached a critical system, how do you conduct a full forensic analysis of that system to understand what was accessed, modified, or exfiltrated — and what is the methodology for that investigation? And how do you design detection rules that alert on lateral movement techniques in real time, so that the two-hour dwell window never goes undetected in the first place?
These are detection engineering, forensic investigation, and security architecture questions — and they connect directly to the scope investigation discipline this article describes. Understanding scope assessment in the context of an incident is the application layer. The underlying layers are detection coverage, log architecture, and forensic methodology.
Meritshot's Cyber Security programme builds all of these layers systematically. The curriculum includes live incident simulation exercises where students investigate realistic compromises with realistic log data and must produce scope assessments that are then reviewed against the actual simulated incident — revealing the gaps in their investigation before those gaps matter in a production environment. The programme includes detection engineering modules that connect logging architecture decisions to investigation capability, and forensic investigation case studies derived from real incident post-mortems. Mentorship from practitioners who have written the incident report the CISO questioned and had to do the follow-up investigation connects classroom learning to the reality of getting scope wrong and understanding exactly what was missed. If this article clarified the gap between incident process and incident investigation, Meritshot is where that investigation capability gets built.
Meritshot EdTech — training professionals across Data Science, Investment Banking, Full Stack Development, Cyber Security, and Business Analytics.
