SC-1 Policy and procedures: requirements and evidence

SC-1 policy and procedures: what the control asks for

An audit, a customer contract or a FedRAMP authorization requires SC-1, and the question is usually the same: does the organization have a documented system and communications protection policy with implementing procedures? SC-1 requires exactly that. The policy must be disseminated to defined roles, managed by a designated official, and reviewed and updated at a defined frequency and after defined events. The control applies at the organization, mission or business process level, or at the system level, and the organization chooses which level fits its environment. Without this governing document, the network boundary rules, cryptographic choices and isolation settings that sit in the rest of the SC family tend to drift, because nobody is accountable for deciding how they should be set or checked.

SC-1 is hard in practice because the organization has to make the decisions the control leaves open. The Release 5.2.0 catalog defines 9 organization-defined parameters for SC-1 and no control enhancements, so the policy owner must fill in who the policy is disseminated to, who the official is, how often review happens and which events trigger an update. Those values need to be specific enough that an assessor can test them. A policy that says reviews happen "periodically" will not give an assessor anything to check against. Confirm the parameter values with your assessor before drafting, and record them in the policy itself so the evidence matches the wording.

SC-1 is an organization-owned control. Only the organization can name its officials and approve its policy, and DeployOpen can help prepare the document set, the procedures and the review records, but it does not write the policy as a substitute for the organization's ownership. Only an independent assessor issues findings on whether SC-1 is met. The assessment procedures in NIST SP 800-53A assess SC-1 through 17 determination statements, using examine and interview methods, so expect the assessor to read the policy, ask the named official how it is run and check the review history against the stated frequency.

Which systems and teams SC-1 policy and procedures covers

SC-1 is written once, but its reach is set by a handful of decisions made before drafting starts. The cards below cover the decisions that change how many documents you maintain, who signs them and which related controls they must align with. The scope decisions belong to the organization, and the choices should be recorded in the policy itself.

Level at which the policy is written

SC-1 allows the policy to sit at the organization, mission or business process, or system level. A single organization-level policy with system-specific procedures produces fewer documents and one owner, but assessors will still look for system-level detail where a boundary has unusual network or cryptographic needs. A policy written per system multiplies review cycles. Decide the level first, then write down which procedures sit beneath it so the assessor can trace each SC control to an owner.

Baseline selected from SP 800-53B

SC-1 appears in the low, moderate and high baselines in SP 800-53B, so the control itself does not change with impact level. What changes is the number of related SC controls the policy must govern. A low system may need a short policy covering boundary and cryptography basics, while a high system brings in isolation, partitioning and key management controls that the policy must address. Confirm the baseline with your categorization before drafting, because it determines which SC procedures the policy references.

FedRAMP Rev5 classes that require SC-1

The FedRAMP Rev5 baselines require SC-1 at Classes B, C and D. If your system is in scope for a FedRAMP authorization, the policy must meet the FedRAMP reading of the control, and the cloud service provider's documented procedures may need to be reconciled with yours. Confirm the class with the authorizing official or the FedRAMP documentation for your package, since the class drives the scope of the policy as well as the assessment evidence you will be asked to produce.

Teams that own network, crypto and isolation

SC-1 is only as good as the owners named in it. Network boundary, cryptography and isolation controls often sit across the network engineering, platform, security and application teams, and a policy that names a single owner for all of them invites gaps. List each SC domain, the team that operates it and the team that approves changes to it. Ask who maintains the procedures, who approves exceptions and who reviews them after defined events, since those names are what an interviewer will test against.

Inherited controls from cloud or shared services

Where a cloud provider or shared platform operates part of the SC environment, such as physical network infrastructure or managed encryption services, some SC-1 procedures are inherited rather than owned. Document which parts of the policy the provider covers, which parts you keep, and where the boundary between them sits. Ask the provider for its shared responsibility documentation and confirm how it is referenced in your policy, because an assessor will not accept a gap that neither party has written down.

Related controls the policy must align with

The Release 5.2.0 catalog links SC-1 to PM-9, PS-8, SA-8 and SI-12. PM-9 concerns the organization-wide risk management strategy, PS-8 covers personnel sanctions, SA-8 covers security engineering principles and SI-12 covers information management and retention. Each one reaches into the SC policy from a different direction, so check that the SC policy uses the same owners, terms and review cycle as those documents. Mismatched definitions across these policies are a common finding, and a single cross-reference table reduces that risk.

How an assessor tests SC-1

This table walks through how an assessor tests SC-1 under the SP 800-53A Release 5.2.0 procedure, row by row: the test approach, the evidence requested and the findings that come up most often. Read each row as a sequence, because the policy, the procedures and the people who use them are each tested separately.

Test step	What the assessor does	What a passing result looks like
Test approach	Works through 17 determination statements using the examine and interview methods, checking each organization-defined parameter that SC-1 leaves to the organization	Every determination statement has documented support, and the organization's chosen parameters (such as review frequency and event triggers) are written down and consistent with each other
Policy examination	Reads the system and communications protection policy and checks scope, purpose, roles, coordination among entities and compliance language	The policy names the systems and boundaries it covers, states management commitment, and assigns a designated official who owns it
Procedure examination	Compares the implementing procedures against the policy and checks that each procedure maps back to a policy statement	Procedures cover network, cryptography and isolation controls in the SC family, and each one names the role that performs it and the record it produces
Risk management strategy examination	Checks that the SC policy traces to the organization's risk management strategy and risk tolerance documentation	The policy cites the risk decisions it implements, and the risk strategy shows the same priorities for boundary, cryptography and isolation
Audit findings examination	Reviews recent internal audit and assessment findings on SC controls and checks whether the policy was updated after findings were raised	Past findings appear in the review history with a documented change, or with a recorded decision to accept the residual risk
Interview with policy owners	Asks the designated official and control owners how the policy is maintained, approved and communicated	Owners describe the same review cycle and approval path the document states, and can say when the policy last changed and why
Interview with people named in procedures	Asks network, cryptography and platform staff whether they know their duties and where the procedures are stored	Staff describe their SC duties accurately, can locate the current procedure, and agree with what is written about them
Common finding: no named owner	Records that the policy or procedure exists but no individual or role is accountable for it	Resolved by naming a designated official in the policy and recording the appointment with its effective date
Common finding: practice differs from procedure	Observes configurations or change records that contradict the documented procedure, such as undocumented exceptions to boundary rules	Procedures are corrected to match approved practice, or practice is brought back in line, with the change recorded
Common finding: review date has passed	Notes that the stated review frequency has lapsed or that no review occurred after a defined triggering event	A dated review record exists for each cycle, with the reviewer, outcome and any revisions

How the SC-1 policy governs boundary, cryptography and isolation controls

The SC-1 policy is the single document that sets the rules the other SC controls then implement. It should name one owner for the system and communications protection program, state the scope it covers (which systems, networks, cloud accounts and data stores), and point to a named standard for each technical area. For boundary protection, that means the policy assigns ownership of SC-7 to the network or platform team and points to an approved standard for deny-by-default rules and internal segmentation. For transmission and at-rest protection, it does the same for SC-8 and SC-28, naming the approved protocols and the storage classes that must be encrypted. For key and certificate management, it links SC-12 and SC-17 to a key and certificate standard that says who may issue certificates, which certificate providers and trust anchors are approved, and who approves changes. For DNS, session authenticity and separation, it does the same for SC-20 to SC-22, SC-23, SC-2 and SC-39.

The procedures are where those statements become steps and records. An assessor who picks one SC-1 statement, such as "boundary rules are deny by default and reviewed at a defined frequency," will usually trace it in three hops: the procedure that defines the review, the firewall or security group export that shows the current rule set, and the change ticket and approval for the last rule added. For a cryptography statement, the trail runs from the procedure to a key register showing key owner, algorithm, creation date, rotation and destruction, and then to the configuration that enforces it. For DNS, the trail runs to the zone configuration showing DNSSEC signing and the separation of internal and external resolvers. Confirm with your assessor which artifact types they expect for each area, since the expected evidence depends on your system boundary and impact level.

Before engaging an implementation partner, confirm three things internally: that the policy owner has authority over the teams that run firewalls, certificate authorities and DNS, that each procedure names the record it produces and where that record is stored, and that the review triggers in the policy match real events such as architecture changes or certificate authority changes. Records kept in a version-controlled wiki or documentation tool can show when a procedure changed and who approved it, which assessors ask for. A partner can prepare the procedures, the registers and the evidence exports, but the organization owns the policy and the decisions it records.

Implementing SC-1: from policy owner to reviewed procedures

This sequence takes SC-1 from an unassigned requirement to a policy and set of procedures with named owners, filled-in parameters, distribution records and a completed first review. Each step closes with a document or record an assessor can examine.

Name the designated official and review owner
Leadership appoints one designated official who is accountable for the system and communications protection policy, and a separate review owner, often in security or GRC, who maintains the documents day to day. The two roles can be the same person in a small organization, but the appointment should be written down. The output is a signed appointment memo or role entry that names both people and states their responsibilities. You know this step is done when an assessor can ask who owns SC-1 and get one name without follow-up.
Define scope and policy level
Decide whether the policy applies at organization, mission or business process level, at system level, or at more than one of these levels, and list the systems, networks, cloud accounts and data centers it covers. Record which parts of the SC family the policy governs, such as boundary protection, cryptography and isolation, and which are handled by a separate standard or by a system owner. The output is a scope statement with an inventory reference. It is complete when every system in the boundary maps to the policy or to a named subordinate document.
Draft the policy and fill in the parameters
Write the policy purpose, scope, roles, compliance expectations and management commitment, then complete the organization-defined parameters that SC-1 requires the organization to set. Confirm the current count and wording of these parameters in the OSCAL catalog for the release you assess against, and put each one in a parameter table with its value, owner and approval date. The output is a draft policy and a parameter table that a reviewer can trace line by line. The step is done when no parameter is left blank or described only as "as appropriate."
Write procedures for each SC area
Produce a procedure for each area the policy covers, such as boundary protection and network segmentation, transmission and at-rest encryption, cryptographic key and certificate management, DNS security, session authenticity, isolation and separation, and time synchronization. Each procedure should name the performing role, the steps, the tool or system used and the record it creates. Store the procedures in a version-controlled wiki or document system so changes are recorded. The output is a procedure set with one owner per document. It is complete when every SC control the organization has selected has a procedure that points to its evidence.
Disseminate documents and record acknowledgment
Approve the policy and procedures through the designated official, then distribute them to every role the policy names, including system administrators, network and cloud engineers, application owners and key custodians. Collect electronic acknowledgments that record the person, the document version and the date. Keep the distribution list current as roles change. The output is a distribution record and an acknowledgment log tied to specific document versions. You know this step is done when every named role appears in the log for the current version.
Set review frequency and event triggers
Set the review frequency and the list of events that force an early review, such as a major architecture change, a security incident affecting the SC family, a change in applicable regulation, or a new release of the control catalog. The organization sets these values, so record them in the policy and in the parameter table. Add a calendar entry and a named reviewer for each review. The output is a review schedule with defined triggers and a change log template. It is complete when the schedule and triggers are written into the policy itself, not only in a planning tool.
Run and record the first review cycle
Conduct the first full review against the approved scope, parameters and procedures, and check that each procedure still matches how systems run today. Log every finding, the decision taken, the approver and the revised version number. Where the review finds gaps in SC controls, open items in the plan of action and milestones rather than editing the policy to hide them. The output is a signed review record and a revised policy version. The step is complete when the review log shows the outcome, the approver and the next scheduled review date.

Evidence that passes SC-1 policy and procedures

SC-1 is assessed on paper before it is assessed in practice: the policy, the procedures beneath it, and the records that show someone owns them and keeps them current. The cards below cover the artifacts an assessor will request and how to keep each one current between assessments.

Approved SC policy with approval record

The system and communications protection policy should state its purpose, scope, roles and the organization, mission, business process or system level it covers. Keep a version number, an effective date and a signed approval record from the official who has authority to issue it. Check that the approved version matches the one distributed to staff. Between assessments, log every edit and route each new version back for approval, since an unapproved draft in circulation is a common finding. Version history supports the approval but never replaces it.

Procedures for each SC area

Procedures turn the policy into steps for the boundary, cryptography, key and certificate, DNS, session and time synchronization controls. Write one procedure per SC area that names the owner, the trigger, the steps and the record produced. Assessors often sample a procedure and then look for the matching configuration or log, so each procedure should point to where its evidence lives. Review procedures whenever a related control changes, such as a new boundary device or a certificate authority change.

Designated official appointment

SC-1 requires the policy to be managed by a designated official. Keep the signed appointment letter or role assignment that names this person, their deputy and their authority over SC procedures. Confirm the appointment still matches the org chart, since a departed owner with an unchanged policy is an easy gap to spot. Record any reassignment with its date so the assessor can see continuous coverage.

Dissemination and acknowledgment records

The policy and procedures must reach the defined roles, and assessors will ask who received them and when. Keep distribution lists, publication dates on the document repository and signed or electronically recorded acknowledgments from system administrators, network engineers and cryptographic key custodians. Compare the recipient list against current staffing each quarter so that new hires and role changes are covered before the next assessment.

Review and update log

SC-1 sets a review frequency and a list of events that trigger an update, such as a significant incident, a new system or a change in regulation. Keep a log that records each scheduled review, each event-driven review, the reviewer, the outcome and any revision made. Confirm that the frequency you wrote in the policy is the one you actually followed, because a policy reviewed less often than it states is a plain finding.

Policy to control traceability

An assessor will want to follow a thread from the policy to the operating control, for example from the boundary protection procedure to the firewall rule set, or from the key management procedure to the key inventory. Maintain a short traceability table that maps each SC area procedure to its control implementation and evidence owner. Review the table when systems change, since stale links are one of the most common reasons a sound policy still fails.

What meeting SC-1 costs in money and effort

This table lists the cost components of writing, maintaining and evidencing the SC-1 policy and procedures, who typically carries each one, and whether it is one-time or recurring. Use it to scope a quote, then check each row against your own number of systems, SC areas and teams.

Cost component	One-time or recurring, and who pays	What drives it up	What keeps it down
Policy drafting and approval time	One-time for the first version, then recurring at each review. Paid by internal policy owners and approvers, sometimes supplemented by an outside consultant.	Number of policy levels (organization, mission or process, system), number of approval bodies, and whether the SC policy is written from scratch.	Reusing an existing organization-wide policy template and folding SC-1 into the approval cycle already used for other policies.
Engineering time to write procedures for each SC area	One-time per SC area, then recurring when architecture changes. Paid by network, cryptography and platform engineers.	Number of SC areas tailored in (boundary protection, cryptography, DNS, session authenticity, isolation), number of platforms, and FedRAMP class if applicable.	Writing procedures against the platform's own configuration as it is built, and limiting the first release to the baseline your system actually selects.
Document tooling or licenses	Recurring if commercial wiki or GRC licenses are used. Paid by the organization to software vendors.	Number of editors and readers, and whether the tool also stores evidence or assessment records.	Self-hosting an open-source wiki with version history, such as XWiki or BookStack, removes per-seat license spend, though hosting and administration remain internal or contracted costs.
Evidence upkeep at each review cycle	Recurring. Paid by control owners who collect proof that the policy was reviewed, approved and disseminated.	Number of defined review triggers, number of teams that must acknowledge the policy, and how many systems each procedure covers.	Aligning SC-1 reviews with an existing calendar and recording approvals and version history in one place so evidence is captured as a by-product of the review.
External review of the policy set	Optional, one-time per engagement, sometimes recurring. Paid by the organization to an outside consultant.	Size of the SC policy set, number of tailored parameters, and whether the review covers all related controls such as PM-9, PS-8, SA-8 and SI-12.	Scoping the review to SC-1 and its related controls, and asking the reviewer to work from the organization's own template and written scope.
Auditor sampling time	Recurring at each assessment. Paid by the organization for the assessor's time, and by internal staff who respond to requests.	Number of policy versions in the assessment period, number of teams sampled for acknowledgment, and whether procedures match the implemented configuration.	Keeping a single current version, a clear change history and dated acknowledgments so the assessor can sample quickly.

Open-source tools that hold the SC-1 document set

Three self-hosted open-source tools can hold the SC-1 document set: the policy text, its review history, its distribution to defined roles and its status in a compliance register. Each covers a different part of the work, so the cards separate them by function. None of these tools approves the policy. The designated official approves it, and an independent assessor tests it.

XWiki for versioned policy text

XWiki (LGPL-2.1-or-later) keeps every change to a page under version control. Every change is recorded with what changed, when and by whom, and reviewers can compare any two versions or roll back to an earlier one. For SC-1, this gives the review log a dated record that matches the review frequency and the triggering events the organization defined. Confirm that the wiki's history falls under your own backup and retention rules, and that edit rights on the policy page are limited to the designated official and approvers. The tool keeps the record, but the designated official still signs off on the content.

BookStack for controlled dissemination

BookStack (MIT) assigns user abilities through roles, and permissions can be overridden per role at the shelf, book, chapter or page level. This lets the SC-1 policy stay readable by the administrators who need it while the procedures for boundary protection and key handling remain editable only by their owners. Map each role to the defined roles named in the policy, then test with a non-administrator account that restricted pages behave as intended. Confirm the role model in the version you run, because permission behavior can change between releases and a silent change could expose or hide a procedure.

CISO Assistant for tracking SC-1 status

CISO Assistant (AGPL-3.0-only) ships more than 200 frameworks, including NIST and ISO frameworks, and runs assessments against them with automatic mapping between frameworks. Teams can use it to track the status of SC-1 alongside its related controls PM-9, PS-8, SA-8 and SI-12, with evidence references attached. Before relying on it, confirm how the SC-1 entry and its organization-defined parameters are represented in your installed version, and whether its mappings match your own reading of the control. Recorded status reflects the organization's own assessment, not an assessor's result. Review the AGPL-3.0 obligations before hosting it for users, including what source you must offer for any modified version.

Who writes, reviews and tests the SC-1 policy

Your organization owns SC-1. The policy is only effective if the people named in it recognize it as their rule and can explain how their network and cryptography controls work in practice. Your designated official is accountable for the document, while the network and cryptography owners write the procedures that describe how the controls operate in your environment. An approver with authority over the policy signs it off and decides when it is reviewed.

Designated official: Holds the SC-1 policy, schedules reviews and records the events that trigger an out-of-cycle update.
Policy owner: Maintains the scope statement, the roles named in the policy and the links to related SC family controls.
Network and cryptography owners: Write the procedures for boundary protection, transmission and at-rest encryption, and key and certificate management, based on the systems you actually run.
Approver: A senior role that formally adopts the policy and procedures, usually an executive with authority over security risk.

Confirm that each named role has accepted the responsibility in writing and that the policy states who may delegate it.

Common questions about SC-1 policy and procedures

How much effort does SC-1 take for a small system compared with an enterprise?

For a small system, SC-1 is mostly a short policy set with clear owners and a few procedures, while an enterprise needs layered policy at organization, mission or business process, and system levels. The control text lets the organization choose the level, so effort scales with how many systems, business units and existing policies must be reconciled. A small system may reuse one organization-wide policy with a system-specific procedure annex. An enterprise typically faces more interviews, more approval routes and more overlap with existing security documents. Ask any partner to show how the scope is split by level before agreeing on effort.

How long does it take to produce a first SC-1 policy set?

The time depends on the drivers, not on a fixed duration that applies to every organization. The main ones are how many policies already exist that can be extended, how many owners must review and approve the text, how quickly interviews can be scheduled, and how much of the network, cryptography and isolation design is documented today. Organizations with current architecture diagrams and an approved information security policy usually move faster than those drafting from scratch. Ask for a timeline in the written scope that lists each review and approval step and the people responsible for them.

Can our own team write the SC-1 policy without outside help?

Yes. The organization owns its controls, so its own staff can write, approve and maintain the policy and procedures. What matters is that the policy names a designated official, an owner for the network, cryptography and isolation topics, and an approver with authority over the organization. Wiki and documentation tools such as XWiki keep version history, and BookStack can restrict editing rights by role, which helps separate drafting from approval. Outside help is most useful for gap analysis against the SP 800-53A assessment procedures, which lists 17 determination statements for SC-1 in Release 5.2.0. An independent assessor still tests the result, because a partner does not issue assessment reports.

What does the SC-1 work require from our team?

The work needs named owners, time for interviews and access to the systems that the policy governs. Owners must confirm which network, cryptographic and isolation decisions are already made and who makes them. Interviews are needed with system administrators, security engineers and the people who approve changes, because SP 800-53A assessors use interviews alongside examination of documents. Access to configuration records, architecture diagrams and existing audit findings lets the team write procedures that match reality. Confirm these commitments in writing before the work begins, including who signs off each draft.

Can we inherit SC-1 from a cloud provider or shared service?

Only part of it. A cloud provider or shared service may document its own controls, but SC-1 requires a policy and procedures that apply to the organization's system. Inheritance can cover the provider's share of the network and physical controls, while the organization still needs its own policy stating who owns the responsibilities it retains, such as firewall rules, key choices and tenant isolation. Ask the provider for its shared responsibility documentation and confirm exactly which SC-1 statements it covers. Any inheritance claim should be checked by the assessor against the written agreement.

How often must the SC-1 policy be reviewed?

The review frequency is the one defined in your own organization's policy, not a number that NIST sets for you. SC-1 requires the policy and procedures to be reviewed and updated at a defined frequency and after defined events, so the policy must state both. Common event triggers include a significant change to the network architecture, a new cryptographic standard adopted, a security incident that exposes a gap, and changes in applicable law or contract terms. Release 5.2.0 also revised related -1 controls, so organizations should check whether their defined events still match the current catalog. Record each review with a date, reviewer and outcome so assessors can see the cycle working.

What should we ask a partner to put in a written scope?

Ask for a written scope that names every deliverable, the systems and organizational levels covered, and the roles that approve each document. Confirm which SC family controls are in scope for this topic, which policies and procedures will be drafted, and which existing documents will be reused. The scope should state what the partner does not do, including issuing assessment reports or certifications, which belong to independent assessors. Ask for the review and approval steps, the schedule tied to those steps, the handover format for policies and evidence, and the support available after delivery. DeployOpen agrees scope, deliverables and timelines in writing before work starts.

How DeployOpen prepares SC-1 policy and evidence

DeployOpen works on SC-1 as a set of documents and records that the organization owns and an independent assessor can test. We plan, implement and document the policy and procedure set inside your own environment, then hand over the evidence trail so your team can keep it current. Only an independent auditor or assessor issues assessment results.

How we scope

Agree in writing which systems, network zones and cryptographic services the SC-1 policy governs before work starts.
Confirm the policy level (organization, mission or business process, or system) and the designated official who owns the document.
Record the review frequency and triggering events you select for the policy and its procedures, as your organization defines them.

How we build

Draft the SC-1 policy and procedures in a self-hosted wiki so every revision keeps its author, date and change history.
Map each SC-1 organization-defined parameter to a named role, owner and review cycle that your organization approves.
Link the SC-1 procedures to the network, cryptography and isolation controls in the SC family so assessors can trace governance to practice.

How we hand over

Deliver the approved policy, procedures, dissemination record and review log as documents your team controls and can export.
Walk the designated official and assessment contacts through where each SC-1 artifact is stored and how it is updated.
Provide a written list of the evidence an assessor will examine and interview for SC-1, with the owner of each item.

How we support

Ongoing support, upgrades and documentation updates are available as a retainer after handover, under a separate written scope.
Retainer work can cover periodic policy reviews, changes after organizational or system events, and refreshes after new NIST releases.
Confirm with your assessor which evidence format and retention period they require before the first assessment cycle begins.