Minimum Viable Security

What Minimum Viable Security Means in Practice

Minimum viable security is not a weaker version of security, it is a deliberately scoped baseline. The goal is to protect the product with the smallest effective control set, then improve coverage through automation and iteration as the system, team and threat profile mature.

That framing matters because many teams try to start with a “perfect” control stack and end up with brittle processes, alert fatigue, or controls that developers bypass. A viable baseline is one the team can actually sustain, measure and evolve.

Why the “Minimum” Has to Be Risk-Based

The controls that belong in a minimum viable set depend on what the product stores, how it is exposed, and what would hurt most if it were abused or unavailable. A customer-facing SaaS app, an internal admin console and an embedded product will not share the same starting point, even if they use the same technology stack.

The right baseline is therefore shaped by business-critical assets, trust boundaries and the consequences of failure, not by a generic checklist. If the minimum does not reduce meaningful risk, it is just security theatre; if it is too broad, it stops being viable.

What Makes Security “Viable” for Delivery Teams

Viability is about fit. A control only belongs in the baseline if it can be applied repeatedly with low friction, clear ownership and reliable evidence. In practice, that usually means choosing controls that can be built into code, pipelines, defaults and platform guardrails rather than relying on manual review for every change.

This is why minimum viable security often favours prevention and hardening that scale with delivery, alongside simple detection that gives teams fast feedback. The point is to reduce repeated human decision-making where the decision should be encoded once and enforced consistently.

For teams building software at speed, this is where security maturity often intersects with OWASP SAMM, because the practical question is how to make core security activities repeatable inside the delivery lifecycle.

How Minimum Viable Security Evolves Over Time

A minimum viable baseline should not be static. As a product grows, the same control set may no longer be enough because the attack surface, dependency chain and operational blast radius have expanded. The mature version of the idea is continuous right-sizing: keep the baseline small enough to run well, but expand it when the risk warrants it.

That also means learning from incidents, vulnerabilities and near misses. If a recurring failure mode shows that a control is missing or poorly automated, the baseline should absorb that lesson and become the new default rather than leaving it to ad hoc human memory.

When the product’s exposure includes cloud, API or platform controls, the baseline can map naturally to security guidance such as NIST Cybersecurity Framework 2.0, especially where teams need a simple way to connect govern, protect, detect and recover activities without overengineering the programme.

Risk and Threat Considerations

Minimum viable security can fail in two common ways: it can be too thin to resist realistic attack paths, or it can become so cumbersome that teams circumvent it. Either failure creates exposure, because gaps in the baseline often show up first as preventable compromise, weak recovery, or uncontrolled drift in how controls are applied.

Failure mechanism: Attackers benefit when the baseline leaves obvious openings such as weak authentication, exposed services, unpatched components or unmonitored admin paths; teams fail when they assume a minimal set is automatically sufficient for every environment.

Impact: The result can be account compromise, service disruption, data loss, or slower recovery after an incident, especially when the organisation has not made the minimum controls both enforceable and observable.

Practitioner Guidance

Why practitioners should care: Minimum viable security is most useful when it defines a defendable starting point, not a permanent excuse for doing less. The baseline should be owned like a product capability, with explicit decisions about what is included, what is deferred, and what evidence shows the controls are working.

Practitioner note: Treat the baseline as an engineering contract, not a policy slogan. If a control cannot be automated, measured or consistently repeated, it is probably not ready to sit inside the “minimum viable” set.

Practitioner takeaway: Keep the baseline small, but make every included control real, testable and hard to bypass.

Related resources from NHI Mgmt Group

• What is the minimum viable AD and Entra ID security stack for a mid-market organisation?
• How do security teams know whether minimum viable recovery is actually working?
• How do security teams know whether their minimum viable digital enterprise is real?
• When should organisations prioritise a minimum viable security plan over a broad security checklist?