How to Audit ISO 27001 Control 8.6: Capacity Management

Auditing ISO 27001 Annex A 8.6 Capacity Management is a technical verification process that ensures information processing resources are proactively monitored and scaled. The Primary Implementation Requirement is the establishment of resource thresholds and alerting, providing the Business Benefit of guaranteed system availability and prevention of performance-related security incidents.

ISO 27001 Annex A 8.6 Capacity Management Audit Checklist

This technical verification tool is designed for lead auditors to establish the continuous availability and performance of information processing facilities. Use this checklist to validate compliance with ISO 27001 Annex A 8.6.

1. Capacity Requirements Baseline Verified

Verification Criteria: Documented performance baselines and future capacity requirements exist for all critical information systems and infrastructure.

Required Evidence: Capacity Plan or System Design documents specifying CPU, RAM, storage, and network bandwidth thresholds.

Pass/Fail Test: If the organisation cannot produce defined capacity limits for production environments, mark as Non-Compliant.

2. Real-Time Resource Monitoring Confirmed

Verification Criteria: Technical monitoring tools are active and configured to track resource utilisation against established baselines.

Required Evidence: Live dashboard access or historical reports from monitoring software (e.g., Datadog, Nagios, Zabbix, or CloudWatch).

Pass/Fail Test: If critical servers or cloud instances are not being actively monitored for resource consumption, mark as Non-Compliant.

3. Capacity Threshold Alerting Validation

Verification Criteria: Automated alerts are configured to trigger when resource utilisation approaches or exceeds defined capacity limits (e.g., 80% disk usage).

Required Evidence: Configuration screenshots showing alert triggers and corresponding notification logs (email, SMS, or Slack).

Pass/Fail Test: If monitoring exists but lacks automated alerting for near-exhaustion of resources, mark as Non-Compliant.

4. Cloud Auto-Scaling Policies Validated

Verification Criteria: For cloud-native environments, auto-scaling policies are defined and tested to handle traffic spikes without manual intervention.

Required Evidence: Cloud console configuration (AWS Auto Scaling, Azure VM Scale Sets) showing ‘Max’ and ‘Min’ instance limits.

Pass/Fail Test: If the organisation relies on manual scaling for production workloads prone to volatility, mark as Non-Compliant.

5. Capacity Trend Analysis Records Identified

Verification Criteria: Periodic analysis of historical performance data is conducted to identify growth trends and forecast future resource needs.

Required Evidence: Quarterly Capacity Review reports or Management Information (MI) packs showing trend lines and forecasting logic.

Pass/Fail Test: If the organisation only reacts to outages rather than analysing trends to predict future capacity shortages, mark as Non-Compliant.

6. Network Bandwidth Sufficiency Confirmed

Verification Criteria: Network throughput and latency are monitored to ensure adequate bandwidth for both internal operations and external service delivery.

Required Evidence: Network traffic logs or ISP utilisation reports showing peak-load performance metrics.

Pass/Fail Test: If network bottlenecks consistently degrade security monitoring or data backup processes, mark as Non-Compliant.

7. Physical Facility Capacity Verification (On-Premise)

Verification Criteria: Physical infrastructure (UPS load, HVAC cooling, floor space) is monitored to ensure it supports the current hardware footprint.

Required Evidence: Facilities management logs or power consumption reports for the server room/data centre.

Pass/Fail Test: If the UPS or HVAC systems are operating at 100% capacity with no room for failover or growth, mark as Non-Compliant.

8. Data Storage Lifecycle and Purging Validated

Verification Criteria: Procedures exist for the regular removal or archiving of redundant data to reclaim storage capacity.

Required Evidence: Data Retention Policy and logs showing the execution of automated or manual data purging scripts.

Pass/Fail Test: If storage is managed solely by adding more hardware without a defined data deletion/archiving schedule, mark as Non-Compliant.

9. Capacity Incident Linkage Verified

Verification Criteria: System outages caused by capacity exhaustion are formally recorded and investigated as information security incidents.

Required Evidence: Cross-reference between monitoring alerts and the Information Security Incident Register.

Pass/Fail Test: If a disk-full or CPU-exhaustion crash occurred but was not raised as an incident for root cause analysis, mark as Non-Compliant.

10. Management Review of Capacity Strategy Recorded

Verification Criteria: Senior management reviews capacity metrics and approves budget for future infrastructure expansion based on verified data.

Required Evidence: Management Review Meeting (MRM) minutes or approved budgetary requests for capacity upgrades.

Pass/Fail Test: If there is no evidence that leadership is briefed on capacity risks or future infrastructure requirements, mark as Non-Compliant.

Control Requirement	The ‘Checkbox Compliance’ Trap	The Reality Check
Baselines	Tool records “Policy.pdf” as evidence of baselines.	Verify the Metric. A policy is not a baseline. Demand the technical specs for CPU/RAM limits for the primary DB.
Active Monitoring	GRC dashboard shows a green tick for “Monitoring Active.”	Verify Agent Status. Many tools mark this “Pass” if an agent is installed, even if it hasn’t reported data in 3 months.
Alerting	Tool identifies that “Alerts are configured.”	Test the Escalation. Who gets the alert? If it goes to a generic “info@” inbox that nobody checks, the control fails.
Trend Analysis	Platform generates a bar chart of current usage.	Demand the Forecast. A chart of today’s usage is data; a 12-month projection of storage growth is “Management.”
Cloud Scaling	GRC tool assumes cloud providers handle everything.	Verify Limits. Cloud accounts have hard limits (e.g., vCPU quotas). If your scaling policy hits a quota, your system dies.
Data Purging	Tool checks if “Data Retention Policy” is uploaded.	Verify the Script. Check the logs to see when data was actually deleted. GRC tools cannot see “orphaned” snapshots.
Availability Linkage	Platform lists Capacity as a standalone task.	Check the Incident Log. If there was an outage due to “Disk Full,” why did the GRC tool report Capacity as “100% Compliant”?

About the author