A secure testing environment is defined and set up that mirrors the intended business process and IT operating environment for performance, capacity, security, internal controls, operating practice, data quality, privacy and workload: a test database resembling production is built, with production data sanitised as business needs and organisational standards require; sensitive test data and results are shielded from disclosure through controls on access, retention, storage and destruction, taking account of interactions with third-party systems; a process decides whether test results, media and documentation are kept for later review, analysis or retesting, or disposed of; the environment reflects the future business and operating landscape, covering roles and procedures, expected workload stress, operating systems, database management systems, application software, and the computing and network infrastructure; and it is secured so that it cannot interact with production systems.
This control maps to 2 controls across 1 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.
The graph holds this control, the 2 it maps to, and the evidence behind each claim, over MCP and REST.