How do you score NIST CSF maturity when the framework has no scoring model?
NIST defines four Tiers, Partial, Risk Informed, Repeatable and Adaptive, that describe the rigor of an organization's cybersecurity risk governance and risk management practices. NIST does not prescribe a scoring model for them and leaves measurement to the organization, so a board, customer or contract that asks for a *maturity score* is asking you to define one. The organization owns that method and its ratings. Leadership usually selects the Tiers it should meet, and those choices then shape the Current and Target Profiles. An independent assessor may review your work and issue a report, but the scoring itself is your organization's statement, not a certificate. Confirm this distinction with the requester before you start, because a customer who expects a certified number will need a different answer.
The right answer differs by organization, and the reasons are usually visible in four places: the scope of the assessment (one business unit or the whole enterprise), the risk the organization faces and the mandates it must meet, the Tiers leadership has chosen as targets, and how mature the evidence behind each outcome really is. An organization with strong controls but no written risk strategy may score well on technical outcomes and poorly on Govern. Reporting one blended number can hide that gap. Ask the requester what decision the score will support, such as funding, contract qualification or board oversight, and let that decision set the level of detail.
In practice, define the scale before you rate anything. NIST's Organizational Profile template records, for each outcome, the current practices, a status, a rating on a scale such as 1 to 5 or 0 to 100 percent, a priority and a target goal. Choose one scale, write down what each rating point means, and state whether the rating reflects documented practice, observed practice or tested practice. Apply the same definitions to every function so results can be compared over time. The Tiers Quick-Start Guide, NIST SP 1302, offers notional Tier descriptions you can reuse or adapt. Expect a one-time cost to design the scale and calibrate it across reviewers, then a recurring cost each cycle to re-rate outcomes and retain evidence.
Partial, Risk Informed, Repeatable and Adaptive: what each Tier looks like in practice
At Partial, cybersecurity risk is handled reactively and informally. Decisions are made case by case, often by individuals, and there is little written link between security work and the organization's objectives. Risk management happens when something breaks or when a customer asks a question, not as a planned activity. The notional Appendix B language in CSWP 29 describes this Tier in general terms, and an organization can reuse or adjust that wording for its own profile.
- Governance: Leaders rarely set cybersecurity risk objectives, and no one owns the program end to end.
- Management: Controls exist, but they are applied inconsistently and depend on the people who happen to be working on a system.
- Evidence an assessor would expect: Ad hoc tickets, emails or chat threads showing decisions, and no approved policy or risk register that the business relies on.
- Typical gap to Tier 2: Leadership must agree on a risk approach, and the organization must start using that approach when it makes everyday security decisions.
- Typical gap to Tier 2 in people terms: A named owner, a short list of documented risk assumptions and a regular review point.
Before assuming an organization sits at Partial, confirm with the executive sponsor whether any risk approach exists in writing, even if no one follows it consistently.
At Risk Informed, leadership has approved a risk management approach and security decisions reflect it. The approach may be documented, but it is not yet applied in the same way across all systems, teams and projects. Priorities are set using risk information, yet the process for doing so is not consistently repeated or measured. The notional Appendix B language treats this Tier as an informed starting point, where the organization understands its risk but has not yet made its practices uniform.
- Governance: Leadership has approved a risk management approach, and cybersecurity risk is discussed at some level of management.
- Management: Asset and risk information exists and is used to prioritize work, though coverage may be partial.
- Evidence an assessor would expect: An approved risk management policy or method, a risk register with entries and owners, and examples of prioritization decisions tied to that register.
- Typical gap to Tier 3: Practices must become repeatable across units, with defined procedures, recurring reviews and consistent records.
- Typical gap to Tier 3 in evidence terms: Records that show the same process was followed for several cycles, not only once.
Ask for the most recent risk register and check whether the entries lead to a decision that someone can trace.
At Repeatable, the organization's risk management practices are formally approved, documented and applied consistently across the enterprise. Governance is part of normal management, with clear roles, regular reporting and processes that produce comparable results from one cycle to the next. The notional Appendix B language describes this Tier as one where the organization can explain how risk decisions were made and repeat that process when conditions change.
- Governance: Cybersecurity risk is integrated with broader risk management, and leadership receives regular reporting that supports decisions.
- Management: Procedures for identifying, assessing, responding to and monitoring risk are documented and followed across relevant teams.
- Evidence an assessor would expect: Current policies and procedures, records from several review cycles, metrics or reports delivered to leadership, and evidence that exceptions are approved and tracked.
- Typical gap to Tier 4: The organization must learn from its own events and change its practices, not only follow them, and use threat and performance information to adjust quickly.
- Typical gap to Tier 4 in evidence terms: Documented lessons learned from incidents and exercises that led to changed procedures.
Check whether the procedures are followed in practice by sampling a few recent changes or incidents, not only by reading the policy.
At Adaptive, the organization uses current threat, business and performance information to adjust its cybersecurity risk management continuously. Practices are not only repeatable but also improved in response to events, tests and changing conditions. Leaders treat cybersecurity as part of how the business adapts to change. The notional Appendix B language describes this Tier as one where the organization anticipates and learns, rather than only responding to what happened.
- Governance: Leadership reviews strategy outcomes and risk performance and directs changes based on what the data shows.
- Management: Lessons from incidents, tests and operations feed into updated procedures, and risk responses are adjusted as conditions change.
- Evidence an assessor would expect: Records of improvements made after tests or incidents, trend data over time, and evidence that changes were approved, implemented and verified.
- Practical limit: Adaptive is not automatically the right target for every organization. Higher Tiers should be chosen where risk, mandates or a cost-benefit analysis justify the added effort.
- Typical gap to Tier 4: Usually a consistent feedback loop between testing, incidents and governance, backed by records that prove the loop operates.
Confirm with leadership whether Adaptive is required by a contract or regulator, or whether it is a deliberate choice based on risk.
Which rating scales NIST's Profile template uses
NIST's Organizational Profile template in SP 1301 records a fixed set of elements for each outcome. The template suggests rating scales, but the organization chooses one and must apply it the same way across every Function, or the scores cannot be compared.
Current practices and artifacts
For each outcome, the template records the practices the organization performs today. It also allows artifacts that show the outcome is met, such as a signed policy, a configuration export, a ticket history or a test report. Record the practice in plain terms and attach the artifact that proves it, so a reviewer can check the rating without interviewing the author. An artifact that is months old or covers only part of the scope should be noted as such, because a rating built on stale evidence overstates maturity.
Status of each outcome
Status records where an outcome stands in its own lifecycle, such as whether it is in place, partly implemented or not yet started. It is a separate field from the rating, so an outcome can be fully designed on paper but not yet operating. Keep status labels fixed for the whole assessment. Mixing labels like "done" and "in progress" across teams makes the results hard to aggregate and hides the difference between documented and operating controls.
Rating scale choice
The template shows scales such as 1 to 5 or 0 to 100 percent, but NIST does not require either. Pick one scale, define what each score means in writing, and apply it to all six Functions. A 1 to 5 scale is easier for leaders to read and for assessors to defend, while a percentage scale allows finer distinctions. Whichever you choose, record the definitions in the Profile so a later reader does not assume a different meaning for the same number.
Consistency across Functions
A rating only means something if a 3 in Govern represents the same level of maturity as a 3 in Respond. Check that the scoring criteria, evidence standard and reviewer are the same across the Functions and their Categories. Common drift appears when one team scores generously against its own policies while another scores strictly against testing results. Calibrate the scores in a joint review before the Profile goes to leadership, and note any Function where the evidence standard had to differ.
Priority for each outcome
Priority ranks which outcomes the organization will address first, usually by the risk they reduce and the effort they need. The template treats it as a separate field from the current rating, so a low-rated outcome may still be low priority if the underlying risk is accepted. Document the reasoning for high and low priorities alongside the scores. Leaders reviewing the Profile will ask why an outcome with a weak rating was not scheduled, and the answer should trace back to the risk register.
Target goals
Target goals record the rating the organization intends to reach for each outcome. They connect the Target Profile to the Tier chosen by leadership, so a goal should be set only where the business has decided it needs that level of maturity. Set goals on the same scale as the current ratings, or the gap between current and target cannot be calculated. Confirm with the SP 1301 template itself which fields it expects on the target side before you build your own worksheet.
Who chooses the target Tier, and why leadership must own it
Leadership generally selects the Tiers an organization should meet, and the security lead should not make that choice alone. NIST's Tiers Quick-Start Guide, SP 1302, says exactly that, and it adds that the chosen Tiers then inform the Current and Target Profiles. The Tier is a statement about how much rigor the organization wants in its cybersecurity risk governance and risk management, so it belongs with the people who accept residual risk on the organization's behalf. In practice, the board or executive team sets risk appetite and tolerance, the CISO or security lead proposes a Target Tier that reflects those limits, and the executives who own the budget and the business decide whether they will fund it. Record that decision in the Governance notes of the Organizational Profile, with the name of the approver and the date.
The security lead's proposal should show its reasoning. CSWP 29 encourages moving to higher Tiers when risks or mandates are greater, or when a cost-benefit analysis shows a feasible, cost-effective risk reduction. A useful proposal names the risks that drive the choice, the regulatory or contractual obligations in scope, and the cost of each step up. Before the proposal goes to leadership, confirm which customer contracts, sector rules or regulators already set a minimum Tier or specific outcomes. When a customer requirement sets a floor, leadership cannot choose a lower Target, so the decision becomes how to meet that floor and where to go beyond it.
An implementation partner can help prepare the evidence behind a Current Profile, document practices and trace gaps, but it should not set the Target Tier. That choice depends on the organization's risk appetite, its obligations and its budget, none of which an outside party owns. If a partner offers to recommend a Tier, ask what risk inputs it used and who on the client side approved them. Independent assessors likewise test whether the stated Tier matches the evidence, and they will not choose it for you. Keeping ownership with leadership also protects the scoring itself: a Tier chosen by the people who will be measured against it is hard to defend to a board, a customer or an auditor.
When moving up a Tier is worth the cost
CSWP 29 encourages moving to a higher Tier when risks or mandates grow, or when a cost-benefit analysis shows a feasible, cost-effective reduction in risk. NIST gives no cost figures for any of this, so each card below names a trigger and the check that tells you whether the step pays off.
Contractual and regulatory mandates
Start by listing every contract, customer questionnaire and regulation that names or implies a CSF expectation. A mandate that requires evidence of repeatable, documented practices usually points to Tier 3 for the outcomes it covers, while a request for ad hoc answers may not justify more. Ask each requiring party what evidence they will accept and whether the wording sets a minimum Tier or only a topic. Record the answers so the target Tier can be traced to a source.
Exposure to critical suppliers
When a single cloud provider, managed service or software vendor supports core operations, the cost of its failure grows. Consider a hypothetical bank that relies on one outsourced payments processor: its supplier oversight practices may need to move from informal checks to documented, monitored reviews to match that exposure. Check which supplier-related outcomes in GV.SC and ID.RA carry the most weight in your business, then decide how far those need to mature.
Incident history and recurring failures
Repeated incidents with the same root cause are a strong signal that a Tier is too low for the affected Functions. If response activities differ by person or are rebuilt each time, the gap is usually in repeatable processes rather than tools. Review post-incident reports for recurring causes, then set the target Tier for Respond and Recover based on what would have prevented the repeat, not on what would look best in a report.
Size of the asset and data at risk
The value of what you protect shapes how much rigor is warranted. Identify the systems and datasets whose loss would stop operations or expose regulated data, then compare their current governance and monitoring with the Tier you intend to reach. A higher Tier for a small set of critical assets can be more cost-effective than a uniform higher Tier across the whole estate. Confirm asset inventories are complete before relying on this comparison.
Cost-benefit analysis of the step
Build your own estimate for each proposed Tier change. Include staff time for policy and process work, tooling and hosting, training, independent assessment, and the recurring effort to keep evidence current. Set these against the expected reduction in loss or disruption for the risks in scope. NIST does not provide cost figures or a formula, so the estimate must come from your own environment and quotes, and it should state its assumptions openly.
Leadership sign-off and funding
Tier decisions belong to leadership, and the chosen Tiers then shape the Current and Target Profiles. Bring the proposed Tier, the risks it addresses and the estimate to the accountable executive in writing. Note which Tier changes are not worth funding now and why, because a documented decision to stay at a lower Tier is more defensible than an unexamined gap. Revisit the decision when mandates, suppliers or incident patterns change.
How to run a maturity score without a NIST model
NIST does not prescribe a scoring model, so an organization sets its own sequence: fix the scope, define the scale, rate outcomes against evidence, roll ratings up under a written rule, challenge them, and record the method so an outside assessor can follow it.
Confirm the scope of the score
Leadership and the assessment owner agree which business units, systems, suppliers and CSF Functions the score covers, and which Tier the organization is aiming for. NIST's Tiers guidance says leadership generally selects the Tiers the organization should meet, and that choice then shapes the Current and Target Profiles. The output is a short scope statement that names the Functions in scope, the excluded areas and the reason for each exclusion, signed off by the executive sponsor. The step is done when someone outside the assessment team could read the statement and state what is and is not being scored.
Agree the rating scale and definitions
Because NIST's Organizational Profile template allows a rating such as 1 to 5 or 0 to 100 percent, the team must pick one scale and define what each rating level means in plain terms. For example, a level might require that a practice is documented, approved, implemented and periodically checked, but the wording is the organization's choice and should be illustrative until it is tested on a sample outcome. The output is a rating definitions sheet that maps each level to observable conditions, with the Tier descriptions in CSWP 29 Appendix B used as a reference for governance and risk management practices. The step is done when two reviewers rate the same outcome and reach the same level using only the written definitions.
Rate each outcome against evidence
Assessors record, for each Subcategory in scope, the current practice, the status, the rating and any artifacts that show the practice exists and works, such as approved policies, configuration exports, tickets, meeting records or test reports. Ratings should rest on what the evidence shows, not on what staff believe is happening. The output is a Current Profile worksheet where every rating points to one or more named evidence references with dates and owners. The step is done when no rating lacks an evidence reference, and any outcome with no usable evidence is marked as unrated with a reason rather than given a score.
Roll ratings up under a documented rule
Subcategory ratings have to be combined into Category, Function and overall Tier results, and NIST does not specify how. The team chooses a rule such as an average, a minimum or a weighted average for critical outcomes, tests it on the existing ratings, and writes it down with the reason for the choice. Results should show the rule's effect, for example whether a single weak Subcategory pulls a Function down. The output is a roll-up table by Function and an overall Tier statement, with the rule stated next to each figure. The step is done when a second person can reproduce every roll-up figure from the Subcategory ratings.
Challenge ratings with a second reviewer
A reviewer who did not perform the ratings checks a sample, or all ratings where the score is high, against the evidence and the definitions. The reviewer looks for ratings that rely on policy documents without evidence of operation, for ratings that cover only part of the scope, and for inconsistencies between Functions. Disagreements are resolved by the reviewer and the rater together, and where they cannot agree the question goes to the sponsor. The output is a review log listing each challenged rating, the original and final rating, and the reason for any change. The step is done when every challenged rating has a recorded resolution.
Record the method for later assessors
The team writes down the scope, the scale, the evidence standards, the roll-up rule, the reviewer names and the dates of each stage, and stores them with the Current Profile and the evidence index. This record lets an internal auditor, a customer or an independent assessor follow how a score was produced and repeat it. If the organization later changes the scale or the rule, the change is logged so older and newer scores are not compared as if they used the same method. The output is a method document and a version history for the scoring workbook. The step is done when a person who did not run the assessment can reproduce the scores from the record alone.
Common scoring errors that make a Tier claim hard to defend
NIST prescribes no scoring model, so the rigor behind a Tier claim depends on how the organization rates its outcomes and documents them. The five errors below are the ones that most often make a Tier claim collapse under questions from a customer, board or assessor.
Rating outcomes without evidence
A self-assigned rating is only a opinion until someone can point to the artifact behind it. The Organizational Profile template records current Practices, and those Practices can include artifacts that evidence the outcome. Before accepting any rating, ask the owner to name the policy, log, ticket or test result that shows the practice runs as described, and mark the rating as unsupported if no such artifact exists.
Mixing scales across Functions
When one team rates on a 1 to 5 scale and another uses percentages, the Govern and Protect columns cannot be compared or summed. Pick one rating scale for the whole Profile, define what each value means in writing, and apply the same anchors to every Function. Inconsistent scales are one of the first things a reviewer notices in a shared Profile.
Treating a Tier as a certificate
Tiers describe the rigor of risk governance and management practices. They are not a pass or fail grade, and NIST does not offer certifications or endorsements of CSF implementations. Describe a Tier claim as a self-described position supported by named evidence, and avoid wording that suggests an external body has confirmed it.
Averaging away weak Govern outcomes
A high overall average can hide a Govern Function that is still ad hoc. Governance outcomes such as the risk management strategy, roles and oversight drive how the other five Functions are run, so a weak Govern score undermines the rest. Report Govern and each Function separately, and check whether the lowest-rated Category sets a ceiling on the Tier you claim.
Copying a sector or vendor model unchecked
Sector bodies and vendors publish scoring templates built for their own risk profile and assets. Adopting one without testing it against your environment can produce ratings that look rigorous but measure the wrong things. Before adopting a borrowed model, map its questions to your own Subcategories, confirm the criteria match your risk and mandates, and record any changes you made so the Tier rationale stays traceable.
Questions buyers ask about NIST CSF Tiers and scoring
Is there an official NIST CSF score?
No. NIST does not prescribe a scoring model for the Cybersecurity Framework 2.0, and it leaves measurement to each organization's discretion. The Tiers describe how rigorously an organization governs and manages cybersecurity risk, moving from Partial (Tier 1) to Risk Informed (Tier 2), Repeatable (Tier 3) and Adaptive (Tier 4). Any numeric score you see, such as a rating from 1 to 5 or a percentage, is an internal convention your organization chooses and must explain. When a customer asks for a score, ask which method produced it, who reviewed the ratings, and what evidence supports each one.
Can a NIST CSF Tier be certified?
No. NIST states that it does not offer certifications or endorsements of CSF-related implementations or services and has no plans for a conformity assessment program. A Tier is a self-described characterization of your risk governance and management practices. An independent assessor can review your evidence and give an opinion on how well it supports the Tier you claim, but that opinion is not a certificate issued under a NIST scheme. Ask any provider to state exactly what document they will issue and who stands behind it.
Who sets the target Tier for our organization?
Leadership generally selects the Tiers the organization should meet, according to NIST's Tiers Quick-Start Guide (SP 1302). The chosen Tiers then inform the Current and Target Profiles. Security and compliance teams should prepare the options, including the risks, mandates and cost of each step, but the decision belongs to executives who own the risk. NIST also encourages moving to a higher Tier when risks or mandates are greater or when a cost-benefit analysis shows a feasible, cost-effective risk reduction. Record the reasoning so the target can be defended to customers and auditors.
How long does a scoring exercise take, and what drives the effort?
NIST does not publish a duration for scoring, so treat any timeline as something to agree in writing. The main drivers are the number of Functions and Categories in scope, the number of business units and systems, how many outcomes already have documented evidence, and how many stakeholders must review each rating. Scoring is faster when policies, asset inventories and recent test results already exist. It slows down when practices are informal or undocumented, because each rating then needs interviews and evidence collection. Ask for a plan that lists the scope, the assessed outcomes and the review steps.
What does the work need from our team?
The work needs people who can describe current practice accurately and produce evidence for it. Typically this includes a sponsor who can approve the scope and target, owners for governance, asset management, identity, detection and recovery, and staff who can show artifacts such as policies, tickets, configuration records and test reports. The Organizational Profile template in SP 1301 records current Practices, which may include artifacts that evidence the outcome, along with Status, Rating, Priority and Goals. Each rating should trace to a named owner, so budget time for those people to review their own sections.
Can we score our own maturity without outside help?
Yes. NIST's framework is voluntary and publishes free Quick-Start Guides and templates, including the Organizational Profile template in SP 1301 and the Tiers guidance in SP 1302. Internal teams often do a first pass well when they have an experienced assessor, a documented scope and an honest review process. Outside help becomes more useful when ratings are challenged by customers, when internal reviewers are too close to the systems they are rating, or when you need an independent opinion for a contract. An implementation partner can prepare evidence and systems, but only an independent assessor can give an independent opinion.
Which rating scale should we use?
Pick one scale, define each level in writing, and use it across every Function so results can be compared over time. NIST's Organizational Profile template gives examples such as a 1 to 5 scale or a 0 to 100 percent scale, but the choice is yours. A 1 to 5 scale is easier to tie to Tier descriptions and to explain to executives. A percentage scale can create false precision unless each band is backed by criteria. Whatever you choose, define what evidence each level requires and how a rating changes when that evidence changes.
How DeployOpen prepares scoring evidence for a NIST CSF assessment
DeployOpen prepares the systems, controls and evidence that an organization needs before it rates its own practices, and it does so under a written scope that the organization approves. The work starts by fixing the Organizational Profile boundary: which business units, systems and outcomes the Current Profile covers, and which Tier the leadership team has chosen as the target. Once that is agreed, DeployOpen works through the self-hosted platforms in the client's own cloud accounts, data centers or air-gapped networks to confirm that the practices recorded for each outcome exist and can be shown. For each rating on the scale in NIST's Profile template (SP 1301), the team identifies the artifact that supports it, such as an exported configuration, a log sample, a test result or a signed policy, and records where that artifact lives and who owns it.
The rating itself stays with the organization. DeployOpen does not set the target Tier, does not assign Tier ratings, and does not issue reports or certificates. NIST's guidance says leadership generally selects the Tiers the organization should meet, and an independent assessor or certification body is the only party that issues a formal opinion. What DeployOpen hands over is the documentation of the method: the rating scale used, the definition of each rating level, the evidence index, the assumptions made about scope, and the open items that the organization still has to close. A reader should ask any implementation partner for this method document in writing before accepting a rating, because it lets internal reviewers and outside assessors repeat the same reasoning.
Engagements are fixed-scope. The written quote follows from the agreed Profile boundary, the number of systems and outcomes in scope, and the evidence the organization already holds, so the cost and timeline depend on those inputs rather than on a standard price. Ask for a breakdown of one-time preparation work, any recurring retainer for re-rating or testing, and what the organization must provide itself, such as staff time for interviews and access to source systems. Hiring DeployOpen does not guarantee any outcome, including a particular Tier, a favorable review by a customer or a passed independent assessment. Confirm those points in the statement of work before work begins.
