SC-31 Covert channel analysis: requirements and evidence

What SC-31 covert channel analysis asks for and why it is selected

If a tailoring decision or an overlay has pulled SC-31 into your scope, the core requirement is narrow but demanding: identify the communications inside your system that could carry information in ways your security policy does not allow, and estimate the maximum bandwidth of each one. A covert storage channel lets one process write data into a shared resource that another process reads, such as a file attribute, a shared counter or a resource-allocation field. A covert timing channel encodes information in the timing of events, such as response delays or the order in which resources are granted. Neither channel uses a normal, documented data path, which is why ordinary data flow reviews and encryption controls often miss them.

SC-31 is not part of any SP 800-53B low, moderate or high baseline, and the same is true of its three enhancements. It is selected only when an organization chooses it through tailoring or an overlay, usually because the system handles information whose disclosure would be serious enough to justify the analysis effort. Before accepting it into scope, confirm with the authorizing official whether the system's threat model and information types warrant it, and record that decision and its rationale in the system security and privacy plan. Appendix C of SP 800-53 classifies the control as implemented by the organization and as assurance-related, so the work must be owned internally, even when outside specialists help.

The analysis is hard because it depends on knowledge that is rarely written down in one place. The analyst must understand shared resources, scheduling behavior, caching, logging and how components interact under load, and must decide which of those paths count as channels worth measuring. Bandwidth estimates require a method and assumptions that an assessor can follow and reproduce, so ask for a written method, the system design documentation it relies on and the configuration settings that were examined. Plan for the analysis to be repeated when the architecture changes, and expect the most useful output to be a short list of channels, each with a bandwidth estimate and a documented decision about whether to remove, limit or accept it.

Which systems and decisions bring SC-31 into scope

SC-31 is not in any SP 800-53B baseline, so it reaches a system only when an organization or an overlay selects it. The cards below cover the boundary, shared resources, high-assurance interfaces and related controls that determine how much analysis is needed and what evidence the assessor will expect.

Choosing the system boundary

The analysis only covers communications inside the boundary you name, so the boundary decision sets the whole scope. Include shared hypervisors, management networks, logging pipelines and identity services that the system depends on, not just the application tier. Confirm in writing which components sit inside, which are inherited from a provider, and which are out of scope, because an assessor will test the analysis against the boundary in the system security plan.

Shared resources and multi-tenant components

Storage and timing channels usually appear where tenants or domains share hardware, caches, schedulers, queues or storage pools. If the system runs on shared infrastructure, list every resource that more than one workload can observe or influence. Multi-tenant platforms, shared databases and common message brokers deserve the closest review because a low-bandwidth channel there can persist unnoticed.

Cross-domain and high-assurance interfaces

Any interface between security domains of different sensitivity is a likely place for information to move in ways the policy forbids. Guards, data diodes, one-way transfers and shared gateways should be listed explicitly. Ask whether the interface was designed to carry only approved fields, and whether anyone has measured what else a sender can encode through timing, ordering or error behavior.

Related controls the analysis touches

SC-31 sits alongside AC-3 (access enforcement), AC-4 (information flow enforcement), SA-8 (security and privacy engineering principles) and SI-11 (error handling). Findings from the covert channel analysis often trace back to these controls, so decide early which control owner receives each finding and how the evidence for those related controls will be cross-referenced in your assessment package.

Overlays and organizational selection

FedRAMP's Rev5 baselines do not require SC-31 at Class B, C or D, so for most cloud systems the control appears only because the organization or an overlay selected it. Record the reason for selection in the tailoring decision and the system security plan. An assessor will ask why the control is in scope and why the boundary was drawn where it was, so the rationale should exist before the analysis starts.

Assessment evidence the scope must produce

SP 800-53A expects the examine methods to draw on covert channel analysis documentation, system design documentation, configuration settings and audit records. Scope the work so each of these artifacts exists for the components inside the boundary. Confirm with your assessor which artifacts they will sample and whether the analysis must be refreshed after significant design or configuration changes.

How to run a covert channel analysis step by step

This sequence turns SC-31 into a documented analysis: it starts from the information flows the policy protects, works through the system design to find channels, estimates their bandwidth, and ends with a recorded decision on each channel.

Define the policy information flows
Start by stating which information flows the system policy forbids, such as high-classification data reaching a lower-classification user, or tenant data reaching another tenant. The system owner and the security team write this list, usually drawn from the security categorization and the access control policy in the AC family. The analysis is only as useful as this list, so it should name the subjects, objects and direction of each prohibited flow. The output is a signed list of prohibited flows that the rest of the analysis tests against. You know this step is done when every later channel can be traced back to a named flow.
Gather system design documentation
Collect the artifacts an assessor will also examine: system design documentation, architecture diagrams, system configuration settings and the audit records that show how components behave. The security architect owns this collection, and the system owner confirms it reflects the system as deployed rather than as originally planned. Gaps found here are recorded as open items, not guessed around. The output is a versioned evidence set with a named reviewer. You know this step is done when every component that touches a prohibited flow has a current design reference.
Inventory shared resources and observable timing
Using the design set, list the shared resources that more than one subject can read or write, such as files, locks, quotas, scheduler state, caches, buffers and shared database tables. Also list behavior that an observer could time, such as response latency, queue depth and resource contention. Engineers who know the platform internals should lead this work, because the obvious resources are rarely the only ones. The output is a resource and timing inventory, each entry tied to the components that expose it. You know this step is done when a second engineer can reproduce the list from the same documents.
Identify candidate storage and timing channels
For each prohibited flow, pair a sender and a receiver that could use a shared resource or observable timing to pass information across it. Classify each pairing as a storage channel, where one party writes state that another reads, or a timing channel, where one party modulates timing that another observes. Record the mechanism in plain terms and the components involved. Where the team cannot rule out a pairing, it stays on the candidate list. The output is a candidate channel register with an identifier, mechanism, sender, receiver and the flow it violates. You know this step is done when every prohibited flow has either candidates or a written reason why none apply.
Estimate maximum bandwidth for each channel
For each candidate, estimate the maximum rate at which information could cross it under the most favorable conditions for the attacker, then compare that estimate with what the policy tolerates. Measurements from a test environment, controlled experiments and the rate limits of the shared resource all feed this estimate. The estimate should state its assumptions, such as the number of observable states and the sampling rate, so a reviewer can challenge it. The output is a bandwidth estimate per channel with its method and assumptions recorded. You know this step is done when every candidate carries a number and a stated basis, even if the basis is a bound rather than a measurement.
Decide mitigations or accepted risk
For each channel, the system owner and the authorizing official choose one of two outcomes: a mitigation that reduces or removes the channel, such as isolating the resource, adding noise or fixing the scheduler, or a documented acceptance of the residual risk. Mitigations are then assigned to the configuration management and system development teams and tracked in the plan of action and milestones. Accepted risks go into the authorization package with the bandwidth estimate and the reasoning. The output is a decision per channel with an owner and a tracking reference. You know this step is done when no channel is left without a decision.
Record the analysis output for assessors
Assemble the covert channel analysis document: the prohibited flows, the design evidence, the channel register, the bandwidth estimates with assumptions, and the decisions with their owners. Keep the version and date of each input, and retain the record with the system security and privacy plan. An independent assessor will examine this document against SC-31's determination statements, and interviews will test whether the people named actually own their decisions. The output is a dated analysis report that an assessor can trace from flow to channel to decision. You know this step is done when a reviewer outside the project can follow any channel from its prohibited flow to its closing decision without asking the authors.
Re-run the analysis after significant change
Treat the analysis as a living record. When the architecture, shared components, scheduler, hypervisor, storage layer or the policy itself changes, the team reviews which channels are affected and updates the register and estimates. Ask the platform engineers and the security team to agree on what counts as significant change under the organization's change process. The output is an updated analysis version with a change log that links to the triggering change. You know this step is done when each significant change has a recorded decision on whether the covert channel analysis needed updating.

How an assessor tests SC-31 against the SP 800-53A procedures

This table maps each SP 800-53A examine object for SC-31 to the evidence an assessor requests, the interview and test methods that go with it, and the findings that most often delay an assessment. Read it as a checklist of what to have ready before an assessor arrives, since the organization owns the analysis and only the independent assessor reaches a conclusion.

Assessment element	What the assessor checks	Evidence to have ready	Common finding
Determination statement 1	The covert channel analysis identifies communications within the system that could serve as covert storage or timing channels	Written covert channel analysis listing candidate storage and timing channels, with the system components examined	Analysis lists no channels and gives no reasoning for why none exist
Determination statement 2	An estimate of the maximum bandwidth of each identified channel is provided	Bandwidth estimates with the method, assumptions and measurements behind each figure	Bandwidth numbers appear without a stated basis or test data
Examine: covert channel analysis documentation	Analysis is current, scoped to the system and reviewed by people who understand the design	Analysis document with version history, scope statement, reviewer names and review dates	Analysis was written once and does not reflect later architecture changes
Examine: system design documentation	Designs show the shared resources and timing paths that the analysis should have considered	Architecture diagrams, data flow diagrams and descriptions of shared resources such as caches, queues and scheduling	Design documents omit shared components, so the analysis cannot be traced to the system
Examine: system configuration settings and associated documentation	Settings that create or limit channels, such as resource sharing, logging and scheduling options, are documented and match the analysis	Configuration baselines, exported settings and change records tied to the channels named in the analysis	Settings in production differ from those described in the analysis
Examine: system audit records	Audit records show whether channel-related events are logged and reviewed	Sample log entries, log source lists and review records for events relevant to the identified channels	No audit records exist for the components the analysis flags
Interview	Engineers and security staff explain how channels were identified and what mitigations are in place	Named interviewees with roles, and a short walkthrough of the analysis method	Staff cannot explain the method or who maintains the analysis
Test	Assessor or tester checks whether a flagged channel can be used at the estimated rate in a controlled setting	Test plan, test environment description, measurement results and any deviations from the estimate	No test was run, or results were never compared with the bandwidth estimate

Evidence that passes a covert channel review

SC-31 is judged on documents and records rather than a single test result. The analysis, the channel inventory, the bandwidth estimates and the decisions made about each channel must agree with the system as it is actually built and configured.

Analysis document with scope and method

The covert channel analysis itself is the first artifact an assessor reads. It should state the system boundary, the components and interfaces analyzed, the method used to find storage and timing channels, and the people who performed and reviewed the work. Check that the scope matches the current system security plan boundary, not the architecture from the original design. An analysis that names a method but not the components it covered gives an assessor nothing to test against.

Channel inventory with classification

The inventory lists each identified storage channel and timing channel, the shared resource or mechanism it uses, and the security policy it could violate. Each entry should say whether the channel is eliminated, reduced or accepted. Ask the team that produced the inventory to show how it searched shared resources such as scheduling, caches, locks, file metadata and resource quotas. An inventory with no entries for a multi-tenant or shared-resource design should prompt questions.

Bandwidth estimates with stated assumptions

SC-31 asks for an estimate of the maximum bandwidth of each identified channel. The estimate is only as credible as its assumptions, so record the measured or modeled timing resolution, the sampling rate, the noise assumed, and the test conditions. Keep the calculation in a version-controlled file so an assessor can reproduce it. Estimates without assumptions cannot be reviewed, and estimates taken from a previous system version need to be re-run before they are cited.

Mitigation and risk acceptance records

Every channel in the inventory needs a recorded decision. A mitigation record names the change made, such as limiting a shared counter, adding noise to timing responses or partitioning a resource, and links it to the configuration that implements it. A risk acceptance record names the accountable official, the estimated bandwidth, the reasoning and the review date. Confirm that acceptance was signed by someone with authority over the risk, not by the team that owns the system.

Configuration evidence for mitigations

Each mitigation should be visible in the configuration of the running system. Collect exported settings for the affected components, such as hypervisor or operating system resource controls, scheduler parameters, quota settings and network or storage partition definitions. Store exports with timestamps and the version of the baseline they came from. A mitigation described in the analysis but absent from the configuration export is a finding an assessor will raise.

Audit records supporting design claims

Where the analysis states that a channel is not usable in practice, audit records and monitoring data should back that claim. Examples include logs showing that a shared resource is not reachable across the security domains in question, or records showing that rate limits or access controls were enforced during testing. Confirm that the logs are retained under the organization's audit policy and that the relevant events are actually being recorded. Claims without supporting records weaken the whole analysis.

Change-driven updates to the analysis

The analysis is a living record that must be revisited when the system design changes. Tie the covert channel analysis to the configuration change process so that a new shared component, a changed scheduler, a new tenant model or a new interface triggers a review of the affected channels. Record each review, even when no channel changes, with the date and the reviewer. Ask the team how a change request reaches the analysis owner and how stale estimates are flagged before the next assessment.

What meeting SC-31 costs in money and effort

This table lists the cost components of a covert channel analysis, who is paid for each, whether it is one-time or recurring, and what drives it up. No figures are supplied for these components, so use the drivers and quote requests to compare proposals. The main takeaway is that the analysis is a one-time expense that becomes recurring whenever the design changes.

Cost component	Who is paid or who bears it	One-time or recurring	What drives it
Specialist analysis time	Internal security engineers or an outside specialist firm	One-time for the baseline analysis, recurring for re-analysis	Number of shared resources, storage and timing paths, and depth of the bandwidth estimate
System design review	Architects and engineers, internal or contracted	One-time, then recurring at each major design review	Number of components, interfaces and shared-resource mechanisms in scope
Mitigation engineering	Platform engineers or implementation partner, paid under a fixed-scope agreement	One-time for initial mitigations, recurring when new channels appear	Number of channels that exceed the acceptable bandwidth and the cost of removing each one
Evidence upkeep after design changes	Control owner and engineers who update analysis documents and configuration records	Recurring	Frequency of system changes, release cadence and how closely documents track configuration
External review	Independent assessor or reviewer, paid directly by the organization	Recurring at each assessment cycle	Assessment scope, the assessor's method and whether the organization needs an independent opinion on the bandwidth estimate
Auditor sampling	Assessor, paid by the organization under its assessment engagement	Recurring at each assessment cycle	Number of sampled design changes, the examine objects requested and the volume of audit records to review

Who owns the analysis, who prepares it and who assesses it

The organization owns SC-31. It decides whether the control is selected at all, since SP 800-53B does not place SC-31 in any baseline, so it arrives through tailoring or an overlay. It also owns the analysis conclusions, the list of channels it accepts or mitigates, and the risk decisions attached to any residual bandwidth. Those decisions belong to accountable officials, not to a vendor or an auditor.

Selection and scope: Record why SC-31 is in the authorization boundary, which system components it covers, and which tailoring decision brought it in.
Organization-defined parameter: Set the value the control leaves to the organization and document the rationale.
Risk acceptance: Name who accepts any channel that cannot be eliminated and the review date for that acceptance.
Policy linkage: Connect the analysis to the information flow and separation policies that define what counts as a violation.
Ongoing ownership: Assign a person to rerun the analysis after significant design changes.

Before engaging anyone, confirm internally who signs the analysis and who is accountable for the accepted residual channels.

Where SC-31 analyses usually fall short

A covert channel analysis is easy to produce once and hard to keep true. The gaps below cover the analysis itself, its bandwidth estimate, the hosts it overlooks, how it stays current and who owns the risks it leaves open. Each card ends with the check that closes the gap.

Analysis stops at design

Many analyses describe the channels a design was expected to have and never test the running system. SC-31 asks for communications within the system that could serve as covert storage or timing channels, so the analysis should trace those paths through the implemented components, configurations and audit records. Check that the analysis cites configuration settings and system audit records, not only design documents.

No bandwidth estimate

Identifying a possible channel is only half of the control. The requirement also calls for an estimate of each channel's maximum bandwidth, which tells the authorizing official whether a channel is a practical leak or a theoretical one. An analysis that lists channels without rates leaves that judgment undocumented. Confirm every listed channel has a stated maximum bandwidth and the method used to estimate it.

Shared and virtualized hosts overlooked

Covert timing and storage channels often run through resources that tenants or processes share, such as CPU caches, hypervisor scheduling, shared storage and memory pages. Analyses built around network flows miss these paths entirely. For an illustrative case, a workload on a shared hypervisor host might influence another workload's observable timing without any network traffic between them. Check that hypervisor, host and shared storage paths are inside the analysis scope.

Analysis not refreshed after change

A channel analysis describes the system as it was when the analysis was written. New components, changed resource sharing, a platform upgrade or a new integration can open channels that did not exist before. Without a trigger tied to change control, the analysis quietly becomes out of date while still appearing complete. Tie the analysis to change requests so significant architecture changes require a documented re-review.

Accepted risks with no owner

When a channel is judged too low in bandwidth to fix, the decision to accept it often sits in the analysis document with no named person behind it. Accepted risk without an owner is rarely reviewed and rarely revisited when conditions change. The organization owns this decision, not the implementation partner or the assessor. Record a named risk owner, the bandwidth estimate behind the decision and a review date for every accepted channel.

Questions buyers ask about SC-31 cost, effort and outside help

Is SC-31 covert channel analysis required by default under NIST SP 800-53?

No. SP 800-53B does not assign SC-31 to the low, moderate, high or privacy baseline, so it applies only when your organization selects it through tailoring or an overlay. Appendix C of SP 800-53 Rev. 5 lists it as implemented by the organization and marks it as assurance-related. Check whether your authorizing official, contract or overlay names it before you plan work for it. If a customer or assessor asks for it, the requirement comes from that agreement, not from the baseline itself.

What drives the effort of a covert channel analysis?

The main driver is how many shared mechanisms the system has and how complex its design is. Assessors expect the analysis to cover storage channels, such as shared resources that one process can write and another can read, and timing channels, such as observable delays that encode data. Effort rises with the number of tenants or security domains, the amount of shared hardware and software, the number of interfaces that share resources, and how much design documentation already exists. Work also grows when the bandwidth estimate must be defended with measurements rather than reasoning.

What does the internal team need to provide for SC-31?

The organization owns the control, so internal staff must supply the knowledge the analysis depends on. That includes current system design and architecture documentation, configuration settings for shared components, a list of the security domains and the information policy each must enforce, and access to people who can explain how resources are shared. Someone with authority over the system must also decide which channels are acceptable, document that decision and accept the residual risk. An outside partner can prepare the analysis, but it cannot make those policy decisions for you.

Can we do SC-31 covert channel analysis in-house?

Often yes, if your team has engineers who understand the operating system, hypervisor, network stack and storage layers well enough to find shared resources and measure timing behavior. The work is technical and specialized, so most teams need a clear method, repeatable tests and an independent review of the findings. Consider an outside partner when your staff lacks time, when the system is complex, or when an assessor will expect a second set of eyes. Whichever route you take, the auditor or assessor evaluates the result and issues any formal conclusion.

How long does a covert channel analysis take?

Duration depends on scope, and no supplied figure sets a standard length. Timelines grow with the number of components in the analysis boundary, the number of security domains that must be checked against each other, and whether bandwidth estimates require controlled tests on live or staging hardware. Access to staff and documentation often decides how quickly work moves, so delays in those inputs usually matter more than the technical testing itself. Ask any provider to break the timeline into discovery, testing, estimation, documentation and review phases so you can see where your team's input is needed.

What should a fixed-scope written quote for SC-31 include?

A fixed-scope quote should state exactly what is covered before work starts. Ask for the system boundary and the components inside it, the security domains and policies in scope, the channel types to be examined, and the method for estimating maximum bandwidth. List the deliverables, such as the analysis report, identified channels, bandwidth estimates and recommended mitigations, along with the review and acceptance steps. Confirm the timeline, your team's responsibilities, the assumptions behind the quote, and what happens if the scope changes. DeployOpen agrees scope, deliverables and timelines in writing before work begins, and a quote follows from that written scope.

Who issues the assessment result for SC-31?

Only an independent assessor, auditor or certification body issues an assessment result or report. DeployOpen prepares systems, controls and evidence, including the covert channel analysis documentation that assessors examine under SP 800-53A. Your organization remains responsible for the control, its risk decisions and its authorization. Ask the assessor early which evidence they expect, such as design documentation, configuration settings and audit records, so the analysis is built to match that request.

Which related controls should we review alongside SC-31?

The catalog links SC-31 to AC-3, AC-4, SA-8 and SI-11. Access enforcement (AC-3) and information flow enforcement (AC-4) determine which information may move between components, so they shape which channels matter. Security engineering principles (SA-8) explain how the design was meant to limit sharing, and error handling (SI-11) affects whether error messages can leak data. Reviewing these together prevents a covert channel analysis from testing a design that differs from what your access and flow controls actually enforce.

How DeployOpen prepares SC-31 evidence

The first step in preparing SC-31 evidence is deciding which system is being analyzed. DeployOpen works with the organization to fix the system boundary before any analysis starts, listing the components, shared services, hypervisors, storage back ends, logging pipelines and management paths that the covert channel analysis will cover. This matters because SC-31 asks about communications within the system, so an unclear boundary produces an analysis that an assessor will reject as incomplete. Confirm early whether the organization wants the analysis to cover only the platform it operates or also the shared infrastructure beneath it, since that choice changes the design documents an assessor will request.

DeployOpen then collects the design and configuration evidence the assessor will examine: system design documentation, the configuration settings that govern shared resources and their documentation, and the system audit records that show how those settings are enforced and monitored. For a self-hosted open-source platform, this usually means exporting configuration from the platform and infrastructure-as-code repositories, recording versions and change history, and mapping each shared resource that could carry a storage or timing channel to the control that limits it. The analysis method itself, including how channel candidates are identified and how bandwidth is estimated, is set with the organization's security team and documented so the reasoning can be repeated. Ask the organization which analysis method its assessor accepts before work begins.

DeployOpen packages the record for the independent assessor, who is the only party that tests the control and issues any assessment result. The package contains the scope statement, the design and configuration evidence, the analysis documentation and the change history, arranged against the SC-31 determination statements in SP 800-53A. DeployOpen does not issue assessment results. The work is fixed-scope, with deliverables agreed in writing before it starts. The organization owns the risk decision on any channel that remains open, including whether it accepts the estimated bandwidth, mitigates it or escalates it, and that decision belongs in the organization's own risk records.