Data Classification

Every piece of data we hold falls into one of four classifications. The classification determines how it must be stored, who can access it, how it travels between systems, and what happens when it's lost.

The point of having four tiers — not three, not seven — is that engineers, PMs, and Compliance can all answer the same question the same way without reading a thirty-page handbook. The classification of the data drives the requirements; the requirements drive the architecture.

The four tiers

Public

Data we intentionally publish. Marketing pages, blog posts, the SPYN App Store listing, public investor materials we've already shared.

Storage: anywhere. Access: anyone. Transit: anywhere. Loss: no impact beyond the news cycle.

Internal

Data that's ours, not sensitive, but not meant for the world. Internal documentation, the SPYN backlog in monday.com, draft release notes before publication, organisation charts.

Storage: company-controlled systems (Microsoft 365, monday.com, this repo). Access: anyone with a Media Tech email; SSO enforced. Transit: TLS in flight; no specific encryption-at-rest requirement beyond the platform default. Loss: embarrassing, possibly competitively useful to a rival, but not a regulatory or contractual event.

Confidential

Data that, if leaked, would damage a customer or the business. Customer commercial terms, salaries and compensation, performance reviews, financial forecasts, partner agreements, source code, infrastructure topology, security incident details.

Storage: company-controlled systems with role-based access. Source code in GitHub (private repos). Financials in scoped folders in Microsoft 365 with named-individual access. Access: named individuals or specific groups; no organisation-wide defaults. Transit: TLS in flight; encryption at rest using platform-managed keys. Loss: notification to affected parties; internal post-mortem; legal review.

Restricted

Data subject to regulation: personal data under GDPR, special-category data (health, sexual orientation, beliefs) which SPYN AI Diaries may produce inferentially, financial data subject to PCI DSS scope, anything covered by a customer DPA that names it.

Storage: in-region (EU for European users), encrypted at rest with customer-data keys distinct from operational data keys. Production databases in Laravel Cloud, file storage in EU-region S3-compatible storage. Access: strictly need-to-know, individually granted, time-limited where possible, audited. Transit: TLS 1.3 minimum, mutual TLS for service-to-service inside the production VPC. Loss: triggers the breach response runbook (compliance/incident-response); 72-hour regulator notification clock starts the moment we have a reasonable basis to believe data left our control.

SPYN mapping

Data	Classification	Notes
User diary content (human-written)	Restricted	Personal data; may contain special-category by inference.
AI-generated diary content	Restricted	Derived from user prompts and behaviour; treated as personal data per GDPR Recital 26.
Uploaded images	Restricted	Personal data; Google Vision moderation results are also Restricted.
User email, display name	Restricted	Personal data.
Account creation timestamp	Restricted	Personal data when joined with user ID.
Aggregated anonymous usage stats	Internal	Pseudonymised; cannot reidentify.
App version & device class telemetry	Internal	Not joined with user ID at rest.
SPYN source code	Confidential	Private repos; access via SSO.
Operational metrics (latency, error rate)	Confidential	Could reveal architecture to a competitor.
Marketing copy on spyn.app	Public	Intentionally public.

Reclassification

Classification is a property of the data, not the system. If a system starts joining datasets in a way that elevates the classification of the result, the system inherits the higher tier. The engineer who builds the join is responsible for flagging the change; Compliance signs off.

Owned by

Head of Compliance. Audited by the Master skill on a 90-day cadence.