Keeping test out of production.
ISO 27001:2022 A.8.31 (separation of development, test and production environments) expects those environments to be kept apart, so that work in development or test cannot reach, change, or expose production. A lot of that boundary lives in configuration: connection strings, environment variables, seed and fixture scripts, and CI pipelines. Which means a single change to a config file can quietly collapse it.
The shapes the same control failure takes.
A.8.31 weakens when a non-production path gains a way into production, or when production data and credentials leak down into a lower environment. The recurring shapes:
A test config points at production
A test or CI database URL, endpoint, or config is set to a production resource, so a test run reads or writes real data.
Production secrets land in a lower environment
A staging or development config is handed production credentials, keys, or endpoints, collapsing the boundary the moment that environment is less protected.
A guard against cross-environment access is removed
An environment check that stopped a destructive, seed, or reset operation from running anywhere but a dedicated environment is dropped, so it can now run against production.
Fixtures or seed data get a path to production
A seed, fixture, or migration script that recreates or wipes data gains a route to the production database instead of an isolated one.
Environments share a backing store
A cache, bucket, or queue is wired so development or test and production read and write the same store, so non-production activity can affect live data.
An end-to-end suite pointed at the production database.
An end-to-end suite needs a database to run against. The dedicated test database is empty and the tests keep failing on missing data, so the setup is pointed at the production connection string to test against real data. The suite truncates and re-seeds tables on every run, and now it does that to production.
- const TEST_DB = process.env.TEST_DATABASE_URL+ const TEST_DB = process.env.DATABASE_URL // prod, to test against real dataawait db.connect(TEST_DB)await resetAndSeed(db) // truncates tables before each runThis points an end-to-end suite that truncates and re-seeds tables at the production database, so a test run can wipe and overwrite live data. A.8.31 expects development, test, and production to be separated so non-production activity cannot reach production. Restore the dedicated test database and load the missing fixtures there, rather than borrowing production, and keep the boundary so a test run can never write to live data.
Separation is checked at the boundary, not just claimed.
An auditor looks for evidence that your environments are actually separated: that test and development cannot reach production data or credentials, and that production is changed only through the controlled path. A test configuration wired to a production resource, or a lower environment holding production secrets, is the kind of gap that contradicts the separation your policy describes, and it usually arrives in a single change to a config or setup file. The diff is where the boundary is crossed, and the cheapest place to catch it.
A review, not your environment topology.
heygrc flags changes that touch A.8.31 and cites the control so the fix happens in the pull request. It does not provision your environments or hold your secrets. It catches the moment a test or development path reaches into production, at the diff. heygrc is in early access.