Compliance · Arivaran

Risk Management Policy

Document ID: KD-POL-006
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 identifies, assesses, treats, and monitors information security risks to KuiperDesk. Risk management is the mechanism that connects business objectives to security controls. Without a structured risk process, controls are either excessive (wasting resources) or insufficient (creating blind spots). This policy ensures that every security investment is traceable to a specific risk and that residual risks are explicitly accepted, not ignored.

2. Scope

This policy covers information security risks to:

KuiperDesk platform services and infrastructure
Customer data processed, stored, and transmitted by KuiperDesk
Arivaran's ability to deliver backup and restore services per contractual SLAs
Supply chain dependencies and third-party services
Regulatory compliance obligations (GDPR, SOC 2, ISO 27001)

3. Policy Statements

3.1 Risk Assessment Methodology

3.1.1. Arivaran uses a semi-quantitative risk assessment methodology. Risks are scored on two dimensions: likelihood and impact, each on a 1-5 scale.

Likelihood Scale:

Score	Label	Definition
1	Rare	Less than once per 5 years, or requires nation-state capability
2	Unlikely	Once per 1-5 years, requires significant attacker skill
3	Possible	Once per year, exploitable by a motivated attacker
4	Likely	Multiple times per year, common attack vector
5	Almost Certain	Expected to occur, or has already occurred

Impact Scale:

Score	Label	Definition
1	Negligible	No customer impact, internal inconvenience only
2	Minor	Single-tenant degraded service, no data loss, resolved within RTO
3	Moderate	Multi-tenant service disruption, or minor data exposure, regulatory notification not required
4	Major	Data breach affecting multiple tenants, regulatory notification required, customer trust damaged
5	Critical	Complete platform compromise, widespread data loss/exposure, existential business risk

3.1.2. Risk Score: Likelihood x Impact. Risk levels:

Score Range	Level	Treatment Requirement
1-4	Low	Accept or monitor. Document rationale.
5-9	Medium	Treat within 90 days or formally accept with compensating controls.
10-15	High	Treat within 30 days. CTO approval required for acceptance.
16-25	Critical	Treat immediately. CEO approval required for acceptance. Cannot be accepted for more than 30 days.

3.2 Risk Identification

3.2.1. Risk identification sources:

Threat modeling: Conducted for each major system component (aaagent, aaHashSvc, aaTwinSvc, aaDash) and for infrastructure (RKE2 cluster, PKI chain, network overlay). Updated when architecture changes.
Vulnerability scanning: Trivy container scans (CI/CD + weekly), OS vulnerability feeds (AlmaLinux OVAL), dependency audits (vcpkg audit for C++ services, npm audit for aaDash).
Incident post-mortems: Every P1-P3 incident generates risk register entries for identified root causes and systemic weaknesses.
Audit findings: Internal and external audit findings are mapped to risk register entries.
Industry intelligence: CVE feeds for deployed components (PgEdge, CNPG, Keycloak, SeaweedFS, RKE2, Cilium).
Regulatory changes: GDPR guidance updates, SOC 2 criteria revisions, ISO 27001 amendment tracking.

3.2.2. Any Arivaran team member may submit a risk for assessment by creating a Forgejo issue with the risk label.

3.3 Risk Register

3.3.1. The risk register is the authoritative inventory of all identified risks. It is maintained as a structured document in the Forgejo repository and reviewed quarterly.

3.3.2. Each risk register entry contains:

Risk ID: RISK-NNN
Title: [Short description]
Description: [Detailed description of the threat scenario]
Affected Assets: [Systems, data, or processes at risk]
Threat Source: [External attacker, insider, natural disaster, vendor, etc.]
Likelihood: [1-5 with justification]
Impact: [1-5 with justification]
Inherent Risk Score: [L x I]
Current Controls: [Existing controls that mitigate this risk]
Residual Likelihood: [1-5 after current controls]
Residual Impact: [1-5 after current controls]
Residual Risk Score: [L x I]
Treatment Decision: [Treat / Accept / Transfer / Avoid]
Treatment Plan: [If Treat: specific actions, owner, deadline]
Risk Owner: [Person accountable]
Last Reviewed: [Date]

3.3.3. The risk register shall contain, at minimum, risks covering:

Supply chain compromise of container images (PgEdge, CNPG, Keycloak, SeaweedFS)
Customer data exfiltration via compromised agent certificate
RKE2 cluster compromise via container escape
Single point of failure in SeaweedFS (001 replication)
OVH provider failure (all infrastructure on one provider)
PKI chain compromise (OpenBao intermediate CA key leak)
Insider threat (small team, broad access)
GDPR enforcement action due to data handling non-compliance

3.4 Risk Treatment

3.4.1. Treat: Implement additional controls to reduce likelihood or impact. Treatment plans must specify: the control to implement, the responsible person, the deadline, and how effectiveness will be measured.

3.4.2. Accept: Formally acknowledge the residual risk without additional controls. Acceptance requires documented justification and approval at the appropriate level (see 3.1.2). Accepted risks are re-evaluated at each quarterly review.

3.4.3. Transfer: Shift the financial impact to a third party (e.g., cyber insurance). The underlying risk still requires monitoring; only the financial consequence is transferred.

3.4.4. Avoid: Eliminate the risk by removing the activity or asset. Example: not storing customer PII beyond what is required for service delivery.

3.5 Risk Review Cadence

3.5.1. Quarterly Risk Review: The CTO conducts a formal review of the full risk register quarterly. The review assesses:

Whether risk scores remain accurate given current threat intelligence
Whether treatment plans are on track
Whether accepted risks are still within tolerance
New risks identified since the last review

3.5.2. Event-Driven Review: The risk register is updated immediately when:

A P1 or P2 incident occurs
A critical vulnerability is disclosed in a deployed component
Infrastructure architecture changes materially (e.g., new storage backend, new cloud provider)
A new regulatory requirement affects KuiperDesk

3.5.3. Annual Comprehensive Assessment: Once per year, a full risk assessment is conducted, including updated threat modeling for all major components. This assessment produces an updated Statement of Applicability (ISO 27001) and feeds into the SOC 2 risk assessment narrative.

3.6 Risk Appetite

3.6.1. Arivaran's risk appetite for KuiperDesk:

Zero tolerance: Customer data confidentiality breaches, PKI chain compromise, insider data theft
Low tolerance: Service availability below SLA commitments, regulatory non-compliance
Moderate tolerance: Operational inefficiency, technical debt, non-critical system outages
Accepted: Business risks inherent to a startup operating with a small team (e.g., key person dependency)

3.6.2. The risk appetite is reviewed annually by the CEO and CTO and communicated to all personnel.

4. Roles and Responsibilities

Role	Responsibility
CEO	Define risk appetite. Approve Critical risk acceptance. Allocate resources for risk treatment.
CTO	Own the risk register. Chair quarterly risk reviews. Approve High risk acceptance. Conduct threat modeling.
Infrastructure Engineers	Identify technical risks. Implement treatment plans. Report risk events.
All Personnel	Report identified risks and near-misses.

5. Compliance Mapping

Policy Statement	SOC 2 Criteria	ISO 27001:2022
3.1 Assessment Methodology	CC3.1	Clause 6.1.2
3.2 Risk Identification	CC3.2	Clause 6.1.2
3.3 Risk Register	CC3.2, CC3.3	Clause 6.1.2, 6.1.3
3.4 Risk Treatment	CC3.4	Clause 6.1.3
3.5 Review Cadence	CC3.1	Clause 8.2, 9.3
3.6 Risk Appetite	CC3.1	Clause 5.2

6. Exceptions

There are no exceptions to maintaining the risk register or conducting quarterly reviews. Individual risk acceptance decisions follow the approval levels defined in Section 3.1.2.

7. Enforcement

Failure to conduct scheduled risk reviews is escalated to the CEO. Undocumented risk acceptance (taking a known risk without formal registration) is a policy violation reportable under KD-POL-003.

8. Revision History

Version	Date	Author	Changes
1.0	2026-03-19	CTO	Initial release