PCI DSS required policies and procedures

Which policies and procedures PCI DSS requires before a QSA review

A customer or acquirer has asked for PCI DSS validation, and the policies you have are scattered across wikis, old templates and individual inboxes. PCI DSS v4.0.1 expects documented, current, in-use policies and operational procedures under each of the 12 principal requirements, and the overall information security policy must be reviewed at least every 12 months. Your organization owns these documents and approves them. DeployOpen can help draft, consolidate and align them with the systems you run, but only the Qualified Security Assessor (QSA) or other assessor tests them and issues the Report on Compliance or Attestation of Compliance. Confirm with your acquirer or brand which validation route applies before you start rewriting anything.

Start with the core set that assessors read first: the Requirement 1.1 network security policy and procedures, the 12.1 information security policy, the 12.2.1 acceptable use policy covering approved hardware and software, the 3.2.1 retention and disposal policy covering every location where stored account data sits, and the 12.10 incident response plan. Each one should name its owner, its scope, its review date and the roles it assigns. For the incident response plan, check that it covers payment brand and acquirer notification, containment, recovery, backups and legal reporting analysis, and that someone is reachable around the clock. Use the PCI SSC Data Security Standard page as the reference text, and confirm the exact sub-requirement wording against it rather than relying on secondhand summaries.

Policies alone do not satisfy the standard. PCI DSS v4.x lets you meet each requirement through the defined approach or, for entities with robust security and risk management, the customized approach, which must still achieve the stated objective. Either way, the assessor compares each document with what operations actually do. A retention policy that says seven years while the data sits indefinitely in a backup bucket fails the check. Before the review, pick a sample of policies and walk each one against a live system, a ticket or a log entry, and fix every gap you find. Record who approved each change and when, because the assessor will ask for that history.

Which policies assessors test most often

Assessors open the policy set first because almost every other PCI DSS requirement depends on it. The cards below cover the policies that come up most often in a PCI DSS assessment, with the evidence an assessor examines for each. Keep each policy current, assigned to an owner, and provably in use.

Information security policy

Requirement 12.1 expects one overall information security policy that is published, maintained and given to personnel, vendors and business partners. It must be reviewed at least every 12 months and updated as needed, with security roles defined for all personnel and responsibility assigned to a CISO or other knowledgeable executive. Assessors examine the signed policy, its revision history, the review record for the last year, and the distribution list. Check that the review date falls within the last 12 months.

Acceptable use policy

Requirement 12.2.1 requires documented and implemented acceptable use policies for end-user technologies such as laptops, mobile devices, remote access tools and email. The policy must state explicit approval by authorized parties, the permitted uses, and a list of company-approved hardware and software. Assessors compare the approved list against a sample of devices and installed applications. An approved list that does not match the fleet is a common finding.

Data retention and disposal policy

Requirement 3.2.1 requires data retention and disposal policies, procedures and processes covering every location where stored account data resides, including backups, logs, exports and test copies. The policy should name retention periods, disposal methods and the owner who approves exceptions. Assessors look for the policy, the disposal logs for a sample of records, and evidence that the rules reach every storage location in the inventory.

Incident response plan

Requirement 12.10.1 requires the incident response plan to name roles, communication strategies including notification of payment brands and acquirers, containment, business recovery, data backup, legal reporting analysis and procedures for each payment brand. Requirement 12.10.2 requires an annual review and test, and Requirement 12.10.3 requires designated personnel available around the clock. Assessors read the plan, the most recent test record and the on-call roster. The annual test record is the item most often requested.

Network security control policy

Requirements 1.1.1 and 1.1.2 require the procedures for network security controls to be documented, kept current, in use and known to affected staff, with roles and responsibilities documented and assigned. Assessors examine the written policy and procedures, then interview the people who run firewall and router changes to confirm they know the process. A RACI matrix covering each Requirement 1 activity is the usual evidence of assigned responsibility.

Third-party provider agreements

Requirement 12.8 and its sub-requirements expect a list of third-party service providers that handle account data, written agreements acknowledging their responsibility for that data, and due diligence before engagement. The agreement is the document an assessor reads to confirm responsibility is shared correctly. Confirm with each provider which requirements it covers, and keep the responsibility matrix current when services change.

How the annual policy review runs in practice

The annual review turns a policy from a document on a shelf into a checked, approved and communicated control that matches how the environment actually runs. Each step leaves a record that an assessor can examine and trace back to the 12-month requirement.

Draft or update the policy text
The policy owner, usually the security lead working under the executive responsible for security, drafts new text or marks up the existing policy against the current scope. Changes to the environment, payment channels, third parties or threats since the last review are noted in the revision history. The step is done when the draft has a version number, a revision date and a summary of what changed.
Check the draft against current systems
Before approval, the owner compares each statement with the systems and processes that exist today, including the network and data-flow diagrams, the system inventory and recent significant changes. Statements that describe tools, teams or locations that no longer exist are corrected or removed. The step closes with a short list of gaps found and how each was resolved, which shows the review tested the text against reality.
Obtain approval from the executive owner
The executive who holds security responsibility reviews the revised policy and records approval with a name and date. Where the organization's governance requires other sign-offs, such as legal, HR or a risk committee, those approvals are captured too. The approved version becomes the only version in circulation, and older copies are archived rather than deleted so the history stays visible.
Disseminate to personnel, vendors and partners
The approved policy is published to staff and communicated to vendors and business partners who handle in-scope systems or data. The distribution list, the method and the date are logged, and acknowledgments are collected where the organization requires them. Confirm with your QSA which audiences your assessment expects to receive the policy, since the standard names personnel, vendors and business partners.
Confirm that practice matches the text
Operational owners check that the daily work described in the policy and its procedures is what staff actually do. Sampling a few recent tickets, access approvals, log reviews or change records against the written steps reveals gaps between policy and practice. Discrepancies are logged as findings with owners and due dates, and the policy or the practice is corrected. The step is complete when the sample results are written down.
Retain the review evidence for the assessor
The review package is filed in a location the assessor can reach: the prior and current policy versions, the change summary, the gap findings, the approval record, the dissemination log and the operational sample results. Retention periods for these records should be confirmed with your QSA and your own records policy. Assembling the package at the time of review, rather than during the assessment, lets you answer the assessor's questions directly.
Confirm the internal cadence with your QSA
The standard sets a review at least every 12 months, and organizations often run internal checks more often, such as after significant changes. Ask your QSA how the assessor expects those interim reviews to be recorded and whether any internal cadence you adopt will be tested against the 12-month minimum. The agreed cadence is then written into the policy governance section so the schedule is itself documented.

Retention and acceptable use policies that hold up under testing

The retention and disposal policy under Requirement 3.2.1 is only useful to an assessor if it names every place stored account data can sit. Assessors compare the policy against the data-flow diagram and the system inventory, so a policy that says "card data is deleted after the retention period" without listing databases, backups, log files, analytics copies, exports, support tickets and file shares will be marked as incomplete. Write the policy as a location register: for each store, state the data element kept, the business reason, the retention period, the disposal method and the person who confirms deletion. The policy must then tie to written disposal procedures and to evidence that those procedures run, such as deletion job logs, backup rotation records or a sample of purged records. The PCI SSC publishes a FAQ on the maximum period cardholder data can be stored. Ask your QSA how that guidance applies to your business and which retention periods they will accept before you set any figure in the policy, because the answer depends on your use case and the assessor's reading of your environment.

The acceptable use policy under Requirement 12.2.1 covers end-user technologies such as laptops, mobile devices, removable media, remote access tools and browsers. Two elements are commonly missing. The first is explicit approval by authorized parties: name the role, usually IT or security leadership, that signs off on each permitted use, and keep the signed approval record. A policy signed by no one, or one that delegates approval to nobody in particular, fails the test. The second is the list of company-approved hardware and software. This list should be a controlled document with an owner, a version history and a review date, and it should match what your asset management tooling actually reports. Assessors often sample a device or application from the inventory and check it against the list, so a list that omits tools in daily use creates an immediate finding. Before the assessment, export the device and software inventory from your management platform, reconcile it against the approved list, and resolve every difference by either approving the item or removing it.

Who writes, approves and tests each policy

The compliance lead coordinates the policy set, and each requirement area usually has a named policy owner, such as the network team owning the Requirement 1 network security control policy or the data team owning the Requirement 3 retention and disposal policy. Owners write the documents, keep them current, and make sure the people who run the controls actually follow them. Nothing in the standard requires one person to hold every policy, but the assignment must be written down and understood.

Drafting the policy set: Owners write the policies and operational procedures that sub-requirements 1.1.1 and 12.1.1 describe, using the company's own systems and terms.
Annual review: The overall information security policy must be reviewed at least every 12 months, so the compliance lead should track review dates and record each approval.
Dissemination: Owners confirm the policy reached personnel, vendors and business partners who need it, and keep acknowledgment records.
Change control: Significant changes to systems or payment flows trigger policy updates, which owners log with version history.
Role records: Owners maintain the roles and responsibilities record, such as a RACI matrix, that sub-requirement 1.1.2 and 12.1.3 expect.

Check that every policy has a named owner, a version and a review date, and that the owner can explain the policy to an assessor without reading from it.

Why policy projects stall or fail assessor review

Most PCI DSS policy gaps are not missing documents. They are documents that do not match the environment, have no owner, or go stale without anyone noticing. Assessors test whether each policy is documented, in use and known to the people it covers, so each card below names one failure pattern and the check that catches it before the assessor does.

Templates that do not match real systems

A policy downloaded from a template often names firewalls, log tools or payment flows the organization does not run. Assessors compare the written procedure with the live environment during interviews and sample checks, and a mismatch undermines every other policy in the set. Fix it by walking each policy section against the current network and data-flow diagrams, then rewriting any step that names a tool, team or system the organization does not use.

Policies with no named owner

A policy that belongs to everyone usually gets updated by no one. Requirement 1.1.2 and the roles requirements in Requirement 12 expect each activity to have documented, assigned and understood responsibility. Fix it by recording one accountable owner and one backup for every policy in a RACI matrix, and confirming that each named person can describe what they are responsible for.

Annual reviews missed

Requirement 12.1.2 requires the overall information security policy to be reviewed at least every 12 months and updated as needed. Teams often track the policy's approval date but not its review cycle, so the date passes unnoticed after a reorganization or a new payment channel. Fix it by keeping a register of every policy with its last review date, next due date and reviewer, and by linking each review to a change record that shows what was checked.

Acceptable use lists out of date

Requirement 12.2.1 expects acceptable use policies for end-user technologies, including explicit approval by authorized parties and a list of company-approved hardware and software. A list that predates recent laptops, mobile devices or SaaS tools shows assessors that approval is not really enforced. Fix it by reconciling the approved list against the asset inventory and endpoint management records, and by recording who approved each addition and when.

Incident response plans never tested

Requirement 12.10.2 requires the incident response plan to be reviewed and tested at least once every 12 months, and 12.10.3 requires designated personnel to be available around the clock. A plan that has never been exercised usually fails on contact details, payment brand notification steps or backup restoration. Fix it by running a tabletop exercise each year, recording the gaps it finds, and updating the plan and the contact roster before the assessor asks for the test record.

Documents describing controls not run

A policy that promises quarterly access reviews or daily log checks is a claim the assessor will test. When the team does not perform the activity, the gap is recorded as a failure of both the control and the document. Fix it by pairing every policy statement with a recurring task, an owner and a retained record, and by removing any commitment the team cannot evidence today.

Questions buyers ask about PCI DSS policies

How much effort does writing PCI DSS policies take?

Effort depends mostly on how many policies your environment needs and how much of the existing documentation you can reuse. A small merchant using a single hosted payment page has far fewer documents to write than a service provider with shared cloud environments, multiple data centers and third-party access. The main drivers are the number of in-scope systems, how many teams touch the cardholder data environment, whether procedures already exist as runbooks, and how many third parties need to be covered by the policy. Most of the time goes into describing how things are actually done, then checking that staff follow those descriptions. Ask any implementation partner to quote the work as a written list of documents, each with an owner, a reviewer and a deliverable date, so you can see what is included.

Can our team write the PCI DSS policies on its own?

Yes, an organization can write its own policies, and the standard does not require outside authors. What matters is that the policies describe your real environment, that the people named in them accept their roles, and that staff can show they follow the documents. Internal teams often struggle with three things: keeping procedures specific enough to test, aligning them with the scope they actually have, and finding time to keep them current after the first version. Some organizations write the policies internally and bring in a consultant to review gaps before the assessor arrives. Keep the authorship decision separate from the assessment, because a consultant who writes the policies may not be able to provide independent assessment work for the same environment.

How often do PCI DSS policies have to be reviewed?

The overall information security policy must be reviewed at least every 12 months and updated as needed, as set out in the Requirement 12.1 sub-requirements. Other documented policies and procedures, such as the incident response plan, must be reviewed and tested at least once every 12 months as well. Set the review date in the document itself, record who approved each version, and keep the change history. Also review a policy after any significant change to the environment, such as a new payment channel, a new hosting provider or a changed data flow, even if the annual date has not arrived. Assessors commonly check the version history against the review dates, so a document that has not been touched for a year is an immediate finding.

Is it acceptable to use a policy template?

A template is a reasonable starting point, but it cannot be a document you adopt unchanged. An assessor will check whether the policy describes your environment, names your roles and reflects the processes you actually run. Generic statements that could apply to any company are a common reason for findings. Use a template for structure, then add the systems in scope, the named owners, the review cycle and the specific procedures behind each policy statement. Keep the template source in your records, and be ready to explain every section you changed. Where you use a template from a third party, confirm that its wording matches your scope and does not describe controls you do not have.

What will the QSA ask to see for the policies?

A Qualified Security Assessor typically asks you to show the written policy and procedure for each requirement, the evidence that the document is current and approved, and proof that staff know it. For the policy and procedure sub-requirements, the assessor examines the documentation and interviews the people responsible. Expect requests for the roles and responsibilities record, such as a RACI matrix, a signed acknowledgment from staff who receive the policy, the incident response plan with its most recent test record, and the acceptable use policy with its list of approved hardware and software. Prepare an index that maps each document to the sub-requirement it supports, so the assessor can move quickly through the set.

Can DeployOpen certify our PCI DSS policies?

No. DeployOpen prepares systems, controls and evidence for assessment, but it does not issue reports, attestations or certifications. Only the independent assessor completing your Report on Compliance or Self-Assessment Questionnaire, with its Attestation of Compliance, validates your policies as part of the assessment. DeployOpen can help you draft, align and organize the policy set against your scope, and can document the implemented technical controls the policies describe. Your organization remains responsible for approving and enforcing the policies. Confirm the division of responsibilities in writing in the scope agreement before work starts, and confirm with your acquirer or payment brand which assessor and validation type they accept.

What should we confirm about the next version of PCI DSS?

The PCI Security Standards Council published PCI DSS v4.0.1 on 11 June 2024 as a limited revision, and it is the only active version. From 3 June to 20 July 2026 the Council ran a request for comments to begin the next iteration. As of October 2026, no release date for a new version had been announced. Confirm with your acquirer, payment brand or assessor whether any change will affect your policy set, and check the Council's website for announcements before planning a new policy cycle. Build your documents so that individual policies can be updated without restructuring the whole set, and record the version of the standard each document references.

What to check before hiring a policy consultant

A policy consultant can save time on the PCI DSS documentation set, but the policies must reflect your environment and remain yours after the engagement ends. The four checks below cover independence, quality, ownership and long-term maintenance, and each one shows up later when an assessor asks who wrote the policy and who keeps it current.

Confirm independence from the assessing QSA

Ask whether the consultant or their firm is also the Qualified Security Assessor who will validate your Report on Compliance. Writing the policies and then testing them against the same standard is a conflict that many organizations only discover mid-assessment. Ask for the names of the assessor you plan to use, and get written confirmation that the consultant has not designed controls the assessor would later judge as the independent party. Keep the consultant's scope limited to preparing documents and evidence, and keep the assessment with an independent firm.

Ask for a mapped sample deliverable

Request a sample policy or procedure before signing, and check that it names the sub-requirement it supports, such as 1.1.1 for the Requirement 1 policies or 12.10.1 for incident response contents. A useful sample states the owner, review date and where the document is stored, rather than repeating the standard. If the sample reads as generic text that could belong to any company, expect the same gaps in the full set. Ask how the consultant will confirm each policy matches your actual systems and processes.

Confirm you receive editable documents

Confirm in the written scope that you receive every policy, procedure and template in an editable format such as Word or Markdown, and that you hold the rights to change and reuse them. Documents delivered only as locked PDFs or inside a consultant's portal make every future change dependent on that vendor. Ask whether the consultant's own templates or tooling remain licensed to them and whether any content must be removed on exit.

Name who approves and maintains policies

Decide before handover who approves each policy, who reviews it at least every 12 months as Requirement 12.1.2 expects, and who updates it after a significant change. Ask the consultant to document this ownership in the policy set and to walk your named owners through the approval record. Policies that no internal owner has accepted often show signs of neglect at assessment time, such as review dates that have passed or procedures that describe systems you no longer run.

How DeployOpen prepares policies and evidence for your assessment

DeployOpen works inside your own infrastructure to prepare the systems, documentation and evidence that a PCI DSS assessment checks for policies and procedures. Your organization owns its policies and approves them, and only a Qualified Security Assessor issues the Report on Compliance or the Attestation of Compliance.

How we scope

Agree in writing which requirements, business units and systems the policy set covers before work starts.
Confirm which policies apply to your payment channels, service providers and cloud accounts, and which sit with your organization.
Engagements are fixed-scope, with deliverables and timelines set out in a written statement of work and quote.

How we build

Draft the information security policy, network security procedures, acceptable use, retention and disposal, and incident response documents against your environment.
Map each documented procedure to its sub-requirement so an assessor can trace every policy to the controls it describes.
Test that written procedures match how systems are configured and how staff actually work, and record gaps for your owners to close.

How we hand over

Deliver the approved policy set with version history, review dates and named owners for the annual review cycle.
Provide a roles and responsibilities record, such as a RACI matrix, that your assessor can examine alongside interviews.
Walk your staff through the documents so the people named in them can explain their duties during assessment.

How we support

Update policies and procedures when significant changes occur in systems, payment flows or service provider relationships.
Ongoing support, upgrades and continuous testing are available as a retainer, scoped separately from the initial engagement.
Confirm with your QSA which evidence format and review cadence they expect before the assessment window opens.

Which policies and procedures PCI DSS requires