PCI DSS Requirements: 2025 Guide to Continuous Compliance

What Is PCI DSS? 

Payment card industry data security standard (PCI DSS) is a global framework developed to secure credit card transactions and protect sensitive cardholder data. It was introduced in 2004 by the major payment card brands—Visa, Mastercard, American Express, Discover, and JCB—to standardize security measures across organizations that handle branded credit cards. 

The PCI DSS provides a baseline for technical and operational procedures, covering everything from network architecture to software design, so organizations can mitigate the risk of data breaches and transaction fraud.

PCI DSS applies to any entity that stores, processes, or transmits cardholder data. This includes merchants, payment processors, financial institutions, and service providers of all sizes. The standard outlines security controls to build and maintain a secure environment, defend against cyber threats, and preserve consumer trust in electronic payment systems. Compliance with its requirements is verified through assessments, either by in-house staff or qualified security assessors (QSAs), depending on transaction volume and business type.

This is part of a series of articles about PCI DSS compliance

In this article:

• Is PCI DSS a Legal Compliance Requirement?
• The Importance of Continuous Compliance for PCI DSS
• PCI DSS: The 12 Requirements, Practical Steps, and How Continuous Compliance Helps

Is PCI DSS a Legal Compliance Requirement? 

PCI DSS is not a law, but rather an industry standard required by major payment card brands as part of their global compliance programs. Organizations that want to process, store, or transmit card payment data are contractually obligated to comply by agreements with their acquiring banks and payment networks. Failure to comply may result in severe penalties, including monetary fines, increased transaction fees, or termination of the ability to process card payments.

However, PCI DSS is often referenced or incorporated in regulations and data breach notification laws around the world. For instance, some national or state governments expect adherence to PCI DSS as a default best practice for protecting consumer financial information. 

In the event of a data breach, non-compliance can amplify legal exposure and reputational harm, as it demonstrates negligence in applying widely accepted security standards. Therefore, PCI DSS can be considered a de facto regulatory requirement, enforced through commercial agreements and regulatory references, if not always by explicit statutory law.

The Importance of Continuous Compliance for PCI DSS 

Achieving PCI DSS compliance is not a one-time event. It requires continuous attention because threats to cardholder data evolve constantly. New vulnerabilities in software, hardware, and infrastructure can introduce fresh risks, making it essential for organizations to maintain an ongoing compliance mindset.

One-time assessments may meet immediate requirements but do not guarantee long-term protection. Regular reviews, monitoring, and updates to security controls ensure that organizations remain aligned with the standard as the threat landscape changes. This includes patching systems promptly, reviewing access controls, and updating risk assessments.

Continuous compliance also demonstrates a proactive approach to security, which can reduce the likelihood and impact of a data breach. It helps build trust with partners, customers, and payment networks by showing that the organization prioritizes data protection, not just when audits are due, but as an integral part of its operations.

PCI DSS: The 12 Requirements, Practical Steps, and How Continuous Compliance Helps 

Requirement 1: Firewall Configuration

Organizations must establish a perimeter security strategy by deploying firewalls to control inbound and outbound traffic to and from the cardholder data environment (CDE). Firewalls must be configured to enforce access control policies based on business needs, ensuring that only authorized traffic is permitted. 

The requirement also mandates maintaining network documentation (like diagrams), reviewing firewall rules regularly, and ensuring rule sets follow least privilege principles. Wireless networks and connections from untrusted networks must be secured and segmented.

Practical steps:

• Identify network components: Document all system components, including routers, firewalls, switches, and wireless access points.
• Create network diagrams: Maintain updated diagrams showing cardholder data flows and network segmentation.
• Restrict traffic: Configure firewalls to block all inbound and outbound traffic that is not explicitly allowed. Use deny-all default policies.
• Control inbound/outbound rules: Only allow traffic necessary for business operations (e.g., port 443 for HTTPS).
• Segregate environments: Use firewalls to isolate the cardholder data environment (CDE) from the rest of the network.
• Review rules regularly: Conduct firewall rule reviews every six months to remove unnecessary rules and update configurations.
• Justify rules: Maintain documentation for every rule change, including its business justification.

How continuous compliance can help:

• Ensures firewall rules are updated in response to new threats or business changes.
• Enables early detection of misconfigurations or unauthorized access attempts.
• Supports timely auditing and documentation of changes for compliance reporting.

Requirement 2: Changing Vendor Defaults

This requirement emphasizes eliminating one of the most common weaknesses: unchanged vendor defaults. Devices like routers, firewalls, applications, operating systems, and POS systems come with default usernames, passwords, and security settings that are widely known and easily exploited by attackers. 

The requirement mandates changing these settings before system deployment, disabling unused features, and securing administrative interfaces. It also calls for hardening system configurations to remove unnecessary services and reduce attack surfaces.

Practical steps:

• Change defaults: Immediately change all default usernames and passwords (e.g., admin/admin).
• Disable unused accounts/services: Remove unnecessary default accounts and disable unused protocols or ports.
• Secure admin interfaces: Ensure management interfaces (e.g., web consoles, SSH) are not exposed to public networks.
• Configure security settings: Customize all security-related settings such as SNMP community strings and FTP banners.
• Harden systems: Follow system hardening guides like the CIS Benchmarks to minimize vulnerabilities.

How continuous compliance can help:

• Quickly identifies reintroduced or missed default settings during updates
• Maintains a hardened environment even as systems and devices are replaced or upgraded.
• Reinforces secure provisioning practices across teams and systems.

Requirement 3: Safeguarding Stored Data

Organizations must minimize and secure any cardholder data they retain. This includes primary account numbers (PAN), expiration dates, cardholder names, and service codes. Storage of sensitive authentication data (e.g., full track data, CVV, PIN) is strictly prohibited after authorization. 

If PANs are stored, they must be rendered unreadable via encryption, truncation, or tokenization. Strong key management controls are essential for encryption practices. This requirement applies to all media types (e.g., electronic, paper) and mandates retention policies and secure deletion procedures.

Practical steps:

• Limit data storage: Store only the minimum necessary data and purge old records regularly.
• Mask PAN: Display only the last four or first six digits of the PAN where full visibility isn’t required.
• Encrypt data: Use industry-accepted algorithms (e.g., AES-256, RSA) to encrypt cardholder data.
• Tokenize data: Use tokenization or truncation where full encryption isn’t feasible.
• Implement strong key management: Use secure key generation, storage, distribution, rotation, and revocation practices per PCI DSS section 3.6.
• Avoid prohibited data storage: Never store full magnetic stripe data, CVV codes, or PINs after authorization.

How continuous compliance can help:

• Prevents accumulation of unprotected or unnecessary cardholder data.
• Ensures encryption and tokenization methods stay aligned with evolving best practices.
• Enables early detection of storage policy violations.

Requirement 4: Encrypting Cardholder Data in Transit

Any cardholder data transmitted over open or untrusted networks (e.g., the internet, wireless networks) must be protected using strong cryptography. The requirement prohibits sending unencrypted cardholder data through channels like email or instant messaging. 

Organizations must implement secure transmission protocols (such as TLS) and disable outdated or insecure encryption methods (like SSL or early TLS). It also covers internal traffic over wireless or VoIP networks if those networks could expose data externally.

Practical steps:

• Use strong encryption: Enforce TLS 1.2 or higher; avoid SSL and early versions of TLS.
• Use secure protocols: Avoid using insecure protocols like FTP, Telnet, or HTTP for transmitting cardholder data.
• Install valid certificates: Use certificates from trusted certificate authorities and configure them correctly.
• Monitor for cleartext: Regularly scan systems to ensure no cardholder data is transmitted unencrypted.
• Protect wireless data: Use WPA2 or WPA3 encryption and change default SSIDs and credentials on wireless networks.

How continuous compliance can help:

• Continuously validates that secure transmission protocols are in use.
• Detects outdated or misconfigured encryption methods before they’re exploited.
• Maintains compliance as new transmission channels or services are introduced.

Requirement 5: Malware Protection

Systems vulnerable to malware—especially endpoints, user workstations, and Windows-based servers—must have active malware protection mechanisms in place. The solution must be capable of detecting, removing, and protecting against known types of malicious software, including viruses, worms, trojans, ransomware, and spyware. 

Organizations must ensure that these tools are regularly updated and actively monitored, and that they generate audit logs.

Practical steps:

• Install AV on all systems: Deploy anti-malware software on all endpoints and servers susceptible to malware.
• Automate updates: Configure AV to update definitions and scan engines automatically.
• Generate logs: Ensure AV activity is logged and integrated with your logging solution (e.g., SIEM).
• Scan regularly: Perform full system scans periodically and on schedule.
• Monitor and respond: Alert security staff on detection of malware and track incident resolution.

How continuous compliance can help:

• Keeps defenses current against newly emerging malware threats.
• Ensures detection systems remain functional and up to date across all endpoints.
• Helps correlate malware alerts with other security events for faster incident response.

Requirement 6: Secure System Development

This requirement aims to integrate security throughout the software development lifecycle and to keep systems protected against known vulnerabilities. Organizations must identify relevant security updates from vendors and apply patches in a timely manner, especially those rated as critical or high-risk. 

Custom-developed applications must follow secure coding standards to prevent issues like SQL injection, cross-site scripting, or broken authentication. Development and test environments must be isolated from production, and all changes must be controlled and documented.

Practical steps:

• Apply patches promptly: Install critical security patches within one month of release.
• Follow secure coding practices: Adopt OWASP guidelines and regularly train developers.
• Perform code reviews: Manually review and test code, especially for input validation and authentication flaws.
• Use dev/test/prod segregation: Never use production data in non-production environments.
• Conduct vulnerability scans: Scan custom applications and third-party components regularly.

How continuous compliance can help:

• Flags unpatched systems or libraries before attackers can exploit them.
• Ensures development practices evolve with updated security frameworks.
• Reduces risk of regression by integrating security into each deployment cycle.

Requirement 7: Restricting Data Access

Only individuals whose roles require access to cardholder data should be granted that access. This principle of least privilege ensures that employees or systems can access only the minimum data and functions necessary to perform their duties. 

Organizations must establish access control systems based on job classifications and functions. These controls should be reviewed regularly and updated to reflect changes in roles or responsibilities.

Practical steps:

• Define access roles: Create access roles with least privilege based on job functions.
• Use RBAC or ACLs: Implement role-based access controls or access control lists to enforce access limitations.
• Review access rights: Periodically audit user access to cardholder data and revoke unnecessary permissions.
• Approve changes: Ensure access changes are authorized and logged.

How continuous compliance can help:

• Detects access creep and removes privileges no longer needed.
• Validates enforcement of least privilege as teams and roles change.
• Prevents insider threats by limiting exposure windows to sensitive data.

Requirement 8: Unique IDs and Authentication

Every user who accesses systems in the cardholder data environment must be uniquely identified and authenticated. This requirement ensures accountability and traceability of user actions. Shared accounts are not allowed. 

Authentication methods must include strong passwords and, for remote or administrative access, multi-factor authentication. Account management processes must enforce password complexity, regular expiration, inactivity timeouts, and lockouts for repeated failed login attempts. System access must be monitored and documented.

Practical steps:

• Assign unique IDs: Ensure every user and administrator has a distinct login ID.
• Implement MFA: Enforce multi-factor authentication for remote access and privileged accounts.
• Password security: Require strong, complex passwords and change them every 90 days.
• Account lockout: Lock accounts after no more than 10 failed login attempts.
• Disable dormant accounts: Remove or disable inactive accounts within 90 days.

How continuous compliance can help:

• Quickly identifies and responds to unauthorized access attempts.
• Ensures authentication policies remain strong and are consistently applied.
• Supports traceability and accountability through maintained user logs.

Requirement 9: Physical Security Measures

Physical security controls must be in place to prevent unauthorized access to locations where cardholder data is processed or stored. This includes data centers, server rooms, and even physical media like paper documents or backup tapes. 

Facilities must implement entry controls, maintain access logs, and monitor visitor access. Media must be stored securely and disposed of properly when no longer needed.

Practical steps:

• Use access controls: Secure entry points with badge readers, biometric systems, or PIN pads.
• Monitor access: Keep logs of physical access and review them regularly.
• Secure media: Lock storage media in secure cabinets or rooms.
• Shred or destroy: Use cross-cut shredders or degaussers for retired physical media.
• Escort visitors: Require identification and always escort non-authorized visitors in sensitive areas.

How continuous compliance can help:

• Ensures visitor and access logs are regularly reviewed for anomalies.
• Detects lapses in physical access control policies as personnel or layouts change.
• Reduces risks from misplaced or unprotected media with ongoing monitoring.

Requirement 10: Logging and Monitoring

Organizations must implement logging mechanisms that allow them to track user activities and system events in the cardholder data environment. These logs must capture key events such as user logins, access to sensitive data, changes to configurations, and administrative actions. 

Logs must be protected from tampering and stored for at least one year, with three months immediately available for analysis. The logs must be reviewed regularly to identify suspicious activity or policy violations.

Practical steps:

• Enable logging: Turn on detailed logging for all systems that handle or access cardholder data.
• Use centralized logging: Aggregate logs using a SIEM or log server for real-time analysis.
• Log key events: Include user access, administrative actions, failed logins, and privilege escalations.
• Review daily: Review logs and reports daily for suspicious activity.
• Retain logs: Keep logs for at least 1 year, with 3 months immediately accessible for analysis.

How continuous compliance can help:

• Enables timely detection and response to suspicious behavior.
• Ensures critical logs are not lost, overwritten, or tampered with.
• Supports forensic analysis and audit readiness with continuous log integrity.

Requirement 11: Ongoing Security Testing

To ensure ongoing effectiveness of security controls, organizations must perform regular testing of their systems. This includes internal and external vulnerability scans (at least quarterly), penetration testing (at least annually), and regular scanning of critical files for unauthorized changes. 

In addition, wireless networks must be scanned to detect rogue access points. All identified vulnerabilities must be prioritized based on risk and remediated promptly.

Practical steps:

• Vulnerability scans: Perform internal and external scans at least quarterly and after significant changes.
• Penetration testing: Conduct both network-layer and application-layer penetration tests at least annually.
• File integrity monitoring (FIM): Use FIM tools to detect unauthorized modifications to critical system files.
• Intrusion detection/prevention: Implement IDS/IPS systems to monitor for malicious activities.
• Test wireless networks: Regularly scan for unauthorized wireless access points.

How continuous compliance can help:

• Identifies new vulnerabilities as environments evolve.
• Validates that previous fixes remain effective after changes.
• Keeps threat detection capabilities current through routine testing.

Requirement 12: Security Policy Management

A formalized security policy is essential to ensure that all personnel understand and adhere to the organization's information security responsibilities. This requirement mandates the creation, communication, and annual review of an information security policy. It must cover risk assessment processes, user responsibilities, acceptable use policies, incident response procedures, and service provider oversight. Security awareness training must be provided upon hire and annually. All personnel must be held accountable for following security policies.

Practical steps:

• Create a security policy: Cover roles, responsibilities, acceptable use, and data classification.
• Review annually: Update the policy every year or after significant changes to your environment.
• Assign ownership: Designate a chief security officer (CSO) or similar to manage the policy.
• Conduct training: Provide initial and annual security awareness training to all personnel.
• Document risk assessments: Periodically assess risks to cardholder data and update controls accordingly.
• Plan for incidents: Develop, test, and document an incident response plan, including roles, contact information, and recovery steps.

How continuous compliance can help:

• Ensures staff stay informed of current policies and responsibilities.
• Aligns security practices with the latest threat intelligence and regulatory updates.
• Reinforces a culture of security awareness and accountability year-round.

PCI DSS Compliance with Anecdotes

Anecdotes’ AI-native GRC platform empowers you to automate the collection of even the most complex evidence from your tech stack, and monitor your environment to confidently meet the requirements of PCI-DSS.

Scoping Your CDE

PCI-DSS is designed to help companies avoid risks by securely handling their Cardholder Data Environments (CDE). A common challenge in this process is accurately scoping the relevant components of the CDE, an effort that often demands significant resources. The Anecdotes platform addresses this challenge head-on with data solutions that include scoping management, providing detailed and granular control over the CDE you're monitoring.

Attest to SAQs With Complete Confidence

PCI Self-Assessment Questionnaires (SAQs) are commonly required from merchants and service providers who handle card payments. To self-attest to these questionnaires confidently and accurately, relying solely on sporadic human-powered workflows is insufficient. Continuous monitoring of your PCI environment is crucial to ensure your responses are comprehensive and free from blind spots. The Anecdotes platform provides data-based automation and out-of-the-box cross-mapping to SAQs, offering a dependable and trustworthy solution.

To learn more, visit Anecdotes.ai