Software engineers are familiar with technical debt — the accumulated cost of shortcuts, quick fixes, and deferred improvements in code. The debt doesn’t cause problems immediately. But it compounds. And eventually, paying it down becomes unavoidable.
IT operations has the same dynamic. I call it IT debt.
What IT Debt Looks Like
IT debt is the gap between where your IT practices are and where they should be — accumulated over time through growth, shortcuts, and deferred decisions.
Here’s how it typically accumulates:
Year 1 (10 people):
No IT structure needed. The founders handle everything. Three people know all the passwords. Devices are set up manually. Nobody thinks about MDM.
Year 2 (25 people):
The informal approach is straining. Onboarding is inconsistent. There are multiple ways to set up a laptop. Access isn’t really tracked. The most technical engineer handles IT questions alongside their engineering work.
Year 3 (45 people):
Three former employees still have accounts. Nobody knows who set up the original AWS account. There’s a Jira ticket from 14 months ago about “sorting out IT.” The MDM that was purchased nine months ago was never fully deployed. Documentation doesn’t exist. Access is everywhere.
Year 4 (65 people):
The IT debt is now a real operational risk. Fixing it properly will require a significant investment of time and disruption. The company is planning Series B fundraising and an enterprise sales push. Suddenly, the cost of not having good IT foundations is very visible.
Why IT Debt Is Different From Technical Debt
Technical debt in code lives in the codebase. It slows development and makes changes harder, but it doesn’t usually create immediate security risk.
IT debt in operations creates active security exposure. Ghost accounts are potential access points. Unmanaged devices are potential breach vectors. Missing documentation creates compliance risk. Poor offboarding creates data security exposure.
IT debt is also harder to quantify than technical debt. A slow codebase is measurable. The risk from an unreviewed access control list is not — until something goes wrong.
The IT Debt Audit
The first step in paying down IT debt is understanding what you have. An IT debt audit covers:
Identity and access:
– How many active accounts exist in your identity provider?
– How many belong to current employees? Former employees? Contractors?
– When was the last access review?
– Are there shared accounts or service accounts that aren’t well-documented?
Devices:
– How many devices does the company have?
– How many are enrolled in MDM?
– How many have current OS versions?
– How many have disk encryption confirmed?
– How many are personal devices being used for work?
Documentation:
– What IT policies exist?
– When were they last updated?
– Are onboarding and offboarding processes documented?
– Is there an asset register?
– Is there a SaaS tool inventory?
Security practices:
– Is MFA enforced everywhere?
– Is a password manager deployed?
– Are backups tested?
– Is there an incident response plan?
The audit typically reveals a list of 20-40 items. That list is your IT debt ledger.
Paying Down IT Debt Without Disruption
The instinct when faced with a large IT debt list is to fix everything at once. This is usually the wrong approach. It disrupts the team, creates change fatigue, and often leads to a good start that isn’t sustained.
A better approach is systematic prioritisation and staged remediation.
Priority 1: Security-critical items
These need to be addressed immediately regardless of disruption:
– Ghost accounts (former employee access)
– Unmanaged admin credentials
– Missing MFA on critical systems
– Devices with no encryption
These are active risks. They cannot wait.
Priority 2: Foundation items
These should be addressed in the first 30-60 days:
– MDM deployment on all devices
– Password manager deployment
– SSO/identity provider setup
– Onboarding and offboarding documentation
These are foundational — getting them right makes everything else easier.
Priority 3: Operational improvements
These can be addressed over 60-120 days:
– Full documentation library
– Comprehensive SaaS audit and cleanup
– Access review process
– Security policy documentation
Priority 4: Compliance and maturity
These are the longer-term items:
– ISO 27001 or SOC 2 preparation
– Vendor risk assessment process
– Business continuity planning
– Security training programme
The Key Principle: Don’t Disrupt While You Fix
The biggest risk in an IT debt remediation is causing operational disruption. Teams hate IT changes when they’re not explained, rushed, or poorly timed.
The principles that make it work:
Communicate before you change. Tell people what’s changing, why, and when. A brief Slack message before rolling out an MDM update prevents a dozen confused support requests.
Stage changes carefully. Don’t deploy MDM to 50 devices on a Monday morning before a major product launch. Pick low-risk moments.
Fix the easy things first. Quick wins build confidence — in the process and in IT leadership. Removing ghost accounts and deploying a password manager are high-impact and low-disruption.
Document as you go. Every improvement should be documented. Not just the final state — the change itself. This builds the documentation library while making progress.
IT debt is normal. Most growing companies have it. The difference between companies that scale well and those that don’t isn’t whether they had IT debt — it’s whether they addressed it before it became a crisis.
If you’d like help understanding your IT debt level, start with the free assessment at itops.zlefterov.com.