92 lines
5.8 KiB
Markdown
92 lines
5.8 KiB
Markdown
# 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)**
|