🗂️ Data Classification & Handling

Nemu Inc. — Updated 2025

1. Purpose

This document defines Nemu Inc.’s data classification framework and the handling requirements for each classification level.
Its purpose is to ensure appropriate protection of all customer and internal data.

2. Data Classification Levels

2.1 Confidential (Highest Sensitivity)

Data that requires the strongest safeguards.
Examples:

• Customer PII
• Household & estate settlement data
• Device identifiers & authentication tokens
• Internal security configurations
• Billing or financial data

Controls Required:

• Encryption at rest & in transit
• Strict RBAC
• Limited retention
• Cannot be stored in unauthorized systems
• Cannot be shared externally without authorization

2.2 Internal

Data intended for internal use by Nemu Inc.
Examples:

• Internal documentation
• Operational metrics
• Slack discussions
• Product planning documents

Controls Required:

• Store only in approved systems
• Domain-restricted sharing
• No external publishing without permission

2.3 Public

Data approved for public release.
Examples:

• Marketing content
• Public documentation
• Social media and website content

Controls Required:

• Required review before publication

3. Data Handling Requirements

3.1 Confidential Data

Permitted only in:

• Supabase (DB/Storage)
• Google Workspace
• Render-hosted services

Requirements:

• Access limited to business-need-to-know
• Encrypted exports only
• Mandatory deletion after use
• Prohibited:
  • Storing in personal cloud accounts
  • Copying to personal devices
  • Sending over personal messaging apps

3.2 Internal Data

• Stored in internal systems only
• Default domain-only sharing enforced

3.3 Public Data

• Must go through a release review
• Cannot contain Confidential or Internal data

3.4 Object Storage (Supabase Buckets)

A Supabase bucket marked public serves its objects over an unauthenticated URL that bypasses Row Level Security entirely. Public buckets therefore have no access control, and the RLS requirement in §6 cannot be relied on for them. Buckets holding Confidential data must be private and reached only through a short-lived signed URL issued by the API after an authorization check.

* Known gap, tracked. These four buckets are read directly by the released mobile application, which resolves object URLs client-side. Making them private requires a coordinated mobile release, so the remediation is phased: server-side controls and the private-bucket signing layer are already in place, and these buckets move to private once the mobile client reads server-issued signed URLs. Compensating controls in the interim: object keys are unguessable v4/v7 UUIDs, upload access is constrained by household-scoped RLS (see §6), and no directory listing is exposed.

Signed URLs are issued by StorageAccessService, which refuses to sign for any bucket not on its private allow-list and enforces the household prefix on household-namespaced buckets.

4. Acceptable Use & Accountability

• Employees acknowledge Acceptable Use & Data Handling policies at onboarding.
• Violations can lead to disciplinary action.
• Employees must:
  • Use only company-approved systems
  • Protect all credentials
  • Report any improper data handling incidents

5. Encryption Requirements

5.1 Data in Transit

• All traffic must use TLS 1.2+
• HTTPS enforced on all systems
• Postgres connections use sslmode=require

5.2 Data at Rest

• Supabase: AES-256 encryption for DB & Storage
• Google Workspace: encrypted by default
• Render: encrypted volumes and disks
• All endpoints: full-disk encryption (FileVault, BitLocker)

6. Access Control Requirements

• Role-based access for all sensitive data
• Privileged access restricted and monitored
• Supabase Row Level Security used where applicable
• Access reviewed periodically
• Storage upload policies are scoped to the owning tenant, not just the bucket. Uploads to item-images are restricted to households the caller belongs to; avatars to the caller’s own user id; voice-notes and price-history-attachments to items in the caller’s households. A bucket-only check would let any authenticated user write into another household’s namespace. Definitions live in packages/nemu-domain/prisma/triggers/storage_policies.sql.

7. Restrictions on Uploading / External Sharing

Confidential data may not be uploaded to:

• Personal Dropbox
• Personal iCloud
• WhatsApp / Telegram
• WeTransfer
• Any unapproved external tool

Google Workspace enforces domain restrictions to block unauthorized sharing.

8. Handling Scoped Data (SIG Requirements)

8.1 Scoped Data Transmission

Scoped data may only be sent electronically when required and must use encryption.

8.2 Scoped Data Storage

Only allowed in approved, encrypted platforms.

8.3 File Sharing Controls

Google Workspace prevents unauthorized uploads through:

• Domain policies
• External sharing restrictions

9. USB / Removable Media

• USB usage for Confidential data is restricted.
• Any authorized use requires encryption.

10. Audit Evidence

Examples:

• Google Workspace admin logs
• Supabase access logs
• Render secret configuration screenshots
• RBAC permission matrices
• RLS configuration examples
• Bucket visibility listing (select name, public from storage.buckets) reconciled against the classification table in §3.4
• Negative test: requesting an export belonging to another household returns 403/404 and never a URL; the same object’s public URL returns HTTP 400
• Storage upload policy verification — bun run verify:storage-policies drives the live Storage API as two users in separate households and asserts that cross-tenant writes are rejected by RLS while same-tenant writes succeed. Exits non-zero on any regression, so its output is repeatable evidence

11. Compliance Mapping

• SIG: D.2 – D.2.4, D.7, D.7.11, D.9.3
• SOC 2: CC6.1 (logical access to stored data), CC6.2/CC6.3 (access removal is effective — download links are minted per request and expire, so revoking household access revokes file access), CC6.7 (no permanent storage URLs are transmitted by email or stored on records)
• ISO 27001: A.8.2.1–A.8.2.3, A.9

Contact: support@mynemu.com
© 2025 Nemu Inc.