If you're the only IT person at your company, you have a strange kind of job security: nobody else knows how anything works.
That feels safe until the day you're out sick, on vacation, or hired away. Then the company discovers that its entire IT environment lives in one person's head. Solo IT is really the job of turning what's in your head into something a stranger could use, and making sure the place is safe while you do it.
And if IT landed on your desk without the title (you're the office manager, the practice administrator, the owner who "knows computers"), this is for you too. You don't need to understand every term below on day one. You just need to know what to look at first and who to call, and this plan gets you there.
I learned the cost of skipping steps the hard way. We once let a wildcard certificate expire, and it broke the sign-in for a clinic's electronic medical records system. For a few hours, three providers couldn't get into their patients' records while we got a new certificate in place. That's why renewal dates show up in Week 2 below.
This is the 30-day IT takeover checklist I'd follow if I were starting from zero, and the one I'd hand to anyone who just inherited an IT environment.
How this series works: this article is the roadmap. Over the next couple of months I'm publishing a deep dive on each step, in the order I do them, and each one comes with a free download (a spreadsheet, template or checklist) you can work through. Each part also ends with the runbooks to write from it, so your documentation builds as you go. By the last part, you'll have a fully documented environment. I'll link each one here as it goes live.
The one rule: write every page for the person who has to take over at 2 a.m. That person might be a contractor you've never met. It might be you, after a rough week, having forgotten everything. Either way, they need answers, not theory.
Week 1: The first three things I check
Documentation can wait a few days. These can't. I check them in this order, every time.
1. The firewall. It sits at the edge of your network, facing the internet. If it's running old firmware with a known exploit against it, nothing else you fix inside matters much, because that's the door that's already unlocked. So the first question isn't "what rules does this have?" It's "when was this last patched, and is there a known exploit against this version?" You can answer that in an hour without changing a thing.
Deep dive coming next week: First Thing I'd Check: The Firewall.
2. The backups. Not "what's being backed up?" but "when did someone last restore something, and did it work?" A backup that has never been restored is a hope, not a plan. If the firewall turns out to be the open door, the backups are what save you.
Deep dive coming soon: First Thing I'd Check, Part 2: Backups.
3. Who has the keys. Find out who has admin access to everything (email, servers, the firewall, the domain registrar, vendor portals), and make sure the company can get into its own systems without you:
Admin accounts: who has global or domain admin, and is it a named person or a shared mystery account? Anyone who no longer works there gets disabled today.
Break-glass access: at least one emergency admin account (the "break glass in case of fire" key), excluded from normal policies, with a long random password kept offline and checked on a schedule.
Password vault: where do credentials actually live? One shared vault beats a spreadsheet, a sticky note and your memory.
MFA (the code from your phone app): which admin accounts have it, and what happens if the phone that holds it dies?
Deep dive coming soon: First Thing I'd Check, Part 3: Identity & Admin Accounts.
Why the firewall before the keys? Both matter on day one, but they guard against different things. Access protects the business from being locked out if you disappear. The firewall protects it from whoever is already knocking. Checking the firewall's patch level is fast and doesn't change anything, so I do it first, then lock down the keys the same week.
Ground rule I'd tattoo on every runbook: log where a credential is stored, never the credential itself. "Firewall admin: stored in the IT vault under Network" is useful. The password itself has no business in a document.
The test at the end of week one: could your boss, holding only the break-glass instructions, regain control of the environment if you vanished tomorrow? If not, fix that before anything else.
Week 2: Know what you have
Now build the inventory. It doesn't need to be fancy. A spreadsheet is fine. What matters is that it exists and has an owner.
Identity: where do users live (Active Directory, Entra ID, Google Workspace, something else)? Who provisions and removes them? Where are the service accounts, and what do they run?
Network: sites, internet circuits, firewalls, switches, Wi-Fi, VPN, and who hosts your DNS. Draw one simple diagram, even a hand-drawn photo. A bad diagram beats none.
Servers and cloud: what runs where, what's virtual, what's in a cloud subscription, and what would hurt most if it went down.
Endpoints: how many devices, who has what, and how they get patched.
Apps and SaaS: every line-of-business app and subscription, with owner, cost and renewal date. Renewal dates alone will pay for this whole exercise the first time one saves you from an auto-renew or a lapsed license. Don't forget domain names and SSL certificates: they expire too, and when they do, they take things down with them.
Deep dives coming soon: Part 4: How to Build an IT Asset Inventory, and Part 5: Vendors, Renewals & Who to Call.
Week 3: Know what else can hurt you
Inventory tells you what exists. This week tells you what's fragile.
Security basics: endpoint protection, email security, and firewall rules nobody remembers creating.
End-of-life: anything running software or hardware the vendor no longer supports. List it, even if you can't fix it yet.
Who to call: the internet provider, the line-of-business vendor, whoever supports the phone system. Put names, numbers and contract or account IDs where you can find them in a crisis (Part 5 covers this).
Deep dive coming soon: Part 6: Security Basics & End-of-Life.
Week 4: Write it down for a stranger, then rank the risks
Now turn what you know into things other people can use.
Runbooks for the top 5 recurring or scary tasks: onboarding and offboarding a user, restoring a file or server, what to do when the internet is down, resetting an admin, renewing the certificate or license that always sneaks up on you. Use numbered steps and screenshots. Assume the reader is competent but has never seen your environment.
A one-page "if I'm out" sheet: where the vault is, where the break-glass instructions are, who to call for what, and the three most likely emergencies with a first move for each.
A risk register: a plain list of everything undocumented, unsupported, not backed up or insecure that you found along the way. Rank it by "how bad if it breaks" and "how hard to fix." This becomes your roadmap and your case when you ask for budget.
Deep dives coming soon: Part 7: How to Write an IT Runbook, Part 8: The "If I'm Out" Binder, and Part 9: The Risk Register and the Report to Management.
The shortcut: pretend it's day one
The trick that makes this work is to walk the environment as if you were seeing it for the first time. Ask the questions a new hire would ask. You'll find the things you stopped noticing years ago: the server nobody owns, the account that still works for someone who left, the license that renews next month.
Years ago, at a large company I worked for, there was a server with a note on it: never turn this off. Nobody there actually knew what it did. It was so old it still ran DOS, and everyone was afraid to reboot it, so it just kept running. It was still running when I left. Every environment has a box like that. Your job is to find yours and put it on the risk list.
Your 30-day IT checklist (scorecard)
The firewall's firmware is checked against known exploits, and anything critical is on the fix list
A real restore has been tested in the last 90 days
Every admin is a current employee, and someone other than me can get into critical systems
Credentials live in a vault, and no document contains a password
I have a current inventory of identity, network, servers, endpoints and apps
Every subscription has an owner and a renewal date
The top 5 runbooks exist
I have a ranked risk list I can show my boss
Don't try to do all of it in one weekend. Thirty minutes a day beats a heroic Saturday you'll never repeat.
Coming up in this series
First Thing I'd Check: The Firewall (next week)
First Thing I'd Check, Part 2: Backups (coming soon)
First Thing I'd Check, Part 3: Identity & Admin Accounts (coming soon)
First Thing I'd Check, Part 4: How to Build an IT Asset Inventory (coming soon)
First Thing I'd Check, Part 5: Vendors, Renewals & Who to Call (coming soon)
First Thing I'd Check, Part 6: Security Basics & End-of-Life (coming soon)
First Thing I'd Check, Part 7: How to Write an IT Runbook (coming soon)
First Thing I'd Check, Part 8: The "If I'm Out" Binder (coming soon)
First Thing I'd Check, Part 9: The Risk Register and the Report to Management (coming soon)
Each one gets its own free download. Subscribe and they'll land in your inbox as they're published.
Get the free Starter Checklist
Subscribers get the printable one-page scorecard for this plan, with space for owners and dates. Subscribe free and it's yours, along with a free download with every deep dive in the series.
IT takeover checklist FAQ
What should I check first when I take over an IT environment?
The firewall's firmware and known exploits, then whether the backups have actually been restored, then who has admin access to everything. Those three come before documentation because they're where the damage happens fastest.
How long does it take to get an inherited IT environment under control?
The basics in this plan take about 30 days at 30 minutes a day. Getting it fully documented takes longer, which is what the rest of this series walks through, one part at a time.
I'm not an IT person, but IT landed on my desk. Is this for me?
Yes. You don't need to understand every term on day one. Start with Week 1, write down what you find, and use the "who to call" list for anything you can't fix yourself.
Do I need special software to do this?
No. A spreadsheet and a password vault cover most of it. The free downloads in this series are spreadsheets and templates you can use as they are.
Know someone who's the whole IT department? Send them this page, or have them subscribe free at soloitpro.com.
