PCI DSS (Payment Card Industry Data Security Standard): PCI DSS – Tutorial (about 60 minutes)

The Payment Card Industry Data Security Standard (PCI DSS) is the security baseline that every organisation storing, processing or transmitting payment card data is expected to meet. Merchants, payment service providers, hosting companies and software firms around the world use it to protect cardholder data and the systems that touch it, and their banks and the card brands ask them to prove it every year. After this tutorial you will be able to explain what PCI DSS protects, how its twelve requirements are organised, how scope is decided, how compliance is validated and how a real organisation can reduce its burden without weakening security.

Free tutorial · about 60 minutes · 7 lessons · 5 diagrams · then a 25-question knowledge check and a certificate.

Course overview

Edition and status: The current and only active version is PCI DSS v4.0.1, published in June 2024 by the PCI Security Standards Council (PCI SSC) as a limited revision of v4.0 (March 2022) that corrected and clarified text without adding or deleting requirements. PCI DSS v4.0 was retired at the end of December 2024, and the requirements that v4.0 had marked as "future-dated" became mandatory on 31 March 2025, so all assessments today use v4.0.1 in full. In June–July 2026 the Council ran a request for comments on v4.0.1 to start work on the next iteration; no publication date for a successor has been announced. Verified 2026-10-29.

Who this is for: developers, cloud and operations engineers, security and compliance staff, product owners of payment features, and anyone who has heard "that system is in PCI scope" and wants to understand what it means in practice. It is also useful for people at a small business who have received a Self-Assessment Questionnaire from their bank and do not know where to start.

Prerequisites: none. A general idea of what a network, a server and a password are is enough. Every payment and security term is explained when it first appears.

By the end of this tutorial:

You will be able to explain why PCI DSS exists, who owns it and who enforces it.
You will be able to distinguish cardholder data from sensitive authentication data and state the basic storage rules for each.
You will be able to describe the six goals and twelve principal requirements of PCI DSS v4.0.1 in your own words.
You will be able to decide whether a system is part of the cardholder data environment, connected to it or out of scope, and explain how segmentation and outsourcing reduce scope.
You will be able to outline how compliance is validated: merchant and service provider levels, Self-Assessment Questionnaires, Reports on Compliance, Attestations of Compliance and quarterly scans.
You will be able to compare the defined approach with the customized approach and with compensating controls.
You will be able to apply the standard to a realistic business and avoid the mistakes that most often cause failed assessments or breaches.

Lesson 1 – Origins, purpose and scope

Why the card industry needed a common standard

A payment card is valuable to a criminal mainly because of the data printed on it and stored in its magnetic stripe or chip. With a card number, an expiry date and sometimes a security code, a fraudster can buy goods online, clone a card or sell the data in bulk. In the late 1990s and early 2000s, as online shopping grew, large thefts of card data from retailers and processors became common. Each of the big card brands responded with its own security programme, each with different rules and questionnaires. A merchant that accepted several brands had to satisfy several overlapping programmes.

In 2004 the brands aligned their programmes into a single document, version 1.0 of the Data Security Standard. In 2006 American Express, Discover, JCB, Mastercard and Visa founded the PCI Security Standards Council as an independent body to own and develop the standard, train and qualify assessors, and publish supporting material. Since then the standard has moved through versions 1.1, 1.2, 1.2.1, 2.0, 3.0, 3.1, 3.2 and 3.2.1 to version 4.0 (2022) and the current 4.0.1. Each new version reflected changes in attacks: the shift to e-commerce skimming, the end of SSL and early TLS, the rise of cloud hosting and the weakness of passwords on their own.

What the standard is, and what it is not

PCI DSS is a set of technical and operational security requirements for protecting account data, which means the card data that criminals want. It is written to be prescriptive enough that two assessors in different countries reach similar conclusions, yet broad enough to cover a corner shop with one card terminal and a global cloud provider.

It is important to understand three things it is not:

It is not a law. Compliance is normally a contractual obligation. A merchant signs an agreement with its acquiring bank, and that agreement brings in the card brands' rules, which in turn require PCI DSS compliance. A few governments reference it, but its force comes mainly from contracts.
The Council does not enforce it. The Council writes the standard and manages assessor programmes. Each card brand decides who must validate compliance, how often, and what happens when an organisation does not comply or suffers a breach.
It is not a guarantee of security. A successful assessment shows that controls were in place when they were assessed. Many breached organisations had been judged compliant at some earlier point; they drifted out of compliance between assessments.

Who must comply

PCI DSS applies to every entity that stores, processes or transmits account data, and to entities that can affect the security of that data. In practice this covers two main groups:

Merchants, which accept card payments for goods and services, whether in a shop, online, by phone or by post.
Service providers, which are businesses that are not a payment brand but are directly involved in processing, storing or transmitting account data for another entity, or that can affect its security. Examples include payment gateways, hosting and cloud providers, managed security service providers and call-centre outsourcers.

Card issuers and acquirers also have obligations, and some of them carry out activities, such as issuing cards, where storing sensitive data is allowed for a business reason. This tutorial focuses on merchants and service providers, which are the audiences most people meet.

The scope of the standard is also wider than "the server with the database". It covers the people, processes and technology that handle account data: staff who take orders by phone, the paper forms in a back office, the payment page on a website, the network that carries traffic, and the administrators and tools that can change those systems.

Lesson 2 – Key concepts and vocabulary

PCI DSS has its own vocabulary, and much confusion comes from mixing up a few key terms. The Council publishes an official glossary; the definitions below are explained in plain words.

Account data – the umbrella term for everything the standard protects. It is made up of cardholder data and sensitive authentication data.
Cardholder data (CHD) – at minimum the full primary account number, possibly together with the cardholder name, the expiration date and the service code.
Primary account number (PAN) – the long card number that identifies the issuer and the account. If the PAN is not stored, processed or transmitted, PCI DSS requirements generally do not apply.
Sensitive authentication data (SAD) – security-related data used to authenticate cardholders or authorise transactions: full track data from the magnetic stripe or its chip equivalent, the card verification code (the three- or four-digit value printed on the card) and PINs or PIN blocks.
Cardholder data environment (CDE) – the system components, people and processes that store, process or transmit account data, plus components that have unrestricted connectivity to them.
System component – any network device, server, computing device, virtual component, cloud resource or software that is in or connected to the CDE, or that could affect its security.
Segmentation – isolating the CDE from the rest of the network with controls such as firewalls and access rules, so that other systems are not in scope. Segmentation is not required, but it is the main way to reduce scope.
Merchant – an entity that accepts payment cards from the brands as payment for goods or services.
Third-party service provider (TPSP) – a service provider used by another entity, for example a payment gateway used by a merchant or a cloud platform used by a gateway.
Acquirer – the bank or financial institution that processes card payments for a merchant and to which the merchant reports its compliance status. It is also called the merchant bank.
Qualified Security Assessor (QSA) – an assessor employed by a company that the Council has qualified to perform PCI DSS assessments.
Internal Security Assessor (ISA) – an employee of the assessed organisation who has completed the Council's ISA training and can perform internal assessments.
Approved Scanning Vendor (ASV) – a company qualified by the Council to run external vulnerability scans of internet-facing systems.
Tokenisation – replacing the PAN with a substitute value (a token) that has no exploitable meaning on its own; only the token system can map it back.
Truncation and masking – truncation permanently removes part of a stored PAN; masking hides digits only when the PAN is displayed or printed.
Strong cryptography – cryptography based on industry-tested algorithms with appropriate key lengths and proper key management.

Figure 1 – Account data is split into cardholder data, which may be stored when protected, and sensitive authentication data, which must not be retained once a payment is authorised.

The two storage rules every beginner should know

The single most important idea in Figure 1 is the difference in treatment. Cardholder data may be stored if there is a business need, if it is kept only as long as needed and if the PAN is rendered unreadable wherever it is stored. Sensitive authentication data must not be kept after a transaction is authorised, even if it is encrypted. The only exception is for issuers and companies that support issuing services and have a documented business need, and they must protect it strictly.

Why the difference? The card verification code and the track data exist precisely to prove that the person paying has the real card. If a merchant keeps them, a thief who breaks in gets everything needed to commit fraud. The PAN, by contrast, is sometimes legitimately needed for refunds, recurring billing or chargebacks, so the standard allows it under strict protection.

Rendering the PAN unreadable can be done in several ways: a one-way hash of the whole PAN using a keyed cryptographic hash, truncation, tokens with securely stored lookup data, or strong encryption with sound key management. When a PAN is displayed, it must be masked so that only staff with a business need can see more than the bank identification number (BIN, the first six or eight digits, which identifies the issuer) and the last four digits.

Lesson 3 – Structure of the standard

The PCI DSS document is long, but its structure is simple once you see it. After introductory sections on applicability, scope, the relationship with other PCI standards, assessment approaches and sampling, it presents twelve principal requirements grouped under six goals. Each principal requirement is broken into numbered sub-requirements, and each sub-requirement comes with testing procedures (what the assessor checks) and guidance (why it matters and how it can be met).

Figure 2 – The twelve principal requirements are grouped under six goals, with appendices for special cases and assessment methods.

The twelve principal requirements, paraphrased

The official titles are short; the descriptions below explain what each one is about.

Network security controls. Install and maintain firewalls, cloud security groups and similar controls that decide which traffic may enter, leave and move inside the CDE, and keep their rules documented and reviewed.
Secure configurations. Change vendor default passwords and settings, harden every system component according to a known configuration standard, and remove unnecessary services.
Protect stored account data. Keep storage to a minimum with a retention policy, never retain sensitive authentication data after authorisation, mask the PAN on display, make the stored PAN unreadable and manage cryptographic keys carefully.
Protect data in transit. Use strong cryptography whenever the PAN travels over open, public networks such as the internet or wireless networks, and never send unprotected PANs by email or chat.
Protect against malicious software. Deploy anti-malware where systems are at risk, keep it updated and active, and use mechanisms that protect staff from phishing.
Secure systems and software. Develop software securely, identify and rank vulnerabilities, install critical security patches promptly, protect public-facing web applications and control changes, including the scripts that run on payment pages.
Restrict access by business need to know. Grant the least access needed for each role, define access in an access-control system and review user accounts and privileges regularly.
Identify users and authenticate access. Give every user a unique ID, manage authentication factors securely, and use multi-factor authentication for access into the CDE and for remote access.
Restrict physical access. Control entry to facilities and to media that hold account data, protect point-of-interaction devices from tampering and destroy media securely.
Log and monitor. Record user activity and security events on all system components, protect and review the logs, keep them for at least a year and synchronise clocks.
Test security regularly. Detect unauthorised wireless access points, run internal and external vulnerability scans, perform penetration tests, use intrusion detection and detect unauthorised changes to critical files and payment pages.
Organisational policies and programmes. Maintain a security policy, perform targeted risk analyses, run security awareness training, screen staff, manage third-party service providers, document and confirm scope, and maintain an incident response plan.

A common pattern inside each requirement

Version 4 introduced a consistent opening for requirements 1 to 11: the first sub-requirement asks that security policies and operational procedures for that area are documented, kept up to date, in use and known to everyone involved, and the second asks that roles and responsibilities for performing the activities are documented, assigned and understood. This sounds bureaucratic, but it targets a real problem: controls that exist only in one engineer's head disappear when that person leaves.

The appendices

Appendix A1 adds requirements for multi-tenant service providers, such as shared hosting, which must keep customers' environments isolated from one another.
Appendix A2 covers the remaining permitted use of SSL and early TLS for certain card-present point-of-sale terminal connections.
Appendix A3 is the Designated Entities Supplemental Validation (DESV), extra requirements that a payment brand or acquirer can impose on selected entities, for example after a breach.
Appendices B and C explain compensating controls and provide the worksheet for documenting them.
Appendices D and E explain the customized approach and point to the Council's sample templates, published on its website, for the controls matrix and the targeted risk analysis it needs.
Appendix F explains how the PCI Software Security Framework can support requirement 6, and Appendix G is the glossary.

What changed in version 4

Version 4.0 was the biggest revision in a decade. Its stated aims were to keep the standard aligned with current security needs, to promote security as a continuous process, to add flexibility in how objectives are met, and to improve validation methods. Requirements that took effort to implement were introduced as best practices with a future date, which arrived on 31 March 2025. Some of the most visible ones are:

multi-factor authentication for all non-console access into the CDE, not only for administrators or remote access;
a longer minimum password length of twelve characters where systems support it;
an inventory, authorisation and integrity check for every script on payment pages, plus a mechanism that detects unauthorised changes to those pages and their HTTP headers;
authenticated internal vulnerability scans, so that scanners log in and see more than the outside of a system;
automated mechanisms to review audit logs, instead of relying on people reading them;
anti-phishing mechanisms to protect personnel;
targeted risk analyses to justify how often certain activities are performed.

Version 4.0.1 then clarified wording, for example that the one-month deadline for installing security patches applies to critical vulnerabilities, and added notes about phishing-resistant authentication factors.

Lesson 4 – How it works in practice

Step 1: understand the payment flows

Before any control can be designed, an organisation needs to know where account data actually goes. The standard requires current network diagrams and data-flow diagrams that show all account data flows across systems and networks. Producing them usually means talking to finance, customer service, e-commerce and IT teams and asking simple questions: How do customers pay? Where is the card number typed? Which systems see it? Where is it stored, even temporarily? Who can export it?

This discovery step often brings surprises: card numbers in customer-service ticket notes, call recordings, spreadsheets used for refunds, debug logs, backups or email inboxes. Many organisations run a data discovery tool across file shares and databases to find PANs they did not know they had.

Step 2: determine and minimise scope

Scope is the set of system components, people and processes that must meet PCI DSS. The organisation must document and confirm its scope at least once every twelve months and after significant changes; service providers must confirm it every six months. Figure 3 shows the basic decision.

Figure 3 – Scoping decision: systems that handle account data form the CDE, systems that can reach or influence it are also in scope, and only fully isolated systems are out of scope.

Systems that are not in the CDE can still be in scope. A directory server that authenticates CDE administrators, a jump host, a patch server, a logging platform and a build pipeline that deploys the payment application can all affect the security of the CDE. If they were compromised, an attacker could reach card data. They are therefore "connected-to" or "security-impacting" systems and need the relevant requirements.

The cheapest control is not having the data at all. Organisations reduce scope in three main ways:

Elimination – stop storing PANs that nobody needs, delete historical data and remove card fields from forms that do not require them.
Outsourcing – use a payment page hosted by a PCI DSS compliant payment service provider, so that the card number never touches the merchant's servers. The merchant still has responsibilities, for example for the website that sends customers to that page, but far fewer.
Isolation – put the remaining CDE in a separate network or cloud account with tightly controlled connections, and prove with penetration testing that the segmentation works.

Technologies such as tokenisation and validated point-to-point encryption (P2PE) for card terminals help too. With P2PE, card data is encrypted inside a validated terminal and can only be decrypted by the solution provider, so the merchant's own network never sees readable card data.

Step 3: assign responsibilities, including to providers

Almost every organisation relies on third parties: a cloud platform, a payment gateway, a managed firewall service. PCI DSS asks the organisation to keep a list of these providers, to have written agreements in which each provider acknowledges its responsibility for the account data it handles, to check its compliance status at least once a year, and to know exactly which requirements are managed by the provider, by the organisation, or shared. This is usually recorded in a responsibility matrix.

A common misunderstanding is "our cloud provider is PCI DSS compliant, so we are too". The provider's compliance covers the parts it manages, such as the physical data centre and the underlying hypervisor. The customer remains responsible for its own configuration, access management, logging and application security on top of that platform.

Step 4: implement and operate the controls

With scope and responsibilities clear, teams implement the twelve requirements for every in-scope component. In practice this is a set of ongoing activities, not a one-off project: reviewing firewall rules, patching, managing user access, reviewing logs, scanning, testing incident response and training staff. Some activities have fixed frequencies set by the standard, such as scanning at least once every three months. Others let the organisation choose a frequency based on a targeted risk analysis, a short documented analysis of the threats an activity addresses and how often it must happen to be effective.

Step 5: keep it "business as usual"

The standard explicitly encourages organisations to build PCI DSS activities into normal operations so that security does not collapse between annual assessments. Examples include automated alerts when a firewall rule changes, access reviews scheduled in the ticketing system, configuration drift detection in infrastructure-as-code pipelines and dashboards that show patch status. Service providers have additional duties, such as reviewing at least every three months that personnel are following security procedures.

Key roles inside the organisation

Executive sponsor – provides budget and accepts responsibility for the protection of account data. Service providers must formally assign this responsibility at executive level.
PCI programme owner – coordinates scope, evidence and assessments, often within security or compliance.
Control owners – engineers and managers who run the day-to-day activities for each requirement.
Incident response team – follows the documented plan when a suspected compromise of account data occurs, including notifying the acquirer and brands as their rules require.

Lesson 5 – Assessment, validation and compliance

Who decides what you must do

PCI SSC writes the standard, but it does not tell individual companies how to validate. That is decided by the card brands, usually communicated through the acquirer for merchants. Each brand groups merchants and service providers into levels, mostly based on annual transaction volume, and sets the validation method for each level. The largest merchants and service providers generally need an annual assessment by a QSA (or, where the brand allows, by a trained ISA), while smaller merchants can usually complete a self-assessment. Thresholds and rules differ between brands and can change, so an organisation should always confirm its level with its acquirer or the brands rather than rely on a summary table.

Figure 4 – Validation paths: depending on its level, an entity is assessed by a QSA or ISA or completes a Self-Assessment Questionnaire, then submits an Attestation of Compliance and, where required, passing ASV scan reports.

The documents of an assessment

Report on Compliance (ROC) – a detailed report, written by the assessor using the Council's template, that records for every requirement what was tested, what evidence was seen and the result. Each requirement is reported as in place, not applicable, not tested or not in place.
Self-Assessment Questionnaire (SAQ) – a questionnaire that eligible merchants and service providers complete themselves. There are several SAQ types, each tailored to a payment channel. For example, SAQ A is for card-not-present merchants that have fully outsourced all account data functions, SAQ A-EP is for e-commerce merchants whose website controls or can affect the payment page, SAQ B and B-IP cover certain standalone terminals, SAQ C-VT covers manual entry into a virtual terminal through a browser, SAQ P2PE is for merchants using a validated P2PE solution, and SAQ D is the full set for everyone else (with separate versions for merchants and service providers).
Attestation of Compliance (AOC) – a short declaration, signed by the entity and, where applicable, the assessor, that summarises the result. The AOC is what an acquirer or a customer of a service provider usually asks to see.
ASV scan reports – results of external vulnerability scans by an Approved Scanning Vendor, needed at least once every three months. A scan "passes" only when no vulnerabilities at or above the failing threshold set by the Council's ASV programme remain; failing results must be fixed and rescanned.

Choosing the wrong SAQ is one of the most frequent mistakes. Each SAQ lists eligibility criteria, and a merchant that does not meet them all must use another one. If in doubt, the acquirer has the final word.

Assessment approaches: defined, customized and compensating controls

For each requirement, an organisation can meet it in one of two ways:

Defined approach – the traditional way: implement the requirement as written, and the assessor follows the defined testing procedures. This is the right choice for most organisations and the only option for those validating with an SAQ.
Customized approach – new in version 4. Most requirements state a customized approach objective, the security outcome the requirement intends. A mature organisation can design its own control to meet that objective, document it in a controls matrix, perform a targeted risk analysis for it and show that it works. The assessor then designs testing procedures specific to that control. It offers flexibility for innovative technology, but it demands more documentation and more assessor effort, not less.

Separately, compensating controls exist for a narrower situation: the organisation cannot meet a requirement as stated because of a legitimate and documented technical or business constraint, such as a legacy system that cannot support a feature. A compensating control must meet the intent and rigour of the original requirement, provide similar protection, go above and beyond other PCI DSS requirements, and match the extra risk created by not meeting the original requirement. It is documented on the compensating controls worksheet and must be re-validated at every assessment. In practice, treat a compensating control as a bridge for as long as the constraint lasts, not as a design choice.

What an assessor actually does

An assessor examines documents, interviews people, observes processes and inspects system configurations. Rather than test every single system, the assessor may test a representative sample, but the organisation must apply the controls to all in-scope components. Evidence must cover the whole assessment period where requirements are periodic: if quarterly scans are required, the assessor will ask for passing scans from each of the last four quarters; for an entity's first assessment, a passing most recent scan plus a documented process for quarterly scanning is normally accepted.

Compliance is annual, security is continuous

Validation is usually annual, but most requirements describe activities that happen continuously or at set intervals during the year. If a breach is suspected, the brands may require a PCI Forensic Investigator (PFI), a firm qualified by the Council, to determine what happened. Findings that the organisation was not actually meeting requirements at the time of a breach can have serious consequences, set by the brands and passed on through the acquirer. That is why "compliant on the day of the assessment" is not a sufficient goal.

Figure 5 – The yearly compliance cycle: scoping, gap assessment, remediation, validation and reporting, then continuous operation until the next change or review.

Lesson 6 – Worked example

To tie the concepts together, follow a fictional company, Harbourline Outfitters, through its first serious PCI DSS project. Harbourline sells outdoor equipment through an online shop, twelve physical stores and a small telephone sales team. Its acquirer has told it that, based on its transaction volume, it may validate with self-assessment questionnaires, and that the deadline for its next Attestation of Compliance is in nine months.

Step 1: discover the data

The new security lead, Amira, starts with interviews and a data-discovery scan. She learns that:

the online shop uses a payment form built by Harbourline's own developers, which sends card numbers through Harbourline's web servers to the payment gateway;
the order database keeps the full PAN and expiry date "in case we need to refund", encrypted with a key stored in the application's configuration file;
telephone staff type card numbers into the same web form while customers read them out, and calls are recorded for quality purposes;
the stores use card terminals connected to the store network, which also carries guest Wi-Fi and back-office PCs;
a scan of file shares finds a spreadsheet with several hundred card numbers created by a finance employee years ago.

On this picture, the CDE is huge: web servers, the order database and its backups, the call recording platform, the store networks and much of the corporate network, which has no segmentation. Harbourline would need the full SAQ D, and many requirements would be hard to meet in nine months.

Step 2: shrink the scope

Amira proposes a scope-reduction plan to the executive sponsor, the operations director:

Delete what is not needed. The payment gateway can refund a transaction using its own transaction reference, so stored PANs are not needed. The team securely deletes the PAN column, the historical backups that hold it (following the retention policy) and the finance spreadsheet.
Outsource the online payment page. Developers replace the home-built form with the gateway's hosted payment page. Card numbers are now entered on the gateway's systems; Harbourline's servers only receive a token and the payment result.
Change the telephone process. Telephone orders move to a service in which customers key their card number on their phone keypad and the tones are captured by a compliant provider, so agents never hear or see the number and recordings contain no card data.
Replace store terminals. The stores switch to a validated P2PE solution, so card data is encrypted inside the terminal and the store network never carries readable card data.

Step 3: deal with what remains

Scope does not disappear completely. Harbourline's web server still serves the pages that redirect customers to the hosted payment page. If an attacker changed that redirect, customers could be sent to a fake payment page. Amira therefore keeps the web platform within the requirements that apply to it: hardened configuration, prompt patching, multi-factor authentication for administrators, change control, monitoring and quarterly external scans by an ASV. For the stores she adds terminal inspection procedures, so that staff check devices regularly for tampering or substitution, and training so they recognise suspicious "technicians".

Step 4: manage the providers

Harbourline now relies on three key service providers: the payment gateway, the telephone payment provider and the P2PE solution provider. Amira collects each provider's current Attestation of Compliance, checks that the services Harbourline uses are covered by it, confirms written acknowledgements of responsibility and builds a responsibility matrix. She schedules an annual check of each provider's status.

Step 5: choose the validation documents

Working with the acquirer, Amira confirms which questionnaires apply. The e-commerce channel, with a fully outsourced payment page and no card data on Harbourline's systems, may meet the eligibility criteria for SAQ A. The stores, using only the validated P2PE terminals, may use SAQ P2PE. The telephone channel is reviewed with the acquirer to decide how it is reported. Amira reads each eligibility list carefully and documents why Harbourline meets every criterion, because the questionnaire is only valid if all of them are true.

Step 6: build the evidence and keep it alive

Each applicable requirement gets an owner and a source of evidence that is produced as part of normal work: tickets for user access reviews, the scanning vendor's quarterly reports, configuration baselines in version control, training records from the learning platform and the incident response plan with notes from a tabletop exercise. A simple calendar shows quarterly and annual tasks. Nine months later Harbourline submits its questionnaires and AOC on time.

What the example shows

Scope is the biggest lever: deleting data and outsourcing removed most of the work, and also most of the risk.
Outsourcing does not remove all responsibility: the website that leads to the payment page and the provider relationships still matter.
Choosing the right questionnaire depends on facts, and those facts must remain true all year. If a developer later adds an embedded script to collect card data directly, the eligibility for SAQ A is lost.
Evidence that comes from everyday tools is cheaper and more convincing than documents written for the assessor.

Lesson 7 – Relationship to other standards and frameworks

PCI DSS is often implemented alongside other security frameworks. Understanding the differences helps avoid duplicated effort and false assumptions.

Other PCI SSC standards

The Council maintains a family of standards, each for a different part of the payment ecosystem. PCI DSS applies to the organisations that handle account data. Others apply to products and specialised operations: the PIN Transaction Security (PTS) requirements for the security of payment terminals, the P2PE standard for point-to-point encryption solutions, the PCI PIN Security requirements for handling PINs, the 3-D Secure standards for the infrastructure behind online cardholder authentication, the card production standards for card manufacturers and personalisers, and the Software Security Framework (the Secure Software Standard and the Secure Software Lifecycle Standard), which replaced the older PA-DSS for payment software. Using products validated against these standards can reduce the PCI DSS effort of the organisation that deploys them, but it does not replace PCI DSS.

Comparison with general security frameworks

Framework	Owner	Focus	Nature	Relationship to PCI DSS
PCI DSS v4.0.1	PCI Security Standards Council	Protection of payment account data and the systems that handle it	Prescriptive requirements, validated yearly via ROC or SAQ; enforced by contracts with brands and acquirers	The subject of this course
ISO/IEC 27001	ISO and IEC	A risk-based information security management system for any information	Management system standard with third-party certification	A good ISMS can host the PCI DSS programme, but an ISO certificate does not demonstrate PCI DSS compliance; the CDE still needs its specific controls and validation
NIST Cybersecurity Framework 2.0	US National Institute of Standards and Technology	Outcomes for managing cybersecurity risk across an organisation	Voluntary framework, no certification	Useful for overall strategy and maturity; PCI DSS requirements can be mapped to its outcomes but are far more specific
SOC 2	AICPA	Controls at a service organisation relevant to security, availability, processing integrity, confidentiality and privacy	Independent auditor's attestation report	Customers may accept SOC 2 for general assurance, but card brands and acquirers expect PCI DSS validation for services that touch account data
PCI P2PE	PCI Security Standards Council	Security of point-to-point encryption solutions for card terminals	Validation of solutions by specialised assessors	A merchant using a listed P2PE solution may qualify for a much smaller questionnaire

A practical approach for organisations with several frameworks is to build one common control set, map each control to the requirements it satisfies, and collect evidence once. PCI DSS will usually be the most specific source for controls inside the CDE, for example on log retention, scanning frequency and authentication, while broader frameworks guide governance and risk management elsewhere.

Privacy laws

Card data is also personal data in many jurisdictions, so privacy laws can apply at the same time. Meeting PCI DSS helps with the security obligations in those laws, but it does not cover privacy topics such as lawful basis, transparency or data subject rights. Equally, a breach notification obligation under a privacy law exists independently of the brands' own notification rules.

Common pitfalls and best practices

Pitfalls

Underestimating scope. Forgetting connected-to and security-impacting systems, such as identity services, jump hosts, CI/CD pipelines and log platforms, or forgetting card data hidden in tickets, recordings and spreadsheets.
Treating compliance as a yearly event. Rushing scans, access reviews and training into the weeks before an assessment, then letting controls drift until the next one.
Storing sensitive authentication data. Logging full requests from a payment API, including the security code, or keeping track data in debug files. Encryption does not make this acceptable.
Assuming a provider's compliance covers you. Relying on a cloud or gateway provider's attestation without checking which services it covers and which requirements remain yours.
Picking an SAQ that does not fit. Completing a short questionnaire when the eligibility criteria are not all met, often because the website hosts its own payment form or loads scripts into the payment page.
Weak segmentation. Claiming systems are out of scope while flat networks, shared admin accounts or broad cloud permissions still connect them to the CDE, and never testing the segmentation.
Using compensating controls as a permanent workaround. Keeping an outdated system for years behind a compensating control instead of planning its replacement.

Best practices

Minimise first. Before building any control, ask whether the data is needed at all; use tokens, hosted payment pages and validated P2PE to keep card data off your systems.
Keep diagrams and inventories current. Update data-flow diagrams, network diagrams and the system inventory as part of change management, not once a year.
Automate evidence. Use configuration management, log tooling, ticketing and infrastructure-as-code so that proof of control operation is a by-product of normal work.
Use a responsibility matrix. For each service provider, record who does what for each requirement and review it when contracts or services change.
Test segmentation and incident response. Run segmentation penetration tests at the required intervals and practise the incident plan with realistic scenarios.
Engage the acquirer and assessor early. Confirm level, validation method and SAQ eligibility before the deadline, and discuss any planned customized-approach controls with the assessor well in advance.
Train people for their role. Developers need secure coding and payment-page script awareness, store staff need terminal inspection skills, and everyone needs phishing awareness.

Summary and key takeaways

PCI DSS is owned by the PCI Security Standards Council, enforced through card brands and acquirers, and applies to any entity that stores, processes or transmits account data or can affect its security.
The current and only active version is v4.0.1; all of its requirements, including those once future-dated, have applied since 31 March 2025.
Account data consists of cardholder data, which may be stored if protected, and sensitive authentication data, which must not be retained after authorisation.
The standard has twelve principal requirements grouped under six goals, plus appendices for multi-tenant providers, legacy terminal protocols, designated entities, compensating controls and the customized approach.
Scope includes the CDE and every system that can connect to it or affect its security; eliminating data, outsourcing and segmentation are the main ways to reduce it.
Validation depends on the level set by brands and acquirers: a ROC by a QSA or ISA for larger entities, an SAQ for many smaller merchants, an AOC in both cases and quarterly ASV scans where required.
The defined approach suits most organisations; the customized approach offers flexibility for mature ones; compensating controls bridge genuine constraints temporarily.
Compliance is validated once a year, but security has to be operated every day, with evidence produced by normal work.

Reflection questions

Draw the payment flows of an organisation you know (or a fictional one). Where does the card number enter, which systems see it, and where might it be stored without anyone noticing?
Pick one system that is not in your CDE. What would you need to show an assessor to convince them it is out of scope rather than connected or security-impacting?
Your company is about to move its payment application to a public cloud platform. Which PCI DSS responsibilities will shift to the provider, which stay with you, and how will you document the split?
A business unit wants to keep card numbers to offer "one-click reorder". What alternatives would you propose, and how would each change the scope and the validation effort?
Think of a control in your environment that is hard to meet exactly as written. Would the customized approach, a compensating control or a redesign be the better response, and why?