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

SC-31(3) requires you to measure the available bandwidth of the organization-defined communication paths in the system’s real operational environment (not a lab) and keep evidence that the measurements are repeatable and tied to risk decisions. Operationalize it by defining scope, selecting measurement methods, scheduling tests, capturing results, and feeding findings into capacity, resilience, and change management. (NIST SP 800-53 Rev. 5 OSCAL JSON)

Key takeaways:

• Define exactly which “communication paths” are in scope and measure them where users and workloads actually run. (NIST SP 800-53 Rev. 5 OSCAL JSON)
• Treat bandwidth measurement as recurring operational monitoring with documented triggers, not a one-time certification artifact.
• Retain raw outputs, analysis, and remediation tickets that show you acted on constraints and regressions.

“Measure bandwidth” sounds straightforward until an assessor asks, “Bandwidth of what, measured how, and under what conditions?” SC-31(3) is about proving you understand the throughput limits of the communication paths your system depends on, in the same environment where mission workflows execute. That means measurements must reflect real routing, security controls, congestion patterns, and shared infrastructure behaviors.

For a Compliance Officer, CCO, or GRC lead, the fastest path is to turn SC-31(3) into a small, testable operational requirement with clear ownership: define in-scope paths, define measurement frequency and triggers, run the measurements, and keep evidence that ties results to decisions. This control often gets weak implementations because teams confuse link speed (provider rate) with measured throughput, or they test in staging and call it “close enough.”

This page gives requirement-level implementation guidance you can hand to a network/SRE lead and then audit against. It is written for NIST SP 800-53 Rev. 5 programs and aligns to assessment expectations for federal systems and contractor systems handling federal data. (NIST SP 800-53 Rev. 5)

Regulatory text

Control requirement (verbatim): “Measure the bandwidth of {{ insert: param, sc-31.03_odp }} in the operational environment of the system.” (NIST SP 800-53 Rev. 5 OSCAL JSON)

What the operator must do

• Define the organization-defined parameter (the placeholder in the text): which communication paths, links, circuits, tunnels, or network segments you will measure. (NIST SP 800-53 Rev. 5 OSCAL JSON)
• Measure bandwidth in production-like reality: in the operational environment where the system runs, including security controls (e.g., VPN, ZTNA, firewalls), routing, and shared capacity. (NIST SP 800-53 Rev. 5 OSCAL JSON)
• Show repeatability and governance: measurements must be documented, attributable to a control owner, and retained as evidence. (NIST SP 800-53 Rev. 5 OSCAL JSON)

Plain-English interpretation

SC-31(3): measure bandwidth in operational environments requirement means you must prove, with real measurements, that the network paths your system relies on can carry the traffic your system needs under actual operating conditions. Your measurements should be good enough to answer:

• “What throughput do we actually get on this path?”
• “Does it meet system needs during normal and peak use?”
• “How do we detect and respond when bandwidth drops due to a change, congestion, or misconfiguration?”

This is a performance-and-resilience requirement that supports availability objectives and helps prevent self-inflicted outages during scaling events, routing changes, or security control rollouts.

Who it applies to

Entity scope

• Federal information systems implementing NIST SP 800-53 Rev. 5 controls. (NIST SP 800-53 Rev. 5)
• Contractor systems handling federal data where NIST SP 800-53 controls are flowed down through contracts, overlays, or authorizing officials. (NIST SP 800-53 Rev. 5 OSCAL JSON)

Operational scope (systems and situations)

Apply SC-31(3) to systems where bandwidth constraints could degrade mission delivery, security telemetry, recovery, or user experience, including:

• Internet egress/ingress paths and DDoS scrubbing routes
• WAN links between sites, data centers, and cloud interconnects
• Encrypted tunnels (site-to-site VPN, SD-WAN overlays)
• Paths to critical third-party dependencies (identity providers, payment processors, managed SOC/SIEM ingestion)
• East-west paths that affect distributed services, storage replication, and backups

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

Step 1: Name a control owner and write the “ODP” definition

SC-31(3) hinges on the organization-defined parameter. Create a short control attachment that states:

• In-scope communication paths (by name/ID)
• Measurement method(s)
• Success criteria (what “acceptable” means for your system)
• Measurement cadence and triggers
• Evidence to retain and where it lives

Keep this tight enough that an engineer can execute without interpretation drift. This mapping and evidence orientation is the fastest way to avoid “we did it once” failures. (NIST SP 800-53 Rev. 5 OSCAL JSON)

Step 2: Build an inventory of in-scope communication paths

Create a table and keep it current via change management:

Path ID	From → To	Type	Owner	Dependency criticality	Measurement point(s)
WAN-01	Site A → DC	MPLS/SD-WAN	Network	High	Edge router A/B
CLD-02	VPC → On-prem	Direct connect/VPN	Cloud NetOps	High	VPC TGW + on-prem gateway
EXT-03	App → Third party	Internet + TLS	SRE	Medium	App subnet egress

Tie this inventory to your system boundary documentation and architecture diagrams so scope is defensible during assessment. (NIST SP 800-53 Rev. 5)

Step 3: Choose measurement methods that reflect reality

Use at least one method that measures effective throughput (not just carrier-rated speed). Common options:

• Active tests (scheduled throughput tests) between defined endpoints
• Passive observation (flow logs, interface counters, telemetry) to validate sustained throughput during real workloads
• Synthetic transactions that approximate application payload patterns if raw throughput tests are risky in production

Define guardrails to avoid disrupting operations (off-peak windows, rate limits, test duration caps). Document the rationale for your method selection in the control procedure so assessors see intent and safety controls.

Step 4: Run measurements in the operational environment

Execution requirements that auditors commonly expect you to show:

• Tests run on the actual path (same routing, same encryption, same security stack)
• Endpoints are representative (production subnets, real gateways, real zones)
• Results include timestamp, endpoints, configuration, and raw output

If you cannot run active tests in production, document why and implement compensating evidence: passive telemetry paired with controlled, limited-scope tests during maintenance windows. Keep the decision record.

Step 5: Analyze results against system needs and document conclusions

For each in-scope path, produce a short “bandwidth adequacy” note:

• Observed throughput range (qualitative is acceptable if you avoid unsupported precision)
• Known bottlenecks (provider shaping, MTU issues, firewall CPU, tunnel overhead)
• Risk statement (what breaks first if throughput drops)
• Decision and action (accept, remediate, monitor)

Where bandwidth is insufficient, open remediation work with owners and due dates through your normal ticketing system.

Step 6: Operationalize as recurring control operation

Define ongoing triggers. Examples that work well in practice:

• Network architecture changes (new firewall, new tunnel, new routing policy)
• Major application releases that increase payload size or call volume
• Site moves, carrier changes, or cloud region changes
• Incident postmortems where latency/throughput contributed

Schedule recurring checks aligned to your change and incident rhythms rather than calendar-only compliance.

Step 7: Make it assessment-ready (SSP + evidence trail)

Ensure your System Security Plan (SSP) or control narrative states:

• What you measure (ODP paths)
• How you measure (methods/tools)
• Where evidence is stored
• How often it is performed and what triggers it

If you use Daydream to manage control ownership, procedures, and recurring evidence requests, set SC-31(3) up as a control with a standardized evidence checklist and automated reminders so measurements do not depend on individual memory. (NIST SP 800-53 Rev. 5 OSCAL JSON)

Required evidence and artifacts to retain

Retain evidence that proves both performance measurement and control operation:

1. ODP definition document for SC-31(3): scoped paths + methods + cadence/triggers. (NIST SP 800-53 Rev. 5 OSCAL JSON)
2. Network/path inventory tied to the system boundary.
3. Test plans / runbooks (how tests are executed safely).
4. Raw outputs (tool output files, screenshots, telemetry exports) with timestamps and endpoints.
5. Analysis summary mapping results to system needs and risk acceptance/remediation.
6. Tickets/changes showing remediation actions or documented risk acceptance.
7. Change records showing re-tests after material network/security changes.

Common exam/audit questions and hangups

Assessors tend to probe these points:

• “What does your organization-defined parameter include, and why?” (NIST SP 800-53 Rev. 5 OSCAL JSON)
• “Show me measurements from the operational environment, not staging.” (NIST SP 800-53 Rev. 5 OSCAL JSON)
• “How do you know the measurement traffic followed the intended path?”
• “What changed since the last measurement, and did you re-measure?”
• “What did you do when results were below expectations?”

Hangup: teams present ISP contracted bandwidth. That is not a measurement. You need measured throughput evidence.

Frequent implementation mistakes and how to avoid them

1. Testing in a lab and calling it ‘operational.’
   Fix: run tests on production routing/security paths, or document a defensible constraint and add passive telemetry plus limited-scope active tests.

2. Measuring interface speed instead of throughput.
   Fix: capture throughput under load (active) and corroborate with passive counters during peak.

3. No ODP definition (scope creep and assessor disputes).
   Fix: publish the in-scope path list with owners and rationale. (NIST SP 800-53 Rev. 5 OSCAL JSON)

4. No linkage to action.
   Fix: require a ticket or risk acceptance record for out-of-family results.

5. One-time measurement with no triggers.
   Fix: bind re-measurement to change management categories that affect paths (firewalls, tunnels, carriers, cloud networking).

Enforcement context and risk implications

No public enforcement cases were provided in the source data for SC-31(3). Practically, failure here increases operational risk: bandwidth shortfalls can break authentication flows, degrade monitoring/telemetry, slow replication/backups, and turn routine failovers into outages. Treat SC-31(3) as a preventative control that reduces the chance that a network change becomes a reportable availability incident.

Practical execution plan (30/60/90)

Use this as an execution cadence for your program; adjust to your system’s change rate and assessor expectations.

First 30 days (establish scope + first measurement)

• Assign control owner (Network/SRE) and compliance owner (GRC).
• Publish SC-31(3) ODP definition: in-scope paths, methods, triggers, evidence repository. (NIST SP 800-53 Rev. 5 OSCAL JSON)
• Build the path inventory and align it to the system boundary.
• Run initial measurements on the highest-criticality paths; capture raw outputs and summaries.

Days 31–60 (close gaps + integrate with operations)

• Identify bottlenecks and open remediation tickets.
• Add measurement steps to change management checklists for network/security changes.
• Implement passive telemetry dashboards or exports that support ongoing verification.
• Update SSP/control narrative and create an assessor-ready evidence packet.

Days 61–90 (stabilize + make it repeatable)

• Re-measure after remediations and major changes; retain before/after proof.
• Expand coverage to remaining in-scope paths, including third-party dependency routes where feasible.
• Run a tabletop “audit walk-through”: have the control owner demonstrate how they would reproduce a measurement and locate evidence in under an hour.
• If you use Daydream, automate recurring evidence tasks and map them to the control so collection is consistent across quarters. (NIST SP 800-53 Rev. 5 OSCAL JSON)

Frequently Asked Questions

What counts as the “operational environment” for SC-31(3)?

The environment where the system actually runs and users or workloads consume the service, including real routing and security controls. The control text explicitly calls for measurement in the operational environment. (NIST SP 800-53 Rev. 5 OSCAL JSON)

Do we need to measure every network link?

Measure the organization-defined set of communication paths you specify in your ODP definition. Scope it to paths that support system functions, resilience, and critical dependencies, then document the rationale. (NIST SP 800-53 Rev. 5 OSCAL JSON)

Is contracted ISP bandwidth acceptable evidence?

No. Contract terms describe theoretical capacity; SC-31(3) requires measured bandwidth in the operational environment. Keep actual measurement outputs and analysis. (NIST SP 800-53 Rev. 5 OSCAL JSON)

We can’t run aggressive throughput tests in production. What do we do?

Use passive telemetry (interface counters/flow logs) plus controlled, rate-limited active tests during maintenance windows. Document the constraint and your compensating approach in the procedure.

How do we handle bandwidth measurement for third-party connections?

Treat the path to the third party as in-scope if it is a dependency for your system. Measure from your environment up to your egress and, where possible, to an endpoint you control, and retain evidence that shows the end-to-end path characteristics you can verify.

What’s the minimum evidence set an auditor will expect?

A defined scope (ODP), a repeatable procedure, measurement results from the operational environment, and proof you reviewed outcomes and acted on deficiencies through tickets or risk acceptance. (NIST SP 800-53 Rev. 5 OSCAL JSON)