The city authors an internal access-control policy that must be reviewed, approved, and made active for the organization. Which lifecycle outcome is required?
Select an answer to reveal the explanation.
Short Explanation
An internal policy isn’t “live” just because someone typed it. It needs the approval path into published or active—then it can drive real obligations. Draft forever means the org still has a wish list, not a rule.
Full Explanation
Internal policies in IRM follow a record lifecycle from draft through review and approval into published or active states. For a city-authored access-control policy that must be reviewed, approved, and made active for the organization, advance the policy record through approval to a published or active state before treating it as obligatory. Leaving the policy permanently in draft while generating production controls from it bypasses governance gates and creates obligations without an approved parent. Publishing only a SharePoint PDF and never creating a policy record in IRM abandons workflow, acknowledgment campaigns, and structured linkage to controls. Marking the policy retired on creation so owners are not notified blocks the lifecycle entirely and prevents legitimate rollout. Exam caveat: published or active status is necessary but not sufficient—scoped control objectives and generation still create the owner work items that operationalize the policy. Operational check: route the access-control policy through the municipal approval workflow, confirm state change to published/active, notify affected owners, then associate related control objectives for generation. Audit the policy activity stream to show approval evidence for examiners and store the approval packet with the policy record.