Data Classification Policy
1. Purpose
Section titled “1. Purpose”Defines classification levels for Meridian Seven information assets and the handling requirements for each level.
2. Scope
Section titled “2. Scope”All data created, received, maintained, or transmitted by Meridian Seven, regardless of format or storage location.
3. Classification Levels
Section titled “3. Classification Levels”| Level | Definition | Examples |
|---|---|---|
| Public | Intended for public distribution; no harm if disclosed | Marketing materials, public docs, open-source code, job postings, status page |
| Internal | For use within Meridian Seven; not sensitive but not for external distribution | Policies, engineering docs, meeting notes, GitHub issues, training materials |
| Confidential | Sensitive business or customer information; unauthorized disclosure could harm Meridian Seven or customers | Customer data, financial records, employee PII, vendor contracts, audit reports, security assessments |
| Restricted | Highly sensitive; unauthorized disclosure could cause severe harm; named-individual access only | Credentials, API keys, encryption keys, DB connection strings, security incident details under investigation, SOC 2 working papers |
When in doubt, classify at the higher level.
4. Handling Requirements
Section titled “4. Handling Requirements”4.1 Storage
Section titled “4.1 Storage”| Level | Requirements |
|---|---|
| Public | No special requirements |
| Internal | Authorized company systems only (GitHub, Slack, approved SaaS). No public-facing storage. |
| Confidential | Encrypted at rest (AES-256). Access restricted to authorized personnel. Stored in approved systems with audit logging. BYOD endpoints may access Confidential data via approved applications; local caching for offline work is permitted only in approved apps. See BYOD Endpoint Security Policy. |
| Restricted | Encrypted at rest (AES-256-GCM where supported; AES-256 minimum). Designated secure systems only (Doppler, 1Password, Supabase with RLS). Named-individual access. Dedicated key management required. |
4.2 Transmission
Section titled “4.2 Transmission”| Level | Requirements |
|---|---|
| Public | No special requirements |
| Internal | TLS 1.2+. Do not post in public channels. |
| Confidential | TLS 1.2+ required. Do not transmit via unencrypted email or unapproved file sharing. |
| Restricted | TLS 1.2+ required. Share only via approved secure channels (1Password secure sharing, Doppler). Never transmit via email, Slack, or any system with accessible message history. |
4.3 Access
Section titled “4.3 Access”| Level | Requirements |
|---|---|
| Public | Unrestricted |
| Internal | Authenticated Meridian Seven employees and authorized contractors |
| Confidential | Role-based access with business justification. Logged and reviewed monthly. |
| Restricted | Named individuals only with explicit CISO or CTO approval. Access logged, alerted on, and reviewed monthly. MFA required. |
4.4 Disposal
Section titled “4.4 Disposal”| Level | Requirements |
|---|---|
| Public | Standard deletion |
| Internal | Standard deletion from all known locations |
| Confidential | Secure deletion from all storage locations. Verify deletion from cloud services. Request vendor deletion confirmation where applicable. |
| Restricted | Cryptographic erasure or secure wipe. Written confirmation of destruction. Maintain destruction log. |
5. Data Transmission Controls (CC6.7)
Section titled “5. Data Transmission Controls (CC6.7)”5.1 Encryption in Transit
Section titled “5.1 Encryption in Transit”All external communications use TLS 1.2 or higher:
| System / Channel | Enforcement Mechanism |
|---|---|
| Cloudflare (public domains) | HTTPS enforced; SSL strict mode |
| Supabase | SSL required at connection string level |
| GCP Cloud Run, GitHub | HTTPS by default; no plain HTTP endpoints in production |
| Doppler CLI | All secret retrieval over TLS |
| All API integrations | HTTPS-only; no HTTP integrations permitted |
5.2 Email
Section titled “5.2 Email”Google Workspace enforces opportunistic TLS for email in transit. Confidential or Restricted information must not be transmitted via email — use approved channels in section 4.2.
5.3 File Transfer
Section titled “5.3 File Transfer”All data movement is via:
| Method | Use Case |
|---|---|
| Git over HTTPS or SSH | Code and policy documents |
| HTTPS API calls | System integrations and automation |
| Doppler (encrypted) | Secret distribution to services |
| Backblaze B2 over HTTPS | Backup storage |
| 1Password secure sharing | Credential sharing between personnel |
5.4 Data Loss Prevention
Section titled “5.4 Data Loss Prevention”| Control | Mechanism |
|---|---|
| Secret scanning | Enabled on all Meridian7-io GitHub repositories; blocks commits containing credential patterns |
| Claude Security Review | Automated PR review scans for sensitive data patterns before merge |
| Doppler as single source of truth | Secrets never committed to code; enforced by secret scanning and policy |
| 1Password for credential sharing | Credentials shared via 1Password secure links, not email or Slack |
5.5 Removable Media
Section titled “5.5 Removable Media”Removable media (USB drives, external hard drives, SD cards) is prohibited for business data. Confidential or Restricted data must not be transferred to any removable or portable storage medium.
5.6 Remote Access
Section titled “5.6 Remote Access”All production system access occurs through web consoles or HTTPS APIs. No SSH-accessible production servers. Google Workspace enforces 2FA; all system consoles require MFA per the Access Control Policy. No direct database connections from developer workstations to production.
6. Labeling Requirements
Section titled “6. Labeling Requirements”- Label documents and data stores with their classification level where practical
- Evidence files: include classification in document header or filename prefix
- Source code repositories: classification noted in README
- Databases: classification documented in schema documentation
- Update labels if sensitivity changes
7. Retention Periods
Section titled “7. Retention Periods”| Data Type | Classification | Retention Period |
|---|---|---|
| Customer data (active accounts) | Confidential | Duration of relationship + 90 days |
| Customer data (churned accounts) | Confidential | Secure deletion within 30 days of written request; automatic deletion 90 days after account closure |
| Agent session logs | Confidential | 12 months |
| Application logs | Internal | 90 days |
| Financial records | Confidential | 7 years |
| Employee records | Confidential | Employment duration + 3 years |
| Security incident records | Confidential | 3 years |
| Audit evidence | Internal / Confidential | 3 years |
| Credentials and keys | Restricted | Rotate per Access Control Policy; no retention of expired credentials |
| Backups | Per source classification | Per Backup and Recovery Policy |
8. Customer Data Handling
Section titled “8. Customer Data Handling”- All customer data is Confidential at minimum
- Customer data containing credentials, payment information, or security-sensitive content is Restricted
- Customer data must not be used beyond the contracted service without explicit consent
- No customer data is shared with third parties without explicit written consent. Vendors processing data on behalf of Meridian Seven or its customers must have a Data Processing Agreement (DPA) in place prior to any data access.
- Customer data deleted within 30 days of written request. Upon receiving a written deletion request, all customer data — including database records, knowledge graph entities, vector embeddings, and backup copies within the retention window — is permanently removed and deletion confirmation is provided to the requesting party.
- Sensitive credentials stored within the platform (API keys, connection tokens) are encrypted with AES-256-GCM and managed exclusively through Doppler, a dedicated secrets management platform. Credentials are never stored in source code, environment files, or application configuration.
Multi-Tenant Isolation Architecture
Section titled “Multi-Tenant Isolation Architecture”Customer data is isolated per organization using a shared schema with organization scoping model in PostgreSQL (Supabase):
| Layer | Mechanism | Enforced By |
|---|---|---|
| Column-level scoping | All tenant tables include an org_id column; queries are scoped to the current organization | Application context (withOrgContext(orgId, cb)) enforces org routing |
| Auth enforcement | Supabase Auth JWT with custom_access_token_hook injects org_ids and org_roles into JWT; validated on every API call | BFF middleware (withAuth()) on every API route |
| RLS — tenant data | RLS enabled on all tenant tables; policies use current_setting('app.current_org_id') to enforce row-level access | Policy applied per-connection via application context |
| RLS — platform data | RLS enabled on shared tables (platform.organizations, platform.org_memberships); service_all + member-scoped policies | Drizzle migrations |
| Direct DB access | No direct database connections from developer workstations to production (see §5.6) | Policy + no SSH access to production servers |
Tenant isolation guarantee: All customer sales data is subject to PostgreSQL Row-Level Security enforcement at the database engine level. Tenant isolation is not dependent on application logic; the database enforces that authenticated client operations can only access data belonging to the requesting organization. No client-initiated query path is capable of returning, modifying, or deleting another organization’s records. Supabase’s service_role does NOT have BYPASSRLS — every query, including server-side operations, is filtered by the RLS policy.
Note on service_role access: The service_role key is used server-side only (BFF and agent service) and is stored in Doppler, never exposed to clients. While the service_role has broader query capabilities, RLS policies still enforce org_id filtering on every operation. The application sets app.current_org_id per-transaction, and the database engine guarantees isolation regardless of application behavior. This design decision is documented in the accepted risk register (automation/config/accepted-risks.yaml).
Nightly verification: The SOC2 automation (make verify) checks nightly that:
- RLS is enabled on all tenant and platform schema tables
- RLS policies correctly enforce
org_idscoping - The
anonrole has no policies granting access to any customer data table
9. Roles and Responsibilities
Section titled “9. Roles and Responsibilities”| Role | Responsibility |
|---|---|
| CISO | Maintains policy; conducts classification reviews; approves Restricted access |
| Founder / Data Owner | Classifies data within their domain; approves Confidential access requests; stewards data governance decisions |
| Engineers | Apply classification-appropriate controls in system design and implementation |
| All Personnel | Handle data per classification; report misclassification or improper handling |
10. Enforcement
Section titled “10. Enforcement”Mishandling classified data is a policy violation subject to disciplinary actions in the Information Security Policy. Incidents involving Confidential or Restricted data must be reported to the CISO immediately and may trigger the Incident Response Plan.
11. Related Documents
Section titled “11. Related Documents”- Information Security Policy
- Access Control Policy
- BYOD Endpoint Security Policy
- Segregation of Duties Matrix
- Vendor Management Policy
- Backup and Recovery Policy
- Incident Response Plan
Meridian Seven — Confidential