Preparing for a penetration test

A penetration test pays a skilled team to attack your product, under agreed rules, and report what they found. Customers and auditors ask for one, and it’s one of the best ways to find problems your own team has stopped seeing. How much you get out of it depends largely on the preparation.

Decide what’s in scope

List exactly what the testers may attack: the web app, the mobile apps, the API, the admin tools, the cloud account. Name the environments and the domains. Anything left off the list won’t be tested, so include the parts customers care about, not only the parts you’re confident in. If a component is run by a vendor, check whether you’re allowed to include it.

Agree on the rules of engagement

Write down the test window, the addresses the testers will work from, what’s off limits (denial of service, social engineering, real customer data), and who to call if something breaks. Check your hosting provider’s policy on security testing and give notice if it asks for it. Tell whoever watches your alerts that a test is running, so a real incident isn’t dismissed as part of the test.

Prepare the environment and accounts

Testing a staging environment is usually safer, as long as it really matches production: the same code, configuration and security settings. Create test accounts for every role, including accounts in two separate customer organizations, so the testers can check whether one customer can see another’s data. In a product that serves many customers, that’s often the most important finding.

Share documentation, API specifications and credentials unless you specifically want an outside-in view. Testers who start with what an insider knows spend their time finding problems, not rediscovering the basics.

Fix by severity and by reach

The report will rank findings by severity. Fix the critical and high ones first, but also look at what each finding could reach: a medium issue on the login page may matter more than a high one on an internal tool. Keep a short note on each fix, because auditors and customers may ask how findings were handled.

Ask for a retest

Most testers include or offer a retest of the findings you’ve fixed. Use it. A retest confirms the fixes work and gives you an updated report that shows them closed, which is what customers want to see.

Share the right document

Customers rarely need the full report, which describes in detail how to attack your product. Ask the testers for a letter of attestation: a short summary of the scope, dates and results that you can share freely. Keep the full report on a need-to-know basis.

The short version

A clear scope, written rules, an environment that matches production, test accounts for every role and a retest after the fixes. Prepare those, and the report becomes a plan rather than a surprise.