Third-Party Security Risk
Third-party security risk is the potential for security incidents, data breaches, or operational disruptions arising from an organisation’s relationships with external entities that have access to its systems, data, or facilities. These relationships extend beyond traditional vendor contracts to include implementing partners, technology providers, cloud services, consultants, and any entity that processes, stores, or transmits organisational data. For mission-driven organisations, third-party relationships present particular complexity: partnerships with local organisations are fundamental to programme delivery, yet these partners frequently operate with limited security resources and may themselves face elevated threat environments.
- Third party
- Any external entity with access to organisational systems, data, networks, or facilities. This encompasses vendors, suppliers, service providers, implementing partners, contractors, consultants, and cloud service providers.
- Vendor
- A commercial entity providing goods or services under contract. Vendors represent one category of third party, distinguished by the transactional nature of the relationship.
- Subprocessor
- An entity engaged by a third party to process data on behalf of the organisation. When a cloud provider uses another company’s infrastructure, that infrastructure provider is a subprocessor.
- Fourth party
- Entities in the supply chain beyond direct third parties. A vendor’s vendors, or a partner’s technology providers, constitute fourth-party relationships that create indirect risk exposure.
- Inherent risk
- The risk level of a third-party relationship before any controls are applied, determined by factors such as data sensitivity, system access, and business criticality.
- Residual risk
- The risk level remaining after security controls and contractual protections are in place. Residual risk determines whether a relationship is acceptable.
- Due diligence
- The investigation and assessment conducted before entering a third-party relationship to understand security posture, financial stability, and operational capability.
Risk inheritance model
When an organisation shares data with a third party or grants system access, the organisation inherits a portion of that third party’s security risk. This inheritance operates through several mechanisms that determine the actual risk exposure.
Data exposure creates risk proportional to the sensitivity and volume of data accessible to the third party. A payroll provider processing salary information for 500 staff members presents different risk than a marketing agency with access to anonymised programme statistics. The exposure calculation considers both the classification level of data and the breadth of access: a provider with access to all beneficiary records across all programmes presents higher exposure than one accessing records for a single project.
System integration depth determines how directly a third party’s compromise could affect organisational systems. A SaaS application accessed through a web browser with SSO creates limited integration depth. An on-premises system with direct database connections, API access to multiple internal services, and privileged credentials creates deep integration where compromise propagates rapidly. Integration depth also affects containment options: shallow integration permits rapid disconnection, while deep integration makes isolation difficult without significant operational impact.
Operational dependency measures how severely third-party failure would disrupt organisational operations. A critical dependency exists when the organisation cannot perform essential functions without the third party’s service. The grants management system, primary email provider, and beneficiary registration platform represent critical dependencies where outages directly halt operations. Non-critical dependencies cause inconvenience but permit continued operation through workarounds.
+------------------------------------------------------------------+| RISK INHERITANCE MODEL |+------------------------------------------------------------------+| || +--------------------+ || | THIRD PARTY | || | Security Posture | || +--------------------+ || | || | Inherits through: || | || +-----+-----+-----+-----+ || | | | | | || v v v v v || +-----+-----+-----+-----+-----+ || |Data |Sys |Ops |Net |Phys | || |Exp. |Int. |Dep. |Conn.|Acc. | || +-----+-----+-----+-----+-----+ || | | | | | || +-----+-----+-----+-----+ || | || v || +--------------------+ || | ORGANISATION | || | Inherited Risk | || +--------------------+ || || Risk = f(Third Party Posture, Inheritance Factors, Controls) || |+------------------------------------------------------------------+Figure 1: Risk inheritance flows through multiple channels from third party to organisation
Network connectivity affects risk when third parties connect directly to organisational networks. A partner organisation with a site-to-site VPN connection to access shared systems creates network-level risk: their compromised endpoint could serve as an entry point to the organisational network. Cloud services accessed over the internet without network integration present lower network connectivity risk but equivalent data exposure risk.
Physical access applies when third parties enter organisational facilities, whether for service delivery, maintenance, or partnership activities. Physical access enables device tampering, visual observation of sensitive information, and potential for credential theft. Cleaning contractors with after-hours access present different physical risk than programme partners attending coordination meetings.
Risk tiering
Risk tiering assigns third parties to categories based on their inherent risk profile, with each tier requiring proportionate due diligence and ongoing monitoring. The tiering model balances security rigour against operational practicality: applying enterprise-grade assessment to every relationship would consume resources that mission-driven organisations lack, while treating all third parties identically would under-protect against significant risks.
Tier assignment derives from a combination of factors rather than any single dimension. A third party might handle sensitive data (high data risk) but have no system access (low integration risk) and be easily replaceable (low dependency risk). The tiering model weights these factors to produce an overall classification.
+------------------------------------------------------------------+| RISK TIERING MODEL |+------------------------------------------------------------------+| || ASSESSMENT FACTORS || +------------------------------------------------------------+ || | | || | Data Sensitivity System Access Dependency | || | +----------------+ +----------------+ +------------+ | || | | Public 1 | | None 1 | | Easily | | || | | Internal 2 | | User-level 2 | | replaced 1 | | || | | Confidential 3 | | Admin 3 | | Workaround | | || | | Restricted 4 | | Privileged 4 | | exists 2 | | || | | Protection 5 | | Infrastructure | | Critical 3 | | || | +----------------+ +----------------+ +------------+ | || | | || +------------------------------------------------------------+ || | || v || TIER ASSIGNMENT || +------------------------------------------------------------+ || | | || | Score 3-5: TIER 3 (Standard) Light assessment | || | Score 6-9: TIER 2 (Elevated) Standard assessment | || | Score 10-12: TIER 1 (Critical) Comprehensive review | || | | || +------------------------------------------------------------+ || |+------------------------------------------------------------------+Figure 2: Tiering derives from weighted assessment of multiple risk factors
Tier 1 (Critical) encompasses third parties with access to protection data, privileged system access, or where service interruption would halt critical operations. Examples include the beneficiary registration platform provider, the organisation’s primary identity provider, case management system vendors for protection programmes, and any entity with domain administrator credentials. Tier 1 relationships require comprehensive due diligence before engagement, including independent security assessments, and continuous monitoring throughout the relationship. The organisation should maintain no more than 15-25 Tier 1 relationships; exceeding this range indicates either over-classification or genuinely elevated risk exposure requiring additional security resources.
Tier 2 (Elevated) covers third parties with access to confidential data, standard system access, or moderate operational dependency. This tier includes most SaaS applications used for core operations, implementing partners handling programme data, IT support contractors with user-level access, and cloud infrastructure providers. Tier 2 assessment uses standardised questionnaires and verification of key controls, with periodic reassessment. Most organisations maintain 30-80 Tier 2 relationships.
Tier 3 (Standard) applies to third parties with limited data access, no system integration, or easily replaceable services. Office supply vendors, facilities maintenance contractors without IT system access, and software tools used for non-sensitive internal functions fall into Tier 3. Assessment relies on basic verification and contractual protections, without detailed security questionnaires. Tier 3 relationships receive monitoring only when material changes occur or incidents arise.
Due diligence mechanisms
Due diligence establishes the third party’s security posture before the organisation commits to the relationship. The depth and method of due diligence scales with tier classification, but all tiers share common elements: verification that the third party’s security controls are appropriate for the data and access they will receive, and confirmation that no disqualifying factors exist.
Assessment instruments
The security questionnaire is the primary instrument for gathering security posture information. Questionnaires derive from established frameworks to ensure comprehensive coverage while maintaining consistency across assessments. The Standardised Information Gathering (SIG) questionnaire provides a widely-recognised baseline; organisations adapt it to their specific requirements and the regulatory environment they operate within. Questionnaire responses require supporting evidence for critical controls: a claim of “annual penetration testing” should be accompanied by an executive summary from the most recent test.
Questionnaires function as self-assessment, introducing the risk that third parties overstate their security maturity. For Tier 1 relationships, questionnaire responses require independent verification through additional mechanisms.
Independent assessments provide external validation of security controls. SOC 2 Type II reports, issued by independent auditors, verify that controls operated effectively over a period (normally 12 months). ISO 27001 certification demonstrates conformance to an information security management system standard, though certification alone does not guarantee control effectiveness. Penetration test reports reveal vulnerability status at a point in time. For Tier 1 third parties lacking recent independent assessments, the organisation commissions its own assessment or accepts elevated residual risk.
Technical verification tests specific controls through direct observation. For cloud services, this includes reviewing security configuration through administrative interfaces, verifying encryption implementation, and confirming access control settings. For on-premises integrations, network architecture review and vulnerability scanning of externally-facing components provide technical evidence. Technical verification is resource-intensive and reserved for Tier 1 relationships with significant technical integration.
Site visits permit direct observation of physical security, operational practices, and organisational culture. For implementing partners in field locations, site visits reveal security conditions that questionnaires cannot capture: whether devices are secured after hours, whether visitors are escorted, whether sensitive documents are protected. Site visits are impractical for cloud-only relationships but valuable for partners with physical operations.
Due diligence workflow
+------------------------------------------------------------------+| DUE DILIGENCE WORKFLOW |+------------------------------------------------------------------+| || +----------------+ || | Relationship | || | Request | || +-------+--------+ || | || v || +-------+--------+ || | Initial | Data types, access needs, || | Scoping | dependency level || +-------+--------+ || | || v || +-------+--------+ || | Tier | || | Assignment | || +-------+--------+ || | || +-----+-----+-----+ || | | | || v v v || +--+--+ +---+--+ +---+---+ || |Tier1| |Tier2 | |Tier 3 | || +--+--+ +---+--+ +---+---+ || | | | || v v v || +--+-------+ ++------+ +--------+ || |Comprehen-| |Standard| |Basic | || |sive | |Question| |Contract| || |Assessment| |naire | |Review | || +--+-------+ ++------+ +---+----+ || | | | || v | | || +--+-------+ | | || |Independent | | || |Verification| | | || +--+-------+ | | || | | | || +-----+-----+-----+-------+ || | || v || +-------+--------+ || | Risk | || | Evaluation | || +-------+--------+ || | || +-----+-----+ || | | || v v || +--+---+ +---+----+ || |Accept| |Decline/| || | | |Remediate || +--+---+ +--------+ || | || v || +--+------------+ || | Contract | || | Negotiation | || +---------------+ || |+------------------------------------------------------------------+Figure 3: Due diligence depth scales with tier assignment
The workflow begins with initial scoping to determine what data the third party will access, what systems they will connect to, and how critical their service is to operations. Scoping requires input from the business owner requesting the relationship, as they understand operational requirements, and from security or IT staff who assess technical implications. Incomplete scoping leads to inappropriate tier assignment: a “simple” SaaS tool that will process beneficiary information presents different risk than one handling only internal scheduling.
Tier assignment follows the scoring model, with adjustments for contextual factors. A third party operating in a high-risk jurisdiction faces elevated threat environment, potentially increasing tier. A long-standing partner with demonstrated security maturity might merit reduced tier despite high data access. Tier adjustments require documented rationale.
Assessment execution proceeds according to tier requirements. Tier 3 relationships proceed directly to contract review with standard security clauses. Tier 2 relationships complete security questionnaires with evidence for critical controls. Tier 1 relationships undergo comprehensive assessment including questionnaire, independent verification, and potentially technical assessment or site visit.
Risk evaluation compares assessment findings against organisational risk tolerance. Identified gaps do not automatically disqualify third parties; evaluation considers whether gaps can be addressed through compensating controls, contractual requirements, or accepting defined residual risk. A partner lacking formal incident response procedures might accept a contractual requirement to follow organisational incident procedures, with compensating control of reduced data sharing until procedures mature.
Contractual security requirements
Contracts establish binding security obligations that convert assessment findings into enforceable commitments. Security requirements in contracts serve three functions: they mandate specific controls, they allocate responsibility for security failures, and they provide mechanisms for verification and enforcement.
Required contract provisions
Security standards clauses specify the minimum security controls the third party must maintain. Rather than incorporating lengthy technical requirements into contracts, security standards clauses reference external standards (ISO 27001, CIS Controls, or organisational security policies) and require adherence. The clause “Supplier shall implement and maintain information security controls conforming to ISO/IEC 27001:2022 or equivalent” establishes a verifiable obligation without contract amendments when specific controls evolve.
Data protection clauses address regulatory compliance for personal data processing. Under GDPR and equivalent regulations, contracts with processors must include specific provisions: processing instructions, confidentiality obligations, subprocessor restrictions, data subject rights assistance, breach notification, and audit rights. These clauses are legally mandated, not optional security enhancements. Template data processing agreements from regulatory authorities (such as the UK ICO’s template) provide compliant starting points.
Breach notification requirements mandate rapid notification when security incidents affect organisational data. Contracts specify the notification timeline (24-72 hours is standard for significant incidents), the notification channel, and the information required. The clause “Supplier shall notify Organisation within 24 hours of discovering any security incident affecting Organisation data, providing incident description, affected data categories, and preliminary impact assessment” creates enforceable obligation. Without contractual notification requirements, third parties may delay notification while investigating, reducing the organisation’s response window.
Audit rights permit the organisation to verify security control implementation. Standard audit rights permit annual assessments with reasonable notice. Enhanced audit rights for Tier 1 relationships permit assessment at shorter notice and include the right to commission penetration testing. Audit rights require corresponding obligations: the organisation must maintain confidentiality of findings and bear assessment costs except when findings reveal material deficiencies.
Subprocessor controls restrict the third party’s use of additional entities to process organisational data. Contracts require advance notification of new subprocessors and permit the organisation to object. The contract should specify whether objection rights include contract termination without penalty if a subprocessor is unacceptable. Without subprocessor controls, the organisation loses visibility into its extended supply chain.
Termination provisions address security-triggered termination and data handling at relationship end. Security termination clauses permit immediate termination following material security breaches, without standard notice periods and without termination fees. Exit provisions require data return in usable format and certified destruction of retained copies. The contract specifies the data return timeline (30 days is standard) and destruction evidence requirements.
Contract negotiation realities
Security contract requirements exist in tension with commercial realities. Enterprise vendors selling to thousands of customers resist individual contract modifications: their model depends on standardised terms. Negotiating power correlates with contract value; a £5,000 annual subscription does not command the same attention as a £500,000 platform deployment.
For standard SaaS agreements where contract modification is impractical, the assessment focuses on evaluating existing terms rather than negotiating improvements. The question shifts from “can we add audit rights” to “do the existing terms provide adequate protection given the risk tier.” Standard terms from reputable vendors often include adequate provisions for Tier 2 and Tier 3 relationships. Tier 1 relationships with third parties unwilling to negotiate security terms require explicit risk acceptance from senior leadership, documented with clear rationale.
Implementing partners present different dynamics than commercial vendors. Partnership agreements are inherently negotiated documents where security requirements integrate alongside programme deliverables, financial terms, and compliance obligations. Partners operating under the organisation’s donor agreements may be contractually required to meet security standards specified in donor terms.
Ongoing monitoring
Due diligence establishes security posture at relationship commencement; ongoing monitoring detects changes that alter risk profile during the relationship. Security postures degrade: staff turnover diminishes expertise, cost pressures reduce security investment, and evolving threats expose new vulnerabilities. Monitoring detects degradation before incidents occur.
Continuous monitoring mechanisms
Automated security rating services provide continuous visibility into externally-observable security indicators. Services such as BitSight, SecurityScorecard, and RiskRecon scan internet-facing infrastructure, certificate configurations, and data breach repositories to generate security scores. Rating changes trigger review: a vendor’s score dropping from 750 to 680 warrants investigation even without specific incident notification. Automated ratings supplement but do not replace direct assessment; they cannot detect internal security weaknesses invisible from external observation.
Periodic reassessment repeats due diligence activities at defined intervals. Tier 1 relationships undergo annual comprehensive reassessment, including questionnaire refresh and verification of independent assessment currency. Tier 2 relationships receive biennial reassessment unless material changes occur. Reassessment verifies that security representations from initial due diligence remain accurate and identifies new risks from operational changes.
Incident and breach monitoring tracks public disclosures affecting third parties. Data breach notification databases, security news sources, and sector-specific threat sharing provide visibility into third-party incidents. Monitoring services aggregate these sources; organisations without monitoring service subscriptions establish manual review processes using public breach notification sites and security news aggregators. Third-party incidents require assessment even when the organisation’s data was not directly affected: a breach reveals security weaknesses that may affect future incidents.
Contractual compliance verification exercises audit rights to confirm control implementation. Audit frequency scales with tier: Tier 1 relationships may receive annual audit exercises, while Tier 2 audits occur opportunistically or following concerning indicators. Audits need not be comprehensive to provide value; focused verification of critical controls (access management, encryption, backup testing) confirms continued compliance without enterprise audit scope.
Monitoring workflow
+------------------------------------------------------------------+| MONITORING LIFECYCLE |+------------------------------------------------------------------+| || +-------------------+ || | | || v | || +------------------------------------+| || | STEADY STATE || || | Automated rating monitoring || || | Periodic reassessment schedule || || | Breach notification watch || || +----------------+-------------------+| || | | || v | || +----------------+-------------------+| || | TRIGGER EVENT || || | - Rating score change > 50 pts || || | - Public breach disclosure || || | - Reassessment due date || || | - Material operational change || || | - Subprocessor notification || || +----------------+-------------------+| || | | || v | || +----------------+-------------------+| || | INVESTIGATION || || | Contact third party || || | Request incident details || || | Assess impact on org data || || | Review current controls || || +----------------+-------------------+| || | | || +---------+---------+ | || | | | || v v | || +------+-------+ +-------+------+ | || | No material | | Material | | || | impact | | concern | | || +------+-------+ +-------+------+ | || | | | || | v | || | +-------+------+ | || | | Remediation | | || | | or | | || | | Termination | | || | +-------+------+ | || | | | || +-------------------+ | || | | || +-------------------+ || |+------------------------------------------------------------------+Figure 4: Monitoring operates continuously with investigation triggered by defined events
Trigger events initiate active investigation. Triggers include security rating changes exceeding defined thresholds (50-point drop warrants investigation), public breach disclosures, scheduled reassessment dates, notification of material operational changes (acquisition, significant staff reduction, infrastructure migration), and subprocessor change notifications. Investigation confirms whether triggers indicate genuine risk changes requiring response.
Investigation outcomes range from no action (trigger was false positive or immaterial) to relationship termination (security posture no longer acceptable). Intermediate responses include requesting remediation with defined timeline, increasing monitoring intensity, reducing data sharing, or revising tier classification. Documentation of investigation and outcome supports demonstrable due diligence.
Subprocessor management
Third parties engaging additional entities to process organisational data create extended supply chains where risk propagates beyond direct relationships. The organisation’s due diligence assessed the direct third party; subprocessors may have materially different security postures. Subprocessor management extends visibility and control into these secondary relationships.
The subprocessor register maintains an inventory of known subprocessors for each third party. Contract provisions require third parties to disclose subprocessors and notify the organisation before engaging new ones. Registers capture subprocessor identity, processing location, data categories processed, and any available security certifications. For cloud services, subprocessor lists are commonly published on vendor websites and update dynamically; monitoring these pages detects changes between formal notifications.
Assessment delegation recognises that the organisation cannot directly assess every subprocessor. The approach relies on the direct third party’s due diligence of its suppliers, with the organisation verifying that adequate due diligence processes exist. For Tier 1 relationships, contract terms require the third party to apply equivalent security standards to subprocessors and permit the organisation to request evidence of subprocessor assessments.
Flow-down requirements ensure contractual protections extend to subprocessors. Data protection regulations require that processor contracts mandate equivalent protections in subprocessor agreements. Security requirements flow down through contract chains: the third party’s subprocessor agreement should include breach notification, audit rights, and data handling requirements equivalent to the primary contract.
Concentration risk arises when multiple third parties depend on common subprocessors. Cloud infrastructure providers (AWS, Azure, GCP) appear as subprocessors across numerous SaaS applications. A major incident at a hyperscale cloud provider could simultaneously affect multiple third parties. Subprocessor registers enable concentration analysis: identifying that seven critical applications depend on the same infrastructure provider reveals systemic risk invisible when examining relationships individually.
Third-party incident response
Security incidents affecting third parties require coordinated response that extends beyond the organisation’s direct systems. The incident may have occurred entirely within third-party infrastructure while affecting organisational data, requiring the organisation to depend on third-party investigation and remediation while meeting its own notification and response obligations.
Notification receipt triggers the response process. Contract provisions specify notification content requirements, but actual notifications frequently provide incomplete information during rapidly evolving incidents. Initial response focuses on confirming the notification’s authenticity (threat actors sometimes send fraudulent breach notifications) and establishing communication channels for updates.
Impact assessment determines what organisational data was affected, informing subsequent response decisions. Assessment requires information from the third party that may not be immediately available. Initial assessment uses available information to establish upper-bound impact: what data could have been affected based on the third party’s access, pending confirmation of actual impact. If the third party had access to 50,000 beneficiary records and the breach affected their entire database, 50,000 records is the upper-bound even if subsequent investigation reveals only 500 records were accessed.
Regulatory notification obligations may activate based on third-party incidents. Under GDPR, the organisation remains the data controller and must notify authorities within 72 hours of becoming aware of breaches likely to result in risk to individuals. The third-party notification starts the clock, even if investigation is ongoing. Notifications can be provided in phases: initial notification meeting the 72-hour deadline followed by supplementary information as investigation progresses.
Communication coordination prevents conflicting messages to affected individuals and stakeholders. The third party may issue its own communications; coordination ensures consistent information and avoids gaps where each party assumes the other is communicating. Contracts should address communication coordination, but incident-specific agreements are needed for significant breaches.
Post-incident review assesses whether the third-party relationship remains acceptable. Incidents reveal security weaknesses that due diligence did not detect. Review considers incident root cause, third-party response effectiveness, and required remediations. Serious incidents may trigger tier escalation, enhanced monitoring requirements, or relationship termination if security posture is fundamentally unacceptable.
Implementation considerations
For organisations with limited IT capacity
Third-party risk management appears resource-intensive, yet organisations with single IT staff or technology managed alongside other duties face significant third-party exposure. Practical implementation prioritises coverage of highest risks with minimal overhead.
Start with an inventory of existing third-party relationships. Most organisations underestimate their third-party footprint until they catalogue it: the payroll provider, email platform, document storage, project management tools, beneficiary databases, donor management systems, and numerous other relationships exist before formal third-party risk management begins. A simple spreadsheet capturing third-party name, data access, system integration, and contract renewal date provides the foundation for tiering.
Apply tiering ruthlessly. Only relationships with protection data, privileged access, or critical operational dependency belong in Tier 1. A typical organisation with 50-100 third-party relationships should have no more than 5-10 at Tier 1. Over-classification of Tier 1 creates assessment burden that overwhelms available capacity; under-classification leaves critical relationships inadequately assessed.
Use standardised questionnaires rather than custom assessments. The SIG Lite questionnaire (approximately 100 questions) provides adequate depth for Tier 2 relationships without enterprise questionnaire complexity. For Tier 1 relationships, request existing SOC 2 reports or ISO 27001 certificates rather than conducting primary assessment; reputable vendors have these documents available.
Focus ongoing monitoring on Tier 1 relationships. Security rating services offer free tiers or nonprofit pricing that enable basic monitoring. Manual monitoring of breach notification databases quarterly provides awareness of incidents affecting Tier 2 relationships without continuous monitoring overhead.
Contract review for existing relationships identifies security gaps without requiring renegotiation. Understanding what protections exist informs risk acceptance decisions; attempting to renegotiate every contract simultaneously is impractical.
For organisations with established IT functions
Organisations with dedicated IT or security staff can implement comprehensive third-party risk programmes. Scale the programme to the relationship portfolio: an organisation with 200 third-party relationships requires different processes than one with 50.
Centralise third-party inventory in a system that tracks relationships through their lifecycle. Purpose-built vendor risk management platforms (OneTrust, Prevalent, ServiceNow VRM) automate assessment workflows, track questionnaire responses, and aggregate monitoring data. For smaller portfolios, structured spreadsheets with defined fields and review workflows suffice.
Implement tiered assessment programmes with defined assessment instruments for each tier. Create organisational questionnaires that map to relevant regulatory requirements and can be completed electronically with evidence attachment. Establish assessment service relationships with firms that can conduct independent assessments of Tier 1 vendors when needed.
Integrate third-party risk into procurement processes so that security assessment occurs before contract commitment, not after. Procurement workflows should require security approval for relationships exceeding defined risk thresholds. Late-stage security objections waste procurement effort and create pressure to accept inadequate security postures to preserve deals already negotiated.
Develop response procedures for third-party incidents, coordinating with broader incident response capabilities. Third-party incidents differ from internal incidents in information availability and response authority; procedures should address these differences explicitly.
For organisations with federated structures
Federated organisations with autonomous country offices or regional entities face third-party risk across organisational boundaries. A country office’s vendor relationship may create risk exposure for the entire organisation through shared infrastructure or data flows.
Establish minimum standards that all entities must apply regardless of local procurement authority. Standards define tiering criteria, assessment requirements, and contract provisions that apply universally. Local adaptation addresses jurisdiction-specific requirements without reducing baseline protections.
Create visibility mechanisms so that central security functions can identify high-risk relationships across the federation. Periodic reporting of Tier 1 and Tier 2 relationships from all entities enables portfolio-wide risk assessment. Shared assessment repositories prevent duplicative evaluation when multiple entities engage the same third party.
Coordinate response for third-party incidents affecting multiple entities. A global SaaS provider breach may affect offices across multiple countries, each with different regulatory notification obligations. Central coordination ensures consistent response while respecting local regulatory requirements.
Technology options
Several categories of tools support third-party risk management processes.
Vendor risk management platforms centralise third-party inventories, automate assessment workflows, and aggregate monitoring data. Open source options are limited in this category; most implementations use commercial platforms.
| Platform | Deployment | Strengths | Considerations |
|---|---|---|---|
| OneTrust Vendorpedia | Cloud (SaaS) | Comprehensive feature set, strong assessment library | Enterprise pricing, complexity for small portfolios |
| Prevalent | Cloud (SaaS) | Strong monitoring integration, assessment services | Primarily US-focused support |
| ProcessUnity | Cloud (SaaS) | Flexible workflow configuration | Implementation complexity |
| ServiceNow VRM | Cloud (SaaS) | Integration with ITSM if ServiceNow deployed | Requires ServiceNow platform |
| RiskRecon | Cloud (SaaS) | Automated ratings focus | Limited assessment workflow |
For organisations unable to invest in dedicated platforms, structured spreadsheet implementations provide basic capability. Required fields include: third-party name, business owner, contract dates, tier classification, data categories accessed, system integration level, last assessment date, next assessment due, and assessment status.
Security rating services provide continuous monitoring of external security indicators.
| Service | Coverage | Nonprofit availability |
|---|---|---|
| BitSight | Comprehensive external rating | Inquire for nonprofit pricing |
| SecurityScorecard | External rating with breach monitoring | Free tier available |
| RiskRecon | External rating, subsidiary analysis | Inquire for nonprofit pricing |
| UpGuard | External rating, data leak detection | Limited free tier |
Rating services supplement rather than replace direct assessment. External ratings cannot detect internal security weaknesses, policy gaps, or operational deficiencies invisible from internet-facing infrastructure.
Appendix: Vendor security questionnaire template
This template provides a standardised questionnaire for Tier 2 third-party assessments. Adapt questions to organisational context and regulatory requirements. For Tier 1 assessments, supplement with additional questions on incident response, business continuity, and control monitoring.
SECTION 1: Organisation and governance
1.1 Provide organisation legal name and primary business address.
1.2 Describe the services to be provided to the Organisation and the data that will be processed.
1.3 Identify any subprocessors that will process Organisation data. For each, provide name, location, and processing activities.
1.4 Does your organisation maintain a formal information security programme with documented policies? If yes, provide the policy review date.
1.5 Do you maintain ISO 27001 certification, SOC 2 Type II report, or equivalent independent assessment? If yes, provide certificate/report date and scope.
1.6 Do you maintain cyber insurance? If yes, provide coverage limits.
SECTION 2: Access control
2.1 Describe how access to Organisation data is controlled, including authentication mechanisms.
2.2 Is multi-factor authentication required for all access to systems processing Organisation data?
2.3 Describe privileged access management controls for administrative access.
2.4 Describe the process for provisioning and deprovisioning access when staff join or leave.
2.5 How frequently are access rights reviewed and recertified?
SECTION 3: Data protection
3.1 Describe encryption controls for Organisation data at rest, including algorithm and key length.
3.2 Describe encryption controls for Organisation data in transit, including protocol versions.
3.3 Where is Organisation data stored? List all geographic locations.
3.4 Describe data backup procedures, including frequency, retention, and testing.
3.5 Describe data disposal procedures at contract termination.
SECTION 4: Security operations
4.1 Describe security monitoring capabilities, including logging and alerting.
4.2 Describe vulnerability management procedures, including scanning frequency and remediation timelines.
4.3 When was the most recent penetration test conducted? Provide executive summary if available.
4.4 Describe endpoint protection deployed on systems processing Organisation data.
SECTION 5: Incident management
5.1 Describe incident response procedures, including detection, containment, and recovery.
5.2 What is the notification timeline for security incidents affecting Organisation data?
5.3 Describe incident communication procedures.
5.4 Have you experienced security incidents affecting customer data in the past 24 months? If yes, provide summary details.
SECTION 6: Personnel security
6.1 Are background checks conducted on staff with access to Organisation data?
6.2 Describe security awareness training programme, including frequency.
6.3 Are confidentiality agreements required for staff with access to Organisation data?
SECTION 7: Physical security
7.1 Where are systems processing Organisation data physically located?
7.2 Describe physical access controls for these locations.
7.3 Are data centre locations certified to any standards (SOC 2, ISO 27001, etc.)?
SECTION 8: Business continuity
8.1 Describe business continuity and disaster recovery capabilities.
8.2 What is the target recovery time for services provided to Organisation?
8.3 When was the most recent disaster recovery test conducted?
SECTION 9: Compliance
9.1 List regulatory frameworks applicable to your processing of Organisation data (GDPR, HIPAA, etc.).
9.2 Have you received regulatory enforcement actions or fines related to data protection in the past 36 months?
SECTION 10: Attestation
I confirm that the responses provided are accurate and complete to the best of my knowledge.
Name: _________________________________
Title: _________________________________
Date: _________________________________
Signature: _________________________________