Security testing and evidence your auditor can check
VulnVerify provides the security testing and evidence your auditor asks for: weekly authorized scans of the domain you verified, human-led penetration testing scoped to your audit, and auditor-ready exports, every report and statement in them with a SHA-256 fingerprint you can verify.
Which framework are you working toward?
One page per framework: what it is and who issues it, where scanning and penetration testing appear in its controls, the frequencies it sets, and what VulnVerify provides for each.
SOC 2
An attestation report issued by a licensed CPA firm under AICPA attestation standards (SSAE 18)
Report on a service organization's controls against the Trust Services Criteria: Security (mandatory) plus optionally Availability, Processing Integrity, Confidentiality and Privacy.
ISO 27001
A certification issued by an accredited certification body after a certification audit
Requirements for an information security management system (clauses 4–10) plus Annex A reference controls.
PCI DSS
A standard maintained by the PCI Security Standards Council
PCI DSS sets explicit frequencies: quarterly internal and external vulnerability scans, annual internal and external penetration tests, segmentation testing, and testing after significant changes (Requirement 11), plus remediation and retest.
HIPAA
A law enforced by the HHS Office for Civil Rights
The Security Rule in force does not use the words “penetration testing” or “vulnerability scanning” and sets no frequency; it requires risk analysis, risk management and periodic evaluation.
GDPR
A law enforced by national supervisory authorities (DPAs)
Article 32 requires security “appropriate to the risk” and, in 32(1)(d), a process for regularly testing, assessing and evaluating the effectiveness of security measures.
NIS2 and DORA
A law supervised by national competent authorities (NIS2) and financial supervisors (DORA)
NIS2 Art. 21(2) requires vulnerability handling and disclosure (e) and policies to assess the effectiveness of security measures (f), without fixed frequencies.
How it works
Three steps from a verified domain to evidence your auditor can check.
Step 1: Verify and scan
Verify your domain, then we scan it every week
Prove you control the domain and authorize scanning. Our scanner then runs under the published safe profile every week — more often than any framework here requires — and on demand after a change.
Step 2: Test
Run a scoped penetration test
Human-led testing of your web applications, APIs, cloud configuration and external network, scoped to your audit with sales: findings with reproducible evidence, remediation guidance, and a retest after the fixes.
Step 3: Export
Export the evidence, or push it
Download the evidence pack for the period your auditor asks about, or connect Drata or Vanta once: new findings, verified fixes and the monthly statement go there as evidence mapped to SOC 2, ISO 27001, PCI DSS, HIPAA, GDPR, NIS2 and DORA controls.
The evidence
The five documents your auditor receives, and what each one carries.
Scan report
One for every completed scan, weekly and on demand: what was tested under the published safe profile, and every finding with its host, severity and status.
Monthly statement
One for every month of weekly scanning: the scans completed, the findings first seen, the fixes verified, and the open scan findings as of the last scan in the period — issued even for a month with nothing found, so the run of documents has no gap.
Evidence pack
A ZIP for the period you choose: the scan reports and monthly statements, findings.csv and fixes.csv with their control tags, controls.json with the mapping from each kind of evidence to the controls it is relevant to, and a README.
Attestation letter
One page for a period: the domain tested, the scans completed and the safe profile they ran under, the fixes verified, the penetration tests in the period, and the sentence that says who issues the report itself.
Penetration-test report
The report of a scoped engagement: scope and method, an executive summary, findings with reproducible evidence and remediation guidance, then the retest report after the fixes and a redacted version for third parties.
The SHA-256 fingerprint of every report, statement and letter is recorded when it is issued, and the evidence pack's README lists the fingerprint of each one inside it. Anyone holding one of those documents can compute its fingerprint and open vulnverify.com/verify/ followed by it: the page confirms the issuer, the domain, the issue date and the kind of document — never a finding.
Which SOC report do I need?
Three reports and two types. VulnVerify's evidence is written for SOC 2.
| Report | What it covers | VulnVerify |
|---|---|---|
| SOC 1 | Controls relevant to your customers' internal control over financial reporting (ICFR). | Not what our evidence targets; technical testing appears in a SOC 1 only as an IT general control. |
| SOC 2 | Controls against the Trust Services Criteria: Security, and optionally Availability, Processing Integrity, Confidentiality and Privacy. | The report our scan reports, statements, evidence pack and penetration-test reports are written for. |
| SOC 3 | A public summary of a SOC 2 examination, without the detail. | Draws on the same SOC 2 evidence. |
| Type | What it covers | VulnVerify |
|---|---|---|
| Type 1 | The design of the controls at a point in time. | The scan reports and statements up to that date, and a penetration-test report if one was done. |
| Type 2 | The operating effectiveness of the controls over a review period, commonly 3 to 12 months. | Weekly scan reports and monthly statements across the period, fix verification, and the attestation letter for the period. |
What we are and what we are not
VulnVerify provides the security testing and evidence your auditor asks for; the SOC 2 report, ISO 27001 certificate or PCI DSS assessment itself is issued by your CPA firm, certification body or assessor.
We run the authorized external scans and the penetration tests, verify fixes, and issue the scan reports, monthly statements, evidence pack and attestation letter your auditor reviews, each report, statement and letter with a SHA-256 fingerprint you can verify.
- We are not a CPA firm. A SOC 2 report is an attestation report issued by a licensed CPA firm, not a certificate.
- We are not a certification body. An ISO 27001 certificate is issued by an accredited certification body; ISO itself certifies nothing.
- We are not a QSA or an ASV. PCI DSS compliance is validated through a QSA Report on Compliance or a Self-Assessment Questionnaire, and the quarterly external scan the standard requires must come from an Approved Scanning Vendor, so we coordinate with an ASV partner for it.
- HIPAA, GDPR, NIS2 and DORA are laws and regulations. There is no official certificate for any of them; what exists is the evidence that you tested and acted.
What the evidence also maps to
Two more frameworks our weekly scans and penetration tests are commonly measured against. Neither has a page of its own here.
CIS Critical Security Controls v8.1 and NIST SP 800-53 Rev. 5 (and FedRAMP)
CIS Critical Security Controls v8.1
Center for Internet Security — best-practice framework, no certificate.
Explicit cadences: internal scans at least quarterly (7.5), external scans at least monthly (7.6), external pentest at least annually (18.2), internal pentest at least annually (18.5), application pentest (16.13).
NIST SP 800-53 Rev. 5 (and FedRAMP)
US federal control catalog; FedRAMP authorizations for cloud providers. No commercial certificate.
RA-5 (vulnerability monitoring and scanning) and CA-8 (penetration testing) use organization-defined frequencies; FedRAMP sets monthly vulnerability scanning and annual penetration testing for authorized cloud services.
Common questions
What each framework requires, in its own terms, and what VulnVerify can and cannot issue.
Does SOC 2 require a penetration test?
No criterion mandates it. The CC4.1 point of focus names penetration testing as one of the evaluation types, and CC7.1 names vulnerability scans run periodically and after significant changes. Most auditors expect at least an annual test plus testing after major changes.
Does ISO 27001 require a penetration test?
No clause names it and no frequency is set. Control A.8.8 requires you to obtain information about technical vulnerabilities, evaluate exposure and act; A.8.29 requires security testing in development and acceptance. Independent testing is how most certified organizations evidence both.
How often does PCI DSS require scans and penetration tests?
Internal and external vulnerability scans at least every three months (external ones by an ASV), internal and external penetration tests at least every 12 months and after significant changes, segmentation testing at least every 12 months (every six months for service providers).
Does HIPAA require penetration testing?
The rule in force does not name it or set a frequency; it requires risk analysis, risk management and periodic evaluation. A proposed rule (January 2025) would require scanning every six months and a penetration test every 12 months; it is not final as of October 2026.
Does GDPR require penetration testing?
Not by name. Article 32(1)(d) requires a process for regularly testing, assessing and evaluating the effectiveness of security measures; penetration tests and scans are the usual way to run and evidence that process.
What do NIS2 and DORA require?
NIS2 Article 21(2) requires vulnerability handling and disclosure and policies to assess the effectiveness of security measures, without fixed frequencies. DORA requires a testing programme with tests by independent parties and at least yearly testing of systems supporting critical or important functions; threat-led penetration testing every three years applies only to designated entities and is not something VulnVerify offers.
Can VulnVerify issue my SOC 2 report or ISO certificate?
No. Those come from a licensed CPA firm and an accredited certification body respectively. VulnVerify supplies the technical testing and evidence they review.
Is VulnVerify's scan a PCI ASV scan?
No. The quarterly ASV scan must come from an ASV, and we coordinate with an ASV partner for it; VulnVerify's weekly scans cover the time between ASV scans, provide after-change external scan evidence, and support the other Requirement 11 evidence.
Start with the domain you already own
Verify your domain and your first report is free; weekly scanning continues on Weekly Scan. When your audit needs a penetration test, sales scopes it with you.