ISO Compliance Insights & Best Practices
CART
ISO Compliance Insights & Best Practices
ISO 27001 capacity management is Annex A control 8.6, and it is the control most teams read as an infrastructure housekeeping task when the standard wrote it as an availability control with a people limb and a facilities limb attached. The control text asks you to monitor and adjust the use of resources in line with current and expected capacity requirements. Nothing in that sentence says disk space.
This guide covers what ISO 27001 capacity management actually requires under A.8.6, the two directions the 2022 edition gives you for meeting it, the demand-side options most implementations ignore, the way a capacity failure quietly disables three or four other controls, and the evidence an auditor will accept. It also flags the frequencies and documents that vendor blogs invent and the standard never states.
Free gap assessment
Where do you actually stand against ISO 27001?
Score every management system clause and all 93 Annex A controls, free, and get a prioritised gap list back.
Run the free ISO 27001 gap assessment → or View premium report sample
A.8.6 sits in the technological controls theme of the 93 Annex A controls in ISO 27001:2022. It is not one of the eleven controls introduced in the 2022 edition — it maps one-to-one from A.12.1.3 in ISO/IEC 27001:2013, which carried the same title. If you certified against the 2013 edition, you already had this control; what changed is the guidance in ISO/IEC 27002:2022, which dropped the old prescriptive direction on expanding capacity and replaced it with a menu of options on both sides of the equation.
The control is classed as both preventive and detective, which is unusual and worth pausing on. Preventive, because planning capacity ahead of demand stops the outage. Detective, because monitoring utilisation is how you find out you are approaching a limit at all. An implementation with thresholds and alerts but no forward projection satisfies only half of it, and so does a capacity plan written once at the start of the financial year and never compared against actuals. Done properly, ISO 27001 capacity management produces both an alert when a resource is filling and a decision made before it does.
| Item | What A.8.6 says |
|---|---|
| Theme | Technological (A.8), one of 34 controls in that theme |
| Control type | Preventive and detective |
| Primary property | Availability — a capacity breach is an availability incident |
| 2013 predecessor | A.12.1.3 Capacity management (one-to-one mapping) |
| New in 2022? | No. The eleven new controls are A.5.7, A.5.23, A.5.30, A.7.4, A.8.9, A.8.10, A.8.11, A.8.12, A.8.16, A.8.23 and A.8.28 |
| Documented information required | None named by the control |
| Frequency stated | None |
The purpose clause in ISO/IEC 27002:2022 names four things whose capacity has to be adequate: information processing facilities, human resources, offices, and other facilities. The implementation guidance goes further and tells managers to use capacity information to identify and avoid dependency on key personnel, because that dependency is a threat to the security of systems and services.
That is the single most-missed limb of ISO 27001 capacity management, and it is the one an auditor can test in about four minutes. If one engineer is the only person who can restore the primary database, patch the firewall estate, or approve a privileged access request, you have a capacity finding and not merely a resourcing grumble. The same logic reaches the office: if the only room that can hold a secure destruction bin is full, or the comms room has no spare rack units and no power headroom, those are capacity constraints with security consequences.
Treat A.8.6 as covering three domains and the control stops looking thin:
| Domain | Typical capacity measure | Security consequence when it runs out |
|---|---|---|
| Information processing | Storage, CPU, memory, database connections, licence seats, log volume, bandwidth | Outage, dropped logs, failed backups, degraded monitoring |
| Human resources | Named cover per critical task, on-call depth, review backlog, open headcount | Single points of failure, unreviewed access, slipped patch windows |
| Offices and facilities | Rack units, power and cooling headroom, secure storage, destruction capacity | Equipment sited insecurely, records retained past retention, physical controls bypassed |
Free ISO 27001 risk assessment
Which of your risks sit above your appetite line?
Set your own risk criteria, pick from 61 information security risk scenarios, rate likelihood and impact, and decide how to treat each one. You get a heat map, a process score and the findings an auditor would raise, free.
Run the free risk assessment → or View premium report sample
ISO/IEC 27002:2022 is explicit that sufficient capacity can be achieved either by increasing capacity or by reducing demand. Most implementations only ever do the first, which is why capacity management shows up in budget conversations as a procurement request and never as a security improvement.
The demand-side list is the more interesting half, because every item on it also reduces your attack surface. Deleting obsolete data frees storage and shrinks what a breach can expose. Decommissioning an unused application removes an unpatched host. Restricting bandwidth for non-business-critical services overlaps directly with web filtering under A.8.23. Securely disposing of hard copy you no longer need is both a capacity measure and a records control.
| Increase capacity | Reduce demand |
|---|---|
| Hire additional staff or buy cover for critical tasks | Delete obsolete data to free storage |
| Buy, lease or rent additional premises | Securely dispose of hard copy no longer needed |
| Add processing power and storage, on premises or in the cloud | Decommission unnecessary systems, applications and environments |
| Use elastic, scalable cloud resources that expand with computational need | Optimise scheduled and batch tasks to cut memory and IO load |
| Bring forward procurement for long lead-time resources | Improve application logic and database query efficiency |
| Contract standby capacity for contingency operation | Restrict bandwidth for resource-hungry, non-critical services |
Writing both columns into your capacity plan is what turns ISO 27001 capacity management from a spending request into a control. It also gives you an answer when the budget is refused: demand reduction is a documented, standard-sanctioned route to the same outcome.
This is the part worth building the whole control around. A capacity breach rarely announces itself as a capacity breach. It announces itself as a dashboard that is still green while a control has stopped operating. That is the real security case for ISO 27001 capacity management, and it is the one most capacity plans never make.
The clearest example is logging. NIST SP 800-53 Rev. 5 treats log storage as a control in its own right: AU-4 requires an organisation to allocate audit record storage capacity to accommodate its retention requirements, precisely because allocating enough storage reduces the likelihood of capacity being exceeded and auditing capability being lost or reduced. AU-5 then requires an alert when the audit logging process fails, and storage exhaustion is one of the named failure modes alongside hardware errors and capture mechanism faults. You can read both in the SP 800-53 Rev. 5 control catalog.
Map that back onto Annex A and the dependency chain is obvious. If the log volume fills, A.8.15 logging is no longer operating, A.8.16 monitoring activities is blind, and your incident timeline has a hole in it that you will discover during an investigation rather than during a review. The same pattern repeats elsewhere.
| Capacity limit reached | Control that stops operating | How you normally find out |
|---|---|---|
| Log storage or SIEM ingest quota | A.8.15 Logging, A.8.16 Monitoring activities | During an incident investigation |
| Backup target full or backup window overruns | A.8.13 Information backup | During a restore test, or a real restore |
| Patch or build server out of disk | A.8.8 Management of technical vulnerabilities | When a scan shows patches silently not deployed |
| Mail or file quota exhausted | A.5.33 Protection of records, retention obligations | During a legal hold or subject access request |
| No cover for the only competent operator | Any control that person performs alone | During their leave, illness or resignation |
That table is also the fastest way to make ISO 27001 capacity management interesting to a board that does not care about disk graphs. The risk is not that a server gets slow; it is that a control you have certified against stops producing evidence without anyone being told.
No. A.8.6 names no documented information, and no capacity management procedure appears in the list of mandatory ISO 27001 documents, which runs to seven documents and six categories of records. A procedure is a good idea in an organisation large enough that capacity decisions cross team boundaries, and Advisera’s guidance says the same: recommended, not mandatory.
What an auditor will want is evidence that the control operates, and that is a different thing from a policy. Capacity thresholds configured in a monitoring tool, a quarterly capacity review minute, a trend chart with a forward projection, a decommissioning record, and a named deputy for each critical task will all pass. A four-page procedure with no utilisation data behind it will not.
Three specific obligations in the ISO/IEC 27002:2022 guidance get skipped more often than the rest.
Stress testing. The guidance asks you to stress test systems and services to confirm sufficient capacity is available to meet peak performance requirements. Peak is the operative word. A system sized for the mean will fail at month end, at the start of the academic year, or on the day your marketing team succeeds. Pick the real peak, test against it, and keep the result.
Long lead times and high cost. Projections of future capacity should take account of new business and system requirements plus current and projected trends, with particular attention to resources with long procurement lead times or high cost. Those resources are where the control earns its keep, because you cannot buy your way out of the problem in the week you notice it. Network circuits, specialist hardware, and cleared or specialist staff all belong on that list.
Key-person dependency. Management should use capacity information to identify and avoid resource limitations and dependency on key personnel, then plan action. The deliverable is a short list of critical tasks with a primary and a named deputy for each, reviewed when people join and leave. It is the cheapest item in this entire guide and the one most likely to be missing.
ISO/IEC 27002:2022 names elastic, scalable cloud resources as a legitimate way to increase capacity, and they are. What they change is the failure mode, not the requirement. On premises, capacity runs out and the service stops. In an elastic environment, capacity usually runs out in one of three less obvious places: a hard service quota you did not know you had, a per-account or per-region limit that autoscaling cannot cross, or a spending control that throttles you at exactly the moment demand spikes. None of those are visible on a utilisation graph of the instances you are currently running.
So the cloud version of ISO 27001 capacity management is a register of service quotas and limits for the services that carry your critical processes, with current usage against each, and an owner for raising them. That register is also genuinely useful during an availability attack: NIST’s SC-5(2), titled Capacity, Bandwidth, and Redundancy, asks organisations to manage capacity, bandwidth or other redundancy to limit the effects of information flooding denial-of-service attacks. Capacity headroom is a resilience control, not only a performance one.
ISO/IEC 27001:2022 states no frequency for ISO 27001 capacity management. Not for capacity reviews, not for stress tests, not for refreshing projections. Published guidance that tells you to review capacity quarterly, stress test annually, or alert at 80 per cent utilisation is giving you a sensible vendor default, not a requirement, and an auditor cannot raise a nonconformity against a threshold the standard does not contain.
What they can raise is inconsistency. If your own capacity plan says monthly review and the minutes show two reviews last year, that is a finding against your own documented arrangement. Set intervals you will actually keep, justify them from business criticality as the guidance asks, and record the justification. This is the same discipline that governs monitoring and measurement under clause 9.1, where you choose the metrics and the standard holds you to your choice.
Bring six things to the audit and A.8.6 takes ten minutes instead of forty.
| Evidence | What it proves |
|---|---|
| Monitoring configuration with thresholds and alert recipients | The detective half of the control operates |
| Utilisation trend for critical resources with a forward projection | The preventive half operates; projections consider trends |
| Capacity review record naming decisions and owners | Resources are adjusted in line with expected requirements |
| Stress or load test result against a stated peak | Peak performance requirements were confirmed, not assumed |
| Decommissioning and data deletion records | Demand-side measures are real, not aspirational |
| Critical task list with primary and deputy per task | Key-person dependency is identified and being reduced |
Keep the steady-state version of this separate from your recovery capacity. A.8.6 is about having enough capacity to run normally; the question of whether a recovered service can carry production load belongs to A.5.30 ICT readiness for business continuity. Auditors ask both, and answering one with the other is a common way to pick up an observation.
If you already run a NIST-aligned control set, most of A.8.6 is built and you are mapping rather than implementing. The relevant anchors in NIST SP 800-53 Rev. 5 are worth knowing because they are free to read and more specific than the ISO guidance.
| Requirement in A.8.6 | NIST SP 800-53 Rev. 5 | What the NIST control adds |
|---|---|---|
| Capacity for log retention | AU-4 Audit Log Storage Capacity | Allocate storage to the retention requirement explicitly |
| Detecting a capacity breach | AU-5 Response to Audit Logging Process Failures | Alert on failure, including storage exhaustion |
| Capacity for contingency operation | CP-2(2) Capacity Planning | Plan capacity for processing, telecommunications and environmental support during contingency |
| Bandwidth and headroom against flooding | SC-5(2) Capacity, Bandwidth, and Redundancy | Treats headroom as denial-of-service resilience |
You do not need a capacity management platform to close this control. You need a list, a graph and a meeting.
Week 1. List the resources that carry your critical processes, in all three domains: storage and compute, the named people, the physical space. Record current usage and the hard limit for each. For cloud services, read the actual service quotas rather than assuming elasticity.
Week 2. Turn on monitoring and alerting for every resource on the list that can be instrumented, with recipients who will act. Pick thresholds that give you enough notice to procure, which for a long lead-time resource may mean alerting far earlier than a default.
Week 3. Run one demand-reduction pass. Delete obsolete data, decommission one unused system, and capture the records. Then stress test the single most business-critical service against its real peak.
Week 4. Hold the first capacity review. Walk the list, project forward, decide increase or reduce for anything heading for a limit, assign owners, and minute it. Write a deputy against every critical task that currently has one name. That meeting record is the evidence most organisations are missing.
No. A.8.6 requires no documented information, and a capacity management policy or procedure is not in the mandatory document list. Larger organisations usually write one anyway to settle who decides when to spend, but an auditor assesses whether the control operates, not whether you own the document.
The standard sets no frequency. Choose an interval you can justify from the business criticality of the systems and processes concerned, write it down, and keep to it. Quarterly suits most mid-sized organisations; monthly is normal where growth is fast or lead times are long.
Yes, with a different emphasis. You still have capacity constraints: licence seats, storage quotas, API rate limits, log retention windows on your provider’s plan, and export limits if you ever need to leave. Add the supplier’s committed limits to your register and treat a looming quota as the same risk as a filling disk. ISO 27001 capacity management in a SaaS estate is contract reading plus quota tracking rather than hardware planning.
No. It carries over from A.12.1.3 in the 2013 edition with the same title and a broadened set of guidance in ISO/IEC 27002:2022. The eleven genuinely new controls in the 2022 edition are A.5.7, A.5.23, A.5.30, A.7.4, A.8.9, A.8.10, A.8.11, A.8.12, A.8.16, A.8.23 and A.8.28.
Monitoring without projection. Thresholds and alerts are configured, so the detective half of the control is working, but nobody is looking forward: there is no trend, no forecast and no review where someone decides to increase capacity or reduce demand before a limit is reached. The second most common is a critical task with exactly one competent person and no deputy, which is the people limb of ISO 27001 capacity management going unaddressed.
ISO 27001 capacity management is one of the cheapest Annex A controls to close properly and one of the easiest to leave half-built. Get the resource list, the forward projection and the capacity review minute in place, extend the list to people and premises as ISO/IEC 27002:2022 asks, and keep the standard’s own two options in front of you: increase capacity, or reduce demand. You can confirm the edition and amendment status of the standard itself on the official ISO/IEC 27001:2022 page, which lists edition 3, published October 2022, with the climate action amendment of 2024 available at no charge.
If you would rather start from a drafted set than a blank page, the ISO 27001 Toolkit ships 165 templates covering the clauses and all 93 Annex A controls, including the registers, review records and monitoring documentation this control depends on, for $149.
October 15, 2026
October 15, 2026
October 14, 2026
October 14, 2026
October 14, 2026