PCI DSSFAQ

PCI DSS (Payment Card Industry Data Security Standard) is a global security standard established by the PCI Security Standards Council. It defines a set of technical and operational requirements designed to protect cardholder data wherever it is processed, stored, or transmitted. Compliance is mandatory for any organisation that handles payment card information.

Any organisation that accepts, processes, stores, or transmits payment card data must comply with PCI DSS. This includes merchants of all sizes, payment processors, acquirers, issuers, and third-party service providers. The specific validation requirements depend on your merchant level and transaction volume.

There are four merchant levels determined primarily by annual transaction volume. Level 1 merchants process over 6 million transactions annually and require a full on-site assessment by a QSA. Level 2 (1-6 million), Level 3 (20,000-1 million e-commerce), and Level 4 (fewer than 20,000 e-commerce or up to 1 million total) typically complete self-assessment questionnaires. Acquirers may adjust these thresholds based on risk.

Begin by determining your merchant level and identifying which Self-Assessment Questionnaire (SAQ) applies to your environment. Next, conduct a gap analysis to understand where your current security posture falls short of requirements. Prioritize remediation of identified gaps, implement required controls, and then complete the appropriate assessment. Using a compliance management platform like GRCTrack can streamline this process significantly.

Non-compliance can result in significant financial penalties ranging from $5,000 to $100,000 per month, imposed by card brands through your acquiring bank. Beyond fines, you may face increased transaction fees, loss of the ability to process card payments, and reputational damage. In the event of a data breach, non-compliant organisations face greater liability and forensic investigation costs.

Compliance costs vary widely depending on your merchant level, environment complexity, and current security posture. Small merchants completing SAQ A may spend a few hundred dollars annually, while Level 1 merchants requiring full QSA assessments can spend $50,000 to $500,000 or more. Major cost factors include security technology, personnel, assessor fees, and ongoing monitoring. Investing in compliance is significantly less expensive than dealing with a data breach.

The timeline depends on your starting point and environment complexity. Organizations with mature security programmes may achieve compliance in 3-6 months. Those starting from scratch or with significant gaps may need 12-18 months. The assessment itself typically takes 2-8 weeks for a QSA-led ROC engagement. Ongoing compliance is a continuous process, not a one-time achievement.

PCI DSS v4.0.1 introduced a customised approach allowing organisations to meet security objectives through alternative controls. It added targeted risk analysis requirements, expanded multi-factor authentication mandates, strengthened e-commerce and phishing protections, and introduced new requirements for service providers. Organizations must fully comply with all v4.0.1 future-dated requirements by March 31, 2025.

PCI DSS is enforced by the five major card brands -- Visa, Mastercard, American Express, Discover, and JCB -- through their respective compliance programmes. The PCI Security Standards Council develops and maintains the standard, but enforcement and penalties are administered by the card brands, typically through the merchant's acquiring bank. Each brand has its own compliance programme with specific deadlines and requirements.

PCI DSS applies to organisations that handle cardholder data, while PA-DSS (Payment Application Data Security Standard) applied to software vendors developing payment applications sold to third parties. PA-DSS has been retired and replaced by the PCI Software Security Framework (SSF), which includes the Secure Software Standard and the Secure Software Lifecycle Standard. PCI DSS remains the primary standard for organisations processing card data.

An SAQ is a validation tool provided by the PCI SSC for merchants and service providers who are not required to undergo a full on-site assessment. It consists of yes/no questions corresponding to PCI DSS requirements applicable to your specific payment environment. Completing an SAQ honestly documents your compliance status and is submitted along with an Attestation of Compliance (AOC).

The correct SAQ depends on how you accept and process payment cards. SAQ A is for fully outsourced e-commerce/MOTO merchants, SAQ B for imprint or standalone terminals, SAQ B-IP for standalone IP-connected terminals, SAQ C-VT for virtual terminal merchants, SAQ C for merchants with internet-connected payment systems, SAQ A-EP for e-commerce with partial outsourcing, SAQ P2PE for validated P2PE merchants, and SAQ D for all others. Your acquirer can help confirm the correct type.

SAQ A applies to e-commerce merchants that fully outsource all payment processing -- their website never touches cardholder data and only uses an iframe or redirect to a PCI-compliant payment provider. SAQ A-EP applies to e-commerce merchants whose website controls how cardholder data is transmitted (e.g., using JavaScript-based payment forms hosted on the merchant's site), even if they never store the data. SAQ A-EP has significantly more requirements than SAQ A.

A Report on Compliance (ROC) is a comprehensive assessment performed by a Qualified Security Assessor (QSA) through an on-site audit, required for Level 1 merchants and some service providers. An SAQ is a self-assessment completed by the merchant themselves. The ROC provides a much more detailed evaluation and is considered the gold standard for PCI DSS validation. Both require an accompanying Attestation of Compliance (AOC).

PCI DSS assessments must be completed annually, whether you undergo a full QSA-led ROC or complete an SAQ. In addition, quarterly external vulnerability scans by an Approved Scanning Vendor (ASV) are required. Significant changes to your environment -- such as new payment channels, infrastructure changes, or mergers -- may also trigger the need for a re-assessment before the annual cycle.

A gap analysis is a preliminary evaluation that compares your current security controls against PCI DSS requirements to identify areas of non-compliance. It produces a roadmap of remediation items with priorities and estimated timelines. Conducting a gap analysis before your formal assessment helps avoid surprises, allows you to budget for necessary changes, and ensures a smoother compliance process.

Yes, merchants at Levels 2, 3, and 4 typically self-assess by completing the appropriate SAQ. However, self-assessment must be done honestly and accurately -- misrepresenting your compliance status can result in significant liability if a breach occurs. Some acquirers may require Level 2 merchants to have a QSA or ISA validate their SAQ. For complex environments, engaging a QSA for guidance even during self-assessment is advisable.

A QSA is an individual certified by the PCI Security Standards Council to conduct on-site PCI DSS assessments. QSAs must work for a QSA Company (QSAC) approved by the Council and must pass annual requalification training. They evaluate an organisation's compliance by testing controls, reviewing documentation, interviewing personnel, and observing processes. Only QSAs can produce an official Report on Compliance.

Look for a QSA company with experience in your industry vertical and payment environment type. Verify their current listing on the PCI SSC website, check references from similar-sized organisations, and evaluate their communication style and availability. Consider whether they offer remediation guidance beyond just assessment, and ensure they have sufficient staff to meet your timeline. The cheapest assessor is rarely the best value.

An ISA is an employee within a merchant or service provider who has been certified by the PCI SSC to conduct internal PCI DSS assessments for their own organisation. ISAs complete a PCI SSC training programme and can perform internal assessments and help prepare for QSA audits. Having an ISA on staff helps maintain year-round compliance awareness and can reduce assessment costs, though an ISA's assessment may not substitute for a QSA-led ROC at Level 1.

Network segmentation is not technically required by PCI DSS, but it is strongly recommended and considered a best practice. Without segmentation, your entire network is in scope for the assessment, which dramatically increases compliance cost and complexity. Proper segmentation isolates the cardholder data environment (CDE) from the rest of your network, reducing the number of systems subject to PCI DSS requirements.

PCI DSS requires strong cryptography for cardholder data both at rest and in transit. Data in transit over open, public networks must use TLS 1.2 or higher. Data at rest must be rendered unreadable using methods such as strong encryption (AES-256), one-way hashing, truncation, or tokenisation. Encryption keys must be managed according to PCI DSS Requirement 3.6, including documented key management procedures covering the full key lifecycle.

PCI DSS Requirement 1 mandates installing and maintaining network security controls (firewalls) between untrusted networks and the CDE. Rules must restrict inbound and outbound traffic to only what is necessary for business purposes, deny all other traffic by default, and be reviewed at least every six months. Firewall configurations must be documented, and any allowed connections must have a documented business justification.

PCI DSS v4.0.1 requires passwords to be at least 12 characters (or 8 if the system cannot support 12) containing both numeric and alphabetic characters. Passwords must be changed at least every 90 days, cannot be the same as the previous four passwords, and must be set to a unique value for first-time use. Multi-factor authentication is required for all access into the CDE and for all non-console administrative access.

Requirement 10 mandates logging all access to system components and cardholder data. Logs must record user identification, event type, date and time, success or failure, origination of event, and identity or name of affected data or resource. Logs must be reviewed at least daily using automated tools, retained online for at least three months, and available for at least twelve months. Automated alerting must be configured for suspicious activity.

PCI DSS requires both internal and external vulnerability scans at least quarterly and after any significant change to the environment. External scans must be conducted by an Approved Scanning Vendor (ASV) and must produce a passing result. Internal scans must be performed by qualified personnel. High-risk vulnerabilities identified in scans must be remediated and rescanned until a passing result is achieved.

Requirement 11.4 mandates annual penetration testing of the CDE from both internal and external perspectives, plus testing after significant changes. Tests must cover both the network layer and application layer, validate that segmentation controls are effective, and be performed by qualified internal resources or external third parties. Identified vulnerabilities must be remediated and retested. The methodology must follow an industry-accepted approach such as NIST SP 800-115 or PTES.

If wireless technology is used in or connected to the CDE, PCI DSS requires changing vendor defaults for wireless encryption keys, passwords, and SNMP community strings. Wireless networks must use industry best practices for strong encryption (WPA2/WPA3 Enterprise with AES). Quarterly wireless scans must be conducted to detect unauthorized access points. All wireless traffic traversing the CDE boundary must be encrypted.

Cloud environments are fully subject to PCI DSS, with responsibility shared between the cloud service provider (CSP) and the customer based on the service model (IaaS, PaaS, SaaS). You must clearly define and document the shared responsibility matrix with your CSP. The CSP must be PCI DSS compliant for their portion, and you must verify this through their AOC or conduct your own assessment. Virtual segmentation, access controls, and encryption require special attention in cloud deployments.

Mobile payment acceptance devices and applications must meet PCI DSS requirements applicable to the payment channel. This includes encrypting cardholder data, using PCI-listed devices and validated payment applications, and maintaining secure configurations. Consumer-owned devices used for payment acceptance introduce additional risks that must be addressed through compensating controls. The PCI SSC publishes supplemental guidance for mobile payment acceptance security.

PCI DSS assessments require multiple types of evidence including documentation (policies, procedures, network diagrams, data flow diagrams), technical evidence (configuration files, scan reports, log samples), and observational evidence (interviews, process walkthroughs). The specific evidence varies by requirement but generally includes proof that controls are documented, implemented, and actively maintained. Using a centralised evidence management system greatly simplifies this process.

Audit logs must be retained for at least twelve months, with at least three months immediately available for analysis. However, other compliance records -- such as policy documents, assessment reports, scan results, and training records -- should be retained for at least three years or as required by your acquirer or applicable regulations. Many organisations retain PCI DSS evidence for five years to cover the full audit trail in case of a breach investigation.

PCI DSS Requirement 12 requires a comprehensive information security policy that addresses all twelve requirements. Additional specific policies include an acceptable use policy for critical technologies, a data retention and disposal policy, a vendor management policy, and an incident response plan. All policies must be reviewed at least annually, distributed to relevant personnel, and acknowledge by users. Policies must reflect actual practices in the environment.

PCI DSS Requirement 10.7 specifies that audit trail history must be retained for at least twelve months. At least three months of log data must be immediately available for analysis (e.g., online, stored in a SIEM). The remaining nine months may be stored in archives that can be restored within a reasonable timeframe. Logs must be secured against tampering and stored in a centralized location with access restricted to those with a legitimate business need.

PCI DSS Requirement 6.5 requires documented change management processes including documentation of the impact, approval by authorised parties, testing to verify the change does not adversely affect security, and back-out procedures. Evidence typically includes change request records, approval documentation, test results, and post-implementation reviews. All changes to system components in the CDE must follow these procedures.

Requirement 12.8 requires maintaining a list of all third-party service providers (TPSPs) with a description of the services provided. You must obtain written acknowledgment from each TPSP that they are responsible for the security of cardholder data in their possession. Collect and review each vendor's PCI DSS compliance documentation annually, typically their AOC or relevant SAQ. Maintain a formal process for engaging new vendors that includes compliance verification.

Requirement 12.6 mandates that security awareness training be provided to all personnel upon hire and at least annually thereafter. You must retain records showing who received training, when it was completed, and what topics were covered. Training content must be relevant to each person's role, and specialised training is required for personnel with security responsibilities. Training must address current threats and the organisation's information security policy.

Requirement 12.10 requires a documented incident response plan that includes roles and responsibilities, communication and notification procedures, specific incident response procedures, business recovery and continuity processes, and legal and regulatory notification requirements. The plan must be tested at least annually, and all personnel must be trained on their responsibilities. Post-incident reports and lessons-learned documentation must also be maintained.

Requirement 7 mandates that access to system components and cardholder data is restricted based on business need-to-know. Evidence must include documented access control policies, current user access lists, records of access reviews performed at least every six months, approval records for access grants and changes, and evidence of prompt revocation when access is no longer needed. Role-based access control documentation should map job functions to required access privileges.

You must maintain quarterly external ASV scan reports showing passing results, quarterly internal scan reports, and scan reports for any rescans performed after remediation. Each report should include the date, scope, findings, and remediation status. External ASV scans must be performed by a PCI SSC-approved vendor. Retain all scan reports for at least twelve months to demonstrate a continuous quarterly scanning cadence.

The CDE encompasses all people, processes, and technologies that store, process, or transmit cardholder data (CHD) or sensitive authentication data (SAD). It also includes any systems that are directly connected to or that could affect the security of the CDE. Accurately defining the CDE is the critical first step in any PCI DSS assessment because it determines which systems, networks, and personnel are in scope.

Start by mapping all locations where cardholder data is stored, processed, or transmitted -- including databases, applications, logs, backups, and any temporary storage. Then identify all connected systems and network segments that could impact CDE security. Document data flows using data flow diagrams and network diagrams. PCI DSS 4.0 requires scope to be validated at least annually and upon significant changes to the environment.

The most effective scope reduction techniques include network segmentation to isolate the CDE, tokenisation to replace cardholder data with non-sensitive tokens, outsourcing payment processing to PCI-compliant third parties, implementing validated Point-to-Point Encryption (P2PE) solutions, and eliminating unnecessary data storage. Each technique reduces the number of systems subject to PCI DSS requirements, lowering both compliance cost and risk.

Tokenisation replaces cardholder data with a non-sensitive surrogate value (token) that has no exploitable meaning. Systems that only store, process, or transmit tokens instead of actual cardholder data can potentially be removed from PCI DSS scope. However, the tokenisation system itself remains in scope. For maximum scope reduction, use a tokenisation solution provided by a PCI DSS-compliant third party so the actual cardholder data never enters your environment.

P2PE is a PCI SSC-validated solution that encrypts cardholder data from the point of interaction (such as a payment terminal) until it reaches the secure decryption environment. When using a validated P2PE solution, merchants can significantly reduce PCI DSS scope because the encrypted data passing through their systems is considered unreadable and therefore out of scope. This is one of the most effective scope reduction methods for card-present environments.

Segmentation testing verifies that network segments outside the CDE cannot communicate with systems inside the CDE. Testing must be performed at least annually and after any changes to segmentation controls. It involves penetration testing techniques to confirm that segmentation controls are effective at isolating the CDE. Tests should verify that traffic from out-of-scope networks cannot reach in-scope systems and that segmentation controls cannot be bypassed.

Systems that connect to or communicate with the CDE are considered "connected-to" or "security-impacting" systems and are in scope for PCI DSS. This includes servers that provide authentication services, DNS, NTP, or logging for CDE systems, as well as management workstations used to administer CDE components. Even a single network connection to the CDE can bring an entire system and its supporting infrastructure into scope.

Third-party service providers (TPSPs) that store, process, or transmit cardholder data on your behalf, or that could impact the security of your CDE, are within the scope of your PCI DSS compliance obligations. You must verify their PCI DSS compliance, maintain written agreements defining responsibilities, and monitor their compliance status at least annually. Their compliance does not eliminate your own -- you remain responsible for the overall security of cardholder data in your environment.

PCI DSS compliance is a continuous process, not an annual event. Maintain compliance by implementing ongoing security monitoring, conducting regular internal vulnerability scans, performing daily log reviews, keeping systems patched and updated, reviewing access controls regularly, and conducting periodic security awareness training. Use a compliance management platform to track control effectiveness and automate evidence collection throughout the year.

Key quarterly activities include external vulnerability scans by an Approved Scanning Vendor (ASV), internal vulnerability scans, and wireless scans to detect unauthorized access points. Additionally, you should review firewall and router rule sets, ensure that security patches have been applied in a timely manner, and verify that logs are being properly collected and reviewed. Document all quarterly activities and results for your annual assessment.

Annual requirements include completing your PCI DSS assessment (ROC or SAQ), annual penetration testing from internal and external perspectives, annual review of all security policies and procedures, annual information security risk assessment, annual incident response plan testing, annual scope validation, annual security awareness training for all personnel, and annual review of third-party service provider compliance status. All of these must be documented and evidence retained.

A re-assessment may be triggered by significant changes to your environment such as new payment channels, major infrastructure or application changes, mergers and acquisitions, or a security breach. Changes to your business model, new third-party integrations affecting the CDE, or a change in merchant level can also necessitate re-assessment. When in doubt about whether a change is significant, consult your QSA or acquirer.

Compensating controls are alternative security measures that provide equivalent protection when an organisation legitimately cannot meet a PCI DSS requirement as explicitly stated. They must meet the intent and rigour of the original requirement, provide a similar level of defence, and go above and beyond other PCI DSS requirements. Each compensating control must be documented in a Compensating Controls Worksheet, including justification, risk analysis, and validation testing. They must be reviewed annually.

Immediately activate your incident response plan and contain the breach. Notify your acquiring bank and the card brands within their required timeframes -- typically within 24-72 hours. Engage a PCI Forensic Investigator (PFI) to conduct a forensic investigation if required by the card brands. Preserve all evidence, document all actions taken, and cooperate fully with the investigation. After remediation, you will likely need to re-validate PCI DSS compliance before resuming normal card processing.

The PCI SSC continuously evolves the standard to address emerging threats and technologies. Current focus areas include enhanced requirements for phishing protection, browser script integrity, cloud security, and API security. The customised approach introduced in v4.0 is expected to see broader adoption, and the Council is developing additional guidance for emerging technologies like contactless payments and IoT devices. Stay current by monitoring PCI SSC announcements and engaging with your QSA on upcoming changes.