A new compliance analyst treats a published policy PDF as identical to a control in ServiceNow IRM. What distinction should be corrected?
Select an answer to reveal the explanation.
Short Explanation
The PDF says what leadership wants; the control is the living lock on the door—owned, scoped to a place, and testable. Reading the policy is not the same as proving the control.
Full Explanation
A policy documents directive intent; a control is an implemented, owned, testable safeguard scoped to an entity. When a new compliance analyst treats a published policy PDF as identical to a control in ServiceNow IRM, the content chain breaks: reading leadership’s directive is not the same as proving a living lock on a specific clinic application or facility. IRM terminology keeps authority and policy language upstream and control instances downstream with owners, scope, and evidence. Saying controls are only Word macros attached to the PDF while policies are CMDB CIs garbles both document management and entity concepts. Calling a policy document and a control interchangeable labels for the same record type collapses the hierarchy CIS-RC teaches. Claiming every policy PDF automatically becomes a risk statement with a score confuses policy, risk statement, and risk instance objects. Exam caveat: expect definition-versus-instance distinctions across policy/control and related pairs. Operational check for the analyst: open one published policy, identify a related control objective, then open a control record scoped to a real entity and verify it shows ownership and a test or attestation path that the PDF alone does not provide.