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 of a person being certified at a training class
• any merchant credential held for a payment processor
• a payment's reference from the processor

The platform holds no dates of birth and no home addresses. The addresses it does hold 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 the processor's own hosted page, on the processor's domain. We receive an amount, a reference, and whether it succeeded.

Where an association takes cards, the money goes into their account, not ours. We never hold an association's funds and never sit in the middle of a settlement. The association grants us permission to create a charge on their account and can withdraw that permission from their own processor 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 or changing a sensitive field requires re-entering a password, and both the successful reveal and the failed attempt are 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 storage credentials used for published artifacts can write and read but cannot delete.

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.

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.