Clients expect their QSA to have a clear answer for every requirement, and some assessors pretend they do. We would rather tell you where the standard leaves room, what we do with that room, and where we are still not sure. This is one of those places.
The requirement
Requirement 3.4.2 asks for technical controls that prevent the copying or relocation of card numbers when they are accessed over remote access, except for personnel with documented, explicit authorisation and a legitimate, defined business need.
The case it is written for is obvious: a support agent with a remote desktop session should not be able to paste card numbers into a spreadsheet at home. The case it is silent on is the one we meet on most assessments: database administrators working on systems that hold card data, over SSH, from a hardened workstation, with every session logged.
The two shortcuts
Assessors take one of two shortcuts here. The first is to demand that copy-and-paste be blocked in every administrative session. That is unworkable. An administrator with a shell can read a table; if they can read it they can relocate it, and a clipboard control changes nothing about that.
The second is to tick the requirement because the data is encrypted at rest. That is too easy. If the administrator can reach the keys, or can grant themselves access to the keys, then copying encrypted card data is copying card data with one extra step.
The test we apply
The question we ask is: who can decrypt what they could copy?
If administrators can reach the keys, then copying encrypted data is a real relocation of card data, and either the technical control or the documented exception has to be real. “Real” means a named person, a written business need, an approval that was actually given, and sessions that are logged and reviewed.
If the keys are genuinely separated from administrative access, in a hardware security module or a cloud key service, with application-only access and administrators technically unable to grant themselves rights, then key separation meets the purpose of the requirement. An administrator who copies the table has copied ciphertext they cannot read. We say so openly in the report, with the reasoning, rather than hiding it behind “in place”.
The exception we have used
Here is the uncomfortable part. On more than one assessment the keys were not separated well enough for the second reading, and blocking copy in SSH sessions was not realistic. We ended up taking the administrative route: the administrators were given a documented business justification to access, and in principle relocate, card data, even though they do not actually need to relocate it. The requirement allows this. We have reused the approach since, because we have not found a better one and we do not want to push clients to cripple their administrators’ tools for a control that would not work anyway.
We are not comfortable with it. A justification written to satisfy an exception is a weaker control than the one the requirement wanted, and we know it. We read the requirement broadly, as “do not relocate cardholder data, even encrypted”, and we hold clients to that reading in practice. But an honest report should say where the standard was met by its letter and where it was met by its intent.
An honest report should say where the standard was met by its letter and where it was met by its intent.
What people get wrong
They expect the QSA to have a rule for everything. The standard is written for a very wide range of environments, and in places it is deliberately broad. An assessor who claims certainty where the text has none is making it up, and the next assessor may make it up differently.
They treat “encrypted” as the end of the conversation. Encryption moves the question to the keys. If you cannot describe who can reach the keys and how, you have not answered the question, you have renamed it.