Skip to main content

assess-third-party-concentration-risk

Assess shared supplier dependencies, common-mode exposure, substitution limits, and exit feasibility. Use when apparently diverse vendors, services, regions, or contracts may fail through one hidden dependency.

来源信息

仓库
protosphinx/sphinxstack
最近来源活动
2026年7月29日 13:55
检测到的 SKILL.md 语言
英语
星标
2
分支
0

安装方式

默认使用会先检查来源的 Prompt;你也可以切换为直接命令,或下载本地副本。

检查来源文件

决定是否安装前,请先阅读 SKILL.md,以及 SkillsMP 当前展示的配套文件。

文件资源管理器
2 个文件

正在显示 SKILL.md

SKILL.md
来源说明 · 只读预览
name
assess-third-party-concentration-risk
category
data
description
Assess shared supplier dependencies, common-mode exposure, substitution limits, and exit feasibility. Use when apparently diverse vendors, services, regions, or contracts may fail through one hidden dependency.
# assess-third-party-concentration-risk ## When to use - Use for portfolio, platform, critical-service, or enterprise supplier concentration decisions. - Use ordinary vendor performance monitoring for one supplier without systemic dependency concerns. ## Preconditions - Confirm critical outcomes, assessment boundary, risk horizon, supplier-data authority, architecture and contract owners, continuity objectives, decision-maker, and confidentiality controls. ## Procedure 1. Build a dependency inventory of direct suppliers, subcontractors, platforms, regions, facilities, networks, identities, data stores, specialists, licenses, and financial dependencies. 2. Map supplier-to-service and service-to-outcome relationships with criticality, volume, replaceability, recovery objectives, contract dates, and evidence confidence. 3. Identify common-mode exposure across parent ownership, cloud, payment rail, logistics route, geography, technology, labor pool, key person, insurer, or regulatory permission. 4. Reconcile contract declarations with architecture, invoices, operational telemetry, incidents, and supplier assurance; retain unknown dependencies visibly. 5. Perform a substitutability test covering functional parity, capacity, interoperability, data portability, security, accessibility, approvals, skills, lead time, and total transition cost. 6. Test exit feasibility through notice rights, assistance, formats, deletion, licenses, source access, knowledge transfer, staffing, parallel run, acceptance, and independent rollback. 7. Stress simultaneous and cascading scenarios rather than treating every vendor failure as independent. 8. Quantify or rank exposure with transparent denominators, confidence, time-to-harm, minimum service, and decision thresholds. 9. Compare mitigation options such as diversification, redesign, inventory, capacity reservation, contractual rights, portability, manual service, and risk acceptance. 10. Assign actions, triggers, residual-risk authority, exercises, and evidence-based review cadence. ## Failure plan - Do not claim diversification from vendor count when suppliers share a parent, platform, route, region, or irreplaceable specialist. - Stop any live failover or data movement that lacks authorization, protected handling, acceptance checks, and rollback. - Preserve unknown subcontractors, untested alternatives, contract limits, and capacity gaps as open exposure rather than scoring them away. ## Done - A concentration map traces critical outcomes through direct and common-mode dependencies with confidence and ownership - A scenario stress test records time-to-harm, minimum service, cascade paths, substitution limits, and recovery decisions - Substitutability test and exit feasibility evidence cover capacity, data, integration, skill, contract, acceptance, and rollback - Mitigation verification proves reduced exposure, exercised alternatives, residual-risk approval, and monitored triggers
在 GitHub 查看