VAPT stands for Vulnerability Assessment and Penetration Testing. The assessment finds and ranks weaknesses across systems; the penetration test then tries to exploit them to prove real impact. JCSS Indonesia scopes VAPT as evidence for IT general controls and ISMS reviews, not as a standalone scan.
What does VAPT stand for and what does each half do?
A vulnerability assessment lists known weaknesses broadly; a penetration test shows which of them an attacker can actually chain into access. Most organisations need both.
| Vulnerability assessment | Penetration test | |
|---|---|---|
| Question answered | What weaknesses exist? | What can an attacker achieve with them? |
| Method | Mostly automated scanning plus analyst triage | Manual, goal-driven exploitation |
| Coverage | Wide: many hosts and applications | Narrow: chosen targets and scenarios |
| Output | Prioritised list of findings | Demonstrated attack paths and impact |
| Typical use | Routine hygiene and patch assurance | Pre-launch, post-change and assurance evidence |
NIST's guide to technical security testing, SP 800-115 (2008), places vulnerability scanning under target identification and analysis, and penetration testing under target vulnerability validation. It also notes that no single technique gives a complete picture and that techniques can be combined.
What types of VAPT engagements are there?
Engagements are defined by target: network, web application, API, cloud, wireless, mobile and people-focused social engineering.
- Network and infrastructure: internal and external hosts, firewalls, remote access and directory services.
- Web application: authentication, session handling, input validation and business logic, commonly tested against the OWASP Web Security Testing Guide.
- API: authorisation flaws and data exposure, mapped to the OWASP API Security Top 10 (2023); see our API security checklist.
- Cloud: configuration, identity and storage exposure within the provider's shared-responsibility boundary.
- Wireless and mobile: access-point configuration and app-level controls.
- Social engineering: phishing and pretext exercises, run only with explicit authorisation.
Testers also differ in knowledge: black-box (none), grey-box (limited credentials) and white-box (full documentation and source). Grey-box usually gives more depth per day of effort because time goes to depth, not reconnaissance.
How does a VAPT engagement run, step by step?
It follows planning, execution and reporting phases, then a retest to confirm fixes. SP 800-115 describes the same planning, execution and post-execution structure.
- Planning and scoping: agree targets, test windows, exclusions, data-handling rules, emergency contacts and the written authorisation (rules of engagement).
- Discovery and vulnerability assessment: enumerate hosts, services and applications, then scan and triage results to remove false positives.
- Penetration testing: attempt exploitation within the agreed limits, recording each step so findings are reproducible.
- Reporting: deliver an executive summary and technical findings with evidence, risk rating and remediation guidance.
- Remediation and retest: the client fixes issues; the tester verifies and records closure.
The retest is the step most often skipped, and it is what converts a report into assurance evidence.
Which tools do VAPT testers use?
Testers combine scanners, proxies and exploitation frameworks; the tool matters less than the tester's judgement in interpreting its output.
| Purpose | Examples |
|---|---|
| Network discovery and port scanning | Nmap |
| Vulnerability scanning | OpenVAS, Nessus |
| Web application testing | Burp Suite, OWASP ZAP, Nikto |
| Exploitation framework | Metasploit |
| Traffic analysis | Wireshark |
| Wireless testing | Aircrack-ng |
Automated scanners produce false positives and miss logic flaws. A report that is only scanner output is a vulnerability assessment, not a penetration test, and should be priced and described that way.
How should you scope a VAPT and read the report?
Scope by business risk: internet-facing assets, systems holding personal or financial data, and anything recently changed. Read the report for exploitability and fix ownership, not finding counts.
For scoping, ask for the asset inventory first; you cannot test what you have not listed. Decide whether production or a staging copy is tested, and how availability will be protected. For reading, look at:
- findings with demonstrated exploitation, which deserve fastest action;
- root causes repeated across hosts, such as weak patching or shared credentials;
- findings that depend on one another, because chaining often raises overall severity;
- whether every item has an owner and a target date.
Indonesian organisations handling personal data should also consider Law No. 27 of 2022 on Personal Data Protection; exposed personal data found in testing should be handled under your incident and data-protection procedures.
How does VAPT fit into ISMS and IT general controls?
VAPT is evidence that technical controls work, supporting an ISMS, an ITGC review or a risk assessment; it does not replace governance, policy or access review.
Under ISO/IEC 27001, test results feed risk assessment and corrective action. In an ITGC review, they corroborate patch management and access controls. For the wider programme, see our security strategy and governance checklist. JCSS Indonesia's internal audit, ITGC and cybersecurity service integrates technical test results into an assurance opinion for management, subject to partner review.
Frequently asked questions
What is the difference between VA and PT?
A vulnerability assessment identifies and ranks known weaknesses across many systems, usually with automated scanners and analyst triage. A penetration test is manual and goal-driven: it attempts to exploit selected weaknesses to show what an attacker could actually reach. The assessment gives breadth, the test gives proof of impact, and together they give a complete view.
How often should VAPT be performed?
There is no single legal interval. A risk-based approach works: test internet-facing systems regularly, repeat after major changes or releases, and retest after remediation. Regulators or customers may set their own expectations, so check contractual and sector requirements. Document the rationale for your chosen frequency so an auditor can follow it.
Is automated scanning enough?
No. Scanners are good at finding known, patchable issues quickly, but they miss business-logic flaws and chained attacks, and they report false positives. A scan is a useful vulnerability assessment. Calling it a penetration test overstates the assurance, so make sure proposals state how much manual testing is included.
What should a VAPT report contain?
It should have an executive summary, scope and method, findings with evidence and a risk rating, clear remediation guidance, and the tester's limitations. Each finding should be reproducible and assigned an owner. A retest section confirming closure is what turns the report into evidence for auditors and certification bodies.
Is it safe to test production systems?
It can be, if planned. Agree test windows, exclusions, rate limits and emergency contacts in writing before starting, take backups, and monitor availability throughout. Higher-risk tests, such as denial-of-service, are usually excluded or run against staging. Written authorisation from the system owner is essential for any penetration testing.
General information only, not legal or tax advice for your specific facts. Regulations change; confirm the current position with JCSS Indonesia before acting.