Lab clone entities must not receive the same generated production controls. How should generation be constrained?
Select an answer to reveal the explanation.
Short Explanation
Lab twins should not inherit the full production compliance harness. Scope generation with entity-type conditions that keep lab clones out. Generate-then-prune, deleting labs from CMDB, or one type for everything keeps dragging noise into production compliance.
Full Explanation
Environment-aware scoping uses entity types and conditions so control generation targets production entities and excludes non-production clones. Applying those conditions prevents lab systems in civic IT estates from receiving the same production control sets, tests, and overdue pressure as live citizen-facing systems. Generating controls for all entities and manually retiring lab controls after each run fails by concept because post-generation cleanup is not durable and reintroduces drift every cycle. Deleting lab entities from the CMDB so they cannot be modeled fails by concept because labs still need CMDB representation for change and support; GRC scoping should constrain generation, not erase inventory. Using the same entity type for lab and production without additional conditions fails by concept because undifferentiated types cannot enforce environment separation. Exam caveat: CIS-RC expects generation constraints via entity-type conditions to keep non-production clones out of production control sets. Operational check: apply entity-type conditions that exclude lab clones, run control generation for a mixed estate, and verify production entities receive controls while lab clones do not.