Third-Party Risk Management Framework for Suppliers: How DORA, SIG, CAIQ, ISO 27001, and Bank-Specific Requirements Fit Together.

Last reviewed: 2 October 2026. Framework versions and buyer requirements can change. Check the current source and your customer's instructions before responding.

Quick answer

DORA, SIG, CAIQ, ISO/IEC 27001 and a bank's custom questionnaire do different jobs. DORA is EU law governing in-scope financial entities' ICT risk and third-party arrangements. SIG and CAIQ are structured question sets that buyers may use to collect information. ISO/IEC 27001 specifies requirements for an information security management system, and certification can provide independent assurance within a defined scope. Bank-specific requirements apply those inputs to one service, risk appetite and contract. A supplier can reuse underlying facts and evidence across them, but should not treat one completed template as universal approval.

A map of the layers

Layer	Primary role	What a SaaS supplier should prepare
DORA	Legal duties for in-scope EU financial entities managing ICT third-party risk	Accurate service, location, subcontracting, resilience and contract information for the customer's assessment.
SIG	Broad third-party assessment questionnaire from Shared Assessments	Approved answers across applicable risk domains, each linked to supporting evidence.
CAIQ / CCM	Cloud-focused questions and controls from Cloud Security Alliance	Cloud service boundary, shared-responsibility explanation and control evidence.
ISO/IEC 27001	ISMS requirements and, optionally, independent certification	Certificate and scope if held; relevant policies, risk treatment and operating records.
Bank-specific layer	The buyer's own service-specific risk decision and contract	Answers to local questions, agreed exceptions, notification terms, service levels and exit details.

This table is an interpretation for supplier preparation. The DORA text, Shared Assessments SIG overview, CSA's CCM and CAIQ materials and ISO's 27001 overview define the individual sources.

DORA sets the bank's obligation

DORA applies to in-scope EU financial entities and provides a separate oversight regime for ICT providers formally designated critical. An ordinary SaaS supplier is not directly subject to all DORA duties simply by selling to a bank. Still, Articles 28 and 30 require financial entities to assess ICT third-party arrangements and include specified contractual elements. The buyer therefore needs supplier facts about services, locations, security, incidents, subcontracting, continuity and exit. Requirements become more demanding when the ICT service supports a critical or important function.

Respond to the customer's actual service classification and proposed contract. Avoid the broad claim “DORA certified”: DORA is not a general supplier certification. See the DORA guide for ICT vendors for the legal boundary and practical flow-down.

SIG and CAIQ organize questions

The Shared Assessments SIG standardizes vendor risk questions across multiple domains. A bank may scope it, shorten it or add its own questions. The CSA CAIQ provides cloud-control questions tied to the Cloud Controls Matrix. CAIQ is especially useful where the product is a cloud service, but a completed CAIQ does not answer a bank's contract, operational dependency or entity-specific questions by itself.

Treat both as request formats. Keep an internal canonical statement such as “production privileged access is reviewed every quarter,” with the responsible owner and evidence. Map that statement into the precise SIG, CAIQ or custom question only after checking whether its wording asks about a different population, cadence or environment.

ISO 27001 provides assurance, within scope

ISO/IEC 27001:2022 defines ISMS requirements. An accredited certification can help a reviewer trust that the management system has been assessed. It does not automatically establish that every bank-specific service, legal entity, data flow or recovery commitment is covered. Provide the certificate, its scope and validity, then point to the particular control evidence needed for the question. If you are not certified, state that plainly and describe your implemented controls without implying certification.

The bank-specific layer makes the final decision

The buyer's own assessment joins these sources to its risk tier, data classification, outsourcing decisions and contract. In the US, the interagency third-party guidance calls for due diligence proportionate to the relationship's risk and complexity. In the EU, the bank applies DORA and other applicable requirements to its own arrangement. Neither a generic SIG answer nor a certificate overrides the customer's particular risk decision.

That is why custom questions may ask for a notification period, a particular data location, a named subprocessor, a tested recovery target or evidence of a control operating in the purchased product. Record such items as customer-specific obligations rather than changing your general answer library for everyone.

Build one evidence model, then map outward

Create a small canonical record for each claim:

1. Control statement: what the supplier actually does, in present tense and within a defined service boundary.
2. Owner and approval: who can verify and approve the statement.
3. Evidence: policy plus a recent operating record where appropriate, with version and date.
4. Scope: legal entity, product, environment, geography and customer responsibility.
5. Framework mapping: relevant SIG or CAIQ question, ISO control or certificate reference, DORA-related request and bank-specific clause.
6. Exception and refresh trigger: where the claim does not fully apply and what event requires a review.

For example, one approved subprocessor record may support a CAIQ supply-chain answer, a SIG supplier-management question and a bank's DORA-related contract schedule. The response still needs different detail for each request. A simple mapping is useful; a one-to-one equivalence claim between frameworks is usually too strong.

Keep a change log. If you move a service to another region or replace a critical subprocessor, the underlying fact changes across several answers and customer commitments at once. Update the source record first, then identify affected submissions and contracts.

Where MatchAudit fits

MatchAudit's Vendor Assurance workspace can hold approved supplier facts and reusable evidence, organize customer-specific requirements, and help a reviewer draft responses linked to those sources. It is a workflow aid for maintaining consistency across assessments. It does not certify controls, provide legal advice or decide the bank's risk appetite. If framework mapping and repeated customer requests are consuming your team's time, explore Vendor Assurance.

Related reading

• Vendor Due Diligence for SaaS Suppliers shows what belongs in the evidence pack.
• Third-Party Risk Assessment for Vendors covers the questions that arrive in a bank review.
• DORA Register of Information for Suppliers covers structured supplier data EU financial customers may request.

FAQ

Does completing SIG or CAIQ make a supplier compliant with DORA?

No. They are questionnaire formats. DORA governs the financial entity's ICT risk management and contractual arrangements; the customer assesses the supplier and its specific service against those obligations.

Can an ISO 27001 certificate replace a bank questionnaire?

Only if that bank accepts it for the relevant questions. Banks may still require service-specific details, exceptions and contractual commitments.

What is the best starting point for a small supplier?

Define the service and its data flows, assign control owners, collect current evidence, and record accurate reusable answers. Map those answers to frameworks when a real buyer request arrives.