Security Criterion

What Security Criteria Do

Security criteria are the benchmarks used to decide whether a system, process, or control is protected well enough for its purpose. They turn security into something testable: instead of relying on broad claims, teams define the properties that must hold, such as confidentiality, integrity, availability, authentication, authorisation, and auditability.

That makes the term important in both design and assurance. A security criterion is not the control itself, but the standard the control must satisfy. In practice, it helps teams move from “we have security” to “we can show the system meets the required objective.”

How Security Criteria Shape Design and Assurance

Security criteria are usually set early, because they influence architecture, control selection, and testing. If the criterion is strong authentication, the design may need phishing-resistant sign-in. If the criterion is integrity, the system may need tamper detection, protected change paths, and verification checks. Criteria therefore define what “good enough” means before implementation begins.

They also give auditors, architects, and operators a common reference point. The same criterion can be used to evaluate a design proposal, a vendor feature, a test result, or an incident review. That consistency matters because security failures often begin with unclear expectations rather than missing tools.

Common Security Properties Used as Criteria

Many security criteria are expressed as core properties. Confidentiality asks whether information is disclosed only to authorised parties. Integrity asks whether data and actions remain accurate and unaltered. Availability asks whether systems remain usable when needed. Authentication and authorisation check whether access decisions are trustworthy and correctly enforced.

Other criteria may include traceability, non-repudiation, resilience, and auditability, depending on the environment. A payment system, for example, may need stronger evidential controls than an internal prototype. The right criterion depends on the risk being addressed, not on a fixed list copied from another system.

Why Security Criteria Need Clear Tests

A criterion is only useful if it can be tested or reviewed. Vague statements such as “the system should be secure” do not help engineering or assurance work. Clear criteria make it possible to define evidence, measure control effectiveness, and spot gaps between intended design and real-world behaviour.

That is why security criteria should be written in a way that supports validation. Teams should be able to answer whether the requirement was met, how it was checked, and what evidence proves it. Without that, a criterion becomes a slogan rather than a decision tool.

For practical control mapping, teams often align criteria to control catalogues such as NIST SP 800-53 Rev 5 Security and Privacy Controls, which helps translate abstract security objectives into testable control expectations.

Risk and Threat Considerations

Weak or ambiguous security criteria create false confidence. If a team cannot state what must be protected, attackers and failures exploit the gap through incomplete controls, misapplied trust, or untested assumptions. The result is often inconsistent protection across systems that were believed to meet the same standard.

Failure mechanism: unclear criteria lead to controls being selected or measured against the wrong objective, so gaps remain hidden until a breach, audit finding, or operational incident exposes them.

Impact: organisations can end up with authorised access paths, data handling, or monitoring that look acceptable on paper but fail under attack, misuse, or normal system drift.

Practitioner Guidance

Governance implication: security criteria should be owned by the same process that owns the system requirement, risk decision, or assurance case. If no one is accountable for stating and validating the criterion, the control goal often becomes informal and unevenly applied.

What to watch for: watch for criteria that are too broad to test, copied from another context, or expressed only as aspirations. Strong criteria are specific enough to drive design choices, review evidence, and support a pass or fail judgement.

Practitioner takeaway: treat security criteria as the bridge between intent and proof, because the most important security question is not whether a control exists, but whether it meets the requirement it was meant to satisfy.

Related resources from NHI Mgmt Group

• Why has identity replaced the network perimeter as the primary security boundary?
• What is phishing-resistant authentication and how does it relate to NHI security?
• What is the first step in building a modern NHI security programme?
• Why is ownership assignment critical for NHI security?