Vanta Flagged Your Pentest Control. Here Is What Actually Closes It.

Quick Answer: Compliance platforms like Vanta and Drata collect evidence, but the platform itself does not perform your penetration test, so the pentest control stays open until you upload a report from an independent tester. Drata's DCF-19, for example, asks for a report showing scope and results plus proof that findings were fixed. The upload turns the control green. Your auditor decides whether the test was the right one.

You connected AWS, GitHub and your identity provider. Most of the dashboard turned green on its own. Then one control stayed stubbornly open, marked as needing manual evidence, and it says something about penetration testing.

That control is not a bug in the platform. It is the one piece of evidence no integration can generate.

Because a penetration test is an activity, not a configuration. Compliance platforms read settings from your systems: whether MFA is enforced, whether backups run, whether laptops are encrypted. A penetration test is a person actively trying to break into your application and documenting what worked. There is no API to pull that from.

So the platforms treat it as a document you upload. Vanta's help centre says customers can upload recent penetration tests on the Documents page, and notes that some auditors also accept a penetration test as vulnerability scanning evidence, because a test typically includes a scan of server hosts. Drata lists it as control DCF-19, "Penetration Tests", among the controls it does not monitor automatically.

The platform's job ends at storing the file and tracking when new evidence is due. Whether the file is good enough is decided later, by someone else.

Drata's DCF-19 asks for evidence of your most recent penetration testing activities: the report showing scope and results, plus evidence that findings were tracked and remediated. Drata's published guidance is specific enough to work as a checklist even if you use Vanta or another platform.

In its ISO 27001 evidence guidance, Drata gives examples: reports from a third-party or internal tester showing the scope and results of the assessment, and evidence of internal tracking and remediation of findings, such as internal tickets or change documentation. It adds that tests should be conducted at least annually or after significant changes to the environment.

Read that list again, because the second half is where teams get caught. The report alone is not the full evidence. An auditor will want to see that what the report found was then handled.

In practice, a complete evidence pack for this control looks like:

If your tester delivers findings as a CSV or JSON export, link each row to the ticket that closed it. That one step answers the auditor's follow-up question before it is asked.

No. The checkmark turns green when a file is uploaded. The auditor reads the file.

This is where the real risk sits. The platform cannot tell a thorough test from a thin one, so it marks both as complete. Problems show up weeks later, during fieldwork, when the auditor opens the report and finds a scope that does not match the system description, a date outside the period being audited, or an automated scan labelled as something more.

There is also a structural reason auditors care about who did the test. A firm that both tests your systems and audits the results loses its independence, which is why auditors often hand you a shortlist of testing firms rather than doing the test themselves. Comparing two or three quotes from that list is normal practice, not a sign you are being difficult.

It depends on the wording of the control and on your auditor. A vulnerability assessment is often enough for vulnerability management controls, while a penetration test is needed when the auditor, a contract or an insurer names one. We covered the general difference in why a scanner report is not a pentest. For compliance platforms specifically, it breaks down like this.

A vulnerability assessment combines automated discovery with manual validation of every critical and high finding. It is audit-recognised evidence for ISO/IEC 27001 Annex A.8.8, management of technical vulnerabilities, and it is a common first piece of independent evidence for a company that has none. Drata's own control-readiness guidance lists vulnerability assessments among example evidence for DCF-19.

A penetration test adds manual exploitation and business-logic testing behind the login, across user roles. If your auditor, a customer contract or an insurer asks for a "penetration test" by name, or you need evidence for ISO 27001 Annex A.8.29, security testing in development and acceptance, a vulnerability assessment will usually not be accepted.

For SOC 2 Type II preparation on a multi-tenant SaaS platform, the test should match what your system description covers, which usually means the API and tenant isolation, not just the public surface. That is why we point SOC 2 Type II preparation to a web app and API penetration test rather than a vulnerability assessment. Many auditors also expect the test to fall inside the period the report covers, so a test from before the observation window started may not count. Our SOC 2 guide explains how that observation period works.

The cheapest mistake to avoid: buying the smaller test, uploading it, watching the control turn green, and learning during fieldwork that it does not match what the auditor needed. If you are not sure, ask your auditor which control the test is evidence for before you order anything. It is a one-email question.

If your auditor wants a penetration test by name, the Focused Web App Penetration Test (from €1,800) is the smallest scope that meets it. We will tell you which one fits before you order.

Four checks, done before anyone signs a statement of work:

No. Some testing firms offer direct integrations that push findings into the platform automatically, which removes the manual upload. It does not change what the auditor accepts. A PDF report, a signed attestation letter and a findings export uploaded by hand are the same evidence.

We do not have an API integration or a commercial partnership with any compliance platform. You upload our report and findings export manually, and your platform will keep showing the control as manual evidence. That is how the control is designed, not a gap in the evidence. More on how the handover works is on our pentest for compliance platforms page.

What matters is what the files say. Choose the test that matches the control, keep the remediation trail next to it, and the green checkmark will mean what everyone assumes it means.