A penetration test is a controlled attack on your systems, run by people who break into things for a living, with your written permission and a defined scope. You get a clear answer to one question: can an attacker reach something that matters, and how. That is the core of our offensive security work. The deliverable is not a tool printout. It is evidence of what a motivated adversary can actually do, ranked by business impact, with the exact steps to fix it.
This matters because most teams confuse activity with assurance. They run a scanner, get 400 findings, patch the loud ones, and assume they are covered. A real test is different. We chain small weaknesses into a full compromise, the way an attacker would, and we tell you which doors are open and which are noise. For regulated companies under NIS2, DORA, ISO 27001, or SOC 2, that distinction is the difference between a defensible security program and a checkbox that fails under scrutiny. This post explains what a penetration testing service actually includes, what you receive, what it costs in effort, and how to tell a serious engagement from a weak one.
What a penetration test actually is
A penetration test simulates a real attack against a defined target within agreed rules. We work toward objectives you care about, such as reaching customer data, gaining domain admin, or moving from a low-privilege user to full control of a production environment. We do this manually, using the same techniques real intruders use, and we document every step so you can reproduce and verify it. The point is not to list every theoretical flaw. The point is to prove what an attacker can reach and what it would take to stop them.
It helps to separate a penetration test from the things people confuse it with. A vulnerability scan finds known issues by pattern matching. A penetration test exploits issues, chains them, and proves impact. We cover this distinction in depth in pentest vs scan and in PTaaS vs pentest vs automated scanning, because buyers get sold the wrong thing constantly. If a vendor hands you a raw scanner export and calls it a pentest, you did not get a pentest.
The main types of penetration testing
Penetration testing is not one service. The target and the threat model define the work. Most engagements fall into a handful of categories, and serious programs combine several over a year rather than buying one and assuming it covers everything.
- Web application testing examines authentication, authorization, business logic, and injection flaws in your apps, mapped against the OWASP Top 10, and we go deeper on this in our web application penetration testing guide.
- API testing targets the endpoints behind your apps and integrations, including broken object level authorization and excessive data exposure, which we break down using the OWASP API Security Top 10 in API security testing.
- Network testing, both external and internal, checks exposed services and what an attacker does after gaining a foothold inside, and we walk through the internal kill chain in network penetration testing.
- Cloud testing reviews identity, misconfiguration, and privilege escalation paths across your cloud accounts, where the quiet risk is almost always IAM, as we explain in cloud IAM quiet risk and the broader cloud security assessment.
- AI and LLM testing probes prompt injection, data leakage, and abuse of model-driven features, which is a fast-growing attack surface we cover in securing LLM apps and prompt injection in the real world.
Black box, grey box, and white box
The access we start with changes what the test finds and how efficient it is. The three common models trade realism against coverage. Most mature buyers choose grey box because it spends the budget on finding real problems instead of burning hours on reconnaissance an attacker would happily spend weeks on anyway.
- Black box gives us no internal information, which mirrors an external attacker but wastes time rediscovering things you already know and can simply tell us.
- Grey box gives us limited credentials and architecture detail, which produces the best ratio of realistic findings to budget for most applications and networks.
- White box gives us full source code, configurations, and design documents, which surfaces the deepest logic flaws and is the right choice for high-stakes or pre-launch systems.
- The right model depends on your threat model, your timeline, and what you actually need to prove to your board, your auditor, or your customers.
How an engagement runs, step by step
A good test follows a disciplined process. We do not just start attacking. The early stages prevent damage and make the findings useful, and the later stages turn raw access into something your engineers can act on. Here is how we run it.
- Scoping defines the targets, the rules of engagement, the test windows, the emergency contacts, and what is explicitly off limits, all in writing before anyone touches a system.
- Reconnaissance and mapping enumerate the real attack surface, which often surfaces forgotten assets, a problem we address continuously through external attack surface management.
- Exploitation and chaining take individual weaknesses and combine them, because the serious risk is rarely one bug, it is three small ones that lead to full compromise.
- Post-exploitation measures real impact, such as what data we could read or what privileges we could reach, so the report describes business consequences rather than abstract severity.
- Reporting, debrief, and retest deliver the findings, walk your team through them live, and verify your fixes actually closed the holes once you remediate.
What you actually receive
The deliverable is where many services fall short. A penetration test should leave you with documents and conversations that drive remediation, not a PDF that sits in a drive until the next audit. When we finish, you hold a complete record of what we found, how we found it, and what to do next.
- An executive summary that states the overall risk in plain language, written so a non-technical board member understands what is at stake and what to fund.
- A technical findings section with each issue, its severity, the affected assets, reproduction steps, and evidence such as screenshots or request and response pairs.
- Clear remediation guidance for every finding, prioritized by real business impact, so your engineers know what to fix first rather than chasing a wall of equal-looking tickets.
- An attack narrative that shows how individual findings chained into a full compromise, because that story is what convinces leadership and reveals systemic gaps.
- A live debrief with your engineers and a retest of fixed issues, plus an attestation letter you can share with auditors, customers, and partners as proof the work happened.
A scanner reports what is vulnerable. A penetration test establishes what an attacker can achieve with it, and that second answer is what should drive your remediation roadmap.
How a real pentest differs from a scan
This is the comparison that matters most because it is where money gets wasted. Automated scanning is useful and cheap, and you should run it continuously between tests. But scanning and penetration testing answer different questions, and treating one as the other creates a false sense of safety. We unpack this further in what is VAPT, since the two are often bundled and misunderstood.
- A scanner matches signatures against known issues and produces volume, including a high rate of false positives that someone still has to triage by hand.
- A penetration tester validates each issue, discards the noise, and proves exploitability, so every finding in the report is real and reachable.
- Scanners cannot understand business logic, so they miss the flaws that let one user read another user's data or skip a payment step.
- A tester chains findings across systems, which a scanner cannot do, and that chaining is usually how a breach actually happens.
- You want both, run scanning often and testing periodically, and never let a vendor sell you a scan dressed up as a manual assessment.
When to test and how often
Testing once a year and never again is a compliance habit, not a security one. The right cadence follows your change rate and your risk. Code that ships weekly needs more attention than a static internal tool. We help clients decide this during scoping rather than defaulting to an annual ritual.
- Test annually at minimum for any system in scope for an audit, since most frameworks expect a regular independent assessment.
- Test before launching a new application or a major feature, because finding a critical flaw in production is far more expensive than finding it before release.
- Test after significant architecture changes, such as a cloud migration or a new authentication system, where new attack paths appear.
- Test continuously through a service model when you ship frequently, which is the case for moving from point-in-time tests toward PTaaS.
- Pair periodic testing with ongoing detection, because a test is a snapshot and you still need eyes on production through managed detection and response.
Common red flags in penetration testing services
The market is full of vendors selling scans as tests and templates as reports. Knowing the warning signs protects your budget and your security posture. We wrote a full guide on this in how to choose a penetration testing company, but these are the issues that should make you walk away.
- The proposal promises a fixed number of findings, which means they are running a tool and counting outputs rather than testing your actual risk.
- The sample report is a scanner export with no attack narrative, no chaining, and no manual validation of severity.
- They refuse to do a live debrief or a retest, which suggests they are not confident the findings are real or remediable.
- They cannot explain their scoping logic and instead quote a flat price for any environment regardless of size or complexity.
- They use the engagement only to upsell their own product, because an honest tester's loyalty is to your security, not to a license renewal, a point we make in a SOC 2 report is not security.
What it costs in money and effort
Cost depends on scope, complexity, and the test model, not on a sticker price. A single web application costs far less than a full external, internal, and cloud assessment across a large estate. The honest answer is that price tracks tester days, and tester days track how much real surface you have. We break down the drivers in detail in penetration testing cost, but the effort on your side matters too.
- Your scope size drives most of the cost, since more applications, networks, and cloud accounts mean more days of skilled manual work.
- Your access model affects effort, because grey box and white box engagements use the budget on finding flaws rather than on reconnaissance.
- Your team spends real time on scoping, granting access, and being available during test windows, which good planning keeps to a few hours.
- Remediation is where the larger investment sits, so budget engineering capacity to fix what we find, not just the test fee.
- The cheapest quote is often the most expensive outcome, because a shallow test that misses a critical flaw costs you the breach it failed to prevent.
How testing ties to compliance frameworks
Penetration testing is named or strongly implied across the frameworks regulated companies live under. A test does not make you compliant on its own, but it produces the evidence auditors and regulators expect, and it surfaces the gaps that a documentation review never will. The relationship runs in both directions, since compliance scopes the test and the test validates the controls compliance requires.
- The NIS2 Directive, formally Directive (EU) 2022/2555, requires risk management measures and testing of their effectiveness, which we map to your environment in NIS2 explained.
- DORA, Regulation (EU) 2022/2554 and in force since January 2025, mandates digital operational resilience testing for financial entities, covered in our DORA work and the practical DORA compliance checklist.
- ISO/IEC 27001:2022, with its 93 Annex A controls across four themes, expects technical vulnerability management and verification, which a test directly supports under ISO 27001.
- SOC 2 Trust Services Criteria call for monitoring and evaluating controls, where a penetration test is strong evidence, though as we argue in SOC 2 is not security, the report alone proves little.
- MITRE ATT&CK gives us a shared language for the techniques we use, so your defenders can map our findings to detections and close the gaps in coverage.
If you want a penetration test that proves real risk rather than printing a scanner report, look at our offensive security service and the way we scope, test, and retest. We tell you what an attacker can reach, rank it by business impact, and stay with you until the holes are closed. When you are ready to define a scope that fits your environment and your compliance obligations, book a scoping call and we will work out exactly what you need to test and how often.