Before a penetration test you need four things on paper: signed rules for the test, the consent of your hosting or cloud provider, the names of the people who will pick up the phone, and a list of material for the tester. The rest gets sorted out along the way. Section 230(1) of the Criminal Code punishes with up to 2 years in prison anyone who breaches a security measure and thereby gains unauthorised access to a computer system. For penetration tests that NÚKIB runs itself, Act No. 264/2025 Coll. says explicitly in § 42(5)(c) that it needs "the consent of the person affected by the testing". So a test starts with a signature, not with a scanner.
- A test starts with written rules that all parties sign (NIST SP 800-115).
- If your hosting contract requires consent, you need it before the test.
- One technical contact picks up the phone throughout the test.
- Fix what you already know through your usual procedure and give the tester the list of known problems.
This article covers preparation only. What the tester does once the test starts is described in the article on how a penetration test runs, and which type of test to choose in the article on black, grey and white box.
Write the rules of the test and have them signed
The US guide NIST SP 800-115 wants a written plan for every test, small or large, whoever runs it. The plan answers five questions: what is tested, who may carry out the test, what it looks like in practice, how sensitive data is handled and what happens in an incident. According to NIST the plan protects both sides: the firm from an accident and the tester from management not knowing what it approved. All parties sign it.
| Question | What to write into the rules |
|---|---|
| What is tested | IP addresses or their ranges, domains, websites. Separately, a list of what must not be tested (NIST gives a payroll database as an example). |
| Who tests | Names and contacts on both sides, including whoever handles incidents. |
| When | A time window. NIST notes that an operational system is sometimes better tested in the evening, not at peak hours. |
| What is forbidden | Write it so that no room for interpretation remains (NIST). Typically attacks on availability. |
| Data the tester will see | May the tester store it? Must the tester list the passwords it reached? (examples from the PCI SSC guide) |
| When to stop the test | When the tester stops, and what to do if it finds traces of a real intrusion. The PCI SSC guide advises starting incident response and pausing the test. |
| When it is done | The goal of the test. Without agreeing where the test ends, PCI SSC says the tester may overstep the limits you expected. |
NIST recommends always involving a lawyer in a penetration test. The lawyer goes through the plan and, where relevant, the non-disclosure agreement and who is liable for what. During a test the tester can capture data that is not yours, for example employees' personal data.
Find out who else has to agree
If some of your systems run at a third-party provider, your signature is not enough. NIST writes that the owner of that network usually has to confirm the plan in writing. The PCI SSC guide specifies it: when your contract with the provider requires its consent, you must have it before the test starts. The provider's own infrastructure is also out of scope, only systems you manage or use are in.
The rules differ for every provider. Amazon Web Services, for example, states on its page that for listed services (EC2, RDS, Lambda and others) a test needs no prior consent. But DoS and DDoS attacks are forbidden and tests with command and control require consent in advance. Simulated phishing and malware tests are reported through a form. This applies to AWS only. For another provider, look up the rules or ask.
What to hand the tester
The UK cyber security authority NCSC wants the preparation to produce a document with the testers' requirements, for example with accounts created for testers, or simply a desk. For a grey or white box test, prepare accounts with the rights of an ordinary user and an administrator. The PCI SSC guide also names material that saves the tester time: a network diagram, the flow of sensitive data, a list of services that should be visible from the internet and a description of how users sign in. Reports from earlier tests and fresh scan results help too.
Here two sources drift slightly apart, and both are right. The common advice is "fix nothing before the test". NCSC says the opposite: ideally you know what the tester will find before it finds it, because a penetration test is meant to check how you handle vulnerabilities in your systems, not replace that work. So the sensible approach is: fix what you already know through your usual change procedure and give the tester the list of known problems. Don't fix things in a hurry just before the start, and don't hide anything.
Production or a copy
NIST says openly that a system can be damaged during a penetration test and an experienced tester only reduces that risk. It cannot remove it entirely. The PCI SSC guide adds that a test on production during working hours can disrupt operations, and trying to avoid that can make the test longer and more complicated. The solution is a separate environment identical to production. Any vulnerabilities found must then be fixed on production and verified again.
This is our recommendation, not a quote: before the test, check that you can restore the backup, not just that one exists. Then even the worst case is manageable.
Who in the firm knows what
NIST distinguishes two ways. In an overt test IT knows about it and helps soften the impact. In a covert one only management knows, and sometimes an intermediary who checks that no response to the test is triggered. According to NIST the overt test is cheaper, less risky and more common. The covert one mainly tests how IT reacts.
Name one technical contact who will pick up the phone throughout the test. NCSC writes that this person does not have to spend all their time with the testers but must be reachable quickly. Decide about protective systems too: the PCI SSC guide advises that IPS and WAF should not block the test, because you are testing the services themselves, not whether a firewall stops the attack. If you also test physical access, the guards get a contact through which they can verify that the tester is the tester.
- Some systems run at a third-party provider?the contract requires its consentHave it before the test
- Want to test IT's reaction too?covert testOnly management knows
- Will the test run on production?the risk of damage cannot be ruled outVerify the backup restore
- All other casesIT and management know in advance
What a firm of twenty people does
There is one IT administrator and nobody on a security team. The sequence, by when each step comes up:
- After ordering: write down the scope and rules with the tester, check the contracts with your hosting and ask about consent.
- Before the start: create accounts for the tester, give it the diagrams and the list of known problems, verify the restore from backup.
- Right before the start: name a contact on both sides and tell the people in IT that the test will run and when.
- During the test: the contact picks up the phone. If the tester finds traces of a real attack, the test stops and you handle an incident.
- After the test: delete the accounts and tools the tester installed (PCI SSC wants the tester to report them). What happens to the findings next is described in the article on the retest.
Mistakes that keep repeating
- A test without a written scope. The tester then either tests what it shouldn't or nothing you expected.
- Nobody asks the hosting provider. The provider may require consent in its terms and forbid some attacks.
- Nobody picks up the phone. The tester runs into something serious and waits.
- A test on production and a backup nobody has tried to restore. The risk is small, but NIST does not rule it out.
- Nobody keeps a list of known problems. NCSC wants the firm to know before the test what the tester will find.
How much work the scope adds is covered in the article on the price of a penetration test.
Common questions
Do I have to tell employees about the test?
At least IT and management should know. NIST distinguishes an overt test that IT knows about and a covert one known only to management. The covert one makes sense when you want to test IT's reaction, and according to NIST it is more expensive.
Do I need the consent of my hosting or cloud provider?
If your contract with the provider requires it, yes, and you must have it before the test. According to NIST the owner of a third-party network usually has to confirm the plan in writing. AWS does not want prior consent for listed services, other providers have their own rules.
Should the test run on production or on a separate copy?
Both work. Production is more faithful, but NIST does not rule out the risk of damage. The separate environment must be identical to production and fixes still have to be made on production and verified again (PCI SSC).
What if a real intrusion is found during the test?
That belongs in the rules in advance. The PCI SSC guide advises writing that the tester stops the test in such a case and incident response starts. How to proceed from there is up to you.
Do I need a non-disclosure agreement?
NIST mentions it as a normal part: a lawyer may require external testers to sign an NDA and a liability limit. Agree it before they get access to your data.
Sources
- NIST Special Publication 800-115, Technical Guide to Information Security Testing and Assessment, September 2008, sections 2.4.2, 5.2, 6.5, 6.6 and Appendix B: https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-115.pdf
- PCI SSC, Information Supplement: Penetration Testing Guidance, version 1.1, September 2017, sections 2.3.4 and 4.1 to 4.3: https://listings.pcisecuritystandards.org/documents/Penetration-Testing-Guidance-v1_1.pdf
- NCSC, Penetration testing, published 8 August 2017, reviewed 10 January 2022: https://www.ncsc.gov.uk/guidance/penetration-testing
- Act No. 40/2009 Coll., Criminal Code, § 230: https://www.zakonyprolidi.cz/cs/2009-40
- Act No. 264/2025 Coll., § 42(5)(c), version effective from 1 November 2025: https://www.zakonyprolidi.cz/cs/2025-264
- Amazon Web Services, Penetration Testing, viewed 25 October 2026: https://aws.amazon.com/security/penetration-testing/
Retest after a penetration test: when it is mandatory and what it checks
Black box, grey box, white box: how to choose the type of penetration test
Web penetration test vs. internal network test: what is the difference and which one you need
