SC-38: Operations Security

SC-38: operations security requirement means you must embed operations security (OPSEC) controls across the full system development life cycle so key organizational information is protected from disclosure through normal engineering and delivery activities. To operationalize it, define what “key information” is, map OPSEC controls to each SDLC phase, assign owners, and retain repeatable evidence that the controls run. ¹

Key takeaways:

• Treat SC-38 as an SDLC-wide control: requirements, design, build, test, deploy, and sustainment all need OPSEC handling. ¹
• “Key organizational information” must be explicitly identified, labeled, and protected in engineering workflows, tooling, and third-party interactions. ¹
• Audit readiness depends on mapping SC-38 to a control owner, a written procedure, and recurring evidence artifacts that show the procedure operates. ¹

SC-38 is easy to misunderstand because it is short and parameterized. The control is not asking for a single technical safeguard; it is asking you to apply a set of operations security practices to protect sensitive information that is routinely exposed during engineering work: architecture decisions, threat models, security test results, build logs, debug output, secrets in tickets, and the “how” of operating the system. The exposure often happens through normal collaboration: shared repos, CI/CD pipelines, support channels, and third-party development or managed services.

For a Compliance Officer, CCO, or GRC lead, the fastest path is to treat SC-38 as an SDLC governance requirement with clear scoping: (1) define what qualifies as “key organizational information,” (2) identify where it appears in SDLC activities and tools, (3) implement OPSEC controls at those touchpoints, and (4) keep evidence that would satisfy a control assessor. NIST expresses the requirement at a high level, so your job is to translate it into a repeatable playbook that engineering teams can follow without slowing delivery. ²

Regulatory text

NIST control excerpt (SC-38): “Employ the following operations security controls to protect key organizational information throughout the system development life cycle: {{ insert: param, sc-38_odp }}.” ¹

What the operator must do:
Because the control references an organization-defined parameter (“sc-38_odp”), you must (a) define the OPSEC controls your organization will “employ,” and (b) apply them end-to-end across SDLC activities. Your assessor will look for two things: your defined OPSEC expectations and proof those expectations are implemented in engineering practice. ¹

Plain-English interpretation

SC-38 requires you to prevent sensitive “inside baseball” about your systems from leaking through normal engineering and operations work. That includes information an attacker could use to plan exploitation or defeat controls (for example, privileged endpoints, security exceptions, unpatched weakness details, environment access patterns, or incident response runbooks). You do not meet SC-38 by publishing a generic “secure SDLC” policy alone; you meet it by embedding specific handling rules into the tools and workflows where this information is created and shared. ¹

Who it applies to (entity and operational context)

SC-38 is relevant anywhere you apply NIST SP 800-53 Rev. 5 controls, including:

• Federal information systems implementing NIST SP 800-53 controls. ²
• Contractor systems handling federal data where NIST SP 800-53 controls are flowed down contractually or adopted as the control baseline. ²

Operationally, it applies to:

• Product engineering teams and platform teams running CI/CD
• Security engineering and AppSec
• SRE/operations teams
• IT and enterprise tooling owners (ticketing, chat, docs, logging)
• Third parties participating in design, development, testing, deployment, or operations activities (including managed service providers)

What you actually need to do (step-by-step)

Step 1: Define “key organizational information” for SC-38 scope

Create a short, explicit classification for SC-38. Keep it pragmatic and tied to the SDLC.

Output: “SC-38 Key Organizational Information” register, with examples such as:

• System architecture diagrams and trust boundaries
• Threat models and abuse cases
• Security testing outputs (SAST/DAST results, pen test findings)
• Configuration and deployment details that expose security posture
• Operational runbooks, escalation paths, and privileged access patterns
• Build artifacts and debug logs that may contain secrets or internal endpoints

This register becomes your sc-38_odp parameter definition in practice: it makes “key information” concrete and assessable. ¹

Step 2: Map OPSEC controls to each SDLC phase (your sc-38_odp)

Build a matrix that answers: “Where does key information appear, and what must teams do about it?”

Minimum SDLC touchpoints to cover:

• Requirements and design: documentation and architecture review systems
• Build: source control, artifact registries, CI logs
• Test: security testing tools, defect tracking, test environments
• Deploy: infrastructure-as-code repos, change management, release notes
• Operate: observability tools, on-call, incident workflows
• Retire: decommission tickets, data migration plans

Typical OPSEC control patterns to define:

• Access controls on sensitive engineering docs and tickets
• Redaction rules for logs, screenshots, and debug output
• Secret handling requirements (including “no secrets in tickets/chat”)
• External sharing rules with third parties (what can leave, approval path)
• Exception handling and time-bound approvals for exposure-risky practices
• Mandatory secure repositories for artifacts (no personal drives)

SC-38 is satisfied when this matrix exists, is approved, and is embedded in delivery workflows. ¹

Step 3: Assign ownership and operational procedures

Auditors want a named owner who can explain how SC-38 works day-to-day.

Do this:

• Assign a primary control owner (often AppSec or GRC with engineering buy-in).
• Assign tool owners as sub-owners (Git platform, CI/CD, ticketing, wiki, logging).
• Publish an SC-38 procedure with: scope, do/don’t examples, review cadence, and exception workflow.

If you use Daydream to manage control operations, map SC-38 to the owner, the procedure, and the recurring evidence artifacts you will collect. This turns “we do OPSEC” into an assessment-ready control record. ¹

Step 4: Embed OPSEC guardrails into tooling (make it hard to do the wrong thing)

Policy won’t scale. Controls must show up where engineers work.

High-yield implementations:

• Templates in tickets for vulnerabilities/incidents with required redaction fields
• Repo settings that prevent public exposure and restrict fork/sharing
• CI/CD log masking and secrets scanning gates
• Documentation permissions for architecture and runbooks
• Chat and email DLP patterns for sensitive strings and incident artifacts
• “External share” workflow for design docs or test results provided to third parties

Step 5: Train and prove adoption through lightweight attestations and sampling

You do not need a heavy training program to start, but you must prove people understand the rules.

Practical approach:

• Provide a short “OPSEC in engineering” guidance page with examples.
• Run periodic sampling: pick a set of recent tickets, docs, and CI logs; verify no prohibited content appears; file remediation tasks.
• Record exceptions with approvals and expiration.

Step 6: Monitor and improve (treat as continuous control)

SC-38 tends to drift because SDLC tooling changes. Tie it into change management for engineering platforms:

• New tool onboarding requires a check for SC-38 touchpoints
• New third-party engagement requires OPSEC sharing rules and access boundaries

Required evidence and artifacts to retain

Keep evidence that (a) defines the organization parameter and (b) shows ongoing operation.

Evidence checklist (assessment-ready):

• SC-38 scoping statement and “key organizational information” register (your sc-38_odp content) ¹
• SDLC OPSEC control matrix mapped to SDLC phases and tools ¹
• Approved SC-38 procedure and exception workflow
• Role/permission snapshots or access reviews for sensitive engineering repositories (docs, runbooks, architecture)
• Configuration evidence: repo visibility settings, CI log masking configuration, secrets scanning policies
• Samples of redacted tickets/logs and remediation records
• Third-party sharing approvals and records of what was shared, with dates and recipients
• Training/guidance publication record and completion attestations (if used)

Common exam/audit questions and hangups

What assessors ask:

• “Define ‘key organizational information’ for your environment. Where is it stored and who can access it?” ¹
• “Show how OPSEC controls apply across SDLC phases, not only production operations.” ¹
• “Demonstrate the control operates: provide recent samples of engineering artifacts with redaction/access controls in place.”
• “How do you control what is shared with third parties during development and support?”

Frequent hangups:

• Teams claim OPSEC is covered by general access control policies, but cannot show SDLC-specific procedures or samples.
• “Key information” is defined too broadly (“anything sensitive”), which becomes impossible to operationalize and test.

Frequent implementation mistakes and how to avoid them

1. Mistake: No organization-defined parameter.
   Fix: Write the sc-38_odp definition as a short, testable list of OPSEC controls and what counts as key information. ¹

2. Mistake: Treating OPSEC as only an operations/SRE topic.
   Fix: Build the SDLC matrix and include design, build, and test artifacts explicitly. ¹

3. Mistake: Relying on “training only.”
   Fix: Add tool-level guardrails (permissions, masking, templates) and keep configuration screenshots/exports as evidence.

4. Mistake: No exception process.
   Fix: Define who can approve external sharing of sensitive artifacts, how long approvals last, and what must be redacted before sharing.

5. Mistake: Evidence is ad hoc.
   Fix: Predefine recurring artifacts (monthly samples, quarterly access snapshots) in your control record; Daydream-style mapping helps you keep that consistent. ¹

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for SC-38. Your practical risk is still clear: OPSEC breakdowns can expose system weaknesses, privileged pathways, and security exceptions through engineering artifacts that spread quickly across repos, tickets, and third-party channels. The compliance failure mode is usually “cannot demonstrate implementation,” not “no security tooling exists.” ¹

Practical 30/60/90-day execution plan

First 30 days (establish control definition and ownership)

• Name SC-38 owner and tool sub-owners (docs, repo, CI/CD, ticketing, logging).
• Draft the “key organizational information” register and OPSEC ruleset (sc-38_odp).
• Build the SDLC OPSEC matrix and get engineering sign-off.
• Stand up an exceptions and external sharing approval workflow.

By 60 days (embed guardrails and start collecting evidence)

• Implement repo/document permission changes for sensitive artifacts.
• Add CI/CD log masking and secrets scanning gates where feasible.
• Add ticket templates and redaction guidance for vulnerabilities/incidents.
• Start evidence collection: first sample set of tickets/docs/logs, plus configuration exports.

By 90 days (prove operation and tighten weak spots)

• Run a second sampling cycle; track remediation to closure.
• Review third-party access and sharing records; tighten where needed.
• Add SC-38 checks to onboarding for new SDLC tools and new third parties.
• Normalize evidence: a recurring schedule and a single control record that always has the latest artifacts (a Daydream workflow fits well here). ¹

Frequently Asked Questions

What counts as “operations security” for SC-38 in an engineering org?

Treat it as OPSEC practices that prevent sensitive system details from leaking via SDLC work products. If it would help an attacker understand your architecture, defenses, or weaknesses, it belongs in scope. ¹

Do we need a separate SC-38 policy if we already have secure SDLC documentation?

You need an explicit SC-38 procedure or mapped control narrative that shows how OPSEC is applied throughout the SDLC and what “key organizational information” means in your environment. Generic secure SDLC language usually lacks the sc-38_odp definition and evidence plan. ¹

How do we handle third parties (contract developers, MSPs, testers) under SC-38?

Define what artifacts can be shared, require an approval path for sensitive items, and enforce least-privilege access in the tools they use. Keep a record of approvals and what was transmitted. ¹

What evidence is strongest for auditors?

A defined “key organizational information” register, an SDLC OPSEC matrix, tool configuration evidence (permissions, masking, scanning), and sampled artifacts showing redaction and controlled access. Evidence should show repeatability, not one-off screenshots. ¹

Our engineers use chat for incident response and debugging. Is that in scope?

Yes if key organizational information appears there (logs, endpoints, privileged instructions, vulnerability details). Add rules for redaction and restrict access to incident channels, then retain samples or configuration evidence that controls are in place. ¹

How should we document sc-38_odp so it’s assessable?

Write it as a short list of specific OPSEC controls and scope definitions, then connect each item to SDLC phases, tools, and evidence. If you can’t test it or collect artifacts for it, rewrite it until you can. ¹

Footnotes

1. NIST SP 800-53 Rev. 5 OSCAL JSON

2. NIST SP 800-53 Rev. 5