PCI Compliance

PCI DSS compliance: understand your scope and responsibilities

PCI DSS is a payment-security standard for protecting account data. Its scope can include organisations and systems that store, process or transmit cardholder data, and those that can affect the security of that environment. Start by understanding how payments work and who controls each part.

This guide concerns PCI DSS v4.0.1. Version 4.0 retired on 31 December 2024; the requirements previously described as future-dated became effective on 31 March 2025. They are current obligations where applicable, not a forthcoming transition. PCI SSC version guidance.

Reviewed: 26 October 2026.

Map payment channels and security dependencies

List online, telephone, mail-order and in-person payment channels, including refunds, administration and support. Trace where account data enters, travels, is stored and is deleted. Include logs, recordings, exports and backups that may accidentally retain it.

Then identify connected systems and services that can affect payment security: identity, remote support, deployment tools, hosting, scripts and administrators. Network segmentation may reduce scope only when it is properly designed, maintained and validated.

Build a complete scope: data, people, processes and technology

Follow account data beyond the checkout

Start with every payment channel: website, shop, telephone, mail order and any exceptional or fallback process. Follow a transaction through authorisation, settlement, refund, dispute and disposal. Ask staff to demonstrate the real process, because a workaround used only during an outage can introduce another place where account data is handled.

Check logs, exports, support tickets, shared folders, email, call recordings, paper receipts and backups where relevant. A migration to a new payment provider does not necessarily remove historic data from the previous system. Record the location, business purpose, access, retention and disposal method for each legitimate store. Discovery should be authorised and should avoid creating new copies of sensitive data.

Distinguish the primary account number (PAN) and other cardholder data from sensitive authentication data such as card verification codes, full track data and PIN/PIN blocks. Merchants must not retain sensitive authentication data after authorisation, even encrypted. A recurring-payment requirement does not justify keeping a card’s verification code. PCI SSC explains this storage prohibition. Issuing services have specific applicability provisions; do not assume those exceptions apply to an ordinary merchant.

Include systems that can affect payment security

Scope is wider than the database containing card numbers. Examine administration, identity, remote access, logging, patching, key management and other services that connect to or can affect the cardholder data environment. Document the reasoning for inclusion or exclusion, along with the architecture and controls supporting that decision.

A network diagram should show relevant trust boundaries and connections; a data-flow diagram should show what information moves, why and between which parties. They answer different questions. Include hosted services and administrative paths rather than drawing only the organisation’s own servers.

Interview the people who perform the work

Involve payment operations, finance, customer support, IT, security, developers and relevant suppliers. Managers can describe the intended process; staff can show how refunds, disputes, access requests and failures are actually handled. A process may remain in scope even when it uses paper or an outsourced service.

Record handovers. For example, establish who authorises a payment-page change, who deploys it, who can inspect its effect and who responds if an unexpected script appears. When the responsibility crosses a supplier boundary, make both sides explicit.

Validate segmentation and sampling assumptions

Segmentation can reduce scope only when it effectively isolates the relevant environments and its operation is demonstrated. A VLAN label or firewall drawing alone is not proof. Include management paths, shared services, remote access and alternative connections in the reasoning and the agreed validation.

Assessment sampling is a way to examine a representative population; it does not let an organisation implement required controls on only the sampled devices or locations. Describe the variants, common management processes and evidence supporting the sample, and expand it if inconsistent implementation is found. See PCI SSC’s sampling clarification.

Outsourcing reduces work, not all responsibility

A compliant payment provider does not automatically make its customers compliant. Confirm the exact service covered by the provider’s Attestation of Compliance, the period and scope, and which requirements remain yours. Document responsibilities in a matrix and review changes.

For e-commerce, a full redirect, an embedded payment form and a merchant-hosted payment page can have different eligibility and security implications. Do not select an SAQ solely from a marketing description such as “hosted checkout”.

PCI SSC’s SAQ A script-attack clarification distinguishes embedded payment forms from full redirects and other fully outsourced arrangements. The embedded-form eligibility condition requires the relevant protection or confirmation described by the Council, alongside all other SAQ criteria.

The Council also clarifies that SAQ A merchants with relevant e-commerce web pages, including redirects or embedded forms, need applicable external ASV scans. A passing scan does not establish compliance with the whole standard. PCI SSC FAQ on SAQ A and ASV scanning.

SAQ, ROC and AOC: choose the correct validation route

These examples help you identify which current eligibility criteria to examine; they do not determine eligibility by themselves.

Other SAQs cover additional environments. Use the current PCI SSC instructions and confirm the route with your acquirer or other accepting entity. Multiple channels and historic data can change the answer; a provider’s product name is insufficient.

Further guidance: PCI SSC: SAQ Instructions and Guidelines v4.0.1 r1 (April 2025).

Payment brands and acquirers generally determine validation and reporting requirements. Transaction volumes can be relevant, but universal “level” tables can mislead across brands, merchant and service-provider programmes and exceptional circumstances. Confirm the route with the entity accepting your compliance evidence. PCI SSC: roles in determining assessment and reporting.

A service provider should assess its own role and eligibility rather than use a merchant questionnaire by analogy. Bring ambiguous scope or applicability decisions to your QSA and compliance-accepting entity.

Understand the twelve PCI DSS requirement areas

These plain-English summaries help organise the work. They are not the full standard or an alternative assessment checklist. Determine the applicable sub-requirements, testing procedures, notes and frequencies from the current PCI SSC document library and your validation route.

A tool purchase is not the same as an operating control. For example, a logging platform may receive events while nobody reviews a failed feed or escalates a material alert. Link each control to who operates it, who checks it and how exceptions are resolved. Avoid putting card data or secrets into evidence packs when a redacted extract or supervised demonstration will suffice.

Turn the requirements into operational work

This grouping is a working aid, not a replacement for the twelve PCI DSS requirements or their applicability details. Use the current PCI SSC document library and the relevant assessment documents for the actual requirements.

From gap assessment to validation: a worked approach

1. Confirm the route. Obtain the accepting entity’s instructions on validation, reporting and timing. Merchant or service-provider level rules are programme-specific; a generic transaction-volume table is not a universal decision tool. SAQ eligibility depends on the actual payment environment, not only business size.
2. Build a requirement register. For each applicable item record the current implementation, owner, evidence, gap and planned correction. Distinguish not applicable, not yet tested and not in place; they are different conclusions. Keep a justification for exclusions.
3. Prioritise the corrections. Address immediate exposures and unnecessary data retention promptly, then sequence dependent changes. A prioritised plan helps delivery but does not waive a requirement or extend a deadline. Escalate risks and missed dates to the responsible business owner.
4. Implement and observe. Test the technical change, update the procedure, train the people who use it and collect evidence that it operates. Some controls need records over time; a screenshot taken just before an assessment cannot demonstrate months of activity.
5. Validate and submit. Have the appropriate assessor or eligible self-assessment process examine the implemented state. Resolve findings, complete the correct reporting documents and submit them through the route required by the accepting entity.

Illustrative example: a merchant has outsourced payment entry but retained an old spreadsheet of full card numbers from a previous process. Its action is not simply to obtain the new provider’s AOC. The merchant must investigate the legacy store, determine lawful/business retention needs, remove unnecessary data securely, establish the correct scope and check that the old export process cannot recreate it. Preserve incident evidence if there is suspected compromise.

Prepare a responsibility matrix for outsourced services. Identify the precise service and period covered by assurance documents, the controls the provider operates, those you operate and those requiring joint action. An AOC for a different product or location does not establish coverage for the service you use.

The PCI SSC Prioritized Approach and its supporting tool provide a structured way to group implementation work into six milestones. Use the current version from the Council’s document library alongside your requirement register. For example, eliminating unnecessary account-data stores may reduce exposure while broader application and access-control work proceeds.

Record the applicable requirement, owner, action and verification evidence for each task. Completing a milestone is progress, not a compliance determination, and does not postpone other applicable obligations. Consult the full standard, including its applicability notes and testing procedures.

Further guidance: PCI SSC: current Prioritized Approach and tool.

Understand scanning, penetration testing and segmentation

Vulnerability scans identify detectable weaknesses. Penetration tests investigate exploitability and attack paths. Segmentation testing checks whether the controls relied on to separate environments actually work. One activity does not automatically satisfy another.

Agree scope, independence, frequency and change-triggered testing against the applicable PCI DSS requirements and your environment. Track failed results through remediation and retesting; keep evidence showing what was checked and when.

A scanner marked “PCI capable”, a clean penetration test or a product certificate is not a blanket PCI DSS compliance determination. PA-DSS is a retired programme; assess current payment-software assurance against the relevant PCI Software Security Framework programmes rather than treating PA-DSS as a current application requirement.

Maintain evidence throughout the year

1. Build a calendar of applicable activities, with owners and escalation for missed work.
2. Keep evidence as the activity happens: approvals, reviews, scan results, fixes and exercises.
3. Reassess scope after new payment methods, scripts, suppliers, acquisitions or infrastructure changes.
4. Investigate control failures and record corrective action rather than assembling a last-minute document pack.
5. Prepare the correct validation documents and resolve applicability questions with the assessor or accepting entity.

Maintain an operating calendar and an assessment evidence pack

Build the calendar from the requirements that apply to your environment. Some activities have explicit intervals; others are triggered by changes or supported by the particular targeted risk analysis allowed by the standard. Do not replace mandatory intervals with an arbitrary annual review or treat every frequency as discretionary.

Revisit scope when payment channels, providers, applications, locations or administrative connections change. A new analytics tag, support arrangement or telephone-payment fallback may change the facts behind the previous assessment. Keep evidence securely with appropriate retention and access, and involve the payment owner when a control stops operating.

If account-data compromise is suspected, activate the incident process and coordinate with the acquirer/payment provider and appropriate specialists. Avoid destroying relevant records while trying to clean up. Notification and investigation obligations should be established for the organisation’s contracts and circumstances.

Common questions

We never see card numbers. Are we automatically out of scope?

No. Your systems may still influence payment security and you may retain validation responsibilities. Map the integration and confirm all eligibility criteria.

Can a customised approach avoid a difficult requirement?

It is not a shortcut or an automatic exemption. It requires supported objectives, documented controls, risk analysis and assessment. SAQs do not support documenting the customised approach; discuss the appropriate ROC route and acceptance requirements.

Where should a small merchant begin?

Document each payment channel and integration, obtain provider scope and responsibility evidence, and confirm the correct SAQ and scanning requirements with your acquirer or accepting entity.

Next steps and related guidance

Close PCI DSS v4.0.1 gaps and organise evidence · Secure an e-commerce platform

For an assessment discussion, bring payment-flow diagrams, provider AOCs, the previous assessment and a list of material changes. This makes scoping advice specific to your environment.

PCI DSS QSA consultancy.

For short answers to common questions, see the PCI DSS FAQ.