Enterprise Supplier Assurance Evidence Matrix

IG-Smart practical guides | Supplier assurance Edition: 24 October 2026 | Audience: Procurement, third-party risk, security, privacy and business-service owners

Use this guide to make a better-evidenced decision. This is general information and an original working aid, not a client-specific legal opinion, certification, clinical safety authorisation or regulatory approval. Apply the relevant jurisdiction, current requirements and competent professional review to your circumstances. Examples are illustrative unless expressly attributed.

1. Map the supplier legal entity, service, access and critical dependencies.
2. Choose applicable controls and challenge evidence against the actual service.
3. Use the workbook to track gaps, then record a human decision and review triggers.

A board-defensible framework for vendor tiering, evidence verification, residual-risk decisions and continuous third-party oversight

Supplier assurance is frequently reduced to collecting an ISO certificate, a completed questionnaire and a penetration-test cover sheet. Those are useful artefacts. They are not, by themselves, a conclusion that the organisation can safely and lawfully depend on the supplier.

An ISO/IEC 27001 certificate must be checked for holder, issuer, scope, sites, validity and relevance to the particular service. A SOC 2 report requires attention to its period, boundaries, control exceptions, subservice organisations and complementary user-entity controls. A penetration test is time-bound, scoped and may not cover the deployed configuration, subcontractors or current threats. A cloud provider's strong platform controls do not automatically establish the customer's tenant security. These are examples of *evidence interpretation*, not reasons to dismiss third-party evidence altogether.

Before onboarding a material supplier, an accountable decision-maker should be able to answer:

1. Dependency: If this supplier fails, is compromised, changes subcontractors or becomes unavailable, which services, people, data and legal duties are affected?
2. Evidence: What proportionate proof supports the relevant controls, what is excluded, and which controls remain unverified or only self-attested?
3. Decision: Is the residual exposure within approved appetite, are binding conditions in place, and who has authority to accept or prohibit the arrangement?

The NCSC recommends understanding supplier risk, building proportionate requirements, checking arrangements and improving oversight throughout the relationship. It does not recommend treating questionnaire completion as assurance in itself. [S1][S2] ISO/IEC 27036-2:2022 addresses the security of supplier–acquirer relationships through definition, implementation, operation, monitoring and improvement. [S3]

The first-page decision card

Executive rule: An amber supplier with one evidenced, owned remediation plan may be a more defensible choice than a 'green' supplier whose unverified claims have been mis-scored as passed. Neither colour is a substitute for the decision record.

Supplier risk management draws on overlapping but non-interchangeable frameworks. The applicable duties depend on the organisation's role, sector, location, data, contract and actual supplier service. No single checklist establishes compliance with all of them.

2026-specific source note: Current ICO international-transfer guidance explains the UK protection test; UK law now uses the phrase 'data protection test' while the ICO continues to use 'transfer risk assessment (TRA)' in its guidance. A spreadsheet field labelled 'TRA/IDTA needed?' is only an intake prompt, never a legal conclusion. [S10] The FCA reports additional operational incident and third-party reporting requirements effective in March 2027 for firms within scope. [S8]

The three assurance boundaries often missed

• Certification versus service evidence: ISO/IEC 27001 certification is evidence of a scoped management system, not a claim that every supplied service is immune to compromise or that a buyer's configuration is compliant.
• Controller accountability versus processor assurances: Article 28 contractual safeguards and supplier diligence assist the controller, but outsourcing processing does not extinguish the controller's own legal obligations. [S6]
• Operational dependence versus contract value: A low-cost integration can have a critical privileged path into production; a high-value contract may have no access to regulated data or important services. Contract spend is not a sufficient risk proxy.

Original working model — not a regulator-approved methodology. Each gate must produce traceable outputs. The gates are deliberately sequential: a polished assurance score cannot rectify a misidentified supplier or a missed legal mandate.

Do not report 'seven gates passed = secure'. The purpose is to ensure no critical decision element becomes invisible. A separate quality assurance review should sample whether the process operated effectively.

The initial tier determines *how much assurance work is needed*; it must not be inferred from the percentage of documents already collected. Consider at least:

1. Business criticality: effect on important functions, regulatory delivery, finances and end users.
2. Data exposure: volume and sensitivity, special-category/health data, confidentiality and international processing.
3. Privilege and connectivity: direct production access, administrative control, network trust, code deployment, integration rights and support access.
4. Concentration and substitutability: single points of failure, geographic or provider concentration, recovery feasibility, fourth-party opacity.
5. Human or clinical safety consequence: whether failure or misuse can create clinical or other consequential human harm.
6. Regulated-service classification: whether sector-specific outsourcing, ICT, reporting, safety or processor duties are engaged.

Four illustrative assurance tiers

The tiers are IG-Smart proposal labels, not a mandated classification under ISO, NCSC, DORA, NHS or FCA rules. Organisation-specific materiality assessments and legal definitions override them where applicable. A human owner must approve the tier; an Excel formula may only suggest one.

Mandatory non-compensatory safeguards

Regardless of the weighted score, withhold unconditional approval where an applicable requirement is materially unmet. Typical examples include:

• No valid Article 28 processor agreement when required, or subprocessor engagement without required authorisation.
• Unresolved critical exposure affecting essential/clinical services or direct privileged access.
• Inability to establish what regulated personal data is processed or where restricted transfers occur.
• Lack of agreed incident notification cooperation for a critical supplier, where needed by law or contract.
• A material clinical-safety requirement left without the responsible clinical owner.
• A supplier refusal to provide proportionate assurance needed for a critical dependency, with no adequate alternative assurance.
• Unauthorised acceptance of material risks by a person without the relevant delegated authority.

Not every information gap is automatically a legal breach. Classify 'unknown' separately from 'failed', identify the consequence of the uncertainty and escalate proportionately.

IG-Smart evidence confidence ladder

Evidence level is not a single maturity score. For a simple control, a current operational artefact may be more decision-useful than an unrelated external certificate. Assess identity, provenance, scope, currency, testing coverage, auditor independence, exceptions, applicability and configuration-specific responsibility.

The 'five questions' test for every supplier artefact

1. Whose? Does it name the contracted legal entity, specific product, site, operating subsidiary and relevant subcontracted scope?
2. What? Which control assertion does it support—and which does it not address?
3. When? What period does it cover? Has a material change or incident occurred since?
4. Who assessed it? Is the assessor suitably competent and independent for the claimed conclusion?
5. What remains? Are exclusions, complementary customer controls, known vulnerabilities, outstanding findings or remediation conditions disclosed?

Evidence quality rule: 'Evidence received' and 'evidence verified' must be separate workflow states. Evidence should not receive full credit solely because a supplier uploaded a file.

The matrix is a reference library. For each supplier, select only the controls relevant to the service and risk tier; justify each 'not applicable' finding. The source artefact may be reused across controls only where its content genuinely supports each claim. `M` denotes a potential mandatory gate when applicable, not an automatically universal legal requirement. The 1–5 weight is an illustrative prioritisation starting point, not a regulatory prescription.

Use the workbook rather than treating this table as a completed audit. The matrix should record an evidence reference, reviewer, status, scope, confidence, age, exceptions and decision for each relevant control. No supplier is automatically 'compliant' because all 36 rows appear in a spreadsheet.

Tier-specific evidence depth: a practical baseline

Legal requirements do not disappear because a supplier is 'low tier'. A low-tier processor still requires appropriate UK GDPR processing terms, for example. [S6]

Four concepts must remain separate in the decision record:

• Inherent risk: exposure before the buyer relies on mitigating controls.
• Control evidence confidence: the strength and scope of verified material supporting the specific control claim.
• Residual risk: exposure remaining after considering controls *and* the organisation's deployment, shared responsibilities, vulnerabilities and dependencies.
• Decision authority: the person or committee authorised to accept, condition, pause or reject the arrangement.

Suggested scoring approach in the companion workbook

A 0–4 reviewer confidence value may be applied to a verified, in-scope control, with an illustrative prioritisation weight of 1–5. The workbook can calculate:

`Evidence confidence (%) = 100 × SUM(weight × verified confidence/4) / SUM(weight of applicable recorded controls)`

This is an evidence confidence indicator, not a cyber-risk probability, provider grade, legal compliance percentage or likelihood of breach. The denominator should exclude only documented, reviewer-approved non-applicable items. If the applicable control set is incomplete, the indicator remains provisional. A single missing mandatory safeguard overrides any otherwise favourable percentage.

Residual risk must be a separate assessed conclusion. One practical method uses the organisation's existing impact/likelihood scales plus documented mitigations, rather than inventing a universal supplier-risk scoring threshold. Where risk appetite is not approved, use *'decision pending'* rather than an artificial green/amber/red conclusion.

Worked example: a fictional health-data SaaS vendor

*Illustrative scenario only — no real client, provider, test or finding is represented.*

A supplier hosts a clinical workflow application containing patient information. It offers a valid ISO certificate and a recent penetration-test letter. The buyer discovers: (a) the certification scope excludes the operational support subsidiary that can access customer tenants; (b) MFA enforcement is evidenced for employees but privileged break-glass access remains untested; and (c) an overseas subprocessor is listed without a documented transfer assessment.

An aggregate score could look reassuring because many policies exist. A defensible decision is hold pending scope and legal clarification, not 'pass with 86%'. The evidence owner should verify the support entity and privileged-control path, assess processor/subprocessor roles and any restricted transfer, and determine whether bounded corrective action can make the arrangement acceptable. Only an authorised buyer can decide whether and when to proceed.

Residual-risk decision categories

'Approved with conditions' is not a licence to commence activity prohibited by law or to ignore a safety-critical concern. In the workbook, readiness and decision approval are distinct fields deliberately requiring human sign-off.

Independence boundary: An adviser who helps design supplier processes may still provide valuable implementation support, but the independence and limitations of any subsequent assurance work must be assessed and disclosed. Do not describe IG-Smart's implementation as independent certification.

Stage 1 — Pre-selection

Define the service, data, end users, dependencies, internal owners, planned integrations and credible failure scenarios. Avoid distributing a generic 200-question pack before understanding what matters. Identify prospective processor roles, regulated outsourcing definitions and fourth-party reliance early. Start a single supplier record and link evidence to the actual product/service, not just the vendor's corporate marketing website.

Stage 2 — Risk-led due diligence

Assign an approved tier, choose relevant control checks, request proportionate evidence, and assess provenance and scope. Separate facts from supplier assertion, control design from operation, and limitations from noncompliance. Confirm which controls rely on buyer configuration (cloud tenant hardening, encryption keys, access provisioning, local clinical safety, etc.).

Stage 3 — Contracts and onboarding

Ensure commercial schedules reflect the control and reporting commitments on which approval depends. Where personal data are processed on behalf of the buyer, check Article 28 terms. For high-consequence services, clarify incident notification, audit/assurance rights, restoration, data retrieval, fourth-party visibility, exit assistance and unresolved remediations. Avoid assuming a general right to unrestricted penetration testing of cloud infrastructure.

Stage 4 — Run and monitor

Collect agreed security/operational metrics, assess material changes, scrutinise incident reports and follow up remediation. Reassess fourth parties, location changes, critical integrations, major vulnerabilities and new AI/data uses. Ask whether deployed configuration still matches the assessed version. Supplier 'annual review completed' is not a sufficient effectiveness metric by itself.

Stage 5 — Exit or substitution

Verify data return/deletion under the applicable legal and contractual arrangements; recover or revoke privileged access, API tokens and keys; validate portability where required; record transition and continuity dependencies; and preserve the necessary audit trail. If deletion cannot occur because of a legal retention obligation, document the continuing basis and controls.

The NCSC's five-stage assessment guidance directly supports integrating assurance throughout supplier relationships and continuous improvement. [S2]

The following are procurement drafting considerations, not a substitute for legal advice or model clauses. Tailor them to supplier type, bargaining position, location, clinical or financial-sector rules and the actual service.

Legal point: ICO guidance identifies specific minimum Article 28 contractual provisions where controller–processor processing occurs. The exact legal arrangements must be established rather than relying on a generic vendor DPA badge. [S6][S7]

Financial-sector point: Where EU DORA applies, particular contractual provisions and registers may be legally required for ICT services; UK FCA/PRA duties follow their own rulebooks and are not interchangeable with DORA merely because the supplier operates internationally. [S8][S9]

Reassessment triggers that override an annual diary

• A significant supplier incident, breach or material vulnerability affecting scope.
• A new clinical workflow, regulated data category or safety consequence.
• Transfer of processing to another country or fourth party.
• Material change in API privileges, cloud tenant, software architecture or production access.
• Expiry, suspension or narrowing of assurance evidence.
• Acquisition, insolvency, material financial distress or concentration increase.
• Material service outage, failed restoration exercise or repeated SLA failure.
• A regulator's new requirement applicable to this particular buyer and arrangement.
• Significant AI functionality or data-use change introduced by the supplier.
• Approaching termination, contract renewal or change of important business service.

Avoid claiming that 'continuous assurance' means continuous invasive scanning. It means ongoing ownership, appropriate evidence collection, exception management and event-driven review.

NHS / clinical digital health

For a supplier delivering a clinically consequential solution, distinguish supplier product evidence from the NHS deploying organisation's clinical risk management. Assess relevant DCB0129 and DCB0160 accountabilities, DTAC and DSPT conditions as the actual procurement/deployment dictates. A good cyber supplier grade does not authorise use of a clinically unsafe product. Where clinical responsibility or hazard acceptance is unresolved, route to qualified clinical safety leadership.

Financial services

For a UK FCA/PRA-regulated buyer, map important business services, outsourcing/materiality and operational resilience obligations before assigning the diligence programme. The FCA makes clear that firms remain accountable for applicable regulatory responsibilities when they outsource. Its 2026 guidance also flags forthcoming reporting changes effective in March 2027 for relevant firms. [S8]

For EU financial entities within DORA, Article 28 and Article 30 requirements may require specified ICT third-party governance and contract features. A UK vendor can be a relevant provider to an EU entity, but that does not mean every UK buyer is directly regulated by DORA. [S9]

Life sciences and research

Where CROs, research platforms, clinical trial systems or pharmacovigilance providers handle sensitive or regulated information, assess both privacy and domain-specific controls. A data hosting certificate cannot replace the sponsor's or responsible entity's clinical/research governance. Confirm data use, research agreements, validated systems where applicable and cross-border flows on the actual facts.

Enterprise SaaS and AI-enabled vendors

Assess privileged integrations, data-use boundaries, AI training and secondary-use settings, model/service suppliers, change notification and customer configuration. AI software risks are not reducible to one 'AI compliant' question. Apply the appropriate AI, privacy, cyber and contractual overlays according to actual role, service and jurisdiction.

Scenario A — Low spend, high privilege: A £2,000/year support utility receives production administrator access. Its low cost does not justify Tier 4. Verify identity, access restrictions, session logging, incident procedures, contract authority and safe revocation. Consider a higher tier based on access and potential impact.

Scenario B — Major cloud provider with scoped reports: A cloud supplier provides extensive third-party assurance. The buyer remains responsible for identity policy, configurations, encryption choices and application-level recovery. Requesting another general penetration test of the hyperscaler is unlikely to answer tenant-specific questions. Verify shared controls instead.

Scenario C — Healthcare SaaS with a strong cyber certificate: The supplier can demonstrate information security controls but cannot identify who owns the clinical safety case for the actual deployment. Cyber due diligence may proceed, but clinical readiness remains a separate hold until clinical safety responsibilities and evidence are resolved.

Scenario D — EU financial entity using a UK SaaS provider: Assess whether the EU financial entity is subject to DORA and whether the contract supports applicable ICT third-party arrangements. Do not assume the UK supplier itself has become an EU financial entity or that UK FCA obligations are identical.

The scenarios are fictional teaching examples, not descriptions of IG-Smart clients, investigations, deal values or actual supplier failures.

Scope and dependency

1. Which legal entity supplies this specific product and holds contractual responsibility?
2. Which system and business services rely on the supplier, and which are genuinely critical?
3. What production, data, administrator and network access exists at launch and in support?
4. Which fourth parties are essential to service delivery and incident recovery?
5. Where are data stored, accessed, backed up or routed, including support and telemetry?

Governance and evidence

1. What is the scope, validity and issuer of the proposed ISO or independent assurance evidence?
2. Which key controls are verified by operational artefacts rather than supplier statements?
3. What exceptions, scope exclusions or customer-responsibility controls remain?
4. What is the most recent independently assessed failure, and what remediation was evidenced?
5. How does the supplier manage privileged access and break-glass events?

Security and privacy

1. How are vulnerabilities identified, prioritised, mitigated and retested?
2. Which relevant application, cloud, API and code-release components were tested?
3. How does the supplier prevent unauthorised use of customer data for secondary purposes or AI model training?
4. What personal-data controller/processor roles apply to the proposed processing?
5. How are subprocessors authorised and notified, and how are equivalent protections flowed down?
6. If a restricted transfer occurs, what mechanism and assessment are relied upon?

Resilience and accountability

1. What has actually been tested against the buyer's recovery needs?
2. What are the practical limits of the provider's SLA and recovery guarantees?
3. How quickly and through which channel will the buyer learn of a material incident?
4. What information will the supplier preserve and share so the buyer can investigate?
5. Who owns known control exceptions and who can approve temporary conditions?
6. What substitute, exit, portability and credential revocation arrangements exist?

Regulatory and lifecycle

1. Does the arrangement trigger special clinical, outsourcing, financial-sector or AI obligations?
2. What events will trigger contract amendment, a new assessment or board escalation?
3. Can we reconstruct the approval decision a year later from the evidence, dates, reviewer notes and authorised sign-off?

SUPPLIER ASSURANCE DECISION — EXECUTIVE RECORD

Board discussion prompts: Does this supplier create concentration or a material single point of failure? Which claims were actually tested? What remains legally or clinically conditional? Which person is accountable if a key supplier control fails? Can we exit safely and recover our data and services?

Is ISO/IEC 27001 certification sufficient to approve a supplier?

No. It can be valuable scoped assurance, but the buyer must confirm certificate relevance, service-specific controls, shared responsibilities, material exceptions and its own risk appetite. A certificate is not a warranty against incidents.

Must every supplier complete the same questionnaire?

No. NCSC guidance supports proportionate, risk-based assurance. Applicable legal duties remain applicable regardless of tier. [S1][S2]

Can a supplier have a high score and still be rejected?

Yes. The weighted indicator summarises recorded evidence confidence. It cannot override an unmitigated critical exposure, a missing mandatory legal safeguard, or an unauthorised risk acceptance.

What is the difference between an inherent and residual risk tier?

An inherent tier describes exposure and diligence depth before credit is given for controls. Residual risk is a separately assessed conclusion after considering actual mitigations and context. The workbook intentionally does not calculate residual risk from collected-document percentages.

What is an evidence exception?

A time-bounded, documented variance from a specified requirement. It needs a reason, business consequence, alternative mitigation, owner, authority and review date. A waiver is not an assertion of legal compliance.

Should a vendor always provide a complete penetration-test report?

Not necessarily. Sensitive technical reports may require controlled disclosure or a credible alternative. Assess the scope, tester independence, findings, remediation and residual relevance; a cover letter alone may be insufficient for a high-risk service.

Is a SOC 2 Type II report equivalent to ISO/IEC 27001 certification?

No. They are different forms of independent assurance with different criteria, reporting boundaries and conclusions. Interpret the actual report, period and scope rather than equating badges.

Does appointing a processor transfer UK GDPR accountability?

No. The controller retains applicable duties and must establish appropriate Article 28 terms and safeguards. The processor also has its own duties. [S6][S7]

Does DORA apply to all UK companies selling software to banks?

No. DORA's primary obligations apply to specified EU financial entities and related in-scope parties. Contractual requirements can flow to providers serving those entities. Analyse each relationship on its facts. [S9]

When should supplier assurance be repeated?

When risk, service scope, evidence, fourth parties, applicable law or material incidents change—and at a cadence proportionate to the supplier's criticality. An annual checkbox is not a substitute for event-driven review.

Make the evidence request fit the supplier

The following are illustrative review lenses, not claims about any named supplier or completed IG-Smart engagement. Select only the tests relevant to the agreed service and risk. A generic questionnaire alone can miss the most consequential dependency.

Use remote document review where it can answer the question. Where justified, agree site visits, interviews, observation or authorised technical testing. Onsite attendance is not proof of effectiveness, and penetration testing requires explicit scope and permission. Treat privacy impact assessments as a distinct assessment where triggered, not a universal questionnaire substitute.

1. Start with the supplier inventory. Record the exact service, legal entity, internal owner, dependency and access/data map.
2. Approve a risk tier. Treat the workbook's calculated suggestion as a screening signal, not delegated authority.
3. Choose applicable controls. Use the 36-item library to build a proportionate evidence request; document omissions and legally mandatory overlays.
4. Verify rather than collect. Record each claim's source, date, limits, reviewer and confidence.
5. Escalate blockers. Track critical and high findings, contractual gaps, unauthorised transfers and clinical/operational concerns separately from the overall score.
6. Make a human decision. Document residual risk, conditions, authority and the point at which service/data access may proceed.
7. Monitor and reclassify. Set review triggers and a defensible lifecycle record.

Next step: Where a regulated buyer needs a bounded review, ongoing vendor oversight or an independently scoped assurance programme, IG-Smart can help define the supplier population, testing depth, accountability, evidence and reporting model. Talk to a Senior Practitioner or Submit a Requirement through the website enquiry routes. Final engagement scope, independent-assurance boundaries, pricing and outputs remain subject to proposal.

Using the revised evidence workbook safely

Set the assessment date on START HERE and use unique supplier and control IDs. The matrix now checks unknown IDs, duplicate supplier/control records, unresolved applicability, confidence values, evidence references, reviewers, future artefact dates and stale review dates. A percentage is neither a probability nor a compliance conclusion. A records-ready flag means only that the configured record checks have passed; independently examine the findings, exception and contract registers and obtain the required human approvals.

Confirm the supplied workbook’s actual configured capacity and supported row-expansion procedure. Extend formulas, validations and summary ranges together before adding further rows; the library does not define universally required controls. Never paste past the configured capacity and assume the summary includes the additional records. Conditional acceptance cannot authorise processing, deployment or service use while a mandatory legal or safety condition remains unmet.

• [S1] UK NCSC — Principles of supply chain security (12 principles). ncsc.gov.uk/collection/supply-chain-security/principles-supply-chain-security
• [S2] UK NCSC — How to assess and gain confidence in your supply chain cyber security. ncsc.gov.uk/collection/assess-supply-chain-cyber-security
• [S3] ISO/IEC 27036-2:2022 — Cybersecurity: Supplier relationships, Part 2, Requirements (official abstract). iso.org/standard/82060.html
• [S4] ISO/IEC 27036-3:2023 — Guidelines for hardware, software and services supply chain security (official abstract). iso.org/standard/82890.html
• [S5] NIST SP 800-161 Rev. 1 Update 1 (2024), Cybersecurity Supply Chain Risk Management Practices. csrc.nist.gov/pubs/sp/800/161/r1/upd1/final
• [S6] ICO — Contracts and liabilities between controllers and processors. ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/accountability-and-governance/contracts-and-liabilities-between-controllers-and-processors-multi/
• [S7] ICO — Contracts (UK GDPR Article 28 guide). ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/accountability-and-governance/guide-to-accountability-and-governance/contracts/
• [S8] FCA — Outsourcing and operational resilience (updated July 2026). fca.org.uk/firms/outsourcing-and-operational-resilience
• [S9] Regulation (EU) 2022/2554 — Digital Operational Resilience Act, notably Articles 28 and 30. eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32022R2554
• [S10] ICO — International transfers and transfer risk assessment / data protection test (current guidance). ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/international-transfers/
• [S11] NCSC — Check your supplier arrangements. ncsc.gov.uk/collection/supply-chain-security/principles-supply-chain-security/check-your-arrangements
• [S12] ISO/IEC 27036-1:2021 — Supplier relationships: overview and concepts. iso.org/standard/82905.html