SC-6 Resource availability: requirements and evidence

What SC-6 resource availability asks for when no baseline requires it

SC-6 requires the organization to protect the availability of resources by allocating defined resources by priority, quota or other defined safeguards. No SP 800-53B baseline selects it, so it reaches a system only when the organization tailors it in or an overlay brings it in. If you have been handed SC-6 without context, start by asking who selected it and why, because the answer tells you what the assessor will expect to see. The underlying risk is simple to describe: a noisy or runaway process consumes processor time, memory, network bandwidth or storage until critical processes, such as authentication, logging or the transaction path, cannot get what they need. The control addresses that starvation before it becomes an outage.

The control is short, but it has three organization-defined parameters that you must fill in before anyone can test it. In Release 5.2.0 the parameters are the resources to be protected, the allocation approach and the safeguards applied, and each one forces a decision. Which resources are critical enough to protect? Which processes count as high priority? Which quotas apply to tenants, service accounts or batch jobs? Many teams have never written these answers down. Platform owners often know the defaults in their container scheduler or hypervisor, but they have not agreed what the priority tiers mean for the business. Confirm the exact parameter wording against the current catalog in the OSCAL content before you draft values, and record each decision with an owner and a review date.

Expect the assessor to test whether the chosen allocation is real and not just described. Under SP 800-53A the examine methods for SC-6 point to system design documentation, configuration settings with their documentation, and audit records, so the documented tiers and quotas must match what the platform enforces. Ask your platform team to show current settings for resource requests, limits, priority classes or cgroup controls on the systems in scope, and to show records of a quota or priority decision being applied. Where the parameters conflict with the actual configuration, close the gap in the design before the assessment starts.

Which systems and teams SC-6 reaches once you select it

SC-6 only creates work once your organization selects it, so the first decision is whether it applies to your system at all and at which impact level. After that, the scope follows the places where compute, memory, bandwidth and storage are shared, the workloads that must win contention, the teams that set quotas, and the outside services whose limits you inherit.

Whether SC-6 is selected at all

SP 800-53B does not assign SC-6 to the low, moderate or high baseline, so it reaches your system only through your own tailoring or an overlay, or through a contract that names it. FedRAMP's Rev5 baselines do not require SC-6 at Classes B, C or D either. Record the selection and its rationale in your system security plan, and confirm with the contracting authority whether the requirement is theirs to impose. This decision changes the work more than any other.

Shared hypervisors and clusters

Hypervisor hosts and Kubernetes clusters are where tenants and workloads compete for processor, memory and storage I/O. Inventory every host pool and cluster that carries in-scope workloads, and note which ones run mixed priorities on the same nodes. Ask whether CPU and memory requests and limits, or hypervisor reservations, are defined for each workload class. An assessor will expect those settings to appear in configuration records.

Shared database and storage hosts

A single database host or storage array serving several applications can let a batch job or reporting query exhaust connections, IOPS or disk space needed by a payment or identity service. Map which applications share each host and which ones must keep their capacity under load. Confirm how connection pools, query time limits and storage quotas are set, and who can change them.

Priority workloads that must win contention

Payment processing, identity services, security logging and control functions usually need protected capacity so lower-priority jobs cannot starve them. List these workloads by name, then state the priority or reservation each one holds. Logging deserves particular attention, because an overloaded host that drops audit records undermines other controls. Verify the priority settings in the platform configuration rather than relying on a diagram.

Teams that own quotas

Quotas and priority classes are only as good as the people who approve changes to them. Identify the team that sets each limit, the team that requests exceptions, and the approver for any increase that would reduce protected capacity. Document these owners in the configuration management records so an assessor can trace a quota change to an authorized decision. Without named owners, quotas drift as workloads are added.

Managed services with inherited limits

Managed databases, queues, container platforms and SaaS components enforce their own resource limits, and you inherit those limits whether or not you wrote them. Obtain the provider's documented quotas, throttling behavior and service commitments for each in-scope service, and note which ones your organization can configure. Where a provider's shared capacity affects your protected workloads, record that dependency and the evidence you collect for it.

How SC-6 differs from SC-5 denial-of-service protection

SC-6 governs how a system divides its own resources among its own processes and users, while SC-5 governs how it defends against denial-of-service events that come from outside or from abusive load. SC-6, Resource Availability, asks the organization to allocate defined resources such as processor, memory, bandwidth and storage by priority, quota or another defined safeguard so that no lower-priority workload can starve a critical one. SC-5, Denial-of-service protection, starts from the attack or overload side: which denial-of-service events matter, and which protections (capacity, filtering, rate limiting, upstream services) address them. The Release 5.2.0 catalog lists SC-5 as the only related control for SC-6, which reflects the overlap, but the two controls are tested with different questions.

Consider an illustrative case. A nightly batch job on a host that also runs an authentication service consumes nearly all available memory, and the authentication service begins failing logins. Rate limiting at the network edge does not help here, because the requests reaching the authentication service are legitimate and the pressure comes from a process inside the host. A memory quota or cgroup limit on the batch job, or a higher scheduling priority for the authentication service, addresses the problem directly. The reader should confirm how their own hosts enforce such limits, for example through operating system resource controls or orchestrator resource requests and limits, and whether those settings are defined and documented as the organization's chosen safeguard.

To tell the two apart, an assessor will ask for the defined resource allocation decisions that SC-6 requires: the resources covered, the priority or quota values, and the systems where they are set. Expect requests for system design documentation describing resource sharing, system configuration settings that enforce quotas or priorities, and audit records or monitoring data showing limits being applied or breached. For SC-5, the assessor will instead ask which denial-of-service events were identified, which protections were chosen for each, and how they were tested. Keeping these two evidence sets separate in the system security plan makes the difference clear to both the assessor and the operations team.

How an assessor tests SC-6 and what they ask to see

This table maps each part of the SP 800-53A procedure for SC-6 to what the assessor examines, the evidence to prepare and the findings that appear most often. Read it as a checklist: the assessor relies on documents and configuration, so each row needs a written, specific record that matches what the system actually does.

Test element	What the assessor examines	Evidence requested	Common findings
Determination statement (single)	Whether the organization has defined resources to allocate by priority, quota or other defined safeguards, and whether that allocation protects availability	A written statement mapping SC-6 to the system, the resources in scope and the safeguard chosen for each	Control narrative describes intent only, with no named resources or mechanisms
System design documentation	Architecture and design records showing which resources are managed (processor, memory, bandwidth, storage) and where priority or quota decisions are made	Current architecture diagrams, resource management design notes and a list of critical processes that must not be starved	Design predates the current system, or critical processes are missing from the list
System configuration settings	Live or exported settings that enforce allocation, such as scheduler priorities, resource limits, cgroup or container quotas, and storage or bandwidth caps	Configuration exports or screenshots with timestamps, plus the change history for those settings	Limits are set in one environment only, or settings drift from the documented values
Configuration settings documentation	Whether the documentation explains each setting, its owner and the reason for its value	Configuration standard or runbook entries tied to each setting, with a named owner	Settings exist but no document explains their purpose or who maintains them
System audit records	Logs or alerts showing that allocation rules operated, including limit hits, throttling events and preemption	Sample records showing enforcement over a defined period, and records of any limit breaches and their follow-up	No audit records exist for resource limits, so the assessor cannot confirm enforcement
Organization-defined parameter 1 (resources and allocation basis)	Whether the resource types and allocation basis are filled in with specific values rather than left as template text	Parameter table naming each resource type and the chosen priority or quota method	Parameter left as a placeholder or described only as "as needed"
Organization-defined parameter 2 (priority tiers or quota values)	Whether specific tiers or numeric quota values are stated and match the configuration	Tier definitions and quota values, cross-checked against the settings export	Quotas defined in the document but not enforced in the configuration
Organization-defined parameter 3 (approval of priority tiers)	Whether the people who approved the priority tiers and their basis are on record	Approval record naming the approver, date and the criteria used to assign each tier	No record of who approved priority tiers or when they were last reviewed

Implementing SC-6 step by step

This sequence turns the three organization-defined parameters of SC-6 into a documented, enforced and tested allocation of resources, so an assessor can see that a lower-priority workload cannot starve a critical one.

Set the three organization-defined parameters
The system owner and security lead define the priority classes, the quota values for each class and the resource types the control covers, such as processor, memory, bandwidth and storage. Record the result in a signed parameter table that names each class, its quota basis and the approver. The step is done when every parameter has a value, an owner and an approval date that an assessor can trace back to the system security plan.
Map each critical service to a priority class
Inventory the workloads on the system and assign each one to a class based on its mission or business impact, using the availability requirements already set in the contingency and impact analysis. Identify which services must never be starved, such as authentication, logging and the management plane. The output is a service-to-class mapping that the platform team and the security team both sign off on, so the allocation rules have a clear purpose.
Configure enforcement on each platform
Apply the parameters with the mechanisms each platform provides. On Linux hosts this usually means scheduler priorities and cgroup limits for processor and memory, traffic shaping for bandwidth and per-volume or per-user storage quotas. On virtualized platforms, use hypervisor reservations and shares for critical guests. Confirm the exact keys and tool options against your distribution and hypervisor documentation. The output is a configuration baseline stored in version control, with each setting traced to a class in the parameter table.
Validate with a starvation test
Run a controlled test in a non-production environment where a deliberately heavy lower-priority workload competes with a critical service for the same resources. Record whether the critical service keeps its defined allocation and response targets while the lower-priority workload is constrained. Repeat the test for each resource type covered by the parameters. The output is a dated test record with the configuration version, inputs, observed results and any failures, and failures go back into the configuration baseline.
Document the design and configuration
Update the system security plan, the architecture documentation and the configuration baseline so they describe the same allocation model. Include the parameter table, the service mapping, the enforcement settings and the test record. Assessors check the system design documentation and configuration settings against the control, so gaps between documents are a common finding. The step is complete when a reviewer can follow one critical service from its class to the setting that protects it and the test that proved it.
Monitor utilization and review periodically
Feed resource metrics and alerts into your monitoring stack so that sustained saturation of a shared resource, or a critical service approaching its allocation limit, is visible to operators. Open-source options such as Prometheus for metrics collection and Grafana Alerting for rules and notifications can provide this, though you should confirm the metrics available on your platform. Set a review schedule that your own policy defines, and re-run the starvation test after material changes. The output is alert history, review records and updated parameter approvals.

Evidence that passes an SC-6 examination

SC-6 is assessed mainly by examining documents, configuration and records, so the evidence has to show a defined allocation model, how the system enforces it, and proof that it works under load. The cards below map to the examine objects in the SP 800-53A procedure and describe how to keep each one current between assessments.

Signed parameter table

This is the document that sets the defined values for SC-6: which resources are allocated (processor, memory, bandwidth, storage), the priority classes, and the quota values for each class. Because SC-6 has three organization-defined parameters in Release 5.2.0, the table should show a value or rule for each one, with the owner and approval date. Keep it current by reviewing it on a fixed schedule and after any capacity change, and record each review with a sign-off. Assessors check that the table matches what the system actually enforces.

System design documentation

The design documentation explains the allocation model: how priority classes are assigned to workloads, where quotas are enforced (hypervisor, container runtime, operating system or network device), and what happens when a limit is reached. This maps to the examine object for system design documentation in the SP 800-53A procedure. Update it when the architecture changes, such as new clusters, tenants or shared services, and keep diagrams and text aligned with the signed parameter table.

Platform configuration exports

Configuration exports show the enforcement settings that the design describes, such as Kubernetes resource requests and limits, priority classes, cgroup or hypervisor reservations, and bandwidth shaping rules. Export them on a schedule, store them under version control, and diff each export against the last approved baseline. Each platform needs its own export, because the examine object covers system configuration settings and their associated documentation. Confirm the exact setting names with each vendor's documentation for your versions.

Starvation test record

This record demonstrates that a lower-priority load cannot starve a critical service. The test drives heavy background work alongside a critical workload, then records whether the critical service kept its allocated share of processor, memory, bandwidth and storage. Keep the test plan, load profile, pass criteria, results and the person who witnessed the run. Rerun the test after major platform upgrades or when parameters change, since SC-6 assessment depends on evidence that the control works, not only that it is configured.

Utilization and alert history

Monitoring data shows that allocations hold over time. Prometheus can store utilization metrics per workload and Grafana Alerting can fire when a critical service nears its limit or when a lower-priority workload consumes more than its quota. Export dashboards, alert rules and alert history at regular intervals, and retain them for the period your assessment requires. Check that the alerts reach a named responder, because an assessor will look for evidence of action after a threshold breach.

Parameter change records

Change records show who altered a resource priority, quota or allocation value, when, why and under which approval. Route every change to the parameter table through the same change control process used for system configuration, and link each change to the updated configuration export and test result where relevant. Missing or unapproved changes are a common reason an assessor cannot confirm that the documented values are still the enforced values, so review the change log against the configuration exports at each assessment.

What meeting SC-6 costs in money and effort

This table breaks down the cost components of meeting SC-6 Resource availability, who is paid for each, whether it is one-time or recurring, and what moves it up or down. NIST does not estimate compliance costs and no figures are supplied for SC-6, so the drivers matter more than any number; use the rows to build the scope you put in a quote request.

Cost component	One-time or recurring	What drives it up or down	How to keep it down
Design of priority classes and quotas	One-time, revisited at each significant change	Number of workload classes, number of platforms, and how many of the three defined parameters the organization must set and justify	Limit priority tiers to those that map to real business impact, and reuse one scheme across platforms
Engineering time for enforcement across platforms	One-time build, then recurring maintenance	Mix of hypervisors, container orchestrators, databases and network devices that must enforce quotas, plus any custom scheduling	Enforce through platform features already in use, and document one configuration pattern per platform type
Test effort to demonstrate starvation resistance	One-time for the initial test plan, recurring on each major change	Number of critical workloads that need load tests, and whether tests run under realistic peak conditions	Script repeatable load tests in version control and run them in a self-hosted test environment
Monitoring and alerting	Recurring	Number of metrics collected, retention period, and number of alert rules tied to quota breaches	Use self-hosted open-source collection and dashboards such as Prometheus and Grafana to avoid license spend; staff time to tune alerts remains
Evidence upkeep	Recurring	How often configurations change, how many systems produce quota and utilization records, and where records are stored	Export configurations and monitoring records on a schedule to a single evidence repository with dated retention
External review or testing	Recurring or per engagement	Scope of systems reviewed, depth of load or denial-of-service testing, and whether results must be independently reproduced	Agree the testing scope in writing before work starts and reuse prior results where configurations have not changed
Auditor sampling	Recurring at each assessment	Number of systems in the authorization boundary and number of quota configurations the assessor chooses to inspect	Keep one current, consistent evidence package so sampling does not trigger new collection work

Using Prometheus, Grafana and Falco to show SC-6 in operation

These tools show how SC-6 behaves in production and where it drifts from the allocation you defined. Prometheus records consumption, Grafana alerts when a lower-priority class encroaches on reserved capacity, and Falco flags processes that behave outside their expected profile. Each adds evidence, but none of them enforces the allocation, which has to come from your platform configuration.

Prometheus records utilization per workload

Prometheus (Apache-2.0) pulls metrics from instrumented jobs over HTTP and stores each series by metric name and labels on its local storage. You query it with PromQL, so you can compare each workload's CPU, memory and storage use against the allocation assigned to its priority class. Confirm that every workload in the critical and lower-priority classes is instrumented, that labels identify the class, and that retention covers the review period your assessor will sample. Prometheus shows consumption against allocation, while the allocation itself is set in your platform.

Grafana Alerting flags encroachment

Grafana Alerting (AGPL-3.0-only) builds alert rules from queries and expressions across multiple data sources. A single rule can compare consumption by a lower-priority class with the capacity reserved for a critical class and fire when the margin is breached. Alerts on metrics and logs are created, managed and acted on from one view, which gives a reviewer one place to see thresholds, firing history and responses. Confirm the thresholds match the allocation in your design document, and have counsel review AGPL-3.0-only obligations for any modified version you offer to users over a network.

Falco detects runaway processes

Falco (Apache-2.0) parses Linux syscalls at runtime, by default through an eBPF probe, and evaluates them against YAML rules. Rules for suspicious process execution and unexpected network connections can reveal a runaway process consuming resources outside its profile. Falco detects the behavior but does not enforce allocation, so it cannot cap CPU, memory or bandwidth. Confirm which rules you enable, route alerts to your monitoring or SIEM through an output such as syslog or HTTP, and test that a deliberate runaway process produces an event.

Linking tool output to assessment objects

SP 800-53A assesses SC-6 through one determination statement, examining system design documentation, system configuration settings and associated documentation, and system audit records. Prometheus configuration and dashboards, Grafana rule exports and Falco alert logs can each supply part of the audit record trail. SC-6 also has three organization-defined parameters, so the design document must state which resources are covered, which priority or quota applies, and which safeguard you chose. Ask your assessor which artifacts they will sample and over what period before you build the evidence set.

Who sets priorities, who builds the quotas and who the auditor is

Your organization owns SC-6. SP 800-53 leaves the key parameters to the organization, so the people who run the system must decide which resources need protection, which priority or quota model applies, and how much contention the system can tolerate before a critical process is affected. Those decisions are risk decisions, and they belong to the system owner and the authorizing official or equivalent accountable executive. SC-6 has three organization-defined parameters in Release 5.2.0, and each one needs a documented value.

Priority model: Define which processes are critical, which are lower priority and how the scheduler or orchestrator ranks them.
Parameter values: Record the resource types, quota or priority rules and any thresholds chosen for each organization-defined parameter.
Risk acceptance: Document residual risk for any workload that cannot be isolated by priority or quota and obtain formal acceptance.
Policy linkage: Connect the SC-6 decisions to the SC-1 policy and to the system security plan so the rationale is reviewable.
Ownership of change: Assign who approves changes to quotas and priorities when workloads grow.

What to check: confirm that a named owner signed the parameter values and that the decisions appear in the system security plan.

Questions about SC-6 cost, effort and scope

Is SC-6 required by default under NIST SP 800-53?

No. SC-6 is not assigned to any SP 800-53B baseline (low, moderate, high or privacy), 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 system and marks it as an assurance-related control, which means an assessor will still expect to see evidence once you have chosen it. Confirm whether your contract, authorizing official or overlay names it before you plan the work.

Does FedRAMP require SC-6 for cloud systems?

FedRAMP's Rev5 baselines do not require SC-6 at Class B, C or D, according to the FedRAMP Consolidated Rules for 2026. That said, a sponsoring agency or a customer contract can still ask for it through tailoring, so check the specific authorization package and any agency-added requirements. Treat the FedRAMP reference as the starting point for your scope discussion, not a guarantee that no one will ask.

How long does SC-6 implementation take?

No duration is given here because none is supplied for this control, and a timeline depends on how many systems share the resources, how mature your capacity data is and how many parameters your owners must decide. Ask any implementation partner for a timeline that follows from a written scope, with milestones for parameter decisions, configuration changes and evidence collection. Be cautious of any timeline quoted before the scope is agreed.

What drives the cost of implementing SC-6?

The main drivers are the number of systems and resource pools in scope, how many of the three organization-defined parameters you must define, and whether allocation rules already exist in your hypervisor, container platform or scheduler. Costs fall into one-time work (design, configuration, documentation and first evidence) and recurring work (reviewing quotas, retesting after capacity changes and refreshing evidence for assessments). Ask for each cost component to be listed separately so you can see who is paid for what.

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

Often yes, if your platform engineers already manage quotas, priority classes or resource limits and have someone who can own the documentation. The harder parts are usually agreeing the parameter values with business owners and assembling evidence that an assessor can trace from the control statement to configuration settings and audit records. An outside partner can prepare systems and evidence, but the organization must own the control, and only an independent assessor can issue an assessment result.

What does SC-6 need from our team during the work?

SC-6 needs decisions and access more than heavy engineering. Your team must set or approve the three organization-defined parameters, name an owner for each protected resource pool, and provide access to the platform configuration, monitoring and audit logs that show allocations in practice. Expect to review draft evidence with the people who run the platform, because an assessor will test whether the settings match what the documentation claims.

How does SC-6 differ from SC-5 for denial-of-service protection?

SC-6 concerns allocating defined resources such as processor, memory, bandwidth and storage by priority or quota, so lower-priority processes cannot starve critical ones. SC-5 concerns denial-of-service events that matter to you and the protections chosen for them, such as capacity, filtering and rate limiting. The Release 5.2.0 catalog lists SC-5 as the one related control for SC-6, so the two should be designed and evidenced together, but an assessor will test them separately.

What should we ask a partner to include in a quote for SC-6?

Ask for a written scope that names the systems, resource pools and platforms covered, the three organization-defined parameters and who decides them, and the evidence set mapped to the SC-6 assessment procedure. Also ask which deliverables are one-time and which are recurring, what access the partner needs, and which parts remain with your staff or your independent assessor. A quote that cannot explain these points is not yet a scope.

How DeployOpen scopes SC-6 and prepares its evidence

DeployOpen approaches SC-6 Resource availability as a fixed-scope implementation: the organization decides which resources need priority or quota protection, and DeployOpen configures and documents the self-hosted platforms that enforce those decisions. DeployOpen prepares the systems and evidence, while an independent assessor tests them and reports on the result.

How we scope

Confirm whether SC-6 is selected in your baseline or tailoring, since SP 800-53B does not assign it to any baseline.
List the defined resources, such as CPU, memory, bandwidth and storage, and the priority or quota rule for each.
Agree in writing which platforms, clusters and hosts fall inside the SC-6 scope and which evidence sources are included.

How we build

Configure resource quotas, limits and priority classes on the self-hosted platforms inside your own infrastructure.
Test that lower-priority workloads cannot exhaust capacity needed by critical processes under load conditions you specify.
Set up Prometheus and Grafana alerting on resource saturation so that starvation events leave a monitored record.

How we hand over

Document the defined parameters, configuration settings and design decisions that an assessor would examine for SC-6.
Export configuration files, test results and alert rule definitions as evidence packages mapped to the SC-6 assessment objects.
Deliver a handover session covering how to review, update and re-test the allocation rules after changes.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after the fixed-scope work ends.
Re-check resource allocation settings when platforms are upgraded or when NIST releases changes to SC-6 or SP 800-53A.
Confirm with your assessor which evidence formats and review intervals they expect before the assessment begins.

SC-6 Resource availability