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. Here is the standard First Six holds itself to, in the same terms your assessor uses.

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

1. 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.

2. Work under version control, never edited live

   All work happens under version control. As a single-maintainer operation, routine changes are committed to the main line after the verification loop below; genuinely risky changes take a separate branch and a preview deployment first. Nothing is edited directly on the running system outside the tracked source.

3. Prove it away from live data first

   A separate non-production project now stands for pre-production testing, and schema changes land on both databases. Development and preview builds still connect to the production database; moving them across is the open half of the split, tracked openly in our risk register. Until that completes, any verification that must run against live data is read-only or wrapped in an immediately rolled-back transaction, and is recorded.

4. 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.

5. Review access and security impact

   Anything affecting who-can-see-what is re-checked against automated database security advisors and a security workflow that runs both daily and as a guard within minutes of any change that could affect it, watched by an external liveness monitor; risky changes get an additional adversarial review before release.

6. 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.

7. 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 are proven away from live data 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.

Segregation of duties

Instead, that separation is enforced by controls that don't depend on a second person: automated checks that run on every single change and fail loudly (they run alongside deployment rather than blocking it, which we state plainly because a reviewer will ask), internal adversarial review of security-relevant changes (a review pass separate from the author's own work, though internal rather than third-party), testing away from live data so nothing reaches production unproven, 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 is not in place today. Our HECVAT responses carry the same open items.

Common questions

Related