NIST CSF Requirements: A Practical Checklist

NIST CSF 2.0 has six core functions, Govern, Identify, Protect, Detect, Respond, and Recover, and meeting it means documenting policies and evidence across all six, not just buying a scanning tool. Below is a practical, skimmable checklist you can use to gauge where your organization stands and what a real assessment will look for.

What Changed in NIST CSF 2.0

The 2024 update added a sixth function, Govern, on top of the original five (Identify, Protect, Detect, Respond, Recover). Govern formalizes what most assessors were already asking about informally: does leadership actually own cyber risk, is there a documented risk strategy, and does the board or executive team get regular reporting. If your last NIST CSF exercise predates 2024, treat this checklist as a re-baseline, not a refresh.

Govern: Leadership and Risk Strategy Checklist

• Documented cybersecurity risk strategy approved by leadership, not just an IT policy binder nobody reads.
• Named accountability, someone (often a fractional CISO for smaller firms) owns the program and reports on it.
• Supply chain risk policy covering how you vet vendors and subprocessors, especially SaaS tools touching customer data.
• Roles and responsibilities for security decisions are written down, not tribal knowledge.
• Legal and regulatory obligations mapped, including PIPEDA federally and Quebec's Law 25 if you handle Quebec residents' data.

Identify: Asset and Risk Inventory Checklist

• Asset inventory covering hardware, software, and data flows, including shadow IT and forgotten cloud accounts.
• Data classification that distinguishes public, internal, and sensitive/regulated data.
• Risk assessment performed at least annually, with findings tied to actual remediation tickets.
• Vendor and third-party inventory, especially for SaaS companies passing data through multiple subprocessors.

Protect: Access Control and Hardening Checklist

• Multi-factor authentication enforced on all privileged and remote access, not just the admin console.
• Least-privilege access control with periodic access reviews, not permissions granted once and forgotten.
• Data protection controls, encryption at rest and in transit, backup policies, and secure disposal.
• Security awareness training delivered on a schedule, with records kept as evidence.
• Configuration and patch management for endpoints, servers, and cloud infrastructure.

Detect: Monitoring and Anomaly Detection Checklist

• Continuous monitoring of networks and systems for anomalous activity, appropriately scoped to your environment's size.
• Logging and log retention sufficient to reconstruct an incident after the fact.
• Detection processes tested periodically, not assumed to work because a tool is installed.

Respond and Recover: Incident and Continuity Checklist

• Written incident response plan with defined roles, escalation paths, and communication templates.
• Tabletop exercises run at least annually so the plan gets tested before a real incident forces the issue.
• Breach notification procedures that account for PIPEDA timelines and any provincial requirements.
• Business continuity and disaster recovery plan, with backups actually tested for restoration, not just scheduled.
• Post-incident review process to feed lessons learned back into the Protect and Detect functions.

Common Gaps We See in Canadian SMBs and Scale-ups

Working with growth-stage companies across Toronto, Waterloo, Ottawa, Vancouver, Calgary, and Montreal, the same gaps show up repeatedly: the Govern function is thin because nobody owns risk full-time, the asset inventory is out of date within months of being built, and incident response plans exist on paper but have never been rehearsed. None of these are hard to fix, but they take an outside eye to catch before a customer's security questionnaire or an auditor catches them for you.

How This Differs From SOC 2 or ISO 27001

NIST CSF is a risk management framework, not a certification you can hand a customer as proof. Many Canadian tech companies use it as the internal roadmap that later feeds a SOC 2 report or ISO 27001 certification when a US enterprise customer demands one. If you are unsure which path fits your sales motion, our compliance solutions overview breaks down how these frameworks relate and where NIST CSF fits as a starting point.

Turning This Checklist Into a Real Posture

A checklist tells you what to look for, it does not tell you how far off you are or what to fix first. That is the gap a structured NIST CSF assessment closes: scoring your current maturity against all six functions, then building a prioritized roadmap instead of a to-do list that never gets tackled in order.

If you want a straight answer on where your organization stands against NIST CSF 2.0, or how it lines up with a SOC 2 or ISO 27001 push you're already planning, get in touch with traztech and we'll walk through it.

Profiles and Tiers, the two things people conflate

CSF 2.0 gives you two separate instruments and most first assessments muddle them. A Profile is a statement of which outcomes apply to you and how well you achieve them. You build a Current Profile describing where you are, a Target Profile describing where you intend to be, and the gap between them is your roadmap. Tiers are a different axis entirely: they describe how rigorous and integrated your risk management practice is, from Tier 1 Partial through Tier 4 Adaptive, and they apply to the program as a whole rather than to individual outcomes.

The practical consequence is that a Tier is not a grade and you should stop treating it as one. Tier 4 is not the goal for a forty person software company, and an assessor who tells you otherwise is selling hours. Most growth-stage companies should be targeting Tier 2 across the board with Tier 3 in the areas where their risk actually concentrates, usually identity, third-party risk, and incident response. Write the target down with a rationale, because the rationale is what a board or an insurer wants to see. Declaring a target of Tier 2 for physical security because you have no offices is a defensible risk decision. Reaching Tier 2 by accident and calling it a strategy is not.

How to score honestly, and why averages lie

Companies love a single number. The temptation is to score every subcategory from one to five, take the mean, and report "we are at 3.2, up from 2.7." That number is close to meaningless, because it hides the distribution. A 3.2 average made of consistent threes is a healthy program. A 3.2 average made of fives in Protect and ones in Detect and Respond is a company that will handle a breach badly, and the mean actively conceals that. If you must report a number, report the count of subcategories below your target alongside it, and name the lowest three.

Score each subcategory on two dimensions instead of one: is the practice defined, and is it evidenced. Defined means somebody wrote down how it works and who owns it. Evidenced means you can produce an artifact from the last quarter proving it happened. Practices that are defined but not evidenced are the ones that fail first under a real assessment or an insurance claim, and in our experience they are the largest category in a first CSF exercise. A shorter scale helps: not performed, performed informally, defined and repeatable, measured. Four options force a decision. Ten-point scales invite negotiation, and the negotiation always drifts upward.

Govern is where the new work is, and GV.SC is most of it

The Govern function reads as leadership boilerplate until you get to the supply chain category, which is the most demanding part of CSF 2.0 for a small company. It asks you to establish supply chain risk criteria, integrate them into your enterprise risk process, run diligence proportionate to criticality before you engage a supplier, write security requirements into contracts, plan for supplier incidents including your own response when they are breached, and manage suppliers through to termination including retrieval or destruction of your data.

Very few growth-stage companies do the last three at all. The termination piece is almost always missing: nobody tracks which vendors still hold data after the contract ended, and nobody asks for deletion confirmation. Start with a tiering rule so the work stays proportionate. Tier one is any vendor that processes customer data, holds production credentials, or would take your product offline if it disappeared, and those get real diligence and contract language. Tier two touches internal data only and gets a light review. Tier three is everything else and gets a register entry. Then handle the case CSF explicitly asks about and almost nobody rehearses: what you do in the first forty eight hours when a tier one vendor reports a breach, who decides whether to notify your customers, and where the contact details live.

Detect is the function that fails the checklist test

Almost every organization scores itself higher on Detect than it deserves, because a tool is installed and a dashboard exists. CSF asks for something narrower: that potentially adverse events are analyzed to understand associated activity, that information from multiple sources is correlated, and that the impact and scope of an event is understood. Correlation is the word that catches people. Endpoint alerts in one console, cloud alerts in another, and identity alerts in a third means nobody can tell that the same account triggered all three within ten minutes.

The honest test for this function is not what you have deployed. It is whether you can answer, for a real alert from the last ninety days, who saw it, when, what they concluded, and how long it took. If the answer is that alerts go to an email inbox nobody has opened since the trial period, you are at Tier 1 for Detect regardless of the license you are paying for. Fixing it rarely requires a new tool. It requires a defined recipient, a triage expectation in hours, a place where the decision is recorded, and a monthly review of what came in and what was done. Three or four well-tuned rules with a human accountable for them beats three hundred untriaged ones, and the review record is what an assessor, an insurer, or a customer's security team asks to see.

A worked example of one subcategory, start to evidence

Take the identity outcome about authentication proportionate to risk. A weak assessment records "MFA enabled" and moves on. A useful one produces four things. First, a statement of what the practice is: all human access to production and to systems holding customer data requires phishing-resistant multi-factor authentication, service accounts use short-lived credentials issued by the workload identity provider, and no shared accounts exist. Second, the enforcement artifact: the conditional access policy export showing the rule, its scope, and any exclusions.

Third, the exception record. There is always an exception, usually a legacy system or a vendor tool that does not support your identity provider, and hiding it makes the whole assessment untrustworthy. Record it, record the compensating control, record who approved it and when it expires. Fourth, the operating evidence: an account listing from last month showing registration status per user, which proves absence of coverage gaps rather than presence of a policy. Those four artifacts take an hour to produce and they turn one line on a checklist into something that survives a customer's security review, an insurance application, and later a SOC 2 or an ISO 27001 audit without being rebuilt. Do that for the twenty subcategories that matter most to your risk and you have a real program.

Mapping CSF to the frameworks your buyers actually ask for

CSF is useful as the internal spine precisely because it maps outward. NIST publishes informative references linking subcategories to SP 800-53 and other control sets, and the major control catalogs cross-reference back. In practice the mapping you want is one you maintain yourself: a single sheet where each row is a control you operate, with columns marking which CSF subcategory it satisfies, which SOC 2 trust services criterion it maps to, and which ISO 27001 Annex A control it covers among the 93, plus the relevant clause 4 to 10 obligation where it is a management system requirement.

Built once, that sheet turns each new framework request into a mapping exercise rather than a new project. It also answers the question every buyer's security team eventually asks, which is not "do you follow NIST CSF" but "show me the control that prevents this specific thing." Two cautions. Mappings are approximate, so treat a mapped row as a starting point rather than proof, because ISO 27001 asks for a management system that CSF does not, and SOC 2 asks for operating effectiveness over a period that a CSF profile does not measure. And keep the sheet in one place with one owner, since the failure mode is four stale copies in four different folders. If you want a view of which framework your market is likely to demand first, the compliance overview lays out how they relate.

What a CSF assessment costs, and what drives the number

The cost drivers are not the framework. They are the size of your environment, the number of people who have to be interviewed, and how much of your evidence already exists. A twenty person company with one cloud environment, a single identity provider, and managed laptops is a two to three week exercise. The same headcount with three acquired product lines, two legacy data centers, and a contractor population is a two month exercise, because half the work is discovering what exists before you can assess it.

The second driver is what you want at the end. A read-only assessment producing a current profile and a gap list is the cheapest output and is often enough for an internal roadmap or a board conversation. Adding a target profile with a phased remediation plan and owners costs more and is worth it if anyone will actually execute against it. Adding remediation delivery is a different engagement entirely and should be priced separately, since bundling it creates an incentive to find more gaps. Ask any firm quoting you to separate the assessment fee from the remediation fee for exactly that reason. Our fixed-scope work is published on the pricing page so the assessment and the delivery are visibly distinct lines.

When NIST CSF is the wrong tool

Be clear about what CSF cannot do for you. There is no certificate, no auditor's opinion, and no artifact a buyer can put in a vendor file. If a customer contract is blocked on evidence, a CSF self-assessment will not unblock it and doing one first delays the thing that will. In that situation go straight to whatever the contract names, usually SOC 2 or ISO 27001, and let the CSF work fall out of it later if you still want the risk view.

Skip it, or defer it, in three other cases. If you already have a mature ISO 27001 management system with a live risk register and an internal audit program, a CSF assessment mostly re-describes what you have in different words, and the money is better spent on testing whether the controls actually resist attack. If you are under ten people with one product and no regulated data, the framework is heavier than your risk, and an afternoon spent turning on MFA everywhere, enabling backups with a tested restore, and writing a one page incident plan buys more security than a scored assessment. And if the assessment is being commissioned because someone wants a document rather than a decision, say no. The cheapest bad outcome in this field is a beautifully formatted profile that nobody funds and nobody revisits.

Where it genuinely earns its place is as the risk language a company uses with its board and its insurer, as a way to compare posture year over year, and as the spine that keeps three separate framework requests from becoming three separate programs. That is a real job. Just do not confuse it with the job of proving to a customer that your controls work, which needs an independent opinion, or the job of finding out whether your controls hold up against an attacker, which needs someone to try. If you want the risk view maintained continuously by someone accountable for it rather than rebuilt from scratch each year, that is the shape of a fractional CISO arrangement, from $3,000 a month, and it is usually the cheaper answer for a company that is not yet ready to hire a security leader outright.

Running the assessment in-house in two weeks

You can do this yourself and many companies should. Week one is collection. Build the subcategory list in a spreadsheet, one row each, and assign each row to whoever administers the relevant system. Ask them for the defined and evidenced answers rather than a score, since people rate themselves generously and describe themselves accurately. Pull the artifacts as you go, into one folder, named by subcategory. Interview two or three people outside IT, because the gap between what the platform team believes and what sales or support actually does is where the real findings live.

Week two is judgment and reporting. Score the rows, set the target, and rank the gaps by risk rather than by effort, then produce a short remediation plan with named owners and dates. Keep the report to two pages plus the spreadsheet: an executive summary naming the three things that would hurt most, the tier position with its rationale, and the plan. Then put a reminder in the calendar for six months' time to re-check only the rows you marked as gaps, which is a half day rather than a rebuild. The companies that get value from CSF are the ones that treat it as a living register they touch quarterly. The ones that get nothing produced a PDF once and filed it, and you will be able to tell which you are within about eight months.