Third-party / vendor risk assessment program

Description

A working vendor risk-assessment program identifies every vendor that handles regulated data, money, or critical infrastructure; classifies them by the risk they introduce; applies due diligence proportionate to that risk; and monitors on an ongoing basis. The components are a vendor inventory that stays current as the SaaS footprint changes, a risk-classification tier that distinguishes a CDN from a payroll processor from a sub-custodian, a due-diligence pack per tier (security questionnaires, SOC 2 reports, sub-processor disclosures, incident history, financial-health signals where relevant), and a periodic-review cadence that catches vendor changes including acquisitions, security incidents, and control regressions. The regulatory frame layers across the institution's other obligations rather than sitting alongside them. GDPR Article 28 processor due diligence is the privacy expression. NIS2 Article 21(2)(d) supply-chain security is the cybersecurity expression. NYDFS Part 500's third-party service provider rules apply to financial-services institutions doing business in New York. DORA Articles 28-30 frame ICT third-party risk for EU financial-services institutions, with the additional designation regime for critical ICT third-party providers that brings them within direct supervisory scope. The AICPA SOC 2 trust criteria provide the contractual vehicle most operators rely on to get assurance over vendor controls without conducting their own audits. Operators commonly run one risk-assessment program with regime-specific questionnaire additions and use the same artifacts (SOC 2, sub-processor lists, pen-test summaries) across multiple framework attestations. The vendor inventory is harder to keep complete than it looks. Engineering teams add SaaS faster than procurement learns about it, and the gap between the procurement system and the actual production dependency graph is where unreviewed vendors live. The pattern that holds up under audit ties the inventory to spend (every recurring vendor spend over a threshold flags for review), to identity (every system that holds an OAuth credential from production) and to network (every outbound destination in production traffic logs). DORA and recent banking-supervision guidance have surfaced the concentration-risk angle that single-vendor diligence does not catch: a portfolio of well-assessed vendors can still represent unacceptable concentration if too many depend on the same underlying cloud, identity provider, or shared infrastructure. Evidence formats that hold up include the published vendor inventory keyed to procurement and to data flows, the risk-tier matrix with documented criteria for tier assignment, and the periodic re-assessment log showing review cadence and findings.

Required by (3 regulations)

• NIS2

  Article 21(2)(d) — supply chain security.

• GDPR

  Article 28 — processor due diligence.

  Regulation (EU) 2016/679 of the European Parliament and of the Council

• China CIIPA

  China CIIPA requires security assessment of products and services procured for critical information infrastructure.

  Regulations on the Security Protection of Critical Information Infrastructure (State Council Order No. 745); implementing Cybersecurity Law Articles 31-39

  Source →

Fulfilled by (2)

• onetrust · full · medium effort · $$
• In-house build · medium effort

Magist does not accept payment from vendors. Methodology.

Evidence formats

• vendor inventory
• risk-tier matrix
• periodic re-assessment log