Back to blog

Published Last updated Last reviewed against PCI DSS v4.0.1

Do You Need a PCI DSS Audit? Here's How to Determine If and When

Posted by

PC

PCIComplianceHub

@pcicompliancehub

cover

Most people call it a PCI DSS audit. The standard calls it an assessment, and the question that matters is not whether you are assessed but how. Every business that stores, processes or transmits card data has to meet PCI DSS. What varies is how it proves that, and the standard itself does not decide that part.

Does PCI DSS apply to you?

PCI DSS applies to any entity that stores, processes or transmits account data, and to the systems and people that could affect its security. Using a payment processor or a hosted payment page does not take a merchant outside the standard. It changes which requirements remain with the merchant, often to a short list, but the merchant still validates.

Two ways to validate

There are two routes, and both end with an Attestation of Compliance (AOC):

  • A Report on Compliance (ROC), prepared by an assessor who examines documents, configurations and records and interviews staff against each requirement's testing procedures. This is what most people mean by an audit. The assessor is a Qualified Security Assessor (QSA), or in some brand programmes an Internal Security Assessor (ISA) employed by the entity itself.
  • A Self-Assessment Questionnaire (SAQ), which the entity completes itself. The SAQ Instructions and Guidelines describe the SAQs as alternate validation tools for merchants and service providers that are not required by an acquirer or payment brand to submit a ROC.

Who decides which route applies

The payment brands and your acquirer decide, not PCI DSS. The SAQ instructions put it in two conditions: to self-assess, an entity must be eligible under the payment brands' compliance programmes and must meet the eligibility criteria of the SAQ it chooses. They also encourage every entity to confirm with its acquirer, or with the brands, before starting.

In practice the brands sort merchants into merchant levels by annual transaction volume. The largest merchants are required to submit a ROC; smaller ones can generally self-assess if their acquirer agrees. The thresholds are set by each brand, differ between brands, and can be tightened by an acquirer, so the only reliable source for your level is your acquirer or the brand's own programme. Service providers are sorted the same way into service provider levels: the highest level submits a ROC, and the SAQ available to the rest is SAQ D for Service Providers.

If self-assessment is open to you, Find my SAQ works out which questionnaire fits how you take payments, and the SAQ mapping shows which controls each one contains.

Situations that change the answer

  • A compromise. After a suspected or confirmed breach, the payment brands' rules usually take over. They may require a PCI Forensic Investigator (PFI) and a more demanding form of validation. That comes from the brands. The standard's part is the incident response plan in 12.10.1, which must cover notifying the payment brands and acquirers.
  • Your acquirer. An acquirer can require more than the brand minimum, including a ROC from a merchant that would otherwise self-assess.
  • Your customers. A service provider is often asked for its AOC by the businesses it serves. That is not only commercial: 12.8.4 requires every entity to monitor its third-party service providers' compliance status at least once every 12 months, and 12.9.2 requires service providers to supply that status, and a split of responsibilities, when a customer asks.

When: the assessment and everything between

Brand programmes generally expect validation every year. The standard adds recurring work that does not wait for the assessment:

  • Internal and external vulnerability scans at least once every three months, under 11.3.1 and 11.3.2, the external ones by an Approved Scanning Vendor.
  • Internal and external penetration tests at least once every 12 months, under 11.4.2 and 11.4.3.
  • A confirmation of scope at least once every 12 months, under 12.5.2.

A significant change does not require a new assessment. It triggers specific work instead: confirming that every applicable requirement is in place on the new or changed systems (6.5.2), internal and external scans (11.3.1.3 and 11.3.2.1), penetration tests after a significant infrastructure or application change (11.4.2 and 11.4.3), and a fresh scope confirmation (12.5.2).

Preparing for an assessment

  1. Confirm scope first. Map where account data enters, where it is stored and where it leaves, and which systems could affect it. Everything else depends on this.
  2. Run a gap analysis against the SAQ you are eligible for, or against the full standard if you are heading for a ROC.
  3. Collect evidence by requirement. Each control page on this site lists what the assessor will examine, taken from the standard's testing procedures.
  4. Choose an assessor from the Council's list. Find an assessor draws on the Council's QSA and ASV listings. Selecting a QSA covers what to ask, and PCI QSA companies in Australia lists the Council's Australian entries.