Pen Test Test Accounts and Synthetic Data: A Setup Plan

NIST SP 800-53 Rev. 5 control SA-3(2) says organizations should "approve, document, and control the use of live data in preproduction environments" and protect those environments at the same level as the live data inside them. Its guidance adds that organizations can reduce the risk by using test or dummy data. A penetration test is the moment most small teams get this wrong, because a staging copy of production is the fastest way to give a tester something realistic.

What's affected

Any test where you give the vendor logins: web apps, APIs, mobile apps. The accounts and data you provide decide how much of the product the tester can actually reach.

What to do now

1. Create two accounts per role. For each role (admin, member, read-only), make two users in two separate tenants. The tester needs the second tenant to check whether tenant A can reach tenant B's records, which is the classic broken object level authorization case.
2. Add one account with no privileges. A freshly registered user with no invitations catches endpoints that forget to check roles.
3. Seed synthetic data in every tenant. Use obviously fake names, an email domain you control, and records the tester can recognize as belonging to a given tenant. Put a different marker string in each tenant's records so a leak is easy to spot in a response.
4. Do not copy production data. If you must use real data, document the approval and protect staging at production strength, as SA-3(2) describes. For most startups the simpler answer is synthetic data only.
5. Give credentials through a secrets channel. Send them via a password manager share or an encrypted channel, never a ticket comment. Set expiry for the day after the test window closes.
6. Disable outbound side effects. Point email, SMS and payment integrations at sandboxes so a tester's request cannot message a real person or charge a card.
7. Tell the tester what is real. List any third-party systems that are live even in staging, so they stay out of scope.
8. Rotate or delete everything after. Remove the accounts, revoke tokens and reset any seeded API keys when the retest is done.

How to avoid this trap

• Keep a seed script in the repository so you can rebuild the test tenants in minutes.
• Run a secrets scan on the staging repo and config before you share access.
• Treat the tester's findings as data that may include screenshots of your seeded records; this is easier when those records are fake.

Quick check

Sources

• NIST SP 800-53 Rev. 5 catalog (OSCAL), control SA-3(2) Use of Live or Operational Data
• NCSC: Penetration testing guidance, preparing for a test
• OWASP API Security Top 10 2023, API1 and API3