home  /  standard of care  /  reasonable security
the standard · cybersecurity incidents

Reasonable security.

Not perfect security, and not a checklist. Measures aligned to the risk the organization actually carried.

begin here

What happened, and when did you learn of it?

Start a conversation with the Incident Concierge, already scoped to reasonable security. Pick a starting point, or describe the incident directly.

Incident Conciergereasonable security · orientation, not a security opinion
Tell me about the organization — roughly its size, what data it held, and what happened. I'll help you see what a reasonable-security analysis would examine and what evidence it needs. I won't reach the conclusion for you.

Courts and regulators increasingly evaluate breach negligence against a standard of reasonable security, and the phrase has become considerably less amorphous than it was. The working formulation has three parts, each load-bearing: safeguards aligned to the organization's actual risks, feasible with technology available at the time, and not imposing disproportionate burden on the security program. Read together they describe a proportionality test rather than a compliance threshold, which is why two organizations with identical control sets can land on opposite sides of it. The organization holding millions of health records faces a different standard from the one holding a mailing list, and the analysis that ignores that difference is not doing the work.

mechanisms

What the analysis examines.

The controls an expert works through, and what each is asked to show.

Access and identity

Who could reach what, whether privilege was least-privilege, and whether multi-factor was where it needed to be.

Patching and vulnerability management

Not whether every patch was current, but whether there was a functioning process and known-critical gaps were closed.

Segmentation

Whether one compromised foothold could reach everything. Frequently the difference between an incident and a catastrophe.

Monitoring and detection

Whether the organization could see the intrusion, and how long it actually took.

Backup and recovery

Whether backups existed, were isolated, and had been tested. Decisive in ransomware matters.

Response planning

Whether a plan existed before it was needed, and whether anyone had rehearsed it.

methodology

What the evidence shows — and what we examine.

How the assessment is built.

Anchor to the pre-incident recordRisk assessments, budgets, vulnerability reports and decisions as they stood before the breach.
Compare to sector practiceWhat comparable organizations actually did, which is a stronger benchmark than any framework alone.
Test proportionalityWhether the safeguards matched the data held and the threats faced, both ways.
Document the decisionsA documented, reasoned decision not to implement a control is defensible. An undocumented one is not.
what's at stake

What the standard decides.

Nearly everything downstream: causation, damages and settlement posture all move with it.

whether negligence is established settlement posture on both sides insurance coverage and subrogation exposure of officers and directors regulatory consequences how early the case can be assessed

The record of what you declined is the case.

A documented risk decision — assessed, reasoned, accepted — is defensible. A known-critical vulnerability raised internally and quietly deferred is the single most damaging document a plaintiff can find, and it is usually in the vulnerability scans.

common questions

Reasonable security — practical questions.

Is there a list we can just comply with?

No, and organizations that believe there is tend to be the ones that fare badly. Frameworks like NIST CSF, ISO 27001 and the CIS Controls describe accepted practice and are genuinely useful, but they are risk-management structures rather than compliance floors, and every one of them expects you to decide which controls apply to your circumstances. That decision is the substance of the standard. A program mapped to a framework with reasoned, documented exceptions is far stronger than an unreasoned attempt at complete coverage.

Does a breach itself prove the security was unreasonable?

It should not, and resisting that inference is much of what the defense analysis does. Sophisticated attackers compromise well-defended organizations, zero-days exist, and a determined adversary with time will often succeed against reasonable safeguards. The legal question is whether the safeguards were reasonable beforehand, not whether they held. That said, the manner of the breach matters enormously: an intrusion through an unpatched vulnerability with a published exploit and a year-old fix is a very different fact pattern from a novel supply-chain compromise.

How much does organization size change the standard?

Substantially, because proportionality is built into the standard rather than being an excuse bolted onto it. A small business is not held to the security program of a bank. But size cuts both ways and smaller organizations often misread it: what scales down is the sophistication and cost of the program, not the basic controls. Multi-factor authentication, tested backups and a patching process are expected essentially everywhere now, and their absence is difficult to defend at any size.

When should this analysis be done?

Before it is demanded, if the organization has any choice. Done in litigation, it is adversarial, expensive and constrained by what evidence survived. Done independently in advance, the same analysis tells a board whether it is exposed while there is still time to act, and it produces exactly the documented risk decisions that make the position defensible later. Where an incident has already occurred, the answer is immediately — for the evidence reason, since the record the analysis depends on has a short life.

related

Related specialization areas & resources.

Know the security position early.

Describe the environment and the incident. The Institute will help you see what the analysis needs.

incident conciergeorientation · not a security opinion
Tell me about the organization — roughly its size, what data it held, and what happened. I'll help you see what a reasonable-security analysis would examine and what evidence it needs. I won't reach the conclusion for you.