When systems crash under load, the damage extends far beyond downtime. Audit logs overflow and stop recording, giving attackers a window to operate undetected. Denial-of-service attacks succeed because nobody planned for surge traffic. According to the Uptime Institute’s 2025 Annual Outage Analysis, 54% of significant outages cost organizations more than $100,000 — and 80% were preventable with better management and processes. ISO 27001 control 8.6 exists to prevent exactly these failures.
What 8.6 Requires
ISO 27001 Annex A 8.6 requires your organization to monitor the utilization of system resources and project future capacity requirements to ensure that adequate resources are available to maintain system performance and availability.
In practical terms, this means three things. First, you must continuously track how much of your critical resources are being consumed — CPU, memory, storage, network bandwidth, and human resources. Second, you must forecast future capacity needs based on current usage trends, anticipated business growth, and planned changes such as new applications or services. Third, you must act on those forecasts before resources hit their limits.
This is a preventive control, consistent with the ISO/IEC 27002:2022 implementation guidance. The objective is not to respond to capacity failures after they happen but to identify resource exhaustion risks early enough to address them. That distinction matters during audits: an organization that only reacts to capacity incidents is not meeting the intent of 8.6, even if it has monitoring dashboards in place.
The control applies broadly. Processing power, storage volumes, network bandwidth, and human resources all fall within scope. If a resource constraint could compromise system availability or security functionality, it belongs in your capacity management program.
Why 8.6 Matters
Consider a scenario where an organization’s SIEM storage fills up during an active security incident. Log ingestion stops. The security team, already investigating suspicious activity, loses visibility into what the attacker does next. Weeks later, forensic investigators discover gaps in the audit trail that make it impossible to determine the full scope of the breach.
This is not hypothetical. Capacity failures cascade — one exhausted resource triggers failures in dependent systems. When database servers run out of disk space, applications fail, triggering emergency changes that bypass normal change control processes. When network bandwidth is saturated, security tools that depend on network telemetry go blind.
The Uptime Institute found that IT and networking issues accounted for 23% of impactful outages in 2024, and that four out of five operators acknowledged their most recent outage was preventable. Capacity management failures are not exotic risks. They are among the most common and most avoidable causes of security and availability incidents.
This is not just an IT performance concern — it is an availability and integrity risk that directly affects your information security posture.
What attackers exploit
Capacity gaps create specific attack opportunities:
- Exhausted log storage — Audit trails stop recording, and attacker activity goes undetected. This is particularly dangerous during slow, persistent attacks that unfold over weeks.
- Overwhelmed network bandwidth — Saturated links make it easier to execute denial-of-service attacks or hide malicious traffic within legitimate congestion.
- Full disk on database servers — Application failures trigger emergency changes that bypass change controls, introducing new vulnerabilities under pressure.
- Understaffed security teams — Alert fatigue means real threats get buried in noise. When analysts are overloaded, mean time to detect and respond increases dramatically.
- Unmonitored cloud limits — Auto-scaling fails silently when account limits or budget caps are hit. Organizations that assume cloud resources are infinite discover otherwise during peak events.
How to Implement 8.6
For your organization (first-party)
Implementing 8.6 starts with knowing what to monitor and building the processes to act on that information.
Step 1: Inventory critical resources. Identify every resource type that could constrain system availability or security functionality. This includes processing capacity, storage volumes, network bandwidth, human resources (security analysts, system administrators), and physical facilities (data center power and cooling).
Step 2: Establish baselines and thresholds. Measure normal utilization over a representative period, then set alert thresholds at 70-80% capacity. This provides enough lead time to act before exhaustion. Setting thresholds at 95% — a common mistake — leaves almost no reaction window.
Step 3: Implement continuous monitoring. Deploy infrastructure monitoring tools that track utilization in real time. Whether you use Prometheus, Datadog, CloudWatch, or similar platforms, the key is continuous visibility across all resource types, not just compute.
Step 4: Conduct regular capacity reviews. Review capacity data at least quarterly, tying reviews to business planning cycles. These reviews should assess current utilization trends, evaluate the impact of planned changes, and update growth projections.
Step 5: Build a capacity management plan. Document what triggers scaling actions, who has authority to approve resource procurement, and what the lead times are for different resource types. A server order that takes eight weeks needs a different planning horizon than a cloud instance that spins up in minutes.
Step 6: Run stress tests. Validate that systems can handle peak loads and projected growth. Stress testing should be scheduled regularly — not just during initial deployment.
Common mistakes to avoid:
- Only monitoring compute resources while ignoring log storage, backup capacity, and human resources
- Setting alert thresholds too high (95%), leaving no time to react before failure
- Treating cloud infrastructure as infinite — auto-scaling has account limits, service quotas, and cost implications
- Never testing capacity assumptions with actual load or stress tests
For your vendors (third-party assessment)
Your vendors’ capacity management practices directly affect your risk exposure. A critical SaaS provider that runs out of capacity can disrupt your operations just as severely as an internal failure.
When assessing vendor capacity management, include these questions in your security questionnaires:
- “Describe your capacity monitoring practices and the resource types you track.”
- “How do you forecast resource needs and plan for growth?”
- “What is your uptime SLA, and how is it supported by capacity planning?”
Request supporting evidence: a capacity management policy, monitoring architecture diagrams, recent capacity review outputs, and historical uptime or SLA reports.
Watch for red flags: no documented capacity plan, uptime SLAs with no monitoring evidence behind them, responses like “we use cloud, so it scales automatically” without specifics, and no stress testing cadence. Verify claims by reviewing historical uptime data and checking incident reports for capacity-related outages or service degradation events. For a structured approach, use UpGuard’s ISO 27001 third-party risk requirements guide.
Audit Evidence for 8.6
Auditors assessing 8.6 will look for documented evidence that your organization actively manages capacity rather than reacting to failures. Prepare the following artifacts:
| Evidence Type | Example Artifact |
|---|---|
| Policy | Capacity Management Policy defining resource types, thresholds, review cadence, and escalation procedures |
| Monitoring records | Dashboard screenshots or reports showing CPU, memory, storage, and bandwidth utilization trends |
| Capacity reviews | Meeting minutes or reports from quarterly capacity planning reviews with growth projections |
| Alerting configuration | Threshold alert rules configured in monitoring tools with escalation workflows |
| Stress test reports | Load testing results demonstrating system behavior at peak capacity |
| Capacity plan | Documented plan linking business growth forecasts to resource procurement timelines |
| Incident records | Post-incident reports for any capacity-related outages or degradation events |
The key is demonstrating a cycle: monitor, review, plan, test, and improve. Auditors are less interested in perfect numbers than in evidence that your organization has a functioning, repeatable process.
Cross-Framework Mapping
ISO 27001 8.6 maps to several controls in other frameworks, which is useful for organizations maintaining compliance across multiple standards.
| Framework | Equivalent Control(s) | Coverage |
|---|---|---|
| NIST 800-53 | AU-04 (Audit Log Storage Capacity) | Full |
| NIST 800-53 | CP-02(02) (Capacity Planning) | Full |
| NIST 800-53 | SC-05(02) (Manage Capacity/Bandwidth) | Partial |
| SOC 2 | A1.1 (Processing Integrity — Capacity) | Partial |
| CIS Controls v8.1 | Control 8 (Audit Log Management) | Partial |
| NIST CSF 2.0 | PR.IR-04 (Adequate resource capacity) | Full |
The NIST 800-53 mappings are drawn from the official NIST OLIR crosswalk. Organizations managing both ISO 27001 and NIST frameworks can consolidate capacity management evidence across these controls rather than duplicating effort.
Related ISO 27001 Controls
Capacity management connects functionally to several other Annex A controls. Understanding these relationships helps you build an integrated implementation rather than treating each control in isolation.
| Control ID | Control Name | Relationship |
|---|---|---|
| 8.5 | Secure authentication | Authentication systems need capacity for concurrent sessions |
| 8.7 | Protection against malware | Malware scanning consumes resources; capacity affects scan coverage |
| 8.13 | Information backup | Backup storage requires capacity planning |
| 8.14 | Redundancy of information processing facilities | Redundancy design depends on capacity forecasting |
| 8.15 | Logging | Log storage is a primary capacity management concern |
| 8.16 | Monitoring activities | Monitoring infrastructure itself needs capacity |
| 5.29 | Information security during disruption | Capacity failures are a common cause of disruptions |
| 5.23 | Information security for use of cloud services | Cloud capacity management has unique characteristics |
Frequently Asked Questions
What is ISO 27001 8.6?
ISO 27001 8.6 is a technological control requiring organizations to monitor system resource utilization and forecast future capacity needs. It ensures processing, storage, network, and human resources remain sufficient to maintain system performance and availability.
What happens if 8.6 is not implemented?
Without capacity management, systems can fail under load, audit logs can overflow and stop recording security events, and denial-of-service attacks become harder to withstand. These failures directly compromise availability and can mask active security incidents.
How do you audit 8.6?
Auditors verify that resource monitoring is active, thresholds trigger alerts before exhaustion, capacity reviews happen on a documented schedule, and stress tests validate that systems can handle projected growth.
How UpGuard Helps
UpGuard’s platform provides continuous monitoring of your external attack surface and vendor security posture, helping you identify capacity-related risks across your organization and supply chain before they become incidents. With automated vendor assessments and real-time risk ratings, you can verify that your third-party providers maintain the capacity management practices your compliance program requires.
Learn more about UpGuard’s platform →
_See also: _ISO 27001 implementation checklist