1. How Vanta and Drata Handle Penetration Testing Checks
Vanta and Drata automate much of the evidence collection for SOC 2 by connecting to your cloud infrastructure, identity providers, and SaaS tools through integrations. They continuously monitor automated checks — MFA enforcement, encryption at rest, backup frequency — and update your compliance dashboard in real time.
Penetration testing is one of the few checks that cannot be automated. Both platforms require manual evidence upload for the penetration testing check because no API integration can verify that adversarial testing occurred. This is important to understand: unlike your GitHub integration or your AWS check, the penetration testing check requires human action and document review.
Both platforms treat the penetration testing check as a policy control — meaning your compliance auditor will review the uploaded evidence during their audit evidence review period. What you upload is what your auditor sees. There is no automated validation.
2. Vanta Penetration Testing Requirements
Vanta surfaces penetration testing under the "Vulnerability Management" and "Risk Assessment" policy sections. The penetration testing check appears as a manual evidence requirement in your Tests dashboard. Here is what Vanta requires:
- Document upload: Penetration test report. The full penetration test report as a PDF or formatted document. Vanta does not validate the document content — your compliance auditor does. But the document must be clearly titled, dated, and associated with your organization's name.
- Document upload: Remediation evidence or attestation letter. Vanta's penetration testing check typically requires both the initial report and evidence of finding remediation. Upload your retest report or remediation attestation letter as a separate document in the same check, or in the associated remediation evidence field.
- Policy: Penetration Testing Policy. Vanta requires a written Penetration Testing Policy document as part of your policy library. This policy should state: how often testing is conducted, who is authorized to conduct it, how findings are managed, and how the policy connects to your vulnerability management program.
- Evidence date must fall within audit period. When uploading, the Vanta evidence review checks the document date against your audit observation period. A report dated outside the audit window will be flagged by your compliance auditor.
- Custom evidence fields for audit scope. Vanta allows you to add context notes to manual evidence. Use this field to confirm: (1) who conducted the test, (2) what systems were in scope, (3) the current status of identified findings. Your auditor reads these notes.
When your Vanta-connected auditor reviews your evidence package, they will open every document you have uploaded to the penetration testing check. They evaluate: Is the test dated within the audit period? Does the scope align to the system description? Are findings documented? Is there evidence of remediation? A report that does not clearly answer these four questions will generate an auditor question — which delays your audit close date.
3. Drata Penetration Testing Requirements
Drata handles penetration testing under the "Vulnerability and Patch Management" control family. The penetration testing control (typically Control ID VUL-03 or similar depending on your framework configuration) requires manual evidence upload. Drata's evidence management is more structured than Vanta's — each control has specific evidence types defined.
- Evidence Type: External Penetration Test Report. Drata defines this as a separate evidence type from internal testing. Upload your full external penetration test report, which must include testing date, scope, methodology, findings by severity, and tester identity.
- Evidence Type: Internal Penetration Test Report (if applicable). For companies with significant internal network infrastructure or on-premises systems in scope, Drata may require separate internal test evidence. For pure cloud SaaS, external testing typically satisfies this with appropriate scope documentation.
- Evidence Type: Penetration Test Remediation Evidence. Drata separates remediation evidence from the initial report. Upload your retest attestation letter or a documented remediation tracking summary as a separate evidence item.
- Policy: Drata's policy library includes a Vulnerability Management Policy template that covers penetration testing. Your policy must be finalized, acknowledged by your team, and versioned — Drata tracks policy review dates, and an outdated policy will generate a control finding.
- Frequency control: Drata tracks when the last test was conducted. The control will show as expiring as you approach 12 months from the last uploaded test date. Plan your next test before this date expires to maintain continuous compliance rather than having a gap period.
- Connected vendor: Drata allows tagging the penetration testing firm as a vendor. Adding your penetration testing firm to your Drata vendor list (under Vendor Management) and linking them to the penetration testing control creates a cleaner evidence chain that auditors appreciate.
4. Vanta vs Drata: What Is Different
Vanta
- Evidence upload is more flexible
- Context notes field lets you add scope confirmation
- Auditor reviews uploaded docs directly
- Policy library templates provided
- Less structured evidence type definitions
- Single upload can cover multiple evidence needs
Drata
- More structured evidence type requirements
- Separates test report from remediation evidence
- Tracks evidence expiration dates automatically
- Vendor management integration for testing firms
- Policy acknowledgment tracking built in
- Control ownership and review workflow
The core evidence — your penetration test report, your policy, and your remediation attestation — is the same for both platforms. The difference is in how each platform organizes and presents that evidence to your auditor. If you are switching platforms or pursuing multi-framework compliance, structure your evidence package to satisfy the more specific Drata requirements and it will work on Vanta too.
5. Evidence Format That Works on Both Platforms
To close the penetration testing check on both Vanta and Drata without auditor follow-up questions, your evidence package needs to include these three documents:
- Document 1: Penetration Test Report (PDF). Must clearly show: (1) your company name and the systems tested, (2) the testing dates, (3) the name of the testing firm and lead tester, (4) the testing methodology used, (5) findings organized by severity with business impact descriptions, (6) remediation recommendations for each finding. The executive summary must be readable by a non-technical auditor — this is the first page they will read.
- Document 2: Remediation Attestation Letter (PDF). A separate signed document from the penetration testing firm confirming: (1) a retest was performed after remediation, (2) all critical and high findings are confirmed remediated, (3) the date of retesting. This is what auditors use to confirm findings were not left open. A note in the original report saying "remediation is the client's responsibility" does not close this evidence requirement.
- Document 3: Penetration Testing Policy (PDF or platform native). Your organization's written policy stating the frequency of penetration testing, how tester independence is maintained, how findings are tracked and remediated, and how the policy connects to your vulnerability management process. Both Vanta and Drata have policy templates — but customize the template to reflect your actual process, not just the boilerplate. Auditors ask about implementation of the policy, not just its existence.
6. Why Penetration Test Evidence Gets Rejected
Based on what we have seen in client engagements, these are the most common reasons penetration test evidence fails to satisfy compliance platform auditor review:
The most common rejection reason. If your SOC 2 Type II observation period is January–December 2026, a penetration test dated November 2025 does not satisfy evidence requirements for that period. Check your audit window before uploading — and confirm with your auditor whether the test date needs to fall inside the window or whether testing just needs to have occurred within 12 months of evidence submission.
- No remediation evidence. The initial test report alone is not sufficient for most auditors. They want to see that findings were addressed — and the confirmation must come from the testing firm, not just from your internal team's ticket system.
- Scope does not match system description. If your SOC 2 system description includes your production web application and AWS infrastructure, but the penetration test scope only lists IP addresses or domain names without clarifying what systems they represent, auditors cannot confirm alignment. Scope statements in reports should use system names that match your system description terminology.
- No methodology documentation. Reports that list "findings" without explaining how they were found are harder for auditors to evaluate. Include a methodology section that references a named framework (OWASP, PTES, NIST) — even one paragraph is enough.
- Findings with no business impact. Pure technical reports with CVSS scores and CVE references but no description of what an attacker could do if they exploited the finding are difficult for non-technical auditors to evaluate. Add a "Business Impact" sentence to each finding.
- Internal testing by the engineering team. Some companies upload results of internal testing by their own developers. While technically acceptable for SOC 2 (unlike PCI DSS, which requires independence), auditors increasingly flag this as insufficient. External third-party testing evidence generates significantly fewer auditor questions.
- Automated scan reports submitted as "penetration tests." Nessus reports, Qualys scans, or Rapid7 InsightVM output are vulnerability scans — not penetration tests. Both Vanta and Drata auditors know the difference. Submitting scan output as penetration test evidence is one of the fastest ways to generate an auditor finding.
7. What Your SOC 2 Auditor Sees When They Review Your Evidence
Understanding what your auditor sees in Vanta or Drata changes how you approach evidence submission. Compliance auditors using these platforms typically follow this process:
- They open the check and review the uploaded document(s). The PDF is what they evaluate. They skim the executive summary, check the dates, look at the finding count, and read any auditor notes you have added in the platform.
- They verify the test date falls within the audit observation period. This is a mandatory check. They will look for the date in the report header or the executive summary. If the date is ambiguous or appears only on an internal cover page, they may ask for clarification.
- They check whether remediation evidence is present. If you only uploaded the initial report and not the remediation attestation, they will generate a request for remediation evidence. This delays audit completion.
- They review the scope for alignment to the system description. They will look for explicit mention of the systems covered by the SOC 2 report — your production application, your cloud infrastructure, your customer-facing APIs. Generic scope descriptions ("all production systems") are acceptable but invite follow-up questions.
- They check whether any findings are critical or high severity. If critical or high findings are present, they will look for evidence of remediation or formal risk acceptance. An open critical finding with no documentation is a SOC 2 audit finding.
8. Sprinto, Secureframe, and Other Platforms
Beyond Vanta and Drata, several other compliance automation platforms are commonly used by early-stage SaaS companies:
- Sprinto. Sprinto handles penetration testing as a control under its "Vulnerability Assessment and Penetration Testing" control group. Evidence upload requirements are similar to Drata: separate fields for the test report and remediation evidence. Sprinto also tracks testing frequency and will alert when a test is overdue.
- Secureframe. Secureframe's penetration testing control accepts document uploads with similar requirements to Vanta. Secureframe has a vendor directory where you can register your penetration testing firm — connecting the vendor record to the penetration testing evidence creates a cleaner audit trail.
- Thoropass (formerly Laika). Thoropass is used by companies requiring more hands-on compliance support alongside the platform. Penetration testing evidence requirements are similar across all platforms — the underlying SOC 2 criteria do not change based on the compliance automation tool you use.
Regardless of which compliance platform you use, the evidence that closes the penetration testing check is always the same: a dated report from an independent third-party tester, covering your in-scope systems, with findings documented and remediation attested. Build your evidence to that standard and it will work on any platform.
9. How NullStrike Closes Vanta and Drata Checks Without Rework
Reports Built to Close Platform Checks on First Upload
NullStrike has worked with companies on Vanta, Drata, Sprinto, Secureframe, and Thoropass. We know exactly what each platform's auditors look for — and we structure every report to satisfy those requirements before the client uploads anything.
When you start an engagement with us, we ask which compliance platform you are using and where you are in your audit cycle. That information shapes the report — the executive summary language, the scope statement, the finding format, and the remediation attestation letter are all written to satisfy the specific evidence review process your auditor uses.
- Report covers page includes audit period dates. We confirm with you the audit observation period before testing and include the testing date prominently on the report cover page in a format that matches what platform auditors look for.
- Scope statement uses your system description language. We ask for your SOC 2 system description (or your Vanta/Drata system description) before writing the scope section. Our scope statement references your systems in the same language your auditor will cross-reference — eliminating scope alignment questions.
- Remediation attestation letter delivered as a separate document. Both Vanta and Drata treat the initial report and remediation evidence as separate items. We deliver them separately — one report, one attestation letter — with dates that clearly show the timeline from initial testing to confirmed remediation.
- Business impact in every finding. Our finding format includes a mandatory "Business Impact" section that describes what an attacker could accomplish — written for a non-technical compliance auditor, not just a security engineer.
- Penetration Testing Policy template included. We provide a customized Penetration Testing Policy template formatted for direct import into your Vanta or Drata policy library — reducing the policy documentation overhead on your team.
- Upload guidance included with delivery. Every client receives step-by-step upload guidance for their specific platform — which documents go in which fields, what notes to add in the platform's context fields, and what to do if the auditor asks a follow-up question.
- Direct auditor response when needed. If your compliance auditor has a question about our engagement that you cannot answer from the report, we respond directly — either via email through your auditor contact or via a short written statement you can upload to the platform.
Close Your Vanta or Drata Penetration Testing Check Without a Second Upload
Tell us your compliance platform, your audit window, and your system scope. We will deliver a report and attestation letter built to pass your auditor's review — first time, no rework.
Summary
Vanta and Drata automate most SOC 2 evidence collection — but penetration testing is manual and requires specific documents: a dated external test report, a remediation attestation letter, and a written penetration testing policy. The most common reasons evidence fails auditor review are wrong dates, missing remediation evidence, scope mismatch with the system description, and confusing vulnerability scan output with actual penetration testing.
NullStrike reports are written with compliance platform auditor review in mind from the first page. The scope language matches your system description. The attestation letter is a separate document. The business impact in every finding is written for non-technical reviewers. And we give you the upload instructions for your specific platform. The goal is zero rework — you upload once and your auditor closes the check.