Adaptive Capacity¶
Adaptive Capacity is whether the system as a whole can absorb a surprise it was not designed for and keep working. It is the condition that used to be called Continuous Learning, named now for what it actually is. The other four conditions each map to a function you can put on an org chart. This one does not. You assess whether the system has it. You cannot hand it to a team.
The idea comes from ecology¶
In 1973 the ecologist C.S. Holling drew a line between two things people had been treating as one. Stability is how fast a system returns to where it was after a small disturbance. Resilience is something else: how much a system can absorb and reorganize around before it becomes a different system altogether. A forest that burns and regrows is not stable while it burns; it is resilient. The capacity lives in the whole web rather than in any single tree, and it is never finished, because the system and the things stressing it keep changing against each other.
Security works the same way. A field of practice grew up carrying Holling's insight out of ecosystems and into engineered ones: Erik Hollnagel reframed safety as the presence of adaptive capacity rather than the absence of failure, David Woods described resilience as graceful extensibility at the brittle edges of a system, Richard Cook catalogued how complex systems fail and keep running anyway, and Kelly Shortridge made the case for treating security as ecology rather than enforcement. The full citations are in the references. The throughline is one claim: a system you certify once and trust to hold is already falling behind, because the things trying to break it keep changing while it stands still.
That throughline is a bet, and it is worth saying what would make it wrong. Adaptive Capacity earns its place only in a world where the threats keep moving. If the landscape ever froze, a system you certified once would hold, and this whole condition would be dead weight. The wager SF² makes is that it does not freeze: adversaries pick up the same automation defenders do, and the pace of change is itself the thing being defended against. Treat that as the assumption to check, not a law of nature.
The sturdier half of this needs no adversary at all. Your own system does not hold still: it grows, and as it grows it outruns the people who understand it, so the picture you hold of your own attack surface goes stale on its own. That alone would keep you tending, even against an enemy that never improved. The threat side only adds to it, and in more ways than the obvious one. Attackers do not have to get smarter for the landscape to change. There can simply be more attackers, because the same automation that helps you lowers the cost of attacking you, and old tools recombine into attacks no one had to invent. The mechanism does not rest on attackers getting cleverer. It rests on two things that move on their own: a system you cannot fully hold, and a threat surface that widens even when no single attacker sharpens.
What it looks like, present and absent¶
You cannot install Adaptive Capacity, but you can see it. It shows up as a blameless post-incident review that actually changes something, not as a document filed and forgotten. It shows up as feedback loops that shorten over time, and as the organization sensing a shift in the threat landscape and adjusting before it gets hit rather than after. It is the difference between learning from an incident and merely surviving it.
When it is missing, the other four conditions can each look fine on a maturity chart while the system stays brittle, because nothing is teaching it to bend. The reviews happen but nothing changes. The same class of incident recurs under a different name. The program is busy and not adapting. Without it, you are just repainting the same four walls on a fixed cadence.
Why it runs across the other four¶
Adaptive Capacity is how all four of the other conditions improve at all. It is the health of all four at once rather than a fifth lane staffed beside them, the question of whether Supply Chain, Third-Party, Process, and Runtime are getting better faster than their failure modes are. A maturity chart can tell you whether each condition is filled in. Only Adaptive Capacity tells you whether the system is still adapting faster than the things trying to break it, and that is the question worth asking.
The seam to the Coadaptive layer¶
This is where the base framework meets the Coadaptive Security layer. The contest between a system that keeps changing and adversaries who keep changing in response is the same predator-and-prey pressure that runs through any living system, and it sharpens once the system includes AI that writes, decides, and acts. Adaptive Capacity is the condition that carries the base framework up into that layer. It is the reason SF² treats security as something a system keeps doing rather than a state a system reaches.
This chapter says security is never finished. The Coadaptive layer says something that sounds like the opposite: you can prove a hard limit on what one component is allowed to do, and that limit holds without tending. Both are true, because they describe different things. You can prove a part. You cannot finish the whole. A single component has a fixed job, so you can bound it and trust the bound. The system those components add up to keeps meeting new surprises, and they land at the seams between the parts, where no single proof reaches. So you prove each piece and you tend the system. Neither move does the other's job.
Next Steps¶
You have now worked through the five universal security conditions. The next section is how you decide which version of tending each one your organization can actually sustain.