Every engagement we have ever run, PCI or not, has stalled on the same question at least once. Not “is this control in place?” but “what is this control supposed to cover?” Here are three.
A manufacturer with no inventory
A manufacturing group with more than twenty plants asked us to run its security programme. The first thing we asked for was a list of what was on the network. There was none. Each site patched its own way, mostly Windows, and the evidence that patching was happening was described in a board paper as “informal data from IT staff”.
You cannot protect what you cannot count. The first measurable step of the programme was not a firewall or a detection platform. It was nine hundred agents on sixteen sites, so that for the first time someone could say how many machines there were and how many vulnerabilities sat on each. The answer, months later, was about two hundred per workstation on average. Unpleasant, but finally a number that could go down.
A processor whose scope documents disagreed
A card-payment processor approached its first 3DS assessment as an extension of its PCI DSS compliance. It was a mature organisation with a large security management system, and it expected the 3DS part to be a formality.
On day one there was no formal definition of the 3DS environment. The list of critical software did not include the main 3DS applications. Two scope documents disagreed on the operating system of the cryptographic servers: one said AIX, the other said Linux. The third party running the data centre had responsibilities nobody had written down.
None of that was a security weakness in itself. All of it stopped the assessment, because an assessor cannot say a control is in place for an environment nobody has defined. Of the forty-one requirements with open points after the on-site days, most were scope, documentation and ownership. The technology was mostly fine.
A bank whose scope hinged on one decision
A challenger bank reached the SWIFT network through a service bureau, not through its own infrastructure. Its assessment under SWIFT’s customer security framework depended entirely on one early decision: which architecture type it was. Pick the wrong one and you assess the wrong controls.
The right answer was the type with no local footprint, which made the scope a single operator virtual machine, reached over VPN, and the people who used it. Once that was settled the assessment took two days. Two of the fifteen mandatory controls were not in place, both on that one machine: it could browse the Internet freely, and nobody reviewed its logs. Had the architecture type been chosen casually, neither would have been looked at.
What people get wrong
They start with controls. Scanners, policies, multi-factor authentication, logging. Controls are satisfying because you can buy them and show them. But a control applied to an undefined environment proves nothing, and an assessor will say so.
They assume the inventory exists because someone must have one. Ask to see it. Ask for its date. Ask who owns it. In our experience, the honest answer is usually a spreadsheet one person maintains, last updated before a reorganisation.
They treat scope as a PCI formality rather than an engineering fact. Scope is the list of things that can hurt you. It is the same list whether the reader is a QSA, a ransomware operator or your largest customer’s security team.
Scope is the list of things that can hurt you.