Human-led penetration testing, scoped to your audit

A scoped engagement against the web applications, APIs, cloud configuration and external network you name: tested by hand, reported with reproducible evidence, and tested again once your fixes are in. The report, the retest report and the attestation letter carry a SHA-256 fingerprint your auditor can check, like every scan report.

What we test

The scope is yours to set on the scoping call. These are the kinds of target an engagement covers.

  • Web applications

    Authenticated and unauthenticated testing of each application in scope: sign-in and session handling, access control between users and roles, input handling and injection, and the business logic a scanner cannot reason about. A finding is reproduced by a tester before it is reported.

  • APIs

    REST and GraphQL APIs, with and without credentials: authorization on every object and function, input handling, rate limiting, and what each response discloses.

  • Cloud configuration

    AWS, GCP and Azure: identity and access, storage exposure, network paths between services, secrets and logging, reviewed as the account is configured rather than as it is documented.

  • External network

    The hosts and services reachable from the internet under the domains in scope: exposed services, versions and configuration, tested by hand beyond what the weekly scan's safe profile runs.

How we test

Manual, tool-assisted

Our testers work by hand against the scope, with tools to cover ground and their own judgment to go further; nothing is reported from a tool's output alone. The work follows the methods your assessor will recognize:

  • OWASP Web Security Testing Guide (WSTG) and Application Security Verification Standard (ASVS)
  • Penetration Testing Execution Standard (PTES)
  • NIST SP 800-115, Technical Guide to Information Security Testing and Assessment

When PCI DSS is in scope

PCI DSS v4.0.1 11.4.1Penetration testing methodology

The statement of work and the report cover each element the requirement names, so your assessor can match them to the document rather than ask. What the requirement asks, in summary:

A penetration-testing methodology is defined, documented and implemented, including industry-accepted approaches, coverage of the entire CDE perimeter and critical systems, testing from inside and outside the network, validation of segmentation and scope-reduction controls, application-layer testing covering at least the vulnerabilities in Requirement 6.2.4, network-layer testing of all components supporting network functions and operating systems, review of threats and vulnerabilities experienced in the last 12 months, a documented approach to the risk of exploitable findings, and retention of results and remediation activities for at least 12 months.

What you receive

  • Report with reproducible evidence

    Each finding with its host, the steps that reproduce it, the evidence, the severity and CVSS, and the CVE and CWE where one applies.

  • Executive summary

    What was tested, what was found and what it means, on the first pages, for the people who own the risk rather than the fix.

  • Remediation guidance

    A fix for each finding and the order to take them in, written for the team that will do the work.

  • Retest report

    After your fixes, the findings tested again and each recorded as fixed or still reproducible, with the date of the retest.

  • Attestation letter

    One page for your auditor: what was tested, when, by which method, and the state of the findings at the retest.

  • Redacted version for third parties

    The report without hosts, paths and evidence excerpts, for a customer or a vendor review that needs the outcome and not the detail.

Every document carries a SHA-256 fingerprint, like every scan report. Whoever holds the fingerprint opens /verify/<fingerprint> and sees the issuer, the domain, the issue date and the kind of document — never a finding.

How an engagement runs

  1. Step 1: Scoping call

    What to test, and which audit it is for

    What is in scope and what is not, the frameworks driving the test, the environments, the test windows and the access our testers need. The call sets the scope; nothing is tested before it.

  2. Step 2: Statement of work

    The scope, the dates and the rules of engagement, in writing

    Targets and exclusions, test windows, contacts for the engagement, and the authorization our testers work under. Testing starts once both sides have signed it.

  3. Step 3: Testing

    Manual, tool-assisted, inside the agreed window

    Our testers work the scope by hand, with tools to cover ground. Anything that could disrupt the service is agreed with you first, and you hear about a critical finding when it is confirmed, not at the end.

  4. Step 4: The report appears in your dashboard

    Issued with a fingerprint, filed with your evidence

    The report, the executive summary and the remediation guidance are issued with a SHA-256 fingerprint and appear on the domain's page in your dashboard and in its evidence pack, beside the scan reports and monthly statements.

  5. Step 5: Retest

    Fixed findings tested again

    Once your fixes are in, the findings are tested again and the retest report records which ones no longer reproduce. It appears beside the report, with the attestation letter for the engagement.

Where the report counts as evidence

A penetration-test report is evidence under SOC 2, ISO 27001, PCI DSS, HIPAA, GDPR, NIS2 and DORA controls. The same mapping tags it in your dashboard and in the evidence pack, so the report lands where your auditor looks for it.

  • SOC 2 CC4.1
  • ISO/IEC 27001:2022 A.8.29
  • ISO/IEC 27001:2022 A.5.35
  • PCI DSS v4.0.1 11.4.1
  • PCI DSS v4.0.1 11.4.2
  • PCI DSS v4.0.1 11.4.3
  • PCI DSS v4.0.1 11.4.4
  • HIPAA §164.308(a)(8)
  • GDPR Art. 32(1)(d)
  • NIS2 Art. 21(2)(f)
  • DORA Art. 24(4)
  • DORA Art. 24(6)
  • DORA Art. 25(1)

What each framework asks of a penetration test, and how often, is on its page under Compliance.

Scope your penetration test

Tell us what to test and which audit it is for. The scoping call sets the rest, and the statement of work follows it.

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.