The System and Communications Protection (SC) domain separates your data from the world. It is the part of your security program that guards the "pipes" and "gates" of your network.
You must set up digital checkpoints at the edges of your network. You must use encryption to protect sensitive data while it travels. You must divide your network into smaller, more secure sections.
You must keep your private data separate from public systems like your website. You must make sure that different users do not see each other's data when they use the same computer or server. By creating digital boundaries, you make it much harder for a hacker to move through your system. You have control over who can connect to your network and what they can see.
The SC domain is the "vault" and the "armored truck" of your business. It creates a safe place for your data to live and a secure way for it to travel.
Domain level policies address the controls implemented within systems and organizations. Policies are the perfect home to define control parameters, such as frequencies. Procedures describe the implementation of policies or controls. Organizations may document procedures within the system security plan or within separate documents.
Here are some of the principles that guided this system and communications protection policy:
A cover page tracks specific details regarding the policy, including:
NIST SP 800-53 defines specific objectives for domain-level policies. From this guidance we incorporate the following major sections into our policy:
The purpose statement should identify why the policy exists and what it aims to achieve.
The scope should identify who it applies to and under what circumstances.
The policy governance section covers most of the organization defined parameters. These subsections cover the following details:
The fourth section includes our policy statements. Subsection headings group related Policy statements together. Each policy statement has a unique number for traceability to other documents. A policy statement number consists of the section, subsection, and policy statement order.
The fifth section identifies the relevant roles and responsibilities identified in the policy. A single, short paragraph describes the responsibilities for each role. The sixth section identifies the supporting procedures. We opted to align our subsection headings with the names of supporting procedures. The seventh section identifies related documents, to include relevant policies. The eighth section documents a revision history. This table captures policy changes, including: version, effective date, approver(s), change summaries. The ninth section captures a formal authorization of the policy by the policy owner.
NIST identified a named set of procedures for each practice within NIST SP 800-171. The assessment guide (SP 800-171A) contains the original mappings. The CMMC assessment guides include this mapping as well. The potential assessment methods and objects section contains a subsection called examine. Within each practice, NIST identified relevant policies, procedures and other artifacts. We used the relevant procedures to organize the section headings within each policy.
Architectural diagrams shall be created and updated at least annually or upon significant change to the network architecture to identify the boundaries of information systems, specifically denoting the CUI Assessment Boundary. These diagrams must illustrate information flows from external to internal sources, or from untrusted to trusted environments, particularly through firewalls. Furthermore, these diagrams shall describe all gateways, major systems, and permanent inbound and outbound connections between systems.
All internal connections between system components (e.g., VLANs, subnets, or API integrations) must be formally authorized by the Security Officer. This includes connections between CUI-processing environments and shared services (such as domain controllers or backup servers). Any data flow crossing these boundary segments must be inspected for unauthorized CUI exfiltration. For each authorized internal connection, the organization shall document in the System Security Plan (SSP):
Internal connections shall be terminated upon discovery of a security compromise, decommission of a component, or end of a specific project. The continued need for each internal connection shall be reviewed annually or upon significant change to ensure the "Principle of Least Privilege" remains enforced.
Internal network segmentation (e.g., VLANs, subnets, or micro-segmentation) shall be used to enforce these authorized boundaries, isolating CUI-processing systems from general-purpose corporate networks and guest access points.
Boundary protections capable of monitoring inbound and outbound network traffic and controlling access based on advanced rules, shall be used at key internal and external boundaries.
Firewalls at both gateways and endpoint devices shall be configured to deny traffic by default and allow traffic by exception. All network ports and protocols not specifically required for business operations shall be disabled or blocked at the boundary. This configuration shall include rules to whitelist or blacklist internet sites based on current threat intelligence and previous incidents and prevent software from creating unauthorized connections.
DNS filtering shall be implemented at gateways and on remote worker endpoints to restrict web browsing and other communications sessions from accessing high-risk domains.
VPN connections to the internal network are not permitted to use "split tunneling." When a device is connected via VPN, all its traffic must be routed through the VPN and the corporate firewall. This policy does not apply to connections that are inherently untrusted, like those to a public cloud service.
When Platform-as-a-Service (PaaS) and Infrastructure-as-a-Service (IaaS) cloud providers are used to host systems, firewalls shall be configured on a deny-by-default basis, with specific rules to allow only necessary point-to-point communications.
The organization shall limit the number of external network connections to the system to the absolute minimum necessary for business operations. All authorized external connections must be justified by a documented business need and reviewed annually to determine if the connection remains essential. Redundant or legacy connections shall be terminated immediately to minimize the organization's external attack surface.
CMMC Objectives Covered in This Section:
Publicly accessible systems, such as web servers, shall be separated from internal networks either by using deny-by-default firewall policies or by physical separation.
Information systems that are publicly accessible shall not be used to process, store, or transmit CUI. Any internal system components that communicate with public-facing systems must do so through a secured proxy or gateway that performs stateful inspection of the traffic.
CMMC Objectives Covered in This Section:
Systems shall utilize session protocols that are resistant to man-in-the-middle attacks, such as HTTPS or Kerberos, to protect the authenticity of network communication sessions.
Unique session identifiers (tokens) shall be protected from unauthorized disclosure and shall be invalidated immediately upon session termination or user logout to prevent session hijacking.
CMMC Objectives Covered in This Section:
All transmission of covered or confidential information over less trusted or public networks (including remote access connections, file transfers, and web sessions) must be secured using identified industry-standard cryptographic mechanisms (e.g., TLS 1.2+, IPsec/IKEv2) and approved architectures (e.g., Host-to-Gateway, SSL Tunneling). Use of deprecated protocols or non-standard architectures is prohibited.
All applications and devices that transmit Controlled Unclassified Information (CUI) must encrypt communications to protect the data while in transit. Encryption must be provided by a FIPS-validated cryptographic module (FIPS 140-2 or higher).
If secure encryption is not possible, the application or device must be disconnected from the network until appropriate physical safeguards for CUI can be established.
CMMC Objectives Covered in This Section:
Any applications or operating systems that may be used to transmit or store Controlled Unclassified Information (CUI) shall be configured to utilize FIPS 140-2 validated cryptography unless alternative, approved physical safeguards are identified and implemented.
Encryption must be provided by a FIPS-validated cryptographic module (FIPS 140-2 or higher). The Security Officer shall maintain a list of NIST certificate numbers for all cryptographic modules used to protect CUI.
CMMC Objectives Covered in This Section:
Cryptographic keys shall be generated using FIPS-compliant mechanisms (e.g., approved random number generators) to ensure sufficient bit-strength.
Once established, cryptographic keys shall be recorded in the Access Management Database and tracked throughout their lifecycle. This record shall include, at a minimum, the key identifier, its installation location(s), the location of any backup file, the designated responsible person, and the key's expiration date.
Cryptographic keys must be stored in secure locations with access restricted to authorized personnel. This includes physical safes for offline keys and FIPS-validated hardware security modules (HSM), encrypted key vaults, or secure digital repositories with restricted access controls for online keys.
Permanent, non-repudiable logs detailing key generation, storage, use, and/or destruction shall be maintained within the Service Request system or Change Management Database. Access to these logs shall be restricted to prevent unauthorized modification.
For each system that uses cryptographic keys, maintenance procedures shall be documented. These procedures must address, at a minimum: how to renew the cryptographic key; how to report a key compromise and revoke the key; how to monitor key and certificate status; and how to restore a backup key if a system rebuild is necessary.
Upon decommissioning of a system or expiration of a key, the organization shall perform cryptographic erasure (sanitization) to ensure the keys cannot be recovered or reused.
CMMC Objectives Covered in This Section:
Network connections shall be automatically terminated at the end of a session (user logout). Internal connections are automatically terminated after 24 hours, regardless of activity. Remote access connections are automatically terminated after 60 minutes, regardless of activity.
CMMC Objectives Covered in This Section:
If a device will be used by multiple users, the device shall be configured to prevent shared system hardware from being used to pass information from one user to another. To enforce this, operating systems and applications shall be configured to clear volatile memory and temporary storage buffers upon session termination or when resources are reallocated to a different process.
CMMC Objectives Covered in This Section:
All mobile code, including but not limited to technologies such as Flash, Java, and ActiveX, shall be disabled unless it has been formally reviewed and explicitly listed as authorized within the Configuration Management Database. The use of mobile code is restricted and managed via technical configuration policies (e.g., GPOs, browser settings). Mobile code may only be enabled if it has been formally reviewed and explicitly listed as authorized within the Configuration Management Database.
Standard web browser technologies, such as signed JavaScript from trusted origins, are permitted for business operations, provided they are monitored by the endpoint protection system. Any mobile code that requires local administrative privileges to execute is strictly prohibited.
CMMC Objectives Covered in This Section:
The use of Voice over Internet Protocol (VoIP) technologies shall be controlled by isolating VoIP traffic on a dedicated, secure Virtual Local Area Network (VLAN) and restricting access via firewall rules.
VoIP communications shall utilize encrypted signaling and media protocols (e.g., SIPS and SRTP) where technically feasible to protect the confidentiality of voice conversations. External VoIP traffic must be routed through a secure, FIPS-validated gateway.
CMMC Objectives Covered in This Section:
Collaborative Computing Devices are defined as video teleconference systems and conference room speaker phones; this definition does not include screen sharing, remote control, or meeting software installed on workstations. When source-selecting a collaborative computing device, it shall be verified that it cannot be activated remotely and that it provides a clear physical or visual indication to nearby users when it is active. The remote activation of collaborative computing devices is strictly prohibited.
All collaboration equipment and remote-control software shall provide a clear indication to the user present at the device when they are in use. To ensure local control, such systems must not be capable of remote activation; instead, the user present at the device must manually start any session. Furthermore, the local user shall have the ability to disconnect the remote-control session, as well as turn off voice and video, at any time.
Collaboration software and equipment that do not meet these requirements for transparency and control are not authorized for use within organizational systems.
CMMC Objectives Covered in This Section:
FedRAMP guidance on how to write a control implementation statement states the following:
Write your policies before you start drafting your security plan. K2 GRC shows you exactly how each part of your policy connects to your security goals. This starts with selecting an objective to document.
After selecting a criteria, K2 GRC shows policy statements relevant to that criteria. The input screen shows the specific policy name and the statement’s number. This enables users to cite relevant policy sections within the control narratives. The system aggregates these control narratives to populate the system security plan (SSP).
Leaving your network unprotected is like leaving the keys in your door. The stress of a potential data leak or a failed audit can keep any leader up at night. You shouldn't have to worry if your sensitive data is slipping through the cracks.
The System and Communications Protection domain turns a vulnerable network into a fortress. By setting boundaries and encrypting data, you take command of your security. Don’t wait for a breach to find out where your walls are weak.
Our System and Communications Protection Policy template gives you the blueprint. It simplifies the complex world into an actionable plan. Download the policy template today and give your data the protection it deserves.
