Designers propose a second, audit-only catalog of controls that duplicates Policy and Compliance. What architecture guidance should CIS-RC favor?
Select an answer to reveal the explanation.
Short Explanation
Two control catalogs are like two conflicting street maps for the same city. Audit should ride the existing entity and control framework—and reuse tests—rather than inventing a parallel universe. One model, many uses.
Full Explanation
CIS-RC architecture favors reusing the entity framework and existing control tests so Audit does not invent a second control universe that duplicates Policy and Compliance. One control catalog with many consumers—compliance testing and audit reliance—beats conflicting street maps for the same city. Duplicate audit-only catalogs create drift and double maintenance.
Always cloning every control into an audit-only table before fieldwork institutionalizes duplication. Storing audit controls only in spreadsheets detached from entities abandons the entity framework. Replacing Entity Framework with assignment groups for all audit scope mistakes ITSM queues for GRC entities.
Exam caveat: reuse entities and control tests; do not clone an audit-only control catalog as default architecture.
Operational check: map audit scope to existing entities and controls; reuse recent tests where independence allows; reject project designs that mandate a parallel audit control table for every engagement.
Architecture review boards should reject proposals for audit-only control clones unless a documented regulatory exception demands physical separation—and even then map back to entities. Default design remains one control universe consumed by compliance testing and audit reliance.