Development, test and production environments are to be kept apart and secured. Purpose: keep work done in development and testing from harming production systems or production data. Guidance: determine and implement the degree of separation needed to avoid production problems, considering: separating development and production systems adequately and running them in different domains, such as separate virtual or physical environments; defining, documenting and applying rules and authorization for promoting software from development to production; testing changes in a test or staging environment before applying them to production (8.29); not testing in production except in defined, approved circumstances; keeping compilers, editors and other development or utility tools out of reach of production systems when not needed; showing clear environment labels in menus to reduce mistakes; and not copying sensitive information into development and test environments unless they have equivalent controls. Development and test environments themselves should be protected by patching and updating all development, integration and test tools (builders, integrators, compilers, configuration systems, libraries), securely configuring systems and software, controlling access, monitoring changes to the environments and the code in them, monitoring them securely, and backing them up. Nobody should be able to alter development and production alike unless someone has reviewed and approved it first, achieved through separate access rights or monitored rules; in exceptional cases, fine-grained logs and live monitoring should catch and respond to unauthorized changes. Other information: developer and tester access to production risks unwanted changes, failures, running untested code, disclosure and integrity or availability problems; a known, stable test environment is needed, supported by well-designed roles, segregation of duties and monitoring; shared environments cause accidental changes; sometimes the boundaries are deliberately blurred through pilot rollouts, internal live use or twin production environments for zero-downtime deployment; processes for using production data in testing (8.33) are needed; the same guidance can apply to training environments.
This control maps to 60 controls across 25 other frameworks. If you already hold one of them, the evidence you collected for it is the starting point here rather than new work.
Every mapping shown was judged rather than inferred from wording similarity, and the ones that failed review are published too. See the coverage reports and what was rejected.
ISO 27002:2022 8.31 is one control. If you already hold one of the frameworks below, a reviewed crosswalk already says how much of ISO 27002:2022 your existing evidence covers. Hold NIST SP 800-53 Rev 5 and 79 of 93 ISO 27002:2022 controls already carry evidence.
Each report names every control your existing framework evidences, every one it does not, the reasoning behind each claim, and the claims that were argued against and rejected. 180 were rejected on the NIST SP 800-53 Rev 5 pair alone.
The graph holds this control, the 60 it maps to, and the evidence behind each claim, over MCP and REST.