Incidents, Investigations and Digital EvidenceIntroductionCyber incidents are no longer only technical events. A compromised account, ransomware attack, data loss, insider misuse, or service outage may create legal, regulatory, contractual, financial, and ethical consequences. Organisations therefore need more than tools for detecting malicious activity. They need disciplined processes for deciding what happened, containing harm, preserving reliable evidence, meeting reporting duties, and communicating honestly with affected parties. Incident response is the organised process used to prepare for, detect, analyse, contain, eradicate, recover from, and learn from a security incident. Digital investigation applies systematic methods to discover facts from computers, mobile devices, networks, cloud platforms, applications, logs, and other digital environments. Digital evidence is information of potential value to an investigation or legal proceeding. Its usefulness depends not merely on what it appears to show, but on whether its origin, integrity, handling, and interpretation can be demonstrated. This chapter introduces the practical foundations required of personnel working in cyber law and compliance. It does not replace jurisdiction-specific legal advice. Notification deadlines, investigative powers, privacy rules, evidential standards, and sector obligations differ across countries and industries. A responsible practitioner must identify the applicable law, contract, regulatory guidance, and organisational policy before taking action. Learning ObjectivesBy the end of this chapter, a learner should be able to: - Explain the purpose and stages of incident response.
- Apply appropriate escalation and decision-making processes.
- Distinguish between volatile and persistent digital evidence.
- Preserve evidence and document a defensible chain of custody.
- Recognise requirements for forensic integrity and potential admissibility.
- Coordinate breach assessment and reporting with legal, regulatory, and operational teams.
- Communicate ethically with regulators, customers, employees, suppliers, and law enforcement.
- Identify the limitations and risks of digital investigations, including cloud and AI-enabled environments.
1. Incidents, Events and BreachesAn event is an observable occurrence in a system, such as a failed login, an unusual network connection, or a malware alert. An incident is an event, or group of events, that actually or potentially harms confidentiality, integrity, availability, legal compliance, or organisational operations. A personal-data breach is generally a security incident involving accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to personal data, although the precise legal definition depends on the applicable jurisdiction. These terms should not be used interchangeably. A failed login may be benign. Ten thousand failed logins followed by a successful administrator login may constitute an incident. An incident may become a reportable breach only after the organisation assesses the information involved, the affected individuals, the likelihood of harm, and the governing reporting rules. Common incident categories include: | Category | Examples | Primary concerns |
|---|
| Unauthorised access | Stolen credentials, privilege abuse | Confidentiality, identity misuse | | Malware or ransomware | Encryption, data theft, destructive code | Availability, extortion, recovery | | Data disclosure | Misaddressed email, exposed storage | Privacy, notification, reputational harm | | Integrity compromise | Altered records, manipulated transactions | Reliability, fraud, safety | | Denial of service | Flooding or resource exhaustion | Availability and continuity | | Insider incident | Malicious or negligent employee action | Evidence, employment and privacy law | | Supply-chain incident | Compromised vendor or software update | Shared responsibility and contractual duties |
A useful early distinction is between scope and impact. Scope concerns what systems, accounts, records, locations, and time periods are involved. Impact concerns the consequences, such as financial loss, operational interruption, physical risk, regulatory exposure, or harm to individuals. Both may be uncertain during the first hours of an investigation. 2. The Incident-Response LifecycleA widely used lifecycle contains preparation; detection and analysis; containment, eradication and recovery; and post-incident activity. Different standards use different labels, but the underlying functions are similar. PreparationPreparation includes policies, playbooks, contact lists, asset inventories, logging, backups, access controls, exercises, forensic tooling, legal-retainer arrangements, and training. It also includes deciding in advance who may isolate systems, approve public statements, contact law enforcement, preserve records, and notify regulators. Preparation has a legal dimension. Policies should explain acceptable use, monitoring, retention, investigation authority, privacy safeguards, and escalation. Contracts with suppliers should address security controls, cooperation, evidence access, audit rights, notification, preservation, and allocation of costs. Without preparation, an organisation may lose time debating authority while evidence disappears. Detection and analysisDetection may arise from a security tool, employee report, customer complaint, supplier notification, regulator inquiry, or law-enforcement contact. The receiving person should record the time, source, initial facts, and actions taken. Early records should distinguish confirmed facts from assumptions. Analysis should establish, as far as reasonably possible: - what occurred and when;
- which assets and identities were involved;
- whether unauthorised access or data movement occurred;
- whether the activity is continuing;
- what evidence may be lost through delay;
- whether people, safety, essential services, or personal data are at risk; and
- which legal, contractual, insurance, and regulatory obligations may apply.
Investigators should avoid premature conclusions. A log entry can indicate a possibility, not necessarily prove an attacker’s identity or motive. Containment, eradication and recoveryContainment limits ongoing harm. Short-term actions may include disabling credentials, isolating a host, blocking malicious traffic, or suspending a compromised integration. Long-term containment may involve segmentation, temporary replacement systems, or controlled shutdown. Containment decisions require balance. Disconnecting a machine may prevent further damage but destroy volatile evidence or interrupt critical services. The incident commander should document the reason, authority, expected benefit, risks, and time of each significant action. Eradication removes the cause, such as malware, unauthorised accounts, persistence mechanisms, or vulnerable software. Recovery restores services safely, validates system integrity, monitors for recurrence, and confirms that business processes can resume. Restoring from a backup without understanding the intrusion may reintroduce the attacker. Post-incident activityA post-incident review should examine technical causes, human factors, governance, communication, legal decisions, and the effectiveness of controls. It should produce assigned corrective actions rather than merely a narrative of blame. Lessons may include improved logging, stronger authentication, revised supplier terms, clearer authority, or better notification procedures. 3. Escalation and Incident GovernanceEscalation is the controlled transfer of an issue to people with the authority, expertise, or resources needed to manage it. It is not an admission of failure. Delayed escalation is a frequent cause of avoidable legal and operational harm. A practical escalation model includes: - Triage: record and classify the report.
- Validation: determine whether suspicious activity is credible.
- Severity assessment: consider scope, impact, uncertainty, and urgency.
- Functional escalation: involve security, IT operations, privacy, legal, communications, human resources, risk, or business leadership as appropriate.
- Executive escalation: activate crisis management when strategic, safety, financial, or reputational consequences are material.
- External escalation: coordinate with regulators, law enforcement, insurers, customers, or suppliers when authorised and required.
Severity should not be determined only by the number of affected records. A small incident involving privileged access, health information, child data, critical infrastructure, or a safety system may be more serious than a larger but low-risk event. An incident record should normally include an incident identifier, reporting time, reporter, systems involved, current status, decision owners, evidence locations, actions, approvals, communications, and next review time. The record should be access-controlled because it may contain personal data, security-sensitive details, legal advice, or information relevant to litigation. A single source of operational truth is useful, but it should not mean that every participant has unrestricted access. Teams should receive the minimum information necessary for their role. Legal advice should be handled according to applicable professional and privilege rules; labelling a document “confidential” does not automatically make it privileged. 4. Digital Evidence and Its CharacteristicsDigital evidence includes data stored or transmitted in digital form that may help establish facts. Examples include disk files, email, access logs, database records, cloud audit trails, browser history, mobile-device artefacts, memory contents, CCTV exports, chat messages, and metadata. Important characteristics include: - Volatility: some evidence disappears quickly, especially memory contents, active network connections, process states, and temporary cloud telemetry.
- Multiplicity: the same event may appear in endpoint, identity, firewall, application, and provider records.
- Dependence: interpretation may require software, keys, timestamps, configuration, or a specialist’s knowledge.
- Ease of alteration: copying, opening, converting, or viewing data can change metadata or access records.
- Scale: modern investigations may involve terabytes of data and millions of log entries.
- Context sensitivity: a timestamp or IP address rarely proves identity or intent by itself.
Evidence is often classified as volatile or non-volatile. Volatile evidence may include RAM, running processes, active sessions, and routing information. Non-volatile evidence may include disk images, exported logs, backups, email archives, and printed records. The order of collection should be determined by likely evidential value, volatility, safety, and legal authority—not by a rigid universal sequence. Investigators should maintain the original where possible and conduct examination on a verified working copy. A forensic image is a bit-for-bit or otherwise validated acquisition of relevant storage. The acquisition method, tool, version, settings, errors, and verification results should be documented. 5. Integrity, Authentication and HashingIntegrity means that evidence has not been altered in an unauthorised or undocumented way. Authenticity concerns whether the evidence is what it is claimed to be and whether it came from the stated source. Integrity does not automatically prove authenticity: an unchanged file could have been created fraudulently. Cryptographic hash functions produce a fixed-length value from digital input. If a file changes, its hash will normally change. Hashes are useful for verifying that a copied file matches a source at a particular time. They do not establish who created the file, whether the source was trustworthy, or whether the hash algorithm was correctly applied. A simplified integrity workflow is: - Acquire data using an approved, documented method.
- Record the source, date, time, operator, tool, and conditions.
- Calculate a recognised cryptographic hash of the acquired item.
- Store the original securely and examine a working copy.
- Recalculate and compare hashes when evidence is transferred or presented.
- Document any transformation, export, conversion, or unavoidable change.
Hash algorithms have different security properties. Older algorithms may remain useful for identification or legacy comparison but may not be appropriate as the sole integrity mechanism where collision resistance is important. Organisations should follow current forensic standards and expert advice rather than selecting an algorithm solely because it is familiar. 6. Chain of CustodyThe chain of custody is the documented history of possession, control, transfer, examination, storage, and disposition of evidence. Its purpose is to show continuity and accountability. A chain-of-custody form should identify the item sufficiently, assign a unique identifier, record its condition, and document every material transfer. | Field | Example content |
|---|
| Evidence ID | IR-2025-014-E03 | | Description | Encrypted laptop drive image | | Source | Asset tag and device identifier | | Collection | Date, time, location, collector | | Method | Tool, version, settings, acquisition notes | | Integrity | Hash value and algorithm | | Storage | Restricted repository and access controls | | Transfers | Sender, recipient, date, time, purpose, signatures | | Examination | Examiner, copy used, actions and results | | Disposition | Return, retention, destruction, or legal hold |
A chain of custody is not improved by excessive paperwork that nobody completes accurately. It is improved by contemporaneous, precise, consistent documentation. Corrections should remain visible, with the reason, date, and person making the correction. Backdating, undocumented handling, shared accounts, unsecured media, and unexplained gaps weaken confidence in the evidence. 7. Forensic Integrity and AdmissibilityRules of admissibility differ among courts and tribunals. Common considerations include relevance, authenticity, reliability, completeness, legality of collection, probative value, prejudice, and compliance with procedural rules. Technical integrity is necessary but may not be sufficient. An organisation should be prepared to explain: - who collected the evidence and their competence;
- what authority permitted collection;
- how the source was identified;
- whether the original was preserved;
- what tools and methods were used;
- how timestamps, time zones, and clock drift were handled;
- how access and alterations were controlled;
- how conclusions were reached; and
- what limitations or alternative explanations remain.
Investigators should preserve exculpatory as well as incriminating information. Selectively retaining only material that supports an early theory can create ethical, legal, and analytical problems. The investigation should distinguish raw data, processed data, interpretation, and opinion. Legal authority is especially important when evidence belongs to employees, customers, suppliers, or another organisation. Possible authorities include consent, contractual rights, workplace policies, court orders, warrants, regulatory powers, statutory duties, or emergency provisions. These authorities are not interchangeable. Cross-border collection may raise issues involving privacy, data transfer, sovereignty, secrecy, and local law. 8. Breach Assessment and ReportingBreach response normally requires a structured assessment rather than an automatic decision to notify or not notify. The assessment should consider: - the nature and sensitivity of the information;
- the number and characteristics of affected people;
- the likelihood and severity of harm;
- whether data was encrypted, deleted, or otherwise protected;
- the duration and containment of the exposure;
- the identity and location of affected individuals;
- contractual and sector-specific duties; and
- applicable reporting deadlines and thresholds.
Reporting obligations may apply to regulators, affected individuals, customers, insurers, payment networks, shareholders, sector bodies, or law enforcement. Different regimes may use different triggers and deadlines. The legal or privacy officer should create an obligation matrix identifying the relevant rule, trigger, deadline, responsible owner, required content, and evidence supporting the decision. A notification should generally state what is known without exaggeration or speculation. It may include the nature of the incident, categories of information, likely consequences, actions taken, recommended protective steps, and a contact channel. If facts are incomplete, the organisation should say so and provide updates when material information becomes available. “No evidence of access” is not always equivalent to “no access occurred”; the wording should reflect the strength of the evidence. Notification decisions should be documented even when no notification is made. The record should explain the facts considered, legal advice or guidance relied upon, risk assessment, approvals, and review date. Deliberate concealment, misleading statements, unreasonable delay, or shifting blame can increase regulatory and reputational consequences. 9. Ethical Communication and CooperationEthical communication is accurate, proportionate, timely, respectful, and protective of affected people. It avoids both minimisation and sensationalism. Communications teams should coordinate with technical and legal specialists so that public statements do not contradict evidence or disclose information that increases risk. When communicating with customers, organisations should: - explain practical risks in understandable language;
- provide specific protective actions, such as password resets or fraud monitoring where appropriate;
- avoid demanding that customers waive rights as a condition of assistance;
- protect affected people from unnecessary disclosure;
- provide accessible contact and complaint channels; and
- correct material errors promptly.
Communication with regulators should be candid and cooperative. A regulator may value a clear account of uncertainty, containment, and corrective action more than an overconfident but inaccurate narrative. Communication with law enforcement should be coordinated through authorised personnel, while preserving evidence and respecting legal rights. An organisation should not destroy, alter, or conceal relevant information because an investigation is inconvenient or damaging. Employees and suspected insiders also have rights. Investigations should be proportionate, confidential, and consistent with employment, privacy, anti-discrimination, and labour requirements. Access to personal devices or private communications should not be assumed merely because a person uses them for work. 10. Special Investigative EnvironmentsCloud computingCloud evidence may be distributed across regions and controlled partly by a provider. The customer may not have physical access to infrastructure or complete visibility into provider logs. Contracts should define retention, access, export formats, time synchronisation, incident assistance, and legal-process responsibilities. Investigators should preserve tenant audit logs, identity events, configuration history, snapshots, object versions, and provider correspondence where relevant. Mobile and Internet of Things devicesMobile devices contain location, communications, application, sensor, and identity data. Encryption, remote wiping, battery state, and network connectivity create special preservation concerns. IoT devices may have limited storage, weak timekeeping, proprietary formats, and safety implications. Collection should avoid unnecessary disruption and should be authorised. Encryption and access credentialsEncryption protects confidentiality but may complicate investigation. Investigators should preserve keys, key-management records, recovery codes, and relevant access logs under lawful authority. Guessing passwords, bypassing controls, or using covert access methods without approval may create new legal violations and compromise evidence. Artificial intelligenceAI tools may assist triage, log classification, translation, clustering, and anomaly detection. Their outputs should be treated as investigative leads, not automatically as proof. Risks include hallucinated explanations, biased classification, hidden training data, poor reproducibility, and disclosure of confidential evidence to an external service. Human review, audit trails, data minimisation, validation, and documented limitations are essential. 11. Applied Case: The Compromised Supplier PortalThe following is an illustrative fictional case. BackgroundA regional healthcare supplier discovers that an attacker used a compromised vendor account to access its procurement portal. The portal contains employee contact details, purchase records, and limited patient-related information submitted for delivery coordination. The organisation’s monitoring system detects unusual downloads late on a Friday evening. ProblemThe security team initially cannot determine whether the attacker merely viewed records or copied them. The cloud provider retains detailed audit logs for only fourteen days. The supplier must preserve evidence, contain access, assess notification duties, maintain business operations, and communicate with healthcare customers. AnalysisThe incident manager opens an incident record and assigns unique identifiers to the portal account, relevant logs, exported records, and forensic working copies. The account is disabled after the cloud audit trail is preserved. Investigators record the decision and its risk: disabling the account may terminate the attacker’s access but could also affect evidence about active sessions. Legal and privacy officers identify possible contractual, health-sector, and personal-data obligations. The team obtains provider logs, authentication records, access times, source addresses, download activity, and configuration history. Time zones are normalised in the investigation timeline, while original timestamps are retained. Hashes are calculated for exported evidence, and access is restricted to named personnel. The team does not claim that every viewed record was exfiltrated. Instead, it distinguishes confirmed downloads from records that were merely queried and describes the uncertainty. The vendor is asked to preserve its own identity and endpoint records. Law enforcement is contacted through the authorised channel after legal review, and potentially relevant evidence is placed under a retention hold. Approach and solutionContainment includes credential reset, stronger authentication, restriction of bulk export, and review of other vendor accounts. Recovery occurs only after the portal configuration and supplier access are examined. The organisation prepares a regulator notification that explains the known facts, categories of information, containment measures, and continuing investigation. A separate customer communication provides practical protective advice without exposing unnecessary personal information. OutcomeThe investigation establishes that a set of records was downloaded during a defined period. It cannot establish that all queried records were retained by the attacker. The organisation makes a risk-based notification, continues monitoring, and completes a post-incident review. Corrective actions include shorter detection intervals, longer protected log retention, supplier authentication requirements, and clearer contractual evidence-preservation clauses. Learning pointsThe case demonstrates that speed and preservation must be balanced; uncertainty should be communicated rather than disguised; cloud contracts affect investigative capability; and an evidence record must explain both what is known and what cannot be established. 12. Challenges and LimitationsDigital investigations face several recurring limitations. Logs may be incomplete, overwritten, altered, or unavailable because a service was misconfigured. Attackers may use compromised infrastructure, making attribution uncertain. Multiple systems may use inconsistent clocks. Encryption may prevent access, while excessive collection may create privacy and storage risks. Third-party providers may be slow to respond or unable to provide the requested data. Investigators also face cognitive risks. Confirmation bias encourages a team to interpret ambiguous evidence in support of its first theory. Availability bias may cause investigators to focus on the most visible system rather than the most important one. Automation bias may lead staff to accept a tool’s classification without verification. Structured hypotheses, peer review, evidence matrices, and explicit uncertainty statements can reduce these risks. No investigation can guarantee complete knowledge. A defensible conclusion should specify its evidential basis, confidence, time boundary, assumptions, and limitations. That discipline is more valuable than a confident but unsupported attribution. 13. Best-Practice ChecklistBefore closing an incident, the organisation should confirm that it has: - recorded detection, escalation, containment, and reporting decisions;
- identified applicable legal, contractual, regulatory, and insurance duties;
- preserved volatile and persistent evidence proportionately;
- maintained hashes, acquisition records, and chain-of-custody documentation;
- separated originals from examination copies;
- documented time zones, clock issues, tools, and transformations;
- considered privacy, privilege, employment, and cross-border restrictions;
- communicated accurately with affected parties and authorities;
- preserved relevant evidence under a legal or organisational hold;
- completed recovery validation and heightened monitoring; and
- assigned and tracked corrective actions through closure.
Chapter SummaryIncident response is a governed process for managing security events and their consequences. Effective practice begins with preparation, proceeds through detection, analysis, containment, eradication, and recovery, and concludes with learning and corrective action. Escalation must be timely, authorised, and based on risk rather than record count alone. Digital evidence can be volatile, distributed, context-dependent, and easy to alter. Its usefulness depends on lawful collection, reliable acquisition, documented handling, integrity verification, authenticity, and transparent interpretation. Chain of custody demonstrates who controlled evidence and what happened to it. Hashes support integrity checking but do not independently prove authorship or truth. Breach reporting requires identification of applicable obligations, assessment of likely harm, careful documentation, and coordination among security, legal, privacy, communications, management, regulators, customers, suppliers, and law enforcement. Ethical communication is accurate, proportionate, timely, and respectful of affected people. Cloud, mobile, IoT, and AI-enabled environments create additional visibility, jurisdiction, privacy, and reliability challenges. A professional investigation acknowledges uncertainty and preserves both supporting and contrary evidence. Key TermsAdmissibility: The legal acceptability of evidence in a particular proceeding. Authentication: Establishing that evidence is what it is claimed to be. Chain of custody: The documented history of evidence possession, transfer, storage, and examination. Containment: Actions taken to limit continuing damage or unauthorised activity. Digital evidence: Information in digital form that may assist an investigation or proceeding. Evidence integrity: Confidence that evidence has not been improperly altered. Event: An observable occurrence in a system or environment. Forensic image: A validated acquisition representing relevant digital storage. Hash function: A cryptographic function that produces a fixed-length value from digital input. Incident: An event or events that cause or may cause harm to systems, information, people, or compliance. Incident commander: The person responsible for coordinating incident decisions and resources. Legal hold: A direction to preserve potentially relevant information. Non-volatile evidence: Evidence that generally persists after power or session termination. Personal-data breach: A security incident involving personal data as defined by applicable law. Preservation: Measures taken to prevent relevant evidence from being lost, altered, or destroyed. Recovery: Restoring and validating services after an incident. Threat attribution: Assessment of the person, group, or source responsible for activity. Volatile evidence: Evidence likely to disappear or change quickly, such as memory or active sessions. Review QuestionsShort Answer Questions- Distinguish between an event, an incident, and a personal-data breach.
- What is the purpose of a chain-of-custody record?
- Why should investigators normally examine a verified working copy rather than the original evidence?
- Identify two factors that should be considered when assessing whether a breach is reportable.
- Why does a hash value not by itself prove who created a file?
Long Answer Questions- Explain the major stages of the incident-response lifecycle and describe the governance decisions required at each stage.
- Discuss the relationship between evidence integrity, authenticity, reliability, and admissibility.
- Describe a defensible process for preserving and examining evidence from a cloud service.
- Explain how an organisation should coordinate communication with regulators, customers, suppliers, and law enforcement.
- Analyse the ethical and legal risks of investigating a suspected insider using workplace systems and personal devices.
Analytical / Application Questions- A company detects suspicious administrator activity but its logging system will overwrite records in six hours. Design an immediate response sequence, explaining preservation, containment, escalation, and legal considerations.
- A regulator asks whether customer data was “stolen,” but the investigation confirms only that records were accessed and queried. Draft the principles that should govern the organisation’s response.
- An AI tool classifies 20,000 log entries as malicious, but the tool cannot explain its classifications. Assess how the organisation should use, validate, document, and communicate those results.
Multiple Choice Questions with AnswersQuestion 1Which statement best distinguishes an incident from an event? A. An event is always criminal, while an incident is never criminal. B. An incident is an event or group of events that causes or may cause material harm. C. An event can occur only on a network, while an incident occurs only on a device. D. An incident is any event recorded after a regulator is notified. Correct Answer: B. An incident is an event or group of events that causes or may cause material harm. Question 2Which item is most likely to be volatile digital evidence? A. A printed contract B. A stored disk image C. Contents of system memory D. An archived backup tape Correct Answer: C. Contents of system memory Question 3What is the primary purpose of a hash value in evidence handling? A. To prove the identity of the attacker B. To verify that data has not changed between comparisons C. To determine the legal jurisdiction of a file D. To identify the person who created a document Correct Answer: B. To verify that data has not changed between comparisons Question 4Which practice best supports chain of custody? A. Allowing investigators to share one unrecorded evidence password B. Moving evidence between offices without recording the transfers C. Recording each material transfer, custodian, time, purpose, and condition D. Examining the original evidence repeatedly to avoid making copies Correct Answer: C. Recording each material transfer, custodian, time, purpose, and condition Question 5Why should breach communications distinguish confirmed facts from assumptions? A. To make the incident appear less serious regardless of evidence B. To avoid misleading recipients and accurately express uncertainty C. To prevent all future regulatory questions D. To ensure that no technical details are ever disclosed Correct Answer: B. To avoid misleading recipients and accurately express uncertainty Question 6Which consideration is especially important when collecting evidence from a cloud provider? A. Whether the provider’s logo appears on the evidence B. Provider retention periods, access rights, locations, and export capability C. Whether the investigator can physically enter the provider’s data centre D. Whether cloud evidence is automatically inadmissible Correct Answer: B. Provider retention periods, access rights, locations, and export capability Question 7What is the main limitation of disabling a compromised account immediately? A. It always increases the attacker’s privileges B. It may stop activity but can affect evidence about active sessions C. It prevents the organisation from notifying anyone D. It permanently invalidates all previously collected evidence Correct Answer: B. It may stop activity but can affect evidence about active sessions Question 8Which statement about AI-generated investigative output is most appropriate? A. It is automatically proof because it was generated by software B. It should be treated as a lead and subject to human validation and documentation C. It can replace chain-of-custody procedures D. It is reliable only when the incident involves personal data Correct Answer: B. It should be treated as a lead and subject to human validation and documentation Question 9Which factor should NOT be used alone to determine incident severity? A. Potential impact on safety and essential services B. Sensitivity of the information involved C. The number of records affected without considering their sensitivity D. Whether the activity is ongoing Correct Answer: C. The number of records affected without considering their sensitivity Question 10What is the most ethically appropriate response when an investigation cannot establish whether all queried records were retained by an attacker? A. State that every record was definitely stolen B. State that no records were accessed C. Describe confirmed access, explain the uncertainty, and provide appropriate updates D. Withhold all communication until certainty is absolute Correct Answer: C. Describe confirmed access, explain the uncertainty, and provide appropriate updates
|