Secure development and change control policy

October 9, 2026

Purpose and approval

Senior management must approve this documented software development lifecycle (SDLC) and change-control policy before it takes effect. It applies to internally developed software, plugins, integrations, scripts, configuration, infrastructure, and third-party software or firmware changes supporting customer services. Record the approval, policy version, and effective date, communicate responsibilities to developers and operators, and review the policy at least annually and after significant changes. This policy supports the Information security program.

Development lifecycle

Change control is part of the development lifecycle: record requirements and security risks; design appropriate safeguards; develop in version control; perform independent review and security testing; obtain approval; deploy through an authorized process; validate operation; and maintain or retire the change securely. Use one issue and linked pull request or deployment record where possible to avoid duplicate paperwork. Include authentication, authorization, input validation, protection of secrets, dependency maintenance, and customer-data handling in design and review.

Development and production separation

Use only synthetic data or irreversibly anonymized data in development and test environments. Apply the production security controls relevant to those environments, including access control, encryption, logging, updates, and monitoring. Do not copy identifiable production records, uploaded files, logs, credentials, or live integration tokens into test systems. Masking or pseudonymization that allows re-identification is not sufficient. Keep test and production credentials and integrations separate.

Developers must not have direct access to production systems, databases, or customer information. Use a separately authorized operator or deployment automation protected by an independent approval gate. Developers must not be able to bypass that gate, retrieve production secrets, or modify the deployment process to grant themselves access. Any emergency developer access must be individually approved, time-limited, logged, and reviewed, and must be disclosed as an exception when answering a question that prohibits direct developer access.

Security validation before deployment

Before production deployment, validate and test firmware, software, applications, and changed source code for vulnerabilities. Use appropriate code review, automated source and dependency scanning, secret scanning, configuration checks, and functional security tests. For Moodle changes, check affected permissions, authentication, data access, and plugin compatibility. For vendor firmware or software without source access, verify provenance or signatures where available, review vendor advisories and available security evidence, and test applicable configuration and runtime behavior in a safe environment. Record what was tested, results, limitations, and unresolved findings. Resolve unacceptable findings before release, and manage remaining findings through the information security program’s risk and remediation process; unsupported testing must be recorded as a gap.

Change records and approval

Record every regular and emergency change in a ticket or equivalent controlled record before implementation. Include the purpose, affected systems and customers, owner, risk and impact, security and functional test results, implementation steps, schedule, communications, and back-out plan. Link the relevant source revision and build or release identifier where applicable.

Management or an explicitly delegated management approver must approve every regular and emergency change before implementation. The approver must be different from the person implementing the change. Document and communicate the implementation plan, expected impact, and back-out plan to the relevant staff, providers, and affected customers before initiation, as applicable to their responsibilities and service impact. For urgent work, a short recorded approval and communication is sufficient, but retrospective approval alone does not satisfy this requirement.

Back-out planning

Every regular and emergency change must have a documented and tested back-out plan before production implementation. Specify rollback triggers, decision authority, steps, required backups or restore points, and verification of restored service. Where a direct reversal is impossible, test a recovery or forward-correction route that restores an acceptable service and data state. A previous test may be referenced only if it covers the same procedure and relevant versions and conditions; otherwise test in staging before proceeding. A written plan without a successful relevant test is insufficient. If urgency makes testing impossible, record an explicit exception and do not claim full compliance with a requirement for tested plans for all changes.

Deployment, verification, and closure

Only authorized operators or controlled automation may deploy approved changes. Use least privilege, protect production secrets, and retain deployment logs. After deployment, verify service health, security controls, customer-data integrity, and relevant functionality. Activate the back-out plan if acceptance checks fail. Record the outcome, reviewer, and any follow-up issues. Review emergency changes promptly after implementation to identify improvements, without replacing the required advance approval.

Exceptions and records

Maintain approvals, test evidence, back-out test results, communications, source revisions, deployment outcomes, and exceptions in linked issues, pull requests, or maintenance records accessible only to authorized people. Management must approve exceptions with a reason, risk, temporary safeguards, owner, and expiry or review date. Exceptions do not override customer commitments or make an unmet questionnaire requirement satisfied.