Redundancy and Capacity Management: ISO 27001 Controls 8.6, 8.14

The Friday before Thanksgiving

At 11:47 a.m. on the Friday before Thanksgiving, Dana Okonkwo-Reyes was standing in the kitchen of Meridian Ledger's Austin office, refilling a coffee mug, when her phone lit up with a PagerDuty alert she'd never seen fire twice in the same minute before. Then it fired a third time. By the time she got back to her laptop, the incident channel already had forty messages in it.

Meridian Ledger processed payment reconciliation for roughly 340 mid-market retailers, and one of its largest clients — a home goods chain running a surprise 48-hour "Black Friday preview" flash sale — had pushed transaction volume to nearly six times Meridian's typical Friday peak. The database connection pool on the primary reconciliation cluster maxed out within eleven minutes. CPU on the API tier pegged at 100% shortly after. There was no autoscaling policy configured for that tier — capacity had been sized eighteen months earlier against a growth forecast nobody had ever revisited — and there was no standby cluster to absorb the overflow, because the reconciliation database had been built as a single, powerful primary node with nightly backups and nothing else.

The outage lasted six hours and twenty minutes. Retailers couldn't reconcile transactions in real time; some had to pause their own promotions rather than risk overselling inventory they couldn't confirm was paid for. Meridian's client contracts carried a 99.9% monthly uptime SLA with tiered service credits, and this single incident burned through the entire quarter's error budget in one morning. The final tally, once the CFO's office finished adding it up: $1.4 million in SLA credits issued to affected clients, roughly $640,000 in transaction fees Meridian never collected because processing simply stopped, and two clients — worth a combined $2.1 million in annual recurring revenue — who gave notice within the following month. Call it north of $2 million in direct impact, with the churn still working its way through the books a year later.

Nothing about this outage involved a hacker, malware, or a leaked credential. Nothing was stolen. The confidentiality and integrity of Meridian's data were never in question. What failed was availability — the "A" in the CIA triad — and it failed for two boring, entirely foreseeable reasons: nobody had been systematically tracking capacity against demand, and nobody had built redundancy into the one component the whole reconciliation pipeline depended on.

That's precisely the gap that ISO/IEC 27001:2022 Annex A closes with two unglamorous but critical technological controls: 8.6 (Capacity management) and 8.14 (Redundancy of information processing facilities). Neither control makes breach headlines. But together they sit between "the system slowed down" and "the system stayed up," and certification auditors increasingly probe them hard — because an ISMS that says nothing credible about whether infrastructure can stay available under load has a large hole in it.

Who this is for

This article is for the people who own uptime: infrastructure and platform engineering leads, site reliability engineers, cloud architects, and the ISMS managers who have to translate "make sure it doesn't fall over" into language a certification auditor will accept as evidence. If your Statement of Applicability marks 8.6 and 8.14 as applicable — which almost any organization running production systems should — you'll walk away with a concrete capacity monitoring and forecasting model, a redundancy and failover design framework tied to real availability requirements, a failover testing cadence, and the specific artifacts auditors ask for on both controls.

The availability picture: where 8.6 and 8.14 sit among the continuity controls

ISO 27001 doesn't have one "availability control." It has a cluster of controls that each own a different slice of staying operational, and confusing them is one of the fastest ways to fail an audit or, worse, to build the wrong protection for the wrong failure mode. As we cover in our technological controls overview, Annex A's 34 technological controls span everything from endpoint hardening to cryptography, and 8.6 and 8.14 are the two that deal specifically with engineering for availability — making sure the infrastructure itself has enough capacity and enough duplication to keep running.

They are easy to mix up with three neighboring controls, so it's worth being precise before going further:

Table 1: Availability-related controls at a glance

The relationship matters more than the definitions. 5.30 (covered in depth in our article on business continuity and ICT readiness) is where the organization decides how much downtime and data loss it can tolerate — the recovery time objective (RTO) and recovery point objective (RPO) for each critical system. 8.6 and 8.14 are where engineering turns those tolerances into an actual design: enough headroom that normal demand growth doesn't cause an outage, and enough duplication that a single failed disk, rack, availability zone, or data center doesn't either. 8.13 backup, discussed alongside configuration management in our piece on configuration management and backup controls, answers a different question entirely: if data is lost or corrupted, can you get it back? Redundancy keeps a live system running; backup restores a damaged one. You need both, and an auditor who understands the standard will ask about both separately, because a company can have flawless backups and still go down for six hours because it never bothered building a second application server.

Meridian Ledger's outage is a clean illustration of the seam between these controls. Backups were fine — no data was lost, and 8.13 wasn't the problem. What Meridian lacked was 8.6 (nobody was watching the connection pool trend toward the ceiling) and 8.14 (there was no redundant path around the ceiling once it was hit). Fixing the backup regime would have done nothing for this incident. Fixing capacity and redundancy would have prevented it outright.

"I've sat across the table from a dozen infrastructure teams who proudly show me their backup runbooks and then go quiet when I ask what happens if the primary database server's power supply dies at 2 p.m. on a Tuesday. Backups answer 'can we get the data back.' Redundancy answers 'did anyone even notice we lost a server.' Those are different questions and they need different evidence." — Renata Silva, ISO 27001 Lead Auditor, Cascade Certification Partners

8.6 Capacity management: what it actually asks of you

The control text is deceptively short: the use of resources shall be monitored and adjusted in line with current and expected capacity requirements. In practice, that single sentence breaks into three distinct disciplines, and auditors expect to see evidence of all three, not just the first.

Monitor. You need visibility into how much of each critical resource is actually being consumed, in something close to real time, across every system that matters to the business. That means dashboards and alerting, not a spreadsheet someone updates when they remember.

Tune. When monitoring shows a resource trending toward exhaustion, someone needs to act — right-size an instance, add a read replica, expand a storage volume, renegotiate a software license seat count, or hire before the security operations team burns out from ticket volume.

Forecast. The forward-looking piece is what separates capacity management from basic monitoring. You're not just reacting to today's utilization graph; you're projecting where demand will be in three, six, and twelve months based on business growth, seasonal patterns, and planned product launches, and sizing ahead of that curve.

Most organizations I've assessed do the first reasonably well — everyone has some dashboard. Very few do the third at all, and that's exactly where Meridian Ledger fell down: monitoring existed in a general sense, but nobody had connected "we just signed three new enterprise clients" to "we need to re-run the capacity model," and nobody had built alerting thresholds tight enough to catch a demand spike inside the eleven minutes it actually took to exhaust the connection pool.

What counts as "capacity" under 8.6

Capacity management is frequently treated as a server-and-storage exercise, but ISO 27002's guidance is broader than that, and a mature implementation tracks all of the following:

Table 2: Resources in scope for capacity management

That last row surprises people every time I bring it up in a workshop, but ISO 27002's guidance on 8.6 explicitly contemplates human resources alongside technical ones. A security operations center that can only triage 40 alerts a day but receives 90 is running over capacity in exactly the sense this control cares about — the organization just hasn't built a dashboard for it. I've seen SOC teams silently start ignoring lower-severity alerts to keep pace, which is a capacity failure wearing the costume of a triage decision.

"The number that changed how my leadership team thought about capacity wasn't a server metric. It was 'our on-call engineers are averaging 4.2 hours of sleep on rotation nights.' Once we put a number on that, capacity stopped being an infrastructure conversation and became a staffing conversation, which is where it should have been the whole time." — Priya Chandrasekaran, Capacity & Performance Engineering Manager, Solvanta Retail

Thresholds and escalation

Monitoring without a threshold is just a chart nobody acts on. Every resource in scope needs a defined tier structure that triggers a specific, documented response — and those thresholds should be set with enough lead time that someone can actually act before the resource is exhausted, not when it's already gone.

Table 3: Capacity threshold and escalation tiers (illustrative)

Meridian Ledger's connection pool had no amber or red tier at all — the only alert configured was "pool exhausted," which is the equivalent of a smoke detector that only goes off once the room is on fire. After the incident, Dana's team rebuilt the threshold model with an amber tier at 65% and a red tier at 85%, giving the on-call engineer roughly twenty minutes of lead time on the worst historical growth curve — enough to trigger manual scaling before the next flash-sale-scale event.

Forecasting: the piece everyone skips

Monitoring tells you where you are. Forecasting tells you where you're going to be, and it's the part of 8.6 that separates organizations that get surprised by growth from organizations that don't.

Table 4: Capacity forecasting methods

The business-driver-linked method is the one most consulting engagements never get to, because it requires infrastructure and revenue teams to actually talk to each other. In Meridian's case, the sales team had a signed pipeline showing three new enterprise clients closing within the quarter — information that existed in a CRM the infrastructure team had never been given access to. Tying capacity forecasting to that pipeline, even at a rough quarterly cadence, would have flagged the coming surge months in advance.

Tuning and adjustment

Once monitoring and forecasting surface a gap, someone has to close it. Tuning covers a wide range of actions: vertical scaling (bigger instances), horizontal scaling (more instances behind a load balancer), autoscaling policies that respond automatically to load, database query and index optimization, archiving or purging stale data to reclaim storage, and renegotiating third-party license or API-rate-limit ceilings before they become the bottleneck. The important governance point for 8.6 isn't which lever you pull — it's that capacity reviews happen on a defined cadence (monthly is typical for fast-growing environments, quarterly for stable ones) and that the review produces a documented decision, even if the decision is "no action needed this cycle." An auditor doesn't need to see that you never hit a capacity constraint; they need to see that you have a system that would have caught it if you had.

Who owns what: a RACI for capacity management

One reason capacity management stalls out in practice is that it touches too many teams for anyone to feel fully accountable for it — infrastructure owns the servers, application teams own the code that consumes resources, finance owns the budget for scaling, and sales owns the demand signal that should trigger forecasting in the first place. Without an explicit accountability model, "capacity management" quietly becomes "whichever team notices the dashboard first."

Table 2b: Illustrative RACI for capacity management activities

A RACI like this doesn't need to be elaborate, but it does need to exist somewhere an auditor can find it — ideally referenced directly from the Statement of Applicability entry for 8.6, since "who is accountable for this control operating correctly" is one of the first questions any competent auditor asks when a control's evidence spans multiple teams.

8.14 Redundancy of information processing facilities: designing so failure isn't fatal

Where 8.6 is about not running out of resource under load, 8.14 is about not going down when a component fails outright — a disk, a server, a network switch, a power feed, an entire data center, or an entire cloud region. The control text requires that information processing facilities be implemented with redundancy sufficient to meet availability requirements. That last phrase — "sufficient to meet availability requirements" — is doing all the work. ISO 27001 does not mandate a specific architecture; it mandates that whatever architecture you choose be justified against a defined availability target, which almost always traces back to the business impact analysis and RTO/RPO decisions made under ICT readiness for business continuity.

This is precisely where Meridian Ledger's second failure lived. The reconciliation database had never had an availability requirement formally attached to it at all — nobody had ever asked "how many nines does this system need?" It was simply built as a single, capable node because that was cheaper and simpler, and the absence of a stated requirement meant nobody could point to a design decision that was wrong on its own terms. The architecture wasn't non-compliant with a number; it was non-compliant with the absence of a number.

Redundancy patterns

Table 5: Common redundancy architectures

A useful gut-check I give clients: if your "redundant" component shares a power circuit, a network switch, a rack, an availability zone, or an on-call engineer's laptop with the primary, it isn't redundant — it's a second copy of the same single point of failure. I've reviewed more than one "high availability" database pair where both nodes lived in the same rack, on the same top-of-rack switch, and the client only discovered the shared dependency when that switch failed and took both nodes down together.

"The question I ask every infrastructure team in a stage 2 audit is simple: 'Show me the thing that would have to fail for this redundant pair to fail together.' If they can't answer instantly, they haven't actually mapped their dependency chain — they've just bought a second server and called it a day." — Marcus Webb, Site Reliability Engineering Lead, Northfield Cloud Systems

Site and facility redundancy

Component-level redundancy protects against a server or disk failing. Site-level redundancy protects against something bigger — a data center losing power, a fire, a regional network outage, or a natural disaster taking out an entire facility.

Table 6: Site redundancy tiers

The RTO/RPO figures in that table aren't arbitrary — they should come directly from the business continuity planning done under 5.29 and 5.30, not be reverse-engineered from whatever architecture already exists. I've sat in more than one planning session where the "RTO" quoted to me was actually just a description of how the current system happened to behave, offered backwards as if it were a deliberate target. That's a compliance smell auditors are trained to catch: ask where the RTO number came from, and if the answer traces back to a business impact analysis, that's a pass; if it traces back to "well, that's about how long it took last time," that's a finding.

Failover mechanics

Redundancy only delivers availability if failover actually happens when it's needed, and failover mechanisms fall into a few recognizable categories: health-check-driven automatic failover (a load balancer or orchestrator detects a failed node and reroutes traffic without human involvement), DNS-based failover (updating DNS records to point to a surviving endpoint, constrained by TTL propagation delay), database replication failover (promoting a replica to primary, either automatically via a cluster manager or manually by an on-call engineer), and manual failover (a documented runbook a human executes step by step). Automatic mechanisms are faster and remove human error from the critical path, but they need careful tuning — health checks that are too sensitive cause "flapping" failovers that make things worse, and checks that are too lenient leave traffic flowing to a dead node for too long. Manual failover is sometimes the right choice for systems where an automatic failover could cause data inconsistency, but it must be backed by a runbook that's been tested, not one that's been written and filed away.

Matching redundancy design to availability requirements

"Sufficient to meet availability requirements" only means something once you've stated the requirement. The table below is the illustrative model I use with clients to connect a stated availability target to an architecture and a rough cost multiplier — useful for framing the conversation with finance before someone assumes "high availability" is a single, fixed price tag.

Table 7: Availability targets mapped to redundancy design

These figures are illustrative, not a guarantee — actual downtime depends heavily on how well failover is tested, not just how it's architected. That caveat is the entire subject of the next section.

Testing redundancy and failover: the step almost everyone shortcuts

Redundancy that has never been tested is a hypothesis, not a control. This is the single most common gap I find in 8.14 evidence during readiness assessments: an architecture diagram showing a beautifully redundant design, and zero records showing that failover from primary to secondary has ever actually been exercised. Untested standby systems fail silently in predictable ways — replication jobs that stopped working months ago without alerting anyone, TLS certificates on the standby node that expired because nothing ever hit that endpoint to notice, DNS TTLs set so high that "instant" failover actually takes forty minutes to propagate, or a runbook that references a hostname that was decommissioned two reorganizations ago.

Table 8: Failover and redundancy test types

A pattern worth naming: the first time most organizations test failover for real, it's during an actual outage — which is the worst possible time to discover the standby database is eleven versions behind because a replication job failed silently three months earlier. That exact scenario is the subject of one of the case studies below, and it's common enough that I now ask every client during a gap assessment for their most recent failover test report before I ask to see the architecture diagram. The diagram tells me what was designed; the test report tells me what actually works.

A failover test report doesn't need to be elaborate, but a handful of elements consistently separate reports auditors accept without question from reports that generate follow-up findings:

Table 8b: Anatomy of a credible failover test report

Reports missing the observed-versus-target RTO/RPO comparison are the single most common gap I see — teams will happily report "the failover worked" without ever stating how long it actually took, which leaves an auditor unable to verify the "sufficient to meet availability requirements" language in the control itself.

"We used to treat DR testing like a fire drill nobody wants to run because it might actually mess something up. Then we ran an unannounced failover on a Tuesday afternoon and found out our 'automatic' database promotion had a manual approval step nobody remembered was there. It added four minutes to every incident until we found it. You cannot find that kind of thing by reading the architecture diagram." — Tom Achebe, CTO, BrightPath Insurance Tech

Cloud considerations: multi-AZ, multi-region, and the autoscaling trap

Cloud infrastructure makes both 8.6 and 8.14 easier and, paradoxically, easier to get wrong through false confidence. Cloud providers give you the building blocks — availability zones, regions, managed load balancers, autoscaling groups — but the shared responsibility model means the provider is responsible for the resilience of the underlying platform, not for whether you configured your workload to actually use it redundantly. Deploying into a cloud region does not, by itself, satisfy 8.14. Deploying into a single availability zone within that region, which is the default in a lot of quickly-built architectures, leaves you with exactly the same single point of failure you'd have in a self-managed data center — just with someone else's hardware underneath it.

Table 9: Cloud redundancy options compared

Multi-cloud in particular is a pattern I talk clients out of more often than into. It sounds like the ultimate redundancy story, but in practice it multiplies operational complexity, doubles the security control surface you have to manage consistently, and is usually a worse use of engineering time than simply doing multi-region well on one provider. Redundancy sufficient to meet availability requirements does not mean redundancy against every conceivable failure mode regardless of cost — it means redundancy proportionate to a stated, justified target.

Autoscaling is capacity management's cloud-native form

Autoscaling groups are the most direct expression of 8.6 in a cloud environment: they monitor a metric (CPU, request queue depth, custom application metrics) and adjust capacity automatically. But autoscaling introduces its own capacity risks that catch teams off guard. Provider account quotas — the maximum number of instances, IP addresses, or API calls permitted per region or account — are a hard ceiling that autoscaling can hit silently, especially during exactly the kind of demand spike autoscaling exists to absorb. I've seen an autoscaling policy configured perfectly, monitoring the right metric, scaling on the right threshold — and failing anyway because the account's regional instance quota was still set at the provider's low default and nobody had ever requested an increase. That's a capacity management gap as real as an under-provisioned database, just one layer removed from the infrastructure the team directly controls. Reviewing cloud quota headroom belongs on the same capacity review cadence as CPU and storage trending, and it pairs naturally with the anomaly detection work covered in our article on logging and monitoring activities, since a quota-driven scaling failure is exactly the kind of event that should generate an alert, not a silent service degradation.

Cost is the honest tension in every cloud redundancy conversation. Multi-AZ deployment roughly doubles compute and data transfer costs for the protected tier; multi-region active-active can run three to six times a single-region deployment once cross-region data transfer and duplicated infrastructure are counted. None of that is a reason to skip redundancy — it's a reason to tie the redundancy decision explicitly to a business-justified availability requirement, documented and signed off, rather than either over-engineering a marketing website to five-nines availability or under-engineering a payments system to save a few thousand dollars a month.

Organizations building or running SaaS platforms carry this tension especially acutely, since a single availability incident can ripple across an entire customer base simultaneously — a dynamic we go into in more depth in our guide to ISO 27001 for SaaS companies, and one that shows up just as sharply for cloud service providers whose own customers are relying on their redundancy design as a downstream dependency.

One detail teams consistently underestimate when they finally test a multi-region failover: clock synchronization. If timestamps across regions or data centers have drifted even by a few seconds, correlating log entries during a failover event — which node went down first, which health check fired, how long the actual cutover took — becomes far harder than it should be, right when clean evidence matters most. That's a direct dependency on the operational hygiene practices covered in our article on clock synchronization, privileged utilities, and software installation controls, and it's worth checking before your next failover drill rather than discovering it while trying to reconstruct a timeline after a real incident.

Evidence auditors actually want to see

Auditors assessing 8.6 and 8.14 are not evaluating whether your architecture is the best possible design — they're evaluating whether you can demonstrate a systematic, repeatable process behind it. That distinction changes what evidence matters.

Table 10: Audit evidence for 8.6 and 8.14

A properly maintained Statement of Applicability should state not just that 8.6 and 8.14 are applicable, but how they're implemented and where the supporting evidence lives — the capacity dashboard, the DR test report repository, the architecture diagram register. Auditors reward specificity here far more than a generic "capacity is monitored via cloud tooling" sentence.

"The single most common finding I write against 8.14 isn't 'no redundancy.' Almost everyone has some redundancy now — cloud defaults make sure of that. The finding is 'redundancy exists but was never tested,' or 'redundancy exists but the availability requirement it's supposed to satisfy was never documented.' Both are minor nonconformities on their own, but they're the kind of finding that becomes a major one if I see it two audits in a row." — Renata Silva, ISO 27001 Lead Auditor, Cascade Certification Partners

Common mistakes

Table 11: Common 8.6 and 8.14 mistakes

These mistakes rarely travel alone. Meridian Ledger's incident touched at least four rows in that table simultaneously: capacity sized once and forgotten, no documented availability requirement, no redundancy on the reconciliation database, and no connection between the sales pipeline and infrastructure forecasting. That's the normal pattern — these controls fail as a cluster, not individually, which is exactly why ISO 27001 treats them as a pair rather than isolating them.

Case studies

Case study 1: Meridian Ledger's recovery

After the Thanksgiving-week outage, Dana Okonkwo-Reyes was given a mandate and a modest budget increase to fix what had broken. The remediation had three parts. First, a capacity monitoring rebuild: dashboards covering connection pool utilization, CPU, memory, and storage across every production system, with the tiered threshold model described in Table 3, feeding into weekly (not monthly) capacity review meetings for the first two quarters. Second, an autoscaling policy for the API tier and a warm standby cluster for the reconciliation database, replicated continuously with a documented, tested promotion runbook. Third — and the change Dana says mattered most — a standing monthly fifteen-minute sync between infrastructure and sales, so pipeline movement that implied a capacity-relevant demand shift would surface before it became a surprise.

Nine months later, Meridian's next flash-sale-scale event arrived from a different client, at a similar traffic multiple to the Thanksgiving incident. The autoscaling policy added capacity automatically within ninety seconds of the threshold breach; the warm standby was never needed because the primary held. Zero downtime, zero SLA credits. At the following stage 2 surveillance audit, both 8.6 and 8.14 were assessed as effective, with the auditor specifically citing the sales-pipeline-linked forecasting process as a maturity indicator well above what she typically sees at a company Meridian's size.

"The most expensive lesson in that whole outage was realizing capacity planning had been living entirely inside infrastructure's head, disconnected from the one team that actually knew demand was about to change. Fixing the dashboards was the easy part. Fixing the silo was the part that actually prevented the next one." — Dana Okonkwo-Reyes, Director of Infrastructure, Meridian Ledger

Case study 2: the standby that wasn't standing by

Alderbrook Behavioral Health Network ran patient scheduling and records-adjacent systems out of a single primary data center, with a documented warm standby in a secondary facility roughly ninety miles away — on paper, a textbook 8.14 implementation. The architecture diagram was clean. The runbook existed. What nobody had verified in over three months was whether the replication job feeding that standby was actually still running.

It wasn't. A credential rotation on the primary database had silently broken the replication connection eleven weeks earlier; the job's failure alerts had been routed to a distribution list that no longer had an active recipient after a team reorganization. When a power distribution failure took down the primary facility for four hours, the on-call team failed over to what they believed was a current standby — and found scheduling data eleven weeks stale. Restoring accurate state required a manual reconciliation against paper intake records for four days, delaying non-urgent appointments across the network and triggering a mandatory incident disclosure review under the organization's own patient-notification procedures.

The root cause wasn't a redundancy design flaw — the architecture was sound. It was the complete absence of the testing discipline covered earlier: nobody had run a failover drill, and nobody had a monitoring check verifying replication health independent of the alert routing that had quietly broken. Alderbrook's remediation added an automated replication-lag health check feeding directly into the same monitoring stack used for capacity thresholds, plus a mandatory quarterly failover drill with results reported to the ISMS steering committee — closing exactly the gap between "redundancy exists" and "redundancy works."

"We had every artifact an auditor would have wanted to see on paper — the diagram, the runbook, the standby contract. What we didn't have was proof any of it still worked, and by the time we needed it, eleven weeks of silent drift meant it didn't. I don't trust a standby anymore until I've watched it take real production traffic in a drill." — Liam Fitzgerald, Head of Cloud Platform, Ashworth Financial Group (Alderbrook's post-incident infrastructure advisor)

Case study 3: built for the surge, not surprised by it

Solvanta Retail, an e-commerce platform processing seasonal promotional traffic for a portfolio of consumer brands, took a different path from the start. Ahead of its largest annual sale, the platform team built capacity forecasting directly off the marketing calendar — every planned promotion fed a projected traffic multiplier into the capacity model at least six weeks in advance — and paired it with a multi-region active-active architecture across two cloud regions, tested via a full unannounced failover drill one month before the sale.

On sale day, traffic peaked at roughly 9x Solvanta's typical baseline. Autoscaling absorbed the surge inside the pre-modeled headroom; a transient network degradation in one region shifted traffic to the second region automatically, with no customer-visible interruption. Post-event analysis estimated the architecture prevented approximately $3.2 million in lost sales compared to Solvanta's prior-year single-region build, which had suffered a two-hour partial outage during the same sale the year before.

Table 12: Case study outcomes compared

Maturity model and implementation roadmap

Organizations don't jump from "no capacity dashboard" to "predictive, sales-linked forecasting with tested multi-region failover" in one sprint, and auditors don't expect that on a first certification cycle. What they do expect is evidence you're moving up this curve deliberately.

Table 13: Capacity and redundancy maturity model

Most organizations I assess land at level 2 going into their first certification audit, and that's a defensible starting point as long as there's a credible plan to reach level 3 within the surveillance audit cycle. What auditors flag is stagnation — being at level 2 at initial certification and still at level 2 two years later with no documented progression.

Table 14: Illustrative implementation roadmap

A capacity forecast, however sophisticated, is only as credible as the risk register it feeds into and is fed by — availability risk belongs in the same register as every other information security risk, scored and tracked with the same rigor, not managed in a separate spreadsheet infrastructure keeps to itself.

Reporting capacity and availability to leadership

Dashboards built for engineers rarely translate directly into something a steering committee or an auditor can digest in five minutes. A small, stable set of metrics reported on a fixed cadence does more for both governance and audit readiness than an ever-growing pile of raw utilization graphs.

Table 14b: Illustrative leadership reporting metrics

Keeping this reporting set small and consistent also makes it easy to hand directly to a certification auditor as a single artifact that demonstrates ongoing management review — exactly the kind of evidence that turns a plausible-sounding control description into a control an auditor can independently verify.

How capacity, redundancy, backup, and continuity interlock

These controls don't operate in isolation — they form a closed loop that starts with a business decision about how much disruption is tolerable and ends with evidence an auditor can verify. The diagram below shows how 8.6 and 8.14 connect to 8.13 backup and the 5.29/5.30 continuity controls to deliver actual availability, rather than four disconnected checkboxes on a Statement of Applicability.

Read left to right: the business sets the target, capacity management keeps day-to-day load inside that target, redundancy absorbs the failures that happen anyway, backup recovers data if it's damaged despite all of that, and 5.29 governs how security controls hold up while all of it is happening under stress. Every arrow in that loop should have a corresponding piece of evidence — that's the practical test of whether these controls are operating as a system rather than as isolated line items.

The business case: availability as a sales asset, not just a compliance line item

It's worth stepping back from the control language for a moment, because I've watched too many organizations treat 8.6 and 8.14 as boxes to tick for an auditor rather than as investments that show up directly in revenue conversations. Every enterprise security questionnaire I've reviewed in the last several years asks some version of "what is your architecture's redundancy design" and "how do you forecast and manage capacity" — often well before it asks about encryption algorithms or password policies. Buyers have learned, usually the hard way, that a vendor's confidentiality controls don't matter much if the vendor's service is down when they need it.

That's true across adjacent frameworks, not just ISO 27001. SOC 2's Trust Services Criteria include an entire Availability criteria category that maps almost directly onto the same monitoring, capacity, and redundancy evidence covered in this article, so organizations pursuing both frameworks — a common combination for B2B SaaS vendors selling into the U.S. market — get significant evidence reuse by building 8.6 and 8.14 well once. The NIST Cybersecurity Framework's Recover function covers similar ground from a different angle, emphasizing restoration of capabilities after disruption. And for organizations operating in or selling into the EU financial sector, the Digital Operational Resilience Act's ICT resilience requirements go further still, mandating tested resilience and redundancy for critical ICT systems with regulatory teeth behind it. None of these frameworks makes an organization automatically compliant with the others — ISO 27001 certification supports these broader regulatory and contractual goals rather than satisfying them outright — but a genuinely mature 8.6/8.14 implementation is evidence that transfers cleanly across all of them.

The framing I use with executive sponsors who are skeptical of the budget: every dollar spent on tested redundancy and disciplined capacity forecasting is a dollar that either prevents a Meridian-Ledger-scale loss outright, or shortens a sales cycle because the security questionnaire gets answered with evidence instead of promises. Both are measurable. Neither requires believing compliance is valuable for its own sake.

Where to start

If you're building out your ISMS and haven't yet formalized 8.6 and 8.14, start with the two questions this whole article keeps circling back to: what is your actual availability requirement for each critical system, and what evidence do you have that your current architecture meets it under real conditions, not just on a diagram? Everything else — thresholds, forecasting cadence, redundancy pattern, test schedule — falls out of honest answers to those two questions. Our Annex A — All 93 Controls at a Glance cheat sheet is a useful reference for seeing where 8.6 and 8.14 sit relative to every other control as you build out your Statement of Applicability, and our ISO 27001 Risk Register Template gives you a starting structure for tracking availability risk alongside every other risk in your ISMS rather than managing it in a separate spreadsheet.

For teams earlier in the journey — still mapping what "applicable" means for their environment — our Complete ISO 27001 Implementation Guide eBook walks through sequencing controls like these against a realistic project timeline, our ISO 27001 Mandatory Documents Checklist keeps the required documentation (including capacity plans and continuity evidence) from slipping through the cracks, and our ISO 27001 Gap Analysis Tool will flag exactly where your current monitoring and redundancy posture falls short of what a certification body will expect — before an auditor finds the gap for you. If any term in this article — RTO, RPO, availability zone, active-active — wasn't immediately familiar, our ISO 27001 Glossary of Terms is worth bookmarking alongside the rest of your working documentation, and it's a good companion to keep open while working through the certification process itself, covered end to end in our ISO 27001 certification process roadmap.

Dana Okonkwo-Reyes put it best, looking back on the year since the Thanksgiving outage: the fix was never really about buying a bigger database or a fancier dashboard. It was about treating "will this stay up" as a question the organization answers deliberately, on a schedule, with evidence — instead of a question that only gets asked, expensively, after the answer turns out to be no.