Home / Insights / QA and Software Testing
QA and Software Testing
Vulnerability Assessment and Penetration Testing: Scoping, Methods and Getting Value
Vulnerability assessments find known weaknesses at scale; penetration tests show what an attacker could actually achieve. This guide explains both, how they fit with automated testing, how to scope and run them, and how to turn reports into real security improvements.
TopicsQA and Software TestingArchitecture and ModernizationWeb and SaaS Development
Key takeaways
- A vulnerability assessment systematically identifies known weaknesses; a penetration test attempts to exploit them to show real impact.
- Automated SAST and DAST in the pipeline catch many issues continuously; penetration testing adds human creativity, business-logic testing and chained attacks.
- Scope deliberately: targets, environments, test accounts, timing, rules of engagement and what is out of bounds.
- Value comes from remediation: prioritise findings by risk, fix root causes and retest.
- Test at least annually and before major releases, new integrations or compliance audits.
On this page
Many organisations commission a penetration test because a customer, auditor or regulator asks for one. Used well, it is much more than a compliance tick: it shows how an attacker could actually harm the business and where defences fall short.
Vulnerability assessment versus penetration testing
| Aspect | Vulnerability assessment | Penetration testing |
|---|---|---|
| — | — | — |
| Goal | Identify and list known weaknesses | Demonstrate exploitability and impact |
| Approach | Mostly automated scanning with expert review | Manual testing by skilled testers, supported by tools |
| Breadth | Wide coverage | Focused on scope and attack paths |
| Depth | Shallow per finding | Deep, including chained exploits |
| Frequency | Frequent, often continuous | Periodic and event-driven |
VAPT combines both: breadth from assessment, depth from penetration testing.
Where VAPT fits with automated testing
- SAST analyses source code for insecure patterns.
- DAST tests running applications from the outside for common vulnerabilities.
- Dependency and container scanning find known vulnerable components.
- Penetration testing adds business-logic abuse, authorisation flaws, chained attacks and creative techniques automated tools miss.
Our DevSecOps checklist explains how to build the automated layers into the pipeline.
Types of penetration tests
| Type | Focus |
|---|---|
| — | — |
| Web application | Authentication, authorisation, input handling, business logic |
| API | Object-level authorisation, data exposure, rate limits |
| Mobile application | Local data storage, API communication, reverse engineering |
| Network and infrastructure | Exposed services, misconfigurations, lateral movement |
| Cloud configuration | Identity and access, storage exposure, logging |
| Social engineering | Phishing and human factors |
Choose types that match your architecture and threats.
Scoping and rules of engagement
- Targets: applications, APIs, environments and IP ranges in scope.
- Approach: black-box, grey-box (with test accounts and some documentation) or white-box (with code access). Grey-box usually gives the best value for applications.
- Test accounts for each role, including tenants for multi-tenant products.
- Timing and environment: staging with production-like data, or production with safeguards.
- Exclusions: denial-of-service tests, third-party systems, sensitive data handling.
- Contacts and escalation for critical findings during the test.
Methodologies and references
Testers commonly structure web and API testing around the OWASP Top 10 and OWASP testing guides, and follow recognised penetration testing methodologies. Ask providers which methods they follow and how they test business logic specific to your product.
Reporting and remediation
A useful report includes an executive summary, risk-rated findings with evidence, reproduction steps, business impact and recommended fixes. Then:
- Triage findings with product and engineering owners.
- Prioritise by risk: exploitability, impact and exposure.
- Fix root causes, not just the specific instance.
- Add regression tests so issues do not return.
- Retest to confirm fixes.
- Track remediation time and recurring categories.
How often to test
- At least annually for important applications.
- Before major releases or architecture changes.
- After adding significant integrations, authentication changes or new data types.
- When required by customers, regulators or certifications.
Frequently asked questions
Can automated scanners replace penetration testing?
No. They find many known issues efficiently but miss business-logic flaws and chained attacks that skilled testers find.
Should we test in production?
Staging is safer and usually sufficient if it mirrors production. Some tests, such as configuration checks, may need production with safeguards.
How long does a penetration test take?
Typically one to three weeks of testing for a web application and its APIs, depending on scope.
How do we choose a provider?
Look for relevant experience, qualified testers, a clear methodology, sample reports and support for retesting.
Sources and methodology
Facts in this article were checked against the sources below on 6 November 2026. Directory data (ratings, review counts, rate bands and team sizes) changes over time and is shown as published on the date accessed. Illustrative examples are labelled as such and are not quotes.
- OWASP: Top 10:2025 — accessed 6 November 2026. Common risk categories used to structure application security testing
Related reading
Continue your research
Need a penetration test before a launch or audit?
Share your application and requirements. We will help you scope testing, prepare your team and prioritise remediation.