A NIST CSF profile is where the framework stops being a reading exercise. The Core lists outcomes. A profile says which of those outcomes matter to you, how well you achieve them today, and where you intend to be.
Most first profiles go wrong in one of two ways. Some are a spreadsheet of self-assigned scores with no evidence behind them. Others try to cover the whole organization at once and are never finished. This article walks through building current and target profiles that are honest enough to plan from and small enough to complete. If you need a refresher on the Core itself, see our overview of the six functions.
What an Organizational Profile is
CSF 2.0 describes an Organizational Profile as a picture of an organization's current or target cybersecurity posture in terms of the Core's outcomes. It has two parts.
The current profile states which outcomes you are achieving, or trying to achieve, and characterizes how or to what extent.
The target profile states the outcomes you have selected and prioritized to meet your cybersecurity risk management objectives.
Version 2.0 also introduced Community Profiles. These are baselines that a sector, technology community, or other group builds around a shared set of concerns. A Community Profile is a useful starting point for your target, but it is an input to your decisions, not a substitute for them.
NIST describes five steps for creating and using an Organizational Profile: scope it, gather the information you need, create it, analyze the gaps and build an action plan, then implement the plan and update the profile. The sections below follow that order and focus on where each step gets hard.
Scope the profile before you start
Scope answers two questions: which part of the organization, and for what purpose.
A profile can cover the whole organization, a business unit, a product, or a single system. For a first profile, narrower is better. A profile of one product's production environment can be done properly. A company-wide first profile tends to drift into estimates.
Write the purpose next to the scope. A profile built for board reporting needs different detail from one built to prioritize engineering work. Say a 60-person SaaS company wants to answer enterprise buyers' security reviews with more confidence. Its sensible scope is the customer-facing product and the systems that support it, not the internal finance stack.
Gather inputs before you write anything
The current profile depends on what you already know. Collect it first.
Obligations. Laws, regulations, and contract terms that set security requirements for the scope.
Risk information. Your risk register, recent risk assessments, and known threats relevant to your sector.
Existing assessments. Audit reports, penetration test results, and findings from earlier reviews.
Policies and procedures. What you have committed to on paper.
System evidence. Configuration exports, access review records, logging coverage, and backup restore tests.
If you already hold a SOC 2 report or an ISO 27001 certificate, much of this exists. The task is to index it against CSF subcategories, not to collect it again.
Write the current profile honestly
For each subcategory in scope, the current profile records three things.
Whether the outcome applies. If it does not, say why in one sentence. "Not applicable" without a reason invites the question later.
What you do today. Describe the practice in specific terms: the system, the owner, the frequency.
What shows it. Name the evidence. If there is none, say so.
The CSF does not prescribe a scoring scale for profiles. Many teams add one, and that is fine, but a score without the description and evidence beside it is a guess. Ratings also invite averaging, and an average across subcategories hides the weak spots a profile exists to expose.
The evidence column is where honesty gets tested. A policy that says access is reviewed quarterly is evidence of intent. An exported review record with reviewer decisions is evidence of practice. Our piece on types of audit evidence covers how to tell the difference.
Set a target that reflects your risk
The target profile is not "everything, fully". It is a set of choices.
Start from Govern. Your risk appetite, your obligations, and the services others depend on tell you which outcomes matter most. A target that raises every subcategory equally has not made any decisions. Our article on what the Govern function added covers where those inputs come from, and our guide to writing a risk appetite statement helps you write one specific enough to use.
For each subcategory, the target should say how far you intend to go and why. Some will stay where they are. Some will be explicitly deprioritized, which is a legitimate outcome if it is recorded and approved. A few will need significant change.
Set a time horizon. A target profile with no date is an aspiration. Pick a horizon that matches your budget and planning cycle, so the actions it produces can be funded.
Turn the gaps into an action plan
The gap analysis compares current to target, subcategory by subcategory. Each gap becomes a candidate action. The action plan puts them in order.
Prioritize by risk reduction first, then by dependency, then by cost. Dependency matters more than people expect. You cannot meaningfully improve monitoring for assets you have not inventoried, so asset management (ID.AM) work often has to come before continuous monitoring (DE.CM) work, even when detection is the bigger worry.
For each action, record:
The subcategory or subcategories it addresses
An owner and a target date
The evidence that will show it is done
Any risk you are accepting while it remains open, and who accepted it
That last field is the one people skip. It is also what makes the plan defensible. A gap that leadership knowingly accepted is a decision. A gap nobody mentioned is an exposure.
Keep the profile alive
A profile is a snapshot. Its value comes from updating it.
Revisit the current profile on a fixed cycle, at least annually, and after significant changes: a new product, an acquisition, a major incident, or a new regulatory obligation. Each update should record what changed and why, so the history shows movement.
Keep earlier versions. A sequence of current profiles showing gaps closing is more persuasive to a board, a customer, or a regulator than a single good snapshot. It is also how you find out whether the action plan is working.
The same discipline applies to the target. When your risk appetite or obligations change, the target should change with them, and the record should say who approved the new version.
How TrustLynce helps
TrustLynce's readiness dashboard shows readiness per framework and runs gap analysis against your mapped controls, which gives a current profile a live source rather than a static spreadsheet. Evidence is collected on a schedule, with timestamps and attribution, so each subcategory can point to a dated record. The NIST CSF framework page covers how the framework sits alongside the others you may run.