🔐 Encryption and Key Management Policy

1. Purpose

This policy establishes Nemu Inc.’s requirements for encryption of data at rest and in transit, and defines how encryption keys and application-level secrets are managed. This policy ensures that Confidential and sensitive data is protected through cryptographic controls that prevent unauthorized disclosure, modification, or access.

2. Scope

This policy applies to:

• All Confidential and regulated data as defined in the Data Classification and Handling Policy
• Data stored in Supabase databases and storage buckets
• Data stored in Google Workspace
• Data transmitted over networks (internal and external)
• Data stored on endpoint devices (laptops, mobile devices)
• Application-level secrets and credentials
• Database encryption keys (managed by CSPs)
• Backup and archived data
• Data managed by fourth-party service providers

3. Policy Owner

The Security/Engineering Lead is responsible for:

• Ensuring encryption options are correctly enabled in all CSP configurations
• Overseeing secret rotation practices and access controls
• Validating compliance with encryption requirements
• Reviewing and updating this policy annually
• Coordinating with vendors on encryption capabilities

4. Encryption Requirements

4.1 Data at Rest Encryption

All Confidential data must be encrypted at rest using industry-standard encryption algorithms. Nemu Inc. requires:

4.1.1 Database Encryption

• Supabase PostgreSQL Databases:
  • Encryption at rest enabled for all production databases
  • Encryption provided by Supabase/underlying cloud provider
  • Minimum encryption standard: AES-256 or equivalent
  • Encryption keys managed by Supabase/cloud provider
  • Verify encryption status during quarterly reviews
• Database Encryption Configuration:
  • Full database encryption (not just selected fields)
  • Encrypted backups and point-in-time recovery archives
  • Encrypted snapshots and replicas
  • Encryption applies to all database objects (tables, indexes, logs)

4.1.2 File Storage Encryption

• Supabase Storage Buckets:
  • Server-side encryption enabled for all buckets storing Confidential data
  • Encryption at rest provided by Supabase/cloud storage provider
  • Minimum encryption standard: AES-256
  • Encryption applied automatically to all objects uploaded
• Google Workspace Storage:
  • Encryption at rest provided by Google for all Drive files, Gmail, and other Workspace data
  • Google-managed encryption keys
  • Encryption standard meets or exceeds AES-128

4.1.3 Endpoint Device Encryption

• Full-Disk Encryption Required:
  • All company-issued laptops and workstations must have full-disk encryption enabled
  • MacOS: FileVault 2 enabled
  • Windows: BitLocker enabled
  • Linux: LUKS or equivalent enabled
  • Encryption keys protected by user password/passphrase
• Mobile Devices:
  • Company-issued mobile devices must use device encryption
  • iOS: Encryption enabled by default (verify not disabled)
  • Android: Encryption enabled in device settings
• Removable Media:
  • USB drives and external storage containing Confidential data must be encrypted
  • Use company-approved encryption tools
  • Unencrypted removable media prohibited for Confidential data transfer

4.1.4 Backup and Archive Encryption

• All backups containing Confidential data must be encrypted
• Encryption applied before backup leaves production environment
• Supabase automated backups: encrypted by default
• Google Workspace backups: encrypted by Google
• Manual exports or archives: must be encrypted before storage

4.2 Data in Transit Encryption

All Confidential data transmitted electronically must be encrypted using secure protocols:

4.2.1 Network Communications

• HTTPS/TLS Required:
  • All web applications and APIs must use HTTPS
  • Minimum TLS version: TLS 1.2 (TLS 1.3 preferred)
  • Strong cipher suites only (disable weak ciphers: RC4, DES, 3DES, export ciphers)
  • Valid SSL/TLS certificates from trusted certificate authorities
  • HTTP redirects to HTTPS (no unencrypted HTTP access)
• API Communications:
  • All API endpoints require TLS encryption
  • API keys transmitted only over encrypted connections
  • Webhooks and callbacks use HTTPS

4.2.2 Database Connections

• PostgreSQL Connections:
  • sslmode=require parameter mandatory for all database connections
  • Minimum TLS 1.2 for database connections
  • Connection strings stored securely (environment variables, secret managers)
  • No plaintext database connections permitted
• Connection String Security:
  • Never log or display connection strings in application logs
  • Never commit connection strings to source control
  • Rotate credentials if exposure suspected

4.2.3 Email Encryption

• Email in Transit:
  • TLS encryption required for email transmission (opportunistic TLS at minimum)
  • Google Workspace: TLS enabled by default for Gmail
  • Email to external recipients: TLS used when recipient supports it
• Sensitive Email Content:
  • Avoid sending Confidential data in email body when possible
  • If necessary: use encrypted attachments or secure file sharing links
  • Password-protect sensitive attachments (password shared through alternate channel)

4.2.4 Remote Access

• VPN Encryption:
  • Company VPN uses strong encryption (AES-256 or equivalent)
  • VPN required for remote access to production systems
  • VPN required when accessing company resources over untrusted networks
• SSH and Remote Management:
  • SSH protocol required for remote server access (no Telnet)
  • SSH keys minimum 2048-bit RSA or 256-bit ECDSA
  • Disable SSH password authentication where possible (key-based auth only)

4.2.5 File Transfers

• Secure Transfer Protocols:
  • SFTP, SCP, or HTTPS for file transfers (no FTP or unencrypted protocols)
  • Cloud storage transfers via HTTPS APIs
  • Large file transfers via encrypted file sharing services (approved vendors only)

4.3 Encryption Standards and Algorithms

4.3.1 Approved Algorithms

• Symmetric Encryption:
  • AES-256, AES-192, or AES-128 (AES-256 preferred)
  • ChaCha20-Poly1305
• Asymmetric Encryption:
  • RSA 2048-bit minimum (4096-bit preferred for long-term use)
  • Elliptic Curve Cryptography (ECC): P-256, P-384, P-521
  • Ed25519 (for signatures and key exchange)
• Hashing:
  • SHA-256, SHA-384, SHA-512 (SHA-2 family)
  • SHA-3 family
  • BLAKE2
• Password Hashing:
  • bcrypt (work factor 10 or higher)
  • Argon2id
  • scrypt
  • PBKDF2-HMAC-SHA256 (100,000+ iterations)

4.3.2 Prohibited Algorithms

• MD5, SHA-1 (except for non-security purposes like checksums)
• DES, 3DES
• RC4
• Any algorithm with known vulnerabilities

5. Encryption Key Management

5.1 Key Management Approach

Nemu Inc. uses a cloud-native architecture where encryption keys are primarily managed by Cloud Service Providers (CSPs):

5.1.1 CSP-Managed Keys (Infrastructure Level)

• Supabase / PostgreSQL and Storage:
  • Encryption keys for data at rest managed by Supabase and underlying cloud provider
  • Keys stored in provider’s key management service (KMS)
  • Keys automatically rotated per provider’s security policies
  • Nemu Inc. does not have direct access to these keys
• Render / Application Hosting:
  • Disk and volume encryption keys managed by Render and cloud infrastructure provider
  • Keys protected by provider’s KMS
  • Encryption transparent to applications
• Google Workspace:
  • Keys for email, file storage, and application data managed by Google
  • Keys stored in Google’s KMS infrastructure
  • Automatic key rotation managed by Google

5.1.2 Key Management Standards for CSP Keys

While Nemu Inc. does not directly manage CSP encryption keys, we require:

• Encryption at Rest: Verified as enabled during vendor onboarding and quarterly reviews
• Key Protection: Keys must be stored in hardware security modules (HSMs) or equivalent by provider
• Key Rotation: Provider must have documented key rotation procedures
• Key Recovery: Provider must have secure key backup and recovery processes
• Compliance: Provider’s key management must meet SOC 2, ISO 27001, or equivalent standards

5.2 Encryption Keys Encrypted at Rest and in Transit

Per requirements:

• Keys at Rest: All encryption keys managed by CSPs are encrypted at rest within the provider’s KMS
• Keys in Transit: Keys are encrypted during any transmission (e.g., during key rotation, replication)
• Hardware Protection: Keys stored in HSMs or equivalent secure hardware where available
• No Key Exposure: Application code and personnel do not have direct access to infrastructure encryption keys

5.3 Application-Level Secrets Management

While CSPs manage infrastructure encryption keys, Nemu Inc. manages application-level secrets:

5.3.1 Secret Types

• Database connection strings (with sslmode=require)
• API keys for Supabase, Stripe, and other third-party services
• Authentication tokens and session secrets
• Service account credentials
• OAuth client secrets
• Webhook signing secrets
• Encryption keys for application-level encryption (if implemented)

5.3.2 Secret Storage

• Environment Variables:
  • Secrets stored as environment variables in Render deployment environment
  • Access restricted to authorized deployment pipelines and administrators
  • Not committed to source code repositories
• Secret Management Services:
  • Use Render’s secret management features or equivalent
  • GitHub Secrets for CI/CD pipeline secrets
  • Google Cloud Secret Manager for certain workflows (if applicable)
• CI/CD Secrets:
  • Stored in GitHub Secrets or CI/CD platform’s secure storage
  • Access restricted to specific workflows and repositories
  • Not logged or displayed in build outputs

5.3.3 Secret Handling Best Practices

• Never Hardcode Secrets:
  • No secrets in source code, configuration files committed to repositories, or documentation
  • Code reviews check for hardcoded secrets
  • Pre-commit hooks scan for accidental secret commits
• Principle of Least Privilege:
  • Secrets accessible only to services and environments that need them
  • Production secrets separate from development/staging secrets
  • Different credentials for different environments
• Secret Obfuscation:
  • Secrets never logged in application logs
  • Secrets redacted from error messages and debugging output
  • API responses never expose secrets
• Secure Transmission:
  • Secrets transmitted only over encrypted channels (HTTPS, TLS)
  • Secrets not sent via email or chat (use secret sharing tools if necessary)

5.3.4 Secret Rotation

• Scheduled Rotation:
  • Database credentials rotated annually at minimum
  • API keys for high-risk integrations (payment processors) rotated quarterly
  • Service account credentials rotated when staff changes occur
• Event-Driven Rotation:
  • Immediate rotation when:
    • Employee with secret access separates from company
    • Secret suspected of compromise or exposure
    • Security incident involving credentials
    • Vendor reports breach or security incident
• Rotation Process:
  • Generate new secret
  • Update application configuration with new secret
  • Deploy updated configuration
  • Verify functionality with new secret
  • Revoke or disable old secret
  • Document rotation in change management system

5.4 Key and Secret Access Controls

5.4.1 Access Restrictions

• Access to secrets restricted by role:
  • Production Secrets: Engineering Lead, CTO, authorized DevOps personnel
  • Staging/Development Secrets: Engineering team members
  • CI/CD Secrets: Authorized build/deployment pipelines only
• Access logging:
  • All access to secret stores logged
  • Reviews conducted quarterly for unusual access patterns
  • Alerts for unauthorized access attempts

5.4.2 Emergency Access

• Break-glass procedures documented for emergency secret access
• Emergency access requires dual approval when possible
• Emergency access logged and reviewed by Security Lead within 24 hours

5.5 Key and Secret Destruction

When secrets are rotated or decommissioned:

• Old secrets immediately revoked or disabled at the provider
• Old secrets deleted from all secret stores and environment configurations
• Documentation updated to remove old credentials
• Verify old credentials cannot be used (test revocation)
• Destruction documented with date and responsible party

6. Full-Disk Encryption for All Systems

6.1 Requirement

All systems that store or process scoped (Confidential) data must have full-disk encryption enabled. This includes:

• Production database servers (managed by Supabase/cloud provider)
• Application servers (managed by Render/cloud provider)
• Employee laptops and workstations
• Company-issued mobile devices
• Any system with local caching of customer data

6.2 Implementation

• Cloud Infrastructure: Encryption provided by CSPs (Supabase, Render)
• Endpoints: FileVault (macOS), BitLocker (Windows), LUKS (Linux)
• Verification:
  • Endpoint encryption status checked during device setup
  • Periodic compliance scans verify encryption enabled
  • Non-compliant devices flagged and remediated within 7 days

6.3 Exceptions

• Systems that demonstrably do not store or process scoped data may be exempted
• Exception requires Security Lead approval and documentation
• Exemptions reviewed quarterly

7. Database Encryption

7.1 Requirement

Regulated or confidential scoped data stored in databases must include database encryption. This ensures:

• Protection of data at rest from unauthorized access to storage media
• Compliance with regulatory requirements (GDPR, CCPA, etc.)
• Defense-in-depth security architecture

7.2 Implementation at Nemu Inc

• Supabase PostgreSQL: Full database encryption at rest enabled for all production databases
• Encryption Method: Transparent Data Encryption (TDE) or equivalent provided by cloud provider
• Verification: Encryption status checked during:
  • Initial database provisioning
  • Quarterly security reviews
  • Annual compliance audits

7.3 Additional Database Security

Beyond encryption:

• SSL/TLS required for all database connections (sslmode=require)
• Database connection strings stored securely
• Row-level security policies enforce access control
• Database activity logging enabled

8. Roles and Responsibilities

8.1 Security/Engineering Lead

• Ensures encryption options are correctly enabled in CSP configurations
• Validates TLS/SSL certificates and configurations
• Oversees secret rotation practices
• Conducts quarterly encryption compliance reviews
• Responds to encryption-related incidents
• Maintains this policy

8.2 Engineering Team

• Implements secure usage of keys and secrets within application code
• Avoids hardcoding secrets in source code repositories
• Configures TLS/HTTPS for all applications
• Enforces sslmode=require for database connections
• Tests encryption functionality during development
• Reports encryption failures or issues

8.3 Operations/IT Team

• Enables and verifies full-disk encryption on endpoint devices
• Configures VPN and remote access encryption
• Manages certificate lifecycle (renewal, installation)
• Monitors encryption health and alerts

8.4 All Personnel

• Protect credentials and secrets (do not share or expose)
• Use company VPN over untrusted networks
• Report lost/stolen devices immediately (for remote encryption verification)
• Follow acceptable use policies regarding encryption

9. Monitoring and Compliance

9.1 Encryption Verification

• Quarterly Reviews:
  • Verify Supabase database encryption status
  • Verify Render hosting encryption configuration
  • Check Google Workspace encryption settings
  • Review endpoint device encryption compliance
• Continuous Monitoring:
  • Alert on SSL/TLS certificate expiration (30 days before expiry)
  • Monitor for weak cipher usage in applications
  • Track database connections for non-SSL connections (alerts on violations)
• Annual Audits:
  • Comprehensive encryption compliance audit
  • Review of secret rotation practices
  • Assessment of encryption key management controls

9.2 Non-Compliance Remediation

• Encryption violations identified and documented
• Remediation plans created within 24 hours for critical issues
• Critical issues (production database without encryption) remediated within 7 days
• Non-critical issues remediated within 30 days
• Repeat violations escalated to management

10. Incident Response

10.1 Encryption-Related Incidents

Report immediately if:

• Encryption discovered to be disabled on production systems
• Encryption keys suspected of compromise or exposure
• Secrets leaked in code, logs, or communications
• SSL/TLS certificates expired causing service disruptions
• Unauthorized access to secret stores

10.2 Response Actions

• Activate incident response procedures
• Assess scope and impact of incident
• Rotate compromised keys/secrets immediately
• Re-enable encryption if disabled
• Investigate root cause
• Document lessons learned and update procedures

11. Audit Evidence

The following evidence demonstrates compliance with this policy:

• Supabase and Render documentation/screenshots showing encryption at rest enabled
• SSL/TLS certificate inventory and renewal logs
• Database connection string configurations (redacted) showing sslmode=require
• Environment variable/secret store configurations (redacted)
• Secret rotation logs and schedules
• Endpoint device encryption compliance reports
• Quarterly encryption verification checklists
• Certificate expiration monitoring alerts
• Encryption incident reports and remediation records

12. Compliance Mapping

13. Related Documents

• Data Classification and Handling Policy
• Information Asset Management Program
• Access Control Policy
• Acceptable Use Policy
• Incident Response Plan
• Vendor Security Assessment Procedures

14. Policy Metadata

Questions or Concerns: support@mynemu.com
General Support: support@mynemu.com

© 2025 Nemu Inc. All rights reserved.