Third-Party & Vendor Risk interview questions

TPRM is the process of identifying, assessing, mitigating and monitoring risks arising from vendors, suppliers, service providers, partners and their own subcontractors (fourth parties).

• Organisations increasingly outsource critical processes and data to third parties (cloud, SaaS, billing, support).
• You can outsource the service but not the accountability — regulators and customers hold you responsible.
• Many major breaches have originated in the supply chain.

Instead of custom questionnaires, many organisations use industry standards:

• Shared Assessments SIG (Standardized Information Gathering) questionnaire.
• Cloud Security Alliance CAIQ (Consensus Assessments Initiative Questionnaire), aligned to the Cloud Controls Matrix.
• Sector-specific options exist, e.g. in healthcare.

Questionnaires should be validated with evidence (reports, policies, test results) for higher-risk vendors — self-attestation alone is weak assurance.

• Third party: any external organisation the company has a relationship with, including vendors, suppliers, partners, contractors, resellers and outsourcers.
• Vendor or supplier: a third party that provides goods or services. In practice the terms are often used interchangeably.
• Fourth party: your vendor's vendors (subcontractors and sub-processors), such as the cloud provider hosting your SaaS vendor.
• Nth party: further down the chain.

• Inherent vendor risk: the risk the relationship carries before considering the vendor's controls. It is based on data access, system access, criticality of the service, regulatory impact and spend.
• Residual vendor risk: what remains after assessing the vendor's controls and any extra controls you add (contract terms, restricted access, monitoring).
• Inherent risk decides the tier and depth of assessment. Residual risk decides approval, conditions and how often you review.

Due diligence is the set of checks done before signing with a vendor, proportionate to its risk:

• Security and privacy: questionnaires, certifications (ISO 27001, SOC 2), penetration test summaries, policies.
• Financial stability and ownership: can they stay in business, and are there sanctions or conflicts?
• Legal and compliance: data location, sub-processors, regulatory licences, litigation history.
• Operational resilience: BCP/DR, support model and SLAs.
• Reputation and ESG concerns where relevant.

1. Planning and sourcing: define the business need and data/system access involved.
2. Inherent risk scoring / tiering: classify the vendor by criticality and data sensitivity.
3. Due diligence: questionnaires, SOC 2 / ISO 27001 reports, policies, pen test summaries, financial and reputational checks — depth based on tier.
4. Risk assessment and remediation: identify gaps, agree remediation or compensating controls, or decide not to proceed.
5. Contracting: security, privacy, audit rights, breach notification, subcontracting and exit clauses.
6. Ongoing monitoring: periodic reassessment, security ratings, news monitoring, performance and incident tracking.
7. Offboarding: revoke access, return or destroy data, obtain confirmation.

Vendor tiering assigns an inherent risk level so assessment effort matches risk. Common factors:

• Type and volume of data accessed (e.g. PHI, personal data, card data, confidential IP).
• Level of system or network access.
• Criticality of the service to operations (what if it fails for a week?).
• Regulatory relevance and geography (e.g. data hosted outside the country).
• Substitutability and concentration (how hard is it to replace?).

High-tier vendors get full due diligence and annual reviews; low-tier vendors may only need a short questionnaire.

• Security requirements and adherence to standards/policies.
• Data protection terms (e.g. BAA under HIPAA, data processing agreement under GDPR/DPDP), including data location and transfer restrictions.
• Breach and incident notification obligations with defined timeframes.
• Right to audit or to receive independent assurance reports (SOC 2, ISO 27001 certificate).
• Subcontractor (fourth-party) approval and flow-down obligations.
• Business continuity and service level commitments.
• Data return and secure destruction at termination; exit and transition support.
• Liability, indemnity and insurance requirements.

In cloud services, security responsibilities are split between the provider and the customer, and the split depends on the model:

• IaaS: provider secures physical infrastructure and virtualisation; customer secures operating systems, applications, data, identities and configuration.
• PaaS: provider also manages the platform/runtime; customer manages applications, data and access.
• SaaS: provider manages most of the stack; customer is still responsible for data, user access, configuration and use.

Common failures come from customers assuming the provider handles something it does not, such as misconfigured storage or excessive permissions.

• Clarify the specific gaps and translate them into business risk (data exposure, regulatory impact, operational impact).
• Work with the vendor on a remediation plan with dates, and include it in the contract.
• Identify compensating controls on your side (e.g. limit data shared, encryption, extra monitoring, SSO with MFA).
• If residual risk remains above appetite, document it and route it for formal risk acceptance by an appropriate authority.
• Set conditions and reassessment dates; track remediation through to closure.

• Security ratings tools scan a vendor's internet-facing footprint (exposed services, patching, email security, leaked credentials) and give a score.
• Useful for monitoring many vendors between assessments and for spotting sudden changes.
• Limitations: they only see the outside, can misattribute assets and do not reflect internal controls.
• Combine them with threat and news monitoring (breaches, financial distress) and with periodic assessments.
• Define triggers: a big score drop or a reported breach starts a vendor follow-up.

• Revoke all access: accounts, VPN, API keys, shared credentials and physical badges.
• Recover or securely delete data, with a certificate of destruction or evidence of return.
• Transition services and knowledge if replacing the vendor.
• Close or update contracts, and check surviving obligations such as confidentiality.
• Update the vendor inventory, risk register and data flows.
• For critical vendors, have an exit plan prepared in advance (a DORA requirement for EU financial entities, and good practice everywhere).

• Start with the data and integration: what data goes in, how users authenticate (SSO), and what integrations or API scopes are needed.
• Request existing assurance first: SOC 2 Type II, ISO 27001 certificate and SoA, penetration test summary, a trust centre.
• Focus on key controls: encryption, access management (SSO, MFA, RBAC), logging, vulnerability management, incident notification, data location and deletion, sub-processors.
• Check the configuration you control: tenant settings, admin roles, audit logs.
• Ask follow-up questions only where evidence is missing.

1. Log it as a potential incident and inform your incident response team and privacy/legal.
2. Ask the key questions in writing: what services and data are affected, is your data involved, what is the timeline, what containment is in place, and when will they update you?
3. Check your contract: notification timelines, cooperation duties and audit rights.
4. Take protective steps: rotate shared credentials or API keys, review logs for activity from the vendor's connections, and consider suspending integrations.
5. Track your own regulatory clocks. Your notification duty may start when you become aware, not when the vendor finishes its investigation.
6. Follow up until closure and reassess the vendor afterwards.

• Assess the vendor now, prioritising by its inherent risk: what data and access does it already have?
• If high risk, apply interim controls (restrict data and access) until the review is done.
• Check whether the contract has security clauses. If not, negotiate an addendum or data processing agreement.
• Fix the process: build the security review into the procurement workflow (no purchase order for in-scope categories without a TPRM ticket), and train procurement.
• Report the process gap as a finding if it is a pattern.

• Challenge the need: can access be time-bound and approved per session instead of permanent?
• Require named accounts (no shared logins), MFA and access through a controlled path such as a privileged access management tool or jump host.
• Least privilege: only the systems and rights needed.
• Session logging or recording, with review of high-risk activity.
• Contract terms: confidentiality, background checks, incident notification and liability.
• Periodic access reviews and immediate removal when staff change.

• Read the exception details: how many samples failed, what kind of access, and over what period.
• Check whether the failing control affects the services and data you use.
• Look at management's response and remediation date.
• Check for compensating controls in the report or in your own environment (for example, your own SSO and access reviews on the vendor platform).
• Decide: accept with follow-up, require remediation evidence, or escalate if the risk is significant. Record the decision in the vendor file.

• Fourth-party risk: risk from your vendors' own suppliers (e.g. your SaaS provider's hosting provider). You usually have no direct contract with them, so you rely on your vendor's controls, contractual flow-downs and SOC reports listing subservice organisations.
• Concentration risk: dependence on a single provider (or a few) for many critical services, so one failure has a wide impact — e.g. many services hosted with the same cloud provider or region.

Mitigations include mapping critical supply chains, requiring disclosure of material subcontractors, multi-region or multi-provider designs where justified, and exit planning.

• Inventory software components, ideally through Software Bills of Materials (SBOMs) from vendors and your own builds.
• Monitor components for vulnerabilities and use frameworks such as NIST SSDF (SP 800-218) for secure development expectations.
• Require vendors to have secure development practices, signed updates and timely vulnerability disclosure.
• Protect your build pipeline (access control, integrity checks, dependency pinning).
• Include software supply chain events in incident playbooks, such as a compromised update or a critical library vulnerability.

• Coverage: percentage of vendors inventoried and tiered; percentage of Tier 1 and 2 vendors assessed on time.
• Risk: number of vendors with high residual risk, open vendor issues by age, and vendors with expired assurance (old SOC 2 reports).
• Contract: percentage of critical vendors with required security clauses and exit plans.
• Events: vendor incidents, response times and notification compliance.
• Concentration: critical services dependent on a single provider.

Report to the risk committee with trends and the few vendors that need decisions.

• Concentration analysis: know which services depend on that provider and region, including fourth parties (SaaS vendors hosted there).
• Architecture: multi-zone or multi-region designs for critical services, with tested failover.
• Exit and contingency plans: documented and tested, including manual workarounds.
• Contracts: SLAs, credits, status communication and support escalation paths.
• Communication: templates for customers and regulators about service disruption.
• After the event: review actual impact against the BIA and adjust the strategy.

• Accept that large providers often will not complete custom questionnaires, but still need assurance.
• Use what they publish: SOC 2 Type II, ISO 27001/27017/27018 certificates, CSA STAR entries, trust centre documentation and contractual commitments.
• Map that evidence to your requirements and note gaps.
• Focus on your side of shared responsibility: configuration, identity, logging and encryption choices.
• Where gaps remain, record residual risk and get it accepted by the business owner.

1. Build the inventory with spend data from finance, SSO and network data, and contract lists.
2. Tier every vendor with a short inherent-risk questionnaire completed by the business owner.
3. Focus deep assessments on Tier 1 (maybe 20–30 vendors) and lighter, evidence-based reviews on Tier 2.
4. For Tier 3, rely on contract terms and periodic attestation only.
5. Reuse existing assurance (SOC 2, ISO) and shared assessment services where possible.
6. Automate with a TPRM tool: reminders, questionnaires and scoring.
7. Agree a phased schedule with leadership and report progress.