Safeguard
Application Security•

Prepare Your App for a Pen Test: A One Week Checklist

Fix the obvious things before the tester arrives so the budget goes to hard problems. A short checklist drawn from ASVS 5.0 Level 1 and PCI SSC guidance.

Safeguard Security Team
3 min read

The ASVS 5.0.0 CSV we counted on 18 October 2026 lists 70 Level 1 requirements, and several of them are things you can verify in minutes: no source control metadata deployed (V13.4.1), no default accounts such as root, admin or sa (V6.3.2), and no password hints or secret questions (V6.4.2). A tester who spends the first day finding those has one less day for your business logic.

What's affected

Anyone with a test booked. The PCI Security Standards Council guidance notes that coordinating details in a pre-engagement step avoids scope mistakes that would force a retest, and that testers need documentation to understand how functionality should work.

What to do now

Work through this list in the week before the test starts:

  1. Check for exposed repository metadata.
curl -s -o /dev/null -w '%{http_code}\n' https://staging.example.com/.git/HEAD

Anything other than 404 or 403 needs fixing today.

  1. Search the code and history for secrets. Run a secrets scan across the repository and its history and rotate anything it finds.
  2. Remove default and test accounts that should not exist in the environment under test.
  3. Create the tester accounts: two tenants, each with an admin and a standard user, and a role for any staff or support access.
  4. Write the documentation pack: architecture diagram, API description, list of roles, and where sensitive data lives.
  5. Freeze deploys during the window, or tell the tester when releases happen. A changing target wastes billable time.
  6. Decide how monitoring should react. The PCI guidance asks whether controls that would detect or block testing should be disabled or tuned, and whether you want live updates on exploitation.
  7. Back up the environment under test and name an emergency contact who can restore it.

How to avoid this trap

  • Do not clean up so thoroughly that you hide real weaknesses. Fix known issues, but do not delete logs or alter detection to look better.
  • Do not test production first. A staging copy that mirrors it is safer, as long as controls match.
  • Do not leave credentials until the morning of day one.

Try it yourself

Run the first two checks on your repository and staging site today. Whatever they find is the cheapest finding you will ever fix.

Click through it at your own pace, or open it full screen.

Quick check

Why give the tester documentation and accounts?

It lets them test how the application is supposed to behave and reach authenticated functionality at once, so time goes to real flaws instead of discovery.

Sources

Never miss an update

Weekly insights on software supply chain security, delivered to your inbox.

Self-healing security runs on Safeguard.

Your first fix PR is minutes away.

No sales call required, even your agent can complete the purchase over MCP.