12.1 Information security policy: requirements and evidence

What PCI DSS 12.1 asks for and why assessors check the policy first

PCI DSS 12.1 information security policy requires your organization to have a written security policy that is published, shared with the people who need it, reviewed at least every 12 months, and backed by named security roles and an executive who owns it. If you are a compliance lead or engineer preparing for an assessment, the policy is usually the first document an assessor opens, because it shows whether the rest of the program has an owner and a direction. The four sub-requirements ask for the following: an overall policy that is established, published, maintained and disseminated to personnel, vendors and business partners (12.1.1); a review at least every 12 months with updates as needed (12.1.2); security roles and responsibilities defined for all personnel (12.1.3); and responsibility assigned to a CISO or other knowledgeable executive (12.1.4). The underlying risk is simple. Without a policy that people have read and that someone is accountable for, controls in other requirements drift, get configured differently by each team, and nobody notices until a breach or a failed assessment.

The policy is often the easiest requirement to draft and the hardest to keep current. A reasonable policy can be written in a few weeks by a small team, but 12.1.2 turns it into a recurring obligation, and the document goes stale when the cardholder data environment changes, new third parties are added, or the organization reorganizes. Your organization owns this policy. It must reflect your actual environment, be approved by the executive named under 12.1.4, and be kept current by people inside the business. DeployOpen can help prepare the policy structure, a document register, and the review workflow, but the content decisions and approvals stay with your team. An assessor will test the policy by examining the document and interviewing the responsible personnel, and only the assessor's report, on the official PCI SSC templates, validates whether the requirement is met. Confirm with your assessor or acquirer which version of the policy evidence they expect and how they want review dates and approvals shown.

Who the PCI DSS 12.1 policy must reach and what it must cover

Requirement 12.1 is short, but four decisions shape how much work the policy represents: who receives it, what it covers, who owns it, and how it fits with the other policies PCI DSS expects. Settle these before drafting, because each one determines what an assessor will sample during interviews and document review.

Distribution audience

The policy must reach all personnel, and it must also be disseminated to vendors and business partners. Build an explicit list of recipient groups, including contractors, managed service staff and key suppliers with access to the environment. Confirm how each group receives the policy, how acknowledgment is recorded, and who keeps the distribution record current when people join, leave or change roles.

Policy scope statement

Decide whether the policy governs the whole organization or only the cardholder data environment and the systems connected to it. Many assessors expect the statement to cover the entire entity, with the CDE as the place where the strictest controls apply. Write the scope in one paragraph so that a reviewer can tell at once which systems, facilities and people the policy binds.

Accountable executive

Requirement 12.1.4 assigns overall responsibility to a CISO or other knowledgeable executive. Name a specific role holder in the policy, confirm that the person has the authority to fund and enforce controls, and check that the name matches the organizational chart and any board or committee minutes. A title without a named person or a documented mandate is a common finding.

Role definitions for all personnel

Requirement 12.1.3 expects security roles and responsibilities to be defined for all personnel, not only the security team. Map duties for engineers, customer support, finance staff and executives who touch payment flows. Assessors commonly test this by comparing the policy's role section with job descriptions and by interviewing staff from different functions.

Links to other PCI DSS policies

The information security policy sits above the more specific policies that PCI DSS expects, such as acceptable use, awareness and incident response. Map which requirement each subordinate document serves and confirm that none contradicts the top-level policy. A short cross-reference table makes this easy to show during an assessment.

Governance of policy changes

Requirement 12.1.2 requires review at least every 12 months and updates as needed. Decide who approves changes, how revisions are versioned, and which events trigger an out-of-cycle update, such as a new payment channel or a change in service providers. Keep the approval history with the policy so the assessor can see that the review actually happened.

What a PCI DSS information security policy has to contain

Requirement 12.1 asks for one overarching information security policy that the organization writes, approves, publishes and keeps current. Four sub-requirements shape it. The policy must exist and reach everyone who needs it, including personnel, vendors and business partners. It must be reviewed at least every 12 months and updated whenever the environment or risk changes. It must define security roles and responsibilities for all personnel, not only the security team. And it must assign overall responsibility to a CISO or another knowledgeable executive. An assessor will read the policy itself and interview the people named in it, so a document that sounds right but nobody can explain is a finding. Confirm with your QSA which vendors and partners they expect to receive the policy, and keep proof of distribution for each group.

The policy is the top-level document. It sets the commitments, the scope of the cardholder data environment, the owner and the review cycle, and it points to supporting standards that carry the detail. Do not fold acceptable use rules into it. Requirement 12.2 covers acceptable use policies for end-user technologies such as remote access, wireless, laptops, email and removable media, and it has its own approval and product list expectations. Do not treat it as the program either. Requirement 12.4 makes PCI DSS compliance a managed program with executive accountability and recurring reviews of whether personnel are performing their security tasks. Keeping the three separate means each has a clear owner, a clear review date and its own evidence trail.

Decide early who owns the policy and who has overall responsibility, and record both in the document. Then build a review calendar that names the reviewer, the approver and the date of the last change. Version control matters here: a wiki or document system that records what changed, when and by whom makes the 12-month review easier to prove. The XWiki blog on document version control describes how page history and rollback work in one open-source option. Whatever tool you use, confirm that it keeps prior approved versions available to the assessor and that roles restrict who can edit the approved text.

How an assessor tests the PCI DSS 12.1 policy

This table compares what an assessor examines, which evidence to prepare and the findings that commonly appear for each element of Requirement 12.1. The SSC's expected testing combines a review of the written policy with interviews of the people responsible for it, so each row pairs a document with the people who must be able to explain it. Read it as a pre-assessment checklist: a finding usually means the document exists but the surrounding record does not.

Element	Evidence the assessor requests	Common findings
Policy document	The current information security policy, its version history and the approval record, examined against the 12.1.1 elements	Policy covers only the security team, or it is a draft that was never formally approved by management
Review record	Evidence of a review at least every 12 months, such as dated revision history, review minutes or sign-off, and records of updates made after changes to the environment	No review date on the document, or the last review is older than 12 months
Role assignments	Written roles and responsibilities for all personnel, such as a RACI or role matrix, and interview answers from staff who hold those roles	Roles named only for the security team, with no defined responsibilities for system owners, developers or operations staff
Executive assignment	Documented assignment of overall responsibility to a CISO or other knowledgeable executive, and interview confirmation from that person	Responsibility sits with a committee or an unnamed manager, or the assigned executive cannot describe the program
Dissemination and acknowledgment	Distribution records for personnel, vendors and business partners, and how the policy is made available to them, such as intranet publication or signed acknowledgments	Policy is stored on a shared drive with no distribution record, and vendors and business partners never receive it

Implementing the PCI DSS 12.1 policy in sequence

This sequence turns Requirement 12.1 into a policy that is approved by the right executive, assigned to named owners, distributed to everyone it covers, acknowledged, and scheduled for review. Each step produces a artifact an assessor can examine and an interview can confirm.

Define the scope of the policy
The organization decides which environments, business units, personnel, vendors and business partners the policy governs, using the current description of the cardholder data environment and the list of connected systems. The organization owns this step because only it knows where cardholder data flows and who touches it. The output is a short scope statement that names the populations 12.1.1 requires the policy to reach, including third parties. The step is complete when the scope statement matches the most recent data-flow and system inventory.
Draft the overall information security policy
The security function writes the overall policy so it covers the security objectives, principles and responsibilities the organization expects personnel to follow. An implementation partner can prepare the draft, map it to the requirement and organize the document, but the organization must supply the business context and confirm every statement reflects how it operates. The output is a draft document with a version number, owner and change history. It is complete when the draft has been checked against each sub-requirement of 12.1 and no statement describes a control the organization does not run.
Obtain executive approval and assign overall responsibility
A CISO or other knowledgeable executive reviews the draft, approves it and is named as the person with overall responsibility for information security, as 12.1.4 requires. The organization owns this step, and the approval must come from someone with authority to fund and enforce the policy. The output is an approved policy version with the approver's name, title and approval date recorded in the document. It is complete when the approval record is stored where the assessor can retrieve it.
Define security roles and responsibilities for all personnel
The organization builds a role matrix that states who is accountable for each security duty, from executives and system administrators to customer support staff and developers. Requirement 12.1.3 expects roles for all personnel, so the matrix must cover ordinary staff, not only the security team. An implementation partner can draft the matrix from the scope and interview notes, while managers confirm each assignment. The output is a role matrix attached to the policy, with a named owner for each duty. It is complete when every role in the HR directory maps to at least one stated responsibility or to the general duties in the policy.
Publish the policy in a controlled repository
The approved policy is placed in a managed location with access controls, a clear title and a visible version identifier, and the previous version is archived. Publication makes the policy available to people who need it, so the repository must be reachable by every role in the matrix. An internal wiki with version history, such as XWiki, or a documentation platform with role-based permissions, such as BookStack, can hold the document, but the organization decides which tool fits its environment. The output is a live policy page with a retained revision history. It is complete when a test user from each audience can open the policy and an administrator can show earlier versions.
Disseminate the policy to personnel, vendors and partners
The organization sends the policy to the audiences 12.1.1 names, which include personnel, vendors and business partners, and records who received it and when. Vendors and partners often need a separate channel, such as a contract addendum or a security requirements page, so the distribution list should identify each external party and the copy it received. The output is a distribution list with dates and the channel used for each audience. It is complete when the list reconciles with the current personnel roster and the third-party register.
Collect acknowledgments from personnel
Each person in the distribution list confirms that they have read and understood the policy and their responsibilities under it. The organization owns the acknowledgment process and decides how it is captured, whether through a signed form, a training system or an attestation in an identity platform. Acknowledgments give the assessor evidence that dissemination reached individuals and not only a repository. The output is a dated acknowledgment record for each person, with exceptions followed up. It is complete when the record covers every person in scope and open exceptions have an owner.
Schedule the first review and record it
The organization sets a review date no later than 12 months after approval, and adds it to the compliance calendar with a named owner who will reopen the policy, update it for changes in scope or technology, and submit it for approval again. Requirement 12.1.2 requires review at least every 12 months, so the calendar entry is the evidence that the cycle is managed. The output is a calendar entry, a review checklist and a change log that link each revision to its approval. It is complete when the owner confirms the entry is active and the review will run through the same approval steps.

Evidence that passes a PCI DSS 12.1 review

A 12.1 review comes down to whether the policy exists in a controlled form, reflects current practice, and is known to the people it governs. The cards below cover the artifacts an assessor typically examines and the checks that show each one holds up under interview.

Approved policy with version history

The information security policy itself, with a document identifier, an owner, an effective date and a record of every revision. Assessors look for a single authoritative copy rather than drafts in several folders. Check that the version in circulation matches the latest approved version and that earlier versions remain retrievable. XWiki keeps every page change under version control, recording what changed, when and by whom, and lets users compare versions and roll back. Confirm whether your wiki or document system offers the same before relying on it.

Review and approval record

Evidence that the policy was reviewed at least every 12 months and updated as needed, with the reviewer, the approver and the date of each decision. Keep the approval tied to the policy version it covers, so the assessor can see that the reviewed text is the text in force. Minutes, sign-off records or workflow approvals all work if they name who decided and when. A review that changed nothing still needs a dated record.

Role and responsibility matrix

A table showing which security roles and responsibilities the policy assigns to each function, and how those roles extend to all personnel who handle the cardholder data environment. Assessors test whether the matrix matches what staff actually do. Reconcile it against job descriptions, on-call rotations and access approval lists. Gaps usually appear where responsibilities were assigned to a team that no longer exists or to a person who has left.

Executive assignment for security

A documented statement that overall responsibility for information security sits with a named CISO or other knowledgeable executive, with the reporting line and the scope of authority. Assessors check that the named person is aware of the assignment and can describe the program in interview. Confirm that the assignment appears in the policy, in governance minutes or in an appointment letter, and that it is current after any leadership change.

Dissemination and acknowledgment records

Proof that the policy reached personnel, vendors and business partners who need it, along with acknowledgments from those people. Keep distribution lists, publication logs and signed or electronically recorded acknowledgments, dated and linked to the policy version. Vendors and business partners often fall outside internal training systems, so check that their distribution is recorded separately. Acknowledgments are most useful when they show the version the person accepted.

Access controls and change log

The policy repository must restrict who can edit or approve the policy and keep a trail of changes. BookStack assigns user abilities through roles and lets permissions be overridden per role at the shelf, book, chapter or page level, which can separate editors from approvers. Export the access settings and the change history for the assessor. CISO Assistant can record framework assessments and track policy evidence against PCI DSS, but confirm which tool fits your environment before standardizing on one.

Who does what for the PCI DSS 12.1 policy

Your organization owns the information security policy under Requirement 12.1. Leadership must approve it, a named CISO or other knowledgeable executive must be accountable for it (12.1.4), and the business must keep it current and in use. The policy only counts if people in the organization can show that they know it, follow it and have been told about changes.

Ownership and approval: An executive sponsor approves the policy and its revisions, and the approval record is kept with the document.
Accountability: The CISO or other knowledgeable executive is named in the policy and in internal role documents.
Roles for all personnel: Your team defines who does what for security, including people outside the security function.
Annual review: Someone is responsible for the review at least every 12 months and for updates when the environment changes.
Dissemination: Your team distributes the policy to personnel and to relevant vendors and business partners, and keeps evidence of it.

Before an assessment, confirm that the named owner can explain the policy in an interview and that the review date and distribution records are current.

What meeting 12.1 costs in money and effort

This table breaks down the money and effort behind Requirement 12.1, showing who is paid for each piece, whether it is one-time or recurring, and what pushes it up or down. No prices or durations are given because no figures were supplied, so use the rows to structure a written quote and to compare your own internal effort against outside help.

Cost component	Who is paid or who spends time	One-time or recurring	What drives it up or down
Drafting the overall policy and its sub-policies	Internal security or compliance staff, and any outside consultant hired to draft	One-time, then recurring when revised	Number of policy documents, how many existing policies must be merged, and how much current practice is undocumented
Legal and HR review	In-house counsel, HR, and sometimes an external lawyer for employment or contract wording	One-time per revision	Number of jurisdictions, whether vendor and business partner clauses are included, and how often counsel reviews drafts
Executive approval time	CISO or a knowledgeable executive, plus the approving board or committee	Recurring at each review cycle	Size of the governance chain, whether approval is delegated in writing, and how clearly 12.1.4 responsibility is already assigned
Document system licenses and hosting	Software vendor or hosting provider, or internal platform team if self-hosted	Recurring subscription, or one-time setup for self-hosted tools	Number of users who must read or edit, and whether a self-hosted wiki removes per-seat license spend
Engineering time to configure versioning and access	Platform or IT engineers, or an implementation partner under a written scope	One-time setup, with occasional recurring changes	Need for version history, role-based permissions by audience, and integration with existing identity and access tools
Distribution and acknowledgment tracking	Security or HR staff who publish, notify and chase staff and third parties	Recurring at each policy update	Number of audiences (personnel, vendors, business partners) and whether acknowledgments are captured electronically
Recurring review effort every 12 months	Policy owner, subject matter experts and the approver	Recurring, at least yearly	How many policies cite changed systems, how often the environment changes, and how current the change log is
Assessor time examining and interviewing	QSA or internal assessor, billed by the assessment firm or charged to internal staff time	Recurring at each assessment	Quality of the policy and roles records, how quickly staff can answer interview questions, and how much evidence is ready before fieldwork

Common gaps that fail PCI DSS 12.1 and how to close them

Most 12.1 findings do not come from a missing document. They come from a policy that exists on paper but is stale, unowned, unpublished or disconnected from the cardholder data environment. The cards below cover the gaps assessors most often probe and the fix for each.

Policy not reviewed within 12 months

The policy may have been approved once and never revisited, so its review date is older than a year. Sub-requirement 12.1.2 expects a review at least every 12 months and an update when the environment changes. Check the document's last approval date against the review log, and confirm that the review covers new payment channels, new third parties and changes to the cardholder data environment. Record each review with a named reviewer and the decision taken, even when no edits were needed.

No named CISO or executive

Sub-requirement 12.1.4 expects overall responsibility for the security policy to sit with a CISO or another knowledgeable executive. Many organizations name a security manager or a shared committee, which an assessor may not accept as the accountable owner. Confirm that a named individual holds the role in writing, that the appointment is recorded in a governance document, and that the person has the authority to approve policy changes and fund remediation.

Roles defined only for security staff

Sub-requirement 12.1.3 expects security responsibilities to be defined for all personnel, not only the security team. Finance staff who handle refunds, call center agents who take card numbers over the phone and engineers who deploy code all have security duties. Check that the policy or an attached responsibility matrix names duties for each function that touches the cardholder data environment, and that staff in those functions can point to their own duties.

No proof of dissemination to vendors and partners

Sub-requirement 12.1.1 expects the policy to reach personnel, vendors and business partners. Publishing the policy on an internal wiki covers staff, but outsourced operators, hosting providers and integrators often never receive it. Keep a distribution record for each external party, with the date and the method, and tie it to the contract or onboarding process. Ask each third party to acknowledge receipt, and keep the acknowledgment with the third-party inventory.

Policy scope excludes the cardholder data environment

A policy written for corporate IT often omits payment systems, card-present devices, call recording or hosted payment pages. An assessor will compare the policy's stated scope with the current scope documentation and flag gaps. Check that the policy names the cardholder data environment explicitly, that it covers every system and location in the scope inventory, and that payment-specific rules, such as handling of PAN and sensitive authentication data, appear in it or in a standard it references.

No version history or approval trail

Without version control, an assessor cannot confirm which policy was in force on a given date, who approved it or what changed. This matters for the 12-month review and for any finding that depends on a past date. Keep the policy in a system that records each change with its author and time, allows comparison between versions and supports rollback. Store approval records alongside the versions so that the current document and its history can be shown together.

Questions buyers ask about the PCI DSS 12.1 policy

Can our own team write the PCI DSS information security policy?

Yes. The organization owns its information security policy, so your own people can write it, and many do. The policy has to reflect how your business actually handles cardholder data, which means the people who know the payment flows, systems and vendors need to be involved. A partner can help structure the document and check it against the standard, but the policy must be approved, published and enforced by your organization. Expect the work to be iterative: drafts go to system owners, legal and the executive who will sign it, then get revised. Confirm with your QSA how they expect the policy to be evidenced before you start.

How much effort does a PCI DSS 12.1 policy take, and what drives it?

The effort depends on how many systems, payment channels, vendors and business units fall inside the cardholder data environment and how mature your existing security documents are. Organizations with an existing security policy usually need to map it to the 12.1 sub-requirements and add missing roles, review cycles and dissemination records. Organizations starting from nothing need to define scope, roles and governance first. Ask any partner or internal team for a written breakdown of tasks, the reviewers involved and the approvals required, because those items drive both cost and calendar time.

Can an implementation partner replace the QSA for the 12.1 review?

No. An implementation partner can help prepare the policy, roles, dissemination records and review process, but it cannot perform the assessment or attest that 12.1 is met. Only a Qualified Security Assessor, working under the PCI SSC framework, can produce the Report on Compliance for an assessment that requires one, and the organization's own validation documents depend on that assessor's work. Keep the roles separate in your contracts: the partner prepares, the QSA tests, and your organization owns the controls and the conclusions it signs.

Is a policy template enough to satisfy Requirement 12.1?

A template is a starting point, not evidence. Assessors examine the policy you actually have and interview the people responsible for it, so a generic document that does not describe your environment, roles and responsibilities will not hold up. Adapt any template to your cardholder data environment, name the accountable executive or CISO, define roles for all personnel, and confirm that the document is published and distributed to personnel, vendors and business partners as the sub-requirements describe. Ask your QSA which template elements they have seen fail in practice.

How often must the information security policy be reviewed?

The policy must be reviewed at least every 12 months and updated as needed. Reviews should also follow material changes such as new payment channels, new service providers, organizational restructuring or significant incidents, even though the standard sets the 12-month minimum. Keep dated review records showing who reviewed the policy, what changed and who approved the update, because assessors ask for that trail. Use version control in your documentation system so each revision is traceable.

Does filing a self-assessment questionnaire change what 12.1 expects?

No. The requirement stays the same whether you validate with a Report on Compliance or a Self-Assessment Questionnaire. The SAQ changes who performs the validation and how the evidence is documented, not the policy expectations. Under the SAQ path, your organization completes the questionnaire and its Attestation of Compliance itself, so the policy, roles and review records must still be in place and ready to show if the payment brand or acquirer asks. Confirm with your acquirer which validation path applies to you.

What should our team provide to an outside partner before work starts?

Provide the existing security policies and standards, an up-to-date description of the cardholder data environment and data flows, a list of systems and vendors, the current role and responsibility assignments, and the names of the executive accountable for security. Also share previous assessment reports, known gaps and the approval path for policy changes. A written scope with these inputs lets a partner give a fixed-scope quote, which DeployOpen does before work starts, and it reduces the chance that discovery work extends the timeline.

How DeployOpen prepares PCI DSS 12.1 evidence

DeployOpen helps organizations prepare the systems, documents and evidence behind Requirement 12.1, the information security policy and its ownership. The organization owns its policy and its CISO or executive accountability, while an independent QSA assesses the result and issues the report.

How we scope

Confirm which business units, personnel groups and third parties the 12.1 policy must reach.
Agree in writing which policy documents, roles and review records DeployOpen will prepare.
Identify the named CISO or executive owner the organization will confirm for the assessor.
Set the fixed scope, deliverables and timeline before any work begins.

How we build

Draft or restructure the overall information security policy with the organization's own leadership.
Document security roles and responsibilities for all personnel groups in a single, versioned register.
Configure a wiki or document platform so policy versions, approvals and review dates are kept.
Map each sub-requirement under 12.1 to the document that answers it, so gaps are visible.

How we hand over

Deliver the published policy, role matrix, review schedule and version history as organization-owned files.
Provide an evidence index that shows where each 12.1 artifact is stored and who approved it.
Walk the organization's staff through what the assessor will examine and which people they will interview.
Confirm with the QSA which evidence format and sample period they expect before the assessment.

How we support

Ongoing support is available as a retainer to keep the annual policy review and role records current.
Retainers can cover updates to the policy when scope, systems or third parties change.
Ask any assessor or consultant to confirm in writing which 12.1 evidence they require for your environment.