Penetration Testing Guide for Organizations: Types, Process and Reports

A penetration test is an authorized, simulated attack on your own systems, carried out by people you hire, to find weaknesses before a real attacker does. This guide is written for the people who commission and use pentests: IT managers, business owners and security leads. It covers the main types of test, what happens during one, how to prepare, what a good report looks like and what to do with the results. If you’re interested in doing the work yourself, our guide to ethical hacking covers the career side.

Pentest, vulnerability scan or red team?

• Vulnerability scan: automated tools check for known weaknesses such as missing patches. It’s cheap and quick, and you should run scans regularly. It doesn’t tell you how bad a combination of issues could be.
• Penetration test: skilled testers confirm which weaknesses are real and show what an attacker could reach through them, within an agreed scope and time window.
• Red team exercise: a longer, goal-driven engagement that tests whether your team can detect and respond to an attack, usually without telling the defenders in advance.

Most organizations start with scanning, add yearly or twice-yearly pentests, and consider red teaming once their detection and response is mature.

Types of penetration test

• External network: what an attacker on the internet can reach, such as VPNs, firewalls, mail servers and exposed services.
• Internal network: what an attacker could do after getting a foothold inside, for example through a phished laptop. This often reveals weak Active Directory configurations.
• Web application and API: authentication, access control, input handling and business logic. The OWASP Web Security Testing Guide is the usual reference.
• Cloud: identity and access settings, storage exposure and misconfigured services in AWS, Azure or Google Cloud.
• Wireless: whether office Wi-Fi is properly encrypted and separated from internal systems, and whether rogue access points could be used.
• Social engineering: phishing simulations, phone calls or physical entry attempts to see how staff respond.
• Mobile app: how the app stores data and talks to its back end.

Tests also vary by how much the testers know at the start. In a black-box test they get little or nothing. In a gray-box test they get some access, such as a normal user account. In a white-box test they get documentation, credentials or source code. Gray-box and white-box tests usually find more in the same number of days, because testers don’t spend time on discovery an attacker would get eventually.

What happens during a pentest

1. Scoping and paperwork. You agree on goals, systems in scope, exclusions, testing windows and emergency contacts, and sign an authorization letter. If systems are hosted by a third party, check their rules too; many cloud providers publish policies on what customers may test.
2. Discovery. Testers map what’s exposed and what technology you use.
3. Vulnerability analysis. They identify weaknesses using scanners and manual review.
4. Controlled exploitation. They confirm the most important issues are real and show the impact, without damaging systems or data, and stop to call you if they find something critical.
5. Reporting. You receive a written report and usually a walk-through meeting.
6. Retest. After you fix the issues, the testers check the fixes.

Recognized methodologies include NIST SP 800-115, the Penetration Testing Execution Standard (PTES), the OWASP testing guides and OSSTMM. Ask a provider which one they follow.

How to prepare

• Decide what you most want to learn. “Could someone on the internet reach customer data?” is a better goal than “test everything”.
• Back up the systems in scope and tell the people who run them when testing will happen.
• Tell your managed service providers and hosting company, so they don’t treat the test as a real attack, unless the point is to test them.
• Set up test accounts if it’s a gray-box test.
• Agree how critical findings will be reported during the test, rather than waiting for the final report.

Choosing a provider

• Ask for a sample report. It tells you more than any sales call.
• Ask who will do the testing and what experience they have. Certifications such as OSCP, GPEN and CREST qualifications are a useful signal, but not the only one.
• Check that they carry professional liability insurance and will sign a clear contract and NDA.
• Be wary of a “pentest” that is just an automated scan with a logo on it. A real test includes manual work and explains how findings were confirmed.

What a good report includes

• An executive summary that a non-technical manager can read in five minutes.
• Each finding with a risk rating (often using CVSS), affected systems, evidence and clear steps to fix it.
• Attack paths that show how several smaller issues combine into a serious one.
• Things that worked well. Knowing which controls held up is useful too.

After the test

Fix the critical and high-risk issues first, assign owners and deadlines for the rest, and schedule the retest. Look for patterns as well as individual bugs. If testers got in through an unpatched VPN, the real problem may be the patching process, not that one device. Feed the findings into your security controls and incident response plans.

How often to test

A common baseline is at least once a year and after significant changes, such as a new application, a major infrastructure move or a merger. PCI DSS requires penetration testing at least annually and after significant changes for organizations in its scope. Some industries and customers ask for more.

Frequently asked questions

Is penetration testing legal?

Yes, when the system owner has authorized it in writing and the testers stay within scope. Testing systems without permission is illegal in most countries.

Can a pentest break things?

It can, which is why scoping, testing windows and backups matter. Experienced testers avoid destructive techniques unless you’ve agreed to them.

Does a clean pentest mean we’re secure?

No. It means the testers didn’t find a way in during a limited time with a limited scope. Keep scanning, patching and monitoring between tests.

Mark Hill