Policy lifecycle, relationships, and acknowledgments

Policies move through a fixed lifecycle:

1. Draft — author writes the policy.
2. Review — under stakeholder review.
3. Approved — signed off but not yet in force.
4. Published — live and enforceable; users can acknowledge.
5. Expired — past its expiry date (the system does not auto-flip this; you promote it).
6. Retired — replaced by a newer version or no longer needed.

Use the Publish button to move an approved policy to published in one click (the effective date gets set to "now" if not already populated).

A policy doesn't exist in isolation. From the view modal you can link it to:

• Controls it implements. "Access Control Policy" → IA-02 MFA control, AC-02 Account management, AC-07 Unsuccessful login attempts. This is how you show that policy language corresponds to operational practice.
• Risks it addresses. The same policy → the risks of unauthorised access, of credential compromise, of insider abuse. Answering an auditor's "why does this policy exist?" becomes mechanical.
• Evidence. Evidence records can set policy_id at upload time.
• Attestation campaigns. A published policy can be assigned to a group of users with a due date; each target is tracked until they click "Acknowledge". Non-ackers get weekly reminder emails until they complete or the campaign is closed.
• Individual acknowledgments. Any user viewing a published policy can acknowledge it themselves — logged with IP and timestamp as defensible evidence.