12 PCI Compliance Requirements: Who Owns Each Control?

The 12 PCI compliance requirements cover network security, secure configurations, stored data, encrypted transmission, malware protection, secure software, access restrictions, authentication, physical security, logging, security testing, and security governance. Together, they define how organizations protect payment card account data under the Payment Card Industry Data Security Standard, or PCI DSS.

For AP managers and compliance officers, the practical question is not simply whether a vendor is compliant. It is which controls the vendor performs, which remain yours, and what evidence demonstrates that the handoff works. This guide explains the requirements through that ownership lens—not as a substitute for a PCI assessment.

First establish whether PCI DSS applies

PCI DSS applies to entities that store, process, or transmit cardholder data or sensitive authentication data, and can also apply to entities whose services could affect the security of the cardholder data environment, or CDE. A vendor may therefore matter to PCI compliance even if it never receives a card number: a managed IT provider with administrative access is an example.

Collecting W-9 or W-8 forms, bank account details, or KYC documents does not, by itself, put a vendor workflow within PCI DSS scope. Those records require appropriate privacy and security controls, but PCI DSS is specifically a payment-card security standard. Avoid treating every supplier as a card-data service provider.

PCI DSS is a global industry standard, not a universal government licensing regime. Validation obligations generally arise through payment-brand rules and acquiring relationships, although local laws can reference the standard.

Use PCI DSS v4.0.1 as the baseline. The PCI Security Standards Council’s publication announcement explains that this limited revision introduced no new or deleted requirements and retained the March 31, 2025 effective date for previously future-dated requirements. That date has passed; applicable controls should not still be treated as optional.

The 12 PCI compliance requirements explained

The table summarizes the top-level requirements described in this PCI DSS v4.0.1 requirements overview. The evidence examples are practical review inputs, not an exhaustive list of assessment requirements. Applicability depends on your environment and services.

Where ownership breaks down across the requirements

Requirements 1–4: Know where card data travels

Start with a data-flow diagram, not a vendor questionnaire. Identify checkout pages, APIs, support tools, exports, backups, and any finance systems receiving card-related records. Record whether each destination receives a full primary account number, a masked value, or a token.

Encryption and tokenization can support scope reduction, but neither automatically removes every connected system from scope. Architecture, access, and the ability to affect card-data security still matter.

For ordinary merchant workflows, sensitive authentication data such as card verification codes must not be retained after authorization, even encrypted. Do not build onboarding forms or support processes that ask vendors to upload card images or verification codes as evidence.

Requirements 5–6: Separate platform security from integration security

A provider may maintain its platform while your organization remains responsible for its own integration code, endpoints, and deployment changes. Ask who patches each component, who receives vulnerability notifications, and who confirms remediation.

Payment-page scripts deserve explicit ownership. Where applicable, script authorization, integrity assurance, and inventory controls cannot be replaced by a generic statement that the payment processor is compliant. Determine which party can add or change scripts and who reviews that activity.

Requirements 7–9: Treat vendor access as a lifecycle

Access approval should identify the person or service account, permitted activity, business owner, and removal trigger. A vendor contract ending is not evidence that its technical access has ended.

Authentication requirements extend beyond a strong password. Review applicable MFA controls, remote access, non-human accounts, and account termination with security specialists. Physical controls also remain relevant when paper records, removable media, or payment devices are involved.

These controls complement, rather than replace, AP fraud prevention controls. PCI compliance does not establish that a supplier’s changed bank account is legitimate or that an invoice is authorized.

Requirements 10–11: Make monitoring lead to action

A log archive is not a monitoring process. Establish who reviews events, who investigates alerts, and how your organization receives notification of incidents involving a provider.

Similarly, a penetration-test summary is not proof that identified weaknesses were fixed. Review the tested scope, unresolved findings, remediation responsibilities, and retesting evidence where appropriate. Security teams should assess technical sufficiency; AP should track whether the required decision and supporting evidence exist.

Requirement 12: Govern the relationship, not just the paperwork

Requirement 12 connects technical controls to policies, risk analysis, scope confirmation, training, incident response, and third-party service provider management. Its provider-management provisions make outsourcing an ongoing governance responsibility.

As this explanation of PCI DSS third-party service provider requirements outlines, organizations need a provider inventory, appropriate written responsibility acknowledgments, due diligence, compliance-status monitoring at least annually, and a record of which requirements belong to each party. A signed contract alone does not establish that these controls operate.

Read validation evidence without overreading it

An Attestation of Compliance, or AOC, documents an assessment’s scope and outcome. A Self-Assessment Questionnaire, or SAQ, is used by eligible entities; a Report on Compliance, or ROC, documents a detailed assessment. An AOC accompanies the relevant validation process—it is not a separate shortcut around assessment.

Check the legal entity, assessed services, assessment date, result, exclusions, and fit with the service you intend to buy. Confirm your own validation obligations with your acquirer or payment brand, supported by a Qualified Security Assessor where appropriate.

As Integrity360 explains in its discussion of why a provider’s AOC is not enough, assurance also depends on understanding the service and the customer’s responsibilities. A provider can be compliant within its assessed scope while your implementation leaves a control gap.

Build a control-ownership record before activation

Use a requirement-level responsibility matrix rather than a single “PCI approved” field. Each entry should identify:

• Scope: the service, data flow, and system involved.
• Operator: who performs the control, including shared tasks.
• Accountable owner: who accepts and reviews the evidence internally.
• Evidence: the artifact, covered period, and scope limitations.
• Review trigger: a scheduled review or material service change.
• Gap treatment: remediation, restricted access, or delayed activation.

Hypothetical example: A processor supplies an AOC for its hosted checkout. Your company controls the surrounding website and manages staff access to the processor dashboard. The ownership record assigns the processor its assessed hosting controls, your engineering team the applicable website controls, and your identity team dashboard access management. “Shared” is then broken into tasks rather than left as an ambiguous label.

Keep commercial approval, vendor payment readiness, and CDE access authorization separate. A supplier can be approved for invoicing without being approved to access cardholder data. When designing AP automation, preserve those separate statuses instead of making a general vendor approval imply security clearance.

A practical next-step checklist

1. Map card-data flows and identify vendors that could affect their security.
2. Have security validate scope before requesting unnecessary PCI documentation.
3. Review assessment evidence against the exact service being purchased.
4. Assign provider, customer, and shared responsibilities at requirement level.
5. Resolve applicable control gaps before granting relevant access.
6. Schedule compliance-status reviews and trigger reassessment after material changes.

The strongest operating model treats the 12 requirements as connected controls with named owners—not twelve documents to collect. Start with one payment-related vendor and trace its evidence through to your own responsibilities. Use configurable approval policies to support business authorization, while keeping PCI scope and technical compliance decisions with the responsible security and compliance teams.

Created with AI assistance. Sources are linked in the article; this content is general information, not legal, tax, or financial advice.