Security
Penetration Testing Services
Authorised, scoped, and done the way a real attacker would work, chaining weaknesses into a proven exploit, then handing you a prioritised report you can act on rather than a catalogue of theoretical risk.
What Penetration Testing means in practice
Who it’s for: Organisations that would rather discover how they could be breached on their own terms (with permission, in a controlled test), than read about it in an incident report, especially those handling sensitive or regulated data, launching something significant, or facing a compliance or customer security requirement.
A penetration test is authorised, ethical, adversarial security testing: with your written permission and a signed scope, skilled testers behave like a real attacker against your systems to find weaknesses and safely demonstrate how they could actually be exploited. The word that matters most in that sentence is authorised. Everything we do here is done with a client permission agreement and defined rules of engagement in place before a single packet is sent: this is legitimate, professional, defensive security work, never anything unauthorised. Within that boundary, the point of the exercise is to stop guessing about your exposure and start knowing it, by having someone competent try to break in on your terms rather than waiting for someone hostile to try on theirs.
What separates a real penetration test from a scan is exploitation and chaining. Automated scanners are good and cheap at what they do (they find the known, catalogued issues quickly and at scale), but they report findings in isolation and they cannot reason. A human tester takes three individually-minor problems, an information leak here, a weak default there, a permission that is slightly too broad, and chains them into a full compromise that no scanner would ever have flagged, because none of the three parts is a vulnerability on its own. The interesting failures in real systems are almost always business-logic flaws and chains like that, and finding them is what you are paying a person to do.
We are blunt about what a penetration test is and is not, because the industry sells it badly. It is a point-in-time snapshot: it tells you what an attacker could do against this system, in this configuration, on the day we tested. It does not make you permanently secure, because your code, dependencies and cloud configuration change the day after we finish, and security is a continuous property, not a certificate you earn once. It is also not a substitute for the cheaper, continuous, automated scanning that should catch the common issues between tests: that is a different job, covered by our security-testing service. The value of a pen test is entirely in fixing what it finds. The report is the start of the work, not the end of it, and a signed-off certificate that nobody acted on has bought you nothing.
What you get
- A signed scope and rules of engagement agreed before any testing begins, exactly what is in and out of bounds, when we test, how we handle anything sensitive we find, and an emergency contact if something needs to stop
- Manual, human-led testing that goes beyond automated scanning, business-logic flaws, access-control failures and multi-step chains that tools cannot reason their way to, because a person is doing the reasoning
- Controlled, safe exploitation that proves a finding is real rather than theoretical. We demonstrate impact carefully and reversibly, without damaging data or disrupting the service we were hired to assess
- A prioritised report written for two audiences: an executive summary of what an attacker could actually achieve and what it would cost you, and technical detail with reproduction steps and clear remediation guidance for the engineers who will fix it
- Every finding risk-rated by real, demonstrated impact and exploitability (not a raw scanner severity), so you fix what an attacker would reach first rather than working down an undifferentiated list
- A debrief where we walk your team through the findings, answer questions, and help you sequence the remediation, because a report handed over in silence is a report half-wasted
- A retest after you have fixed the findings, to confirm the fixes actually close the holes and did not quietly open new ones. The difference between believing you are fixed and knowing it
What Penetration Testing does for you
You find out on your own terms
The choice is not whether your systems get probed, anything exposed to the internet is probed constantly by people who did not ask permission. The choice is whether the first competent person to find your weaknesses is working for you, under a scope, writing you a report, or working against you, under no rules, writing nothing. An authorised penetration test buys you the far cheaper of those two ways to learn where you are exposed.
Real risk separated from noise
A scanner will hand you hundreds of findings, most of them low-impact, some of them false positives, all of them undifferentiated. That volume is its own failure mode: a team facing an unranked wall of issues fixes the easy ones and loses the dangerous ones in the pile. A human-led test inverts that. It tells you the handful of things an attacker would actually use, proves them, and ranks them by real impact, so your remediation effort lands where it changes your exposure rather than where it pads a metric.
Evidence you can show others
When a customer, regulator or insurer asks whether your systems have been tested, a credible, independent penetration report and the record of remediation that followed it is the answer that satisfies them. It is worth being honest that the certificate is not the point and does not make you secure, but as evidence that you took your exposure seriously, had it tested by people with no incentive to go easy, and fixed what they found, it does real work in a procurement or audit conversation.
Why teams choose us for Penetration Testing
- You want testing done by senior security engineers who exploit and chain by hand, not a service that runs a scanner, exports the PDF, and bills you for the reformatting, because the findings that matter are exactly the ones a scanner cannot reason its way to.
- You want a report you can act on: prioritised by demonstrated impact, written so your executives understand the risk and your engineers can reproduce and fix each finding, rather than a raw tool dump that lands on a desk and is never opened again.
- You want a firm that is honest about the limits of the exercise. That a pen test is a point-in-time snapshot, that automated scanning is the cheaper tool for the common issues between tests, and that the value is entirely in the fixing, rather than one that sells you a certificate and implies it makes you permanently secure.
- You want the loop actually closed with a retest, so you leave the engagement knowing your fixes worked, not hoping they did, and because we operate what we build, we treat that confirmation as part of the job rather than an upsell.
What Penetration Testing includes
The concrete pieces of work this covers, scoped to what your problem actually needs.
Web application penetration testing
Testing web applications the way an attacker approaches them: authentication and session handling, access control between users and roles, injection and input-handling flaws, and (most valuable of all), the business-logic failures unique to your application that no generic tool understands, like a checkout that can be made to skip payment or an approval step that can be bypassed by calling the steps out of order. This is where chaining pays off, and where human testing is worth most over scanning.
API penetration testing
APIs are increasingly the real attack surface, and they fail differently from the web pages in front of them. We test for broken object-level and function-level authorisation: the classic case where a user can read or change another user’s data simply by editing an identifier in a request, along with excessive data exposure, missing rate limits, and authentication and token handling. Because APIs are meant to be called by machines, the assumptions they make about their callers are often weaker than the UI implies, and that gap is exactly what we probe.
Network and infrastructure penetration testing
Testing the network and the systems on it (external perimeter and, where scoped, internal networks), for exposed and misconfigured services, weak or default credentials, missing patches, and paths that let an attacker who gets a foothold move laterally and escalate privileges. The internal test in particular answers a question most organisations cannot: if someone did get in, whether through a phished laptop or a compromised supplier, how far could they actually get, and how fast?
Cloud penetration testing
Cloud environments are breached through configuration far more often than through exotic exploits. An over-permissive role, a storage bucket open to the world, a secret committed where it should not be, an identity that can quietly grant itself more than it should. We test your cloud estate for exactly those failures across the major providers, focusing on identity and access, network exposure, and the privilege-escalation paths that turn a small foothold into control of the whole account.
Mobile application penetration testing
Mobile apps carry risks the web does not, because the client runs on a device you do not control. We test how the app stores data on the device, how it talks to its backend and whether that channel can be intercepted or tampered with, how it handles authentication and secrets, and what an attacker with the app in hand can learn or abuse by reverse-engineering it. The backend the app talks to is tested as an API, because that is usually where the real damage is done.
Reporting, risk-rating and retesting
The deliverable is as much a capability as the testing itself. We rate each finding by demonstrated impact and real exploitability rather than a raw tool severity, write it up so both a board and an engineer can act on it, walk your team through it in a debrief, and (after you have remediated), retest to confirm the fixes hold. A finding nobody can reproduce or nobody prioritised correctly is a finding wasted, so the report is engineered as deliberately as the exploit.
Where it fits
Meeting a compliance or customer security requirement
A company that has been told, by a regulator, a large customer or an insurer, that it needs an independent penetration test before it can handle certain data or sign a contract. We scope the test to the systems and standard in question, test them properly rather than performing a box-ticking exercise, and produce a report and a remediation record that stands up in the audit or procurement conversation. We are clear throughout that passing the test is not the goal (closing the findings is), but we make sure you have the credible evidence the requirement actually asks for.
Hardening a product before a major launch
A team about to launch a product that will hold sensitive data and be exposed to the internet, who want to know how an attacker would go at it before real ones do. We test the web application, its APIs and the cloud environment behind it as a whole, chaining across those boundaries the way an intruder would rather than testing each in a silo, and hand back a prioritised list of what to fix before launch versus what can follow. The aim is that the first serious attempt to break in happens under our scope, not on your launch day.
Assessing exposure after a significant change
An organisation that has just migrated to the cloud, replaced its authentication system, merged in another codebase, or shipped a major new feature, and reasonably suspects the change introduced exposure its routine testing would not catch. We focus the test on the changed surface and the trust boundaries around it, because that is where new intrusion paths appear, and confirm whether the change quietly opened something that needs closing before an attacker finds it first.
Answering "how exposed are we, really?" for a data-sensitive business
A business handling personal, financial or health data that has never had anyone competent and independent try to break in, and genuinely does not know how exposed it is. We run a scoped external and, where warranted, internal test to answer that honestly, what an attacker could reach, how far a foothold would spread, and what it would cost, and turn a vague, background anxiety into a concrete, prioritised list of things to fix, which is a far better place to make decisions from than not knowing.
How we approach Penetration Testing
We test the way an attacker actually works, which means thinking in chains rather than in checklists. A scanner walks a list and reports each item in isolation; a real intrusion strings small, individually-unremarkable weaknesses together until they add up to a compromise. So our testers spend their effort where the reasoning lives: the access controls, the trust boundaries, the business logic, the assumptions a system makes about who is calling it and why, because that is where the exploitable, chainable failures hide and where automated tooling is weakest. Tools have their place and we use them to cover ground quickly, but they set up the human work rather than replace it.
Everything happens inside the agreed scope and rules of engagement, and we exploit carefully. Proving a finding means demonstrating real impact without causing real harm: we will show that we could reach data we should not, or take an action we should not, in a way that is safe and reversible and does not disrupt the system we were hired to assess. We keep you informed as we go rather than disappearing for a fortnight and returning with a document, if we find something serious enough that you would want to know immediately, you hear about it immediately, not on report day.
The methodology: scoping to retest
Everything begins with scoping and rules of engagement, and nothing technical happens until they are signed. We agree in writing exactly what is in scope and what is explicitly out of it, the type of test (black, grey or white box), when testing may run so it does not collide with your peak load, how we handle anything sensitive we uncover, and who to contact (on both sides), if something needs to pause or stop. This is the authorisation that makes the work legitimate, and it is also where a good test is shaped: too narrow and you get false comfort, too broad and effort is spread thin. From there we move into reconnaissance, mapping the actual attack surface: the hosts, endpoints, technologies, entry points and trust boundaries that really exist, which is frequently larger and messier than the architecture diagram claims.
Reconnaissance feeds vulnerability identification, where we combine automated tooling to cover ground quickly with the manual analysis that finds what tooling cannot. The logic flaws, the broken access controls, the assumptions worth attacking. Then comes controlled exploitation: rather than merely reporting that something looks vulnerable, we prove it, safely and reversibly, within scope, so a finding is demonstrated fact rather than a scanner’s guess. Where an exploit lands we do post-exploitation impact assessment: establishing what that foothold actually reaches, whether it chains into something worse, and how far a real attacker could take it, because the severity of a hole is defined by where it leads, not by the hole itself. Finally the whole thing becomes a prioritised report with clear risk ratings and remediation guidance, a debrief to walk your team through it, and, once you have fixed the findings, a retest to confirm the fixes closed the holes and opened no new ones. That retest is what turns a report into a resolved problem.
Types of test: black, grey and white box, across every surface
A penetration test is defined partly by how much we are told up front, and the right choice is a genuine trade-off rather than a default. In a black-box test we start with nothing but what any outsider could find, which most faithfully simulates an external attacker with no inside knowledge but spends real budget on reconnaissance that a real attacker with unlimited time would also do. In a white-box test we are given source code, architecture and credentials, which lets us test far more thoroughly and cheaply because no effort is wasted rediscovering what you already know: at the cost of being less like a first-contact intrusion. Grey box sits in between and is often the most cost-effective for an application: we test as an authenticated user with some knowledge, which mirrors the very common real-world case of an attacker who has obtained a low-privilege account, and concentrates the budget on finding what that foothold can be turned into. We will recommend the level that answers your actual question rather than the one that sounds most impressive.
Independently of the box colour, a test is scoped to one or more surfaces, and each is its own discipline. Web application testing goes after logic and access control in the app itself; API testing goes after the authorisation and data-exposure failures behind it, which are often where the real damage lives; network and infrastructure testing goes after exposed services, weak credentials and lateral movement across hosts; cloud testing goes after the identity and configuration failures that account for most cloud breaches; and mobile testing goes after on-device storage, the app-to-backend channel, and what reverse-engineering the client reveals. Real engagements frequently combine several, because attackers do not respect these categories. A chain that starts at a leaky API endpoint and ends in a cloud account takeover crosses three of them, and testing them together is the only way to find the chains that run between them.
How findings are risk-rated and remediated
A finding is only useful if you can tell how much it matters, and we deliberately do not rate by raw tool severity, because a scanner’s idea of severity ignores your context entirely. We rate by two things we can actually speak to: demonstrated impact, what we proved this finding lets an attacker do to your specific system and data (and exploitability), how realistically and easily an attacker could pull it off given your real configuration, not a worst-case abstraction. A theoretically-high issue behind three other controls that make it impractical is rated down; a theoretically-modest issue that we chained into an account takeover is rated up. The output is a genuine priority order, which matters enormously, because the whole point of ranking is to stop your team draining its effort on easy, low-impact fixes while the dangerous ones sit untouched.
Remediation guidance is written to be acted on, not admired. For each finding we give the reproduction steps so an engineer can see it fail for themselves, the underlying cause rather than only the symptom, and specific, practical fix guidance for your stack, and where several findings share a root cause, we say so, so you fix the class rather than swatting instances. In the debrief we help you sequence the work against real constraints, distinguishing what must be fixed before you are safe from what is genuine improvement. And because a fix you have not verified is a fix you are merely hoping worked, we retest afterwards to confirm each finding is actually closed and that the change did not open something new. That closed loop is the difference between a report that changed your security posture and one that changed only your filing system.
Signs it’s time
- A customer, partner, insurer or regulator is asking for an independent penetration test, before you are allowed to handle their data, sign the contract, or meet a standard such as those that govern payments, health or personal data
- You are about to launch or significantly expand something that will hold sensitive data or be exposed to the internet, and you want to know how an attacker would go at it before real attackers get the chance
- You have made significant changes. A new authentication system, a cloud migration, a major feature, a merged codebase. That could have introduced exposure your existing testing would not have caught
- You handle personal, financial or otherwise regulated data and genuinely do not know how exposed you are, because nobody competent and independent has ever tried to break in with permission
Our testing philosophy
The core belief is that a penetration test earns its keep through exploitation and chaining, not enumeration. Anyone can run a scanner and hand you its output; the value a skilled human adds is the reasoning that turns a scatter of individually-minor findings into a proven, end-to-end compromise, and the judgement to know which of a hundred flagged items actually matters. So we spend our effort on the parts machines are worst at (logic, access control, trust boundaries, chains that cross system types), and treat tooling as a way to cover ground and set up the human work rather than as the work itself. A test that only tells you what a scanner would have told you has not paid for a tester.
The second belief is that we owe you honesty about what the exercise can and cannot do, because the industry routinely oversells it. A pen test is a point-in-time snapshot: it tells you your exposure on the day we tested, against the system as it was configured that day, and it does not make you permanently secure, because everything changes the moment we finish, security is a continuous property, not a one-off certificate. It is not a replacement for the cheaper, continuous, automated scanning that should catch the common issues between tests, which is a different job handled by our security-testing service. And its entire value is realised in the fixing: a report that is filed and forgotten has bought you nothing but a document. We would rather tell you that plainly, and help you actually close the findings, than sell you a certificate and let you believe you are done.
Technologies we build it with
Chosen per problem, not per fashion. This is the stack we most often reach for on this work.
How we deliver
- 01
Discover
We map the system, the constraints and the business it serves, including the parts nobody documented.
Architecture brief
- 02
Architect
Decisions get made, written down and defended before a line of production code exists.
Decision records
- 03
Build
Short cycles against working software. You see progress in the product, not in a status deck.
Shipping increments
- 04
Operate
Monitoring, incident response and iteration. The system is alive, so the engagement is too.
Runbooks & SLOs
Want a straight answer on Penetration Testing?
A short call with a senior engineer, before you write a brief. If Penetration Testing is the wrong answer for your situation, we will say so and tell you what we think is right.
What changes
Exploitable risk, proven
Not a list of theoretical issues but a demonstrated account of what an attacker could actually do to you. The chains that turn minor findings into a real breach, shown safely rather than speculated about.
A clear order to fix in
Every finding rated by demonstrated impact and exploitability, so remediation effort goes to what an attacker would reach first, and you are not working down an undifferentiated scanner dump.
Confirmed, not assumed, fixes
A retest after remediation that proves the holes are actually closed and no new ones were opened, so you know you are fixed rather than merely believing it.
Industries we serve
Domain knowledge changes what gets built. A few of the sectors we know before the first meeting.
How pricing works
- A focused, single-surface test (for example one web application, one API, or an external network perimeter), scoped as a discrete engagement with a defined target and rules of engagement, priced by the size and complexity of that surface. This is the common starting point when a specific system needs testing for a launch or a requirement.
- A combined, multi-surface assessment where an application, its APIs and the cloud environment behind it are tested together so we can chain across them the way an attacker would, priced against the total scope. This costs more than a single surface but finds the cross-boundary chains that a set of isolated tests would each miss.
- A retest, included in scope where it is part of the original engagement and priced as a smaller follow-on where a previous test elsewhere needs its fixes confirmed, because verifying remediation is part of doing the job properly, not an afterthought.
- A recurring testing arrangement for organisations that need testing at a regular cadence or ahead of every significant change, priced per engagement, which we will always frame honestly against the cheaper continuous scanning of our security-testing service so you are paying for human depth where it is warranted and automation where it is enough.
Typical timeline
- 01
Scoping and rules of engagement
A short period, typically a few days of back-and-forth, to agree in writing exactly what is in and out of scope, the type of test, the testing window, how sensitive findings are handled, and the emergency contacts on both sides. Nothing technical begins until this is signed, because this authorisation is what makes the work legitimate and well-aimed.
- 02
Reconnaissance and vulnerability identification
Mapping the real attack surface. The hosts, endpoints, technologies and trust boundaries that actually exist rather than the ones on the diagram, and combining automated tooling for coverage with manual analysis for the logic and access-control flaws that tooling cannot reason its way to.
- 03
Exploitation and impact assessment
Safely and reversibly proving that findings are real, within scope, and establishing what each foothold actually reaches and whether it chains into something worse. The phase that turns a list of possibilities into a demonstrated account of what an attacker could genuinely do. Anything serious enough to warrant it is reported to you immediately, not held for report day.
- 04
Reporting, debrief and retest
Producing the prioritised report with risk ratings and remediation guidance, walking your team through it so it is understood and correctly sequenced, and (after you have fixed the findings), retesting to confirm the holes are closed and no new ones were opened. This last step is what turns the report into a resolved problem rather than a filed document.
What working with us actually means
Senior testers who exploit by hand
The people testing your systems are senior security engineers who chain and exploit manually, not a service that runs a scanner and reformats the output. That matters because the findings worth paying for (the logic flaws, the access-control failures, the chains that cross system boundaries), are precisely the ones automated tooling cannot reason its way to. You are paying for judgement and adversarial thinking, and that is what you get.
We operate what we build
Because we build and run production systems ourselves, we understand what we are attacking and, just as importantly, what it takes to fix it. Our remediation guidance is written by people who have had to implement fixes under real constraints, not by people who only ever write findings, so it is practical and specific to your stack rather than a generic recommendation you cannot act on.
Reports built to be acted on
We engineer the report as deliberately as the exploit: prioritised by demonstrated impact, reproducible by your engineers, understandable by your board, and followed by a debrief and a retest. A finding nobody can reproduce or nobody ranks correctly is wasted, so we make sure the output changes your security posture rather than just your filing system.
Honest about scope and limits
We will tell you plainly that a pen test is a point-in-time snapshot, that automated scanning is the cheaper tool for the common issues between tests, and that the value is entirely in the fixing rather than the certificate. That honesty is the whole point of hiring senior people: we would rather scope you the test you actually need and help you close its findings than sell you reassurance that does not survive contact with a real attacker.
How to engage us
Three ways to work with us on this, chosen to fit the problem, not our margin.
- Dedicated team A standing team that works only on your product, in your rituals and your tooling. Best when the roadmap outlives the project. Ongoing product development
- Staff augmentation Named senior engineers embedded into your existing team, reporting into your leads. Best when you know what to build and need capacity. Filling a capability gap
- Software outsourcing A defined outcome delivered end-to-end by an accountable team. Best when you want the result owned, not just the hours filled. Outcome-owned delivery
Related services
Part of Cybersecurity. Other work we do alongside this.
Common questions
Is this legal, and how do you make sure the testing stays authorised?
Yes. This is authorised, ethical, professional penetration testing, and authorisation is the foundation of the whole engagement rather than a formality. Nothing technical happens until we have your written permission and a signed scope with defined rules of engagement: exactly which systems are in bounds and which are explicitly out, when we may test, how we handle anything sensitive we find, and emergency contacts on both sides so testing can be paused or stopped instantly if needed. We only ever test systems you are entitled to authorise us to test, and we stay strictly within the agreed scope throughout. If any part of the target is owned or hosted by a third party, we make sure the necessary permissions are in place before it is touched. This is legitimate defensive security work, done with permission, and it never strays into anything unauthorised.
How is a penetration test different from an automated vulnerability scan?
A scan enumerates known, catalogued issues quickly and cheaply, and reports each one in isolation; it is a genuinely useful tool and it is the right way to catch the common problems continuously between tests. But it cannot reason. It will not chain three individually-minor findings into a full compromise, it will not understand your application’s business logic well enough to find the checkout that can skip payment or the request that lets one user read another’s data, and it hands you an undifferentiated wall of findings, false positives included, with no sense of which actually matter. A penetration test is a skilled human doing exactly the reasoning a scanner cannot: exploiting findings to prove they are real, chaining them into demonstrated impact, and ranking them by what an attacker would truly use. The two are complementary. The honest recommendation for most organisations is continuous automated scanning, which our security-testing service covers, plus periodic human penetration testing for the depth scanning cannot reach.
Does passing a penetration test mean we are secure?
No, and we will not let you believe otherwise. A penetration test is a point-in-time snapshot: it tells you what an attacker could do against your system, in its configuration, on the day we tested. The day after we finish, your code changes, a dependency ships a new vulnerability, a cloud setting gets adjusted, and your exposure is no longer exactly what the report described. Security is a continuous property, not a certificate you earn once and keep. A clean or well-remediated test tells you that you took your security seriously and closed the holes we found on that day, which is genuinely valuable and often exactly what a customer or regulator wants to see, but it is a checkpoint in an ongoing process, not a permanent state. That is precisely why we are blunt that the value is in the continuous work and the fixing, not in the certificate itself.
Will the testing disrupt our live systems or put our data at risk?
Minimising disruption is a first-class part of how we scope and run the work, not an afterthought. In the rules of engagement we agree a testing window that avoids your peak load, define which techniques are and are not permitted, and set clear stop conditions with contacts on both sides. When we exploit a finding, we do it carefully and reversibly to prove impact without causing harm: we demonstrate that we could reach data or take an action we should not, in a controlled way that does not damage data or take the service down. Certain higher-risk classes of test, such as anything that could affect availability, are only ever run with explicit agreement and often against a staging environment rather than production. The goal is to prove your exposure safely; deliberately breaking the system we were hired to assess would be a failure of the engagement, not a demonstration of its value.
What do we get at the end, and what happens after the report?
You get a prioritised report written for two audiences: an executive summary of what an attacker could actually achieve and what it would cost you, and technical detail for each finding, reproduction steps, the underlying cause, a risk rating based on demonstrated impact and real exploitability, and specific remediation guidance for your stack. We then walk your team through it in a debrief, answer questions, and help you sequence the fixes against your real constraints, separating what must be closed before you are safe from what is genuine improvement. Crucially, the engagement does not end at the document: once you have remediated the findings, we retest to confirm the fixes actually closed the holes and did not open new ones. That closed loop is deliberate, because the entire value of a penetration test is realised in the fixing: a report that is filed and never acted on has bought you nothing, and we would rather help you resolve the findings than hand over a PDF and walk away.
Thinking about Penetration Testing?
Tell us the problem in your own words, not in requirements. A senior engineer reads it and comes back with a straight view on whether Penetration Testing is the right answer here, or what would be.
- 01A senior engineer reads it. Not a form queue, and not an account manager.
- 02We reply either with questions or with a straight answer that we are not the right fit.
- 03If it looks like a fit, a technical call with the person who would actually run the delivery.
- 04Then scope, effort and risk in writing, before anyone signs anything.