The Pattern That Keeps Repeating
A Series B company is growing fast. Revenue is up, the team is expanding from 8 to 25 engineers, and the product roadmap is ambitious. Then comes the infrastructure sprint: everything needs to scale, and nobody agrees on where to start.
Six months later, they’ve hired a DevOps lead, rewritten their deployment pipeline, and migrated two services to Kubernetes — but the actual bottleneck (it turned out to be a poorly indexed PostgreSQL query pattern that had been in production for two years) took another four months to surface.
A three-week IT audit at the beginning of the growth phase would have found it in week two.
What an IT Audit Actually Examines
An IT audit is not a penetration test, a code review, or an architecture diagram session. It’s a systematic assessment of five dimensions where technical risk accumulates:
1. Infrastructure and reliability
- What does your deployment pipeline look like, and where are the single points of failure?
- What’s your mean time to recovery (MTTR) for production incidents in the last 12 months?
- Is infrastructure defined as code, or does it live in someone’s head?
- What’s your disaster recovery posture, and has it been tested?
Most companies discover they have infrastructure that was designed for half their current load, managed by one engineer who has become a critical dependency.
2. Security posture
- Are secrets managed properly, or are environment variables scattered across deployment configs?
- Who has production access, and when was the list last reviewed?
- Are dependencies updated, or are you running known CVEs?
- What’s your data classification and handling policy?
Security issues discovered during an audit are fixable. Security issues discovered after a breach are expensive.
3. Technical debt topology
Not all technical debt is equal. An audit distinguishes between:
- Load-bearing debt — legacy code that is actively in the critical path, risky to touch, but responsible for core business logic
- Liability debt — old patterns that will break under scale (N+1 queries, synchronous calls in async contexts, missing pagination)
- Cosmetic debt — inconsistent naming, missing tests for non-critical paths, outdated dependencies with no known vulnerabilities
Most engineering leaders conflate these categories. An audit separates them, which lets you prioritise correctly: address liability debt before scaling, manage load-bearing debt carefully, and defer cosmetic debt indefinitely.
4. Team and process capability
- How long does a feature take from spec-complete to production?
- What’s the PR merge rate, and where do PRs stall?
- Is there a documented incident response process, and has it been used?
- Are engineers cross-trained, or are there knowledge silos?
The human and process layer is where most technical risk actually lives. A sophisticated infrastructure with an immature deployment process produces more incidents than a simple infrastructure with a strong engineering culture.
5. Vendor and tooling stack
- Are you paying for tools your team stopped using?
- Are critical business processes dependent on vendors with unclear contract terms?
- What’s your data portability posture if a key vendor shuts down or raises prices?
Vendor audits consistently surface 15–25% of infrastructure spend that can be eliminated or renegotiated.
What Good Looks Like at Different Scales
The right audit findings depend on where you are:
Seed / Pre-Series A (team < 10 engineers) At this stage, the most important finding is usually: “you have architectural decisions baked in that will require significant refactoring at Series B.” The point isn’t to fix everything — it’s to know what you’re committing to, so the technical debt is deliberate rather than accidental.
Series A / B (team 10–40 engineers) This is when reliability and security become critical. An audit here should identify: your top three single points of failure, your security exposure surface, and the two or three technical decisions that will become expensive at 2× current load.
Growth / Post-Series B (team 40+ engineers) At scale, the audit becomes more about process and organisational design than technology. Are you accidentally building a distributed monolith? Are your domain boundaries creating coupling that slows delivery? Is your incident management process scaling with team size?
The ROI Case
Consulting engagements are usually justified by cost savings or risk reduction. An IT audit offers both, but the clearest way to present the ROI is through incident cost.
A production incident in a B2B SaaS company with 50 customers costs, on average:
- 4–8 engineering hours to diagnose and resolve
- 1–2 hours of engineering leadership time
- Customer communication overhead
- Potential SLA penalties
If your team has four such incidents per month (not unusual for a fast-growing team without strong infrastructure practices), and an audit reduces that to one per month, the saving is material — and that’s before counting the cost of the incidents that would have been severe.
How to Prepare for an IT Audit
The companies that get the most value from an audit come prepared:
- Pull the last 6 months of incident history with notes on root cause and resolution time
- Document your current architecture even roughly — a whiteboard photo is fine
- List your current vendor stack with monthly costs
- Identify your three biggest engineering concerns — the things keeping your CTO awake
- Be honest about your documentation state — auditors find out anyway, and early transparency saves time
An audit done well doesn’t produce a list of things that are broken. It produces a prioritised map of where to invest, sequenced by the risk you’re actually carrying versus the scale you’re actually targeting.
The companies that use it well don’t fix everything. They fix the right things first.