What breaks when third-party risk management stays questionnaire-based?

Questionnaire-only programmes miss real-time drift, hidden sub-processors, and changes in access scope. They also encourage false confidence because the evidence is old by the time it is reviewed. The failure is not just inefficiency; it is that the control model assumes vendors remain stable long enough for periodic assurance to work.

Why This Matters for Security Teams

Questionnaire-only third-party risk programmes fail because they measure intent, not current control reality. A supplier can answer honestly in January and still be materially different in March after a new integration, a subcontractor change, or a permission expansion. That is especially risky for environments where non-human identities, API keys, and service accounts carry production access. NHI governance has to be lifecycle-based, not point-in-time, which is why NHI Lifecycle Management Guide and the Top 10 NHI Issues both emphasise continuous visibility over periodic assurance. The same logic appears in NIST Cybersecurity Framework 2.0, where governance and monitoring are expected to operate together rather than as separate phases.

The operational failure is simple: a questionnaire can tell a buyer what the vendor believed at the time of completion, but it cannot reveal whether secrets were copied into a CI pipeline, whether an agentic workflow widened access, or whether a downstream processor now holds the data. In practice, many security teams encounter broken vendor assurances only after credentials are already active in the wrong place, rather than through intentional monitoring.

How It Works in Practice

Modern third-party risk management needs evidence that changes with the supplier’s environment. That means tying questionnaires to control telemetry: secret-scanning alerts, cloud posture checks, SaaS audit logs, identity inventories, and contractual obligations to disclose material changes. For NHI-heavy suppliers, the review should explicitly ask how they issue, rotate, and revoke machine credentials, because secrets are often the fastest-moving part of the risk picture. NHIMG’s 52 NHI Breaches Report shows why this matters: compromised NHIs are a recurring breach path, not a rare edge case.

Current guidance suggests moving from annual attestations to a layered model:

• Use questionnaires to establish baseline claims and contractual commitments.
• Validate those claims with continuous signals from logs, scanners, and attestations of control operation.
• Track non-human identity lifecycle events, including issuance, rotation, revocation, and orphaned access.
• Require notification when sub-processors, toolchains, or privilege scope change.

That approach aligns with the OWASP Non-Human Identity Top 10, which treats machine identity exposure as a first-class risk, not a paperwork issue. It also fits the broader governance direction in Ultimate Guide to NHIs — Regulatory and Audit Perspectives, where audit evidence must reflect actual operational control, not static declarations. These controls tend to break down when the vendor environment changes faster than the review cycle because the evidence trail always lags the privilege trail.

Common Variations and Edge Cases

Tighter third-party oversight often increases operational overhead, requiring organisations to balance assurance depth against vendor friction and internal review capacity. That tradeoff becomes sharper in cloud-native, SaaS, and AI-enabled supply chains where access is ephemeral, integrations are numerous, and sub-processors change frequently. There is no universal standard for how often a supplier should produce machine-identity evidence, but best practice is evolving toward event-driven review instead of calendar-driven questionnaires.

Some environments do still need questionnaires for procurement, regulatory filing, or baseline due diligence, especially for low-risk vendors with no system access. Even there, the questionnaire should be treated as the starting point, not the control. If the supplier uses agents, automation, or delegated workflows, the buyer should ask how identity is bound to workload, how secrets are short-lived, and how intent changes are authorised at runtime. That is the practical lesson from LiteLLM PyPI package breach and Reviewdog GitHub Action supply chain attack: trust breaks when hidden automation can mint, move, or expose secrets faster than the assessment process can react.

Related resources from NHI Mgmt Group

• Third-party risk management
• Who should own third-party access risk in a banking GRC programme?
• What breaks when risk management is separated from identity governance?
• Why do third-party integrations increase identity risk so quickly?