Why Process Flow Visibility Exists
For years, cybersecurity addressed complexity by adding people. That worked while budgets and headcount expanded. The executive mandate has changed — and it creates a question tooling alone cannot answer.
Complexity was solved by adding people. That era is over.
More tools meant more administrators; more alerts, more analysts; more vulnerabilities, more engineering. Boards now want better outcomes, improved detection, lower cost growth, and risk explained in business terms.
If you cannot simply add people every time complexity rises, a harder question appears: how much capacity is already trapped inside the way work flows? That is where operational visibility becomes a security leadership issue — not a cost-cutting exercise, but a way to recover capacity and improve outcomes.
Borrowed math, new decomposition
PFV introduces no new Lean mathematics. Process Cycle Efficiency — the ratio of active processing time to total elapsed time — is established Lean practice, codified by Michael L. George (Lean Six Sigma, McGraw-Hill, 2002) and applied to security-adjacent work by Carnegie Mellon’s Software Engineering Institute (Brown, 2021), which defines flow efficiency for the DevSecOps value stream. The principle that elapsed time in knowledge work is dominated by queue time rather than active processing is core Lean (Womack & Jones; Kersten). Applying value-stream analysis to security operations is likewise established — SEI to the DevSecOps pipeline, DORA to the incident-response recovery value stream, and commercial tooling (ServiceNow, Opus, Kissflow) to IT and security workflows.
PFV’s contribution — the unit and object of decomposition
- Per-step PCE across the security control portfolio, rather than a single flow-efficiency figure for one value stream.
- The defender’s detect-and-remediate path as the mapped value stream, rather than the build-and-deliver or recovery pipeline.
- Operationalization as a quantified diagnostic linking per-step queue time and remediation latency to financial impact, where the prior art generally terminates at process definition or workflow automation.
Sources: George, Lean Six Sigma (McGraw-Hill, 2002); Brown, Taking DevSecOps to the Next Level with Value Stream Mapping, SEI/CMU (2021); DORA value-stream management guidance; Womack & Jones, Lean Thinking (Simon & Schuster, 1996); Kersten, Project to Product (IT Revolution, 2018); Little, “A Proof for the Queuing Formula L = λW”, Operations Research (1961); Hubbard, How to Measure Anything (Wiley, 2007; 3rd ed. 2014, calibrated 90% intervals); Hubbard & Seiersen, How to Measure Anything in Cybersecurity Risk (Wiley, 2016); Harris, How Many Parts to Make at Once (1913, economic order quantity); Reinertsen, The Principles of Product Development Flow (Celeritas, 2009, queueing, WIP constraints, and flow control).
From pressure to measurement
Once you accept that delay creates exposure, the next step is to measure it — to separate the active work from the waiting, and to see where outcomes actually slow down.