One finding, four frameworks. How to map a pentest result to the controls auditors actually ask about.
A list of vulnerabilities is not what an auditor is looking for. They want to know which control each one exercises — and whether that control held. The good news is that a single finding usually answers for several frameworks at once. Here is how the mapping works, which identifiers are safe to cite, and where people quietly get it wrong.
The short version: the frameworks an auditor cares about are different vocabularies for the same handful of security properties. A pentest finding is a fact about one of those properties being broken, so it almost always speaks to several frameworks at once. Mapping is the act of writing down, per finding, which control each framework would file it under — OWASP for the technical class, SOC 2 for the Trust Services Criteria, ISO 27001 for its Annex A controls, PCI DSS for its requirements. Do it as part of the test and compliance evidence falls out of the work. Do it as a separate spreadsheet six weeks later and it becomes a second project nobody budgeted for.
Why auditors want findings mapped to controls
An auditor is not assessing whether you have bugs — everyone has bugs. They are assessing whether your controls work: whether access is restricted by need, whether software is developed securely, whether systems are configured and tested. A raw finding like "IDOR on the invoice endpoint" does not answer that question on its own. The same fact, written as "the logical-access control that should restrict a record to its owner failed, here is the proof," is exactly the evidence a control owner needs. Mapping is the translation between the two. It turns a technical result into something that drops straight into a control narrative, and it lets a reviewer trace a line on your report to the clause in their framework without having to interpret.
There is a second, quieter reason. Several frameworks don't just accept pentest evidence — they expect it. PCI DSS has a dedicated requirement area for regularly testing the security of systems, penetration testing included. SOC 2 engagements routinely lean on independent testing as supporting evidence for the logical-access and change-management criteria. A test whose findings are already mapped to those controls is the artefact the auditor was going to ask for anyway.
One finding, several frameworks at once
Take the single most common high-impact web finding: broken object-level authorization — the IDOR/BOLA class, where request GET /invoices/1043 returns a record that belongs to another tenant. That one fact fans out across every framework a B2B SaaS company is likely to face, because every framework has something to say about access control.
Nothing about the underlying bug changed between those four rows. What changed is the lens. Once you see that, mapping stops being guesswork and becomes a lookup: identify the security property that broke, then read it through each framework's language. The rest of this piece walks the four lenses in the order of how precise you can safely be.
OWASP: the precise technical anchor
OWASP is where you can and should be exact, because its categories are stable, public and widely understood. Map the finding's class first; everything else hangs off it. The common cases:
- Broken access control / IDOR / BOLA → A01:2021 Broken Access Control, and for an API surface, API1:2023 Broken Object Level Authorization in the OWASP API Security Top 10.
- SQL, OS-command, or other injection → A03:2021 Injection.
- Security misconfiguration — default credentials, verbose errors, an exposed admin panel, permissive CORS → A05:2021 Security Misconfiguration.
- Broken authentication / session handling → A07:2021 Identification and Authentication Failures.
- SSRF → A10:2021 Server-Side Request Forgery.
Two cautions. First, cite the edition: the Top 10 is dated (2021 for web, 2023 for the API list), and the category numbers shifted between editions, so a bare "A1" is ambiguous. Second, OWASP is a classification, not a compliance framework — it tells an auditor what kind of problem this is, which is precisely the input the other three frameworks need to file it correctly.
SOC 2: criteria, not numbered controls
This is the mapping people most often get wrong, because they treat SOC 2 as if it had a numbered control catalogue. It does not. SOC 2 is an attestation against the Trust Services Criteria — the five categories of Security, Availability, Processing Integrity, Confidentiality and Privacy, with Security (the "Common Criteria," the CC series) mandatory. You map a finding to the relevant criterion area, not to a clause number you half-remember.
For the IDOR example, the natural home is the logical and physical access controls area (the CC6 group), which is about restricting access to information and systems to authorized users. An injection or secure-development failure speaks more to the change-management and system-operations areas (the CC7–CC8 groups), which cover how software changes are developed, reviewed and deployed. Because SOC 2 controls are defined by each organization against those criteria, the honest mapping is "this finding is evidence against your logical-access criteria," and then let the control owner connect it to their specific documented control. Inventing a precise sub-criterion for someone else's system is how you hand an auditor something to dispute.
The mistake to avoid. SOC 2 has no universal "control 6.1.2" that means the same thing everywhere — the criteria are shared, but the controls that satisfy them are the organization's own. Map to the criterion area and attach the proof. A reviewer can always tighten a correct-but-general mapping; they cannot un-see a confidently wrong clause number.
ISO 27001: Annex A control themes
ISO/IEC 27001 carries its controls in Annex A, and the 2022 revision reorganised them into four themes — Organizational, People, Physical and Technological controls — replacing the older fourteen-domain layout. Most pentest findings land in the Technological theme. For the access-control example, the relevant controls are the ones covering access control and information access restriction (restricting access to information in line with the access-control policy). An injection or insecure-build finding maps to the secure development life cycle and secure coding controls; a misconfiguration maps to configuration management.
If you track the exact Annex A reference numbers and you are confident in the edition, cite them. If you are not certain whether a client is on the 2013 or 2022 structure, name the control theme — "access control," "secure coding," "configuration management" — rather than a number that may not exist in their version of the standard. The theme is unambiguous across editions; the numbering is not.
PCI DSS: requirement areas
PCI DSS is organised as numbered requirements, and for mapping purposes the useful granularity is the requirement area. The ones a pentest most often touches:
- Requirement 6 — develop and maintain secure systems and software. This is the home for injection, insecure coding, and the broader "fix known vulnerabilities" expectation.
- Requirement 7 — restrict access to system components and cardholder data by business need to know. This is where the IDOR/BOLA finding lands.
- Requirement 2 — apply secure configurations to all system components. The natural home for security-misconfiguration findings.
- Requirement 8 — identify users and authenticate access. Broken-authentication and session findings map here.
- Requirement 11 — regularly test the security of systems and networks. This is the requirement that asks for the pentest itself, so a mapped report is evidence of the testing control as well as of the findings.
PCI DSS v4.0 defines granular sub-requirements (6.2.4, 11.4.x and so on), and if your scope genuinely involves the cardholder data environment and you know the version, those are worth citing. Outside a confirmed CDE scope, mapping to the requirement area is the correct conservative level — it tells the assessor which control family the finding exercises without overstating what the test covered.
Keeping the mapping honest
A mapping is only worth anything if it inherits the same discipline as the finding behind it. Three rules keep it honest. First, only map verified findings. A candidate that did not reproduce has no business implying a control failed — mapping an unproven signal to a SOC 2 criterion manufactures a compliance gap that does not exist. We hold the unproven back for exactly this reason; how a candidate becomes a finding covers the gate it has to pass first. Second, separate "a control was tested" from "a control failed." A test that exercised your access-control layer and found it held is evidence the control works — that is a result an auditor wants too, and it should read differently from a breach. Third, map to the level you can defend: a precise OWASP category, a SOC 2 criterion area, an ISO control theme, a PCI requirement area. Precision you cannot back up is a liability in an audit, not an asset.
Done this way, the mapping is a by-product of testing rather than a separate deliverable. Each verified finding already carries its request, its control comparison and its reproduction; adding the control references it touches is one more field on an evidence package you have already built — and it is what turns a pentest report into something a compliance team can file directly.
FAQ
Does a pentest make us SOC 2 or PCI DSS compliant?
No. A pentest is evidence that specific controls were exercised and either held or failed; it is not an audit opinion and it grants no certificate. SOC 2 is attested by a CPA firm against the Trust Services Criteria and ISO 27001 is certified by an accredited body. What a mapped pentest does is feed those processes — it produces the independent-testing artefact that criteria like SOC 2's logical-access controls and PCI DSS Requirement 11 expect, and it shows an auditor which controls each finding touches.
Why does one finding map to several frameworks at once?
Because the frameworks describe the same small set of security properties in different languages. A broken object-level authorization bug is an access-control failure however you read it: OWASP calls it A01 and API1, SOC 2 reads it against its logical-access criteria, ISO 27001 against its access-control controls, PCI DSS against its restrict-access-by-need requirement. One fact, several vocabularies.
What if we are not sure of the exact control number?
Map to the control area and say so, rather than inventing an identifier. OWASP categories are stable and worth citing exactly; SOC 2 is criteria, not numbered controls, so map to the Common Criteria area; for ISO 27001 and PCI DSS, cite the control theme or requirement area unless you are certain of the sub-clause. A correct-but-general mapping can be tightened; a confidently wrong one has to be disproved.
Want to see where the mapping starts? Read how a candidate becomes a finding, open a worked report to see a finding with its controls attached, review how we map findings to frameworks, or book a demo.