Migrated from Linear KKN-203 (https://linear.app/kokonut/issue/KKN-203/operational-and-data-compliance)

Certification Compatibility & Readiness Assessment

Executive Summary

Based on thorough exploration of the codebase (15 compliance-relevant areas) and research into 10 certification frameworks, here are the findings:

| Standard | Relevance | Current Readiness | Effort to Achieve | | -- | -- | -- | -- | | SOC 2 Type I | High — B2B data platform, enterprise customers | 70% — Strong technical controls, missing policy docs | 3–4 months | | SOC 2 Type II | High — same as above but requires 6–12 month observation | 70% — Same controls, needs observation period | 9–15 months (6–12 mo observation + 3 mo prep) | | ISO 27001:2022 | High — International gold standard for information security | 55% — Good technical controls, missing ISMS documentation | 6–9 months | | ISO 27701:2025 | High — Privacy extension, directly relevant to farmer PII | 50% — Strong consent/privacy features, needs PIMS framework | 4–6 months (after ISO 27001) | | ISO 14001:2015 | Medium — Environmental management for regenerative ag platform | 30% — Environmental data tracked, no EMS documented | 6–9 months | | ISO 9001:2015 | Medium — Quality management for data products | 40% — Quality processes exist informally, no QMS | 4–6 months | | ISO 22000:2018 | Low-Medium — Food safety if tracking harvest data for food chain | 20% — Harvest tracking exists, no food safety management | 9–12 months | | ISO 27017:2015 | Medium — Cloud security controls for hosted infrastructure | 60% — Docker/Pin/Compose security is strong, needs documentation | 3–4 months | | ISO 27018:2019 | Medium — PII protection in cloud, relevant to farmer data | 50% — Privacy features exist, needs formal cloud PII controls | 3–4 months | | GDPR | High — EU regulation if serving EU farmers/partners | 55% — Consent/portability exist, missing DSAR automation, erasure | 3–6 months |

---

Detailed Readiness by Area

| Area | Maturity | SOC 2 TSC | ISO 27001:2022 Annex A | Status | | -- | -- | -- | -- | -- | | Audit & Logging | FULL | CC6.1, CC7.2 | A.8.15 | ✅ Audit log, access audit log, ingestion log, agent action log. Missing: log rotation, retention policy | | Access Control | FULL | CC6.1–CC6.3 | A.9 | ✅ RBAC, capability tokens, API keys, rate limiting, agent safety. Missing: access reviews, joiner-mover-leaver | | Data Encryption | PARTIAL | CC6.7 | A.10 | ⚠️ Backup AES-256-CBC, token hashing, Caddy TLS. Missing: DB TDE, field-level PII encryption, gRPC TLS enforced, key rotation | | Data Retention | FULL | CC6.5 | A.8.3 | ✅ Policy table, soft delete, legal hold, enforcement log. Missing: automated scheduling, hard_delete/anonymize/archive | | Incident Response | PARTIAL | CC7.3 | A.16 | ⚠️ Emergency incident table, health alerts. Missing: IRP document, severity taxonomy, escalation matrix, post-incident review | | Change Management | FULL | CC8.1 | A.12 | ✅ Checksummed migrations, drift detection, upgrade/rollback scripts. Missing: CAB approval, non-schema change log | | Risk Management | FULL | CC3.1 | A.1 | ✅ CRISP 5-dimension scoring, threatcasting, backcasting, risk mitigation register. Missing: ISO 31000-aligned risk register, treatment plan | | Business Continuity | PARTIAL | CC9.1 | A.17, A.5.30 | ⚠️ Encrypted backup/restore scripts. Missing: automated scheduling, offsite replication, RPO/RTO targets, DR testing | | Data Classification | ABSENT | CC6.1 | A.8.2 | ❌ No formal classification scheme. Need: Public/Internal/Confidential/Restricted labels, handling procedures | | Third-Party Risk | ABSENT | CC9.2 | A.15 | ❌ No vendor register, assessment, or review process. Need: vendor inventory, risk questionnaires, contractual requirements | | Privacy & Consent | FULL | P1.1 | A.18 | ✅ Consent management, portability, sharing agreements, selective disclosure, append-only logs. Missing: DSAR automation, right to erasure cascade, PIA process, DPO designation | | Monitoring & Alerting | FULL | CC7.1, CC7.2 | A.12 | ✅ Health checks, alerting, anomaly detection, data freshness. Missing: centralized monitoring dashboard, SLA/SLO tracking, log aggregation | | Evidence & Traceability | FULL | CC7.4 | A.8.10 | ✅ Evidence lineage graph, provenance, chain of custody, IRI system, RDF triples, content hashing, immutability triggers | | Governance Frameworks | FULL | CC1.1, CC2.1 | A.5 | ✅ 200+ governed collections, lifecycle enforcement, decision policies, agent safety, governance circles | | Agent Safety | FULL | CC6.1 | A.6.2 | ✅ Pre-write safety assessment, high-risk action blocking, payload hashing, execution allowlist, DB-level enforcement |

---

Recommended Certification Path

Based on readiness, effort, and business value:

Phase 1: SOC 2 Type I (3–4 months)

Why first: Lowest documentation overhead, highest market value for B2B sales. SOC 2 is an attestation (auditor examines controls), not a certification (formal audit against a standard). It's faster and cheaper than ISO 27001.

Gap closure required:

1. Data Classification — Implement 4-tier scheme (Public/Internal/Confidential/Restricted) with table labels and handling procedures
2. Incident Response Plan — Document IRP with severity matrix (P1–P4), escalation contacts, communication templates
3. Access Review Process — Quarterly access certification for admin/governance roles
4. Log Retention Policy — Define and enforce retention periods for audit/access/ingestion logs
5. Policy Documentation — Information Security Policy, Acceptable Use Policy, Change Management Policy, Vendor Management Policy
6. SOC 2 System Description — Document system boundaries, data flows, infrastructure

Already strong: Audit logging, access control, encryption (backups), change management, risk management, monitoring, evidence traceability, governance frameworks.

Phase 2: SOC 2 Type II (6–12 months observation after Phase 1)

Same controls as Type I but audited over a 6–12 month observation period. Begin observation window immediately after Type I report.

Phase 3: ISO 27001:2022 (6–9 months)

Why next: International recognition, builds on SOC 2 foundation, 93 Annex A controls across 4 themes (Organizational, People, Physical, Technological).

Gap closure required (on top of SOC 2):

1. ISMS Documentation — Full Information Security Management System with scope, context, leadership commitment
2. Statement of Applicability (SoA) — Justify each of 93 Annex A controls
3. Risk Treatment Plan — Accept/mitigate/transfer/avoid for each identified risk
4. Third-Party Risk Management — Vendor register, assessment questionnaires, contractual security requirements
5. Business Continuity Plan — RPO/RTO targets, DR testing, automated backup scheduling
6. Physical Security — Facility access controls (if applicable), physical monitoring
7. Secure Coding — OWASP practices, code review requirements, dependency vulnerability scanning (already have Slither/Semgrep)
8. Data Leakage Prevention — DLP controls for sensitive data exfiltration
9. Configuration Management — Baseline configurations, change control for infrastructure
10. Monitoring Activities — Formal SIEM or log aggregation (Loki/ELK)

Phase 4: ISO 27701:2025 (4–6 months, after ISO 27001)

Why: Directly relevant to farmer PII protection. Extends ISO 27001 with privacy controls.

Already strong: Consent management, data portability, privacy-preserving attestations, selective disclosure, append-only consent logs.

Gap closure required:

1. PII Inventory — Complete register of all PII processed, purposes, legal basis, retention
2. Privacy Impact Assessments (PIAs/DPIAs) — Process for high-risk processing
3. Right to Erasure — Automated deletion cascade when consent withdrawn
4. Data Protection Officer (DPO) — Designate responsible person
5. Cross-border Transfer Controls — Document where PII flows (Celo on-chain, ClickHouse, etc.)
6. Privacy by Design — Embed privacy into new feature development process

Phase 5: ISO 27017/27018 (3–4 months, can run parallel with Phase 4)

Cloud security and PII protection in cloud. Relevant because the platform runs on Docker/PostgreSQL/ClickHouse infrastructure.

Gap closure required:

1. Cloud Security Policy — Document cloud-specific security controls
2. Shared Responsibility Model — Document what the platform controls vs. infrastructure provider
3. Virtual Network Security — Document Docker network isolation, Caddy TLS, MQTT TLS
4. Cloud PII Handling — Document how PII is handled in cloud-hosted databases

Phase 6 (Optional): ISO 14001 + ISO 9001 (6–9 months)

ISO 14001: Only if the platform wants to formalize environmental management (relevant for regenerative agriculture brand).

ISO 9001: Only if the platform wants to formalize quality management for data products.

---

Key Decision Points

1. SOC 2 Type I vs ISO 27001 first? → SOC 2 Type I is faster (3–4 months vs 6–9 months) and more common for B2B SaaS. Start there.
2. Include Privacy in SOC 2? → Yes. The platform processes farmer PII (names, KYC, locations). Include all 5 Trust Service Criteria.
3. Which criteria for SOC 2? → Security (mandatory) + Availability + Processing Integrity + Confidentiality + Privacy. All 5 are relevant.
4. ISO 22000 (Food Safety)? → Only if the platform expands into direct food supply chain tracking. Defer for now.
5. ISO 14001? → Only if the platform wants to position itself as an environmental management system for farms. Defer unless brand strategy requires it.

---

SOC 2 Type I Implementation Plan

Scope & System Boundaries

System Description: Kokonut Intelligence — a regenerative agriculture data platform processing farmer identity data, on-chain attestations, metric computation, and governance workflows.

In Scope:

• PostgreSQL database (primary data store)
• ClickHouse (analytical event store)
• Docker Compose infrastructure (PostgreSQL, ClickHouse, Redis, Directus, Metabase, Gateway, MQTT)
• Python services (40+ modules under services/)
• Directus API and hooks (extensions/kokonut-hooks/)
• Gateway API (authentication, routing, audit)
• Solidity smart contracts (EAS, KGP, Celo/Gnosis on-chain)
• gRPC services
• MQTT sensor ingestion pipeline

Out of Scope:

• End-user devices (farmer phones)
• Third-party weather/market APIs (vendor-managed)
• Solidity contract source code (separate deployment lifecycle)

Trust Service Criteria (All 5)

| Criteria | Why Relevant | | -- | -- | | Security (Common Criteria) | Mandatory. Protects against unauthorized access, data breaches. | | Availability | Platform uptime SLAs for farmers and partners. | | Processing Integrity | Metric computation, credit issuance, governance decisions must be accurate. | | Confidentiality | Farmer PII (names, KYC, locations), financial data. | | Privacy | Farmer consent, data portability, selective disclosure. |

Gap Closure Tasks (Organized by Priority)

Phase 1: Policy Foundation (Weeks 1–4)

P1.1 — Information Security Policy

• Owner: You (lead author)
• Output: docs/policies/information-security-policy.md
• Content: Security objectives, scope, roles, risk management approach, compliance obligations, management commitment
• Effort: 2–3 days

P1.2 — Acceptable Use Policy

• Owner: You
• Output: docs/policies/acceptable-use-policy.md
• Content: Device usage, software restrictions, data handling, incident reporting, personal device policy
• Effort: 1 day

P1.3 — Data Classification Policy

• Owner: You
• Output: docs/policies/data-classification-policy.md
• Content: 4-tier scheme (Public/Internal/Confidential/Restricted), labeling requirements, handling procedures, data lifecycle
• Effort: 1–2 days

P1.4 — Incident Response Plan

• Owner: You
• Output: docs/policies/incident-response-plan.md
• Content: Severity matrix (P1–P4), escalation contacts, communication templates, post-incident review process
• Effort: 2 days

P1.5 — Change Management Policy

• Owner: You
• Output: docs/policies/change-management-policy.md
• Content: Change approval process, rollback procedures, testing requirements, deployment workflow
• Effort: 1 day

P1.6 — Vendor/Third-Party Management Policy

• Owner: You
• Output: docs/policies/vendor-management-policy.md
• Content: Vendor inventory, risk assessment questionnaires, contractual requirements, periodic review
• Effort: 2 days

P1.7 — Acceptable Use & Security Awareness Training

• Owner: You
• Output: docs/policies/security-awareness-training.md
• Content: Training topics, onboarding requirements, annual refresher schedule, phishing awareness
• Effort: 1 day

P1.8 — Code of Ethics

• Owner: You
• Output: docs/policies/code-of-ethics.md
• Content: Ethical conduct, conflict of interest, reporting obligations
• Effort: 1 day

Phase 2: Technical Controls (Weeks 2–8)

P2.1 — Data Classification Implementation

• Owner: Backend engineer
• Output: SQL migration adding data_classification column to key tables (farmer_identity, consent_record, expense_event, revenue_event, etc.)
• Effort: 3–4 days
• Details: Add column with enum (public, internal, confidential, restricted), populate from existing patterns, add audit triggers

P2.2 — Access Review Process

• Owner: You
• Output: docs/procedures/access-review.md + quarterly review script
• Effort: 2–3 days
• Details: Define which roles require quarterly review, create review checklist, document certification process

P2.3 — Log Retention Policy Enforcement

• Owner: Backend engineer
• Output: Update retention_policy seeds with log-specific retention periods
• Effort: 1–2 days
• Details: Audit logs: 7 years, Access logs: 2 years, Ingestion logs: 1 year, Agent action logs: 2 years

P2.4 — Encryption Enhancement

• Owner: Backend engineer
• Output: Field-level PII encryption for farmer names, KYC data
• Effort: 3–5 days
• Details: Implement AES-256-GCM encryption for PII fields, key rotation mechanism, re-encryption on migration
• Note: Consider using pgcrypto or application-level encryption

P2.5 — Centralized Logging

• Owner: DevOps
• Output: Log aggregation setup (Loki/ELK or similar)
• Effort: 3–5 days
• Details: Aggregate all service logs into central store, search capability, alerting integration

P2.6 — Business Continuity Plan

• Owner: You + DevOps
• Output: docs/business-continuity-plan.md
• Content: RPO/RTO targets, DR procedures, automated backup scheduling, offsite replication, DR testing schedule
• Effort: 2–3 days
• Details: RPO: 1 hour (WAL-based), RTO: 4 hours (restore + verify), offsite: encrypted S3/GCS, DR test: quarterly

P2.7 — Backup Scheduling

• Owner: DevOps
• Output: Automated daily backup cron, offsite replication
• Effort: 2–3 days
• Details: Update config/worker/crontab to add daily encrypted backup + upload to offsite storage

P2.8 — TLS for gRPC

• Owner: Backend engineer
• Output: Enforce TLS for gRPC connections
• Effort: 2–3 days
• Details: Update services/grpc/server.py and services/grpc/cli.py to use TLS certificates

Phase 3: Documentation & Audit Prep (Weeks 6–12)

P3.1 — SOC 2 System Description

• Owner: You
• Output: docs/compliance/soc2-system-description.md
• Content: System overview, infrastructure, data flows, trust service criteria mapping, control evidence
• Effort: 5–7 days
• Details: This is the core audit document. Map all 5 TSC to existing controls.

P3.2 — Control Evidence Matrix

• Owner: You
• Output: docs/compliance/control-evidence-matrix.csv
• Content: Control ID, description, owner, evidence location, test procedure, status
• Effort: 3–5 days
• Details: Create CSV mapping each SOC 2 control to specific files, tables, logs in the codebase

P3.3 — Risk Assessment Register

• Owner: You
• Output: docs/compliance/risk-assessment.md
• Content: Risk register aligned with SOC 2/ISO 27001, treatment plans, residual risk acceptance
• Effort: 3–4 days
• Details: Already have CRISP risk scoring; formalize into ISO 31000-aligned register

P3.4 — Privacy Impact Assessment (PIA)

• Owner: You
• Output: docs/compliance/privacy-impact-assessment.md
• Content: PII inventory, processing purposes, legal basis, data flows, risk mitigation
• Effort: 3–4 days
• Details: Cover farmer identity, KYC, consent, location data, on-chain attestations

P3.5 — DSAR (Data Subject Access Request) Process

• Owner: Backend engineer
• Output: docs/procedures/dsar-process.md + automation script
• Effort: 3–5 days
• Details: Define process for access, rectification, erasure, portability requests. Existing consent/portability features provide foundation.

P3.6 — Right to Erasure Cascade

• Owner: Backend engineer
• Output: Implement erasure cascade for farmer PII
• Effort: 5–7 days
• Details: Anonymize farmer_identity, consent records, expense/revenue events, KYC data. Preserve aggregate metrics. On-chain attestations cannot be erased (document limitation).

P3.7 — Secure Development Lifecycle (SDLC) Documentation

• Owner: You
• Output: docs/policies/secure-development-policy.md
• Content: Code review requirements, static analysis, dependency scanning, testing requirements
• Effort: 2–3 days
• Details: Already have Slither/Semgrep; document as formal policy

P3.8 — Vendor Risk Assessment Template

• Owner: You
• Output: docs/compliance/vendor-risk-questionnaire.md
• Content: Standard questionnaire for third-party vendors (OpenWeatherMap, Alchemy, Celo RPC, etc.)
• Effort: 2–3 days

Phase 4: Operational Readiness (Weeks 10–16)

P4.1 — Tabletop Exercise (Incident Response)

• Owner: You
• Output: Incident response tabletop walkthrough documentation
• Effort: 1 day
• Details: Simulate a data breach scenario, test IRP, document findings

P4.2 — DR Test

• Owner: DevOps
• Output: Disaster recovery test report
• Effort: 1–2 days
• Details: Full backup restore, verify data integrity, measure RTO

P4.3 — Access Certification

• Owner: You
• Output: First quarterly access certification completed
• Effort: 1 day
• Details: Review all admin/governance role assignments, document certification

P4.4 — SOC 2 Readiness Self-Assessment

• Owner: You
• Output: docs/compliance/soc2-readiness-self-assessment.md
• Content: Self-score against all 5 TSC, identify remaining gaps
• Effort: 2–3 days

P4.5 — Auditor Engagement

• Owner: You
• Output: Audit firm shortlist, engagement letter
• Effort: 2–3 days
• Details: Big 4 firms: Deloitte, PwC, EY, KPMG. Mid-tier: BDO, Grant Thornton, Mazars. Budget: $15K–$40K for Type I.

---

Timeline Summary

| Phase | Duration | Key Deliverables | | -- | -- | -- | | Phase 1: Policy Foundation | Weeks 1–4 | 8 policy documents | | Phase 2: Technical Controls | Weeks 2–8 | Data classification, encryption, logging, BCP | | Phase 3: Documentation & Audit Prep | Weeks 6–12 | System description, evidence matrix, PIA, DSAR | | Phase 4: Operational Readiness | Weeks 10–16 | Tabletop, DR test, self-assessment, auditor | | Total | 16 weeks (4 months) | SOC 2 Type I report |

Resource Requirements

| Resource | Effort | Cost | | -- | -- | -- | | Internal engineering (you) | ~200–300 hours | Existing team | | Audit firm | 4–6 weeks fieldwork | $15K–$40K | | Legal review (policies) | 2–3 days | $2K–$5K (external counsel) | | Total | \~$20K–$50K | 4 months |

Key Risks

| Risk | Mitigation | | -- | -- | | Policy documentation takes longer than estimated | Start Phase 1 immediately, use templates | | Encryption enhancement delays | Can defer field-level encryption to SOC 2 Type II | | Audit firm availability | Engage firm in Week 6, not Week 14 | | On-chain data cannot be erased (GDPR limitation) | Document in PIA as technical limitation with legal basis |

---

Immediate Next Steps

1. Create the policy directory structure: docs/policies/ and docs/compliance/
2. Start with P1.1 — Information Security Policy (highest priority, foundation for everything else)
3. Engage an audit firm early (Week 6) to align scope and avoid surprises

Want me to proceed with creating the policy directory and starting with the Information Security Policy? Or would you prefer to adjust the scope (e.g., skip Privacy criteria, focus on Security + Availability only for a faster Type I)?