Penetration Testing That Shows What an Attacker Could Reach

A scan enumerates known weaknesses across many systems automatically and reports what appears to be exposed. A penetration test is a person attempting to exploit weaknesses and, more importantly, to chain several unremarkable ones together to reach something valuable. That chaining is the part automation cannot do. A scanner may report three medium-severity findings on three different systems; a tester may use those three to reach domain administrator and demonstrate access to your financial records. The first tells you what is theoretically exposed. The second tells you what would actually happen.

Ask what proportion of the engagement is manual, ask to see a redacted sample report, and ask how findings are validated. A genuine report describes the path the tester took, includes evidence of exploitation, and rates findings by demonstrated business impact rather than by tool-assigned severity. A rebadged scan reads as a formatted export: hundreds of findings, no narrative, no attack chain, and no explanation of what an attacker could ultimately reach. The price difference between the two is large, and so is the difference in what you learn.

It depends on the question you are trying to answer. Black box testing starts with no information and simulates an outsider's view, which feels realistic but spends much of a fixed engagement on reconnaissance an actual attacker would take months over. Gray box testing provides limited information, such as a standard user account, and usually produces the most findings per dollar. White box testing supplies full documentation and configuration access, and is the most thorough. For most organizations under a compliance or insurance driver, gray box is the sensible default. We will recommend against black box when it would mostly buy you an expensive reconnaissance exercise.

Sometimes, and sometimes not. It is worth resolving before you buy. Several frameworks, customer security reviews, and insurers expect testing to be performed by a party independent of the team that built and administers the environment, precisely because a tester is unlikely to find the assumptions they themselves made. Where your requirement calls for that independence, we will say so and help you engage an independent tester rather than sell you an engagement that will not satisfy the requirement. Where independence is not required, testing by the team that knows the environment can be more efficient.

There is always some risk, and any tester claiming otherwise is not being straight with you. Certain techniques can crash fragile services, and denial-of-service testing is normally excluded outright unless you specifically ask for it. Risk is managed through scope agreed in writing, testing windows, an emergency contact who can stop work immediately, and extra caution around industrial, medical, and legacy systems. For genuinely fragile environments, testing a representative staging system is sometimes the right call.

Annually is the common baseline, and many frameworks and insurers set that as the floor. Significant change is the better trigger: a new internet-facing application, a network redesign, a migration, or a merger all warrant testing regardless of when the last one ran. Retesting of remediated findings is a defined part of the engagement rather than a separate purchase, because a report on issues that were never verified as fixed is not evidence of anything.