Showing NIST CSF alignment to customers starts with a Current Profile, not a certificate
When a contract or security questionnaire asks whether you follow NIST CSF 2.0, the honest answer is a documented, evidenced statement of your current capabilities. NIST does not certify or endorse implementations of the framework, and it has no plans for a conformity assessment program, so no certificate exists to hand over. Any vendor offering a "NIST CSF certified" badge is describing something NIST does not recognize. Your customer is not really asking for a logo. They want to know which outcomes you achieve, how you know, and who has checked it. A Current Profile, meaning a record of the Core Categories and Subcategories your organization achieves today with the evidence behind each, answers that question directly. Its content should be scoped to the services the customer buys, so write down which systems, locations and teams that statement covers before you write anything else.
What differs between suppliers is scope, the independent reports they already hold, and how much evidence the customer's own risk tier demands. A supplier with a current SOC 2 report or an ISO/IEC 27001 certificate can often map those controls to CSF outcomes and reuse much of the same evidence, while a smaller supplier may need to produce it from scratch. A customer handling low-sensitivity data may accept a Current Profile with summary evidence, while a customer that places critical workloads with you will usually ask for samples, dates and test results. Before you respond, confirm with your customer which CSF Functions and Categories matter most to their supplier risk process, and confirm which of your existing reports they will accept as evidence. Those two answers determine how deep the Current Profile needs to go.
Which evidence suppliers are commonly asked to provide
What asset inventory do customers usually ask a supplier to show?
Customers usually ask for a current inventory of the hardware, software, cloud services and data that touch their information, because NIST CSF 2.0 expects an organization to know what it runs (ID.AM). The artifact is typically an exported inventory or configuration management database extract with an owner, a classification and a last-updated date, not a diagram drawn for the occasion. Expect to share a summary rather than the full inventory. Confirm with your legal team which artifacts you can release under NDA, and whether the inventory can name subprocessors or only categories of them.
Which governance policies do customers expect to see mapped to GV outcomes?
Customers expect the cybersecurity risk management policy, and the supporting policies that cover access, data handling, incident response and supplier management, with a table showing which Govern outcomes each one addresses. The Govern Function (GV.PO, GV.RM, GV.RR and GV.SC) is where buyers look first, since it was added in CSF 2.0. The artifact is a policy set with version numbers, approval dates and review cycles. Confirm which documents are releasable under NDA and which can only be described in a questionnaire response.
How do suppliers show vulnerability handling to a customer?
Suppliers typically show how they find, rank and fix vulnerabilities, and how they accept reports from outside. Common artifacts include a written vulnerability management procedure, a summary of recent scan or patch cycles, and a published or contractual disclosure channel. These support the identification and platform security outcomes in ID.RA and PR.PS. Ask customers whether they want the procedure, metrics from the last reporting period, or both. Confirm which findings you can share without exposing unpatched systems, and whether a redacted summary satisfies the request.
What backup and recovery test records do customers ask for?
Customers commonly ask for evidence that backups exist, are protected, and have been restored successfully. The artifact is usually a backup policy, a summary of the most recent restore test with its date and outcome, and the recovery time and recovery point targets the service commits to. These map to PR.DS-11 for backups and RC.RP for recovery execution. Restore test records can contain sensitive detail, so confirm with your team which parts you can release, and whether the customer accepts a written attestation from an independent reviewer instead.
What incident response contact and notification terms should suppliers provide?
Customers want a named incident contact, an escalation path and written notification terms that state how quickly and through which channel they will hear about an incident affecting their data or service. The artifacts are the incident response plan summary, a contact matrix kept current, and the contract clause that sets notification obligations. These address RS.CO and the supplier-related parts of DE.CM. Confirm internally which timelines you can commit to contractually, and which contact details you will share outside the contract.
What access review records do customers expect to see?
Customers typically ask for proof that access to their environment or data is granted on a need basis and reviewed on a schedule. The usual artifacts are an access control policy, a sample of recent access review results showing who was checked and what was changed, and a description of how privileged accounts and multi-factor authentication are handled. These map to the PR.AA outcomes. Access review exports include personal data about staff, so confirm whether you can release samples, aggregated results, or a signed statement.
How do suppliers flow down security requirements to their own vendors?
Customers increasingly ask how a supplier manages its own suppliers, since GV.SC covers supply chain risk across the relationship. Suppliers commonly provide a supplier security policy, a list of critical subcontractors with their roles, and a sample of the security clauses required in subcontract agreements. Customers may also ask for due diligence records on those subcontractors. Confirm which subcontractor names you can disclose under NDA, and whether the customer will accept a description in place of the contracts themselves.
Mapping existing SOC 2 or ISO 27001 controls through NIST informative references
NIST publishes informative references that link CSF 2.0 Subcategories to controls in other standards, and the Reference Tool export shows which of those links exist. For ISO/IEC 27001:2022, the supplied count is that 99 of the 106 Subcategories map to at least one Annex A control, and each of the 93 Annex A controls maps to at least one Subcategory. That makes ISO 27001 the most useful starting point for a supplier that already holds a certificate and wants to answer a customer's CSF question with its existing evidence. Confirm the current mapping version in the Reference Tool before you cite it, because NIST updates informative references separately from the framework document. The export is available through the NIST CSF 2.0 Reference Tool export, and the NIST Informative References for CSF 2.0 page explains how the mappings are maintained.
A mapping is a reference, not a substitute for testing. When you tell a customer that Subcategory PR.AA-05 is covered by an Annex A access control, you are pointing to where the evidence lives, and the customer will still expect to see that the control operated. Keep the mapping in a register with four columns: the Subcategory, the mapped control, the artifact that proves operation (for example, an access review export or a change ticket sample), and the date it was last tested. Be careful with SOC 2. NIST does not publish an official SOC 2 mapping in the supplied sources, so the supplier must build its own crosswalk from Trust Services Criteria to CSF Subcategories, and its CPA auditor should review that crosswalk before it goes to a customer. Ask the auditor to confirm that the crosswalk does not claim coverage the SOC 2 report does not test.
The mapping also shows where you are weak. Any Subcategory with no mapped control, and any Subcategory where the only mapped control was never tested in the past period, is a gap you should disclose rather than hide. Illustratively, if a customer asks about supplier monitoring in GV.SC-07 and your ISO 27001 supplier relationship controls have no operating evidence for the last quarter, say so and state the remediation date. Customers in regulated sectors often accept a documented gap with a plan more readily than a claim of full alignment they later find untrue. Review the gap list at each certification surveillance or SOC 2 period end, and record who owns each open item.
What to send depending on who is asking
Procurement teams usually ask whether you follow NIST CSF 2.0 as a yes or no item inside a broader vendor questionnaire. They need a short, consistent answer they can file and compare across suppliers. The right package is a summary Current Profile: a one-page or few-page view of which Functions and Categories you cover, your self-declared Tier where you have assessed it, and the known improvement areas you are working on. Because NIST does not certify anyone, the answer should be phrased as a self-description supported by your documents, not as a claim of compliance.
- Plain answer first: State whether you use CSF 2.0 as a voluntary reference and which Functions your program is organized around.
- Summary Current Profile: Share a short extract that names the outcomes you meet and the ones still in progress, dated and signed by an accountable owner.
- Scope statement: Name the services, systems and locations the statement covers, so the buyer does not assume enterprise-wide coverage.
- Independent reports, if any: Point to any SOC 2 or ISO 27001 report you hold, with its scope and period, and say what it does and does not cover.
- Declared gaps: List the open items you already know about rather than letting the buyer find them.
Before sending, confirm the profile date, the owner's name, the scope boundaries and whether the questionnaire wording asks for certification, which you should decline to claim.
Security architects evaluating your service want to test the claims themselves. They ask how a given Subcategory is implemented, who operates it and what records show it runs. The right package is a mapped control set: your existing controls, cross-referenced to NIST CSF 2.0 Subcategories through NIST's informative references, with each row pointing to an evidence item. This lets the architect follow a path from outcome to control to artifact without reading your entire program. Where you already run SOC 2 or ISO 27001 controls, the mapping can reuse that work, but the mapping must be checked against your actual environment rather than copied from a template.
- Mapped control set: A table linking CSF Subcategories, such as those in the GV.SC or PR.AA groups, to your internal control IDs and owners.
- Evidence index: For each mapped control, the artifact that shows it operating, such as an access review export, a patch report or a restore test record.
- Architecture context: Diagrams of data flows, trust boundaries and where customer data is stored or processed.
- Supplier chain disclosure: Your critical subprocessors and the outcomes you require of them.
- Sample evidence on request: Redacted extracts that the architect can inspect, with a clear rule for what is shared under NDA.
Before sending, confirm that each mapping row was reviewed by the control owner, that evidence dates fall in the same period, and that you have removed material not approved for external release.
Board members, audit committees and regulators ask a different question: is cybersecurity risk governed and resourced well enough to be trusted? They rarely want Subcategory detail. The right package is a short executive summary built around the Govern Function, showing who is accountable, how risk is reported, how the policy is reviewed and what the current improvement priorities are. You can reference the independent report you hold, but it should be presented as the basis for the summary, not as a substitute for the answer the reader asked for.
- Governance summary: Who owns cybersecurity risk, how often it reaches the board and what decisions were recorded.
- Risk and priority view: The top risks, the response decisions and the dated improvement plan.
- Independent assurance reference: The name of the assessor, the report type, scope and period, and how to request a copy under your confidentiality terms.
- Incident and supplier context: A factual account of material incidents and how supplier risks are monitored, without speculation.
- Contact point: A named person who can answer follow-up questions.
Before sending, confirm that the summary matches what the board actually received, that no figure is stated without a source and that legal or regulatory counsel has reviewed any statement about regulatory obligations.
Who owns the controls, who prepares evidence and who issues reports
Your organization owns every control, every Subcategory outcome you claim and every statement you give a customer. Your leadership approves the Current Profile before it leaves the building, because the profile describes your capabilities and known gaps, and you are accountable for whether those descriptions are accurate. Nobody outside your organization can make that call on your behalf.
- Control ownership: Named owners for each Category or Subcategory you assert, with a record of how each outcome is operated day to day.
- Profile approval: Sign-off from an accountable executive on the Current Profile and on any shared summary of it.
- Statements and questionnaires: Responsibility for answers to customer questionnaires, security schedules and contract clauses, including the wording of any claim of alignment.
- Evidence custody: Retention of logs, tickets, configurations and records that show the outcome operated over time, not only on the day you prepared them.
- Corrections: Updating the profile and the shared statements when systems, suppliers or staffing change.
Before sharing anything, confirm that each claim has an owner who can explain it and produce the underlying record.
An implementation partner such as DeployOpen can help your team build the systems, mappings and evidence packs that support a CSF alignment conversation. This work is typically scoped in writing before it starts, with the systems in scope, the deliverables and the timeline agreed in advance. The partner works inside your environment and reports to your team. It does not issue reports, attestations or certificates, and it does not decide which outcomes you claim.
- Systems preparation: Configuring and hardening the self-hosted platforms that produce logs, inventories and access records your outcomes depend on.
- Mapping work: Tracing how your existing controls relate to CSF Subcategories through NIST's informative references, for your review.
- Evidence packs: Assembling organized, dated records that map each claimed outcome to the artifacts that show it operating.
- Documentation: Drafting runbooks and profile documents that your owners review, edit and approve.
- Testing support: Running security testing that gives your team findings to act on, scoped in the same written agreement.
Before engaging a partner, confirm in writing which deliverables are included, who reviews them and that the partner will not represent your alignment to any third party.
An independent auditor, assessor or certification body is the only party that can issue a report or attestation on your controls. 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, so no body can certify CSF 2.0 compliance on NIST's behalf. Where a customer wants independent assurance, it comes from an assessor engaged for a defined scope and reporting standard.
- Scope and standard: The assessor defines what it tests and under which reporting standard, which may be a SOC 2 examination, an ISO 27001 certification or another engagement agreed with the customer.
- Testing: The assessor samples evidence, interviews staff and tests operating effectiveness independently of the partner who prepared the packs.
- Report issuance: Only the assessor issues the report, opinion or certificate, and it states the period and scope covered.
- Independence: The assessor must not be the party that built the controls it tests.
- Limits: A report covers the scope tested, so statements about unaudited systems remain your own claims.
Ask any assessor which framework and report type it will use, and whether the customer will receive the report directly.
Common mistakes that cause customers to reject an alignment claim
Customers who ask whether you follow NIST CSF 2.0 usually test the claim against evidence, not against your wording. The five pitfalls below share one root cause: a statement that goes further than what you can show. Check each one before you send a profile, a mapping or a letter.
Claiming certification
NIST does not certify organizations, products or services against the CSF, and says it has no plans for a conformity assessment program. A statement that you are "CSF 2.0 certified" or "NIST compliant" signals to a procurement team that the claim has not been checked. Describe your alignment as self-assessed unless an independent assessor has reviewed a specific scope, and name that assessor only if you hold their report. Ask legal and sales to review every use of the word "certified" in proposals and security questionnaires.
Overstating Tiers without evidence
Tiers describe how rigorously an organization manages cybersecurity risk, from Partial to Adaptive. Declaring Repeatable or Adaptive without records of repeated, reviewed and improved processes invites a customer to ask for those records, and a missing answer undermines the rest of the profile. Tie each Tier statement to dated artifacts such as review minutes, change records or metrics. If you cannot produce them, claim a lower Tier or state the Tier as a self-assessment that you are still building toward.
Sharing an Organizational Profile unredacted
NIST says Organizational Profiles are generally not shared publicly. An internal Current Profile can list unpatched systems, known weaknesses, staffing gaps and named vendors, which gives a customer a map of your exposure. CSWP 29 supports sharing a Current Profile to communicate capabilities and known improvement opportunities, but that version should be a deliberate extract. Before release, remove internal system names, IP ranges, unresolved findings that are not yet in a remediation plan, and personal names. Record who approved the version sent.
Mapping controls that are not operated
A mapping from your SOC 2 or ISO 27001 controls to CSF Subcategories through NIST's informative references is only as strong as the controls behind it. Listing a control as supporting a Subcategory when it exists only in a policy, or when the tool is licensed but not configured, produces a claim the customer can disprove in one question. For each mapped control, confirm that the control runs, that it has produced evidence in the last review period, and that an owner can explain it. Remove or flag any mapping that fails this check.
Letting the mapping go stale
A mapping written at one point in time drifts as systems move, vendors change and controls are retired. CSF 2.0 Subcategories, informative references and Quick-Start Guides are updated separately, and NIST's archive records new mappings since February 2024, so a mapping you built against an older reference can cite outdated correspondence. Assign an owner, set a review trigger tied to major changes such as a new cloud region, an acquisition or a new SOC 2 report period, and date every version you send. Withdraw the old version when you issue a new one.
Questions suppliers ask before answering a NIST CSF request
Does NIST certify suppliers against the CSF?
No. NIST does not certify organizations, products or services against the Cybersecurity Framework, and it says it has no plans to build a conformity assessment program. The CSF is a voluntary framework, so a customer asking about alignment is asking for a description and evidence of your program, not a certificate. Some customers accept a self-described Current Profile with supporting evidence, while others want an independent assessor's report. Ask the customer which of these they need before you start, because the answer changes the work. Only an independent auditor or assessor can issue a report on your controls, and no NIST body does that for CSF alignment.
Can a SOC 2 report answer a NIST CSF question?
Only partly. A SOC 2 report describes controls tested against the Trust Services Criteria, and those controls overlap with many CSF Subcategories, but the report does not state CSF alignment. To bridge the two, you map your SOC 2 controls to CSF Subcategories using the informative references NIST publishes, and you explain where the mapping has gaps. Expect the customer to ask about Subcategories that SOC 2 does not address, such as parts of GV.SC on supplier risk or RC.CO on recovery communication. Treat the mapping as your own document, reviewed by the people who run each control, and do not present an existing report as proof of every CSF outcome.
How long does a Current Profile take to prepare, and what drives the effort?
The effort depends mainly on three things: how many Subcategories you claim, how much evidence already exists, and how many systems and teams the profile covers. A narrow profile for one product line with recent audit evidence takes far less work than an enterprise-wide profile across six Functions and 106 Subcategories. The Current Profile records what you do today, so each claimed outcome needs an owner, a description and a source you can show. Ask any advisor for a scope that lists the Subcategories, business units and systems included, plus the evidence reviewed for each. NIST's Quick-Start Guides explain profile creation in detail, but no fixed duration is set by NIST for this work.
Can we prepare a CSF Current Profile ourselves?
Yes, many organizations do. NIST designed the CSF so that an organization can build its own profile, and CSWP 29 describes a Current Profile as a document you can share with business partners and prospective customers. An internal team needs people who understand each Subcategory, access to evidence owners, and time for review. The usual gaps are overclaiming, where a control is described as in place but has no recent evidence, and inconsistent answers across teams. An outside partner can help with structure, evidence collection and review, but the organization keeps ownership of its controls and the statements it makes to customers. Decide which parts you will own before you pick a partner.
What evidence do customers usually ask for with a CSF profile?
Customers typically ask for evidence that matches the outcomes you claim, rather than the profile alone. Common requests include:
- Current asset inventories and network or data flow diagrams (ID.AM)
- Access review records and multifactor authentication settings (PR.AA)
- Backup configuration and restore test results (PR.DS and RC.RP)
- Vulnerability management reports and change records (ID.RA and PR.PS)
- Incident response plans and tabletop exercise records (RS.MA and ID.IM)
- Supplier due diligence records and contract clauses (GV.SC)
For each item, confirm that the evidence is current, that someone accountable can explain it, and that you can share it under your confidentiality terms. Do not share raw logs or sensitive architecture without an agreement in place.
What should we ask a partner to include in a written scope?
A written scope should name the outcomes in or out of the profile, the systems and business units covered, the evidence each outcome relies on, and who on your side reviews it. Ask the partner to state its deliverables in writing, such as a Current Profile document, an evidence index, a mapping to existing SOC 2 or ISO 27001 controls, and a list of gaps with suggested owners. Confirm what is excluded, including any statement that the partner will issue an audit report or certificate, which only an independent assessor can do. Ask how changes to scope are priced and agreed. DeployOpen works from a fixed written scope with agreed deliverables and timelines, and it prepares systems, controls and evidence without issuing reports or certifications.
Which parts of the work can we outsource, and which must we keep?
You can outsource preparation, but not accountability. An implementation partner can help build the profile, collect and organize evidence, configure the systems that produce it, and draft the mapping to your SOC 2 or ISO 27001 controls. You must keep the decisions on risk, the sign-off on what you claim, and ownership of each control. If a customer later asks questions about a claim, your staff must be able to answer them. Where the customer needs independent assurance, you also pay an independent assessor or auditor separately, and that cost is outside the profile work. Confirm this split in the written scope so each party knows its role.
What does preparing a CSF profile cost, and what is one-time?
No price for this work is set by NIST, so the cost depends on the scope and on who does the work. Cost components usually include internal staff time for interviews and evidence, the partner's fees for the agreed deliverables, and any tooling or remediation needed to close gaps. Most of the profile work is one-time, but keeping it accurate recurs, because a profile that is not updated after system changes becomes a liability. Ask for a quote that separates the initial profile, the mapping, the evidence index and any ongoing review, and that states which items are one-time and which are retainers. Compare quotes against the same written scope, not against different levels of coverage.
How DeployOpen works on this
DeployOpen helps organizations prepare the systems, controls and evidence behind a Current Profile and any mapping to existing SOC 2 or ISO 27001 controls. The organization owns its alignment statement, and only an independent auditor or assessor issues reports or certificates.
How we scope
- Agree in writing which customer-facing outcomes and Subcategories the Current Profile will cover.
- Confirm which systems, cloud accounts and suppliers fall inside the disclosed scope.
- Identify which existing SOC 2 or ISO 27001 controls will be mapped through NIST's informative references.
How we build
- Prepare the Current Profile and the supporting records a customer questionnaire usually asks for.
- Configure logging, access reviews, backups and vulnerability tracking so evidence exists before the request arrives.
- Document the mapping from your existing controls to CSF 2.0 Subcategories, with the gaps marked clearly.
How we hand over
- Deliver the Current Profile, evidence index and mapping as documents your team owns and can update.
- Walk your security and sales teams through what each artifact proves and where it stops.
- Note which statements need an independent assessor's report before you give them to a customer.
How we support
- Offer retainer support to refresh the Current Profile and evidence after material environment changes.
- Review new customer requests against the existing evidence index before answers go out.
- Confirm with your assessor which mapped controls and profile statements their next report will cover.
Sources and further reading
- NIST Cybersecurity Framework FAQs ↗
- NIST CSWP 29, The NIST Cybersecurity Framework (CSF) 2.0 (PDF) ↗
- NIST SP 1301, CSF 2.0 Quick-Start Guide for Creating and Using Organizational Profiles ↗
- NIST CSF 2.0 Reference Tool export: Core, Implementation Examples and Informative References ↗
- NIST Informative References for CSF 2.0 ↗
