Every PCI DSS programme has a folder of Attestations of Compliance from its service providers, collected once a year, usually in January, usually in a hurry. The folder feels like proof. Most of the time, nobody has read what is in it. Four cases from our assessments.
The AOC that covered every site but yours
A client outsourced part of its card handling to a call-centre provider with many locations. The provider’s AOC was current, signed by a QSA, and listed the locations in scope. It listed plenty of them. It did not list the one our client actually used.
This is the most common failure we see, and it is not fraud. Large providers assess a subset of their estate, often the sites their largest customers care about, and the AOC says so, in the scope section nobody reads. The client had been filing that AOC for years as proof that its call handling was covered.
The acquirer whose AOC excluded the terminals it supplied
A merchant took payments on terminals leased from its acquirer, which was also the terminal provider. The acquirer held the merchant responsible for the terminals’ compliance, and its AOC said so explicitly: the requirements about protecting devices from tampering were excluded from its scope. Its installation manual, meanwhile, printed the terminals’ default administrator password and the password for downloading software to them.
You cannot inherit a control from a provider whose AOC does not cover it. We sent the provider a formal letter of questions, one requirement at a time, asking for evidence rather than reassurance. The merchant’s compliance then moved to where it really sat: a terminal inventory, daily tamper inspections, staff training and an escalation path, and a responsibility matrix agreed with the acquirer in writing.
You cannot inherit a control from a provider whose AOC does not cover it.
The providers who sent a merchant’s SAQ A
A public-transport operator taking over a network inherited eight payment providers and a request from its authority for PCI validation. It collected AOCs from the providers as evidence. Two of the key providers had sent the AOC from their own merchant SAQ A, the shortest self-assessment there is. A merchant SAQ A describes how a company takes its own payments through an outsourced page. It says nothing whatsoever about the service that company provides to anyone else.
We could not endorse an SAQ A for the operator on the basis that processing was outsourced and documents had been collected. The work that should have come first was clear: map every channel to its merchant account, check what each inherited document actually covered, and choose the validation approach channel by channel.
The engagement had started as “you are a QSA, we need you to sign this SAQ A with us”. SAQ A did not apply to most of the estate, so we did not. We never saw the end of the story. Our assumption is that the operator signed the SAQ A itself, the authority accepted a self-signed document that did not describe the situation, and the project closed that way. A QSA cannot bend the rule. The entity asking for an attestation and the entity answering it both can, and sometimes do. Our position was to be clear about the rules and about our decision, even where that reads as a negative message. We do not write the rules, and we do not bend them either.
The AOC that cannot exist
A payment-infrastructure vendor’s customer asked for “an AOC for the vendor’s domain”. The vendor would attest the payment infrastructure, the customer would keep the right to change its configuration, and would tell the vendor about changes once a quarter. Seven areas of responsibility were on the table. Five had no agreed owner.
An AOC is a declaration by a legal entity about itself. There is no AOC for a set of equipment, any more than there is a passport for a server room. And a quarterly notification is not change control. The real question was a fork, and it was technical, not commercial. Either the customer keeps control of changes and is the assessed entity, with the vendor listed as a third-party provider in a signed responsibility matrix. Or the vendor attests, and every change goes through the vendor. Both at once is impossible. The best evidence was already on the table: appointing key custodians had been blocked for two months because nobody could say which management line authorises them.
What people get wrong
They collect an AOC once, at contract signature, and file it. The AOC is dated, scoped and signed for a period. Next year it describes last year.
They do not read the scope. The scope section says which services, which locations and which requirements the attestation covers. If the service you buy is not in it, you have a nice document about something else.
They have no responsibility matrix. The standard asks for one for exactly this reason: so that each requirement has a name against it, yours or theirs. Without it, the first assessor to ask “who does this?” gets two companies pointing at each other.
They mistake an AOC for a control. A provider’s attestation tells you the provider says its controls operated. It does not inspect your terminals, patch your servers or train your staff. The requirements that remain yours are usually the ones that cause breaches.