What GV.OC-01 asks for and why NIST CSF 2.0 Govern starts here
GV.OC-01 asks the organization to understand its mission and use that mission to shape how it manages cybersecurity risk. It is a Subcategory of the Organizational Context (GV.OC) Category, which sits in the Govern Function that NIST added to the CSF in version 2.0. Its position at the start of the Category matters: before an organization can weigh stakeholder expectations (GV.OC-02) or legal and contractual requirements (GV.OC-03), it needs a clear statement of what it exists to do and which risks would stop it from doing that. NIST's Implementation Example is to communicate the mission, for example through vision and mission statements or service strategies, so that the risks that could get in its way can be identified. The Subcategory absorbs part or all of CSF 1.1 ID.BE-2 and ID.BE-3, so organizations that already mapped their business role under the earlier version can carry that work forward, though the wording and placement have changed.
The difficulty is that many mission statements are written for customers and recruiters, not for risk decisions. A statement that promises to be the most trusted provider in a market says little about which systems, services or data would cause the most harm if they failed. A useful check is to ask a risk owner to name the one or two services the mission depends on most, then ask whether the cybersecurity risk register, the risk appetite and the budget ranking reflect that dependency. If they do not, the mission is decorative, and GV.OC-01 is not yet met in substance. Confirm with leadership which statement is the operative one and whether it is used in risk workshops.
For the assessment file, the evidence is a documented mission statement or service strategy with a visible link to cybersecurity risk decisions, such as a risk register entry or a board paper that cites the mission when ranking exposures. The control references behind GV.OC-01 include SP 800-53 Rev. 5.2.0 control PM-11 and clauses in ISO/IEC 27001:2022, which your assessor may use as cross-references. Check those mappings against the NIST CSF 2.0 Reference Tool before relying on them, since the tool is the source for each reference. The NIST CSF 2.0 Reference Tool export lists the informative references and Implementation Examples in one place.
Which business units, services and mission statements fall under GV.OC-01
GV.OC-01 only works if the organization decides which mission statements, service strategies and business lines it is talking about. The decisions below set that boundary, and each one changes which risks leadership must consider when it reads its mission.
Mission statements in scope
Start by listing every mission, vision and purpose statement that actually guides decisions: the board-approved statement, divisional charters and any public commitments. Record which document is authoritative when two statements conflict. GV.OC-01 asks that the mission be understood and used to shape risk decisions, so a statement that exists only on a website and never reaches budgeting or project approval is a weak starting point. Confirm with the executive team which statement they would cite when accepting a risk.
Service strategies and objectives
Mission statements are usually too broad to show which failures would matter. Pair them with the service strategies, product roadmaps or operating objectives that turn the mission into delivered outcomes. For each service, note the outcome leadership would consider a failure, such as a payment service being unavailable or patient records being altered. These outcomes give later risk analysis a concrete basis. Ask owners to confirm the list is current, since strategies often change faster than charters.
Business lines and business units
Decide which business lines and units sit inside the mission scope used for cybersecurity risk. A unit that generates revenue or holds sensitive data but operates under a different mission statement can create risks the parent statement never mentions. Document each unit's contribution to the enterprise mission and flag any unit with its own mandate, regulator or board. The result should be a list that a reviewer can check against the org chart and the legal entity register.
Subsidiaries and affiliates
Decide whether subsidiaries, joint ventures and majority-owned affiliates adopt the parent mission or keep their own. The answer determines whether a parent-level risk decision reaches a subsidiary that runs its own systems. Record the ownership and control relationship, the mission statement each entity uses and who approves risk acceptance for it. Where a subsidiary is out of scope, say so explicitly so an assessor does not have to infer it.
Shared services and external providers
Shared services such as identity, hosting, finance systems and security operations often support several missions at once. Decide which mission statement governs each shared service and how conflicts between units are resolved. External providers that deliver mission-critical services should be listed as dependencies of the mission, not treated as outside it. Confirm which team holds the shared-service inventory, because that inventory is the evidence that these dependencies were considered.
Ownership of mission documents
Name the accountable owner for each mission document and the team that maintains it, usually the executive office, strategy or the chief risk officer's function. Define how changes flow from the mission to cybersecurity risk management, including who reviews a revised statement and who updates the risk register. Without a named owner, the mission can drift from the risk program. Ask for a revision history and a review cycle as part of the evidence package.
How an assessor tests whether the mission drives risk management
This table sets out how an assessor typically tests GV.OC-01, what evidence they ask for and where organizations most often fall short. Read each row as a test step: the activity, the evidence that would satisfy it, and the finding that usually appears when the mission is documented but never used in risk decisions.
| Test activity | Evidence requested | Common finding |
|---|---|---|
| Interview leadership on how the mission shapes risk priorities | Named executives who can explain the mission and give one recent example of a risk decision it influenced | Leaders recite the mission but cannot connect it to any specific risk trade-off |
| Trace the mission statement into the risk appetite statement | Signed risk appetite or tolerance document with references to mission objectives or critical services | Risk appetite is written in generic terms and does not mention the mission or the services it protects |
| Trace mission-linked objectives into risk register entries | Risk register extract showing mission objectives, impact ratings and owners for each entry | Risk entries describe threats and controls but record no link to the objective at risk |
| Check that the mission is communicated to risk owners | Records of briefings, onboarding material or risk committee minutes that reference the mission | Mission appears on the intranet or in the annual report, but system and business owners were never briefed |
| Review how the mission was used in the most recent risk assessment | Assessment workpapers or meeting notes showing mission-based impact criteria | Impact scales are copied from a template and were not reviewed against the organization's own mission |
| Confirm the mission is reviewed when strategy changes | Dated revision history of the mission statement and the risk documents that depend on it | Mission was restated after a strategy change, but risk documents still reflect the earlier version |
| Test a sample of decisions for mission reference (illustrative) | Sample of accepted, mitigated or transferred risks with the rationale recorded | Decisions are recorded without any reference to the mission, so the link exists only in principle |
How to document the mission and connect it to risk decisions
This sequence turns a mission statement into a documented reference that leaders use when they decide which cybersecurity risks matter most. Each step produces a record that the next step relies on, so the final result can be traced back to the mission.
Confirm the current mission and service strategy statements
Leadership, usually the chief executive with the board or its designated committee, reviews the organization's mission statement, vision and any service strategies in writing. The team checks whether these documents still describe what the organization actually does today, and records the owner, approval date and location of each statement. The step is complete when there is one approved, dated version of each statement that the cybersecurity function can cite. Ask whether the statements were approved by the people who can change them, because a mission drafted for marketing often lacks the detail that risk decisions need.
Identify the services and outcomes the mission depends on
Working with business unit leaders, the team lists the services, products and outcomes that deliver the mission, such as claims processing for an insurer or patient scheduling for a hospital. For each one, it notes who depends on it and what failure would look like. The output is a short register of mission-critical services linked to the statements from the previous step. This register is the input to later work on critical services in GV.OC-04, so keep the wording business-focused and agreed with each owner.
Identify risks that could prevent mission outcomes
For each mission-critical service, the risk owner and cybersecurity staff identify the events that could stop or degrade it, such as ransomware on a core system, loss of a key cloud provider or compromise of customer data. They describe each risk in terms of the mission outcome it threatens rather than in technical terms alone. The output is a list of mission-linked risk statements, each tied to a named service and owner. The step is done when every mission-critical service has at least one associated risk statement, or a recorded reason why none applies.
Record how leadership uses the mission in decisions
The team documents the decision points where the mission is applied, such as risk appetite discussions, investment prioritization, acceptance of residual risk and the choice of recovery priorities. For each point, it names the decision-maker and the mission reference they use, and writes the rule or criteria in plain language. The output is a decision procedure or addendum to the risk management policy that states how mission criteria shape risk ratings. Confirm with leadership that the procedure reflects how decisions are actually made, not only how they are supposed to be made.
Link the mission record to the risk register
The cybersecurity risk register is updated so that each risk carries its mission-critical service, its linked mission statement and the decision criteria it was rated against. Staff check a sample of entries to confirm that the link can be followed from a risk back to the mission statement in both directions. The output is a register with mission traceability fields. Ask the risk tool or spreadsheet owner to confirm that these fields can be exported and retained, since assessors and auditors will ask to see this traceability.
Communicate the result to risk owners
The documented mission statements, the critical service register and the decision criteria are briefed to each risk owner and to the committee that oversees risk. The briefing explains which risks were rated highest because of their mission impact and why. The team records attendance, issues raised and any changes requested. The step is complete when each risk owner has acknowledged the criteria that apply to their risks, and the acknowledgments are filed with the risk management records.
Review the mission record on a set schedule
The team sets a review trigger for the mission record, such as a change in mission statement, a new service line, an acquisition or a significant incident. When a trigger occurs, the owners repeat the relevant steps and update the register and decision criteria. The output is a dated review log that shows what changed and who approved it. Confirm the review cadence with leadership, since NIST's guidance on this subcategory describes the outcome but does not set a fixed interval for each organization.
How the work differs for a small business, an enterprise and a regulated firm
A small business can meet the intent of GV.OC-01 with a short, written statement of what the organization exists to do and the services it delivers to customers. NIST's Small Business Quick-Start Guide (SP 1300) uses GV.OC-01 to help small business owners think about how a cyber incident could disrupt the mission, so the first deliverable is usually a plain list of what matters most to the business. There is rarely a need for a formal governance structure at this stage.
- One mission statement: A few sentences describing the purpose of the business and who it serves, dated and approved by the owner or manager.
- A service list: The products or services that generate revenue or that customers depend on, named in plain terms.
- Impact in plain words: A short note on what would hurt most if those services stopped, such as lost orders, missed deadlines or damaged customer trust.
- Review on change: Updating the statement when the business adds a service, changes a key supplier or enters a new market.
Confirm with your own advisers whether any customer contract or sector rule expects more than this. If it does, the work moves toward the regulated approach below.
An enterprise needs traceability from the mission, through business units and services, down to the cybersecurity risks that could block them. Each unit usually has its own objectives and its own view of what matters, so a single mission statement is not enough on its own. The work is to show how each service supports a stated objective and how the risk team uses that link when it ranks risks and funds controls.
- Mission to objective: A documented chain from the enterprise mission to each business unit's objectives, with an owner for each link.
- Service inventory tied to objectives: Each important service mapped to the objective it supports and the unit that runs it.
- Risk linkage: Entries in the risk register that reference the services and objectives they could affect.
- Consistent communication: The same mission language used in strategy documents, risk reports and board materials.
Ask how the enterprise risk function records these links and whether an assessor can trace a risk decision back to a stated objective.
A regulated firm starts from the same mission logic but must also show how that mission sits inside its legal, regulatory and contractual context. For GV.OC-01, the mission statement and service map are the foundation. The obligations that come from laws, regulators and contracts are handled under GV.OC-03, so this topic should cross-reference that work rather than repeat it. The regulator or auditor will usually ask how the two sets of documents agree.
- Mission statement reviewed against obligations: Confirmation that the stated mission does not conflict with licensed activities or regulatory duties.
- Critical services identified: The services that regulators or customers treat as important, linked to their objectives.
- Documented ownership: Named executives accountable for each mission-linked service and its risk.
- Cross-reference to GV.OC-03: A clear pointer to the register of legal, regulatory and contractual requirements.
Check with legal and compliance counsel which regulator, sector body or contract clauses require a specific form of mission or risk statement before drafting it.
Evidence that shows the mission informs cybersecurity risk
An assessor looking at GV.OC-01 wants to see a chain: the mission is written down, leaders use it when they weigh risk, and the people who own risks hear about it. The six artifacts below each cover one link in that chain. Keep them dated, versioned and linked to one another so the trail survives a review cycle.
Approved mission and vision statements
The mission and vision statements are the root of the evidence chain. Record the version, the approver, the approval date and the review date on the document itself. Check that the cybersecurity risk discussion in your governance documents refers to the same mission wording as the approved statement, not an older draft. If the organization has restructured, merged or entered a new market, confirm the statements still describe what the organization does before the next assessment. Store prior versions so an assessor can see when the wording changed.
Service strategy linked to the mission
A service or business strategy that names the services the mission depends on gives risk discussions something concrete to protect. The NIST Small Business Quick-Start Guide suggests this kind of link when it asks organizations to understand how cyber risks could disrupt their mission. Check that each strategic objective traces back to a mission statement and that the cybersecurity sections name the services at stake. Review the strategy whenever a major service launches, retires or changes hosting.
Risk register entries citing mission objectives
A risk register that records the mission objective each risk could affect shows the mission is applied, not just filed. For each entry, check for a field or reference naming the objective, the service it touches and the impact described in mission terms, such as a patient-facing service being unavailable. Illustrative example: a ransomware risk on a billing system might cite the objective of keeping invoices on schedule. Sample entries at each review cycle to confirm the link is real and not a template default.
Risk appetite statements tied to mission outcomes
Risk appetite statements state how much cybersecurity risk leaders will accept to pursue the mission. An assessor will test whether the wording refers to outcomes the mission cares about, such as service continuity or safe handling of client data, and whether it sets thresholds that someone can measure. Confirm who approved the statement, when it was last reviewed and whether it has been used in a real decision. A statement that no one can apply to a risk decision is weak evidence for GV.OC-01.
Minutes showing leadership reviewed risk against mission
Meeting minutes are the strongest evidence that leaders actually weigh risk against the mission. Look for a record where a named committee or executive reviewed specific risks and discussed their effect on mission objectives, along with the decision taken. Minutes that only list attendance or say that risk was noted do not show the link. Keep the agenda, the papers presented and the action log together so the review can be traced. Confirm the cadence is set in governance documents and that meetings occurred as scheduled.
Communication records to risk owners
Risk owners need to know which mission objectives their risks could affect, so they can choose responses that fit. Keep distribution records for mission statements, risk appetite and register extracts sent to owners, with dates and acknowledgements where your process uses them. Check that the communications reach the people who run the services named in the strategy, not only the central risk team. Review the distribution list each time roles change, because a stale list is a common gap in this evidence.
What meeting GV.OC-01 costs in money and effort
This table lists the cost components of documenting the mission and tying it to cybersecurity risk decisions, who is paid for each, whether it is one-time or recurring, and what moves it up or down. Use it to shape a written scope and to compare quotes on like-for-like terms. No prices or durations are given because none are supplied for this topic, so ask each provider to state its own.
| Cost component | Who is paid or who pays | One-time or recurring | What drives it up or down |
|---|---|---|---|
| Leadership and strategy time | Internal executives and board members, usually unpaid in direct fees but a real opportunity cost | One-time for the initial mission statement, recurring at each review | Number of business units with separate missions, and whether leaders already agree on priorities |
| Facilitation or consulting time | External facilitator or advisor, billed under the written scope | One-time for the workshop series, sometimes repeated after reorganizations | Age and clarity of existing mission documents, and how many sessions the scope names |
| Mission-to-risk mapping work | Internal risk or security staff, or an implementation partner preparing the record | One-time to build, recurring to keep current | Number of business services that depend on the mission, and the quality of the existing risk register |
| Evidence upkeep | Internal governance or GRC owner, plus any tooling licenses if a self-hosted GRC tool is used | Recurring, tied to each review cycle | How often mission or strategy changes, and whether the record is versioned and linked to decisions |
| External review | Independent reviewer or advisor, if the organization buys one | Recurring when used, often at annual or event-driven points | Scope of the review and whether the organization wants a second opinion before an audit |
| Auditor sampling | Independent auditor or certification body, under its own engagement terms | Recurring at each audit cycle | Number of mission statements and risk decisions sampled, and whether the trail from mission to decision is easy to follow |
How mission statements flow into risk registers and appetite
The point of GV.OC-01 for a working team is traceability: a reader should be able to follow a line from the mission statement to a risk register entry and then to a treatment decision. Start with the mission as written by leadership, then ask which services and business outcomes carry it out. Each service or outcome then yields dependent risks, such as a payment platform that must stay available for a hospital to bill patients or a case management system that must keep records intact for a public agency. Those dependent risks belong in the cybersecurity risk register with a named owner, a likelihood and impact rating, and a link back to the mission outcome they threaten. Without that link, the register lists technical findings that leadership cannot rank against what the organization exists to do.
Risk appetite and treatment decisions come next. Leaders should state how much disruption to a mission-critical service they will accept, expressed in terms the business understands, and the risk register should show which entries sit inside that tolerance and which need treatment. The risk response options, whether to reduce, accept, transfer or avoid, should be recorded against the mission outcome, so that a later decision to defer a fix can be judged against what it puts at stake. Review closes the loop: when the mission, a major service or a dependency changes, the chain must be walked again. Confirm with your own leadership how often this review happens and who signs it off, because the framework does not set a cadence.
GV.OC-01 does not stand alone. The same decisions also draw on GV.OC-02, which covers the expectations of stakeholders such as customers, regulators and staff, and on GV.OC-03, which covers the legal, regulatory and contractual requirements the organization must meet. A mission outcome may be fixed in a contract with a customer or a statutory duty, and that obligation can raise the priority of a risk that the mission statement alone would not. Practically, map each risk entry to all three sources at once, so that the risk appetite discussion reflects what the mission asks for, what stakeholders expect and what the organization is bound to deliver.
Who owns the mission, who prepares evidence and who assesses it
GV.OC-01 is a statement about leadership. The organization must understand its mission and use it to shape how it manages cybersecurity risk, and no outside party can make that judgment on its behalf. Executives and the board decide what the mission is in operational terms, which services and outcomes matter most, and how much disruption the organization can tolerate before it affects the mission. Those decisions then feed risk criteria, priorities and the Target Profile. The organization also keeps the records that show the link is real and current.
- Mission statement ownership: Leadership approves the mission and the services that deliver it, and reviews them when strategy changes.
- Risk decisions: Business owners tie cybersecurity risks to specific mission outcomes and decide what is acceptable.
- Communication: Staff receive the mission and the risks that could block it, in language they can act on.
- Records: The organization keeps minutes, approved strategy documents and risk registers that reference the mission.
- Accountability: A named executive owns the process and signs off on updates.
Before engaging any partner, confirm that your leadership can name the decisions the mission drives and who signs them off.
An implementation partner helps the organization prepare for GV.OC-01 but does not decide the mission or certify its use. Typical work includes facilitating workshops where leaders connect mission outcomes to cybersecurity risks, drafting traceability records that map mission statements to risk entries and Profile targets, and assembling the evidence an assessor will request. DeployOpen operates in this role for self-hosted open-source platforms in the client's own environment, and its deliverables are prepared for the organization to review and own.
- Workshop facilitation: Structured sessions that surface which services and dependencies the mission relies on.
- Traceability records: Documents linking the mission to risk register entries and Current and Target Profile items.
- Evidence assembly: Collected minutes, approved documents and tool outputs organized by subcategory.
- Gap notes: Written findings on where the mission link is missing or outdated.
- Handover: Materials the internal team can maintain after the engagement ends.
Ask the partner to state in writing which deliverables it prepares and which decisions remain with your staff.
Only an independent auditor, assessor or certification body can test GV.OC-01 and issue a report or attestation. NIST states that it does not offer certifications or endorsements of CSF-related products, implementations or services and has no plans for a conformity assessment program, so any claim of CSF certification should be treated with caution. An assessor independent of the implementation work samples decisions, reviews the evidence and forms an opinion. The assessor's independence is what gives the result weight with customers and regulators.
- Sampling: The assessor selects strategy documents, meeting records and risk entries to test whether the mission drives decisions.
- Interviews: Leaders are asked how the mission influenced a recent risk decision.
- Reporting: The assessor issues its own report, separate from any implementation deliverables.
- Independence: The firm that designed or prepared the evidence should not also be the one that tests it.
- Scope: The assessor's engagement letter defines what is tested and against which framework version.
Confirm with any assessor which report type it issues and whether it accepts evidence prepared by an implementation partner.
Organizations usually outsource the preparation work, such as facilitation, documentation and evidence collection, because it takes time that internal staff may not have. They keep the decisions. Independence draws the line at the point where an outside party would be judging its own work. An implementation partner can help write a mission-to-risk traceability record, but it should not attest that the record reflects how leadership actually decides. That attestation belongs to the organization in management representations and to the assessor in its report.
- Usually outsourced: Workshop preparation, document drafting, evidence indexing and gap analysis.
- Kept internal: Mission approval, risk appetite decisions and sign-off on the Target Profile.
- Assessor only: Testing conclusions, opinions and any issued report.
- Cost drivers: Scope size, number of business units and how much evidence already exists.
- Recurring work: Annual review of the mission link, which the organization should budget for internally.
When requesting a quote, ask which items are one-time and which recur, and who signs each deliverable.
Where organizations fall short on GV.OC-01 and how to close each gap
GV.OC-01 is easy to document and hard to evidence. The gaps below recur across programs that have a mission statement but cannot show how it shapes cybersecurity risk decisions. Each card names the gap, why an assessor or board member would notice it, and one action that closes it.
Mission statement reads as marketing copy
The mission is written for the website and never mentions what the organization must protect to deliver its services. GV.OC-01 expects the mission to be stated in a form that lets people identify risks that could get in its way. Check whether the mission names the services, customers or outcomes that depend on technology. Close the gap by rewriting the statement with the risk owners, then recording which services it protects in the risk management documentation.
No traceable link to the risk register
The mission exists in one document and the risk register lists threats in another, with no visible reason why one risk ranks above another. An assessor will look for a path from mission statement to the risks recorded and their priorities. Trace three or four mission-critical services to their entries in the register. Close the gap by adding a mission or service field to each risk entry so prioritization can be explained.
Mission not updated after strategy change
The organization has entered new markets, acquired a business or moved workloads to a new hosting model, but the mission and its risk framing still describe the old operation. This leaves risk decisions tied to services that no longer matter. Set a trigger for review, such as a board-approved strategy change or a major acquisition, and confirm the mission text reflects the current scope. Close the gap by recording the review date and the reason for each revision.
No evidence of leadership review
Leaders approve the mission once and never revisit how it informs cybersecurity risk. Without minutes, decisions or sign-offs, the mission cannot be shown to shape governance. Ask what evidence would convince an independent assessor that leaders considered the mission when setting risk priorities. Close the gap by adding mission and risk framing to a standing agenda item for the risk committee and keeping the minutes that show the discussion.
Mission not communicated to risk owners
Business owners of systems and data often do not know which mission objectives their systems support, so they rate risks without that context. The Implementation Example for GV.OC-01 focuses on communicating the mission so risks can be identified. Ask a sample of system owners to state the mission objective their service supports. Close the gap by including the mission objective in the onboarding material for risk owners and in the template used to record each risk.
Questions buyers ask about GV.OC-01 cost, effort and evidence
How much effort and cost does GV.OC-01 take to meet?
Effort depends mostly on how much mission material already exists and how many business units must agree on it. Cost is mainly staff time: executives reviewing the mission statement, strategy owners linking it to decisions, and the people who maintain the risk register updating it. The first documented version is largely one-time work, while annual review and updates after strategy changes recur. Tooling costs for GV.OC-01 itself are usually small, because the output is an approved document and its records. NIST's Implementation Example suggests communicating the mission through vision statements or service strategies so risks that could block it can be identified, and that wording sets the scope. Ask any quote to separate internal staff time, external facilitation and tooling licenses, and to state which costs are one-time and which recur.
Can we do GV.OC-01 in-house without an outside partner?
Yes. GV.OC-01 is an outcome the organization owns, so its leaders, risk function and strategy owners can complete it without an outside partner. The practical question is capacity and independence: whether the people who write the strategy can also check that risk decisions reflect it. An implementation partner such as DeployOpen can prepare systems, documentation and evidence inside the client's own cloud accounts, data centers or air-gapped networks, but the mission, the risk decisions and the sign-off remain the organization's. Outside help makes the most sense when the mission is spread across unclear documents, several subsidiaries need aligned statements, or the internal team lacks time. Ask any provider which deliverables it will produce and which ones the client must approve.
What does GV.OC-01 need from leadership?
Leadership must state the mission in terms that can be used to judge cybersecurity risk, and it must accept that risk decisions follow from it. In practice this means a named executive sponsor, approval of the mission and any service strategy by the accountable governing body, direction to risk owners to reference mission objectives in their assessments, and protected time for those owners. Leaders also decide which mission-critical services count as priorities, which later shapes work under GV.OC-04. Without that backing, the statement tends to stay in a policy library and never reaches a risk decision. Before the engagement starts, confirm who approves the statement, whether the board receives it, and how often leaders will revisit it.
How long does GV.OC-01 take to complete?
No duration figure is supplied for GV.OC-01, so treat any timeline as unverified until it is written into scope. Duration depends on the number of business units, the state of existing strategy documents, how many stakeholders must agree on the wording, and how quickly leaders can approve it. An organization with a current, approved mission statement and a risk register that already cites it has a shorter path than one that must rebuild its mission from several sources. Ask for milestones: an inventory of current documents, drafting, stakeholder review, approval and first use in a risk decision. DeployOpen's engagements are generally fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
Does NIST certify that we meet GV.OC-01?
No. NIST does not certify organizations, products or services against the Cybersecurity Framework, and it does not offer endorsements or a conformity assessment program. A claim that a company is NIST certified for GV.OC-01 should be questioned. What exists is self-assessment by the organization and, where a customer, regulator or contract requires it, an independent assessment by a party that the requesting body accepts. Those parties issue their own reports under their own rules, and their conclusions are not NIST certificates. Ask any provider to explain exactly what it delivers, and ask your customer or regulator which form of evidence they will accept.
What will an auditor or assessor ask for under GV.OC-01?
An independent assessor will look for proof that the mission exists, has been approved and actually shapes risk decisions, not only that a statement is published. Typical requests include the approved mission and any vision or service strategy, the approval date and approver, evidence that the statement was communicated to relevant staff, risk assessment or register entries that reference mission objectives, records of periodic review, and the method used to decide which services matter most. Assessors also check consistency with the other GV.OC subcategories. Only the assessor or certification body issues a conclusion. DeployOpen prepares the records and systems so this evidence is complete and easy to find, and the organization decides what is true about its own program.
How DeployOpen prepares GV.OC-01 evidence
This sequence turns a documented mission into scoped, traceable records that the organization owns and can present to its own assessors. DeployOpen prepares the material; independent auditors and the organization's leadership decide what it proves.
Agree the scope in writing
Before any work starts, DeployOpen and the organization agree in writing which business units, systems and documents fall within the GV.OC-01 work, who approves the mission statement and which deliverables will be produced. The scope names the people who must provide input, such as executive sponsors and service owners. The step closes when both parties have signed the scope document, which then sets the boundaries for every later step and for the quote.
Collect the current mission statements
The organization supplies its existing mission, vision, charter and service strategy documents, along with any board minutes that refer to them. DeployOpen reviews these to find where the mission is written, which version is current and where different documents disagree. The output is a dated source inventory listing each document, its owner and its approval status. Gaps are logged for the organization to resolve rather than filled by DeployOpen.
Map mission elements to services
DeployOpen works with service owners to list the services, products and business objectives that the mission depends on, then links each one to the operational processes and systems that deliver it. This mapping shows which parts of the organization would be affected if a cybersecurity event disrupted them. The output is a working traceability table that the organization's own staff review and correct before it is accepted.
Draft the risk-linked mission record
Using the traceability table, DeployOpen drafts a record that states how the mission frames cybersecurity risk decisions, consistent with the Implementation Example NIST publishes for GV.OC-01. The draft describes how mission-critical risks are identified and communicated to decision makers. Leadership approves or amends the wording, and the organization records the approval date and approver. The step is complete when the approved record is stored in the organization's own document repository.
Build the GV.OC-01 traceability matrix
DeployOpen builds a matrix that links the approved mission record to the GV.OC-01 Subcategory, the related ISO/IEC 27001:2022 clauses and the SP 800-53 Rev. 5.2.0 control PM-11 shown in NIST's Reference Tool, and to the organization's own policies and risk register entries. Each link names the artifact that proves it. The matrix is complete when every link points to a document the organization holds, so an assessor can follow it without needing explanations from the implementer.
Package evidence for organizational ownership
DeployOpen assembles the approved records, the source inventory, the traceability matrix and the scope document into a single evidence folder, with version numbers and a change log. The folder is handed over to the organization, which becomes its owner and controls who can edit it. The handover is confirmed in writing, and the organization stores a copy in the location its auditors can access.
Review with the independent assessor
The organization presents the evidence folder to its own internal reviewers and to any independent auditor or assessor it engages. DeployOpen may answer questions about how the materials were produced if the organization asks, but it does not issue audit reports, attestations or certifications. Only the independent assessor can state whether the evidence meets a given standard. The step ends when the organization records the assessor's findings and any corrections it must make.
