Penetration Testing: What to Expect
Penetration testing: what to expect.
A penetration test (pentest) is an authorised, simulated attack carried out by skilled people to find the weaknesses a real attacker would use, and to prove what they could reach. This guide explains the types of test, how an engagement runs, how to prepare, and what you should get at the end.
What a pentest is, and isn’t
| Vulnerability scan | Test de pénétration | Red team | |
|---|---|---|---|
| Done by | Mostly automated tools | Skilled testers, with tools | A small expert team |
| Goal | List known weaknesses | Find and prove exploitable weaknesses, and how they chain together | Reach a business objective without being detected |
| Coverage | Broad, shallow | Deep, within an agreed scope | Narrow, realistic attack path |
| Tests your detection? | Non | Sometimes | Yes, that is the point |
| Typical frequency | Monthly or quarterly | Yearly and after major change | When defences are mature |
Scanning tells you a door might be unlocked. A pentest walks through it, shows what is on the other side, and tells you which locks to fix first.
Types of test
- External network: what anyone on the internet can reach: firewalls, VPNs, mail, remote access and exposed services.
- Internal network: what an attacker can do once inside, for example from an infected laptop: Active Directory, file shares, legacy protocols, segmentation.
- Web application and API: login, access control, injection and business-logic flaws, usually following the OWASP Web Security Testing Guide.
- Wireless: Wi-Fi encryption, guest isolation and rogue access points.
- Cloud configuration: identities, storage permissions and exposed management interfaces.
- Social engineering: phishing simulations, phone pretexting and, by agreement, physical access.
Tests can also be black box (testers start with no information), grey box (a normal user account and basic network details) or white box (full documentation and access). Grey box usually gives the best value for the time spent.
When you need one
- At least yearly and after significant changes, such as a new network design, a major application release, a merger or a cloud migration.
- For PCI DSS: v4.0 Requirement 11.4 requires internal and external penetration testing at least every 12 months and after significant change, plus testing of any segmentation used to reduce scope at least every 12 months (every six months for service providers).
- Before a launch, after a security incident, or when customers, insurers or auditors ask for evidence.
How an engagement runs
- Scoping call: goals, systems, test type and any compliance needs.
- Rules of engagement and written authorisation: exact targets (IP ranges, URLs), dates and test windows, what is out of bounds, emergency contacts and how sensitive data will be handled. Never allow testing without this signed.
- Reconnaissance and discovery: mapping hosts, services, users and technologies.
- Vulnerability analysis: combining tools with manual checks to find likely weaknesses.
- Exploitation: safely proving which weaknesses are real and how far they lead, staying within the agreed rules.
- Reporting and debrief: a written report and a walkthrough with your team.
- Retest: confirming that fixes actually work.
Good testers follow a recognised methodology such as PTES, NIST SP 800-115 or the OWASP testing guides, and keep a log of every action so anything unexpected can be traced.
How to prepare
- Know what you own. An accurate list of sites, devices, IP ranges and applications makes scoping faster and stops forgotten systems being missed. This is exactly what Atlas MAG212 maps for us before and during a test.
- Name one contact on your side who can make decisions during the test.
- Check backups and confirm critical systems can be restored, just in case.
- Prepare test accounts for grey-box testing, with the same rights as normal staff.
- Decide who knows. Tell your IT provider or SOC, or keep it quiet to test detection, but agree this up front.
- Get third-party permission where needed: hosting, cloud and SaaS providers have their own testing policies.
- Avoid big changes during the test window so results stay meaningful.
What a good report contains
- Executive summary in plain language: overall risk, the most serious findings and what to do first.
- Scope and method: what was tested, when and how, including anything not tested.
- Résultats rated by severity, usually with CVSS (Critique Haut Moyen Faible), each with evidence, business impact, steps to reproduce and clear remediation advice. See Explication des systèmes CVE et CVSS.
- Attack paths showing how smaller issues chained into a serious compromise.
- What worked well, so you keep the controls that stopped the testers.
After the test
- Fix critical and high findings first, especially anything that leads to domain admin or customer data.
- Assign each finding an owner and a date, and track it to completion.
- Ask for a retest to confirm the fixes, then fold lessons into your hardening baseline.
Sources: PCI Security Standards Council, PCI DSS v4.0.1 Requirement 11.4; NIST SP 800-115, Technical Guide to Information Security Testing and Assessment; Penetration Testing Execution Standard (PTES); OWASP Web Security Testing Guide. Reviewed November 2026.
MAG212 CYBER offers network and cybersecurity consultation, penetration testing with MAG212 Atlas, and security seminars for organisations around the world.