Function-level case study
Modeled · illustrative scenario
Transforming a Security Operations Center.
A full applied case.
The thesis · in one line
Modeled shift reallocation: ~0 → ~5 proactive hours of 8 — the same workforce, the same data, the alert backlog no longer claiming the analyst’s day.
Per-incident handling time modeled at 26–65 min → 13–28 min (−55% to −60%). Full table in section H below. Modeled · illustrative.
This is the first applied case study in the methodology. It documents how an AI-native skill substrate transforms one specific security function — Security Operations — end to end. The same approach extends across the remaining AI Controls Matrix (AICM) control domains, but Security Operations is where the work is most developed and where the before-and-after contrast is sharpest. Read it as the worked example. The framework chapters generalize from here.
This is a constructed case, not a named client engagement. The operational patterns, time estimates, and transition dynamics are drawn from the methodology and its working library. Numbers are illustrative; specific outcomes will vary with team size, alert volume, tooling maturity, and implementation discipline.
Situation
Your SOC’s day is consumed by reactive work; the backlog owns the calendar.
Complication
Every improvement pitch asks you to buy something new — and none shows what the same team could reclaim with the tools already owned.
The question
“What would the same workforce look like if the reactive load were cut in half?”
The answer
A modeled full-function transformation: per-incident handling time −55–60%, roughly zero → five proactive hours of eight — same people, same data. Modeled, illustrative, labeled.
The trap.
Modern Security Operations Centers (SOCs) are structurally stuck, and the structure is the problem. Alert volumes generated by modern detection infrastructure outpace analyst capacity by orders of magnitude. A reasonably-staffed tier-one team in an enterprise SOC handles thirty to fifty alerts per analyst per shift; the underlying telemetry generates hundreds of times that. The gap is bridged by aggressive filtering, suppression, and prioritization — which catches what's loudest and misses what's careful.
Inside that gap, most of the analyst's day is mechanical. Pivot to the threat-intelligence platform; look up an indicator. Pivot to the Endpoint Detection and Response (EDR) tool; pull a process tree. Pivot to identity logs; check a baseline. Pivot to network telemetry; check egress. Pivot back to the Security Information and Event Management (SIEM) system; write the disposition. The work that demands senior judgment — investigation, threat hunting, detection engineering, incident-response design — gets squeezed out by the reactive backlog. It does not fit. It cannot fit. The analyst who would do it is already booked.
The conventional fixes do not work for structural reasons. More tooling increases cognitive load and integration debt; each new console is another tab the analyst pivots through. More headcount runs into talent supply, training time, and the unforgiving math that doubling a SOC team does not double its capacity — coordination overhead grows non-linearly with team size, and shift handoffs leak context. Outsourcing the tier-one work moves the problem to a vendor who, structurally, has the same constraints.
The honest reading of the last decade of SOC investment is that the industry has thrown several billion dollars at the alert-volume problem and produced incremental gains where structural ones were needed. The bottleneck is not what the SOC has. It is what the SOC is asked to do with the people it has.
Cognitive reallocation.
The fix is structural, not incremental. A SOC cannot be tooled or staffed out of the trap described in the previous section — both have been tried at scale for a decade. What works is rearchitecting the SOC around a different operating substrate: a structured library of skills that AI agents load and execute alongside human analysts, in the same workflow, against the same data. Each skill is a small, focused unit of senior expertise written down. How to investigate a specific alert type. How to enrich a particular indicator. How to extract evidence from a process tree. How to draft an incident report. Hundreds of these skills, vetted and maintained, become a substrate the SOC runs on.
What this produces is tier compression. Work that previously required tier-three judgment — the kind of cross-source correlation only experienced analysts can do well — becomes executable at tier two, because the senior analyst's reasoning is now encoded in a skill the tier-two analyst's agent can run. Work that needed tier two becomes tier one. Work that consumed tier one becomes largely automated, with the human role moving from execution to validation. The hierarchy does not disappear; it migrates downward. The same workforce handles materially more of the work the SOC has wanted to do for years — proper investigation, hypothesis-driven threat hunting, detection engineering, post-incident learning. The analyst becomes more capable of high-judgment work because low-judgment work no longer claims their hours. This is the transformation. Not headcount reduction. Not efficiency-as-cost-savings. Capability reallocation across the entire tier structure.
AI in the SOC is not about replacing analysts. It is about reallocating where analyst judgment is spent.
The working thesis
The macro before/after.
The transformation is sharpest at the macro level — an eight-hour tier-one analyst shift in current practice, compared to the same shift after substrate adoption. The total hours do not change. The composition of those hours changes.
Roughly sixty to seventy percent of analyst time migrates from low-judgment reactive work to high-judgment proactive work. The reactive categories do not disappear — there are still alerts to triage and false positives to dismiss — they compress. The proactive categories do not appear from nowhere — the SOC has wanted to do this work for years — they become possible because the analyst now has the hours to do them. Multiplied across a team on rotating shifts, this is what transforms the function from one struggling to keep up with alerts into one doing the strategic work its leadership has long described in plans but never had hours to execute.
What the freed five hours produce
The five-phase workflow.
The transformation in the macro view distills into five phases of work an analyst performs on every meaningful alert. Each phase compresses against its current-state cost. Each phase has specific skills that produce the compression. The names below are the canonical skill identifiers as they appear in the public reference library — they are live artifacts, not illustrative placeholders.
Phase 1 — Alert intake and prioritization.
Before. An alert lands in the SIEM. The analyst reads the description, scans for context, applies an internal rule of thumb to decide whether it needs immediate attention or can wait. Priority drift is the norm: the same alert reviewed by two analysts on consecutive shifts often gets two different dispositions. Average time: three to five minutes per alert.
Skills loaded:
After. The agent applies a consistent priority schema based on asset criticality, source confidence, and recent threat intelligence. Related alerts cluster into a single incident view. The analyst confirms or overrides the priority. Average time: under thirty seconds per alert, and queue prioritization stays consistent across shifts and individuals.
Phase 2 — Contextual enrichment.
Before. The analyst pivots through five or six tools to build context. Threat-intelligence platform for the indicators. Identity logs for the user's baseline. EDR for the process tree. Network logs for recent egress. Back to the SIEM to correlate. Each pivot is a context switch; each context switch leaks cognitive load. Average time: eight to fifteen minutes per alert. Critical signals get missed in proportion to how tired the analyst is.
Skills loaded:
After. Four skills execute in parallel; the agent assembles a single contextual view — indicator reputation, baseline deviation, process anomalies, egress patterns — on one page. The analyst reviews the assembled context rather than gathering it. Average time: one to two minutes. The context is complete by design. The lateral-movement signal that gets missed when an analyst is tired of pivoting now sits in front of them on first read.
Phase 3 — Investigation and determination.
Before. The analyst forms a hypothesis from the context they have. Gathers evidence to confirm or refute it. Makes a determination — true positive, false positive, or escalate. Quality varies dramatically by analyst experience. Junior analysts miss subtle indicators that senior analysts catch on instinct, because senior judgment is built on years of pattern exposure that junior analysts have not yet had. Average time: ten to thirty minutes for non-trivial alerts.
Skills loaded:
After. The agent surfaces three ranked hypotheses with evidence already gathered for each. The analyst validates the most likely one — or rejects all three and forms their own. The skills explicitly encode what senior analysts would check, which means junior analysts now execute that same workflow on alerts the library covers. Average time: five to fifteen minutes. Junior-analyst output approaches senior quality on covered scenarios.
Phase 4 — Response and documentation.
Before. On a true positive, the analyst executes containment — isolate the endpoint, revoke credentials, block the indicator, terminate the session. Writes the incident report. Updates the ticketing system. Packages context for tier-two escalation if needed. Quality of documentation varies. Some incidents have rich audit trails; others are minimal. Average time: five to fifteen minutes.
Skills loaded:
After. Containment actions execute with audit trails and reversibility checks built into the skills. The incident report is drafted from the captured context. The analyst reviews and approves. Escalation packages are complete by default. Tier two does not lose half a shift re-gathering what tier one already had. Average time: two to five minutes.
Phase 5 — Learning and continuous improvement.
Before. This phase rarely happens. The analyst closes the ticket and moves to the next alert. Detection improvements come from rare post-incident reviews. Threat-hunt hypotheses get updated infrequently if at all. Institutional learning leaks at the seam between one alert and the next.
Skills loaded:
After. Five minutes per incident captures the learning. The detection-engineering team receives a steady inbound stream of proposed rules from real findings. Threat-hunt hypotheses stay fresh. When an existing skill missed something it should have caught, the gap is flagged for review. The library improves continuously rather than annually. The SOC becomes a learning function in operational practice, not aspirational language.
LOG · Handle one meaningful alert end-to-end across the five-phase workflow (intake → enrichment → investigation → response → documentation)
Security Operations — per-incident handling time
Skills-off vs skills-on, same workflow and data; ranges conservative — well-implemented teams see steeper reductions on mechanical phases
efficiency · Time per incident
Ranges conservative; steeper on mechanical phases (intake, enrichment, response); phase 3 (investigation) more variable — human judgment remains the primary input
effectiveness · Junior-analyst output quality
Qualitative in the modeled case; needs measurement against a senior answer key to substantiate
productivity · Shift time reallocated reactive → proactive
Total shift hours unchanged; proactive categories (investigation, hunting, detection engineering) previously absent due to reactive backlog
Modeled worked example; projected outcomes from the methodology, not a measured engagement. Source: case study at /case-study/security-operations. The case study carries the disclaimer: "This is a constructed case, not a named client engagement. Numbers are illustrative; specific outcomes will vary with team size, alert volume, tooling maturity, and implementation discipline."
Skill-library adoption stages.
The transformation in the previous section is a destination, not a starting point. Real Security Operations Centers move from current state to substrate adoption through five AI Security Maturity Model (AISMM) levels (Initial through Efficient), each with its own work and its own failure mode. The progression below is the realistic adoption path for the skill library, with honest framing of what each transition costs.
L1 · Initial.
The skill library exists as reference material. Senior analysts know it is there; junior analysts mostly do not use it. The library functions as documentation rather than operational substrate. Most SOCs that have done early AI experimentation are here, whether they describe themselves this way or not.
Common failure at L1: the library sits unused, treated as a knowledge-management initiative rather than an operational change. Transition cost from L1 to L2 is mostly cultural — the SOC has to decide that the library is canonical, not optional, and leadership has to reinforce the decision consistently for it to hold.
L2 · Repeatable.
Skills become canonical playbooks. New-hire onboarding references them. Tier-one SOPs cite specific skills by name. The team’s institutional knowledge is now legible to people who joined last month, which is the first concrete benefit leadership can point to.
Common failure at L2: standardization without enforcement. Old habits persist where managers do not actively reinforce the new pattern, and the standardization becomes nominal. Transition cost from L2 to L3 is technical and operational — AI tooling, integration with SIEM and EDR, and training analysts to work with agents rather than around them.
L3 · Defined.
Analysts execute their workflow through an AI agent that loads skills as the work demands them. Productivity becomes measurable: triage times drop, false-positive handling compresses, documentation grows more consistent across the team. This is the threshold where the time-savings story becomes real and defensible to leadership.
Common failure at L3: AI tooling deployed before library quality is high enough. Agents produce inconsistent output because the underlying skills are uneven, and trust in the system erodes before it has a chance to compound. Transition cost from L3 to L4 is the hardest in the model — moving from analyst-led-with-AI to AI-led-with-analyst-approval requires governance decisions, autonomy-boundary definitions, and process maturity that takes deliberate work to build.
L4 · Capable.
The agent handles tier-one triage and routine response autonomously, with human approval gates at material decisions. Tier compression becomes real. Senior analysts shift to investigation, threat hunting, and detection engineering — the work they were trained for and have rarely had time to do. Capacity expands without headcount expansion.
Common failure at L4: organizations push here before fixing library quality issues at L3, and trust erodes from bad autonomous decisions made under inadequate oversight. Transition cost from L4 to L5 is largely architectural — feedback loops from incident outcomes back into the library require infrastructure most teams have to build from scratch.
L5 · Efficient.
The library improves automatically from incident outcomes. Detection rules feed back from phase five. Skills that missed something get flagged for review and revision. The SOC has institutional learning compounding over months and years rather than leaking at the seams.
Most enterprises are three to five years from L5. Some will decide L4 is sufficient and stop there deliberately, which is a defensible choice. The honest framing: L5 is a horizon, not a destination, and reaching it requires sustained investment most security functions will not muster. Naming this openly is more useful than aspirational language that sets expectations the work cannot meet.
Most SOCs should plan a twenty-four to thirty-six month journey from L1 to L3. L4 is achievable in year three or four with sustained investment. L5 is a multi-year horizon. The mistake organizations make most often is treating these as discrete projects rather than capability evolutions — each transition has its own work, and skipping the work at one level guarantees failure at the next.
Implementation blueprint.
Substrate adoption in a SOC is not a single project. It is six phases of work that can be sequenced, paralleled where dependencies allow, and adjusted to local conditions. The week ranges below are realistic for a single pilot SOC team. Scaling to multiple teams adds time at the back end. The deliverable for each phase is what must exist before the next phase can begin.
Phase A — Baseline. Weeks one to four.
Measure the pilot team's current state with rigor. Average triage time per alert, false-positive rate, alerts handled per analyst per shift, time-to-detect for the last ten confirmed incidents, the percentage of analyst time spent on each of the five workflow phases. Capture this data before any change is introduced. Without a real baseline, the substrate's contribution becomes undefendable to leadership later, and improvements appear as opinion rather than measurement.
The deliverable is a baseline performance report — when, in month four or five, the productivity dip arrives, the executive sponsor needs evidence that the dip was expected.
Phase B — Curation. Weeks four to ten.
Identify the twenty to thirty most-invoked workflows the pilot team actually performs. Map each workflow to skills from the library. Author the ones missing. Vet quality through senior-analyst review. This is the L1-to-L2 work: turning inventory into standardized playbooks.
Most SOCs discover during this phase that their actual workflows are not what their standard operating procedures (SOPs) say they are. SOPs describe ideal practice; analysts describe what they do. The skills should match the second, not the first. Curation is where the gap gets closed. The deliverable is a curated set of skills covering the most-invoked twenty to thirty workflows of the pilot team, vetted by at least one senior analyst per skill.
Phase C — Tooling integration. Weeks eight to fourteen, in parallel with Phase B.
Wire the AI agent into the SOC's existing infrastructure. Read access to SIEM, EDR, identity provider, ticketing system. Define autonomy boundaries — what the agent can act on without approval, what requires a human gate. This is the technical foundation for L3 augmentation.
Two integration decisions matter most. First, the agent's read access must be scoped tightly to what the skills actually need, not granted broadly for convenience — security tooling has historically been compromised through over-privileged service accounts, and adding an AI agent to that pattern would be a serious mistake. Second, autonomy boundaries should be conservative at the start and expand only after evidence accumulates. The deliverable is a working agent integrated with scoped read access to SOC infrastructure, with documented autonomy boundaries reviewed by the security architecture function.
Phase D — Pilot deployment. Weeks fourteen to twenty-six.
Roll out to the pilot team. Measure relentlessly against the Phase A baseline. Expect a productivity dip in the first four weeks as analysts learn to work with the agent rather than around it. Plan for this and do not panic when it appears. Measure recovery by week eight. Steady-state improvements should be visible by week sixteen.
The single most common reason pilots fail at this phase is leadership panic during the productivity dip. The Phase A baseline report is the antidote: it shows in advance what the dip will look like and when it will recover. Holding leadership steady through the dip is the principal job of the SOC manager in months four and five. The deliverable is a pilot team operating at steady state with measurable improvement against baseline, documented and reviewed.
Phase E — Lessons captured. Continuous from week fourteen.
Every incident generates feedback into the library. Weekly skill-library health review. Monthly metric review with SOC leadership. This is the L3-to-L4 muscle: the discipline of treating the library as living infrastructure rather than a one-time deliverable.
Most teams underestimate the operational weight of this phase. The library does not maintain itself. Skills drift, become outdated as attacker techniques evolve, or develop edge cases that need refinement. Allocating dedicated capacity for library maintenance — typically one senior analyst at fractional time — is the difference between substrate adoption that compounds and substrate adoption that decays. The deliverable is a maintained library with documented review cycles and named ownership.
Phase F — Scale. Month seven onward.
Expand from the pilot team to other SOC teams. Begin moving tier-one triage toward autonomous execution with human approval gates — careful staged rollout, not all at once. Track expanded metrics across multiple teams. The objective in this phase is institutional, not local: the substrate becomes how the SOC operates, not how one team operates.
Scaling reveals problems the pilot did not. Inter-team handoff patterns vary; shift rotations introduce edge cases; senior analysts in different teams have different priorities and idioms. The library should be updated to reflect what is genuinely common and what is local. The deliverable is an operational substrate adopted across the SOC, with measurable improvements documented at each tier.
The six-phase blueprint above is the realistic shape of a substrate adoption for a single SOC team, taken from current state through stable L3 operation. Total elapsed time runs roughly six to twelve months for the pilot, with scaling adding another six to twelve depending on team count and complexity. The mistake organizations make most often at this stage is compressing the timeline — running Phase A and Phase B in two weeks instead of six, or skipping the productivity-dip planning in Phase D. Each phase exists because the work it captures cannot be skipped without consequences that surface later.
Common failure modes.
The framework documented above is shaped by the ways substrate adoption goes wrong in practice. Naming the failures honestly is more useful than implying they do not happen. Six failure modes recur across organizations that have attempted SOC AI adoption over the last three years. Each has a recognizable shape, a common cause, and a specific countermeasure designed into the methodology.
Failure mode 1 — The library-as-documentation trap.
The most common failure at L1, and the one organizations most often do not recognize as a failure. The library exists; people know it exists; nobody uses it operationally. Leadership describes it as a knowledge-management initiative and treats it as complete because the documents are written. The substrate that would change how work gets done sits in version control, referenced occasionally, never executed.
Prevention is structural. The library must be made canonical — leadership decides, explicitly and publicly, that the documented skills are the operating standard, and tier-one SOPs cite them by name. Without this declaration, the library is a side artifact. With it, the library becomes the operating reference.
Failure mode 2 — Premature autonomy.
Organizations watch a successful L3 pilot, see the productivity numbers, and push the agent to autonomous tier-one operation before the underlying library is stable. The agent makes confident decisions on flawed or uneven skills. Trust erodes after the third or fourth bad autonomous action, and the program retreats — sometimes all the way to L1.
Prevention requires patience that senior leadership often lacks under quarterly metric pressure. The L3-to-L4 transition needs documented agent reliability metrics, autonomy boundaries that expand only after evidence accumulates, and the willingness to wait — frequently six to nine months — before letting the agent operate without per-action approval. Skipping this discipline is the most expensive mistake in the model.
Failure mode 3 — The productivity-dip panic.
Weeks four through eight of the pilot deployment are typically worse than the baseline. Analysts are learning a new workflow; the agent is being tuned; skills are being refined. Productivity numbers, taken at this moment, look like the substrate is not working. Leadership, untrained on the expected shape of adoption, sometimes responds by cancelling or reducing the program.
Prevention is information, given early. The Phase A baseline report should include an explicit prediction of the dip and its expected recovery curve. Monthly reviews during weeks four through twelve should reference this prediction so the dip appears as expected behavior, not as program failure. The SOC manager's principal job during these months is holding leadership steady through measurable but explained worsening.
Failure mode 4 — Library decay.
The library is built, deployed, and then left alone. Months pass. Attacker techniques evolve. Detection logic in the SIEM changes. Skills that worked at deployment now reference deprecated tools or stale signatures. Quality drifts downward, the agent's outputs degrade, and the organization concludes that AI in the SOC does not work — when what stopped working was the maintenance discipline.
Prevention is named ownership with allocated capacity. A senior analyst with fractional time dedicated to library maintenance is sufficient for a pilot team; multiple teams require proportionally more. The library is operational infrastructure and requires the operational care any other infrastructure does.
Failure mode 5 — The over-privileged agent.
In integration urgency, the AI agent is granted broad read access — to all SIEM data, all EDR data, all identity logs — for convenience rather than necessity. The agent becomes a high-privilege identity with credentials that, if compromised, would give an attacker exceptional reach across the security stack.
Prevention is scope discipline. Each skill should declare the minimum data access it requires; the agent's permissions should aggregate to the union of those declarations, not exceed them. The security architecture function reviews and approves the agent's permissions on the same standard applied to any other privileged service identity. Adding an AI agent to the security stack does not change the principle of least privilege; it makes it more important.
Failure mode 6 — Compression without substance.
The least visible failure, and the one most likely to discredit the project broadly. Leadership claims time-savings of fifty to seventy percent in executive forums. Ground-truth measurement at the analyst level shows ten to twenty percent. The gap is explained by selective sampling, optimistic skill modelling, or quiet exclusion of edge cases. When the gap is eventually noticed — by an audit, a board question, or a comparison with another team's numbers — credibility for the entire substrate approach collapses.
Prevention is measurement rigour. The Phase A baseline is taken with the same statistical care a product team would apply to a feature-launch experiment. Phase E measurement is continuous and reported honestly, including the variability across analysts and alert types. Underclaiming protects the project; overclaiming kills it.
None of these failure modes is hypothetical. Each is observable in organisations that have attempted SOC AI adoption over the last three years. The framework documented on this site is informed by them. The adoption stages on the AISMM scale, the implementation blueprint, and the measurement discipline are responses — specific countermeasures designed into the methodology because the failures preceded the methodology.
One case, one domain.
Security Operations is the worked example here because the substance there was most developed and the before/after contrast was sharpest. The methodology — operating substrate, AISMM adoption path, measurement discipline — is universal. The remaining AICM control domains in the library follow the same structural logic with domain-specific skills. Subsequent case studies will document those transformations as the work in each domain matures.
What changes domain by domain is the catalogue of skills. What stays constant is the substrate, the AISMM scale that paces library adoption and domain maturity with one vocabulary, and the discipline of measurement that protects the work from its own enthusiasm. The framework holds. The applications expand.
End of case study.