Security Questionnaires Are Not Enough: Rethinking Vendor Risk in the DORA and NIS2 Era

Inherent in nearly every third-party risk program is a common element: the vendor security and privacy questionnaire. Before a contract is signed, and sometimes just after, technology and service vendors are routinely asked to explain how they protect data, secure systems, manage incidents, train employees, use subprocessors, and comply with applicable laws. Theoretically, this makes sense. Organizations need a way to understand the risks introduced by the vendors they rely on. Procurement, security, privacy, and legal teams need documentation. Regulated organizations need evidence that they performed due diligence.

But in reality, many of those questionnaires fall short.

Some ask the wrong questions. Some ask the same question ten different ways. Some force yes/no answers where context is essential. Some are only designed for certain types of vendors and do not reflect how other technology or service vendors actually operate. Others focus so heavily on specific certifications or static data descriptions that they miss the controls, safeguards, and risk signals that matter most.

This creates a problem for both sides. Vendors may be forced into oversimplified answers that do not accurately describe their services, making them appear either more secure or more risky than they actually are. Customers may walk away with a false sense of assurance, believing they have assessed risk when they have mostly collected checkboxes, or they may flag a vendor as risky simply because the questionnaire did not allow for the context needed to explain the answer.

As DORA, NIS2, GDPR, and other key regulations increase supply chain scrutiny, having vendors merely check a box is no longer good enough.

The regulatory stakes are higher now

Third-party risk is not new, but the expectations around how organizations assess and manage it have changed.

دورا, which applies from January 17, 2025, places significant emphasis on ICT third-party risk management for financial entities. It requires organizations to maintain oversight of ICT third-party service providers, manage contractual arrangements, and keep a register of information covering ICT third-party relationships.

NIS2 also places greater focus on supply chain security. Organizations in scope are expected to assess and manage cybersecurity risks across supplier and service provider relationships, including the security practices of those providers.

Regardless of the regulation at play, the requirement is clear: organizations need to understand the risks created by their vendors and suppliers, not just collect paperwork at onboarding.

That does not mean questionnaires are useless. In fact, the opposite is true. Questionnaires can still be incredibly valuable when they are well designed, risk-based, and supported by evidence. But if a questionnaire is too rigid, too generic, or too focused on the wrong things, it can slow procurement and frustrate vendors without improving risk management.

Worse, it can cause organizations to miss issues that matter under DORA, NIS2, GDPR, or other regulatory frameworks, creating gaps in due diligence that may increase the risk of non-compliance, regulatory scrutiny, and penalties.

When the questionnaire does not fit the vendor

Many questionnaires appear to be built around a generic technology vendor model. In that model, a vendor collects defined categories of data from users, stores them in known systems, and processes them according to predictable workflows. For some vendors, that assumption may work. For others, it can quickly break down.

Take data processing, for example. A software vendor may process data differently from a SaaS provider. A cloud-based platform may create different risks than a standard business application. A cybersecurity service may not receive a fixed data set from the customer at all, but instead discover data dynamically through threat intelligence, breach monitoring, attack surface monitoring, or data breach detection.

In those cases, the vendor may not be able to pre-enumerate every category of personal data it could encounter. The data depends on what is discovered, where it is found, and how the service operates. The privacy question is still fully relevant to the questionnaire. It just needs to be asked in a different way.

Instead of only asking: What personal data do you process?

A more useful version might be: What categories of data may your service encounter, and what safeguards apply when potentially sensitive or personal data is discovered?

That shift matters. The goal is not to force a vendor into a static answer that may be incomplete or misleading. The goal is to understand how the vendor identifies, protects, limits access to, retains, deletes, and reports on data once it is encountered.

The problem with checkbox assurance

Another common issue is the reliance on yes/no questions that produce very little insight.

A questionnaire may ask: Do you encrypt data at rest? The vendor answers yes.

That answer may be accurate, but it does not tell the customer much. It does not explain what encryption mechanisms are used, how keys are managed, whether backups and logs are covered, who can access the data, or how controls are tested.

A checkbox demonstrates compliance with the question. It does not necessarily demonstrate the strength of the control.

This becomes especially risky when questionnaires are used as the primary evidence of vendor due diligence. If a supplier can check “yes” without explaining how a control works, the customer may not have enough information to distinguish between a mature control environment and a superficial one.

Every question does not need a long narrative response. But when it comes to critical controls, especially those tied to sensitive data, critical services, or regulated obligations, vendors should have room to explain how the control is implemented and provide supporting evidence where appropriate.

When “not applicable” is the most accurate answer

In some cases, questionnaire issues arise when the questions do not match the service being purchased. A questionnaire may assume the vendor will access the customer’s production systems, deploy software inside the customer’s environment, host customer data directly, or process customer-provided datasets. For some services, that may be true. For others, it is not.

A cloud provider, a hosted SaaS platform, a downloadable software vendor, a managed service provider, and a cybersecurity monitoring service may all create different risk profiles. Some may process customer data directly. Some may only receive limited account information. Some may operate entirely outside the customer’s environment. Others may provide visibility into external exposures without ever connecting to the customer’s internal systems.

That distinction matters.

A vendor may answer “no” to a question not because a control is missing, but because the scenario does not apply. A “no” answer can look like a risk when the better answer is “not applicable.” But many questionnaires do not offer a “not applicable” option or provide enough room to explain why. This can trigger unnecessary follow-up, delay procurement, or cause reviewers to misunderstand the service. The reverse is also true. If reviewers do not understand what the service actually does, they may overlook risks that should have been assessed or flag risks where none actually exists.

This is why vendor due diligence should not happen in a vacuum. Privacy, security, procurement, and legal teams need at least a basic understanding of the service being purchased. They also need input from the business owner who selected the vendor. Without that context, even a well-intentioned questionnaire can produce the wrong result.

Asking the same thing ten different ways does not improve risk assessment

Many questionnaires are also repetitive. A vendor may receive separate questions about encryption at rest, encryption in transit, encryption for backups, encryption for logs, encryption for temporary files, and encryption for archived data.

Sometimes that level of detail is necessary. But often, the answers are all derived from the same architecture, policy, or control framework.

The same issue appears in privacy questionnaires. One question may ask whether employees receive annual privacy training. The next may ask whether employees who handle data subject requests receive specific training on privacy laws and response requirements. Depending on the service and the vendor’s role, those may be related but not equally relevant.

Repetition does not automatically produce better assurance. It often produces longer questionnaires, inconsistent answers, and slower reviews.

A better approach is to ask broader control-based questions and allow vendors to provide explanation where needed. For example:

Describe your privacy and security training program, including whether role-specific training is provided for employees with specialized privacy or security responsibilities.

That question gives the reviewer more useful information than a string of disconnected yes/no prompts.

Questionnaires should not ignore the documents that already govern the relationship

Another common problem is that questionnaires sometimes ask questions already addressed in the DPA, contract, security addendum, or other binding documentation. For example, a questionnaire may ask: How do you ensure transparency toward data subjects under Articles 13 and 14 of the GDPR?

For many vendors, the answer may depend on the role they play, the nature of the service, and the commitments already set out in the DPA. A public privacy policy may explain website data practices, while the DPA governs processing performed as part of the service. Treating those documents as interchangeable can create confusion. This is not just annoying from the vendor side. It can also create consistency problems for the customer.

A DPA or contract is typically more enforceable than a questionnaire response. If the binding document already addresses subprocessors, data subject requests, international transfers, security measures, audit rights, or incident notification, the questionnaire should either reference that document or ask for clarification only where needed.

Good due diligence should connect the questionnaire to the contractual commitments, not create a parallel set of informal answers that may be less precise or less enforceable.

Certification bias can distort the risk picture

Certifications can be useful. SOC 2, ISO 27001, and other independent assessments can provide meaningful assurance and reduce the burden of reviewing every control from scratch. But certifications should not become a substitute for risk analysis.

Some scoring models give full credit for one certification, partial credit for another, and no credit if the preferred certification is not available. That can create a distorted view of vendor risk. A vendor may have ISO 27001, an internal audit program, penetration testing, independent security reviews, strong contractual commitments, and mature operational controls, yet still score poorly because it does not have the exact certification the questionnaire expected.

The better approach is to evaluate the underlying controls and accept equivalent evidence where appropriate. A certification can support the assessment. It should not be the entire assessment.

Better questionnaires ask better questions

Improving vendor questionnaires does not mean they need to be longer or more complicated. A better questionnaire should help the customer understand the actual risk presented by the vendor and the service being purchased.

That starts with clarity. Vendors should understand what kind of response is expected, whether supporting documentation should be provided, who should be involved in completing the questionnaire, and how to handle questions that do not apply to the service.

In practice, better questionnaires should:

• ask questions that match the service being purchased;
• allow vendors to explain when a yes/no answer is misleading;
• distinguish between “no” and “not applicable”;
• evaluate safeguards and control implementation, not just static data categories;
• accept equivalent certifications or evidence where appropriate;
• connect questionnaire answers to DPAs, contracts, and security documentation;
• reduce repetitive questions that do not add meaningful insight;
• provide clear instructions about who should complete the questionnaire and what supporting documents are expected.

If the questions are better, the answers are better. And if the answers are better, organizations are in a stronger position to understand and manage third-party risk.

Questionnaires are only one part of the picture

Even a well-designed questionnaire has limits. It is still a point-in-time representation of what a vendor says about its controls, processes, and practices. But third-party risk changes over time.

A vendor may be secure at onboarding and exposed six months later. Credentials may leak. A cloud asset may be misconfigured. A supplier may introduce risk. A vulnerability may become actively exploited. A subcontractor relationship may change. An incident may occur that does not show up in a questionnaire until the next review cycle.

This is where organizations need to complement questionnaire-based due diligence with external visibility and ongoing monitoring.

CybelAngel can support that effort by helping organizations identify external exposures, leaked credentials, vulnerable assets, and third-party risk signals that may affect suppliers, vendors, and other parts of the extended ecosystem. It is not a replacement for vendor due diligence, contracts, DPAs, certifications, or regulatory analysis. But it can provide additional evidence that helps organizations understand whether the risk picture has changed after onboarding.

That matters for organizations subject to DORA, NIS2, and other frameworks where controlling and monitoring third-party risk is key.

From paperwork to risk understanding

Vendor questionnaires are not going away, nor should they. They serve an important purpose in third-party risk management. But they need to evolve.

A questionnaire that asks the wrong questions, forces oversimplified answers, ignores context, or treats certifications as the whole story can create friction without creating assurance. It may satisfy a process requirement while still failing to identify the risks that matter.

In the DORA and NIS2 era, organizations need more than completed forms. They need meaningful answers, supporting evidence, and ongoing visibility into the vendors and suppliers they rely on.

Because when the questionnaire does not fit the vendor, the risk assessment may not fit the risk.

Move beyond point-in-time vendor assessments

A questionnaire captures what a vendor said at onboarding. It cannot tell you what is exposed today. CybelAngel gives you continuous external visibility into leaked credentials, unprotected assets, and third-party risk signals across your extended supply chain — evidence that your risk picture still matches the answers on file.