When third-party risk management depends only on questionnaires and periodic assessments, organisations can believe a vendor is safe even after its posture has changed. That creates a gap between assessment and reality, which is where breaches emerge. Sensitive data and internal systems remain exposed longer, and teams may discover the problem only after damage has already occurred.
Why questionnaires and periodic reviews create a false sense of vendor safety
Questionnaires and scheduled assessments are point-in-time signals, not continuous assurance. They tell you what the vendor could prove, document, or describe on the day of review, but they do not keep pace with changes in access paths, sub-processors, secrets, infrastructure, or incident response maturity. When procurement treats them as the whole control, risk becomes a reporting exercise instead of an operating reality.
A vendor can pass a questionnaire while still drifting into unsafe territory between review cycles. New integrations can be added, permissions can expand, tokens can be reused, and exposed data paths can appear after the assessment window closes. The core problem is not that questionnaires are useless, but that they cannot observe the live state that determines whether a third party is actually safe.
Where the assessment gap turns into exposure
The dangerous gap is time. If your only check is periodic, the organisation may continue trusting a supplier long after the supplier’s control environment has changed. That lag is especially visible in NCSC guidance, which consistently treats operational monitoring and board-level oversight as separate from one-off assurance activities.
In practice, this means sensitive data, privileged integrations, and downstream systems can remain reachable even though the last review looked clean. A questionnaire may confirm a policy exists, but it rarely proves the policy is enforced, that exceptions are visible, or that access was revoked when circumstances changed. That is why breaches often appear first as an abuse of trust, then as a discovery problem.
For cloud and software-dependent vendors, the risk is amplified by supply-chain change. A third party may rely on external services, connected apps, or delegated access that were not present during the last assessment. The vendor profile on paper can stay static while the attack surface changes underneath it.
What a stronger third-party risk model has to verify
Questionnaires should be used as an intake tool, not as the control itself. The better question is whether the vendor can demonstrate current access boundaries, current data handling, and current dependency changes. If a supplier handles sensitive information or holds privileged paths into your environment, then governance must cover live permissions, revocation speed, and the ability to detect drift between reviews.
Where third-party access is involved, DORA is a useful external reference because it explicitly treats ICT third-party risk as an operational resilience issue, not just a procurement checklist. Similarly, the SOC 2 Trust Services Criteria are often used to assess whether a service provider can actually sustain security and confidentiality controls over time.
From a practitioner standpoint, the key change is moving from “did they answer the questionnaire?” to “can we confirm the control is still active today?” That usually means validating inventory, reviewing active integrations, checking termination and revocation paths, and confirming that ownership for each third-party relationship is clear enough for rapid escalation.
Risk and Threat Considerations
Periodic review models fail when attackers exploit the interval between assessments. A vendor may become compromised, overprivileged, or misconfigured after the last attestation, while the customer continues to trust the earlier result. That creates a classic stale-assurance problem: the organisation is defending against the last known state, not the present one.
Failure mechanism: Trust is granted from an outdated snapshot, then preserved even as vendor access, secrets, or dependencies change. Attackers only need the gap between “last review looked fine” and “current environment is no longer fine.”
Impact: Sensitive data, APIs, and internal systems can remain exposed longer, and the organisation may detect the problem only after unauthorised access, data theft, or operational disruption has already occurred.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the technical controls, while DORA, SOC 2 (AICPA) and ISO/IEC 27001:2022 define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| DORA | GV.SC-01 — Third-Party Risk Management | Third-party resilience depends on ongoing oversight, not point-in-time questionnaires. |
| Recommendation — Map critical vendors to ongoing ICT risk oversight and verify current control evidence between review cycles. | ||
| SOC 2 (AICPA) | CC6.1 — Logical and Physical Access Controls | Vendor trust hinges on current access control effectiveness, not static attestations. |
| Recommendation — Confirm vendors can prove access restrictions, revocation, and monitoring are operating today. | ||
| NIST CSF 2.0 | GV.SC-05 — Third-Party Risk Management | The question is about managing supplier risk over time and detecting drift in external dependencies. |
| Recommendation — Continuously monitor supplier changes and tie reassessment to material changes in access or exposure. | ||
| ISO/IEC 27001:2022 | A.5.19 — Information security in supplier relationships | Supplier relationships require security obligations and review beyond a one-time questionnaire. |
| Recommendation — Define supplier security requirements, then verify compliance with ongoing monitoring and review. | ||
| NIST SP 800-53 Rev 5 | SA-9 — External System Services | Third-party services need explicit controls because trust and exposure extend beyond your boundary. |
| Recommendation — Set security expectations for external services and validate them with recurring evidence and access checks. | ||
Practitioner Guidance
What to verify: Verify that every material third party has a current owner, a defined access path, and a revocation trigger. If you cannot show who can disable access quickly, the assessment process is not giving you actionable control.
Decision rule: If a vendor can touch production data or production systems, treat questionnaire results as baseline evidence only and require a second control signal, such as access review, telemetry, or contractual revocation authority. If no second signal exists, the relationship is higher risk by design.
Common mistake: Teams often confuse “last attestable state” with “current security state.” That shortcut is most dangerous where integrations, credentials, and sub-processors can change faster than the review cycle.
Practitioner takeaway: Third-party risk management is only credible when it can detect and act on change, not merely document it; the control objective is to shorten the time between vendor drift and your ability to see, challenge, and revoke it.
Related resources from NHI Mgmt Group
- Why do traditional vendor questionnaires fall short for modern third-party risk management?
- How should organisations expand third-party risk management beyond periodic vendor reviews in complex ecosystems?
- How should organisations mature a third-party risk management program beyond annual questionnaires?
- What happens when compliance and cybersecurity teams stay siloed during third-party risk management?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 28, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
