What matters first
- Inventory workflows and roles before choosing tools.
- Include authenticated and cross-account behavior in the agreed scope.
- Define a fix-verification plan before the report is delivered.
Establish the application boundary
List production and staging URLs, API hosts, mobile backends, administrative consoles, and third-party integrations. Record the owner of each system and which assets may be tested. A visually simple website can depend on several separately deployed services, so the domain list alone is rarely a complete scope.
Prepare representative test accounts with different roles and separate organizations where relevant. Use synthetic data that preserves realistic workflows. Agree the testing window, a contact for unexpected behavior, and limits for actions that could send messages, change balances, or disrupt availability.
References: [1] NIST
Review identity and data access
Walk through registration, sign-in, recovery, invitation, role changes, and logout. Then inspect the server-side authorization decisions behind reading, changing, exporting, and deleting data. Testing only whether a login page works leaves out what an authenticated user can do afterward.
For a SaaS product, build a small matrix of actors, objects, and actions. A customer owner may export their organization’s invoices; a support user may need restricted access; a different tenant should have none. Use that matrix to choose positive and negative tests, including background jobs and download links.
Follow inputs and release artifacts
Review how untrusted data reaches queries, templates, file processing, URL fetching, and connected services. Include configuration and dependency questions relevant to the deployed stack. The aim is to connect an entry point to a sensitive operation, rather than collecting warnings without confirming their context.
Inspect client bundles, source maps, public storage, error responses, and build outputs for unintended exposure. A client-visible value is not automatically a secret, and a missing header is not automatically a critical vulnerability. Classify findings using the actual data, capability, and deployment conditions involved.
Close the loop with verification
For every confirmed finding, record an affected component, a reproducible description using safe test data, an impact explanation, a proposed owner, and a verification criterion. Separate confirmed issues from questions that need more access or design context. This keeps the report useful when work is handed to another developer.
After fixes, repeat the relevant allowed and disallowed workflows. Include adjacent cases so a narrow patch does not leave another route exposed. Preserve a small regression test for the underlying boundary and document residual risks that were accepted or moved into a wider review.
Your next steps
- Create an asset and role inventory, including APIs and asynchronous jobs.
- Choose the highest-impact workflows and agree safe testing limits.
- Assign an owner and verification requirement to each confirmed issue.
- Book an audit call with the inventory and any existing reports.
Questions teams ask
Can this checklist replace a full penetration test?
It helps scope and organize a review. The depth, techniques, and coverage of a penetration test must be agreed separately for your application.
Should production be tested?
Choose the environment and limits during scoping. Staging with representative configuration and synthetic data is useful for checks that could affect behavior; some production configuration still needs separate review.
Sources and editorial notes
Public-source facts are cited above. The review questions and action plans are Cyphen’s guidance for applying those lessons to your own systems. Sources checked on .