Organizational Context

This case examines Department of Defense cybersecurity operations conducted across a highly distributed enterprise: combatant commands, military services, defense agencies, bases, deployed environments, cloud platforms, weapons-system support networks, and mission-partner connections. Cyber work is performed by a mix of government teams and contractors operating SOCs, cyber protection teams, network operations, vulnerability management, and compliance functions.

Cybersecurity work arrives continuously through automated detections, user reports, threat intelligence, vulnerability scans, audits, and mission-driven change events.

• Thousands of alerts and anomalies are generated daily across environments of differing classification and mission criticality.

• Standard tools, severity ratings, and playbooks exist, but day-to-day execution varies by team, mission tempo, and local norms.

• Escalation behavior often substitutes for shared classification logic.

• Cycle time, containment decisions, and outcomes are inconsistent even for events that appear similar on the surface.

Leadership sought faster response and better outcomes, but the deeper problem was that individual cyber events were being treated as equivalent when they were not.

How the Work Was Intended to Function

From an executive viewpoint, cybersecurity operations were assumed to function predictably:

• A cyber event is detected by sensors or reported by users.

• Analysts triage the event using standardized severity and categorization criteria.

• Events are escalated through predefined tiers based on severity.

• Containment and remediation follow established technical playbooks.

• Post-event reporting and lessons learned feed control improvements.

Because tools, policies, and escalation ladders were in place, the system appeared controlled at an aggregate level.

What Was Actually Happening

Observed reality diverged materially:

• Two cyber events with similar alert signatures could receive very different handling depending on who detected them and where.

• Severity ratings were applied inconsistently and were often influenced by urgency, visibility, or seniority of the affected organization.

• Teams developed informal workarounds—direct calls, side chats, ad-hoc coordination—to bypass perceived bottlenecks.

• Containment actions were delayed or avoided to reduce operational disruption, without explicit framing of the tradeoffs involved.

• Judgment-heavy events were sometimes processed as if they were routine, while routine events were escalated as crises.

• Trust eroded as operators and commanders experienced cyber as either overreactive or dangerously slow.

The underlying issue was not tooling or staffing, but the absence of a shared way to interpret an individual cyber event before attempting to optimize response.

How FLOW Was Introduced

Leadership sought a way to stabilize execution without redesigning the cyber enterprise. Specifically, they wanted:

• A common language to explain why cyber events behave differently.

• A method to separate prioritization from urgency, noise, and visibility.

• A lens focused on the individual event decision rather than averages and queues.

• A way to align ownership and governance to impact breadth rather than escalation pressure.

FLOW was introduced as a classification lens applied before routing, escalation, or optimization decisions were made.

Identifying the Unit of Effort

The organization shifted analysis away from alert volume and toward a single, stable unit of work:

• Unit of Effort: One cyber event requiring triage, decision, and disposition.

• The unit begins when a signal is received and ends when the event is dispositioned with accountable documentation.

• Multiple alerts, logs, or detections may relate to the same unit without creating additional units.

• The unit does not change as impact expands; only the handling and governance change.

How Complexity Was Determined

Complexity was defined strictly as the amount of judgment required to evaluate, contain, and resolve one cyber event.

• Low complexity: clear indicators with known playbooks and minimal interpretation.

• Higher complexity: ambiguous signals requiring interpretation and correlation.

• Higher complexity: meaningful tradeoffs between containment options with mission impact.

• Higher complexity: need for specialized expertise such as malware analysis, cloud forensics, identity engineering, or OT constraints.

This definition of complexity was applied uniformly across all FLOW levels.

How Scale Was Determined

Scale was defined as the breadth of organizational impact created by one cyber event.

• Number of systems, enclaves, or organizational elements affected by the event’s outcome.

• Degree of downstream dependency if the event is mishandled.

• Coordination and visibility required to execute containment cleanly.

• Extent to which the event constrains future operational or architectural options.

Events confined to a single enclave were treated as low scale; events cascading across commands, partners, or core services were treated as higher scale.

Other Measures of Scale Considered

• Tool-generated severity scores.

• Alert counts or correlation volume.

• Time pressure or perceived urgency.

• Classification level or media visibility.

These measures remain operationally useful, but were not used as the primary definition of scale in this walkthrough.

Applying FLOW to Real Cybersecurity Events

With complexity and scale definitions fixed, each cyber event was classified using the same logic. The unit remains constant across all examples; only the impact surface and judgment requirements change.

• Classify complexity first.

• Classify scale second.

• Assign the single FLOW classification that best fits the unit.

FLOW A — Local, Contained Events

This example involves one cyber event. The unit does not change.

Example: a single workstation triggers an endpoint protection alert for a known commodity malware signature, and the file is automatically quarantined.

• Complexity: low (clear signature and disposition path).

• Scale: low (one host; minimal downstream dependency).

• Handling implication: minimal oversight; rapid closure is appropriate.

Built-out handling: the analyst validates the signature match, confirms quarantine success, checks the host for obvious lateral movement indicators, ensures user credential hygiene if needed, documents the disposition, and closes the event. No cross-team coordination is required.

FLOW B — Broader Operational Impact from One Event

This example still involves one cyber event. The unit remains the same; the impact surface expands.

Example: a single detected phishing event reveals a common lure and indicators showing coordinated targeting across multiple bases and units.

• Complexity: low (known tactic; established playbooks exist).

• Scale: moderate (multiple units affected; coordination required).

• Handling implication: greater visibility and coordinated execution.

Built-out handling: analysts extract indicators from the event, push enterprise email and web blocks, coordinate with email administrators, issue user guidance, search for related credential submissions, initiate targeted password resets or MFA enforcement, and coordinate reporting. The distinguishing factor from FLOW A is not deeper analysis, but synchronized action across organizations.

FLOW C — Complex, Judgment-Driven Events

This example still involves one cyber event. What changes is the amount of judgment required.

Example: suspicious privileged authentication activity appears in a cloud environment, but indicators are ambiguous—the activity could represent misconfiguration, authorized testing, compromised credentials, or an adversary using legitimate tools.

• Complexity: high (interpretation, correlation, and tradeoffs are required).

• Scale: low-to-moderate (impact may be localized, but consequences of error are high).

• Handling implication: slow down for analysis; speed-first handling increases rework and risk.

Built-out handling: analysts correlate identity logs, conditional access policies, device posture, token usage, and administrative changes. They validate authorized change windows, assess containment options that could disrupt mission services, and may involve specialized expertise. Evidence preservation and counterintelligence considerations may also be required.

FLOW D — System-Level Impact from One Event

This example still involves one cyber event. The unit remains unchanged; the dependency surface becomes enterprise-wide.

Example: compromise or credible suspicion of compromise of an enterprise identity provider or zero-trust enforcement layer supporting multiple commands and mission systems.

• Complexity: variable (some actions may be standard; diagnosis may be complex).

• Scale: high (organization-wide dependency and cascading impact).

• Handling implication: elevated governance and careful sequencing.

Built-out handling: response becomes an organizational sequencing problem. Leaders may need to authorize global token revocation, password resets, service account rotations, emergency policy changes, and coordinated downtime. Mission owners, communications teams, and continuity planners must be engaged because one event constrains many downstream options.

FLOW S — Exceptional Events

This example still involves one cyber event, but normal governance pathways are inappropriate.

Example: an active, time-sensitive intrusion in a weapons-system support or safety-critical environment with potential operational or life-safety consequences.

• Complexity and scale vary.

• Handling implication: explicit exception authority under urgency.

• Key risk: bypassing controls without accountable exception pathways.

Built-out handling: immediate containment actions may be required that normally demand approvals. Emergency cross-domain coordination, counterintelligence involvement, and command-level decisions occur in parallel. FLOW S is defined by the need for a special handling pathway, not by severity alone.

What Changed After FLOW Classification

• Prioritization disagreements decreased because impact breadth was visible and shared.

• FLOW A events moved faster without unnecessary escalation.

• FLOW B events received consistent coordination, reducing repeated compromise.

• FLOW C events received the judgment required, reducing rework and miscontainment.

• FLOW D events gained governance appropriate to systemic impact.

• FLOW S events were handled through explicit exception pathways.

Organizational Implications

• Escalation became purposeful and tied to impact breadth.

• Ownership aligned to the type of event and required judgment.

• Runbooks became FLOW-aware rather than generic.

• Metrics became meaningful because like work was compared to like work.

• Trust improved because the system became explainable.