5.1 Accountability, Incident Response, and Due Diligence
Key Takeaways
- Accountability in U.S. practice means documenting decisions, assigning owners, monitoring vendors, and being able to show the FTC or a state attorney general that the program was reasonable
- Due diligence is required at vendor onboarding and periodically; a signed data-processing agreement does not transfer accountability to the vendor
- BoK I.C expressly names ransomware and vendor incidents as incident-response examples; paying a ransom does not extinguish notification duties
- A playbook is the written procedure, a tabletop is a discussion exercise that tests it, and a legal hold suspends ordinary destruction once litigation or an investigation is reasonably anticipated
- A security incident becomes a reportable breach only when the facts meet a legal definition — typically unauthorized acquisition of defined personal information — and the full notice matrix is Domain V
Accountability, Incident Response, and Due Diligence
Domain I.C performance indicators 2 and 3 ask you to know incident-response programs — the Body of Knowledge names ransomware and vendor incidents expressly — and to understand accountability and the due diligence that makes it real. On the CIPP/US exam, accountability is not a slogan. It is the evidence you can put in front of the Federal Trade Commission (FTC) or a state attorney general (AG) that the organization made reasonable decisions, assigned owners, watched its vendors, and can reconstruct what it did.
What accountability means in U.S. practice
Accountability is the obligation to take responsibility for personal-information practices and to demonstrate that those practices were reasonable. U.S. law does not copy the European Union's Article 5(2) "controller shall be responsible for, and be able to demonstrate" sentence as a single federal statute. The U.S. version is practical and enforcement-driven:
- Document decisions. Why this vendor? Why this retention period? Why this sharing? A dated risk assessment, a residual-risk acceptance, and a written policy beat a hallway conversation when an investigator asks "what did you know, and when?"
- Assign owners. Every processing activity and every vendor relationship needs a named business owner plus a privacy or security contact. "The team" is not an owner.
- Monitor vendors. Signing a data-processing agreement (DPA) does not end accountability. The company that collected the data is still the one the FTC or AG will ask first. Chapter 4 covers DPA clauses; this section covers the duty that survives the signature.
- Be able to show reasonableness. The FTC's long-running Section 5 security cases — including the Wyndham Worldwide line — ask whether the company used readily available, reasonable measures. Perfection is not the standard. "No comprehensive federal privacy statute applies" is not a defense to an unreasonable program.
Industry frameworks such as the National Institute of Standards and Technology (NIST) Cybersecurity Framework, the NIST Privacy Framework, and the FTC's Start with Security / Stick with Security guidance are evidence of what a reasonable program looks like. They are not statutes. Citing them without implementing them is another representation problem.
Due diligence at onboarding and periodically
Due diligence is the process that produces accountability evidence. It happens at onboarding — before personal data flows — and periodically, because vendors add subprocessors, get acquired, change regions, or get ransomed. A questionnaire from 2019 sitting in a shared drive is not diligence in 2026.
Typical artifacts, scaled to the vendor's risk tier:
- Security and privacy questionnaires aligned to the data the vendor will actually see
- SOC 2 Type II or ISO/IEC 27001 reports, read for exceptions — not just filed
- Encryption, access-control, and subprocessor descriptions
- Breach-history and financial-stability review
- Insurance and a contractual right to audit
- A re-review trigger: contract renewal, material change, incident, or a set calendar cycle
You do not need every artifact for a low-risk email template vendor. You do need a risk-tiered method you can defend. The Disposal Rule discussion in the next section uses the same idea: due diligence plus a written, monitored contract — not an oral "they'll take care of it."
Incident response: ransomware and vendor incidents
A security incident is an attempted or successful unauthorized access, use, disclosure, modification, or destruction of information or systems. Incident response (IR) is the program that detects, contains, investigates, recovers, and decides whether the incident is also a reportable breach.
The BoK's two named examples are exam bait.
Ransomware. Attackers encrypt systems and demand payment. Modern strains often exfiltrate data first (double extortion). Paying the ransom does not erase notification duties, does not restore a legal-hold obligation, and does not prove the data was never copied. Treat ransomware as both an availability event and a confidentiality event until forensics say otherwise.
Vendor incidents. A payroll processor, cloud host, or marketing platform is compromised. Your customers' data may sit on that vendor's systems. Contracts should require prompt notice, cooperation, and forensics. The IR plan should assume you may first learn about the incident from a journalist unless you have already written the other path. Vendor delay does not stop your discovery analysis.
Playbook, tabletop, and legal hold
| Tool | What it is | What it is not |
|---|---|---|
| Playbook | A written, role-based procedure for a named incident type (ransomware, lost laptop, vendor notice) | A slide deck no one has opened since last year's audit |
| Tabletop | A facilitated discussion that walks a scenario, names decision-makers, and finds gaps — without touching production systems | A full technical failover test, or a substitute for a written playbook |
| Legal hold | Counsel-directed preservation of potentially relevant records once litigation or a government investigation is reasonably anticipated | Ordinary backup rotation, and not a reason to keep everything forever |
The three tools fail in different ways. A playbook that no one has tabletopped is a document. A tabletop with no playbook is improvisation. A legal hold that never reaches IT or a vendor lets ordinary destruction continue — and spoliation of electronically stored information can draw sanctions under Federal Rule of Civil Procedure 37(e).
Scenario. Friday 6 p.m.: a billing vendor emails that ransomware has encrypted its claims portal. Your playbook names a privacy lead, a security lead, outside counsel, and a communications owner. Counsel issues a legal hold covering the vendor file, customer complaints, and system logs. Security isolates remaining connections. Privacy starts a data-element and residency worksheet — whose information, which states, whether the files were encrypted, whether a sectoral statute such as the Health Insurance Portability and Accountability Act (HIPAA) or the Gramm-Leach-Bliley Act (GLBA) applies. That worksheet is how you later decide whether this incident is a reportable breach. You do not wait for the vendor's blog post to start the clock analysis.
When a security incident becomes a reportable breach (preview)
Domain V tests breach-notification statutes in depth. Domain I wants the fork:
- Not every incident is a breach. A failed phishing simulation with no data leaving the environment is an incident and a training event, not a statutory notice.
- A reportable breach exists only when the facts meet a legal definition — typically unauthorized acquisition (some states: access) of personal information as that statute defines it.
- Common state trigger: a resident's name plus a data element such as a Social Security number, driver's-license number, or a financial-account number with an access code. Definitions vary; some states now cover health, biometric, or username-and-password combinations.
- Many statutes include an encryption / safe-harbor path: if the data was encrypted to the statutory standard and the key was not taken, notification may not be required.
- Sectoral overlays you will meet later: HIPAA breach notification for unsecured protected health information (individuals without unreasonable delay and no later than 60 calendar days after discovery; the U.S. Department of Health and Human Services and the media if 500 or more individuals); GLBA / Safeguards expectations for financial institutions; FTC Section 5 if the company promised security it did not have.
- The clock usually starts at discovery, or when the company reasonably should have discovered. Who you notify — individuals, the AG, a regulator, credit bureaus, sometimes the media — depends on the statute and the headcount.
Exam traps. Do not say paying ransomware "cures" notice. Do not treat a DPA as a transfer of accountability. Do not confuse a tabletop with a legal hold. Do not recite a 50-state notice matrix on a Domain I question — name the fork, then leave the matrix for Domain V.
In U.S. privacy practice, what does accountability primarily require a company to be able to do?
A SaaS vendor encrypts the company's customer database and demands ransom. The company has a written ransomware playbook but has never walked through it with decision-makers. Which statement is most accurate on the CIPP/US exam?
Which fact most strongly indicates that a security incident has become a reportable breach under typical U.S. rules?