Penetration testing
that ends in a detection.
Most tests end with a report and a remediation list, and the findings die there. Ours end where your alerts do: every exploitable weakness we prove becomes detection content in the SOC, watched from then on.
A finding nobody actions
is a finding you paid for twice.
The uncomfortable truth about penetration testing is how much of it gets filed. A report lands, the critical items get fixed, the mediums go on a backlog, and next year a new tester finds most of them again.
That happens because testing and monitoring are almost always bought from different companies. The testers leave once the report is signed off, and nobody who saw the attack path is around when it matters. The report describes a way in; the SOC watching your estate never hears about it.
We run both, so the handover does not exist. What a tester proves is exploitable becomes detection content written for your estate, and it is backtested before it goes live. The medium-severity finding you decided not to fix this quarter is at least being watched for, which is a materially better position than a line item on a backlog.
- Every exploitable finding is reviewed for whether a detection can cover it.
- Detections written for your estate and backtested before deployment.
- Anything we could not detect is told to you plainly, rather than quietly dropped.
- The findings feed your Threat Attack Profile, so future testing targets what actually threatens you.
- One team, one escalation path, no handover between the people who found it and the people watching for it.
If you already have a SOC you are happy with, we will still test and we will still hand the detection logic over. The argument is that the loop should close somewhere, not that it has to close with us.
Nine kinds of test.
Scoped to what you actually run.
Internal and external, infrastructure and applications, on prem and in cloud. Scope is agreed in writing before anything is touched, and it can be as narrow as one application or as broad as the estate.
External infrastructure
Everything facing the internet: perimeter, websites, mail, remote access and the services nobody remembers exposing. The view an attacker starts from, tested the way they would.
Internal infrastructure
An attacker already inside, by phish, stolen credential or a contractor laptop. What they can reach, escalate to and move laterally onto, which is usually further than anyone expects.
Web applications
Authenticated and unauthenticated testing against the logic, not just the scanner findings: access control, session handling, injection and the business logic flaws no tool reports.
Mobile applications
iOS and Android, client side and the APIs behind them. Storage, transport, certificate handling and what the app trusts that it should not.
Cloud
Azure, AWS and GCP configuration, identity and privilege paths. Most cloud compromise is a permissions problem rather than an exploit, so that is where the time goes.
Wireless
Corporate and guest wireless: segregation, authentication and whether the guest network really is separate from the one your finance team is on.
Build and configuration review
A workstation, server or gold image assessed against how it is actually deployed. Finds the misconfiguration that a network test only finds if it happens to be reachable that day.
Code review
Source-level review of the components that matter most, so a flaw is found where it was written rather than inferred from the outside.
IoT and OT
Connected devices and industrial equipment, tested with the care that estate requires. Availability comes first, and what gets touched is agreed before it happens.
Not sure which you need? That is what scoping is for, and it is a conversation rather than a form. We will tell you when a test is the wrong purchase.
Scoped, tested, proven,
then tested again.
The retest is the part most providers charge extra for, and it is the only part that proves the money did anything.
-
01
Scope it honestly
What is in, what is out, what we are allowed to do and who to ring if something breaks. Agreed in writing, with the rules of engagement, before any traffic is sent.
-
02
Test it
Manual testing led by our own testers, with tooling used for coverage rather than as the test itself. A scanner report is not a penetration test and we will not sell you one as one.
-
03
Prove it
Findings come with evidence and a reproducible path, rated on what it would actually take an attacker to do it here, not on a generic score lifted from a database.
-
04
Explain it
A technical report your engineers can action and a summary your board can read, plus a walkthrough with the tester who found it rather than an account manager reading the document aloud.
-
05
Close the loop
Retest of the findings you fixed, and detection content written for the ones you have not. This is the step that separates a test from an invoice.
Our own testers,
start to finish.
The people testing your estate are ours. Nothing is subcontracted to a partner you never meet and never agreed to.
Our testers are individually certified and test full time, and the same person who found something is the one who walks you through it. That matters more than it sounds: the gap between a report and a fix is usually a conversation with whoever actually did the work.
It also means the engagement does not end when the report is signed. The tester who proved the attack path works in the same business as the analysts who will be watching your estate for it, so what they learned about your environment stays with us rather than leaving with a contractor at the end of the week.
Where we are strongest is what happens after the report, because we are the ones still watching the estate in six months.
A report somebody can act on,
and a retest that proves they did.
Deliverables are fixed and agreed at scoping, so nothing arrives as a surprise and nothing useful sits behind an upsell.
- A technical report
- Every finding with evidence, a reproducible path and a fix that is specific to your environment rather than a link to a vendor advisory.
- An executive summary
- What the risk is in business terms, written to be forwarded. Suitable for a board paper, an insurer or a customer security questionnaire.
- Risk ratings you can defend
- Rated on exploitability in your estate, not on a raw CVSS score. A critical that needs domain admin to reach is not the same critical as one on the perimeter, and we say so.
- A walkthrough with the tester
- A session with the person who did the work. Questions get answered by whoever found it rather than relayed through an account team.
- A retest
- The findings you have fixed, verified and the report updated, so you have evidence of closure rather than an assertion of it.
- Detection content
- Where a finding can be detected, the logic is written for your estate and backtested. Yours to keep whether or not we run your SOC.
Penetration testing, answered.
How much does penetration testing cost in the UK?
It is priced on tester days, and days come from scope: how many hosts or applications, internal as well as external, whether testing is authenticated, and whether a retest is included. We quote against a written scope rather than publishing a rate, because a number without a scope behind it is guesswork.
How long does a penetration test take?
Most single-application or external infrastructure tests run three to five tester days, with the report a few days behind. Scoping happens before that and the retest after. A larger internal or multi-application engagement is longer, and we will say so at scoping rather than mid-test.
Who will actually be testing our estate?
Our own testers, employed by us and testing full time. Nothing is subcontracted to a partner you never meet and never agreed to. They are individually certified, and the person who finds something is the one who walks you through it rather than an account manager relaying it secondhand.
Do you use AI and automation in testing?
Yes, for coverage and repetition, where it beats a person comfortably. Judgement stays with the tester: chaining unremarkable findings into one real attack path, and working out what a weakness is worth in your estate. Afterwards the findings become detection content our AI SOC runs around the clock.
What is the difference between a penetration test and a vulnerability scan?
A scan lists what might be wrong. A test proves what an attacker could actually do with it, and chains findings that look minor on their own. Scans are cheap, fast and worth running often. A test answers a different question, and one is not a substitute for the other.
How often should we test?
Annually as a baseline, and again after anything that changes the attack surface: a new application, a migration, a significant infrastructure change or an acquisition. Compliance obligations and customer contracts often set the floor, and testing to that floor alone is how gaps open between tests.
Do you provide a retest after we fix the findings?
Yes, and it is agreed in the original scope rather than sold afterwards. We verify what you have remediated and update the report so you hold evidence of closure, which is what an auditor, insurer or customer will ask for.
What happens to the findings afterwards?
Where a finding can be detected, we write detection content for your estate and backtest it before it goes live. It is yours whether or not we run your SOC. Anything we could not build a detection for is stated plainly rather than left out of the report.
Will testing disrupt our systems?
Rules of engagement are agreed before anything starts, including what is out of scope, what needs a maintenance window and who to call. Testing against OT and IoT is treated with more caution again, because availability comes first on that estate. Disruptive techniques are used only where you have agreed to them.
Scope it properly
before anybody quotes you.
A conversation with somebody who tests for a living, not a form that produces a number. We will tell you which test answers your question, and when a test is the wrong purchase.