A working third-party risk management framework has four stages: tier vendors by the risk they actually introduce, assess each vendor against that risk tier before contracts are signed, monitor vendor security continuously rather than once a year, and have a defined response plan for when a vendor experiences a breach that touches your data. Most TPRM programmes fail not because they lack a questionnaire, but because they stop at onboarding and never monitor or respond to vendor risk that emerges afterward.
Below is the full framework, including how to tier vendors correctly, what to actually ask, and how to build the ongoing monitoring most programmes skip entirely.
Why Third-Party Risk Management Has Become Non-Negotiable?
Modern organisations run on vendors. Cloud infrastructure, payroll processing, customer support tools, marketing platforms, and dozens of SaaS products each have some level of access to company or customer data. Every one of those relationships is a potential entry point that exists outside your direct control.
Regulators have caught up to this reality. Frameworks including SOC 2, ISO 27001, HIPAA, and emerging regulations such as DORA in the EU financial sector now explicitly require organisations to manage and document third-party risk, not just their own internal security. A breach originating from an uncontrolled vendor is no longer treated as an excuse. It is treated as a failure of your own risk management programme.
Digisecuritas' Third-Party Risk Management Consulting helps organisations build TPRM programmes that satisfy both regulatory expectations and genuine security need, rather than producing a questionnaire archive no one revisits.
Stage 1: Tier Your Vendors by Actual Risk
The single biggest mistake in TPRM is treating every vendor the same way. A payroll processor with access to employee bank details carries a fundamentally different risk profile than a vendor providing office furniture, even though both might appear on the same procurement list.
A practical tiering model:
- Tier 1, Critical: Vendors with access to sensitive data (customer PII, financial data, health records), direct network or system access, or vendors whose outage would halt core business operations. These require the deepest assessment and ongoing monitoring.
- Tier 2, Significant: Vendors with limited access to sensitive data or systems, or vendors that are important to operations but not critical. These require a meaningful but lighter-weight assessment.
- Tier 3, Low Risk: Vendors with no access to sensitive data or systems, such as physical suppliers or vendors providing services entirely disconnected from your data environment. A lightweight, largely contractual review is usually sufficient.
Tiering should be based on data sensitivity, system access level, and business criticality, not on contract value or vendor reputation. A small, low-cost vendor with deep system access is a higher risk than a large, expensive vendor with none.
Stage 2: Assess Before You Sign, Not After
Once a vendor is tiered, the assessment depth should match that tier. This is where most security questionnaires either become a useless box-ticking exercise or an effective filter, depending entirely on how they are built and reviewed.
What to Actually Ask
For Tier 1 vendors, a meaningful assessment covers:
- Data handling: What specific data will the vendor access, store, or process, and where is it stored geographically
- Certifications and audits: Does the vendor hold SOC 2 Type II, ISO 27001, or equivalent certification, and can they provide the actual audit report, not just a badge on their website
- Access controls: What authentication standards does the vendor enforce internally, including MFA requirements for their own staff accessing your data
- Incident history and response: Has the vendor experienced a breach in the past 24 months, and what was their notification timeline and response process
- Sub-processors: Does the vendor use their own third parties (sub-processors) to deliver the service, and what is their oversight process for those sub-processors
- Breach notification terms: What does the contract specify about notification timelines if the vendor experiences a breach affecting your data
- Right to audit: Does your contract include the right to request evidence of security controls or conduct an audit, not just a one-time questionnaire at signing
A vendor's marketing page claiming they are "SOC 2 compliant" is not evidence. The actual SOC 2 report, including the auditor's findings and any noted exceptions, is evidence. Request the document, not the claim.
Where Questionnaires Fall Short
Standard vendor security questionnaires, often built from templates like SIG or CAIQ, are useful starting points but are frequently filled out by a vendor's sales or compliance team with limited technical accuracy, and rarely verified by the customer requesting them. Treat questionnaire responses as a starting point for follow-up, not as the assessment itself, particularly for Tier 1 vendors where the stakes justify a deeper review or independent verification.
Digisecuritas' Compliance Audit Readiness work includes building vendor assessment processes that go beyond template questionnaires, incorporating actual evidence review aligned to frameworks like SOC 2 and ISO 27001, which most vendors are increasingly expected to hold.
Stage 3: Monitor Continuously, Not Annually
This is the stage most TPRM programmes skip entirely, and it is the most important one. A vendor that passed a thorough assessment at onboarding can introduce new risk six months later through a misconfiguration, a new sub-processor, an unpatched vulnerability, or their own security incident, none of which an annual questionnaire would catch in time.
Practical continuous monitoring approaches:
- Security ratings services that provide ongoing, externally observable risk scoring for vendors based on factors such as exposed vulnerabilities, certificate hygiene, and breach history
- Breach and incident monitoring to catch news of a vendor security incident as it happens, rather than discovering it weeks later through their own delayed disclosure
- Periodic re-assessment for Tier 1 vendors, at minimum annually, with lighter-touch reviews for Tier 2 vendors on a longer cycle
- Contractual triggers requiring vendors to proactively notify you of material changes to their security posture, sub-processor list, or data handling practices
Continuous monitoring does not need to mean constant manual review of every vendor. It means having a process that surfaces meaningful changes in vendor risk between formal assessment cycles, so issues are caught in weeks, not discovered a year later during the next scheduled review.
Stage 4: Have a Response Plan Before a Vendor Breach Happens
Most organisations have an incident response plan for their own environment. Far fewer have a defined process for what happens when a vendor, not them, experiences a breach that affects their data.
A vendor breach response plan should define:
- Notification verification: A process to confirm a vendor breach notification is legitimate, since attackers sometimes impersonate breach notifications as a secondary social engineering attempt
- Impact assessment: A fast process to determine what data of yours the affected vendor actually had access to, which depends heavily on accurate records from the assessment stage
- Communication obligations: Your own regulatory and customer notification obligations that may be triggered by a vendor breach, which exist independently of the vendor's own obligations
- Contractual recourse: What the contract specifies about liability, remediation costs, and termination rights in the event of a vendor security failure
The principles here overlap significantly with internal incident response. The notification timelines, evidence requirements, and communication discipline covered in our ransomware incident response playbook apply just as directly when the breach originates at a vendor rather than inside your own environment.
A Practical TPRM Maturity Checklist
- All vendors tiered by data sensitivity, system access, and business criticality, not by contract value alone
- Tier 1 vendor assessments include actual SOC 2 or ISO 27001 report review, not just a questionnaire
- Breach notification timelines are explicitly defined in vendor contracts
- A continuous monitoring process exists for Tier 1 vendors between formal review cycles
- Sub-processor disclosure is required and reviewed for any vendor with access to sensitive data
- A defined response plan exists specifically for vendor-originated breaches
- Vendor risk ownership is assigned to a specific role, not left to whichever team initiated the procurement
Conclusion
Most third-party risk management programmes are built to satisfy an audit checkbox: a questionnaire sent at onboarding, filed away, and revisited only when a renewal or a new compliance cycle forces another look. That approach catches almost nothing, because the risk that actually causes breaches tends to emerge after onboarding, not during it.
A framework built around tiering, real evidence review, continuous monitoring, and a defined vendor breach response plan catches the risk that actually matters, and does so before it becomes your incident rather than after.
Digisecuritas helps organisations build third-party risk management programmes that go beyond questionnaire archives, including vendor tiering, evidence-based assessment, and continuous monitoring.
Book a Discovery Call to assess where your current vendor risk programme stands.
Frequently Asked Questions
How many vendors should undergo a full security assessment?
Only Tier 1, critical vendors need the deepest level of assessment. Tiering by data sensitivity and system access first prevents organisations from either over-investing in low-risk vendor reviews or, more dangerously, under-investing in genuinely critical ones because the process treats every vendor identically.
Is a completed security questionnaire enough to approve a vendor?
For lower-tier vendors, often yes. For Tier 1, critical vendors, a questionnaire alone is rarely sufficient. Request the actual SOC 2 or ISO 27001 audit report, and follow up on any gaps or exceptions noted in the questionnaire responses before approval.
How often should vendor risk assessments be repeated?
At minimum annually for Tier 1 vendors, with continuous monitoring filling the gap between formal reviews. Lower-tier vendors can typically be reassessed on a longer cycle, such as every 18 to 24 months, unless a material change occurs.
What is a sub-processor and why does it matter for vendor risk?
A sub-processor is a third party that your vendor uses to help deliver their service, meaning your data may pass through an organisation you never directly assessed or contracted with. Requiring sub-processor disclosure ensures your risk visibility extends beyond just the vendor you signed a contract with.
Who should own third-party risk management inside an organisation?
This varies, but it typically sits with security, compliance, or procurement, often as a shared responsibility. The critical factor is that ownership is explicitly assigned to a specific role or team, rather than left ambiguous, which is how vendor risk most often falls through the cracks.