Capacity Management and Planning Procedure

Template draft. Replace everything in [square brackets] with your own decision, delete what does not describe what you really do, and approve it through your own document control. It is not legal advice and does not make an organisation compliant or certified.

1. Purpose

This procedure makes sure that processing, memory, storage, network bandwidth, licences, facilities and support staff are sufficient for current and expected demand, so that a shortage never becomes an outage, a security weakness or a missed commitment to a customer. It sets how capacity is measured, who reviews it, when action is triggered and how the cost of adding capacity is weighed against the risk of not adding it.

It supports the Communications and Operations Security Policy and the capacity management control of the Organisation's information security management system.

2. Scope

In scope: production, pre-production and shared infrastructure; cloud subscriptions and quotas; databases, file stores, message queues and backup repositories; network links, firewalls and internet gateways; logging and monitoring platforms; endpoint and collaboration licences; the service desk and security operations staffing needed to run them.
In scope: capacity that supports customer-facing platforms, internal business systems and the security tools themselves.
Out of scope: individual developer workstations, unless a pool of them is shared (for example build agents), and capacity planned by a supplier under its own contract, which is governed by the Supplier Relationship Management Procedure.
Applies to: all teams that own, operate or buy technology services, and to project managers who introduce new load.

3. Terms and definitions

Term	Meaning
Capacity	The maximum amount of work a resource can deliver while still meeting its performance target.
Utilisation	The share of capacity in use, measured as a peak and as an average over a stated period.
Headroom	Capacity left between current peak utilisation and the limit, expressed as a percentage.
Baseline	The normal pattern of utilisation for a resource, measured over at least [3 months].
Threshold	A utilisation level that triggers an alert (warning) or an action (critical).
Demand forecast	A reasoned estimate of future load, based on trend, planned projects and business events.
Capacity plan	The approved document that states expected demand, the capacity needed and how and when it will be provided.
Capacity owner	The named person accountable for one resource or service staying within its thresholds.

4. Roles and Responsibilities

Role	Responsibilities
Head of IT Operations (procedure owner)	Owns this procedure, chairs the capacity review, approves the annual capacity plan and escalates unfunded needs to management.
Capacity owner	Keeps the capacity register current for the resources named against them, sets thresholds with the service owner, produces the forecast and raises the capacity request.
Service owner	States the business demand and the performance target, and accepts or declines the cost and risk of the proposed plan.
Infrastructure and cloud engineers	Configure monitoring, act on alerts, resize or scale resources through the change process and record the result.
Information security team	Reviews capacity for security tooling, log retention and attack-load resilience, and flags security consequences of any shortfall.
Project managers	Declare expected load and data growth for new systems before go-live and fund the capacity they need.
Finance and procurement	Confirm budget, commit purchases and track the cost of cloud consumption against forecast.
Human resources	Support recruitment and cover for staffing capacity gaps in operational teams.

Activity	Responsible	Accountable	Consulted	Informed
Maintain the capacity register	Capacity owner	Head of IT Operations	Service owner	Information security team
Set and tune thresholds	Infrastructure and cloud engineers	Capacity owner	Service owner	Information security team
Monthly capacity review	Capacity owner	Head of IT Operations	Information security team	Service owner
Annual capacity plan	Head of IT Operations	Head of IT Operations	Finance and procurement	Management
Raise and approve a capacity request	Capacity owner	Service owner	Finance and procurement	Head of IT Operations
Assess new project load	Project managers	Service owner	Capacity owner	Head of IT Operations
Respond to a capacity alert	Infrastructure and cloud engineers	Capacity owner	Service desk	Service owner

5. Capacity Management Procedure

5.1 Identify and register capacity-managed resources

Every resource whose exhaustion would affect a service, a customer commitment or a security control is entered in the capacity register (Annexure A). The register is built from the asset inventory kept under the Asset Management Procedure, so nothing is monitored that is not owned and nothing owned is left out.

SelectThe capacity owner lists each resource that has a hard limit: CPU, memory, disk, database size, queue depth, bandwidth, concurrent sessions, API or licence quotas, backup storage and log storage. Input: asset inventory. Target: within [10 working days] of a new service being accepted.
RecordEnter the resource, owner, service supported, unit of measure, current limit and the performance target the business expects. Output: register entry.
RateRate business criticality as [High, Medium or Low] using the service criticality given in the business impact analysis. High-criticality resources are reviewed more often.
ApproveThe Head of IT Operations confirms the register entry. Unapproved entries are not used for planning.

5.2 Set thresholds and collect data

Thresholds are set per resource type from the baseline, not copied from a vendor default. A warning gives time to plan; a critical level means action is already needed. Measurements are taken by the monitoring platform described in the Logging and Monitoring Procedure and kept long enough to show a trend.

Resource type	Warning threshold	Critical threshold	Sampling interval
Compute (CPU, sustained)	[70 percent for 15 minutes]	[85 percent for 10 minutes]	[1 minute]
Memory	[75 percent]	[90 percent]	[1 minute]
Disk or volume space	[75 percent used]	[90 percent used]	[5 minutes]
Database size and connections	[70 percent of limit]	[85 percent of limit]	[5 minutes]
Network link	[60 percent of peak bandwidth]	[80 percent of peak bandwidth]	[1 minute]
Backup and archive storage	[70 percent]	[85 percent]	[daily]
Log and monitoring storage	[70 percent of retention need]	[85 percent of retention need]	[daily]
Licences and cloud quotas	[80 percent consumed]	[95 percent consumed]	[daily]
Service desk and operations staffing	[Ticket backlog above 2 days of work]	[Backlog above 5 days or single-person dependency]	[weekly]

Note. Monitoring must itself be sized. If the monitoring or logging platform cannot ingest the volume it is given, security events are lost, so its capacity is treated as High criticality.

5.3 Review capacity on a fixed rhythm

Capacity is reviewed on a schedule, not only when something breaks. The review looks at peaks, trend, alerts, incidents caused by lack of capacity, and projects that will add load.

Review	Frequency	Led by	Output
Operational check of alerts and headroom	[weekly]	Infrastructure and cloud engineers	Actions logged in the ticketing tool
Capacity review meeting	[monthly]	Head of IT Operations	Updated register, forecast changes, capacity requests
Cloud cost and quota review	[monthly]	Finance and procurement with capacity owner	Forecast versus actual spend, quota changes
Annual capacity plan	[once a year, before budget setting]	Head of IT Operations	Approved capacity plan
Event review (sale, campaign, migration, audit)	[before each planned peak]	Capacity owner	Event readiness note

5.4 Forecast demand

GatherCollect [12 months] of utilisation data and planned business events, projects, customer onboarding and retirement. Owner: capacity owner.
ProjectProject the peak for the next [12 months] using trend plus known step changes; state the assumption behind each. Use the higher of the trend and the planned-event figure.
CompareCompare projected peak with current limit. If projected headroom falls below [20 percent] within [6 months], a capacity request is raised.
ChallengeThe service owner confirms the demand assumptions; the information security team confirms security tool and log volumes.
RecordStore the forecast in the annual plan or review minutes, with date and approver.

5.5 Raise and approve a capacity request

A request states the resource, the shortfall, the date by which capacity is needed, the options and the cost. Lead times for purchase or provisioning are part of the date, so that requests are raised early enough.

Option	Typical use	Consider
Tune or clean up	Quick gain without spend	Archive old data, remove unused volumes, fix inefficient queries
Scale up or scale out	Predictable growth	Cost, change window, licence impact, restart requirement
Automatic scaling	Variable or spiky load	Upper limit to control cost, alert on reaching the limit, test scale-in
Throttle or queue demand	Protect a service during surges	Agreed with the service owner, with customer impact stated
Redesign or replace	Structural limit reached	Goes through the change and project process

Approval authority follows spend and risk: the capacity owner approves spend up to [the delegated limit], the Head of IT Operations up to [a higher limit], and management above that. Provisioning is carried out through the change process described in the Change Management Policy and Procedure.

5.6 Respond to a capacity alert

AcknowledgeThe engineer on duty acknowledges a critical alert within [15 minutes] and a warning within [1 working day].
DiagnoseDecide whether the cause is normal growth, a one-off peak, a fault or hostile traffic. If an attack is suspected, raise a security incident under the Incident Management Procedure.
ActApply the least risky fix: clean up, throttle, add capacity under a standard or emergency change. Record the action.
ConfirmCheck utilisation has returned below the warning level and update the capacity register.
LearnIf service was degraded, open a problem record under the Problem Management Policy and Process to remove the cause.

5.7 Assess capacity for new systems and changes

Before go-live, a project provides expected users, transactions, data volume and growth, and the capacity owner confirms that production, backup, log storage and monitoring can absorb it. Load or stress testing is done for systems rated High and the result is attached to the change record. Capacity is also assessed before onboarding a large customer, a migration or a data restore, because these produce one-time peaks that normal baselines do not show.

5.8 Cloud and elastic capacity

Each cloud account or subscription has a named capacity owner, a budget alert at [80 percent] of the monthly forecast and a hard guard rail on the maximum size of any single resource.
Automatic scaling policies state a minimum, maximum and cool-down, and are tested at least [once a year].
Service quotas and regional limits that could block recovery are reviewed against the disaster recovery plan in the BCP and DR Procedure.
Unused or idle resources are identified monthly and removed, because unmanaged capacity is both a cost and a security exposure.

6. Measures

Measure	Target	How measured
Incidents caused by lack of capacity	[0 per quarter for High-criticality services]	Ticketing tool, cause code
Resources with approved thresholds in the register	[100 percent of High and Medium]	Register versus asset inventory
Critical alerts acknowledged on time	[95 percent within 15 minutes]	Monitoring platform report
Monthly capacity reviews held	[12 of 12 a year]	Meeting minutes
Forecast accuracy (peak, 6 months ahead)	[within 20 percent]	Forecast versus actual peak
Capacity requests approved before headroom falls under 10 percent	[90 percent]	Request log

7. Records and evidence

Record	Where kept	Retention
Capacity register	Document management system or configuration tool	Current version plus [3 years] of history
Utilisation data and trend reports	Monitoring platform	[13 months] to allow year-on-year comparison
Monthly review minutes and annual capacity plan	Document management system	[3 years]
Capacity requests and approvals	Ticketing tool	[3 years]
Load test results	Attached to the change record	[3 years]

Annexure A: Capacity register

Resource	Service	Owner	Criticality	Current limit	Peak use	Warning / critical	Forecast date of shortfall	Last reviewed
Example: primary database storage	Customer platform	Database lead	High	[2 TB]	[1.2 TB]	[75 / 90 percent]	[Q3 next year]	[date]

Annexure B: Capacity request form

Field	Entry
Request number and date
Requester and capacity owner
Resource and service affected
Current limit, peak use and headroom
Forecast and date capacity is needed
Options considered and recommended option
Cost (one-off and recurring)
Risk if not approved
Approver, decision and date
Change reference

8. Exception

Exceptions to this document are allowed only where compliance is not practicable and the risk has been assessed. A request must state what is to be excepted, why, the risk it creates, the compensating controls, and an end date no later than [6 months]. It is approved in writing by the document owner and the risk owner, recorded in the exceptions register, and reviewed at the end date. An exception does not change the document.

9. Enforcement

Compliance is monitored through internal audits, management review and routine checks by the document owner. Non-compliance is reported through the incident or non-conformity process and handled under the organisation's disciplinary procedure, and under the terms of any contract for people who are not employees. Serious or repeated non-compliance may lead to loss of access and, where the law is broken, to referral to the authorities.

10. Review

This document is reviewed at least every [12 months], and when there is a significant change to the organisation, its systems, its risks or the law, or after an incident that shows it was not effective. Each review is recorded in the revision history.

ISO/IEC 27001:2022 references

Reference	Title
A.8.6	Capacity management
A.8.14	Redundancy of information processing facilities
A.8.16	Monitoring activities
A.5.30	ICT readiness for business continuity
8.1	Operational planning and control