The 12 PCI DSS Requirements Explained

Why it matters

A payment system is safer when its boundaries are intentional. Strong network controls reduce unnecessary exposure, limit lateral movement after an incident, and make it possible to explain which systems can communicate with the cardholder data environment.

What to consider

• Document the cardholder data environment, connected systems, trust boundaries, and data flows before deciding where controls belong.
• Use firewalls or equivalent technologies such as cloud security groups, network ACLs, or service-level controls to regulate ingress and egress traffic.
• Define rules that are specific, justified, reviewed, and consistent with a deny-by-default approach where practical.
• Consider segmentation, remote administration paths, wireless networks, third-party connections, and administrative access when mapping the boundary.

Why it matters

Attackers routinely look for predictable defaults and avoidable functionality. Secure configuration makes the intended security posture explicit and reduces the number of ways a system can be misused or compromised.

What to consider

• Remove or change vendor-supplied defaults, including passwords, credentials, keys, unnecessary accounts, and insecure configuration settings.
• Maintain an inventory of in-scope systems, operating systems, applications, cloud resources, network devices, and other components.
• Define hardening baselines for servers, endpoints, databases, containers, wireless infrastructure, and cloud services as applicable.
• Disable unnecessary services, protocols, ports, and functionality, and document exceptions that must remain enabled.

Why it matters

A breach cannot expose data that is not stored. When retention is necessary, strong protection and disciplined key management reduce the impact of unauthorized access to databases, backups, logs, exports, and developer environments.

What to consider

• Identify where the primary account number (PAN) and other account data are collected, stored, copied, backed up, exported, or displayed.
• Set retention limits and securely dispose of data when the business, legal, or contractual purpose ends.
• Use masking or truncation when a full PAN is not needed, and use approved cryptographic protections and key-management processes when storage is necessary.
• Distinguish sensitive authentication data from account data. Sensitive authentication data has stricter handling expectations and generally must not be retained after authorization, even if encrypted.

Why it matters

Data in transit can pass through networks and systems outside the organization’s control. Strong transport protection makes interception materially harder and helps prevent an attacker from altering a payment request or response without detection.

What to consider

• Use current, approved cryptographic protocols and configurations for browser, API, mobile, wireless, administrative, and service-to-service traffic where account data is transmitted.
• Validate certificates and endpoints, manage certificate lifecycles, and prevent downgrade or insecure fallback behavior.
• Identify legacy protocols, plaintext channels, debug endpoints, and third-party integrations that may bypass the intended encrypted path.
• Treat APIs, webhooks, payment pages, customer portals, and cloud-to-cloud connections as data flows that need an explicit protection decision.

Why it matters

Malicious software can steal credentials, alter payment pages, capture data, disable logging, or provide a bridge into other systems. Controls should reflect the threats and technologies present in the environment.

What to consider

• Identify systems that require anti-malware or equivalent protections and document the rationale for systems where a different approach is used.
• Keep detection engines, signatures, agents, and policies current, and make sure alerts reach someone who can act on them.
• Include phishing, malicious scripts, ransomware, web shells, supply-chain risk, and endpoint misuse in the threat model—not only traditional file-based viruses.
• Periodically evaluate whether protections remain effective as operating systems, workloads, and attack techniques change.

Why it matters

Payment environments change constantly. A secure network can still be undermined by a vulnerable dependency, a rushed release, an insecure API, or a change that bypasses review. Secure development and patch management make security part of delivery rather than an afterthought.

What to consider

• Maintain a vulnerability-management process that covers operating systems, applications, libraries, containers, cloud services, and third-party components.
• Prioritize remediation according to exploitability, exposure, business impact, and whether a component can affect the cardholder data environment.
• Use secure software-development practices such as requirements review, code review, testing, change control, secrets protection, and separation of development and production.
• Review web applications, APIs, React or Next.js applications, CI/CD pipelines, package registries, build runners, and infrastructure-as-code as parts of the delivery system.

Why it matters

A compromised or misused account is less damaging when it cannot reach unrelated payment systems or data. Least privilege also makes access activity easier to interpret and investigate.

What to consider

• Define roles and permissions for employees, contractors, administrators, developers, support teams, applications, and service accounts.
• Separate ordinary and privileged access where practical, and control emergency or break-glass access with additional review.
• Connect access to an approved business need and review it when a person changes jobs, leaves, or no longer supports the system.
• Use centralized access-control systems and consistent authorization decisions across cloud, SaaS, database, application, and network layers.

Why it matters

Identification answers who is requesting access; authentication verifies that claim; authorization decides what the verified identity may do. Keeping those concepts clear creates accountability and prevents shared access from hiding responsibility.

What to consider

• Use unique IDs for people and systems, with controlled processes for creation, modification, suspension, and removal.
• Protect passwords or passphrases, apply appropriate authentication factors, and use MFA where required by the environment and access risk.
• Pay particular attention to privileged, remote, vendor, API, service, emergency, and inactive accounts.
• Do not use shared accounts when an individual identity can be provided; where a technical shared identity is unavoidable, add compensating attribution and monitoring controls.

Why it matters

A person who can reach an unattended workstation, removable backup, server, or printed report may bypass logical controls. Physical access also matters during equipment disposal, visitor access, maintenance, and incident response.

What to consider

• Control access to offices, server rooms, network closets, workstations, payment terminals, media storage, and other relevant facilities.
• Use visitor procedures, badges, escort rules, physical access logs, and monitoring appropriate to the sensitivity of the location.
• Protect removable media and paper records, and securely destroy media or documents when they are no longer needed.
• For cloud environments, understand the provider’s physical-security responsibilities while retaining responsibility for your own offices, devices, media, and operational processes.

Why it matters

During an incident, memory and assumptions are unreliable. Authentication events, privileged actions, access attempts, administrative changes, and security alerts can show the sequence of events, scope the investigation, and support a defensible response.

What to consider

• Capture relevant authentication, privileged, access, administrative, security, and system events for in-scope components.
• Centralize or otherwise protect logs so an attacker cannot quietly alter the evidence by compromising one host.
• Synchronize timestamps with an approved time source and retain logs for the period required by the applicable standard, contracts, and risk decisions.
• Define review, alerting, escalation, investigation, and retention responsibilities instead of collecting logs without an operating process.

Why it matters

A design document cannot prove that a firewall rule, segmentation boundary, intrusion detection control, or change-detection process behaves as intended. Testing provides evidence about actual exposure and control effectiveness.

What to consider

• Use vulnerability scanning to identify known weaknesses and misconfigurations; scanning is not the same as a penetration test.
• Use penetration testing to exercise attack paths and validate whether weaknesses can be chained into meaningful impact, with scope and method appropriate to the environment.
• Consider internal, external, wireless, segmentation, intrusion-detection or prevention, and change-detection testing where applicable.
• Track findings through remediation, document risk decisions, and retest to confirm the fix rather than treating the report as the finish line.

Why it matters

People and vendors make daily decisions that affect payment security. A clear program assigns ownership, prepares the organization to respond, and turns lessons from changes or incidents into better controls.

What to consider

• Maintain information-security policies, standards, acceptable-use rules, and procedures with named owners and review dates.
• Define roles and responsibilities for executives, technology teams, security, workforce members, service providers, and incident responders.
• Include risk analysis, security awareness, incident response, third-party management, employee responsibilities, and change governance.
• Review documentation and programs at least as often as applicable obligations require and whenever the environment, threats, or responsibilities change.