What is ISO 27001 Annex A 8.6 – Capacity Management?
ISO 27001 Annex A 8.6 focuses on monitoring and managing the capacity of information-processing resources to ensure that systems have enough resources to operate effectively and securely.
Capacity means having enough resources to handle the organization’s current and expected workload.
These resources may include:
- CPU
- Memory
- Storage
- Database capacity
- Network bandwidth
- Internet connectivity
- Cloud resources
- Application capacity
- Virtual machines
- Containers
- Serverless resources
- API capacity
- User licenses
- Backup capacity
- Security-tool capacity
- Power and cooling where relevant
Simple Explanation
Make sure your technology has enough capacity to support the business today and as the business grows.
If capacity is not managed, systems may become:
- Slow
- Unavailable
- Unstable
- Overloaded
- Unable to process transactions
- Unable to complete backups
- Unable to support business growth
Capacity management therefore supports the availability and performance of information-processing systems.
Why is Capacity Management Important?
A system does not necessarily fail because of a cyberattack.
It can fail simply because it runs out of resources.
For example:
Customer Growth
↓
More Users
↓
More Transactions
↓
Higher CPU / Memory / Database Usage
↓
Capacity Limit Reached
↓
Application Becomes Slow
↓
Service Disruption
This can affect:
- Customer experience
- Business operations
- Revenue
- Service availability
- Security monitoring
- Backup operations
- Incident response
- Regulatory or contractual commitments
Common Capacity Risks
- Server CPU reaches maximum
- Database storage becomes full
- Network bandwidth becomes insufficient
- Cloud resources reach limits
- API rate limits are exceeded
- Backup storage fills up
- Log storage becomes full
- Monitoring systems cannot process events
- Email or SaaS license limits are reached
- Production environments cannot handle increased demand
Simple Principle
Do not wait for systems to run out of capacity before taking action.
What Does ISO 27001 Annex A 8.6 Require?
The organization should monitor and manage the capacity of information-processing resources.
The organization should consider:
- Current resource utilization
- Expected business growth
- Expected changes in demand
- System performance
- Resource thresholds
- Capacity limits
- Availability requirements
- Critical business services
- Supplier/cloud limitations
- Scalability
- Redundancy where required
- Performance monitoring
- Capacity planning
The control should be implemented according to the organization’s risk, size, technology environment, and business requirements.
A small startup does not need an expensive capacity-management platform simply to satisfy ISO 27001.
What is Capacity Management?
Capacity management is the process of ensuring that technology resources are sufficient for current and expected requirements.
It can be viewed as:
Measure → Analyze → Forecast → Plan → Scale → Monitor
For example:
A SaaS company observes that its production database is consistently operating at 75–80% storage utilization.
Instead of waiting for the database to reach 100%, the organization:
- Monitors usage
- Defines a threshold
- Forecasts growth
- Plans additional capacity
- Expands storage
- Records the change
- Continues monitoring
Capacity vs Performance vs Availability
These concepts are related but different.
| Concept | Question |
|---|---|
| Capacity | Do we have enough resources? |
| Performance | Are systems responding efficiently? |
| Availability | Is the system available when required? |
Example
A database may be:
- Available but slow → performance issue
- Fast but nearly full → capacity risk
- Completely unavailable → availability issue
A.8.6 primarily addresses capacity, although capacity problems can directly affect performance and availability.
Activities Required to Implement Annex A 8.6
1. Identify Critical Information-Processing Resources
Start by identifying resources supporting important business services.
Examples:
- Production servers
- Cloud infrastructure
- Databases
- Storage
- Network infrastructure
- Internet connectivity
- SaaS platforms
- Backup systems
- Logging infrastructure
- Monitoring platforms
- Security tools
A simple register might look like:
| Resource | Business Service | Criticality |
|---|---|---|
| Production Database | SaaS Platform | Critical |
| Application Servers | SaaS Platform | Critical |
| Object Storage | Customer Data | Critical |
| Internet Connection | Office Operations | High |
| Backup Storage | Business Continuity | High |
| Monitoring Platform | Security Monitoring | High |
2. Identify Capacity Metrics
Determine which measurements are meaningful for each resource.
Examples:
Compute
- CPU utilization
- Memory utilization
- Container utilization
- VM utilization
Storage
- Disk usage
- Database size
- Backup storage
- Log storage
Network
- Bandwidth utilization
- Throughput
- Connection count
- Network latency
Database
- Storage
- Connections
- Query load
- IOPS
- CPU
- Memory
Applications
- Concurrent users
- Requests per second
- Transactions per second
- Queue size
- API calls
3. Establish Capacity Thresholds
Organizations should define thresholds appropriate to their environment.
For example:
| Resource | Normal | Warning | Critical |
|---|---|---|---|
| CPU | <70% | 70–85% | >85% |
| Memory | <70% | 70–85% | >85% |
| Storage | <70% | 70–85% | >85% |
| Database | <70% | 70–85% | >85% |
| Backup Storage | <70% | 70–85% | >85% |
These values are examples, not ISO 27001 requirements.
Actual thresholds should be determined based on the organization’s architecture and risk.
4. Monitor Capacity
Capacity monitoring can be performed through:
- Cloud dashboards
- Infrastructure monitoring
- Application monitoring
- Database monitoring
- Network monitoring
- Operating-system monitoring
- SIEM/observability platforms
- Managed service dashboards
For cloud environments, organizations can use built-in monitoring services or other appropriate tools.
5. Define Alerts
Monitoring is useful only if someone responds to important capacity issues.
Example:
Storage > 80%
↓
Alert
↓
IT / DevOps Notification
↓
Investigate
↓
Forecast
↓
Scale or Remediate
Alerts should be meaningful.
Generating hundreds of unnecessary alerts can result in alert fatigue.
6. Forecast Future Capacity
Capacity management should not only look at today’s usage.
Consider:
- Customer growth
- Employee growth
- Transaction growth
- New products
- New applications
- Seasonal demand
- Marketing campaigns
- Geographic expansion
- New customers
- Data growth
- Regulatory retention requirements
Example
A SaaS company has:
10,000 users today
and expects:
25,000 users within six months.
The company should consider whether:
- Database capacity
- Storage
- API capacity
- Compute
- Network
- Monitoring
- Backup
will support the expected growth.
7. Plan for Business Growth
Capacity planning should be connected with business planning.
For example:
Business Growth
↓
Expected Customer Growth
↓
Expected Transaction Growth
↓
Technology Capacity Assessment
↓
Capacity Plan
↓
Infrastructure Scaling
This is especially important for fast-growing startups.
8. Consider Cloud Scalability
Cloud environments often provide flexible scaling.
Examples include:
- Auto-scaling
- Larger compute instances
- Additional instances
- Database scaling
- Storage expansion
- Load balancing
- Container scaling
- Serverless scaling
However, cloud does not automatically eliminate capacity-management responsibilities.
Cloud systems still have:
- Resource limits
- Service quotas
- API limits
- Database limits
- Network limits
- Account limits
- Cost constraints
Therefore:
Cloud scalability is a capability, not a substitute for capacity management.
9. Monitor Storage Capacity
Storage is frequently overlooked.
Monitor:
- Production disks
- Database storage
- Object storage
- Backup storage
- Log storage
- SIEM storage
- Archive storage
A full disk can cause:
- Application failures
- Database failures
- Logging failures
- Backup failures
- System instability
10. Manage Backup Capacity
Backup systems also require sufficient capacity.
For example:
More Data
↓
Larger Backups
↓
More Backup Storage
↓
Capacity Monitoring Required
The organization should consider:
- Backup size
- Backup frequency
- Retention period
- Storage growth
- Backup repository capacity
- Recovery requirements
This connects capacity management with business continuity and backup controls.
11. Consider Security-System Capacity
Security systems also need capacity.
Examples:
- SIEM
- EDR
- Firewalls
- IDS/IPS
- Log management
- Vulnerability scanners
- Monitoring systems
If log storage becomes full, security events may stop being retained.
If a monitoring platform becomes overloaded, important alerts may be delayed or lost.
Therefore, capacity management supports security monitoring as well as business applications.
12. Consider SaaS License Capacity
Capacity does not always mean CPU or storage.
SaaS services may have:
- User limits
- API limits
- Storage limits
- Transaction limits
- Usage limits
- License limits
Example:
A company has 100 employees but its collaboration platform supports only 100 licensed users.
If the organization grows to 130 employees, additional capacity must be planned.
13. Manage Network Capacity
Network capacity can affect:
- Customer applications
- VPN
- Remote work
- Cloud connectivity
- Backup
- Security monitoring
- Video conferencing
- Business applications
Organizations should consider bandwidth requirements and critical connectivity dependencies.
14. Address Capacity During Major Changes
Capacity should be considered when:
- Launching a new application
- Adding major customers
- Migrating infrastructure
- Opening a new office
- Changing cloud architecture
- Increasing backup retention
- Implementing new security tooling
This connects A.8.6 with change management and project management.
Startup Example
Example: SaaS Startup
A 30-person SaaS company has:
- AWS production environment
- PostgreSQL database
- Object storage
- Kubernetes
- CloudFront/CDN
- Monitoring platform
- Backup system
The company currently has:
5,000 customers
and expects:
20,000 customers
within the next year.
Current Situation
The company monitors CPU but does not monitor:
- Database storage
- Database connections
- Backup storage
- API requests
- Kubernetes resource limits
- Log storage
This creates a capacity-management gap.
Improved Approach
The company defines:
Production Capacity Dashboard
| Metric | Current | Threshold | Action |
|---|---|---|---|
| CPU | 52% | 80% | Investigate/scale |
| Memory | 61% | 80% | Investigate/scale |
| DB Storage | 68% | 80% | Plan expansion |
| DB Connections | 55% | 80% | Review |
| Backup Storage | 63% | 80% | Forecast |
| API Requests | 60% | 80% | Review scaling |
| Log Storage | 72% | 85% | Increase/clean appropriately |
The startup reviews the dashboard regularly and includes capacity considerations in major technology changes.
Capacity Management Register
A simple startup register could be:
| Resource | Metric | Current Usage | Threshold | Review Frequency | Owner |
|---|---|---|---|---|---|
| Production CPU | Utilization | 55% | 80% | Continuous | DevOps |
| Database | Storage | 65% | 80% | Daily | DBA/DevOps |
| Backup | Storage | 60% | 80% | Daily | IT |
| Network | Bandwidth | 45% | 75% | Daily | IT |
| Log Platform | Storage | 70% | 85% | Daily | Security |
| SaaS Platform | Licenses | 85 users | 95 | Monthly | IT |
Capacity Planning Example
Suppose database storage is growing by approximately 100 GB per month.
Current storage:
600 GB
Available capacity:
1,000 GB
At the current growth rate:
1,000 GB
- 600 GB
= 400 GB available
400 GB ÷ 100 GB/month
= approximately 4 months
The organization should therefore plan additional capacity before the system reaches the limit.
This is the basic principle behind capacity forecasting.
What Evidence Can an Auditor Ask For?
An auditor may request:
Governance
- Capacity Management Policy
- Capacity Management Procedure
- IT Operations Policy
- Infrastructure Management Procedure
Monitoring
- Capacity dashboards
- CPU monitoring
- Memory monitoring
- Storage monitoring
- Database monitoring
- Network monitoring
Planning
- Capacity plans
- Forecasts
- Growth projections
- Infrastructure scaling plans
Alerts
- Capacity alerts
- Alert configuration
- Incident/ticket records
- Remediation records
Cloud
- Cloud monitoring reports
- Resource utilization
- Service quota reviews
- Auto-scaling configuration
- Cloud architecture documentation
Backup
- Backup storage utilization
- Backup capacity reports
- Retention calculations
ISO 27001 Annex A 8.6 Audit Checklist
| Question | Yes/No | Evidence |
|---|---|---|
| Are critical information-processing resources identified? | Asset register | |
| Are capacity requirements defined? | Capacity standard | |
| Are important resources monitored? | Monitoring dashboard | |
| Are capacity thresholds established? | Configuration | |
| Are alerts configured? | Alert settings | |
| Are capacity issues investigated? | Tickets/incidents | |
| Is future demand considered? | Capacity forecast | |
| Is business growth considered? | Capacity plan | |
| Is cloud capacity monitored? | Cloud dashboard | |
| Are cloud quotas considered? | Quota review | |
| Is storage monitored? | Storage reports | |
| Is backup capacity monitored? | Backup reports | |
| Is security-tool capacity considered? | SIEM/log reports | |
| Are major changes assessed for capacity impact? | Change records | |
| Are capacity requirements periodically reviewed? | Review records |
Common Mistakes
1. Monitoring CPU Only
CPU is only one capacity metric.
An application can fail because:
- Database storage is full
- Memory is exhausted
- Network capacity is insufficient
- Database connections are exhausted
- API limits are reached
2. Waiting Until Capacity Is Exhausted
Capacity management should be proactive.
The objective is:
Predict → Plan → Scale
rather than:
Fail → Investigate → Emergency Fix
3. Assuming Cloud Means Unlimited Capacity
Cloud platforms are scalable, but they still have technical and service limits.
4. Ignoring Backup Capacity
Backup storage can grow rapidly.
5. Ignoring Log Storage
Security and operational logs can consume significant storage.
A full logging system can also affect security monitoring.
6. No Capacity Thresholds
Monitoring without defined thresholds may not provide meaningful early warning.
7. No Ownership
Someone should be responsible for reviewing and responding to capacity alerts.
8. No Forecasting
Historical usage should be considered when planning future capacity.
9. Ignoring Business Growth
Capacity planning should reflect expected customer and transaction growth.
Practical Startup Implementation Model
A startup can implement A.8.6 using:
Identify → Measure → Monitor → Set Thresholds → Forecast → Plan → Scale → Review
Identify
Identify critical resources.
Measure
Determine meaningful capacity metrics.
Monitor
Monitor resource utilization.
Set Thresholds
Define warning and critical thresholds.
Forecast
Estimate future demand.
Plan
Create capacity actions.
Scale
Increase or optimize resources when required.
Review
Review trends, incidents, and business growth.
Policy vs. Process vs. Evidence
| Type | Example |
|---|---|
| Policy | Critical IT resources shall be monitored for capacity |
| Process | DevOps reviews capacity alerts and utilization trends |
| Standard | Storage warning threshold is defined |
| Configuration | Cloud monitoring alert at defined utilization |
| Evidence | Capacity dashboard |
| Record | Capacity review meeting |
| Action | Infrastructure scaling change |
An auditor should be able to see a connection between:
Requirement → Monitoring → Alert → Action → Evidence
Capacity Management for Cloud-Native Startups
A cloud-native startup may have little physical infrastructure.
Its capacity-management scope could instead include:
Cloud Compute
↓
Database
↓
Storage
↓
Network
↓
API Limits
↓
Logs
↓
Backups
↓
Monitoring
The startup should identify which of these are relevant to its business.
Example
A startup using AWS may monitor:
- EC2/ECS/EKS resources
- RDS capacity
- S3 usage
- Network utilization
- Cloud service quotas
- API usage
- CloudWatch metrics
- Backup capacity
The specific services will depend on the organization’s architecture.
A.8.6 vs A.8.14 – Redundancy of Information Processing Facilities
These controls are related but different.
| Control | Focus |
|---|---|
| A.8.6 | Having sufficient capacity |
| A.8.14 | Redundancy to achieve availability |
Example
A database has enough storage:
Capacity → A.8.6
Two database instances are configured for resilience:
Redundancy → A.8.14
Capacity does not automatically mean redundancy.
A.8.6 vs A.8.13 – Information Backup
| Control | Focus |
|---|---|
| A.8.6 | Ensure sufficient technology capacity |
| A.8.13 | Ensure information is appropriately backed up |
However, backup storage itself is a capacity-management consideration.
A.8.6 vs A.5.30 – ICT Readiness for Business Continuity
| Control | Focus |
|---|---|
| A.8.6 | Normal and expected capacity requirements |
| A.5.30 | ICT capability to support business continuity |
Capacity planning should consider both normal operations and continuity requirements where applicable.
Questions an Auditor May Ask
1. How do you know your systems have sufficient capacity?
Show monitoring and capacity planning.
2. What resources do you monitor?
Explain the organization’s critical resources.
3. What happens when capacity reaches a threshold?
Demonstrate the alert and response process.
4. How do you plan for business growth?
Show forecasts or capacity plans.
5. How do you monitor database capacity?
Provide relevant monitoring evidence.
6. How do you monitor cloud limits?
Show service quotas and resource monitoring where relevant.
7. How do you manage backup storage?
Show capacity monitoring and retention planning.
8. What happens if capacity is insufficient?
Explain escalation, scaling, optimization, or contingency actions.
9. Who owns capacity management?
Identify responsible personnel or teams.
10. How often is capacity reviewed?
Demonstrate monitoring and periodic review.
Useful Resources
Organizations implementing Annex A 8.6 may maintain:
- Capacity Management Policy – [Insert Draft Document Link]
- Capacity Management Procedure – [Insert Draft Document Link]
- Capacity Monitoring Standard – [Insert Draft Document Link]
- Capacity Register – [Insert Draft Document Link]
- Capacity Planning Template – [Insert Draft Document Link]
- Infrastructure Utilization Dashboard Template – [Insert Draft Document Link]
- Capacity Risk Assessment – [Insert Draft Document Link]
- Cloud Capacity Review Checklist – [Insert Draft Document Link]
- Capacity Alert and Escalation Procedure – [Insert Draft Document Link]
- Capacity Management Audit Checklist – [Insert Draft Document Link]
Startup-Focused Quick Summary
For a startup, A.8.6 can be implemented with a relatively simple approach.
Start with your critical systems
Identify:
- Production
- Database
- Storage
- Network
- Backup
- Logging
- Security monitoring
Monitor meaningful metrics
Do not monitor everything just for the sake of monitoring.
Focus on resources that could affect business operations.
Set practical thresholds
Define when utilization requires investigation or action.
Forecast growth
Consider:
- Customers
- Employees
- Transactions
- Data
- New products
Plan before failure
If capacity is approaching a limit, take action before the business is affected.
Keep evidence
Maintain:
- Dashboards
- Reports
- Alerts
- Tickets
- Capacity reviews
- Scaling changes
Startup-Focused Final Takeaway
ISO 27001 Annex A 8.6 is about making sure that information-processing resources have enough capacity to support business operations now and as requirements change.
It is not simply a requirement to monitor CPU usage.
A practical startup approach is:
Know what resources matter → Measure them → Monitor them → Define thresholds → Forecast growth → Plan capacity → Scale before failure.
For a SaaS startup, this may be as simple as monitoring:
Compute + Memory + Database + Storage + Network + Backups + Logs + Cloud Limits
and maintaining evidence that the organization reviews those resources and acts when necessary.
The key question for an auditor is:
“How do you know that your critical systems have sufficient capacity, and what do you do when capacity approaches a limit?”
If the organization can demonstrate monitoring, thresholds, forecasting, ownership, and timely action, it has a practical foundation for implementing Annex A 8.6.
One-Line Summary
ISO 27001 Annex A 8.6 ensures that information-processing resources are monitored, planned, and managed so that insufficient capacity does not disrupt secure and reliable business operations.