What is a penetration test?

A penetration test is an authorized, simulated attack on a system, performed by people, to find out how an attacker could actually compromise it. The goal is not to produce a list of theoretical weaknesses but to demonstrate a realistic path to impact — and to explain how to close it.

What is the difference between a penetration test and a vulnerability scan?

A vulnerability scan is an automated tool that checks systems against a database of known issues and outputs a list. A penetration test uses human judgment to chain findings together, verify what is genuinely exploitable, and discard false positives. A scan tells you what might be wrong; a test tells you what an attacker could actually do.

How long does a penetration test take?

Timelines vary with scope, but a small, well-defined engagement is commonly measured in days to a couple of weeks of testing, plus time for reporting and a debrief. Be cautious of anything advertised as instant or fully automated — that is a scan being sold under a different name.

Does my cyber insurance require a penetration test?

It increasingly may. Insurers have tightened requirements and often ask specific questions about multi-factor authentication, backups, and security testing on applications or renewals. Read your policy and your application answers carefully, because a claim can be disputed if the controls you attested to were not actually in place.

How often should a business get a penetration test?

Annually is a common baseline, but the more useful trigger is change. Test after a significant release, a migration, a merger, or any architectural change to something internet-facing. A test describes a system at a moment in time, and that moment expires.

What should a penetration test report contain?

An executive summary a non-technical reader can act on, the scope and dates, each finding with clear reproduction steps and evidence, a realistic severity rating explained in business terms, and specific remediation guidance. A report that is only a tool export with the vendor's logo on it is not a penetration test report.

What a Penetration Test Actually Is

“Penetration test” is one of the most misused terms in this industry. Businesses buy something under that name and receive something else entirely — usually an automated scan with a cover page. Because I teach this material and do not sell testing services from this site, I can be blunt about the difference.

The short definition

A penetration test is an authorized simulated attack, performed by people, intended to demonstrate how a real attacker could compromise a system — and to explain what to do about it.

Three parts of that definition do the work. Authorized separates it from a crime. Performed by people separates it from a scan. Demonstrate separates it from a list of hypotheticals.

Why the human part matters

Automated tools are genuinely useful. They are fast, thorough about known issues, and cheap to run repeatedly. You should use them. But there are things they cannot do.

A scanner sees each weakness in isolation. A tester sees that a low-severity information leak on one page reveals a username format, which makes a password-spraying attempt viable against a login portal, which yields access to an account that can reach a file share holding customer records. Individually those findings might be rated low or medium. Chained, they are a breach.

That chaining is the product. It is also why testing resists full automation: it requires understanding what your business considers valuable, which no tool knows.

What you are actually buying

When you commission a test, you are buying a report and a conversation, not an activity. Judge providers on what you receive.

A serious report contains:

An executive summary written for someone who does not work in security, and who has to decide what to fund.
Explicit scope and dates. What was tested, what was excluded, and when. A finding is a statement about a moment in time.
Each finding with evidence and reproduction steps. Enough detail that your engineers can confirm it themselves.
Severity explained in business terms. “Critical” should mean something about your operations, not just a numeric score copied from a database.
Specific remediation guidance. Not “apply security best practices,” but what to change.
A debrief. A meeting where you can ask questions and your technical staff can push back.

If a proposal cannot describe its deliverable in these terms, that tells you what you need to know.

How to tell a real test from a scan in a sales conversation

A few questions surface the difference quickly, and none require technical expertise to ask:

“Who performs the testing, and what are their qualifications?” You should get names or at least roles and certifications, not a product description.

“Can I see a sanitized sample report?” Reputable providers have one ready. Look at whether the findings read as written by a person about your kind of system, or as tool output.

“How do you handle false positives?” A real answer describes manual verification. Silence or vagueness here is informative.

“What happens if you find nothing serious?” A good tester will tell you that this happens, that it is a legitimate result, and how they report it. Someone who promises to always find critical issues is telling you their findings are calibrated to justify the invoice.

“Is retesting included?” You will fix things. Confirming the fixes worked is part of the value.

Where testing sits in the order of operations

Penetration testing is not a first step. If you have not yet done the basics on the small business checklist — multi-factor authentication, tested backups, prompt patching — a test will simply produce an expensive document confirming that.

Testing earns its place once the fundamentals are handled and you need to know what remains. It is a way of checking your assumptions, not a way of acquiring security.

The insurance dimension

This is worth flagging because it has changed quickly. Cyber insurance applications and renewals now commonly ask detailed questions about specific controls, and in some cases about security testing.

Two things follow. First, read the questions carefully and answer them accurately — attesting to a control you do not actually have can create a real problem at claim time. Second, if your policy or your application references testing, find out precisely what is required before you buy anything, because “penetration test” in a policy document may mean something narrower or broader than what a vendor is proposing.

If it has already gone wrong

Testing is a preventive measure and is not useful in an emergency. If you are dealing with an active incident right now, the first 24 hours after a breach is the more relevant place to start.