What is a penetration test

A penetration test does three things at once. It checks how well a system stands up to the approach a real attacker would take. It documents the state of technical measures for someone outside the company, typically an auditor, a customer, or an insurer. And it gives developers and administrators a specific fix to make, not a general recommendation to improve security.

• Resilience check: the tester tries to follow the same path an attacker would and records how far they get.
• Documentation of measures: a report with a date, scope, and methodology holds up as evidence during an inspection.
• A brief for the fix: every finding has a description, an impact, and steps the developer can use to reproduce it.

The difference from a theoretical assessment is the evidence. Next to the claim that a weakness exists, the report shows the request, the server’s response, or a screenshot that proves the weakness can be exploited.

A penetration test is not a vulnerability scan. A scan is an automated check against a database of known flaws that a tool can run without a person; a test also looks for paths that only appear when several small issues are combined. We cover the difference between a penetration test and a vulnerability scan in detail on a separate page.

It isn’t a security audit either. An audit verifies compliance with rules and the existence of records; a test verifies whether the defenses hold. The two are often ordered together and the line between them blurs easily, which is why the difference from a security audit has its own entry.

• It’s not a bug bounty: a test has a scope, a date, and a price agreed in advance; a bug bounty pays per finding.
• It’s not a certification: a test produces no certificate, only a report on the state of the system on a specific day.
• It’s not a permanent guarantee: the result holds for the day of the test and the version of the system that was tested.

By subject, penetration tests split mainly into application tests and infrastructure tests. For applications, that means a test of one application including its API, which checks authorization between user roles and business logic. For infrastructure, a test of the network, perimeter, and domain environment, where configuration, privileges, and identity management decide the outcome.

Two more axes come into play, and they get confused with the subject: the tester’s starting position (outside or inside the network) and how much knowledge the tester starts with. The full typology, including categories rarely offered in the Czech Republic, is in the entry on types of penetration tests and when to choose which.

The open PTES standard describes the process and divides a test into seven phases. In short: agreeing on scope and rules, gathering information about the target, threat modeling, finding vulnerabilities, attempting exploitation, moving further into the system, and finally the report.

The scope agreement stands out from that list: it determines what may and may not be tested, and what to prepare on the client’s side, and no test starts without written authorization. One thing is missing from the phases entirely: re-verifying the fixes, known as a retest. The standard ends at the report, so a retest is a matter of contract, not methodology, and without it the report documents only half the job. The text of the standard is publicly available.

The standard describes what should happen, not how long it takes with a specific vendor. The detailed breakdown is in the entry on the seven PTES phases; the specific form, that is, what a test looks like from the signed scope to the retest, differs from team to team.

Either an internal team or an external vendor. An internal team knows the environment and is cheaper to coordinate, but it judges its own colleagues’ work and lacks distance. An external vendor has that distance and brings comparison from other companies, but needs time to understand the environment.

With a vendor, two questions are worth asking when you’re choosing who will run the test. Who will actually do the testing, because the name on the proposal and the name in the report need not be the same. And what hands-on certifications that person holds, meaning exams passed by attacking a lab environment, not by picking from multiple-choice answers.

A weak deliverable shows before anyone starts fixing. The most reliable sign is a scanner export renamed as a report: dozens of findings sorted by score, no evidence of exploitation, and no mention of what was tried and didn’t work.

• A finding has no reproduction steps, so the developer can’t trigger the bug.
• The report doesn’t state the scope or methodology, so there is no way to tell what wasn’t tested.
• Every finding carries the severity the tool assigned, and nobody has translated it into the company’s context.
• No retest is agreed, so nobody documents that the fixes work.