System and Communications Protection (SC)¶

Domain: System and Communications Protection (SC)
Requirements in this domain: 16
Assessment Objectives in this domain: 41

SC.L2-3.13.1¶

SC.L2-3.13.1[a]¶

Assessment Objective

the external system boundary is defined.

Collection Approach: Document

Potential Evidence Examples

SSP and network diagram clearly depicting the external system boundary, including any cloud provider(s) and their FedRAMP Moderate (or equivalent) authorization status.

Assessment Guide – Further Discussion

What are the external system boundary components that make up the entry and exit points for data flow (e.g., firewalls, gateways, cloud service boundaries), behind which all system components that handle regulated data are contained? What are the supporting system components necessary for the protection of regulated data [a]?

SC.L2-3.13.1[b]¶

Assessment Objective

key internal system boundaries are defined.

Collection Approach: Document

Potential Evidence Examples

SSP and network diagram identifying key internal system boundaries (e.g., segmentation between the CUI enclave and the general business network).

Assessment Guide – Further Discussion

What are the internal system boundary components that make up the entry and exit points for key internal data flow (e.g., internal firewalls, routers, any devices that can bridge the connection between one segment of the system and another) that separate segments of the internal network – including devices that separate internal network segments such as development and production networks as well as a traditional Demilitarized Zone (DMZ) at the edge of the network [b]?

SC.L2-3.13.1[c]¶

Assessment Objective

communications are monitored at the external system boundary.

Collection Approach: Screen Share

Potential Evidence Examples

Screen share of the boundary logging/monitoring device (e.g., firewall, IDS/IPS, or SIEM ingesting boundary traffic) showing communications at the external boundary are actively monitored.

Assessment Guide – Further Discussion

Is data flowing in and out of the external and key internal system boundaries monitored (e.g., connections are logged and able to be reviewed, suspicious traffic generates alerts) [c,d]?

SC.L2-3.13.1[d]¶

Assessment Objective

communications are monitored at key internal boundaries.

Collection Approach: Screen Share

Potential Evidence Examples

Screen share of the internal-boundary logging/monitoring device configuration showing communications at key internal boundaries (e.g., between the CUI enclave and the rest of the network) are actively monitored.

Assessment Guide – Further Discussion

Is data flowing in and out of the external and key internal system boundaries monitored (e.g., connections are logged and able to be reviewed, suspicious traffic generates alerts) [c,d]?

SC.L2-3.13.1[e]¶

Assessment Objective

communications are controlled at the external system boundary.

Collection Approach: Screen Share

Potential Evidence Examples

Screen share of the external boundary device's rule base/ACLs (e.g., perimeter firewall) showing communications are controlled per the defined information-flow policy.

Assessment Guide – Further Discussion

Is data traversing the external and internal system boundaries controlled such that connections are denied by default and only authorized connections are allowed [e,f]?

SC.L2-3.13.1[f]¶

Assessment Objective

communications are controlled at key internal boundaries.

Collection Approach: Screen Share

Potential Evidence Examples

Screen share of the internal boundary device's rule base/ACLs (e.g., internal segmentation firewall or router ACL) showing communications between internal zones are controlled.

Assessment Guide – Further Discussion

Is data traversing the external and internal system boundaries controlled such that connections are denied by default and only authorized connections are allowed [e,f]?

SC.L2-3.13.1[g]¶

Assessment Objective

communications are protected at the external system boundary.

Collection Approach: Screen Share

Potential Evidence Examples

Screen share of external boundary protection configurations (e.g., IPS/IDS signatures active, email gateway filtering, next-gen firewall threat prevention, TLS termination) showing communications are actively protected, not just permitted/denied.

Assessment Guide – Further Discussion

Is data flowing in and out of the external and key internal system boundaries protected (e.g., applying encryption when required or prudent, tunneling traffic as needed) [g,h]?

SC.L2-3.13.1[h]¶

Assessment Objective

communications are protected at key internal boundaries.

Collection Approach: Screen Share

Potential Evidence Examples

Screen share of internal boundary protection configurations (e.g., internal IPS/IDS, VLAN isolation, malware protection at internal chokepoints) showing communications at key internal boundaries are actively protected.

Assessment Guide – Further Discussion

Is data flowing in and out of the external and key internal system boundaries protected (e.g., applying encryption when required or prudent, tunneling traffic as needed) [g,h]?

SC.L2-3.13.2¶

SC.L2-3.13.2[a]¶

Assessment Objective

architectural designs that promote effective information security are identified.

Collection Approach: Document

Potential Evidence Examples

Enterprise architecture document, network diagram, or Configuration Management Policy showing the organization has identified architectural designs (e.g., network segmentation, defense-in-depth layering) that promote effective information security.

Assessment Guide – Further Discussion

Does the organization have a defined system architecture [a,d]?

SC.L2-3.13.2[b]¶

Assessment Objective

software development techniques that promote effective information security are identified.

Collection Approach: Document

Potential Evidence Examples

Software Development Life Cycle (SDLC) Policy or secure-coding standard identifying development techniques (e.g., input validation, code review, secure coding guidelines) that promote effective information security, if the organization develops software.

SC.L2-3.13.2[c]¶

Assessment Objective

systems engineering principles that promote effective information security are identified.

Collection Approach: Document

Potential Evidence Examples

Systems Engineering Policy/standard (e.g., defense-in-depth, least-privilege-by-design principles) identifying engineering principles the organization applies to promote effective information security.

SC.L2-3.13.2[d]¶

Assessment Objective

identified architectural designs that promote effective information security are employed.

Collection Approach: Artifact

Potential Evidence Examples

CCB minutes, current network diagrams, or project-plan artifacts showing the identified architectural designs from [a] are actually implemented in the production environment.

Assessment Guide – Further Discussion

• Does the organization have a defined system architecture [a,d]?
• Are system security engineering principles applied in the specification, design, development and implementation of the systems [d,e,f]?

SC.L2-3.13.2[e]¶

Assessment Objective

identified software development techniques that promote effective information security are employed.

Collection Approach: Artifact

Potential Evidence Examples

CCB minutes, static/dynamic code-scan results, or code-repository configuration showing the identified secure development techniques from [b] are actually applied in the SDLC.

Assessment Guide – Further Discussion

Are system security engineering principles applied in the specification, design, development and implementation of the systems [d,e,f]?

SC.L2-3.13.2[f]¶

Assessment Objective

identified systems engineering principles that promote effective information security are employed.

Collection Approach: Artifact

Potential Evidence Examples

CCB minutes, configuration-management records, or patch/lifecycle-management process artifacts showing the identified systems engineering principles from [c] are actually applied.

Assessment Guide – Further Discussion

Are system security engineering principles applied in the specification, design, development and implementation of the systems [d,e,f]?

SC.L2-3.13.3¶

SC.L2-3.13.3[a]¶

Assessment Objective

user functionality is identified.

Collection Approach: Document

Potential Evidence Examples

SSP or Acceptable Use Policy identifying which functionality is available to standard/end users.

SC.L2-3.13.3[b]¶

Assessment Objective

system management functionality is identified.

Collection Approach: Document

Potential Evidence Examples

SSP or Privileged Access Agreement identifying which functionality is reserved for system-management/administrative use.

SC.L2-3.13.3[c]¶

Assessment Objective

user functionality is separated from system management functionality.

Collection Approach: Screen Share

Potential Evidence Examples

Screen share of the technical separation between user and administrative functionality — e.g., administrators must connect through a dedicated jump box/PAW, or system-management consoles are inaccessible from standard user desktops/accounts.

Assessment Guide – Further Discussion

Are physical or logical controls used to separate user functionality from system management-related functionality (e.g., to ensure that administration (e.g., privilege) options are not available to general users) [c]?

SC.L2-3.13.4¶

SC.L2-3.13.4[a]¶

Assessment Objective

unauthorized and unintended information transfer via shared system resources is prevented.

Collection Approach: Screen Share

Potential Evidence Examples

Screen share of OS/hypervisor/application configuration preventing unauthorized information transfer via shared resources — e.g., memory/object reuse protections, VDI session isolation, secure print-queue clearing, or certificate/media reuse and destruction policy documentation.

Assessment Guide – Further Discussion

Are shared system resources identified and documented [a]?

SC.L2-3.13.5¶

SC.L2-3.13.5[a]¶

Assessment Objective

publicly accessible system components are identified.

Collection Approach: Document

Potential Evidence Examples

SSP and network diagram identifying which system components are publicly accessible (e.g., web server, mail relay in a DMZ).

Assessment Guide – Further Discussion

Are any system components reachable by the public (e.g., internet-facing web servers, VPN gateways, publicly accessible cloud services) [a]?

SC.L2-3.13.5[b]¶

Assessment Objective

subnetworks for publicly accessible system components are physically or logically separated from internal networks.

Collection Approach: Artifact

Potential Evidence Examples

Network diagram, VLAN/subnet documentation, or firewall configuration showing the subnetwork(s) hosting publicly accessible components (e.g., DMZ) are physically or logically separated from the internal CUI network.

Assessment Guide – Further Discussion

Are publicly accessible system components on physically or logically separated subnetworks (e.g., isolated subnetworks using separate, dedicated VLAN segments such as DMZs) [b]?

SC.L2-3.13.6¶

SC.L2-3.13.6[a]¶

Assessment Objective

network communications traffic is denied by default.

Collection Approach: Screen Share

Potential Evidence Examples

Screen share of the firewall's default policy showing network traffic is denied by default (default-deny posture).

Assessment Guide – Further Discussion

Are network communications traffic on relevant system components (e.g., host and network firewalls, routers, gateways) denied by default (e.g., configured with an implicit deny rule that takes effect in the absence of any other matching traffic rules) [a]?

SC.L2-3.13.6[b]¶

Assessment Objective

network communications traffic is allowed by exception.

Collection Approach: Screen Share

Potential Evidence Examples

Screen share of the firewall rule base showing traffic is allowed only through explicit exception rules layered on top of the default-deny posture.

Assessment Guide – Further Discussion

Are network communications traffic on relevant system components (e.g., host and network firewalls, routers, gateways) allowed by exception (e.g., configured with explicit allow rules that takes effect only when network traffic matches one or more rules) [b]?

SC.L2-3.13.7¶

SC.L2-3.13.7[a]¶

Assessment Objective

remote devices are prevented from simultaneously establishing non-remote connections with the system and communicating via some other connection to resources in external networks (i.e., split tunneling).

Collection Approach: Screen Share

Potential Evidence Examples

Screen share of the VPN client/concentrator split-tunneling setting showing it is disabled, confirming remote devices cannot simultaneously access the internal network and an external network through the same connection.

Assessment Guide – Further Discussion

Does the system prevent remote devices that have established connections (e.g., remote laptops) with the system from communicating outside that communications path with resources on uncontrolled/unauthorized networks [a]?

SC.L2-3.13.8¶

SC.L2-3.13.8[a]¶

Assessment Objective

cryptographic mechanisms intended to prevent unauthorized disclosure of CUI are identified.

Collection Approach: Document

Potential Evidence Examples

SSP, PKI policy, or data-protection standard identifying the specific cryptographic mechanism used to prevent unauthorized disclosure of CUI in transit (e.g., TLS 1.2+ for web/email, S/MIME for email attachments).

SC.L2-3.13.8[b]¶

Assessment Objective

alternative physical safeguards intended to prevent unauthorized disclosure of CUI are identified.

Collection Approach: Document

Potential Evidence Examples

SSP or Physical Security Policy identifying any alternative physical safeguards used in place of cryptography where encryption is not feasible (e.g., protected distribution system for cabling, courier hand-carry procedures).

SC.L2-3.13.8[c]¶

Assessment Objective

either cryptographic mechanisms or alternative physical safeguards are implemented to prevent unauthorized disclosure of CUI during transmission.

Collection Approach: Screen Share

Potential Evidence Examples

Screen share of the actual encryption configuration protecting CUI in transit (e.g., TLS settings on the mail/web server, VPN cipher configuration, or SFTP configuration), citing FIPS validation where applicable, or documentation of the alternative physical safeguard actually in place.

Assessment Guide – Further Discussion

Are cryptographic mechanisms used to prevent unauthorized disclosure of information during transmission unless otherwise protected by alternative physical measures (e.g., PDS) [c]?

SC.L2-3.13.9¶

SC.L2-3.13.9[a]¶

Assessment Objective

a period of inactivity to terminate network connections associated with communications sessions is defined.

Collection Approach: Document

Potential Evidence Examples

SSP or Network Communications Policy defining the period of inactivity that triggers termination of a network connection associated with a communications session.

Assessment Guide – Further Discussion

Are the network connections requiring management and time-out for inactivity documented [a]?

SC.L2-3.13.9[b]¶

Assessment Objective

network connections associated with communications sessions are terminated at the end of the sessions.

Collection Approach: Screen Share

Potential Evidence Examples

Screen share of firewall/VPN/web-server session-timeout configuration or a session log showing network connections are terminated at the end of a communications session (e.g., logout event closes the connection).

SC.L2-3.13.9[c]¶

Assessment Objective

network connections associated with communications sessions are terminated after the defined period of inactivity.

Collection Approach: Screen Share

Potential Evidence Examples

Screen share of firewall/VPN/web-server idle-timeout configuration or a session log showing connections are terminated after the defined inactivity period elapses.

Assessment Guide – Further Discussion

Are the network connections requiring management and time-out for inactivity configured and implemented [c]?

SC.L2-3.13.10¶

SC.L2-3.13.10[a]¶

Assessment Objective

cryptographic keys are established whenever cryptography is employed.

Collection Approach: Artifact

Potential Evidence Examples

PKI/Certificate Management Policy and screen share of the certificate authority or key-management system showing cryptographic keys are generated/established through a controlled process whenever cryptography is used.

Assessment Guide – Further Discussion

Are cryptographic keys established whenever cryptography is employed (e.g., digital signatures, authentication, authorization, transport, or other cryptographic mechanisms) [a]?

SC.L2-3.13.10[b]¶

Assessment Objective

cryptographic keys are managed whenever cryptography is employed.

Collection Approach: Artifact

Potential Evidence Examples

PKI/Certificate Management Policy and screen share of the key-management console showing keys are actively managed post-issuance (e.g., renewal, rotation, revocation, access-controlled key storage).

Assessment Guide – Further Discussion

Are cryptographic keys maintained whenever cryptography is employed (e.g., key storage, backup, recovery, revocation, destruction, etc.) [b]?

SC.L2-3.13.11¶

SC.L2-3.13.11[a]¶

Assessment Objective

FIPS-validated cryptography is employed to protect the confidentiality of CUI.

Collection Approach: Screen Share

Potential Evidence Examples

Screen share of "FIPS mode" (or equivalent) enabled on each cryptographic implementation protecting CUI confidentiality (e.g., VPN, wireless controller, disk-encryption tool, email encryption plugin), citing the applicable FIPS 140-2/140-3 validation certificate for each module — the algorithm name alone (e.g., "AES-256") is not sufficient evidence.

Assessment Guide – Further Discussion

Is cryptography implemented to protect the confidentiality of CUI at rest and in transit, through the configuration of systems and applications or through the use of encryption tools [a]?

SC.L2-3.13.12¶

SC.L2-3.13.12[a]¶

Assessment Objective

collaborative computing devices are identified.

Collection Approach: Document

Potential Evidence Examples

SSP or network diagram identifying collaborative computing devices in use (e.g., conference-room cameras/microphones, VTC systems, collaboration platforms with camera/mic access).

SC.L2-3.13.12[b]¶

Assessment Objective

collaborative computing devices provide indication to users of devices in use.

Collection Approach: Physical Review

Potential Evidence Examples

Physical inspection/photo of a collaborative computing device (e.g., a VTC camera/mic unit) confirming it provides a visible/audible indication (e.g., an active light) when in use.

Assessment Guide – Further Discussion

Are the collaborative computing devices configured to provide indication to users when in use (e.g., a light, text notification, or audio tone) or are users alerted before entering a space (e.g., written notice posted outside the space) where they are in use [b]?

SC.L2-3.13.12[c]¶

Assessment Objective

remote activation of collaborative computing devices is prohibited.

Collection Approach: Artifact

Potential Evidence Examples

Screen share of the collaborative computing device's configuration/console showing remote activation is disabled or not possible (e.g., camera/mic cannot be triggered without local physical action).

Assessment Guide – Further Discussion

Are the collaborative computing devices configured to prevent them from being turned on without user interaction or consent [c]?

SC.L2-3.13.13¶

SC.L2-3.13.13[a]¶

Assessment Objective

use of mobile code is controlled.

Collection Approach: Screen Share

Potential Evidence Examples

Screen share of controls restricting mobile code (e.g., browser settings blocking unsigned ActiveX/Java applets, GPO restricting script execution, endpoint-protection mobile-code policy, secure web gateway configuration).

Assessment Guide – Further Discussion

Are there defined limits of mobile code usage and established usage restrictions, which specifically authorize use of mobile code (e.g., Java, JavaScript, ActiveX, PDF, Flash, Shockwave, Postscript, VBScript) within the information system [a]?

SC.L2-3.13.13[b]¶

Assessment Objective

use of mobile code is monitored.

Collection Approach: Screen Share

Potential Evidence Examples

Screen share of the SIEM or security console showing mobile-code-related events/alerts are actively monitored (e.g., blocked script execution logs).

Assessment Guide – Further Discussion

Is the use of mobile code documented, monitored, and managed (e.g., Java, JavaScript, ActiveX, PDF, Flash, Shockwave, Postscript, VBScript) [b]?

SC.L2-3.13.14¶

SC.L2-3.13.14[a]¶

Assessment Objective

use of Voice over Internet Protocol (VoIP) technologies is controlled.

Collection Approach: Artifact

Potential Evidence Examples

Screen share of VoIP-specific network controls (e.g., dedicated voice VLAN, ACLs restricting VoIP traffic, session border controller configuration) showing use of VoIP is controlled.

Assessment Guide – Further Discussion

Are VoIP technologies (e.g., approved and managed products or solutions) that may or may not be used in the system defined [a]?

SC.L2-3.13.14[b]¶

Assessment Objective

use of Voice over Internet Protocol (VoIP) technologies is monitored.

Collection Approach: Artifact

Potential Evidence Examples

Screen share of VoIP monitoring (e.g., SIEM ingestion of call-manager/session-border-controller logs) showing VoIP usage is actively monitored.

Assessment Guide – Further Discussion

Is monitoring for unapproved VoIP technologies or unapproved use of the allowed VoIP solutions employed [b]?

SC.L2-3.13.15¶

SC.L2-3.13.15[a]¶

Assessment Objective

the authenticity of communications sessions is protected.

Collection Approach: Screen Share

Potential Evidence Examples

Screen share of the cryptographic protocol configuration (e.g., TLS certificate validation settings, SSH host-key verification, Kerberos mutual authentication) demonstrating communications-session authenticity is protected against session hijacking/spoofing.

Assessment Guide – Further Discussion

• Is a communications protocol used that ensures the sending and receiving parties do not change during a communications session [a]?
• Are controls in place to validate the identities and information transmitted to protect against man-in-the-middle attacks, session hijacking, and insertion of false information into communications sessions [a]?

SC.L2-3.13.16¶

SC.L2-3.13.16[a]¶

Assessment Objective

the confidentiality of CUI at rest is protected.

Collection Approach: Artifact

Potential Evidence Examples

Screen share of encryption-at-rest configuration protecting CUI (e.g., full-disk encryption status such as BitLocker with FIPS validation, database/SAN encryption settings, encrypted backup configuration), citing the applicable FIPS certificate.

Assessment Guide – Further Discussion

Is the confidentiality of CUI at rest protected using encryption of storage devices and/or appropriate physical methods [a]?