ISO 27001 Capacity Management: A.8.6 Evidence and Audit Tests

Direct answer: ISO 27001 capacity management should identify the resources that constrain important services, monitor current use, forecast demand and trigger action before resource limits threaten availability. Auditors should see both the management design and evidence that thresholds, forecasts and scaling decisions operate in practice.

Capacity management is not only about server processor or storage utilisation. An information service can fail because an identity provider reaches a limit, a software licence pool is exhausted, a supplier quota is exceeded, a recovery platform cannot handle the required load or a specialist team has insufficient coverage.

ISO/IEC 27001:2022 Annex A control 8.6 addresses capacity management. ISO/IEC 27002 provides implementation guidance, while the organisation’s own risk assessment and service requirements determine what is necessary. This article provides AuditPrepared guidance and does not reproduce the standard’s text.

Define capacity from service outcomes

Start with services in the ISMS scope and the business outcomes they support. For each important service, identify:

• expected transaction, user, data and integration volumes;
• peak and seasonal patterns;
• availability and response-time commitments;
• recovery capacity and degraded-service requirements;
• upstream and downstream constraints;
• supplier limits, throttling and contractual quotas;
• security tooling volumes such as logs, alerts and retention; and
• people or operational resources that can restrict service.

The official ISO/IEC 27001 overview explains that an ISMS protects confidentiality, integrity and availability through risk management. Capacity decisions should therefore connect to service impact, not be treated as isolated infrastructure housekeeping.

Build a service-to-resource model

A useful model links each critical service to its limiting resources and accountable owners.

Service element	Capacity measure	Example constraint	Owner
Application tier	Request rate, latency, concurrent sessions	Worker or connection pool	Application owner
Database	Storage, input/output, connections, replication lag	Storage growth or query load	Database service owner
Identity service	Authentications, tokens, directory operations	Tenant or rate limit	Identity owner
Network	Bandwidth, packet loss, device sessions	Link or firewall throughput	Network owner
Logging platform	Events per second, ingestion and retention	Licence or storage quota	Security monitoring owner
Cloud service	API requests, compute quota, regional availability	Provider quota or scaling delay	Cloud service owner
Operations team	On-call coverage, ticket load, specialist time	Single qualified responder	Operations manager

Document important dependencies. A front-end may scale automatically while a database, licence or external API remains fixed. The bottleneck, not the largest component, determines service capacity.

Translate risk into thresholds

Define thresholds that trigger investigation and action before failure. Avoid applying one percentage to every technology. The right signal depends on workload behaviour, scaling time and business impact.

Use several levels:

1. Operating range — normal variation that needs no action.
2. Early warning — review trend, forecast and planned changes.
3. Action threshold — add, tune or reallocate capacity within an approved time.
4. Critical threshold — escalate because a service objective or recovery capability is at risk.

For a log platform, retained volume and daily ingestion may matter more than processor load. For a database, sustained latency and connection saturation may signal risk before storage is exhausted. For a support team, unresolved priority tickets and on-call gaps may be leading indicators.

Link thresholds to the ISO 27001 KPI design guide so that measures have an owner, data source, frequency, target and defined management response.

Forecast demand and supply

Historical trends alone are insufficient when the business is changing. Combine operating data with forward-looking inputs:

• customer or employee growth;
• planned product releases and campaigns;
• acquisitions, migrations and new locations;
• changes in data retention or logging detail;
• new regulatory or contractual needs;
• supplier deprecation or quota changes;
• recovery and resilience improvements; and
• threat-driven demand, including attack traffic or incident logging.

Forecast a range rather than a single precise number. State assumptions and uncertainty. A base, high-growth and disruption scenario can expose which capacity decisions are reversible and which require long lead times.

The NIST glossary defines capacity planning as systematically determining resource needs for projected output over a defined period. That definition is a useful cross-check, but the organisation must establish its own ISO 27001 control design.

Select treatment options deliberately

Capacity action may include:

• vertical or horizontal scaling;
• performance tuning or workload scheduling;
• data archiving or retention changes approved by accountable owners;
• supplier quota increases;
• load balancing or regional distribution;
• queuing, throttling and priority processing;
• removal of obsolete workloads;
• additional licences or specialist coverage; and
• graceful degradation that protects essential functions.

Evaluate security side effects. Adding an unmanaged server, weakening retention or bypassing approval may solve a short-term performance problem while creating a different risk.

For cloud autoscaling, verify minimum and maximum boundaries, scale-up delay, quota ceilings and the capacity of dependencies. “The cloud scales” is an assumption until tested against the full service path.

Include recovery capacity

Production capacity and recovery capacity are different questions. A secondary environment may exist but be unable to handle priority workload, security monitoring or data reconciliation within the required time.

Use the business impact analysis guide to identify minimum acceptable service levels and recovery timing. Test whether the recovery arrangement can support those levels for the expected duration. Include staff, connectivity, identity, security tooling and suppliers in the test.

Preserve design and operating evidence

Design evidence

• capacity scope and service-resource mapping;
• approved thresholds and service objectives;
• ownership and escalation rules;
• data sources and monitoring frequency;
• forecasting method and assumptions;
• change, scaling and emergency-response procedures; and
• links to risk, continuity and supplier records.

Operating evidence

• monitoring dashboards or exported metrics;
• threshold alerts and investigations;
• periodic forecasts and management decisions;
• approved scaling or tuning changes;
• supplier quota reviews;
• recovery or load-test results;
• exceptions and temporary measures; and
• closure evidence for identified shortfalls.

A dashboard proves that data exists, not that management acts. Sample an alert and trace it through analysis, decision, implementation and confirmation.

Use a worked example

An online service expects customer volume to grow 30% after a product launch. Current monitoring shows database connections reach 70% during normal peaks, with a warning at 75% and action at 85%.

The service owner models base and high-growth demand. The application tier can scale within minutes, but the database requires a planned configuration change and the supplier must approve a higher connection limit. A load test also shows that the standby environment supports only half of the business-approved minimum recovery volume.

Management approves three actions: increase the database limit before launch, tune connection handling and expand the standby environment. Each action has an owner, due date, test result and rollback plan. This is capacity management connected to availability risk—not merely a monthly graph.

Audit control operation

Select services with different architectures and importance. For each sample:

1. compare service commitments with defined capacity measures;
2. identify the resource most likely to constrain delivery;
3. examine whether thresholds precede service failure;
4. compare forecast assumptions with business changes;
5. trace an alert to action and verification;
6. inspect supplier and licence limits; and
7. compare production and recovery capacity.

The Annex A control lookup can help teams navigate related controls, while the licensed standard and Statement of Applicability remain the authoritative basis for conformity.

Result	Example
Pass	Critical services have owned measures, evidence-based thresholds, forecasts and tested actions covering production and recovery constraints.
Partial	Infrastructure monitoring is strong, but supplier quotas, people constraints or recovery capacity are omitted.
Fail	Capacity is reviewed only after outages, alerts have no defined response or critical limits are unknown.

Common questions

Does capacity management require a separate policy?

No particular document title is universally required. The organisation needs controlled information and evidence sufficient for its control design, risks and operating complexity.

Is average utilisation adequate evidence?

Usually not. Averages can hide short peaks, regional constraints and exhausted pools. Use measures that reveal the failure mechanism and the time available to respond.

Does autoscaling satisfy A.8.6 automatically?

No. Autoscaling is one mechanism. Limits, dependencies, security effects, cost controls, recovery use and tested behaviour still need management.

Manage capacity before availability becomes an incident

Effective capacity management turns business demand into measurable service constraints and timely decisions. Monitor the right bottlenecks, forecast material change, test recovery capacity and retain evidence that management acts before thresholds become outages.