Join our Newsletter — 33% off our NHI Course

Reasonable Cybersecurity Programme

A reasonable cybersecurity programme is a documented set of controls that matches the nature of the organisation and the risks it faces. The standard is not one fixed product or checklist, but a defensible combination of policy, technical controls and evidence that those controls were in place and operating.

What Makes a Cybersecurity Programme “Reasonable”

A reasonable cybersecurity programme is judged against the organisation it protects, not against a universal checklist. The practical question is whether the programme reflects the nature of the business, the sensitivity of the assets, the threat environment and the operational realities that shape what can be defended well.

That makes “reasonable” a defensible standard of fit, not perfection. A small business, a critical supplier and a highly regulated platform may all have different control sets and different levels of evidence, yet each can still be reasonable if the programme is coherent, documented and aligned to actual risk.

What a Reasonable Programme Contains

A reasonable programme usually combines governance, prevention, detection and response in a way that is proportionate to the environment. In practice, that means written policy, assigned ownership, technical safeguards, monitoring, incident handling and periodic review, with the control mix shaped by what the organisation actually does.

The key feature is internal consistency. Policies should describe the intended control posture, operational controls should make that posture real, and evidence should show the controls were implemented and maintained. Frameworks such as NIST Cybersecurity Framework 2.0 are useful because they map those expectations into govern, identify, protect, detect, respond and recover activities.

For control depth, a reasonable programme often draws from established control catalogues rather than inventing its own model. NIST SP 800-53 Rev 5 Security and Privacy Controls is a strong reference point for structuring access control, logging, configuration management and system integrity in a way that can be evidenced.

How Reasonableness Is Evaluated

Reasonableness is typically assessed by looking at whether the programme is suitable for the organisation’s size, data, dependencies and exposure, and whether management can show it was actually operating. A programme can fail this test either by being too thin for the risk or by existing only on paper.

Evidence matters because reasonableness is as much about execution as design. Policies, inventories, approvals, monitoring records, vulnerability handling, training records and incident reports all help demonstrate that controls were not merely aspirational. Where identity and access are in scope, NIST SP 800-63 Digital Identity Guidelines helps anchor the strength of authentication and assurance decisions.

The standard is therefore contextual, but not vague. A reasonable programme is one that a competent reviewer can trace from risk to control to evidence, and that can explain why stronger controls were not required for that specific environment.

This term matters because “reasonable” often becomes the test for whether a security programme was adequate after an incident, during assurance reviews, or in disputes about diligence and oversight. It is a governance concept as much as a technical one: leaders must be able to show that security decisions were intentional, risk-based and documented.

It also matters because the programme is judged in context. A mature organisation with sensitive data, external dependencies or broad attack surface may need more stringent controls than a low-risk organisation, even if both claim to have a cybersecurity programme. A framework such as CISA Secure by Design is helpful when the question is whether baseline engineering choices reduce avoidable exposure from the start.

For organisations operating in cloud or distributed environments, the same reasonableness test often turns on whether secure defaults, configuration control and privilege boundaries were treated as first-class design concerns. That is where practical control coverage, not just policy language, becomes decisive.

Risk and Threat Considerations

A cybersecurity programme becomes unreasonable when the control set is mismatched to the organisation’s real exposure, when critical safeguards are missing, or when the evidence does not support the claimed posture. Attackers and failures exploit those gaps, especially where weak governance leaves high-value systems, credentials or external dependencies under-protected.

Failure mechanism: The most common failure is false assurance, where a documented programme exists but controls are incomplete, outdated, not operated consistently, or not measurable. That gap makes it difficult to detect compromise, prove diligence, or close obvious paths to misuse.

Impact: The result can be avoidable intrusion, lateral movement, data loss, service disruption, failed audits, contractual disputes or weaker legal defensibility after an incident. In practice, unreasonable programmes tend to fail at the same point, they cannot show that security measures matched the actual risk.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.

Framework Control / Reference Relevance
NIST CSF 2.0 GV.RM-01 — Risk Management Strategy Defines cybersecurity as risk-based and context-specific for the organisation.
GV.OV-01 — Oversight of Risk Management Supports governance oversight of whether controls and evidence match stated risk posture.
Recommendation — Align the programme to the organisation’s risk strategy and document why chosen controls fit the environment. Assign oversight to verify the programme is operating as intended and documented evidence exists.
NIST SP 800-53 Rev 5 PM-1 — Information Security Program Plan Directly supports a documented, organisation-wide security programme structure.
RA-3 — Risk Assessment Supports selecting controls based on the organisation’s actual risks and environment.
Recommendation — Maintain an information security program plan that records scope, objectives, and control responsibilities. Perform and update risk assessments to keep controls proportional to current exposure.
ISO/IEC 27001:2022 A.5.1 — Policies for information security Anchors the need for documented security policy as part of a defensible programme.
Recommendation — Publish and maintain information security policies that reflect business context and risk.

Practitioner Guidance

Why practitioners should care: The useful test is not whether a programme sounds mature, but whether it would stand up under scrutiny from an informed internal reviewer, regulator, auditor or plaintiff expert. That means the programme should be specific enough to show risk-based design and operational enough to show it was active.

Common misunderstanding: Teams often treat policy volume or tool count as proof of reasonableness. In reality, a smaller set of well-chosen, well-run controls is stronger than a broad but weakly evidenced control stack.

Practitioner takeaway: If you cannot clearly link the organisation’s risks to the controls selected, and then to the evidence that those controls were working, the programme is unlikely to be viewed as reasonable.