ISO 27001 A.8.6: Plan capacity before services suffer

What A.8.6 requires in practice

A.8.6 concerns capacity management. It asks the organisation to monitor how resources are being used and to adjust them in line with both present needs and expected future needs. Resources here means anything a service depends on to keep working, such as processing power, memory, storage, network bandwidth, licences or staff in an operations team.

The control has a watching part and an acting part. Watching means knowing current use against the limits of each important resource. Acting means looking ahead, deciding when more capacity or less demand is needed and doing something in time. The link to information security is availability: a service that runs out of capacity at a critical moment can fail the customers and the business just as surely as an attack.

Outputs include measurements of resource use, a view of expected demand and decisions about capacity that are carried through. The control does not set thresholds or require a monitoring product. Reviewing capacity before known peaks is a method many Sterling teams use rather than a fixed rule.

Start with the service constraint

A processor dashboard is useful only if processor capacity limits the service. Storage, database connections, network bandwidth, facility space, supplier quotas and available skilled people can also constrain operation. Map the resources supporting an important service, including dependencies that the organisation does not directly own.

Define an acceptable operating condition in terms that matter to the business. This might concern the completion of a scheduled processing run or the availability of a customer portal during an agreed period. Link resource measures to that condition so the team can distinguish harmless activity from an approaching service problem.

Forecast demand and the time needed to respond

Compare normal demand, foreseeable peaks and planned business changes. New customer contracts, additional sites or a revised retention decision can change the assumptions behind a previously adequate design. Past averages alone may hide simultaneous demand or a seasonal event that occurs outside the observation period.

Choose warning points with response time in mind. A storage alert that arrives after procurement can no longer finish before exhaustion provides little protection. Cloud services can offer flexibility, but scaling depends on configuration, quotas, costs and the parts of the application that can actually expand. Assign someone to act on a warning and give that person an approved route to a resource decision.

Why capacity planning matters to the business

Services seldom fail at quiet times. They fail at month end, during a campaign or just after a successful sale, which is exactly when customers notice. A storage volume that fills overnight or a processing queue that cannot clear can stop operations and trigger penalties under service agreements. Planning capacity is usually cheaper than emergency purchases or the cost of lost trading, and it avoids rushed changes that create their own security weaknesses. It also supports growth decisions, because leaders can see when the current arrangement will stop being enough. Auditors value it because it shows the organisation treats availability as something it manages deliberately, not something it discovers when users complain.

How to implement A.8.6

Begin with the services that matter most and the resource each one is most likely to run short of. Capacity work is most useful when it is routine and attached to business planning, not triggered only by an outage.

1. Identify the important services and the limiting resource behind each, including shared dependencies such as databases and network links.
2. Decide what to measure and how often, and who sees the measurements, so that the information reaches people with authority to approve change.
3. Gather demand information from the business, such as seasonal peaks, planned campaigns, new clients and system changes.
4. Set warning points that leave enough time to respond, and agree who is expected to act when one is reached.
5. Weigh the options when pressure builds: add capacity, reduce unnecessary demand or change how work is scheduled.
6. Test that warnings reach the right people and that a response can actually be delivered in time.
7. Review the forecast after major changes and after any near miss, and keep a short record of what each review concluded and what was done as a result.

Evidence an auditor expects for A.8.6

An auditor will look for proof that capacity is watched and that watching leads to action. Typical evidence includes:

• records of resource use for important services, with a view of how they compare with known limits;
• records of demand forecasts or planning discussions that include expected business changes;
• examples where a warning was raised and a decision followed, such as extra capacity or reduced load;
• observation of the monitoring screens or alert settings with the service owner;
• an interview with the person responsible, to test how they would respond to a new peak.

The observations carry more weight when the auditor can follow one real case from warning to outcome. A set of graphs with no sign that anyone acted on them is weak evidence.

Common nonconformities with A.8.6

Capacity findings usually reflect monitoring that exists without planning behind it.

• Resource use is measured but nobody forecasts future demand, so growth is discovered when a limit is hit.
• Warnings go to a mailbox that nobody reads, or to a person who has left.
• Shared dependencies such as the database or network link are ignored while individual servers are watched.
• Known peaks, such as month-end processing, are not considered in the plan.
• Capacity decisions are made but not recorded, so nothing shows why they were taken.

Illustrative software example: the database behind an elastic service

Illustrative BPO example: a month-end processing window

A hypothetical BPO organisation receives larger month-end file batches after taking on a new account. Technical processing can finish overnight, but a small authorised team must review exceptions before customer delivery. Its capacity estimate originally includes servers and storage while overlooking that review workload.

The organisation measures representative exception volumes, confirms trained cover and agrees a practical escalation route for unusually large batches. It tests the complete process using appropriately protected sample information. The resulting plan balances technology and people; it does not assume that adding infrastructure creates competent reviewers or extends the customer's delivery window.

Choose between more capacity and less unnecessary demand

Adding resources is one option. Removing obsolete workloads, improving inefficient processing or rescheduling competing activities may also address the constraint. Evaluate the effect on information security and business requirements before reducing demand. Deleting records to free space, for example, must respect the organisation's retention decisions and applicable obligations.

Keep these decisions connected to information deletion and change management. An apparently helpful optimisation can alter service behaviour or remove needed information. Capacity planning should provide a controlled decision, with accountable acceptance of any residual limitation.

Test the warning and the response

Useful evidence includes resource trends, assumptions about future demand, agreed limits, assigned actions and results from proportionate tests. A separate capacity plan can help a critical service, but ISO 27002's advice should not be presented as a mandatory document title for every organisation. Retain enough information to explain the selected control and its operation.

Test safely within agreed boundaries. An authorised exercise can establish whether a warning reaches the right person and whether the proposed response restores acceptable operation. Avoid uncontrolled stress testing on production systems. Record any differences between the exercise and real operating conditions, including dependencies that were simulated rather than tested.

Frequent weaknesses include forecasts with no business owner, alerts without funded actions and measuring averages while customers experience peak-period failures. Review material changes through operational planning and control. Consider redundancy separately: spare capacity does not automatically provide a working alternative after a failure.