How we change the platform safely
Every platform has bugs; what a security review actually cares about is whether new changes reach your students tested, reviewed, and reversible — or whether they land on production and hope. This page describes the standard First Six holds itself to, in the same terms your assessor uses.
Every change is authorised, proven in a separate non-production environment before production, reviewed for its effect on data access, reversible, and recorded — with its documentation updated in the same change.
That sentence is SOC 2 CC8.1SOC 2 Common Criteria 8.1 — the change-management control: authorise, test, approve, and implement changes to code, data, and configuration. in miniature, and it answers the HECVAT questions about secure development and change control.
The lifecycle of a change
- Authorise and scope
A change starts from a real need. If it touches a security control — access rules, authentication, how data is stored — it is logged in our internal risk register with a tracking number before it ships, so the trade-off is written down rather than discovered later.
- Build on a branch, never live
All work happens under version control on a feature branch. Nobody edits the running system directly.
- Prove it in non-production first
Database and application changes are applied to a separate non-production environment and exercised there before they touch production. Production and non-production are different databases and different deployments, so an experiment can never write to real student data.
- Run the verification checks
A fixed checklist runs on every change: it compiles and builds, its security impact is assessed, any data change has an undo path, the user-facing result is walked through, and the documentation is updated. A change that fails any check does not ship.
- Review access and security impact
Anything affecting who-can-see-what is re-checked against automated database security advisors and a daily security workflow, and risky changes get an additional adversarial review before release.
- Deploy — reversibly
Only then does the change reach production. Every data-changing step carries a documented way to roll it back, and the committed schema is refreshed so it always mirrors what is actually running.
- Log and monitor
Privileged actions are written to an immutableAppend-only: records can be added but never edited or deleted, so the history can be trusted after the fact. audit log, and errors flow to monitoring with personal data stripped out. See the audit log.
Rigor scales with risk
Not every change gets the same weight — the process is proportionate:
- Wording or layout changes get the build + review + docs checks, then ship.
- Database changes must be proven in non-production first and must be reversible.
- Access-control or authentication changes get the full process plus the security-advisor pass and an adversarial review, and are tracked in the risk register.
- Emergency fixes during an incident may deploy directly, but the same evidence — the risk note, the non-production replay, the documentation — is completed straight afterwards. An emergency reorders the trail; it never removes it.
Continuous deployment is a security property
First Six runs a single live version, shipped continuously. There is no fleet of old releases quietly running an unpatched flaw, and never any question about which version your institution is on: a fix reaches every user the moment it ships.
Being straight about segregation of duties
SOC 2 prefers that the person who writes a change isn't the only one who approves and deploys it. First Six is a single-maintainer service, so we don't have a second human approver — and we don't pretend to.
Instead, that separation is enforced by controls that don't depend on a second person: automated gates that must pass before anything deploys, independent adversarial review of security-relevant changes, environment separation so nothing reaches production untested, and an immutable audit log that can't be quietly rewritten. Independent attestation — a SOC 2 Type II report and a third-party penetration test — is on our roadmap, and we name it as an open item rather than imply it's already done. Our HECVAT responses list those open items honestly.
Common questions
Do changes get tested before they reach our students?
Yes. Database and application changes are applied to a separate non-production environment and exercised there first. Production and non-production are isolated from each other, so testing can never touch real student data.
Can a change be rolled back if something goes wrong?
Every data-changing step is written with an undo path, and daily backups exist independently. Because there's a single live version, a corrective fix also reaches everyone immediately.
Who approves changes?
First Six is currently a single-maintainer service, so approval is enforced by automated checks, independent adversarial review, environment separation, and an immutable audit log rather than a second human sign-off. Independent attestation is a named roadmap item, not a current claim.
How do security-relevant changes get extra scrutiny?
Anything touching access rules, authentication, or how data is stored is re-checked against automated security advisors and a daily security workflow, gets an adversarial review of the change itself, and is recorded in our risk register before it ships.
Related
The fastest answer is usually one question away.