A short written statement of what your organization requires. It is approved, dated, and it says what people must do, not how.
Also called policies, security policy.
Practitioner Guidance
What it means in practice
A policy says what is required, and a procedure says how it is done.
Keeping the two apart makes both shorter and more useful. A policy states that only authorized users reach systems holding Controlled Unclassified Information. A procedure says who approves an account, who creates it, and what record is kept. Assessors read both, and a document that mixes them usually fails to satisfy either objective.
Policy is evidence only when it is approved and dated.
Section 170.24(b)(1) rejects unofficial or unapproved policies as evidence. Put a version, a date, an owner, and an approver on every policy. This costs nothing and removes a category of finding entirely.
Short policies are followed, and long ones are not.
Nobody reads a forty-page document, which means nobody follows it, which means the interviews go badly. Write the policy at the length your company can actually live with. An assessor asks your people what happens, and their answers are measured against what you wrote.
Write policy for the organization you have, not the one in the template.
A template written for a large company assigns work to roles you do not have and cites practices you do not follow. That is a finding waiting to happen. Name the roles that exist, describe the practice you actually run, and let the document be small.
What falls short
A policy naming a security officer role nobody holds. The interview finds this immediately.
A policy that restates a requirement without deciding anything. The requirement is the obligation, and the policy is your decision about it.
A policy with no review date. Several requirements expect periodic review, which means at an interval you set that does not exceed a year. AT.L2-3.2.1 is one that turns on your own stated interval.
Edge cases
A provider's policy governs part of your environment. Reference it, record the inheritance, and keep a copy.
One policy covers several requirements. That is fine, and your system security plan should point to the section that covers each one.
Your practice has moved ahead of your policy. Update the policy, because the assessor tests the document against the practice.
Over-engineering
A policy set modeled on a large enterprise framework. The requirements do not ask for it, and the volume works against you.
A separate policy for each of the 110 requirements. A handful of policies covering the families is normal and easier to keep current.