Penetration test prep
A pentest is only worth its price if the scope is honest, the rules keep it
safe, and the findings actually get fixed and re-tested. The common failures
bracket the engagement: a vague scope that wastes days on the wrong assets, a
missing rules-of-engagement doc that turns a test into an outage, and a
report that lands in a drawer while the same holes stay open.
Method
- Define scope as concrete assets, not adjectives. List exact domains,
IP ranges, API base URLs, mobile builds, and account tiers in and out of
scope. "Our platform" invites the tester to guess; an explicit inventory
plus named exclusions (third-party SaaS you cannot authorize) keeps the
effort where it pays.
- Write rules of engagement before anyone connects. Agree on the test
window, permitted intensity, whether social engineering and
denial-of-service are allowed, a data-handling clause for anything
sensitive found, and an emergency stop contact. Get written authorization
from the asset owner: testing without it is a crime, not a test.
- Choose the access model deliberately. Decide black-box, gray-box, or
white-box, and provision test accounts at each privilege level, staging
credentials, and source or API docs accordingly. A gray-box test with real
accounts finds authorization flaws a pure black-box run never reaches.
- Test against staging that mirrors production, or plan for production
care. Point testers at an environment with production-like config and
seeded data, not live customer records. If production is in scope, agree on
rate limits and a rollback plan so a payload does not corrupt real data.
- Triage findings by real risk, not the report's raw severity. Re-rate
each issue against your exposure and data sensitivity, deduplicate, and
assign an owner and a due date proportional to severity. A "medium" on an
internet-facing auth endpoint outranks a "high" behind a VPN.
- Remediate, then demand a retest of each fix. Patch, and have the tester
or your team verify the specific finding is closed, since a fix that
addresses the symptom often leaves the class open. Track every item to
closed in the same tracker as normal work.
Litmus tests
- Could the tester list exactly which hosts and accounts are in scope from
your brief alone?
- Is there signed authorization and a named emergency-stop contact before the
window opens?
- Does each finding have an owner, a due date, and a retest, not just a
severity label?
- Are the fixes verified closed rather than marked done on assertion?
Boundaries
This covers commissioning and consuming a pentest, not performing one, and
not the continuous scanning and dependency work that should run between tests
(see dependency-auditing). A pentest is a point-in-time sample, not proof of
security: findings are a floor on your problems, never a ceiling.
1---2name: penetration-test-prep3description: Prepare for a penetration test by fixing scope, rules, and access up front, then turn its findings into tracked, verified remediation. Use when commissioning an external pentest or acting on the report one delivered.4---56# Penetration test prep78A pentest is only worth its price if the scope is honest, the rules keep it9safe, and the findings actually get fixed and re-tested. The common failures10bracket the engagement: a vague scope that wastes days on the wrong assets, a11missing rules-of-engagement doc that turns a test into an outage, and a12report that lands in a drawer while the same holes stay open.1314## Method15161. **Define scope as concrete assets, not adjectives.** List exact domains,17 IP ranges, API base URLs, mobile builds, and account tiers in and out of18 scope. "Our platform" invites the tester to guess; an explicit inventory19 plus named exclusions (third-party SaaS you cannot authorize) keeps the20 effort where it pays.212. **Write rules of engagement before anyone connects.** Agree on the test22 window, permitted intensity, whether social engineering and23 denial-of-service are allowed, a data-handling clause for anything24 sensitive found, and an emergency stop contact. Get written authorization25 from the asset owner: testing without it is a crime, not a test.263. **Choose the access model deliberately.** Decide black-box, gray-box, or27 white-box, and provision test accounts at each privilege level, staging28 credentials, and source or API docs accordingly. A gray-box test with real29 accounts finds authorization flaws a pure black-box run never reaches.304. **Test against staging that mirrors production, or plan for production31 care.** Point testers at an environment with production-like config and32 seeded data, not live customer records. If production is in scope, agree on33 rate limits and a rollback plan so a payload does not corrupt real data.345. **Triage findings by real risk, not the report's raw severity.** Re-rate35 each issue against your exposure and data sensitivity, deduplicate, and36 assign an owner and a due date proportional to severity. A "medium" on an37 internet-facing auth endpoint outranks a "high" behind a VPN.386. **Remediate, then demand a retest of each fix.** Patch, and have the tester39 or your team verify the specific finding is closed, since a fix that40 addresses the symptom often leaves the class open. Track every item to41 closed in the same tracker as normal work.4243## Litmus tests4445- Could the tester list exactly which hosts and accounts are in scope from46 your brief alone?47- Is there signed authorization and a named emergency-stop contact before the48 window opens?49- Does each finding have an owner, a due date, and a retest, not just a50 severity label?51- Are the fixes verified closed rather than marked done on assertion?5253## Boundaries5455This covers commissioning and consuming a pentest, not performing one, and56not the continuous scanning and dependency work that should run between tests57(see dependency-auditing). A pentest is a point-in-time sample, not proof of58security: findings are a floor on your problems, never a ceiling.
Amey-Thakur