The request for a technology audit rarely arrives on a calm day. A customer disputes an invoice the system cannot explain. A platform goes down for a morning and nobody can say why it took four hours to recover. A board member reads about a breach at a competitor and asks whether the same thing could happen here. Someone says "we need an audit", and within a week the word has travelled round the building.
By the time it reaches the teams who run the systems, it has usually changed meaning. An audit, as most people experience it, is the thing that happens before somebody is moved, disciplined or quietly sidelined. So people prepare accordingly. Documents get tidied. Answers get shorter. The engineer who knows exactly where the weakness is decides that this is not the week to mention it.
That reaction destroys the value of the exercise before it starts. A technology audit that people fear produces a defensive organisation and a thin evidence file. A technology audit that people understand produces something far more useful: an honest picture of how well the system works, where it is fragile, and what would make it healthier.
This series calls that second kind of audit a technology health check. The name is deliberate. A health check is not an accusation. It examines a living system, measures what it can, states what it finds, and leaves the patient and the people responsible for their care to decide what to do next.
Cedarberg Logistics is fictional, and its systems and figures are illustrative. It is a Cape Town cold-chain logistics firm with about 1,100 staff, depots in Epping, Paarl, George and Midrand, and roughly 180 refrigerated vehicles. It carries food, flowers and pharmaceuticals for customers who pay a premium because the temperature of their goods is guaranteed.
How Cedarberg got here
A pharmaceutical customer disputed a consignment that had travelled from Cape Town to Midrand. The trailer's temperature log showed a three-hour gap in the middle of the trip. Cedarberg believed the load had stayed cold. It could not prove it. The customer rejected the stock and opened a claim.
The executive meeting that followed went the way these meetings usually go. Who was on shift? Which team owns the telematics platform? Why did nobody notice? Each question had a person as its answer, and each answer closed the conversation without making the next consignment any safer.
The chief executive asked for an independent technology health check instead, scoped across the whole cold-chain technology estate rather than the one failed trip. The terms of reference said explicitly that the review would examine systems, processes and controls, and that it would not make findings about individual performance. That one sentence changed how the next six weeks went.
What a health check actually examines
The useful unit of analysis is the system, in the broad sense: technology, the processes that use it, the people who operate it, the rules it is supposed to enforce and the controls that should detect when it does not. A failure almost always involves several of these at once. A probe went silent, which is technology. Nobody was alerted, which is a control. The night controller had no runbook for a missing reading, which is process and people. The customer's service level lived in a contract nobody had translated into an alert rule, which is rules.
Treating the gap as somebody's mistake would have found one of those layers and stopped. Treating it as a system question finds all of them.
The shift is not about being kind. It is about asking questions that have fixable answers. "Who missed the alert?" produces a name. "Did an alert exist, and who received it?" produces a fact about the design, and Cedarberg's answer turned out to be that no alert for missing data had ever been configured. No amount of individual vigilance would have caught a problem the system was never built to report.
Evidence, criteria and the shape of a finding
What separates a health check from an opinion is evidence. A reviewer who walks the corridors and returns with impressions has produced a consultant's view, which may be wise but cannot be tested. A health check works from criteria and evidence:
- Criteria are the standard the system is measured against. For Cedarberg that included the customer service level (a reading every five minutes), the company's own information security policy, the recovery objectives in its continuity plan and a small set of good-practice expectations agreed at the start, such as every production system having a named owner.
- Evidence is anything that shows what is actually true: configuration exports, logs, tickets, access lists, architecture records, contracts, interview notes confirmed in writing, and walkthroughs where an operator demonstrates a task.
The review requested 64 evidence items and received 52. Twelve could not be produced, which was itself evidence. When an organisation cannot show who has administrative access to its warehouse system, that absence is a finding, even if nobody has misused the access.
Each finding then takes a conventional shape: the condition found, the criteria it was measured against, the cause where the evidence supports one, and the effect on the business. Part 6 of this series returns to that structure in detail, because the line between a finding and a fix is where many audits lose their independence.
The workflow, and where the roles separate
A health check has a recognisable rhythm. The interesting part is not the sequence of steps. It is the point where ownership changes hands.
The reviewer agrees the scope and criteria, gathers evidence, runs interviews and walkthroughs, tests the evidence and drafts findings. Then the work passes to management. Management responds to each finding: it accepts it, accepts the risk without acting, or disputes it with evidence of its own. Management designs and owns the corrective actions. The reviewer returns later to check whether those actions closed the gap, and checks that against new evidence rather than a status report.
This separation is what makes the findings trustworthy. If the reviewer also designs the fix and runs the project, the next review is marking its own homework. If management treats findings as instructions rather than as information, it outsources its own judgement to the reviewer. Both failures are common, and both quietly weaken the organisation's ability to govern its technology.
Nine domains, one estate
Cedarberg's review covered nine domains: strategy alignment, architecture, data, security, operations and resilience, delivery practice, cost, vendor and supplier risk, and remediation ownership. Part 4 sets out what each domain asks. For now, the important point is that a health check looks across all of them, because the failures that hurt most usually sit in the joins.
The three-hour gap is a good example. The telematics vendor's platform recorded every reading the probe sent. Cedarberg's transport management system recorded every consignment. Nothing linked the two in real time, because the integration was a nightly file transfer built when the company carried mostly vegetables. When the pharmaceutical customers arrived, the commercial team sold a five-minute evidence promise on top of an architecture that delivered a next-morning report. No single team had done anything wrong. The system as a whole had drifted out of line with what the business was selling.
The review produced 14 findings, three rated high. Only one of the high findings concerned a technology component. The other two concerned a missing control and an undefined role.
What a health check is not
Clarity about limits is part of the method. A health check is not:
- A performance review. It does not assess individuals, and its report should not be usable as one.
- A forensic investigation. If fraud, sabotage or a breach is suspected, that needs a different mandate, different legal advice and often different specialists.
- A guarantee. A review samples. It tests what is in scope, during a window, using the evidence provided. Its report should say plainly what it did not examine.
- A design exercise. It can say that a control is missing and why that matters. It should not hand over the finished architecture of the replacement, for the independence reasons above.
Stating these limits at the start is what lets people talk honestly during the review. Cedarberg's night controllers, who had every reason to be nervous, gave the most useful interviews of the engagement once they understood the review was about the system they worked inside.
The trade-offs worth deciding up front
A health check costs time and attention, and both are scarce in an organisation that has just had an incident. Three decisions shape how much value it returns.
Breadth or depth. A narrow review of the failed integration would have taken a fortnight and fixed one symptom. Cedarberg's six-week review across nine domains cost more and found the two control and ownership gaps that would have produced the next incident somewhere else.
Independence. A team reviewing its own estate is cheap and fast, and it rarely finds what it was not already looking for. Part 4 sets out a ladder of independence and when each step is justified.
Timing. The best time for a health check is before a major decision, such as a platform replacement, a large contract or a new regulated service. The second-best time is straight after an incident, when attention is high but the pressure to find a culprit is also highest.
A test you can apply to your next audit
Before commissioning one, ask whether the terms of reference would pass three questions:
- Does it name the criteria the system will be measured against, rather than leaving the reviewer to decide what good looks like?
- Does it say that findings concern systems, processes and controls, not individuals?
- Does it say who owns the response to each finding, and when the follow-up review will happen?
If any answer is no, the audit is likely to produce either a defensive organisation or a report that nobody acts on. If all three are yes, it has a fair chance of producing what Cedarberg got: an honest map of where its cold-chain promise was not backed by its technology, and a management team that could act on it without first deciding whom to blame.
The rest of this series works through the method. Part 2 covers architecture gap analysis, Part 3 the architecture repository, Part 4 the scope of an independent assurance review, Part 5 how evidence-led reviews improve proposals and estimates, and Part 6 the difference between a finding and a corrective action. For the cost side of a review, see the cloud cost audit checklist, and for the early signs that a programme needs one, five warning signs of a digital transformation in trouble.
Next: Part 2, How to perform a useful architecture gap analysis. All parts are on the series page.
How CloudNala can help
We run technology health checks that examine systems, processes and controls against agreed criteria, using evidence rather than impressions. The output is a set of findings in a consistent shape, each with the evidence behind it and the limits of what was examined, ready for management to respond to and own. Where a review is needed after an incident, we scope it so that the conversation stays on the system, which is usually the fastest way to make the next incident less likely.
Work with CloudNala
CloudNala helps organisations move from technology ambition to practical execution across cloud, AI, data, platform engineering and digital services.
Whether you are exploring AI, modernising your cloud environment, building a public-sector digital service, or turning an idea into a working MVP, we can help you shape the roadmap and deliver the next step.
Book a Technology Health Check or write to us at consult@cloudnala.co.za