Sales has opportunities. Uber has trips. Hospitals have patients and beds. Naval Aviation had gripes and readiness reports. Cybersecurity handed me a pile of alerts and called it a job, and I have spent 24 years unwilling to accept that.
I learned what work is supposed to look like on a flight line. As a young Aviation Electronics Technician, every piece of work my shop touched had the same shape. A discrepancy got written up. The write-up became a job. The job pointed at a publication that told us, step by step, how that specific work was done and what "done" meant. And when the job closed, it rolled up (along with every other job in the squadron) into readiness reporting that told the commanding officer whether we could fly and fight, and told the Navy where to invest. A 19-year-old with a soldering iron and an admiral reading a readiness brief were looking at the same object from opposite ends. (I wrote about those years from a different angle in Dragon 305.)
The idea of a unit of work was not unique to Naval Aviation. It is in every mature craft in the world. When I worked in sales, the work was managed as opportunities to chase. When I get into an Uber, the work is created, priced, and measured as a trip. When I go to the hospital, the work is organised around patients and beds. In each case the unit of work does two jobs at once. It defines how the work is done (the documented processes, the training, the tooling all hang off it). And it gives the broader business a handle on what the work means (the metrics, the staffing, the investment, the reporting all roll up from it).
The craft with no unit
When I transitioned out of Naval Aviation and into cybersecurity in the US Navy, 24 years ago, I was in for a large shock. There were no units of work. There were no publications on how to do the units of work (there was no agreed shape of the work to write one about). There was no way to roll situation reports up the chain of command so that someone with a budget could see how we needed to invest in operational readiness. It felt less like joining a new craft and more like arriving before the craft existed.
So I started keeping a list of what the right unit of work would need to be. It was two items long:
- Specific enough that the people doing the work could lean on documented processes written for that work.
- Legible enough that the broader business (in my case, the chain of command) could understand the impact of that unit of work.
Underneath the list sat a warning that still holds: get the unit of work wrong and everything downstream goes wrong with it. The training is wrong. The tooling is wrong. The investments are wrong. And your ability to explain what your team is doing (the thing that keeps a security programme funded) will always be insufficient.
The alert is not the work
The tools on the market back then mostly picked a unit anyway, and most of the tools informing security operations today still run on it: the alert. A tool receives an alarm from another tool, wraps a little context around it, and queues it for a human. Count the queue and you have "metrics."
Alerts fail both of my requirements. The business does not understand them (I have never met an executive who wanted a count of alerts, though I have watched plenty get handed one). And they are too small to be the scope of an investigation and an incident response cycle. An alert is a doorbell. It is not the visitor, not the conversation at the door, and not the reason someone came to your house. I was grumbling about this back in 2014 in When An Alarm Isn't, and by 2016 I was trying to measure the real work in Metering Incident Response 101. The doorbell count never got more useful.
Meetings with the base police
Here's the thing about my path that I did not appreciate until years later: I got lucky in where I landed. As the Network Security Officer at the US Naval Postgraduate School, the emphasis of my role was on the security, not the network. That made my job unusual among my peers. My department meetings were with the base police and Naval Intelligence. The questions on the table were where arrests needed to be made and which reports needed to be rolled up as national-security concerns. We were not talking about patching vulnerabilities or blocking packets. My team had the authority to arrest people on base and coordinated with law enforcement beyond it, so my focus was crime, and explaining what was happening on base to the Security Director.
That meant translation. I had to convert what my team was seeing on the wire into units the Security Director understood, and his units were a police department's units: crimes, cases, evidence, suspects. What formed very quickly was the need to group the attacks and incidents into units that reflected how someone was trying to commit a crime. Law enforcement has had a name for that for more than a century: the modus operandi.
A unit of work shaped like a case file
In 2016, when we started the research at WitFoo, this became the most important and most central question we worked on: can you build a unit of work that maps to the attack types a security operations centre actually sees? That research produced the methodology we call Empathetic Processing (modelling how the analyst reasons instead of forcing the analyst to reason like the tools) and, inside it, the discipline we call Temporal Link Analysis.
Temporal Link Analysis looks at all of the signals and builds a graph of every relationship observed: all the users, all the computers, all the services, all the files, all the emails, and all the relationships between them. It is the same thing a detective does with evidence about a specific crime (a corkboard and string in the movies; a case-management system in real life). Then we pose theories of crime to that graph. Was this data theft? Extortion via ransomware? Trespassing via phishing? The evidence gets analysed the way an investigator analyses it: does what we observed support the theory of the crime, or not? (The theory sits in Empathetic Processing and Temporal Link Analysis from November 2025, and the courtroom version of the argument sits in Which Detective Would You Hire?)
Ten years of evidence
That was 10 years of research ago, and it has proven out in a direction that still delights me: the more evidence we put into the model, the better it gets. More signals means less triage, not more. Feed the graph everything and it gets denser, the theories get easier to test, and the modelling gets more effective. (This is the opposite of how alert-centric tools age, where every new data source is a new tax on the humans.)
Building units of work that group evidence based on a theory of crime also have a solution to the industy's three largest problems:
1) it improves clarity of what is happening
2) it reduces the units of work (through graph deduplication) by more than 98%
3) it enables reliable automation via AI or AI assisted workflows
Bank robberies and kidnappings
Finding the right unit of work bought back the thing I had been missing since the flight line: playbooks that map to the work. Police do not respond to a bank robbery the way they respond to a kidnapping. Same profession, same badge, completely different procedures, skills, tempo, and definitions of success. Incident responders should not work a data-theft case the way they work a ransomware case, either. Data theft is a quiet exfiltration problem; ransomware is a loud extortion problem; the clocks, the skills, and the stakes are different. A unit of work based on attack types is what makes it possible to write, drill, and improve playbooks for each (my longer grumble about automation and playbooks lives in 18 Years of Getting SOAR to Fly).
And the business side finally works too. A sentence like "we saw nine data-theft attempts and two extortion attempts this quarter; all 11 were disrupted, and here is which controls did the disrupting" is a sentence a board, a CFO, an insurer, or a Security Director can act on. It reads like a police blotter, not a syslog. Training lines up behind it (you train responders on attack types, the way detectives specialise), tooling lines up behind it, and investment lines up behind it, because you can finally put money where the crime pressure actually is (I offered some math for that back in Math for Calculating Tool ROI). That was my two-item list from 24 years ago, satisfied in both directions.
Wrap Up
Every mature craft has a unit of work that defines how the work is done and tells the business what the work means. Cybersecurity's unit of work is not the alert. It is the incident, grouped by the crime being attempted (the modus operandi), carrying its evidence with it. It took a maintenance bay to teach me that work needs a unit, a police department to teach me what the unit should look like, and 10 years of research at WitFoo to make it real. If you operate or fund a SOC, ask what your unit of work is. If the honest answer is "the alert," then your training, your tooling, your investments, and your board reporting are all quietly inheriting that answer. Sit with that question for a moment. Then go ask your team what they would pick instead.
