PCI DSS, protect card data and keep taking payments
Find out which level and questionnaire apply to you, and what to do before your assessment.
Official sources
Use these official places to read the text and find the latest version.
Official website
The PCI Security Standards Council publishes the standard, forms and guides.
Visit pcisecuritystandards.org ↗Get the document
The standard and self-assessment questionnaires are free in the council’s document library.
Open the official page ↗What PCI DSS is
The Payment Card Industry Data Security Standard sets security rules for anyone who stores, processes or sends card data. It is set by the card brands through the PCI Security Standards Council.
You prove compliance with a self-assessment questionnaire or a report from a qualified assessor, depending on your size and setup.
How PCI DSS got to where it is today
The milestones that changed what organisations have to do.
PCI DSS 1.0
The major card brands release a single common standard.
Version 3.0
Greater focus on making security routine, not a yearly exercise.
Version 4.0
A major update, with new and customised approaches to meeting requirements.
Future-dated rules apply
The extra v4.0 requirements become mandatory after 31 March 2025.
Dates are for orientation. The official website holds the authoritative record.
Do you need it?
If any of these sound familiar, probably yes.
You take card payments online or in person.
You store or handle card numbers.
Your bank asks for a compliance form.
You want to reduce how much card data you touch.
What it asks of you
The requirements fall into six areas.
Secure network
Firewalls and safe configurations.
Protect account data
Store less, encrypt what you keep.
Vulnerability management
Patch and scan regularly.
Access control
Limit who can see card data.
Monitor and test
Log, scan and test networks.
Policies
Written policy and awareness.
The 12 requirements and 63 sub-requirement themes, in 6 goals
Twelve requirements under six goals protect payment card data. Each breaks into sub-requirements that say what to document, build and test.
12 requirements · 63 requirements
Build and maintain a secure network and systemsNetwork controls and secure settings.2 requirements · 8 requirements
R1Requirement 1: Install and maintain network security controlsControl what can reach your payment systems.5 requirements
- 1.1
Define, document and assign ownership of the processes for network security controls.
What you do
- Write the procedure and name an owner
- 1.2
Configure and maintain network security controls, with changes approved and rules reviewed.
What you do
- Keep a config standard and review rules every six months
- 1.3
Restrict network access into and out of the card data environment to what is needed.
What you do
- Deny by default and allow only documented flows
- 1.4
Control connections between trusted and untrusted networks.
What you do
- Block direct public access to internal systems and use a DMZ
- 1.5
Manage risks from devices that connect to both untrusted networks and the card data environment.
What you do
- Add personal firewalls to laptops that connect from outside
Evidence to keep
- Network and data flow diagrams
- Firewall rule reviews
- Network security control standards
R2Requirement 2: Apply secure configurations to all system componentsRemove default settings and harden systems.3 requirements
- 2.1
Define, document and assign ownership of the processes for secure configurations.
What you do
- Write a build standard and assign an owner
- 2.2
Configure system components securely, change vendor defaults and keep only needed services.
What you do
- Apply a recognised baseline and disable default accounts
- 2.3
Secure wireless environments, changing defaults and using strong encryption.
What you do
- Change default Wi-Fi keys and use WPA2 or WPA3 with a strong passphrase
Evidence to keep
- Hardening standards
- Configuration checklists
- Inventory of system services
Protect account dataProtect stored and transmitted card data.2 requirements · 9 requirements
R3Requirement 3: Protect stored account dataKeep as little card data as possible and make what you keep unreadable.7 requirements
- 3.1
Define, document and assign ownership of the processes for protecting stored account data.
What you do
- Write the procedure and name an owner
- 3.2
Keep storage of account data to a minimum with defined retention and secure deletion.
What you do
- Delete old card data on a schedule and prove it
- 3.3
Never keep sensitive authentication data after authorisation.
What you do
- Do not store security codes or full track data after approval
- 3.4
Limit display of the card number and control who can see more than the permitted digits.
What you do
- Mask the number on screens and restrict full view to approved roles
- 3.5
Make the card number unreadable wherever it is stored.
What you do
- Use strong encryption, tokenisation or truncation
- 3.6
Protect the cryptographic keys that guard stored card data.
What you do
- Store keys separately and limit who can access them
- 3.7
Document and apply key management processes across the key lifecycle.
What you do
- Define key generation, rotation, retirement and split knowledge
Evidence to keep
- Data retention policy
- Data discovery results
- Key management procedures
R4Requirement 4: Protect cardholder data with strong cryptography during transmission over open, public networksEncrypt card data when it travels.2 requirements
- 4.1
Define, document and assign ownership of the processes for protecting transmitted card data.
What you do
- Write the procedure and name an owner
- 4.2
Protect the card number with strong cryptography whenever it is sent over open networks.
What you do
- Use current TLS, keep a certificate inventory and never send card numbers in plain email
Evidence to keep
- Inventory of trusted keys and certificates
- Transmission protocol configuration
- Scan results for TLS settings
Maintain a vulnerability management programmeKeep systems protected against malware and flaws.2 requirements · 9 requirements
R5Requirement 5: Protect all systems and networks from malicious softwareStop and detect malware and phishing.4 requirements
- 5.1
Define, document and assign ownership of the processes for malware protection.
What you do
- Write the procedure and name an owner
- 5.2
Prevent, detect and remove malware on all in-scope systems.
What you do
- Deploy endpoint protection and review which systems are exempt
- 5.3
Keep anti-malware mechanisms active, current and unable to be disabled by users.
What you do
- Lock settings and send alerts to a central console
- 5.4
Use anti-phishing mechanisms to protect users.
What you do
- Enable email filtering and link protection
Evidence to keep
- Anti-malware configuration
- Scan logs
- Phishing protection settings
R6Requirement 6: Develop and maintain secure systems and softwareBuild secure software and fix flaws quickly.5 requirements
- 6.1
Define, document and assign ownership of the processes for secure development and maintenance.
What you do
- Write the procedure and name an owner
- 6.2
Develop bespoke and custom software securely.
What you do
- Train developers and review code for common flaws
- 6.3
Identify and address security vulnerabilities.
What you do
- Subscribe to vendor alerts and patch critical items within a month
- 6.4
Protect public-facing web applications against attacks.
What you do
- Use a web application firewall or regular assessments
- 6.5
Manage changes to all system components securely.
What you do
- Require approval, testing and a back-out plan for each change
Evidence to keep
- Secure development procedures
- Change records
- Vulnerability and patch records
Implement strong access control measuresLimit access by need, identity and physical presence.3 requirements · 14 requirements
R7Requirement 7: Restrict access to system components and cardholder data by business need to knowGive access only where the job needs it.3 requirements
- 7.1
Define, document and assign ownership of the processes for restricting access.
What you do
- Write the procedure and name an owner
- 7.2
Define and manage access appropriately, by need and with least privilege.
What you do
- Review all user and system access every six months
- 7.3
Manage access to systems and data through access control systems.
What you do
- Use central access control and deny by default
Evidence to keep
- Access control policy
- Access reviews
- Role and privilege matrix
R8Requirement 8: Identify users and authenticate access to system componentsMake sure every user is known and properly authenticated.6 requirements
- 8.1
Define, document and assign ownership of the processes for identifying and authenticating users.
What you do
- Write the procedure and name an owner
- 8.2
Manage user identification and accounts through their lifecycle.
What you do
- Give each person a unique ID and remove leavers promptly
- 8.3
Establish and manage strong authentication for users and administrators.
What you do
- Use long passwords and protect them in a password manager
- 8.4
Use multi-factor authentication to secure access into the card data environment.
What you do
- Require MFA for all admin and remote access
- 8.5
Configure multi-factor authentication systems to resist misuse.
What you do
- Prevent bypass and replay and require two different factor types
- 8.6
Manage use of application and system accounts and their authentication.
What you do
- Prevent interactive login for service accounts and rotate their secrets
Evidence to keep
- User account lists
- Password and MFA configuration
- Third-party access records
R9Requirement 9: Restrict physical access to cardholder dataControl who can physically reach card data.5 requirements
- 9.1
Define, document and assign ownership of the processes for physical access controls.
What you do
- Write the procedure and name an owner
- 9.2
Use physical access controls to manage entry into facilities and systems with card data.
What you do
- Use badges or locks and log entry to sensitive areas
- 9.3
Authorise and manage physical access for personnel and visitors.
What you do
- Issue visitor badges, escort visitors and keep logs
- 9.4
Securely store, handle and distribute media with card data.
What you do
- Lock away media and track movement
- 9.5
Protect payment terminals from tampering and substitution.
What you do
- Keep a terminal list and inspect devices on a schedule
Evidence to keep
- Visitor logs
- Media inventory
- Terminal inspection records
Regularly monitor and test networksLog, scan and test to find problems.2 requirements · 13 requirements
R10Requirement 10: Log and monitor all access to system components and cardholder dataKeep logs and review them.7 requirements
- 10.1
Define, document and assign ownership of the processes for logging and monitoring.
What you do
- Write the procedure and name an owner
- 10.2
Record audit logs to support detection and investigation.
What you do
- Log user actions, admin actions and failed access attempts
- 10.3
Protect audit logs from destruction and tampering.
What you do
- Send logs to a central, write-restricted store
- 10.4
Review audit logs to identify anomalies or suspicious activity.
What you do
- Use automated tools and review key logs daily
- 10.5
Keep audit log history for at least 12 months, with three months readily available.
What you do
- Set retention and test that old logs can be retrieved
- 10.6
Synchronise time on all systems.
What you do
- Use trusted time sources for every system
- 10.7
Detect, alert on and fix failures of critical security control systems promptly.
What you do
- Alert when logging, antivirus or firewall services stop
Evidence to keep
- Log configuration
- Log review records
- Time synchronisation settings
R11Requirement 11: Test security of systems and networks regularlyScan, test and watch for changes.6 requirements
- 11.1
Define, document and assign ownership of the processes for security testing.
What you do
- Write the procedure and name an owner
- 11.2
Identify and manage wireless access points.
What you do
- Run regular wireless checks and keep an authorised list
- 11.3
Find and address external and internal vulnerabilities through scans.
What you do
- Scan quarterly and after major changes, using approved vendors for external scans
- 11.4
Run external and internal penetration tests regularly and after major change.
What you do
- Test at least annually and retest after fixes
- 11.5
Detect and respond to network intrusions and unexpected file changes.
What you do
- Use intrusion detection and file integrity monitoring on critical files
- 11.6
Detect and respond to unauthorised changes on payment pages.
What you do
- Monitor scripts and headers on payment pages and alert on changes
Evidence to keep
- Scan and pen test reports
- Wireless scan records
- Change detection settings
Maintain an information security policyPolicies, roles, suppliers and incident response.1 requirement · 10 requirements
R12Requirement 12: Support information security with organisational policies and programmesGovernance, awareness, suppliers and incident response.10 requirements
- 12.1
Maintain and review an information security policy known to all personnel.
What you do
- Publish the policy and review it at least once a year
- 12.2
Define and apply acceptable use rules for end-user technologies.
What you do
- Set rules for laptops, phones and removable media
- 12.3
Identify and manage risks formally, including targeted risk analysis where required.
What you do
- Do an annual risk assessment and record decisions
- 12.4
Service providers manage and show responsibility for their PCI DSS compliance.
What you do
- Assign executive ownership and review controls quarterly
- 12.5
Document and confirm the scope of PCI DSS coverage.
What you do
- Keep data flow diagrams and confirm scope every year
- 12.6
Run formal security awareness training for all personnel.
What you do
- Train at joining and yearly, including phishing
- 12.7
Screen potential personnel before hire to limit risk.
What you do
- Do background checks where law allows
- 12.8
Manage risk from third-party service providers.
What you do
- Keep a supplier list, written agreements and annual checks
- 12.9
Third-party providers support their customers' compliance.
What you do
- Give customers their responsibility matrix and compliance status
- 12.10
Respond to suspected and confirmed incidents immediately.
What you do
- Keep a tested response plan with named roles and card brand contacts
Evidence to keep
- Security policy
- Risk assessment
- Training records
- Incident response plan
- Supplier responsibility matrix
Nothing matches. Clear the search or pick another goal.
Outcomes and implementation examples are from PCI DSS v4.0.1, PCI Security Standards Council, published by NIST. Descriptions of what to do and the evidence lists are our own plain-English guidance. Check the official source for the authoritative text.
Your path to getting started
Five steps from first look to ready. Effort depends on your size and starting point.
- 1
Find your scope
Where card data flows.
- 2
Reduce scope
Use a payment provider so you hold less data.
- 3
Pick your questionnaire
Based on how you accept cards.
- 4
Fix gaps
Against the requirements.
- 5
Attest
Self-assess or use an assessor.
How Optimus GRC helps
Each area maps to a part of the platform, so the work and the evidence sit together.
| What it asks | What you do in Optimus GRC |
|---|---|
| Secure network | Configuration records |
| Protect account data | Data flow records |
| Vulnerability management | Scan schedules and results |
| Access control | Access reviews |
| Monitor and test | Log reviews and test records |
| Policies | Policy management |
Free PCI DSS readiness checklist
A one-page PDF you can print or share with your team. No sign-up needed.
Download the checklist (PDF)- Cardholder data flow template
- Scope worksheet
- Vulnerability scan log
- Policy starter
Share or cite this page
Writing about PCI DSS? You are welcome to link to this guide. Copy the link below.
<a href="/frameworks/pci-dss/">PCI DSS explained in plain English - Optimus CyberX</a>Common questions
Is it law?
No. It is a contractual standard, but breaking it can lead to fines and loss of the right to take cards.
Which level are we?
It depends on yearly card volume. Your acquiring bank confirms.
Can we avoid it?
Not if you take cards, but using a hosted payment page reduces your scope.
Who assesses us?
Small merchants often self-assess. Larger ones use a Qualified Security Assessor.
Related frameworks
See how ready you are for PCI DSS
Answer questions across every area. We email you a report showing where you comply and where you do not.