VAPT explained: scope, testing types and what a good report contains

By Akash Sengar · 6 October 2026 · 5 min read

What VAPT covers

VAPT combines two activities. A vulnerability assessment identifies and prioritises known weaknesses, usually with scanning tools and manual validation. A penetration test goes further: a tester tries to exploit weaknesses, chain them and show the real impact, within agreed rules. NIST's SP 800-115, Technical Guide to Information Security Testing and Assessment, describes these techniques and how to plan and run them.

Common targets are external networks (internet-facing IP addresses and services), internal networks, web applications and APIs, mobile apps, cloud configurations, and Microsoft 365 or Google Workspace tenants. For web applications, the OWASP Web Security Testing Guide is a widely used reference for what to test.

Black, grey and white box

• Black box: the tester starts with no inside knowledge, like an outside attacker. Realistic, but time is spent on discovery rather than depth.
• Grey box: the tester has some information, such as user accounts for each role or architecture notes. This is the usual choice for applications, because it tests what a logged-in user could do.
• White box: the tester has full information, which can include source code and configuration. Most thorough per hour of testing.

Choose by the question you want answered. "What can someone on the internet do to us?" suggests black box externally. "Can one customer see another customer's data?" needs grey box with accounts for both.

Scope and rules of engagement

Write these down and sign them before testing starts:

• In scope: exact domains, IP ranges, applications, environments (production or staging) and user roles
• Out of scope: anything the tester must not touch, including third-party services you do not own
• Testing windows, and any times when testing must stop
• Permitted techniques, and those excluded (for example, denial-of-service or social engineering)
• Contacts on both sides, with an escalation path if something breaks or a critical issue is found
• How test data and findings will be stored, shared and deleted

Cloud providers publish their own policies on penetration testing of resources hosted with them. Check the policy for each platform in scope.

The authorisation letter

Testing systems without permission can be an offence. Before any work, the system owner signs a written authorisation naming the tester, the targets, the dates and the scope. If an application is hosted or run by a supplier, get their written agreement too. Testers should carry the letter and stop if anyone questions it until it is confirmed.

Severity and CVSS

Findings need a consistent severity. The Common Vulnerability Scoring System (CVSS), maintained by FIRST, is the most common method. It scores a vulnerability from 0.0 to 10.0 and maps the score to a rating: None (0.0), Low (0.1 to 3.9), Medium (4.0 to 6.9), High (7.0 to 8.9) and Critical (9.0 to 10.0). CVSS v4.0 is the current version; many reports still use v3.1. A good report says which.

A base score describes the vulnerability itself, not your business. Good testers add context: a medium-rated issue on a system that holds payment data may deserve faster action than a high-rated one on an isolated test server. Ask for both the CVSS vector and a plain-English business impact.

What a good report contains

1. Executive summary. One page for leadership: what was tested, the overall picture, the most important risks and what to do first. No jargon.
2. Scope and method. Targets, dates, testing approach, accounts used, tools and standards followed, and anything that limited the test.
3. Findings list. Every finding with a unique ID, title, severity, CVSS vector and score, and affected assets.
4. Evidence. Steps to reproduce, requests and responses, and screenshots, enough for your team to confirm the issue.
5. Impact. What an attacker could actually do, in business terms.
6. Remediation. Specific fixes, not just "apply patches". Where there are options, the trade-offs.
7. Positive observations. Controls that worked, so they are kept.
8. Retest status. After remediation, each finding marked fixed, partly fixed or open, with the retest date.

Watch for reports that are mostly raw scanner output. They have long lists of findings, little evidence of manual work, and remediation copied from tool descriptions.

Remediation and retest

Agree target fix times by severity before the report arrives, so there is no debate later. Assign each finding an owner. Fix the cause rather than the single instance: if one endpoint lacks an authorisation check, check every similar endpoint.

A retest confirms fixes work and have not introduced new problems. Keep the original report, the remediation evidence and the retest result together. Auditors and clients often ask for all three.

How often to test

There is no single right frequency. Test at least once a year, and after significant changes: a new application or major release, a new internet-facing service, a cloud migration, or an acquisition. Some frameworks set explicit requirements. For example, PCI DSS v4.0.1 requires internal and external penetration testing at least once every 12 months and after any significant infrastructure or application change, and internal and external vulnerability scans at least once every three months.

Contracts and sector rules may add their own conditions, such as testing by a CERT-In-empanelled organisation for some government and regulated work. Check what your clients and regulators ask for before you commission the test.

How to prepare for a test

• Confirm in writing who owns each system in scope, including cloud and hosting providers whose terms may require notice
• Provide test accounts for each user role in a web application, so access control can be tested properly
• Tell your monitoring team or managed service provider, so alerts are expected rather than escalated as an attack
• Take backups of systems in scope and agree a contact who can be reached at any time during testing
• Freeze major changes during the test window where possible, so results reflect a stable state
• Decide whether testing runs against production or a staging copy; staging must match production closely to be useful

Questions to ask a testing provider

1. Who will do the testing, and what qualifications and experience do they have?
2. How much is manual testing, and how much is automated scanning?
3. Can we see a sample report, with client details removed?
4. How do you handle a critical finding found mid-test? Do you tell us straight away?
5. Is a retest included, and within what period?
6. How do you protect the data you see during testing, and how long do you keep it?
7. Do you hold any empanelment or accreditation our clients or regulators require?

A low price based on an automated scan alone produces a long list of unverified issues. Ask what you are paying for: the depth of manual testing and the quality of the report matter more than the page count.