Vendor Security Questionnaires and Assessments

The SIG questionnaire, maintained by Shared Assessments, is the most widely used standardised vendor questionnaire outside the cloud sector. Its eighteen risk domains cover the principal areas of information security: asset management, access control, human resources security, physical and environmental security, communications and operations management, incident management, business continuity, compliance, and several others. Within each domain, questions are mapped to specific controls in ISO 27001 Annex A, the NIST Cybersecurity Framework, PCI-DSS, HIPAA, and other frameworks. This cross-referencing means that when a vendor completes the SIG, the buyer can read the responses through the lens of whichever framework governs their own compliance obligations.

The SIG Core contains several hundred questions. The SIG Lite is a subset of roughly 125 questions designed for vendors where the inherent risk is lower: a supplier of printed materials used internally, for instance, needs less scrutiny than a cloud provider processing customer personal data. Many organisations tier their vendor population by inherent risk and deploy SIG Lite for Tier 2 and Tier 3 vendors while reserving SIG Core for Tier 1 (critical or high-risk) suppliers.

The CAIQ serves a different purpose. Published by the Cloud Security Alliance and aligned to its Cloud Controls Matrix (CCM), the CAIQ is structured around cloud-specific concerns that general questionnaires do not address well: which party in a shared-responsibility model is responsible for a given control, how data is isolated between tenants, where data resides geographically, and how virtualisation infrastructure is hardened. Cloud vendors including major infrastructure providers publish completed CAIQs in the CSA STAR registry, a public database of cloud security assessments. Buyers can download these completed assessments rather than asking each provider to complete a questionnaire from scratch, which reduces the assessment burden on both sides.

Neither format is universally mandated; some sectors have their own questionnaire formats. Financial services regulators in the UK (under FCA outsourcing rules) and the European Banking Authority (under EBA ICT guidelines) each publish third-party risk assessment expectations that go beyond generic questionnaires. The SIG and CAIQ are best understood as a foundation that many regulated sectors then extend with sector-specific requirements.

The fundamental limitation of any questionnaire is self-reporting. A vendor completes a questionnaire without the buyer present. There is no mechanism in the questionnaire itself that prevents a vendor from answering questions optimistically, from misunderstanding a question and answering a different one, or from describing a policy that exists on paper but has never been implemented. These are not hypothetical problems: procurement and risk teams routinely find, during evidence review or on-site assessment, that questionnaire answers do not match observable reality.

Questionnaire responses also go stale. A vendor that completed an accurate SIG twelve months ago may have changed its architecture, replaced a CISO, suffered a breach, or let certifications lapse since then. Annual reassessment is the minimum cadence for high-risk vendors; some organisations reassess Tier 1 suppliers every six months or on any material change in the vendor's environment.

A second class of limitation is completeness. Standard questionnaires are written to cover common controls across a general vendor population. A specific vendor relationship may carry risks that the questionnaire does not address: a software vendor that has access to source code repositories, a logistics provider that physically handles hardware, or a translation vendor that receives legally privileged documents. Questionnaire-based programmes must supplement standard instruments with custom questions tailored to the specific risk profile of each vendor relationship.

Fourth-party risk is a third limitation. A questionnaire captures what the vendor does directly. It rarely captures what the vendor's own subcontractors do. If a critical vendor outsources its backup infrastructure or its security operations centre to a subcontractor, a questionnaire directed at the vendor reveals nothing about the subcontractor's posture. Mature programmes address this by requiring vendors to disclose material subcontractors and to confirm that those subcontractors are assessed to equivalent standards.

An on-site assessment places the buyer's security or risk professionals (sometimes accompanied by a specialist third-party assessor) at the vendor's premises to evaluate controls directly rather than through self-reported answers. The assessment combines interviews, inspection, and testing. It is more resource-intensive than a questionnaire, so it is typically reserved for vendors with high inherent risk: those handling sensitive personal data, providing critical IT infrastructure, or operating in the supply chain for regulated products or services.

A structured on-site assessment follows a consistent sequence. Before the visit, the assessor reviews the vendor's completed questionnaire, any prior audit reports (SOC 2, ISO 27001 certificate), the contract, and the data flow map showing what data the vendor receives and processes. This pre-visit review identifies areas where questionnaire responses need verification and guides the interview agenda. On site, assessors conduct structured interviews with the vendor's CISO, IT operations lead, and relevant process owners. They inspect physical controls (access to server rooms, clean-desk policy, visitor logs), review configuration samples (firewall rule sets, patch levels on a sample of systems, password policy settings), and observe key processes such as backup verification or incident response drills if timing permits.

The output of an on-site assessment is a formal report with findings classified by severity, typically using a Critical / High / Medium / Low / Informational scale. Each finding states the observed condition, the expected standard (citing the contract, the questionnaire requirement, or the applicable framework control), the gap, and a recommended remediation action with a suggested timeline. The report is shared with the vendor and the buying organisation's third-party risk committee or equivalent governance body.

Validation transforms a self-reported questionnaire response into verified evidence. The three main validation mechanisms are evidence requests, independent audit reports, and technical testing.

Evidence requests ask the vendor to supply artefacts that corroborate specific answers. A vendor that answers "Yes" to "Do you have a documented information security policy?" may be asked to provide the policy document. A vendor that claims to perform annual penetration tests may be asked to supply the most recent executive summary. A vendor with ISO 27001 certification may be asked to supply the current certificate (which includes the certification body's name, the scope statement, and the expiry date). Evidence requests are targeted: asking for dozens of documents from every vendor is impractical; the request should be scoped to the highest-risk areas and the answers most in doubt.

Independent audit reports are the most scalable validation mechanism for technology vendors. A SOC 2 Type II report from a reputable CPA firm covers a defined period and tests whether the vendor's stated controls actually operated effectively over that period. Buyers should check that the report covers the relevant trust service criteria (especially Security, and Availability if uptime matters), that the audit period is recent, that the report was issued by a recognised firm, and that the report scope covers the systems and data in the vendor relationship. A vendor that provides a SOC 2 Type II for a subsidiary that does not handle the buyer's data is providing an artefact that does not validate the relevant controls.

Technical testing can supplement questionnaire validation for high-risk vendors. This includes requesting recent penetration test reports (verifying scope and methodology), reviewing vulnerability scan results for internet-facing assets, or using passive external scanning tools to identify misconfigured infrastructure before and after the assessment. Technical testing conducted directly against vendor systems requires prior written consent from the vendor and clear scoping to avoid unintended disruption.

When a questionnaire review, evidence check, or on-site assessment reveals a gap that exceeds the buying organisation's risk tolerance, the finding must be escalated and a remediation plan agreed. The escalation path depends on the severity of the finding and the stage of the vendor relationship.

For a pre-contract assessment, a critical finding may block onboarding entirely. If the vendor cannot demonstrate adequate controls before a contract is signed, the organisation should either decline the relationship, require remediation before contract execution, or accept the risk formally at an appropriate governance level (typically the CISO and business owner jointly, documented in the risk register). Accepting residual risk from a vendor without formal documentation violates the governance expectations of ISO 27001 clause 6.1.3 and most regulatory frameworks.

For an existing vendor, escalation follows a defined severity ladder. Critical findings (for example, evidence of an unpatched critical vulnerability on a system holding the organisation's data, or absence of encryption where it was contractually required) trigger immediate notification to the vendor's account manager and the vendor's security team, a demand for a remediation plan within a defined short timeframe (commonly 24 to 72 hours for the plan, not the fix), and possible suspension of data sharing until the gap is addressed. High findings typically have a 30-day remediation window; medium findings 90 days; low findings may be tracked in the next scheduled assessment cycle.

Contractual audit rights are the legal foundation of this process. Without a clause in the vendor contract that grants the buyer the right to audit, inspect, or receive third-party audit reports, the buyer has no enforceable mechanism to demand evidence of remediation. Standard data processing agreements under GDPR Article 28 must include audit rights; the same requirement appears in HIPAA Business Associate Agreements, in PCI-DSS contractual requirements for service providers, and in the DPDP Act 2023 requirements for data fiduciaries engaging data processors. Organisations should ensure the audit rights clause is present before signing any contract with a vendor that handles personal data or provides critical services.

Point-in-time questionnaires and periodic assessments are necessary but not sufficient for high-risk vendor relationships. Continuous monitoring adds signals between formal assessment cycles to detect changes in vendor posture before they materialise as incidents. Monitoring inputs include: external attack surface scans (identifying new internet-facing assets or newly discovered vulnerabilities); threat intelligence feeds (alerts when a vendor is mentioned in breach disclosures, dark-web data sales, or CVE databases for their products); news and regulatory action monitoring (sanctions, regulatory fines, major leadership changes, or public breaches at the vendor); and automated questionnaire re-trigger rules (for example, if the vendor experiences a security incident, a reassessment is triggered outside the annual cycle).

Third-party risk management (TPRM) platforms such as Archer, ServiceNow VRM, and OneTrust automate much of the questionnaire distribution, response tracking, evidence collection, and scoring workflow. They also aggregate external monitoring signals and link vendor risk scores to the internal risk register. Organisations without a dedicated platform typically manage the process in spreadsheets, which becomes unsustainable once the vendor population exceeds a few dozen active relationships. The choice of tooling affects how consistently the programme is applied but does not change the underlying process requirements.

Regulatory expectations for third-party risk programmes are rising. The EU's Digital Operational Resilience Act (DORA), which took effect in January 2025 and applies to financial entities and their critical ICT service providers, sets detailed requirements for vendor registers, contractual provisions, and ongoing monitoring. India's DPDP Act 2023 requires data fiduciaries to ensure that data processors implement appropriate security measures, making vendor security assessment an implied regulatory obligation. The US SEC's cybersecurity disclosure rules require public companies to disclose material risks from third parties. Across jurisdictions, the direction of travel is toward formalised, documented, and auditable third-party risk programmes rather than ad hoc questionnaire exercises.