ISO 27001 A.8.6: Capacity Management

Quick Reference (60 Seconds)

Bottom Line: Capacity management ensures your systems have enough resources to handle current and future demand. Without it, systems slow down, crash, or become unavailable, leading to business disruption, lost revenue, and damaged reputation. It's about having enough capacity, not too much, and planning for growth.

What the Control Asks For

In short:

ISO 27001:2022 Annex A 8.6 asks organizations to monitor and adjust the use of resources to meet current and expected capacity needs.

Do you need this control?

A.8.6 is not mandatory in itself: under clause 6.1.3 you include it if your risk assessment calls for it, and record the decision in your Statement of Applicability. Include it if running out of capacity (compute, storage, network, people) could affect availability or security. Cloud autoscaling changes how you do it, not whether you need it.

What ISO 27002:2022 Adds

27002 8.6 (paraphrased) covers the capacity of information processing facilities, human resources, offices and other facilities, not only IT. It suggests:

• identifying capacity requirements by the business criticality of systems and processes
• tuning and monitoring systems to keep them available and efficient
• stress-testing systems and services to confirm they can meet peak demand
• detective controls that flag problems in time
• projecting future needs from new business and system requirements and from trends
• paying attention to resources with long procurement lead times or high cost
• managers using capacity information to avoid resource limits and dependency on key personnel

To increase capacity: (a) hire people, (b) obtain new facilities or space, (c) acquire more powerful processing, memory and storage, (d) use cloud elasticity and scalability.

To reduce demand: (a) delete obsolete data, (b) dispose of hard-copy records past retention, (c) decommission applications, systems, databases or environments, (d) optimise batch processes and schedules, (e) optimise code and queries, (f) restrict bandwidth for non-critical heavy services (for example video streaming).

Consider a documented capacity plan for mission-critical systems. ISO/IEC TS 23167 gives more on cloud elasticity.

Why Capacity management Matters

The Cost of Capacity Failures

Capacity failures are among the most visible and damaging IT incidents. When systems run out of capacity, they don't just slow down, they crash, corrupt data, and deny service to users. The financial and reputational impact can be severe.

Key Statistics

• Industry surveys of cloud spending (for example Flexera's annual State of the Cloud reports) consistently find that organisations believe a large share of their cloud spend is wasted, so over-provisioning is a cost risk as well as under-provisioning an availability risk
• Peak events drive failures: festival sales, month-end and tax deadlines, exam results and market volatility all create surges that systems must be tested for
• People are capacity too: a single administrator or on-call engineer is a single point of failure

How It Goes Wrong (hypothetical patterns)

• An e-commerce site crashed during Diwali sales due to inadequate server capacity; the company lost six hours of peak sales and 50,000 customers moved to competitors
• A bank's core banking system ran out of storage during month-end processing; all branch transactions were halted for 4 hours, affecting 2 million customers
• A SaaS company's database ran out of connection capacity; all 5,000 customers experienced simultaneous service disruption, leading to 15% churn in the next quarter
• A cloud migration was done without capacity planning; the new environment had 40% less capacity than required, causing performance degradation and a costly rollback
• A government portal for tax filing crashed on the deadline day due to unexpected traffic surge; the government had to extend deadlines and faced public criticism

Regulatory and Business Drivers

• SEBI has a specific capacity-planning framework for market infrastructure institutions (installed capacity planned as a multiple of projected peak load and reviewed regularly), and stock exchanges set capacity requirements for brokers' trading systems; SEBI CSCRF (2024) adds resilience expectations
• RBI (Master Direction on IT Governance 2023) expects regulated entities to plan capacity and performance for critical systems; NPCI sets uptime and success-rate expectations for UPI participants
• SOC 2 A1.1 asks service organisations to maintain, monitor and evaluate processing capacity
• Service Level Agreements (SLAs) with customers and partners specify availability requirements that depend on capacity management
• Business Continuity requires that critical systems have adequate capacity to maintain operations during disruptions
• Cost Optimization requires balancing capacity needs with cost, over-provisioning wastes budget, under-provisioning risks availability

Scope and Applicability

What Is Covered

• All information processing facilities (servers, virtual machines, containers, cloud instances)
• All storage systems (SAN, NAS, object storage, cloud storage, databases)
• All network capacity (bandwidth, throughput, latency, connections)
• All memory and compute resources (CPU, RAM, GPU)
• All database capacity (connections, storage, IOPS, throughput)
• All application capacity (concurrent users, transactions per second, API rate limits)
• All cloud resources (compute, storage, network, database, serverless)
• All backup and recovery capacity (storage for backups, network for replication)
• All infrastructure supporting critical business processes
• People: on-call cover, key-person dependency and skills for critical systems (27002 8.6)
• Offices and facilities: space and facilities needed for operations

What Is Not Covered

• Power and cooling capacity for equipment, covered with utilities (A.7.11)
• Non-IT capacity (manufacturing equipment, vehicles), outside ISMS scope

Applicability by Organization Type

Key Definitions and Terminology

Relationship to Other Controls

Implementation Roadmap (Week-by-Week)

Week 1: Capacity Inventory and Baseline Establishment

• Inventory all information processing facilities (servers, VMs, cloud instances, containers)
• Inventory all storage systems (SAN, NAS, object storage, cloud storage, databases)
• Inventory all network infrastructure (bandwidth, throughput, connections)
• Establish baseline use for all resources (CPU, memory, disk, network, database connections)
• Identify peak load periods and patterns (daily, weekly, monthly, seasonal)
• Identify critical systems and their availability requirements
• Document current capacity and use baseline

Week 2: Capacity Planning Framework Development

• Define capacity management policy and objectives
• Define capacity planning methodology (trend-based, forecast-based, model-based)
• Define use thresholds (warning, critical, action)
• Define headroom requirements (e.g., 20% spare capacity for critical systems)
• Define capacity review and planning cycle (monthly, quarterly, annual)
• Define roles and responsibilities for capacity management
• Establish capacity planning templates and documentation standards

Week 3: Monitoring and Threshold Implementation

• Deploy capacity monitoring tools (monitoring, APM, cloud-native tools)
• Configure monitoring dashboards for all critical resources
• Set warning thresholds (e.g., 70% CPU, 80% memory, 85% disk)
• Set critical thresholds (e.g., 85% CPU, 90% memory, 95% disk)
• Configure alerting for threshold breaches (email, SMS, ticketing)
• Implement capacity monitoring for cloud resources (AWS CloudWatch, Azure Monitor, GCP Monitoring)
• Configure database capacity monitoring (connections, storage, IOPS, slow queries)

Week 4: Capacity Planning and Forecasting

• Analyze historical use trends (3–12 months of data)
• Identify growth patterns and seasonality
• Forecast capacity needs for the next 12–24 months
• Document capacity requirements for new projects and initiatives
• Plan for peak load scenarios (e.g., Diwali, tax season, year-end, product launches)
• Identify bottlenecks and constraints in current capacity
• Develop capacity improvement plan with timeline and budget

Week 5: Scalability and Auto-scaling Implementation

• Implement auto-scaling for cloud resources (if applicable)
• Configure load balancers for horizontal scaling
• Test scalability of critical applications under load
• Implement database scaling (read replicas, sharding, partitioning)
• Configure caching layers to reduce backend capacity demand
• Implement CDN for static content to reduce server load
• Test failover and redundancy capacity during maintenance

Week 6: Optimization and Right-sizing

• Analyze over-provisioned resources and right-size them
• Implement resource tagging for cost allocation and capacity tracking
• Identify and terminate unused or idle resources (zombie instances, unattached storage)
• Implement storage tiering (hot, warm, cold) to optimize cost and capacity
• Implement data compression and deduplication where applicable
• Optimize database capacity (indexing, archiving, purging)
• Implement resource scheduling (start/stop non-production environments outside business hours)

Week 7: Documentation, Reporting, and Communication

• Document capacity baseline, thresholds, and targets
• Create capacity dashboard for stakeholders
• Establish monthly capacity report with trends, forecasts, and recommendations
• Communicate capacity status to IT leadership and business stakeholders
• Document capacity escalation procedures for threshold breaches
• Create capacity plan for the next 12 months with budget requirements
• Prepare capacity documentation for audit

Week 8: Testing, Training, and Audit

• Conduct load testing to validate capacity planning assumptions
• Test alerting and escalation procedures for threshold breaches
• Test auto-scaling behavior under simulated load
• Test failover capacity during maintenance windows
• Train IT operations staff on capacity monitoring and management
• Conduct internal audit of capacity management implementation
• Prepare for external audit
• Plan for continuous improvement

Detailed Implementation Guidance

Capacity Planning Methodology

Trend-Based Planning:

• Analyze historical use data (3–12 months)
• Identify trends (linear growth, seasonal patterns, step changes)
• Extrapolate trends to forecast future needs
• Simple and effective for stable environments
• Formula: Future Capacity = Current Capacity × (1 + Growth Rate)^Time Period

Forecast-Based Planning:

• Incorporate business plans, marketing campaigns, product launches
• Adjust for known events (e.g., Diwali sales, tax season, new client onboarding)
• More accurate for dynamic environments
• Requires business input and cross-functional collaboration

Model-Based Planning:

• Use queuing theory, simulation, or modeling tools to predict capacity needs
• Accounts for complex interactions between systems
• Useful for complex, interconnected environments
• Requires specialized tools and expertise

Hybrid Approach (Recommended):

• Use trend-based for baseline forecasting
• Use forecast-based for known business events
• Use model-based for complex, high-risk systems
• Combine methods for complete capacity planning

Capacity Thresholds and Headroom

Recommended Thresholds:

Headroom Considerations:

• Critical systems: 20–30% headroom to handle unexpected spikes and failover
• Standard systems: 15–20% headroom for normal growth and variability
• Non-critical systems: 10–15% headroom; can tolerate occasional degradation
• Peak season systems: 30–50% headroom during peak periods (e.g., e-commerce during Diwali)
• Failover systems: 50–100% headroom to handle full production load during failover

Cloud Capacity Management

Cloud-Specific Capacity Considerations:

Cloud Cost Optimization Through Capacity Management:

• Use reserved instances or savings plans for predictable workloads (30–60% savings)
• Use spot instances for non-critical, interruptible workloads (60–90% savings)
• Implement auto-scaling to avoid over-provisioning during low demand
• Right-size instances based on actual use (not just "safe" sizing)
• Use storage tiering (S3 Glacier, Azure Cool Blob) for infrequently accessed data
• Implement resource scheduling (start/stop dev/test environments outside hours)
• Use serverless for variable workloads to pay only for actual usage
• Monitor and eliminate unused resources (unattached volumes, idle instances, abandoned snapshots)
• Implement resource tagging for cost allocation and accountability

Database Capacity Management

Database Capacity Dimensions:

Database Capacity Planning:

• Monitor database growth rate (GB per month, rows per month)
• Forecast storage needs based on growth rate and retention policies
• Plan for index growth and maintenance space
• Account for log file growth (transaction logs, binary logs, redo logs)
• Plan for backup storage (full + incremental + archive)
• Test database performance under projected load before production deployment
• Plan for database scaling (vertical, horizontal, sharding, read replicas)

Application Capacity Management

Application Capacity Metrics:

Application Capacity Planning:

• Profile application performance under load (load testing, stress testing)
• Identify bottlenecks (database queries, external APIs, memory leaks, CPU-intensive operations)
• Optimize bottlenecks before scaling (caching, query optimization, code optimization, CDN)
• Plan for user growth based on business projections (marketing, sales, expansion)
• Plan for seasonal spikes (Diwali, tax season, year-end, back-to-school)
• Test application behavior at 2x, 3x, and 5x expected peak load
• Plan for graceful degradation under extreme load (throttling, priority queues, feature degradation)

Network Capacity Management

Network Capacity Dimensions:

Network Capacity Planning:

• Baseline current network use (peak and average)
• Identify bandwidth-intensive applications and users
• Plan for growth in remote work (VPN, video conferencing, cloud access)
• Plan for cloud migration (increased internet bandwidth, reduced internal traffic)
• Plan for new applications (bandwidth requirements, latency sensitivity)
• Implement QoS to prioritize critical traffic (VoIP, video, real-time systems)
• Design redundant links for critical paths (diverse paths, automatic failover)
• Monitor for bandwidth abuse and unauthorized high-bandwidth usage
• Plan for DDoS protection capacity (on-premise and cloud-based scrubbing)

Tools, Technologies, and Solutions

Infrastructure Monitoring and APM

Cloud Native Monitoring

Database Capacity Management

Load Testing and Capacity Validation

Policy and Procedure Templates

Capacity Management Policy Template

Capacity Incident Response Procedure

Risk Assessment and Treatment

Risk Assessment Matrix for Capacity management

Audit and Compliance Checklist

Internal Audit Checklist (30 Questions)

Policy and Planning (5 Questions)

1. Is a capacity management policy documented and approved?
2. Is capacity planning performed on a defined schedule (monthly, quarterly, annually)?
3. Are capacity plans documented and approved by IT leadership?
4. Are business requirements and growth projections incorporated into capacity planning?
5. Is the policy reviewed annually?

Monitoring and Thresholds (5 Questions)

6. Is capacity monitoring implemented for all critical resources?
7. Are use thresholds defined and documented?
8. Are alerts configured for threshold breaches?
9. Is monitoring data retained for trend analysis?
10. Are monitoring dashboards accessible to operations and management?

Response and Action (5 Questions)

11. Are capacity incidents responded to within defined SLAs?
12. Are escalation procedures documented for capacity incidents?
13. Are capacity incidents documented and analyzed?
14. Are post-incident reviews conducted for critical/high incidents?
15. Are corrective actions implemented and tracked?

Optimization and Efficiency (5 Questions)

16. Is resource right-sizing performed regularly?
17. Are unused or idle resources identified and removed?
18. Are cloud costs monitored and optimized?
19. Is storage tiering implemented for infrequently accessed data?
20. Are non-production environments scheduled for start/stop?

Scalability and Resilience (5 Questions)

21. Is auto-scaling implemented for applicable cloud resources?
22. Is load balancing configured for critical applications?
23. Is failover capacity adequate for critical systems?
24. Is failover capacity tested during maintenance or DR drills?
25. Is load testing conducted for critical applications?

Documentation and Reporting (5 Questions)

26. Is capacity baseline documented and maintained?
27. Are monthly/quarterly capacity reports produced and distributed?
28. Is capacity forecasting documented with methodology?
29. Is capacity plan documentation available for audit?
30. Are capacity incident records retained and reviewed?

Audit Scoring

• 30–27: Excellent (Green), Full compliance
• 26–22: Good (Yellow), Minor gaps, address within 30 days
• 21–15: Needs Improvement (Orange), Significant gaps, address within 60 days
• 14–0: Critical (Red), Major non-compliance, immediate action required

Metrics and KPIs

Key Performance Indicators

Common Pitfalls and How to Avoid Them

Pitfall 1: "We'll Add Capacity When We Need It"

Problem: Organizations wait until systems are at 95% use before planning capacity. By then, it's too late, procurement, deployment, and testing take weeks or months. Systems crash before new capacity arrives. Solution: Implement proactive capacity planning with defined thresholds (70% warning, 85% critical, 90% action). Plan capacity 3–6 months in advance. Include procurement and deployment lead times in capacity planning. Use auto-scaling for cloud resources to handle short-term spikes. Proactive capacity management prevents reactive firefighting.

Pitfall 2: Over-Provisioning "Just to Be Safe"

Problem: Organizations massively over-provision resources to avoid any risk of capacity shortfall. This wastes 30–50% of budget and creates "zombie" resources that are never used. Cloud costs spiral out of control. Solution: Use data-driven capacity planning, not guesswork. Monitor actual use and right-size regularly. Use auto-scaling for variable workloads. Use reserved instances for predictable workloads. Implement resource tagging allocation. Review cloud bills monthly. The goal is "just enough" capacity, not "way too much."

Pitfall 3: Ignoring Non-Production Environments

Problem: Organizations focus capacity management on production but ignore development, testing, and staging environments. These environments run 24/7 with no users, consuming significant resources and budget. Solution: Implement resource scheduling for non-production environments (start at 8 AM, stop at 8 PM). Use smaller instance sizes for non-production. Use spot instances or preemptible VMs for testing. Implement automated shutdown policies for idle environments. Non-production environments can consume 30–50% of total cloud spend, optimize them aggressively.

Pitfall 4: No Capacity Planning for Peak Loads

Problem: Organizations plan for average load but ignore peak periods (Diwali, tax season, year-end, product launches). Systems that handle average load fine crash during peak periods, leading to lost revenue and reputation. Solution: Identify all peak periods and their expected load. Plan capacity for peak, not average. Use auto-scaling for cloud resources to handle peaks. Use CDN for static content during high traffic. Implement load shedding and graceful degradation for extreme peaks. Load test at 2x–3x expected peak load. Peak planning is not optional for business-critical systems.

Pitfall 5: Capacity Management Without Business Input

Problem: IT plans capacity in isolation, without understanding business plans. A marketing campaign that will drive 10x traffic is not communicated to IT. The system crashes on launch day. Solution: Establish a formal process for business to communicate capacity requirements (campaigns, launches, expansions). Include business stakeholders in capacity planning meetings. Create a capacity requirement intake form for new projects. Review business plans quarterly for capacity implications. IT capacity planning must be a business partnership, not an IT-only function.

Pitfall 6: No Capacity Monitoring for Cloud

Problem: Organizations migrate to cloud but do not implement cloud-native monitoring. They are surprised by bills, performance issues, and outages because they cannot see what's happening in the cloud. Solution: Implement cloud-native monitoring (AWS CloudWatch, Azure Monitor, GCP Monitoring) from day one. Use cloud cost management tools (CloudHealth, Flexera). Set up budget alerts and anomaly detection. Monitor cloud resource use just as you would on-premise. Cloud visibility is essential for cloud management.

Pitfall 7: Ignoring Database Capacity

Problem: Organizations monitor server CPU and memory but ignore database-specific capacity (connections, storage, IOPS, query performance). Database capacity issues are the most common cause of application slowdowns. Solution: Monitor database capacity separately from server capacity. Track connections, storage growth, IOPS, query performance, and lock contention. Use database-specific monitoring tools (Oracle Enterprise Manager, SQL Server DMVs, PostgreSQL pg_stat_statements). Plan for database growth, indexing, and archiving. Database capacity is not server capacity, it requires specialized attention.

Pitfall 8: No Load Testing Before Production

Problem: Applications are deployed to production without load testing. The application works fine with 10 users but crashes with 100. The first real test is in production, with real users. Solution: Load test all critical applications before production deployment. Use realistic user scenarios and data volumes. Test at 2x, 3x, and 5x expected peak load. Identify and fix bottlenecks before launch. Use load testing tools (JMeter, Gatling, K6). Load testing is not optional for business-critical applications.

Illustrative Scenarios

Illustrative scenario, a composite example for guidance, not a specific Singahi engagement or a verified outcome.

Illustrative Scenario 1: Indian E-commerce Startup, Capacity Planning for Growth (Growing company)

Organization: A 150-employee e-commerce startup in Delhi selling fashion and lifestyle products, growing 40% year-over-year Challenge: The startup was growing rapidly but had no capacity planning. Their infrastructure was a single server (8 CPU, 16 GB RAM) running the website, database, and payment processing. During the previous Diwali, the website crashed at 11 AM on the first day of the sale. The server CPU hit 100%, memory was exhausted, and the database connection pool was maxed out. Customers flooded social media with complaints. The brand reputation was severely damaged. The CEO mandated a capacity overhaul before the next Diwali. Before State:

• Single server running all services (website, database, payment)
• No capacity monitoring; no alerts; no thresholds
• No capacity planning; infrastructure was "buy more when it breaks"
• No load testing; no idea of maximum capacity
• No auto-scaling; no cloud infrastructure
• No backup capacity planning; backups failed when storage was full
• Database was on the same server as the application
• No CDN; all traffic hit the single server directly
• No caching; every request hit the database
• No peak load planning; the previous year's Diwali traffic was 10x normal

Implementation: Month 1: Migrated to cloud (AWS) with auto-scaling EC2 instances, RDS for database, and S3 for storage and CDN. Month 2: Implemented complete monitoring (CloudWatch, RDS Performance Insights, Application Load Balancer metrics). Month 3: Implemented caching (Redis for session and product data, CloudFront for static content). Month 4: Conducted load testing with JMeter; identified and fixed bottlenecks (database queries, API latency, image loading). Month 5: Implemented auto-scaling policies (scale up at 70% CPU, scale out at 80% ALB requests). Month 6: Planned peak capacity for Diwali (3x expected load, pre-provisioned 10 instances, warmed CDN cache). Month 7: Implemented database read replicas and query optimization. Month 8: Implemented right-sizing optimization (reserved instances, storage tiering, non-prod scheduling). Month 9: Conducted Diwali simulation load test at 5x expected load; system handled it gracefully.

Results (Diwali Sale):

• Website handled 15x normal traffic without degradation
• Auto-scaling added 12 instances during peak and removed them after
• CDN served 85% of static content, reducing server load by 70%
• Database read replicas handled 60% of read queries
• Zero downtime during the 7-day Diwali sale period
• Revenue grew about threefold year on year, despite the previous crash
• Customer satisfaction: 95% (up from 60% after the previous crash)
• Cloud cost during Diwali: (optimized with auto-scaling and reserved instances)
• Cost optimization savings: per month through right-sizing and resource scheduling

Investment: (cloud migration, monitoring, caching, load testing, optimization, training)

Key Lesson: Capacity management is not an IT luxury, it is a business imperative for e-commerce. The cost of a capacity failure (lost revenue, reputation, customer churn) far exceeds the cost of proactive capacity planning. Cloud infrastructure, combined with monitoring, auto-scaling, and load testing, makes capacity management accessible to growing companies.

Illustrative Scenario 2: Large Indian Bank, Core Banking Capacity Management

Organization: A public sector bank with 2,000+ branches, 50 million customers, and a core banking system processing 5 million transactions per day Challenge: The bank's core banking system (CBS) was running on aging infrastructure with no capacity planning. The system was at 85% CPU use during normal business hours and frequently hit 95% during month-end and quarter-end. Storage was at 92% capacity with no archiving strategy. Database connection pools were frequently exhausted, causing transaction failures. The bank experienced 12 capacity-related outages in the previous year, with an average outage duration of 3 hours. The RBI audit flagged capacity management as a critical deficiency and required a complete capacity overhaul within 6 months. The bank faced regulatory penalties and potential restrictions on new product launches if not resolved. Before State:

• Core banking system on aging physical servers with no virtualization
• CPU: 85% normal, 95% peak; no headroom for failover
• Memory: 90% use; frequent swapping and slowdowns
• Storage: 92% full; no archiving; backups frequently failed due to space
• Database: 500 max connections, frequently exhausted; no connection pooling
• Network: No monitoring; no QoS; bandwidth unknown
• No capacity planning process; no monitoring; no thresholds
• No load testing; capacity unknown
• Month-end processing took 12 hours (should be 4 hours)
• Failover system had only 50% of production capacity (inadequate for full failover)
• No cloud strategy; all infrastructure on-premise
• Capacity incidents were "managed" by restarting services or adding emergency hardware

Implementation: Phase 1 (Months 1–2): Emergency capacity expansion and monitoring. Added memory, CPU, and storage to critical servers. Implemented complete monitoring (SolarWinds, database monitoring tools). Defined thresholds and alerts. Phase 2 (Months 3–4): Capacity planning framework. Established capacity planning team, methodology, and documentation. Implemented monthly, quarterly, and annual capacity planning cycles. Included business requirements (new products, branch expansion, customer growth) in capacity planning. Phase 3 (Months 5–6): Database optimization. Implemented connection pooling, query optimization, indexing, and archiving. Reduced database connection requirements by 40%. Implemented database partitioning for historical data. Phase 4 (Months 7–8): Storage optimization. Implemented data archiving (transactions older than 2 years moved to archive storage). Implemented storage tiering (hot data on SSD, warm data on HDD, cold data on tape). Freed 30% of primary storage. Phase 5 (Months 9–10): Infrastructure modernization. Migrated non-critical workloads to cloud (AWS for DR, Azure for development). Implemented virtualization for better resource use. Added redundant capacity for failover (100% of production capacity for critical systems). Phase 6 (Months 11–12): Load testing and validation. Conducted load testing for peak scenarios (month-end, quarter-end, tax season). Validated failover capacity. Optimized bottlenecks. Prepared RBI audit documentation.

Results (After 18 Months):

• CPU use: 65% normal, 75% peak (20% headroom maintained)
• Memory use: 60% normal, 70% peak (30% headroom)
• Storage use: 55% (archiving freed 30% space; tiering optimized cost)
• Database connections: 300 average, 400 peak (connection pooling reduced requirements by 40%)
• Month-end processing: 4 hours (down from 12 hours)
• Capacity incidents: 0 in the last 12 months (down from 12)
• Failover capacity: 100% of production for all critical systems
• RBI audit: Passed with no capacity-related findings
• Cloud migration: 30% of non-critical workloads moved to cloud, reducing costs
• Infrastructure costs reduced through right-sizing, virtualisation and archiving

Key Lesson: For large, legacy organizations, capacity management is a transformation journey, not a quick fix. It requires infrastructure modernization, process change, and cultural shift. The RBI's pressure accelerated the transformation, but the benefits (availability, performance, cost, compliance) justified the investment. Capacity management for critical banking systems is not optional, it is a regulatory and business requirement.

Multi-Framework Mapping

ISO 27001:2022 A.8.6 to Other Frameworks

Regulatory and Industry Context

India-Specific Regulatory Requirements

SEBI: the capacity-planning framework for market infrastructure institutions requires installed capacity to be planned against projected peak load with headroom, reviewed periodically and reported; exchanges set capacity and performance requirements for stockbrokers' trading systems. SEBI CSCRF (2024) adds resilience requirements.

RBI: the Master Direction on IT Governance, Risk, Controls and Assurance Practices (2023) expects capacity and performance management for critical systems, and business continuity and DR capacity.

NPCI: UPI participants must meet NPCI's uptime, technical-decline and performance expectations, especially during peaks such as festive seasons.

IRDAI (2023): resilience and business continuity for insurers' core systems.

DPDP Act 2023: loss of access to personal data is a personal data breach (s.2(u)), so capacity failures that destroy or lock up personal data can trigger intimation duties once the Rules apply.

Industry-Specific Context

• BFSI: plan for month-end, quarter-end, tax deadlines and festive peaks; keep DR capacity able to carry production load; follow SEBI and NPCI capacity expectations where they apply.
• Healthcare: imaging storage grows fast; plan storage and network for PACS and telemedicine peaks.
• Government and public portals: deadline-day surges need load testing, queueing and elastic capacity.
• SaaS: use autoscaling with limits and alerts; watch database connections and noisy neighbours; publish capacity-related incidents honestly.

Roles and Responsibilities (RACI)

Documentation and Evidence Requirements

Continuous Improvement

Figure · Tiers

Maturity levels for capacity management

Maturity Model for A.8.6

Continuous Improvement Activities

Monthly:

• Capacity use review and trend analysis
• Capacity incident analysis and remediation tracking
• Right-sizing and resource cleanup
• Cloud cost review and optimization
• Capacity report generation and distribution
• Monitoring threshold review and adjustment

Quarterly:

• Capacity planning cycle (forecast, budget, recommendations)
• Database capacity review and optimization
• Application capacity review and load testing
• Peak load planning for upcoming events
• Failover capacity testing
• Internal audit of capacity management

Annually:

• Full policy review
• Complete capacity risk assessment
• Long-term capacity plan update (12–24 months)
• Technology and tool evaluation
• Benchmark against industry best practices
• External audit preparation
• Maturity assessment against target level
• Budget planning for capacity investments

Trigger-Based:

• After any capacity-related incident (outage, performance degradation, resource exhaustion)
• Upon business change (new product, new client, expansion, acquisition)
• Upon infrastructure change (migration, upgrade, new technology)
• Upon significant cloud cost variance (>20% from budget)
• After significant audit findings
• Upon regulatory change

FAQ

Q1: What is the difference between capacity management and performance management? A: Capacity management is about ensuring you have enough resources to meet demand. Performance management is about optimizing how efficiently those resources are used. Capacity management asks: "Do we have enough?" Performance management asks: "Are we using it well?" They are related but distinct. You can have adequate capacity but poor performance (inefficient code), or you can have good performance but inadequate capacity (out of resources). Both are needed for optimal system operation.

Q2: How often should we conduct capacity planning? A: Capacity planning should be a continuous activity with formal cycles: Monthly (short-term, next 3 months), Quarterly (medium-term, next 6–12 months), Annually (long-term, next 12–24 months). Additionally, capacity planning must be triggered by: new projects, business changes, technology changes, capacity incidents, and audit findings. The frequency depends on your organization's dynamism, rapidly growing companies need monthly planning; stable organizations can plan quarterly.

Q3: What is the optimal resource use target? A: There is no single optimal number, it depends on the resource type and criticality. General guidelines: CPU: 60–75% (leave headroom for spikes), Memory: 60–75% (avoid swapping), Disk: 60–80% (leave room for growth and defragmentation), Network: 60–70% (leave room for bursts), Database connections: 60–75% (leave room for connection storms). Critical systems should run at lower use (50–60%) to ensure resilience. Non-critical systems can run at higher use (70–80%). The key is maintaining enough headroom for unexpected demand while avoiding wasteful over-provisioning.

Q4: How do we handle capacity planning for unpredictable demand (e.g., viral content, sudden news events)? A: Unpredictable demand is challenging but manageable: (1) Use cloud auto-scaling for elasticity, (2) Implement CDN for content delivery (reduces origin load by 80–90%), (3) Use caching layers to reduce backend demand, (4) Implement circuit breakers and graceful degradation (limit non-essential features during high load), (5) Plan for 5x–10x baseline capacity in cloud, (6) Use serverless functions for variable workloads, (7) Monitor social media and news for early warning of demand spikes, (8) Implement load shedding to prioritize critical transactions. You cannot predict viral events, but you can build systems that scale elastically.

Q5: Should we buy on-premise hardware or use cloud for capacity? A: The answer depends on your workload patterns: On-premise is better for: predictable, steady-state workloads (you know the demand and it doesn't change much); regulatory requirements that mandate data location; very high, consistent use (cheaper than cloud at high use); existing sunk costs in data centers. Cloud is better for: variable, unpredictable workloads; rapid growth; seasonal spikes; need for geographic distribution; desire for auto-scaling and elasticity; cost optimization through right-sizing; disaster recovery. Many organizations use hybrid: on-premise for baseline, cloud for variable and peak load. Evaluate both options based on workload characteristics, cost, and strategic goals.

Q6: How do we manage capacity for legacy systems that cannot scale? A: Legacy systems that cannot scale require creative solutions: (1) Optimize the application (code, database, caching) to reduce resource demand, (2) Use load balancing and reverse proxies to distribute load, (3) Implement caching layers to reduce legacy system load, (4) Migrate data or functions to modern systems that can scale, (5) Use queueing systems to smooth demand spikes, (6) Implement graceful degradation (disable non-essential features during peak), (7) Plan for capacity limits and communicate them to business stakeholders, (8) Develop a modernization roadmap to replace the legacy system. If a legacy system truly cannot scale, you must either limit demand or modernize, there are no other sustainable options.

Q7: What is the most common audit finding for A.8.6? A: The most common findings are: (1) No capacity planning process, "we add resources when things break," (2) No capacity monitoring, no visibility into use, (3) No use thresholds or alerts, no proactive warning of capacity issues, (4) No documentation of capacity baseline or forecasts, (5) No load testing, applications deployed without capacity validation, (6) No cloud cost optimization, significant over-provisioning and waste, (7) No peak load planning, systems crash during predictable peak periods. Auditors will check monitoring dashboards, capacity plans, incident records, and load test results.

Q8: How do we manage capacity for a multi-tenant SaaS application? A: Multi-tenant SaaS capacity management is complex: (1) Plan capacity for the aggregate of all tenants (not just the largest), (2) Implement tenant-level resource quotas to prevent one tenant from consuming all capacity, (3) Use auto-scaling to handle tenant growth, (4) Monitor per-tenant use to identify noisy neighbors, (5) Implement tiered service levels (premium tenants get more capacity), (6) Plan for tenant onboarding spikes (new tenants may import large data sets), (7) Use database multi-tenancy strategies (shared schema, separate schema, separate database) with appropriate capacity planning for each, (8) Implement rate limiting per tenant to prevent API abuse. Multi-tenant capacity management requires both aggregate and per-tenant planning.

Q9: What is the cost of implementing A.8.6 for a growing company? A: Mostly effort rather than licences. Open-source monitoring (Prometheus, Grafana) and load testing (JMeter, Gatling, k6) cover many needs; cloud providers' native cost and capacity tools are included. The main costs are engineering time, extra capacity where tests show gaps, and on-call cover so you are not dependent on one person.

Q10: How do we manage capacity for disaster recovery and business continuity? A: DR capacity planning ensures you have adequate resources when primary systems fail: (1) DR site must have 100% capacity to handle full production load (not just a subset), (2) DR capacity must be tested during DR drills (not just assumed), (3) Network capacity to DR site must support failover traffic, (4) Storage capacity for DR must include growth and backup retention, (5) Database replication must not overwhelm DR database capacity, (6) Cloud DR (warm standby, pilot light) must be capacity-planned for rapid scale-up, (7) DR capacity must be reviewed quarterly as production capacity grows. DR capacity is not a secondary concern, it is primary capacity that happens to be used only during emergencies.

Q11: What is the role of FinOps in capacity management? A: FinOps (Financial Operations) is the practice of managing cloud costs with financial accountability. It is closely related to capacity management: (1) FinOps provides cost visibility that informs capacity decisions, (2) Capacity right-sizing is a FinOps activity, (3) Reserved instance planning is both capacity and FinOps, (4) Resource tagging for cost allocation is a FinOps practice that supports capacity tracking, (5) FinOps teams and capacity teams should collaborate on cloud optimization. In cloud environments, capacity management and FinOps are intertwined, you cannot manage capacity without managing cost, and you cannot manage cost without managing capacity.

Q12: How do we handle capacity for big data and analytics workloads? A: Big data workloads have unique capacity characteristics: (1) They are batch-oriented and bursty (high resource usage during processing, idle otherwise), (2) Storage grows exponentially (data lakes, data warehouses), (3) Compute is often decoupled from storage (cloud data warehouses like Snowflake, BigQuery), (4) Capacity planning must account for batch windows (ETL jobs must complete within time windows), (5) Use elastic compute resources (auto-scaling clusters, serverless) for batch processing, (6) Plan storage tiering (hot, warm, cold) for cost optimization, (7) Monitor data growth rates and plan storage expansion, (8) Use data compression and partitioning to reduce storage and compute needs. Big data capacity planning requires understanding workload patterns, not just average use.

Q13: What is the difference between horizontal and vertical scaling, and when should we use each? A: Vertical scaling (scale up) adds more power (CPU, RAM) to an existing server. It is simpler but has limits (maximum server size) and creates single points of failure. Horizontal scaling (scale out) adds more servers to distribute the load. It is more complex but provides unlimited scalability, better resilience optimization. Use vertical scaling for: stateful applications that cannot be distributed, quick temporary fixes, databases that are difficult to shard. Use horizontal scaling for: stateless web applications, microservices, cloud-native applications, and when you need high availability and resilience. Modern architectures favor horizontal scaling for most components.

Q14: How do we manage capacity for IoT and edge computing? A: IoT and edge computing have distributed capacity challenges: (1) Edge devices have limited CPU, memory, and storage, plan for lightweight processing, (2) Network capacity from edge to cloud must handle data ingestion bursts, (3) Cloud capacity must handle data aggregation, analytics, and storage, (4) Plan for device growth (number of devices, data volume per device), (5) Implement edge caching and filtering to reduce cloud capacity demand, (6) Use MQTT or similar lightweight protocols to reduce network capacity, (7) Plan for firmware updates (bandwidth and device capacity during updates), (8) Monitor edge device capacity (CPU, memory, storage) remotely. IoT capacity management spans edge, network, and cloud, all must be coordinated.

Q15: What is the relationship between capacity management and green IT / sustainability? A: Capacity management directly impacts sustainability: (1) Over-provisioned servers consume unnecessary power and cooling, (2) Right-sizing reduces energy consumption, (3) Cloud migration to efficient data centers reduces carbon footprint, (4) Resource scheduling (shutting down non-production environments) saves energy, (5) Storage tiering moves cold data to low-energy storage, (6) Virtualization and containerization improve resource use and reduce physical server count. Capacity management is not just about cost and availability, it is also about environmental responsibility. Efficient capacity management is green IT.

References and Further Reading

Standards and Frameworks

• ISO/IEC 27001:2022, Information Security, Cybersecurity and Privacy Protection, Information Security Management Systems, Requirements
• ISO/IEC 27002:2022, Information Security, Cybersecurity and Privacy Protection, Information Security Controls
• NIST SP 800-53 Rev 5, Security and Privacy Controls for Information Systems and Organizations
• ITIL 4: Capacity Management Practice Guide
• COBIT 2019, Control Objectives for Information and Related Technologies

Indian Regulations

• RBI Cyber Security Framework for Banks
• SEBI Cybersecurity and Cyber Resilience Framework (CSCRF) for SEBI Regulated Entities, circular of 20 August 2024
• Information Technology Act, 2000 (as amended)
• Digital Personal Data Protection Act, 2023 (India)

Books and Publications

• ISO 27001/27002: A Pocket Guide by Alan Calder
• ITIL 4: Capacity Management Practice (AXELOS)
• The Art of Capacity Planning by Arun Kejariwal and Lee Atchison
• Cloud FinOps by J.R. Storment and Mike Fuller
• Site Reliability Engineering by Google (SRE Book)