NexusSec.Short version: Before a penetration test, agree a written scope, list the IP addresses, sites and applications in it, create test accounts, arrange access, confirm backups, choose testing windows, name a contact on each side, and agree how urgent findings will be reported. Preparation is what turns testing days into useful findings rather than time lost on access problems.
Most delays in a penetration test come from things that could have been sorted out the week before: a missing VPN account, an IP address nobody knew about, a firewall that blocks the tester halfway through. This checklist covers what to have ready.
Two weeks before
- Agree the scope in writing. What is in, what is out, and whether the test is internal, external or both. See internal vs external testing.
- List public IP addresses and domain names, and confirm you own or control each one. Testing an address that belongs to someone else is a problem for everyone.
- List applications with their addresses and the user roles to be tested.
- Check third-party permissions. Hosting and cloud providers publish rules for testing what you run on them. You cannot test a supplier's own platform without its permission.
- Decide who needs to know. Tell your IT team or IT provider, and any monitoring provider so a test is not handled as a real attack, unless you deliberately want to see whether they notice.
One week before
- Create test accounts for each role in scope, with test data rather than real customer records where possible.
- Arrange access for internal testing: a VPN account, a network port or an agreed remote-access route.
- Confirm backups of critical systems are current and that you could restore them.
- Agree testing windows and blackout dates, such as month-end close or payroll.
- Exchange contacts on both sides, including who can stop testing and how.
During the test
- Keep your contact reachable during testing hours.
- Avoid unplanned changes to systems in scope without telling the testers, because it makes results hard to read.
- Note anything unusual you see, and tell the testers.
- Keep your logs. Afterwards, checking whether your monitoring noticed the test is a useful result in itself.
Agree a rule for urgent findings
Decide in advance that a serious issue, such as a remotely exploitable flaw on an internet-facing system, is reported straight away rather than in the final report. Name the person who takes that call and can act on it.
After the test
- Hold the walkthrough call with the people who will fix things.
- Give every finding an owner and a date.
- Disable the test accounts and remove any access created for the test.
- Book the retest once the fixes are in, and keep the report and retest together. See what a good VAPT report should contain.
What not to do
- Do not quietly tidy things up just before the test so the report looks clean. You are paying to test the real environment.
- Do not hand over administrator accounts unless the scope needs them.
- Do not forget the clean-up. Test accounts left active are a finding in next year's test.
