SC-5 Denial-of-service protection: what assessors expect

What SC-5 denial-of-service protection requires and why audits stall on it

SC-5 asks the organization to protect against, or limit the effects of, denial-of-service events of types it has defined, and to use defined controls for each type. In practice, you must first decide which denial-of-service event types matter for your system, then choose and document a protection for each one. Assessors under NIST SP 800-53 Rev. 5 test both halves of that statement, so an undefined event list or an unnamed safeguard is a finding even when the infrastructure is well protected. SP 800-53B assigns SC-5 to the low, moderate and high baselines, so every federal system at those impact levels carries it. FedRAMP's Rev5 baselines require SC-5 at Classes B, C and D. The control has three organization-defined parameters and three enhancements, but none of those enhancements is assigned to an SP 800-53B baseline, so the base requirement is what most assessments examine. Confirm the class and baseline for your system against the current FedRAMP and SP 800-53B documents before you scope the work, because the evidence you need follows from those selections.

Audits stall on SC-5 for a predictable reason: the event list and the chosen safeguards usually live in people's heads or in a firewall console, not in a document an assessor can read. The SP 800-53A procedure asks the assessor to examine a list of the safeguards that protect against or limit denial-of-service effects, the system design documentation, the configuration settings and their documentation, and the audit records. If any of those four sources disagrees with the others, the assessor cannot conclude the control is implemented. Start with a short, versioned register that names each denial-of-service event type in scope, the protection assigned to it (capacity, filtering, rate limiting or an upstream service), the configuration that enforces it and the owner who reviews it. Then confirm that the audit records show those protections acting. Ask your team to identify, in writing, which events are out of scope and why, because an assessor will ask.

Which systems, traffic paths and third parties SC-5 covers

SC-5 is only as strong as the scope behind it. The decisions below set which services, dependencies and providers an assessor expects to see covered, and each one changes how much work the team takes on and who owns it. The -1 policy and the related controls CP-2, IR-4, SC-6, SC-7 and SC-40 shape these boundaries as well.

Internet-facing services

Start with every service a client, partner or anonymous source can reach over the internet, including public APIs, login pages, portals and DNS endpoints. Each one needs a named denial-of-service event type and a protection that matches it. Application teams usually own the endpoints, while the platform team owns the edge components that handle traffic first, such as the reverse proxy and packet filter. Confirm the inventory against DNS records and load balancer configuration, since shadow endpoints are a common gap.

Internal services other systems depend on

Internal authentication, database, message queue and DNS services can fail under flood or exhaustion just as public ones can, and a single shared dependency can take several business systems down with it. Scope these by dependency map, not by network zone. Platform engineering typically owns capacity and rate limits for shared services, and each consuming team owns its own retry and timeout behavior. Ask whether the assessor will treat an internal outage triggered by one client as in scope for SC-5.

Upstream and cloud providers absorbing traffic

When a cloud provider, CDN or upstream carrier absorbs volumetric attacks, part of the protection lives outside the system boundary. Document which denial-of-service events the provider handles, what it does not handle, and which contract or service terms describe those limits. The organization still owns the evidence that the arrangement works, so ask providers for their mitigation descriptions and incident reports in writing before relying on them in the system security plan.

Defined denial-of-service event types

SC-5 requires the organization to define the types of denial-of-service events it protects against and the controls used for each type. Scope grows with every type added, so the list should name concrete events such as volumetric floods, application-layer request floods and resource exhaustion from a single client. Security engineering usually drafts this list, and the risk owner signs off. Make sure the chosen types match the organization's risk assessment, because an assessor will compare the two.

Related controls that shape the boundary

The -1 policy sets the owners, review cycle and scope rules for SC-5 itself. The Release 5.2.0 catalog also links SC-5 to CP-2 (contingency planning), IR-4 (incident handling), SC-6 (resource availability), SC-7 (boundary protection) and SC-40 (wireless link protection). Map each related control to the same services in scope, so the denial-of-service boundary matches the boundary protection and incident procedures. Governance and compliance leads typically own the mapping, and engineers confirm that the controls cover the same paths.

Shared responsibility for each boundary

Every scoping decision should name who answers for each protection, the organization, a hosting provider, or an implementation partner. Write the split into the system security plan so an assessor can trace each protection to an owner and to evidence. Gaps usually appear where two teams each assume the other handles rate limiting or traffic filtering. Confirm ownership in writing before the assessment starts, and treat unowned paths as in scope until someone accepts them.

How an assessor tests SC-5 and what they ask for

This table compares the three SP 800-53A assessment methods against what an assessor asks for on SC-5, the evidence that answers each request and the findings that appear most often. Read it as a checklist: each row is a question the assessor will put to your team, and the evidence column shows what to have ready before the assessment starts.

Test method	What the assessor asks for	Evidence that answers it	Common findings
Examine: safeguard list	A list of the safeguards that protect against or limit denial-of-service effects, mapped to the defined event types	Current DoS protection register naming each safeguard (capacity, filtering, rate limiting, upstream service) and the event type it addresses	Safeguard list is generic or out of date, and does not name the event types the organization defined
Examine: system design documentation	Where DoS protections sit in the architecture and which traffic paths they cover	Architecture diagrams showing edge, load balancer, firewall, WAF and upstream provider placement, with data flow notes	Design documents omit internal services or APIs that are reachable without the protections
Examine: configuration settings	Settings that enforce each safeguard and the documentation that explains their values	Exported firewall rules, WAF rule sets, rate limit configuration and Prometheus or Grafana alert thresholds, with change history	Settings exist but no documented rationale for thresholds, or settings differ from what the design says
Examine: audit records	Records showing DoS events were detected, handled and reviewed	Firewall and WAF logs, alert history and tickets showing triage and response to attack-like traffic	No records of attacks or tests, so the assessor cannot confirm the safeguards operate
Interview: system owners and operators	Who selects the event types, who tunes thresholds and who acts on alerts	Named roles in the procedure, on-call rota and a record of recent threshold reviews	Staff describe protections differently from the documentation, or cannot name the owner
Test: event types against actual exposure	That the event types the organization defined match the traffic and services it really protects	Test results or controlled load exercises for each defined event type, with pass or fail outcomes and follow-up actions	Defined event types cover only volumetric attacks, leaving application-layer or DNS-based events untested

Which denial-of-service events matter for your system

SC-5 asks you to name the types of denial-of-service events you protect against, then to choose a control for each type. Its parameters are the place where that choice becomes visible to an assessor, so the first job is to fill them with a list you can defend. Start with the event families that actually reach your system: volumetric floods that saturate bandwidth at the edge, application-layer request floods that exhaust backend capacity with requests that look legitimate, resource exhaustion such as connection pools, memory, file handles or database locks being consumed faster than they are released, and connection-state attacks that hold half-open or idle sessions open until new clients cannot connect. Each family maps to a different protection: capacity and upstream services for floods, rate limiting and web application filtering for request floods, quotas and timeouts for resource exhaustion, and stateful packet filtering with connection limits for connection-state attacks.

The list needs evidence behind it. A documented threat analysis should name the event types, the assets each one would disrupt, the likelihood your environment faces, and the impact on the services in scope. Past incident records, availability monitoring data and capacity reports are the strongest inputs, because they show which events have already occurred and what their effect was. If your organization has no incident history for this area, say so in the analysis and base the list on the threat model and on the traffic patterns your metrics show. An assessor testing the determination statements will compare the defined event types with the analysis, so each protection should trace back to a named risk rather than to a general wish for resilience. Confirm the parameter values with your system owner and record the reasoning in the system security plan.

Once the list is fixed, keep it current. Review it when services change, when a new internet-facing interface appears, or when an incident shows an event type you had not considered. Tools such as the OPNsense rule log, Grafana alert rules and Prometheus metrics can show whether each protection is firing on the event types you listed, which is the kind of operational record an assessor may ask to see. Confirm with your own engineers which metrics and thresholds you can produce before you commit to them in the plan.

How to implement SC-5 in sequence

This sequence turns SC-5 from a policy statement into a documented set of denial-of-service events, matched protections, tested configurations and a review cycle that an assessor can trace from requirement to evidence. Each step names the record it produces so the work can be checked at every stage.

Define the denial-of-service events that matter
Start by listing the denial-of-service event types the system must withstand, such as volumetric floods against public endpoints, application-layer request floods against login and API paths, resource exhaustion from a single client, and loss of a dependent upstream service. SC-5 requires the organization to define these types, so the list is an organizational decision, usually led by the system owner with security and platform engineering input. Record each event with the system component it affects and the business function it would interrupt. The step is complete when the signed event list exists and each event has an owner. Ask your auditor which level of detail they expect for the defined types before you finalize the list.
Assign one protection to each event
For every event on the list, choose the protection that addresses it: capacity (enough headroom and scaling to absorb load), filtering (blocking traffic by source, destination, port or protocol at a boundary), rate limiting (capping requests per client or path at the application layer), or an upstream service (a provider that absorbs or scrubs traffic before it reaches your network). Some events need more than one protection. Write the decision and its reason in a protection matrix that maps event to control to component. The output is an approved protection matrix, reviewed by the people who run the affected systems, and it becomes the design record that assessors read first.
Configure each safeguard to the design
Apply each chosen protection in the environment you control. Packet filtering rules can be built in a stateful firewall such as OPNsense, which passes, blocks or rejects traffic by source, destination, port and protocol and can log each rule match. Application-layer filtering and request inspection can be handled by a web application firewall such as Coraza, which is compatible with ModSecurity SecLang rulesets and the OWASP Core Rule Set and has integrations for Caddy, HAProxy, Traefik and Nginx. Rate limits and capacity settings are configured in the load balancer, reverse proxy or platform layer. Export each configuration and keep it under version control. The output is a configuration baseline that matches the protection matrix, with any deviation documented.
Set monitoring and alerting thresholds
Protections that nobody watches do not show that SC-5 is operating. Collect the metrics that reveal each event type, such as request rates, connection counts, dropped packets and upstream error rates, using a pull-based collector like Prometheus, which stores time series and queries them with PromQL. Then define alert thresholds in a tool like Grafana Alerting, which builds rules from queries across data sources and can combine metrics and logs. Set each threshold against the normal baseline observed for that system, and route alerts to a named responder. The output is a threshold register listing each metric, its threshold, its owner and the alert destination.
Test the protections under load
Run controlled tests that simulate each defined event type against a non-production copy of the environment, or against production only under an approved change window and with agreed limits. Confirm that filters block the traffic they should, that rate limits engage at the defined thresholds, that capacity holds, and that alerts fire and reach the responder. Record the test scenario, the expected result, the observed result and any gap. Testing may be performed by your own staff or by an external tester under a written scope. The output is a dated test record for each event type, and failed tests generate entries in the plan of action and milestones.
Document the design and settings
Assemble the evidence an assessor will examine. SC-5 assessment procedures look at the list of safeguards that protect against or limit denial-of-service effects, the system design documentation, the system configuration settings with their supporting documentation, and the system audit records. Put the event list, protection matrix, configuration baseline, threshold register and test records into the system security and privacy plan or its linked artifacts, and confirm that each document names its owner and version. The output is a cross-referenced evidence set in which every protection can be traced from requirement to design, configuration, monitoring and test result.
Set a recurring review cycle
Threats, traffic patterns and system architecture change, so the SC-5 design needs a scheduled review and a trigger for unscheduled review. Set the review frequency in the policy and procedures that govern the SC family, and add triggers such as a significant architecture change, a new public endpoint, a major traffic increase or a denial-of-service incident. At each review, check the event list against current threats, retest changed protections, and update thresholds that no longer match normal traffic. Your organization sets the review interval; confirm with your assessor or authorizing official what they expect. The output is a review record with decisions and any changes to the event list, protection matrix or configuration baseline.

Which evidence satisfies SC-5 and how to keep it current

An assessor testing SC-5 looks for a defined set of denial-of-service events, a documented protection for each one, and records showing those protections exist and work. The cards below cover the artifacts that carry that proof, how often each should be refreshed between audits, and what the assessor will sample. The organization owns these records; DeployOpen can prepare them, but only an independent assessor draws conclusions about them.

Documented DoS event list

This is the list of denial-of-service event types the organization has chosen to protect against, with a short rationale for each. SC-5 requires defined event types, so the list is the anchor for every other artifact. Each entry should name the affected service, the likely source (volumetric flood, application-layer request flood, resource exhaustion), and why it was included or excluded. Review it after architecture changes and after significant incidents. An assessor will typically ask who approved the list and when it last changed.

Design document mapping protections

The system design document should show which protection covers which event on the list. A single table tying each event to a capacity measure, filtering rule, rate limit or upstream service is the clearest form. Note where a protection depends on a provider outside the system boundary, since the assessor will ask how that dependency is evidenced. Refresh the mapping whenever a network path, load balancer or public endpoint changes. Assessors commonly sample two or three events and trace each to its protection in the design.

Configuration exports and change history

Exports of firewall rules, web application firewall settings, rate limit thresholds and load balancer connection limits show the protections as they run. Keep the exports under version control so each change has an author, a date and a reason. Compare exports against the design document at each review, since drift between the two is a frequent finding. An assessor will usually pick one rate limit or filter rule and ask for its change record and approval.

Safeguard inventory with owners

A list of each denial-of-service safeguard, the component that provides it, and the named person responsible for its operation is what makes the control accountable. Include upstream services such as a content delivery network or scrubbing provider, with the contract or service reference that governs them. Confirm owners quarterly, and update the list when staff change. Assessors often ask who can change each safeguard and whether that person knows what it protects.

Monitoring dashboards and alert rules

Dashboards and alert rules show whether the organization can see an attack in progress and whether it responds. Metrics such as request rates, connection counts, error rates and resource saturation should feed alerts with thresholds tied to the protections on the event list. Export alert rule definitions and keep a record of the test firing of each rule. Review thresholds after traffic patterns change, because a threshold set for last year's load may hide a current attack.

Audit records of triggered protections

Logs showing that filters, rate limits or upstream mitigations fired during real events or scheduled tests give the strongest evidence that SC-5 operates in practice. Retain the log entries, the alert that raised them and the response record. Sample a set of tests at each review, and record the results even when a protection did not trigger. Assessors commonly ask for an example from the audit trail and then check that the logged event matches the event list.

What meeting SC-5 costs in money and effort

This table compares the cost components of meeting SC-5 by who is paid, whether the cost is one-time or recurring, and what drives it up. Read it to see where open-source tooling removes license spend and where the cost shifts to engineering time and evidence upkeep. No prices are stated, so ask for each line in a written scope before comparing quotes.

Cost component	One-time or recurring	What drives it	How to reduce it
Upstream or cloud DoS service subscriptions	Recurring	Traffic volume that must be absorbed, number of protected endpoints, and whether protection is contracted per service or per account	Confirm which DoS layers your provider already includes, and size subscriptions from measured peak traffic rather than assumed peaks
Filtering and firewall licenses	Recurring for commercial products, none for BSD-licensed options such as OPNsense	Number of rule sets, high availability pairs, and vendor support tiers if you buy them	Self-hosted open-source packet filtering removes license spend, so the remaining cost is hardware and the support contract you choose
Engineering time to design and configure protections	One-time, with later changes	Number of exposed services, complexity of rate limits and filtering rules, and how many environments must match	Document a single protection baseline and reuse it across environments, and keep rule changes under change control
Load testing	Recurring at each significant change or review	Size of the test environment, the traffic profiles tested, and whether tests run against production-like capacity	Scope tests to the defined denial-of-service event types and reuse scripts across cycles
Evidence upkeep	Recurring	Log retention settings, dashboards, alert rules and the number of configuration changes to record	Export alert rules and configuration as versioned files, and automate evidence collection where your tools allow it
External testing or review	Recurring or per engagement	Scope of the systems tested, whether denial-of-service testing is included, and rules of engagement agreed in advance	Agree the test scope and safe testing limits in writing before work starts, and ask whether testing is part of the fixed scope
Auditor sampling effort	Recurring at each assessment	How many protections and events the auditor samples, and whether evidence is organized by event type	Keep one evidence index that maps each defined event type to its protection, configuration and logs
Staff time for monitoring and response	Recurring	Alert volume, on-call coverage, and how much tuning false positives requires	Tune alert thresholds during the design phase and document the escalation path to upstream providers

Which open-source tools produce SC-5 evidence

SC-5 evidence comes from the layers that see denial-of-service traffic: the packet filter, the web application firewall, the metrics that show saturation, and the alerts that tell someone when thresholds are crossed. The four tools below each produce one part of that record, and none of them proves on its own that the organization is protected.

OPNsense packet filter rules

OPNsense is a stateful packet filter whose rules pass, block or reject traffic by source, destination, port and protocol. For SC-5, the rule set and its aliases show which traffic is dropped or limited at the boundary, and the option to log each rule match gives an assessor a record of those actions. Check that the rules you export match the configuration in production and that the logged matches are retained long enough to cover a review period.

Coraza web application firewall

Coraza is a web application firewall compatible with ModSecurity SecLang rulesets and the OWASP Core Rule Set, with integrations for Caddy, HAProxy, Traefik and Nginx. Its rule configuration and blocked-request records can show which request patterns are refused before they reach the application. Coraza is an application-layer control, so it does not replace volumetric protection, and you should confirm which request floods it can absorb in your deployment.

Prometheus traffic and saturation metrics

Prometheus collects metrics from instrumented jobs over HTTP and stores them as time series that PromQL can query. Series for request rates, connection counts, CPU, memory and queue depth provide the record of saturation that an assessor can compare against the thresholds your SC-5 design defines. Confirm that the exporters you run cover the boundary devices and services in scope, because metrics for a host that is not scraped are absent from the evidence.

Grafana Alerting history

Grafana Alerting builds alert rules from queries and expressions across multiple data sources, and it can alert on metrics and logs together. Saved alert rules show the thresholds the organization chose for denial-of-service conditions, and the alert history shows when those thresholds were crossed and who responded. Because Grafana is licensed under AGPL-3.0-only, confirm with counsel that your intended use and any modifications meet its terms before you build the evidence pipeline on it.

Who owns SC-5 work, what partners take on and where the auditor stops

SC-5 asks the organization to protect against, or limit the effects of, the denial-of-service event types it has defined, using the controls it has defined for each type. Those definitions are yours. Your security and operations leaders decide which events matter for the system, which protections answer each one, and how much residual disruption leadership is willing to accept. Those decisions are what an assessor reads first, so they must be written down and approved by someone with authority over the system.

Event list: Maintain the list of denial-of-service event types for the system, such as volumetric floods, application-layer request floods and resource exhaustion from a single client, with the scenarios that matter most to your business.
Risk acceptance: Record which residual risks are accepted, by whom, and under what conditions, and review them when traffic patterns or architecture change.
Operational response: Staff the alerting, triage and escalation path so that an attack is noticed and handled by people who know the protections in place.
Ownership of parameters: Set and approve the organization-defined values in SC-5, and keep them consistent with system design documentation.

Confirm with your assessor which parameter values and event types they expect to see documented before you finalize them.

Common questions about SC-5 cost, effort and audit readiness

How long does it take to get SC-5 denial-of-service protection in place?

Duration depends on how many denial-of-service events the organization has defined, how much of the protection already exists, and whether the internet-facing services run on infrastructure that can be changed. No duration figure is supplied for this control, so treat any number a vendor gives as an estimate to test against your own environment. The work usually moves in three stages: defining the event types and the protection for each, implementing and tuning the controls, and then producing the evidence an assessor will examine. Ask for a written scope with stage dates before work starts, and confirm which systems fall inside the boundary.

What does meeting SC-5 cost, and what drives the price up or down?

No cost figure is supplied for SC-5, and DeployOpen does not publish prices. The cost has several parts: internal staff time to define events and own the controls, licensing or hosting for any filtering or monitoring tools, cloud or upstream DoS service fees if you use them, and the fees of an implementation partner or assessor if you hire one. Costs rise with the number of internet-facing services, the number of defined event types, the amount of traffic handled, and how much custom rule tuning is needed. Most of the cost is one-time build work, while capacity, licensing and monitoring recur. Ask any partner for a quote that separates one-time and recurring items and names who is paid for each.

Can our own team implement SC-5 without outside help?

Yes, many teams with network and platform engineering skills can implement SC-5 in-house, provided they have time and clear ownership. The harder parts are usually defining the denial-of-service events that matter for your services, tuning rate limits so legitimate traffic is not blocked, and writing evidence that ties each protection to a defined event type. Outside help is most useful for a fixed-scope build of the open-source components, a review of the configuration against the assessment procedure, or a test of the protections. DeployOpen prepares systems and evidence under a written scope, but an independent assessor is still needed to issue any report.

What does SC-5 require from engineering and operations teams?

Engineering teams must document the protections for each defined denial-of-service event type, including capacity planning, filtering, rate limits and upstream services. Operations teams must keep those settings in configuration management, monitor traffic and alerts, and respond when thresholds are crossed. In practice this means keeping rule sets under version control, retaining logs of rule matches, and testing that alerts reach an owner. Expect recurring work for tuning, reviewing alert noise and updating protections when services change. Confirm early who approves threshold changes, since an unreviewed change can either block customers or leave a gap.

Does a cloud provider's DoS protection service satisfy SC-5 on its own?

Usually not on its own. A provider's DoS service can cover part of the protection, but SC-5 asks the organization to define the event types it is protecting against and to show how each is handled, which the provider cannot do for you. Read the provider's shared responsibility documentation to see what it covers, then document the remaining protections such as application rate limits, capacity and the upstream services you rely on. Assessors will look at system design documentation and configuration settings, so the provider's settings need to be captured and tied to your defined events.

How often must SC-5 evidence be refreshed?

No refresh interval is fixed in the supplied material for SC-5, so the answer depends on your assessment program, your authorization terms and any framework that requires it. Evidence should be refreshed whenever a protection changes, a new internet-facing service is added, or a threshold is tuned. Many organizations also review the configuration and alert records on a regular schedule. Confirm the required cadence with your assessor or contracting authority, and ask how changes to rule sets will be recorded so that the current evidence always matches the running configuration.

What should we confirm before an SC-5 assessment?

Confirm that the defined denial-of-service event types match the services in scope, that each event has a named protection and owner, and that configuration settings and audit records exist for every protection. Check that rate limits and filters have been tested with realistic load, that alerts reach a responder, and that the system design documentation explains how the protections fit the architecture. Also confirm with your assessor which examine, interview and test methods they will use, and whether they expect a test of the protections. Ask for the assessor's own requirements in writing, since assessment scope is set by them and by the authorizing body.

How DeployOpen scopes, implements and prepares SC-5 evidence

DeployOpen starts from the denial-of-service events your organization has defined for its system, then plans, builds and documents the protections that address them inside your own infrastructure. We prepare the configurations, monitoring and records an assessor will examine, while your organization keeps ownership of the control and an independent assessor reaches the conclusion.

How we scope

Confirm with your team which denial-of-service event types the organization has defined for SC-5 and its parameters.
Map each event type to the protection chosen, such as capacity, filtering, rate limiting or upstream services.
Record the written scope, deliverables and timeline before any work starts, since engagements are fixed-scope.

How we build

Deploy self-hosted filtering and rate-limiting components, such as Coraza with OWASP Core Rule Set rulesets, in your environment.
Configure stateful packet filter rules in OPNsense with aliases and per-rule logging enabled for review.
Build Grafana Alerting rules and Prometheus metrics that show traffic anomalies tied to each defined event type.

How we hand over

Deliver the configuration files, rule sets and alert definitions with documentation linking each to its SC-5 event type.
Provide sample audit records and log exports that show protections operating, ready for an assessor's examine method.
Document the upstream service and capacity arrangements your organization owns, so ownership of the control stays clear.

How we support

Review protection settings after significant changes to the system architecture or to the defined SC-5 parameters.
Keep rule sets and monitoring current through upgrades, offered as an ongoing retainer on written terms.
Run continuous security testing against the denial-of-service protections, scoped in writing and reported back to your team.