IT hygiene is the routine upkeep of what you own: knowing every device and piece of software, keeping configurations sane, and controlling accounts. It matters because you cannot patch, monitor or recover what you do not know exists. Readiness starts with an accurate inventory and a few repeatable habits.
What counts as IT hygiene?
The CIS Critical Security Controls give a useful definition by example. Version 8.1 lists 18 controls, and the first ones are plain housekeeping. Control 1 is inventory and control of enterprise assets. Control 2 is the same for software. Control 4 is secure configuration of assets and software, and Control 5 is account management.
Nothing there is exotic. It is the unglamorous work of keeping a ledger of devices, a ledger of software, a known-good configuration, and a list of who can log in to what.
Why does readiness depend on it?
Every incident response plan assumes you can answer four questions fast: what is affected, what runs on it, who has access, and what changed. A team with weak hygiene spends the first day of an incident just answering those.
Consider a constructed example. A 40-person company gets a report that an old file server is exposed. Nobody is sure whether it is still in use, who owns it, or whether it holds customer data. The fix itself takes ten minutes. Finding out whether it matters takes two days. A current inventory with an owner column turns that into a lookup.
The same applies to software. A vulnerability notice is only actionable if you can search your own estate for the affected version. That is the purpose of a software inventory, and for code it means knowing your dependencies, including the indirect ones.
Where does hygiene usually slip?
Four places show up again and again.
- Unowned assets. Things that were set up for a project and never retired.
- Drift. A configuration that was correct at launch and changed by a hundred small edits.
- Stale accounts. Contractors, former staff and service accounts with no expiry.
- Unknown software. Browser extensions, local tools and forgotten dependencies that nobody approved.
None of these are technical failures. They are process failures, which is why they respond to a schedule better than to a product purchase.
How to check or apply this
- List every device, server, cloud account and SaaS tool you pay for or run. Add an owner to each row. Anything without an owner is your first cleanup task.
- List installed software and, for your own code, the dependency tree. Note which items have no maintainer you could contact.
- Pick one baseline configuration per asset type and write down how you would detect drift from it.
- Review accounts monthly. Remove access for anyone who left, and give service accounts an owner and a review date.
- Put patching on a calendar with a target time for urgent fixes, and track the misses.
- Keep the inventory as a living file or system. A spreadsheet reviewed monthly beats a tool nobody opens.
Where can tooling help?
Software inventory is the part most teams do by hand and get wrong. Safeguard builds an SBOM and scans dependencies, with reachability analysis to separate vulnerable code that your application can actually call from code that it cannot. There is also a free in-browser scan at gold.safeguard.sh/scan for up to 100 dependencies if you want to see your own tree first. It supports the software side of the CIS controls above, not the whole list.
Quick check
Is IT hygiene the same as patching?
No. Patching is one habit inside it. Hygiene also covers inventory, configuration, and account control, and patching depends on the inventory to know what to patch.
What is the smallest useful first step?
An asset and software list with an owner on every line. Most other controls assume it exists.
Sources
Last reviewed: 18 October 2026.
