SC-31(3): Measure Bandwidth in Operational Environments

SC-31(3) sits under the NIST SP 800-53 System and Communications Protection (SC) family and is a targeted requirement: measure the bandwidth of a subset of identified covert channels in the operational environment of the system. The compliance trap is that many programs stop at “we identified covert channels” (paper exercise) or “we blocked obvious ones” (implementation claim) without proving how much information can still move through remaining paths under real conditions.

For a CCO, GRC lead, or system owner, the fastest path to compliance is to treat SC-31(3) as a measurable security performance requirement: you are expected to (1) decide which covert channels matter most, (2) measure how much data they can carry in production-representative conditions, and (3) use results to justify mitigations, exceptions, and ongoing monitoring.

This page is written to help you assign ownership, define a test cadence, create a clean evidence bundle, and be ready for assessments where an auditor asks, “Show me your covert-channel bandwidth measurements, in your operational environment, and what you did about the findings.”

Regulatory text

Requirement (verbatim): “Measure the bandwidth of [subset of identified covert channels] in the operational environment of the system.” ¹

Operator interpretation:

• You already have (or should have) an inventory of potential covert channels for the system (from architecture analysis, threat modeling, prior SC-31 work, or security assessment).
• You must select a subset of those channels and measure their bandwidth (how much information can be transmitted per unit time) in the operational environment (production or production-representative conditions, with real configurations, controls, and normal load).
• The output is not a policy statement. It is a test result with a method, assumptions, and conclusions you can defend in an assessment. ²

Plain-English interpretation (what “measure bandwidth” really means)

A covert channel is an unintended path to transfer information in a way that bypasses normal access controls or auditing. “Bandwidth” is the practical data-transfer capacity of that path under real system constraints. For SC-31(3), you are proving whether a given covert channel can move “meaningful” amounts of data in your environment and how quickly.

What examiners tend to probe:

• Did you measure in the real environment (same network segmentation, same endpoint controls, same cloud service configurations, same logging, same performance constraints)?
• Did you measure actual throughput, not just “possible in theory”?
• Did you document how you chose the subset and what you did after learning the measured bandwidth?

Who it applies to (entity and operational context)

Entity types (typical):

• Federal information systems.
• Contractor systems handling federal data. ³

Operational context (where it matters most):

• High-assurance environments (defense, intel, regulated federal workloads) where covert exfiltration risk is explicitly in scope.
• Multi-tenant or complex systems where unintended signaling paths exist (shared compute, shared caches, cross-service telemetry, CI/CD systems, observability pipelines).
• Systems that process sensitive data types where “low-and-slow” exfiltration is still damaging.

System scope tip: tie SC-31(3) to a defined authorization boundary (or equivalent boundary definition). If you cannot state what “the system” includes, you cannot credibly claim you measured covert-channel bandwidth in its operational environment.

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

Step 1: Assign ownership and define the control “run”

Make SC-31(3) operational by creating a one-page control card (runbook format):

• Control objective: quantify covert-channel throughput for prioritized channels in the operational environment.
• Control owner: usually Security Engineering or a Red Team function; GRC owns oversight and evidence quality.
• Trigger events: major architecture changes, platform changes, network redesign, new monitoring tooling, new remote admin pathways, new third-party integrations.
• Execution cadence: set one that matches change velocity; define “out-of-cycle” testing when triggers occur.
• Exception rules: what you accept, who can approve, how long exceptions last, and what compensating controls apply.

This directly addresses the common audit failure: no one can show who owns it or when it runs. ¹

Step 2: Define your “subset of identified covert channels”

You need a documented selection rationale. A practical selection method:

1. Start from your identified covert channels list (from prior assessments, threat modeling, SC-31 work, pen tests, architecture review).
2. Rank by impact if exploited and likelihood in your environment.
3. Pick the subset that is both plausible and high impact.

Use a simple decision matrix for each channel:

Channel candidate	Data types exposed	Preconditions	Detectability	Expected throughput	Selected?	Rationale
Timing channel via API response latency	sensitive metadata	attacker can send queries	medium	unknown	yes	plausible external path
Storage/queue backpressure signal	operational data	needs internal foothold	low	unknown	no	out of boundary
Shared resource contention signal	secrets inference	co-resident compute	low	unknown	yes	multi-tenant risk

Your matrix is evidence that “subset” was intentional, not arbitrary.

Step 3: Design a bandwidth measurement approach that is repeatable

Define, in writing, for each selected channel:

• Test hypothesis: what information is being encoded, where, and how it is decoded.
• Measurement unit: bits/sec or bytes/sec, plus error rate (how often decoding fails).
• Test duration and run conditions: normal load vs maintenance windows; expected network jitter; expected scaling behavior.
• Instrumentation: how you capture timing, logs, packet traces, application metrics, or host telemetry.
• Safety controls: do not disrupt production; set guardrails; get change approval if needed.

If you run tests in production, use a controlled and approved method that cannot degrade availability. If you run in a production-representative environment, document exactly how it matches production (configs, policies, instance types, security agents, scaling rules).

Step 4: Execute testing in the operational environment and record results

Run the tests and record:

• Environment identifier (prod cluster name, account/subscription, region, VPC/VNet, or equivalent).
• Configuration snapshot references (IaC commit hash, policy version, security agent version).
• Normal operating conditions evidence (performance metrics, baseline load indicators).
• Raw observations and derived bandwidth calculation.

Your output should be measurable and reviewable by someone else.

Step 5: Compare results to risk tolerance and decide remediation vs acceptance

SC-31(3) is measurement, but assessments will ask what you did with the data. Build a decision point:

• If bandwidth is trivial and exposure is limited, document risk acceptance with reasoning and compensating controls (monitoring, segmentation, rate limiting, noise injection, isolation).
• If bandwidth is meaningful or the channel bypasses key controls, create a remediation plan: reduce capacity (rate limiting, scheduling randomization, constant-time responses), remove shared resources, add isolation boundaries, or add detection for channel use patterns.

Track remediation items to closure with owners and due dates. ¹

Step 6: Package evidence and keep it audit-ready

Centralize artifacts in a controlled repository (GRC tool, ticketing system, or secured document store) with consistent naming: SC-31(3)_CovertChannelBandwidthTest_<System>_<Date>.

If you use Daydream, treat SC-31(3) as a requirement card with embedded run steps, required evidence fields, and recurring control health checks so the control stays “alive” across engineering turnover. ¹

Required evidence and artifacts to retain

Minimum evidence bundle (keep it tight and defensible):

1. SC-31(3) control card/runbook (owner, triggers, cadence, scope, exception path).
2. Covert channel inventory (or pointer to where it lives) and the subset selection matrix with rationale.
3. Test plan per channel (method, metrics, environment, safety constraints).
4. Execution records (change approvals if applicable, test date/time, operator, environment identifiers).
5. Raw data (logs, traces, metrics exports) and bandwidth calculation worksheet (even if it’s a script output).
6. Results report summarizing measured bandwidth, error rates, and interpretation.
7. Risk decision artifacts: remediation tickets, risk acceptance memo, or exception approvals.
8. Control health check records showing the control continues to run and findings are managed. ¹

Common exam/audit questions and hangups

Expect these questions, and pre-answer them in your evidence:

• “Show me the list of identified covert channels and which subset you chose for SC-31(3). Why those?”
• “How do you know your testing environment is ‘operational’ or production-representative?”
• “What is your measurement method? Could another engineer reproduce it?”
• “Where are the raw results and the calculation?”
• “What changes trigger re-measurement?”
• “What did you remediate based on results, and how do you know remediation worked?”

Hangups that cause findings:

• You only have a narrative statement (“we assessed covert channels”) with no measurements.
• You measured in a lab that does not match production controls (different IAM, agents, segmentation, autoscaling, or observability).
• You cannot show a traceable path from measurement results to risk decisions.

Frequent implementation mistakes and how to avoid them

1. Mistake: treating “subset” as a loophole.
   Fix: define selection criteria and document why excluded channels are out of scope or lower risk.

2. Mistake: measuring theoretical maximum bandwidth.
   Fix: measure under the same constraints attackers face in your environment (rate limits, jitter, detection controls, quotas).

3. Mistake: no link to system boundary.
   Fix: include a one-paragraph scope statement and boundary diagram reference in the test plan.

4. Mistake: results exist, but no operational response.
   Fix: require a decision record for each tested channel: mitigate, accept, transfer, or avoid, with an owner.

5. Mistake: evidence scattered across engineers’ laptops.
   Fix: standardize the evidence bundle and retention location; make it part of the “definition of done” for each test cycle. ¹

Enforcement context and risk implications

No public enforcement cases were provided in the supplied source set for this requirement, so this page does not claim specific regulator actions tied to SC-31(3).

Risk-wise, weak SC-31(3) execution creates two concrete exposures:

• Security exposure: covert channels are designed to bypass typical controls; unmeasured bandwidth means you do not know whether an attacker could exfiltrate meaningful data without tripping alerts.
• Assurance exposure: in federal assessments and customer due diligence, inability to show measurement artifacts can result in control failure, POA&M creation, delayed ATO, or loss of trust in the system security narrative. ³

Practical 30/60/90-day execution plan

Use phases rather than day-count guarantees; adjust to your change velocity and system criticality.

First 30 days (stand up the control)

• Name the SC-31(3) owner and backup; publish the control card.
• Confirm system scope and where the covert channel inventory lives.
• Define channel selection criteria and pick the initial subset.
• Draft test plans for each selected channel, including safety constraints and approvals needed.
• Set the evidence bundle template and repository location.

Days 31–60 (run first operational measurements)

• Execute measurement for the first set of channels in the operational environment (or a documented production-representative environment).
• Produce a results memo with raw-data references and computed bandwidth.
• Open remediation tickets for findings that exceed your risk tolerance; assign owners and target dates.
• Define re-test triggers tied to architecture and configuration change events.

Days 61–90 (close the loop and industrialize)

• Re-test channels after mitigations to prove bandwidth reduction (or validate compensating controls).
• Add control health checks: verify cadence, evidence completeness, and ticket closure.
• Integrate SC-31(3) into change management: a trigger checklist item when relevant components change.
• Prepare an “audit-ready packet” so you can answer assessor questions in a single share.

Frequently Asked Questions

Do we have to test in production for SC-31(3)?

The requirement says “operational environment,” so production is the cleanest interpretation. If you use a production-representative environment, document exactly how it matches production configurations and constraints. ¹

What counts as a “covert channel” in practice?

It’s an unintended communication path that can encode information through side effects like timing, resource contention, or signaling via shared components. Your inventory can come from threat modeling, architecture review, or security testing outputs, but SC-31(3) expects measurable follow-through. ³

How do we choose the “subset of identified covert channels” without getting flagged?

Use written criteria (impact, likelihood, exposure path, feasibility) and a selection matrix that shows why each channel was included or excluded. Assessors mainly look for a rational, risk-based choice and evidence that the choice is revisited when the system changes. ¹

What artifact usually satisfies auditors the fastest?

A short test report per channel with raw evidence references, the bandwidth calculation, and a decision record (mitigate or accept) tied to tickets. Pair it with a control card that defines owner, triggers, cadence, and retention. ¹

What if engineering says measuring covert channels is “not feasible”?

Treat that as a risk statement that needs documentation: which channels, what makes measurement infeasible, and what compensating controls you apply. Then test the next most relevant channels where measurement is feasible, so the control still operates. ³

How do we keep SC-31(3) from becoming a one-time assessment artifact?

Tie it to change triggers (platform upgrades, new shared services, observability changes) and run periodic control health checks that verify evidence completeness and remediation closure. A GRC workflow tool like Daydream helps by templating the runbook and evidence bundle and tracking recurring execution. ¹

Footnotes

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

2. NIST SP 800-53 Rev. 5 DOI

3. NIST SP 800-53 Rev. 5