What happens between the scan and the install — eight steps

The question that comes up in every first conversation is "so what exactly do you do that the scanner does not". The best answer I have found is not a definition but a sequence. Here it is.

1 · The list arrives

The input is an export from the scanner or from the security operations team: one row per vulnerability-and-affected-host pair. The same CVE appears thirty times, once per machine.

That shape is right for scanning and wrong for planning. You cannot schedule a vulnerability.

2 · Group by the patch

The schedulable unit is the patch: a cumulative update, a version, a package. One patch usually closes many vulnerabilities across many hosts at once.

That inversion — from a row per vulnerability to a row per patch — is what turns a list of thousands of lines into a few dozen items a person can hold in their head. It also changes the conversation with the system owner: instead of "you have seventeen vulnerabilities" it becomes "there is one update and it needs a reboot".

3 · Rank against business impact

CVSS measures the technical severity of the flaw. It knows nothing about the system it sits on, and that is by design — it scores a vulnerability, not a risk.

A usable ranking combines at least four things: severity, the host's external exposure, the business criticality of the system (BIA), and how long it has been since the last update.

More important than the formula is that it is visible. Nobody trusts a closed score. A score that shows its components — each one and how many points it contributed — is a conversation, and that is exactly the conversation you need to have with an owner who is resisting a date.

4 · Propose a window

Now a date can be proposed. What goes into it:

• Cadence — each host has a rhythm derived from its tier. Externally facing systems on one, internal systems on another.
• Next due — when the next window should open, from the last update and the cadence.
• Forbidden periods — change freezes, quarter ends, known peak days.

5 · The owner's approval, in writing

The system owner receives a calendar invitation. Not an email asking them to approve — an invitation with an accept button.

In practice you need two copies of it, and this is where many implementations fall over: a meeting organiser cannot accept their own meeting. So one copy goes out on behalf of the coordinator to the owner and the contacts, and a second goes to the coordinator alone from the system address, so their calendar fills too. The two carry different UIDs, or they overwrite each other.

6 · A reminder before the window opens

The single most useful message in a system like this is an SMS a few hours before the outage, to the system owner's phone. Not to ask for another approval — so that nobody discovers in the morning that their system was down.

7 · Execution against a checklist

At three in the morning, at the end of a shift, memory is not a working tool. The checklist is the form the team fills in as they go: service stopped, backup taken, update installed, rebooted, verified, service restored.

When the checklist closes, a summary goes to everyone who touched it — the owner, the contacts, the coordinator. That closes the loop without anyone having to remember to write an email.

8 · The evidence

At the end of the process the following exist, with no extra effort: who approved and when, what was done and by whom, what failed and what was done about it, and the patch state of every system. That can be exported and handed over.

What is not in this sequence

Regulaxy does not scan. It does not push updates. It is not a CMDB. It takes the list from the scanner, hands a date to whoever installs, and owns what happens in between.

That boundary is deliberate. Most tools in the category try to be both ends and skip the middle, and the middle is exactly where the schedule breaks.