IT team of one: what to do first when everything is priority one
There are forty items on the list. Eleven are security, nine are somebody's laptop, six are a project somebody promised a customer, and the rest arrived this morning. All of them are legitimate. Several are from the managing director.
An it team of one does not need a better list. It needs an order that holds when somebody senior is standing at your desk, because without one the order is whoever asked most recently and loudest, which is how estates end up with excellent printer availability and no tested backups.
The order for an it team of one
Four tiers. The reasoning is blast radius: what does the failure of this take with it.
Identity first. If identity is compromised, everything is compromised, and no other control survives it. MFA everywhere, no standing Global Administrator, break-glass accounts that work and have been tested, legacy authentication blocked. This is the Conditional Access set, and it is first because it is the only category where one failure loses everything at once.
Backups second, and specifically restores. A backup job going green proves the job succeeded. It does not prove a restore works, and those are different claims. Ransomware is the scenario where this is the only control that matters, and the test is not the report, it is having actually restored something.
Endpoints third. Patching, disk encryption, malware protection, and knowing which devices exist. Most incidents arrive here, and it is third rather than first because a compromised laptop with good identity controls is contained, while a compromised identity with perfect endpoints is not.
Everything else fourth, prioritised by whichever of cost, risk or noise is currently loudest.
It also broadly matches the sequence in the NCSC's Small Business Guide, which is worth having to hand precisely because it is external: a priority order you can attribute to the national cyber security authority survives a disagreement better than one you devised.
That order is defensible to a board and it is stable under pressure, which is its real value. When somebody asks why their request is behind something else, "identity failure loses everything, yours loses a morning" is an answer.
What to automate
Only two properties make something worth automating at this size: it recurs, and being inconsistent about it is expensive.
That is a narrower filter than it sounds and it rules out most one-off tasks. It rules in joiner, mover and leaver, evidence collection, access reviews, credential expiry checks and anything that produces a report somebody asks for quarterly. All of those are in the automation notes, and all of them fail the same way if you get it wrong, by reporting success having done nothing.
What not to automate: anything you have done twice. Twice is a coincidence. By the third time you understand the edge cases well enough to write something you will not immediately rewrite.
What to outsource
The test is not difficulty, it is whether the constraint is your hours or something structural.
Buy independence. Internal audit needs somebody who is not you and no amount of effort changes that, which is the independence problem. Same for a genuine second opinion on an architecture you designed.
Buy a deadline you cannot move. A migration weekend, a certification date. A fixed external deadline with one person is a risk concentrated in whether that person is well that week.
Buy specialist depth used rarely. A penetration test. A particular platform's quirks you meet once every two years.
Do not buy the everyday queue. Handing over the helpdesk removes the information you use to know what is actually breaking. It is also the cheapest part of the job in hours.
Saying no in a way that sticks
The hardest part, and it is a communication problem rather than a technical one.
Silence is not refusal. An unanswered request stays open in the requester's mind and arrives again with more urgency and a director attached. Refusing explicitly ends it.
What works: refuse against the order rather than against the request. "That is category four, and categories one to three currently have items outstanding. I can do it after those, or now if somebody wants to move it up the list and accept what drops." That converts a refusal into a prioritisation decision owned by somebody else, which is where it belongs.
The version that does not work is "I do not have time", because it invites an argument about your time management rather than about priorities.
Reporting upwards to get budget
The mistake is reporting activity. Tickets closed, patches applied, uptime. These prove you are busy, and being busy is not an argument for money.
Report exposure and trend instead. Three or four numbers, the same ones every time, moving in a direction:
- Accounts with privileged access, and how many are permanent
- Devices out of compliance, as a proportion
- Last successful restore test, as a date
- Whichever recurring control is furthest overdue
The last one is the useful one, because an overdue control with a date attached is a decision somebody else is now aware of. Silence about it makes the risk yours alone; reporting it makes it the company's.
Then attach one ask per report. Not five. One, with what it costs and what it reduces. A single specific ask succeeds far more often than a list, and a list invites selection of the cheapest item.
Questions
Should identity really come before backups?
Yes, because an identity compromise can reach the backups. Backup systems are authenticated, and an attacker with sufficient privilege deletes or encrypts them. Immutable or separately-credentialled backups narrow that gap, which is a good reason to have them, and the ordering still holds.
What if the business will not fund any of it?
Report the exposure in writing, with dates, and keep reporting it. That is not cynicism, it is the correct action: an accepted risk that somebody senior has been told about is a business decision, and an accepted risk nobody was told about is yours. Documenting it is also the only version of this that protects you.
How do I get out of firefighting?
Automate one recurring thing properly, then use the time it frees to automate the next. Not a project to fix everything, which will be interrupted. One thing, finished, that never comes back.
Is a managed service provider worth it at forty people?
For round-the-clock cover, yes, because one person cannot provide it and pretending otherwise is the actual risk. For the day queue at this size, usually not: it costs more than it saves and it removes your visibility of what is breaking.
When is one person genuinely not enough?
When two of these are true at once: a fixed external deadline, an estate you did not build, and no independent review available. That combination is where bringing somebody in pays, and it is worth recognising before rather than during.