Reasonable Security Is Not Perfect Security. It Is Defensible Security.

Reasonable Security Is Not Perfect Security. It Is Defensible Security.

A practical guide for business and technology leaders who need to assess risk, validate safeguards, and make security decisions that hold up under scrutiny.

If your organization experienced a serious cyber incident tomorrow, could you explain why the security decisions you made were reasonable?

Organizations are not expected to prevent every attack or eliminate every risk. They are increasingly expected to make informed, risk-based security decisions and show that those decisions were implemented, tested, and revisited over time.

Reasonable security is not simply buying more tools, completing a compliance checklist, or adopting a framework. It is the ability to show that the organization understood its risks, selected appropriate safeguards, verified that they worked, and documented the reasoning behind important decisions.

The HIPAA Security Rule, FTC Safeguards Rule, DFARS, and multiple state laws use risk-based terms such as “reasonable,” “appropriate,” “adequate,” or “commensurate.” These authorities have different scopes and legal effects, but each connects security decisions to circumstances and risk.

A defensible program brings these elements together: risk assessment, safeguard selection, documentation, and verification.

Risk Assessment Is the Foundation

A defensible cybersecurity program begins with a meaningful risk assessment. The assessment should identify a foreseeable event, the systems and data involved, who could be affected, the safeguards already in place, and the potential likelihood and impact.

A compliance gap or maturity assessment can inform this work, but it does not always answer the same questions. A checklist may show that multifactor authentication is missing. A risk assessment asks what an attacker could reach, who could be harmed, how likely the scenario is, and which treatment options are reasonable.

Before scoring individual risks, establish impact levels, a consistent likelihood method, treatment thresholds, and approval authority. This reduces the temptation to create criteria around a preferred answer.

Risk management is an ongoing cycle. Organizations identify and evaluate risks, select safeguards, test their effectiveness, and reassess as circumstances change.

A Finding Should Lead to a Decision

A risk finding is not the end of the process. It should lead to a decision to reduce, avoid, transfer, or accept the risk. For each feasible treatment, leadership should compare the expected reduction in likelihood or harm against cost, disruption, and any new risk the safeguard creates.

Evaluate each safeguard against four considerations: whether it addresses the threat, how much risk it reduces, the burden of implementation, and the risk that remains.

The best answer is not automatically the most expensive control or the least expensive option. The objective is a proportionate response that addresses the actual threat and leaves a level of risk the organization can support and explain. Mandatory legal, regulatory, and contractual requirements still must be met.

Insurance and contracts can move some financial consequences, but they do not eliminate the underlying event or the harm that customers and others could experience. Treat transfer as one part of the decision, not as a substitute for safeguards.

A Planned Control Is Not a Working Control

Policies and implementation plans describe intent. They do not prove that a safeguard operates consistently across the environment. That is why proactive security testing is essential.

To determine whether a safeguard works as intended:

• Confirm which systems, applications, accounts, and locations are actually covered.
• Test common bypass paths, including recovery, exception, and vendor-access workflows.
• Verify that alerts are generated, reviewed, and acted on.
• Track exceptions with an owner, approval, expiration date, and compensating controls.
• Reassess remaining risk using observed results rather than assumed effectiveness.

‍

A vulnerability assessment, penetration test, or control review can uncover gaps that are invisible in a policy document. The testing result may also change the risk decision by showing that a control provides less coverage than expected or that an unexpected attack path remains.

Evidence should demonstrate more than initial implementation. It should show coverage, testing results, ongoing monitoring, and how approved exceptions are managed.

Document the Decision Before You Need to Defend It

Risk documentation does not need to become a hundred-page exercise. A concise decision record can show that the organization identified the issue, evaluated alternatives, assigned accountability, and followed through.

Document three key elements:

• The risk: The foreseeable event, affected systems and parties, potential harm, and existing safeguards.
• The decision: Alternatives considered, the selected response, rationale, owner, deadline, remaining risk, and approver.
• The evidence: Implementation and testing results, monitoring, exceptions, and reassessment triggers.

‍

Internal risk acceptance is a management decision. It does not, by itself, establish legal reasonableness. It does provide evidence that the organization made a deliberate decision and retained supporting information.

Six Questions for Leadership

1. Have we established consistent criteria for evaluating cybersecurity risk?
2. Do our assessments identify specific events, affected parties, and potential harm?
3. Do we compare feasible treatment options instead of defaulting to one solution?
4. Does every significant risk decision have an owner, deadline, and accountable approver?
5. Have we tested whether the selected safeguards actually work?
6. Can we produce the documentation and evidence supporting the decision?

‍

These questions are a decision aid, not a legal safe harbor or guarantee against breach. They help leadership determine whether the organization is actively managing cybersecurity risk or merely accumulating tools and documents.

Turn Risk Analysis Into Action

Many organizations do not need another generic list of recommendations. They need to know which risks matter most, whether current safeguards address those risks, where credible attack paths remain, and what leadership should decide next.

GO Security Pro helps organizations connect risk analysis with technical validation through:

• Organization-wide, application, system, and third-party risk assessments
• Virtual CISO support, including risk-management planning, risk-register maintenance, and policy development
• Penetration testing, vulnerability assessments, and vulnerability-management support

‍

The best time to evaluate whether your security program is defensible is before an attacker, customer, insurer, regulator, or attorney asks you to prove it.

Sources and Editorial Notes

The regulatory examples and risk-management concepts in this article were adapted from “The Reasonable Security Standard: Building a Defensible, Not Perfect, Cybersecurity Program,” GO Security Pro, September 30, 2026. The presentation cites the following primary and standards-based sources:

• HIPAA Security Rule, 45 CFR Part 164
• FTC Safeguards Rule, 16 CFR Part 314
• DFARS 252.204-7012
• New York Department of Financial Services Cybersecurity Regulation, 23 NYCRR Part 500
• NIST Cybersecurity Framework 2.0 and NIST SP 800-30 Rev. 1
• CIS Risk Assessment Method v2.2 and the Duty of Care Risk Analysis Standard

‍

The article’s implementation guidance and service recommendations are broader practical recommendations from GO Security Pro. They should not be read as legal advice or as a universal cybersecurity checklist.