VAPT
A vulnerability assessment tells you what is exposed across the whole estate. The penetration testing half proves which of those findings an attacker could actually use. You get one report that separates the two.
ROOT64 / VERIFIED
What VAPT actually means here
A vulnerability assessment is breadth. Authenticated and unauthenticated scanning across your applications, hosts, network ranges and cloud services, to build a complete picture of what is reachable and what is out of date.
A penetration test is depth. A tester takes the findings that matter and attempts to exploit them under controlled conditions, so you know which are genuinely reachable and which are noise.
Scanners are good at breadth and bad at judgement. Every finding we publish has been manually reviewed. Anything we could not reproduce is marked as unconfirmed rather than padded into the count.
Scope
Typically in scope
- External network ranges and internet-facing hosts
- Web applications and admin panels, authenticated and unauthenticated
- REST, GraphQL and internal APIs
- Internal network segments, Active Directory and file shares
- Cloud account configuration — IAM, storage, network, logging
- Operating system, service and dependency patch levels
- TLS, DNS, email authentication (SPF, DKIM, DMARC)
Not included unless separately agreed
- Denial-of-service and volumetric load testing
- Social engineering of staff — that sits in red teaming
- Physical site access
- Any system you do not own or cannot produce written authorisation for
- Destructive exploitation on production data
How the engagement runs
Every step is authorised, evidenced and designed to leave your team with a clear next action.
-
Scope and authorise
We agree targets, IP ranges, credentials, test windows, escalation contacts and stop conditions in writing before anything is touched.
-
Discover
Asset discovery, service enumeration and configuration review to confirm the scope is actually the scope. Surprises found here get flagged immediately.
-
Assess
Authenticated and unauthenticated scanning across the agreed estate, tuned to reduce noise rather than inflate the finding count.
-
Validate and exploit
Manual verification of every candidate finding. Controlled exploitation where the rules of engagement permit, to establish real impact.
-
Report
A written report with an executive summary, a technical finding register, CVSS scoring, business context and specific remediation steps.
-
Retest
Once you have fixed the findings, we retest and reissue the report with closure status against each item.
What you receive
Included in every engagement
- Executive summary written for a non-technical reader
- Finding register: severity, CVSS vector, affected asset, evidence, reproduction steps, fix
- Remediation plan ordered by risk and effort, not just by severity
- Raw tool output and evidence pack, access-controlled
- Retest report with per-finding closure status
- A closing call to walk your engineers through the findings
Standards and methodology
Testing follows published methodology rather than an in-house checklist, so coverage is reviewable and comparable between engagements.
- OWASP Web Security Testing Guide
- OWASP ASVS
- PTES
- CVSS v3.1 / v4.0
- NIST SP 800-115
Common questions
Is a scan report the same as a VAPT report?
No. A scan report lists what a tool believes it saw. A VAPT report lists what a tester confirmed, with evidence and impact attached.
How long does it take?
Scope drives it. A single web application is usually a working week including reporting. A multi-application estate with internal network coverage runs longer. You get an indicative timeline in the proposal before you commit.
Will testing take our systems down?
The rules of engagement set explicit stop conditions and exclude destructive testing by default. Where a check carries risk, we agree it in advance and run it in a window you choose.