Prepare pentest credentials, tenants and synthetic data by building a time-bound test identity system, not by lending personal accounts or copying customer records. Create named accounts for every material role, at least two users where horizontal access matters, at least two isolated tenants, canary objects and lifecycle states. Store credentials securely, monitor use, prevent real-world side effects and revoke everything after closure.

Define the architecture question before testing

Start from the authorization and workflow matrix. Which identities, tenant relationships, object states, integrations and cloud permissions are needed to test the agreed hypotheses? Provision only those capabilities while ensuring negative comparisons are possible.

Write the expected security invariant and the prohibited outcome in language that engineering, security and operations interpret the same way. Name the identity, trust transition, protected asset and authoritative state. That statement becomes the basis for scope, evidence and retesting.

Build the minimum evidence pack

  • A current component and trust-boundary diagram for the environment under test.
  • Identity, credential, network and data-flow details relevant to the decision.
  • Representative accounts, workloads and synthetic records with known ownership.
  • Logs or traces that follow the action through every material control point.
  • Explicit safety limits, stop conditions, owners and restoration steps.

Create a register of identities, roles, tenants, objects, integrations, credentials, expiry and owner; an approved secret-sharing channel; synthetic data rules; notification and payment sandboxes; canary storage and cloud resources; log identifiers; reset scripts; cleanup checklist and emergency revocation path.

Map identities to test objectives

One administrator account cannot prove horizontal, vertical and tenant isolation. Build the smallest set that covers meaningful relationships.

  • Create two accounts for each horizontal role.
  • Create ordinary and privileged roles.
  • Use two tenants with equivalent structures.
  • Include revoked, invited or transferred states.
  • Add machine and integration identities where relevant.

Document expected authority and prohibited pairs before testing. Account gaps should appear as coverage limitations.

Use synthetic but structurally realistic data

Data needs the relationships, formats and lifecycle states that drive policy without containing customer information.

  • Seed owned, shared and foreign objects.
  • Include boundary quantities and workflow states.
  • Create clearly labelled files and exports.
  • Use fake personal and financial values.
  • Represent archived and soft-deleted records.

Mark synthetic records visibly and ensure they cannot be mistaken for customer activity or enter production analytics.

Control credential creation and transfer

Credentials are sensitive even when they belong to test accounts because they can reach production systems.

  • Use unique accounts and strong generated secrets.
  • Transfer through approved secret storage.
  • Avoid email, chat and report attachments.
  • Require MFA or client certificates as the product does.
  • Set automatic expiry and revocation.

Keep an access register without storing secret values. Attribute every account to tester and purpose.

Prevent external and customer side effects

Tests can send messages, charge cards, invoke partners, create support tickets or trigger fraud controls.

  • Route email and SMS to controlled sinks.
  • Use payment and identity-provider sandboxes where representative.
  • Provide owned webhook receivers.
  • Block real shipping, provisioning and notification.
  • Set quotas and stop conditions for expensive integrations.

Document which integrations are real, mocked or sandboxed and how that affects coverage.

Make authoritative outcomes observable

Testers need to know whether a request changed data, queued work or generated a file. Provide safe visibility without broad administrator access.

  • Expose canary object state or audit records.
  • Propagate request and job identifiers.
  • Provide controlled export and storage inspection.
  • Enable reset for one-time workflows.
  • Monitor cloud and integration effects.

Least-privilege observability is preferable to powerful shared support accounts. Log all elevated access.

Support repeatable reset and retest

Business-logic and lifecycle cases consume state. Repeatability improves finding validation and remediation testing.

  • Script recreation of identities and objects.
  • Reset coupons, approvals and one-time tokens safely.
  • Version fixture definitions with product changes.
  • Preserve exact relationships for retest.
  • Separate destructive cases into dedicated fixtures.

Record fixture version and environment in findings so developers and testers reproduce the same preconditions.

Revoke and clean up after closure

Temporary users, API keys, buckets and relaxed policies should not become a forgotten attack surface.

  • Disable or delete accounts and sessions.
  • Remove keys, certificates and allowlists.
  • Delete synthetic records under policy.
  • Restore temporary configuration.
  • Review logs for activity after expiry.

Close the engagement with a signed cleanup checklist and owner verification, retaining only sanitized evidence required for assurance.

Execute as controlled hypotheses

  1. Establish the legitimate baseline and capture authoritative state.
  2. Change one trust variable—identity, route, scope, object, time or environment.
  3. Observe the decision at each layer rather than relying only on the response.
  4. Stop at the minimum proof that demonstrates or rejects the hypothesis.
  5. Restore test state and record residual uncertainty or blocked coverage.

Provision through normal identity and infrastructure workflows where possible so controls remain representative. Test the fixture before kickoff, but avoid sharing expected vulnerabilities. Keep production data out of non-production and do not weaken tenant boundaries to simplify setup.

Report the architectural consequence

State which identities, tenants, states and integrations were available, which were missing, and how fixture differences affected conclusions. Record data-handling and cleanup outcomes separately from vulnerabilities.

Separate observed evidence from inference. State prerequisites, repeatability, blast radius and the shared component responsible for the decision. When multiple findings have one architectural cause, keep the individual proofs but group the remediation around the common control.

Required closure evidence

  • The original proof no longer succeeds.
  • A legitimate workflow still succeeds under the intended identity and route.
  • Alternate consumers of the same pattern enforce the same invariant.
  • Telemetry records both allowed and denied decisions with useful context.
  • The architecture record and threat assumptions reflect the new control.

Remediate at the durable control point

Automate a secure test-fixture capability: time-bound identities, synthetic tenant templates, sandbox integrations, canary resources, least-privilege observability and verified teardown. Maintain it for retests and future assessments.

Retest the invariant, not just the payload

Recreate the documented relationships, repeat original proofs and legitimate workflows, and confirm cleanup after the retest. If the fixture changed, explain how equivalence was maintained.

Use the NIST Technical Guide to Information Security Testing and Assessment for assessment planning and evidence discipline, and the OWASP Web Security Testing Guide for relevant application techniques. Adapt both to the system-specific trust decision described here.

The architecture decision

High-quality pentesting needs realistic authority and state, not customer data. Purpose-built, time-bound fixtures improve depth, safety, attribution and retest speed simultaneously.

Ask WIMD to define the pentest fixture matrix for roles, tenants, synthetic data, integrations and safe cleanup.