Change management policy
How changes to application code, database schema, access controls, configuration, and infrastructure are authorised, tested, reviewed, deployed, logged, and documented — the single named policy for secure-SDLC reviews.
What this policy commits us to
- Every change is authorised, proven before production, reviewed for access and security impact, reversible, logged, and has its documentation updated in the same change.
- Any change touching RLS, grants, auth, or secrets re-runs the database security advisors and gets an adversarial review pass before shipping.
- Segregation of duties is achieved through automated and independent-review controls rather than a second human approver — stated honestly for the single-maintainer reality.
- Every writing migration carries a plain undo path, or a snapshot is taken first.
- Emergency changes back-fill the same evidence trail immediately after deployment.
Controls mapped to this policy
Mapping controls to the policy is how we check adherence. A green dot marks a control that is operating and traceable to evidence; an amber dot marks one that is documented and scheduled but has not run yet.
- Dependency vulnerability scanningApplications
- CI build and test gatesApplications
- Immutable deploymentsCloud infrastructure
- Secret scanningCloud infrastructure
- Schema capture and drift detectionCloud infrastructure
- Environment separation (non-production mirror)Cloud infrastructure
- Nine-step change lifecycleProduct delivery
- Risk-scaled change classesProduct delivery
- Migration reversibilityProduct delivery
- Security review of access-touching changesProduct delivery
- Docs-go-with-code ruleProduct delivery
- Compensating controls for segregation of dutiesProduct delivery
- SIS integration end-to-end proofProduct delivery
Standards mappings
Through its controls, this policy maps to the following standards and frameworks. Each entry states our real relationship with the standard.
ISO/IEC 27001:2022InfoSec complianceSelf-assessed
A full 93-control Annex A Statement of Applicability is maintained and honestly dispositioned, and the ISMS went live on 26 July 2026 with its first completed management review. Not certified: no external audit has occurred, the clause 9.2 internal audit is openly unmet, and the certification trigger (a named tender, funding, or first hire) was formally decided at the first management review.
- A.8.8Management of technical vulnerabilities
- A.5.21Managing security in the ICT supply chain
- A.8.29Security testing in development and acceptance
- A.8.19Installation of software on operational systems
- A.8.24Use of cryptography
- A.8.9Configuration management
- A.8.32Change management
- A.8.31Separation of development, test and production environments
- A.5.3Segregation of duties
SOC 2 (AICPA Trust Services Criteria)InfoSec complianceAligned
Controls are explicitly mapped to the criteria — change management to CC8, logging and monitoring to CC7, access control to CC6 — but no SOC 2 attestation of any type exists. Independent attestation is a tracked roadmap item, offered as a contractual milestone for a pilot.
- CC8.1Change management
- CC7.4Incident response and recovery
- CC6.1Logical access security
- CC2Communication and information
HECVAT (Higher Education Community Vendor Assessment Toolkit)Higher educationSelf-assessed
A full HECVAT answer pack is maintained and kept current for university procurement, deliberately honest about gaps (no SOC 2 or ISO attestation, no independent penetration test, PITR not enabled). It is a vendor self-assessment, not an externally validated response, backed by a full internal HECVAT-aligned self-audit.
- SDLCSecure development lifecycle
- VulnMgmtVulnerability and access-control management
- DocsDocumentation currency
Request access and we can share the full policy set, assessment reports, and completed questionnaires under NDA — or answer your security questionnaire directly.