Updated 19 October 2026.
The NIST Cybersecurity Framework (CSF) 2.0 can help an organisation explain why a cybersecurity project deserves funding. It provides a common language for desired security outcomes. A project manager can use that language to connect a proposed change to a business risk, an accountable owner and evidence of improvement.
CSF 2.0 was released on 26 February 2024. Its Core contains six functions: Govern, Identify, Protect, Detect, Respond and Recover. These functions work together; they are not a six-step project lifecycle. See NIST’s release announcement.
What each function contributes to project selection
| Function | Question for a proposed project |
|---|---|
| Govern | Who owns the risk, which policies apply and who accepts the remaining exposure? |
| Identify | Which business services, assets, suppliers and risks need attention? |
| Protect | What safeguards will reduce exposure or support service resilience? |
| Detect | How will the organisation discover and analyse possible incidents? |
| Respond | What will people do when an incident is detected? |
| Recover | How will affected services and operations be restored? |
For example, buying a monitoring tool may support Detect, but its success also depends on who receives alerts, how incidents are handled and how the service recovers. A purchase without those responsibilities can leave the original business risk unresolved.
Start with the business service and the risk
Identify the service the organisation needs to protect and the consequences of disruption or misuse. Describe the risk in business language before choosing a solution. “We need a new security platform” is a purchase request; “we cannot reliably identify or remove former suppliers’ access to the payment service” is a problem that can guide options.
Record what is known, where evidence is missing and who can validate the assessment. A project manager should involve the service owner and security specialists rather than assign technical risk ratings alone.
Use Current and Target Profiles
CSF Organisational Profiles describe current and target cybersecurity outcomes. Use the gap between them to identify possible changes, then agree a scope that the organisation can fund and operate. NIST’s Profiles guidance explains this approach.
A useful working record can contain the relevant outcome, the evidence for today’s position, the target outcome, the gap, a proposed response and an accountable owner. Keep unknowns explicit. A blank assessment is not proof that a safeguard exists, and completing a document is not proof that it works.
Do not turn a Profile into an automatic maturity percentage. The CSF’s Implementation Tiers describe the rigour of cybersecurity risk governance and management practices; a Tier label alone does not establish that a business service is secure.
Compare projects using explicit criteria
The framework helps organise the conversation, but it does not calculate which project is best. Agree decision criteria with the sponsor and security owner. The following checklist is a practical project-selection aid:
- Risk addressed: the business consequence and the evidence that the proposed change can reduce it.
- Obligation or deadline: the specific requirement, its applicability and who confirmed it.
- Dependencies: prerequisite data, access, operating processes or supplier changes.
- Whole cost: implementation, licences, support, training and ongoing ownership.
- Deliverability: available skills, change windows, capacity and implementation risk.
- Acceptance evidence: how the organisation will know that the outcome works.
If scores are used, document their meaning and assumptions. A total score should support discussion, not conceal an unresolved mandatory requirement or an unmanageable residual risk.
Worked example: improving access removal
Illustrative scenario: a business relies on contractors to support a critical application. Access records are incomplete, and the service owner cannot show that accounts are disabled promptly when contracts end. The project options include a manual control improvement, a connector to the existing identity service or a wider identity-platform change.
The project team first checks which option can achieve the agreed access-removal outcome with acceptable effort. It maps the work to relevant CSF outcomes, establishes ownership and tests the process from a contractor’s leaving notification through to evidence of removed access. This scenario is illustrative; no measured customer result is claimed.
Define success before implementation
| Area | Example of acceptance evidence |
|---|---|
| Govern | Named control owner, approved responsibilities and an agreed route for exceptions. |
| Identify | Reconciled list of relevant accounts, applications and access dependencies. |
| Protect | Sampled leaver cases demonstrate access removed within the agreed target. |
| Detect | Overdue or failed access removals are visible to an accountable team. |
| Respond | An exception exercise demonstrates escalation and containment steps. |
| Recover | An approved procedure restores legitimate access after an incorrect removal. |
For each measure, record the baseline, denominator, data source, reporting period and limitations. Pair completion measures with effectiveness evidence: staff attending training is different from demonstrating that the intended control operates.
Explain value without inventing ROI
Separate observed costs and benefits from forecasts. Reduced effort can be measured with recorded time; avoided incident losses require assumptions about likelihood and impact. Show ranges and uncertainty rather than presenting a hypothetical avoided loss as money already saved.
A project can be necessary even when a credible financial return cannot be calculated. Explain the risk reduction, service resilience or obligation that supports the decision and name the person accepting the remaining exposure.
Fit the work into existing governance
Use the organisation’s existing risk register, change process and reporting cycle where they serve the purpose. Link the project record to the relevant security outcome rather than maintain duplicate facts. When other standards apply, validate the mapping with the organisation’s specialists; a CSF mapping alone does not establish certification or regulatory compliance.
A project selection checklist
- Name the business service and risk owner.
- Describe the current evidence and desired outcome.
- Compare proportionate options and whole-life costs.
- Agree dependencies, funding and operating ownership.
- Define acceptance tests and residual-risk approval.
- Review the outcome after handover and update the assessment.
The useful result is a defensible decision: what will change, why it matters, who owns it and how success will be demonstrated. That is how CSF 2.0 can support project selection and credible sponsor reporting.
Put It Into Practice
Pick one thing from this article to try on your next project. If you need a starting point, Resources has free status report, action log and decision log templates. For a difficult conversation, try the People Field Guide.
Get new practical guides by email →
About Paulius
I’m Paulius Petravicius, a project manager with a background in business and data analysis. I share practical ways to make everyday project work a little easier. Read my story →