SC-38 Operations security: requirements and evidence

SC-38 operations security: what the requirement asks for

If you have been told SC-38 applies, the requirement is less about a technical setting and more about a decision your organization must write down. SC-38 Operations Security is a base control in the System and Communications Protection family of NIST SP 800-53 Rev. 5. It asks the organization to define operations security (OPSEC) safeguards that protect its key information throughout the system development life cycle. The control has one organization-defined parameter and no enhancements in Release 5.2.0, so the substance sits in the list you define. SP 800-53B does not assign SC-38 to any security or privacy baseline. It applies only when your organization selects it through tailoring or an overlay, which means the question to answer first is whether your contract, authorizing official or assessor has put it in scope.

The risk SC-38 addresses is exposure through ordinary material. Adversaries rarely need to break into a system to learn how it works. They can assemble a picture from public documents, design diagrams, configuration details in job postings or vendor case studies, error messages, and assessment reports that circulate beyond the people who need them. SC-38 asks the organization to recognize that this information is itself sensitive and to limit it. The control covers more than the production environment: design documents, test data, and the assessment and risk material that SP 800-53A procedures generate can all reveal the same details.

The hard part is that the critical information is rarely written down. Teams know which architecture details or security configurations would help an attacker, but that knowledge lives in people's heads and scattered repositories. The control is also easy to claim without substance, since a statement that the organization practices OPSEC tells an assessor nothing. Confirm with your assessor which life cycle phases and information types they expect you to cover, then build a short, dated list of critical information, the safeguards applied to each item, and the owner who reviews it. That list, linked to your risk assessments and threat and vulnerability assessments, is the artifact the assessment will examine.

Where SC-38 operations security applies in your environment

SC-38 is not in any SP 800-53B baseline, so it applies only when your organization selects it through tailoring or an overlay. The cards below are the scoping decisions to record before you build the OPSEC list, because each one sets what the list must protect and who must maintain it. Together they show that SC-38 is a life-cycle and information-handling control, not a single technical setting.

Systems and life-cycle stages

Decide which systems the OPSEC list covers and at which life-cycle stages: design, build, operation and retirement. Design documents and build pipelines often expose more than production does, so a list written only for operation misses early exposure. Confirm whether decommissioned systems still hold architecture diagrams or credentials that need protection. Record the boundary in the system security plan so an assessor can trace each stage to a safeguard.

Categories of critical information

Identify which information is critical to the system's security and would help an adversary if disclosed. Typical categories include architecture diagrams, configuration baselines, incident and assessment records, and details of security tooling such as detection rules and scanner coverage. Each category should name an owner and a storage location. The 11 related controls in the catalog, including CA-2, CA-7, RA-3, RA-5, SC-7 and SR-3, point to where this information is produced, so use them as a checklist for the list.

Teams that own the safeguards

Assign each OPSEC safeguard to a named team, such as platform engineering for configuration data, the security operations team for detection details, and the risk function for assessment records. SC-38 requires the organization to define its controls, so ownership cannot be left to the security team alone. Ask who approves disclosure of architecture material to auditors, customers and vendors. Document the approval path in the same place as the safeguard so reviews are repeatable.

Third parties that hold the information

List every external party that receives or stores critical information, including cloud providers, managed service partners, auditors, penetration testers and SaaS tools that ingest logs. Each recipient should be covered by a contract or agreement that restricts use and requires return or deletion. SR-3 and SR-7 bring supply chain risk into the same picture, so include suppliers' own sub-processors. Confirm that test reports and assessment packages sent outside the organization are controlled as carefully as the system itself.

Recording the tailoring decision

Because SP 800-53B does not assign SC-38, the decision to select it must be recorded in the tailoring or overlay documentation with a rationale. Note whether the control was selected for the system, for a program or for a specific risk, and link that choice to the risk assessment that justified it. Assessors using the SP 800-53A procedure will look for this record first, so an unrecorded decision leaves the control unassessed. Revisit the decision when the system boundary or threat picture changes.

How an assessor tests SC-38 operations security

This table maps the single SP 800-53A determination statement for SC-38 to the examine, interview and test methods and the objects an assessor reviews. Read each row as what the assessor asks for, what it looks like in practice and where organizations usually fall short.

Assessment element	What the assessor does	Where it usually fails
Determination statement	Confirms the organization has defined operations security safeguards that protect key organizational information across the system development life cycle.	Safeguards are described in general terms without naming the critical information they protect.
Examine: list of operations security safeguards	Reads the documented list of OPSEC safeguards and checks it names the safeguards, their owners and the life cycle phases they cover.	The list is missing, dated before the current system design, or never approved by an owner.
Examine: security control assessments	Compares safeguards against recent control assessment results to see whether the safeguards were tested and what gaps were recorded.	Assessment results do not mention operations security, so no evidence shows the safeguards work.
Examine: risk assessments	Checks that the risk assessment identifies the information an adversary could learn and ties each item to a safeguard.	The risk assessment ignores operational information leakage, such as deployment details or administrative activity patterns.
Examine: threat and vulnerability assessments	Looks for threat information about adversaries who collect operational details and for vulnerabilities that expose them.	Threat assessments cover malware and intrusion only, with no entry for information gathering by adversaries.
Interview	Asks system owners, developers and operators how they decide what is sensitive, how they handle it and how they learn about changes to the list.	Staff describe practices that differ from the written list or cannot name the safeguards they follow.
Test	Observes or samples live practices, such as how public-facing documentation, logs and repositories are reviewed before release and how access to operational details is restricted.	Safeguards exist only in policy, with no configuration, workflow or record showing they run.

How to implement SC-38 step by step

This sequence turns SC-38 from a policy statement into a working operations security program, moving from defining what must stay hidden to keeping the safeguards current through reviews and records.

Scope the life cycle and information categories
Start by defining which system, environment and life cycle stages the OPSEC program covers, from design and development through operation, change and decommissioning. Agree the categories of information in scope, such as architecture diagrams, configuration baselines, network maps, credentials, incident details and assessment results. The security lead and system owner confirm the boundary in writing. The step is done when the scope statement names each life cycle stage and each information category, and an assessor could trace every later step back to it.
Identify critical information with system owners
Work with each system owner to list the information that would help an adversary attack the system if it were exposed, such as topology details, administrative paths, deployment pipelines, monitoring coverage and recovery procedures. Rank each item by how much harm its disclosure would cause. Record where each item is stored and who can read it today. The output is a critical information register with an owner, a location and a sensitivity rank for every entry, reviewed and signed off by the system owners.
Define OPSEC safeguards and assign owners
For each critical information item, define the safeguard that limits what outsiders or unauthorized insiders can learn. Typical safeguards include restricting access to design documents, removing sensitive detail from public repositories and status pages, controlling who may publish architecture material, and limiting what error messages reveal. Assign a named owner to each safeguard and record how it is enforced. The output is a safeguard catalog that maps each critical item to a safeguard, an owner and an enforcement method. Ask your organization to confirm how it defines the organization-defined parameter for SC-38, because the parameter sets what must be defined.
Connect safeguards to risk and threat assessments
Link each safeguard to the risk assessment and the threat and vulnerability assessment that justify it. Review whether the assessments name the threats that could exploit disclosed information, such as reconnaissance from exposed documentation or leaked configuration data. Update the risk register where a safeguard addresses a risk, and note the gap where none exists. SC-38 sits alongside SC-7 and several CA, RA and SR controls, so cross-references should be explicit. The output is a traceability table that links each safeguard to at least one risk or threat entry and to the controls it supports.
Apply safeguards in design and change reviews
Add a check for critical information to the design review and the change approval process. Reviewers confirm that new interfaces, logs, dashboards, documentation and public-facing outputs do not expose items on the register, and that new components are assigned the safeguards they need. Changes that alter a safeguard or add a new critical item go through the same review. The output is completed review records that show the OPSEC check, the reviewer, the decision and any follow-up actions for each relevant change.
Set a review cycle for the safeguards
Set how often the critical information register, the safeguard catalog and the traceability table are reviewed, and trigger an earlier review after significant system changes, incidents or new threat intelligence. Each review rechecks whether the items are still correct, whether owners are still in post and whether enforcement still works. The organization sets the cycle in its own policy, and the policy should name the review frequency explicitly. The output is a dated review log with the reviewer, the changes made and the approval for each cycle.
Retain the OPSEC records
Keep the scope statement, critical information register, safeguard catalog, traceability table, review records and change review evidence together under version control so that any past state can be reconstructed. Set retention periods in line with your records policy and any contractual or regulatory obligations, and confirm them with legal or compliance. Restrict access to the records themselves, since they describe what is sensitive. The output is a retained, versioned evidence set that an independent assessor can sample against the SC-38 assessment procedures.

Evidence that satisfies SC-38 operations security

SC-38 has no prescribed artifact list, so the organization defines its operations security safeguards and then shows they were chosen, owned, reviewed and applied. The cards below cover the records an assessor typically samples and how each one stays current between assessments.

Approved OPSEC safeguard list

This is the list of operations security safeguards the organization has defined to protect its key information, with each safeguard's owner, the information it protects and its review date. Assessors check that the list exists, is approved by a named authority, and matches what teams actually do. Keep it current by tying each safeguard to a review date and recording who approved every change. Confirm the review interval with your own governance policy before setting it.

Critical information inventory

This inventory identifies the information whose disclosure would help an adversary, such as network diagrams, administrative procedures, key management details and vendor integration specifics. Assessors sample entries and ask how each item was classified and where copies reside. Keep it current by linking each entry to the system component and data store it describes, and by revisiting entries when architecture changes. Entries without an owner are the most common gap.

Risk and vulnerability linkage records

These records show which safeguards answer which risk assessment and vulnerability scan findings, including threat scenarios that involve reconnaissance or disclosure of system design. Assessors trace a finding to a safeguard and then to evidence that the safeguard operates. Keep them current by updating the mapping whenever a new assessment is completed, so the chain from threat to safeguard stays traceable. The related controls RA-2, RA-3 and RA-5 provide the inputs.

Design and change review checks

Architecture reviews, design approvals and change tickets should show an explicit operations security check, asking whether the change exposes critical information such as topology, configuration or logging detail. Assessors sample recent changes and look for the check and its outcome. Keep this current by adding the question to the review template so it is answered on every change, not only on major projects. Tie it to the configuration change process used for the system.

Access and sharing records for architecture material

Records of who can read and who received sensitive architecture material, including vendor and contractor access, show that disclosure is limited to people with a need to know. Assessors ask for the access list for a sample of repositories and a sample of external sharing events. Keep these records current by reviewing access on a schedule and by recording each external share with its approval. Self-hosted wikis and documentation platforms can keep this material under role-based permissions, which should be confirmed in the specific platform.

Safeguard review history

A dated history of reviews, changes and approvals of the safeguard list and inventory shows that SC-38 is maintained, not written once. Assessors look for reviews that changed something and for evidence that findings from earlier assessments were acted on. Keep it current by retaining prior versions and recording the reason for each change. Versioned documentation systems make this straightforward, provided the versions are reviewed and not only stored.

What SC-38 operations security costs to meet

This table breaks the cost of meeting SC-38 into components, showing who is paid, whether each cost is one-time or recurring, and what pushes it up or down. NIST does not estimate compliance costs, so use the drivers to shape a written scope and quote rather than to predict a budget.

Cost component	Who is paid or who spends effort	One-time or recurring	What drives it up or down
Tooling and licenses	Vendors for any commercial monitoring or classification software; open-source tools carry no license fee	Recurring if commercial licenses are used; one-time setup for self-hosted tools	Up with commercial products and user counts; down with self-hosted tools and existing logging stacks
Engineering and security time to identify and define safeguards	Internal security, engineering and architecture staff, or an implementation partner under a written scope	One-time for the initial list; recurring when the system or life cycle changes	Up with number of systems and life-cycle stages covered; down with a narrow, well-defined list of critical information
Reuse of existing risk assessments	Internal risk function, with optional partner support to map existing work to SC-38	One-time, then refreshed on each risk assessment cycle	Down when current risk assessments and threat assessments already name critical information; up when they must be built from scratch
Evidence upkeep	Internal control owners, who keep the safeguard list, review records and change notes current	Recurring across the assessment cycle	Up with frequent system changes and many third parties; down with version-controlled documentation and self-hosted wikis
External review of the safeguard list	Independent reviewer or partner, if the organization buys a second opinion	One-time per review, repeated when the list changes	Up with third-party dependencies and regulated data; down when the review is limited to the defined list
Auditor or assessor sampling effort	Independent auditor or assessor, paid under its own engagement terms	Recurring with each assessment	Up with the number of safeguards, systems and records sampled; down with clear ownership and complete, dated records
Quote inputs to request	Partner or consultant, in writing before work starts	Stated in the written scope	Ask for the systems in scope, life-cycle stages, third parties, tooling assumptions, review frequency and which evidence is delivered

How self-hosted documentation tools keep OPSEC records current

The OPSEC list is itself a controlled record. Its contents, its review history and the approvals behind each change all need to be versioned and restricted, because an assessor testing SC-38 will ask who decided what counts as critical information, when that decision changed and whether only authorized staff could alter it. A self-hosted wiki can hold that evidence inside your own infrastructure, but the tool only protects the record. Deciding which information is critical, which adversary observables matter and which safeguards are selected remains the organization's responsibility, and the decision should be signed off by the people who own the risk.

XWiki keeps every change to a page under version control, recording what changed, when and by whom, and it lets reviewers compare any two versions and roll back to an earlier one. For the OPSEC list, that means a reviewer can show the assessor the exact revision in force during an assessment period and the change that removed or added a safeguard. Confirm that the version history, page comparison and rollback behave as you need in the release you deploy, and check that history cannot be pruned by ordinary editors. XWiki is licensed under LGPL-2.1-or-later, so read the license terms that apply to your deployment and any modifications before you depend on them.

BookStack takes a different approach to the same problem. User abilities come from the roles assigned to each user, and permissions can be overridden per role at the shelf, book, chapter or page level. In practice, you can let the security team edit the OPSEC page while every other staff member gets read-only access, and limit approval-related pages to a named group. Before go-live, test the permission matrix with accounts from each role and record the results as evidence. BookStack is licensed under MIT, and you should confirm the current permission model in your installed version, since role and override behavior are the parts most likely to change.

Who does what for SC-38 operations security

Your organization owns SC-38. The control asks you to define the operations security safeguards that protect key organizational information across the system life cycle, so the decisions about what counts as critical and how it is protected sit with your leadership, security function and the system owners who understand the mission. No partner or auditor can make those decisions for you.

Critical information list: Your team decides which information needs protection, such as design documents, architecture diagrams, configuration details, and security assessment results, and records the reasoning.
Safeguards and owners: Your team selects the safeguards, assigns an accountable owner for each one, and approves the rules for who may view and share each item.
Sign-off and review: Your authorizing official or security leadership approves the policy and the review frequency, and accepts residual risk.
Day-to-day operation: Your staff apply the safeguards during development, deployment and maintenance, and report exceptions.

Before engaging anyone, confirm that a named individual owns the critical information list and that the sign-off path is documented, because an assessor will ask who approved it.

Where organizations usually fall short on SC-38 and how to close the gap

SC-38 asks an organization to decide what operational information needs protecting and then to run safeguards that keep it protected across the system life cycle. The gaps below tend to appear in the same places: the list of critical information, the review cycle, the link to risk, the handling of shared material, the life-cycle stages and the tailoring record.

No written list of critical information

SC-38 starts with the organization defining its operations security safeguards for key information, so a missing list leaves every later safeguard without a target. Teams often assume they know what is sensitive, but architecture diagrams, admin procedures, monitoring thresholds and vendor contacts rarely appear in one place. Check that the list names each item, its owner, where it is stored and which systems or roles can read it. Assessors will ask for this list first.

A list that never gets reviewed

A critical information list written once at system launch drifts as systems change, new vendors join and threat conditions shift. Set a review trigger tied to architecture changes, major releases and incidents, not only a calendar date. Record each review with a reviewer, the date and the changes made. An assessor comparing the list to current architecture will notice stale entries quickly.

OPSEC safeguards disconnected from risk assessments

SC-38 safeguards should follow from the threats and vulnerabilities the organization has identified, not from habit. Connect each safeguard to a specific risk in the risk assessment and threat and vulnerability assessment, and record the link. When a safeguard cannot be traced to any risk, either the risk register is incomplete or the safeguard is not needed. Assessors look for this traceability because the examine objects for SC-38 include both risk and threat assessments.

Sharing architecture and assessment material without a record

Architecture diagrams, control assessment results and vulnerability reports are often shared with auditors, integrators, vendors or consultants by email or shared drives with no log. Keep a register of what was shared, with whom, under which agreement and when, and restrict access by role. Permissions in wiki and documentation tools can be set per space, book or page, so review those settings against the register. Without a record, the organization cannot show that critical information stayed within the approved audience.

Life-cycle stages left out

SC-38 covers key information across the system development life cycle, and that includes planning, development, operations, maintenance and decommissioning. Teams usually protect production but forget design repositories, test environments with real topology, backups of documentation and the disposal of old diagrams. Map each life-cycle stage to the critical information it creates or holds, then confirm a safeguard exists for each. Decommissioning is the stage most often skipped.

Tailoring decisions with no recorded reason

SC-38 is not in any SP 800-53B baseline, so its presence in a system's control set depends entirely on a tailoring decision. Record whether SC-38 was selected or excluded, the reason, the risk that drove the choice and who approved it. An exclusion justified by the system's low impact should be stated, and so should an inclusion required by a contract or overlay. Assessors check that tailoring decisions are documented, because an undocumented omission looks like a missed control.

Questions buyers ask about SC-38 operations security

How much effort does SC-38 take for a typical system?

The effort depends mostly on how many items the organization decides are critical information and how many safeguards it must define for them. SC-38 has one organization-defined parameter and no enhancements, so the control itself is narrow, but the work of identifying critical information, listing the operations security safeguards that protect it, and tying those safeguards to risk and threat assessments can grow with system size and the number of teams involved. Drivers include how many development and operations workflows touch sensitive material, how often the system changes, and how mature existing risk and vulnerability assessments already are. Ask any provider to estimate effort against a named list of systems and workflows, and confirm whether the figure covers evidence collection for assessors or only the policy work.

Can an organization implement SC-38 without outside help?

Yes, an organization can define and document its own operations security controls, because SC-38 is an organization-implemented control and its assessment asks for evidence the organization already produces. Internal staff usually own the critical information inventory, the safeguards list and the link to risk assessments. Outside help is most useful when the team lacks time to map life cycle activities, needs a second review of what counts as critical information, or wants systems prepared for an assessor. An implementation partner prepares the systems, documentation and evidence, but the organization keeps ownership of the control, and only an independent assessor can issue a report.

How long does SC-38 work take, and what does the timing depend on?

No duration is set by the control or by the researched facts for this topic, so treat any timeline as something to confirm in writing. Timing depends on how many systems are in scope, whether the organization already has a current risk assessment and threat and vulnerability assessment process, how many people must review the critical information list, and whether SC-38 is being added to an existing authorization or assessment cycle. Work that involves several development teams across the system development life cycle usually takes longer than a single well-documented system. Ask for milestones tied to specific deliverables rather than a single end date.

What does SC-38 need from the client's own staff?

The work needs people who know the system's information and its workflows. Typical contributions include:

Information owners who can say which data, designs, credentials and configuration details are critical.
Engineering and operations leads who can describe how code, builds, logs and tickets move through the life cycle.
Security staff who maintain risk assessments, threat and vulnerability assessments and the list of operations security safeguards.
Compliance or assessment coordinators who collect evidence and track open items.

Budget time for these people before work starts, because the control depends on decisions only the organization can make.

Is SC-38 required at FedRAMP Class B, C or D?

No. Under the FedRAMP Rev5 baselines, SC-38 is not required at Class B, C or D. It is also not assigned to any SP 800-53B security or privacy baseline, so it applies only when an organization selects it through tailoring or an overlay. A cloud provider or agency may still choose to implement it because its own risk assessment calls for it, or because a contract names it. Confirm the current FedRAMP requirements with the authorizing body before scoping, since the baseline rules are published by FedRAMP and may change.

What should a written scope from an implementation partner include for SC-38?

A written scope should name the systems covered, the critical information categories agreed with the organization, and the operations security safeguards to be documented or implemented. It should list deliverables such as the critical information inventory, the safeguards register, the mapping to related controls, and the evidence pack for an assessor. Ask the partner to state what is excluded, which party performs each task, which assessment methods the evidence is prepared for, and how changes to scope are handled. Confirm that the partner prepares evidence but does not issue assessment reports, and ask how the organization's own staff will review and accept each deliverable.

Which related controls should be reviewed alongside SC-38?

SC-38 sits in a web of related controls, so an assessor will often look at more than the control alone. The catalog lists CA-2, CA-7, PL-1, PM-9, PM-12, RA-2, RA-3, RA-5, SC-7, SR-3 and SR-7 as related. The most direct links are to risk assessment and vulnerability scanning, because critical information and threats feed those processes, and to boundary protection, because some operations security safeguards depend on network controls. Review these alongside SC-38 so the evidence for one control does not contradict another.

How DeployOpen scopes and prepares SC-38 evidence

DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside the client's own infrastructure. For SC-38 Operations security, the work is to define which operations security safeguards protect key organizational information, then prepare the systems and records an independent assessor would examine. DeployOpen prepares evidence but does not issue assessment reports or certifications.

How we scope

Agree in writing which system boundary and life cycle stages the SC-38 safeguards must cover before work starts.
Confirm with the organization which critical information the operations security program protects and who owns that decision.
Record which related controls, such as SC-7, RA-3 and SI-2, feed SC-38 evidence in the agreed scope.

How we build

Configure self-hosted platforms so documented operations security safeguards are defined, versioned and traceable to named owners.
Build a repeatable check that confirms each agreed safeguard exists and is applied across the in-scope environment.
Test the safeguards against the examine objects an assessor would sample, such as risk and threat assessments and safeguard lists.

How we hand over

Deliver the SC-38 safeguard list, procedures and evidence index in the format the client's assessor has agreed to review.
Document operator steps, configuration keys and evidence locations so the client's own staff can reproduce each check.
Provide a closing record of open gaps with owners, so the organization can decide remediation and assessor scheduling.

How we support

Offer ongoing support, upgrades and continuous testing for SC-38 safeguards as a retainer after the fixed-scope work ends.
Review changes to the system and to SP 800-53 releases that could affect the SC-38 safeguard list or its evidence.
Ask the client to confirm with its assessor which evidence format and sampling approach it will accept before handover.