The organization authorizing the work, the exact targets and environments, the permitted activity, and any restrictions that protect people, data, and operations.
Before the review
Prepare for your security review.
Start with the system, your main concerns, and who owns it. This checklist helps us agree on the scope and arrange the access needed for useful testing.
Preparation checklist
Four areas to prepare.
This is a scoping aid, not a substitute for the engagement authorization. The final scope should record the targets, permitted methods, exclusions, contacts, and rules both sides accept.
01
Scope and ownership
- List the exact domains, applications, APIs, mobile builds, networks, cloud accounts, and environments in scope.
- Identify the business owner and technical owner for each target, plus a person who can resolve a scope question quickly.
- Call out exclusions, fragile systems, maintenance windows, and any asset that requires separate approval.
02
Roles and access
- Document the user roles and workflows that matter, including what each role should and should not be able to do.
- Provide agreed test accounts and a safe way to reset them. Do not share personal accounts or production credentials unnecessarily.
- Name the identity provider, test tenant, API authentication method, and any allowlisting process that affects access.
03
Environment and data
- Choose the approved environment and explain how it differs from production when that difference affects risk.
- Use representative, non-sensitive test data where possible. Flag records, integrations, and actions that could affect real people or systems.
- Confirm backup, recovery, monitoring, and rollback contacts before work begins on a sensitive environment.
04
Boundaries and communication
- Identify third-party services, shared infrastructure, and customer-controlled assets that require their own written permission.
- Set primary and backup contacts, an escalation channel, hours for urgent questions, and stop conditions.
- Agree on how high-impact behavior is handled: pause, preserve evidence, notify the owner, and resume only when authorized.
Report and retest
Know what the work can and cannot establish.
A security review samples a defined surface and time period. It cannot prove the absence of all vulnerabilities.
- 01
Agree on report recipients, the level of technical detail, and how sensitive evidence is handled.
- 02
Decide how confirmed urgent issues are communicated before the final report is delivered.
- 03
Define whether remediation review or retesting is included and what proof is needed to close a finding.
- 04
Record what was sampled. Do not treat a defined review as proof that nothing else exists.
Review scoping
Start with what you know.
Security testing
You don’t need every answer before getting in touch. Share your systems, main concern, and timeline, and I’ll help clarify the scope.