Security Awareness Policy

This Security Awareness Policy establishes the minimum security knowledge and behavioural standards expected of all Mixed Race Community (MRC) team members, contractors, and any third parties who are granted access to systems, infrastructure, or data belonging to MRC.

MRC processes racial and ethnic heritage data — classified as special category data under GDPR Article 9. A single security failure can expose our community members to discrimination, identity-based harm, or loss of privacy. Security awareness is therefore not optional; it is a core operational requirement.

This policy satisfies SOC 2 CC1.4 (Communication of Responsibilities), ISO 27001 A.7.2.2 (Information Security Awareness), and NIST CSF PR.AT (Awareness and Training).

Initial training: All team members with access to production systems or user data must complete a security orientation before being granted access. This covers: data classification, password policy, incident reporting, phishing recognition, and acceptable use of MRC systems.

Annual refresher: Every person in scope must complete a security awareness refresher each calendar year. Completion is tracked and non-completion results in access suspension until the refresher is done.

Role-specific training: Team members with elevated privileges (database access, admin panel, Sentry/Vercel/Supabase consoles) must additionally complete training on secure coding practices, least-privilege administration, and safe secret management.

Training records are retained for a minimum of three years to support compliance audits.

Authorised use only: MRC systems — including Neon Postgres, Supabase file storage, Resend, Upstash Redis, Sentry, Cloudflare, and Vercel — may only be used for legitimate MRC business purposes. Personal use on production infrastructure is prohibited.

No unauthorised access: Team members must not access user data, admin tools, or infrastructure beyond the scope of their assigned role. Curiosity browsing of user records — even without intent to misuse — constitutes a policy violation.

No data exfiltration: Downloading, copying, or transmitting user data (especially heritage/ethnic origin data) to personal devices, personal cloud storage, or unauthorised third-party services is strictly prohibited.

No sharing of credentials: API keys, database connection strings, session tokens, and admin passwords must never be shared via email, chat, version control, or any channel that does not support end-to-end encryption and access controls.

Secret management: All secrets must be stored in environment variables managed through Vercel's encrypted environment variable store. Secrets must never be committed to the Git repository, even in private branches.

Software installation: Only approved software may be installed on devices used to access MRC production systems. Team members must not install browser extensions with broad data access permissions on devices used for MRC work.

Immediate reporting: Any suspected or confirmed security incident must be reported immediately — within one hour of discovery — to the MRC security contact at security@mixedracecommunity.com. Do not attempt to investigate or remediate alone before reporting.

What constitutes an incident: Incidents include (but are not limited to) — suspected unauthorised access to any MRC system; discovery of credentials or secrets in a public or unprotected location; phishing email that was acted upon; malware on a device used for MRC work; accidental disclosure of user data to an unauthorised party; discovery of a vulnerability in MRC systems.

What to report: When reporting, include — what happened (in as much detail as known), when it was discovered, which systems or data may be affected, what actions have already been taken, and contact information for follow-up.

No blame culture: MRC operates a blameless incident response culture. Team members are expected to report incidents promptly and honestly. Delayed reporting due to fear of consequences is itself a policy violation and will be treated more seriously than the underlying incident.

Regulatory deadlines: Under GDPR Article 33, personal data breaches must be reported to the relevant supervisory authority within 72 hours of MRC becoming aware of them, where feasible. Prompt internal reporting is therefore critical to meeting this obligation.

Post-incident review: All incidents are reviewed within 14 days using a blameless post-mortem process to identify root causes and prevent recurrence.

Phishing: Attackers may impersonate trusted parties — including Vercel, Supabase, Google, GitHub, or even MRC team members — to steal credentials or induce harmful actions. Always verify unexpected requests through a known-good contact method before acting. Do not click links in unsolicited emails; navigate directly to service dashboards.

Spear phishing: Targeted phishing attacks use personalised information (your name, role, recent activity) to appear credible. Treat any unexpected request involving credentials, payments, or data access with heightened suspicion regardless of how legitimate it appears.

Pretexting: An attacker may construct a false scenario (e.g. 'I am from Vercel support and need your API key to resolve an outage') to extract sensitive information. Legitimate services will never ask for your credentials or secrets. Verify all such requests through official support channels before responding.

Vishing and smishing: Social engineering attacks arrive via phone calls and SMS, not only email. The same principles apply — verify through known-good channels before acting.

Reporting suspected social engineering: If you receive a suspicious message — even if you did not act on it — report it to security@mixedracecommunity.com. Reporting helps protect other team members who may receive the same attack.

MRC classifies all data into seven tiers. Team members must understand the tier of data they handle and apply the corresponding controls.

Critical — encryption keys, database connection strings, API keys, OAuth secrets. Never transmitted in plaintext, never committed to version control, never shared via chat. Stored exclusively in Vercel encrypted environment variables or equivalent secret management.

Special Category — racial and ethnic heritage data (heritage1, heritage2, heritage1_nation, heritage2_nation, mixed_colors, mixed_gradient, heritage_accent). Governed by GDPR Article 9. Access strictly role-limited. All access logged. Explicit consent required before collection. Full erasure on account deletion.

Sensitive — date of birth, city, verification status, account flags. Access limited to authorised team members and automated systems with a documented need. Not transmitted to third parties without legal basis.

Personal — display name, email address, profile photo URL, pronouns. Handled in accordance with GDPR Articles 5-6. Not disclosed to other users beyond what the account holder has made public.

Content — posts, comments, reactions, DMs. Treated as user-owned; accessed by MRC only for moderation, safety, and legal compliance purposes.

Operational — server logs, error traces (Sentry), deployment metadata. Retained for up to 90 days unless longer retention is required for a specific investigation.

Analytics — aggregated, anonymised usage statistics. No individual-level analytics on heritage data. Aggregated analytics do not constitute personal data where they cannot reasonably be used to re-identify individuals.

Unique passwords: Every MRC-related account — Vercel, Neon, Supabase, Resend, Upstash, GitHub, Sentry, Cloudflare, Google Cloud — must have a unique password that is not reused across any other service.

Password manager: All team members must use a reputable password manager (e.g. 1Password, Bitwarden) to generate and store credentials. Writing passwords in plaintext documents, spreadsheets, or chat is prohibited.

Minimum complexity: Passwords must be at least 16 characters. Where a service supports passphrases, these are preferred over short complex passwords.

Multi-factor authentication (MFA): MFA is mandatory on all MRC service accounts that support it. Hardware security keys (FIDO2/WebAuthn) are preferred; TOTP authenticator apps are acceptable. SMS-based MFA is discouraged due to SIM-swap risk but is acceptable where no alternative exists.

Compromised credentials: If any credential used for MRC systems is suspected to be compromised, rotate it immediately and report the incident per Section 4.

Device encryption: All devices used to access MRC production systems — laptops, desktops, and mobile devices — must have full-disk encryption enabled (e.g. FileVault on macOS, BitLocker on Windows, dm-crypt on Linux).

Screen lock: Devices must be configured to lock automatically after no more than 5 minutes of inactivity. Manual locking (e.g. Win+L, Ctrl+Cmd+Q) is expected whenever leaving a device unattended, even briefly.

Unattended devices: Never leave a device with an active MRC session unattended in a public or semi-public space. In shared office environments, always lock your screen when stepping away.

Remote work: When working remotely, avoid accessing MRC systems on public or shared Wi-Fi without using a VPN. If public Wi-Fi is unavoidable, confirm that all connections are over HTTPS (which they will be on MRC services by default).

Disposal: Before decommissioning any device previously used for MRC work, ensure it is securely wiped using a method appropriate to the storage medium (e.g. cryptographic erasure for SSDs, multi-pass overwrite for HDDs).

This policy is reviewed annually — and additionally whenever a significant security incident occurs, when MRC's technology stack or data processing activities change materially, or when regulatory guidance is updated.

Review process: The policy owner (MRC security contact) is responsible for initiating the review. Changes are documented, approved, and communicated to all in-scope team members within 30 days of the 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.