What protects your members' data

Where your data lives, who can reach it, and what happens if the worst does.

• Tenant isolation

  One organization cannot read another

  In place

  The separation is enforced by the database, not by the application. A request that arrives without an organization attached gets nothing back rather than everything.

• Residency

  Your data is stored in Canada

  In place

  The database runs in Toronto and is reachable only from our own servers on a private network, never from the open internet.

• Residency

  Member files stay in Canada, including the backup

  In place

  Uploads and data-request bundles are stored in Toronto. The nightly backup copy is made server to server inside the same region, so those files never leave the country at any point.

• Backups

  The database is backed up daily

  In place

  Automatic daily backups, plus the ability to rewind to any moment in the last week.

• Recovery

  We have never done a full practice restore

  Not yet

  The backups exist. The restore has never been rehearsed end to end, so we cannot tell you how long a recovery would take, and we will not quote a number until we have run one. No end-to-end restore has been performed against the member database, so no recovery time objective is known or claimed.

• Backups

  Support and internal systems are backed up offsite

  In place

  Encrypted every night and copied off the machine they came from, kept for 35 days. This covers support conversations and internal tooling, not member records.

Leaving should cost nothing, and a member who asks to be forgotten should actually be forgotten.

• Portability

  Export everything, whenever you want

  In place

  Every record we hold for your organization, in JSON, CSV or SQL, on demand. No charge and no support ticket. Each export is recorded in the log.

• Erasure

  A member can be erased without breaking your books

  Partly done

  Personal details are erased in place while invoices and payments stay intact and anonymous. The backup copy of a member's uploaded files is deleted at the same time as the live copy, whether or not the live copy is still there. That step is not switched on in production yet, because the restricted storage credential it needs does not exist, and every run says so in its own logs. Until it does, a deleted file can survive in the backup copy.

• Rights requests

  Member data requests run on a tracked clock

  In place

  A request is logged with a due date 30 days out and your staff can see it. One extension is allowed, and taking it has to be recorded.

• Payments

  Card numbers never reach us

  In place

  Payment details go straight to our processor. We hold a token and a receipt, never a card number.

What we can show you about what happened, and where that record is still thin.

• Audit log

  The log cannot be altered without it showing

  In place

  Every change is written to a sealed log where each entry is bound to the one before it. Alter a record and the chain breaks where it was altered.

• Audit coverage

  Sign-ins are not logged yet

  Partly done

  Changes to records are logged. Authentication events are not, so the log cannot yet answer who signed in and when. Sign-in, sign-out, failed-login and session-revocation events are not written to the audit log, so the trail cannot reconstruct account access.

• Audit log

  The log has no copy outside the system it records

  Not yet

  The sealed log lives in the same database as the records it describes. Anyone who could reach the database could reach both. No append-only copy of the audit chain exists outside the primary database, so a sufficiently privileged actor could alter records and the log describing them together.

• Logging

  Personal details are kept out of the log

  Partly done

  Application logs record what failed and where, not who it happened to. On paths that handle personal data the exception type is recorded rather than its message. Coverage is a naming-pattern grep plus a shared exception helper, not a type-aware guarantee. A log call that formats personal data through an unrecognised path would not be caught. No cross-file data-flow analysis runs today.

Who else touches member data, and what we will never do with it.

• Data use

  We never sell or share member data

  In place

  No advertising platforms, no data brokers, no tracking pixels, and no analytics product that receives personal data.

• Transparency

  Every third party is named

  In place

  The vendors that touch member data are listed publicly with what each one receives and where it stores it.

The habits and gates behind the software, including the ones we have not built yet.

• Access

  Nobody else has access

  In place

  Sembr is one person. No contractor, agency or third party holds a credential to the production systems.

• Release gate

  Known vulnerabilities block a release

  In place

  Every change runs dependency, secret and static-analysis scans, and a known vulnerability fails the build rather than filing a note.

• Release gate

  The isolation rules are enforced by the build

  In place

  The rules that keep organizations separate are checked by the build itself, so breaking one fails a pull request instead of reaching production.

• Incident response

  The breach procedure has never been rehearsed

  Partly done

  A written breach procedure exists. It has not been practised, so we do not know how long the steps in it actually take. No tabletop or live rehearsal of the breach-notification procedure has been run, so notification timelines are written rather than measured.

• Independent assurance

  No outside party has reviewed any of this

  Not yet

  No penetration test, no independent code review, no privacy counsel review, no accessibility audit and no certification against any framework. Everything on this page is our own assessment of our own work. No SOC 2 report, ISO certification, penetration test, independent code review, privacy counsel review or accessibility audit exists. Every claim in this register is self-attested and evidenced from our own systems.