What a penetration test actually is.
Strip away the jargon: a penetration test is a controlled, authorised attack on your own systems, carried out by security professionals, to find the ways a real attacker could get in before one does. Here’s how it works, end to end.
A real attacker — but on your side.
A penetration test (a “pen test”) is a security assessment where trained professionals probe your systems for weaknesses and try to exploit them the way a real attacker would: the same tools, the same techniques, the same creativity. The difference is that we have your permission and do no damage. At the end you get a clear account of the flaws that matter, what they would let an attacker do, and how to close them.
A scanner makes a list. A pen test tells you what it means.
It’s the most common mix-up. A vulnerability scan is automated software that flags possible weaknesses. It’s fast and useful, but it can’t tell which ones a real person could actually use, and it buries you in false positives.
- Automated software, run in minutes
- Flags known weaknesses one at a time
- Can’t chain issues or judge real impact
- Lots of “maybes” and false positives
- Skilled people applying real judgement
- Finds the weaknesses that can actually cause harm
- Proves the real impact, and how flaws combine
- Tells you what to fix first, and why
And scanning on its own is on the way out. The modern approach is continuous testing: automated, always-on validation that proves what’s actually exploitable, with expert testers on the parts that still need a human. It turns a once-a-year snapshot into always knowing where you stand.
Explore continuous testing with Incenter →It starts with what’s in, and what’s off-limits.
Before anyone touches anything, you and the testers agree the scope in writing: exactly which systems, applications, networks or accounts are fair game, and which are explicitly out of bounds. Everything that follows is built on it.
- In and out of scope The exact assets that will be tested (IP ranges, domains, applications, cloud accounts) and the ones that won’t. Named, and agreed in writing.
- Which environment Production, staging or UAT. Testing live is the most realistic; staging keeps any risk away from real customers. Your call, and it’s spelled out up front.
- Depth and goal A broad sweep across a surface, or a focused objective: “could someone reach the payments database?” The scope sets the ambition of the test.
- Authorisation Written permission to test the in-scope assets, and only those. No legitimate test runs without it. It’s what separates a pen test from an actual attack.
The ground rules, agreed up front.
A pen test is a controlled exercise, not a free-for-all. The rules of engagement set out exactly how it runs, so there are no surprises for either side.
- Timing and windows When testing happens, and any blackout periods (a peak sale, a month-end close) when it pauses so it never disrupts the business.
- What’s allowed And what isn’t. No denial-of-service, no destructive actions, and real customer data left untouched unless it’s explicitly agreed.
- Escalation If something critical is found, you hear about it immediately, not buried in the final report weeks later.
- Data handling How anything the testers access is stored, protected and securely destroyed once the engagement is done.
- Deconfliction Named contacts on both sides, so if your team spots the activity, they can confirm it’s the test and not scramble a real incident response.
Five phases, start to finish.
- 01
Planning & scoping
Objectives, scope and rules of engagement are agreed and signed off before anything starts, so the test hits what matters and nothing it shouldn’t.
- 02
Reconnaissance
The testers build the same picture a real attacker would: what you run, what’s exposed to the internet, and where the soft spots are likely to be.
- 03
Exploitation
They try to break in, by hand, proving which weaknesses are actually exploitable and chaining small ones together into serious access.
- 04
Post-exploitation
Once inside, they see how far it goes: what data, what systems, and what a real attacker would be able to walk away with.
- 05
Reporting & re-test
A clear report ranked by real risk, a walkthrough, hands-on help to fix it, and a free re-test of every issue to confirm the fix held.
Black box, grey box, white box.
The “box” just describes how much information the testers start with. More knowledge means deeper coverage; less means a more realistic outside attacker. The right choice depends on the question you’re answering.
Black box
Just your name, like a real outside attacker. It shows what someone with no inside knowledge could achieve from the internet.
Grey box
A login, some documentation. It mimics a malicious insider or a customer gone rogue, and lets us test more, faster.
White box
Full documentation, credentials, even source code. Nothing is hidden, so we find the deepest flaws, not just the reachable ones.
A report you can actually act on.
The output isn’t a tool dump or a wall of red. A good report is written to be used — by the board that needs the risk in plain terms, and the engineer who has to fix it.
- Executive summary The risk in business language, for the leaders who won’t read the technical detail but have to make the call.
- Every finding, ranked Ordered by real-world risk in your context, not a raw severity score in a vacuum.
- Reproduction steps Clear enough that your own team can see each issue for themselves, and trust it.
- Remediation guidance Concrete, prioritised fixes: what to do first, and why it matters most.
- Proof of impact Evidence of exactly what was achieved, so nothing is asserted and hand-waved.
Plus a walkthrough of the findings, hands-on remediation support, and a free re-test of every issue to confirm the fix actually held.
Anything an attacker would touch.
A pen test can be aimed at one thing or your whole estate: networks, web apps and APIs, cloud, mobile apps, connected (IoT) devices, industrial (OT) systems, and the AI you’ve shipped. Each has its own challenges and its own way in. See exactly what we look for on each.
See what we test →Methodology, not guesswork.
Good testing follows established methodologies, so it’s thorough and repeatable, not dependent on one tester remembering everything.
- OWASP The Top 10 lists for web, APIs, mobile and LLMs: the canonical reference for application-layer flaws.
- PTES The Penetration Testing Execution Standard, an end-to-end methodology for how an engagement should be run.
- NIST SP 800-115 The US standard for technical security testing and assessment.
- OSSTMM A peer-reviewed methodology built for repeatable, measurable testing.