Scope an external penetration test from architecture and trust boundaries, not from a flat list of URLs. The objective is to cover the paths through which identities, data and privileged actions move across web applications, APIs, mobile clients and shared services. This avoids two common failures: testing every component with equal superficial depth, or testing only public screens while the material attack paths cross internal services and authorization boundaries.
A CTO should be able to trace every in-scope activity to a risk hypothesis. Start with high-value assets and prohibited outcomes, map the identities and data flows that can reach them, then select representative surfaces and workflows. Record exclusions and residual uncertainty so a focused scope is not mistaken for complete architecture assurance.
Begin with the decisions the test must support
Clarify whether the engagement supports a product launch, enterprise assurance, architectural change, annual risk review or a specific customer requirement. Define what leadership needs to know: whether tenant separation holds, whether administrative paths can be abused, whether mobile clients expose backend capabilities, or whether shared services create a route across products.
This decision sets the depth. A customer evidence request may need a defined product boundary and closure artifact. A major platform redesign may require deeper testing of identity, service authorization and data flows even when fewer public features are selected.
Map the system as attack paths
- Identify valuable data, privileged actions and availability dependencies.
- Map human identities, machine identities, roles, tenants and support access.
- Trace entry points through clients, gateways, APIs, queues and shared services.
- Mark every trust transition where identity, authorization or data ownership changes.
- Identify controls that are shared across many products and therefore create concentrated risk.
A simple diagram is sufficient when it shows the relationships. It need not document every implementation detail. The vendor should use it to generate hypotheses: can a low-privilege web identity invoke a mobile-only API, can one tenant reference another tenant’s object, can a service credential reach an administrative function, or can asynchronous processing bypass a synchronous policy check?
Scope each client and its backend correctly
Web application
Include browser-visible workflows, server-side APIs, session handling, authorization and business logic. Do not let the UI route list define the backend scope; modern clients often call endpoints that are not obvious from navigation.
Mobile applications
Separate client-resident risk from backend risk. Assess local storage, platform interaction, transport assumptions, deep links and tamper resistance where relevant, while treating the backend API as an independent authorization surface. Android and iOS may share APIs but have platform-specific behaviours.
Public and partner APIs
Include authentication modes, scopes, object ownership, rate controls, bulk actions, webhooks and integration-specific permissions. Partner APIs may operate with broader privileges than consumer clients and deserve explicit identities and datasets.
Shared and internal services
Identify services whose compromise affects several products: identity, file processing, reporting, notification, search, administration or data export. Select representative service-to-service paths and machine identities rather than declaring everything behind the gateway out of scope.
Use a role-and-tenant coverage matrix
List the meaningful identity pairs and actions. For multi-tenant systems, include same-role cross-tenant checks, privileged cross-tenant support access, membership changes and object transfers. For hierarchical organizations, include parent-child boundaries and delegated administration. The matrix makes authorization coverage measurable without pretending every possible combination receives equal effort.
Prioritize combinations with high impact, weak isolation assumptions, recent change or broad data reach. Sample lower-risk repetitive paths and state that sampling in the report.
Select depth by risk tier
- Tier 1: high-value assets, privileged workflows, tenant isolation and identity control—deep manual testing and chaining.
- Tier 2: important supporting workflows and representative integrations—manual validation plus targeted automation.
- Tier 3: low-impact or repetitive surfaces—discovery, baseline checks and sampled validation.
- Excluded: third-party or unsupported systems—document the dependency and resulting uncertainty.
This approach is more defensible than testing all endpoints shallowly or excluding large areas without analysis. It also makes change control clearer when new assets appear.
Choose test positions intentionally
An external position shows what an internet attacker can reach. An authenticated customer position exposes role and tenant risk. A privileged or support position tests vertical escalation and administrative misuse. An internal or service position may be needed for machine identities and private APIs. Each position should have a purpose, accounts and rules of engagement.
Do not grant maximum access merely to save time. Test the boundaries that exist in reality, then add privileged access when it answers a separate hypothesis.
Connect methodology to the architecture
The OWASP Web Security Testing Guide supplies a broad testing framework, and NIST SP 800-115 provides planning and rules-of-engagement guidance. Use these references to support a product-specific test design; neither replaces the architecture map or business-risk priorities.
- Discovery should reconcile documented assets with client traffic and observed interfaces.
- Automated checks should broaden coverage and identify leads.
- Manual testing should examine authorization, workflow, state, chaining and business impact.
- Validation and peer review should convert observations into defensible findings.
Define completion before testing starts
Require a final record of tested assets, identities, workflows, test positions, sampling, blocked areas and exclusions. The report should distinguish absence of findings from absence of coverage. It should also identify architecture-level observations that may not be single exploitable bugs but materially affect future risk.
Questions for the scoping workshop
- Which trust boundaries protect the most valuable data and actions?
- Which controls are shared across web, mobile and API clients?
- Where do human and machine identities change privilege?
- Which recent changes could invalidate old security assumptions?
- Which third-party dependencies limit authorized testing?
- What evidence would change a launch or architecture decision?
The practical decision
Approve a scope that traces material attack paths across clients and services, assigns depth by risk, and leaves a transparent coverage record. You do not need to test everything equally. You need to know why each critical boundary was tested, how it was tested and what remains uncertain.
Discuss an architecture-led VAPT scope with WIMD using your trust-boundary diagram, role matrix and critical workflows.