This plan defines how Project Catalyst selects, governs, monitors, and — when necessary — replaces external vendors. The program relies on three categories of vendors: hyperscaler cloud providers, LLM/AI model providers, and SaaS tooling vendors. Each category carries different risk profiles and requires different governance intensity. Owned by L. Park (Vendor Manager, Pulaski) with oversight from D. Chen (EARB) for technical vendors and R. Thorne (General Counsel) for contract governance.
Table of Contents
1. Vendor Landscape & Categories
| Category | Examples | Budget Allocation | Risk Level | Governance Intensity |
|---|---|---|---|---|
| Hyperscaler Cloud Provider(s) | AWS, GCP, Azure | $26.9M (cloud & AI platform infrastructure) | High — platform dependency, cost volatility, data residency | Monthly performance reviews; quarterly cost optimization; annual contract review |
| LLM / AI Model Provider(s) | OpenAI, Anthropic, or comparable | Included in cloud allocation (inference costs) + potential licensing | High — model quality dependency, pricing volatility, API stability, BAA requirement for PHI-adjacent workloads | Monthly performance reviews; quarterly model evaluation; vendor contingency plan maintained |
| SaaS Tooling Vendors | Governance platforms, compliance monitoring, test automation, MLOps tooling, observability | $1.9M (tooling budget) | Medium — operational dependency but individually replaceable | Quarterly reviews; annual license renewal assessment |
1.1 Multi-Cloud Strategy Context
Per Change Control CN-003, Project Catalyst adopted a multi-cloud architecture to reduce single-vendor concentration risk and enable competitive pricing. The practical implementation: a primary hyperscaler is selected for default workloads (compute, storage, managed services); secondary providers are qualified for specific workloads where they offer cost or capability advantages (e.g., GPU pricing for model training, specialized AI/ML services). Workloads can be migrated between providers within 4 weeks if needed (vendor contingency plan, Section 8).
2. Vendor Selection Criteria
All vendor selections are evaluated against a weighted scoring framework. Criteria and weights are set during Phase 0 and approved by the EARB before any vendor evaluation begins.
| Criterion | Weight | What We Evaluate |
|---|---|---|
| Healthcare Compliance Readiness | 25% | HIPAA compliance posture, BAA willingness and terms, SOC 2 Type II certification, HITRUST certification (preferred), data residency controls (US-only for PHI) |
| Technical Fit | 25% | Service capabilities matching program requirements, API maturity and stability, integration with existing ACME systems, scalability to production volumes |
| Cost & Commercial Terms | 20% | Total cost of ownership (not just list price), pricing model transparency, volume discount availability, contract flexibility (term, exit clauses) |
| Operational Reliability | 15% | Historical uptime (target: 99.9%+ for critical services), incident response SLAs, support tier availability (24/7 for critical), documented disaster recovery |
| AI/ML Capability Depth | 10% | Managed AI/ML services, GPU availability and pricing, model hosting capabilities, MLOps integration, vector database services (for RAG) |
| Strategic Viability | 5% | Financial stability, market position, investment trajectory, risk of acquisition or discontinuation during 36.5-month program |
3. Contract & BAA Requirements
3.1 Business Associate Agreements (BAA)
Non-Negotiable: Every vendor that processes, stores, transmits, or has access to Protected Health Information (PHI) must execute a Business Associate Agreement with ACME before any PHI flows through their systems. No exceptions. No "we'll get to it later." BAA status is tracked by S. Patel (Vendor Contract Specialist, Legal) and verified by E. Sato (CPO) before any vendor environment is provisioned for PHI workloads.
- BAA must include: permitted uses of PHI, safeguards requirements, breach notification obligations (within 60 days per HIPAA), subcontractor flow-down requirements, and termination provisions for material breach.
- Vendors that refuse to sign a BAA or propose materially weaker terms than ACME's standard BAA template are disqualified — there is no "risk-accepted" path for BAA non-compliance.
3.2 Standard Contract Provisions
- Data ownership: ACME retains ownership of all data processed by the vendor. Vendor has no rights to use ACME data for model training, benchmarking, or any purpose beyond the contracted service.
- Data residency: PHI data must reside exclusively in US-based data centers. Vendors must certify data residency compliance and permit ACME audit of data location.
- Audit rights: ACME has the right to audit vendor compliance with security, privacy, and contractual obligations. Audit may be conducted by ACME's internal audit team or a designated third party.
- Termination for convenience: ACME may terminate with 90-day notice. Vendor must provide data export assistance and transition support during the termination period.
- IP ownership: Models developed using ACME data are ACME intellectual property. Vendor retains IP in their pre-existing platform and tools. Custom configurations and integrations built for ACME are joint IP with ACME having perpetual license.
- Liability & indemnification: Vendor indemnifies ACME for breaches of data security, privacy violations, and IP infringement originating from vendor systems or personnel.
4. Procurement Authority & Thresholds
| Contract Value | Approval Authority | Required Reviews |
|---|---|---|
| < $50,000 | Program Director (C. Tyrrell) | Vendor Manager review |
| $50,000 – $500,000 | Program Director + CFO (S. Williams) | Vendor Manager + Legal review |
| $500,000 – $2,000,000 | Executive Steering Board | Vendor Manager + Legal + EARB review |
| > $2,000,000 | Executive Sponsor + CFO + Legal | Full vendor evaluation scorecard; EARB technical approval; Audit Committee notification |
5. Vendor Performance Management
5.1 Performance Review Cadence
| Vendor Category | Review Frequency | Review Owner | Escalation Path |
|---|---|---|---|
| Hyperscaler Cloud Provider | Monthly | L. Park + W. Kumar | Program Director → EARB → ESB |
| LLM / AI Model Provider | Monthly | L. Park + S. Khurana | Program Director → AI Gov Board → ESB |
| SaaS Tooling Vendors | Quarterly | L. Park | Program Director → EARB |
5.2 Performance Scorecard
Each vendor is scored monthly (hyperscaler/LLM) or quarterly (SaaS) across five dimensions:
| Dimension | Weight | Green | Yellow | Red |
|---|---|---|---|---|
| Uptime / Availability | 30% | ≥ 99.9% | 99.5% – 99.8% | < 99.5% |
| Support Responsiveness | 20% | Within SLA for all tickets | 1–2 SLA breaches/month | 3+ SLA breaches/month |
| Cost vs. Forecast | 20% | Within ±5% of forecast | ±5–15% of forecast | > ±15% of forecast |
| Technical Quality | 20% | No quality incidents | 1 minor quality incident | Major quality incident or regression |
| Contract Compliance | 10% | Full compliance | Minor non-compliance (remediated) | Material non-compliance |
A vendor scoring Red on any dimension for 2 consecutive review periods triggers an escalation meeting with the vendor's account executive and ACME's Program Director. A vendor scoring Red for 3 consecutive periods triggers a vendor replacement assessment.
6. SLA Framework & Monitoring
6.1 Minimum SLA Requirements (All Vendors)
| SLA Metric | Target | Measurement |
|---|---|---|
| Service Availability | ≥ 99.9% (monthly) | Vendor-reported + ACME-monitored |
| Incident Response (Critical) | ≤ 15 minutes acknowledgment; ≤ 4 hours resolution | Ticket system timestamps |
| Incident Response (High) | ≤ 1 hour acknowledgment; ≤ 8 hours resolution | Ticket system timestamps |
| Data Backup / Recovery | RPO ≤ 1 hour; RTO ≤ 4 hours | Quarterly DR test results |
| Security Patch Application | Critical patches within 24 hours; High within 72 hours | Patch management reports |
6.2 SLA Monitoring
- ACME deploys independent monitoring (synthetic transactions, uptime checks) in addition to vendor-provided monitoring. ACME's monitoring is the source of truth for SLA compliance disputes.
- SLA breaches are logged in a vendor incident tracker maintained by L. Park. Monthly SLA compliance report delivered to Program Director as part of the vendor performance review.
- Financial SLA credits (where contractually available) are tracked and applied by Program Finance (A. Rodriguez). Credits offset future invoices — they do not substitute for vendor performance improvement.
7. Vendor Risk Management
7.1 Vendor Risk Categories
- Concentration risk: Over-reliance on a single vendor for critical capabilities. Mitigated by multi-cloud architecture (CN-003) and LLM vendor contingency plan (Section 8). Monitored quarterly.
- Pricing risk: Vendor changes pricing models, imposes usage caps, or increases rates beyond budget forecasts. Mitigated by multi-year committed pricing where available, FinOps monitoring (W. Kumar), and budget contingency. Related to RAIDD R-02.
- Data risk: Vendor data breach, unauthorized data use, or data residency violation. Mitigated by BAA requirements (Section 3.1), contractual data ownership provisions, and quarterly data residency verification.
- Continuity risk: Vendor discontinues service, is acquired, or exits the market. Mitigated by vendor contingency plans (Section 8), data portability requirements in contracts, and multi-cloud architecture.
- Compliance risk: Vendor's compliance posture degrades (SOC 2 lapse, HITRUST non-renewal, security incident at vendor). Mitigated by annual compliance verification and contract provisions allowing termination for compliance failure.
7.2 LLM Provider-Specific Risks
The LLM vendor relationship carries unique risks: API terms may change (rate limits, content policies, pricing), model quality may degrade between versions, and the vendor may deprecate models the program depends on. These risks are distinct from traditional SaaS vendor risks because the program cannot easily replicate the vendor's model — switching LLM providers requires re-tuning, re-validation, and potentially re-architecture. The vendor contingency plan (Section 8) addresses this with a documented alternative provider and estimated switching timeline.
8. Vendor Contingency Planning
8.1 Contingency Plan Requirements
Every vendor classified as "High" risk (hyperscaler cloud, LLM provider) must have a documented contingency plan maintained by L. Park and reviewed quarterly. The plan includes:
- Alternative vendor identification: Named alternative provider(s) that could replace the primary vendor's capability.
- Switching cost estimate: Engineering effort, data migration cost, re-validation cost, and timeline to complete migration.
- Trigger criteria: Specific events that would activate the contingency plan (vendor bankruptcy, service discontinuation announcement, material SLA breach sustained for 30+ days, pricing increase > 30%).
- Migration runbook: Step-by-step technical migration procedure, tested annually (or whenever the contingency plan is updated).
8.2 Current Contingency Plans
| Vendor Category | Primary | Contingency | Estimated Switch Timeline | Estimated Switch Cost |
|---|---|---|---|---|
| Hyperscaler Cloud | Primary vendor (selected Phase 0) | Secondary qualified vendor (multi-cloud) | 2–4 weeks per workload | $200K–$500K engineering effort |
| LLM / AI Model | Primary LLM provider | Alternative LLM provider (pre-evaluated) | 4–8 weeks (includes re-tuning + re-validation) | $300K–$800K (engineering + validation) |
| SaaS Tooling | Per-tool vendor | Alternative tool identified per category | 2–6 weeks | $50K–$150K per tool |
9. Vendor Relationship Governance
9.1 Vendor Manager Role
L. Park (Vendor Manager, Pulaski) is the single point of contact for all vendor relationships. Responsibilities:
- Day-to-day vendor communication and issue resolution
- Monthly performance reviews and scorecard maintenance
- Contract administration (renewals, amendments, terminations) in coordination with Legal
- Cost tracking and FinOps coordination with W. Kumar (Platform Lead) and A. Rodriguez (Program Finance)
- Contingency plan maintenance (quarterly review and update)
- Escalation to Program Director for vendor issues that cannot be resolved at working level
9.2 Vendor Governance Meetings
| Meeting | Frequency | Attendees | Purpose |
|---|---|---|---|
| Vendor Operational Sync | Weekly (per hyperscaler/LLM vendor) | L. Park + vendor TAM | Tactical: open tickets, upcoming changes, capacity planning |
| Vendor Performance Review | Monthly | L. Park + W. Kumar + vendor account exec | Strategic: scorecard review, SLA compliance, cost forecast, roadmap alignment |
| Vendor Quarterly Business Review | Quarterly | L. Park + C. Tyrrell + D. Chen + vendor leadership | Executive: relationship health, contract performance, strategic alignment, upcoming needs |
| Annual Contract Review | Annually | L. Park + R. Thorne (Legal) + S. Williams (CFO) | Contract renewal assessment: pricing, terms, alternatives, continue/renegotiate/replace decision |
9.3 Vendor Information Security Requirements
- All vendors with access to ACME systems or data must complete ACME's Vendor Security Assessment Questionnaire (VSAQ) before contract execution and annually thereafter.
- Vendors must maintain current SOC 2 Type II certification and provide the report to ACME annually. HITRUST certification is preferred for healthcare-focused vendors.
- Vendors must notify ACME within 24 hours of any security incident that could affect ACME data or systems, per BAA breach notification requirements.
- CISO (M. Hassan) has the authority to suspend vendor access to ACME systems if a security concern is identified, pending investigation. This authority is exercised independently of the vendor relationship — security overrides commercial considerations.
10. Document Control
| Field | Value |
|---|---|
| Document Title | Vendor & SaaS Management Plan |
| Version | 1.0 |
| Date | 17 August 2026 |
| Owner | L. Park (Vendor Manager, Pulaski Advisory Group) |
| Approved By | C. Tyrrell (Program Director), D. Chen (EARB Chair), R. Thorne (General Counsel) |