External network testing, web application security, internal network assessment, and social engineering — scoped to your environment, conducted with real attacker methodology, and reported in a way your team can act on.
The market for penetration testing is large, and a significant portion of it exists to satisfy an audit requirement rather than to find real vulnerabilities. A test scoped narrowly to meet a framework requirement, conducted against a limited target list, and delivered as a PDF that nobody reads until the next audit cycle is not a security activity — it is a documentation activity. It produces a report. It does not reduce risk.
The difference between a compliance-driven test and an adversarial test is not just scope — it is the methodology. A real penetration test is conducted by someone who approaches the engagement the way an attacker approaches a target: starting from what is visible externally, identifying what is interesting, and determining what can be chained together to reach something that matters. The goal is not to find a list of CVEs. It is to find a path.
The most important findings in a penetration test are almost never the ones that come from automated tools. They come from understanding how systems are connected, how trust is delegated, and how the exceptions and legacy configurations that exist in every real environment can be leveraged. Those findings do not appear in a vulnerability scan. They appear when someone with attacker methodology has access to the environment and the time to use it.
An internal web server running an outdated framework. An overpermissioned service account. An unrestricted internal DNS zone transfer. The scanner had flagged all three — low severity, no known public exploit, no direct path to sensitive data. During the test, the three were chained together. Domain administrator access in under two hours. The scanner found the components. It could not find what they meant together.
The authentication flow was approved. Rate limiting was specified. The session management design was sound. During the test, rate limiting was found to be applied at the load balancer but not at the origin — bypassed with a single header change. Session tokens were generated correctly but not invalidated on logout. The review assessed the design. Nobody had tested whether the design was what was actually deployed.
The perimeter was hardened. The assumption was that an attacker reaching the internal network would be contained by segment boundaries. The test started from a simulated compromised workstation on the standard employee VLAN. Kerberoastable service accounts. Misconfigured WSUS. A legacy server excluded from the hardening policy because it was "scheduled for decommission" — for fourteen months. Domain administrator access in 38 minutes.
The output of a vulnerability scanner is a list of known issues, ranked by CVSS score, with remediation recommendations drawn from the same database the scanner uses. It is valuable. It is not a penetration test. A penetration test uses the scanner output as a starting point and then asks the question a scanner cannot: given what exists here, what can an attacker actually do?
Not every engagement requires all four tracks. The scope is defined before the test begins, based on what you are trying to protect, what you are required to test, and what your threat model actually looks like.
Testing your internet-facing attack surface from the perspective of an external attacker — no prior knowledge, no internal access, starting from what is publicly visible. The goal is to determine whether an attacker on the internet can gain a foothold in your environment.
Manual testing of web applications and APIs against real-world attack techniques — not just automated scanning. The focus is on authentication, authorisation, business logic, and the application-specific behaviours that automated tools cannot test.
Testing your internal environment from the perspective of an attacker who has already obtained a foothold — through phishing, a compromised endpoint, or a rogue insider. The goal is to determine how far an attacker can move, what they can reach, and whether they can achieve a meaningful objective.
Testing the human layer — the employees, the processes, and the behaviours that technical controls cannot fully address. Social engineering testing is scoped carefully and conducted with clear rules of engagement to ensure findings are actionable and the process does not cause operational harm.
The test begins with a scoping conversation that defines exactly what is in scope, what is not, and what success looks like. It ends with a report that is useful to both the engineers fixing the findings and the leadership making decisions about risk.
Scope definition covers target systems, testing methodology, out-of-scope systems and actions, emergency contacts, and the handling of critical findings discovered during the test. A penetration test without clear rules of engagement is a liability for both sides. The scoping document is the contract that defines what the test is — and what it is not — before anyone touches a system.
Week 1Passive and active enumeration of the target environment — identifying exposed services, technologies, employee information, domain structure, and anything else that informs the attack approach. The reconnaissance phase determines what is worth attacking. A test that skips this step and jumps straight to exploitation is a scan with extra steps — not an adversarial test.
Weeks 1–2Manual exploitation of identified vulnerabilities, with a focus on chaining — understanding how individual weaknesses combine into meaningful access. Each finding is documented with reproduction steps, evidence, and an assessment of real-world exploitability. The goal is not maximum coverage. It is to find the highest-impact path an attacker would actually take.
Weeks 2–3Where access has been obtained, post-exploitation determines what an attacker would do next — lateral movement, privilege escalation, data access, persistence mechanisms. This phase answers the question that executive stakeholders actually care about: if someone got in, what could they reach and what would it cost the business?
Week 3Two outputs: a technical findings report for the engineers fixing the issues, and an executive summary for the leadership making decisions about risk. Each finding includes severity, reproduction steps, evidence, and remediation guidance that is specific to your environment — not a copy-paste from a database. A penetration test report that sits in a compliance folder until the next audit cycle is not a security outcome. A remediated environment is.
Week 4The organisations that benefit most from a penetration test are not necessarily the ones with the weakest security — they are the ones who have invested in controls they have never validated, or who need to demonstrate to a third party that they have.
These frameworks require evidence of penetration testing — not just vulnerability scanning. Auditors are increasingly specific about methodology, scope, and recency. A test conducted by a credible tester, scoped to cover the relevant systems, and documented properly satisfies the requirement and produces findings that improve the actual security posture.
A cloud migration, an acquisition, a major product release, or a significant architectural change introduces new attack surface. Controls that were valid for the previous architecture may not apply cleanly to the new one. Testing after change — not just annually — ensures that the new environment is tested under conditions that reflect what it actually looks like.
Vulnerability scanning is a necessary baseline, not a substitute for adversarial testing. A scan finds known issues in known configurations. A penetration test finds what an attacker would find — including the combinations, the logic flaws, and the trust assumptions that no scanner is designed to identify. If the most recent external test of your environment was a scan, the environment has not been tested.
The question a penetration test answers is not just whether you can be breached — it is whether you would know. A test conducted with detection monitoring active reveals which attacker behaviours your tooling catches and which it misses entirely. For companies with a SIEM, an EDR, or a managed security service, this is often the most valuable output of the engagement.
The engagement ends with deliverables that support both the engineers fixing the findings and the leadership communicating about risk — and a retest that confirms the remediation was effective.
Every finding documented with severity rating, affected systems, reproduction steps, evidence, and CVSS score. Written for the engineer fixing it — not for the auditor filing it. Remediation guidance is specific to your environment and your technology stack, not drawn from a generic database.
A board-ready summary that translates technical findings into business risk. What an attacker could reach. What the realistic impact would be. What the prioritised remediation looks like. Written for the person making decisions about risk — not the person who understands what a CVSS score means.
Findings prioritised by real-world exploitability and business impact — not just by CVSS score. Remediation guidance that is actionable: what to change, how to change it, and what the residual risk looks like after the fix. Including guidance on the finding chains that represent the highest-impact paths, not just the highest-severity individual findings.
A targeted retest of the remediated findings to confirm that the fixes were effective and did not introduce new issues. A penetration test without a validation retest is a list of findings — the retest is what turns findings into a measurably improved security posture. Included for critical and high findings as standard.
When your auditor asks for evidence of penetration testing, the report exists, it is current, and it covers the scope they require. When your next customer security questionnaire asks whether you conduct regular penetration tests, the answer is yes — with a date, a methodology, and a retest confirming remediation. When your engineers fix the findings, they know the fixes worked. The test was not a documentation exercise. It was a security exercise.