Independent Assurance vs Systems-Integrator Assurance

The distinction is structural, not semantic. A systems integrator is contracted to design, configure, build, migrate, test or operate part of the solution. Its quality controls, internal reviews and readiness statements are necessary delivery evidence. They remain evidence produced within the delivery chain.

Independent Delivery Assurance exists for a different purpose: to test whether the evidence supporting a material client decision is sufficient, credible and independent of the outcome being judged.

The control boundary

Function	Primary responsibility	Core question
Systems integrator	Deliver the contracted solution and demonstrate that its controls and outputs meet agreed obligations.	Have we built, tested and prepared the solution correctly?
Client governance	Own acceptance, risk, investment and operational decisions.	What are we prepared to accept and on what basis?
Independent client-side assurance	Test material delivery claims and the evidence supporting the client’s decision.	Can the client reasonably rely on this evidence?

These roles complement each other when the boundaries are explicit. Problems arise when supplier self-assurance is treated as a substitute for independent challenge.

What systems-integrator assurance does well

• Technical quality control over configuration, code, interfaces and environments.
• System and integration testing within the supplier’s delivery scope.
• Defect management, remediation and regression evidence.
• Internal architecture, security and release reviews.
• Migration execution controls and technical reconciliation.
• Readiness reporting against the supplier’s own contractual deliverables and plans.

Those controls should be expected. Weak supplier quality control is itself a delivery risk. The problem is not that a systems integrator assures its own work. The problem begins when the client assumes that this is sufficient assurance for the client’s acceptance, investment or go-live decision.

Where independence breaks down

• Commercial interest: the supplier may carry revenue, milestone or contractual consequences if a release is delayed or rejected.
• Delivery ownership: the same organisation may have designed the solution, operated the controls and produced the evidence now being judged.
• Evidence selection: supplier reporting can emphasise completed activity while underrepresenting unresolved dependencies, exceptions or weak acceptance evidence.
• Scope boundary: a systems integrator may report only on obligations within its contract, while the client decision depends on business readiness, third-party interfaces, data ownership, operational support and other suppliers.
• Escalation route: supplier assurance normally reports through the delivery relationship rather than directly to the client body carrying the final accountability.

None of these conditions imply supplier misconduct. They are normal consequences of role and incentive. Good governance designs around them rather than pretending they do not exist.

The practical independence test

Question	If yes	Assurance implication
Does the reviewer own delivery of the area being assessed?	There is a self-review risk.	Use separate independent verification for material decisions.
Does the reviewer have a commercial interest in acceptance or progression?	The conclusion may be affected by outcome pressure.	Client governance should not rely on that opinion alone.
Can the reviewer examine evidence outside the supplier’s contractual scope?	If no, programme-level exposure may be missed.	Broaden the assurance mandate across dependencies and client-owned controls.
Can the reviewer challenge evidence directly and select samples independently?	If no, evidence may be filtered.	Require direct access under an explicit assurance mandate.
Does the conclusion report directly to the accountable client decision-maker?	If no, escalation may be diluted.	Create a direct client-side reporting route.

When systems-integrator assurance is sufficient

Independent assurance is not required for every technical activity. Supplier assurance may be entirely proportionate where:

• the decision is low consequence and readily reversible;
• the control is narrowly technical and contained within the supplier’s responsibility;
• acceptance criteria are objective and independently observable by the client;
• there are no material cross-supplier, data, business or operational dependencies;
• the client has sufficient internal capability to challenge the evidence directly.

The correct question is not whether independent assurance should duplicate supplier testing. It should not. The question is whether the client has an independent basis for the decision that remains after supplier evidence has been produced.

When independent client-side assurance becomes necessary

• A major go-live, cutover, migration or acceptance decision transfers material risk into live operations.
• The systems integrator is the principal source of both delivery evidence and readiness reporting.
• Multiple suppliers or client teams own interdependent parts of the outcome.
• Programme status is disputed or stronger than the source evidence appears to justify.
• Recovery plans depend on assumptions about defects, resources, throughput or business availability.
• Data migration, reconciliation or operational readiness cannot be validated from technical completion alone.
• The board, SRO or accountable executive needs a defensible record of why progression was approved.

Enigma’s Supplier Delivery Assurance examines supplier claims and delivery evidence without taking over supplier responsibilities. Where the decision depends on testing, defects or acceptance evidence, Quality and Test Assurance provides the relevant client-side challenge. For migration and release decisions, Data Migration and Cutover Assurance addresses the evidence required beyond technical completion.

How independent assurance should use supplier evidence

Independent assurance should not recreate the supplier’s delivery process. It should use supplier outputs as source evidence and test the parts material to the client decision.

1. Define the client decision and consequence of error.
2. Identify the supplier claims that the decision depends on.
3. Request the underlying evidence, not only status summaries.
4. Test traceability, completeness, exceptions and cross-workstream dependencies.
5. State what is demonstrated, what remains uncertain and what conditions are required.
6. Return remediation to the supplier or accountable client owner.
7. Verify closure before changing the assurance position.

This approach is consistent with Enigma’s Evidence Sufficiency Standard, Independence and Conflict Standard and Decision Condition Framework.

Decision criteria for the client

If the client needs…	Primary control
Confidence that the supplier’s build and technical controls operate as designed	Systems-integrator quality assurance.
Control of obligations, acceptance, risks and governance decisions	Client governance and internal QA.
An opinion on whether material supplier claims are safe to rely on	Independent client-side assurance.
A defensible go-live, recovery or investment decision across multiple workstreams	Independent assurance integrated with client governance.

The governance conclusion

A competent systems integrator should assure its own delivery. That does not make the supplier’s opinion independent, and it does not transfer accountability away from the client. The client needs enough independent challenge to understand which claims are demonstrated, which remain conditional and which risks it is consciously accepting.

For the broader distinction between assurance, internal QA and supplier governance, see Independent Assurance, Internal QA and Supplier Governance. Practical evidence expectations are set out in the Supplier Evidence Request Checklist and Programme Board Evidence Checklist.