How the data is protected

What follows is how the platform is actually built, in enough detail to be checked.

In transit

• Every page is served over TLS. There is no unencrypted route in.
• HSTS is set for two years including subdomains, so a browser that has visited once will not try plain HTTP again.
• A content security policy restricts what a page may load and refuses inline scripts and inline styles outright. This is why the software carries no third-party widgets.

At rest

Disk-level encryption is provided by our hosting provider for both the database and uploaded files.

Three columns are additionally encrypted in the application itself, so they are unreadable even to somebody holding a database dump:

• the license number, home address and telephone of a person booked onto a training class, where the association asks for them
• the postal address of somebody an association bills who is not a member
• any merchant credential held for a payment processor
• a payment's reference from the processor

The platform holds no dates of birth. It holds a home address only where an association asks for one — a person booked onto a training class, or somebody billed who is not a member — and those are encrypted as above. An association's own staff see them masked, and must enter their password again to reveal one; every reveal is recorded. The other addresses it holds are business addresses — a member company, a supplier, a conference venue — which appear in public directories by design.

Card payments

No card number ever reaches our servers. Payment details are entered on Stripe's own hosted page, on Stripe's domain. We receive an amount, a reference, and whether it succeeded.

Where an association takes cards, the money goes into their own Stripe account, not ours. We never hold an association's funds and never sit in the middle of a settlement. They connect the Stripe account they already have — no key changes hands in either direction — and what they grant is permission to create a charge, which they can withdraw from their own Stripe dashboard at any time, without telling us.

Separation between associations

Every record belongs to exactly one association, and that scoping is enforced at the base of the model layer rather than left to each query. Which association a request belongs to is resolved from the address it arrived on, before anything looks at who is signed in.

A request on an address belonging to no association is refused outright and reveals nothing about what else exists. A session belonging to one association is refused on another's address, in both directions.

Accounts and access

• Passwords are stored as bcrypt digests. We cannot read them.
• Sign-in, password reset and step-up re-authentication are rate limited.
• Revealing a home address requires re-entering a password, and both the successful reveal and the failed attempt are recorded. A class registrant's license number and telephone are shown to the association's administrators, who send them to the state registry; every download of the class list is recorded.
• Two levels of access within an association: staff can read, administrators can change.
• Where we sign in as an association to help them, a banner says so for the whole session and every action is recorded against the name of the person doing it.

The activity record

One append-only log, with a fixed vocabulary of actions. Entries cannot be edited or deleted — immutability is enforced in the model rather than left as a convention. Anything resembling a token, code, password or secret is stripped before an entry is written, because a table that cannot be edited is the wrong place to discover a mistake.

Published pages cannot be destroyed

Every published version is kept and can be restored in one action. The bucket holding published files keeps every version of every object, so a delete — ours, a mistake in our own code, or one issued by somebody holding the key — hides the current version rather than destroying what came before it.

Certifications and audits

If your procurement process needs specifics — certifications, audit history, penetration testing, data processing terms — ask and we will answer each one directly.

What we rely on

Stripe for card payments, DigitalOcean for hosting and file storage, Cloudflare for domain name service, Resend for email, and Anthropic for assisted drafting when somebody asks for it. Each receives only what its job requires, and the privacy page lists exactly what that is for each one.

There is no analytics service, no advertising pixel and no tracker of any kind.

Reporting something

If you have found a vulnerability, write to us before publishing it and we will work with you. We will not threaten anybody who reports a problem in good faith.

Questions

Write to hello@chartermarks.com and a person will answer.