GV.PO-01 Cybersecurity policy established: requirements and evidence

What GV.PO-01 asks for and why a policy alone is not enough

A customer questionnaire, a contract clause or an internal audit asks whether a cybersecurity policy exists under NIST CSF 2.0 GV.PO-01, and the answer has to show more than a document in a shared drive. The Subcategory expects a policy for managing cybersecurity risk that is built from the organization's context, strategy and priorities, then communicated and enforced. The risk it addresses is simple: without a written statement of management intent, security decisions get made inconsistently by different teams, and nobody can show what was expected or who agreed to it. Under CSF 2.0, the Govern Function was added to the framework, and GV.PO-01 absorbs part or all of CSF 1.1 ID.GV-1, so organizations that already claimed the older outcome should check whether their existing policy language still matches the new wording.

The hard part is usually not drafting. Teams often write a policy from a template, get it approved once, and stop there. The communication and acknowledgment parts fail quietly: the policy is posted but not pushed to new hires, contractors are missed, and nobody records who read the current version after the last change. NIST's implementation examples for this Subcategory expect personnel to acknowledge the policy at hire, annually and after updates, so the reader should confirm which population (employees, contractors, outsourced administrators) the acknowledgment process covers and where the signed records are kept. Practical checks include pulling a sample of recent joiners and confirming each has an acknowledgment for the current version.

A policy alone also will not satisfy an assessor who asks how the policy is enforced. Assessors look for the link between the policy statements and the operational controls that carry them out, along with evidence of senior management approval and of the review cycle that GV.PO-02 covers. Organizations that host their own wiki or document platform can keep version history, approval records and acknowledgment logs in one system, which makes the trail easier to produce. Confirm with your platform team whether the chosen tool records authorship and change history, and whether that history can be exported for an auditor. For a structured outline of what the policy needs to cover, the NIST Cybersecurity Framework 2.0 publication is the primary reference.

Which policies, people and third parties does GV.PO-01 cover

GV.PO-01 asks for one cybersecurity risk management policy, but the policy only works if its boundaries are set deliberately. The decisions below determine who must read it, which systems it governs and how the evidence is collected, so settle them before drafting.

Business units and systems in scope

Decide whether the policy governs the whole organization or named business units, and which systems, cloud accounts and data centers fall under it. Write the scope statement so an assessor can match it against your asset inventory (ID.AM). Ambiguous scope is the most common reason a policy cannot be shown to apply to the systems that matter. Check that every system in the scope statement has an owner who has received the policy.

Contractors and suppliers acknowledgment

Decide whether contractors, temporary staff and key suppliers must acknowledge the policy, or only agree to its requirements in their contracts. Acknowledgment by contractors gives you direct evidence, while contract clauses give you enforceable terms. Many organizations use both, with the policy referenced in the contract. Confirm with legal how acknowledgments are collected and stored for people who are not employees.

Languages and accessible formats

Decide which languages the policy and its acknowledgment must be issued in, and whether summaries or accessible formats are needed for staff who cannot read the full document. A policy that staff cannot understand does not communicate management intent, which is the point of the outcome. Record which version each employee received and in which language, so the acknowledgment can be defended later.

Subsidiaries and shared services

Decide whether subsidiaries adopt the group policy directly, adopt it with local annexes, or keep their own policies that map to it. Shared services such as a central IT team serving several legal entities need a clear statement of which entity owns each control. Document these decisions in the scope statement and the RACI, so an assessor does not have to infer ownership from organization charts.

Acknowledgment timing and records

Decide when acknowledgments are required: at hire, after each material update and on a recurring cycle. NIST's implementation examples describe acknowledgment at hire, annually and after updates. Choose a system that records who acknowledged which version and when, and that can flag people who have not responded. Confirm the retention period for these records with your auditor and legal team before you set it.

How an assessor tests the cybersecurity policy

This table walks through the four checks an assessor typically performs on GV.PO-01, with the evidence each check needs and the gaps that come up most often. Read it as a checklist for your own pre-assessment review, since the assessor's sampling and conclusions come from their own engagement with your records.

Assessment step	What the assessor looks for	Common finding
Review the policy text	A written policy that reflects the organization's mission, risk context, legal duties and strategic priorities, and states management intent in understandable language	Generic template text that names no business drivers or risk priorities
Check ownership and scope	A named owner, a stated scope covering relevant systems and personnel, and a defined review cycle	A policy that names no owner or leaves its scope undefined
Check senior management approval	Records showing that senior leaders reviewed and approved the current version, with the approver's name and a date	Approvals without dates, or approvals that cannot be matched to the version in use
Sample distribution and communication	Evidence the policy reached the people it governs, such as publication locations, notices and access to the current version	The policy sits in a shared drive that most staff cannot find
Sample staff acknowledgments	Signed or recorded acknowledgments from a sample of staff, checked against hire dates, annual cycles and the most recent update	Acknowledgments missing for new hires or for staff who joined before the latest revision
Test enforcement	Evidence that the policy drives practice, such as exceptions tracked against it, linked standards and procedures, and policy-driven decisions in the records	A policy that no procedure, control or exception process refers back to
Confirm version history	A traceable record of what changed, when and who approved it, so the assessor can tie each control test to the right version	Edits made without a recorded approval or change log

How to establish the policy from organizational context

This sequence turns the organization's mission, obligations and risk decisions into a written cybersecurity risk management policy that leadership has approved, staff have been told about, and personnel have acknowledged. Each step produces a record an assessor can check against GV.PO-01.

Collect organizational context from GV.OC
Gather the inputs the policy must reflect: the mission, critical services, stakeholder expectations, dependencies on suppliers, and the legal, regulatory and contractual requirements that apply. The cybersecurity risk owner, usually with legal and compliance, compiles this into a single context document. The step is done when each requirement the policy must address has a named source, such as a statute, a customer contract or an internal business objective.
Align the policy with risk strategy from GV.RM
Take the risk objectives, risk appetite and tolerance, and the standard risk method already defined under GV.RM and check that the policy uses the same language and thresholds. Where those decisions do not yet exist, record that gap rather than writing risk tolerances into the policy by default. The output is a short mapping from each strategic priority to the policy statement that will carry it.
Draft a policy stating management intent
Write the policy in plain language so it states management's intent and direction for managing cybersecurity risk, the scope of systems and people it covers, and the roles that carry it out. Keep operational detail in supporting standards and procedures so the policy stays readable and stable. The output is a draft that a reviewer outside the security team can understand in a single reading.
Obtain senior management approval
Send the draft to the executive or board body that owns cybersecurity risk, and record the approval with the name of the approver, the date and the version number. Confirm with the approver which decisions they are accepting, such as the scope and the stated direction. The output is a signed approval record stored alongside the policy, which is the evidence most assessors ask for first.
Communicate the policy across the organization
Publish the approved policy where staff, contractors and relevant third parties can find it, and brief the teams whose work it changes most. Tell readers what the policy requires of them and where to raise questions. The output is a published, version-controlled copy and a record of the audiences it was sent to.
Collect acknowledgments at hire and after updates
Ask every person in scope to acknowledge the policy when they join, again on the cycle the organization sets, and after each material update. NIST's Implementation Examples describe acknowledgment at hire, annually and after updates, so confirm the exact cycle with your assessor before you adopt it. The output is an acknowledgment register that shows who acknowledged which version and when, with gaps followed up.
Link the policy to enforcement
Connect each policy statement to the procedures, technical controls and consequences that make it enforceable, such as access rules, disciplinary processes and supplier contract clauses. Record which control implements which statement so violations can be investigated against a clear rule. The output is a traceability table from policy statements to implementing controls and the process for handling breaches.

How version control and access roles keep the policy evidence intact

A documentation platform can keep the history of the cybersecurity risk management policy trustworthy, which is useful evidence for GV.PO-01, but it cannot create that evidence on its own. Under GV.PO-01 the organization must base the policy on its context and strategy, obtain senior management approval, communicate it and collect staff acknowledgments. XWiki, an LGPL-2.1-or-later wiki, keeps every change to a page under version control, recording what changed, when and by whom, and lets users compare any two versions and roll back to an earlier one. Those records show an assessor how the policy evolved and which text was in force on a given date. They do not show that a named executive approved a version. Keep the approval record (a signed memo, board minute or ticket) and link it to the version it covers.

Access roles determine who can publish or change the policy, and this is where evidence integrity is most often lost. In BookStack, an MIT-licensed platform, user abilities come from the roles assigned to each user, and permissions can be overridden per role at the shelf, book, chapter or page level. A practical design gives the policy book a restricted edit permission, limits publishing to the owner of the policy, and leaves staff with view access only, so that an unapproved draft cannot quietly replace the approved text. Confirm the current role and permission model with BookStack's documentation before you rely on it, and test the setup by attempting an edit with a non-approver account. Confirm the same for XWiki's rights model and its current version history features with the vendor, since capabilities differ between releases and editions.

The practical check is to walk one policy version from draft to acknowledgment and confirm that the platform record and the governance record match. Record which version each staff member acknowledged, keep those acknowledgments outside the wiki if your audit process requires it, and set a schedule for re-acknowledgment after updates, which NIST's Implementation Examples for GV.PO-01 point to. Platform setup, role design and evidence export are implementation work that a partner can prepare under a written scope, but the organization owns the policy content and its enforcement. An independent auditor will decide whether the evidence is sufficient.

Evidence that passes a GV.PO-01 review

GV.PO-01 asks whether a cybersecurity risk management policy exists, reflects the organization's context and strategy, is approved, communicated and enforced. The six artifacts below show that chain from start to finish. Each one must stay current between assessments, so the owner of each record should be named and the update trigger written down.

Approved policy with version history

The policy document itself, written in plain language and stating management's intent and direction for cybersecurity risk. Keep every revision with its date, author and summary of changes, so an assessor can see what changed and when. Store it in a wiki or document system that records version history and allows comparison between versions, such as XWiki. Check that the version in circulation matches the approved version. Review the document on a fixed cycle and after material changes to the business or threat environment.

Senior management approval record

A dated record showing that a named senior leader or governing body approved the policy, along with the version approved. Meeting minutes, a signed approval page or a board resolution all work, provided they reference the exact document version. Without this link, an assessor cannot tell whether leadership approved the text now in use. Confirm with your auditor which approver forms are acceptable under your own governance rules.

Communication record across the organization

Evidence that the policy reached the people it governs: distribution lists, intranet publication dates, announcement messages and briefings for managers and business units. Record the audience for each communication, not only the channel. Assessors commonly ask whether contractors and third-party staff who handle organizational systems received the policy or the parts that apply to them.

Staff acknowledgment logs with dates

Per-person records showing that each employee acknowledged the current policy at hire, on an annual cycle and after each update, as the Implementation Examples describe. Export the log with names, dates and policy version, then reconcile it against the HR roster. Missing acknowledgments for recent joiners and for the latest version are the most common gaps. Automate reminders and escalate overdue records to managers.

Enforcement and exception process

A documented procedure for how policy breaches are detected, reported and handled, and how time-limited exceptions are requested, approved, recorded and retired. Keep the exception register with owner, justification, compensating measure and expiry date. Assessors look for exceptions that never expire, which signals that the policy is not enforced in practice. Review open exceptions at each policy review.

Link to organizational context

A traceable connection between the policy and the inputs that justify it: the mission, legal and contractual obligations, risk appetite and the stakeholder expectations that shape cybersecurity decisions. A short mapping table from each policy section to its source in the organizational context is usually enough. Update the mapping when a new regulation, customer requirement or strategic change arrives, because a policy that no longer reflects the context will not pass a careful review.

What meeting GV.PO-01 costs in money and effort

This table breaks the GV.PO-01 policy work into cost components, showing who does the work, whether the cost is one-time or recurring, and what moves it up or down. No figures are supplied for these components, so use the right-hand column to build a quote request. The main takeaway is that most of the cost is internal time, and that tooling is only one line item.

Cost component	One-time or recurring	What drives it up or down
Policy drafting time	One-time, then revised	Size of the organization, number of regulations it must reflect, and whether an existing policy set can be reused. Ask who drafts and how many review cycles are included.
Senior management review and approval	One-time, then at each revision	Number of executives and board members who must sign off, and whether approval is tied to a scheduled committee. Ask how approval evidence will be recorded.
Tooling and license spend	Recurring if commercial, minimal if self-hosted open source	Choice between commercial policy management software and self-hosted open-source wikis or document systems. Self-hosted options can remove license fees but add hosting and administration time. Confirm hosting, backup and upgrade responsibilities in writing.
Communication and acknowledgment administration	Recurring at hire, annually and after each update	Headcount, contractor turnover and number of locations. Automated acknowledgment workflows reduce manual chasing. Ask how acknowledgments are captured, stored and reported.
Annual review effort	Recurring	Frequency of change in law, threats and business strategy, and the scope of the policy. Ask what the review includes and who signs off on the result.
External review or assessor sampling	Recurring at each assessment cycle	Assessor sampling approach and how well-organized the evidence is. Ask the auditor which policy versions and acknowledgments they will sample, and ask the implementation partner what preparation is included.
Implementation partner preparation (illustrative)	One-time scope, optional retainer	Scope of drafting, customization and evidence setup. Work is fixed-scope and quoted from a written scope, so ask for deliverables, exclusions and timelines before work starts.

Which self-hosted tools can hold GV.PO-01 evidence

XWiki is a self-hosted wiki platform released under the LGPL-2.1-or-later license. Its strongest fit for GV.PO-01 is version control of the policy page itself. According to XWiki's own description of its document versioning, every change to a page is kept under version control, recording what changed, when and by whom, so you can compare any two versions and roll back to an earlier one. That record supports an assessor who asks what the policy said on a given date and who changed it.

Change history: Each revision keeps the author, timestamp and content difference, which gives you a dated record of policy edits.
Version comparison: Reviewers can compare the current approved text with any earlier version during periodic review.
Rollback: Erroneous edits can be reverted, with the rollback itself recorded.
Licensing: The LGPL-2.1-or-later license permits use and modification, but your legal team should review its terms for any distribution or embedding you plan.
Limitation: Version history does not record senior management approval or staff acknowledgments. Those need a separate, dated process.

Before relying on this, confirm with your deployed release how page history, approval workflows and access logs are retained and exported.

Where GV.PO-01 policies usually fall short

A cybersecurity policy that exists on paper rarely satisfies GV.PO-01 on its own. The gaps below recur across programs, and each one leaves an assessor without the evidence that the policy is approved, understood, current and enforced. Check each item against your own records before an assessment begins.

Generic policy, disconnected from risk

The policy repeats industry boilerplate and does not reflect the organization's mission, regulatory duties, risk appetite or priorities. GV.PO-01 expects the policy to be based on organizational context and strategy. Check that each policy statement traces to a documented risk decision, a legal or contractual duty, or a named owner. Statements that trace to nothing are candidates for removal or rewriting.

Missing senior management approval

A policy drafted by the security team and posted to the intranet has no recorded endorsement from leadership. The implementation examples for GV.PO-01 call for senior management approval, so the absence of a dated sign-off is an immediate evidence gap. Confirm which role approves the policy, record the approval date and version, and keep the signed or recorded decision with the policy file.

No acknowledgment after updates

Staff sign the policy at hire, then never again, even after material changes. GV.PO-01 implementation examples expect personnel to acknowledge the policy at hire, annually and after updates. Check whether your records show who acknowledged which version and when. Set a trigger so that every revision starts a new acknowledgment cycle for the affected population.

Contractor acknowledgments not tracked

Employees are tracked in the HR system, but contractors, temporary staff and managed service personnel who access systems often sign nothing or sign a form that is filed separately. Their access is still governed by the policy. Confirm that contract terms require acknowledgment, that the sponsoring manager owns the record, and that offboarding removes access and closes the record.

Policy stored in uncontrolled copies

Several versions circulate as Word files, PDF attachments and wiki pages, and nobody can say which one is current. An assessor will ask for the authoritative version and its history. Keep one controlled repository with version history, recorded authorship and a documented approver. Use a self-hosted wiki or document platform with version control and role-based permissions, and withdraw superseded copies from circulation.

No evidence of enforcement

The policy states rules, but the organization cannot show that anyone checks compliance or acts on violations. GV.PO-01 covers enforcement as well as creation and communication. Define which controls and tickets demonstrate enforcement, such as access reviews, exception approvals or disciplinary records, and keep samples of them. Confirm with your own assessor which evidence they expect for your environment.

Questions buyers ask about GV.PO-01 cost, effort and readiness

How much effort does a first cybersecurity policy take?

The effort depends less on writing the document than on the decisions behind it. A first policy needs the organization to agree its mission, its regulatory and contractual obligations, its risk appetite and the systems in scope, and those inputs often sit with different owners. The drafting itself is usually the smallest share. Effort rises when the organization has no current asset inventory, no documented risk method, or several business units with separate rules. Ask any partner to break its estimate into discovery, drafting, review cycles, approval and rollout, so you can see which step your own environment makes heavy.

Can we write our cybersecurity policy in-house?

Yes, many organizations do, provided someone with security and governance knowledge owns the draft and the business leaders supply their context. GV.PO-01 asks for a policy that is understandable, reflects management intent and is built from organizational context and strategy, so the people who know the business must contribute. In-house teams often struggle with three things: aligning the policy with existing standards they already hold, keeping it short enough to read, and running the approval and acknowledgment cycle. An outside implementation partner can help with structure and wording, but the organization owns the policy and its approval.

What does GV.PO-01 need from senior leadership?

Senior management must review and formally approve the policy, which makes it an expectation set by leadership rather than an IT document. In practice this means a named executive sponsor, time in the approval meeting, and a decision on who is accountable for enforcement. Leaders also need to confirm the risk direction the policy states, because the policy should reflect management's intent. Without that sponsorship, the policy often stalls in drafts or becomes a document no one enforces. Record the approval date and approver, since those details become evidence later.

Does NIST certify that our organization complies with CSF 2.0?

No. NIST states that it does not offer certifications or endorsements of CSF-related products, implementations or services, and it has no plans for a conformity assessment program. The CSF is voluntary for most organizations, though some customers or suppliers require it contractually. Any organization offering a CSF certificate is not issuing a NIST certification. If a customer asks for proof of GV.PO-01, provide the approved policy, its approval record, the review history and the acknowledgment records, and let the customer or an independent assessor judge them.

How do we track staff acknowledgment of the policy?

Track acknowledgments as a register that links each person to the policy version they accepted and the date they did so. NIST's Implementation Examples for GV.PO-01 describe acknowledgment at hire, annually and after updates, so the register needs to capture all three triggers. A practical setup includes:

A version identifier and approval date on the policy itself.
An onboarding step that records acceptance before access is granted.
A reminder cycle and a report of people who have not acknowledged the current version.

Where a self-hosted wiki or knowledge base holds the policy, its version history can show which revision was current at each date. Confirm the audit trail and permission settings in the specific platform you choose before relying on them.

What should we ask an implementation partner for in a fixed-scope quote?

Ask for a written scope that names the deliverables, the systems and business units covered, and what the partner needs from your staff. A useful quote states the policy and standards to be produced, the number of review rounds, the approval and communication steps, the acknowledgment tooling to be configured, and the evidence pack handed over. Also ask what is excluded, such as legal review, translation or assessor fees, and who pays for them. Confirm who owns the final document and who signs it. DeployOpen works on fixed-scope engagements that are agreed in writing before work starts, and it does not issue audit reports or certifications, so ask any partner to state the same boundary.

What recurs after the first policy is approved?

The one-time cost is the initial policy, approval and rollout. The recurring work is review, acknowledgment of updates and the evidence that goes with them. Recurring effort grows when the business changes quickly, when new regulations apply, or when the organization adopts new technology such as AI tools, because those changes can trigger policy updates. Ask a partner whether ongoing review and support sit under a separate retainer, and what triggers a paid update. Retainers for ongoing support, upgrades and continuous testing are available from DeployOpen, and their scope should be agreed in writing like any other engagement.

How DeployOpen prepares GV.PO-01 evidence in your environment

DeployOpen works inside your own infrastructure to prepare the systems, documents and records that show a cybersecurity risk management policy exists, was approved, was communicated and was acknowledged by staff. DeployOpen prepares this evidence for your assessment, but your organization owns the policy and the controls, and only an independent auditor or assessor issues any report or certificate.

How we scope

Engagements are fixed-scope, with the policy documents, approval records and acknowledgment process agreed in writing before work starts.
The written scope names which policy documents, versions and business units are in scope for GV.PO-01 Cybersecurity policy established.
Scope also records which evidence owners in your organization approve the policy and track staff acknowledgments.

How we build

We set up a version-controlled place for the policy so each revision records what changed, when and by whom.
We configure role-based permissions so policy owners edit and senior management approves, with the approval step recorded.
We help draft a readable policy that states management intent, direction and roles, mapped to your organizational context.

How we hand over

You receive the policy, its revision history, approval records and the communication and acknowledgment procedure as documented deliverables.
Handover covers a walkthrough of how to pull evidence for an assessor, including versions and staff acknowledgment records.
We document what remains your responsibility, including senior management approval and the periodic review schedule.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer if your policy evidence needs regular maintenance.
Retainers can cover updates to the policy after changes in law, technology or the business, with the change history kept current.
Confirm with your assessor which evidence format and retention period they expect before the handover is signed off.