Preparing for a penetration test: what to know before you start

1. Set the objective

Why are you running this test? The answer shapes everything else:

• before going live: check that a new application has no major flaw;
• a customer, regulator or insurer requirement: produce a recognised report;
• after an incident: understand how the attacker got in and make sure the door is closed;
• periodic review: measure your security level over time.

2. Define the scope

List precisely what will be tested, and what will not:

• web applications and APIs (URLs, environments, user roles);
• mobile applications (iOS, Android);
• IP addresses and services exposed to the Internet;
• internal network and directory (Active Directory);
• Wi-Fi, physical access, social engineering (simulated phishing), if relevant.

Anything not written into the scope must not be tested. Write down the exclusions too: it prevents misunderstandings.

3. Choose the approach

Black box

The tester has no information, like an external attacker. Realistic, but part of the time goes into reconnaissance.

Grey box

The tester receives user accounts and basic documentation. The best trade-off for most applications.

White box

The tester has access to code, architecture and configurations. Maximum coverage, ideal before a critical go-live.

4. Get written authorisation

A penetration test without authorisation is unauthorised access to a computer system, a criminal offence (in Morocco, Articles 607-3 et seq. of the Criminal Code, introduced by Law 07-03; in France, Article 323-1 of the Criminal Code). Before you start, you need:

• an authorisation letter signed by someone empowered to commit the company on the systems concerned;
• the agreement of the third parties hosting part of the scope: hosting provider, cloud provider, SaaS vendor. Each has its own policy; some require prior notice;
• the dates, times and source IP addresses of the tests, so your teams can recognise them.

5. Prepare the environment

• Production or staging? Staging limits the risk, provided it is identical to production.
• Verified backups just before the test, with a tested restore.
• Test accounts for each role (user, manager, administrator), without real data if possible.
• Time windows: avoid activity peaks and closing periods.
• Tell your monitoring team or not? Telling them avoids false alarms; not telling them also tests your detection capability. Decide in advance.

6. Organise contacts

• a technical contact available throughout the test;
• an emergency number on both sides, and an immediate stop procedure;
• a clear rule: any critical flaw found is reported immediately, without waiting for the report.

7. Require useful deliverables

A good report reads at two levels:

• an executive summary: overall risk level, major flaws, priorities;
• a technical section for each vulnerability: description, evidence, severity (for example on the CVSS scale), impact, remediation advice.

Ask for a debrief meeting and plan a retest from the start to check that each fix actually works.

How long does it take?

Depending on the scope, allow 5 to 15 days of testing, plus a few days for the report. A medium-sized web application tested as a grey box usually sits at the lower end of that range; a large internal network at the upper end.

The checklist at a glance

1. Test objective written down and shared.
2. Scope and exclusions listed.
3. Approach chosen (black, grey, white box).
4. Authorisation letter signed; third parties informed.
5. Environment, backups and test accounts ready.
6. Dates, times and source IPs communicated.
7. Contacts, emergency number and stop procedure defined.
8. Report format, debrief and retest planned.

FIDO TEAM performs penetration tests on applications, APIs, infrastructure and internal networks, and supports you through to the retest. Let’s discuss your scope.