Mapping Findings to PCI-DSS, GDPR, SOC 2

Most organizations commissioning a penetration test are doing it for at least two audiences at once: the engineering team who has to fix what was found, and an auditor or a client who needs proof a specific compliance requirement was actually satisfied. A report that only speaks to the first audience makes the second one do extra work it should not have to do.

PCI-DSS: penetration testing is often explicitly required

The Payment Card Industry Data Security Standard requires regular penetration testing for organizations handling cardholder data, with specific expectations around scope, frequency, and remediation retesting. A report aligned to PCI-DSS should make clear which requirement each finding relates to, and, just as importantly, should distinguish confirmed penetration test findings from automated scan results, since the standard treats them as separate obligations. See our piece on why scanning and testing are not the same thing for why that distinction is not just semantic.

GDPR: less prescriptive, still material

GDPR does not mandate penetration testing by name, but its requirement for "appropriate technical and organizational measures" to protect personal data is regularly interpreted, by regulators and by courts, to include regular security testing for any organization processing meaningful volumes of personal data. Findings involving personal data exposure specifically, an IDOR that leaks another user's records, an exposed storage bucket containing customer information, are worth flagging explicitly as data protection findings, not just generic severity ratings.

SOC 2: evidence over assertion

SOC 2 audits focus heavily on whether controls actually operated as described, not just whether they exist on paper. A penetration test report that shows dated, specific evidence, what was tested, when, by whom, and with what result, functions as exactly the kind of control evidence a SOC 2 auditor is looking for. A tamper-evident audit trail strengthens this considerably, since it lets an auditor verify the evidence itself has not been altered after the fact. See tamper-evident audit logs for how that actually works.

This only works if findings are structured, not just narrative

Compliance mapping is only practical if findings are recorded as structured data, severity, confidence, target, source, from the start, rather than reconstructed from free-text prose after the fact. That structure is also what makes a report genuinely useful for the client's own tracking, not just for the auditor reading it once.