Overview
Automated scanners find the easy issues and miss the expensive ones, like changing a number in a URL and seeing another customer's invoice. We test your web application by hand, covering the usual vulnerability categories plus the business rules only your product has, acting as a user who is already signed in. Every issue comes with clear steps to reproduce it and proof that it works, so your developers can fix rather than debate. Once your fixes are in, we retest and update the report for your customers.
What you receive
- Manual testing of login, permissions and your application's business rules
- Standard web vulnerability categories checked, plus API-specific test cases
- Each finding scored with CVSS and backed by reproduction steps and proof
- Permission boundaries tested for every user role in your product
- A plain-language summary for non-technical leaders and stakeholders
- Fix guidance written for your own stack rather than generic advice
- A second round of testing within 30 days at no charge, plus a customer attestation letter
How it runs
-
Step - 01
Scoping
We agree targets, user roles, test accounts and the rules we will follow.
-
Step - 02
Testing
Several days of hands-on testing, with any critical issue raised to you straight away.
-
Step - 03
Reporting
Each finding is written up with proof, a score and practical fix advice.
-
Step - 04
Retest
After your team fixes issues, we confirm them and update the report.
Timeline: 12 working days, counted from the day we receive what we need from you.
Is it a fit?
A good match for
- Apps that store payment, medical or other personal information
- Businesses asked by a large customer for a third-party security report
- Teams whose product no outside tester has ever examined
What we need from you
- Test logins for all user roles, on staging or a near-production copy
- Written permission to test from someone authorised to give it
- A developer who can respond fast if we find something critical
Why it helps
- Security holes found and closed before an attacker uses them
- Documentation fit for customer or auditor review
- Proof that fixes work, rather than assuming they do
Questions
We prefer staging. If production is the only option, we agree strict boundaries and timings with you first and avoid any tests that could damage data or availability.
It follows the layout that auditors and security reviewers at large customers generally expect, including for ISO 27001 or SOC 2 reviews. Acceptance is ultimately your auditor's decision.
We state that in the report. A documented clean result is itself useful evidence whenever customers or auditors ask for it.