VAPT methodology: five phases from scope to report
BERRY9 runs every VAPT through the same five phases: scope, reconnaissance, vulnerability identification, exploitation and risk analysis, and reporting and remediation. This guide explains what happens in each phase, what you provide, what you receive, and how findings are scored, proven and tracked until they are fixed.
- Phases
- Five, in every test
- Typical scope
- 5 to 10 working days
- Severity
- CVSS 3.1
- Reports
- Executive and engineering
Last reviewed
Phase 1, scope: assets, rules of engagement and stop conditions, agreed in writing.
Phase 2, reconnaissance: a map of what is really exposed.
Phase 3, vulnerability identification: scanners and manual work, every result checked.
Phase 4, exploitation and risk analysis: a proof of concept for each finding.
Phase 5, reporting and remediation: two reports and a remediation matrix.
01 / Overview
The five phases of a VAPT
Each phase hands something to the next: the scope tells reconnaissance where to look, reconnaissance tells testing what exists, testing hands confirmed weaknesses to exploitation, and exploitation gives the reports their evidence.
Phase 1 · days 1–2
Scope
Your team and ours settle the assets, the threat model, the rules of engagement, who to call in an emergency and the limits of the test.
OutputStatement of work, rules of engagement, asset inventory, emergency runbook
Phase 2 · days 2–3
Reconnaissance
Passive research that never touches your systems, followed by active mapping of hosts, services, endpoints and technologies.
OutputAttack-surface map, exposure brief, technology profile
Phase 3 · days 3–5
Vulnerability identification
Automated scanning at scale and manual testing by an engineer, with false positives removed before anything is called a finding.
OutputTriaged findings list, coverage report, risk pre-rating
Phase 4 · days 5–7
Exploitation and risk analysis
A safe proof of concept for every finding worth keeping, and attack chains followed from the first weakness to the last.
OutputValidated proofs of concept, attack-path graph, impact analysis
Phase 5 · days 7–10
Reporting and remediation
Two reports, one for executives and one for engineers, plus a remediation matrix that follows each finding until it is closed.
OutputExecutive report, engineering report, remediation matrix, retest result
The day labels follow a ten-day engagement. For a typical scope, the five phases fill 5 to 10 working days from kickoff until the reports; a small scope moves through the same five phases in less time, and a large estate takes longer, with the schedule set in the proposal. The phases stay fixed from one test to the next, while the depth and the tooling in each phase follow the system being tested. Each phase's outputs, such as the attack-surface map and the coverage report, are separate documents delivered alongside the final reports.
02 / Phase 1
Phase 1: scope and rules of engagement
Scoping settles what will be tested, from where, how hard and within which limits, before any traffic reaches your systems. It starts with a working session rather than a questionnaire: our lead engineer goes through the assets with your team, agrees the rules of engagement, names the people to call in an emergency and sets limits on what the test may reach.
Before the first request is sent, the threat model is put in writing: what an attacker would most want from your systems, where the testers are allowed to show impact, and which systems or actions are off limits. Everything that happens in the later phases is measured against this agreement, so a vague scope here shows up later as a vague report.
Across the industry, written permission from a person with the authority to grant it is the line between a penetration test and an attack. Testers work inside that authorization and halt when a stop condition is met; the emergency contact named in the rules is the person who hears about it first.
What the rules of engagement record
- Targets. The URLs, IP ranges, hosts, applications and accounts the test covers, plus anything excluded by name.
- Environment. Production, staging or both, and which records a test may read or change in each.
- Time windows. When testing may run, and any dates, such as a release, when it must pause.
- Testing intensity. How hard automated checks may push against each target.
- Contacts. A technical contact for questions, and an emergency contact who can be reached while testing runs.
- Stop conditions. The events that halt testing at once, for example a service slowing down or data turning up that nobody expected to be reachable.
On network tests, the IP ranges, hosts, time windows, testing intensity and stop conditions are documented and signed by both sides before testing begins. The same applies to every engagement: the rules of engagement are signed by both sides before testing starts.
What you provide
- The list of assets and environments you want tested.
- The written requirement from your auditor or customer, if one is driving the test.
- Technical and emergency contacts, and any dates when testing must pause.
- Permission from any third party that hosts a target, where its terms ask for it.
What you receive
- Statement of work: the written proposal for the engagement.
- Rules of engagement: targets, windows, intensity and stop conditions.
- Asset inventory: every target in scope, listed.
- Emergency runbook: who is called, and what happens, if a stop condition is reached.
03 / Phase 2
Phase 2: reconnaissance
Reconnaissance builds a picture of what is really exposed before anything is tested. It starts with sources that never touch your systems, then moves on to active mapping of the hosts, services and technologies in scope.
Show details for Phase 2: reconnaissance
The passive part relies on public sources: open-source intelligence, the certificate transparency logs, credentials that have leaked, and configuration files left exposed on the internet. Certificate transparency logs are public records of the TLS certificates that certificate authorities issue, which is why they so often list subdomains an organization has forgotten about.
The active part discovers ports and services, fingerprints whatever answers, and profiles the technology behind it. For an application, it means listing all of its endpoints, documented or not; an API's endpoint map comes from its OpenAPI or GraphQL schema, or is enumerated where no schema exists. The model of your attack surface that comes out of this phase often shows shadow assets your team did not know were exposed.
A common rule in the field is that anything found outside the agreed list stays untested until its owner confirms it in writing. The discovery itself still belongs in the findings, because an asset nobody is maintaining is a risk on its own.
What you provide
- Whatever documentation exists: a network diagram, an API schema, the application URLs.
- A quick answer when reconnaissance turns up an asset that was not on the list.
What you receive
- Attack-surface map: the hosts, services and endpoints that are really reachable.
- Exposure brief: what is visible from outside that perhaps should not be.
- Technology profile: the platforms, frameworks and versions in use.
04 / Phase 3
Phase 3: vulnerability identification
This is the vulnerability assessment half of VAPT: finding the weaknesses in everything reconnaissance mapped. Scanners and manual testing run side by side, and an engineer checks every automated result against your environment before it can count as a finding.
Show details for Phase 3: vulnerability identification
Automated scanning is quick at the known patterns: outdated software, missing patches, weak configuration. It cannot tell whether a customer of one organization can open another organization's records, or whether a discount can be applied twice; those flaws are found by an engineer walking through the system. For an application, that walk covers each input, each role and each boundary between what users may and may not do, both signed in and signed out.
The work concentrates on the kinds of weakness that combine into real attacks, rather than on long lists of low-value scanner output. Scanner results that an engineer cannot confirm against your environment are removed here, before they can reach a report as findings.
What you provide
- Test accounts for each role in scope; for a multi-tenant system, accounts in two tenants.
- A way in for internal tests, through VPN access or a jump host, or with a laptop placed on site, at the access level of an ordinary employee.
- The signed app build for a mobile test, or repository access for a code review.
- Someone who can answer questions about expected behavior.
What you receive
- Triaged findings list: confirmed weaknesses only.
- Coverage report: the categories covered, with results for each.
- Risk pre-rating: a first severity for each finding, settled in phase 4.
05 / Phase 4
Phase 4: exploitation and risk analysis
Exploitation turns a suspected weakness into a demonstrated one. Every finding worth keeping gets a safe proof of concept, and where several weaknesses combine, the chain is built and documented as one attack path.
Show details for Phase 4: exploitation and risk analysis
Severity means little until impact has been shown, so a finding is not rated on a guess. Each one is demonstrated with a proof of concept, inside the limits set in phase 1, which were agreed in writing before testing began and say which systems may be used to show impact and which are off limits.
Some weaknesses look minor alone and serious together. Where they combine, the chain is built end to end and recorded as one attack path, and it is rated by what the whole chain achieves. A critical finding is raised with your named contact as soon as it is confirmed, ahead of the report.
What a proof of concept shows for each finding
- The starting point: the role or account the tester used, or none at all for a signed-out test.
- Numbered steps that let your developer reproduce the issue without asking the tester.
- The evidence: the exact request, with the payload where one was used, and the response showing what it achieved.
- The outcome: what an attacker would gain, in terms of your data and your users.
What you provide
- The contacts named in the rules of engagement, reachable while testing runs.
- A decision, when asked, on whether a found path may be followed further inside the scope.
What you receive
- Validated proofs of concept: one for each finding that stays in the report.
- Attack-path graph: how chained findings lead from a foothold to an outcome.
- Impact analysis: what each finding means for the business.
06 / Phase 5
Phase 5: reporting and remediation
Reporting turns the test into documents that two audiences can act on, and remediation is where your team closes what was found. Every finding is written up with its fix, scored with CVSS 3.1 and entered in the remediation matrix, which tracks it to closure.
Show details for Phase 5: reporting and remediation
The executive report explains the business risk without jargon, for founders, managers and the auditors who will read it. The engineering report gives each finding its reproduction steps, payloads, code-level fix and references, so a developer can confirm the problem and correct it from the page alone.
The remediation matrix lists every finding with its severity, the change that fixes it, the person who owns that change, its status and, after a retest, the retest result. Your team works through the matrix in order of severity, and it is the document that shows, at any point, what is still open.
A retest checks that each fix holds, and its result goes into the matrix. The starter scope comes with one free retest; on larger scopes, the proposal sets out how retesting is handled. The VAPT cost guide covers what each scope includes. How long test evidence and client data are kept, and how they are deleted, is agreed in writing in the proposal.
What you provide
- The names of the people who should receive each report.
- The fixes, made by your team.
- A note when the fixes are ready to be retested.
What you receive
- Executive report: business risk, for management.
- Engineering report: one write-up per finding, for developers.
- Remediation matrix: every finding with its fix, owner and status.
- Retest result: recorded against each finding in the matrix.
The sample VAPT report shows all three documents with invented example findings.
07 / At a glance
What you provide and what you receive
The same exchange, phase by phase, on one table: what your team hands over, and what comes back.
Show details for What you provide and what you receive
| Phase | What you provide | What you receive |
|---|---|---|
| 1. Scope | Assets, environments, contacts, blackout dates, any written audit requirement | Statement of work, rules of engagement, asset inventory, emergency runbook |
| 2. Reconnaissance | Diagrams, schemas and URLs you have; answers on newly found assets | Attack-surface map, exposure brief, technology profile |
| 3. Vulnerability identification | Test accounts per role, VPN or jump host access, app builds or repository access | Triaged findings list, coverage report, risk pre-rating |
| 4. Exploitation and risk analysis | Reachable contacts and quick decisions inside the scope | Validated proofs of concept, attack-path graph, impact analysis |
| 5. Reporting and remediation | Report recipients, the fixes, a note when they are ready | Executive report, engineering report, remediation matrix, retest result |
08 / Severity
How findings are scored with CVSS 3.1
Every finding gets a CVSS 3.1 score, using the Common Vulnerability Scoring System that FIRST maintains, and is then weighed against your environment. The score says how serious the flaw is in itself; the context says how much it matters in your systems.
Show details for How findings are scored with CVSS 3.1
CVSS 3.1 builds a base score from eight metrics. Four describe how the flaw is exploited: the attack vector (network, adjacent, local or physical), the attack complexity, the privileges the attacker needs and whether a user has to take part. A fifth, scope, records whether the damage can reach beyond the component that has the flaw. The last three rate the impact on confidentiality, integrity and availability as none, low or high. The result is a number from 0.0 to 10.0, written down with a vector string of short codes, so anyone can see how the number was reached; the sample report decodes one, code by code.
FIRST's own guidance for CVSS 3.1 says that CVSS measures severity, not risk. That is why BERRY9 scores every finding against CVSS 3.1 and your environment: the base score describes the flaw, and the write-up says what it means in your architecture, next to the data it exposes. The same weakness on a page that holds nothing private and on an endpoint that returns customer records should not lead to the same urgency, and the report says which is which.
| Rating | Base score | In the sample report |
|---|---|---|
| Critical | 9.0 to 10.0 | No example |
| High | 7.0 to 8.9 | F-01, an authorization flaw (8.1) |
| Medium | 4.0 to 6.9 | F-02, an outdated component (6.1) |
| Low | 0.1 to 3.9 | F-03, a missing security header (3.1) |
| None | 0.0 | Not reported as a finding |
09 / By service
How the method adapts to each service
The five phases are the same for a web app and for a Windows domain. What changes is where the effort goes once testing starts, and what your team needs to hand over first.
Show details for How the method adapts to each service
| Service | Where the depth goes | What you provide first |
|---|---|---|
| Web application | Inputs, roles and access boundaries, signed in and signed out; chained findings walked end to end | Application URLs, test credentials, a scope memo |
| Mobile application | Static analysis of the build, the app observed while it runs on a device, then the backend API it calls | Signed APK or IPA, a backend test environment, test users |
| API | Schema walk, authentication review, an authorization sweep per object type, then business-logic abuse | An OpenAPI or GraphQL schema if one exists, test users for each role |
| Network | External enumeration; from an assumed-breach foothold, lateral movement and privilege escalation | IP ranges, a network diagram, the rules of engagement |
| Active Directory | Permission abuse, Kerberoasting, certificate services mistakes and delegation, tried as routes to the domain | An ordinary domain account and a way onto the network |
| Source code review | Threat model, a static-analysis baseline, manual review category by category, a pattern list for pull requests | Repository access, build instructions, an architecture brief |
The seven advanced scopes use the same five phases. What phases 3 and 4 cover for each, and what you provide first, is worked out during scoping and written into the proposal:
- Thick-client penetration testing
- Cloud security assessment
- Wireless penetration testing
- IoT and firmware testing
- Red team assessment
- Social engineering assessment
- DevSecOps services
Every test, grouped by what it covers, is on the offensive security services page. For the difference between the two halves of the name, read VAPT vs penetration testing.
10 / Standards
Standards the method is aligned with
The method lines up with four public references that auditors, customers and security teams already know, so a report can be read against them.
Show details for Standards the method is aligned with
OWASP
The Open Worldwide Application Security Project publishes free, community-written references. Its Top 10 lists the most serious categories of web application risk, ASVS is a catalog of verification requirements, OWASP MASVS does the same for mobile apps, and the API Security Top 10 covers APIs.
NIST SP 800-115
The US National Institute of Standards and Technology's Technical Guide to Information Security Testing and Assessment. It sets out how to plan a test, run it, analyze what was found and report it, including the rules of engagement.
PTES
The Penetration Testing Execution Standard, a community framework that walks an engagement from pre-engagement interactions and intelligence gathering through threat modeling, vulnerability analysis and exploitation to post-exploitation and reporting.
MITRE ATT&CK
A public knowledge base of the tactics and techniques attackers use, built from observed intrusions. Mapping test activity to it lets defenders compare what the testers did with what their monitoring detected.
11 / FAQ
Frequently asked questions
Short answers about scope, price and how testing works. For anything else, call +91 86868 92922.
What are the five phases of VAPT?
At BERRY9 they are scope, reconnaissance, vulnerability identification, exploitation and risk analysis, and reporting and remediation. Scoping agrees the targets and the rules of engagement; reconnaissance maps what is exposed; identification finds weaknesses with scanners and manual work; exploitation proves each one with a proof of concept; and reporting delivers the executive and engineering reports along with a remediation matrix. See the section on The five phases of a VAPT above.
What are rules of engagement in a penetration test?
Rules of engagement are the written agreement that controls a test: the targets in and out of scope, the environment, the time windows, how hard automated checks may push, who to call, and the stop conditions that halt testing at once. At BERRY9 they are agreed in phase 1, before any testing starts. See the section on Phase 1: scope and rules of engagement above.
How long does a VAPT take?
For a typical scope, plan for 5 to 10 working days, starting at kickoff and ending when both reports are delivered. A small scope passes through the same five phases faster, and a large estate, such as several applications or a network spread over several sites, takes longer; the proposal gives the schedule.
What does BERRY9 need from us before a test?
The list of assets and environments, technical and emergency contacts, any dates when testing must pause, and the written requirement from your auditor or customer if one drives the test. Before phase 3 we also need test accounts for each role and, for internal tests, remote access through VPN or a jump host, or else an on-site laptop, with an ordinary employee's access. See the section on What you provide and what you receive above.
How are vulnerabilities rated in a VAPT report?
BERRY9 scores every finding with CVSS 3.1, which turns eight metrics about how a flaw is exploited and what it affects into a base score from 0.0 to 10.0 and a rating of low, medium, high or critical. The report then explains what the finding means in your environment, because the same flaw matters more where it exposes sensitive data. See the section on How findings are scored with CVSS 3.1 above.
What is a proof of concept in a VAPT report?
A proof of concept is the evidence that a finding is real: the account or role used, numbered steps to reproduce it, the exact request and the response it produced, and what an attacker would gain. Each finding in a BERRY9 engineering report carries one. See the section on Phase 4: exploitation and risk analysis above.
Is a retest included after we fix the findings?
On the starter scope, yes: it includes one free retest. On larger scopes, the proposal sets out how retesting is handled before the work begins. The retest result is then recorded against each finding in the remediation matrix, and the VAPT cost guide explains what each scope includes. See the section on Phase 5: reporting and remediation above.
Will testing disrupt our production systems?
Testing is planned so that it stays safe: each finding's impact is demonstrated with a validated proof of concept, the systems that may be used to show it and those that are off limits are agreed in writing during scoping, and stop conditions halt testing at once if something unexpected happens. Where a staging environment with realistic data exists, it is often the better place to test.
Plan your next security test
Tell us what needs testing and when you need it done, and we will propose a scope and timeline. We respond within 24 hours. If you would rather talk first, call or write to us.
- +91 86868 92922
- contact@berry9.com
- H.No: 8-3-945/A/12 & 13, Sri Venkata Sai Nest Apartments, Nagarjuna Nagar Colony, Yellareddyguda, Hyderabad 500073, Telangana