Full-spectrum testing of your web applications against OWASP Top 10, business logic flaws, authentication weaknesses, and custom attack scenarios — delivered manual-first, with automated tooling as a supplement.
Web applications are the most common entry point for attackers. Our WAPT service delivers a thorough, manual-first assessment of your web-facing applications — covering everything from input validation and authentication bypass to complex multi-step business logic flaws that automated scanners structurally cannot detect. We test against the OWASP Top 10, the WSTG (Web Security Testing Guide), and custom threat models developed specifically for your application's architecture and business context.
WHAT'S INCLUDED
Web application penetration testing assesses browser-based applications by attempting to exploit weaknesses the way an attacker would. Scope covers server-side input validation, authentication and session management, authorisation logic, file handling, and the integration points between the application and its APIs or third-party services. Testing addresses the OWASP Top 10 risk categories — injection, broken access control, cryptographic failures, and security misconfiguration among them — and extends to business-logic flaws specific to how your application operates. These logic flaws, such as multi-step workflow abuse or price manipulation, cannot be detected reliably by automated scanners and require a tester who understands the application's intended behaviour.
The engagement uses the OWASP Web Security Testing Guide (WSTG) as its baseline methodology, with the Penetration Testing Execution Standard (PTES) informing scoping and reporting structure, and the NIST Cybersecurity Framework used to map findings to broader risk management. Each finding is classified using CVSS v3.1 for a consistent severity rating. The approach is manual-first: automated scanners handle enumeration and initial coverage, but every reported finding is reproduced and validated by a tester. This reduces false positives and ensures the report reflects exploitable risk rather than scanner noise. Where the application has custom architecture — microservices, single sign-on, or AI integrations — the test plan is adapted to cover the attack surface those introduce.
The engagement begins with a scoping call to agree on the target applications, environments, accounts, rules of engagement, and timelines. A threat model is then developed to identify high-value targets and prioritise testing effort. Active testing is delivered in sprints, with progress updates rather than a single end-of-engagement handover, so your engineering team can begin remediation on confirmed findings while testing continues. Testing is conducted against agreed environments — typically staging or production — with authorisation documented before any work begins. At the end of the active phase, a report is produced with an executive summary for leadership and a technical report for engineering, followed by a complimentary retest once remediation is complete.
Each report includes an executive summary describing the scope, the overall risk posture, and the most significant findings in business terms. The technical section documents every confirmed finding with its CVSS severity, a proof of concept, the underlying cause, and prioritised remediation guidance. Findings are mapped to the relevant OWASP category and, where relevant, to the control objectives of ISO 27001 Annex A or NIS2 Article 21. A retest confirmation and an attestation letter are issued once remediation has been verified. The report is structured so engineering teams can act on it directly without a separate translation exercise.
Yes. After your team remediates the confirmed findings, a retest verifies that each fix resolves the original issue and has not introduced a new one. Verified fixes are documented and an attestation letter confirming the retest is issued. The retest is included in the engagement price rather than billed separately, and the engagement is not considered closed until it is complete.
Penetration testing does not by itself constitute compliance with NIS2 or ISO 27001, but it provides evidence that several specific control objectives are being met. Under NIS2 Article 21, essential and important entities must implement risk-based technical measures including vulnerability handling and testing; a documented penetration test is a direct input to that obligation. Under ISO 27001, Annex A controls A.8.8 (technical vulnerability management) and A.8.29 (security testing in development) expect evidence of active testing of in-scope systems. The report maps findings to these controls so auditors and internal risk functions can trace testing back to the relevant requirement. Testing frequency, scope, and remediation evidence should be aligned with your broader compliance programme rather than treated as a standalone exercise.
FAQ
Engagement length depends on the size and complexity of the application, the number of environments in scope, and the reporting requirements. A precise timeline is confirmed during scoping once the target surface is agreed. Testing is delivered in sprints with progress updates rather than a single end-of-engagement handover.
Testing follows the OWASP Web Security Testing Guide (WSTG) as its baseline, supplemented by the Penetration Testing Execution Standard (PTES) for scoping and reporting, and CVSS v3.1 for severity rating. The approach is manual-first: scanners handle enumeration, but every finding is reproduced and validated by a tester.
Yes. After remediation, a retest verifies that each fix resolves the original finding and introduces no new weakness. Verified fixes are documented and an attestation letter is issued. The retest is included in the engagement price and the engagement is not closed until it is complete.
The report includes an executive summary and a technical section. Each finding has its CVSS severity, a proof of concept, the underlying cause, and prioritised remediation guidance. Findings are mapped to OWASP categories and, where relevant, to ISO 27001 Annex A or NIS2 Article 21 control objectives.
Penetration testing does not by itself constitute compliance with NIS2 or ISO 27001. It provides evidence for specific control objectives, such as NIS2 Article 21 vulnerability testing measures and ISO 27001 Annex A.8.8 and A.8.29. Testing should be aligned with your broader compliance programme.
Before testing, we need the target applications and environments, test accounts, documentation of intended behaviour, and written authorisation to test. Rules of engagement, timelines, and points of contact are agreed during scoping. Access to staging or production environments is confirmed before any active testing begins.
Book a scoping call and we'll define targets, rules of engagement, and timeline together.
Request a scoping call