Penetration test scoping checklist

For every test

• A signed proposal and rules of engagement: what’s in scope, what’s off limits, and when we can test
• Emergency contacts on your side, reachable while testing runs
• Testing windows and any blackout dates, such as release freezes
• Whether we test production or a staging copy that matches it
• Your deadline, if an auditor, customer, or insurer has set one
• Who should receive the report and the attestation letter
• An NDA, if you want one before sharing details (we’ll sign a mutual NDA or send ours)
• Confirmation that you own the systems in scope, or have the hosting or SaaS provider’s permission to test them

Penetration testing

Web application penetration testing

• The application URLs in scope, and any features or pages that are off limits
• Test accounts for each user role, two per role so we can test access between users
• A second tenant or organization account if the app is multi-tenant
• Which environment to test: production, or a staging copy that matches it
• Anything that needs care, such as payments, emails to real users, or rate limits

API penetration testing

• An OpenAPI spec, Postman collection, or GraphQL schema
• Base URLs for each environment in scope
• API keys or tokens for each role, and for a second tenant if you have one
• Endpoints that need care, such as payments, bulk actions, or rate-limited calls
• Any undocumented or legacy endpoints you know about

Network penetration testing

• External: the public IP addresses, ranges, and domains in scope
• Internal: the network ranges and Active Directory domains in scope
• How we’ll connect for internal testing: a small virtual appliance you deploy, or on-site
• Wireless: the sites and networks in scope, if any
• Systems that are fragile or off limits
• Who should know our source IP addresses, such as your IT team or managed IT provider

Cloud penetration testing

• The AWS account, Azure subscription, or Google Cloud project IDs in scope
• A read-only audit role we can use for the configuration review
• For assumed-breach testing: a workload or identity to start from
• Kubernetes clusters in scope, if any
• Regions, services, or accounts that are off limits

Mobile application penetration testing

• App builds for each platform: an IPA for iOS, and an APK or AAB for Android
• Test accounts for each user role
• The backend API hosts in scope
• A build with certificate pinning and root or jailbreak detection turned off, if you have one

AI and LLM penetration testing

• Access to the AI feature, with test accounts for each user role
• The system prompt and tool or function definitions, if you can share them
• What the model can reach: documents, databases, APIs, or other tools
• Any usage or cost limits we should stay within
• Which model providers and third-party AI services are involved

Adversary simulation

Red team and assumed-breach testing

• The objectives: the systems or data an attacker would most want to reach
• A small control group who knows the test is happening
• What’s off limits, including people, systems, and techniques
• Emergency contacts on both sides, named in the rules of engagement
• The dates the operation may run

Phishing and social engineering testing

• Which channels to test: email, phone, text message, or a mix
• The people or departments in scope, and anyone to exclude
• Who approves pretexts, usually leadership and HR
• A contact on your IT or email team to agree on sending domains and filtering
• Campaign dates and any blackout periods

Assessment and training

Secure code review and threat modeling

• Read-only repository access or a source snapshot
• The languages, frameworks, and components in scope
• Architecture notes or diagrams, even rough ones
• Time with the architects and engineers who know the system, if threat modeling is in scope
• The areas you’re most worried about, such as login, payments, or tenant isolation
• A developer contact for questions

Vulnerability assessments and scanning

• The IP ranges, hosts, and web applications to scan
• Credentials for authenticated scanning, wherever possible
• Scan windows that suit your operations
• Systems that are fragile or should be excluded
• Who should receive results

Security training and hands-on labs

• Who’s attending, and their experience level
• The topics or technologies to focus on
• Remote or on-site, and your preferred dates
• Group size, so we can prepare lab environments