Service 01
Penetration
testing
Independent, manual testing of the systems you depend on — carried out the way an attacker would approach them, reported the way your engineers can act on.
In short
A penetration test is an authorised, time-boxed attempt to compromise a defined system in order to find and prove exploitable weaknesses before a real attacker does. It differs from a vulnerability scan in that a human tester chains findings together, verifies exploitability, and reports business impact rather than a raw list of potential issues.
What we typically test
Scope follows risk, so the first conversation is about what would actually hurt if it failed — not about which package to buy. In practice, engagements usually fall into one or more of the following.
Web applications
Authentication and session handling, access control between users and tenants, injection and deserialisation, business-logic abuse, file handling, and the parts of an application that only misbehave when a real user account is driving them. Testing is aligned to the OWASP Testing Guide and the OWASP Top 10, extended with logic testing that no checklist covers.
APIs and integrations
REST, GraphQL and service-to-service interfaces, where the most common serious findings are broken object-level authorisation, missing rate limits, over-permissive tokens and inconsistent validation between the API and the application in front of it. Our guide to API authentication methods covers the failure modes we see repeatedly.
Infrastructure — external and internal
External perimeter testing looks at what is reachable from the internet and what an unauthenticated attacker can do with it. Internal testing assumes a foothold already exists — a compromised laptop, a contractor VPN account — and answers the question that matters more: how far does that foothold get?
Cloud environments
Identity and permission design in AWS, Azure and Google Cloud, exposed storage, network segmentation, secrets handling, and the privilege-escalation paths that come from roles being wired together for convenience. Our application security architecture guide sets out the zero-trust reference model we test against, with the Azure and AWS controls side by side.
Mobile applications
iOS and Android clients, their local data storage, transport protection and certificate handling, and the backend they talk to — which is usually where the more serious findings live.
How we test
Every engagement is manual testing supported by tooling, not the reverse. Automation is used to cover ground quickly and consistently; the findings that matter — chained access-control flaws, logic abuse, trust assumptions between services — come from a person who understands what the application is for.
Work is carried out against recognised methodologies: the OWASP Testing Guide and Application Security Verification Standard for applications, the Penetration Testing Execution Standard for infrastructure, and CIS Benchmarks and provider baselines for cloud configuration. Findings are rated with CVSS for comparability, then re-ranked by what they actually mean for your business — because a medium-severity flaw on the system that holds your customer data outranks a high-severity one on a staging box nobody uses.
What you receive
A typical engagement delivers the following. The exact deliverable set is confirmed at scoping — some clients need a board pack, some need only the technical detail, and some need an attestation letter they can share.
- An executive summary that a non-technical reader can act on: what we found, what it would cost you, what to do first.
- Detailed technical findings, each with evidence, reproduction steps, affected components, and remediation guidance specific to your stack.
- A prioritised remediation plan ordered by risk reduction per unit of effort, so a small team knows where to start.
- A findings walkthrough with your engineers, because the questions that matter rarely get asked of a PDF.
- A retest of remediated findings, and a clean summary report suitable for sharing with customers, insurers or auditors.
Before you commission a test
Most disappointing penetration tests were mis-scoped before anyone touched a keyboard: the wrong environment, no credentials, a scope that excluded the thing an attacker would go for. We have written up how to avoid that in How to scope a penetration test — including the questions worth asking any provider, us included, before you sign.
Platform experience, stated
We test named platforms, not categories. Our assessments have covered VMware vSphere 8, NetApp ONTAP, ServiceNow and its MID Servers, Microsoft 365, Azure and AKS, API estates of 1,300+ endpoints, IPC Unigy trading communications and Windows and macOS corporate builds. The full list, and the benchmark each is measured against, is on the experience page.
Two ratings, both defended
Every individual finding is rated with CVSS v4.0, exploit-maturity modifier included. Every attack chain — a sequence of findings from a realistic starting position to a business outcome — is rated separately on cumulative impact using OWASP Risk Rating and a qualitative risk matrix of the kind described in ISO/IEC 27005:2022 Annex A. The two axes are reported side by side, because a chain of Mediums can be a Critical.
Reproducible and honest about coverage
Tool names and versions are listed in an appendix of every report, so any result can be reproduced. Where automation allows, coverage extends across the whole in-scope population; where it does not, the sampling approach is stated openly, so you know how much coverage you bought.
Questions we are asked
What is the difference between a penetration test and a vulnerability scan?
A vulnerability scan is automated. It compares what it can see against a database of known issues and produces a list of possibilities, including false positives. A penetration test is driven by a person who verifies which of those issues are genuinely exploitable, chains them together, tests the logic that no scanner understands, and reports the business consequence. Scanning is a useful routine hygiene control; it is not a substitute for testing, and no serious framework treats it as one.
How often should we run a penetration test?
The common baseline is annually, plus a test after any significant change — a new application, a major architectural change, a migration, or a merger that brings an unfamiliar estate onto your network. Some regimes are stricter: PCI DSS requires testing at least annually and after significant change. For teams shipping continuously, a single annual test tells you about a system that no longer exists, so a smaller recurring scope tends to be more useful than one large yearly exercise.
Should we test production or a staging environment?
Production gives the truest answer, because staging environments differ in configuration, data and scale in ways that hide real findings. Where testing production carries unacceptable risk, we test a staging environment that is a genuine mirror — same configuration, same integrations, representative data — and say clearly in the report which differences remain untested. A staging environment that is materially different from production produces a report about a system you do not run.
Will testing take our systems down?
Testing is conducted under written rules of engagement that define what is in scope, what techniques are excluded, testing windows, and the escalation path if something unexpected happens. Denial-of-service testing is excluded by default and only performed if explicitly requested and separately agreed. Disruption is rare, but the honest answer is that any interaction with a live system carries some risk — which is why the rules of engagement, and a named contact who can be reached during the test, are agreed before work starts.
Do you provide a certificate or letter of attestation?
Yes. Alongside the full technical report, we can issue a summary attestation letter confirming the scope, dates and methodology of the test, and the remediation status at the point of retest. This is the document usually shared with customers, insurers and procurement teams, since the full report contains detail you would not want circulating.
What do you need from us to get started?
A description of the systems in scope, the environments and URLs or ranges involved, test credentials for each user role if the application is authenticated, a named technical contact, and written authorisation from someone entitled to give it — including from your hosting provider where their terms require it. Anything missing at the start becomes lost testing time later.
Next step
Talk to a security consultant
Tell us what you are building, defending or certifying. We will tell you plainly what we would test first, what it takes, and whether you need us at all.