A technology assurance review is usually commissioned at a moment of exposure. A programme is about to ask for its largest tranche of funding. A contract is about to be signed. A new service is about to go live for customers who will notice if it fails. Someone senior wants confidence that the decision is sound, and asks for an independent view.
What comes back is often a review of the project rather than the solution. Is the plan realistic? Are the risks logged? Is the steering committee meeting? Those questions matter, but a programme can answer all of them well and still be about to buy an architecture that cannot meet the promise it is being bought for. Project health and solution health are different things, and an assurance review that covers only the first gives the board a false sense of the second.
Cedarberg Logistics is fictional, and its systems and figures are illustrative. After the health check described in Part 1, the Cape Town cold-chain firm launched a programme to give customers live, per-consignment temperature evidence. Before it approved the main contract, the board asked for an independent assurance review of the programme and its proposed solution.
Nine domains, each reduced to one question
A useful review covers the solution, the delivery and the organisation that will own the result. Cedarberg's terms of reference used nine domains, each with a single question the review had to answer with evidence.
Strategy alignment. Does the programme serve a stated business outcome, and would the board recognise that outcome? Cedarberg's did: the target from Part 2, live temperature evidence for every consignment. A programme that cannot state its outcome in a sentence is not ready for funding, however good its plan.
Architecture. Do the parts fit, and is there a record of who decided why? The review tested the proposed design against the outcome, the existing estate and the standards in the repository described in Part 3.
Delivery evidence. Is progress shown by working, tested change, or by status reports? A programme reporting 60% complete with nothing deployed to a test environment is showing activity, not progress.
Security. Are access, secrets and third-party connections controlled and reviewed? For Cedarberg this included how the vendor platform would authenticate to the new integration and who could change alert rules.
Data. Is there an agreed record of truth for each important fact, with an owner? The vehicle-to-trailer conflict found in Part 2 would have broken the new customer view on day one if nobody had decided which system was authoritative.
Operations. Can the result be run, monitored and recovered by the people who will own it? This is where many programmes are weakest, because the operating team is often not in the room until handover. Who supports the solution after the workshop? covers why that is so costly.
Cost. Is spend tracked to an owner and an outcome, including the running cost after go-live? Cedarberg's business case covered build cost in detail and run cost in a single line.
Vendor risk. What happens if a supplier fails, changes terms or exits? The programme depended on the telematics vendor's platform for every reading. The review asked what the contract said about data access if that relationship ended.
Remediation ownership. Does every finding from earlier reviews have a named owner and a status backed by evidence? This domain makes the other eight useful. The review found that most findings from the original health check were closed, but one, about administrator access to the warehouse system, was overdue and had had no owner since a reorganisation.
How independent does it need to be?
Independence is not binary. It is a ladder, and each step costs more and gives more confidence that nobody is marking their own work.
- Self-assessment. The delivery team checks itself against a checklist. Fast and cheap, and useful as preparation. It rarely finds what the team was not already worried about.
- Peer review. Another delivery team reviews the work. Good for design quality, weaker on challenging the programme's own assumptions, because peers often share them.
- Second line. A risk, architecture or quality office with authority but no delivery stake. Appropriate for most significant changes.
- Independent review. Reviewers with no stake in the outcome, either internal audit or an external party. Justified for major investment gates, regulated services and post-incident reviews.
Cedarberg's board asked for level 4 because the programme was the company's largest technology investment in a decade and because it underpinned a commercial promise to its most demanding customers. A routine release would not have justified it.
Independence also has to survive the engagement. A reviewer who is likely to be awarded the delivery contract, or who designed the solution being reviewed, is not independent no matter what the letter of appointment says. Cedarberg's terms of reference excluded the reviewer from bidding for the build.
What the board should receive
The output of an assurance review is a decision aid, not a report for the file. It should give the board four things:
- An overall opinion, stated plainly. Cedarberg's was "proceed, with two conditions".
- Findings by domain, each with the evidence and its rating, in the condition, criteria, cause and effect shape described in Part 6.
- Conditions for proceeding, separated from recommendations. A condition must be met before the decision takes effect. A recommendation is advice management may weigh.
- Limitations: what was not examined, what evidence was unavailable, and what the opinion therefore cannot cover.
Cedarberg's two conditions were specific. The data owner for vehicle and trailer assignments had to be named and the conflict resolved before integration testing. The vendor contract had to secure data access on exit before signature. Both were met within a month, and the contract was signed with neither risk carried into delivery.
When to commission one
Assurance is most valuable before an irreversible step. Useful trigger points are:
- before approving a major funding tranche or contract award;
- before go-live of a service that customers or regulators depend on;
- after a significant incident, as part of the response rather than the blame;
- before a material change of supplier or platform; and
- when a programme's reported status and its visible results have diverged for more than a quarter.
Commissioning one after the contract is signed is still useful, but its conditions become change requests, and those cost more.
The trade-off to be honest about
A thorough review takes time from the people the programme most needs. Cedarberg's took four weeks of elapsed time and roughly two days each from eight key people. The board judged that cheap relative to the contract value. For a smaller change, a second-line review using the same nine questions in a single workshop gives most of the benefit at a fraction of the cost. The questions scale down. The independence, for a decision this size, should not.
Next: Part 5, Evidence-led audits improve proposals and estimates. All parts are on the series page.
How CloudNala can help
We provide independent technology assurance reviews at the points where they change decisions: before funding gates, contract awards and go-live. Our reviews cover the solution and its operation as well as the project, separate conditions from recommendations, state their limitations, and are scoped so that the reviewer has no stake in the delivery that follows.
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