Clients are sometimes surprised that we almost never use a formal compensating control worksheet. The paperwork is heavy and busy teams do not like it, but that is not the reason. The reason is that most of what is offered as a compensating control is not one. It is a different control, for a different requirement, presented in place of the one that was asked for. We would rather a client fixed the control, or recorded it as not in place with a plan, than built a worksheet around a substitute.
Refused: “we block it at the firewall”
A service that should not have been running was listening on every interface of a container worker node. The client’s own inventory of approved services listed it as not approved and said it must be disabled. The exception raised for it was closed as “superseded by network deny rules”.
Blocking traffic does not disable the service. The requirement is about which services run on the system. A different requirement covers the network. To close the finding: the service disabled in the node image, shown on a running node.
Refused: “our infrastructure-as-code is our change detection”
For the requirement that asks for a change-detection mechanism that alerts people, the client pointed to the templates that define its container platform. Templates define the desired state. The requirement asks for something that notices when the real state drifts from it, and tells someone. Drift detection could be acceptable, with evidence that it runs: what it covers, how often it compares, how an out-of-band change raises an alert, and who reviews. It also has to see runtime changes that the templates never will. Showing that the code matches the deployment today proves today.
Refused: “we’ll write it in by hand on the day”
A payment-infrastructure vendor, under the PIN security standard, proposed keeping its key-ceremony procedures generic and filling in the specifics by hand at the start of each ceremony. That sounds reasonable, which is what makes it dangerous. It mixes two things. Instance records, the names, the card serial numbers, the check values, the seal numbers, are fine to write by hand. Design parameters are not: the quorum, the number of cards, whether keys can be exported, which commands are authorised. Chosen in the room, under time pressure, by the one person who understands the subject, they get no approval and no review. The quorum alone sets the collusion threshold for the whole system. It goes in an annex approved before the ceremony.
On a related point, the vendor described an optional check that was genuinely good practice. Our answer: what you describe is a good control, and it is not in the procedure, and we are reviewing the procedure. An optional control is not a control.
Reframed: the authorisation that could not be temporary
The same vendor rejected our recommendation to make a hardware security module’s host-command authorisation temporary, because its terminal management system has to generate and export keys on demand. It was right about that constraint, and we said so. But permanent authorisation combined with keys marked exportable is exactly the combination that causes the problem. The way out was not to insist, and not to give up: bound it and watch it. A minimal command list, key attributes locked, every export command logged and reviewed. A control you cannot remove can still be narrowed.
A control you cannot remove can still be narrowed.
Accepted: no agent on an immutable operating system
A payments platform ran its container nodes on an immutable, read-only operating system with no package manager and no way to install an agent. Authenticated internal vulnerability scans, as the requirement describes them, were technically impossible. The client proposed a layered substitute: signed immutable images that are rebuilt rather than patched, image scanning before deployment, runtime threat detection from the cloud provider, network-layer scans, and infrastructure-as-code with admission controllers so that nothing undeclared reaches the cluster. All of it was written up in a formal worksheet.
We accepted it. The constraint was real and technical, not a preference. Each piece of the substitute was evidenced as running, not described. And together they met the intent of the requirement, which is to know what is vulnerable on the inside, not to run a particular kind of scan. That is the difference from the firewall case above: a substitute that addresses the purpose, with evidence, for a constraint the client did not choose.
Accepted, with a residual weakness: the guard at the door
A data centre hosting a 3DS access control server had no single-person entry portal, which the 3DS standard requires to stop people following each other in. The client proposed a guard at the door as the compensating control.
We asked for it to be documented on the worksheet. The following month we proposed validating it with an unannounced check of the guard’s presence, at any hour. A year later, in the next cycle’s notes, we were still asking: how does the guard check visitors against a current access list? What does he record? Is there a written procedure, and training? Are there spot checks of his performance?
The control was accepted. The guard checked visitors against a current list, staff had to be pre-authorised, every visitor was scheduled in advance, and a printed procedure sat at the guard’s post. Formal spot checks of the guard were never put in place. That is the honest residual weakness, and it is in the record. A person is a weaker control than a door unless their work leaves records, and a compensating control has to be re-proven every year. It is accepted for a cycle, not forever.
What people get wrong
They offer a control for a different requirement and call it compensating. The test is simple: does the substitute address the purpose of the requirement it replaces, or a purpose nearby?
They write the worksheet instead of fixing the control. Most findings are cheaper to fix than to compensate, and a worksheet is reviewed every year for as long as it exists.
They treat acceptance as permanent. A compensating control is accepted against the evidence of one cycle. Next year it is asked for again.