A boil-the-ocean approach is an implementation style that tries to solve too much at once and overwhelms the programme. In security projects, it usually leads to slow delivery, incomplete controls, and weak operational repeatability because the work is not scoped and sequenced effectively.
What the Boil-The-Ocean Approach Means
A boil-the-ocean approach is less a technical pattern than a delivery anti-pattern. It describes work that is so broad, ambitious, or poorly bounded that teams try to solve everything at once and end up delivering little of durable value.
In security programmes, this usually shows up when a team attempts to redesign too many controls, platforms, or policies in one sweep. The result is not just delay, but loss of clarity about what “done” means and where operational ownership begins.
Why It Fails in Security Programmes
Security work depends on sequencing, dependency management, and repeatable control operation. A large, undifferentiated initiative tends to hide those dependencies, which makes delivery unpredictable and turns control design into a moving target.
The failure is often organisational rather than purely technical. When scope is too wide, teams defer hard decisions, accumulate exceptions, and spend time coordinating rather than closing specific risk reduction outcomes. The work may still produce artefacts, but not necessarily controls that can be operated consistently.
That is why security leaders usually prefer bounded increments, each tied to a concrete asset, risk, or control objective. The phrase maps closely to the need for NIST Cybersecurity Framework 2.0, which emphasizes organised governance, prioritisation, and outcome-driven execution rather than one sweeping security transformation.
Operational Signs You Are Overreaching
A boil-the-ocean effort is often visible before it fully fails. Common signs include unclear milestones, overly generic roadmaps, repeated re-planning, and workstreams that depend on too many unresolved decisions to finish in sequence.
Another warning sign is when the programme cannot explain its own delivery order in practical terms. If every control improvement seems equally urgent, or every team is waiting on every other team, the initiative has usually exceeded its manageable scope.
In security engineering, this problem is especially damaging because control effectiveness depends on implementation detail. Broad initiatives often leave gaps between policy intent and operational reality, which is why structured control catalogues such as NIST SP 800-53 Rev 5 Security and Privacy Controls are often used to break a large objective into specific, testable requirements.
How Mature Teams Avoid It
Mature teams treat scope as a security control in its own right. They narrow the first delivery slice to a specific business service, identity population, threat path, or control gap, then prove repeatability before expanding the programme.
This usually means choosing a sequence that can be validated, operated, and learned from, rather than selecting the most comprehensive design on paper. It also means accepting that some goals belong in later phases, because trying to solve everything at once usually weakens both implementation quality and operational adoption.
Tools and reference models can help when they encourage staged delivery. For example, OWASP SAMM supports incremental improvement in software assurance maturity, while SLSA helps teams sequence supply-chain integrity work rather than trying to rebuild the full build pipeline in one effort.
Risk and Threat Considerations
A boil-the-ocean programme creates security risk because breadth can outpace governance, testing, and operational follow-through. The immediate consequence is usually incomplete control coverage, but the deeper issue is that sprawling change makes it harder to see what has actually been secured and what is still exposed.
Failure mechanism: Excessive scope fragments accountability, delays control implementation, and leaves interim exceptions in place long enough to become de facto operating models.
Impact: Organisations can end up with partial remediation, inconsistent enforcement, and a false sense of progress while the underlying security exposure remains largely unchanged.
If the programme also depends on shared platforms, identity flows, or centralised infrastructure, failure can ripple outward. In those cases, broad delivery plans may compound configuration drift, approval fatigue, and rollback difficulty, which increases the chance that insecure defaults survive the transformation.
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, NIST SP 800-53 Rev 5, OWASP SAMM and SLSA set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.RM-01 — Risk Management Strategy | Boil-the-ocean programmes are scoped through risk prioritisation and governance. |
| Recommendation — Sequence security work by risk priority and avoid initiating broad, unsequenced transformations. | ||
| NIST SP 800-53 Rev 5 | PM-11 — Mission and Business Process Definition | Defines security work around bounded mission outcomes rather than undifferentiated scope. |
| Recommendation — Tie each programme increment to a defined mission outcome and deliver it in bounded phases. | ||
| OWASP SAMM | Software Assurance Maturity Model | Supports staged security maturity instead of all-at-once improvement. |
| Recommendation — Use incremental maturity targets to break large security improvements into manageable releases. | ||
| SLSA | Supply-chain Levels for Software Artifacts | Encourages stepwise build and provenance hardening instead of wholesale pipeline redesign. |
| Recommendation — Advance build integrity controls in stages and validate each level before expanding scope. | ||
Practitioner Guidance
Why practitioners should care: This term is a warning about programme design, not ambition. Security leaders should treat it as a signal that scope, sequencing, and ownership need to be tightened before more work is added.
Practitioner note: The most effective remedy is usually to define the smallest defensible security outcome that can be delivered, measured, and operated cleanly, then expand only after that slice is stable. That approach preserves momentum without turning transformation into theatre.
Related resources from NHI Mgmt Group
- How should organizations approach the governance of AI agents?
- Why do APIs need a different approach than user authentication for post-quantum readiness?
- When does OIDC federation work better than a vault-based approach?
- Why do identity systems need a different recovery approach than normal servers?
