SC-38: Operations Security

Quick-reference card

What this control requires

SC-38 requires organizations to identify and protect sensitive operational information that adversaries could use to compromise systems, supply chains, or strategic plans. This control goes beyond traditional data classification by targeting the patterns, processes, and decisions that reveal organizational capabilities and intentions, even when individual pieces of information aren’t classified or restricted.

In practice, implementing SC-38 means embedding operations security (OPSEC) safeguards across the entire system development life cycle. Organizations must determine which information is critical, assess who might exploit it and how, and then apply countermeasures to limit exposure. That scope includes protecting details about security architectures, testing protocols, supplier relationships, and functional requirements from anyone outside the authorized circle, including vendors, potential suppliers, and other external parties.

The control is deliberately broad because OPSEC failures rarely stem from a single disclosure. Instead, adversaries piece together fragments of unclassified information, such as procurement records, job postings that reveal technology stacks, or public-facing system documentation, to map an organization’s attack surface and plan targeted operations. SC-38 forces a structured approach to denying that composite picture. It sits within the System and Communications Protection family, reflecting its focus on safeguarding information flows rather than individual assets.

Why it matters

Most organizations treat information protection as a classification exercise, focusing on labeled secrets while leaving operational metadata exposed. SC-38 addresses a different risk class entirely. It targets the unclassified details that, when aggregated, give adversaries a roadmap to organizational vulnerabilities, supplier dependencies, and security gaps.

Failure to maintain this control introduces audit risk and may result in certification withdrawal or regulatory findings. Assessors evaluating NIST SP 800-53 compliance look for documented OPSEC processes, identified critical information lists, and evidence of threat and vulnerability assessments tied to operational activities. Without these artifacts, organizations face findings that can delay authorizations, trigger remediation plans, and erode stakeholder confidence.

The risk compounds in environments with complex supply chains. When procurement details, system design specifications, or security control implementation strategies are shared without OPSEC consideration, every additional disclosure widens the adversary’s intelligence picture. Regulatory bodies increasingly expect organizations to demonstrate that they’ve assessed this exposure, not just protected classified data.

What attackers exploit

• Publicly available procurement and supplier data that reveals technology stacks, security tooling, and vendor dependencies
• Job postings and recruitment materials that disclose internal system architectures, programming languages, and security frameworks in use
• Unprotected system design specifications and testing protocols shared with contractors or potential vendors during evaluation cycles
• Supply chain process documentation that maps organizational dependencies and identifies single points of failure
• Security control implementation details exposed through public-facing documentation, conference presentations, or partner communications

How to implement

The most common failure with SC-38 isn’t a lack of security controls. It’s treating OPSEC as a one-time checklist rather than a continuous process embedded in how the organization operates and communicates. Without that mindset shift, critical information leaks through routine activities that no individual policy catches.

For your organization

Start by establishing a formal OPSEC program that follows the five-step process outlined in NSDD-298 and subsequent DoD guidance. Each step builds on the previous one, and skipping any of them leaves gaps that adversaries can exploit.

Step 1: Identify critical information. Build and maintain a critical information list (CIL) that catalogs the operational details, technical specifications, and strategic plans that would give an adversary an advantage if disclosed. This list should cover user identities, system design specifications, security requirements, testing protocols, supplier identities, and supply chain processes. Review and update the CIL at least quarterly.

Step 2: Analyze threats. Determine which adversaries have the intent and capability to target the identified information. Map threat actors to specific CIL items using threat intelligence feeds and industry-specific indicators of compromise.

Step 3: Analyze vulnerabilities. Identify the channels through which critical information could be exposed. This analysis covers everything from public-facing websites and social media to contractor communications and conference presentations. Examine how DevSecOps practices and development workflows might inadvertently disclose security architecture details.

Step 4: Assess risks. Evaluate each vulnerability against the threat landscape to determine the likelihood and impact of disclosure. Prioritize countermeasures based on risk severity rather than treating every item equally.

Step 5: Apply countermeasures. Implement controls proportional to the assessed risk. Common countermeasures include information sharing agreements with non-disclosure provisions, sanitization of public-facing documents, compartmentalized access to system design specifications, and review gates before external communications that reference organizational capabilities.

A common mistake is limiting OPSEC to the security team. Effective programs require coordination across procurement, human resources, public affairs, and engineering teams, since each function handles information that could contribute to an adversary’s understanding.

For your vendors

Third-party OPSEC failures are a direct threat to the contracting organization. When vendors mishandle shared design specifications, security requirements, or supply chain details, the exposure cascades back to the originating organization.

Questionnaire questions to include:

• Does the vendor maintain a formal OPSEC program or equivalent information protection process?
• How does the vendor identify and categorize critical information shared by clients?
• What controls prevent vendor employees from disclosing client system specifications, security architectures, or testing methodologies?
• How does the vendor restrict subcontractor and fourth-party access to client-sensitive operational data?

Evidence to request:

• OPSEC policy or critical information protection procedures
• Non-disclosure agreements and information sharing agreements specific to client data
• Training records showing OPSEC or information handling awareness for staff with access to client operational details
• Access control logs demonstrating compartmentalized access to client-provided specifications

Red flags to watch for:

• No documented process for identifying or protecting client-critical information
• Vendor marketing materials or case studies that reference client-specific architectures, tooling, or security configurations without authorization
• Broad internal access to client deliverables with no compartmentalization or need-to-know restrictions

Organizations can use a Vendor Risk management platform to assess vendor OPSEC maturity and continuously monitor for indicators that sensitive operational details have been exposed. Automated questionnaire workflows reduce the burden of collecting and validating vendor evidence at scale.

An attack surface management solution can also help identify whether operational details have surfaced publicly, enabling proactive remediation before adversaries can aggregate that information.

Evidence examples

Cross-framework mapping

No cross-framework mappings are currently configured for this control.

Related controls

• CA-02 — Control Assessments: Provides the assessment methodology that validates whether OPSEC controls are implemented and operating effectively.
• CA-07 — Continuous Monitoring: Establishes ongoing monitoring that detects changes to the OPSEC posture, including new information exposures or control degradation.
• PL-01 — Policy and Procedures: Defines the policy foundation that formalizes the OPSEC program, its scope, and organizational responsibilities.
• PM-09 — Risk Management Strategy: Sets the organizational risk tolerance that determines how aggressively OPSEC countermeasures are applied to identified vulnerabilities.
• PM-12 — Insider Threat Program: Addresses the insider dimension of OPSEC, where authorized personnel may intentionally or inadvertently disclose critical information.
• RA-02 — Security Categorization: Informs which systems and data flows warrant OPSEC protection based on their impact level and sensitivity classification.
• RA-03 — Risk Assessment: Feeds the risk analysis step of the OPSEC process by providing threat likelihood and impact data for critical information items.
• RA-05 — Vulnerability Monitoring and Scanning: Identifies technical vulnerabilities that could serve as channels for critical information disclosure.
• SC-07 — Boundary Protection: Controls the network boundaries through which sensitive operational information could leave the organization.
• SR-03 — Supply Chain Controls and Processes: Extends OPSEC principles to the supply chain, protecting shared specifications and vendor relationship details from adversary exploitation.

Frequently asked questions

What is NIST SP 800-53 SC-38

SC-38 is the NIST SP 800-53 control that requires organizations to apply operations security (OPSEC) safeguards to protect critical information throughout the system development life cycle. It addresses the risk that adversaries can piece together unclassified operational details, such as system design specifications, supplier relationships, and testing protocols, to map an organization’s vulnerabilities. The control mandates a structured five-step process covering identification of critical information, threat and vulnerability analysis, risk assessment, and countermeasure application.

What happens if SC-38 is not implemented

Without SC-38, organizations lack a structured process for identifying and protecting the operational information that adversaries use to plan targeted attacks. Assessors reviewing NIST SP 800-53 compliance will look for OPSEC policies, critical information lists, and documented threat and vulnerability assessments. Missing these artifacts results in audit findings that can delay system authorizations and require formal remediation through plans of action and milestones. The absence of OPSEC controls also increases the risk that supply chain details and security architecture information are exposed through routine business activities.

How do you audit SC-38

Auditing SC-38 starts with verifying that the organization maintains a documented OPSEC program with a current critical information list and supporting threat and vulnerability assessments. Assessors examine whether OPSEC controls are integrated into system development life cycle documentation, reviewing evidence at design, development, testing, and deployment phases. They also evaluate security control assessment records to confirm that OPSEC safeguards are tested for effectiveness and that identified gaps are tracked through plans of action and milestones with assigned owners and target dates.

What are the five steps of the OPSEC process

The OPSEC process follows five sequential steps defined by national security directives. First, identify the critical information that would give an adversary an advantage if disclosed, including system specifications, security requirements, and supplier data. Second, analyze threats to determine which adversaries have the intent and capability to target that information. Third, analyze vulnerabilities to find the channels through which disclosure could occur. Fourth, assess the risk by combining threat likelihood with potential impact. Fifth, apply countermeasures proportional to the assessed risk, such as information compartmentalization, non-disclosure agreements, and communication review gates.