11. Incident Response, Breach Notification and Regulatory Engagement

Introduction and Context

A cyber incident becomes a legal and governance event when it affects personal data, regulated information, essential services, contractual commitments, or the continuity and reputation of an organisation. Technical teams may initially describe an event as malware, unauthorised access, data exfiltration, or service disruption. Legal counsel must translate those facts into questions of duty: What happened? Whose information or systems were affected? What evidence supports that conclusion? Is notification required, to whom, and by when? What must be preserved? Which statements can safely be made to customers, employees, regulators, insurers, business partners, and law-enforcement authorities?

Incident response therefore cannot be treated as a purely technical exercise. It is a coordinated organisational process involving security operations, information technology, privacy, legal, compliance, communications, human resources, senior management, risk, insurance, and sometimes external forensic and investigative specialists. The quality of the first few decisions may influence regulatory exposure, litigation outcomes, insurance recovery, public confidence, and the organisation’s ability to learn from the event.

This chapter examines incident response from an integrated legal, technical, and managerial perspective. It uses the term “breach” carefully. Not every security incident is a legally reportable personal-data breach, but every suspected breach requires disciplined assessment. Applicable duties vary by jurisdiction and sector. Consequently, this chapter presents general principles and widely used approaches rather than jurisdiction-specific legal advice. Organisations must verify statutory deadlines, thresholds, sectoral rules, contractual requirements, and regulator guidance applicable to their circumstances.

Learning Objectives

After studying this chapter, students should be able to:

1. Distinguish a security event, security incident, personal-data breach, and legally notifiable breach.

2. Explain how legal counsel should be integrated into technical incident response.

3. Apply a structured method for assessing materiality, risk, notification, and regulatory engagement.

4. Analyse privilege, evidence preservation, communications, insurance, and third-party responsibilities.

5. Design an incident-response and breach-notification workflow for a complex organisation.

6. Evaluate post-incident remediation, accountability, and ethical decision-making.

From Technical Event to Legal Incident

A security event is an observable occurrence, such as repeated failed logins, an unusual data transfer, or a malicious file being detected. An incident is an event that threatens the confidentiality, integrity, or availability of information or systems and requires investigation or response. A personal-data breach generally involves accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or unauthorised access to personal data. A reportable breach is a breach that satisfies the notification threshold under an applicable law, regulation, contract, or regulatory scheme.

These categories should not be confused. A phishing email blocked by a secure gateway may be an event but not an incident. A compromised administrator account may be a serious incident even before investigators know whether data was accessed. A lost encrypted device may not create a notification duty if the encryption and key-management controls make the data effectively inaccessible, although that conclusion must be documented and tested against applicable law. Conversely, a short-lived exposure of a small dataset may be reportable if it involves highly sensitive information or a vulnerable population.

The initial classification should remain provisional. Early assumptions are often based on incomplete logs, unreliable attacker claims, or an affected system owner’s understanding of the data. Response leaders should record what is known, what is suspected, what remains unknown, and what action is being taken to resolve each uncertainty.

The Incident-Response Lifecycle

A useful lifecycle contains preparation, detection and analysis, containment, eradication and recovery, notification and engagement, and post-incident improvement. In practice, these stages overlap. Notification decisions may begin during analysis; evidence preservation begins immediately; and recovery may proceed while the organisation continues to investigate.

Preparation

Preparation includes an incident-response plan, clearly assigned authority, contact lists, technical playbooks, decision criteria, backup arrangements, logging standards, tabletop exercises, and pre-approved communication processes. Legal preparation includes identifying applicable privacy and cybersecurity laws, contractual notification clauses, regulator contacts, law-enforcement channels, insurance requirements, data-processing relationships, and outside counsel or forensic providers.

A response plan should specify who can declare a major incident, who can authorise isolation or system shutdown, who makes notification decisions, and who speaks publicly. It should also address conflicts of interest. For example, the executive responsible for a system may be reluctant to classify an incident as serious, while the privacy officer may favour early notification to reduce legal risk. A defined escalation structure reduces delay and arbitrary decision-making.

Detection and Analysis

The analysis team establishes a timeline, identifies affected assets, determines the attack vector, and assesses whether confidentiality, integrity, or availability has been compromised. It should identify data owners, data subjects, locations, retention periods, classifications, and relevant vendors. The legal team maps these facts to duties and privileges without directing investigators to ignore inconvenient evidence.

Important questions include:

• When was the incident discovered, and when may it have begun?
• What systems, accounts, applications, backups, and cloud environments were involved?
• Was data merely exposed, or is there evidence of access, acquisition, copying, alteration, or deletion?
• What categories of individuals and information are implicated?
• What controls reduced the likelihood of misuse?
• Are affected persons located in different jurisdictions?
• Are contractual, sectoral, employment, consumer-protection, or critical-infrastructure rules triggered?

Containment, Eradication, and Recovery

Containment limits damage while preserving the ability to investigate. It may involve disabling accounts, isolating hosts, blocking traffic, suspending integrations, rotating credentials, or temporarily taking a service offline. Decisions must balance security against operational, safety, and evidentiary consequences. For example, wiping an infected server may restore service quickly but destroy valuable forensic evidence.

Eradication removes persistence and closes the attack path. Recovery restores systems from trusted sources, validates integrity, monitors for recurrence, and confirms that critical business processes can operate safely. Legal counsel should be involved in decisions that affect evidence, contractual performance, customer access, safety, or public representations.

Breach Materiality and Notification Analysis

“Materiality” in incident response does not have one universal meaning. It may refer to legal risk, harm to individuals, operational impact, financial significance, regulatory seriousness, or disclosure significance to investors and boards. A notification assessment should use the specific statutory threshold rather than a general impression that an incident is “large” or “small.”

A practical risk assessment considers:

1. Nature of the data. Identity information, authentication credentials, financial information, health information, precise location, biometric identifiers, confidential communications, and information about children may create greater risk than ordinary business contact data.

2. Volume and scope. The number of records matters, but a small number of highly vulnerable individuals may present significant risk.

3. People affected. Children, patients, employees, customers, protected witnesses, and persons exposed to discrimination or physical danger may require special consideration.

4. Likelihood of misuse. Evidence of exfiltration, publication, sale, extortion, targeted surveillance, or attacker capability increases risk.

5. Safeguards. Strong encryption, tokenisation, rapid containment, and credential invalidation may reduce risk, but should not be assumed effective without verification.

6. Consequences. Possible identity theft, financial loss, discrimination, physical harm, embarrassment, loss of confidentiality, or loss of control over personal information must be considered.

7. Remedial measures. Credit monitoring, password resets, fraud alerts, recall of documents, and direct support may reduce continuing harm but do not necessarily eliminate a notification duty.

A defensible assessment records the facts, assumptions, methodology, legal provisions considered, decision-makers, dissenting views, and reasons for notifying or not notifying. “No evidence of access” should not automatically be written as “no access.” The distinction between absence of evidence and evidence of absence is crucial where logs are incomplete.

Notification commonly involves several audiences. A data-protection authority may require notification within a prescribed period after the organisation becomes aware of a qualifying breach. Affected individuals may require prompt communication where the risk is sufficiently serious. Customers, business partners, insurers, law enforcement, sector regulators, stock exchanges, lenders, or contractual counterparties may have separate requirements. One notification does not necessarily satisfy all obligations.

A notification should be accurate, comprehensible, and useful. It normally explains what happened, when it occurred or was discovered, what information was involved, likely consequences, steps taken by the organisation, protective steps individuals can take, and how to obtain assistance. Avoid speculation, blame, exaggerated reassurance, and technical language that conceals rather than clarifies. If facts remain uncertain, the organisation should state what is known and provide a mechanism for updates.

Legal Counsel, Privilege, and Evidence Preservation

Legal counsel performs at least four distinct functions: advising on applicable duties, coordinating legal risk, protecting the integrity of decision-making, and helping the organisation communicate responsibly. Counsel should not replace technical experts or become a bottleneck for every operational decision. Instead, the response model should define where legal approval is essential and where pre-authorised technical actions may proceed immediately.

Privilege is frequently misunderstood. Communications are not automatically privileged merely because a lawyer is copied on an email or because a document is labelled “confidential” or “privileged.” Privilege depends on applicable law, the purpose of the communication, the status of the participants, and the relationship between counsel and client. Business, public-relations, or routine operational advice may not become privileged simply through legal involvement. The organisation should obtain jurisdiction-specific advice on attorney-client privilege, litigation privilege, professional secrecy, and the treatment of forensic reports.

A sound approach separates legal advice from ordinary business communications where appropriate, limits circulation to those with a need to know, maintains factual accuracy, and avoids creating unnecessary informal commentary. Privilege should never be used to conceal facts from regulators or to obstruct investigation. In some jurisdictions, disclosure to a regulator or third party may waive protection; in others, special rules may apply.

Evidence preservation begins when litigation, regulatory investigation, or enforcement is reasonably anticipated, and good practice often begins earlier. The organisation should preserve relevant logs, endpoint images, memory captures where feasible, access records, cloud audit trails, email, messages, policies, tickets, configurations, contracts, and decision records. A legal hold may suspend ordinary deletion schedules. Chain-of-custody records should identify who collected evidence, when, how, using which tool, where it was stored, and whether it was altered.

The response should preserve both technical evidence and governance evidence. A regulator may ask not only how attackers entered but also when senior management became aware, what risk assessment was performed, whether controls were known to be deficient, and why notification was delayed or withheld.

Communications and Stakeholder Trust

Incident communications are a risk-control activity, not merely a public-relations exercise. Internal employees need practical instructions: how to report suspicious activity, whether to communicate with customers, how to preserve messages, and which systems may be unavailable. Customers need information that helps them protect themselves. Regulators need candour, chronology, and evidence of control. Boards need material facts, options, uncertainty, and decisions required from them.

A communications structure should provide a single source of verified facts. Technical teams should not issue speculative public statements; communications teams should not simplify facts to the point of inaccuracy. Statements should be coordinated with legal, privacy, security, and executive leadership. Organisations should also consider accessibility, language, vulnerable populations, and the risk that public detail could assist an attacker.

Paying a ransom raises legal, ethical, insurance, and operational issues. It may not restore systems, may encourage further attacks, and may create sanctions or money-laundering concerns depending on the parties involved. Any decision should involve legal counsel, law enforcement where appropriate, insurers, senior management, and a documented assessment of alternatives. Payment does not remove notification or remediation duties.

Insurance, Vendors, and Regulatory Engagement

Cyber-insurance policies often require rapid notice, approved vendors, cooperation, preservation of evidence, and consent before incurring response costs or making payments. Failure to comply can affect coverage. At the same time, insurance requirements must not delay containment or legally required notification. The organisation should understand whether policies cover forensic services, counsel, notification, public relations, business interruption, restoration, extortion, and third-party claims.

Third-party incidents complicate responsibility. A cloud provider, payment processor, managed-service provider, or data processor may control essential evidence and have its own contractual and statutory duties. Contracts should establish incident-notice timing, cooperation, audit access, forensic support, subprocessor disclosure, security standards, cost allocation, and assistance with data-subject requests. The organisation remains responsible for understanding its own duties even where processing is outsourced.

Regulatory engagement should be deliberate and credible. Early contact may be appropriate where law requires it, where serious harm is possible, where an essential service is affected, or where regulator guidance can assist. A regulator will often value a clear chronology, known facts, uncertainty analysis, containment measures, notification plans, and a timetable for further information. Overconfident conclusions, inconsistent statements, and unexplained delays damage credibility.

Engagement is not limited to submitting a form. It may involve answering questions, supplying supplementary reports, participating in meetings, accepting undertakings, responding to an audit, or demonstrating remediation. Organisations should maintain a regulatory-communications record and ensure that submissions are consistent across jurisdictions without concealing material differences.

Illustrative Case: The Compromised Research Platform

Background

Northbridge Health Research Institute, a fictional organisation, operates a cloud platform used by hospitals and universities to manage research participants. The platform stores contact details, coded health information, consent records, and investigator credentials. A managed-service provider monitors the environment.

Situation

The provider detects an unusual administrator login from an unfamiliar location. The account is disabled, but investigators discover that an attacker had maintained access for approximately three weeks. Audit logging was incomplete for one application. There is evidence that several export jobs ran outside normal hours, although the files cannot initially be identified. The institute’s insurance policy requires prompt notice, and multiple countries are involved.

Analysis

The incident commander forms a response group consisting of security, privacy, legal, the provider, communications, research governance, and executive management. The team preserves cloud logs, snapshots relevant systems, and issues a legal hold. Investigators determine that coded health data and contact details were present in the affected environment. Strong encryption protected backups, but the live database was accessible to the compromised account. Because logging is incomplete, the team cannot reliably establish that no data was accessed.

Legal counsel maps the participants and institutions to applicable jurisdictions and contracts. The privacy team evaluates sensitivity, duration of access, the possibility of re-identification, the use of health information, and the affected individuals’ vulnerability. The organisation distinguishes confirmed facts from hypotheses and records the basis for each decision.

Approach and Solution

Northbridge notifies the insurer and engages approved forensic counsel without delaying containment. It rotates privileged credentials, blocks the attack path, validates the provider’s environment, and increases monitoring. It prepares a regulator notification describing the incident, the uncertainty caused by incomplete logs, containment measures, and the planned timetable for further findings. Affected participants receive direct, plain-language communication once the initial facts and protective advice are sufficiently reliable. The organisation establishes a helpline and coordinates with research institutions.

The board receives a concise risk report, while the regulator receives a detailed chronology and technical appendix. Public statements avoid claiming that data was definitely exfiltrated or definitely not accessed. Law enforcement is consulted regarding the attacker and potential extortion.

Outcome

Further analysis identifies unauthorised export activity but cannot reconstruct every file. The institute supplements its notifications, provides additional support to affected participants, and reaches a remediation agreement requiring improved logging, privileged-access management, vendor oversight, and annual exercises. The insurer covers a substantial portion of eligible costs, partly because notice and approved-provider requirements were followed.

Learning Points

The case illustrates that incomplete evidence does not justify indefinite delay. It also demonstrates the value of separating confirmed facts from uncertainty, involving counsel early without compromising technical independence, preserving evidence before rebuilding systems, and treating vendors as participants in—not substitutes for—organisational accountability.

Common Errors, Constraints, and Ethical Questions

The most damaging mistakes are often procedural. Organisations may wait for perfect certainty, fail to identify the legal notification clock, destroy evidence during hurried restoration, issue inconsistent statements, overlook contractual duties, or treat a vendor’s report as a complete investigation. Another common error is underestimating insider access, compromised credentials, cloud control-plane activity, or data in backups and test environments.

Resource constraints are real. Smaller organisations may lack dedicated privacy counsel, forensic specialists, or mature logging. A proportionate response is still possible through pre-arranged retainers, tested escalation lists, clear data inventories, managed detection services, and sector information-sharing arrangements. Proportionality should reduce complexity, not reduce honesty.

Ethically, incident response involves tension between transparency and security, individual privacy and investigative need, business continuity and evidence preservation, and organisational reputation and public safety. Decisions should respect affected persons, avoid discriminatory assumptions, communicate uncertainty fairly, and provide meaningful assistance rather than merely satisfying formal notice requirements. Regulators and customers should not be misled by technically true but materially incomplete statements.

Post-Incident Remediation and Emerging Practice

A post-incident review should ask not only who made an error but why the system allowed the error to matter. Root-cause analysis may identify excessive privileges, weak identity assurance, inadequate segmentation, unsupported software, poor vendor governance, missing logs, unrealistic recovery objectives, or a culture that discourages reporting. Corrective actions should have owners, deadlines, funding, measurable outcomes, and independent verification.

Useful measures include time to detect, time to contain, time to restore, time to make a notification decision, percentage of privileged accounts using strong authentication, logging coverage, exercise performance, vendor-response time, and closure of high-risk findings. Metrics must be interpreted carefully: a low incident count may reflect poor detection rather than strong security.

Automation can assist with alert correlation, asset discovery, identity analytics, evidence collection, notification workflow management, and deadline tracking. Artificial-intelligence tools may help summarise logs or identify anomalous behaviour, but their outputs require validation. Sensitive incident data should not be entered into unapproved systems, and automated classification should not make final legal decisions without accountable human review. Emerging practice increasingly emphasises identity-centric security, immutable logging, zero-trust architectures, software-supply-chain assurance, privacy-enhancing technologies, and continuous control monitoring.

Best-Practice Decision Framework

An organisation can use the following sequence during a major incident:

1. Stabilise the situation and protect people, systems, and critical services.

2. Establish an incident authority, secure communications, and preserve evidence.

3. Identify affected systems, data, individuals, jurisdictions, vendors, and contracts.

4. Create a verified chronology and separate facts, assumptions, and unknowns.

5. Assess legal thresholds, individual harm, operational materiality, and notification deadlines.

6. Notify regulators, individuals, insurers, partners, and law enforcement when required or strategically appropriate.

7. Communicate consistently, clearly, accessibly, and without speculation.

8. Recover securely and validate that the threat has been removed.

9. Document decisions, dissent, approvals, and supplementary notifications.

10. Remediate root causes and test whether improvements actually work.

Chapter Summary

Incident response is a multidisciplinary governance process in which technical investigation, legal analysis, privacy protection, communications, insurance, and regulatory engagement must operate together. Organisations should distinguish events, incidents, personal-data breaches, and legally reportable breaches. Notification decisions require a documented assessment of data sensitivity, affected persons, misuse likelihood, consequences, safeguards, and remedial measures. Legal counsel supports duty analysis, privilege management, evidence preservation, communications, and regulator interaction, but privilege is not created merely by copying a lawyer on an email.

Effective response begins with preparation and continues through detection, containment, recovery, notification, and post-incident improvement. Evidence preservation must cover technical records and governance decisions. Vendors and insurers can provide essential assistance, but they do not eliminate the organisation’s accountability. Transparent, accurate, and useful communication is central to ethical and regulatory performance. Finally, post-incident remediation should address systemic causes, use measurable controls, and apply automation or AI only with appropriate validation and human accountability.

Key Terms

Security event: An observable occurrence involving information systems or security controls.

Security incident: An event that threatens the confidentiality, integrity, or availability of information or systems and requires response.

Personal-data breach: Accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to personal data.

Reportable breach: A breach that satisfies a legal, regulatory, contractual, or sector-specific notification threshold.

Breach materiality: The significance of an incident assessed by legal, individual-harm, operational, financial, or governance criteria.

Incident commander: The person authorised to coordinate response activities and allocate operational priorities.

Containment: Actions taken to limit an incident’s spread, impact, or continuing access.

Eradication: Removal of malicious tools, persistence mechanisms, vulnerabilities, or unauthorised access.

Recovery: Restoration and validation of safe, reliable, and monitored operations.

Legal hold: A direction suspending ordinary deletion or destruction of potentially relevant information.

Chain of custody: A documented record of evidence collection, handling, storage, and transfer.

Attorney-client privilege: Legal protection for qualifying confidential communications between lawyer and client concerning legal advice, subject to applicable law.

Regulatory engagement: Structured communication and cooperation with a competent supervisory or sector regulator.

Data processor: An entity processing personal data on behalf of another organisation, where recognised by applicable law.

Data controller: An entity determining the purposes and means of personal-data processing, where recognised by applicable law.

Risk assessment: A systematic evaluation of likelihood, consequences, affected data, safeguards, and uncertainty.

Incident chronology: A verified timeline of discovery, attacker activity, decisions, containment, and notifications.

Post-incident review: A structured examination of causes, response performance, and corrective actions.

Cyber insurance: Insurance covering specified cyber-related losses and response costs subject to policy conditions.

Privileged access management: Controls governing powerful administrative accounts and their use.

Review Questions

Short Answer Questions

1. Distinguish a security event from a legally reportable personal-data breach.

2. Why should incident records distinguish confirmed facts from unknowns?

3. Identify four factors relevant to breach-risk assessment.

4. What is the purpose of a legal hold?

5. Why does copying a lawyer on an email not automatically create privilege?

Long Answer Questions

1. Explain how legal counsel, security teams, privacy officers, communications staff, and senior management should coordinate during a major incident.

2. Describe the complete incident-response lifecycle and show how notification decisions can overlap with containment and recovery.

3. Analyse the role of evidence preservation in regulatory investigations and civil litigation.

4. Discuss the legal and managerial risks of relying on a cloud provider or processor to manage breach obligations.

5. Explain how post-incident remediation can address systemic weaknesses rather than merely assigning individual blame.

Analytical / Application Questions

1. A company discovers that an encrypted laptop was lost, but the encryption key may have been stored in a recovery system accessed by an unauthorised user. Develop a notification assessment and identify the evidence required before reaching a conclusion.

2. During a ransomware incident, executives want to issue a statement claiming that no personal data was accessed, although logging is incomplete. Evaluate the proposal and design a safer communication strategy.

3. A multinational organisation identifies unauthorised exports from a vendor-managed database containing employee and customer information. Construct an escalation, evidence-preservation, regulatory-engagement, and remediation plan.

22. Multiple Choice Questions with Answers

Question 1

Which statement best distinguishes a security incident from a reportable breach?

A. Every security event is automatically a reportable breach.

B. A security incident requires response, whereas a reportable breach satisfies an applicable notification threshold.

C. A reportable breach can occur only when systems are unavailable.

D. A security incident exists only when an attacker publicly claims responsibility.

Correct Answer: B. A security incident requires response, whereas a reportable breach satisfies an applicable notification threshold.

Question 2

Why should an organisation record uncertainty explicitly during breach analysis?

A. To avoid preserving incomplete evidence.

B. Because uncertainty may affect risk assessment, notification timing, and the credibility of regulatory explanations.

C. To permit the organisation to ignore missing logs.

D. Because regulators generally prohibit recording assumptions.

Correct Answer: B. Because uncertainty may affect risk assessment, notification timing, and the credibility of regulatory explanations.

Question 3

Which factor most directly increases the likelihood that a breach will create serious individual harm?

A. The affected server was located in a cloud environment.

B. The data consisted of highly sensitive health information and was accessible through a compromised privileged account.

C. The incident was detected outside normal business hours.

D. The organisation had a written incident-response policy.

Correct Answer: B. The data consisted of highly sensitive health information and was accessible through a compromised privileged account.

Question 4

What is the most appropriate description of a legal hold?

A. A temporary suspension of relevant information deletion or destruction.

B. A technical control that blocks all internet traffic.

C. A regulator’s decision to suspend an organisation’s licence.

D. A method for encrypting forensic images.

Correct Answer: A. A temporary suspension of relevant information deletion or destruction.

Question 5

Which practice is most likely to preserve both evidence and operational capability?

A. Immediately wiping every affected server before collecting records.

B. Allowing employees to discuss the incident freely on personal messaging services.

C. Collecting relevant logs and images, documenting custody, and using controlled containment measures.

D. Delaying all containment until every fact is known.

Correct Answer: C. Collecting relevant logs and images, documenting custody, and using controlled containment measures.

Question 6

Which statement about privilege is most accurate?

A. Any document marked “privileged” is protected in every jurisdiction.

B. Copying counsel on a message automatically makes the message privileged.

C. Privilege depends on applicable law, confidentiality, participants, and the purpose of the communication.

D. Privilege permits an organisation to conceal material facts from regulators.

Correct Answer: C. Privilege depends on applicable law, confidentiality, participants, and the purpose of the communication.

Question 7

A vendor reports that it found no evidence of data access, but application logging was incomplete. What is the strongest response?

A. Close the incident because the vendor has denied access.

B. Record the limitation, investigate other evidence, and avoid equating lack of evidence with evidence of absence.

C. Notify every person immediately without any further analysis.

D. Delete the incomplete logs because they cannot prove access.

Correct Answer: B. Record the limitation, investigate other evidence, and avoid equating lack of evidence with evidence of absence.

Question 8

Which communication approach is most appropriate when facts are still developing?

A. Claim certainty to protect reputation.

B. Provide verified facts, identify material uncertainty, explain protective measures, and update stakeholders as needed.

C. Release raw forensic data without context.

D. Refuse all communication until the investigation is perfect.

Correct Answer: B. Provide verified facts, identify material uncertainty, explain protective measures, and update stakeholders as needed.

Question 9

Why must an organisation review its cyber-insurance policy during response?

A. Insurance always determines whether a breach is legally reportable.

B. Policies may require prompt notice, approved providers, cooperation, and consent for particular costs or actions.

C. Insurance eliminates the need for evidence preservation.

D. Insurers replace regulators in breach investigations.

Correct Answer: B. Policies may require prompt notice, approved providers, cooperation, and consent for particular costs or actions.

Question 10

Which post-incident measure best demonstrates meaningful remediation?

A. Assigning blame to the employee whose account was compromised.

B. Publishing a general statement that security has improved.

C. Implementing accountable corrective actions, assigning deadlines, and independently testing whether controls work.

D. Reducing future logging to lower investigation costs.

Correct Answer: C. Implementing accountable corrective actions, assigning deadlines, and independently testing whether controls work.