ChecklistsFree

Penetration Test Preparation Checklist

Prepare for a pentest the right way: asset scoping, test accounts, testing windows, PICs, and legal aspects — so testing runs smoothly from day one.

In short

Preparation determines how deep a penetration test can reach within the agreed time. What needs to be ready before day one: a written scope and target list, test accounts for every role, an agreed testing window, rules of engagement, and escalation contacts in case of disruption.

Format
DOCX
Size
15 KB
Price
Free

Your data is handled in accordance with Indonesia's Personal Data Protection Law. We only send the document you requested and the occasional relevant GRC insight — no spam.

What This Document Is For

A pattern repeats in nearly every engagement: the first week goes not to testing but to waiting. Waiting for test accounts, waiting for the tester's IP to be allowlisted, waiting for a decision on whether one subdomain is in scope. That time does not come back — the schedule runs on, and testing depth is what shrinks.

This checklist gathers everything that must be decided and prepared before day one. Some items need a management decision, others a few hours of technical work. Doing them early moves time out of administration and into actual testing.

Most Useful For

  • Organisations undergoing a penetration test for the first time
  • IT teams preparing the environment before testers begin
  • Companies required to test periodically for OJK, Bank Indonesia, or ISO 27001

What's Inside

01

Scope & targets

The list of domains, IPs, applications, and user roles under test, plus what is explicitly excluded.

02

Rules of engagement

Permitted and prohibited techniques, denial-of-service testing limits, and handling of sensitive data discovered.

03

Test accounts

Credentials per role including privileged ones, and how to reset them if an account locks mid-test.

04

Testing window

Agreed testing hours and exclusions for business-critical periods.

05

Environment readiness

Tester IP allowlisting, WAF and rate limit adjustments, and the production-versus-staging decision.

06

Contacts & escalation

The communication path for critical findings or accidental disruption.

Standards & Regulations It Helps Satisfy

Standard / RegulationClause / ArticleWhat this document covers
ISO/IEC 27001:2022Control A.8.8Management of technical vulnerabilities, evidenced in part by periodic testing.
ISO/IEC 27001:2022Control A.8.29Security testing in development and acceptance.
POJK 11/2022 & SEOJK 29/2022Periodic testingThe cyber resilience and security testing obligation for commercial banks.

This document helps satisfy the requirements above, but does not by itself make an organisation compliant. Compliance is judged on practice in operation, not on documents held.

Questions About This Document

Test production or staging?

Ideally a staging environment that genuinely mirrors production. In practice staging often lags in version or lacks data, so findings do not represent real risk. When production is tested, the testing window and rules of engagement matter far more — and that is what this checklist prepares.

Should the WAF be disabled during testing?

It depends on the goal. To learn how the system holds up as an attacker sees it, leave the WAF on. To learn the application's actual vulnerabilities — the ones that remain if the WAF ever fails — the tester needs allowlisting. Many engagements run both in sequence.

How much preparation time is reasonable?

One to two weeks for an organisation that has never been tested, mainly because creating test accounts and adjusting allowlists usually involves more than one team. Organisations that test regularly typically need two to three days.

Related Reading

Background that helps you fill this document in correctly, rather than merely filling it in.

Need guidance, not just a template?

A template speeds up producing the document. What decides whether an audit passes is whether its contents genuinely reflect how your organisation works — and that is what we support.