Information Security Policy

This Information Security Policy defines the governance framework, security standards, and operational controls that Mixed Race Community (MRC) applies to protect information assets and the personal data of community members.

Scope: This policy applies to all MRC information systems, data repositories, infrastructure components, and personnel — including employees, contractors, and any third parties with authorised access to MRC systems or data.

MRC processes racial and ethnic heritage data classified as special category data under GDPR Article 9. Accordingly, MRC's information security posture is designed to meet the heightened obligations that apply to this category of processing.

This policy satisfies SOC 2 CC1.1 (Control Environment), CC1.2 (Board Oversight), CC1.3 (Organisational Structure), ISO 27001 Clause 5.1 (Leadership) and Annex A.5.1 (Policies for Information Security), and NIST CSF ID.GV (Governance).

MRC classifies all information assets across seven tiers. Controls applied to each tier are proportionate to the sensitivity of the data and the harm that could result from unauthorised disclosure or loss.

Tier 1 — Critical: Encryption keys, database master credentials, API secrets, OAuth client secrets, Vercel deployment tokens, Neon connection strings. Stored exclusively in Vercel encrypted environment variables. Never transmitted in plaintext. Never committed to version control. Access restricted to the system or individual with a documented operational need. Rotation schedule: at minimum annually and immediately upon suspected compromise.

Tier 2 — Special Category: Racial and ethnic heritage data — heritage1, heritage2, heritage1_nation, heritage2_nation, mixed_colors, mixed_gradient, heritage_accent. Processed under GDPR Article 9(2)(a) explicit consent. Access restricted by role; all access is logged. Subject to DPIA (Data Protection Impact Assessment). Full erasure on account deletion via CASCADE delete. Consent is timestamped, versioned, and withdrawable at any time.

Tier 3 — Sensitive: Date of birth, city of residence, account verification status, moderation flags, subscription status. Accessible to authorised team members and automated systems with a documented operational need. Not transmitted to third parties without an explicit legal basis.

Tier 4 — Personal: Display name, email address, profile photo URL, pronouns, biography. Handled under GDPR Articles 5-6. Disclosed to other users only to the extent the account holder has published it. Used only for the purposes stated at collection.

Tier 5 — Content: Posts, comments, reactions, direct messages, reported content. Treated as user-owned. Accessed by MRC only for moderation, safety, legal compliance, or at explicit user request.

Tier 6 — Operational: Server access logs, error traces, deployment metadata, rate-limiting counters (Upstash Redis), Sentry error payloads. Retained for up to 90 days. Error payloads are scrubbed of special category data before transmission to Sentry.

Tier 7 — Analytics: Aggregated, anonymised usage statistics (e.g. page view counts, feature adoption rates). No individual-level analytics on heritage data. Aggregated data does not constitute personal data where individuals cannot reasonably be re-identified.

Principle of least privilege: All access — human and machine — is granted at the minimum level required to perform the authorised function. Elevated access is time-limited where technically feasible and revoked immediately when no longer needed.

User access: Authenticated community members may access and modify only their own profile data, heritage information, posts, and settings. Cross-user data access is enforced at the API layer; all routes validate session ownership before returning or modifying data.

Admin access: Administrative functions (content moderation, account management, analytics dashboards) are restricted to explicitly designated admin accounts. Admin status is set at the database level and verified on every privileged API request. Admin accounts require MFA.

Infrastructure access: Access to Neon Postgres, Supabase, Resend, Upstash, Sentry, Vercel, and Cloudflare consoles is restricted to named individuals with a documented operational need. Access credentials are stored in a password manager with MFA. Shared credentials are prohibited.

Access reviews: All infrastructure access grants are reviewed quarterly. Access for departed team members or contractors is revoked within 24 hours of departure.

Service accounts: Machine-to-machine access (e.g. API keys used by the application) follows the same least-privilege principle. Keys are scoped to the minimum permissions required. Keys are rotated at minimum annually.

Password hashing: User passwords are hashed using PBKDF2-SHA512 with a per-user salt and a work factor calibrated to take at least 100ms on current hardware, making bulk offline cracking attacks computationally prohibitive. Plaintext passwords are never stored or logged.

Encryption in transit: All traffic between clients and MRC servers is encrypted using TLS 1.2 or higher. HTTP requests are redirected to HTTPS. Certificate management is handled by Vercel and Cloudflare, which enforce modern cipher suites and disable deprecated protocols (SSLv3, TLS 1.0, TLS 1.1).

Encryption at rest: The Neon Postgres database is encrypted at rest using AES-256 via Neon's managed infrastructure. Supabase file storage (profile photos, uploaded assets) is encrypted at rest using AES-256 via Supabase's managed infrastructure. Vercel serverless function environments are ephemeral and do not persist data to disk.

Session tokens: Session tokens are generated using a cryptographically secure random number generator, stored as httpOnly, Secure, SameSite=Lax cookies, and are not accessible to JavaScript. Sessions expire after 30 days of inactivity and are invalidated on sign-out and password change.

CSRF protection: All state-changing API requests are protected using a double-submit cookie pattern (mrc_csrf token). The token is validated server-side on every mutating request.

All changes to MRC's production codebase require a pull request (PR) on GitHub. Direct commits to the main branch are prohibited. PRs require at least one code review approval before merge.

CI/CD pipeline: Deployments to production are handled exclusively through Vercel's CI/CD pipeline, triggered by merges to the main branch. Manual deployments to production are prohibited. The pipeline runs automated checks including dependency vulnerability scanning (npm audit) on every deployment.

Environment separation: MRC maintains separate development, preview, and production environments. Preview deployments are created automatically for every PR and use isolated non-production data. Production environment variables are never exposed to preview environments.

Database migrations: Schema changes are applied via versioned migration scripts. Migrations are reviewed as part of the PR process and tested in the preview environment before being applied to production.

Dependency management: Dependencies are pinned to specific versions in package.json. npm audit is run on every deployment. Critical and high severity vulnerabilities in direct dependencies are remediated before the release proceeds.

Secrets rotation: Secrets are rotated at minimum annually and immediately following any suspected or confirmed compromise. Rotation events are documented.

The following systems constitute MRC's asset inventory. Each is classified, has a designated owner, and is subject to the access controls and encryption standards described in this policy.

Neon Postgres — Primary relational database. Stores all user profiles, heritage data, posts, comments, sessions, moderation records, and consent records. Classification: Critical (credentials), Special Category (heritage data), Personal, Content. Encrypted at rest and in transit. Backed up by Neon (point-in-time recovery).

Supabase Storage — File storage for user-uploaded assets (profile photos). Classification: Personal (photo URLs), Content. Encrypted at rest. Access controlled via Supabase RLS policies and signed URLs.

Resend — Transactional email delivery (verification emails, password reset, notifications). Classification: Personal (email addresses). Email content is not stored by MRC beyond the send event. Resend is used only for transactional email; marketing email is handled separately with explicit opt-in.

Upstash Redis — Rate limiting counters and temporary state. Classification: Operational. Data is ephemeral (TTL-based). No personal data is stored as values; only anonymised keys (hashed IP addresses, user ID hashes).

Sentry — Application error monitoring and performance tracing. Classification: Operational. Sentry error payloads are scrubbed of special category heritage data and passwords before transmission. PII scrubbing is enforced at the SDK level.

Vercel — Hosting, serverless function execution, CI/CD, and encrypted environment variable storage. Classification: Critical (environment variables), Operational (access logs). Production environment is isolated from preview environments.

Cloudflare — DNS, TLS termination, DDoS protection, and Turnstile bot protection. Classification: Operational. Cloudflare processes request metadata (IP addresses, user agents) in accordance with its own privacy policy.

Google OAuth — Optional social sign-in. Classification: Personal (OAuth tokens, email, name). MRC requests only the minimum OAuth scopes needed (email, profile). OAuth tokens are not stored; only the resulting user identity is persisted.

MRC employs a qualitative risk assessment methodology adapted from ISO 27005. Risks are assessed on two dimensions — Likelihood (Very Low / Low / Medium / High / Very High) and Impact (Low / Medium / High / Critical) — yielding an Overall Risk rating.

Risk register: Identified risks are recorded in an internal risk register with the following fields: risk description, affected asset(s), likelihood, impact, overall rating, current controls, residual risk, and owner.

Risk treatment: Risks rated High or Critical require a documented treatment plan with a remediation deadline. Medium risks are reviewed quarterly. Low risks are reviewed annually.

Acceptable residual risk: Residual risks rated Low are accepted without further treatment, subject to annual review. Residual risks rated Medium are accepted only where treatment is disproportionate to the likelihood and impact, and where compensating controls are in place.

DPIA integration: Processing activities involving special category data (Tier 2) are subject to a Data Protection Impact Assessment (DPIA) under GDPR Article 35. The DPIA for heritage data processing is maintained separately and reviewed before any material change to heritage data processing.

Every deployment: npm audit run automatically in CI/CD pipeline. Any critical or high severity vulnerability in a direct dependency blocks deployment.

Weekly: Sentry error dashboard reviewed. Unusual error patterns or volume spikes are investigated within 48 hours.

Monthly: Content moderation queue review. Hate speech filter effectiveness assessed. Community guidelines updated if required.

Quarterly: Access review — all infrastructure access grants verified against current team roster. Policy review — all compliance policies reviewed for currency. Risk register reviewed and updated. Upstash rate-limiting thresholds reviewed.

Annually: Full security awareness training completed by all in-scope team members. All policies formally reviewed and updated. Transparency report published. Penetration test conducted by a qualified independent assessor. Dependency audit beyond automated scanning (manual review of major dependencies).

Trigger-based: GDPR breach notification to supervisory authority within 72 hours of becoming aware of a qualifying breach. Policy review triggered by: material security incident, material change to data processing, regulatory guidance update, or new product feature involving personal data.

This policy is reviewed on an annual basis by the MRC policy owner. The review assesses whether the policy remains accurate, proportionate, and compliant with applicable law and industry standards.

Reviews are also triggered by: a significant security incident; a material change to MRC's technology stack, data processing activities, or organisational structure; updated regulatory guidance from the ICO, CNIL, or other relevant supervisory authority; or a finding from an external audit or penetration test.

Approved changes are communicated to all in-scope team members within 30 days of the new policy effective date.

Current version effective date: March 24, 2026. Next scheduled review: March 2027.

Questions about this policy should be directed to security@mixedracecommunity.com.