We test your applications, networks and online exposure the way an attacker would, then explain what we found, how serious it is and how to fix it. Nothing starts until you've signed the rules of engagement.

What we test

A scanner gives you a list of possible problems. A tester works out which ones can actually be used, how they connect, and what someone could reach with them.

  • Web applications and APIs

    Customer portals, internal tools and the APIs behind them: how people log in, what each user can see and change, where data leaks out, and whether the business logic can be bent.

  • External and internal networks

    Everything you expose to the internet, tested from outside. And what someone could do from a single compromised laptop or staff account.

  • Reconnaissance

    What an attacker can learn without touching your systems: forgotten subdomains, exposed services, leaked passwords and code. Done with Hound, so every finding has evidence.

  • Investigations

    Research into a specific question, with your authorisation. Are staff credentials being traded? How did a document end up online?

Red team engagements

Weeks rather than days. We agree an objective, for example read access to the finance share, and try to reach it the way a real attacker would, recording what your staff, your IT provider and your tools noticed along the way.

  1. ReconnaissancePublic sources, exposed services, leaked credentialsNot detected
  2. Initial accessA targeted phishing email to an agreed group of staffNot detected
  3. FootholdA test implant on one workstationDetected, no response
  4. Privilege escalationA misconfigured service accountNot detected
  5. Lateral movementFrom the workstation to a file serverDetected and escalated
  6. ObjectiveRead access to the agreed finance shareObjective reached
Detected at 2 of 6 stages. An example of what the debrief shows, not a real client.
  1. Agree the objective

    What we're aiming for, which techniques are allowed, who on your side knows, and when we stop. All in the signed rules of engagement.

  2. Run the engagement

    Reconnaissance, getting in, moving towards the objective. Every action is logged with a timestamp so it can be replayed.

  3. Stop if we need to

    If we hit the stop condition, find something critical, or see signs of a real attacker, we stop and call your emergency contact.

  4. Debrief

    We go through the attack with your team stage by stage and agree which changes would have caught us earliest.

If you haven't had a penetration test before, that's usually the better place to start. We'll tell you which one makes sense.

How a penetration test runs

The same five stages every time, and no testing before the rules of engagement are signed.

  1. Scoping

    What you want to find out, which systems are in scope, when we can test and who needs to know. If a customer or insurer asked for it, we make sure the scope covers what they want.

  2. Rules of engagement

    The scope goes into a written document that you sign. We don't start testing before that.

  3. Testing

    Mostly manual work in the agreed windows. If we find something critical, or evidence someone has already been in, we stop and call you.

  4. Report

    A short summary for management and a technical section for whoever fixes things, then a call to go through it.

  5. Retest

    Once you've fixed the issues we test them again and update the report, so you can show it to your customer or insurer.

Rules of engagement

Accessing a computer system without permission is a criminal offence under the Computer Misuse Act 1990. The signed rules of engagement are what make our work legal, so we're strict about them.

We also check that the person signing has authority over every system in scope, including anything hosted by a third party.

More on how we work

Scope
The systems, addresses, applications and accounts we may test.
Objectives
What the test is meant to establish.
Timing
When we can test, and any periods when we must stop.
Exclusions
Systems and techniques that are off limits.
Contacts
Named people on both sides and how to reach them.
Data
How we store evidence and when we return or delete it.

What you get

A report written for two audiences. The first pages are for management, a customer or an insurer. The rest is for whoever fixes things: each finding with evidence, the affected systems and the steps to fix it, in the order we'd tackle them.

  • A management summary you can pass on
  • Technical findings with evidence and fixes
  • A prioritised list based on your actual risk
  • A call with the testers to go through it
  • A retest and an updated report
  • Evidence returned or deleted as agreed

Has someone asked you for a penetration test?

Send us what your customer or insurer asked for and we'll tell you what a test that meets it would involve.