# Vendor Management Policy
**Document ID**: KD-POL-008
**Owner**: Chief Technology Officer
**Approved By**: CEO, Arivaran
**Effective Date**: 2026-03-19
**Next Review Date**: 2027-03-19 (recomputed 2026-10-02 on the stated semi-annual cycle from the Effective Date; the 2026-09-19 occurrence was not recorded, and this date does not assert that a review has taken place)
**Review Cycle**: Semi-annual
**Classification**: Internal
## 1. Purpose
This policy defines how Arivaran evaluates, onboards, monitors, and offboards third-party vendors and sub-processors that support KuiperDesk operations. As a data processor for our customers, Arivaran is responsible under GDPR Article 28 for ensuring that sub-processors provide sufficient guarantees for data protection. Vendor risk directly translates to KuiperDesk risk.
## 2. Scope
This policy covers all third parties that:
- Host or process KuiperDesk customer data (sub-processors)
- Provide infrastructure on which KuiperDesk runs
- Supply software components deployed in the KuiperDesk production environment
- Have access to KuiperDesk systems or data for support purposes
## 3. Current Vendor Inventory
| Vendor | Category | Data Access | Criticality | DPA Status |
|--------|----------|-------------|-------------|------------|
| **OVH** | IaaS (VPS hosting) | Physical access to servers hosting encrypted data | Critical | DPA in place (EU standard) |
| **Cloudflare** | DNS, CDN, Tunnel | DNS records, HTTP metadata (no backup data) | High | DPA in place |
| **PgEdge / CNPG** | OSS vendors (PgEdge + CloudNativePG) | None (self-hosted, images pulled from registry) | Medium | N/A (OSS, no data access) |
| **SeaweedFS** | OSS vendor | None (self-hosted) | Medium | N/A (OSS) |
| **Keycloak / Red Hat** | OSS vendor | None (self-hosted) | Medium | N/A (OSS) |
| **GitHub** | Git mirror, CI/CD secondary | Source code mirror (no customer data) | Low | DPA in place |
| **GoDaddy** | Domain registrar | Domain registration data | Low | Standard terms |
| **AWS** | CloudHSM (historical) | HSM key material (terminated, backed up) | Low (historical) | DPA in place |
| **Kamatera** | VPS (SMTP relay) | Email metadata only (no backup data) | Low | Standard terms |
## 4. Policy Statements
### 4.1 Vendor Risk Assessment
4.1.1. Before onboarding a new vendor that will process customer data or host KuiperDesk infrastructure, a vendor risk assessment is conducted. The assessment evaluates:
- **Data handling**: What customer data does the vendor access? In what jurisdiction? Is data encrypted in transit and at rest?
- **Security posture**: Does the vendor hold SOC 2, ISO 27001, or equivalent certifications? When were they last audited?
- **Contractual protections**: Does the vendor offer a DPA? What are the breach notification terms? What are the liability provisions?
- **Business continuity**: What is the vendor's SLA? What happens if the vendor ceases operations? Can we migrate away within a reasonable timeframe?
- **Supply chain**: For software vendors, how are images built and distributed? Is there a signed release process?
4.1.2. Vendor risk is scored using the same Likelihood x Impact framework as KD-POL-006 (Risk Management Policy). The assessment is documented in the risk register with a `vendor-risk` tag.
4.1.3. Vendors are classified by criticality:
| Criticality | Definition | Assessment Depth |
|-------------|-----------|-----------------|
| Critical | KuiperDesk cannot operate without this vendor. Data is hosted on vendor infrastructure. | Full assessment, annual audit review, DPA required |
| High | Significant operational dependency. Metadata or limited data exposure. | Standard assessment, annual review, DPA required if data processed |
| Medium | Software dependency, self-hosted. No vendor data access. | Lightweight assessment focused on supply chain risk |
| Low | Peripheral service, easily replaceable. | Documented in inventory, reviewed annually |
### 4.2 Sub-Processor Requirements (GDPR Article 28)
4.2.1. Sub-processors (vendors that process personal data on behalf of Arivaran's customers) must have a Data Processing Agreement (DPA) that includes:
- Processing only on documented instructions from Arivaran
- Confidentiality obligations for vendor personnel
- Appropriate technical and organizational security measures
- Sub-sub-processor restrictions (prior authorization or general authorization with notification)
- Assistance with data subject rights requests
- Deletion or return of data upon contract termination
- Audit rights (right to inspect or commission audits)
- Breach notification within 72 hours
4.2.2. The current sub-processor list is published to customers and updated when sub-processors change. Customers are notified at least 30 days before a new sub-processor begins processing their data. Customers may object to a new sub-processor; objections are handled per the customer agreement.
4.2.3. For KuiperDesk's current architecture, OVH is the only sub-processor that hosts customer backup data (encrypted, on OVH VPS NVMe storage). Cloudflare proxies HTTP traffic but does not store backup data.
### 4.3 Open Source Software (OSS) Vendors
4.3.1. OSS components (PgEdge, CNPG, SeaweedFS, Keycloak, RKE2, Cilium, cert-manager) are self-hosted and self-operated. The vendor risk for OSS is supply chain risk, not data access risk.
4.3.2. OSS supply chain controls:
- Container images are pulled through Harbor proxy cache, not directly from public registries in production
- Images are scanned with Trivy before deployment (see KD-POL-007)
- Critical OSS components are pinned to specific versions/digests
- cosign signature verification is enforced where the upstream project supports it (Keycloak, cert-manager, Cilium)
- GitHub Security Advisories and project-specific mailing lists are monitored for vulnerability disclosures
4.3.3. For OSS projects that do not provide signed images, Arivaran builds images from source using the CI/CD pipeline and signs them with the Arivaran cosign key before pushing to Harbor.
### 4.4 Vendor Monitoring and Review
4.4.1. **Annual Review**: All Critical and High vendors undergo annual review. The review includes:
- Updated risk assessment
- Review of vendor's latest SOC 2 report or ISO 27001 certificate
- Review of any vendor security incidents disclosed during the year
- DPA renewal or update if terms have changed
- Assessment of vendor lock-in risk and exit feasibility
4.4.2. **Continuous Monitoring**: For Critical vendors (OVH):
- Subscribe to vendor status page and security advisories
- Monitor vendor SLA performance against contracted targets
- Track vendor's public security disclosures and incident history
4.4.3. **Trigger-Based Review**: Vendor risk is reassessed immediately when:
- The vendor discloses a security breach
- The vendor changes ownership or undergoes significant organizational change
- Arivaran's use of the vendor changes (e.g., new data flows, new regions)
- Regulatory changes affect the vendor relationship (e.g., Schrems II implications)
### 4.5 Vendor Offboarding
4.5.1. When a vendor relationship is terminated:
- Confirm deletion or return of all Arivaran/customer data per the DPA
- Revoke all vendor access to Arivaran systems (API keys, credentials, network access)
- Update the sub-processor list and notify customers if the vendor was a sub-processor
- Document the offboarding in the vendor inventory with date and reason
4.5.2. Migration plans for Critical vendors are maintained as part of the business continuity plan (KD-POL-005). The plan documents estimated migration effort, alternative vendors evaluated, and data portability mechanisms.
### 4.6 Vendor Concentration Risk
4.6.1. Arivaran acknowledges that OVH represents a single-provider concentration risk for compute and storage. This is documented in the risk register (see KD-POL-006) with the following mitigations:
- HA hub pair across two OVH DCs (Milan + Oregon) with PgEdge multi-master and k8gb failover
- Infrastructure-as-code enables re-deployment to an alternative provider
- No proprietary OVH services used (standard VPS with Linux)
## 5. Roles and Responsibilities
| Role | Responsibility |
|------|---------------|
| CTO | Approve new vendor onboarding. Conduct vendor risk assessments. Negotiate DPAs. |
| CEO | Approve Critical vendor contracts. Authorize sub-processor list changes. |
| Infrastructure Engineers | Monitor vendor status pages. Report vendor incidents. Execute vendor offboarding procedures. |
## 6. Compliance Mapping
| Policy Statement | SOC 2 Criteria | ISO 27001:2022 | GDPR |
|-----------------|----------------|----------------|------|
| 4.1 Vendor Risk Assessment | CC9.1 | A.5.19, A.5.20 | Art. 28(1) |
| 4.2 Sub-Processor Requirements | CC9.2 | A.5.21, A.5.22 | Art. 28(2)-(4) |
| 4.3 OSS Supply Chain | CC9.1 | A.5.23 | — |
| 4.4 Vendor Monitoring | CC9.2 | A.5.22 | Art. 28(3)(h) |
| 4.5 Vendor Offboarding | CC9.2 | A.5.20 | Art. 28(3)(g) |
## 7. Exceptions
Exceptions to DPA requirements are permitted only for vendors classified as Low criticality with no customer data access. All exceptions are documented in the vendor inventory.
## 8. Enforcement
Onboarding a vendor without a completed risk assessment is a policy violation. Using an unvetted container image in production is a change management violation (KD-POL-007).
## 9. Revision History
| Version | Date | Author | Changes |
|---------|------|--------|---------|
| 1.0 | 2026-03-19 | CTO | Initial release |