Who does what in a PCI DSS engagement

Six parties appear in a PCI DSS programme, and each produces a different document. A Report on Compliance, an Attestation of Scan Compliance and a segmentation test report come from three different parties, and only one of them can be bought from any given supplier. Most arguments about who is responsible for what dissolve once you can name the artefact you are asking for.

The entity does the work everyone assumes an assessor does

Scoping is the entity's job, and PCI DSS v4.0.1 is blunt about it: "The first step in preparing for a PCI DSS assessment is for the entity to accurately determine the scope of the review." It then closes the obvious workaround:

"This annual confirmation of PCI DSS scope … is an activity expected to be performed by the entity. This activity is not the same, nor is it intended to be replaced by, the scoping confirmation performed by the entity's assessor during the assessment."

Two scope exercises, then — yours under 12.5.2, and your assessor's validation of it. Outsourcing does not move the obligation either: entities that outsource payment operations "remain responsible for ensuring that the account data is protected by the third party." And Requirement 11.4.1 puts the penetration testing methodology on the same side of the line: it is "defined, documented, and implemented by the entity", not by the tester. A report written against a supplier's house methodology, with no reference to yours, answers the wrong document.

The QSA writes the ROC and acknowledges a role in the AOC

A QSA company is qualified by PCI SSC and produces the Report on Compliance using the Council's ROC Reporting Template. The confusion starts at the Attestation of Compliance, because the QSA does not sign it as the compliant party. In SAQ D, Section 3, Part 3b is the Merchant Attestation, signed by the Merchant Executive Officer — the service provider edition is identical, with a Service Provider Executive Officer. Part 3c is the QSA Acknowledgement, completed only "If a QSA was involved or assisted with this assessment", and it asks the assessor which role they performed: testing procedures, or other assistance. The compliance claim is the entity officer's; the assessor acknowledges what they did beneath it.

Independence is the part worth reading before you procure. Under the QSA Qualification Requirements v4.0 §2.2.1, a QSA company must disclose in the ROC where it assesses a customer using a security solution the company developed, owns, configured or manages — the list includes "Vulnerability scanning services or solutions" — and it "must not misrepresent any requirement of the PCI DSS … or state or imply that the PCI DSS or any other PCI SSC Standard requires usage of the QSA Company's products or services." That is the Council's own answer to a supplier telling you compliance requires its platform. More on what a QSA may not assess, and how to verify one.

The ISA does the same reports from inside the building

An Internal Security Assessor is qualified by PCI SSC but employed by the assessed entity, and the AOC carries a separate Part 3d for their involvement. Appendix D of v4.0.1 places the two roles side by side — "Use of the customized approach must be documented by a QSA or ISA" — but whether your acquirer accepts an ISA-produced ROC is not a question the standard answers. The Council refers "whether an entity is required to use a QSA, or may use an ISA" to the compliance programme.

The ASV owns one requirement, closed to everyone else

Requirement 11.3.2 is the single place in Requirement 11 that names a credential. External vulnerability scans must be performed "At least once every three months · By a PCI SSC Approved Scanning Vendor (ASV) · Vulnerabilities are resolved and ASV Program Guide requirements for a passing scan are met." It adds: "This requirement is not eligible for the customized approach."

The artefact is equally specific: every ASV scan report must follow the templates in Appendices B and C of the ASV Program Guide and carry an Attestation of Scan Compliance in the Appendix A form. Declaring a passing scan is the ASV's act and nobody else's. See what an ASV does, and why an ASV scan, an internal scan and a penetration test are three separate requirements.

The independent penetration tester: what the standard asks of them

Six requirements in v4.0.1 — 11.3.1.3, 11.3.2.1, 11.4.2, 11.4.3, 11.4.5 and 11.4.6 — describe the person doing the work in the same two lines:

"Performed by a qualified internal resource or qualified external third party."

"Organizational independence of the tester exists (not required to be a QSA or ASV)."

The bar is competence and independence, and the assessor tests it by interview under procedures 11.4.2.b and 11.4.3.b. What comes back is a family of artefacts, not one report: internal testing under 11.4.2 and external under 11.4.3, both at least once every 12 months and after any significant infrastructure or application upgrade or change; segmentation testing under 11.4.5 at least every 12 months, and under 11.4.6 every six months for a service provider; and under 11.4.4, correction ranked by your own risk process at 6.3.1 followed by "Penetration testing is repeated to verify the corrections" — the retest sits inside the requirement, not on a change order. Multi-tenant service providers additionally support their customers' external testing under 11.4.7.

The standard is also candid about what a good report looks like, in a line worth quoting to anyone who reads a clean result as good news:

"A penetration test that found nothing is typically indicative of shortcomings of the penetration tester, rather than being a positive reflection of the security posture of the entity."

This is the role Security Brigade occupies: penetration testing scoped to Requirement 11.4, segmentation testing, and evidence an assessor can rely on when they examine the scope of work and results.

The acquirer and the payment brand decide, not the Council

PCI SSC writes the standard. It does not run the compliance programme, and says so on page three: "Whether any entity is required to comply with or validate their compliance to PCI DSS is at the discretion of those organizations that manage compliance programs (such as payment brands and acquirers)."

Your level comes from the brand, with discretion written into the definition — American Express sets a Level 1 merchant at 2.5 million card transactions a year "or any Merchant that American Express otherwise, in its discretion, assigns a Level 1". Your acquirer reviews what you file: Visa's service provider guidance states that "Visa will not review the contents of the SAQ-D as issuers and acquirers are responsible for reviewing the accuracy of the SAQ-D." More on who assigns your level.

The two artefacts nobody in the list produces

A PCI DSS certificate is not one of them. The PCI SSC document library lists ROC templates, SAQs and AOCs, and no certificate; the AOC is "the official PCI SSC form for merchants and service providers to attest to the results of a PCI DSS assessment." Attest, not certify — and the attesting signature is your own executive officer's. If a supplier offers to issue you a certificate, ask which of the six roles above they occupy and which form they intend to complete. See what "PCI DSS certification" actually means and who signs it.

The second is a passing scan declared by anyone other than an ASV, which has no standing under 11.3.2 whatever the scan output says. Settle the roles before you buy anything: the costliest procurement error in this market is buying one artefact in the belief that it is another.