Security & Data Handling

Systeric builds tools for businesses whose data is not abstract. Our clients span healthcare, financial institutions, and service providers, and the records running through what we build are identity documents, health records, and payment details belonging to real people. Seedr’s patients hand over their NRIC and medical history to get seen by a doctor. That data is theirs, not ours.

The default posture is simple: treat every client’s data the way you would want your own patient file treated. Not “compliant enough.” As if it were your own.

Classify before you build#

Not all data carries the same weight. Before a feature touches a field, know which bucket it is in.

Class	Examples	Handling
Sensitive	NRIC/identity documents, health and medical records, payment details, auth tokens, passwords	Encrypt at rest and in transit, mask in every non-production surface, log only that an operation happened, never the value
Identifying, not sensitive	Name, email, phone number	Access-controlled, not broadcast to every log line or third-party tool by default
Not sensitive	Aggregate counts, feature usage, timestamps	Free to log, chart, and share internally

When a new field doesn’t obviously fit, classify it as sensitive until someone says otherwise. Downgrading later is cheap. Discovering a leak later is not.

Least data#

The safest sensitive data is the data you never captured. Before adding a field or a log line, ask: do we need this to do the job, or would it just be convenient to have?

Collect only what the feature requires. Don’t capture a field “in case it’s useful later.” That’s a liability sitting in the database waiting for a breach to matter.
Don’t log sensitive fields. A stack trace that includes an NRIC or a health note is a leak with a timestamp. Log the operation and its identifiers, not the payload.
Mask by default in anything that captures a screen. Session Replay already does this: maskAllInputs on every field, data-mask on sensitive text. That same discipline applies anywhere a user’s screen or a request body could be captured, replay tools, logs, traces, support tickets. If a system can see what’s on screen, assume it will eventually see something it shouldn’t unless you mask first.
Retention is part of least data. Data with no ongoing purpose is a candidate for deletion, not a decision to defer.

Privacy by default, not by request#

Privacy is a setting you start with, not one a user or a client has to ask for. Concretely:

New sensitive surfaces get masked or access-controlled as they’re built, not patched afterward when someone notices.
Debugging a production issue does not require looking at real patient data. Reach for the trace and the redacted replay first. If you must look at raw data, that’s the exception, not the workflow.
Access to sensitive data is scoped to the people who need it for their actual job, not the whole team by default. See Secrets & Access for how that’s enforced day to day.

When in doubt, the same rule Session Replay uses applies everywhere: masking too much costs you a little convenience; masking too little is a leak. That trade is not close.

A breach is not downtime#

An outage is embarrassing and costs money. A data breach is different in kind: someone’s identity document, someone’s medical history, is now somewhere it should never be, and that doesn’t undo when the incident closes. Treat the two with different urgency and different judgment.

Downtime gets fixed and life goes on. A leak of sensitive data means a real person is now exposed, possibly for years.
A near-miss (a sensitive field almost logged, an unmasked surface caught before launch) is worth treating like a real incident retrospective, not a shrug. See The Team on surfacing problems early rather than absorbing them quietly, this is exactly the kind of thing that should be said out loud the moment it’s noticed.
If a real exposure happens, it follows the same discipline as any other production incident: declare it, stabilize it, and write it up honestly. See Incidents & Postmortems.

This document sets the posture, not a formal compliance program; none is established at the studio level today. Treat it as the floor, not a substitute for whatever a specific client’s contract or regulation adds on top.