The 200-question annual vendor assessment was designed for a world of stable supplier relationships, on-premise infrastructure, and annual audit cycles. That world no longer exists. Your organisation's third-party ecosystem now includes layered SaaS dependencies, multi-cloud infrastructure providers, sub-processors three and four levels deep, API integrations that engineering adopted without procurement's knowledge, and open-source components maintained by volunteers. An annual questionnaire captures a self-reported snapshot of this ecosystem at one moment in time — and that snapshot begins decaying the day it is completed.
NIS2 Article 21(2)(d) requires entities to implement supply chain security measures. DORA Chapter V mandates continuous management of ICT third-party risk. Neither regulation accepts the traditional model: assess annually, store in spreadsheet, forget for twelve months. The shift is structural. Third-party risk management must become continuous, event-driven, and concentration-aware. Organisations that treat this as an incremental improvement to their existing questionnaire programme will find themselves non-compliant and, more importantly, operationally exposed.
The Structural Failure of Annual Questionnaires
Annual questionnaires fail for four reasons that are inherent to the model, not fixable by making questionnaires better.
Self-attestation without verification. A questionnaire is a self-reported assessment. The vendor describes its own controls, its own incident history, and its own compliance status. For low-risk vendors providing non-critical services, self-attestation may be proportionate. For critical vendors whose failure would disrupt your essential operations, accepting unverified self-assessment as your primary risk signal is like accepting a driver's self-reported driving record as proof of insurance. Under NIS2 Article 21(2)(d), supply chain security measures must consider "the overall quality of products and cybersecurity practices of their suppliers and service providers." Self-attestation alone does not satisfy "consider."
Point-in-time answers in a continuous-change environment. Cloud providers ship changes daily. SaaS vendors modify their data processing locations, update their sub-processor lists, acquire new companies, and experience security incidents on timelines measured in days and weeks, not years. A vendor that reported strong access controls in January may have suffered a credential compromise in March, reorganised its security team in June, and migrated to a new cloud region in September — all invisible to the organisation that assessed them twelve months ago and will not reassess until next January.
No concentration risk visibility. Annual questionnaires assess vendors individually. They do not reveal concentration risk — the pattern that emerges when multiple critical services depend on the same underlying provider, data centre, or technology platform. If your CRM, your email platform, and your identity provider all run on the same cloud infrastructure, you have a concentration risk that no individual vendor questionnaire will surface. DORA Article 28(8) explicitly requires concentration risk assessment. NIS2 Article 21(2)(d) implicitly demands it through its requirement for supply chain security that accounts for "vulnerabilities specific to each direct supplier and service provider."
Operational uselessness during incidents. When a critical vendor experiences a security incident, the question your incident response team needs to answer is: "What do we depend on from this vendor, and what is the blast radius?" An annual questionnaire completed eight months ago does not answer this question. It tells you what the vendor's controls looked like eight months ago. It does not tell you what services you consume, which of your business functions depend on those services, or what your exposure is to the specific incident. If your third-party risk data cannot support real-time incident triage, it is not operational — it is administrative.
What NIS2 and DORA Actually Require
The regulatory shift from periodic to continuous third-party risk management is not aspirational. It is prescribed.
NIS2 Article 21(2)(d): Supply chain security. NIS2 requires essential and important entities to implement "supply chain security, including security-related aspects concerning the relationships between each entity and its direct suppliers or service providers." The implementing guidance specifies that these measures should address the overall quality of products and cybersecurity practices of suppliers, account for the results of risk assessments, and consider vulnerabilities specific to each supplier. This language requires active, ongoing management — not annual assessment and file storage.
The supply chain security obligation extends to consideration of the "overall level of diversification of suppliers and service providers." This is a concentration risk requirement in all but name. Organisations must understand not just who their suppliers are but whether their supplier portfolio creates dependency concentrations that could amplify the impact of a single supplier failure.
DORA Chapter V: ICT third-party risk management. DORA goes further than NIS2 with prescriptive operational requirements. Article 28(3) mandates a register of information covering all contractual arrangements with ICT third-party service providers, maintained and kept up to date. Article 28(8) requires identification and assessment of concentration risk. Article 30 specifies mandatory contractual provisions including incident notification, audit rights, and exit strategies. These are not annual exercises — they are continuous operational obligations. For a deeper dive into DORA's specific TPRM provisions, including the register of information and exit strategy requirements, see our detailed operational guide.
GDPR Article 28: Processor obligations. While GDPR's third-party provisions are older and more familiar, they remain relevant. The requirement that processors "shall not engage another processor without prior specific or general written authorisation of the controller" means that sub-processor changes by your vendors require your awareness and, often, your consent. An annual questionnaire cannot capture sub-processor changes that occur between assessment cycles.
The combined effect of these three regulatory frameworks is that any organisation operating in the EU must manage its third-party risk continuously, with event-driven reassessment, concentration risk visibility, and operational readiness for vendor incidents. The annual questionnaire is no longer the foundation of a compliant programme — it is one input among many.
The Shift to Continuous Third-Party Risk Management
Continuous TPRM does not mean monitoring every vendor in real time. That is neither practical nor necessary. It means building a system that detects relevant changes in your vendor ecosystem and triggers proportionate responses. The model operates on four pillars.
Dynamic risk tiering. Not all vendors warrant the same level of monitoring. Tier your vendors based on criticality to your business operations, sensitivity of data processed, regulatory significance, and substitutability. Critical vendors (Tier 1) that support essential business functions or process sensitive data receive continuous monitoring and quarterly deep assessments. Important vendors (Tier 2) receive event-driven monitoring and semi-annual assessments. Standard vendors (Tier 3) receive annual questionnaire-based assessment. This tiering should be reviewed semi-annually as your vendor landscape evolves.
Event-driven assessment. Define the events that trigger reassessment for each tier. For Tier 1 vendors, triggers should include: security incident (disclosed or detected), ownership change (acquisition, merger, major investment), leadership change (CISO departure, security team restructuring), sub-processor change, certification expiry or revocation, regulatory enforcement action, significant service change, and financial distress indicators. When a trigger event occurs, initiate a proportionate reassessment — not a full annual questionnaire, but a focused assessment of the event's impact on your risk exposure.
Concentration risk analysis. Maintain a living map of your vendor dependencies, including transitive dependencies. Which vendors share the same underlying infrastructure? Which critical business functions would be affected if a single cloud provider experienced a prolonged outage? What is your single largest concentration exposure, and what is your mitigation plan? This analysis should be updated quarterly and reported to the management body. Under both NIS2 and DORA, concentration risk is a board-level governance concern, not a procurement detail.
Operational integration with incident response. Your TPRM data must be accessible to your incident response team in real time. When a vendor incident is disclosed, the incident team needs to answer "what is our exposure?" within minutes, not hours. This requires that your vendor register, dependency mapping, and risk assessments are maintained in a system that can be queried operationally — not in spreadsheets stored on a shared drive that someone in procurement last updated six months ago.
What Modern TPRM Looks Like in Practice
A modern TPRM programme combines several information sources and operational capabilities that the questionnaire-only model lacks.
Automated signal collection. Security rating services, breach notification feeds, regulatory enforcement databases, corporate registry changes, and certificate transparency logs provide continuous external signals about your vendors' security posture and business stability. These signals do not replace direct assessment but they fill the visibility gap between assessment cycles. A vendor whose security rating drops by 15 points in a quarter warrants investigation regardless of when the next annual assessment is scheduled.
Vendor collaboration portals. Instead of exchanging questionnaires by email, modern programmes provide vendors with a structured portal where they can maintain their security profile, update their sub-processor lists, report incidents, and share evidence. This shifts the update burden to the vendor — who has the most current information — and creates a living record rather than a point-in-time document.
Automated compliance mapping. When your organisation's compliance requirements change — a new NIS2 implementing act, an updated DORA regulatory technical standard, a revised ISO 27001 control — the TPRM programme should automatically identify which vendors are affected and trigger reassessment of the relevant controls. This prevents the common failure mode where regulatory changes are implemented internally but not propagated to vendor assessments.
Exit readiness tracking. For critical vendors, maintain a current exit readiness assessment: how long would migration take, what alternatives are available, what data portability mechanisms exist, and what is the estimated cost? This assessment should be updated whenever the scope of services changes or when the vendor risk profile shifts. DORA Article 28(8) makes exit strategy maintenance a regulatory requirement for financial entities; NIS2's supply chain security provisions make it a practical necessity for everyone else.
The Questionnaire's Remaining Role
Annual questionnaires are not eliminated in a continuous TPRM model — they are repositioned. The questionnaire becomes one data source among many, appropriate for Tier 3 vendors where the risk profile does not justify continuous monitoring, and as a periodic baseline check for Tier 1 and Tier 2 vendors where continuous signals are supplemented by structured self-assessment.
The key shift is that the questionnaire is no longer the primary risk signal. It is a supplement to continuous monitoring, event-driven assessment, and dependency-aware concentration analysis. For CISOs presenting their TPRM programme to supervisory authorities, the question is not "how many questionnaires did you send?" but "how do you detect relevant changes in your vendor ecosystem between assessment cycles?"
That question is the dividing line between legacy TPRM and the model that NIS2 and DORA demand. If your answer involves spreadsheets, annual email reminders, and hope, you are on the wrong side of it.
Key Takeaways
- Annual vendor questionnaires fail structurally under NIS2 and DORA because they produce unverified, point-in-time, individually-scoped assessments in an environment that demands continuous, verified, ecosystem-aware third-party risk management.
- NIS2 Article 21(2)(d) requires supply chain security measures including concentration risk awareness; DORA Chapter V mandates a continuously maintained register, concentration risk assessment, and exit strategy readiness — these are operational obligations, not annual exercises.
- Modern TPRM operates on four pillars: dynamic risk tiering (not all vendors warrant the same monitoring intensity), event-driven assessment (triggered by vendor incidents, ownership changes, certification changes, and sub-processor changes), concentration risk analysis (mapping transitive dependencies across your vendor portfolio), and operational integration with incident response.
- Questionnaires are not eliminated — they are repositioned as one data source among many, appropriate for low-risk vendors and as periodic baseline checks, but no longer the primary risk signal for critical and important vendors.
- The dividing question for your TPRM programme is "how do you detect relevant changes in your vendor ecosystem between assessment cycles?" — if the honest answer involves spreadsheets and hope, the programme is not NIS2/DORA-ready.