What NIST CSF profiles and tiers mean for your readiness work
When a customer, contract or regulator asks for NIST CSF 2.0 alignment, the first thing to understand is what it can and cannot ask you to prove. Current and Target Profiles record your cybersecurity outcomes against the CSF Core, and Tiers describe how rigorous your cybersecurity risk governance and management practices are. NIST issues no certification for CSF 2.0, so no document from NIST confirms that you meet a Tier or a Profile. The evidence is whatever your own assessment produces, and the person who relies on it decides whether it is enough.
The Target Profile and the chosen Tiers differ from one organization to the next because they depend on scope, mandates and risk appetite. A bank supervised under a specific regime, a healthcare provider and a software vendor selling into regulated customers will not select the same outcomes or Tiers, and the Tier leadership selects should match the risks and obligations you actually carry. Before you start, confirm in writing which customer or regulatory requirements define the expected Tier, which business units and systems fall inside the Profile, and who in leadership approves the choices.
Your organization owns its Current and Target Profiles, the Tier decisions and the risk acceptance behind them. An implementation partner can prepare working material, such as a Profile template populated from your interviews and system records, a gap list, and an evidence index that maps each outcome to the artifacts an assessor would ask for. The partner does not set your targets or certify your posture, and only an independent assessor you engage can issue a report that a third party will accept.
How Current and Target Profiles work together
An Organizational Profile is how an organization describes its cybersecurity posture in terms of the CSF Core's outcomes, and it comes in two parts. The *Current Profile* records which outcomes the organization achieves today or is attempting to achieve, and how well it does so. The *Target Profile* records the outcomes the organization has selected and prioritized, taking into account expected change such as new requirements, technology adoption and shifting threats. Because the Target Profile looks ahead, it is a planning document as much as a measurement, and the two profiles are only useful when they describe the same set of outcomes at the same level of detail.
The gap between the two profiles is what drives the action plan. Each outcome where the Target is more demanding than the Current becomes a candidate for work, and the priority of that work follows the Target's ranking. Before building anything, confirm who owns the Target decision. Leadership generally selects the Tiers the organization should meet, and those Tiers then inform both profiles, so the Target should be agreed with the executives who accept the residual risk. Ask the people producing the Current Profile to record evidence for each outcome, not only a self-rating, so the gap rests on facts an assessor could inspect.
NIST says Organizational Profiles are generally not shared publicly, so treat them as internal records that you choose to disclose, usually to a customer, regulator or auditor under an agreement. NIST's Excel template supports side-by-side comparison of the Current and Target Profiles, and the Organizational Profiles Quick-Start Guide (SP 1301, February 2024) explains how to use it. Confirm that the template you adopt keeps the Current and Target entries aligned by outcome, and that it has a named owner who updates it after each review. A profile that nobody maintains becomes a snapshot that misstates the posture within a year.
What each of the four Tiers asks for
Partial is the starting point on the CSF Tiers scale. At this Tier, cybersecurity risk management is informal and reactive. Decisions are made case by case, often by individuals, and there is little consistent awareness of how cybersecurity risk relates to organizational objectives. Coordination with other risk management activities is limited, and the organization may not have a documented way to share cyber risk information internally or with partners.
- Governance: Cybersecurity risk is not formally directed, and no policy or accountable owner consistently sets priorities.
- Risk identification: Asset and threat information is gathered when an event forces it, not on a planned cycle.
- Protection and detection: Safeguards exist in pockets, and monitoring depends on who notices a problem.
- Response and recovery: Responses are improvised, and lessons from past events are rarely written down or applied.
- Sharing: Cyber risk information is passed informally, so leaders may not see the full picture.
Before you select Tier 1 as a target, confirm with leadership whether your customers, contracts or regulators expect a more structured approach.",
Risk Informed means management approves cybersecurity practices, and those practices reflect the organization's risk priorities. The approach is not yet an organization-wide policy, so practices may vary between teams. Risk assessments inform decisions, but the process may not be repeated on a fixed schedule or integrated into every business function. Leadership knows what risks matter, yet execution depends on individual teams.
- Governance: Leaders approve risk-based practices and direct where cybersecurity effort goes, although a formal, organization-wide policy may be missing.
- Risk assessment: Assessments are done for significant systems and projects, using a method that people understand.
- Prioritization: Safeguards are chosen on the basis of identified risk and business impact.
- Consistency: Practices may differ by team, and the organization may lack a standard way to measure them.
- Information flow: Risk information reaches relevant decision makers, but not always in time to change direction.
If you are at this Tier, check whether the gaps between teams are documented, because they are often the first findings an assessor raises.",
Repeatable means the organization has formal policies for cybersecurity risk management, and practices are updated based on risk assessments and changing threats. Processes are consistent across the organization and produce results that can be compared over time. The Govern Function is well established, and roles, reporting and supplier risk are part of normal operations rather than special projects.
- Governance: A formal cybersecurity risk management policy exists, and leaders review performance on a regular cycle.
- Process consistency: Practices are applied the same way across business units, and staff know the steps to follow.
- Risk updates: Risk assessments refresh controls when the environment, threats or requirements change.
- Measurement: Metrics show whether outcomes in the Target Profile are being met.
- Supplier and improvement: Supplier risk and lessons from exercises feed back into plans on a repeatable schedule.
Before claiming Tier 3, ask for evidence that the policy, the review cycle and the metrics operate in practice, not only that they are written down.",
Adaptive is the highest Tier. The organization adjusts its cybersecurity practices based on lessons learned and predictive indicators, and it responds to changes in threats and technology in close to real time. Cybersecurity is integrated into strategic decisions, and the organization shares what it learns with partners. Reaching Tier 4 is usually a choice made for high risk or high obligation, and NIST notes that higher Tiers should be justified by a cost-benefit analysis rather than assumed.
- Governance: Cybersecurity risk is part of enterprise strategy, with leadership reviewing predictive indicators and adjusting direction.
- Continuous improvement: Lessons from incidents, tests and operations change practice quickly and are tracked to completion.
- Adaptive response: Monitoring and response adjust to emerging threats and to changes in the organization's own environment.
- Information sharing: The organization exchanges cyber risk information with suppliers and partners in a planned way.
- Cost justification: Leaders document why the added rigor reduces risk enough to justify its cost.
Select Tier 4 only when a documented cost-benefit analysis supports it, and confirm the Tier with leadership before setting it as a target.
Who selects Tiers and why it is not a scoring exercise
NIST's Tiers Quick-Start Guide places the Tier decision with leadership, and the cards below explain what that decision connects to. Each card covers a different part of the choice: who makes it, how it sits beside existing risk methods, what justifies a higher Tier, and why reporting a Tier as a maturity score misreads the framework.
Leadership selects the target Tiers
NIST's Tiers Quick-Start Guide says leadership generally selects the Tiers the organization should meet. The chosen Tiers then inform the Current and Target Profiles, so the decision comes before any profile work begins. Check that the executive or board owner who accepts the cybersecurity risk is the person recorded as approving the Tiers, and that the decision is written down with its date and rationale.
Tiers complement your risk method
CSWP 29 says Tiers should complement an organization's existing risk management methodology rather than replace it. In practice, the Tier description tells leaders how rigorous their risk governance and management should be, while your current risk assessment, register and treatment process still decides what to do about each risk. Confirm that your risk team can point to where Tier-level expectations appear in the methods they already run.
Justify higher Tiers with risk
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 higher Tier needs a stated reason, such as a new regulator requirement, a larger exposure from a critical system, or a funded reduction in loss. Ask whether the case names the risks it addresses and the expected reduction, because a Tier target without that reasoning is hard to defend to an auditor or board.
Tiers are not a maturity score
A common mistake is to assess each Function, add up the results and report a single Tier as a grade, then use that grade in customer questionnaires. NIST describes Tiers as characterizing the rigor of governance and management practices, not as a pass mark. Check whether anyone in your organization is asking for a Tier number on a slide, and whether the Tier chosen by leadership is actually the one the Target Profile reflects.
Tier appendix as a starting text
Appendix B of CSWP 29 provides notional Tier descriptions with separate columns for cybersecurity risk governance, which maps to the Govern Function, and for risk management across the other five Functions. Organizations can reuse these descriptions, customize them or replace them. Before adopting the text, confirm that the wording reflects your sector, your size and the risks leadership has accepted, so the Tier target reads as your own decision.
Document the Tier decision
The Tier selection should be recorded with the decision maker, the date, the risks and mandates considered, and the cost-benefit reasoning behind any step up. Auditors, customers and regulators who later ask why a Target Profile sits where it does will look for this record. Store it alongside the Organizational Profiles and the gap analysis so that the chain from leadership decision to planned action is visible.
When a Community Profile should become your Target Profile
A Community Profile is a baseline of CSF 2.0 outcomes that many organizations share because they face the same sector, technology or threat. CSWP 29 describes it as a consensus starting point, and NIST's CSF FAQs note that Community Profiles reflect a consensus view and can inform an organization's Target Profile. The NIST Profiles page lists examples such as the SP 800-61 Rev. 3 incident response profile, a ransomware risk management profile and the Cyber Risk Institute's financial sector profile. Before you adopt one, identify which Community Profile matches your sector, the technologies you run and the threats you face most often, and confirm the profile's scope and publication date on the NIST page, since the list changes over time.
Adopting a Community Profile does not make it your Target Profile automatically. Your Target Profile records the outcomes your leadership has selected and prioritized for your own environment, including the Tiers leadership chose and the changes you expect, such as new regulatory requirements or technology adoption. Compare the Community Profile line by line with your Current Profile. Use it as a starting point where its outcomes match your risk, and strike or reprioritize outcomes that do not fit your systems, your legal obligations or your risk appetite. Record each change and the reason for it, so an auditor, customer or board member can see why the Target Profile differs from the baseline.
NIST's guide to creating Community Profiles is NIST CSWP 32, which the Profiles page links as an initial public draft. Read it if your industry group, sector body or contract wants to publish a shared profile, because it explains how such a baseline is built. Confirm the draft status and any later final version before you cite it in a policy or contract. Whichever profile you use, the decision belongs to your organization: confirm with your executive sponsor who approves the Target Profile, and keep your own Current Profile as the evidence of where you actually stand.
How to build profiles and select Tiers in sequence
This sequence turns NIST CSF 2.0 Tiers and Profiles from definitions into a working record: leadership sets the context and Tiers, the Current Profile shows where the organization stands, and the Target Profile and gap action plan show what to change next. Each step closes with a document that someone can review.
Confirm scope and risk context with leadership
Leadership defines which business units, systems, data and suppliers the profile covers, and records the mission, legal and contractual obligations and risk appetite that frame it. Cybersecurity risk management is a leadership decision under the Govern Function, so the people who own the risk decide the boundary. The step is done when a written scope statement names the covered environment, the accountable executive and the risk assumptions the profiles will rely on. Ask your reviewers to confirm that the scope matches the systems and contracts you actually run.
Select the Tiers leadership should meet
Leadership chooses the CSF Tiers the organization should reach, from Partial (Tier 1) through Adaptive (Tier 4), separately for cybersecurity risk governance and for risk management. NIST's Tiers Quick-Start Guide (SP 1302) explains that leadership generally makes this choice and that the Tiers then inform the Current and Target Profiles. Use the notional Tier descriptions in Appendix B of CSWP 29 as a starting vocabulary, then customize them to your risk methodology. The output is a short, signed Tier decision with the reasons for each selection, which you will revisit when risks or mandates change.
Draft the Current Profile in the Excel template
Staff who run each Function record the outcomes the organization currently achieves, or attempts to achieve, and how well, using NIST's CSF Organizational Profile template. The template is an Excel spreadsheet that lays Current and Target Profiles side by side, and SP 1301 (the Organizational Profiles Quick-Start Guide) explains how to fill it in. Evidence owners should cite the artifact behind each status, such as a configuration baseline or an access review. The step is complete when every Function has a status and an evidence reference, and the people who own each area have reviewed their rows.
Decide whether to adopt or adapt a Community Profile
Review the Community Profiles listed on NIST's Profiles page and decide whether one fits your sector, technology or threat exposure, such as the incident response profile based on SP 800-61 Rev. 3 or the ransomware profile. NIST's guide to creating Community Profiles, NIST CSWP 32, is linked from that page as an initial public draft, so check its status before relying on it. A Community Profile is a baseline that can inform your Target Profile, not a finished answer. Record which profile you adopted, which outcomes you added or removed, and why, so the choice can be explained later.
Set the Target Profile with priorities
Using the chosen Tiers, the Current Profile and any Community Profile as inputs, define the outcomes the organization has selected and prioritized for the Target Profile. NIST's framing considers expected changes such as new requirements, technology adoption and threat trends, so the target should reflect where the environment is going, not only where it is today. Assign priority and an accountable owner to each outcome that changes. The step is complete when the Target Profile is approved by the accountable executive and every changed outcome has a named owner.
Record the gap and action plan
Compare the Current and Target Profiles row by row to identify each gap, then turn each gap into an action with an owner, a priority and a way to verify completion. The Excel template's side-by-side layout supports this comparison, and the Tiers decision sets how far each Function must move. Feed the highest risks into your enterprise risk register so that the action plan, risk decisions and reporting use the same record. The output is a gap register that leadership can review and that an independent assessor can later trace back to the profiles.
Review the profiles on a fixed cycle
Set a recurring review in which the owners confirm that the Current Profile still reflects the environment, that the Tiers still match risk and mandates, and that completed actions moved the status they were meant to move. Profiles are internal working records and are generally not shared publicly, so keep the review within the governance forum that owns risk decisions. Update the Target Profile when requirements, technology or threats change, and note the change and the reason in the record. The step is done for each cycle when the profile version, approval and open actions are recorded.
What must be in place before profiles can be used as evidence
A Current or Target Profile is only as credible as the governance, asset data and record-keeping behind it. The cards below cover the four items an assessor or customer will look for first, and each one names a check you can run before a profile is shared.
Named ownership for each Function
Each of the six CSF 2.0 Functions needs a named accountable owner who can explain the outcomes recorded against it. Govern is the Function that sets this accountability, so its roles should be documented before the profile is filled in. To check it, ask each owner to walk through their Function's rows in the Current Profile and state who made each status call and when it was last reviewed. If the answer is a team name rather than a person, ownership is not yet established.
Documented risk management strategy
The Target Profile reflects priorities and risk tolerance, so it needs a written risk management strategy behind it. This is the Govern outcome that covers objectives, risk appetite and tolerance, and how cybersecurity risk feeds enterprise risk management. Check that the Target Profile's priorities can be traced to a stated tolerance, and that the document shows who approved it and when it was last reviewed.
Asset inventory the profile points to
Many Current Profile statements describe outcomes for specific hardware, software, services and data, so the profile must reference an inventory that exists. The Identify Function expects asset records, data flow maps and prioritization. To check it, pick five outcomes from the profile and confirm each one names systems that appear in the inventory with a current owner. Gaps here mean the profile describes systems the organization cannot list.
Dated and versioned profile record
A profile used as evidence must show which version was assessed, the date of each status entry, and the approver. Without this, a later reviewer cannot tell whether a Target Profile was set before or after an incident. Keep the NIST CSF 2.0 Organizational Profile template as the working file, store each approved revision with a change note, and confirm that superseded versions are retained rather than overwritten.
Organization sign-off on every profile
The organization owns its profiles, and sign-off must come from named internal leaders, not from a consultant or auditor. An implementation partner can prepare the profile and its evidence, but an independent assessor only tests it and does not issue a certification, since NIST does not offer one for CSF. Confirm that a designated executive or governance body has approved each version, and that the approval record sits alongside the profile.
Which profile route fits your situation
This table compares three ways to build the working material for a Target Profile: drafting from scratch, starting from a Community Profile, and using an implementation partner to draft the material. Read each row against your own starting point, then check what the organization must still own under each route, because the accountable decisions do not transfer to anyone else.
| Route | When it fits | What the organization still owns | What does not transfer |
|---|---|---|---|
| Build from scratch | Mature teams with a clear view of their own assets, obligations and risk appetite, and no sector baseline available | Selecting outcomes, setting priorities, recording current status and approving the Target Profile | Knowledge of the environment, which must come from internal inventories and interviews |
| Start from a Community Profile | Sectors or threat types with a published baseline, such as the ransomware or incident response profiles NIST lists | Tailoring the baseline to the actual business, removing outcomes that do not apply, adding local obligations | The consensus view itself, which reflects shared interests and not your specific risk decisions |
| Implementation partner drafts the working material | Teams short on staff time or without CSF experience who need a first Current Profile and draft Target Profile | Accepting or rejecting every entry, leadership approval of Tiers, and ownership of the evidence behind each status | Accountability for the posture described, since the partner prepares documents and does not set risk decisions |
| Hybrid: Community Profile plus partner draft | Organizations in a regulated sector that want a sector baseline and outside help mapping their own systems | Confirming the baseline fits the organization, and retaining the final Target Profile and its rationale | Certification or endorsement, because NIST offers no conformity assessment program |
Common mistakes that make profiles useless as evidence
A Current Profile, Target Profile and Tier only help when an assessor, customer or board can trace each entry to a decision and to proof. The mistakes below share one root cause: the profile records an opinion rather than a documented, risk-based, dated position.
Treating the Tier as a score
Tiers describe the rigor of cybersecurity risk governance and management, from Partial (Tier 1) to Adaptive (Tier 4). They are not a percentage or a pass mark, and NIST says they should complement an organization's risk management methodology rather than stand in for it. Check that each Tier selection has a written rationale tied to risks and mandates, and that leadership, not the security team alone, selected it. Ask whether a higher Tier is justified by a cost-benefit analysis.
Copying a Community Profile unchanged
A Community Profile is a consensus baseline for a sector, technology or threat, and it can inform a Target Profile. Adopting it wholesale produces a target that reflects other organizations' environments, not yours. Before adoption, compare each Subcategory against your asset inventory, system architecture and contractual obligations, then record what you added, removed or prioritized differently. An illustrative example: a bank that adopts a sector baseline should document which outcomes its own payment systems change.
Setting a Target without a risk basis
A Target Profile should specify the outcomes an organization has selected and prioritized, considering expected changes such as new requirements, technology adoption and threat trends. A target chosen because it looks ambitious, or because a peer published it, cannot be defended to an auditor or board. For each target outcome, record the risk, requirement or business objective that justifies it, the owner and the date by which the gap is expected to close.
Leaving profiles unversioned
A Current Profile is a snapshot. Without a version number, date and change log, a reader cannot tell whether a statement describes last quarter's environment or today's. Store each Organizational Profile with its approval record, the Tier selected at that time and the evidence references behind each status entry. NIST notes that Organizational Profiles are generally not shared publicly, so the internal version history is what proves the profile was maintained and not rewritten after a request arrived.
Statuses without linked evidence
A Current Profile entry that says an outcome is achieved is a claim until it points to something an assessor can inspect, such as an inventory export, a configuration baseline, a test report or a training record. Map each Subcategory status to a named artifact, its location and its date. Entries with no artifact should be marked as unverified rather than achieved, so that the gap analysis does not hide them.
Confusing a profile with a certificate
A Current or Target Profile is an internal description of posture, and NIST states it does not offer certifications or endorsements of CSF implementations or services. No accredited body issues a NIST CSF certificate. Describing a profile as certified, or sending a customer a profile as if it were a third-party report, invites rejection in procurement. If a customer needs independent assurance, ask for an assessment by a qualified independent party and state its scope, date and limitations in the cover note.
Questions buyers ask about profiles and Tiers
Does NIST certify NIST CSF 2.0 profiles?
No. NIST does not offer certifications or endorsements of CSF-related products, implementations or services, and it has no plans for a conformity assessment program. An Organizational Profile is an internal record of your current and target outcomes, so no certificate exists for it. If a customer asks for proof, the usual evidence is the profile itself, the gap analysis behind it and a report from an independent assessor who reviewed your controls. Confirm with the requesting party which form of evidence they will accept before you start.
Who selects the CSF Tiers for an organization?
Leadership generally selects the Tiers the organization should meet. NIST's Tiers Quick-Start Guide says the chosen Tiers then inform the Current and Target Profiles, so the choice is a governance decision, not a technical one. Security staff usually prepare the options and the risk reasoning, and executives or the board approve them. The Tiers should complement your existing risk management method, and moving to a higher Tier makes sense when risks or mandates are greater or a cost-benefit analysis supports it.
Must we share our CSF profiles with customers?
Not necessarily. NIST says Organizational Profiles are generally not shared publicly, so they are normally internal working documents. Customers usually ask for an attestation of alignment, a summary of the gap analysis or evidence for specific outcomes, and you can decide what to disclose. Community Profiles are different: they are published baselines that reflect a consensus view, and your Target Profile can draw on one. Agree the disclosure scope in the contract before sharing anything sensitive.
How much effort does building a profile take, and what drives it?
Effort depends on how many Subcategories you include, how much evidence already exists and how many systems and business units sit in scope. A narrow scope with current asset inventories and documented policies takes far less work than an enterprise-wide profile across many suppliers and legacy platforms. The number of stakeholders who must confirm their outcomes also matters, because each owner needs time to review status. Ask any provider to break its estimate into scoping, interviews, evidence gathering and review, and to state which assumptions it depends on.
Can an outside partner prepare our CSF profiles?
Yes, an implementation partner can prepare the scoping, the Current and Target Profile drafts, the gap analysis and the evidence that supports each status entry. The organization still owns its risk decisions, its Tier selection and its target outcomes, and leadership must approve them. A partner does not issue an assessment report or certificate, so an independent assessor is needed if a third party must verify the result. DeployOpen works under a fixed scope agreed in writing before work starts, and its role is to prepare systems and evidence, not to certify them.
What must our organization provide before a profile project starts?
Start with the people and records a profile depends on. You need named owners for the functions in scope, an up-to-date view of your assets, access to current policies, incident and vulnerability records, and the risk register or a clear statement of risk appetite. Leadership must agree the mission and the Tiers they want to reach, and someone must have authority to approve the Target Profile. Missing inventories and unclear ownership are the most common causes of delay, so confirm access and availability in the scope before signing.
Do Community Profiles replace building our own profile?
No, they give you a starting baseline, not a finished answer. A Community Profile describes outcomes shared by many organizations for a sector, technology or threat type, and NIST's guide to creating them is NIST CSWP 32, currently an initial public draft. You still need to compare the baseline with your own mission, systems and risks, adjust priorities and record your Current Profile honestly. Many organizations use an existing profile such as the incident response or ransomware profiles as their Target Profile and then add their own outcomes.
Where an implementation partner fits
The organization owns its Tiers, its Current and Target Profiles and the controls behind them. Leadership selects the Tiers it should meet, and those choices then shape both Profiles, so the decisions belong to the people accountable for cybersecurity risk, not to whoever does the implementation work. An implementation partner such as DeployOpen can prepare the systems, working Profile spreadsheets, gap analysis inputs and supporting evidence inside the organization's own cloud accounts, data centers or air-gapped networks. Before any work starts, confirm in writing which Profile template the work will populate, who signs off each Tier decision, and where the resulting records will be stored.
Be precise about what the partner does not do. DeployOpen prepares systems, controls and evidence, but it does not issue attestations, certificates or assessment reports, and it does not guarantee any Tier, Profile score or outcome. NIST does not offer certifications or endorsements of CSF-related implementations or services, so any claim that a provider has certified an organization against CSF 2.0 should prompt a question. Only an independent auditor or assessor, engaged by the organization, can issue a report on its results. Ask any partner to state that boundary in the proposal and to identify which deliverables are evidence inputs rather than conclusions.
A practical check before signing is to ask for the scope of the engagement in terms of Profile work: which Community Profiles, if any, will inform the Target Profile, which Functions the Current Profile covers, and who inside the organization must review each draft. Expect fixed-scope terms with deliverables and timelines agreed in writing before work begins. Keep the internal owner for each Function named in the Target Profile, because a partner can document a gap but cannot accept the residual risk on the organization's behalf.
How DeployOpen prepares profiles and evidence for your assessment
DeployOpen is a Chainscore Labs company that plans, implements and documents self-hosted open-source platforms inside your own infrastructure. For NIST CSF profiles and tiers, we prepare the systems, records and evidence your team needs to maintain Current and Target Profiles, while your leadership owns the Tier decisions and an independent assessor issues any formal report.
How we scope
- Agree in writing which Functions, Categories and Subcategories the Current and Target Profiles will cover.
- Confirm which leadership group selects the Tiers and which Community Profiles, if any, feed your Target Profile.
- Define which systems, cloud accounts and data centers fall inside the written scope and which sit outside it.
How we build
- Set up a self-hosted workspace in your environment to hold the Current Profile and the Target Profile side by side.
- Map each Subcategory status to named systems, owners and the evidence that supports the stated status.
- Test that the chosen Tier descriptions match the processes, approvals and risk reporting your teams actually run.
How we hand over
- Deliver the completed profile records, gap analysis and action plan in formats your team can maintain.
- Document how each Profile entry was built, who owns it and when it should be reviewed next.
- Provide an evidence index that an independent assessor can sample, without DeployOpen issuing any report.
How we support
- Offer ongoing support, upgrades and updates to profiles as NIST publishes new Quick-Start Guides or Community Profiles.
- Available as a retainer for periodic profile reviews after the fixed-scope engagement ends.
- Ask for the written scope, deliverables and support terms in any quote before work begins.
