Map services to dependencies
A public application, cloud workload and internal identity system may form one connected attack path. Scope those relationships deliberately, including third-party permissions, business rules and recovery dependencies.
List the business services first, then map the applications, identity systems, networks and providers that support them. Record which owner can authorise each component. A domain count alone cannot describe the permission boundaries or operational consequences.
Prepare roles and representative data
Supply dedicated identities with documented roles and known expected permissions. Use more than one tenant, customer or organisational unit where boundaries are part of the objective. Label canary objects so testers and owners can distinguish them from real records.
Choose the assessment areas
- Web application penetration testing: An authenticated user can be a more useful starting point than an anonymous scan. Test what each role may read, change, approve and export.
- API penetration testing: A hidden endpoint or a frontend restriction does not enforce an API permission. Customer, support and workload identities need separate policy checks.
- Network and Active Directory penetration testing: Network reachability becomes a business risk when it combines with usable credentials, delegation or administrative authority. The report should establish each transition.
- Cloud penetration testing: A workload token, deployment artefact or support role can bridge boundaries that look isolated in a network diagram. Evaluate the permissions actually issued.
- Mobile application penetration testing: Device controls and backend authorisation answer different questions. A secure-looking client cannot compensate for an API that trusts caller-supplied ownership.
- Penetration test retesting: A closed development ticket does not prove that the released service now enforces the intended boundary. Retest the original conditions and relevant variants.
Agree the test conditions
Use written authorisation, agreed environments, synthetic data and named stop authority. Define rate limits, excluded methods, cleanup and escalation before testing. Production activity and supplier systems require explicit permission.
- Named test sources, destinations and permitted interfaces.
- Approved time windows, rate limits and excluded methods.
- Third-party consent, control contacts and stop authority.
- Evidence handling, cleanup, reporting and retest responsibilities.
Keep changes visible
Record material releases, new routes and permission changes during the test. If an unexpected path reaches a system outside the authorised boundary, pause and resolve scope through the named decision maker. Record untested dependencies in the final coverage statement.
Prepare a brief before the scoping call
Describe the decision you need to make, the systems involved and the boundaries the test must examine. The brief turns that context into proposed workstreams and questions for the scoping call.
Use the free penetration testing brief builder to record objectives, assessment areas, constraints and NDA preferences. Review the proposed scope, then send it directly to Atlant Security through the contact form.
