A.8.6 Capacity management: requirements and evidence

What A.8.6 capacity management asks for and why auditors check it

Capacity management is one of the lines in your Statement of Applicability that is easy to mark as implemented and hard to defend. The control, A.8.6, asks the organization to monitor how its resources are used and to adjust them to match current and expected capacity requirements. In practice that means processing power, storage, network throughput and the people who run the platform all need to be watched, and the organization needs to show it acts when the trend says it should. The risk the control addresses is familiar: capacity erodes slowly, nobody notices until an outage or a degraded service forces the issue, and the incident then becomes an information security matter as well as an availability one.

Auditors rarely test whether a dashboard exists. They test whether the organization can show a chain of decisions. Expect the assessor to ask which resources are in scope, what thresholds trigger a review, who receives alerts and how they respond, and how expected demand is estimated for the next budget cycle. A forecast with a named owner and a dated review is usually more persuasive than a long list of graphs. Confirm with your auditor how they expect forecasts to be documented, and whether they want the forecast tied to business plans such as new customers, product launches or seasonal peaks. Also check that your Statement of Applicability describes how A.8.6 is implemented in your environment rather than repeating the control title.

Start by recording which platforms, storage pools, network links and support staff are covered, then compare current consumption against the thresholds you have set. Keep the threshold history, the alert records and the meeting notes or tickets where a capacity increase or a deliberate decision not to increase was approved. Those records are the evidence that a monitoring setup has been operated over time, and they are what turns A.8.6 from a statement into a control an assessor can test.

Which resources and teams fall under A.8.6 capacity management

A.8.6 covers more than servers. The scope decision for each resource type determines which systems are monitored, who owns the forecast, and which evidence an assessor will ask for. The cards below map the four capacity types an organization typically has to decide on, along with the boundary questions that shape each one.

Processing capacity

This covers the compute that runs in-scope services: virtual machines, containers, clusters, databases and the hosts behind them. Start by listing which production systems handle information within the ISMS scope, then decide whether non-production environments are included. Check whether CPU, memory and queue depth are tracked against a documented threshold, and whether a named owner reviews trends and approves additional capacity when those trends require it. Confirm the boundary with the auditor before you start collecting data.

Storage and audit log capacity

Storage capacity is where A.8.6 meets logging. If logs, backups or evidence stores fill up, monitoring and recovery both fail. NIST's crosswalk relates A.8.6 to the audit log storage control in SP 800-53, so assessors may expect to see log retention volumes watched alongside general disk use. Decide whether log archives, backup targets and object storage used for evidence are in scope, and who is alerted before a volume reaches its limit. Note that NIST cautions mapped controls are not always equivalent.

Network capacity

Network capacity covers bandwidth, load balancers, firewalls, VPN concentrators and the links between sites and cloud regions. The scoping decision here is whether capacity of third-party network services, such as a managed cloud gateway or an ISP circuit, is tracked by your team or only reviewed through the provider's reports. Identify the links that carry in-scope traffic, define the utilization signals you watch, and document how congestion is escalated. Related controls on network services and redundancy may also apply, so confirm the boundary with them.

Human capacity and skilled staff

Human capacity covers on-call rotations, staff who can run and recover critical systems, and the skills needed to operate monitoring. Whether this sits under A.8.6 or under people and continuity controls is a scoping decision you should record explicitly. Many organizations cover the monitoring and forecasting side here and handle hiring, training and succession elsewhere. Ask your auditor which controls they expect to test this, and confirm that a named person can act when an alert fires outside working hours.

How an assessor tests A.8.6 capacity management

This table sets out, for each area an assessor usually samples, what they test, the evidence they request and the findings that come up most often. Read it as a checklist of what your records must show: a planning process, monitored resources, forecasts compared with actual use, alerts tied to documented responses, and people capacity planned alongside technical capacity.

Assessment area	Test approach	Evidence requested	Common findings
Capacity planning process	Read the documented process and check that it covers processing, storage, network and human capacity, with named owners and review intervals	Capacity management procedure, roles, review meeting records and the most recent plan approved by management	Procedure exists but names no owner, or covers only compute and ignores storage, network and staffing
Sampling of monitored resources	Select a sample of production systems and confirm that utilization metrics are collected for each one over the audit period	Metric dashboards or exports, monitoring scope list, and the inventory of systems it is matched against	Critical systems or a whole cloud account are missing from monitoring, or metrics stop for weeks without anyone noticing
Forecasts against actual use	Compare the forecasts in the plan with the utilization recorded afterward and check whether the plan was revised	Forecast documents with dates, actual utilization reports for the same period, and records of plan updates	Forecasts were set once and never updated, or actual growth exceeded the forecast with no explanation or adjustment
Alert thresholds and response	Review alert rules for capacity thresholds, then trace a sample of fired alerts to tickets, changes or accepted-risk decisions	Alert rule configuration, notification history, incident or change tickets and sign-off for threshold changes	Alerts fire with no documented response, or thresholds were set so high that no warning is ever given before exhaustion
Human capacity planning	Check whether staffing, on-call rota and skills coverage are assessed against workload and critical operations	On-call schedules, staffing reviews, skills matrix and records of workload discussed by management	No review of key-person dependence, on-call load is unmanaged, or security operations depend on one individual
Storage for logs and audit data	Confirm that log and monitoring storage is sized against retention requirements and that full-disk conditions are alerted	Retention settings, storage utilization history and alerts for log volume or disk exhaustion	Log pipelines dropped events during peaks because nobody sized storage for growth

Implementing A.8.6 capacity management step by step

This sequence turns A.8.6 into a working cycle: an inventory of what needs capacity, metrics with named owners, thresholds that route alerts, a forecast fed by business plans, a recorded decision trail, and a first review run end to end that an auditor can trace.

Inventory the resources in scope
List every processing, storage, network and people resource that supports the systems in the ISMS scope, such as compute clusters, databases, object storage, log pipelines, network links and on-call or operations staff who keep those systems running. Record the owner, the platform each resource runs on and any dependency on a cloud provider or data center. The output is a capacity register that matches the asset inventory used for other controls, so an auditor can trace any monitored resource back to an asset record. Confirm the register with the system owners before you move on.
Define capacity metrics and owners
For each inventoried resource, choose the measures that show how close it is to its limit, such as CPU and memory utilization, disk fill rate, log ingestion volume, connection pool use, bandwidth and queue depth, plus a staffing measure for human capacity such as on-call load. Name one accountable owner per metric. Metrics that an open-source collector can scrape, such as those exposed to Prometheus, should be listed with their collection source. The output is a metric catalog with owners, which an assessor will compare against the register to check nothing important is unmeasured.
Set thresholds and alert routes
Agree a warning level and a critical level for each metric, based on the resource's real limit and the time needed to add capacity. Configure alert rules in your monitoring stack, for example with Grafana Alerting, which builds rules from queries across data sources, and send each alert to the named owner through a defined route. Test that a threshold breach actually notifies someone. The output is a threshold table, exported rule definitions and a test record showing alerts were delivered, which together show the monitoring is operating as designed.
Establish a forecasting review cadence
Set a recurring forecast review in which owners compare observed trends with expected demand. Pull the demand assumptions from business plans, such as planned customer onboarding, product launches, seasonal peaks, new regions or contract volumes, and translate them into expected load on each resource. Document the cadence, the attendees and the inputs each review needs. The output is a forecast per resource with a stated horizon and a dated review schedule. Ask your organization to confirm that the business planning owner provides demand inputs, because an assessor will look for that link.
Define the decision and escalation record
Write down what happens when a forecast or an alert shows that capacity will fall short: who decides between adding capacity, optimizing use, or accepting a temporary shortfall, who approves spending, and when an issue goes to senior management. Record each decision with the date, the trigger, the options considered, the chosen action and the owner. The output is a decision log template and an escalation path. An auditor will test whether a real threshold breach led to a recorded decision, so the template must capture enough detail to show the reasoning.
Run the first review cycle end to end
Carry one full cycle through without shortcuts: pick a resource, pull its metrics for the review period, compare them with thresholds and the forecast, log any alerts and the decisions taken, and confirm the forecast was updated. Keep the meeting notes, exported dashboards, alert history and decision records together as one evidence package. Then ask the owners to sign off and note any gaps in metrics, thresholds or routes. The output is a completed first review with its evidence, which shows the control operated, not only that it was designed.
Feed review findings back into the cycle
Use the outcome of the first review to correct the register, metric catalog, thresholds and forecast assumptions. Remove resources that were retired, add new ones, and adjust thresholds that produced noise or missed real pressure. Record each change with its reason so the history shows improvement over time. The output is an updated register and a change log that ties back to the review. This closes the loop that an auditor expects to see across successive review cycles, and it is the point where the control becomes routine rather than a one-off exercise.

Evidence that passes A.8.6 and how to keep it current

An assessor testing A.8.6 Capacity management wants to see that resource use was watched, that thresholds and forecasts were acted on, and that decisions can be traced to dates and owners. The cards below cover the artifacts that usually carry that proof, from the written plan to the records of human capacity. Each one should be kept current between audits, so a sampled period shows a continuous record rather than a catch-up exercise.

Capacity plan with scope

The capacity plan states which systems, sites, network links, storage pools and staffing functions it covers, who owns each, and which thresholds trigger action. Assessors check that the scope matches the ISMS scope and the asset inventory. Keep it current by reviewing scope whenever a system is added, retired or moved to a new cloud account, and record the review date and approver. A sampled period should show the plan version in force at each point, with changes explained.

Metric definitions and dashboards

Metric definitions record what is measured, such as CPU, memory, disk, queue depth or bandwidth, how it is collected, its unit and its time window. Dashboards show those metrics against the thresholds in the plan. With Prometheus, the collection jobs and PromQL expressions themselves can serve as the definition, kept under version control. Check that every system in scope has at least one metric, and that dashboards still load and point at live data after platform changes. Confirm the retention period of the metric store with the platform team, since it limits how far back a sampled period can be shown.

Alert rule exports and routing records

Alert rules show the conditions that raise a capacity warning, and routing records show who received it and when. Export the rules and notification policies on a schedule and store them with the change history, so an assessor can compare the rules in force at a given date with the alerts fired. In Grafana Alerting, rules are built from queries across data sources, which makes the export a clear artifact. Test notifications periodically and keep the test records, since an alert nobody receives is not evidence of control.

Forecast reviews with dated decisions

Forecast reviews compare recent consumption with the projected trend and state whether the expected capacity need changed. Each review should end with a dated decision: no action, a purchase, a scale-out, or a retirement of unused capacity, with the owner named. Schedule the review at a fixed interval set in the plan and hold it even when nothing has changed, since a silent quarter is itself a record. Assessors commonly sample a few reviews and check that a threshold breach or forecast change led to a recorded decision.

Change and ticket records of capacity actions

Capacity actions such as adding storage, resizing a cluster, or adding bandwidth should appear in the change or ticket system with the trigger, the approval and the outcome. Link each record to the alert or forecast decision that prompted it, so the chain from measurement to action is visible. Check that emergency capacity changes are recorded after the fact with the same detail. Missing links between alerts and tickets are a frequent gap in the sampled period, so review them monthly rather than at audit time.

Human capacity plans

A.8.6 also covers human capacity, so the plan should record staffing levels needed to run security-relevant operations such as on-call rotations, log review and access reviews. Record coverage gaps, leave and turnover that affect those functions, and the decisions taken to close them, such as hiring, cross-training or contracted support. Refresh the plan after reorganizations and when a key person leaves. Ask the organization to confirm which roles are counted as capacity-critical, since the standard does not define a staffing ratio and the assessor will expect the organization's own reasoning.

What meeting A.8.6 capacity management costs

This table breaks down the cost components of meeting A.8.6 by who is paid, whether each cost is one-time or recurring, what pushes it up or down, and how to keep it contained. Use it to structure a written scope and to compare quotes line by line. No figures are given here, so ask each provider to price every row separately.

Cost component	One-time or recurring	What drives it up or down	How to keep it down
Tooling or licenses	Recurring (subscription or support), with some one-time setup	Commercial monitoring suites charge by host, metric volume or user; self-hosted open-source tools such as Prometheus and Grafana remove license spend but not infrastructure or labor	Confirm license terms in writing, including the Grafana AGPL-3.0-only terms if you modify and offer it as a service; size storage for metric retention you actually need
Engineering time to instrument and configure monitoring	One-time, with ongoing changes as systems are added	Number of systems, applications and network devices in scope; how many services already expose metrics; whether dashboards and alert rules are built from scratch	Standardize exporters and label conventions; reuse alert templates; agree the capacity scope in writing before work starts
Forecast and review effort	Recurring, usually on a set review cycle	Frequency of capacity reviews; how volatile demand is; whether forecasts cover processing, storage, network and human capacity or only compute	Document the review cadence and thresholds; limit forecasts to resources with real growth risk; record decisions in the same review
Evidence upkeep	Recurring	Number of capacity reports, alert records and review minutes kept; retention periods; whether evidence is collected by hand or exported automatically	Automate exports of dashboards and alert history; define which records an assessor will sample and keep only those
External review	Recurring, often tied to the audit cycle	Whether an independent party reviews the capacity approach before the audit; how many systems and sites it covers; whether readiness review is included	Ask for a fixed-scope review with named deliverables; use internal staff to prepare evidence before the reviewer arrives
Auditor sampling time	Recurring, within each certification audit	Number of capacity records and alert events the auditor samples; gaps found during sampling that require follow-up; sites in scope	Keep a single index of capacity reviews and their outcomes; resolve gaps before the audit window
Quote items to request	Both	Ask for each row above as a separate line with one-time and recurring amounts, assumptions and the scope they cover	Request the assumed number of systems, retention periods, review frequency and which costs the provider excludes

Open-source monitoring tools that produce A.8.6 evidence

A.8.6 asks for evidence that resource use is watched and adjusted against current and expected needs. Two open-source components can supply much of that record: one collects and stores the measurements, the other turns them into alerts that someone must act on. Neither decides capacity targets, so the organization still owns the thresholds, forecasts and review.

Prometheus metric history

Prometheus collects metrics from instrumented jobs over HTTP using a pull model, then stores them as time series identified by metric name and labels on its local storage. Queries written in PromQL can show CPU, memory, disk, and network trends for each host, service or cluster, which is the raw material for judging current load and projecting growth. Confirm how long data is kept on local storage in your own environment, since retention determines how far back an assessor can see. Also confirm the capacity of the storage volume and whether long-term history is copied elsewhere.

Prometheus job coverage records

The pull model means Prometheus must reach each target to collect data, and an unreachable target shows as a gap rather than silence. Keep the list of scraped jobs under configuration control so that an assessor can compare it with the asset inventory and see which systems in scope are actually measured. Missing jobs for production databases, backup systems or network devices are common findings, so review coverage at each capacity review and record the decision for any system left out.

Grafana Alerting rule exports

Grafana Alerting builds alert rules from queries and expressions across multiple data sources and lets teams create, manage and act on alerts from one view. Exported alert rule definitions show which thresholds, such as disk or processing headroom, trigger notices and who receives them. These exports, together with the change history of the rules, show that capacity thresholds were defined and then adjusted when needs changed, which is the adjustment half of A.8.6.

Grafana alert handling records

A capacity alert only supports A.8.6 if someone responds to it. Use the alerting views to keep the firing history, acknowledgements and the follow-up actions tied to each alert, such as adding storage or moving workloads. Confirm that notification routes reach a named owner outside business hours, since an alert sent to an unmonitored channel gives an assessor no evidence of action.

Grafana license before deployment

Grafana is licensed under AGPL-3.0-only, which carries obligations that differ from permissive licenses such as Apache-2.0 used by Prometheus. Whether those obligations apply depends on how the software is modified and offered to users, so have legal counsel review the license against your deployment before rollout. This check belongs in the supplier and open-source review that supports the organization's governance of third-party components.

Who owns A.8.6 capacity management and what to outsource

Your organization owns A.8.6 in full. Only your staff can decide what capacity the business needs, which thresholds trigger action, how far ahead to forecast, and who approves spending or workload shifts when demand rises. These decisions are the control itself, so they cannot be delegated to a vendor or a consultant. Your team also owns the human side of capacity, including on-call coverage, skills cover for key platforms and the planning of staff time against expected change.

Capacity decisions: Define the resources in scope (processing, storage, network and people) and record who decides when each one is expanded or reduced.
Thresholds and forecasts: Set alert levels, review cycles and forecast horizons that match your business plans and seasonal demand.
Human capacity: Plan rotas, backup skills and succession for the people who operate monitored systems.
Review and sign-off: Review trend reports on a set cadence and record the outcome of each review.
Risk acceptance: Document any capacity shortfall you choose to accept and who approved it.

Check that each decision has a named owner, a written threshold and a dated review record that an assessor can trace.

Common gaps that fail A.8.6 and how to close them

Most A.8.6 findings are not missing tools. They are monitoring that nobody reviews, plans that ignore the business, and evidence assembled in a rush before an audit. Each card below names one gap, the action that closes it and the record an assessor can check.

Monitoring runs but nobody reviews it

Dashboards and metrics collection can be fully running while no one is accountable for looking at them. An assessor will ask who reviews resource use, how often, and what happens to a threshold breach. Assign a named owner for each monitored resource, set a review cadence, and keep dated review notes. Evidence: review records, dashboard exports taken on review dates, and tickets raised from findings.

Forecasts ignore planned growth

Capacity forecasts built only from past usage miss launches, new customers, acquisitions and planned migrations. A.8.6 expects adjustment to expected capacity needs, not just current load. Require product and finance inputs to the forecast and record the assumptions behind each projection. Evidence: a dated forecast that lists planned business events, the capacity change each one requires, and the approval of the change.

Alerts fire with no documented response

Capacity alerts that reach an inbox but trigger no defined action are a common finding. Each alert should map to a runbook that states who responds, the first action, and when the issue escalates to a change. Test a few alerts end to end so the response is proven, not assumed. Evidence: alert rules, linked runbooks, and tickets showing the response to real or test alerts.

Audit log storage capacity is untracked

Logging systems can silently fill their storage, which stops event capture and creates a gap in the logging control. Treat log volume and retention storage as monitored resources with their own thresholds and forecasts. NIST relates A.8.6 to audit log storage capacity in its crosswalk, though it cautions that mapped controls are not always equivalent. Evidence: storage metrics for log stores, retention settings, and alerts on projected exhaustion.

Human capacity missing from planning

Capacity covers people as well as servers. Key operators who are the only people able to run a platform, renew a certificate or respond to alerts create a capacity risk. Record staffing for critical monitoring and operations roles, cover absences, and review the load when systems grow. Evidence: a roster of named backups for each critical role and a staffing review in the capacity plan.

Evidence gathered only at audit time

Teams often rebuild capacity reports from memory when an assessor arrives, and the result cannot show what was known at the time. Export and store metrics, forecasts and review records on a fixed schedule so history exists before the audit. Confirm retention periods for these records with your auditor. Evidence: a dated archive of forecasts, review sign-offs and threshold history kept under the organization's own retention rules.

Frequently asked questions about A.8.6 capacity management

How much effort does A.8.6 capacity management take to run?

The effort depends mostly on how many systems are in scope, how variable their load is, and how many capacity signals already exist. A small environment with one application and a single database usually needs a short list of metrics, a few thresholds and a monthly review. A larger estate with several clusters, cloud accounts and log pipelines needs per-system thresholds, forecasts for each growth driver and a review cadence tied to change management. Ask any implementer to size the work from your asset inventory and the systems you have already designated as in scope, not from a generic estimate.

How long does it take to get capacity evidence in order?

Timing depends on whether monitoring already collects resource metrics. If it does, the main work is defining which metrics matter, setting thresholds, documenting who acts on alerts and keeping review records. If it does not, instrumentation of each in-scope system comes first, and that work is often the longest part. Auditors look for a period of recorded monitoring and reviews, so evidence needs to exist over time, not just be configured on the day of the audit. Confirm the schedule with your implementer and your certification body before committing to an audit date.

What does the internal team need to provide for capacity management?

The internal team owns the decisions that a tool cannot make. Those include which services are critical, what growth the business expects, who receives alerts out of hours, and what action follows a threshold breach. Engineering owners should confirm capacity limits for their systems, and the business should supply demand forecasts such as planned launches or customer onboarding. An implementation partner can configure dashboards, alert rules and reports, but the organization remains accountable for the capacity plan and for showing that it was reviewed and acted on.

Can we run A.8.6 capacity management in-house?

Yes, many organizations do. An in-house team can define scope, deploy monitoring, set thresholds and keep review records if it has the skills to operate the platform and the time to maintain it. The main risks are gaps in ownership, metrics that were configured once and never reviewed, and forecasts that ignore planned business changes. A self-assessment against the control's purpose, using a written list of in-scope systems and a sample of recorded reviews, will show whether the internal approach holds up before an external assessor tests it.

What does an implementation partner add to capacity management?

A partner can prepare the technical side: deploying self-hosted metrics collection, building dashboards and alert rules, integrating storage and network signals, and documenting the configuration as evidence. DeployOpen, for example, plans and implements self-hosted platforms inside the client's own infrastructure and can prepare the evidence an assessor will request. It does not decide what capacity is acceptable for your business, and it does not issue audit reports or certificates. Independent auditors and certification bodies do that. Ask for a written scope listing the systems, deliverables and handover of ownership.

How does A.8.6 relate to A.8.14 and A.8.16?

A.8.6 covers monitoring resource use against current and expected needs. A.8.14 covers building enough redundancy into processing facilities to meet availability requirements, so capacity data feeds redundancy decisions. A.8.16 covers monitoring systems for anomalous behavior and acting on what is found. The three overlap in tooling, since the same metrics and alerts often serve all of them, but they ask different questions. Document where one control's evidence supports another, and keep each control's purpose, scope and owner distinct so that an assessor can follow the reasoning.

How does A.8.6 map to NIST AU-4, and is the mapping exact?

NIST's crosswalk from SP 800-53 Rev. 5 to ISO/IEC 27001:2022 relates A.8.6 to AU-4, Audit Log Storage Capacity. That link is useful if you already implement NIST controls, because storage capacity for audit logs is a shared concern. NIST cautions that mapped controls are not always equivalent, so AU-4 does not cover the full scope of A.8.6, which also includes processing, network and human capacity. Use the crosswalk to reuse evidence where it fits, and confirm with your assessor how they will treat the mapping before relying on it.

How DeployOpen prepares A.8.6 capacity management evidence

DeployOpen plans, builds and documents the capacity monitoring, forecasting and alerting that support A.8.6 Capacity management, inside the client's own infrastructure. The organization keeps ownership of its capacity decisions and control design, while DeployOpen prepares the systems and records that show how resource use is watched and adjusted.

How we scope

Agree in writing which processing, storage, network and supporting platforms fall inside the A.8.6 capacity monitoring scope.
Confirm with the client which capacity thresholds, review cadence and owners the organization has set for each resource type.
Record scope, deliverables and timelines in a fixed-scope agreement before any build work starts.

How we build

Deploy Prometheus to collect metrics from instrumented jobs and retain time series for the period the client sets.
Configure Grafana Alerting rules on capacity metrics and logs, with alert routing to the people named in the capacity procedure.
Test alert rules against simulated threshold breaches so the client can show that warnings fire and reach the right owner.

How we hand over

Document dashboards, query definitions, alert rules and the forecasting method in a handover pack the client's team can maintain.
Provide evidence records such as dashboard exports, alert history and review logs that an assessor can sample against the control.
Walk the client's operators through how to read capacity trends, respond to alerts and record decisions about adding resources.

How we support

Offer ongoing support, upgrades and monitoring maintenance as a retainer after the initial handover.
Review capacity alert performance and evidence completeness with the client ahead of any independent audit.
Confirm with the client's auditor or certification body which capacity evidence they expect, since only they issue reports or certificates.