# 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 |