You're in the third week of audit preparation. The pentest report contains dozens of findings, screenshots, request traces, and remediation notes. Then the auditor asks a simple question: “Which control does each finding affect, and what evidence supports that conclusion?”
A vulnerability report can prove that an exploit worked. An auditor needs to know what that exploit says about access control, monitoring, vulnerability management, encryption, or another defined obligation. A compliance heat map for pentesting teams supplies the missing layer by connecting the finding, risk rating, control reference, evidence artifact, and remediation status in one usable view.
Table of Contents
- The Moment Every Pentest Team Dreads
- What a Compliance Heat Map Actually Is
- Two Ways to Build One and Why One Falls Apart
- How to Read a Compliance Heat Map Cell
- Mapping Pentest Findings to SOC 2, ISO 27001, and PCI
- Showing the Heat Map to Auditors Without Getting Pushed Back
- A Short Checklist Before You Send the Next Heat Map
The Moment Every Pentest Team Dreads
The security lead opens the findings folder and starts searching. One document contains the authenticated SSRF. Another contains the proof-of-exploit screenshot. A spreadsheet has remediation owners, but the control references are incomplete. The GRC platform has a separate list of audit requirements, and nobody is certain whether the compensating firewall rule was included in the original risk rating.
The auditor isn't asking for more color. They're asking whether the testing evidence supports a control conclusion.
A raw pentest finding answers a technical question: Can an attacker perform this action? A compliance review asks a broader question: What security objective failed, how significant is the exposure, and can the organization prove that it has addressed or accepted the risk? Those questions overlap, but they aren't interchangeable.
Practical rule: A finding without a control reference is a security observation. A finding with exploit proof, control mapping, and remediation context can become audit evidence.
Consider an authenticated SQL injection in a customer portal. The technical report might document the endpoint, payload, database response, and returned data. That's valuable proof. It still doesn't tell the auditor whether the issue affects logical access controls, data protection, monitoring, vulnerability management, or several controls at once.
The team needs a record that preserves the technical facts while translating them into the auditor's vocabulary:
- Finding: What was discovered and where?
- Exploit proof: How was exploitability validated?
- Likelihood and impact: Why does the issue occupy its risk position?
- Control ID: Which framework requirement is threatened?
- Control status: Is the control failing, partial, or supported by compensating evidence?
- Action ownership: Who is fixing it, and how will retesting confirm closure?
That record is the foundation of the heat map. The visual matrix comes later. Starting with colors before assembling the evidence creates a polished artifact that may not survive the first audit question.
What a Compliance Heat Map Actually Is
A compliance heat map is a visual risk model built from evidence. In a pentesting program, each plotted item should connect a validated finding to a likelihood rating, an impact rating, a threatened control, and the artifact that supports the assessment.
That makes it different from a vulnerability heat map. A vulnerability heat map generally groups technical issues by severity, exploitability, asset, or vulnerability score. A compliance heat map adds the governance layer. It shows what the issue means for a defined control objective and whether the organization can demonstrate control effectiveness.
Start with four required components
Likelihood describes how realistically the finding can be exploited in the assessed environment. Use the testing conditions, required privileges, exposure, attack path, and observed barriers. An authenticated SSRF in a staging API shouldn't receive the same likelihood rationale as an unauthenticated issue exposed on a public production endpoint.
Impact describes what follows if exploitation succeeds. Consider the affected data, system function, business process, and compliance objective. A server-side request forgery that reaches internal administration services may create a different control concern from one limited to a harmless metadata response.
Control reference identifies the specific requirement threatened by the finding. The reference might point to a SOC 2 Trust Services Criterion, an ISO 27001 Annex A control, or a PCI-DSS requirement. Without that identifier, the map can't support traceability.
Evidence artifact proves the technical and compliance conclusions. Useful artifacts include an authorized request and response, screenshot, exploit transcript, video, affected asset record, control test result, remediation ticket, and retest result. Guidance on combining framework requirements in a structured control view is also available in this compliance matrix explanation for security teams.
A worked example
Suppose testers authenticate to a staging API, submit a crafted URL, and cause the server to request an internal service. The evidence bundle should preserve the request, response, account privilege, target behavior, and authorization for the engagement.
The map then records the finding's likelihood and impact, identifies the control threatened by inadequate server-side request restrictions, and links to the exploit proof. If an egress proxy or allowlist reduces the reachable attack path, the residual rating should reflect that control evidence rather than treating the raw exploit result as the final risk.
The matrix is only the reader-friendly surface. The evidence record underneath is what makes the square defensible.
Two Ways to Build One and Why One Falls Apart
Most introductory guidance starts with a 5Ă—5 likelihood-versus-impact matrix. That structure is established in compliance risk assessment practice. A common model uses likelihood and impact values from 1 to 5, producing a score from 1 to 25. In one published framework, scores from 11 to 17 are orange, or high, while scores from 18 to 25 are red, or critical, as described in this compliance risk assessment heat map framework.
The matrix itself isn't the problem. The problem is treating it as the complete deliverable.
| Attribute | Naive 5x5 Matrix | Evidence-Tied Residual Model |
|---|---|---|
| Primary input | Severity judgment or issue count | Validated finding and supporting artifacts |
| Risk position | Inherent likelihood and impact | Inherent risk, existing controls, and residual risk |
| Control traceability | Often absent | Specific framework control attached |
| Exploit chain | Usually summarized or omitted | Request, response, screenshot, or video linked |
| Compensating controls | Commonly ignored | Evaluated and reflected in residual rating |
| Remediation view | Color indicates urgency | Owner, action, deadline, and retest status |
| Audit response | “This is red” | “This control is affected, this proof supports it, and this residual exposure remains” |
A naive map can place an unpatched component in a red cell based on technical severity. It may never show whether the component is internet-facing, isolated behind a control, monitored, or covered by a documented exception. The map looks decisive while hiding the assumptions that produced the rating.
A mature model separates inherent risk from residual risk. Inherent risk represents the exposure before mitigation. Residual risk represents the remaining exposure after existing controls are considered. The implementation guidance for compliance risk heat maps recommends connecting risks to controls, registers, and action plans so teams can see where mitigation has reduced exposure, rather than counting issues. That approach is described in this residual-risk heat map reference.
Why auditors reject unsupported red squares
An auditor can't validate a color. They can validate a control test, an artifact, a documented exception, and a remediation record.
If a team presents a red cell with no control ID, the auditor must ask what requirement failed. If the team supplies a control ID but no exploit proof, the auditor must ask whether the technical conclusion is reliable. If both exist but the map ignores a compensating control, the auditor may challenge the rating itself.
The question behind every red square is simple: What happened, which control does it affect, and what evidence lets someone else verify your conclusion?
Define the scoring rules before plotting findings. A typical matrix can be useful only when the thresholds remain consistent, so the same score doesn't drift between severity bands during later assessments. The visual should summarize a controlled method, not replace one.
How to Read a Compliance Heat Map Cell
Read a cell as a compact evidence package, not as a colored coordinate. The worked example here is an authenticated SQL injection in a customer portal returning personally identifiable information.
First, identify the finding and asset
The cell should name the finding clearly, for example, “Authenticated SQL injection in customer portal.” Add the affected application, endpoint, environment, account context, and finding identifier. “Portal vulnerability” is too vague for an auditor or a remediation owner.
Next, inspect the proof. The report should link to the authorized request, payload, response, extracted record, screenshot, or other artifact that demonstrates the result. The evidence should establish what the tester did and what the application returned, without exposing unnecessary sensitive data in the audit package.
Then, separate likelihood from impact
Likelihood should explain why exploitation is plausible. In this example, a low-privilege authenticated account can reach the vulnerable portal function, and the tester validated database interaction. The rating should reflect those conditions, not just a generic label such as “high.”
Impact should connect the technical result to the data classification. Returning PII indicates a confidentiality concern and may affect access-control and data-protection objectives. The narrative should state what was exposed and what the attacker could do, rather than relying on the color alone.
Finally, attach the control ID and status. A cell might link the finding to SOC 2 CC6.1, record the control as failing or partial, and point to the evidence bundle. If a web application firewall blocks the tested pattern but doesn't address the underlying query construction, document that distinction and evaluate whether the control reduces the residual risk.
A cell-by-cell plotting test
Use this sequence for every finding:
- Name the finding: Use a precise title and identifier.
- Record the likelihood basis: Include access requirements, reachability, and observed exploit conditions.
- Describe the impact: Tie the consequence to data, systems, and business processes.
- Map the control: Add the exact framework reference and current control status.
- Link the evidence: Provide the artifact, remediation ticket, and retest record where applicable.
A row's color is only the index. The affected asset, exploit proof, control state, and residual-risk rationale tell the auditor whether the index deserves trust.
Mapping Pentest Findings to SOC 2, ISO 27001, and PCI
A pentest finding becomes auditable when the team maps it to a named control and preserves evidence that supports the mapping. The exact reference depends on the assessment scope, framework edition, testing procedure, and service boundaries, so the table below is a working reference for organizing review, not a substitute for the applicable audit criteria.
| Finding Category | SOC 2 CC | ISO 27001 Annex A | PCI-DSS Requirement | Example Evidence |
|---|---|---|---|---|
| Broken access control | CC6.1, logical access controls | A.5.15, access control, where applicable to the assessed control set | Requirement 7, restrict access to system components and cardholder data by business need to know | Authenticated request, role comparison, authorization test, and retest result |
| Missing encryption | CC6.7, transmission and protection considerations, where applicable | A.8.24, use of cryptography | Requirement 4, protect cardholder data with strong cryptography during transmission over open networks | Intercepted session evidence, configuration record, certificate review, and retest |
| Weak logging or monitoring | CC7.2, system monitoring | A.8.15, logging, and A.8.16, monitoring activities | Requirement 10, log and monitor all access to system components and cardholder data | Test event, log record, alert output, retention evidence, and control owner confirmation |
| Unpatched component | CC7.1 and CC8.1, where applicable to the assessed change and risk processes | A.8.8, management of technical vulnerabilities | Requirement 6, develop and maintain secure systems and software | Version evidence, exploit proof, patch record, vulnerability ticket, and retest |
The named control matters because auditors don't score isolated technical severity. They assess whether the relevant control was designed, implemented, tested, and supported by evidence. Independent pentesting guidance specifically identifies SOC 2 CC6.1 for logical access controls, SOC 2 CC7.2 for system monitoring, ISO 27001 A.8.8 for technical vulnerabilities, and ISO 27001 A.8.20 for network security as examples of the concrete mappings that turn a technical result into a compliance artifact. See this penetration testing compliance mapping reference for the control-level approach.
Build the mapping from the finding outward
Start with the exploit, then ask what security objective the exploit challenges. A broken authorization test may affect logical access. A missing TLS configuration may affect protected transmission. A logging gap may affect monitoring and incident detection. An outdated component may affect vulnerability management and secure maintenance.
Don't copy a control number into every related cell without testing the relationship. The evidence should show why the finding threatens that control, what the control currently does, and whether another safeguard changes the remaining exposure.
PCI-DSS requires special care because the applicable requirement and testing procedure depend on the cardholder-data environment and assessment scope. Record the relevant requirement, testing procedure, affected system boundary, and evidence location together. A map that says “PCI issue” leaves too much interpretation to the auditor.
Use one finding across several frameworks carefully
A single pentest result can support multiple framework mappings, but the team should avoid duplicating the same issue as separate unrelated risks. A cross-framework overlay preserves one technical finding while showing its effect on each applicable control set. OWASP's Autonomous Penetration Testing Standard includes a dedicated APTS Compliance Matrix, which provides a concrete model for cross-referencing penetration-testing requirements with major frameworks and standards.
For a deeper example of how evidence, findings, and framework references can appear in deliverables, review these compliance reporting examples for pentest teams. The objective isn't to make one report satisfy every audit automatically. It's to prevent the same validated evidence from being trapped in separate spreadsheets that disagree about status, ownership, or risk.
Showing the Heat Map to Auditors Without Getting Pushed Back
The first team arrives with a polished slide. It contains green, yellow, orange, and red cells, a title, and a severity legend. The red squares came from technical severity ratings, but the slide has no control IDs, evidence links, asset names, or remediation references.
The auditor asks which requirement each red square represents. The security lead opens the findings report, then another spreadsheet, then a ticketing system. The meeting shifts from validation to reconstruction.
The second team starts differently. It opens the control view, selects the affected requirement, and shows the linked finding. The tester's authorization and scope are documented, the exploit proof is attached, the residual rating reflects existing controls, and the remediation ticket identifies the owner, action, and retest state.
That presentation gives the auditor a traceable path:
- Control: Which requirement is being evaluated?
- Finding: What technical condition threatens it?
- Evidence: What proves the condition existed?
- Mitigation: What reduced the exposure?
- Status: Is the control failing, partial, or supported?
- Follow-up: Who owns remediation and retesting?
Formal penetration-testing evidence should include engagement documentation, proof-of-exploit artifacts, remediation and retesting records, and mappings to applicable requirements such as PCI DSS, SOC 2 Trust Services Criteria, ISO/IEC 27001 Annex A, and FedRAMP or NIST SP 800-53 controls. Auditors also expect clear scope, authorization, methodology, and tester independence, as explained in this penetration-testing evidence guide for auditors.
Audit-room test: If the auditor selects any red cell, you should be able to reach the finding, control, proof, owner, and current remediation state without rebuilding the analysis live.
The evidence package also needs controlled records. In regulated environments, teams may use Closer Innovation Labs Corp. regulated industry eSignatures to support approval and attestation workflows around remediation decisions, exceptions, or compliance documentation. That signature record doesn't replace technical proof, but it can help preserve who approved a risk decision and when.
A practical documentation structure can keep the handoff usable. This compliance documentation resource for pentest teams is relevant when the report must support both customer delivery and audit review.
A Short Checklist Before You Send the Next Heat Map
Paste this checklist into the pentest runbook and require a reviewer to verify every item before delivery.
Required data for each finding
- Finding title and ID: Name the condition precisely.
- Affected asset: Record the application, host, environment, and relevant endpoint.
- Exploit proof: Attach the authorized request, screenshot, video, response, or transcript.
- Risk basis: Include the likelihood and impact rationale, plus the technical severity score when used.
- Control reference: Identify the applicable SOC 2 TSC criterion, ISO 27001 Annex A control, or PCI-DSS requirement and testing procedure.
- Evidence link: Make the artifact accessible to the intended reviewer.
- Ownership: Name the remediation owner.
- Remediation date: Record the planned action date and retest status.
Control references to verify
Check that each mapping names the exact framework requirement, not just “SOC 2,” “ISO,” or “PCI.” Confirm that the evidence supports the control relationship and that compensating controls appear in the residual-risk rationale.
The mistake that invalidates the model
Don't send a color-only 5Ă—5 matrix. A matrix without evidence linkage, control traceability, and residual-risk context can misrepresent the exposure even when the colors look reasonable.
Before sending, select every red cell and ask: Who owns the fix? What exactly was found? Which control is affected? What evidence supports the rating? If any answer is missing, the heat map isn't ready.
ThreatExploit AI helps security service providers conduct automated penetration testing across web applications, networks, and cloud environments, then produce evidence-backed reports with compliance control mappings. If your team needs to turn verified findings into clearer audit conversations and reusable client deliverables, visit ThreatExploit AI to explore the platform.