Compliance Framework Alignment
ISO/IEC 27001:2022 — Annex A 8.6 (Capacity management) ISO/IEC 27002:2022 — Control 8.6 (implementation guidance) SOC 2 (AICPA TSC) — Availability criterion A1.1 (monitoring and evaluation of current processing capacity and system-component use to manage capacity demand) SOC 2 (AICPA TSC) — Availability criteria A1.2 & A1.3 (recovery infrastructure and recovery testing — cross-referenced via RTO/RPO and the BCP) CERT-In Directions, 2022 & DPDP Act, 2023 (India) — availability-affecting incidents where a capacity shortfall causes an outage This Policy is the topic-specific policy evidencing the capacity-management control at ISO/IEC 27001:2022 Annex A 8.6, whose objective is that the use of resources is monitored and adjusted in line with current and expected capacity requirements. It also supports the SOC 2 Availability criterion A1.1, under which the entity maintains, monitors, and evaluates current processing capacity and use of system components to manage capacity demand and to enable additional capacity to be provisioned. Certification / attestation requires operating evidence (monitoring dashboards, forecast reports, threshold-alert records, scaling and tuning change tickets) — not the policy alone.
ACME TECHNOLOGIES PVT LTD CAPACITY MANAGEMENT POLICY Aligned with ISO 27001:2022 A.8.6 & SOC 2 Availability A1.1
Effective Date [Effective Date]
Review Date [Review Date]
Framework Alignment ISO 27001:2022 A.8.6 & SOC 2 Availability A1.1
Alert Thresholds Warning 70% · Critical 85%
RTO / RPO Targets RTO 4h · RPO 1h
Capacity Owner Vikram Patel
Escalation sre@company.com 1. Purpose and Scope
This Capacity Management Policy ("Policy") establishes how Acme Technologies Pvt Ltd monitors, forecasts, tunes, and scales the resources that underpin its cloud / elastic systems so that the required capacity is available to meet current and expected demand without service degradation or outage. It applies to compute (CPU, memory, container and function concurrency), storage (block, object, database and file capacity, together with input/output throughput), network (bandwidth, connections, and load-balancer capacity), and personnel capacity (the people who operate and support the service). It applies to all production information-processing facilities, and to all employees, contractors, and third-party service providers who provision or operate capacity on the Company's behalf. This Policy is the topic-specific capacity-management control required by ISO/IEC 27001:2022 Annex A 8.6 and evidences SOC 2 Availability criterion A1.1.
2. Capacity Management Objectives
The objectives of capacity management are to: (a) ensure information-processing resources are monitored and adjusted in line with current and expected requirements; (b) prevent availability and performance incidents caused by resource exhaustion (for example, a full disk, saturated CPU, exhausted database connections, or bandwidth saturation); (c) provision capacity efficiently, avoiding both shortfall and wasteful over-provisioning; (d) forecast future demand and plan lead-time procurement or reservation of capacity; and (e) protect the Company's availability commitments — including 99.9% monthly and the recovery objectives in Clause 10 — as demand grows.
3. Capacity Monitoring
The use of all in-scope resources shall be continuously monitored and recorded, so that current utilisation is measurable at all times as required by SOC 2 A1.1: (a) Compute — CPU and memory utilisation, container/pod resource use, function concurrency, and request queue depth; (b) Storage — disk and volume usage, object-store growth, database size and connection-pool usage, and input/output operations and latency; (c) Network — inbound and outbound bandwidth, connection counts, packet loss, and load-balancer and gateway limits; (d) Personnel — the availability, on-call coverage, and workload of the teams that operate and support the service, so that human capacity is treated as a managed resource alongside infrastructure. Monitoring shall cover application-level indicators (response time, throughput, error rate, and saturation) as well as infrastructure metrics, with metrics retained long enough to support the trend analysis in Clause 4.
4. Forecasting and Trend Analysis
Historical utilisation data shall be analysed to identify growth trends, seasonality, and demand peaks, and to forecast future capacity requirements quarterly across compute, storage, network, and personnel. Forecasting shall account for known business events (for example, product launches, marketing campaigns, onboarding of large customers, and period-end processing) that materially change demand. Forecasts shall factor in procurement, reservation, or provisioning lead times so that additional capacity can be secured before it is needed, and shall be documented and reviewed with the resource owners and with management as part of the capacity-review cycle in Clause 9.
5. Capacity Thresholds and Alerting
Utilisation thresholds shall be defined for every in-scope resource so that action is triggered well before capacity is exhausted. As a baseline, a Warning threshold of 70% sustained utilisation and a Critical threshold of 85% sustained utilisation shall apply, with resource-specific thresholds set where the baseline is unsuitable (for example, tighter thresholds for storage that cannot be expanded instantly). Breaching a threshold shall automatically generate an alert to sre@company.com . Warning alerts prompt planning and tuning; Critical alerts require immediate remediation to restore headroom. Alert rules and thresholds shall be reviewed periodically to keep them meaningful and to minimise both missed conditions and alert fatigue.
6. Capacity Thresholds — Baseline Matrix
The following baseline thresholds and responses apply per resource type. Resource owners may set stricter values in the capacity plan; values here are the default minimum baseline and are illustrative of the alerting and action model, not exhaustive.
Resource Key metric(s) Warning (70%) Critical (85%) Primary response Compute CPU, memory, concurrency 70% sustained 85% sustained Auto-scale out; tune workload Storage Disk / volume / DB size, IOPS 70% of capacity 85% of capacity Expand volume; archive / tier cold data Network Bandwidth, connections, LB limits 70% of limit 85% of limit Raise limits / add nodes; enable caching / CDN Personnel On-call coverage, workload Coverage gap forecast No cover / overload Adjust rota; recruit / re-prioritise
7. Tuning and Optimisation
Before adding capacity, the Company shall consider whether demand can be met by tuning and optimisation, so that capacity is used efficiently: (a) database and query optimisation, indexing, and connection-pool tuning; (b) caching, content-delivery, and compression to reduce compute and bandwidth load; (c) archival or tiering of cold data and removal of redundant data to reclaim storage; (d) code and configuration changes that reduce per-request resource cost; and (e) decommissioning of unused or idle resources. Tuning actions shall be tracked as changes and their effect on utilisation verified against the monitoring in Clause 3, so that the benefit is measured rather than assumed.
8. Scaling and Auto-Scaling
Where tuning is insufficient, capacity shall be scaled to meet demand. Elastic auto-scaling shall be configured for suitable cloud / elastic workloads to add or remove compute and, where supported, storage and throughput automatically in response to demand signals such as CPU, memory, queue depth, or request rate. Auto-scaling shall be bounded by minimum and maximum limits so that scaling protects availability while remaining within budget and provider quotas, and scaling events shall be logged and reviewed. Where auto-scaling cannot fully absorb a spike (for example, provider quota, database, or licensing limits), manual or scheduled scaling and the escalation in Clause 5 apply. Vertical scaling (larger instances) and horizontal scaling (more instances) shall both be available where the architecture allows, and provider quotas and reserved-capacity limits shall be tracked so they do not silently cap scaling.
9. Capacity Planning and Headroom
A capacity plan shall be maintained for critical systems and reviewed monthly, drawing on the monitoring (Clause 3) and forecasts (Clause 4). The plan shall maintain a minimum planned headroom of 25% spare capacity above expected peak demand for each critical resource, so that unexpected surges, node failures, and failover of workloads between availability zones or sites can be absorbed without breaching thresholds. Capacity risks — resources trending toward exhaustion, forecast shortfalls, or single points of contention — shall be reported to management, prioritised, and remediated with a documented owner and target date.
10. Linkage to Availability, RTO/RPO and Business Continuity
Capacity management directly supports the Company's availability commitments and its Business Continuity Plan (BCP). Sufficient capacity — including the headroom in Clause 9 — shall be maintained not only for normal operation but also for degraded and failover conditions, so that when workloads fail over between availability zones, regions, or sites, the surviving capacity can carry production load within the target Recovery Time Objective (RTO) of 4 hour(s) and Recovery Point Objective (RPO) of 1 hour(s), and continue to meet 99.9% monthly . Recovery and failover environments shall be sized against the same forecasts as production, and capacity assumptions shall be validated during business-continuity and disaster-recovery testing so that a recovery site is not itself capacity-constrained when invoked. A capacity shortfall that causes or threatens an outage shall be handled as an availability incident under the Company's incident-response and business-continuity procedures, including any applicable CERT-In (6-hour) and DPDP Act reporting where an outage affects personal data.
11. Roles, Responsibilities, and Reporting
Vikram Patel is accountable for capacity management under this Policy and is the escalation point at sre@company.com . Responsibilities include maintaining monitoring and alerting, producing and reviewing forecasts, maintaining the capacity plan and headroom targets, and coordinating tuning and scaling actions with system owners. Capacity status — current utilisation against thresholds, forecast versus available capacity, and any capacity risks or breaches — shall be reported to the CISO / management on a regular basis and used to drive continual improvement of the availability and capacity programme.
12. Policy Compliance and Review
Compliance with this Policy is mandatory for all Personnel and service providers involved in provisioning or operating capacity. Non-compliance may result in disciplinary action. This Policy shall be reviewed at least annually, and additionally after any significant capacity-related incident, major architecture or demand change, or a change in availability commitments. The next scheduled review date is [Review Date]. Approved changes shall be version-controlled and communicated to affected Personnel.
This Capacity Management Policy has been approved by the management of Acme Technologies Pvt Ltd and is effective from [Effective Date].
CISO / CTO (Approver)
Approver (CISO / CTO name)
______________________
Capacity / Availability Owner
Vikram Patel
______________________