Are development, testing, and production conducted in separate environments?
The real question underneath is whether production data has been copied into environments with weaker controls.
What the carrier is actually asking
The carrier is asking whether development, test, and production run in separate environments with separate access. It is asking about isolation and, implicitly, about whether real data is used outside production.
Why it is underwritten
Non-production environments routinely have weaker access control, no monitoring, and broader developer access, and they routinely contain a copy of production data. That combination has produced a long list of breaches where the compromised system was a test environment nobody was watching.
Where the answer lives in Microsoft 365, Entra ID, and Azure
In the cloud, separation is measurable through subscription and identity boundaries.
| Platform | Where the setting lives | What has to be true |
|---|---|---|
| Azure | Separate subscriptions or management groups per environment | Environments in distinct scopes with distinct role assignments |
| Azure | Role assignments per environment | Production access is a separate grant, so development access does not confer it |
| Azure | Network connectivity between environments | No routed path from development into production data services |
| Data handling | Whether production data is copied into lower environments | Masking or synthetic data, since the alternative extends the regulated footprint. Attested |
| Azure | Public exposure of non-production resources | Test systems are frequently the ones left publicly reachable, so check them specifically |
If a copy of the customer database sits in a test environment, that environment is inside the scope of every breach and every privacy obligation, with none of the controls. Masking is the fix, and it is deferred more often than any other data control.
What a defensible yes requires
- Environments are separate at the subscription or account level with distinct access.
- Production access is granted separately and held by fewer people.
- Non-production data is masked or synthetic.
- No network path connects development directly to production data.
- Non-production resources are checked for public exposure, since they are the most likely to have it.
How this answer goes wrong
Environments are separated by naming convention inside one subscription, with one role assignment covering all of them. Or they are properly separated and the test environment holds a full copy of production data with developer-wide access.
Frequently asked
Is separation by resource group enough?
It is weaker than subscription separation because inherited permissions cross it easily. It can work with careful role design, and subscription separation is the cleaner boundary.
Can we use production data in testing?
Only masked or with the same controls as production. Most organisations underestimate how much regulated data sits in their test environments.
What about developer access to production?
It should be exceptional, time-bound, and logged. Standing developer access to production is a common finding and a real exposure.
Does this apply to software-as-a-service?
Yes, where sandbox instances hold real data. The same principle applies to platforms you do not host.
Related questions
Stop answering this from memory
Connect Microsoft 365, Entra ID, and Azure read-only. Insurance Posture reads the live configuration behind each application answer and shows you which ones you can prove before you sign.
Assess your posture