# Vendor & Third-Party Risk Management Policy

**Document owner:** [Owner/Role]  
**Approved by:** [Steering Committee / CISO]  
**Effective date:** [YYYY-MM-DD]  
**Review cadence:** [Annually]

---

## 1. Purpose & Scope
This policy establishes mandatory requirements for assessing, onboarding, monitoring, and offboarding third parties (vendors, suppliers, MSPs, SaaS providers) that access [Organization] systems or data. It applies to all business units engaging third parties, and to Third-party/Vendor accounts defined in [Authentication Policy §3](authentication_policy.md).

---

## 2. Roles & Responsibilities
- **Vendor Owner (business sponsor):** Accountable for the relationship, ensures due diligence is completed before onboarding, tracks reassessment dates.  
- **Security/CISO:** Defines tiering criteria, reviews due diligence evidence, approves exceptions.  
- **Procurement/Legal:** Ensures contractual requirements (§3.3) are included before signature.

---

## 3. Policy Statements

### 3.1 Vendor Tiering
Every vendor **must** be tiered at onboarding, based on the highest TLP level of data accessed (per [Data Classification Policy](data_classification_policy.md)) and business criticality:

| Tier | Criteria | Example |
|---|---|---|
| **Critical** | Accesses TLP:AMBER+STRICT/RED data, or is a single point of failure for a revenue-critical or kill-chain function (per [Authentication Policy §2.1](authentication_policy.md)) | Cloud IdP, payroll processor, core SaaS platform |
| **High** | Accesses TLP:AMBER data, or supports a significant business function | CRM vendor, MSP with standing admin access |
| **Medium** | Accesses TLP:GREEN data or limited system access | Marketing tools, non-privileged SaaS |
| **Low** | Accesses only TLP:CLEAR data, no system access | Public-facing content vendors |

### 3.2 Due Diligence Requirements

| Tier | Required Before Onboarding |
|---|---|
| Critical | Security questionnaire; current SOC 2 Type II or ISO 27001 certificate; penetration test summary (last 12 months); cyber insurance evidence; documented exit/migration plan |
| High | Security questionnaire; SOC 2/ISO 27001 or equivalent attestation |
| Medium | Security questionnaire (lightweight) |
| Low | None required beyond standard procurement terms |

### 3.3 Contractual Requirements
For **Critical** and **High** tier vendors, contracts **must** include:
- Data protection / processing terms (GDPR Art. 28 or equivalent where applicable).  
- Breach notification **within 72 hours** of vendor becoming aware.  
- Right-to-audit or right to receive independent audit reports.  
- **Data export and exit clauses** as primary terms — format, timeline (≤30 days from request), and any de-provisioning assistance. Absence of an exit clause is a contract blocker for Critical tier.  
- No unilateral change to data residency or subprocessors without notice.

### 3.4 Ongoing Monitoring & Reassessment
- **Critical:** Reassessed annually; SOC 2/ISO certificate currency checked continuously (expiry alert).  
- **High:** Reassessed every 18 months.  
- **Medium/Low:** Reassessed at renewal or every 3 years, whichever is sooner.  
- Any material vendor incident (breach, outage >4h, ownership change) triggers an out-of-cycle reassessment.

### 3.5 Concentration Risk / Single-Vendor Dependency
- Vendor Owners **must** flag any Critical-tier vendor for which no viable alternative or fallback exists.  
- For each flagged dependency, a documented exit/migration path **must** exist and be executable within **90 days** (aligned with [Authentication Policy §2.11](authentication_policy.md)).  
- Concentration risk **must** be reviewed at least annually as part of the kill-chain mapping exercise.

### 3.6 Offboarding
- On contract termination, vendor access **must** be revoked within **24 hours**.  
- Data return or certified destruction **must** be confirmed in writing within the contractual exit window.  
- Any shared credentials, API keys, or federated trust relationships **must** be rotated or removed.

### 3.7 Vendor-Involved Incidents
- Vendor-caused or vendor-affecting incidents **must** be handled per the incident-driven structural learning process in [Authentication Policy §2.12](authentication_policy.md) — a structural change (contract amendment, control, or vendor replacement) is required within 30 days of root cause confirmation.

### 3.8 Enforcement
- Onboarding without completed due diligence **must not** proceed. Exceptions require documented CISO approval with compensating controls and a review date ≤ 6 months out.

---

## 4. Antifragility Alignment
This policy is built to the five pillars of the organization's internal **Antifragile Enterprise Manifest**.

| Pillar | Applied In | How |
|---|---|---|
| **1. Structural Decoupling** | §3.5 | Concentration-risk flagging forces mapping of hidden single points of failure; 90-day exit path required for each |
| **2. Optionality Preservation** | §3.3 | Data export/exit clauses are primary contract terms, not afterthoughts — preserves the right to leave |
| **3. Stress-to-Signal Conversion** | §3.7 | Vendor incidents force a structural change within 30 days, not just a post-mortem doc nobody reads |
| **4. Sovereign Intelligence** | §2 | Named Vendor Owner per relationship; due diligence evidence retained and owned, not scattered across inboxes |
| **5. Asymmetric Payoff Design (Barbell)** | §3.1–§3.2 | Heavy diligence and contractual rigor concentrated on Critical tier; Low tier gets minimal friction — no moderate process applied uniformly |

---

## 5. References
- **[NIST SP 800-161 Rev. 1, Cybersecurity Supply Chain Risk Management](https://csrc.nist.gov/pubs/sp/800/161/r1/final)**  
- **[ISO/IEC 27001:2022](https://www.iso.org/standard/27001)**  
- **[ENISA Digital Identity and Data Protection](https://www.enisa.europa.eu/topics/digital-identity-and-data-protection)**