A new analyst treats every control objective as if it were already an entity-specific control. Why is that incorrect?
Select an answer to reveal the explanation.
Short Explanation
A recipe is not the cake on each table. The objective is the recipe—the definition—while the control is the cake baked for a specific entity. Swap those roles and the kitchen model falls apart.
Full Explanation
Control objectives are definitions; controls are the instances generated for scoped entities. A new analyst treating every control objective as if it were already an entity-specific control is incorrect because the objective is reusable library content until generation creates owned instances on entities. Objectives and controls are not identical records that differ only by UI theme. It is backwards to claim controls are definitions while objectives are the generated instances per entity. Objectives are not limited to Classic UI and cannot appear in workspaces; both surfaces can present the definition layer. Exam caveat: UI labels such as policy statement versus control objective may vary by version and workspace, but the definition-versus-instance roles remain the teaching point for CIS-RC. Operational check: show analysts an objective with multiple mapped citations and zero or many generated controls across entities; generate for one municipal entity; contrast the objective record with the new control record's entity and owner fields; and assign a test only to the control. Add this distinction to onboarding quizzes so analysts stop assigning attestation campaigns to objectives instead of controls and flooding the wrong queue.