5. Incident Detection, Triage and Scoping

Introduction and Context

Digital forensic and incident response work begins long before an investigator images a disk or examines malware. It begins when an organization notices something unusual and must decide whether that signal represents a security incident, how serious it may be, and what should happen next. Detection, triage, and scoping therefore form the decision-making bridge between security monitoring and formal investigation.

Detection identifies potentially hostile, unauthorized, or policy-violating activity. Triage determines whether the signal is credible, how urgently it must be handled, and which response resources are justified. Scoping establishes the breadth of the event: affected users, hosts, accounts, applications, data, time periods, and business processes. These activities are closely related but should not be confused. A detection is an observation; triage is an assessment; scope is an evidence-based statement about extent.

Poor decisions at this stage create two opposite risks. Treating a genuine compromise as a false positive permits adversaries to expand their access. Treating an innocent anomaly as a major incident consumes scarce resources, disrupts business operations, and may destroy useful evidence through unnecessary containment. Effective practice therefore combines technical evidence, business context, threat intelligence, confidence assessment, and risk-based prioritization.

Learning Objectives

After studying this chapter, the reader should be able to:

• distinguish detection, validation, triage, scoping, and incident declaration;
• evaluate alerts using evidence quality, confidence, business impact, and threat context;
• formulate and test investigative hypotheses;
• classify incidents according to severity and urgency;
• preserve volatile evidence while avoiding unnecessary disruption;
• determine the likely scope of compromise across users, systems, identities, networks, and data;
• apply structured decision criteria to competing response priorities;
• recognize legal, ethical, governance, and operational constraints; and
• use automation and analytics without surrendering professional judgment.

From Signal to Defensible Incident Decision

An alert is a notification generated by a security control, user, analyst, or external party. Alerts may originate from endpoint detection and response systems, security information and event management platforms, identity providers, email security gateways, firewalls, cloud audit logs, vulnerability systems, or human reports. An alert is not equivalent to an incident. It is an input to an investigative decision.

A useful operational sequence is:

observe → validate → triage → hypothesize → scope → prioritize → contain or investigate → reassess.

The sequence is iterative rather than strictly linear. New evidence can reduce confidence, expand scope, change severity, or invalidate the original hypothesis. A disciplined team records these changes rather than silently replacing earlier judgments.

Validation asks whether the alert is technically and contextually credible. The analyst examines the raw event, its timestamp, source reliability, affected asset, user activity, preceding and subsequent events, and possible benign explanations. For example, an impossible-travel alert may result from a corporate virtual private network, a cloud proxy, or a mobile carrier rather than account theft. Conversely, an apparently ordinary login becomes more concerning when followed by mailbox-rule creation, token use, and access to sensitive files.

Triage converts validated information into an operational decision. Typical outcomes include closing the alert as benign, monitoring it, escalating it for investigation, declaring an incident, or initiating immediate containment. Triage should be time-sensitive but not evidence-free. The objective is not to prove every detail; it is to make the safest proportionate decision using the information currently available.

Scoping answers the question, “How far does this activity extend?” Scope may be measured across:

• time: earliest suspected activity, dwell time, and last observed activity;
• identity: compromised accounts, privileged identities, service principals, and tokens;
• assets: endpoints, servers, cloud workloads, applications, and network devices;
• access paths: phishing, exposed services, stolen credentials, remote tools, or supply-chain connections;
• data: accessed, altered, encrypted, exfiltrated, or potentially exposed information; and
• business impact: interrupted services, affected customers, regulatory exposure, and operational dependency.

Scope is usually expressed with confidence levels. It is professionally stronger to state “three endpoints are confirmed affected and twelve additional endpoints are suspected” than to present an unsupported total as fact.

Concepts and Terminology for Early-Stage Response

A false positive is an alert indicating suspicious activity when the underlying activity is benign or authorized. A false negative occurs when malicious activity is not detected. False positives create analyst fatigue; false negatives create hidden risk. Detection engineering seeks to reduce both, although they cannot be eliminated entirely.

Confidence is the degree to which available evidence supports an assessment. Confidence is not the same as severity. A low-confidence alert may describe a potentially catastrophic event, while a high-confidence alert may concern a low-impact policy violation.

Severity describes the consequence or potential consequence of an event. Urgency describes how quickly action is required. A moderate-severity event may be urgent if the attacker is active, whereas a severe historical event may require careful investigation but no immediate containment.

A leading indicator suggests that an attack may be developing, such as repeated authentication failures or reconnaissance. A lagging indicator reflects activity that has already occurred, such as confirmed data theft. An indicator of compromise is an observable artifact associated with malicious activity, including a hash, domain, IP address, registry change, process pattern, or suspicious authentication sequence. Indicators must be interpreted in context because legitimate infrastructure can share the same artifacts.

A hypothesis is a provisional explanation that can be tested against evidence. Examples include: “A privileged account was compromised through credential phishing,” or “The alert was generated by authorized administrative activity.” A hypothesis should identify expected evidence and disconfirming evidence.

Volatile evidence is information that can disappear or change when a system is powered off or altered. Examples include memory contents, active processes, network connections, logged-in users, temporary files, and ephemeral cloud credentials. Preservation means taking reasonable steps to maintain evidence integrity and availability for later analysis.

A Framework for Alert Validation and Confidence

Alert assessment benefits from separating four dimensions that are often incorrectly combined: detection reliability, evidentiary confidence, potential impact, and adversary relevance.

First, assess the reliability of the source. A detection based on a well-tested endpoint sensor with complete telemetry normally deserves more initial trust than an unverified user report, although user reports can reveal attacks missed by automated controls. Second, assess corroboration. Independent evidence from identity logs, endpoint telemetry, DNS, proxy records, application logs, and user confirmation increases confidence. Third, assess context. Approved maintenance, a known penetration test, a travel schedule, or a newly deployed application may explain the event. Fourth, assess temporal coherence. A sequence of related events is generally more meaningful than an isolated artifact.

A practical confidence scale may be expressed as:

• Low confidence: a single weak or ambiguous signal with plausible benign explanations;
• Moderate confidence: multiple related observations, but important gaps remain; and
• High confidence: reliable, corroborated evidence directly linking activity to unauthorized behavior.

The scale should be accompanied by a rationale. “High confidence because the endpoint sensor recorded credential dumping, the account authenticated from the same host, and a new privileged token was issued” is more useful than simply recording “high.”

Threat intelligence contributes context rather than certainty. Intelligence may indicate that an IP address, domain, malware family, tactic, or tool is associated with a known threat actor. However, reputation lists can be stale, shared hosting can create misleading associations, and adversaries can use legitimate services. Intelligence should therefore be evaluated for source quality, age, specificity, relevance to the organization, and corroboration with local evidence.

Severity, Business Impact, and Risk-Based Prioritization

Severity classification should reflect both current harm and plausible near-term consequences. A useful model considers:

Risk = likelihood × impact, modified by confidence, exposure, and time sensitivity.

This is not necessarily a numerical formula. It is a reasoning structure. Likelihood is influenced by evidence of malicious intent, exploitability, attacker persistence, and threat intelligence. Impact includes confidentiality, integrity, availability, safety, legal obligations, financial loss, and reputational consequences. Exposure concerns the number and importance of affected assets. Time sensitivity reflects whether the activity is ongoing and whether delay will increase harm.

Organizations commonly define severity levels such as critical, high, medium, and low, but the labels are less important than the criteria. A critical incident might involve active compromise of an identity provider, ransomware affecting essential operations, or confirmed exposure of highly regulated information. A high-severity incident might involve lateral movement on production systems or compromise of a privileged account. Medium severity may include a contained malware infection on a noncritical workstation. Low severity may describe a blocked scan or policy violation with no evidence of compromise.

Business context can change the classification. A single compromised account may be low impact in one department but high impact if it belongs to a payroll administrator, cloud automation identity, or executive with access to confidential negotiations. Technical analysts should therefore consult asset owners, data stewards, legal counsel, and business continuity personnel when classification depends on organizational consequences.

When several alerts compete for attention, priority should consider active adversary behavior, irreversible harm, privileged access, affected business services, evidence volatility, regulatory deadlines, and containment opportunities. Evidence volatility is particularly important: a memory-resident payload or expiring cloud token may deserve immediate collection even when the overall incident severity is still uncertain.

Investigative Hypotheses and Scoping Methods

Hypothesis-driven investigation prevents analysts from collecting large volumes of irrelevant data. A hypothesis should be specific enough to test but flexible enough to be revised. A useful format contains four elements:

1. Claim: what may have happened;

2. Expected observations: what evidence should exist if the claim is true;

3. Alternative explanation: what benign or competing explanation is plausible; and

4. Decision consequence: what action follows if the claim is supported.

Consider the hypothesis: “An attacker used a stolen employee password to access the organization’s cloud environment.” Expected observations might include authentication from an unusual location, absence of a trusted device, use of a new session or token, impossible travel, and subsequent access to cloud resources. An alternative is legitimate use through a corporate proxy. The decision consequence may be token revocation, account protection, and review of all actions performed under the identity.

Scoping begins with a reliable anchor: a confirmed malicious host, account, timestamp, domain, process, or transaction. Analysts then pivot through related telemetry. For an endpoint, they may examine process ancestry, persistence mechanisms, logged-on users, network connections, file creation, and neighboring hosts. For an identity incident, they may examine authentication methods, locations, devices, token issuance, privilege changes, mailbox rules, and accessed applications. For cloud activity, audit logs, control-plane actions, object access, service principals, and configuration changes are central.

A timeline is one of the most effective scoping tools. It should distinguish observed facts from interpretations and identify gaps in logging. The timeline may show initial access, execution, privilege escalation, discovery, lateral movement, collection, exfiltration, and persistence. Analysts should search both backward and forward from the initial alert. Searching only the alert window can miss the initial compromise or later actions.

Scoping should also examine negative evidence. The absence of expected logs does not prove that an action did not occur; retention gaps, sensor failures, clock differences, and attacker log manipulation may explain the absence. Nevertheless, negative evidence can narrow hypotheses when collection is known to be complete.

Preserving Volatile Evidence Without Paralyzing Response

The first responder must balance preservation with containment. Powering off a compromised system may stop an attack but destroy memory evidence. Leaving it connected may preserve volatile state while allowing continued exfiltration or lateral movement. There is no universal answer; the decision depends on threat activity, business criticality, evidence value, legal authority, and available response capabilities.

A preservation plan should identify the evidence most likely to disappear, the least disruptive collection method, the person authorized to approve it, and the chain-of-custody requirements. Common priorities include memory capture, active network connections, running processes, logged-in sessions, open files, temporary credentials, cloud tokens, and relevant logs. Collection tools should be trusted, documented, and tested. Investigators should record the time, system state, tool version, operator, commands, storage destination, and cryptographic hashes where appropriate.

Containment actions can themselves alter evidence. Blocking an address, disabling an account, isolating a host, rotating keys, or removing malware may change logs and system state. This does not mean containment should be delayed indefinitely. It means that responders should document the action, collect high-value volatile information when feasible, and preserve relevant records before making changes.

Legal and organizational authority is essential. Analysts should not access private communications, employee devices, or third-party systems beyond authorized scope. Cloud evidence may involve multiple jurisdictions and providers. Privacy-preserving collection, data minimization, role-based access, and secure evidence storage reduce secondary harm.

Applied Scenario: Suspected Cloud Account Compromise

Background

This illustrative case concerns Meridian Health Services, a fictional organization that operates a cloud-hosted patient appointment platform. Its security operations center receives identity alerts from a cloud access security broker and audit logs from the identity provider.

Situation

At 02:14, the monitoring platform reports a successful login to a finance manager’s account from a country in which the manager has never worked. The same account had authenticated from the organization’s normal office network forty minutes earlier. At 02:21, a new mailbox forwarding rule is created, and at 02:26, the account accesses a cloud storage folder containing financial forecasts. The alert is initially marked medium because the identity provider records the foreign address as belonging to a commercial cloud service.

Analysis

The analyst validates the raw authentication events and confirms that the foreign session used a newly issued token and a device not previously associated with the manager. The manager is contacted through a verified channel and denies the activity. Threat intelligence indicates that the cloud service is frequently abused for credential attacks, but this information is treated as supporting context rather than proof.

The working hypothesis becomes: “The finance manager’s credentials or session token were compromised, and the actor is attempting to collect information through cloud services.” Expected evidence includes additional unfamiliar sessions, mailbox rule activity, storage downloads, consent grants, or unusual forwarding. A competing hypothesis—that the manager used a corporate privacy service—is rejected after verified user confirmation and device mismatch.

The scope review identifies two successful foreign logins, one mailbox rule, access to four storage objects, and no evidence at that point of access to the payment system. Investigation of sign-in logs reveals that the same browser fingerprint accessed another finance account earlier that week, although that account did not show successful downloads. This expands the scope from one account to a possible campaign against finance personnel.

Response Strategy

The incident commander authorizes immediate revocation of active sessions and tokens, removal of the forwarding rule, forced credential reset, and temporary enforcement of phishing-resistant multifactor authentication for the affected group. Before revocation, the team exports relevant identity and audit logs and records the token identifiers and timestamps. Cloud storage access logs are preserved, and legal and privacy representatives are notified because financial information may have been exposed.

The team searches for downloads, external sharing, application consent, privilege changes, and related IP addresses. Endpoint examination is initiated for the manager’s device to determine whether credentials were captured locally. The organization also reviews email logs for the likely phishing message and searches for other recipients.

Outcome

The investigation confirms unauthorized access to the manager’s account and access to financial forecasts, but no evidence of alteration or confirmed external download is found. A phishing message containing a link to a counterfeit sign-in page was delivered to five finance employees. Two accounts were accessed; one was contained before sensitive files were opened. The incident is classified as high severity because it involved unauthorized cloud access and sensitive business information, even though operational systems were not disrupted.

Learning Points

The initial alert severity was revised because business context and corroborating evidence changed the assessment. The case demonstrates that mailbox rules and cloud audit events can be more informative than the original geographic anomaly. It also illustrates the importance of preserving token and audit information before containment, distinguishing confirmed access from suspected exposure, and using a single compromised identity as an anchor for broader scoping.

Operational Challenges and Common Errors

A frequent error is treating alert volume as investigative progress. Large queues encourage rapid closure, but closure without documented reasoning creates hidden risk. Another error is relying on a single indicator, such as an IP reputation score or malware hash. Indicators become meaningful when linked to behavior, identity, asset criticality, and time.

Analysts may also anchor prematurely on the first explanation. An impossible-travel alert may be dismissed as VPN use even when later events indicate token theft. Conversely, a well-known malicious domain may cause analysts to overlook the possibility of a false association. Hypotheses, alternative explanations, and explicit confidence statements reduce cognitive bias.

Other challenges include incomplete telemetry, inconsistent time synchronization, encrypted traffic, overloaded responders, poor asset inventories, unmanaged devices, and third-party dependencies. Cloud environments introduce additional complexity because control-plane logs, data-plane logs, identity logs, and provider-level evidence may be stored separately. Retention periods may be shorter than the time required to recognize an incident.

Organizations should avoid destructive “clean-up” before collection, uncoordinated account disabling, unrecorded changes to firewall rules, and broad searches that expose unrelated personal information. They should also avoid promising that an incident is contained merely because one host was isolated. Containment is a hypothesis requiring continued validation.

Governance, Ethics, and Professional Responsibility

Detection and triage involve surveillance, employee data, communications, and potentially sensitive customer information. Governance should define who may monitor systems, approve containment, access evidence, declare an incident, communicate externally, and engage law enforcement. Policies should be consistent with applicable privacy, employment, breach-notification, sectoral, and evidence-handling requirements.

Professional judgment requires proportionality. Collect only information relevant to the investigative purpose, restrict access according to role, protect evidence from unauthorized alteration, and maintain an auditable record of decisions. Analysts should distinguish fact, inference, and uncertainty in reports. Overstating compromise can cause unnecessary legal and reputational damage; understating it can expose affected individuals and obstruct remediation.

Incident records should support accountability. A mature record includes alert origin, validation steps, hypotheses, evidence sources, confidence, severity rationale, decisions, approvals, containment actions, scope changes, communication, and unresolved questions. Post-incident review should examine not only technical failure but also decision quality, escalation paths, staffing, business assumptions, and control improvement.

Automation, Analytics, and Emerging Practice

Automation can enrich alerts with asset ownership, vulnerability status, identity risk, threat intelligence, previous incidents, and business criticality. It can also execute carefully governed actions such as isolating a host, revoking a token, or collecting a standard evidence package. Automation is most valuable when it reduces repetitive work while leaving high-impact decisions subject to human review.

Statistical and behavioral analytics can establish baselines for login times, data access, process execution, and network relationships. Machine-learning systems may identify deviations that rule-based controls miss, but unusual does not mean malicious. Models can inherit biased training data, produce opaque explanations, and fail when attacker behavior resembles legitimate administration. Analysts should ask what data trained the model, how confidence is calculated, what false-positive rate is acceptable, and how decisions can be audited.

Current practice increasingly emphasizes identity-centric detection, cloud control-plane monitoring, endpoint telemetry, attack-path analysis, and unified case management. Adversaries also exploit legitimate administration tools, stolen session tokens, software-as-a-service integrations, and weaknesses in third-party relationships. Consequently, scoping must extend beyond traditional network boundaries and include identities, APIs, applications, service accounts, and external providers.

Best Practices for Detection, Triage, and Scoping

Effective organizations establish severity criteria before a crisis, maintain current asset and business-ownership inventories, synchronize clocks, preserve adequate logs, and test evidence-collection procedures. They define escalation thresholds and ensure that analysts can reach system owners, legal advisers, privacy officers, and incident commanders at any hour.

For each significant alert, responders should:

1. preserve the original alert and raw evidence;

2. identify the affected asset, identity, and business function;

3. validate the signal using independent sources;

4. record a primary hypothesis and at least one alternative;

5. assess confidence separately from severity;

6. search backward and forward across relevant telemetry;

7. prioritize volatile evidence and irreversible harm;

8. document containment decisions and their evidentiary effects;

9. state what is confirmed, suspected, and unknown; and

10. reassess scope and severity as new evidence arrives.

The quality of early response is measured not by how quickly every alert is closed, but by whether the organization makes timely, proportionate, evidence-based decisions that reduce harm and preserve the ability to learn what happened.

Chapter Summary

Incident detection, triage, and scoping transform uncertain signals into defensible response decisions. Detection supplies an observation; validation tests its credibility; triage determines urgency and handling; and scoping establishes the event’s time, identity, asset, access, data, and business dimensions. Effective decisions separate confidence from severity, use threat intelligence as context, and apply risk-based prioritization based on likelihood, impact, exposure, time sensitivity, and evidence volatility. Hypothesis-driven investigation, timeline construction, corroboration across telemetry, and explicit treatment of uncertainty improve investigative quality. Volatile evidence must be preserved where feasible without allowing preservation concerns to create unacceptable operational harm. Governance, privacy, authorization, documentation, automation oversight, and continual reassessment are essential professional responsibilities.

Key Terms

Alert: A notification indicating potentially suspicious, unauthorized, or policy-violating activity.

Triage: The rapid assessment and prioritization of an alert or suspected incident.

Scoping: Determining the breadth, duration, affected entities, and consequences of an incident.

False Positive: A benign event incorrectly identified as suspicious.

False Negative: Malicious activity that a detection process fails to identify.

Confidence: The degree to which evidence supports an investigative assessment.

Severity: The actual or potential consequence of an event.

Urgency: The speed with which action is required.

Indicator of Compromise: An observable artifact associated with potentially malicious activity.

Threat Intelligence: Information about threats, actors, techniques, infrastructure, and campaigns used to support security decisions.

Hypothesis: A provisional explanation that can be tested against evidence.

Volatile Evidence: Evidence that may disappear or change when a system or session is altered.

Evidence Preservation: Actions taken to maintain the integrity and availability of relevant evidence.

Containment: Measures intended to limit ongoing damage or attacker movement.

Dwell Time: The period during which an adversary remains present before discovery or removal.

Attack Surface: The set of exposed assets, identities, services, and interfaces that may be targeted.

Chain of Custody: The documented history of evidence collection, handling, transfer, and storage.

Risk-Based Prioritization: Ranking response actions according to likelihood, impact, exposure, urgency, and uncertainty.

Review Questions

Short Answer Questions

1. Why is an alert not automatically classified as an incident?

2. Distinguish confidence, severity, and urgency.

3. What types of information are commonly considered volatile evidence?

4. Why should threat intelligence not be treated as conclusive proof?

5. What is the purpose of an investigative hypothesis?

Long Answer Questions

1. Explain the progression from detection through validation, triage, and scoping.

2. Discuss how business impact and asset criticality influence incident severity.

3. Describe a method for scoping a suspected cloud identity compromise.

4. Explain the tension between preserving volatile evidence and containing an active attack.

5. Evaluate the role and limitations of automation and machine learning in triage.

Analytical / Application Questions

1. An administrator logs in from an unfamiliar country, creates a mailbox forwarding rule, and accesses sensitive files. Develop a primary hypothesis, an alternative explanation, evidence to collect, and an initial response priority.

2. A high-confidence malware alert affects a noncritical workstation, while a low-confidence alert concerns a cloud administrator account. Which should be prioritized and why?

3. During an investigation, responders isolate a host before collecting memory. Analyze the evidentiary and operational consequences and propose improvements for future incidents.

22. Multiple Choice Questions with Answers

Question 1

Which statement best distinguishes triage from scoping?

A. Triage determines the breadth of an incident, while scoping validates the alert source.

B. Triage assesses credibility, urgency, and priority, while scoping determines the extent of affected entities and activity.

C. Triage preserves evidence, while scoping declares the incident legally.

D. Triage is performed only after containment, while scoping precedes detection.

Correct Answer: B. Triage assesses credibility, urgency, and priority, while scoping determines the extent of affected entities and activity.

Question 2

An impossible-travel alert is followed by a new mailbox rule and access to sensitive cloud files. What most appropriately increases confidence in compromise?

A. The foreign IP address appears on a generic reputation list.

B. The user confirms the login, but the device is unfamiliar.

C. Independent identity, mailbox, and cloud audit events form a coherent unauthorized sequence.

D. The alert was generated during nighttime hours.

Correct Answer: C. Independent identity, mailbox, and cloud audit events form a coherent unauthorized sequence.

Question 3

Which factor is most likely to justify immediate evidence collection even when incident severity remains uncertain?

A. The evidence is volatile and may disappear quickly.

B. The alert has a low confidence score.

C. The affected asset has no business owner.

D. The event occurred outside normal working hours.

Correct Answer: A. The evidence is volatile and may disappear quickly.

Question 4

What is the principal purpose of formulating an alternative hypothesis during triage?

A. To delay containment until every possibility is disproved.

B. To ensure that only threat-intelligence data is considered.

C. To reduce premature commitment to one explanation and test competing interpretations.

D. To replace technical evidence with managerial judgment.

Correct Answer: C. To reduce premature commitment to one explanation and test competing interpretations.

Question 5

Which statement about threat intelligence is most accurate?

A. A listed malicious IP conclusively proves that the local host was compromised.

B. Threat intelligence provides context whose relevance and reliability must be assessed alongside local evidence.

C. Threat intelligence is useful only after an incident has been contained.

D. Threat intelligence eliminates the need for user or asset-owner validation.

Correct Answer: B. Threat intelligence provides context whose relevance and reliability must be assessed alongside local evidence.

Question 6

A compromised account belongs to a payroll administrator but has produced no confirmed data loss. Which reasoning is most appropriate?

A. The incident must be low severity because no loss is confirmed.

B. The account’s privilege and potential business impact may justify elevated severity despite uncertainty about loss.

C. Severity should be based only on the number of alerts generated.

D. The account should be ignored until a malware sample is found.

Correct Answer: B. The account’s privilege and potential business impact may justify elevated severity despite uncertainty about loss.

Question 7

Which action best supports defensible scoping?

A. Search only the five minutes surrounding the original alert.

B. Use a confirmed malicious account or host as an anchor and pivot across related telemetry backward and forward in time.

C. Assume that systems without alerts were unaffected.

D. Delete irrelevant logs to reduce investigative volume.

Correct Answer: B. Use a confirmed malicious account or host as an anchor and pivot across related telemetry backward and forward in time.

Question 8

Why can powering off a compromised system be problematic?

A. It always permits continued lateral movement.

B. It can destroy volatile evidence such as memory, processes, and active connections.

C. It prevents the organization from changing passwords.

D. It makes all disk evidence legally inadmissible.

Correct Answer: B. It can destroy volatile evidence such as memory, processes, and active connections.

Question 9

Which risk-based priority is most defensible when resources are limited?

A. Handle alerts strictly in the order received.

B. Prioritize events with active adversary behavior, privileged access, high business impact, or rapidly disappearing evidence.

C. Prioritize only alerts with the highest volume of indicators.

D. Close all low-confidence alerts without documentation.

Correct Answer: B. Prioritize events with active adversary behavior, privileged access, high business impact, or rapidly disappearing evidence.

Question 10

What should an incident record clearly distinguish?

A. Confirmed facts, analytical inferences, and unresolved uncertainty.

B. Technical evidence from all business considerations.

C. Containment actions from their possible effects on evidence.

D. Threat intelligence from all local telemetry.

Correct Answer: A. Confirmed facts, analytical inferences, and unresolved uncertainty.