Vendor Management Policy

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

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:

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

6. Compliance Mapping

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