Vulnerability assessment and penetration testing guide
A penetration test of a website does not automatically cover the application your organization operates. A SaaS product may have a browser interface, mobile APIs, administrative tools, background jobs, and partner integrations. Application and security owners should define which components, identities, data flows, and business workflows the authorized engagement will examine with the assessor.
Start with the customer workflow
Describe what the application does with sensitive information: who submits it, who may see it, who can approve a change, and where it goes next. Turn that description into a coverage agreement. A file-sharing service, for example, needs more than a review of its sign-in screen. Its permission model, sharing lifecycle, administrative features, and exports may matter more to a customer than its public pages.
- Applications and interfaces: list the browser application, API versions, mobile back ends, administration consoles, and integrations included. Identify retired interfaces that still operate.
- Identities: specify anonymous users, ordinary users, customer administrators, support staff, and service identities where relevant.
- Tenant boundaries: state whether the review includes separation between customers as well as permissions within one customer account. Use authorized test tenants and synthetic data.
- Business workflows: identify sensitive actions such as approvals, account recovery, exports, payment changes, and invitations. Record excluded workflows and why.
Separate identity from permission
Authentication establishes who a user is. Authorization determines which records and actions that identity may access. A strong sign-in process does not answer whether a user can access only the right customer records or whether an ordinary user is restricted from administrative functions. OWASP’s API Security Top 10 distinguishes object-level, property-level, and function-level authorization risks. Ask for coverage that reflects the application’s actual role and data model rather than a generic claim of “OWASP testing.”
The OWASP Web Security Testing Guide provides a broader testing reference. Require the proposal to identify the version or methodology used, the relevant areas selected, and any areas excluded. Naming a guide is not evidence that every applicable area was assessed.
Ask for evidence of coverage, not just findings
Require the assessment record to identify the application release, dates, environment, test roles, and functions reviewed. For each important boundary, record whether it was evaluated through configuration or design review, authorized application testing, or both. Distinguish confirmed observations from unresolved concerns, and examined boundaries from those unavailable or excluded. This gives the application owner a coverage record even when a test produces no finding.
For a staging test, ask which production settings differ: identity integration, feature flags, third-party services, data permissions, and deployment configuration. If only one role was supplied, the report should not imply that all role boundaries were covered.
Assign fixes and verify their reach
The application owner should assign each confirmed issue to the team responsible for the underlying control. A permission defect in a shared service may affect multiple interfaces; closing the original ticket is not enough if the same control serves other workflows. Ask the remediation owner to identify the affected scope, the deployed change, and the evidence used to confirm it.
Retesting should name the original finding and the version reviewed. Distinguish “fixed and retested” from “a fix is planned,” “not observed again,” and “risk accepted.” Material changes to identity, APIs, customer separation, or business workflows should prompt a decision about additional assessment rather than waiting automatically for the next annual cycle.
Sources and scope of this guidance
The scope questions and examples above help system owners plan an assessment; they are not a claim that a particular law or assurance standard requires every activity. Match the engagement to your architecture, risks, obligations, and written authorization.