--- title: "How to Document Penetration Test Results for HITRUST and SOC 2 Audits" summary: "Both HITRUST r2 and SOC 2 require documented penetration testing and vulnerability assessment evidence. This guide explains how to document your penetration test results, track remediation efforts, and automate evidence collection so auditors accept your reports without follow-up questions." publishedAt: "2026-04-21" author: "Screenata Team" image: "/static/how-to-document-penetration-test-results-for-hitrust-and-soc-2-audits.jpg" tags: ["HITRUST r2", "SOC 2", "Penetration Testing", "Vulnerability Assessment", "Compliance Automation"] category: "Compliance" featured: false structuredData: "@context": "https://schema.org" "@type": "FAQPage" mainEntity: - "@type": "Question" name: "What do auditors look for in a penetration test report?" acceptedAnswer: "@type": "Answer" text: "Auditors look for an executive summary, a clear testing methodology, a defined scope that matches your audit boundary, a list of findings with severity levels, and documented proof of remediation for any critical or high-risk vulnerabilities." - "@type": "Question" name: "How do HITRUST r2 and SOC 2 penetration testing requirements differ?" acceptedAnswer: "@type": "Answer" text: "SOC 2 is less prescriptive, typically requiring an annual test to satisfy CC7.1 and CC4.1. HITRUST r2 is highly specific under controls 10.m and 10.n, requiring independent testing, specific scoping rules, and strict remediation timeframes based on vulnerability severity." - "@type": "Question" name: "Can I just give the auditor the raw penetration test PDF?" acceptedAnswer: "@type": "Answer" text: "No. Handing over a raw penetration test report without a remediation summary invites unnecessary scrutiny. You should provide the executive summary, the methodology, and a mapped list of findings linked to your internal ticketing system showing how and when issues were resolved." --- Getting a penetration test is only half the work. Documenting the results for HITRUST r2 and SOC 2 audits is where most engineering teams get stuck. Assessors do not just want the PDF from your security firm. They need evidence that you reviewed the findings, tracked the remediation, and integrated the results into your broader vulnerability assessment program. Across HITRUST CSF control domains and SOC 2 criteria, manual documentation of these workflows often leads to missing context. Automating this evidence collection through targeted screenshots and workflow captures ensures that your penetration test results and subsequent fix tickets are formatted properly for assessor review. Here is exactly how to document your penetration testing and vulnerability assessment evidence so you pass the audit without endless back-and-forth. ## What Do Auditors Actually Look For in Penetration Test Reports? Auditors look for proof that the test covered your production environment, was conducted by an independent party, and that you actually fixed the critical issues they found. Honestly, handing an auditor a 200-page raw penetration test report is a mistake. Assessors do not want to read the raw technical payloads, and exposing that level of detail usually invites questions you do not want to answer. Instead, your documentation package should include: * **The Executive Summary:** Showing the date, the vendor name, and the overall conclusion. * **The Scope Statement:** Proving the systems tested match the systems defined in your SOC 2 system description or HITRUST assessment boundary. * **The Methodology:** Confirming the vendor used industry-standard practices (like OWASP Top 10). * **The Findings and Remediation Log:** A clear mapping of what was found, the severity, and the link to your internal tracking system showing it was resolved. The report itself is just the starting point. The actual compliance evidence is your response to that report. ## How Do HITRUST r2 and SOC 2 Penetration Testing Requirements Differ? While both frameworks require you to test your defenses, they treat the evidence very differently. SOC 2 relies on your judgment to define the testing parameters. HITRUST tells you exactly what to do. | Requirement | SOC 2 (CC7.1, CC4.1) | HITRUST r2 (10.m, 10.n) | | :--- | :--- | :--- | | **Frequency** | Typically annual (defined by your own policy). | Annually, or after any significant infrastructure or application change. | | **Independence** | "Independent" can sometimes mean an internal team not responsible for the system, though third-party is standard. | Must be conducted by an independent third party. | | **Remediation** | You must fix issues "timely" based on your own risk assessment policy. | Strict SLAs for remediation based on severity (e.g., Criticals within a specific timeframe). | | **Evidence Needed** | Test report, remediation tickets, and risk acceptance for open issues. | Test report, methodology proof, remediation tickets, retest validation, and formal CAPs (Corrective Action Plans) for delayed fixes. | If you are preparing for a HITRUST r2 assessment, your vulnerability assessment evidence must align perfectly with your documented policies. If your policy says you fix high-severity vulnerabilities in 14 days, your Jira tickets and pull request timestamps better prove that you hit that deadline. ## How Do You Document Vulnerability Assessment and Remediation Evidence? The biggest gap in audit prep is proving that a finding in a PDF actually maps to a deployed fix in your application. To document this correctly, you need a chain of custody. When a penetration tester finds a SQL injection vulnerability, you cannot just tell the auditor "we fixed it." You need to show the lifecycle of that fix. First, capture the specific finding from the vendor's report. Next, document the corresponding Jira or Linear ticket where the engineering team was assigned the work. The ticket needs to show the severity level and the creation date. Then, you need evidence of the actual fix. This means capturing screenshots of the pull request linked to that ticket. The PR must show the code review approval, the passing CI/CD checks, and the merge timestamp. Finally, you need the retest documentation. This is either a follow-up letter from your penetration testing firm confirming the vulnerability is closed, or a screenshot of your internal vulnerability assessment scanner showing the issue no longer exists in production. This exact workflow proves the operating effectiveness of your vulnerability management controls. ## Where Traditional GRC Automation Stops for Penetration Test Evidence Most compliance platforms claim to automate vulnerability management. In practice, this automation is highly limited. Tools like Drata or Vanta connect to your cloud provider via API. They might integrate with AWS Inspector or Tenable to pull in your daily vulnerability assessment scans. They will also give you a file upload button to attach your annual penetration test PDF. That is where traditional automation stops. APIs cannot capture the application-level UI workflow of a developer fixing a specific finding. A GRC platform will show a boolean status of "Pen Test Uploaded: True." It will not automatically link the finding on page 14 of the vendor report to the Jira ticket, the GitHub pull request, and the deployment log. When the auditor asks to sample three high-severity findings and trace their remediation, you are back to manually taking screenshots of Jira and GitHub to build the evidence chain. ## Handling Risk Acceptance for Open Findings You will rarely finish a penetration test and fix 100% of the findings before your audit window closes. You will have open medium or low-severity issues. Auditors expect this. What they will fail you for is ignoring them. For any finding that is not fixed, you must document formal risk acceptance. This requires a screenshot of your risk register showing the specific vulnerability, the business justification for not fixing it immediately, and a sign-off from management (usually the CTO or CISO). The evidence must clearly show that leadership reviewed the vulnerability assessment results and accepted the residual risk. A Slack message saying "we'll get to this next quarter" is not acceptable evidence. A documented risk register entry with a timestamped approval is. ## Learn More About HITRUST r2 Evidence Automation For a complete guide to handling complex evidence requirements across all CSF domains, see our guide on [automating HITRUST r2 evidence collection](/resources/blog/how-to-automate-hitrust-r2-evidence-collection), including how to capture the application-level workflows that APIs miss.