Every criterion. A line of evidence.

Governance posture, codified responsibilities, and the integrity of the people running the system.

1. CC1.1Live today

   The entity demonstrates a commitment to integrity and ethical values.

   Kodori implementation — Public roadmap, public stack-decisions log, public scope doc. We say which certifications we don't hold yet on the security page itself. Comparison pages flag where incumbents win.

   Evidence

   • project_scope_v0.1.md (Phase numbers + exit criteria)
   • stack_decisions_v0.1.md (D1–D75 vendor decisions on the record)
   • /security/#certifications — honest dates, no marketing fiction
2. CC1.2On audit engagement

   The board exercises oversight responsibility for internal control.

   Kodori implementation — Solo-founder phase: the founder owns every decision and every audit response. Quarterly review of D-decisions, audit-log anomaly counts, and security email volume against a written rubric. External advisor onboarded when the SOC 2 Type I auditor engagement opens.

   Evidence

   • Quarterly review log — internal
3. CC1.3Live today

   Management establishes structures, reporting lines, and authorities.

   Kodori implementation — Three roles in-product (owner / admin / member) with explicit transfer-ownership flow. Last-owner refusals are enforced server-side — a workspace can never be left without an admin.

   Evidence

   • /members — role assignments per tenant
   • apps/web/actions/members.ts — last-owner guard
4. CC1.4On audit engagement

   The entity attracts, develops, and retains competent personnel.

   Kodori implementation — Solo-founder phase. Background check + reference check policy documented for first hires. Onboarding includes signing a security-acknowledgement statement bound to the role.

   Evidence

   • Hiring policy — internal
5. CC1.5Live today

   Personnel are held accountable for internal control responsibilities.

   Kodori implementation — Every privileged action (sensitivity downgrade, retention change, hold release, member role change) emits a hash-chained event with the actor's identity. The audit chain itself is the accountability artifact.

   Evidence

   • /audit — every event filterable by actor
   • packages/events/src/store.ts — hash chain

Internal and external information flows that support the running of controls.

1. CC2.1Live today

   Quality information is obtained or generated to support internal control.

   Kodori implementation — Anomaly-detection cron runs every 15 minutes against the audit log; high-severity AGENT signals auto-pause the offending principal. Cap-warning banner surfaces upcoming quota exhaustion before users hit it.

   Evidence

   • /audit?type=anomaly — anomaly events
   • /permissions — auto-written deny rules
2. CC2.2Live today

   Internal communication of objectives and responsibilities for internal control.

   Kodori implementation — CLAUDE.md + project_scope_v0.1.md + stack_decisions_v0.1.md are the public-internal source of truth. Slack / email is supplementary, not authoritative.

   Evidence

   • Repo root markdown files
3. CC2.3Live today

   External communication regarding matters affecting internal control.

   Kodori implementation — security@kumokodo.ai is the disclosed contact (1 business day SLA). Public changelog at /changelog enumerates every shipped change. Marketing pages identify status of every certification claim.

   Evidence

   • /security — security contact + SLA
   • /changelog — release ledger

Identifying, analyzing, and responding to risks to the achievement of objectives.

1. CC3.1Live today

   Specifies suitable objectives with sufficient clarity to identify risks.

   Kodori implementation — Phase exit criteria in project_scope_v0.1.md are the formal objectives. Each Phase exit gate is risk-reviewed against the criteria list before declaring exit.

   Evidence

   • project_scope_v0.1.md §11 — Phase exits
2. CC3.2On audit engagement

   Identifies risks to the achievement of its objectives across the entity.

   Kodori implementation — Stack-decisions doc has explicit "what we revisit" gates per decision. Quarterly review combines anomaly-detection signal trend, security email backlog, and dependency CVE scan.

   Evidence

   • stack_decisions_v0.1.md "Revisit triggers" sections
   • CVE scan — pnpm audit + Dependabot in CI
3. CC3.3Live today

   Considers the potential for fraud in assessing risks.

   Kodori implementation — Anomaly detection flags high-volume regulated reads, off-hours spikes, agent loops above ceiling — the canonical fraud-indicator patterns for a DMS.

   Evidence

   • /audit?type=anomaly
4. CC3.4Live today

   Identifies and assesses changes that could significantly impact internal control.

   Kodori implementation — Stack-decisions doc gates vendor swaps behind a written D-decision. Schema changes to packages/db require a migration AND a design note (per CLAUDE.md). Phase exit gates re-review the full risk surface.

   Evidence

   • stack_decisions_v0.1.md
   • CLAUDE.md "files not to touch"

Ongoing and separate evaluations to ascertain whether components of internal control are present and functioning.

1. CC4.1Live today

   The entity selects, develops, and performs ongoing and/or separate evaluations.

   Kodori implementation — Anomaly detection runs every 15 minutes. Inngest cron schedules: hash-chain validator (daily), webhook delivery health (hourly), retention-class sweep (daily), onboarding-email delivery audit (daily), seat-cap reconciliation (daily).

   Evidence

   • packages/workflow/src/functions/* — Inngest functions
   • /inngest — function dashboard (admin only)
2. CC4.2Live today

   Evaluates and communicates internal control deficiencies.

   Kodori implementation — Anomaly events surface on the audit log with severity. Owner / admin email notification for high-severity anomalies. Auto-paused agents block on /permissions until an owner reviews and resumes with a written rationale.

   Evidence

   • /audit
   • /permissions — paused-principal queue

Policies and procedures that mitigate risk to acceptable levels.

1. CC5.1Live today

   Selects and develops control activities that contribute to mitigation of risk.

   Kodori implementation — Deny-wins ACL is a single SQL fragment used by UI, search, agent, and public REST. One fragment to audit, not N copy-pasted permission checks. Hash-chain on append, not on read — tamper-evidence is built in regardless of who reads.

   Evidence

   • packages/mcp/src/permissions/can-read-document.ts
   • packages/events/src/store.ts
2. CC5.2Live today

   Selects and develops general control activities over technology.

   Kodori implementation — CI runs typecheck, lint, build on every PR. Pre-deploy migration check confirms no destructive operations without an explicit allow list. Vercel preview deployments require manual promote to prod.

   Evidence

   • .github/workflows
   • Vercel project settings
3. CC5.3Live today

   Deploys control activities through policies and procedures.

   Kodori implementation — Inngest cron policies are code, not config. Retention class definitions are tenant-scoped Drizzle rows with explicit human-confirmation step before disposal. Legal hold deny-wins is enforced at three independent layers (UI, MCP tool, audit assertion).

   Evidence

   • packages/db/src/schema/retention.ts
   • packages/mcp/src/tools/legal-hold-*.ts

Access to systems and data is restricted to authorized users only. The bulk of a DMS audit lives here.

1. CC6.1Live today

   Implements logical access controls to protect against threats from sources outside the system.

   Kodori implementation — SSO-only authentication via Google Workspace + Microsoft Entra ID. No passwords on Kodori. Auth.js v5 with JWT session strategy; tenant-scoped JIT user sync. Session staleness check forces re-sign-in after a tenant move so a moved member cannot keep a stale token.

   Evidence

   • apps/web/auth.ts
   • apps/web/middleware.ts — JWT staleness check
2. CC6.2Live today

   Registers and authorizes new internal and external users.

   Kodori implementation — Invitation flow: owner / admin invites via email; invite carries a single-use token; accept binds the new user to the inviting tenant. Last-owner safeguards prevent a workspace from being orphaned. WorkOS SAML/SCIM integration is the escape hatch when an enterprise contract requires SAML-only or SCIM-provisioned access.

   Evidence

   • /members — pending + accepted invites
   • apps/web/actions/members.ts
3. CC6.3Live today

   Authorizes, modifies, or removes access to data, software, functions, and other protected resources.

   Kodori implementation — Three roles (owner / admin / member). Document-level deny rules win over allow rules, enforced by canReadDocument SQL fragment. Removed users have their session invalidated by JWT staleness check; re-invitation requires a fresh invite token.

   Evidence

   • /permissions — explicit allow / deny rules
   • packages/mcp/src/permissions/can-read-document.ts
4. CC6.4Roadmap

   Restricts physical access to facilities and protected information assets.

   Kodori implementation — No physical Kodori facilities; production runs on Vercel + Neon + Cloudflare R2. Each subprocessor publishes their own SOC 2 / ISO 27001 reports covering physical security. Sub-processor list disclosed at /security/subprocessors (phase-1).

   Evidence

   • Vercel SOC 2 Type II report
   • Neon SOC 2 Type II report
   • Cloudflare ISO 27001 + SOC 2
5. CC6.5On audit engagement

   Discontinues logical and physical protections over physical assets only after the ability to read or recover data is removed.

   Kodori implementation — Subprocessor decommissioning policy: any blob storage region change runs through a documented migration with hash-chain verification before the old region is decommissioned. Hardware decommissioning is the subprocessor's responsibility under their SOC 2.

   Evidence

   • Migration runbook — internal
6. CC6.6Live today

   Implements logical access security to protect against threats from outside the system boundary.

   Kodori implementation — TLS 1.2+ enforced on every public endpoint. Webhook deliveries signed with HMAC-SHA256 + 5-minute timestamp drift window. Cloudflare Email Worker for inbound email signs every forwarded message before the API route accepts it. API keys carry opt-in scopes; search:read is the always-granted baseline. The public Model Context Protocol surface at POST /api/mcp accepts the same scoped API keys, so external AI clients (Claude Desktop, Cursor, ChatGPT desktop, Kodokyo) inherit the same authentication and scope-filtering as the REST API — no privileged "AI access" path bypasses the key surface.

   Evidence

   • /api-keys — scope checkboxes
   • /help/webhook-signature-verification
   • /help/mcp-server — public MCP endpoint setup
   • apps/web/app/api/email/inbound/route.ts
   • apps/web/app/api/mcp/route.ts — scope filter + audit-attribution
7. CC6.7Live today

   Restricts the transmission, movement, and removal of information.

   Kodori implementation — Permission-trimmed retrieval: a user without read on a document never sees a search hit, dashboard count, snippet, API response, or agent reply. The same canReadDocument gate runs everywhere it matters. Per-tenant export bundles only what the requester can read; the agent uses the same gate.

   Evidence

   • /api/tenant/export — permission-trimmed bundle
   • /agent — same gate as UI
8. CC6.8Live today

   Implements controls to prevent or detect and act upon the introduction of unauthorized or malicious software.

   Kodori implementation — Dependencies pinned via pnpm lockfile. CI runs pnpm audit on every push. Production deployments are immutable Vercel builds — no SSH, no in-place patching. Inngest function code is the same code shipped to Vercel.

   Evidence

   • pnpm-lock.yaml
   • .github/workflows

Detection, prevention, and recovery from system failures and incidents.

1. CC7.1Live today

   Uses detection and monitoring procedures to identify (1) changes to configurations and (2) susceptibilities to vulnerabilities.

   Kodori implementation — Vercel deployment log captures every config change. Sub-processor list versioned in repo. Anomaly-detection cron monitors for behavioural anomalies in real time.

   Evidence

   • Vercel deployment log
   • /audit
2. CC7.2Live today

   Monitors system components and the operation of those components for anomalies.

   Kodori implementation — Anomaly events on the hash-chained audit log: high-volume regulated reads, full-tier-spread access, off-hours baseline spikes, repeated held-doc touches, agent tool-call ceiling hits. Severity-graded; high severity auto-pauses the offending principal.

   Evidence

   • /audit?type=anomaly
3. CC7.3On audit engagement

   Evaluates security events to determine whether they could or have resulted in a failure of the entity to meet its objectives.

   Kodori implementation — Owner / admin email notification on high-severity anomalies. Triage runbook documents triage steps + escalation. Formal bug-bounty program activates alongside the SOC 2 Type I auditor engagement; until then we honor responsible-disclosure reports manually with named acknowledgment in /security release notes.

   Evidence

   • Triage runbook — internal
4. CC7.4On audit engagement

   Responds to identified security incidents by executing a defined incident response program.

   Kodori implementation — Incident response policy: log preservation, customer notification within 72 hours of confirmed material incident affecting their data (per GDPR Art 33), coordinated disclosure for vulnerabilities reported via security@kumokodo.ai.

   Evidence

   • Incident response policy — internal
5. CC7.5Live today

   Identifies, develops, and implements activities to recover from identified security incidents.

   Kodori implementation — Hash-chained audit log lets us prove tamper-evidence at any point in time. Reversibility model means agent transactions can be reverted within the retention window. Tombstone-then-purge pattern means deletes are recoverable inside the grace period.

   Evidence

   • /help/reversibility
   • packages/events/src/store.ts

Authorizes, designs, develops, configures, documents, tests, approves, and implements changes to systems.

1. CC8.1Live today

   Authorizes, designs, develops or acquires, configures, documents, tests, approves, and implements changes to systems.

   Kodori implementation — Every change flows through git → PR → CI → preview deploy → manual promote. Schema changes require a migration + a design note. D-decisions in stack-decisions are gated behind a written entry. Files-not-to-touch list in CLAUDE.md prevents silent drift on governance primitives.

   Evidence

   • GitHub PR history
   • CLAUDE.md "files not to touch"
   • stack_decisions_v0.1.md

Identifies, selects, and develops risk mitigation activities for risks arising from potential business disruptions.

1. CC9.1Live today

   Identifies, selects, and develops risk mitigation activities.

   Kodori implementation — Vendor-diversification posture: blob storage abstracts behind an S3-compatible interface (R2 today, AWS-S3 BYO-bucket available). Auth providers are pluggable Auth.js providers. Anthropic is the model provider but the tool-call interface is provider-agnostic.

   Evidence

   • stack_decisions_v0.1.md D8 (storage), D9 (auth)
2. CC9.2Roadmap

   Assesses and manages risks associated with vendors and business partners.

   Kodori implementation — Sub-processor list maintained in repo. Each sub-processor is selected for HIPAA-tier offering availability + SOC 2 Type II report on file. DPA template available on request.

   Evidence

   • /security/subprocessors (phase-1)

Information designated as confidential is protected as committed or agreed.

1. C1.1Live today

   Identifies and maintains confidential information to meet the entity's objectives.

   Kodori implementation — Five-tier sensitivity model on every document (public / internal / confidential / restricted / regulated). Auto-classification proposes a tier on ingest; humans confirm. Tier surfaces visually across every list.

   Evidence

   • /help/sensitivity-and-classification
   • packages/core/src/sensitivity.ts
2. C1.2Live today

   Disposes of confidential information to meet the entity's objectives.

   Kodori implementation — Retention classes define disposal cadence per tenant. Disposal requires explicit human confirmation (queue → review → confirm) — no silent automated deletion. Documents on legal hold refuse disposal regardless of retention class.

   Evidence

   • /retention — retention classes per tenant
   • /legal-hold — bound subjects
3. C1.3Live today

   Protects confidential information at rest with cryptographic controls under customer custody.

   Kodori implementation — Envelope encryption on every blob: each upload gets a fresh AES-256-GCM Data Encryption Key (DEK), wrapped against a Key Encryption Key (KEK) that lives in the customer's own KMS (AWS KMS, Azure Key Vault, or GCP KMS). Plaintext DEKs never persist; revoking the KEK in the customer's KMS instantly makes every blob unreadable regardless of where the encrypted bytes live. Default tenants use a deployment-managed envelope key derived from AUTH_SECRET. Full lifecycle audit on every key change: tenant-kms.registered / tenant-kms.rotated / tenant-kms.disabled events on the tenant's hash-chained audit stream with from/to keyIdSuffix in the rotated event payload, so auditors can see "every change to your key custody" with one /audit query. Re-wrap pipeline (live SDK calls + walk every wrapped DEK to re-encrypt against the new KEK so the retired key can be safely deleted from the customer's KMS) is documented for delivery as part of the SOC 2 Type I engagement.

   Evidence

   • /encryption — admin BYO-key registration UI
   • /audit?types=tenant-kms.registered,tenant-kms.rotated,tenant-kms.disabled — lifecycle history
   • packages/db/src/schema/tenant-kms-keys.ts
   • docs/plans/tenant-key-rewrap-plan.md — re-wrap pipeline plan