Third-Party Risk Management Frameworks: A Practical Guide
NIS2 requires it. DORA mandates it. ISO 27001 expects it. StartComply helps European organisations turn ad hoc vendor reviews into a continuously monitored, audit-ready framework that can prove compliance when regulators ask for evidence.
Trusted by 100+ organisations across Europe
NIS2 
DORA 
ISO 27001:2022 
TPRM Framework What you need to know about 3rd party risk management frameworks
- A 3rd party risk management framework is a mandatory operating structure under NIS2 Article 21 and DORA Articles 28 to 30, not an optional governance exercise.
- The core framework components are vendor inventory and tiering, risk assessment and due diligence, contractual controls, ongoing monitoring, and incident escalation.
- Every framework component must produce audit-ready evidence, not just internal records or spreadsheet notes.
- Frameworks must map explicitly to regulatory articles. A framework that cannot cite NIS2 Article 21 or DORA Article 30 is incomplete for European regulatory purposes.
- Spreadsheets break at scale. Organisations with more than 30 active vendors under assessment need automation to keep the framework operational.
- NIS2 fines can reach €10 million or 2% of global annual turnover for essential entities, making the cost of a functioning framework a fraction of the exposure.
- Operationalising a framework in 90 days is achievable: inventory and tiering first, assessments and contract gap analysis second, monitoring cadence and escalation paths third.
Sources: NIS2 Directive, DORA Regulation. Last updated May 2026.
Third-Party Risk Frameworks Are a Regulatory Requirement
A documented, mapped, evidence-backed framework
- NIS2 Article 21: supply chain security as a mandatory cybersecurity measure for essential and important entities
- DORA Articles 28 to 30: ICT provider register, concentration risk monitoring, and contractual controls
- ISO 27001:2022 Annex A 5.19 to 5.22: supplier relationship controls, agreements, ICT supply chain, and monitoring
- NIS2 Article 23: incident escalation workflows when a third party incident creates a reporting obligation
- Audit-ready evidence: vendor register, tiering rationale, assessments, contracts, monitoring logs, and incident records
Penalty exposure: NIS2 fines can reach €10M or 2% of global turnover for essential entities. Sources: NIS2 Directive, DORA Regulation.
Manual registers, email evidence, annual questionnaires
- No central vendor inventory, with critical suppliers scattered across spreadsheets and inboxes
- No reliable tiering rationale showing why a vendor is critical, high, medium, or low risk
- Completed questionnaires stored as attachments rather than linked to the vendor record
- Contractual findings that do not flow into enforceable SLAs, audit rights, or termination clauses
- Annual reassessments that fail to show continuous monitoring between formal reviews
- Vendor incidents sitting in inboxes while NIS2 reporting clocks continue running
The audit reality: regulators do not ask whether you manage vendor risk. They ask for files, dates, owners, decisions, follow-ups, and evidence that controls operate continuously.
The Core Components of a 3rd Party Risk Management Framework
Vendor Inventory and Tiering
You cannot manage what you have not mapped. StartComply gives you a current record of every third party, subcontractor, and material fourth party, then tiers each relationship by inherent risk.
- Complete vendor inventory with contract owners, services, data types, and criticality
- Risk tiers based on operational criticality, data access, regulatory classification, and substitutability
- DORA Article 28 ICT provider register structure ready for regulated financial entities
- Clear rationale showing why each vendor receives critical, high, medium, or low oversight
Risk Assessment and Due Diligence
Once vendors are tiered, StartComply sends the right level of due diligence automatically, from full questionnaires for critical vendors to proportionate attestation for lower-risk suppliers.
- Structured questionnaires covering cybersecurity, business continuity, data processing, and subcontractors
- Configurable scoring aligned to your risk appetite and supplier tiering model
- Evidence requests for ISO 27001, SOC 2, penetration testing, and policy documentation
- Version-controlled assessments linked directly to the vendor record
Contractual Controls and SLAs
Assessment findings must flow into enforceable obligations. StartComply helps teams track contractual gaps against DORA Article 30, NIS2 supply chain expectations, and internal control requirements.
- DORA Article 30 provisions for service descriptions, audit rights, data location, termination rights, and incident notification
- SLA tracking for recovery time, business continuity, security reporting, and remediation deadlines
- Contract gap logs with owners, due dates, and remediation status
- Evidence that risk findings are converted into contractual controls, not left as observations
Ongoing Monitoring and Reassessment
Onboarding due diligence is only a snapshot. StartComply keeps the framework alive between formal reviews by monitoring signals that can change vendor risk in real time.
- Continuous monitoring for vendor incidents, financial distress, sanctions, regulatory changes, and material risk events
- Tier-based reassessment cadence for critical, high, medium, and low-risk vendors
- Trigger-based reassessments after acquisitions, breaches, subcontractor changes, or service changes
- Automatic updates to vendor risk status when monitoring signals change
Incident Response and Escalation
When a vendor incident occurs, the framework must define who is notified, who owns the decision, and whether regulatory reporting is triggered. StartComply routes alerts before deadlines become problems.
- Auto-escalation workflows for third party incidents and high-risk monitoring alerts
- NIS2 Article 23 reporting clocks reflected in internal escalation paths
- Incident logs linked to the affected vendor, service, owner, and evidence trail
- Clear decision records for reporting, remediation, and follow-up actions
StartComply vs. The Alternatives
A third party risk management framework only works if it runs continuously and produces evidence without a last-minute audit scramble.
StartComply is built for European organisations that need a working TPRM framework, not another static template.
What Is a 3rd Party Risk Management Framework?
A 3rd party risk management framework is a repeatable operating structure for identifying, assessing, monitoring, and managing risks that arise from vendor and supplier relationships. It tells your team what to do, when to do it, who owns it, and how each activity is evidenced.
Without a framework, vendor risk management becomes reactive. Teams chase questionnaires manually, store evidence in email threads, and scramble before audits. With a framework, the lifecycle becomes structured: onboarding, tiering, due diligence, contract review, ongoing monitoring, incident escalation, and offboarding.
For European organisations, the framework must map directly to regulatory obligations. NIS2 Article 21 requires supply chain security measures, DORA Article 28 mandates a register of ICT third-party service providers, and ISO 27001:2022 Annex A Control 5.19 requires formal information security in supplier relationships.
A framework document is not a framework. The workflow has to run, the evidence has to accumulate, and the team has to know exactly what happens when a vendor risk changes.
How to Operationalise Your Framework in the First 90 Days
Build the vendor inventory Days 1 to 30
Pull every active vendor relationship into a single register. Capture contract owner, service category, data processed, operational criticality, existing due diligence, and renewal dates. Then apply practical tiers: critical, high, medium, and low. The inventory is the foundation for every assessment, monitoring decision, and incident response action that follows.
Run assessments and contract gap analysis Days 31 to 60
Send structured risk assessments to critical and high-tier vendors. Cover cybersecurity controls, business continuity, data processing, and subcontractor management. At the same time, review critical contracts for DORA Article 30 provisions and NIS2 supply chain expectations. Contractual gaps with critical vendors should become remediation actions with owners and deadlines.
Set cadence and escalation paths Days 61 to 90
Define monitoring cadence by tier: continuous alerting and monthly review for critical vendors, quarterly review for high-tier vendors, and proportionate attestation for lower-risk vendors. Define who receives vendor incident alerts, who owns the regulatory reporting decision, and what the internal SLA is. By day 90, the workflow should be operational, not just documented.
Client Testimonials
“We evaluated enterprise platforms costing 10x more. StartComply does what we need at a price that makes sense.”Elena Kowalski
“Finally, a compliance tool that understands European regulations. StartComply got us audit-ready in weeks, not months.”Maria Papadopoulou
“The AI policy engine alone saved us hundreds of hours. And the third-party risk management is exactly what DORA requires.”Thomas Müller
Frequently Asked Questions About 3rd Party Risk Management Frameworks
What is a 3rd party risk management framework and what does it include?
A 3rd party risk management framework is a structured, repeatable programme for identifying, assessing, monitoring, and managing risks that arise from vendor and supplier relationships. It includes a vendor inventory, risk tiering criteria, due diligence and assessment processes, contractual control requirements, ongoing monitoring cadences, and incident escalation procedures. For European companies, the framework must also produce audit-ready evidence mapped to specific regulatory articles such as NIS2 Article 21 and DORA Article 28.
Is a third party risk management framework legally required in the EU?
Yes. NIS2 Article 21 requires essential and important entities to implement supply chain security measures as part of their overall cybersecurity obligations. DORA Articles 28 to 30 mandate a documented ICT third-party risk management framework for financial entities, including a vendor register, concentration risk monitoring, and specific contractual provisions. ISO 27001:2022 also requires formal supplier risk management under Annex A Controls 5.19 to 5.22. A framework is not optional for organisations in scope of these regulations.
How is a third party risk framework different from a vendor due diligence checklist?
A checklist is a point-in-time tool. A framework is an ongoing operational programme. Due diligence checklists cover onboarding assessment but do not address continuous monitoring, contractual enforcement, incident escalation, or regulatory reporting obligations. A mature 3rd party risk management framework incorporates the checklist as one component within a broader lifecycle, from initial vendor tiering through to offboarding.
How many vendor tiers should a third party risk framework use?
Four tiers is the practical standard: critical, high, medium, and low. Tiering criteria typically combine data sensitivity, operational criticality, regulatory classification, and substitutability. Critical and high-tier vendors receive full due diligence, quarterly monitoring, and contractual reviews. Medium and low-tier vendors receive proportionate oversight. More than four tiers often creates administrative burden without meaningful risk differentiation.
What evidence does a regulator expect from a third party risk management framework?
Regulators expect documented and retrievable evidence at each framework stage. This includes a current vendor register with tiering rationale, completed risk assessments and questionnaire responses, signed contracts with regulatory-required clauses, monitoring records showing ongoing oversight, and incident logs demonstrating escalation and notification within required timelines. Evidence must be version-controlled and accessible without manual assembly.
How often should third party risk assessments be repeated?
Reassessment frequency should be proportionate to vendor tier and risk profile. Critical ICT vendors under DORA should be reassessed annually at minimum, with continuous monitoring between formal assessments. High-tier vendors typically warrant annual reassessment. Medium and low-tier vendors may operate on an 18 to 24-month cycle with annual attestation. Trigger-based reassessments are also required after acquisitions, data breaches, or material operational changes.
Stop Running Your TPRM Framework From Spreadsheets.
How the Framework Maps to NIS2, DORA and ISO 27001
A 3rd party risk management framework that does not map to specific regulatory articles is not audit-ready. Regulators do not accept generic assurances. They expect you to point to a control, show the evidence, and demonstrate that it operates continuously.
The strongest frameworks translate each obligation into an operational output: a register, an assessment, a contract clause, a monitoring record, or an incident escalation record.
ISO 27001:2022 aligns closely. Annex A Controls 5.19 to 5.22 cover supplier relationships, supplier agreements, ICT supply chain, and monitoring, making your TPRM framework a major part of the audit scope.
90-Day Framework Rollout Timeline
Confirm framework scope: legal entities, supplier categories, business owners, regulatory drivers, and evidence ownership.
Build the vendor register and apply tiering criteria. Critical, high, medium, and low is enough for most organisations.
Run assessments for critical and high-tier vendors, then document contractual gaps against DORA Article 30 and NIS2 Article 21 expectations.
Set monitoring cadence, reassessment triggers, internal SLAs, incident escalation paths, and regulatory reporting decision ownership.
The framework should now be operational: evidence is accumulating, risk scores are maintained, and vendor incidents follow a defined escalation path.
Audit reality:
By the time a regulator asks for evidence, it is too late to build the framework. The register, assessments, contracts, monitoring records, and incident logs must already exist.
The 5 Core Components of a Complete TPRM Framework
Each component has a specific function and a specific output that feeds the next stage. When one is missing, the framework stops being auditable.
Vendor inventory and tiering
A complete, current register of third parties, subcontractors, and material fourth parties, with every vendor tiered by inherent risk, data access, operational criticality, regulatory classification, and substitutability.
Risk assessment and due diligence
Structured questionnaires and evidence requests proportionate to vendor tier, covering cybersecurity, business continuity, data processing, subcontractor management, and regulatory requirements.
Contractual controls and SLAs
Assessment findings converted into enforceable obligations, including audit rights, incident notification timelines, recovery expectations, data location terms, termination rights, and remediation deadlines.
Ongoing monitoring and reassessment
Continuous monitoring between formal reviews, including incidents, financial distress, regulatory status changes, sanctions, acquisitions, breaches, and other material changes that alter vendor risk.
Incident response and escalation
Clear escalation paths for vendor incidents, including internal notifications, reporting decisions, evidence logging, remediation ownership, and follow-up actions before regulatory deadlines expire.
