How is this template different from SIG, CAIQ, and a SOC 2 report?

SIG (Standardised Information Gathering) is a comprehensive question bank maintained by Shared Assessments that covers about 1,200 questions across 19 risk domains; SIG Lite is the shorter version. CAIQ (Consensus Assessments Initiative Questionnaire) is the Cloud Security Alliance question bank aligned to the Cloud Controls Matrix and built for cloud service providers. A SOC 2 report is the auditor-attested evidence the vendor produces against the AICPA Trust Services Criteria. This template is the BUYER-side assessment workbook that consumes those vendor artefacts and produces a defensible scoring decision. It is shorter than SIG because it concentrates on the questions a buyer needs to make a sourcing decision, broader than CAIQ because it covers on-premises and hybrid vendors as well as cloud-only suppliers, and is the workbook the SOC 2 report is read INTO rather than a replacement for the SOC 2 report. Mature programmes use this template alongside SIG or CAIQ for high-tier vendors (Tier 1 critical) and use this template alone for lower tiers (Tier 2 important, Tier 3 standard).

How does vendor tiering work in this template?

Vendor tiering is the rule that decides the depth of the assessment, the cadence of reassessment, and the contractual security clauses. A defensible tiering rule uses four signals. Data sensitivity (does the vendor process, store, or transmit personal data, regulated data, financial data, intellectual property, or production credentials). Operational criticality (does the loss of the vendor stop the customer-facing service, the engineering pipeline, the security operations function, or the back-office finance flow). Integration depth (does the vendor have inbound network access, outbound webhook access to production, identity federation, API keys with write scope, or read-only API access). Regulatory exposure (is the vendor in scope of PCI DSS, HIPAA, SOC 2, ISO 27001, NIS2, DORA, FedRAMP, or sector-specific regimes by virtue of the data they process). The four signals roll up to Tier 1 critical (full deep-dive assessment, annual reassessment, dedicated security clauses, contractual right to audit), Tier 2 important (mid-depth assessment, biennial reassessment, standard security clauses), Tier 3 standard (lightweight assessment, triennial reassessment, baseline security clauses). The template carries the tiering rule in Section 4 so the assessor records the tier before answering the question bank.

What residual risk scoring rubric does the template use?

The template uses a five-band residual risk rubric (critical, high, medium, low, accepted) computed from inherent risk minus compensating controls. Inherent risk is the unmitigated risk if the vendor had no security controls (a function of data sensitivity, operational criticality, integration depth, regulatory exposure). Compensating controls are the security controls the vendor demonstrates in their answers and evidence (governance, technical, operational). Residual risk is what is left after the compensating controls reduce inherent risk. The rubric uses bands rather than numeric scores so the read is interpretable at the audit committee level rather than buried under decimal-point arithmetic. A critical residual rating requires CISO and executive sponsor approval to proceed with onboarding. A high residual rating requires CISO approval. A medium rating requires head-of-security approval. A low rating proceeds at programme-owner discretion. An accepted rating documents the residual risk on the risk register with an expiry date and a renewal trigger.

When does this template get used in the vendor lifecycle?

The template is used at five points in the vendor lifecycle. Onboarding (before signing the contract, the assessor runs the template against the candidate vendor and the contract terms are conditional on a passing residual risk rating). Renewal (at every contract renewal, the assessor refreshes the template against the current state of the vendor with delta tracking against the previous cycle). Scope change (when the vendor relationship expands to add a new product, a new data category, or a new integration, the template is rerun on the expanded scope). Incident (when the vendor suffers a security incident, the template is rerun on the relevant sections with the incident learnings recorded). Decommissioning (when the relationship terminates, the template documents the data return and destruction confirmation, the access revocation evidence, and the closure sign-off). The recurring reassessment cadence per tier ensures vendors do not drift between formal events.

How does this template interact with vendor questionnaire response workflows?

This template is the BUYER-side instrument. The vendor receives the questionnaire and answers it through their own response workflow. The companion artefact on the vendor side is the security questionnaire response process documented in the vendor questionnaire response workflow use case on SecPortal. The two artefacts meet at the evidence interface: the buyer asks the question, the vendor returns the answer plus the evidence pointer (policy version, SOC 2 report excerpt, ISO 27001 certificate, activity log export, scanner output), and the buyer scores the answer against the rubric. A mature programme operates both sides of the interface on the same platform so a buyer-side assessment a company runs on a third-party vendor and the buyer-side assessment a customer runs on the company use the same structured evidence record rather than two disconnected spreadsheets. The template is the buyer-side instrument; the response workflow is the vendor-side discipline.

How often should the template be reviewed and updated?

The defensible cadence is annual minimum review with material-change-triggered revision. Annual review tests whether the question bank still reflects the current control catalogue (an ISO 27001 revision, a NIST 800-53 revision, a new privacy regime, a new sector rule), whether the tiering rule still maps to the company risk appetite, whether the residual scoring rubric still produces interpretable bands, and whether the evidence reference list still aligns to the artefacts vendors typically produce. Material change triggers an off-cycle revision: a new regulation in scope (DORA, NIS2, EU AI Act, US state privacy laws), a new data category the company starts processing, a new business model that changes the integration patterns with vendors, a new acquisition that adds an inherited vendor portfolio, a vendor incident that surfaces a question the template should have asked, or a customer audit that requires the company to demonstrate a stricter vendor discipline. The revision cadence is logged in the document control history with date, summary, approver, and rationale.

What is fourth-party risk and how does the template surface it?

Fourth-party risk is the risk introduced by the subprocessors and subcontractors of a vendor. The vendor is the third party; their suppliers are the fourth parties from the buyer perspective. The template surfaces fourth-party risk in three places. Section 14 (supply chain and fourth-party risk) asks the vendor to disclose their critical subprocessors, the data each subprocessor handles, the geographic location, and the governance the vendor exercises over the subprocessor (contractual security clauses, periodic assessment, audit rights). Section 8 (data handling) asks the vendor to disclose where the data is processed, stored, and backed up at the fourth-party level. Section 16 (compliance and certifications) asks the vendor whether the fourth parties are themselves in scope of relevant compliance frameworks. The buyer reads the disclosed fourth-party portfolio against their own risk appetite and decides whether further assessment of named fourth parties is warranted. NIS2 Article 21 and DORA Articles 28 to 30 both expect fourth-party risk to be assessed for critical ICT providers.

How does SecPortal carry the assessment record?

SecPortal carries the vendor security risk assessment on a vendor engagement record rather than as a standalone spreadsheet. The assessor opens an engagement against the vendor, files the completed template as a document on the engagement, records each scored question as a finding with the residual rating, attaches the evidence the vendor returned, and tracks the remediation items on the same engagement. The activity log captures the timestamped chain of state changes by user across the assessment, the scoring, the approval, the remediation tracking, and the closure or renewal. Team management with role-based access control gates who can approve residual ratings at each band (member, head of security, CISO, executive sponsor). Compliance tracking maps the assessment findings to ISO 27001, SOC 2, PCI DSS, NIST, NIS2, and DORA controls so the assessment evidences specific framework requirements. Document management retains the version history of the template, the completed assessment, and the supporting evidence the vendor returned. AI report generation produces the assessment summary the audit committee reads. The platform does not auto-distribute the questionnaire to the vendor (no email-out automation, no vendor portal for vendor self-service), does not integrate with third-party GRC platforms (no OneTrust, ProcessUnity, Archer, ServiceNow GRC, MetricStream, or LogicGate integration), does not perform automated vendor security ratings (no BitSight, SecurityScorecard, UpGuard ingestion), and does not produce contractual templates (the template is the assessment workbook, not the master services agreement or the data processing agreement).

What goes wrong when a vendor security risk assessment is missing or thin?

Six failure patterns recur. First, vendors are onboarded with no security review, then surface as the entry point of an incident months later, and the breach evidence cannot identify which approver authorised the bypass because there was no documented authorisation. Second, the assessment is run once at onboarding and never refreshed, so a vendor that has changed dramatically (acquired by a private equity firm, lost their lead security engineer, expanded into a new data category) is read at audit time as the same risk profile they had three years earlier. Third, the assessment lives in a spreadsheet detached from the engagement record, so renewal cycles start from a blank document and prior decisions are reinvented. Fourth, the residual rating is computed inconsistently across assessors, so two assessments of the same vendor by two analysts produce different decisions and the audit reads the inconsistency as evidence of an unscored process. Fifth, fourth-party risk is ignored, so a single subprocessor outage takes down multiple Tier 1 vendors and the buyer discovers the concentration after the fact. Sixth, the approval ladder collapses to one role, so every residual rating routes to the head of security regardless of severity and the leader becomes the bottleneck while critical ratings sit unsigned. Each failure has a structural fix the template above is designed to enforce.

Free Tool

Vendor Security Risk Assessment Template
twenty sections for tiering, controls, evidence, residual scoring, and a defensible sign-off

A free, copy-ready vendor security risk assessment template for internal security, AppSec, vulnerability management, GRC, cloud security, and security operations teams running a third-party supplier review. Twenty structured sections covering cover and document control, engagement scope and context, vendor tiering decision, governance and security organisation, data handling and data protection, network and infrastructure security, application and product security, identity and access management, vulnerability and patch management, logging and security operations, incident response and breach notification, business continuity and operational resilience, product-level controls the buyer can configure, supply chain and fourth-party risk, privacy and data protection, compliance and certifications, contractual security clauses and exit, evidence pack and verification, findings ledger with residual risk scoring, and decision, sign-off, and reassessment trigger. Aligned with ISO/IEC 27001 Annex A 5.19 to A 5.22, NIST SP 800-53 SA-12 and SR controls, NIST SP 800-161, SOC 2 CC9.2, PCI DSS Requirement 12.8, HIPAA 164.308(b), NIS2 Article 21, and DORA Articles 28 to 30.

Get Started Free

No credit card required. Free plan available forever.

Twenty sections that turn a vendor security review into a defensible decision record

A vendor security risk assessment template is the structured questionnaire and scoring workbook the security or GRC function uses to assess a third-party supplier before onboarding, at renewal, and on a recurring cadence during the relationship. It carries the company section, the engagement context, the tiering rule, the question bank across governance, data handling, infrastructure, product security, identity and access, vulnerability management, logging, incident response, business continuity, product controls, supply chain, privacy, compliance, contractual clauses, evidence pack, findings ledger, residual scoring, and the named decision and sign-off. The twenty sections below cover the durable shape of the artefact across ISO/IEC 27001 Annex A 5.19 to A 5.22, NIST SP 800-53 SA-12 and SR controls, NIST SP 800-161, SOC 2 CC9.2, PCI DSS Requirement 12.8, HIPAA 164.308(b), NIS2 Article 21 supply-chain requirement, and DORA Articles 28 to 30 ICT third-party risk management. Copy the section that fits your stage and paste the rest as you go.

The template is the buyer-side instrument. For the vendor-side discipline of responding to inbound questionnaires, pair this with the vendor security questionnaire response workflow use case. For the enterprise narrative on the programme this template sits inside, see the third-party vendor risk assessment enterprise guide. For the SLA discipline the contractual section references, see the vulnerability remediation SLA policy template. For the exception register that absorbs accepted residual ratings, see the security exception register template. For the underlying risk register entries each accepted residual produces, see the risk register template. For the procurement-side artefacts that pair with the contractual section, see the vulnerability management platform RFP template. For the in-house business continuity programme the Section 12 continuity check reads against on the buyer side, see the business continuity and disaster recovery plan template that carries the BIA, the RTO and RPO commitments per tier, the recovery strategy per tier, the backup immutability rule, the exercise cadence, and the framework crosswalk the buyer reads against when evaluating vendor recovery commitments.

Copy the full assessment (all twenty sections) as one block.

1. Cover and document control

Open the assessment with the version, the effective date, the assessor, the vendor name, and the engagement context. The cover is the artefact the audit reads first to confirm the assessment is a controlled record rather than a working draft. ISO/IEC 27001 Clause 7.5 expects documented information to carry version, owner, and review cadence; the vendor assessment is no exception.

Assessment title: Vendor Security Risk Assessment
Template version: {{TEMPLATE_VERSION}}
Effective date of this assessment: {{ASSESSMENT_DATE}}
Next scheduled reassessment date: {{NEXT_REASSESSMENT_DATE}}

Vendor under assessment:
- Legal entity name: {{VENDOR_LEGAL_NAME}}
- Trading name: {{VENDOR_TRADING_NAME}}
- Headquarters jurisdiction: {{VENDOR_HQ_JURISDICTION}}
- Primary processing region(s): {{VENDOR_PROCESSING_REGIONS}}
- Public registry identifier: {{VENDOR_REGISTRY_ID}}

Vendor primary security contact:
- Name: {{VENDOR_SECURITY_CONTACT_NAME}}
- Role: {{VENDOR_SECURITY_CONTACT_ROLE}}
- Email: {{VENDOR_SECURITY_CONTACT_EMAIL}}

Buyer-side assessor (the person running this assessment):
- Name: {{ASSESSOR_NAME}}
- Role: {{ASSESSOR_ROLE}}
- Function: {{ASSESSOR_FUNCTION}}

Buyer-side relationship owner (the person carrying the vendor relationship):
- Name: {{RELATIONSHIP_OWNER_NAME}}
- Role: {{RELATIONSHIP_OWNER_ROLE}}
- Business unit: {{RELATIONSHIP_OWNER_BU}}

Assessment trigger (one of):
- Onboarding (pre-contract).
- Annual renewal.
- Scope change (new product, new data category, new integration).
- Incident-triggered reassessment.
- Decommissioning.
- Other: {{OTHER_TRIGGER}}.

Parent policy referenced from this assessment:
- Third-Party Vendor Risk Management Policy, version {{TPRM_POLICY_VERSION}}.

Sibling artefacts that consume the output of this assessment:
- Security Exception Register (for accepted residual ratings).
- Risk Register (for tracked residual risk).
- Master Services Agreement and Data Processing Addendum (for contractual security clauses).
- Incident Response Vendor Notification List (for incident escalation routing).

Frameworks the assessment evidences:
ISO/IEC 27001 Annex A 5.19 to A 5.22 (supplier relationships), NIST SP 800-53 SA-12 and SR controls (supply chain), NIST SP 800-161 (cybersecurity supply chain risk management), SOC 2 CC9.2 (vendor management), PCI DSS Requirement 12.8 (service provider management), HIPAA 45 CFR 164.308(b) and 164.314(a) (business associates), NIS2 Article 21 (supply-chain risk), DORA Articles 28 to 30 (ICT third-party risk management), internal vendor risk policy.

Document control history (maintained inline or as an appendix):
- Version, effective date, summary of change, approver, rationale.
- Previous version archived per Audit Evidence Retention Policy.

2. Engagement scope and context

Define the relationship before scoring the controls. The scope statement names the products and services in the engagement, the data the vendor processes, the integration patterns, and the operational dependency. Two assessments of the same vendor for different services produce different residual ratings; the scope statement is what makes that explicit.

Engagement scope:
- Products or services in scope: {{IN_SCOPE_PRODUCTS_SERVICES}}
- Products or services explicitly out of scope: {{OUT_OF_SCOPE}}
- Anticipated contract value: {{CONTRACT_VALUE_BAND}}
- Anticipated contract term: {{CONTRACT_TERM}}
- Service start date: {{SERVICE_START_DATE}}

Data the vendor will process, store, or transmit (mark all that apply):
- Production customer personal data (PII).
- Production customer financial data.
- Production customer health data (PHI).
- Production customer credentials, secrets, or keys.
- Production customer business data not covered above.
- Employee personal data.
- Employee health data.
- Intellectual property (source code, designs, models).
- Production credentials, API keys, or secrets owned by the buyer.
- Production telemetry, logs, or activity data.
- Pseudonymised or aggregated data only.
- No customer or buyer data (operational tooling only).

Regulatory exposure (mark all in scope):
- PCI DSS scope (cardholder data).
- HIPAA scope (PHI in a covered entity or business associate relationship).
- GDPR or UK GDPR scope (EEA or UK data subjects).
- US state privacy law scope (CCPA, CPRA, VCDPA, others).
- SOC 2 scope (customer trust commitments referenced in attestation).
- ISO 27001 scope (customer commitment to ISO 27001 assurance).
- NIS2 scope (essential or important entity status).
- DORA scope (financial entity ICT services).
- FedRAMP scope (US federal data).
- Other sector or geography rule: {{OTHER_REGULATORY_SCOPE}}.

Integration depth (mark all that apply):
- Inbound network access to buyer systems.
- Outbound webhook or callback access to vendor systems.
- Identity federation (SAML or OIDC) with buyer identity provider.
- API keys with write scope on buyer systems.
- API keys with read scope on buyer systems.
- Browser-based access only.
- Shared physical site.
- No technical integration (paper, email, or telephone only).

Operational dependency (free text):
- What stops if the vendor is unavailable for 4 hours, 24 hours, 7 days, 30 days.
- Documented failover, alternative supplier, or business continuity workaround.

Buyer-side stakeholders consulted on this assessment:
- Engineering or product team: {{ENGINEERING_STAKEHOLDER}}
- Cloud or platform team (if integration): {{PLATFORM_STAKEHOLDER}}
- AppSec or product security team (if product integration): {{APPSEC_STAKEHOLDER}}
- GRC and compliance: {{GRC_STAKEHOLDER}}
- Privacy officer (if personal data): {{PRIVACY_STAKEHOLDER}}
- Legal and procurement: {{LEGAL_STAKEHOLDER}}
- Business unit sponsor: {{BUSINESS_SPONSOR}}

3. Vendor tiering decision

Tier the vendor before answering the question bank. The tier decides the depth of the assessment, the cadence of reassessment, and the contractual security clauses the procurement team negotiates. Tiering is a deliberate decision recorded against named signals, not a guess.

Tiering signals (record the answer per signal):
1. Data sensitivity rating (from Section 2):
   - Critical (production customer credentials, regulated data at scale, IP).
   - High (production customer personal or financial data, employee personal data).
   - Medium (pseudonymised or aggregated production data, internal operational data).
   - Low (no customer or buyer data, operational tooling only).

2. Operational criticality rating (from Section 2):
   - Critical (loss stops the customer-facing service).
   - High (loss stops the engineering pipeline, security operations function, or major back-office).
   - Medium (loss degrades a non-critical workflow).
   - Low (loss is recoverable inside one working day without customer impact).

3. Integration depth rating (from Section 2):
   - Critical (write API access, identity federation, or inbound network access to production).
   - High (read API access to production, outbound webhook to production).
   - Medium (browser access only, identity federation with read-only scope).
   - Low (no technical integration).

4. Regulatory exposure rating (from Section 2):
   - Critical (PCI DSS, HIPAA, FedRAMP, or DORA scope by virtue of data or services).
   - High (GDPR with regulated data categories, NIS2 scope).
   - Medium (SOC 2 customer commitment, ISO 27001 customer commitment, US state privacy laws).
   - Low (none of the above).

Tier assignment rule:
- Tier 1 (critical): any one signal at Critical, or two signals at High.
- Tier 2 (important): one signal at High, others at Medium or Low.
- Tier 3 (standard): all signals at Medium or Low.

Assigned tier for this vendor: {{ASSIGNED_TIER}}
Tiering rationale (named signal levels and rule application): {{TIERING_RATIONALE}}

Tier-driven assessment depth:
- Tier 1 (critical): full template with named subject-matter input across cloud, AppSec, GRC, privacy. Full evidence pack required (SOC 2 Type II or ISO 27001 certificate, penetration test summary, vulnerability disclosure policy, incident response policy, business continuity plan). Annual reassessment.
- Tier 2 (important): full template completed by the assessor with selective subject-matter input. Standard evidence pack (SOC 2 Type II or ISO 27001 certificate, or signed self-attestation against the template). Biennial reassessment unless triggered earlier.
- Tier 3 (standard): lightweight subset (Sections 5, 9, 10, 11, 13, 14, 17). Self-attestation acceptable. Triennial reassessment unless triggered earlier.

Tier-driven contract template:
- Tier 1: full security and data processing schedule with right to audit, named subcontractor list, incident notification window, breach indemnity.
- Tier 2: standard security and data processing schedule with notification commitments.
- Tier 3: baseline security clauses in the standard MSA.

Tier review:
- Reviewed at every reassessment and at any material change (Section 2 scope expansion, vendor acquisition, vendor incident, new regulatory regime in scope).

4. Governance and security organisation

Read the security function as an organisational structure before reading individual controls. A vendor with a published policy framework, a named accountable security leader, and a documented review cadence is operating a programme; a vendor without those signals is asserting controls without the structure to operate them.

Q4.1 Does the vendor publish an information security policy framework?
- Required answer: policy framework documented, reviewed annually, signed by a named executive, made available on request.
- Evidence reference: policy document version, last review date, approver signature.

Q4.2 Who carries accountability for information security at executive level?
- Required answer: named role (CISO, head of security, equivalent) with documented authority and reporting line to executive or board.
- Evidence reference: org chart, executive sponsor confirmation, board reporting cadence.

Q4.3 What is the security function headcount, and how is it organised?
- Required answer: declared headcount (FTE), declared organisational shape (centralised, embedded, hybrid), named functional leads for AppSec, security operations, GRC, vulnerability management, incident response.

Q4.4 Does the vendor maintain a published security governance cadence?
- Required answer: quarterly security review at executive level, annual security review at board or audit committee level, documented attendees, documented decisions.
- Evidence reference: governance review minutes (redacted), cadence reference in security policy.

Q4.5 Does the vendor publish a security training programme?
- Required answer: annual security training mandatory for all staff, phishing simulation cadence, completion tracking, named owner.
- Evidence reference: training programme documentation, completion rate metric, phishing programme summary.

Q4.6 Does the vendor publish a code of conduct, background-screening policy, and acceptable use policy?
- Required answer: yes for each, applied to new hires and contractors, reviewed annually.
- Evidence reference: policy documents, screening provider reference.

Q4.7 Does the vendor disclose ownership, beneficial ownership, and significant control changes in the last 24 months?
- Required answer: disclosed; documented evidence of ultimate beneficial ownership; named significant ownership changes (acquisition, private equity ownership, public listing, restructure).
- Evidence reference: corporate registry citations, ownership disclosure document.

Scoring per question:
- Met: evidence confirms the required answer.
- Partially met: documented control exists with declared gap (gap recorded as a finding in Section 19).
- Not met: control absent or evidence not produced (finding recorded as residual risk).
- Not applicable: justified inapplicability documented (relationship is out of scope of the control).

5. Data handling and data protection

Data handling is where the buyer reads the vendor against their own data classification policy. The questions in this section have to surface what the vendor does with the data at every stage of the lifecycle, where the data lives, and what happens when the relationship ends.

Q5.1 What classes of buyer data will the vendor process, store, or transmit?
- Required answer: enumerated against the data list in Section 2.

Q5.2 In which jurisdictions will the data be processed, stored, and backed up?
- Required answer: jurisdictions named at country level for processing, storage, and backup independently. Cross-border transfer mechanisms named where applicable (Standard Contractual Clauses, UK IDTA, Binding Corporate Rules, EU-US Data Privacy Framework).
- Evidence reference: data flow diagram, processing register entry.

Q5.3 How is the data classified inside the vendor systems?
- Required answer: documented classification scheme aligned to the buyer classification level (confidential, restricted, internal, public or equivalent). Stated handling rule per class.

Q5.4 How is the data segregated from other vendor customers?
- Required answer: logical segregation (per-tenant database isolation, per-tenant key separation, row-level access controls) or physical segregation (per-customer infrastructure).
- Evidence reference: architecture diagram, multi-tenancy documentation.

Q5.5 What encryption controls apply at rest and in transit?
- Required answer: encryption in transit using current TLS (1.2 minimum, 1.3 preferred), encryption at rest using AES-256 or equivalent, documented key management with rotation cadence, documented customer-managed key option if applicable.
- Evidence reference: cryptography policy, KMS documentation, attestation in SOC 2 report.

Q5.6 What data retention rules apply to buyer data?
- Required answer: stated retention period per data class, stated deletion timeline at relationship end, stated retention extension rule under legal hold.

Q5.7 What backup, replication, and disaster recovery posture applies to buyer data?
- Required answer: backup cadence, retention of backups, geographic separation of backup storage, tested recovery time objective (RTO) and recovery point objective (RPO).
- Evidence reference: BCP/DR test report, last test date.

Q5.8 What happens to buyer data at relationship termination?
- Required answer: data return mechanism (export format, export window), data destruction mechanism (cryptographic erasure, drive sanitisation, deletion confirmation), retention exception under legal obligation, documented timeline (commonly 30 to 90 days).
- Evidence reference: termination clause in MSA, data destruction certificate template.

Q5.9 Does the vendor publish a data protection impact assessment (DPIA) for high-risk processing?
- Required answer: DPIA template published; DPIAs completed for high-risk processing activities; DPIA review cadence documented.

Q5.10 Does the vendor support buyer-managed encryption keys (bring-your-own-key) for data classes that warrant it?
- Required answer: BYOK or HYOK option documented; supported key management systems named; key rotation and revocation procedure documented.

Scoring per question: Met, Partially met, Not met, Not applicable.

6. Network, infrastructure, and cloud security

Infrastructure security is where the buyer reads how the vendor protects the substrate the service runs on. The questions cover the network boundary, the host posture, the cloud posture, the hardening discipline, and the change-management cadence.

Q6.1 What is the production hosting model (cloud, on-premises, hybrid)?
- Required answer: hosting model named; named cloud providers and regions; named on-premises locations.

Q6.2 What network segmentation isolates production from corporate and from other environments?
- Required answer: documented segmentation (VPC, subnet, security group, firewall ruleset, micro-segmentation), documented zero-trust posture if applicable.

Q6.3 What edge controls protect the production perimeter?
- Required answer: WAF, DDoS protection, rate limiting, bot management, geo-blocking where relevant.

Q6.4 What host hardening baseline applies to production systems?
- Required answer: named baseline (CIS Benchmark, vendor baseline, internal baseline), baseline version, last review date.
- Evidence reference: baseline documentation, compliance report.

Q6.5 What endpoint security applies to corporate devices that access production?
- Required answer: full-disk encryption, EDR with central management, mobile device management, screen lock policy, removable-media restriction.

Q6.6 What cloud security posture is maintained for cloud-hosted production?
- Required answer: CSPM tooling deployed, named CSPM product, documented review cadence, drift remediation SLA.

Q6.7 What change-management discipline governs production changes?
- Required answer: documented change management process, named approver per change class, segregation of duties between change submitter and change approver, change audit trail.

Q6.8 What configuration drift detection is in place?
- Required answer: drift detection tooling named, review cadence documented, drift remediation SLA documented.

Q6.9 What container or workload security posture is maintained (if applicable)?
- Required answer: image scanning, runtime security, registry signing, named tooling.

Q6.10 What network observability is in place?
- Required answer: flow logging enabled in production, retention period documented, monitoring integration named.

Scoring per question: Met, Partially met, Not met, Not applicable.

7. Application and product security

Product security reads how the vendor builds the service the buyer is consuming. The questions cover the SSDLC, the security testing cadence, the third-party-library posture, and the secrets discipline.

Q7.1 What secure software development lifecycle (SSDLC) discipline applies to the production codebase?
- Required answer: documented SSDLC stages (design review, threat modelling, secure coding standards, code review, security testing, deployment gates).
- Evidence reference: SSDLC policy, threat model artefacts (redacted) for a representative system.

Q7.2 What static application security testing (SAST) is in place?
- Required answer: SAST tool named, integrated into the CI pipeline, severity threshold documented, breaking-build policy documented.

Q7.3 What software composition analysis (SCA) is in place?
- Required answer: SCA tool named, integrated into the CI pipeline, severity threshold documented, breaking-build policy documented, license posture managed.

Q7.4 What dynamic application security testing (DAST) is in place against production-like environments?
- Required answer: DAST cadence (per-release, weekly, monthly), tool named, severity threshold documented.

Q7.5 What manual penetration testing cadence applies?
- Required answer: annual third-party penetration test minimum, named provider rotation policy, severity threshold for retest, executive summary made available to buyers on request under NDA.
- Evidence reference: most recent penetration test executive summary or attestation letter.

Q7.6 What secret-scanning discipline is in place?
- Required answer: secret scanning in CI pipeline and on commit, leaked-credential rotation SLA, named tooling.

Q7.7 What bug bounty or vulnerability disclosure programme is published?
- Required answer: public VDP policy with safe-harbour language, contact endpoint, response SLA, scope statement. Bug bounty programme details if applicable.
- Evidence reference: published VDP URL, programme page URL.

Q7.8 How are third-party libraries kept current?
- Required answer: dependency upgrade cadence (monthly minimum), automated dependency PRs (Dependabot, Renovate, equivalent), SBOM generation per release.

Q7.9 How are API endpoints documented and protected?
- Required answer: documented API inventory, authentication required by default, rate limiting, abuse detection, deprecation policy.

Q7.10 What logging is captured at the application layer for security review?
- Required answer: authentication events, authorisation decisions, privileged action events, data access events, administrative changes, with retention documented.

Scoring per question: Met, Partially met, Not met, Not applicable.

8. Identity and access management

Identity and access read how the vendor controls who can touch buyer data, both inside the vendor organisation and at the buyer integration layer. Federation, MFA enforcement, privileged access controls, and joiner-mover-leaver discipline are the load-bearing answers.

Q8.1 What identity provider underpins workforce access to production?
- Required answer: SSO required for production access (Okta, Entra ID, Google Workspace, equivalent), MFA enforced on the IdP, conditional access rules documented.

Q8.2 What MFA enforcement applies to administrative and privileged access?
- Required answer: phishing-resistant MFA required for privileged accounts (FIDO2, smart card), TOTP minimum for all production access, SMS not accepted for production access.

Q8.3 What privileged access management discipline is in place?
- Required answer: PAM tool named, just-in-time elevation documented, session recording for privileged sessions, audit trail of privileged actions.

Q8.4 What joiner-mover-leaver discipline applies?
- Required answer: documented onboarding access provisioning, named approval per role, periodic access review cadence (quarterly minimum for production), revocation SLA at termination (named hours), documented automation between HRIS and IdP.

Q8.5 What service-account and machine-identity discipline applies?
- Required answer: named owner per service account, periodic review cadence, rotation policy, secrets vault (named) holding credentials, no shared interactive accounts.

Q8.6 What federation does the vendor support for buyer-side workforce access?
- Required answer: SAML 2.0 federation, OIDC federation, SCIM provisioning, system for cross-domain identity management documented.

Q8.7 What buyer-side admin role separation is supported?
- Required answer: role-based access control inside the vendor product with separation of administrative roles from end-user roles, audit log of role assignments.

Q8.8 What customer-managed authentication policies can the buyer enforce?
- Required answer: customer-configurable password policy, MFA enforcement, session timeout, IP allowlist, conditional-access rules.

Q8.9 What audit log is exposed to the buyer for identity events?
- Required answer: buyer-accessible audit log of authentication, authorisation, role changes, and privileged actions, with export to standard formats (CSV minimum, SIEM integration where applicable).

Q8.10 What anomaly detection runs on identity events?
- Required answer: identity-anomaly detection (impossible-travel, brute-force, privilege escalation) integrated with incident response, named tooling.

Scoring per question: Met, Partially met, Not met, Not applicable.

9. Vulnerability and patch management

Vulnerability management is where the buyer reads the discipline the vendor runs against the discoveries that surface on the production estate. SLA windows per severity, evidence of programme maturity, and the exception governance are the load-bearing answers.

Q9.1 What vulnerability management policy is published?
- Required answer: documented policy with severity-based remediation SLA, exception governance, named programme owner, review cadence.
- Evidence reference: policy version, last review date.

Q9.2 What vulnerability remediation SLA windows apply per severity?
- Required answer: documented windows (commonly Critical 7 to 14 days, High 30 days, Medium 90 days, Low 180 days), per-asset-tier modifier if applicable, stop-the-clock conditions documented.

Q9.3 What scanner coverage applies to the production estate?
- Required answer: authenticated scanning coverage percent, external scanning coverage percent, code scanning coverage percent, container image scanning coverage percent.

Q9.4 What CISA KEV (Known Exploited Vulnerabilities) catalogue posture applies?
- Required answer: documented response to KEV listings (commonly 21-day window for KEV-listed vulnerabilities applicable to the estate).

Q9.5 What is the vendor breach rate against the published SLA in the last 12 months?
- Required answer: declared breach rate per severity band; mean time to remediate per severity band.

Q9.6 What exception governance discipline applies?
- Required answer: exception register maintained, residual-rating approver ladder documented, expiry dates required, periodic exception review.

Q9.7 What patch management discipline applies to operating systems, container images, and third-party libraries?
- Required answer: patch cadence per platform, automated patching where applicable, named exclusions and justifications.

Q9.8 What process applies to zero-day vulnerabilities affecting the production estate?
- Required answer: named emergency response process, documented executive escalation, customer notification commitment.

Q9.9 What metrics does the vendor publish on vulnerability management?
- Required answer: open critical findings, mean time to remediate per severity band, SLA breach rate, exception count.

Q9.10 What evidence of programme maturity does the vendor produce?
- Required answer: SOC 2 CC7.1, ISO 27001 Annex A 8.8, or equivalent attestation in scope of the relationship; named maturity benchmark (NIST 800-40r4, internal model) if used.

Scoring per question: Met, Partially met, Not met, Not applicable.

10. Logging, monitoring, and security operations

Security operations read how the vendor detects and responds to suspicious activity. Log coverage, retention, the detection programme, and the alerting cadence are the load-bearing answers; absence of a 24-by-7 monitoring posture for a Tier 1 vendor is a structural finding.

Q10.1 What log sources are captured into the security monitoring platform?
- Required answer: authentication and authorisation logs, network flow logs, application audit logs, database audit logs, endpoint security logs, cloud control-plane logs, with retention documented.

Q10.2 What log retention applies?
- Required answer: hot retention period (commonly 90 days), cold retention period (commonly 12 to 18 months, longer for regulated data), with named tiered storage.

Q10.3 What SIEM or detection-and-response platform underpins security monitoring?
- Required answer: named platform, named operations team, documented coverage of MITRE ATT&CK technique tree at a stated coverage percent.

Q10.4 What detection engineering discipline operates?
- Required answer: detection-as-code repository, named coverage signal (rule count by technique), false-positive rate tracking, detection review cadence.

Q10.5 What threat intelligence is consumed?
- Required answer: named threat intelligence sources, frequency of ingestion, named team consuming the intel.

Q10.6 What 24-by-7 monitoring posture applies?
- Required answer: 24-by-7 SOC coverage required for Tier 1 critical vendors processing regulated data; business-hours coverage acceptable for Tier 3 standard.

Q10.7 What mean time to detect and mean time to respond does the vendor target?
- Required answer: documented targets (MTTD and MTTR by severity), measured performance over the trailing 12 months.

Q10.8 What threat-hunting cadence runs?
- Required answer: named cadence (weekly, monthly), named hypotheses framework, output captured.

Q10.9 What customer-facing audit log is exposed?
- Required answer: customer-facing audit log of administrative actions, data access events, and privileged actions, with named retention and named export option (CSV minimum, named SIEM integration where applicable).

Q10.10 What detection or anomaly signal does the vendor surface to the buyer when buyer data is involved?
- Required answer: named anomaly events (unusual access, mass export, privilege escalation, account takeover), named notification mechanism, named SLA.

Scoring per question: Met, Partially met, Not met, Not applicable.

11. Incident response and breach notification

Incident response and breach notification are where the relationship is read against contract and regulatory clocks. Notification windows, named contact, evidence preservation, and post-incident learning discipline are the load-bearing answers.

Q11.1 What incident response plan is published?
- Required answer: documented IR plan with declared severity classification, declared response stages (preparation, identification, containment, eradication, recovery, lessons learned), named roles, named cadence, last test date.

Q11.2 What incident severity classification governs the IR plan?
- Required answer: defined classification (commonly Critical, High, Medium, Low) with documented examples, named owner of the classification decision.

Q11.3 What incident exercise cadence runs?
- Required answer: tabletop exercise at least annually, full-scale simulation cadence documented, named participants, last exercise date and learnings recorded.
- Evidence reference: exercise summary report.

Q11.4 What customer notification commitment applies when buyer data is implicated?
- Required answer: notification SLA (commonly 24 to 72 hours from confirmed incident), named notification contact, named escalation path, contractual obligation documented in MSA or DPA.

Q11.5 What regulatory notification posture applies?
- Required answer: named regulatory regimes the vendor notifies (GDPR 72 hours, SEC cybersecurity rule, NIS2, DORA, sector-specific rules), named regulatory contact, documented process.

Q11.6 What evidence preservation discipline applies during an incident?
- Required answer: chain of custody, evidence-store integrity, legal-hold trigger, forensic-readiness posture.

Q11.7 What public communication discipline applies during a customer-impacting incident?
- Required answer: named communications lead, drafted holding statement, named approval path, named legal review.

Q11.8 What post-incident review discipline applies?
- Required answer: blameless postmortem after every Critical and High incident, documented contributing factor analysis, documented corrective action ledger, documented framework alignment statement.
- Evidence reference: redacted after-action report template.

Q11.9 What vendor disclosure cadence applies to incidents that did not implicate buyer data?
- Required answer: published security advisories for material incidents, transparency report cadence (annual minimum), named advisory channel (status page, RSS, dedicated mailing list).

Q11.10 What incident metrics does the vendor publish?
- Required answer: count and severity of material incidents in the last 12 months, mean time to detect and mean time to respond, customer-notifiable incidents in scope of the relationship.

Scoring per question: Met, Partially met, Not met, Not applicable.

12. Business continuity and operational resilience

Business continuity reads how the vendor sustains the service through disruption, and operational resilience reads how the relationship survives the kind of event that the buyer might be regulated against (DORA for financial entities, NIS2 for essential or important entities, sector-specific rules elsewhere).

Q12.1 What business continuity plan is published?
- Required answer: documented BCP scoped to the production service, declared disruption scenarios, declared RTO and RPO per scenario, named owner, last review date, last test date.
- Evidence reference: BCP test report.

Q12.2 What disaster recovery posture protects the production service?
- Required answer: multi-region or multi-zone architecture for Tier 1 services, documented failover trigger, last failover test date, evidence of meeting RTO and RPO targets in test.

Q12.3 What dependency mapping has the vendor published for their own critical inputs?
- Required answer: named critical infrastructure providers, named regional concentration, named single points of failure, named mitigation.

Q12.4 What operational resilience posture is in place for regulated services (DORA, NIS2)?
- Required answer: declared scope of operational resilience programme, severe-but-plausible scenario testing, board oversight, documented threshold scenarios.

Q12.5 What capacity planning discipline applies?
- Required answer: named capacity headroom, named scaling automation, documented surge plan.

Q12.6 What pandemic and remote-work continuity posture applies?
- Required answer: documented remote-work continuity, named secure-workstation requirement, named alternate-site posture.

Q12.7 What supplier-failure continuity posture applies?
- Required answer: alternative supplier list, documented migration runbooks, documented testing.

Q12.8 What incident-of-concentration risk has been identified?
- Required answer: named concentration risks (single cloud region, single SaaS dependency, single payments provider), documented mitigation.

Q12.9 What insurance posture applies?
- Required answer: declared cyber insurance coverage, declared E&O insurance coverage, named coverage limits.

Q12.10 What customer-facing transparency posture applies during a continuity event?
- Required answer: named status page, named subscription mechanism (RSS, email), named cadence of customer-facing updates during a sustained event.

Scoring per question: Met, Partially met, Not met, Not applicable.

13. Product-level security controls (customer-facing)

Product-level controls read the configurable surface the buyer can use to enforce their own posture inside the vendor product. The questions in this section have to surface what the buyer can enforce contractually and what they have to absorb as a residual.

Q13.1 What administrative controls can the buyer configure?
- Required answer: customer-configurable password policy, MFA enforcement, session timeout, IP allowlist, conditional-access rules.

Q13.2 What audit log is exposed to the buyer in product?
- Required answer: buyer-accessible audit log of administrative actions, data access events, role changes, privileged actions, with named retention and named export option (CSV minimum, named SIEM integration where applicable).

Q13.3 What data export option is available to the buyer?
- Required answer: customer-initiated export in named formats (CSV, JSON, named API endpoint), named retention window for export availability.

Q13.4 What data deletion option is available to the buyer?
- Required answer: customer-initiated deletion of records, named SLA between request and deletion, named confirmation mechanism.

Q13.5 What customer-managed encryption keys can the buyer enforce?
- Required answer: BYOK or HYOK option, named supported KMS, named key rotation and revocation procedure.

Q13.6 What data residency option can the buyer enforce?
- Required answer: customer-selectable processing region, customer-selectable backup region, transparent data flow documentation.

Q13.7 What customer-controlled retention can the buyer configure?
- Required answer: customer-configurable retention per data class within named windows.

Q13.8 What customer-controlled access scope can the buyer enforce?
- Required answer: customer-configurable role definitions, customer-configurable approval workflows where applicable, customer-controlled API key issuance.

Q13.9 What customer security advisory channel is published?
- Required answer: named advisory channel (status page, RSS, email subscription), named frequency, named scope.

Q13.10 What pre-production environment is exposed to the buyer for security testing?
- Required answer: named sandbox or staging access, documented permitted-testing scope, documented prohibited testing.

Scoring per question: Met, Partially met, Not met, Not applicable.

14. Supply chain and fourth-party risk

Fourth-party risk is the risk introduced by the suppliers of the supplier. The vendor is the third party from the buyer perspective; the vendor suppliers are the fourth parties. The questions in this section surface the disclosed dependencies, the governance the vendor exercises, and the concentration risk to escalate.

Q14.1 What critical subprocessors does the vendor disclose?
- Required answer: enumerated list of critical subprocessors with named function, named geographic processing location, named data categories processed.
- Evidence reference: published subprocessor list, last update date.

Q14.2 What governance discipline applies to subprocessor selection and oversight?
- Required answer: documented subprocessor onboarding process, named contractual security clauses, named periodic assessment, named termination triggers.

Q14.3 What customer notification commitment applies to new or replaced subprocessors?
- Required answer: notification window (commonly 30 days advance notice), customer objection mechanism, named replacement criteria.

Q14.4 What concentration risk has the vendor identified in their supply chain?
- Required answer: named concentration risks (single cloud region, single regional infrastructure provider, single payments provider, single identity provider), documented mitigation.

Q14.5 What posture applies to open-source dependencies?
- Required answer: SBOM generation per release, vulnerability tracking on the dependency graph, named tooling, named SLA for material upstream vulnerabilities.

Q14.6 What posture applies to firmware and hardware supply chain (if relevant)?
- Required answer: named hardware procurement source list, named firmware verification posture, named tampering detection posture.

Q14.7 What posture applies to AI and ML supply chain (if the vendor uses third-party models)?
- Required answer: named models in scope, named model providers, named data flow into and out of the model, named acceptable-use posture.

Q14.8 What posture applies to development pipeline supply chain?
- Required answer: SLSA level declared, named build provenance, named artefact signing, named CI/CD platform hardening.

Q14.9 What regional or jurisdictional concentration applies to subprocessors?
- Required answer: named jurisdictions, named transfer mechanism per jurisdiction, named sub-jurisdictional residency commitments.

Q14.10 What evidence of fourth-party assessment does the vendor produce on demand?
- Required answer: named due-diligence record (SOC 2 of subprocessor, ISO 27001 of subprocessor, internal assessment of subprocessor), named refresh cadence.

Scoring per question: Met, Partially met, Not met, Not applicable.

15. Privacy and data protection

Privacy and data protection reads how the vendor handles personal data against regulatory expectations and against the buyer privacy programme. Lawful basis, data subject rights, cross-border transfers, and DPA execution are the load-bearing answers.

Q15.1 Does the vendor sign a data processing agreement (DPA) as a processor or sub-processor?
- Required answer: standard DPA template available; named DPA terms (purpose limitation, processing instructions, confidentiality, security measures, sub-processor list, data subject rights assistance, breach notification, audit, return and destruction); commercial DPA agreed at contract signature.
- Evidence reference: DPA template, sample executed DPA (redacted).

Q15.2 What lawful basis does the vendor process buyer data under?
- Required answer: processor (acts on buyer instructions only), controller (named purpose and lawful basis), or joint controller (named arrangement under Article 26 GDPR).

Q15.3 What data subject rights does the vendor support?
- Required answer: named processes for access, rectification, erasure, restriction, portability, objection; named SLA per request type; named cost-recovery posture.

Q15.4 What cross-border transfer mechanism applies?
- Required answer: named mechanism per jurisdiction (Standard Contractual Clauses 2021, UK IDTA, Binding Corporate Rules, EU-US Data Privacy Framework), named transfer impact assessment posture, named supplementary measures.

Q15.5 What privacy impact assessment posture applies?
- Required answer: DPIA template published; DPIAs completed for high-risk processing; DPIA review cadence documented; named DPIA reviewer.

Q15.6 What privacy training is delivered to staff?
- Required answer: mandatory privacy training annual minimum, named completion rate, named role-specific training for staff with privileged access to personal data.

Q15.7 What posture applies to children data (if applicable)?
- Required answer: named scope assessment, named compliance posture against children-data regimes (COPPA, GDPR Article 8, sector-specific rules).

Q15.8 What posture applies to sensitive personal data (special categories)?
- Required answer: named scope assessment, named additional safeguards, named explicit consent or alternate lawful basis.

Q15.9 What customer-visible privacy notice does the vendor publish?
- Required answer: named privacy notice URL, last update date, named cookie posture, named tracking posture.

Q15.10 What posture applies to government access requests?
- Required answer: named transparency report, named government-access posture, named customer notification commitment.

Scoring per question: Met, Partially met, Not met, Not applicable.

16. Compliance, certifications, and audit

The certifications and audit posture section reads the third-party attestations the vendor produces to evidence the controls the rest of the assessment asks about. SOC 2, ISO 27001, PCI DSS, FedRAMP, and sector-specific attestations are the typical artefacts; the buyer reads them against the relationship scope.

Q16.1 What third-party attestations does the vendor hold?
- Required answer: enumerated list with effective date, expiry date, scope statement, auditor identity. Typical artefacts include SOC 2 Type II, ISO/IEC 27001, ISO/IEC 27017, ISO/IEC 27018, ISO/IEC 27701, PCI DSS attestation of compliance, FedRAMP authorisation, HITRUST CSF, CSA STAR, Cyber Essentials Plus, and sector-specific equivalents.
- Evidence reference: certificates and attestation reports made available under NDA.

Q16.2 Is the relationship scope inside the named attestation scope?
- Required answer: yes per attestation, with named system or service in scope; documented gap if the relationship scope is outside any attestation scope.

Q16.3 What is the customer-facing audit posture?
- Required answer: SOC 2 Type II provided annually, ISO 27001 certificate provided on request, customer audit right reserved for Tier 1 relationships under named conditions.

Q16.4 What right-to-audit clauses does the vendor accept?
- Required answer: customer-led audit on named conditions; pooled audit on industry-standard terms; auditor-led audit using named external auditor; documented declined scenarios.

Q16.5 What posture applies to sector-specific or geographic regulations?
- Required answer: named regulations in scope of the vendor service, named compliance posture, named registration or authorisation, named regulator contact for the vendor.

Q16.6 What posture applies to AI and ML regulation (EU AI Act, sector rules)?
- Required answer: named applicability assessment, named risk classification, named transparency posture, named governance.

Q16.7 What posture applies to sanctions, export-control, and trade-compliance?
- Required answer: named sanctions-screening process, named restricted-customer posture, named export-control posture, named documented compliance officer.

Q16.8 What posture applies to anti-bribery and anti-corruption?
- Required answer: named policy, named training, named conflict-of-interest discipline.

Q16.9 What posture applies to modern slavery and human rights?
- Required answer: named statement (where regulated), named supply-chain due diligence, named whistleblower channel.

Q16.10 What evidence does the vendor provide on request to support a buyer audit?
- Required answer: SOC 2 Type II report, ISO 27001 Statement of Applicability, recent penetration test summary or attestation letter, recent vulnerability management metrics, last business continuity test report, organisational chart, security policy framework, vendor-side risk register summary (redacted).

Scoring per question: Met, Partially met, Not met, Not applicable.

17. Contractual security clauses and exit

The contractual section turns the controls into commitments. The buyer reads the contract clauses the procurement and legal teams will negotiate, the named SLA terms, the named breach indemnity, and the named exit and data-return rules. Tier 1 vendors require dedicated security schedules; Tier 2 require named clauses in the standard MSA; Tier 3 use baseline clauses.

C17.1 Security schedule scope:
- Tier 1: dedicated security and data processing schedule, scoped to the named service.
- Tier 2: named security clauses in the standard MSA plus DPA where personal data is in scope.
- Tier 3: baseline security clauses in the standard MSA.

C17.2 Audit and assurance right:
- Tier 1: named audit right with reasonable advance notice and reasonable scope.
- Tier 2: pooled-audit right under SOC 2 plus right to request additional evidence on reasonable terms.
- Tier 3: reliance on SOC 2 Type II or ISO 27001 attestation; no separate audit right.

C17.3 Subprocessor change notification:
- Notification window: 30 days advance notice for material new or replaced subprocessors.
- Customer objection mechanism: named grounds for objection, named replacement procedure.

C17.4 Incident notification:
- Named SLA: commonly 24 to 72 hours from confirmed incident; named contact; named content of notification.
- Contractual obligation to share lessons-learned summary at named cadence.

C17.5 Data residency and processing:
- Named processing region with no transfer outside named geography without buyer consent.
- Named subprocessor list with named geographic location per subprocessor.

C17.6 Confidentiality and information handling:
- Named confidentiality terms, named permitted purposes, named exceptions, named term and survival.

C17.7 Indemnity and liability:
- Named breach indemnity (commonly capped at named multiple of fees or named monetary cap).
- Named regulatory fine pass-through posture.

C17.8 Insurance:
- Named cyber liability minimum.
- Named E&O minimum.
- Named additional insured posture where applicable.

C17.9 Service level commitment:
- Named availability target, named credits, named exclusions, named root-cause-analysis commitment.

C17.10 Exit and data return:
- Named export format and window at termination (commonly 30 to 90 days customer-initiated export).
- Named destruction commitment with named confirmation mechanism (data destruction certificate).
- Named transition cooperation commitment with named hours allocated.
- Named retention exceptions under named legal obligations.

C17.11 Governing law and dispute resolution:
- Named jurisdiction, named arbitration or court venue, named language.

C17.12 Variation and renewal:
- Named renewal mechanism, named price-change posture, named termination-for-convenience window.

The contractual posture maps to the tier in Section 3 and to the residual rating in Section 19. The legal and procurement team negotiates against the named tier; the security and GRC team signs off on the residual rating.

18. Evidence pack and verification

The assessment is read against the evidence the vendor produces. The pack lists the artefacts the buyer expects to see, the named verification step the assessor takes per artefact, and the named retention of the artefacts on the assessment record.

Required evidence pack (tier-dependent):

Tier 1 critical:
- SOC 2 Type II report (effective date, expiry date, scope statement, exceptions noted).
- ISO/IEC 27001 certificate plus Statement of Applicability.
- Most recent third-party penetration test executive summary or attestation letter.
- Most recent vulnerability management metric report (open findings, mean time to remediate, breach rate).
- Most recent business continuity test report.
- Most recent incident response exercise summary.
- Vendor security policy framework (redacted as needed).
- Vendor data flow diagram for the in-scope service.
- Vendor subprocessor list with named function, named geography, named data categories.
- Cyber insurance certificate of currency.
- Most recent transparency report on government access requests (if published).

Tier 2 important:
- SOC 2 Type II report OR ISO/IEC 27001 certificate.
- Most recent third-party penetration test executive summary or attestation letter.
- Vendor security policy framework (redacted as needed).
- Vendor subprocessor list.
- Cyber insurance certificate of currency.

Tier 3 standard:
- SOC 2 Type II report OR ISO/IEC 27001 certificate OR signed self-attestation against the template.
- Vendor security policy summary.
- Cyber insurance certificate of currency.

Verification per artefact:
- Date check (effective date inside the named validity window; expiry within the assessment period).
- Scope check (named service or system inside the named attestation scope).
- Auditor check (named auditor is in the named accreditation register; named auditor is independent of the vendor).
- Exception check (named qualified opinions, named exceptions, named carve-outs reviewed against the relationship scope).
- Currency check (most-recent date of the artefact is inside the named freshness window: SOC 2 within 13 months, penetration test within 12 months, ISO certificate inside its three-year cycle with current surveillance).

Storage of the evidence pack:
- Filed on the assessment engagement record with named retention.
- Retained per the audit evidence retention policy.
- Redacted as needed; named handler with access to unredacted artefacts.
- Renewed at each reassessment cycle; superseded versions archived.

Assessor sign-off per artefact:
- Reviewed and accepted, accepted with caveat, accepted with finding (recorded in Section 19), rejected (recorded as finding in Section 19).

19. Findings ledger and residual risk scoring

The findings ledger is the structured record of every gap surfaced in Sections 4 through 18. The residual rating is the aggregate read against the rubric. The audit reads this section to confirm the decision to onboard or renew was made with named evidence rather than with a generic confidence statement.

Findings ledger (one row per partially-met, not-met, or accepted-with-caveat answer):
- Finding reference number: {{FINDING_REF}}
- Section reference: {{SECTION_REF}}
- Question reference: {{QUESTION_REF}}
- Finding description: {{FINDING_DESCRIPTION}}
- Compensating control identified: {{COMPENSATING_CONTROL}}
- Inherent risk rating: Critical / High / Medium / Low.
- Residual risk rating: Critical / High / Medium / Low / Accepted.
- Remediation action requested: {{REMEDIATION_ACTION}}
- Remediation owner (vendor side): {{VENDOR_REMEDIATION_OWNER}}
- Remediation due date: {{REMEDIATION_DUE_DATE}}
- Acceptance approver (if Accepted): {{ACCEPTANCE_APPROVER}}
- Acceptance expiry: {{ACCEPTANCE_EXPIRY}}
- Renewal trigger: {{RENEWAL_TRIGGER}}

Inherent risk computation:
- A function of data sensitivity, operational criticality, integration depth, and regulatory exposure recorded in Sections 2 and 3.
- Critical inherent risk: at least two signals at Critical, or one Critical plus one High.
- High inherent risk: one Critical or two High.
- Medium inherent risk: one High or two Medium.
- Low inherent risk: all signals at Medium or Low.

Residual risk computation:
- Compensating controls strong: inherent risk reduced by two bands.
- Compensating controls partial: inherent risk reduced by one band.
- Compensating controls absent: inherent risk unchanged.
- Compensating controls counter-productive (a stated control fails on its evidence check): inherent risk increased by one band.

Aggregate residual rating per assessment:
- Worst finding residual rating drives the assessment-level rating, with documented exception path.
- Concentration of partially-met answers across multiple sections is a structural finding regardless of individual ratings.
- Trend over reassessment cycles (improving, flat, declining) is recorded at every renewal.

Approval ladder by aggregate residual rating:
- Accepted (no residual): programme owner sign-off.
- Low: programme owner sign-off.
- Medium: head of security sign-off.
- High: CISO sign-off.
- Critical: CISO and executive sponsor joint sign-off with named board notification.

The aggregate residual rating is the input to the contractual posture in Section 17 and the input to the onboarding or renewal decision in Section 20.

20. Decision, sign-off, and reassessment trigger

The decision section closes the assessment with the named approver, the named outcome, the named conditions on the relationship, and the named reassessment trigger. The audit reads this section to confirm the relationship is operating under a named authority rather than as an inherited default.

Assessment outcome (mark one):
- Approved for onboarding (or renewal) at the named tier with no conditions.
- Approved for onboarding (or renewal) at the named tier with named conditions (Section 19 findings open with named remediation).
- Approved with reduced scope (named scope restriction).
- Deferred pending remediation of named findings.
- Declined.

Named conditions on the relationship (if any):
- Open findings with remediation due dates (linked to Section 19).
- Reduced data scope (named exclusions).
- Reduced integration scope (named exclusions).
- Reduced geographic scope (named exclusions).
- Customer-managed encryption keys required for named data classes.
- 24-by-7 SOC required (Tier 1) within a named window.

Reassessment triggers:
- Tier-driven cadence: Tier 1 annual, Tier 2 biennial, Tier 3 triennial.
- Scope change (any expansion of the relationship under Section 2).
- Vendor change-of-control event.
- Vendor security incident affecting named scope.
- Vendor loss of a named attestation (SOC 2, ISO 27001, equivalent).
- Buyer regulatory change that brings the vendor into a new compliance scope.
- Customer audit finding that requires a stricter vendor discipline.

Named approvers and sign-off:

Assessor (the person who completed this assessment):
- Name: {{ASSESSOR_SIGNATURE_NAME}}
- Role: {{ASSESSOR_SIGNATURE_ROLE}}
- Date: {{ASSESSOR_SIGNATURE_DATE}}

Approving security authority (driven by residual rating in Section 19):
- Name: {{SECURITY_APPROVER_NAME}}
- Role: {{SECURITY_APPROVER_ROLE}}
- Date: {{SECURITY_APPROVER_DATE}}

Business sponsor (the relationship owner):
- Name: {{BUSINESS_SPONSOR_SIGNATURE_NAME}}
- Role: {{BUSINESS_SPONSOR_SIGNATURE_ROLE}}
- Date: {{BUSINESS_SPONSOR_SIGNATURE_DATE}}

CISO sign-off (Tier 1 and any High or Critical residual):
- Name: {{CISO_SIGNATURE_NAME}}
- Role: {{CISO_SIGNATURE_ROLE}}
- Date: {{CISO_SIGNATURE_DATE}}

Executive sponsor sign-off (Critical residual or board notification):
- Name: {{EXECUTIVE_SPONSOR_SIGNATURE_NAME}}
- Role: {{EXECUTIVE_SPONSOR_SIGNATURE_ROLE}}
- Date: {{EXECUTIVE_SPONSOR_SIGNATURE_DATE}}

Effective date once all sign-off is collected: {{EFFECTIVE_DATE_FINAL}}

Next scheduled reassessment date: {{NEXT_REASSESSMENT_DATE_FINAL}}

Document control entry (this assessment is logged in the parent TPRM policy document-control history with the named approver and rationale).

Six failure modes the assessment has to design against

The vendor security risk assessment fails the audit read in recognisable patterns. Each failure has a structural fix the template above is designed to enforce. Read this list before you customise the template so the customisation does not weaken the discipline that makes the assessment defensible.

Onboarding without an assessment then surfacing the gap after an incident

A vendor is signed under commercial pressure with the security review deferred until "next quarter". The vendor becomes the entry point of an incident months later, and the breach evidence cannot identify which approver authorised the bypass because there was no documented authorisation. The fix is the named approval ladder in Section 20 and the contractual conditionality on a passing residual rating before signature.

Static assessments that never refresh against a changing vendor

A vendor is assessed at onboarding and never reassessed; three years later the assessment record reflects the vendor of three years ago, not the vendor that has been acquired by a private equity firm, lost their lead security engineer, and expanded into a new data category. The fix is the tier-driven reassessment cadence in Section 3 and the named reassessment triggers in Section 20.

Spreadsheet assessments detached from the engagement record

The assessment lives in a spreadsheet on a shared drive that nobody can find at renewal. Renewal cycles start from a blank document; prior decisions are reinvented; the audit cannot reconcile the current relationship to a named historical decision. The fix is to carry the assessment on a workspace engagement record so the prior cycle is one query away.

Inconsistent residual scoring across assessors

Two assessments of the same vendor by two analysts produce different residual ratings because the rubric is interpreted rather than computed. The audit reads the inconsistency as evidence of an unscored process. The fix is the named rubric in Section 19 with the computed inherent rating, the computed compensating-control adjustment, and the named aggregate rule.

Fourth-party risk ignored until a subprocessor outage takes down multiple Tier 1 vendors

Section 14 is treated as optional and skipped; the buyer never identifies the concentration that exists across the Tier 1 vendor portfolio (every vendor depends on the same cloud region, the same identity provider, the same payments processor). When the subprocessor degrades, the concentration becomes visible. The fix is the disclosed subprocessor list in Section 14 read across the full vendor portfolio at the programme level.

Approval ladder collapses to one role

Every residual rating routes to the head of security regardless of severity because the lower bands have no engaged approver and the higher bands have no engaged executive sponsor. The leader becomes the bottleneck; critical-rated relationships sit unsigned; lower-rated relationships flow through without review because the head of security is overwhelmed. The fix is to staff and operate the ladder at every band per Section 20 with named approvers at each level.

Ten questions the governance review has to answer

The template is not self-maintaining. Operational review keeps assessments fresh against a changing vendor portfolio. Governance review answers whether the template is the operating instrument the programme is actually running against, or a paper artefact the audit will read as drift. Run these ten questions at every governance cycle and capture the answers in the programme record.

1.Is the vendor in this assessment in the buyer-side vendor inventory with the named tier in Section 3, and does the recorded tier match the tiering rule against the named signals in Section 2.
2.Has the evidence pack in Section 18 been verified per the named date, scope, auditor, exception, and currency checks, and is the named auditor independent of the vendor.
3.Are the findings in Section 19 each linked to a remediation action with a named owner on the vendor side and a named due date, with the named acceptance expiry and renewal trigger where the residual rating is Accepted.
4.Does the aggregate residual rating in Section 19 align to the named approval ladder in Section 20, and is the named approver signature dated within the approval window.
5.Are the contractual clauses in Section 17 mapped to the named tier in Section 3, and does the executed contract reflect the named tier-specific security schedule, audit right, subprocessor change notification, incident notification, and exit provisions.
6.Is the next scheduled reassessment date in Section 20 inside the tier-driven cadence (Tier 1 annual, Tier 2 biennial, Tier 3 triennial), and is the date in the buyer-side renewal calendar.
7.Is the disclosed subprocessor list in Section 14 reconciled against the buyer-side portfolio so that concentration risk across multiple Tier 1 vendors is visible at the programme level.
8.Are open findings on this vendor surfaced on the buyer-side risk register with named compensating control, named owner, and named decision cadence, or do open findings exist on the assessment but not on the register.
9.Has any material change (scope expansion, vendor change-of-control, vendor incident, vendor loss of attestation, buyer regulatory change) since the last reassessment been logged against the assessment and triggered a reassessment.
10.Does the buyer-side audit committee or risk committee receive a portfolio-level summary of vendor security risk at named cadence, with named drill-down to Critical and High residual ratings.

How the assessment pairs with SecPortal

The template above is copy-ready as a standalone artefact. If the security or GRC team already runs finding tracking, remediation, and compliance evidence on a workspace, the vendor assessment becomes the byproduct of the work rather than a separate maintenance project. SecPortal carries each vendor on an engagement record so the completed template, the supporting evidence the vendor returned, the scored findings, the residual ratings, and the named sign-offs live on one record rather than across a spreadsheet, a shared drive, and an email thread.

The engagement management feature scopes the per-vendor work under a single engagement record, so a programme-level read of the vendor portfolio is one query against the workspace rather than a reconciliation across spreadsheets. The findings management feature carries the findings ledger from Section 19 with named residual rating, named remediation owner, named due date, and named acceptance expiry; the audit reads the ledger against the assessment record rather than against a separate tracker. The document management feature retains the completed assessment, the prior versions across reassessment cycles, the SOC 2 reports, the ISO 27001 certificates, the penetration test summaries, the business continuity reports, and the redacted policy artefacts; the evidence pack from Section 18 lives alongside the assessment with named retention.

The activity log captures the timestamped chain of state changes by user across the assessment lifecycle (assessor draft, scoring, approver review, sign-off, renewal); the audit reconstructs the decision against a named operating record rather than against memory. The team management feature gates who can approve a residual rating at each band (programme owner for Low, head of security for Medium, CISO for High, CISO plus executive sponsor for Critical) so the approval ladder in Section 20 is gated by the platform rather than by convention. The multi-factor authentication enforcement on the workspace gates the approvers against an authenticated session, so the named sign-off on a Critical residual rating is a defensible record rather than an email approval the audit cannot evidence.

The compliance tracking feature maps findings and controls to ISO/IEC 27001, SOC 2, PCI DSS, NIST 800-53, NIST 800-161, NIS2, and DORA so the assessment evidences specific framework controls when an auditor asks for the vendor coverage of named requirements. The AI report generation workflow drafts the assessment summary the audit committee reads at the programme level, aggregated across the vendor portfolio, with named Critical and High ratings drawn out for executive attention.

SecPortal does not auto-distribute the questionnaire to the vendor (no email-out automation, no vendor portal for vendor self-service), does not integrate with third-party GRC platforms (no OneTrust, ProcessUnity, Archer, ServiceNow GRC, MetricStream, LogicGate integration), does not ingest automated vendor security ratings (no BitSight, SecurityScorecard, UpGuard ingestion), and does not produce contractual templates (the template is the assessment workbook, not the master services agreement or the data processing agreement). The assessor runs the assessment, files the evidence on the engagement, scores the findings on the workspace, and uses the named approval ladder to close the cycle.

Buyer and operator pairing

The vendor security risk assessment template is the artefact CISOs and security leaders, GRC and compliance teams, internal security teams, vulnerability management teams, AppSec teams, product security teams, cloud security teams, and security operations leaders run when a vendor relationship has to survive an external audit, an executive review, and a regulator inspection on the same record. External providers (virtual CISOs, compliance consultants, security consultants) use the same template to give clients a per-vendor operating instrument that is consistent with framework expectations rather than a fresh document per engagement.

Loading tool...

Related features

Orchestrate every security engagement from start to finish

Vulnerability management software that tracks every finding

Document management for every security engagement

Compliance tracking without a full GRC platform

Every action recorded across the workspace

Collaborate across your entire team

Multi-factor authentication on every workspace

AI-powered reports in seconds, not days

Notifications and alerts for the people who carry the work

Vendor security questionnaire response workflow

M&A security due diligence

Compliance audits

Audit fieldwork evidence request fulfillment

Security leadership reporting

Vulnerability acceptance and exception management

New application security onboarding

Cross-framework control mapping

Score the vendor against the live record, not against a side spreadsheet

SecPortal carries vendor assessments on a workspace engagement record so the completed template, the evidence, the scored findings, the residual ratings, and the sign-off live on one record the audit can read. Free plan available.

Get Started Free

No credit card required. Free plan available forever.

Vendor Security Risk Assessment Templatetwenty sections for tiering, controls, evidence, residual scoring, and a defensible sign-off

Twenty sections that turn a vendor security review into a defensible decision record

1. Cover and document control

2. Engagement scope and context

3. Vendor tiering decision

4. Governance and security organisation

5. Data handling and data protection

6. Network, infrastructure, and cloud security

7. Application and product security

8. Identity and access management

9. Vulnerability and patch management

10. Logging, monitoring, and security operations

11. Incident response and breach notification

12. Business continuity and operational resilience

13. Product-level security controls (customer-facing)

14. Supply chain and fourth-party risk

15. Privacy and data protection

16. Compliance, certifications, and audit

17. Contractual security clauses and exit

18. Evidence pack and verification

19. Findings ledger and residual risk scoring

20. Decision, sign-off, and reassessment trigger

Six failure modes the assessment has to design against

Onboarding without an assessment then surfacing the gap after an incident

Static assessments that never refresh against a changing vendor

Spreadsheet assessments detached from the engagement record

Inconsistent residual scoring across assessors

Fourth-party risk ignored until a subprocessor outage takes down multiple Tier 1 vendors

Approval ladder collapses to one role

Ten questions the governance review has to answer

How the assessment pairs with SecPortal

Buyer and operator pairing

Related features

Orchestrate every security engagement from start to finish

Vulnerability management software that tracks every finding

Document management for every security engagement

Compliance tracking without a full GRC platform

Every action recorded across the workspace

Collaborate across your entire team

Multi-factor authentication on every workspace

AI-powered reports in seconds, not days

Notifications and alerts for the people who carry the work

Vendor security questionnaire response workflow

M&A security due diligence

Compliance audits

Audit fieldwork evidence request fulfillment

Security leadership reporting

Vulnerability acceptance and exception management

New application security onboarding

Cross-framework control mapping

Score the vendor against the live record, not against a side spreadsheet

Twenty sections that turn a vendor security review into a defensible decision record

1. Cover and document control

2. Engagement scope and context

3. Vendor tiering decision

4. Governance and security organisation

5. Data handling and data protection

6. Network, infrastructure, and cloud security

7. Application and product security

8. Identity and access management

9. Vulnerability and patch management

10. Logging, monitoring, and security operations

11. Incident response and breach notification

12. Business continuity and operational resilience

13. Product-level security controls (customer-facing)

14. Supply chain and fourth-party risk

15. Privacy and data protection

16. Compliance, certifications, and audit

17. Contractual security clauses and exit

18. Evidence pack and verification

19. Findings ledger and residual risk scoring

20. Decision, sign-off, and reassessment trigger

Six failure modes the assessment has to design against

Onboarding without an assessment then surfacing the gap after an incident

Static assessments that never refresh against a changing vendor

Spreadsheet assessments detached from the engagement record

Inconsistent residual scoring across assessors

Fourth-party risk ignored until a subprocessor outage takes down multiple Tier 1 vendors

Approval ladder collapses to one role

Ten questions the governance review has to answer

Vendor Security Risk Assessment Template
twenty sections for tiering, controls, evidence, residual scoring, and a defensible sign-off