Vendor Security Assessment Template

Most vendor security reviews either send every supplier the same 300-question spreadsheet or approve on the strength of a logo on a trust page, and neither tells you whether the vendor can be trusted with your data and your credentials. This template gives you a complete, tiered vendor security assessment: scoping and tiering, pre-assessment intake, question sets by domain, the evidence to request, a scoring rubric, a risk rating and decision, remediation tracking and reassessment cadence. It gives particular weight to the API keys, OAuth tokens and service accounts a vendor holds for you, which recent supply chain breaches show are often the real exposure. It is aligned to NIST CSF 2.0 GV.SC, NIST SP 800-161 Rev. 1 and ISO/IEC 27001:2022 Annex A 5.19 to 5.22, and works alongside the SIG or CAIQ.

How to use this template

• Replace text in square brackets, such as [Organisation], [Third-party risk team] and [X days], with your own terms and values.
• Tier first (section 2), then send only the question sets and evidence the tier requires.
• Copy sections 5 to 9 into your GRC tool or spreadsheet with columns for response, evidence reference, score, assessor comment and follow-up. Keep the question IDs (GOV-1, NHI-3 and so on) so results stay comparable across vendors and years.
• If a vendor has a completed SIG or CAIQ, accept it and ask only what it does not cover, usually sections 5.3 (vendor-held credentials) and 5.8 (AI).
• Score on evidence, not on the answer. A "yes" with no evidence scores no higher than 1 for tier 1 and tier 2 vendors.

1. Purpose

This procedure sets out how [Organisation] assesses the information security of vendors before contract, at renewal and after material change, so that risks are understood, recorded, accepted or treated by the right person, and reflected in the contract. It implements the [Supplier Security Policy] and supports NIST CSF 2.0 GV.SC-06 ("Planning and due diligence are performed to reduce risks before entering into formal supplier or other third-party relationships") and GV.SC-07 (supplier risks are assessed and "monitored over the course of the relationship").

2. Scope and tiering

This procedure applies to every vendor, contractor, SaaS or cloud provider, managed service provider and AI service that will access [Organisation] systems or data, hold credentials for them, or provide a service [Organisation] depends on. The business owner completes the intake (section 4); [Third-party risk team] assigns the tier from the highest applicable criterion.

Tiering implements NIST CSF 2.0 GV.SC-04 ("Suppliers are known and prioritized by criticality"). Tier on what the vendor touches, not on contract value.

3. Roles and responsibilities

• Business owner: completes the intake, owns the relationship, and accepts residual risk within delegated limits.
• [Third-party risk team]: assigns the tier, runs the assessment, scores and recommends a decision.
• [Security architecture / IAM]: reviews integrations, OAuth scopes, API keys and network access for tier 1 and 2 vendors.
• [Data Protection Officer]: reviews personal data processing, sub-processors and transfers.
• [CISO / risk committee]: approves high residual risk and all exceptions for tier 1 vendors.

4. Pre-assessment information

The business owner provides the following before the vendor is contacted:

1. Vendor legal name, parent company, country of incorporation and service locations.
2. Service description and the business process it supports.
3. Data types and classification, approximate record volumes and whether personal or special category data is involved.
4. Access required: user accounts, VPN or network access, API keys, OAuth grants (with requested scopes), service accounts or agents installed in [Organisation] environments.
5. Credentials the vendor will hold for [Organisation] systems, and credentials [Organisation] will hold for the vendor's.
6. Whether the service uses AI models, and whether [Organisation] data is sent to them.
7. Impact if the service is unavailable for [4 hours / 1 day / 1 week], and the time to replace the vendor.

5. Question sets by domain

5.1 Governance and assurance (GOV)

1. GOV-1: Do you maintain an information security policy approved by senior management and reviewed at least annually? Provide it or its table of contents.
2. GOV-2: Who is accountable for information security, and to whom do they report?
3. GOV-3: Which independent assurance do you hold for the in-scope service: ISO/IEC 27001 certification, SOC 2 Type 2, CSA STAR, other? Is the in-scope service inside the certified or attested boundary?

5.2 Data protection (DATA)

1. DATA-1: Where is [Organisation] data stored and processed, including backups and support access locations?
2. DATA-2: Is [Organisation] data encrypted in transit (minimum TLS version) and at rest? Who manages the keys, and is customer-managed key support available?
3. DATA-3: Is [Organisation] data logically segregated from other customers' data? How is this tested?
4. DATA-4: How is data returned and deleted at contract end, within what period, and is deletion certified?

5.3 Access control, including vendor-held credentials and NHIs (NHI)

1. NHI-1: Is multi-factor authentication enforced for all staff access to production and to systems holding [Organisation] data? Is it phishing-resistant for administrators?
2. NHI-2: How many of your staff can access [Organisation] data or tenant, under what approval, and is that access logged and reviewed?
3. NHI-3: Where are API keys, OAuth refresh tokens, passwords or certificates that [Organisation] issues to you stored? Are they encrypted, held in a secrets manager or HSM, and isolated per customer?
4. NHI-4: Does your integration request the minimum OAuth scopes and API permissions needed? List them and explain each.
5. NHI-5: Do you support short-lived credentials or workload identity federation instead of long-lived static keys? How often are long-lived credentials rotated?
6. NHI-6: How are service accounts, API keys and secrets in your own production environment inventoried, owned and rotated, and how do you prevent secrets in source code repositories?
7. NHI-7: Can [Organisation] see and revoke the credentials and grants you hold, and will you notify us within [24 hours] if any are suspected compromised?

5.4 Vulnerability management (VULN)

1. VULN-1: What are your remediation timescales for critical and high vulnerabilities on internet-facing systems, and what is current performance?
2. VULN-2: When was the last independent penetration test of the in-scope service, who performed it, and are all critical and high findings closed?

5.5 Incident response and notification (IR)

1. IR-1: Do you have a tested incident response plan? When was it last exercised?
2. IR-2: Within how many hours of confirming an incident affecting [Organisation] data, credentials or service will you notify us, and through which contact? (Target: [24 to 72 hours]; personal data breaches without undue delay.)
3. IR-3: Will you share indicators of compromise, affected credentials and a root cause report?
4. IR-4: Have you had a security incident affecting customer data in the last [36 months]? Summarise it and the actions taken.

5.6 Business continuity and disaster recovery (BCDR)

1. BCDR-1: What are the recovery time and recovery point objectives for the in-scope service, and when were they last tested?
2. BCDR-2: Are backups immutable or otherwise protected from deletion by a compromised administrator account?

5.7 Sub-processors and fourth parties (SUB)

1. SUB-1: List sub-processors and hosting providers that will process [Organisation] data, with locations.
2. SUB-2: How do you assess their security, and how will you notify [Organisation] of changes and allow objection? (GDPR Article 28(2) requires prior specific or general written authorisation and, for general authorisation, the opportunity to object.)
3. SUB-3: Do any sub-processors hold credentials for [Organisation] systems?

5.8 AI use (AI)

1. AI-1: Does the service use AI models? Which providers, and are they listed as sub-processors?
2. AI-2: Is [Organisation] data, including prompts and outputs, used to train or improve models? Is this off by default and contractually excluded?
3. AI-3: Do AI agents in the service take actions in [Organisation] systems? Under what identity, with what permissions, and with what human approval for high-impact actions?
4. AI-4: How do you test for prompt injection and data leakage, and do you hold ISO/IEC 42001 certification or follow the NIST AI RMF?

5.9 Secure development (DEV)

1. DEV-1: Do you follow a documented secure development life cycle with threat modelling, code review and security testing?
2. DEV-2: Do you scan dependencies and code for vulnerabilities and secrets before release, and can you provide an SBOM on request?
3. DEV-3: How are build and deployment pipelines protected, and are their credentials short-lived and scoped?

6. Evidence requested

7. Scoring rubric

Average the scores within each domain, then weight the domains. Suggested weights for tier 1: NHI 20%, DATA 15%, IR 15%, GOV 10%, VULN 10%, BCDR 10%, SUB 10%, AI 5%, DEV 5%; raise AI to 15% where the service processes [Organisation] data with AI models. Mark these as knock-out questions: any score of 0 or 1 on them sets the control rating to Weak regardless of the total: NHI-1, NHI-3, NHI-7, IR-2, DATA-2 and AI-2.

8. Risk rating and decision

Decision options, recorded with the approver's name and date:

• Approve: low or medium residual risk, approved by the business owner.
• Approve with conditions: remediation items with dates are written into the contract or an addendum before signature.
• Approve with risk acceptance: high residual risk accepted by [CISO / risk committee] for no more than [12 months], with compensating controls on [Organisation]'s side (for example narrower OAuth scopes, IP allow-listing, extra monitoring).
• Reject: very high residual risk, or a knock-out failure the vendor will not fix.

9. Remediation tracking

Each finding is logged with: finding ID, question ID, description, risk rating, agreed action, vendor owner, [Organisation] owner, due date, evidence of closure and status (Open, In progress, Closed, Risk accepted). Open tier 1 items are reviewed [monthly]. Overdue knock-out items escalate to [CISO] and, after [30 days], trigger a fresh decision.

10. Reassessment and ongoing monitoring

• Scheduled: as set by tier in section 2, using a delta questionnaire that asks what changed since the last assessment.
• Triggered: a security incident at the vendor, a change of ownership, a new sub-processor or hosting region, new data types or broader access requested, new AI features that process [Organisation] data, or expiry of a certificate or attestation.
• Continuous: track certificate and report expiry, review the vendor's OAuth grants and integration logs, and watch public breach reporting.
• Exit: at contract end, revoke every credential, OAuth grant, account and network path, and obtain confirmation of data return or deletion (NIST CSF 2.0 GV.SC-10).

11. Framework mapping

12. Source references

1. NIST: SP 800-161 Rev. 1, Cybersecurity Supply Chain Risk Management Practices for Systems and Organizations
2. NIST: The NIST Cybersecurity Framework (CSF) 2.0
3. CSF Tools: NIST SP 800-53 Rev. 5 SR-6 Supplier Assessments and Reviews
4. NCSC: Supply chain security guidance
5. Cloud Security Alliance: Cloud Controls Matrix and CAIQ
6. Cloud Security Alliance: STAR Level 1 Security Questionnaire (CAIQ v4)
7. GDPR: Article 28, Processor
8. NIST: AI Risk Management Framework core
9. Mitratech: SIG 2025, key updates and considerations

Implementation guidance

NIST SP 800-161 Rev. 1 places supply chain risk work at three levels: enterprise, mission and business process, and operational. This template sits at the operational level; the tiering in section 2 is where enterprise risk appetite shows through.

1. Build the inventory first. List current vendors from accounts payable, SSO application lists, OAuth grants in your SaaS tenants and cloud marketplace subscriptions. Many critical integrations never went through procurement.
2. Tier the existing population. Run the intake for current vendors and assess tier 1 vendors first, starting with those holding admin or write credentials to your systems.
3. Pilot on five vendors across tiers, then adjust weights and knock-out questions.
4. Wire it into procurement. No purchase order or SSO onboarding for a tier 1 or 2 vendor without a recorded decision.
5. Write findings into contracts. Notification times (IR-2, NHI-7), sub-processor change notice, audit rights and exit deletion belong in the agreement, not just the questionnaire.
6. Run reassessment and monitoring from the tracker, and report coverage to the [risk committee] quarterly.

Choosing a questionnaire: the Shared Assessments SIG is a licensed, broad third-party risk questionnaire; according to Mitratech's summary of the 2025 release, SIG Core has 627 questions across 21 risk categories and SIG Lite has 128 for less critical vendors, with mappings that include NIST CSF 2.0, DORA and NIS2. The CSA Cloud Controls Matrix has 197 control objectives in 17 domains, and its CAIQ yes/no questions are now combined with it in version 4.1, which suits cloud providers. Use one of these for breadth with tier 1 vendors and this template's NHI and AI sets for depth. Small organisations can rely on SOC 2 or ISO/IEC 27001 evidence plus sections 5.3 and 5.5 for most vendors; large ones should automate intake and evidence expiry in a GRC or TPRM platform.

Metrics: percentage of tier 1 and 2 vendors with a current assessment; median days from intake to decision; open findings past due date; percentage of vendor integrations whose OAuth scopes and API keys were reviewed in the last [12 months]; vendors with access but no recorded assessment (target zero).

Common failure patterns: accepting a SOC 2 report without checking that the in-scope service is covered or reading the exceptions; asking about the vendor's controls but never about the credentials it holds for you, the exposure behind the Salesloft Drift breach, where stolen OAuth tokens from one integration opened many customers' Salesforce data; ignoring how a vendor protects customer tokens in its own estate, as in the Sisense breach; assessing once at onboarding and never again; and leaving grants and keys active after the contract ends. See the Security Questionnaires Guide, the Third-Party Access Guide and the SaaS and OAuth App Governance Guide. For evidence, see the SOC 2 Guide and the ISO 27001 Certification Guide.

This template is provided for guidance and must be adapted to your organisation. It is not legal advice. Related NHI Mgmt Group resources: Security Questionnaires Guide · Third-Party Access Guide · SaaS and OAuth App Governance Guide · API Key Management Guide