The test is the easy part. The report is what you actually buy.

Services

Five things we test, and nothing we don't.

• 

  Web Application Testing

  Manual testing of your application's authenticated and unauthenticated attack surface, aligned to OWASP ASVS.

• 

  Mobile Application Testing

  iOS and Android testing that treats the app as untrusted, because in an attacker's hands it is.

• 

  External Network Testing

  What an attacker on the internet can see, reach and exploit before anyone at your company notices.

• 

  Internal Network Testing

  We assume the perimeter already failed, then find out how far that gets someone inside your network.

• 

  API Testing

  Your API is the real application. We test it directly, with every client-side restriction removed from the path.

How it runs

Six phases, and you hear from us in every one.

1. 01

   Scoping and threat alignment

   We agree targets, roles, environments and exclusions in writing, then map the attack surface that actually matters to your business.

2. 02

   Manual recon and enumeration

   Full enumeration of routes, parameters, roles and API endpoints. Automated scanning is a starting point here, never the deliverable.

3. 03

   Targeted exploitation

   Confirmed exploitation of what we find, with evidence captured as we go. We do not report theoretical findings.

4. 04

   Impact analysis

   Each finding is scored with CVSS and classified with CWE, then adjusted for what it means in your environment specifically.

5. 05

   Reporting and remediation

   Written findings with reproduction steps, evidence and remediation guidance specific enough to hand to a developer.

6. 06

   Retest

   Once you have remediated, we retest the affected workflows and issue a retest summary confirming what is closed.

Case study

Finding an MFA bypass in a multi-tenant SaaS platform

A six-day white box assessment of a multi-tenant workforce management platform, tested from both authenticated and unauthenticated perspectives across staging and production, combining manual application testing, API testing, business-logic analysis and source-code review.

Something you won't see elsewhere

We tell you what's working, too.

Every report includes a positive observations section covering the controls that held up under testing. It is not padding. If you have already invested in a control that works, you should know it works, and you should not be sold a fix for it.

On the engagement above, we reported the following as plainly as the findings:

• No path to remote code execution was found.
• No SQL injection was found.
• No cross-tenant or cross-user data access was demonstrated.
• No unauthenticated compromise was demonstrated. The primary attack path required a valid password.

Findings are reported at the severity the evidence supports. We would rather tell you an issue is moderate than inflate it to justify an invoice.

Common questions

The four we get asked first.

What is a penetration test, and why does it matter?

A penetration test is a time-boxed, authorised attempt to break into your systems the way a real attacker would, followed by a written account of what worked. It matters because it tells you which weaknesses are actually exploitable in your environment, rather than which ones a tool flagged as theoretically present.

How often should we test?

Annually is the common baseline, and after any significant change to authentication, authorization, or your externally reachable surface. A test is a snapshot of one moment. If you rewrote your login flow last month, last year's report no longer describes your application.

We do not hold sensitive data. Why would anyone attack us?

Most attacks are not targeted. Automated scanning finds your systems because they are reachable, not because of what they contain. Your infrastructure has value as a foothold, a mail relay, a host for someone else's content, or a route into a customer with deeper pockets than you.

What is the difference between a vulnerability scan and a penetration test?

A scan compares what it can see against a list of known issues and produces output. A penetration test uses scanning as one input, then a person tries to exploit what was found, chains findings together, and tests the logic no scanner understands. If a report reads like tool output, you paid for a scan.