Skip to main content

Penetration Testing

Authorised, hands-on testing that finds the weaknesses an attacker could exploit in your applications and infrastructure, and shows you how to close them.

Request a proposal

What it is

A penetration test is a controlled attack on your systems, carried out with your written permission and within agreed rules. Automated scanners help with coverage, but the value comes from skilled testers who chain issues together, test business logic, and confirm what is really exploitable.

Every finding is validated, rated with CVSS, and explained with clear steps to reproduce and fix it.

  • Web applications

    Authentication, session management, access control, input handling and business logic, following the OWASP Web Security Testing Guide.

  • APIs

    REST and GraphQL APIs, including authorisation flaws, data exposure and abuse of functionality, guided by the OWASP API Security Top 10.

  • Mobile applications

    Android and iOS apps and their back-end services, guided by the OWASP Mobile Application Security Testing Guide (MASTG).

  • Network and infrastructure

    External and internal networks, servers, cloud-exposed services and segmentation testing.

Who needs it

A penetration test is valuable if you:

  • Are launching a new application or making a major release
  • Handle personal data, payments or other sensitive information
  • Need evidence of testing for PCI DSS, ISO/IEC 27001, regulators or customer security questionnaires
  • Want to check that previous fixes and new controls actually work
  • Have changed your network, cloud environment or third-party integrations

Our approach

  1. Scoping and authorisation

    Define targets, test type (black, grey or white box), testing windows and contacts, and sign rules of engagement before any testing begins.

  2. Reconnaissance and mapping

    Map the attack surface: endpoints, roles, functions, technologies and exposed services.

  3. Testing and exploitation

    Manual testing supported by tooling, following OWASP WSTG, PTES and NIST SP 800-115. Exploitation stays within the agreed limits.

  4. Analysis and reporting

    Validate every finding, remove false positives, rate risk with CVSS and business context, and write clear remediation guidance.

  5. Debrief and retest

    Walk your team through the results, then retest the reported findings once fixes are in place.

Deliverables

  • Executive summary

    Overall risk posture, key issues and recommended priorities for leadership.

  • Technical findings

    Each issue with CVSS score, affected assets, evidence, steps to reproduce and specific remediation.

  • Debrief session

    A walkthrough with your developers and engineers to answer questions and agree next steps.

  • Retest report

    An updated report confirming the status of each finding after remediation.

Frequently asked questions

Will testing disrupt our production systems?

We agree testing windows, exclusions and stop conditions in advance and avoid destructive techniques unless you explicitly approve them. Where possible we recommend testing a production-like staging environment.

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

A scan is automated and lists potential issues. A penetration test uses skilled people to confirm which issues are real, combine them, and test logic that scanners cannot understand.

Black box, grey box or white box?

Grey box, where we receive test accounts and basic documentation, usually gives the best coverage for the time spent. We will recommend an approach during scoping.

How often should we test?

At least annually and after significant changes. PCI DSS, for example, requires penetration testing at least once every 12 months and after significant changes.

Ready to find out where you stand?

Tell us about your environment and goals. We will reply with a suggested scope and next steps.

Request a proposal