What does "reasonable security" actually mean?

It's a flexible legal standard rather than a specific list of controls. It generally asks whether an organization's safeguards were appropriate given the sensitivity of the data it held and the risks it could reasonably foresee. Regulators and courts often look to recognized frameworks — the NIST Cybersecurity Framework, the CIS Critical Security Controls, ISO 27001 — as reference points for what "reasonable" looks like, and timely patching of known vulnerabilities is a recurring theme across all of them.

Who enforces the reasonable security standard in the US?

At the federal level, the FTC has long treated inadequate data security as an "unfair" practice under Section 5 of the FTC Act, an authority a federal appeals court affirmed in FTC v. Wyndham (3rd Cir. 2015). At the state level, roughly two dozen states plus DC require reasonable security by statute — Massachusetts 201 CMR 17.00 and New York's SHIELD Act are among the most detailed. California's CCPA also lets consumers sue directly when a breach results from a failure to maintain reasonable security.

Does running legacy software automatically violate the standard?

No. The standard is about whether safeguards were reasonable, not about the age of any one system, and an older system protected by strong compensating controls may still be defensible. The difficulty is that an unsupported, end-of-life platform can no longer receive security patches, and "patch known critical vulnerabilities" is one of the most consistent expectations across frameworks and enforcement actions. A system that structurally can't be patched makes the reasonableness argument harder to make and harder to defend after the fact.

How do you demonstrate that your security was reasonable?

You demonstrate it with a record, not an assertion. In practice that means adopting a recognized framework (NIST CSF, the CIS Controls, or ISO 27001) and being able to show you actually followed it, keeping an inventory of the data you hold and where it lives, patching known critical vulnerabilities on a defensible cadence, controlling and logging access, and documenting the risk decisions you made and why. Reasonableness is judged after the fact, often after a breach, so the contemporaneous paper trail is the point. A decision that was reasonable but undocumented is far harder to defend than one you can show you weighed at the time.

Does complying with HIPAA or PCI DSS satisfy the reasonable security standard?

It helps, but it is not automatic. Meeting a specific regime like the HIPAA Security Rule or PCI DSS is strong evidence you took recognized safeguards seriously, and regulators treat that alignment as a point in your favor. But reasonable security is broader and context-driven, so a control that technically satisfies a checklist can still be found unreasonable if it left an obvious, foreseeable risk open. Treat framework compliance as a floor that makes the reasonableness case easier to argue, not a ceiling that ends the question.

The "Reasonable Security" Standard & Legacy Tech

ModernLift ·June 25, 2026 ·9 min read

"Reasonable security" is the standard most US data-security law is written against — the FTC enforces it under the Section 5 prohibition on unfair practices, and roughly two dozen states require businesses to maintain reasonable safeguards. It is deliberately not a fixed checklist; it asks whether a company's protections were appropriate to the sensitivity of the data and the foreseeable risks. Timely patching is a recurring expectation, so an unsupported, unpatchable legacy system makes the standard harder to satisfy. This is educational, not legal advice.

Most US data-security obligations don’t hand you a checklist. They hold you to a standard: reasonable security. It sounds soft, even vague — until a breach happens and the question becomes whether your protections were reasonable for the data you held and the risks you could see coming. That’s the standard regulators enforce, the one plaintiffs invoke, and the one an unsupported legacy system quietly makes harder to meet.

This page explains what “reasonable security” means in practice, where it comes from, and why end-of-life technology sits awkwardly against it. It’s educational, not legal advice — the legal judgment in any specific situation belongs to your counsel.

What “reasonable” actually means

The reasonable security standard is deliberately not a fixed list of controls. Technology and threats change too fast for that. Instead it asks a contextual question: were the safeguards appropriate to the sensitivity of the data and the risks the organization could reasonably foresee?

Because the standard is open-ended, regulators and courts tend to anchor it to recognized frameworks — the NIST Cybersecurity Framework, the CIS Critical Security Controls, and ISO 27001 are the common reference points. None of them is the law, but they describe what mainstream practice looks like, and falling well short of all of them is hard to defend. Across every one of them, a few expectations recur: know what data you hold, control access to it, monitor for intrusions, and patch known vulnerabilities promptly. That last one is where legacy systems run into trouble.

Where the standard comes from

The standard shows up in several places at once, which is part of why it’s hard to ignore.

The FTC, under Section 5. The Federal Trade Commission has long treated unreasonable data security as an “unfair” practice under Section 5 of the FTC Act. In FTC v. Wyndham Worldwide (3rd Cir. 2015), a federal appeals court affirmed that the FTC has authority to bring data-security cases under the unfairness prong and is not required to first publish specific security rules — companies are expected to have fair notice that grossly inadequate security can be unfair. The Wyndham matter itself involved intrusions the FTC said compromised more than 619,000 payment-card numbers and over $10.6 million in fraud loss.
State data-security laws. Roughly two dozen states plus the District of Columbia require businesses to maintain reasonable security by statute. Massachusetts’ 201 CMR 17.00 is among the most prescriptive, requiring a written information security program with administrative, technical, and physical safeguards. New York’s SHIELD Act similarly requires “reasonable safeguards” across those same three categories.
Private litigation. California’s CCPA includes a private right of action (Cal. Civ. Code § 1798.150) that lets consumers sue when nonencrypted personal information is exposed as a result of a business’s failure to maintain reasonable security — with statutory damages set at $100 to $750 per consumer per incident, subject to a 30-day cure notice. That turns “reasonable security” from a regulator’s concern into something individuals can litigate directly.

The same expectation shows up commercially, too: cyber-insurance underwriters increasingly treat timely patching and the removal of unsupported software as conditions of coverage, which is why an unpatchable system can surface as a renewal blocker long before it surfaces in court.

A handful of states pull in the other direction with safe harbors: Ohio’s Data Protection Act, for example, offers an affirmative defense to certain tort claims for organizations that maintain a written cybersecurity program conforming to a recognized framework (NIST CSF, NIST SP 800-171/800-53, FedRAMP, the CIS Controls, or ISO 27000). The safe harbor is itself evidence of where the bar sits — it rewards the same framework alignment everyone else is measured against.

Why legacy tech undermines it

Nothing in the standard says “old software is illegal.” A well-isolated older system under strong compensating controls can be entirely defensible. The problem is structural, and it’s specific:

An end-of-life system can’t be patched. When the vendor stops shipping security fixes, “patch known critical vulnerabilities promptly” stops being achievable. The single most consistent expectation across frameworks becomes one the platform physically cannot meet.
It often can’t do modern controls natively. MFA, strong encryption, and complete audit logging are retrofits on architectures that predate the expectation — and retrofits are exactly what assessors and plaintiffs probe.
It makes failure look foreseeable. Reasonableness turns on what you could see coming. A breach through an unpatched, known vulnerability on a system you knew was unsupported is hard to characterize as an unforeseeable accident.

The most cited illustration is the 2017 Equifax breach, which exposed personal data on roughly 147 million people. The entry point was a known Apache Struts vulnerability (CVE-2017-5638) for which a patch had been available since March 2017 but was never applied. Equifax later agreed to a settlement with the FTC, CFPB, and states of at least $575 million, and potentially up to $700 million. The breach is remembered less for being sophisticated than for being preventable — the gap between an available patch and an unpatched system is exactly the gap the reasonable security standard is built to scrutinize.

What the standard expects	Where an unsupported legacy system falls short
Patch known critical vulnerabilities promptly	The vendor no longer ships patches — the fix will never arrive
MFA, encryption, complete logging	Older architectures can’t do these natively; they’re bolt-ons
Safeguards appropriate to data sensitivity	Sensitive data sitting on an abandoned platform is hard to call appropriate
Foreseeable risks addressed	A known, public vulnerability left open reads as foreseeable, not bad luck

How you show your security was reasonable

Because reasonableness is judged after the fact, usually after a breach, the practical goal is to build a contemporaneous record that your safeguards were appropriate and your known gaps were being closed. There is no certificate for this. There is a body of evidence you either have or you do not. The recurring elements across enforcement actions and framework guidance are consistent enough to list.

Pick a recognized framework and actually follow it. NIST CSF, the CIS Controls, or ISO 27001. The value is not the badge. It is that you can point to a mainstream standard and show your program maps to it.
Keep an inventory of the data you hold and where it lives. You cannot protect, or argue you reasonably protected, data you cannot locate. This is also the first thing an unmapped legacy estate makes impossible.
Patch known critical vulnerabilities on a defensible cadence. This is the single most consistent expectation, and the one an end-of-life system structurally cannot meet.
Control and log access. Who could reach the data, and can you show it.
Document the risk decisions you made and why. A reasonable decision you cannot evidence is weak in hindsight. A reasonable decision with a dated rationale is defensible.

Notice how much of that list is about being able to show something. A modern, instrumented system produces this evidence as a byproduct of running. A legacy estate that cannot patch, cannot log, and cannot even map its own data forces you to reconstruct the record by hand, exactly when you can least afford the time.

How modernization restores the argument

Meeting the reasonable security standard isn’t about a single heroic upgrade; it’s about being able to show that your safeguards are appropriate and that known gaps get closed. That’s something a documented, validated modernization produces as a byproduct.

The highest-exposure components — the unpatchable systems in a sensitive-data path — become the first slices. They’re modernized slice by slice behind a strangler facade so the business keeps running, onto supported platforms that can patch, enforce MFA, and log natively. Each slice is proven to behave identically to the legacy before it carries live traffic, and the work leaves an audit trail — the change record that demonstrates due care rather than asserting it. AI-accelerated discovery reads the codebase and dependencies end to end and captures the real behavior, including the undocumented logic, under senior-engineer review, so the remediation targets the actual exposure. Reasonable security defended on evidence is far stronger than reasonable security defended on hope.

Not every old system is unreasonable

This is educational, not legal advice, and “reasonable” is ultimately judged case by case — by regulators, courts, and your counsel, on facts we don’t decide. Plenty of older systems are perfectly reasonable to keep: a stable component outside any sensitive-data path, well-segmented and supported, may carry little of this exposure at all. The standard bites hardest where an unpatchable system sits in a regulated or sensitive-data path and a known vulnerability stays open because no fix can ship. We’ll help you tell those situations apart honestly rather than escalate every old system to a legal problem.

Where to start

The first step is to see where a legacy system actually undermines the reasonable security argument — and where it doesn’t. A discovery call scopes which systems sit in sensitive-data paths, which can no longer be patched, and what a remediation path would look like — on evidence, not a pitch. The legacy system liability assessment goes deeper on the regulatory, contractual, and fiduciary angles. Reach the team at sales@modernlift.ai.

Frequently asked questions

What does "reasonable security" actually mean?: It's a flexible legal standard rather than a specific list of controls. It generally asks whether an organization's safeguards were appropriate given the sensitivity of the data it held and the risks it could reasonably foresee. Regulators and courts often look to recognized frameworks — the NIST Cybersecurity Framework, the CIS Critical Security Controls, ISO 27001 — as reference points for what "reasonable" looks like, and timely patching of known vulnerabilities is a recurring theme across all of them.
Who enforces the reasonable security standard in the US?: At the federal level, the FTC has long treated inadequate data security as an "unfair" practice under Section 5 of the FTC Act, an authority a federal appeals court affirmed in FTC v. Wyndham (3rd Cir. 2015). At the state level, roughly two dozen states plus DC require reasonable security by statute — Massachusetts 201 CMR 17.00 and New York's SHIELD Act are among the most detailed. California's CCPA also lets consumers sue directly when a breach results from a failure to maintain reasonable security.
Does running legacy software automatically violate the standard?: No. The standard is about whether safeguards were reasonable, not about the age of any one system, and an older system protected by strong compensating controls may still be defensible. The difficulty is that an unsupported, end-of-life platform can no longer receive security patches, and "patch known critical vulnerabilities" is one of the most consistent expectations across frameworks and enforcement actions. A system that structurally can't be patched makes the reasonableness argument harder to make and harder to defend after the fact.
How do you demonstrate that your security was reasonable?: You demonstrate it with a record, not an assertion. In practice that means adopting a recognized framework (NIST CSF, the CIS Controls, or ISO 27001) and being able to show you actually followed it, keeping an inventory of the data you hold and where it lives, patching known critical vulnerabilities on a defensible cadence, controlling and logging access, and documenting the risk decisions you made and why. Reasonableness is judged after the fact, often after a breach, so the contemporaneous paper trail is the point. A decision that was reasonable but undocumented is far harder to defend than one you can show you weighed at the time.
Does complying with HIPAA or PCI DSS satisfy the reasonable security standard?: It helps, but it is not automatic. Meeting a specific regime like the HIPAA Security Rule or PCI DSS is strong evidence you took recognized safeguards seriously, and regulators treat that alignment as a point in your favor. But reasonable security is broader and context-driven, so a control that technically satisfies a checklist can still be found unreasonable if it left an obvious, foreseeable risk open. Treat framework compliance as a floor that makes the reasonableness case easier to argue, not a ceiling that ends the question.