SC-1, Policy and Procedures, is the opening control of the System and Communications Protection family. It asks the organization to develop, document and disseminate a system and communications protection policy to the personnel or roles it names, along with procedures to implement the policy and its controls. It must designate an official to manage both, and review and update the policy and procedures on a defined frequency and after defined events.
800-53 binds US federal systems, and others through contract. For small and mid size companies it is a reference, and the SC family covers encryption, network boundaries and sessions, which makes this policy one of the first things a customer asks to read.
What it means in practice
The policy must cover purpose, scope, roles, responsibilities, management commitment, coordination among organizational entities and compliance. It must be consistent with applicable laws and standards.
The procedures are separate. They describe how people carry out the policy, such as how keys are rotated or how a firewall change is approved.
The guidance contains the line auditors quote: simply restating controls does not constitute an organizational policy or procedure. A document that copies control text with the words "we do this" fails the test. It needs your decisions, your numbers and your owners.
Other points from the record: policies at organization level are generally preferable and can remove the need for system specific ones. The policy can sit inside a general security policy or be several policies. Security and privacy programs should work together on it. The risk management strategy influences it.
Evidence to collect
- The policy document with version, date, approver and owner.
- The procedures, either inside the policy or as separate runbooks.
- A distribution record showing who received it and when, such as an acknowledgment log.
- The designation of the responsible official.
- Review history: the frequency you set, dates of reviews, and what changed.
- Records that an event triggered a review, if one occurred.
Common gaps
A policy copied from a template with placeholder values still in it.
No procedures. The policy says keys are rotated, and no document says how.
No evidence of dissemination. Putting a file on a wiki is not the same as telling people.
A stated annual review with a last edit date three years ago.
An owner who left the company.
How to implement it
- Write the policy in plain language with your actual rules: minimum TLS version, session timeout, who approves boundary changes.
- Add procedures for the recurring tasks and link them from the policy.
- Name the owner by role, and update the name when the person changes.
- Set a review frequency you will keep, commonly yearly, and add triggers such as a major architecture change or an incident.
- Collect acknowledgments from the people affected.
- Map the policy to the controls it supports. Mappings to other frameworks vary, so check the one your auditor uses. The demo shows how a policy maps across frameworks.
Click through it at your own pace, or open it full screen.
Quick check
Why can restating the control text fail an audit?
The guidance says simply restating controls does not constitute an organizational policy or procedure. It needs your own requirements and decisions.
Do the policy and procedures have to be separate documents?
No. The policy can be part of a general security policy or several policies, and procedures can be set per program, process or system as needed.
