Skip to content

ISO 27001, SOC 2, the DPDP Act and manual VAPT. Book a Free Scoping Call

Help centre

Preparing Test Accounts and a Staging Environment

Give the tester fresh test accounts, at least two for each role, in an environment that mirrors production and holds seeded, not real, data. SecureRoot never needs your existing production credentials, a real customer's login or real customer data. Send usernames and passwords by separate channels, make every account expire, and revoke it when the engagement ends.

Request an assessmentContact us

About this help article

Written by SecureRoot Risk Advisory LLP.

Accounts

Create test accounts for every role

Access-control testing is comparative: the tester holds two sessions and tries to reach one user's data, or one role's functions, from the other. Without a second identity there is nothing to cross.

  1. 01

    Two accounts per role

    At least two accounts at each privilege level, so the tester can test one user against another at the same level as well as across levels.

  2. 02

    Both sides of every boundary

    If you have tenants, an approval chain or an admin console, provide accounts on each side: two tenants for a multi-tenant product, the requester and the approver for a workflow.

  3. 03

    Create them fresh

    Make new accounts for the test. Never hand over a real customer's login or an employee's everyday account, and never a standing administrator account.

  4. 04

    Write down the role map

    Send a short list of each role and what it should and should not reach. The tester checks the application against it.

Environment

Prepare a staging environment that represents production

SecureRoot prefers staging when it mirrors production in code, configuration and roles. A staging environment that lags a release, runs debug settings or holds very little data produces findings you cannot act on.

  • Deploy the same build and configuration that production runs, with debug modes off.
  • Seed realistic but fictitious data: enough records, files and transactions for each workflow to be exercised, and nothing copied from real customers.
  • Point payment, email and SMS integrations at sandbox or test endpoints, so nothing reaches a real person.
  • Tell us what still differs from production, so we can say whether it represents the live application.
  • If the environment is in the cloud, it stays inside your own tenancy. Provider rules still apply: AWS, for example, prohibits denial-of-service and request flooding even against your own resources.

If production is the only realistic target, testing runs in agreed windows, destructive actions stay off the table, payment and notification paths that reach real customers are not exercised, and the accounts and records we may touch are agreed in advance. All of it goes into the Rules of Engagement.

Credentials

Hand credentials over safely

  • Send the username and the password by different channels, never together in one email, ticket or chat message.
  • Use a password manager's secure share or a one-time link where you have one, rather than plain text.
  • Give each account only the permissions its role needs, and set it to expire when the engagement, including the retest, ends.
  • For cloud work, create a read-only role and, where agreed, a limited test principal inside your own identity system. You do not share an existing administrator's password or session.
  • Revoke every test account and key when the engagement closes, and keep the record of what was created.

Controls

Decide how to handle MFA and rate limits

MFA and rate limits are security controls, and testing them is part of the work. Rate limiting and resource consumption are tested in their own right on an API engagement. So the question is how the tester gets through them, not whether to switch them off.

  • Keep MFA on. Enrol each test account's second factor on an authenticator the tester holds, and send the enrolment by a separate channel.
  • Do not disable MFA, lockout or rate limits across the application for the test. If an exemption is needed, limit it to named test accounts or agreed source addresses, and record it in the Rules of Engagement.
  • Agree request rates and testing windows in the Rules of Engagement. Where a test would be destructive, SecureRoot demonstrates it at small scale and describes the rest.
  • Warn your monitoring team, or decide together that they will not be warned, so an alert during testing is handled as agreed.

Scope boundaries

What this does not cover

  • You remain responsible for the environment, its backups and for authorising testing of every system in scope, including services hosted by third parties.
  • Findings from a staging environment hold for production only as far as staging matches it.
  • Testing does not stop your own controls from alerting or blocking; how those alerts are handled is agreed in the Rules of Engagement.

Primary Sources

Where the Figures on This Page Come From

Every deadline, threshold and control count above is taken from the instrument itself. These are links to the primary text, not to a summary of it.

Related

Services and help that go with this

Plan the environment on the scoping call

Tell us what environment you have and what differs from production. SecureRoot will say whether it represents the live application and what accounts we need.

Request an assessmentContact us