What do teams get wrong when defining security requirements for new systems?

A common mistake is treating security requirements as separate from functional and non-functional design choices. Teams also understate the challenge of changing threats, fail to align stakeholders early, and write requirements that are difficult to measure or test. When requirements are vague, implementation becomes inconsistent and later assurance work is much harder.

Where Teams Most Often Go Wrong

Security requirements fail when they are written as a separate checklist instead of being tied to the system’s trust boundaries, data flows, access model, and operational constraints. The strongest requirements are specific enough to drive design decisions, but many teams stop at broad statements like “use MFA” or “encrypt data” without defining who must prove what, under which conditions, and how the requirement will be verified.

Another recurring mistake is treating requirements as static. New systems are usually built in environments where integrations, threats, dependencies, and users change quickly, so a requirement that looked sufficient at design time can become incomplete before release. If the team does not revisit assumptions with architecture, product, security, and operations together, gaps tend to appear late and become expensive to fix.

• Define requirements in terms of observable behaviour, not intentions.
• Anchor them to assets, trust boundaries, and abuse cases as well as business goals.
• Make sure security and non-security requirements are resolved together, not in sequence.
• Write them so they can be tested during build, integration, and acceptance.

Teams also underestimate how much ambiguity damages later assurance work. A requirement that cannot be measured, tested, or traced to a specific control usually turns into inconsistent implementation, weak evidence, and arguments at review time. For that reason, some of the best requirement work is less about adding more controls and more about removing vagueness.

Good requirement writing is also about deciding what the system must not do. That includes unsafe defaults, excessive trust, unchecked external input, overbroad access, and unclear error handling. These are common failure points because they sit between functional design and security design, so they are easy to miss unless they are named explicitly.

Why “Good Enough” Requirements Break Down in Practice

Requirements break down when they are framed as one-off statements instead of control points across the system lifecycle. Security choices for authentication, authorization, logging, retention, recovery, and third-party integrations affect one another, so a requirement that ignores those dependencies often produces a design that is technically compliant but operationally weak.

That is why measurable wording matters. “Protect sensitive data” is not enough on its own; a team needs to know which data classes are covered, what protection is required in transit and at rest, which exceptions are allowed, and what evidence demonstrates compliance. The more a requirement can be traced to a specific implementation test or review question, the less likely it is to drift during delivery.

For application security teams, OWASP ASVS is a useful reference point for turning vague intent into testable requirements for authentication, access control, and validation, while the OWASP ASVS helps teams express those expectations in a form that can actually be verified. For broader engineering governance, OWASP SAMM is useful because it pushes requirements back into the software delivery lifecycle rather than treating them as an afterthought.

When the system depends on APIs, service accounts, or automated integrations, requirements also need to cover privilege boundaries and credential behaviour early. NHIMG’s Ultimate Guide to NHIs, what are non-human identities is a practical way to connect those requirements to the realities of machine access, and the same guide’s regulatory and audit perspectives section is helpful when the requirement has to survive review, not just implementation.

What Strong Requirement Writing Looks Like for New Systems

Strong teams write security requirements as decisions, not slogans. They specify the control objective, the scope, the measurable threshold, the owner, and the evidence that will prove the requirement has been met. That usually means fewer requirements, but each one is sharper and easier to enforce.

What to verify: Check whether every security requirement can be traced to a concrete design element, test case, or operational control. If a requirement cannot be evaluated by engineering or assurance without interpretation, it is still too vague.

What to prioritise: Start with requirements that shape architecture early, especially identity and access paths, data protection, logging, and recovery. Those choices are hardest to retrofit once the system is built, and they tend to determine the rest of the control set.

Common mistake: Do not write requirements only for the steady-state happy path. New systems fail most often at exception handling, integration boundaries, onboarding, offboarding, and change management, so those cases need explicit treatment.

NIST Cybersecurity Framework 2.0 is useful when the requirement set needs a structure for governance, protection, detection, response, and recovery across the whole system. For implementation depth, NIST AI Risk Management Framework and NIST Privacy Framework are relevant where the new system materially changes risk, data handling, or decision transparency.

Practitioner takeaway: The best security requirements are the ones engineering can implement, test, and prove, because vague requirements usually fail later as inconsistent design, weak assurance evidence, and expensive rework.

Related resources from NHI Mgmt Group

• What do security teams get wrong about first-day access for new hires?
• What do security teams get wrong about least privilege for autonomous systems?
• What do security teams get wrong about least privilege for agentic systems?
• What do security teams get wrong about fingerprinting hardened AI systems?