PR.IR-04 Capacity management: requirements and evidence

What PR.IR-04 capacity management asks your team to prove

If you are preparing a NIST CSF 2.0 assessment and PR.IR-04 is on your list, the core question is simple: can you show that your organization keeps enough resource capacity to maintain availability? The Subcategory sits in the PROTECT Function under the Technology Infrastructure Resilience Category, and its outcome is about having enough storage, power, compute and network bandwidth for systems to keep working. The practical proof is not a policy statement. It is evidence that you monitor those resources, that you know where the thresholds are, and that you forecast demand and scale ahead of it. Capacity is a security concern as well as an operations one. When a disk fills, a database stops accepting writes, a log pipeline drops events, or a firewall saturates, the result can be an outage, a loss of audit trail, or a condition attackers exploit, such as a denial of service that succeeds because headroom was never planned.

The lineage matters when you map older work. In CSF 1.1, the closest outcome was PR.DS-4, which sat under data security and concerned adequate capacity to ensure availability. NIST's CSF 1.1 to CSF 2.0 Core Transition Changes spreadsheet shows that this outcome moved into the new identifier PR.IR-04. If your earlier assessment cited PR.DS-4, carry that evidence forward and re-label it rather than rebuilding it. Confirm the mapping against the transition spreadsheet itself, since the wording and scope of the outcome have been reorganized.

Three things usually make this Subcategory hard. First, there is often no shared baseline: each team sets its own alert thresholds, and no one can say what normal load looks like for a given service. Second, capacity is owned by different people, so the infrastructure team holds the hypervisors, the facilities team holds power and cooling, and application owners hold database growth, with no single view of the whole. Third, cloud and on-premises resources are mixed, so storage quotas, reserved instances and data center circuits are measured in different tools with different units. Start by agreeing one inventory of capacity-bearing resources, one set of thresholds per resource, and one owner who reviews forecasts each quarter. Ask your team to show the most recent forecast and the action taken on the last alert.

Which systems, teams and providers fall under PR.IR-04

Capacity monitoring under PR.IR-04 is only as complete as the scope behind it. The choices below decide which storage, power, compute and bandwidth figures an organization must watch, and which outside providers it must hold accountable for their own headroom.

Production versus non-production

Scope usually starts with production, but test and staging environments can exhaust shared storage or bandwidth and then affect production. Decide whether non-production capacity is monitored with the same alert thresholds or on a lighter schedule, and document the reason. Ask whether any non-production environment is a dependency for a production service, such as a shared build pipeline or a restore target, because that dependency pulls it into scope.

Shared hypervisors and storage arrays

A single hypervisor cluster or storage array often hosts many business systems, so one overloaded volume can degrade services that look unrelated. Scoping this component widens monitoring to every workload that shares the resource, not only the system that owns it. Confirm that each tenant's demand is visible to the team that forecasts capacity, and that the owner of the shared pool can see the consumption trend.

Facility power and cooling

Power and cooling limits set how much compute an organization can add, even when servers have spare CPU and memory. Where a data center or colocation facility supplies these services, the organization may not hold the raw meter data itself. Ask the facility operator which power and thermal measurements are shared, how often they are reported, and what the contractual headroom is for the racks the organization uses.

Network links to critical services

Bandwidth limits often sit on the links between sites, to cloud regions or to identity and payment providers rather than inside the data center. Scope these links by the critical services they carry, then monitor utilization and error rates on each. A link that is quiet on average can still saturate during backup windows or failover, so confirm that peak and burst behavior is captured, not only monthly averages.

Hosted and managed providers

Managed hosting, SaaS and managed service providers can own the capacity that an organization's availability depends on. Their capacity is in scope for the organization's risk decisions even when the provider operates the platform. Request contractual capacity commitments, reporting obligations and notice periods for capacity changes, and confirm which metrics the provider will share with the organization on a recurring basis.

Ownership and monitoring handoffs

Capacity gaps often appear where ownership changes, such as between infrastructure, application and facilities teams. Assign a named owner to each scoped resource and record who receives its alerts and who approves expansion. Where a provider runs part of the stack, document the handoff so that an alert from the provider's dashboard reaches the team that can act on it.

How an assessor tests PR.IR-04 capacity management

This table walks through what an independent assessor typically samples for PR.IR-04, the evidence each step asks for, and the findings that most often appear. Read it as a checklist for preparing your own evidence before an assessment begins. NIST does not certify or assess organizations against CSF 2.0; the assessor is an independent party you engage, and the findings are theirs to issue.

Test step	What the assessor checks	Evidence requested	Common finding
Review capacity thresholds	Whether defined limits for storage, power, compute and network bandwidth exist and are tied to the availability objective	Capacity policy or standard, threshold register, approval record and the availability targets they support	Thresholds set by default vendor values with no link to the availability objective
Sample monitoring dashboards	Whether resource use is actually watched across the scoped systems and facilities	Dashboard exports or screenshots dated within the review period, and the data sources behind them	Dashboards cover compute but not storage, power or bandwidth
Sample alert history	Whether threshold breaches generate alerts that reach a responder and are closed with a recorded action	Alert logs, notification routing rules, acknowledgment and closure records	Alerts with no named owner or no acknowledgment, so breaches go unanswered
Check forecast documents	Whether forecasts of future demand exist, cover the scoped resources and are refreshed on a stated cycle	Dated capacity forecasts, growth assumptions and the review minutes or tickets that updated them	Forecasts written once and never updated after new workloads were added
Trace scaling decisions	Whether procurement, scaling or decommissioning decisions followed the forecast and thresholds	Change or procurement tickets linked to specific forecast or threshold breaches, with approval records	Scaling happens reactively with no reference to the forecast, or forecast gaps are not explained
Inspect capacity incidents	Whether past shortfalls were detected, handled and used to improve thresholds and forecasts	Post-incident reviews for a sample of capacity-related incidents, corrective actions and their closure	Root cause stops at the immediate fix, and no threshold or forecast change follows
Confirm ownership and scope	Whether named roles are accountable for each monitored resource and each facility or provider in scope	RACI or ownership register, service provider agreements covering monitored resources	Responsibility for power or hosted capacity sits with a third party whose reporting is not reviewed

How to implement capacity monitoring and forecasting step by step

This sequence turns PR.IR-04 from a statement of intent into a working cycle: know what resources exist, set thresholds tied to availability, watch them, route alerts to owners, forecast demand and record the decisions that follow.

Inventory the resources in scope
List the systems whose availability depends on storage, power, compute and network bandwidth, including the platforms your organization runs in its own cloud accounts, data centers or air-gapped networks. Record each resource, its owner, the service it supports and the capacity it has today. Start from the asset inventory maintained under ID.AM so the list matches what is actually deployed. The output is a capacity register with one row per resource and a named owner for each. You know this step is done when a technical owner can confirm every row and the business service it supports.
Define thresholds tied to availability objectives
For each resource, agree with the service owner the utilization level that starts a warning and the level that starts an urgent response, and tie both to the availability objective the service must meet. A threshold is only useful if someone can explain why that number protects the service. Record the reasoning next to each value so the thresholds can be reviewed later. The output is a threshold table that lists the metric, warning level, critical level and the availability objective it protects. The step is complete when each service owner has signed off the values for their systems.
Deploy monitoring for storage, power, compute and bandwidth
Instrument each in-scope resource so its utilization is collected continuously, covering storage capacity, power draw and headroom where your facility exposes it, compute load and network bandwidth. Open-source options such as Prometheus, which collects metrics over HTTP and stores them as time series, and Grafana Alerting, which builds alert rules from queries across data sources, are common choices, but confirm that each exporter or data source you need is supported in your environment. The output is a working dashboard and metric set per resource class. The step is done when every threshold from the previous step can be displayed and tested against live data.
Set alert routing and owners
Configure alert rules so each threshold breach reaches a named owner through a channel that someone monitors outside business hours if the service requires it. Define who acknowledges, who acts and who escalates when no action follows. Test the routing with a controlled alert before relying on it. The output is an alert routing record listing each rule, its recipient, escalation path and acknowledgment expectation. The step is complete when a test alert is delivered, acknowledged and logged end to end.
Build a periodic forecast and scaling review
Using the stored utilization history, project how each resource will grow over the planning horizon the business has agreed, and compare the projection with the thresholds. Include known events such as new workloads, contracted customer growth and hardware end of life. Where a projection crosses a threshold before the planned response can complete, record a scaling action with an owner. The output is a forecast worksheet per resource and a scaling action list. The step is done when the review has been held on a fixed cadence that the organization has written down and the actions are tracked.
Record decisions and evidence for assessors
Keep the artifacts from every prior step together with the decisions made about them: threshold changes, accepted risks, deferred scaling actions and the outcome of each alert review. Store exported dashboards, alert logs and review minutes in a location that auditors can access. Assessors look for evidence that the process ran over time, not just that it was designed, so retain a dated history. The output is a capacity management record that links each threshold, alert and forecast to the decision it informed. The step is complete when a reviewer outside the team can trace one alert from detection to decision using only the stored record.

How metrics and alerts become audit evidence

For PR.IR-04, a dashboard is not evidence by itself. An assessor wants to see that the organization continuously collects measurements of storage, power, compute and network bandwidth, that it has set thresholds that matter for availability, and that a breach of those thresholds produced a recorded alert and a documented response. Prometheus, which collects metrics from instrumented jobs over HTTP and stores them as time series identified by metric name and labels, can supply the raw history. Grafana Alerting, which builds alert rules from queries across data sources and lets teams act on alerts from one view, can supply the threshold logic and the alert trail. Together they produce a traceable record of resource use over time, provided the rules, the notification routing and the history are kept rather than recreated after the fact.

The NIST Implementation Examples for PR.IR-04 point at two activities: monitoring the use of storage, power, compute, network bandwidth and other resources, and forecasting future needs so resources can be scaled in time. The second activity is where many programs are thin. Trend data from the metric store can support forecasts, but the forecast assumptions, the review cadence and the scaling decisions taken from them need to be written down and dated. Before relying on this record, confirm with your own platform team how long metric and alert data is retained in your environment, whether it is replicated or backed up, who can alter or delete it, and whether retention covers the audit period. Prometheus stores data on local storage by default, so retention and backup are decisions the organization must make and test, not defaults to assume.

Ask the auditor early which evidence they will sample, typically a period of alert history, the rules that were active during that period, and tickets showing how each significant alert was handled. Where a threshold was tuned, keep the change record. Where capacity was added after a forecast, keep the request and the outcome. Because the organization owns its controls, this evidence must come from its own systems. An implementation partner can configure the collection, rules and retention, but only the independent assessor decides whether the evidence is sufficient.

Evidence that satisfies PR.IR-04 and how to keep it current

An assessor testing PR.IR-04 looks for proof that capacity was watched, that limits were defined, and that the organization acted before resources ran short. The cards below cover the artifacts that show this, and each one needs a routine owner and a refresh cycle so the evidence still describes today's environment when the audit happens.

Capacity inventory

A capacity inventory lists each storage pool, power circuit, compute cluster, and network link that supports in-scope services, with current utilization and the owner of each resource. It is the baseline every other artifact refers back to. Keep it current by tying updates to the change process, so a new rack, volume, or circuit cannot go live without an inventory entry. Check quarterly that entries match what the monitoring system actually sees.

Documented capacity thresholds

Thresholds state the utilization level at which a warning or action is triggered for each resource, and they should be approved by the people who own the service. Assessors look for thresholds that are written down, justified against service availability needs, and reviewed. Review them when service levels, workloads, or hardware change, and record the approval date and approver in the document itself.

Monitoring configuration and rule exports

Monitoring configuration files, such as Prometheus scrape jobs and recording rules, show what is measured and how often. Grafana alert rule exports show which conditions raise notifications and where they route. Store these in version control so every change has an author and a reason. Recheck the exports after each platform upgrade, because a silently dropped data source can leave a resource unmonitored for months.

Alert and ticket history

Alert logs and the tickets opened from them show that thresholds were acted on, not just configured. Assessors sample alerts across the audit period and trace each one to an acknowledgment, a response, and a closure note. Run a monthly sample yourself, looking for alerts that were silenced without a reason or that closed without action. Those gaps are what a sampling test is designed to find.

Capacity forecast reports

Forecast reports project when each resource will reach its threshold, based on growth trends and planned projects. PR.IR-04 expects forecasting of future needs, so the report should name its method, its data window, and the assumptions behind any planned growth. Regenerate it on a fixed schedule and keep prior versions, so the audit can show how forecasts compared with what actually happened.

Scaling change records and review minutes

Change records for capacity additions, such as added storage, extra nodes, or new circuits, show that forecasts led to action. Review meeting minutes show that leaders examined utilization trends and approved decisions. Keep both on a standing cadence, with each minutes entry linking to the forecast and tickets it discussed. Missing minutes for a quarter are a common finding, so schedule the review as a recurring calendar item with a named chair.

What meeting PR.IR-04 costs in money and effort

This table breaks down the cost and effort components of keeping capacity monitoring and forecasting in place for PR.IR-04, showing who is paid, whether each cost is one-time or recurring, and what moves it. No prices or durations are supplied for this topic, so use the table to shape a written scope and quote request rather than as a budget.

Cost component	One-time or recurring, and who is paid	What drives it up or down
Monitoring tooling and licenses	Recurring if commercial; open-source platforms such as Prometheus and Grafana carry no license fee but still need hosting	Number of data sources, metric volume and retention period; confirm licensing and hosting terms for each component
Engineering time to instrument and tune	One-time for initial exporters, dashboards and alert rules, then recurring as systems change; paid to internal staff or an implementation partner	Fleet size, number of storage, power, compute and network sources, and how much of the estate is already instrumented
Alert threshold design and tuning	Recurring; paid to platform engineers who reduce noise and set thresholds that reflect capacity limits	Rate of infrastructure change and the number of teams receiving alerts
Forecast and review effort	Recurring; paid to capacity planners or platform leads who review trends and scaling decisions	How often forecasts are reviewed, and whether scaling decisions are documented with the reasoning behind them
Evidence upkeep	Recurring; paid to operators who retain dashboards, alert history and review records in a form an assessor can sample	Retention period, number of reviews per period and whether evidence is exported automatically or collected by hand
External testing or review	Optional and recurring; paid to a security or resilience assessor for independent review of capacity controls	Scope of review, number of in-scope environments and whether the work is fixed-scope or retained
Auditor sampling time	Recurring per assessment cycle; paid to the independent auditor or assessor, not to the implementation partner	Number of samples the assessor selects and how quickly evidence can be produced on request

Who owns capacity management, who can help, and where the auditor stops

Your organization owns PR.IR-04. The outcome is that enough resource capacity is maintained to ensure availability, and that accountability sits with the people who run the services and fund the capacity decisions. No partner or auditor can take on that accountability. Internal owners typically decide which resources are measured, what thresholds matter for each service, and how forecasts feed budget and change planning.

Named ownership: Assign an accountable owner for capacity across storage, power, compute and network bandwidth, and document who acts when a threshold is crossed.
Service-level thresholds: Decide which utilization levels trigger review or scaling for each critical service, based on its availability needs.
Forecast decisions: Own the forecasts, the growth assumptions behind them and the budget and procurement choices that follow.
Review records: Keep meeting notes, approved scaling decisions and exceptions, since these show the control operating over time.
Scope of the control: Confirm which systems, providers and data centers fall inside the capacity boundary, including those run by service providers.

Before engaging anyone, check that the capacity owner can show current thresholds and a dated record of at least one decision made from them.

Common gaps in capacity management and how to close them

Most capacity failures under PR.IR-04 do not come from missing tools. They come from thresholds nobody set, coverage that stops at compute, forecasts that go stale, and alerts without an owner. Each card names one gap, why it weakens availability, and the action that closes it.

Thresholds never defined

Dashboards show storage, compute and bandwidth use, but no one has written down the level at which action is required. Without a threshold, a volume at 85 percent full looks the same as one at 40 percent until it fills. Close the gap by recording a threshold per resource in the capacity standard, with the owner, the trigger level and the response time. Ask an assessor to walk you from one threshold to the alert rule that enforces it.

Power and bandwidth left unmonitored

Teams often watch compute and memory closely while power draw in racks, UPS runtime and uplink bandwidth sit outside the monitoring scope. The Implementation Examples for PR.IR-04 name power and network bandwidth alongside compute and storage, so an uncovered resource is a visible gap. Close it by inventorying every resource class the service depends on, then confirming a metric and an alert exist for each, including facility-owned power and carrier circuits that your provider must report to you.

Forecasts written once

A capacity forecast approved at budget time often assumes growth rates that no longer match actual usage. The forecasting element of PR.IR-04 expects future needs to be estimated and resources scaled to meet them, which requires the forecast to change as the business does. Close the gap by setting a review date in the forecast document, comparing predicted against actual consumption at each review, and recording the reason for every revised assumption.

Alerts with no owner

A capacity alert that fires into a shared channel with no named responder often gets acknowledged and forgotten. Grafana Alerting can route alerts from multiple data sources to a single view, but routing does not assign accountability. Close the gap by giving each alert rule a named team, a documented first action and an escalation path, and by reviewing silenced or repeatedly firing alerts each month to confirm someone still acts on them.

Cloud quotas unmonitored

Cloud accounts enforce service quotas on instances, IP addresses, storage volumes and API calls, and a quota hit can block scaling even when the platform has spare hardware. Many teams track their own usage but not the provider limit, so the constraint appears only during an incident. Close the gap by pulling current quota values into the same monitoring view as usage, alerting on a fixed share of each limit, and confirming with the provider how to request increases and how long they take.

No record linking capacity to availability

When an outage or slowdown occurs, auditors and leaders often cannot see whether capacity decisions contributed to it. A record that ties each capacity change to the availability target it protects is what turns monitoring into evidence. Close the gap by logging each scaling or procurement decision with the metric that triggered it, the expected effect, and the outcome observed afterward, and by keeping those records with your availability reporting.

Which self-hosted tools produce capacity evidence

Which open-source tool collects capacity metrics from servers and applications?

Prometheus is the usual choice for collecting capacity metrics. It pulls metrics from instrumented jobs over HTTP on a schedule, rather than waiting for systems to push data. Each sample is stored as a time series identified by a metric name and labels, on local storage that runs independently of other systems. Teams query that history with PromQL to see how storage, compute and bandwidth have trended over weeks and months. That trend data is the raw input for showing that capacity is monitored and that future needs are forecast, which is the substance of PR.IR-04. Your team still decides which metrics matter, how long to retain them, and how to size the storage behind them.

How does Grafana Alerting turn capacity metrics into actionable alerts?

Grafana Alerting builds alert rules from queries and expressions that can read from several data sources at once, so a rule can combine Prometheus metrics with log data or other systems. Teams create, manage and act on alerts from a single view, which helps when a disk, power circuit or bandwidth threshold needs a named owner and a documented response. For an assessor, the useful evidence is the rule definitions, the notification routing, and a record of alerts that were raised and handled. Confirm in your own environment which data sources and notification channels your operations process requires before you design the rules.

What licenses apply to Prometheus and Grafana?

Prometheus is licensed under Apache-2.0, a permissive license that generally allows internal use, modification and redistribution with notice requirements. Grafana is licensed under AGPL-3.0-only. The license caveat matters if you modify Grafana and make it available to users over a network, because the AGPL's source obligations can apply to that modified version. Routine internal use of an unmodified deployment usually raises fewer questions, but this is a legal determination for your counsel, not something this page settles. Ask your legal team to review how you deploy, customize and expose the dashboards before rolling them out to customers or partners.

Can these tools monitor power and facility sensors?

Prometheus and Grafana monitor whatever you feed them, so power and facility coverage depends on exporters and integrations. Most metrics from servers, hypervisors and network devices are available through common exporters, but readings from UPS units, power distribution units, cooling and environmental sensors often need vendor-specific exporters, SNMP-based collection or a building management interface. Confirm exporter coverage for every power and facility sensor in your own environment before you assume capacity alerts will fire. Gaps in this coverage are a common reason capacity evidence looks complete on paper but misses the constraint that actually fails.

Do we need a partner to set up capacity monitoring ourselves?

Many teams can deploy Prometheus and Grafana internally, especially where they already run similar platforms. The effort is usually in the decisions around them: choosing metrics, setting thresholds that reflect real service objectives, retaining history long enough for forecasting, and documenting who responds to each alert. DeployOpen plans, implements, integrates and documents self-hosted open-source platforms inside your own infrastructure, and it prepares monitoring evidence for assessments. Work is typically fixed-scope, with deliverables agreed in writing before it starts. DeployOpen does not issue audit reports or certifications, so the independent assessor still reviews the evidence.

What should a capacity evidence package contain?

An assessor will usually look for evidence that monitoring is in place, that thresholds are defined, that alerts reach a responsible person, and that forecasts inform decisions. Useful artifacts include exported dashboards for storage, power, compute and bandwidth, alert rule definitions, notification routing, samples of fired alerts with their tickets, and a periodic capacity review with recorded decisions. Keep the Prometheus configuration and retention settings under version control so changes are traceable. Ask your assessor early which samples and time periods they expect to see, since that determines how long history must be kept.

Can Prometheus alone satisfy the capacity forecasting need?

Prometheus provides the historical series and query language needed to project trends, but it does not decide what the trend means for your business. Forecasting requires someone to set planning horizons, agree growth assumptions, and record scaling decisions. Teams often pair Prometheus data with a planning process run by infrastructure leads and finance, and they keep the outputs in a register that auditors can review. The tooling supplies the evidence; the governance around it is what turns the data into a forecast that an assessor will accept.

How DeployOpen scopes and prepares PR.IR-04 evidence

DeployOpen plans, implements and documents self-hosted monitoring and capacity processes inside the client's own infrastructure, and prepares the evidence an assessor will ask for. The work happens in the client's cloud accounts, data centers or air-gapped networks, and it is agreed as a fixed-scope engagement with scope, deliverables and timelines confirmed in writing before any work starts. A quote follows from that written scope. DeployOpen does not publish a price list, so the first useful step is to define which storage, power, compute and bandwidth resources are in scope and which systems feed the capacity data.

DeployOpen does not issue audit reports, attestations or certifications. Only an independent auditor, assessor or certification body can do that. The organization owns its PR.IR-04 control, including the thresholds it sets, the forecasts it signs off and the decisions it makes when a forecast shows a shortfall. DeployOpen's role is to prepare the systems and records that show those decisions are made: monitoring dashboards and alert rules, documented capacity reviews, and retained metric history. A practical check before engaging anyone is to ask who will approve the capacity thresholds and who will sign the forecast, because those answers determine what evidence exists at assessment time.

When you request a scope, ask the provider to state which of the two NIST Implementation Examples for PR.IR-04 each deliverable addresses, which informative references in the NIST CSF 2.0 Reference Tool are covered, and which evidence items the assessor will receive. Confirm with your auditor beforehand which artifacts they accept for a capacity forecast, how far back metric history must go, and whether a self-hosted tool's retention settings will be reviewed as part of the test. Scope what is ongoing separately from the one-time build, since continued monitoring, upgrades and forecast reviews may suit a retainer rather than a fixed project.

PR.IR-04 Capacity management