---
title: "ISO 27001 capacity management (Annex A 8.6) for cloud teams"
canonical: https://www.grcmana.io/vault/iso-27001/annex-a-8-6-capacity-management
published: 2023-06-16
updated: 2026-10-07
author: "Harry West"
framework: "ISO 27001"
control: "A.8.6 Capacity management"
journeyStage: implementation
---

# ISO 27001 capacity management (Annex A 8.6) for cloud teams

## Key takeaways

Annex A 8.6 is an availability and SLA discipline that a cloud-native firm can prove with telemetry it already runs. Set 80% thresholds with named owners, turn every alert into a ticket, and cut demand before paying to scale. A short quarterly review beats a 30-page plan nobody updates.

- **Scope** — Annex A 8.6 covers compute, storage, bandwidth, cloud quotas, licences, people and facilities, so defining capacity as servers alone misses the constraint most likely to stop you.
- **Working threshold** — An 80% utilisation trigger with a named owner, set on existing monitoring such as CloudWatch or Azure Monitor, is the working pattern. Every alert that fires must open a ticket.
- **Demand-side levers** — Purging data past retention, decommissioning idle environments, tuning heavy queries and archiving cold storage free headroom more cheaply than scaling, and each action leaves evidence auditors can sample.
- **Audit grading** — Certification bodies typically grade absent monitoring on critical systems, or repeated outages with no management response, as major. An unactioned alert or missing forecasting usually grades minor.

The database disk fills over a bank holiday weekend. Nobody attacked you, yet the SLA breach lands on your desk, and the next enterprise questionnaire asks how you manage resource headroom. This guide covers ISO 27001 capacity management for cloud-native teams of 25–250 people: what Annex A 8.6 asks for, how to evidence it with telemetry you already run, and what auditors sample.

It is written for CTOs, heads of infrastructure and GRC leads who want a control that satisfies an auditor without ITIL-grade paperwork.

## What does ISO 27001 Annex A 8.6 require?

ISO 27001 Annex A 8.6 requires you to track how your critical systems use resources and keep that use ahead of current and expected demand. The scope runs beyond servers: compute, storage, bandwidth, licences, people and facilities all count. You need known thresholds, a named owner and forecasting that plans for growth rather than discovering limits in production.

In plain English, the control asks three things of you:

- **Know** what your critical services consume, and what would stop them if it ran out.
- **Watch** usage against thresholds that fire before users feel pain.
- **Plan** for growth, so limits surface in a review rather than in an incident.

The guidance behind the control recognises two levers. You can add resources, or you can cut demand by deleting, decommissioning and tuning what you already run. Both count, and the second is usually the cheaper one.

A.8.6 sits beside Annex A 8.14 on redundancy, and it shares its telemetry with the monitoring that Annex A 8.16 requires.

The common pitfall is defining capacity as servers. The constraint that actually bites is usually the cloud API quota, the licence cap or the one engineer who holds the pager.

## Why is capacity management an information security control?

Capacity is a security control because exhaustion damages integrity and confidentiality, not only availability. Full disks truncate writes, crashing databases lose transactions, and scarcity pushes data onto unmanaged overflow locations outside your controls. A.8.6 therefore pairs preventive forecasting with detective threshold monitoring that signals trouble in time to act.

Availability is still the sharpest edge. For a firm selling to regulated buyers, capacity is really an SLA conversation. The breach that costs you rarely looks like a security event; more often it is the traffic spike from a large client onboarding.

Exhaustion can also be hostile. The [NCSC guidance on understanding service resource exhaustion](https://www.ncsc.gov.uk/collection/denial-service-dos-guidance-collection/preparing-denial-service-dos-attacks1/understand-your-service) describes how an attacker can fill storage by forcing heavy log writes or flooding upload routes, causing an outage or a cascade into other parts of the system. What an attacker does on purpose, a busy week can do by accident.

Buyers' due-diligence teams read a mature capacity story as evidence that you can be relied on at their scale. A threshold, an owner and a quarterly review note answer that questionnaire row more convincingly than a paragraph of policy.

## Where does capacity really run out: cloud quotas and key people?

Cloud capacity is finite: NCSC guidance notes services only appear to have infinite capacity, and providers limit how many instances you can start. Auto-scaling handles routine fluctuation but not the control. You still own the quotas, scaling ceilings and budget alarms, and a single platform engineer is a capacity risk too.

The [NCSC guidance on preparing for Denial of Service attacks](https://www.ncsc.gov.uk/collection/denial-service-dos-guidance-collection/preparing-denial-service-dos-attacks1/scaling) makes the point plainly. Instance limits can need a manual request to the provider, so ask well before a launch rather than during an incident. It also advises deciding in advance the point at which you would rather offer a reduced service than keep paying to scale.

In the cloud the failure mode inverts. You rarely run out of capacity; you overspend. Orphaned resources and unpurged data keep billing quietly, while a quota you never knew existed takes you down at the worst moment.

Auto-scaling is a budget decision disguised as an engineering feature.

Map the constraints that can stop a regulated service, including the ones that never appear on an infrastructure diagram:

- **Cloud quotas and ceilings:** instance limits, API rate limits, database connections and the maximum your scaling policy allows.
- **Spend:** budget alarms, plus a cost ceiling at which the service degrades rather than scales.
- **People:** the platform engineer who alone can deploy or restore. A second person needs access and a runbook.
- **Third parties:** the payment, identity or SaaS provider whose own limits cap your throughput.

The [FCA Operational Resilience insights and observations](https://www.fca.org.uk/firms/operational-resilience/insights-observations) expect regulated firms to identify and document the people, processes, technology, facilities and information behind each important business service. If your customers are FCA-regulated, the same map answers their dependency questions.

Treat a single-person dependency as a finding you have already noticed. An auditor will expect you to have spotted it, and the fix is a cross-training or documentation action recorded in your capacity review, not a nod in the meeting.

## How do you implement ISO 27001 capacity management with 80% thresholds?

Start by setting an 80% utilisation threshold, with a named owner, on the monitoring your platforms already include, such as CloudWatch, Azure Monitor or your APM tool. Then close the loop: every alert that fires opens a ticket and leaves a trace. In a cloud-native estate that is days of effort, then hours per quarter.

Work through it in this order:

1. **List what constrains critical services.** Start from the systems your risk assessment and continuity analysis already name as business-critical. Record compute, storage, database connections, bandwidth, cloud quotas, API rate limits, licence counts and single-person dependencies. Facilities join the list only if you run your own kit or premises matter to delivery.
2. **Set thresholds and owners.** Give each constraint an 80% trigger and one named person. The NCSC's denial-of-service guidance gives the same advice for storage: raise alerts before the problem becomes critical. The gap at this scale is almost never tooling. It is nobody owning the alert.
3. **Close the alert-to-action loop.** An alert that fires must produce an action and leave a trace. A ticket is enough.
4. **Forecast lightly but genuinely.** Once a quarter, compare your usage history with the sales pipeline and the growth plan. Pay most attention to anything that takes a long time or serious money to expand. A page of notes from that review is credible evidence.

Two failures are worth designing out from the start. Alert theatre is thresholds firing into a muted Slack channel, which produces perfect evidence that warnings existed and nobody acted. Auditors find it in minutes. Pure reactivity is the other: the first signal that the disk was low is the incident that filled it.

The effort is front-loaded and small. Because the evidence this control generates is continuous and cheap, it is a sensible early-programme win. It also strengthens the availability story that your redundancy work depends on.

## How do you free headroom without paying to scale?

Free headroom by cutting demand before buying supply. Purge data past its retention period, decommission environments and VMs nobody uses, tune the queries and batch jobs everyone complains about, and archive cold storage. Each action is cheaper than scaling, and each leaves a minuted trace that auditors like to see.

Each lever targets a different leak and leaves a different artefact:

- **Retention purges** reclaim storage and close the data-retention question at the same time. The purge log is the evidence.
- **Decommissioning** removes idle environments and VMs that still bill and still need patching. A decommissioning record shows who approved it.
- **Query and batch tuning** lowers load on the busiest components. A ticket with a before-and-after metric proves the gain.
- **Cold-storage archiving** moves rarely used data to cheaper tiers. The archive run shows what moved and when.

Storage grows forever because deleting needs a decision and expanding only needs a credit card.

Left alone, that habit produces a data-retention finding and a large cloud bill at the same time. A scheduled deletion job takes the decision out of someone's backlog, and the review meeting only has to ask what the jobs reclaimed last quarter.

## Who should be allowed to resize infrastructure or change quotas?

Only named, authorised staff should resize infrastructure, alter provider quotas or delete data, and each of those operations should sit behind MFA and your normal access rules. These levers are privileged: a mistaken or malicious change can cause the very exhaustion or data loss the control exists to prevent.

In practice, three settings make the guardrail real:

- **A dedicated role.** Put resize, quota and delete permissions in one cloud role granted to named people, rather than in every engineer's everyday access.
- **MFA at the point of use.** Require a fresh MFA check to take on that role, so an everyday session cannot resize or delete without a second check.
- **A trail on both sides.** The change ticket records why, and the provider's activity log, such as AWS CloudTrail or the Azure Activity Log, records who and when.

Scheduled purge and sweep jobs need the same scrutiny. A job with delete rights acts like an administrator, so review its scope and permissions on the same cycle as human admin accounts.

## Do you need a standalone capacity management policy?

No, not at 25–250 people. A section in your operations or security procedures that names the metrics, thresholds and owners is enough, and it stands up at audit. A dedicated capacity plan earns its keep only for a genuinely mission-critical platform with hard SLAs, where a short plan and a pre-launch load test make peak behaviour known rather than assumed.

A 30-page capacity plan nobody updates is evidence of intent, not of a control.

A workable capacity management policy section fits on one page and names:

- the metrics you watch for each critical service;
- the thresholds that trigger an alert;
- the owner for each alert;
- the escalation route when the owner does not respond;
- the review cadence and who convenes it.

ITIL-grade capacity frameworks tend to collapse under their own reporting weight by the second quarter at 50 people. Documentation drift is the quieter risk. Baselines written for the audit and never revised as the architecture changed end up contradicting your dashboards, and a procedure the dashboards contradict is a minor finding waiting to happen.

## What do auditors sample for Annex A 8.6, and what grades as a major?

Auditors ask for a live look at your monitoring dashboard, pick a past alert and trace it to the action taken, then request your latest capacity review notes. Grading follows the pattern: no monitoring on critical systems, or repeated outages with no management response, grades major; an unactioned alert or missing forecasting grades minor.

Expect questions in this shape:

- Which resources would take your service down if they ran out, and where is that list?
- Show me the alert that fires before storage fills up. What happened the last time it fired?
- How do you know capacity covers the growth your sales plan assumes?
- What do you do to reduce demand, not just add resources? Show me a recent example.
- Who else can run this platform if your lead engineer is off for a month?

The auditor will also probe the non-obvious dimensions: a cloud quota, a licence ceiling, a key-person dependency. The test is whether your definition of capacity is wider than disks. Where you claim peak performance, expect a request for the load test on the critical application.

Certification-body practice on grading is consistent enough to plan around:

- **Major:** no monitoring at all on business-critical systems, or repeated capacity-driven outages with no management response.
- **Minor:** an unactioned alert, missing forecasting evidence, or a procedure the dashboards contradict.
- **Minor aggregating to major:** a pattern of ignored alerts that shows the control is not operating.

Walk in with one real alert traced from threshold to ticket to resolution, plus the last review note. That pair answers most of the sample before the auditor reaches the harder questions.

## How do you automate capacity evidence with thresholds-as-code?

Capacity is telemetry-native, so the engineering is wiring what exists into evidence. Thresholds live as code in your infrastructure repository, alerts open tickets automatically, scheduled jobs purge and sweep, and a generated pack starts each quarterly review. The work itself produces the audit evidence, and the cost line is one the CFO notices.

The split of work is the point: the machine gathers, and the humans forecast and decide. Start with the alert-to-ticket link, because it turns the evidence auditors sample hardest into a by-product of normal operations. Move thresholds into code the next time the alert rules change.

This is the kind of build GRCMANA's GRC engineering work delivers on top of the telemetry you already run. The table maps each artefact to its source and to the auditor question it answers.

| Evidence artefact | Where it comes from | Auditor question it answers |
| --- | --- | --- |
| Threshold definitions | Alert rules in the infrastructure repository, with diff history | What do you monitor, and at what level? |
| Alert-to-action trail | Tickets opened automatically by capacity alerts | What happened the last time it fired? |
| Demand-reduction log | Scheduled purge, sweep and idle-shutdown jobs | What do you do to reduce demand? |
| Quarterly review pack | Generated trend graphs, quota headroom and budget-alarm status | How do you know capacity covers growth? |

## Frequently asked questions

### Who should own A.8.6 capacity management in a 50-person firm?

Whoever owns operations: a Head of Infrastructure, the platform lead or, at a smaller firm, the CTO. The audit-relevant point is a name, not a title. Put that name in the procedure and in the alert routing, and update both when the person changes role.

### What changed for capacity management in ISO 27001:2022 compared with 2013?

Less than the renumbering suggests. The control moved from A.12.1.3 to A.8.6, and its core is the same: watch how resources are used, adjust them and plan for future demand. The 2013 guidance already offered two routes, adding capacity or reducing demand. If you are carrying a 2013-era procedure across, update the reference and check that it covers provider quotas and scaling ceilings, which procedures written for on-premises kit often miss.

### How often should capacity be reviewed for A.8.6?

Monitoring runs continuously, and the forecasting review runs quarterly. Add an out-of-cycle review before a major launch or a large client onboarding, when growth can outrun the plan. Add one after an architecture change, such as a database migration, because the old baselines no longer describe the system. Keep the notes from each review, even if they are one page.

### Is an alert in a Slack channel enough evidence for A.8.6?

Not on its own. Slack can carry the notification, but the evidence is the record behind it. Route each capacity alert through an integration that opens a ticket automatically, showing the alert and its time, who acknowledged it and what changed before it closed. That record is what the auditor follows when they pick a past alert.

### Does A.8.6 cover office space and facilities for a remote-first company?

Yes, but the entry is short. For a remote-first firm with no kit of its own, the data-centre side sits with your cloud provider, and you rely on its assurance under your supplier and cloud-service controls, such as A.5.23. What remains is the capacity your people depend on every day: remote-access concurrency, SaaS seat licences and laptop stock for new joiners. Record those in the same review, with one line explaining why physical facilities are out of scope.