What your diagnostic report looks like.

The example company's answers draw a familiar picture: 45 people, one internal person running technology alongside another job, and an inventory of devices and access that lives partially in a spreadsheet. Backups exist but have never been restored, multi-factor authentication covers only some of the team, and updates get applied when something breaks. No incident in the last year — which the report treats as good luck to build on, not as evidence of safety.

The same answers also show where money is leaking quietly: several hours a week, in more than one area, go to repetitive manual work — orders received by email and re-typed into the inventory system. That combination of open security basics plus visible manual load is what places the company at the Developing level: the operation works, but it depends on nothing going wrong.

The order matters more than the list. First come the moves that close the biggest risks for the least money: turning on multi-factor authentication everywhere, then proving the backups real with an actual restore. Both are measured in days, not months, and either one can be the difference between an incident and a catastrophe. Next comes a monthly patch cadence, because "when something breaks" is how known vulnerabilities stay open for months.

Only then does the report turn to efficiency: the order re-typing is the clearest automation candidate, because the hours are visible and the process is repetitive. That sequencing is deliberate — automating on top of weak security basics builds speed on sand. Close the risks that could stop the business first; then invest in what makes it faster.