System and Communications Protection Policy

Approval #

Revision History #

Review cycle: Every year, under the Policy and Procedure Management Policy.

1. Purpose and Scope #

In this policy, the CISO sets the Organization’s requirements for system and communications protection in every information system that the Organization operates or that others operate for it. The CISO issues the policy under these authorities:

• The Federal Information Security Modernization Act (FISMA) of 2014.
• National Institute of Standards and Technology (NIST) Special Publication 800-53 Revision 5.
• Office of Management and Budget (OMB) Circular A-130, Managing Information as a Strategic Resource.
• The OMB memoranda and Executive Orders that apply.

The Organization also uses this policy to carry out the NIST Cybersecurity Framework (CSF) 2.0, which Executive Order 13800 and OMB Circular A-130 require.

1.1 Program Objectives #

This policy covers system and communications protection. The Organization relies on its network architecture to protect systems, because it cannot trust the network itself. The Organization must implement defense in depth and zero trust segmentation. It must manage boundary protection that denies traffic by default and use Federal Information Processing Standards (FIPS) 140-3 validated cryptography for data in transit. It must also keep Domain Name System (DNS) integrity under Binding Operational Directive (BOD) 18-01 and separate user and management functions. It must design systems to withstand denial-of-service attacks. It must isolate High Value Assets behind tiered boundary protections under the Cybersecurity and Infrastructure Security Agency (CISA) High Value Asset (HVA) overlay.

This policy applies to everyone in the program: executives who accept risk, System Owners who fund the controls, security officers who run them, and every user. By following it, the Organization meets its FISMA obligations for this control family and shows its maturity in the annual Inspector General (IG) FISMA evaluation. The Organization’s target is Level 4 (Managed and Measurable). The CISO tracks progress with the performance measures and the improvement commitments later in this policy.

1.2 CSF 2.0 Alignment #

The controls in this policy support these CSF 2.0 categories:

• PR.DS — Data Security (Protect function)
• PR.PS — Platform Security (Protect function)
• PR.IR — Technology Infrastructure Resilience (Protect function)

These categories fall under the Protect function(s) of CSF 2.0. The Organization’s CSF 2.0 Profile maps each category to the NIST SP 800-53 controls in this policy.

This policy covers every system and communications protection control in the low baseline of FIPS 200 and NIST SP 800-53B:

• SC-01 — Policy and Procedures
• SC-05 — Denial-of-service Protection
• SC-07 — Boundary Protection
• SC-07(24) — Personally Identifiable Information
• SC-08 — Transmission Confidentiality and Integrity
• SC-08(1) — Cryptographic Protection
• SC-12 — Cryptographic Key Establishment and Management
• SC-13 — Cryptographic Protection
• SC-15 — Collaborative Computing Devices and Applications
• SC-20 — Secure Name/Address Resolution Service (Authoritative Source)
• SC-21 — Secure Name/Address Resolution Service (Recursive or Caching Resolver)
• SC-22 — Architecture and Provisioning for Name/Address Resolution Service
• SC-28 — Protection of Information at Rest
• SC-28(1) — Cryptographic Protection
• SC-39 — Process Isolation

2. Authority and References #

The CISO issues this policy under the authority of:

• FISMA 2014 (44 U.S.C. § 3551 et seq.) — Statutory mandate for federal information security programs
• NIST SP 800-53 Rev 5 — Security and Privacy Controls for Information Systems and Organizations
• OMB Circular A-130 — Managing Information as a Strategic Resource
• OMB Circular A-123 — Management’s Responsibility for Internal Control (revised March 10, 2026)
• NIST CSF 2.0 — Cybersecurity Framework (mandated by EO 13800 and OMB Circular A-130)
• EO 13800 — Strengthening the Cybersecurity of Federal Networks and Critical Infrastructure
• OMB M-22-09: Moving the U.S. Government Toward Zero Trust Cybersecurity Principles, January 26, 2022.
• OMB M-15-13: Policy to Require Secure Connections across Federal Websites and Web Services, June 8, 2015.
• OMB M-19-26: Update to the Trusted Internet Connections (TIC) Initiative, September 12, 2019.
• OMB M-26-15: Execution of the Migration to Post-Quantum Cryptography, June 24, 2026.
• OMB M-23-02: Migrating to Post-Quantum Cryptography, November 18, 2022.
• Executive Order 14028: Improving the Nation’s Cybersecurity, May 12, 2021.

2.1 Derived Governance Requirements #

The requirements below come from federal governance sources and apply to the SC control family. They add to the NIST SP 800-53 control requirements in the Policy section.

OMB M-22-09: Moving the U.S. Government Toward Zero Trust Cybersecurity Principles

• The organization must encrypt all data in transit and at rest using FIPS-validated cryptographic modules. DNS traffic must be encrypted (DoH or DoT) and all internal network traffic must be authenticated and encrypted. Deadline: FY 2024. (OMB M-22-09, §3(c)(i))
• The organization must segment networks by application and environment instead of relying on a flat network, with access controls and monitoring enforced in each segment. Deadline: FY 2024. (OMB M-22-09, §3(c)(ii))

NIST SP 800-207: Zero Trust Architecture

• The organization must encrypt all communication between resources end to end, even on internal networks presumed trusted, so that its security does not depend on network location. (NIST SP 800-207, §3.3)

CISA BOD 23-02: Mitigating the Risk of Internet-Exposed Management Interfaces

• The organization must implement network segmentation to isolate management interfaces from production traffic. Management plane access must be separated from data plane access. (CISA BOD 23-02, §2)

OMB M-23-02: Migrating to Post-Quantum Cryptography

• The organization must plan for migration to quantum-resistant cryptography, with the goal of mitigating quantum risk by 2035. The inventory must include cryptographic algorithm types, data lifecycle characteristics, and system ownership. Deadline: 2035. (OMB M-23-02, §II.B)

OMB M-19-03: Strengthening Cybersecurity through the High Value Asset Program

• The organization must isolate and segment High Value Assets from broader agency networks using boundary protections and architecture reviews so that compromise of general-purpose environments does not directly expose HVAs. (OMB M-19-03, §B)

CISA High Value Asset (HVA) Control Overlay v1.0

• The organization must protect HVA authorization boundaries with boundary protection devices (gateways, routers, guards, encrypted tunnels, firewalls, application proxies) at the boundary and at tiered points within it, per the overlay’s SC-7 selection rationale. (CISA HVA Control Overlay v1.0, SC-7)

OMB M-26-15: Execution of the Migration to Post-Quantum Cryptography

• The organization must execute a prioritized migration of cryptographic systems in every information system the organization owns or operates, with the objective of mitigating as much quantum risk as feasible by December 31, 2030. Prioritize high-impact systems, High Value Assets, and any other system holding highly sensitive data or judged particularly vulnerable to attack by a cryptanalytically relevant quantum computer. Deadline: 2030-12-31. (OMB M-26-15, Action One)
• The organization must support TLS 1.3 with post-quantum or hybrid key exchange, adopt crypto-agility (algorithm choices in external configuration rather than compiled in; agile key management infrastructure), fold PQC upgrades into planned cloud migrations, development lifecycles, and hardware refreshes, and identify systems that cannot support PQC or hybrid cryptography for priority replacement or decommissioning. (OMB M-26-15, Action One and Appendix)

Executive Order 14412: Securing the Nation Against Advanced Cryptographic Attacks

• The organization must review the inventory of High Value Assets and high-impact systems, then move every one of them to PQC for key establishment by December 31, 2030, and to PQC for digital signatures by December 31, 2031. Deadline: 2030-12-31 (key establishment); 2031-12-31 (digital signatures). (EO 14412, §4(b)(i)-(iii); OMB M-26-15)

OMB M-15-13: Policy to Require Secure Connections across Federal Websites and Web Services

• The organization must serve every publicly accessible website and web service only over a secure HTTPS connection, with HTTP Strict Transport Security (HSTS) enabled. Deadline: 2016-12-31. (OMB M-15-13)

OMB M-19-26: Update to the Trusted Internet Connections (TIC) Initiative

• The organization must keep an accurate inventory of network connections, keep network and system boundary policies current with Trusted Internet Connections (TIC) 3.0, and name the TIC use cases the Organization allows. (OMB M-19-26)

CISA BOD 18-01: Enhance Email and Web Security

• The organization must serve all public websites and web services over HTTPS only with HTTP Strict Transport Security (HSTS), and identify domains that can be HSTS preloaded. (CISA BOD 18-01, Required Actions)
• The organization must disable SSLv2 and SSLv3, and the 3DES and RC4 ciphers, on all internet-facing web and mail servers. (CISA BOD 18-01, Required Actions)
• The organization must configure all internet-facing mail servers to offer STARTTLS. (CISA BOD 18-01, Required Actions)
• The organization must publish valid Sender Policy Framework (SPF) and DMARC records for every second-level domain, with CISA’s address among the DMARC aggregate report recipients. (CISA BOD 18-01, Required Actions)
• The organization must set a DMARC policy of reject (p=reject) for all second-level domains and mail-sending hosts. (CISA BOD 18-01, Required Actions)

NIST CMVP: FIPS 140-3 Transition Effort

• The organization must buy only cryptographic modules that hold an active FIPS 140-3 validation, because FIPS 140-2 certificates moved to the CMVP Historical list in September 2026. Deadline: September 2026. (FIPS 140-3; NIST CMVP FIPS 140-3 Transition; 40 U.S.C. § 11331)
• The organization must track each system that still uses a FIPS 140-2 module after September 2026 as a plan of action and milestones item until the module is replaced. (FIPS 140-3; NIST CMVP FIPS 140-3 Transition)

OMB M-21-07: Completing the Transition to Internet Protocol Version 6 (IPv6)

• The organization must keep an IPv6 implementation plan that moves at least 80 percent of IP-enabled assets on federal networks to IPv6-only. Deadline: End of FY 2025 (80 percent IPv6-only). (OMB M-21-07)
• The organization must list each system that cannot move to IPv6-only, with a schedule to replace or retire it. (OMB M-21-07)
• The organization must enable IPv6 on every new networked federal information system when it is deployed. Deadline: Starting in FY 2023. (OMB M-21-07)
• The organization must make sure every system that supports network operations or enterprise security, such as firewalls, intrusion detection, and logging, can operate in an IPv6-only environment. (OMB M-21-07)

NIST SP 800-52 Rev 2: Guidelines for the Selection, Configuration, and Use of Transport Layer Security (TLS) Implementations

• The organization should configure servers for government-only applications to use TLS 1.2 or later, and never to use TLS 1.0, SSL 3.0, or SSL 2.0. (NIST SP 800-52 Rev 2, §3.1)
• The organization should support TLS 1.3 on servers and clients that use TLS. Deadline: January 1, 2024. (NIST SP 800-52 Rev 2, §3.1)

NIST SP 800-57 Part 1 Rev 5: Recommendation for Key Management: Part 1 - General

• The organization should document key management for each system, including a cryptoperiod for each key type and how keys are generated, distributed, stored, backed up, archived, and destroyed. (NIST SP 800-57 Part 1 Rev 5, §§5-8)
• The organization should keep a key compromise recovery plan that covers revoking and replacing affected keys and notifying the parties that rely on them. (NIST SP 800-57 Part 1 Rev 5, §6)

NIST SP 800-119: Guidelines for the Secure Deployment of IPv6

• The organization should detect and examine IPv6 traffic on every network, including networks meant to carry only IPv4, so that no device uses IPv6 unseen. (NIST SP 800-119)

3. Policy #

The Organization must implement and maintain its system and communications protection controls to meet the following requirements:

SC-01 — Policy and Procedures #

Baselines: Low / Moderate / High CSF 2.0: PR.DS (Data Security)

Requirement:

1. Develop, document, and disseminate to [Assignment: organization-defined personnel or roles — to be defined]:

1. [Selection (one or more): organization-level; mission/business-process-level; system-level — to be defined] system and communications protection policy that:

1. Addresses purpose, scope, roles, responsibilities, management commitment, coordination among organizational entities, and compliance; and
2. Is consistent with applicable laws, executive orders, directives, regulations, policies, standards, and guidelines; and

2. Procedures to facilitate the implementation of the system and communications protection policy and the associated system and communications protection controls;

2. Designate an [Assignment: organization-defined official — to be defined] to manage the development, documentation, and dissemination of the system and communications protection policy and procedures; and
3. Review and update the current system and communications protection:

1. Policy at least every 3 years and following significant changes; and
2. Procedures at least annually and following [Assignment: organization-defined events — to be defined].

Implementation guidance:

The Organization must keep a system and communications protection policy at the organization level and at the system level, with procedures that put each requirement into practice. The CISO must manage the development, documentation, and distribution of both documents. The CISO delivers them to the Authorizing Official, System Owners, Information System Security Officers (ISSOs), and key stakeholders when they are issued and after every revision. The policy and the procedures must stay consistent with the laws, executive orders, directives, and standards that apply to the Organization. That includes the encryption and segmentation requirements in OMB M-22-09 that shape this control family. The CISO must review and update the policy and the procedures every year. The CISO must also review them sooner whenever the components or technologies that carry communications functions change. A policy that no longer matches the architecture will produce an assessment finding.

SC-05 — Denial-of-service Protection #

Baselines: Low / Moderate / High CSF 2.0: PR.DS (Data Security), PR.PS (Platform Security), PR.IR (Technology Infrastructure Resilience)

Requirement:

1. Protect against the effects of the following types of denial-of-service events: at a minimum: ICMP (ping) flood, SYN flood, slowloris, buffer overflow attack, and volume attack; and
2. Employ the following controls to achieve the denial-of-service objective: [Assignment: organization-defined controls by type of denial-of-service event — to be defined].

Implementation guidance:

The Organization must protect its systems against denial-of-service attacks. At a minimum, the protections must cover SYN floods, Internet Control Message Protocol (ICMP) and ping floods, teardrop and ping-of-death malformed-packet attacks, peer-to-peer abuse, application-level floods, and distributed attacks. The safeguards must follow SANS denial-of-service guidance or an alternative that the CISO approves. System Owners must host public-facing services on the cloud platform infrastructure with the capacity and layout to absorb traffic surges. System Owners must keep internal applications unreachable from the open internet by publishing them only through the zero trust network access (ZTNA) service. Anyone who suspects a denial-of-service attack must report it to the ISSO immediately, and the ISSO must handle it as a security incident.

SC-07 — Boundary Protection #

Baselines: Low / Moderate / High CSF 2.0: PR.DS (Data Security), PR.PS (Platform Security)

Requirement:

1. Monitor and control communications at the external managed interfaces to the system and at key internal managed interfaces within the system;
2. Implement subnetworks for publicly accessible system components that are [Selection: physically; logically — to be defined] separated from internal organizational networks; and
3. Connect to external networks or systems only through managed interfaces consisting of boundary protection devices arranged in accordance with an organizational security and privacy architecture.

Implementation guidance:

The Organization must monitor and control traffic at every external interface and at key internal interfaces. The Organization must place publicly accessible components in subnetworks kept physically or logically apart from internal networks. Systems must connect to outside networks only through managed interfaces that fit the approved security architecture. The network engineering team must map each external connection to a Trusted Internet Connections (TIC) 3.0 use case the CISO approves under OMB M-19-26. Under OMB M-19-03 and the CISA HVA overlay, High Value Assets must sit behind boundary protections at the perimeter and at tiered points inside it. In the cloud platform, System Owners must segment networks by application and by environment. Outbound web traffic must leave only through the secure web gateway. The CISO must approve a new external connection before it carries traffic. Before a rule opens a system to the internet, the security operations team must scan it and confirm that no critical finding and no past-due high finding remain. The perimeter must not allow cleartext administrative or file-transfer protocols, such as Telnet and File Transfer Protocol. The CISO tracks the milestones for isolated network environments and encrypted DNS in the Zero Trust and identity, credential, and access management (ICAM) Implementation Plan (PLAN-ZT-001).

SC-07(24) — Personally Identifiable Information #

Baselines: Privacy

Requirement:

For systems that process personally identifiable information: (a) Apply the following processing rules to data elements of personally identifiable information: [Assignment: organization-defined processing rules — to be defined]; (b) Monitor for permitted processing at the external interfaces to the system and at key internal boundaries within the system; (c) Document each processing exception; and (d) Review and remove exceptions that are no longer supported.

Implementation guidance:

For each system that processes personally identifiable information (PII), the System Owner must enforce [SC-07(24) parameter 1 — to be defined] on PII data elements. The ISSO must monitor PII traffic at the system’s external interfaces and at the main internal boundaries between network segments. OMB M-22-09 requires each segment to enforce its own access controls and monitoring. The System Owner must document each exception to the processing rules, with its reason and the Privacy Officer’s approval. The System Owner must remove any exception that is no longer justified.

SC-08 — Transmission Confidentiality and Integrity #

Baselines: Low / Moderate / High CSF 2.0: PR.DS (Data Security)

Requirement:

Protect the [Selection (one or more): confidentiality; integrity — to be defined] of transmitted information.

Implementation guidance:

The Organization must protect the confidentiality and integrity of all transmitted information, on internal paths as well as external ones. Under OMB M-22-09, systems must encrypt traffic with FIPS-validated cryptographic modules and must encrypt DNS queries. System Owners must configure every Transport Layer Security (TLS) server to NIST SP 800-52 Rev 2, with TLS 1.2 at minimum and no Secure Sockets Layer (SSL), Rivest Cipher 4 (RC4), or 3DES. Every public website and web service must use Hypertext Transfer Protocol Secure (HTTPS) only and send the Strict Transport Security (HSTS) header, as OMB M-15-13 and CISA BOD 18-01 require. User traffic to applications must use ZTNA tunnels. Staff must send sensitive PII or Controlled Unclassified Information outside the Organization only through channels the CISO approves. The Security Operations Center must run data loss prevention on outbound email and web traffic. If a legacy interface cannot yet comply, the System Owner must document the exposure, apply compensating protections, and set a remediation date that the CISO accepts.

SC-08(1) — Cryptographic Protection #

Baselines: Low / Moderate / High

Requirement:

Implement cryptographic mechanisms to [Selection (one or more): prevent unauthorized disclosure of information; detect changes to information — to be defined] during transmission.

Implementation guidance:

The Organization must use cryptographic mechanisms on every transmission path to prevent unauthorized disclosure and to detect any change to information in transit. The modules must be FIPS-validated, as OMB M-22-09 requires. System Owners must make sure that sessions negotiate approved algorithms with integrity protection and must prohibit fallback to unprotected transport. A path that cannot support validated cryptography requires a documented exception that the CISO accepts.

SC-12 — Cryptographic Key Establishment and Management #

Baselines: Low / Moderate / High CSF 2.0: PR.DS (Data Security), PR.PS (Platform Security)

Requirement:

Establish and manage cryptographic keys when cryptography is employed within the system in accordance with the following key management requirements: In accordance with Federal requirements.

Implementation guidance:

The Organization must manage cryptographic keys under NIST SP 800-57 Part 1. The CISO must set a cryptoperiod for each key type using that guideline, and administrators must replace each key before its cryptoperiod ends. Each key must have a named owner. Administrators must protect secret and private keys inside the cryptographic module against unauthorized disclosure, modification, and substitution. They must protect public keys against unauthorized modification and substitution. Administrators must store keys apart from the data they protect. They must back up keys needed to recover encrypted data, but not private signing keys. System Owners must generate and hold keys for cloud workloads in FIPS-validated modules within the cloud platform. Anyone who suspects a key compromise must report it as a security incident. Under OMB M-23-02, the ISSO must keep an inventory of cryptographic systems for the move to quantum-resistant cryptography.

SC-13 — Cryptographic Protection #

Baselines: Low / Moderate / High CSF 2.0: PR.DS (Data Security), PR.PS (Platform Security)

Requirement:

1. Determine the [Assignment: organization-defined cryptographic uses — to be defined]; and
2. Implement the following types of cryptography required for each specified cryptographic use: FIPS-validated or NSA-approved cryptography.

Implementation guidance:

Wherever cryptography protects Organization information, the Organization must use validated modules. New purchases and deployments must use modules with an active FIPS 140-3 validation under the Cryptographic Module Validation Program. A module whose FIPS 140-2 validation has moved to the program’s Historical list may stay in service only under a plan of action and milestones (POA&M) item with a replacement date. The Authorizing Official must accept that risk. The defined uses of cryptography include protecting sensitive data on mobile devices and protecting stored passwords. They also include securing connections to the Organization’s public web services. System Owners must identify each place where their system uses cryptography. They must record the module and its validation, and replace any unvalidated implementation. The CISO must approve a deviation only when it has compensating protections and a remediation date.

SC-15 — Collaborative Computing Devices and Applications #

Baselines: Low / Moderate / High CSF 2.0: PR.DS (Data Security), PR.PS (Platform Security)

Requirement:

1. Prohibit remote activation of collaborative computing devices and applications with the following exceptions: no exceptions for computing devices; and
2. Provide an explicit indication of use to users physically present at the devices.

Implementation guidance:

No one may activate a collaborative computing device or application remotely unless the Chief Information Officer (CIO) or a designated representative authorizes it in writing. The authorization must name the permitted mechanism, its purpose, and the specific system on which it may operate. Collaborative devices and applications must give the people physically present a clear signal when they are active, so that no one is recorded without knowing it. System Owners must configure conferencing and collaboration equipment to these settings. The ISSO must verify the settings when equipment is installed or changed.

SC-20 — Secure Name/Address Resolution Service (Authoritative Source) #

Baselines: Low / Moderate / High CSF 2.0: PR.DS (Data Security), PR.PS (Platform Security)

Requirement:

1. Provide additional data origin authentication and integrity verification artifacts along with the authoritative name resolution data the system returns in response to external name/address resolution queries; and
2. Provide the means to indicate the security status of child zones and (if the child supports secure resolution services) to enable verification of a chain of trust among parent and child domains, when operating as part of a distributed, hierarchical namespace.

Implementation guidance:

The Organization’s authoritative name service must attach origin authentication and integrity verification data to every answer it returns to an external query. DNS administrators must sign the public zones so that resolvers can validate what they receive. DNS administrators must publish the delegation records that let parent and child domains form a chain of trust that resolvers can verify. System Owners for the public zones hosted in the cloud platform must keep the zones signed and must manage signing keys under change control. DNS administrators must handle a lapsed or broken signature as an operational incident, not as routine maintenance.

SC-21 — Secure Name/Address Resolution Service (Recursive or Caching Resolver) #

Baselines: Low / Moderate / High CSF 2.0: PR.DS (Data Security), PR.PS (Platform Security)

Requirement:

Request and perform data origin authentication and data integrity verification on the name/address resolution responses the system receives from authoritative sources.

Implementation guidance:

Recursive and caching resolvers that serve Organization clients must request origin authentication and integrity verification data on every answer from an authoritative source. The resolver must verify that data before it uses the answer. The Organization routes client DNS through the DNS filtering service. System Owners must make sure that resolution paths validate answers and do not simply forward them. A resolver must reject an answer that fails validation; it must not use the answer with a warning. Bypassing the protected resolution path requires a documented exception that the ISSO approves.

SC-22 — Architecture and Provisioning for Name/Address Resolution Service #

Baselines: Low / Moderate / High CSF 2.0: PR.DS (Data Security), PR.PS (Platform Security)

Requirement:

Ensure the systems that collectively provide name/address resolution service for an organization are fault-tolerant and implement internal and external role separation.

Implementation guidance:

The systems that together provide name and address resolution must keep resolving when a component fails. System Owners must run redundant instances placed so that no single failure stops resolution. The service must separate internal and external roles: the servers that answer the internet must not also serve internal clients, and internal resolution must not be reachable from outside. System Owners must host the external authoritative service on redundant cloud platform infrastructure and must keep internal resolution separate behind the boundary. Any change to the resolution architecture requires ISSO review before implementation.

SC-28 — Protection of Information at Rest #

Baselines: Low / Moderate / High CSF 2.0: PR.DS (Data Security), PR.PS (Platform Security)

Requirement:

Protect the [Selection (one or more): confidentiality; integrity — to be defined] of the following information at rest: [Assignment: organization-defined information at rest — to be defined].

Implementation guidance:

The Organization must protect the confidentiality and integrity of information at rest. At a minimum, this covers sensitive PII, sensitive business identifiable information (BII), and information categorized as moderate or high impact under FIPS 199. Under OMB M-22-09, the protection must be cryptographic and must use FIPS-validated modules. System Owners must encrypt storage in the cloud platform at rest wherever covered information lives, including volumes, object stores, databases, and backups. Security-relevant system information, such as configurations and credentials, must receive the same protection. If anyone finds storage that holds covered information without encryption, the System Owner must treat it as a security finding and correct it. Scheduling the fix as routine maintenance is not acceptable.

SC-28(1) — Cryptographic Protection #

Baselines: Low / Moderate / High

Requirement:

Implement cryptographic mechanisms to prevent unauthorized disclosure and modification of the following information at rest on all information system components storing Federal data or system data that must be protected at the High or Moderate impact levels: [Assignment: organization-defined information — to be defined].

Implementation guidance:

The Organization must encrypt sensitive data at rest on every system component so that no one can read or alter it without authorization. The cryptographic modules must be FIPS-validated, as OMB M-22-09 requires. System Owners must not exempt any class of component: server storage, databases, backups, and endpoint drives all require encryption. Any exception requires a risk decision that the CISO accepts, with compensating controls and an expiration date.

SC-39 — Process Isolation #

Baselines: Low / Moderate / High CSF 2.0: PR.DS (Data Security), PR.PS (Platform Security)

Requirement:

Maintain a separate execution domain for each executing system process.

Implementation guidance:

Systems must keep a separate execution domain for every running process. Each process runs in its own address space, and processes communicate only through controlled interfaces. Without this isolation, a single bug in one process can compromise the whole system. The platform provides this isolation: the operating systems in the standard build enforce per-process separation, and the Organization inherits workload isolation beneath the operating system from the cloud platform under its Federal Risk and Authorization Management Program (FedRAMP) authorization. System Owners must not disable or weaken the isolation features. A configuration that would let processes share an execution domain requires a documented exception that the CISO approves.

4. Roles and Responsibilities #

These roles apply across this policy. Each System Owner records the system-specific assignments in the system’s System Security and Privacy Plan (SSPP).

5. Performance Measurement #

The CISO manages this policy with the measures below, which meet the IG FISMA maturity model’s Level 4 (Managed and Measurable) criteria. The CISO collects and trends the measures and reports them to the CIO and the Authorizing Officials. When a measure moves away from its target, the CISO starts corrective action through the POA&M process.

The CISO keeps the measurement data for the annual IG FISMA evaluation and for trend analysis across reporting periods.

6. Compliance and Enforcement #

Every employee, contractor, and other user with access to an information system that the Organization operates, or that others operate for it, must comply with this policy. The CISO records each case of non-compliance as a finding in the Organization’s continuous monitoring program. The ISSO tracks the finding to resolution as a POA&M item, as OMB Circular A-130 and NIST SP 800-37 Rev. 2 describe.

A violation of this policy can lead to suspension of system access, withdrawal of the system’s authorization to operate (ATO), and administrative or disciplinary action under applicable law, regulation, and human capital policy.

The Inspector General assesses the maturity of system and communications protection controls each year through the IG FISMA reporting metrics. The target maturity level for this policy area is Level 4: Managed and Measurable.

7. Continuous Improvement #

Level 4 is the minimum the Organization aims for. To meet the IG FISMA maturity model’s Level 5 (Optimized) criteria, the CISO improves system and communications protection through these commitments:

1. Review the performance measures in this document at least annually; where a measure has met its target for four consecutive periods, tighten the target or replace the measure with a more demanding indicator.
2. Conduct an annual effectiveness review of this policy area using IG FISMA audit results, assessment findings, incident data, and metric trends; document resulting changes in the revision history.
3. Feed lessons learned from incidents, assessments, and exercises into updates of this document and its procedures within 90 days of the triggering event.
4. Benchmark against the IG FISMA maturity model annually and maintain a documented plan to reach and sustain Level 4 (Managed and Measurable), with a roadmap toward Level 5 (Optimized).
5. Advance network segmentation toward identity-aware microsegmentation for high-value segments, measured by lateral-movement test results.

8. Exceptions and Waivers #

The CISO may grant an exception to this policy only when compliance is not technically feasible or would harm the mission. To request one, the System Owner sends the CISO a written request that includes:

1. A business justification and a risk assessment.
2. Compensating controls that reduce the risk the exception creates, following the NIST SP 800-53B guidance on compensating controls.
3. A proposed end date no more than one year away.

The CISO decides each request in coordination with the Authorizing Official. An exception that involves privacy risk also needs the agreement of the Senior Agency Official for Privacy (SAOP). The CISO re-evaluates each exception when it comes up for renewal. The System Owner records each approved exception in the system’s SSPP, and the ISSO tracks it as a POA&M item.

9. References #

These are the sources this document cites, with a link to each official text.

• CISA BOD 18-01: Enhance Email and Web Security, October 16, 2017.
• CISA BOD 23-02: Mitigating the Risk from Internet-Exposed Management Interfaces, June 13, 2023.
• CISA High Value Asset (HVA) Control Overlay v1.0, November 1, 2017.
• Executive Order 13800: Strengthening the Cybersecurity of Federal Networks and Critical Infrastructure, May 11, 2017.
• Executive Order 14028: Improving the Nation’s Cybersecurity, May 12, 2021.
• Executive Order 14412: Securing the Nation Against Advanced Cryptographic Attacks, June 22, 2026.
• Federal Information Security Modernization Act of 2014 (44 U.S.C. § 3551 et seq.), December 18, 2014.
• Superseded source, kept for its history: FIPS 140-2: Security Requirements for Cryptographic Modules, May 25, 2001. Replaced by FIPS 140-3.
• FIPS 140-3: Cryptographic Module Security Requirements, March 22, 2019.
• FIPS 140-3 Transition Effort, updated continuously.
• FIPS 199: Standards for Security Categorization, February 2004.
• FIPS 200: Minimum Security Requirements for Federal Information and Information Systems, March 2006.
• NIST Cybersecurity Framework 2.0, February 26, 2024.
• NIST SP 800-37 Rev. 2: Risk Management Framework for Information Systems and Organizations, December 2018.
• NIST SP 800-52 Rev. 2: Guidelines for the Selection, Configuration, and Use of Transport Layer Security (TLS) Implementations, August 2019.
• NIST SP 800-53 Rev. 5: Security and Privacy Controls for Information Systems and Organizations, September 2020.
• NIST SP 800-53B: Control Baselines for Information Systems and Organizations, September 2020.
• NIST SP 800-57 Part 1 Rev. 5: Recommendation for Key Management: Part 1 - General, May 2020.
• NIST SP 800-119: Guidelines for the Secure Deployment of IPv6, December 2010.
• NIST SP 800-207: Zero Trust Architecture, August 2020.
• OMB Circular A-123: Management’s Responsibility for Internal Control, March 10, 2026.
• OMB Circular A-130: Managing Information as a Strategic Resource, July 28, 2016.
• OMB M-15-13: Policy to Require Secure Connections across Federal Websites and Web Services, June 8, 2015.
• OMB M-19-03: Strengthening the Cybersecurity of Federal Agencies by Enhancing the High Value Asset Program, December 26, 2018.
• OMB M-19-26: Update to the Trusted Internet Connections (TIC) Initiative, September 12, 2019.
• OMB M-21-07: Completing the Transition to Internet Protocol Version 6 (IPv6), November 19, 2020.
• OMB M-22-09: Moving the U.S. Government Toward Zero Trust Cybersecurity Principles, January 26, 2022.
• OMB M-23-02: Migrating to Post-Quantum Cryptography, November 18, 2022.
• OMB M-26-15: Execution of the Migration to Post-Quantum Cryptography, June 24, 2026.
• Responsibilities for Federal information systems standards (40 U.S.C. § 11331).