The Decision You're Facing
Your board expects measurable progress on cybersecurity. Your CISO presents quarterly metrics. Your auditors want to see remediation timelines. Yet, despite increased spending over three years, the threat landscape hasn't improved.
You're facing a fundamental choice about how to frame cybersecurity in your governance model: as a solvable technical project with defined endpoints, or as an ongoing organizational condition requiring continuous management. This decision shapes your budget cycles, hiring strategy, vendor relationships, and stakeholder promises.
Cybersecurity shares more characteristics with climate adaptation or geopolitical risk than with ERP implementations. Rittel and Webber's 1973 framework for "wicked problems" describes challenges where "there are no 'solutions' in the sense of definitive and objective answers." You can't declare victory. You can't optimize to zero. The Australian government's analysis of wicked problems identifies three mitigation strategies: authoritative (regulatory compliance), competitive (market-driven innovation), and collaborative (cross-functional integration). Your security program likely needs all three.
Key Factors That Affect Your Choice
Stakeholder expectations matter most. If your board expects a three-year roadmap to "fix" cybersecurity, you've got a governance education problem before you have a technical one. Review your last four board presentations. Do they promise closure or describe ongoing risk management?
Regulatory context shapes your options. SOC 2, PCI DSS 4.0, and ISO/IEC 27001:2022 all require continuous monitoring and improvement. If you're pursuing these certifications, you've already committed to the condition model whether you've named it or not.
Your talent strategy reveals your actual belief. Organizations treating security as a project hire for implementation skills. Those treating it as a condition build for institutional knowledge and cross-functional fluency.
Budget cycles tell the truth. Project-framed security gets one-time capital allocations. Condition-framed security gets operational budgets with annual adjustments.
Path A: Frame It as a Technical Project (When Compliance Drives the Timeline)
Choose this path when you're working toward a specific regulatory milestone with a known finish line.
You should frame security as a project if:
- You're preparing for SOC 2 Type I certification with a defined audit date
- You're implementing CMMC 2.0 controls to meet a contractual deadline
- You're remediating specific findings from a penetration test or regulatory examination
- You have a discrete legacy system that needs hardening before decommissioning
What this looks like in practice:
Your security leader reports to the CIO or COO. You allocate capital budget for specific tools and implementations. You measure success by control deployment percentages and audit findings closed. Your vendor contracts include delivery milestones and acceptance criteria.
This works when the scope is truly bounded. PCI DSS compliance for a single payment application? Fine. "Achieving cybersecurity maturity"? You're lying to yourself.
The governance implications:
Your board gets quarterly progress reports against the project plan. Risk committee oversight focuses on timeline and budget variance. You'll need to explain what happens after the project "completes" because the threat environment won't pause.
Path B: Frame It as an Organizational Condition (When Threat Evolution Is Constant)
Choose this path when you're managing enterprise cyber risk across business units, third parties, and evolving attack surfaces.
You should frame security as a condition if:
- Your organization operates in healthcare, financial services, or critical infrastructure where threat actors continuously adapt
- You manage material third-party risk across dozens of vendors
- Your business model depends on customer trust and data protection
- You've experienced the limits of "implement and forget" security controls
What this looks like in practice:
Your security leader has a direct reporting line to the CEO or board risk committee. You fund security from operational budgets with annual reviews tied to threat intelligence and business growth. You measure success through risk quantification (using frameworks like FAIR), incident response effectiveness, and security culture indicators.
You stop asking "when will we be secure?" and start asking "how effectively are we managing our current exposure given our risk appetite?"
The governance implications:
Your board receives risk dashboards, not project status reports. You discuss acceptable loss scenarios and risk transfer strategies. Your risk committee evaluates security program maturity using NIST Cybersecurity Framework 2.0 tiers, not percentage-complete metrics.
You hire fractional or full-time security leadership with policy and business risk expertise, not just technical credentials. Your vCISO or CISO spends as much time on vendor risk governance and incident response planning as on firewall rules.
Path C: Hybrid Model (When You're Transitioning)
Most organizations need both frames simultaneously during maturity transitions.
Use the hybrid approach when:
- You're building foundational controls (project) while managing ongoing threats (condition)
- You're preparing for certification while establishing long-term risk management practices
- You're transitioning from reactive to proactive security governance
Run discrete compliance projects within an operational risk management program. Your CISO manages both the multi-year NIST SP 800-53 Rev. 5 control implementation (project) and the quarterly threat briefings to the audit committee (condition).
The risk: you confuse your board about which frame applies to which activities. Be explicit in your reporting about what has endpoints and what doesn't.
Summary Matrix
| Factor | Project Frame | Condition Frame |
|---|---|---|
| Primary driver | Regulatory deadline or audit requirement | Enterprise risk management and business resilience |
| Reporting line | CIO, COO, or CFO | CEO or board risk committee |
| Budget model | Capital allocation with defined ROI | Operational budget adjusted annually |
| Success metrics | Controls implemented, findings closed | Risk quantification, incident impact reduction |
| Talent strategy | Implementation specialists, contractors | Institutional expertise, cross-functional leaders |
| Board communication | Project status, timeline variance | Risk exposure, scenario planning |
| Vendor relationships | Fixed-scope SOWs with deliverables | Ongoing partnerships with SLA-based performance |
| Time horizon | 12-36 months to "completion" | Indefinite with continuous improvement |
Your choice isn't permanent, but it shapes everything from how you write job descriptions to how you explain a breach to your board. Most organizations default to the project frame because it's more comfortable. It promises control and completion.
But if Marcus Ranum's observation holds true (that the future will be "just as insecure as it possibly can, while still continuing to function"), then your governance model needs to reflect that reality. You're not building a cathedral with a ribbon-cutting ceremony. You're managing a condition that evolves with your business.
Choose the frame that matches your actual risk environment, not the one that makes your board presentation easier to write.
