Organisations should use a structured questionnaire and checklist that covers security controls, data handling, and supplier assurance before a third party is approved. The goal is to make review repeatable, comparable, and evidence-based, rather than relying on informal trust. A good assessment process should help teams identify missing controls, clarify accountability, and decide whether the vendor can meet baseline security expectations.
How to Structure a Third-Party Assessment That Finds Real Gaps
A useful assessment starts by turning vendor review into a repeatable control test, not a conversation. The questionnaire should be organised around the risks that matter before onboarding, such as access, data handling, secure development, operational resilience, and incident response, so reviewers can compare suppliers consistently and spot missing evidence early.
Structure the review so each control area asks for a concrete answer, a named owner, and proof that can be checked. That means separating policy statements from operational practice, and treating “we have a process” as incomplete until the supplier can show how it is run, measured, and revised when something fails. For vendor security questionnaires, this approach aligns closely with the kinds of assurance questions captured in SOC 2 Trust Services Criteria (AICPA) and the cloud control mapping structure in CSA Cloud Controls Matrix.
A strong assessment also distinguishes between baseline questions and follow-up checks. Baseline questions establish whether the supplier has the minimum controls, while follow-up requests validate specifics such as how access is approved, how secrets are protected, how logs are retained, and how offboarding is handled when the relationship ends. The point is to uncover mismatches between claimed maturity and actual control operation before the contract is signed.
What a Good Assessment Should Force the Supplier to Prove
The most productive questionnaires ask for evidence that is hard to fake and easy to compare. That usually means control descriptions, recent policy extracts, sample reports, architecture diagrams where relevant, and named exceptions. It also means asking who owns each control, because unclear accountability is often the reason a vendor sounds compliant while leaving gaps unresolved.
Reviewers should make sure the assessment covers the full path from data intake to deletion. If a supplier cannot explain what data it receives, where that data is stored, who can access it, how long it is retained, and how it is destroyed or returned, the assessment is not really testing security posture, it is testing assumptions. Where the vendor uses shared services or subcontractors, the questionnaire should also surface those dependencies so third-party risk is not hidden behind a single assurance statement.
One practical signal to watch is whether the supplier can answer the same question consistently across security, legal, procurement, and operations. Inconsistent answers often reveal that the control exists on paper but not in practice. That is especially important in onboarding, because this is the point where there is still leverage to correct the issue, request compensating controls, or walk away before a weak supplier is embedded in production workflows.
Risk and Threat Considerations
Third-party assessments fail when they reward polished responses instead of verifiable controls. The main risk is not just an incomplete questionnaire, but onboarding a supplier whose access, data handling, or offboarding process creates exposure that is hard to unwind later. Supplier assurance is only useful if it exposes those weak points before integration begins.
Failure mechanism: The vendor presents policy-level answers, but the organisation does not ask for evidence, exception handling, or ownership. That lets hidden gaps in access governance, retention, subcontractor control, or incident handling survive the review and move into live production use.
Impact: The organisation may approve a supplier that can access sensitive data or systems without adequate oversight, creating avoidable breach, compliance, and recovery risk. If the relationship later fails, the same weak structure can also slow containment, revocation, and offboarding.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack surface, NIST CSF 2.0, CIS Controls v8 and NIST SP 800-63 set the technical controls, and DORA define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.RM — Risk Management Strategy | Third-party onboarding is a governance and risk decision that needs repeatable supplier risk criteria. |
| Recommendation — Define supplier risk thresholds and approve vendors only when baseline controls and evidence meet them. | ||
| CIS Controls v8 | 15 — Service Provider Management | This topic is directly about assessing and managing third-party security expectations before approval. |
| Recommendation — Assess providers against documented security requirements and retain evidence of control verification. | ||
| NIST SP 800-63 | IAL — Identity Assurance Level | Onboarding checks often depend on assurance that access approvals and identities are properly verified. |
| Recommendation — Verify identity and approval assurance before granting supplier access to sensitive environments. | ||
| OWASP Non-Human Identity Top 10 | NHI-01 — Secrets and Credential Exposure | Third-party reviews should uncover whether supplier credentials, tokens, or keys are exposed or weakly managed. |
| NHI-05 — Excessive Permissions and Privilege Creep | Vendor onboarding often fails when the supplier is granted broader access than the service requires. | |
| NHI-07 — Lifecycle and Offboarding Gaps | Onboarding assessments must confirm the supplier can revoke access and close accounts cleanly when the relationship ends. | |
| Recommendation — Check how the supplier stores, rotates, and restricts secrets before any integration is approved. Scope vendor access to the minimum privileges needed and require justification for every exception. Validate offboarding and revocation processes before a third party is allowed into production. | ||
| DORA | ICT-THIRD-PARTY — ICT Third-Party Risk Management | Where regulated entities use vendors, assessment structure must support contractual and operational third-party oversight. |
| Recommendation — Document and test third-party controls, dependencies, and exit expectations before approval. | ||
Practitioner Guidance
What to verify: Require proof that maps directly to the control being claimed, not just a verbal assurance or generic policy excerpt. If the supplier cannot show recent evidence of how the control operates, treat that as a gap rather than a documentation issue.
Decision rule: If a supplier cannot clearly answer who owns access, data handling, logging, retention, and offboarding, the assessment is not ready to approve onboarding. At that point the right move is to pause, narrow scope, or require compensating controls before contract finalisation.
Practitioner takeaway: The best third-party assessments are designed to force evidence, ownership, and follow-through, because that is what separates a usable vendor assurance process from a paper exercise.
Related resources from NHI Mgmt Group
- How should security teams use third-party risk questionnaires in vendor onboarding?
- How should security teams build a third-party risk programme that actually reduces identity risk?
- How should security teams structure third-party risk questionnaires by use case?
- How should security teams implement third-party risk assessments in high-growth vendor ecosystems?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 19, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
