Security Programme Building Guide: A Sequenced Plan from Zero Using CSF 2.0

Organisations that start a security programme by buying tools, before they know what they are protecting, who decides on risk and what "good enough" means, usually end up with expensive products and the same exposures. This guide sets out a sequenced plan for building a security programme from nothing, using NIST Cybersecurity Framework (CSF) 2.0 as the backbone: Govern first, then Identify and Protect, then Detect, Respond and Recover. Older manager-level guidance such as NIST SP 800-100 (2006, updated 2007) predates cloud, SaaS and modern identity attacks, so this page uses current sources. It is for first security hires, IT leaders given security as a new remit, founders and CIOs. The leadership side of a new role is covered in the CISO Guide: First 90 Days; this page is the programme plan itself.

Key takeaways

• Govern before you buy. CSF 2.0 added the Govern function so that context, risk appetite, roles and policy come first. A one-page charter and a named executive owner are worth more in month one than any tool.
• Pick one baseline and use it. CSF 2.0 for structure, CIS Controls v8.1 Implementation Group 1 (56 safeguards) or Cyber Essentials for the first technical controls, and ISO/IEC 27001 only when customers or contracts require certification.
• Identity is the first control set. MFA on remote access and email, control of administrator accounts and an inventory of service accounts and keys stop the most common intrusion routes.
• Sequence by risk, not by framework order. Use a Current and Target Profile to find the gaps, then fix the few that matter most to your threats, data and obligations.
• Measure from day one. Track a small set of outcome metrics, such as MFA coverage and patch latency, so progress is visible to the board and the plan can be adjusted.

Start with Govern: the first 30 days

CSF 2.0 (NIST CSWP 29, February 2024) describes Govern as establishing, communicating and monitoring the organisation's cybersecurity risk management strategy, expectations and policy. In practice, the first month produces six things.

Templates: the Security Programme Charter Template, the Cyber Risk Appetite Statement Template and the Information Security Policy Template. For the Govern function in depth, see the NIST CSF 2.0 Govern Function Guide.

Choosing a baseline

A framework gives structure and a common language; a baseline gives the first concrete controls. Most organisations need one of each, mapped together.

Small versus large: a company of 50 people with one IT person can use the CSF 2.0 Small Business Quick-Start Guide with CIS IG1 or Cyber Essentials and reach a sound baseline within a year. A large or regulated organisation should build a CSF 2.0 Organisational Profile, map it to the control set its regulators expect and plan for a multi-year Target Profile. See the NIST CSF 2.0 Guide and the CIS Controls Guide.

Profile the gap and build the roadmap

CSF 2.0 sets out five steps for an Organisational Profile: scope it; gather inputs such as policies, risk priorities, the risk register and applicable standards; create the Current and Target Profiles; analyse the gaps and create a prioritised action plan; then implement and update. Keep the first profile to the Categories that matter; scoring every Subcategory in month two produces a spreadsheet, not a plan. See the CSF 2.0 Organisational Profiles Template.

The phases overlap; in a small organisation one person may run several at once. The Security Programme Maturity Assessment Template can be used to set the baseline before phase 1 and re-measure at month 12.

The first controls that buy the most risk reduction

1. MFA on everything internet-facing: remote access, email, SaaS admin consoles and cloud consoles, phishing-resistant for administrators. CISA's performance goals call for the strongest available MFA, with SMS or voice codes as a last resort.
2. Administrator accounts: separate admin accounts, remove standing global admin rights where possible, and an emergency access process. See the Privileged Access Management Guide.
3. Asset and software inventory: CISA's goal 1.A asks for an inventory refreshed no less than monthly. You cannot patch or monitor what you do not know about. See the Asset Inventory and CMDB Security Guide.
4. Patching with deadlines: internet-facing systems and known exploited vulnerabilities first, with a target time per severity.
5. Backups that are tested and isolated: at least one copy that ransomware operators cannot reach with the same credentials, and a timed restore test.
6. Email protection: DMARC on your domains, attachment and link filtering, and a report button.
7. Endpoint protection: EDR on laptops and servers, with someone, internal or a provider, watching the alerts.
8. Logging: identity provider sign-ins, admin actions, email and endpoint alerts kept centrally for at least [12 months].
9. Incident response: a short plan, a contact list, an external retainer and a first tabletop. See the Incident Response Plan Template.
10. Supplier basics: a list of critical suppliers and security terms in new contracts. See the Third-Party Security Contract Clauses Template.

Rolling out controls without breaking the business

A new programme loses support quickly if its first changes lock people out or stop a production system. Use the same pattern for every control in phase 2.

1. Report-only first: run conditional access policies in report-only mode, application control in audit mode and email rules in monitor mode for two to four weeks, and review what would have been blocked.
2. Pilot ring: apply the control to IT and security staff, then to a willing business unit, before everyone.
3. Exceptions with expiry: record every exclusion, such as a legacy system that cannot take MFA, with an owner, a compensating control and an end date, and report the number of open exceptions monthly.
4. Communicate before enforcing: tell staff what changes, when, and where to get help; brief the service desk first.
5. Rollback plan: know how to disable the policy or revert the change in minutes, and keep emergency access accounts excluded from conditional access and tested.
6. Confirm the outcome: after enforcement, check the metric moved (for example MFA coverage) and that no unrecorded exclusions remain.

What to do first when everything looks urgent: fix what an attacker can reach from the internet with a stolen password (remote access, email, SaaS and cloud consoles), then what would stop you recovering (backups and admin accounts), then what would tell you it is happening (identity and endpoint logs). Most other work can wait for the profile.

Where identity fits

Identity controls appear in every phase. In phase 1, the inventory must include non-human identities: service accounts, API keys, OAuth integrations, cloud access keys and certificates, each with an owner. In phase 2, MFA and admin controls cover people, while service accounts are moved out of interactive use, given least privilege and their secrets moved into a secrets manager. CSF 2.0 PR.AA-01 covers identities and credentials "for authorized users, services, and hardware", so non-human identities are explicitly in scope. A new programme that treats identity only as user MFA will miss the keys in code and the integrations that hold standing access. See the Identity Security Programme Guide and the Non-Human Identity (NHI) Guide.

Team, budget and operating model

• First hire: a generalist who can do governance and hands-on engineering. Specialists come later.
• Managed services: most organisations under a few hundred staff should buy 24x7 monitoring (MDR) and incident response retainers rather than build a SOC.
• Shared responsibility with IT: IT runs patching, backups and identity administration; security sets the standards and checks them. Write this down in a responsibility matrix.
• Budget: tie each request to a gap in the Target Profile and the risk it reduces. A quantified scenario helps for large items. See the FAIR Model and Open FAIR Standard Guide.
• Awareness: start with role-based basics for staff who approve payments, administer systems or handle sensitive data. See the Security Awareness and Human Risk Management Guide.
• Forums: a monthly security steering group with IT, finance, legal and operations, and a quarterly board update. See the Board Cyber Risk Reporting Guide.

Measuring the programme

Choose five or six metrics in month one and report them every month. Each should have a target and an owner.

• MFA coverage: percentage of users and of internet-facing applications protected by MFA, and percentage of admins using phishing-resistant methods.
• Patch latency: median days to patch critical and known exploited vulnerabilities on internet-facing systems.
• Inventory coverage: percentage of assets, SaaS applications and service accounts with a named owner.
• Restore success: result and duration of the last tested restore of a critical system.
• Detection coverage: percentage of critical log sources feeding central monitoring.
• Profile progress: number of Target Profile gaps closed against plan.

See the Security Metrics and KPIs Programme Guide.

Framework mapping

For ISO/IEC 27001 alignment, see the NIST CSF to ISO 27001 Mapping Guide.

Common failure patterns

• Tools first: buying a SIEM or a platform before there is an inventory, an owner or anyone to watch alerts.
• Framework as a spreadsheet exercise: scoring every CSF Subcategory and never producing a prioritised action plan.
• No executive owner: security reports to IT operations with no authority to set standards or accept risk.
• MFA with exceptions: coverage is reported as complete, but legacy remote access portals or service accounts are exempt. The Change Healthcare breach began with a compromised credential on a Citrix remote access portal that did not have MFA; 192.7 million people were affected.
• Backups never restored: backups exist but have not been tested, or share credentials with production.
• Ignoring non-human identities: the inventory lists laptops and users but not the API keys and service accounts with the most access.

Lessons from incidents

Change Healthcare's chief executive told US lawmakers in May 2024 that "the portal did not have multifactor authentication". A mature organisation with a large security budget was entered through the kind of gap that a phase 2 control and an honest coverage metric are designed to find. The lesson for a new programme is to measure coverage against the real inventory of internet-facing access points, not the list of systems the identity team already manages, and to treat every exception as a risk acceptance signed by the executive owner. The same discipline applies to non-human access: a service account or API key that bypasses MFA by design needs an owner, least privilege, short-lived or rotated credentials and monitoring, or it becomes the next unprotected door.

Practitioner checklist

• Name the executive owner and agree the security lead's authority in writing.
• Produce the context summary, obligations register and risk appetite statement in the first month.
• Choose CSF 2.0 for structure and one control baseline (CIS IG1, Cyber Essentials or CISA performance goals).
• Build a focused Current and Target Profile and a prioritised 12-month action plan.
• Inventory assets, SaaS, data and identities, including service accounts and API keys, with owners.
• Enforce MFA on all internet-facing access, phishing-resistant for administrators, with no unrecorded exceptions.
• Test a restore of a critical system and run a first incident tabletop within nine months.
• Report five or six metrics monthly and update the Target Profile at month 12.

Standards and references

• NIST: The NIST Cybersecurity Framework (CSF) 2.0 (CSWP 29)
• NIST: CSF 2.0 Quick-Start Guides
• NIST: SP 800-53 Rev. 5
• CIS: CIS Controls Implementation Group 1
• CISA: Cross-Sector Cybersecurity Performance Goals
• NCSC: Cyber Essentials
• NIST: SP 800-100 Information Security Handbook: A Guide for Managers

Related NHI Mgmt Group resources: CISO Guide: First 90 Days · NIST CSF 2.0 Guide · Security Programme Charter Template · Identity Security Programme Guide