Penetration testing services: what you actually get

Penetration testing services put a skilled attacker on your side of the table. The goal is simple: find the ways into your systems before a real adversary does, then prove them so you can close them. The label covers several different kinds of work, and knowing which one you need is the first step to buying well.

The main types of penetration test

Most engagements fall into one of these categories. Many real projects combine a few.

• External network testing. We assess your internet-facing perimeter the way an outside attacker first sees you: exposed services, misconfigurations, and weak entry points.
• Internal network testing. Assume-breach testing from inside the network. We map how far an attacker moves once they have a foothold.
• Web and API testing. Deep testing of your applications across the OWASP scope, including the business-logic flaws tools miss. More in our web application penetration testing guide.
• Cloud testing. Configuration and identity review for AWS, Azure, and GCP, where most cloud breaches actually start. See application and cloud security.
• Mobile application testing. Client, API, and storage testing for iOS and Android apps.
• Social engineering. Phishing and pretext campaigns that measure how your people respond under realistic pressure.
• Red team operations. A goal-based, full-scope exercise that tests detection and response, not just prevention.

How a real engagement runs

A serious provider works in clear phases, and you know what is happening at each one.

• Scope and rules. We agree targets, exclusions, and rules of engagement up front, in writing.
• Recon and access. We map the attack surface and establish a foothold, using the same tooling and tradecraft real attackers use.
• Move and escalate. We pivot, escalate privilege, and pursue the agreed objective, flagging critical findings the moment we see them.
• Report and retest. You get a reproducible report with remediation guidance, then a free retest of the fixes.

What you get at the end

The deliverable is not a list of CVEs. It is a decision-ready picture of your risk.

• An executive summary that a non-technical board can act on.
• Technical findings with reproducible proof of concept.
• A risk-ranked remediation roadmap.
• An attack-path narrative with evidence.
• A free remediation retest within a defined window.

Point-in-time versus continuous testing

A point-in-time test is a snapshot: it tells you where you stand on the day. That is the right tool for a launch, an audit, or an annual baseline. But code ships every week, and a snapshot ages fast. Fast-moving teams pair the annual deep test with continuous or scheduled testing so new exposure is caught between the big engagements. We compare the models in PTaaS vs traditional pentest vs automated scanning.

When should you run a test?

• Before a major launch or release.
• After a significant architecture or infrastructure change.
• On a regular cadence, at least annually, for a baseline.
• When a framework like NIS2, DORA, or SOC 2 requires evidence of testing.
• After a security incident, to confirm the gap is closed and find what else is open.
• During due diligence, before an acquisition or a major contract.

What separates a good provider

The market is full of automated scans dressed up as penetration tests. The difference shows in three places: the work is led by senior engineers, the testing goes beyond what a tool can find, and the report proves real attack paths rather than listing theoretical issues.

A scanner tells you what is broken. A penetration test tells you how someone would use it against you.

If you want to see how we run engagements, start with our offensive security service, or book a scoping call with a senior engineer.