Penetration testing
A tester works against a defined target with a defined goal, by hand, the way an attacker would. The output is not a list of theoretical weaknesses — it is a record of what was reached and how.
ROOT64 / VERIFIED
Automated tooling finds the obvious. People find the rest.
Business logic flaws, broken access control between two legitimate user roles, chained low-severity issues that together become critical — none of these are visible to a scanner, because none of them look like a bug in isolation.
Every test is manual at its core. Tooling is used to cover ground quickly; judgement decides what is worth chasing.
We test against a written objective agreed with you, so the report answers a question you actually asked.
What we test
- Web applications
- Authentication, session handling, access control between roles, injection, business logic, file handling, and the admin surface people forget is internet-facing. Mapped to OWASP WSTG and ASVS.
- APIs
- REST and GraphQL. Object and function level authorisation, mass assignment, rate limiting, token handling and undocumented endpoints. Mapped to the OWASP API Security Top 10.
- Mobile applications
- Android and iOS. Local data storage, certificate handling, hardcoded secrets, tamper resistance and the backend the app talks to. Mapped to OWASP MASTG.
- Internal network and Active Directory
- Assumed-breach positioning from a workstation or VPN foothold: credential exposure, privilege escalation paths, lateral movement, domain escalation.
- External infrastructure
- Perimeter services, forgotten hosts, exposed management interfaces, VPN and remote access, mail and DNS configuration.
- Cloud configuration
- AWS, Azure and GCP. Identity and permission boundaries, public exposure, key management, network segmentation and whether your logging would have caught us.
How much we are told beforehand
- Black box
- No credentials, no documentation. Closest to an unauthenticated outsider. Cheapest to start, and the least coverage per rupee — a tester spends time discovering what you could simply have told them.
- Grey box
- Standard user credentials and basic documentation. The best coverage-to-cost ratio for most applications, and what we recommend by default.
- White box
- Full credentials for every role, architecture documentation and source code where available. Highest coverage, best for pre-launch and regulated systems.
Scope
Not included unless separately agreed
- Denial-of-service testing
- Phishing or pretexting against staff — that is red teaming
- Testing of third-party SaaS you do not control and cannot authorise
- Exploitation that would destroy or exfiltrate live customer data
How the engagement runs
Every step is authorised, evidenced and designed to leave your team with a clear next action.
-
Objective and rules of engagement
Written scope, targets, credentials, test windows, stop conditions, escalation path and named authoriser. Nothing starts without it.
-
Reconnaissance and mapping
Understand the application, its roles, its data and its trust boundaries before attacking any of them.
-
Manual testing
Systematic coverage against the applicable OWASP methodology, plus targeted work on whatever looks weakest.
-
Exploitation and chaining
Confirm real impact. Individually minor findings are chained where doing so demonstrates a genuine path to your data.
-
Critical escalation
Anything critical is reported the same day, not held back for the final document.
-
Report and debrief
Written report plus a live walkthrough with the engineers who will fix it.
-
Retest
Fixes verified and closure status recorded against every finding.
What you receive
Included in every engagement
- Executive summary and risk narrative
- Finding register with reproduction steps and evidence
- Attack path diagrams where findings chain
- Prioritised remediation plan with effort estimates
- Same-day notification for critical findings
- Retest report and closure register
- A letter of attestation you can share with customers and auditors
Standards and methodology
Testing follows published methodology rather than an in-house checklist, so coverage is reviewable and comparable between engagements.
- OWASP WSTG
- OWASP ASVS
- OWASP API Security Top 10
- OWASP MASTG
- PTES
- NIST SP 800-115
Common questions
How often should we test?
Annually as a baseline, and again after any significant architectural change, new authentication flow, payment integration or major release. Continuous change deserves more than an annual snapshot.
Do you need our source code?
Not required, but it improves coverage. A white box test finds more per day than a black box test on the same application.
Can we share the report with a customer?
Yes. We also issue a letter of attestation that confirms the engagement without disclosing the technical findings.