Nobody in this story is real. It follows an invented, deliberately ordinary pair of IT staff at an imaginary outpatient heart centre, and their month is a composite of situations that smaller healthcare organisations meet when a serious software flaw hits the news. Follow them for four weeks and you will see what VulnerabilityOps looks like in practice: a working routine for sorting, assigning, proving and measuring fixes, not a slogan on a slide.
The setting is administrative. Appointment booking, a records archive, staff email, a visitor wi-fi network and a handful of vendor-managed boxes in a cupboard. Nothing here touches care decisions, and nothing here is clinical advice.
Week one: the afternoon everybody asks “are we affected?”
On a Tuesday, a widely used open-source logging component is reported to have a flaw that attackers can abuse remotely. By three o’clock the centre’s director has forwarded two news links and asked a reasonable question. Are we affected?
The two-person team, call them Asha and Dev, discover that they cannot answer. They have a list of servers but no list of what software sits inside the applications on those servers. They spend the evening opening vendor documentation and phoning suppliers. By Thursday they have a partial answer and a tired feeling that most of it was guesswork.
This is not a made-up difficulty. The Ops Atlas entry on VulnerabilityOps recalls the real Log4Shell episode of December 2021 and the federal review that followed. One government department reportedly spent 33,000 hours responding, and the review found that organisations holding software bills of materials said none of them had used the documents to find the affected component. The Atlas draws a simple benchmark from this: a team should be able to locate a dependency within minutes, not days.
Week two: tiers, owners and a first deadline
Asha proposes a modest reform. Every finding, from now on, gets three answers before anybody works on it. Who can reach the system, strangers online or only staff? Has the flaw already shown up in the catalogue of weaknesses attackers are known to abuse? And if someone did abuse it, would they gain full control or only a sliver?
With those three answers the sprawling list falls into groups. The booking website is exposed. The records archive is internal. The visitor wi-fi controller is exposed, but the flaw affecting it is minor. Dev drafts a one-page policy with three tiers and a due date for each. He borrows the shape from the federal directive that came out in June 2026, which the Atlas summarises: the clock depends on exposure, on exploitation evidence, on whether abuse can be automated, and on technical impact. The directive applies to US federal agencies only, so the centre treats it as a model and not an obligation.
Crucially, each item gets a human name beside it. Asha owns the web booking tier. A supplier contact owns the vendor appliances, and the supplier agrees to a date in writing. The Atlas calls this a dated owner queue, and the team finds that merely having names changes the tone of weekly meetings.
One awkward discovery comes out of the tagging exercise. Eleven machines have no tag at all because nobody remembers what they do. Rather than debate each one, Dev adopts a blunt default that the Atlas also uses in its local policy variants: an untagged asset is treated as publicly exposed until someone proves otherwise. The effect is immediate. Owners who had ignored requests for months suddenly want to explain, in detail, what their forgotten server does and why it is safe to treat as internal. The default is a nudge, and it turns an invisible problem into a conversation.
The team also agrees on a second rule from the same source. A person reviewing findings may promote an item to a more urgent tier if experience says it deserves it, but nobody may demote an item without the owner’s written agreement. It sounds bureaucratic until the first time a busy afternoon tempts someone to quietly downgrade a nuisance.
Week three: the ticket that was “done”
Midway through the month a ticket for the booking site’s component is marked resolved. Dev, who has been reading about closure rules, asks a question that irritates a colleague: “What shows it’s fixed?” The answer is that a developer said so.
The team decides that nothing counts as closed without evidence from the system. A new scan, run with a login so that it can see inside, must come back clean, or a configuration test must pass, or a rebuilt image must carry a different digest. When they rescan the booking site, the old component is still present in a second copy that nobody had noticed. Had the ticket been trusted, the exposed server would have kept its hole for months.
There is a related lesson in the Atlas from a 2023 appliance flaw: the fix definition must sometimes include extra steps beyond installing the update. In that case, sessions that had already been hijacked stayed alive after patching, so the vendor advised ending all active sessions as well. Asha adds a line to the hand-off template that asks, for each item, whether anything already compromised could survive the fix.
Week four: measuring flow, not just the pile
At the monthly review the director wants one number. Dev offers two. For each tier he reports how many new findings arrived and how many were verified closed. For the exposed tier, eleven came in and twelve closed, a ratio under one, so that queue is shrinking. For the larger internal tier, arrivals ran well ahead of closures, a ratio above one, which means the backlog is growing and the sixty-day promise will slip unless something changes.
The Atlas uses the same idea and adds Little’s Law, an old queueing rule that says the time an item waits is roughly the number waiting divided by the rate at which items are cleared. With a backlog that big and that slow a closure rate, the arithmetic shows the wait running past the deadline. Dev takes this to the director not as a failure but as a staffing and automation question: which one repetitive class of finding could be handled by a script?
He also reports coverage. Two machines had silently lost their scanner credentials. Without that check, the month would have ended with a happy chart and two unexamined servers.
The month ends with a small ritual. Asha and Dev sit with the director and read out three figures: the time it took to answer the original “are we affected?” question the second time round, the share of systems that were scanned with working logins, and the number of items closed with evidence. They do not claim victory. They agree that the next month’s goal is a single automated check, a daily comparison of their inventory against the public list of actively exploited flaws, so that the next headline gets a two-minute answer instead of a two-day one.
Notice that the story never required a new product. It required a list, a policy page, a handful of names, and the willingness to check whether a fix had worked. Plenty of small organisations never get past the first step because the work looks too large, yet the work only ever arrives one finding at a time.
What the story shows about VulnerabilityOps
Four habits carried the team through, and none of them needs a large budget:
- Know where things live. An inventory with exposure tags turns “are we affected?” from a day-long scramble into a lookup.
- Sort by evidence of use. Reports of real-world exploitation outweigh estimated likelihood, and likelihood outweighs a generic severity label.
- Close by proof. Status fields are opinions; rescans and configuration tests are facts.
- Measure arrivals against closures. It is the one comparison that reveals whether you are keeping up.
Reading on from here
For background on the digital side of cardiology services, there is an overview of how digital tools sit within heart services on this blog, and for the engineering angle, a primer on learning an automation server for modern software delivery. Both will help non-specialists see why the invisible layer of software deserves the same discipline as any physical routine.
If your own organisation looks anything like the imaginary centre, the first move is small. Next time a headline about a software flaw lands in your inbox, time how long it takes to answer “are we affected?” Write that number down. Then check it again after you have tagged your systems and named your owners. The change between the two numbers is the most convincing argument for running the work as a flow.
