Most web application assessments that go sideways do not go sideways because of a clever payload. They go sideways because nobody agreed on which hostnames were fair game, who to call when the site slows to a crawl, or what happens if a tester lands in a customer's account by accident. That conversation takes an hour. Cleaning up after skipping it can take weeks.

What follows is the checklist worth having signed, dated, and sitting in a shared folder before the first HTTP request leaves a tester's laptop.

Scope: Write Down What You Are Allowed to Touch

"The website" is not a scope. A scope is a list you could hand to a network engineer and a lawyer and have both agree on it. Start with the assets and be boringly specific.

• Root domains and each subdomain, including wildcards — and whether the wildcard is intentional.
• IP ranges, load balancers, and any origin server you are permitted to reach directly.
• API versions, GraphQL endpoints, and the mobile back-end services the app depends on.
• Authentication flows, including the identity provider if the client owns it and permits testing.
• Admin panels, staging copies, and leftover interfaces reachable from the internet.
• Environments: production, staging, development — named individually, not lumped together as "all".

Then write the out-of-scope list with equal care. Third-party SaaS integrations and anything owned by another company generally need that company's permission, not just your client's. Denial-of-service testing, social engineering, and physical entry are separate engagements unless explicitly included.

If the client cannot produce an up-to-date asset list, treat that as a finding before testing starts. Offer to run passive reconnaissance first and confirm the results together — it is cheaper than arguing about it afterward.

Rules of Engagement: The Operational Contract

Scope says what you may touch. Rules of engagement say how, when, and under what conditions you stop.

Testing windows

Agree on dates and times in a specific timezone, including blackout periods for releases and peak traffic. If the client's business day is the riskiest window, say so out loud rather than discovering it at 3 p.m. on a Tuesday. Decide in advance who can extend a window, and whether an email from the technical contact is enough.

Stop conditions and emergency contacts

Every engagement needs a kill switch that works in both directions. List named people — not a shared inbox — who can call a halt, with phone numbers and a fallback. Then agree on what triggers a stop:

1. Any sign of service degradation, elevated error rates, or a customer-facing outage.
2. Discovery of an active breach, or evidence that a third party is already inside the environment.
3. Exposure of real customer data during testing.
4. Unexpectedly reaching systems outside the agreed scope.
5. Client request, for any reason, with no justification required.

Testing intensity belongs here too. State rate limits, whether automated scanners may run, whether brute-force attempts against authentication are permitted, and how much data a tester may extract to prove impact. "Proof of concept, up to a handful of records" is a conversation worth having before it becomes a judgement call at midnight.

Written Authorization and Legal Boundaries

Verbal approval is worth very little when something breaks. Get a signed authorization letter or statement of work naming the testing organization, the client entity with authority over the assets, the specific in-scope systems, the testing window, and the person who signed it. Confirm that person actually holds that authority — a marketing manager cannot authorize testing on infrastructure owned by a parent company.

Testing without authorization can expose both sides to serious legal consequences, and the rules differ by country. Laws such as the Computer Fraud and Abuse Act in the United States and the Computer Misuse Act in the United Kingdom are commonly cited in this area, but the details matter and this is general guidance, not legal advice. Have counsel review authorization for cross-border engagements, and check the client's insurance and your own.

Data Handling, Credentials, and Evidence

Decide before testing how accounts and data are handled. Prefer dedicated test accounts over production credentials, and rotate anything shared for the engagement once it ends. If real user data is unavoidable, agree on minimization, encryption in transit and at rest, storage location, retention period, and a deletion date.

For evidence, confirm how screenshots and logs travel to the client — encrypted archive, shared workspace, or their own transfer tool — and what gets redacted. Findings should be reproducible without hoarding personal data. A record ID, a request and response pair with the payload, and a timestamp are almost always enough.

Common Gaps That Sink Engagements

• Scope defined by domain name only, with no IP or environment boundaries.
• An emergency contact who is on holiday for the entire test window.
• No agreement on how a critical finding is reported out-of-band, immediately, rather than in the final report.
• Ambiguity about whether the hosting provider permits the testing you plan to run.
• No retention or deletion clause for extracted data.

The Day Before Kickoff

Run through five questions with the technical contact: Is the signed authorization in the shared folder? Do both sides have the same dated in-scope list? Are the emergency numbers current and tested? Does the test account work and hold the privileges you expect? Does the client know roughly what happens on day one?

If all five are yes, the engagement starts on solid ground. If one is a no, that is not a reason to panic — it is a reason to spend twenty minutes fixing it now instead of explaining it later.

Photo: Thirdman / Pexels