The United States has no general federal data security statute, so for most companies the practical rulebook is Section 5 of the FTC Act and the consent orders the Federal Trade Commission has built on it. Section 5 prohibits unfair or deceptive acts or practices, and the FTC has used both limbs to bring more than 80 data security enforcement actions, from Wyndham to Drizly and GoDaddy. Those orders, and the FTC's own "Start with Security" lessons drawn from them, describe the controls the agency treats as reasonable: access control, multi-factor authentication, secrets kept out of code, supplier oversight and monitoring. This guide covers who is in scope, the legal tests, what orders require, penalties, the current position, and what it all means for API keys, cloud credentials and AI agents. It is for security, privacy and legal teams at US-facing companies. For state laws that sit alongside it, see the US State Cybersecurity Laws Map.
Status checked 27 October 2026: 15 U.S.C. 45 is in force as amended. The inflation-adjusted maximum civil penalty for violating a final order or a trade regulation rule is $53,088 per violation, in 16 CFR 1.98 for penalties assessed after 17 January 2025 (eCFR up to date as of 23 October 2026).
Key takeaways
- Two theories, one statute: deception covers security promises you did not keep; unfairness covers security practices that cause or are likely to cause substantial, unavoidable injury to consumers, even if you promised nothing.
- Courts back the unfairness theory: in FTC v. Wyndham the Third Circuit upheld the FTC's authority to use unfairness against data security failures and rejected the argument that the company lacked fair notice.
- Orders are the real penalty: a first case usually ends in a consent order with a mandated information security programme, independent assessments and reporting; money penalties attach when that order is later violated, at up to $53,088 per violation, with each day of a continuing failure a separate offence.
- The FTC names identity failures specifically: its Start with Security lessons cite a shared admin cloud key posted online (Uber), unrotated shared AWS root credentials (Chegg) and repository credentials without two-factor authentication (Drizly).
- Executives can be bound personally: the Drizly order placed obligations on the CEO to run security programmes at future companies that hold data on more than 25,000 people.
Scope: who and what is covered
Section 5(a)(1) declares unlawful "unfair methods of competition" and unfair or deceptive acts or practices in or affecting commerce. Section 5(a)(2) gives the FTC power to prevent them, with exceptions.
| Category | Position under Section 5 | Where to look instead |
|---|---|---|
| Most for-profit companies in or affecting US commerce | In scope | Section 5 plus sector rules |
| Banks, savings and loan institutions, federal credit unions | Excluded by 45(a)(2) | Banking regulators; see the Banking Cybersecurity Programme Guide |
| Common carriers subject to the Acts to regulate commerce; air carriers | Excluded by 45(a)(2) | FCC, Department of Transportation |
| Non-bank financial institutions (lenders, tax preparers, auto dealers) | In scope, plus the FTC's GLBA Safeguards Rule | GLBA Safeguards Rule Guide |
| Health apps and personal health record vendors outside HIPAA | In scope, plus the Health Breach Notification Rule | FTC Health Breach Notification Rule Guide |
| Foreign companies targeting US consumers | Can be reached where conduct affects US commerce | Order practice and cross-border cooperation |
The legal tests
| Theory | Test | Typical data security fact pattern |
|---|---|---|
| Deception | A material representation, omission or practice likely to mislead consumers acting reasonably | "Bank-grade" or "award-winning" security claims, privacy framework claims, MFA promised but not enforced |
| Unfairness (45(n)) | The practice "causes or is likely to cause substantial injury to consumers which is not reasonably avoidable by consumers themselves and not outweighed by countervailing benefits to consumers or to competition"; public policy may be considered but cannot be the primary basis | Plain-text credentials, no access limits, no monitoring, known vulnerabilities left open, leading to exposure of personal data |
The unfairness test is the one that turns weak security into a legal violation without any promise having been made. Because the injury need only be likely, the FTC can act before data is misused, and has done so after exposures of credentials and personal data.
Key obligations
Section 5 contains no control list. The obligations come from three places: the reasonableness standard applied case by case, the FTC's published guidance distilled from its settlements, and the specific requirements in each order. Read together, they give a consistent picture.
| Start with Security lesson | What the FTC cited | Control expectation |
|---|---|---|
| 1. Start with security | Collecting and keeping data the business did not need | Data minimisation and retention schedules |
| 2. Control access to data sensibly | Uber: one cloud key with full admin rights shared across the company and posted online | Least privilege, restricted admin rights, no shared keys |
| 3. Require secure passwords and authentication | Twitter: guessable, reused passwords; TaxSlayer: credential stuffing | MFA or security keys for source code and databases; rate limits; blocking known compromised passwords |
| 4. Store and transmit sensitive data securely | Plain-text storage | Encryption at rest and in transit |
| 5. Segment and monitor the network | No monitoring of who goes in and out | Segmentation, egress monitoring, alerting |
| 6. Secure remote access | Dave and Buster's: broad third-party access | Device checks, temporary and narrowly scoped vendor access, monitored connections |
| 7. Secure development | Authentication bypass flaws | Secure SDLC and testing |
| 8. Oversee service providers | GMR Transcription, Upromise | Contractual security terms and verification |
| 9. Keep security current | Unpatched and unaddressed vulnerabilities | Patch and vulnerability management, a way to receive reports |
| 10. Secure paper, media and devices | Lost or discarded media | Physical and disposal controls |
What a data security consent order usually requires
- Prohibition on misrepresentation: no false claims about security, privacy or compliance programmes (as in the GoDaddy order finalised on 21 May 2025).
- A comprehensive information security programme: written, with a named senior owner, risk assessment and safeguards. Drizly's order listed training, access controls for personal data and multi-factor authentication for databases and other assets containing consumer data.
- Data minimisation and deletion: Drizly had to destroy personal data it did not need and publish a retention schedule.
- Independent assessments: a qualified third-party assessor reviews the programme; orders typically run for 20 years with assessments every two years.
- Reporting and certification: incident reports to the FTC and annual certification by a senior officer.
- Individual obligations: where an executive is named, duties can follow that person to future companies.
Timeline and current status
| Date | Development | Why it matters |
|---|---|---|
| 1914, amended 1938 | FTC Act; Wheeler-Lea amendment adds unfair or deceptive acts or practices | Consumer protection basis for data security cases |
| 1994 | Section 5(n) codifies the three-part unfairness test | The test the FTC must meet today |
| August 2015 | Third Circuit decision in FTC v. Wyndham | Confirms unfairness reaches data security and rejects the fair notice defence |
| 2018 | Eleventh Circuit decision in LabMD v. FTC | Order vacated as too vague; later orders spell out specific controls |
| 2021 | Supreme Court decision in AMG Capital Management v. FTC | Section 13(b) does not authorise monetary relief, which increases the weight of order violation penalties and rule-based penalties |
| October 2022 | Drizly proposed order naming the CEO | Personal accountability and data minimisation in orders |
| 17 January 2025 | Penalty maximum adjusted to $53,088 | Current figure in 16 CFR 1.98 |
| 21 May 2025 | GoDaddy order finalised, 3-0 vote | MFA, monitoring and secure connections cited as basic failures |
The statute has been stable for decades; what moves is enforcement priority and the content of orders, which change with the Commission's membership. Check the FTC's data security case list for the latest orders before relying on any order term as current practice.
Enforcement and penalties
- Investigation: usually starts after a breach or complaint, often with a civil investigative demand for policies, architecture and incident records. Many investigations close with a closing letter and no action.
- Administrative or federal court route: the FTC can issue an administrative complaint or go to federal court. Most data security matters settle as consent orders.
- Order violations (45(l)): a civil penalty of up to $53,088 per violation (the statute says $10,000, adjusted for inflation), with each day of continuing failure a separate offence.
- Rule violations (45(m)): knowing violations of a trade regulation rule, such as the Health Breach Notification Rule, carry the same per-violation maximum, which is why the FTC prefers rule-based cases where one exists.
- Interplay: state attorneys general bring parallel cases under state law, and the GLBA Safeguards Rule adds specific obligations for non-bank financial institutions.
What it means for AI agents and non-human identities
Several of the FTC's best-known cases are machine identity failures: a cloud access key published to a code-sharing site, shared root credentials never rotated after a contractor left, a corporate GitHub account that held database credentials. The FTC's guidance draws the practical conclusions: distinct keys per person or service, MFA on databases and source code, regular rotation, and no credentials in repositories. These are directly enforceable expectations for anyone already under an order, and persuasive evidence of what "reasonable" means for everyone else.
| NHI or AI practice | Section 5 risk | Control that answers it |
|---|---|---|
| Shared admin cloud keys or root credentials | Unfairness: cited by name in FTC guidance | Per-workload identities, no root use, short-lived credentials; see the Secrets Management Guide |
| Secrets committed to repositories | Unfairness: Uber and Drizly fact patterns | Secret scanning on push, rotation on detection, MFA on code hosting |
| Contractor or vendor keys not revoked | Unfairness: Chegg fact pattern | Offboarding that covers keys and tokens, owner per credential |
| Marketing claims that an AI agent or product is "secure" or "private" | Deception if practices do not match | Claims review by security before publication |
| AI agent with broad access to customer data | Unfairness if foreseeable misuse causes likely substantial injury | Scoped tools, least privilege, logging of agent actions, human approval for bulk exports |
| Third-party SaaS integration with standing OAuth access | Unfairness: unmanaged vendor access (lesson 6 and 8) | Inventory and periodic review of OAuth grants and service principals |
For an inventory model that meets an assessor's expectations, see the Service Account Inventory Template and the API Key Management Guide.
Framework mapping
| FTC expectation | NIST CSF 2.0 | NIST SP 800-53 Rev 5 | CIS Controls v8.1 |
|---|---|---|---|
| Written programme, senior owner | GV.RR-02, GV.PO-01 | PM-1, PM-2 | No direct equivalent |
| Least privilege, no shared keys | PR.AA-05 | AC-6, AC-2 | Controls 5 and 6 |
| MFA on databases and source code | PR.AA-03 | IA-2 | Safeguards 6.3 to 6.5 |
| Secrets out of code, rotation | PR.AA-01 | IA-5 | Control 16 |
| Monitoring and logging | DE.CM-01, DE.CM-03 | AU-6, SI-4 | Control 8 |
| Vendor oversight | GV.SC-05 | SR-3, SA-9 | Control 15 |
| Data minimisation and retention | PR.DS-01 | SI-12 | Control 3 |
Compliance steps
- Inventory your security claims: website, app store listings, sales decks, privacy notices and AI product pages. Map each to evidence; remove or fix claims you cannot prove.
- Benchmark against the ten lessons and recent orders: treat order provisions such as MFA on systems holding consumer data and a named programme owner as the baseline.
- Fix identity and secrets first: eliminate shared admin and root keys, enforce MFA for humans with data access, move workloads to federated short-lived credentials, and scan repositories.
- Minimise data: write a retention schedule and delete what you do not need; less data means less likely injury.
- Govern vendors and integrations: contract terms, access scoped and time-limited, and periodic verification.
- Document reasonableness: keep a dated risk assessment, decisions and exceptions, signed by a senior owner. This is your answer to a civil investigative demand.
- If under an order: build a compliance calendar for assessments, certifications and incident reports, and track each order clause to a control owner.
Detection and measurement
- Claims coverage: percentage of public security claims with mapped evidence; target 100%.
- Shared privileged credentials: count of admin or root credentials used by more than one person or workload; target zero.
- MFA coverage: share of accounts with access to consumer data or source code that enforce MFA.
- Secret exposure dwell time: hours from a secret appearing in a repository to its revocation.
- Stale vendor access: number of vendor accounts, keys or OAuth grants unused for 90 days.
- Data over retention: volume of personal data held past its schedule.
Common failure patterns
- Marketing ahead of engineering: security claims written by sales without evidence are the simplest deception case.
- Assuming no promise means no exposure: unfairness needs no promise.
- Static, shared cloud keys: the fact pattern the FTC returns to most often. The Codefinger S3 ransomware campaign shows that leaked or stolen long-term AWS keys alone were enough to lock and ransom stored data.
- Keeping everything: retained data that served no purpose enlarges the injury and invites a deletion order.
- Treating the order as a project: orders run for years; a control that lapses in year five is an order violation.
- Ignoring AI features: new agent capabilities that reach customer data without access review recreate the old access control failures.
Practitioner checklist
- Map every public security and privacy claim to evidence.
- Score the programme against the ten Start with Security lessons.
- Remove shared admin and root credentials and rotate any that remain.
- Enforce MFA on databases, cloud consoles and source code hosting.
- Scan repositories for secrets and revoke on detection.
- Publish and apply a data retention schedule.
- Scope and time-limit vendor and integration access, and review it.
- Name a senior owner and keep a dated, signed risk assessment.
- Track order obligations clause by clause if you are under an order.
Standards and references
- Cornell LII: 15 U.S.C. 45, Unfair methods of competition unlawful
- eCFR: 16 CFR 1.98, Adjustment of civil monetary penalty amounts
- FTC: Start with Security, A Guide for Business
- FTC: Data Security guidance and cases
- FTC: Action against Drizly and its CEO
- FTC: Order with GoDaddy over data security failures
- FTC: Third Circuit rules in FTC v. Wyndham
- NIST: Cybersecurity Framework 2.0
This guide summarises Section 5 of the FTC Act as applied to data security as of 27 October 2026 and is not legal advice. Related NHI Mgmt Group resources: US State Cybersecurity Laws Map · GLBA Safeguards Rule Guide · FTC Health Breach Notification Rule Guide · Secrets Management Guide