How to Prepare for a Web Application Security Audit
Before a web application security audit starts, get written approval for the scope, check that test access works and agree the safety rules.
Preparation has four steps.
- Set the rules: get written permission, define the targets and testing limits, name emergency contacts, and agree on reports and retesting.
- Check assets and access: confirm the deployed apps and APIs, map the login and data flows, and test every account and role.
- Prepare materials and safeguards: share documentation, use synthetic data, protect credentials and evidence, and verify monitoring and recovery plans.
- Approve readiness: freeze the tested build, resolve access blockers and record approval before testing begins.
In this post, an audit means a hands-on security test of the application, as in a penetration test. It checks technical security at one point in time. It does not prove that you are secure, and it does not end in a compliance certificate. (sources: pentest vs security audit guide)
This post covers preparation. Our web application penetration testing page describes what we test and how an engagement runs. For the checks that the test accounts are used for, see API Security Testing: 7 Checks for Access Control Gaps and SaaS Penetration Testing: 8 Checks for Tenant Isolation.
Set the audit scope and testing rules
Define test targets and security goals
Ask the application owner, engineering lead, security contact and assessment team to approve one scope document, and treat it as the single source of truth. List the exact hostnames, URLs, API base paths, environments and build versions for every application and API in scope. State the objective of the audit and choose black-box, gray-box or white-box access. Gray-box testing gives the auditors accounts and documentation, which allows deeper access-control checks. (sources: preparation guide, rules of engagement guide, black-box, grey-box and white-box guide)
For a multi-tenant application, we suggest at least two accounts per role in at least two test tenants. One account cannot show that a user in one tenant can read another tenant’s data. (sources: preparation guide, black-box, grey-box and white-box guide)
Use staging when its configuration matches production. Test in production only with explicit approval, and only on records created for the test. (sources: preparation guide, external and internal testing guide, black-box, grey-box and white-box guide)
Record testing permissions and safety limits
Get signed authorization before testing. It should name the signer with their role and authority, the assessment company, the exact targets, and the start and end dates. Check cloud-provider and third-party testing policies separately, because the application owner’s permission does not automatically cover those systems. Put the permissions in a scope table. (sources: rules of engagement guide, methodology guide)
| Activity or target | Status | Required boundary |
|---|---|---|
| Approved staging application and APIs | In scope | Exact targets, environment and build |
| Production testing | Requires written approval | Approved test tenants and records only |
| Email or SMS sends, uploads, password guessing, paid API calls | Allowed only within written limits | Set count, size, attempt and call limits |
| Third-party systems and other customers’ tenants | Out of scope | No direct testing without separate authorization |
| Denial of service | Out of scope | Unless specifically scoped for load testing |
Record the test dates, hours, time zones and blackout windows. Name a primary emergency contact, a backup and an escalation owner who can halt testing. Agree to pause testing and notify the team if the testers see service degradation, suspected exposure of real customer data, a critical flaw that affects live users or signs of an earlier compromise. Decide how evidence is stored, who can access it, how long it is kept and how it is deleted before any sensitive material is collected. (sources: preparation guide, rules of engagement guide)
Assign owners and agree on reports and retesting
Have the engineering lead coordinate the audit and the fixes, DevOps or engineering provide access, and the security lead handle report storage and retest coordination. Agree on the report format, the recipients, how severity is handled and the retest terms. Critical findings go to the named contacts immediately. These owners should hand over the asset inventory and the test-access details before testing begins. (sources: preparation guide, rules of engagement guide, application security testing guide)
Inventory assets and set up test access
Once the scope is approved, check it against what is deployed.
Verify application and API assets
Auditors cannot test assets that the team has not identified. Compare DNS records, cloud assets and the application inventory with your documentation. Include admin interfaces, webhooks, identity providers, integrations and private services. For each asset, record the owner, environment, data sensitivity, hosting location and deployment version. (sources: preparation guide, rules of engagement guide, external and internal testing guide)
Compare OpenAPI files, GraphQL schemas and Postman collections with the routes found in client-side code and browser traffic. Check whether old /v1/ routes still work next to /v2/. Flag undocumented endpoints so that an owner can approve them for scope before the auditors test them. (sources: rules of engagement guide, OWASP API Top 10 guide)
Map architecture and identity flows
Give the auditors a diagram that connects browsers, front ends, APIs, services, databases, queues, storage and third parties. Mark the trust boundaries between public and private components and between tenants. A simple sketch works, as long as it matches the deployed system.
Add flow notes for login, SSO, OAuth and OpenID Connect, MFA, password recovery, invitations, token refresh, session expiry and logout. State what access users should have at each stage. (sources: preparation guide, external and internal testing guide, OWASP API Top 10 guide, application security testing guide)
Create test accounts for each role and tenant
Working test access avoids delays, false blockers and gaps in access-control testing. Create an access matrix that lists each account, role, tenant, permitted action and accessible record.
Fill the test tenants with synthetic records marked TEST_. Limit destructive tests to records that the auditors create. Sign in to each account yourself before the audit begins to confirm that it works. (sources: preparation guide, rules of engagement guide, external and internal testing guide, OWASP API Top 10 guide)
Share temporary credentials and MFA instructions through a secrets manager or an encrypted channel, not by email. If MFA is required, provide a test MFA seed, a bypass for test accounts or access to a mailbox that the auditor can reach. (sources: preparation guide, rules of engagement guide)
Prepare audit materials and safeguard testing
Gather documentation and known findings
Build one access-controlled audit package from the approved scope, the asset inventory and the access matrix for the test accounts. Tie it to the exact hostnames, URLs, environment and build version under test. Freeze changes during the test window so that the findings match that build. (sources: preparation guide, rules of engagement guide, ISO 27001 testing guide, pentest vs security audit guide)
| Deliverable | Purpose |
|---|---|
| Architecture diagrams and short flow notes | Show trust boundaries, main user flows and roles. |
| API descriptions: OpenAPI files, GraphQL schemas or Postman collections | Help testers map endpoints and send requests. |
| Test account register with account, role, tenant and access limits | Link approved access to credentials that are stored separately. |
| Known issues, previous pentest reports, bug reports and open vulnerabilities | Identify known findings before testing begins. |
| Remediation tracker with finding status, owners, tickets, fix dates, retest results and the reason for any accepted risk | Require retest evidence before a finding is marked fixed. Closing a ticket is not enough. |
Protect test data, credentials and evidence
Match the production authentication, authorization and logging settings where practical. If testing must happen in production, limit it to test-owned accounts and records. Use synthetic or properly sanitized data, and leave out personal, financial, health or login information that testing does not need. (sources: preparation guide, rules of engagement guide)
Keep secrets out of ordinary email and uncontrolled documents. Store evidence in encrypted storage, limit access to named reviewers, and redact sensitive details from screenshots and request and response captures before sharing them. (sources: preparation guide, rules of engagement guide)
Agree on a retention deadline and document the deletion of evidence and source archives. Revoke temporary credentials and tokens as soon as testing and any agreed retesting are complete. (sources: preparation guide, rules of engagement guide)
Check monitoring, backups and recovery plans
Before testing starts, make sure the monitoring and recovery teams can tell approved testing from a real attack. Share the tester identities, source IPs, test windows and escalation paths with internal security and any monitoring provider. State the time zones, keep protective controls active for the whole test window and check that failed-login, rate-limit and server-error alerts reach the right people. Preserve logs for investigation. For examples of requests, responses and logs kept as evidence, see our research notes. (sources: preparation guide, rules of engagement guide)
Verify recent backups, restore plans and rollback plans before active testing begins. The pause rules from the scope apply here too: stop on service degradation, unexpected access to customer data, signs of an earlier compromise or requests outside the approved scope. Preserve the relevant logs and notify the designated contact before testing resumes. (sources: preparation guide, rules of engagement guide)
Check readiness and approve testing
Test access and resolve blockers
Before the final go/no-go check, ask the system owner or a designated admin to sign in to every test account. Check that the prepared materials work in practice: verify each required role across the test tenants, test MFA, and confirm allowlisting and target access from the approved tester IPs. Make sure the API docs or collections load and match the build. Verify the synthetic test records and the deployment freeze. Fix any issue that could expose real data or stop testing. (sources: preparation guide, rules of engagement guide, external and internal testing guide)
Approve the readiness checklist
Review the checklist with the system owner, security lead, engineering lead and testing lead, and record the final approval. Replace the role labels with named owners and record a verification date for each item. (sources: preparation guide, rules of engagement guide)
| Category | Readiness check | Owner | Verification date |
|---|---|---|---|
| Scope | ☐ Objective documented; approved targets, exclusions, build and test window confirmed | Security lead | Add date |
| Permissions | ☐ Signed authorization and rules of engagement complete; provider policies checked | System owner | Add date |
| Access | ☐ All required accounts, roles and tenants sign in successfully; MFA works | Engineering lead | Add date |
| Data | ☐ Synthetic test records loaded; action limits and evidence rules confirmed | Security lead | Add date |
| Docs | ☐ API docs, diagrams and flow notes shared; known issues reviewed | Engineering lead | Add date |
| Recovery | ☐ Restore plan and change freeze verified; monitoring team notified | DevOps | Add date |
| Owners | ☐ Technical, backup and escalation contacts named; stop conditions documented | Security lead | Add date |
Start testing only after the blockers are resolved or the accountable owner records an explicit risk decision. (sources: preparation guide, rules of engagement guide, external and internal testing guide)
FAQs
How far in advance should we prepare for an audit?
Start as soon as you know the test window. Put the scope and rules of engagement in writing and book the tester early. Leave time to fix issues and complete a retest before the deadline that the report is for.
Before testing begins, finish the readiness checklist. Set up test accounts across roles and tenants, arrange MFA access and prepare safe test data. Freeze risky changes during the testing window.
Which known vulnerabilities should we fix before testing?
You do not need to fix every known bug before an audit. Document the known issues and share them with the auditor, who can skip them or check their status. Fix the cheap items first, such as a missing security header or a weak password policy. Otherwise each one takes up a line in the final report. (sources: preparation guide)
What if staging does not match production?
If the differences could hide security flaws, consider testing in production under stricter rules of engagement and with the system owner’s written approval. Use test-owned accounts and label the test records clearly. Set strict limits on email, file uploads and password guessing, and name a contact who can stop testing. Agree on the environment with your tester and write it into the scope of work. (sources: preparation guide, rules of engagement guide)