Change management policy

How changes to our SaaS products, infrastructure, organisation and ISMS are planned, checked for security impact and kept traceable. It applies to everyone who changes code, configuration, servers, suppliers, access or the ISMS.

Annex A controls: 5.8, 8.19, 8.32. It also covers ISO 27001 clause 6.3, planning of changes.

Small and big changes (8.32)

• Small change: code, configuration or documentation within an existing system, supplier and way of working, such as a feature, a bug fix, a dependency update, a version upgrade or the configuration of an existing service. Route: a merge request.
• Big change: a new supplier, tool or SaaS service; a new product, or a new kind of data such as personal data; someone joining, leaving or changing roles; a new, moved or removed server; a change to networks, firewalls, backups, authentication or monitoring; a change to the ISMS. Route: an issue reviewed by the Information Security Officer, then merge requests.

When in doubt, treat a change as big.

Small changes (8.32)

• Every change to code, configuration and infrastructure is made in Git and reaches the main branch only through a merge request. The main branch is protected.
• The pipeline (linting, tests) passes and someone other than the author reviews the merge request, following the code review conventions and the secure development policy.
• A merge to the main branch deploys to staging; production releases come from the release branch or a release tag, as described in branching and deployments.
• Dependency updates arrive as Renovate merge requests. Minor and patch updates with a green pipeline merge automatically without a review; the others are reviewed like any change. See external dependencies.
• A hotfix is first fixed on the main branch through a reviewed merge request and then brought to production, as in hotfixes.
• A failed deployment is rolled back by deploying the previous build, which stays available because images are pinned to immutable tags.

Infrastructure changes (8.32)

• Servers are configured through Ansible in the infra repository and applications are deployed through Coolify from Git, as in Coolify or Ansible.
• New infrastructure is described in the infra repository as in new infrastructure; removed infrastructure follows infrastructure teardown.
• Planned work that interrupts a service runs in a maintenance window: announce it in the alert channel, silence the expected alerts, take a snapshot when data could be lost, do the work, then lift the silence and announce the result.
• In an incident, Infrastructure may change a system directly to restore it. The change is recorded in the incident issue and made permanent in Git through a merge request afterwards.

Software on operational systems (8.19)

• Software reaches servers only through Ansible, run by Infrastructure, or as container images that Coolify deploys from Git. Nobody installs software on a production server by hand, except as an emergency change in an incident.
• Software comes from the operating system’s repositories, the official releases of the upstream project, or official container images, pinned to a specific version.
• Version upgrades of server software are small changes: a merge request that changes the pinned version, applied in a maintenance window when the service is interrupted.
• Development machines are not operational systems; their users manage their own software.

Big changes (8.32, 5.8)

1. The person who wants the change opens an issue in the project it concerns, or in dc/dcentralize/general when it concerns the organisation. The issue describes the change, the information and systems it affects, and why.
2. They assign the issue to the Information Security Officer with the workflow::Review label, as in requesting an opinion.
3. The Information Security Officer records the security impact in a comment: new risks for the risk register, and the controls the change needs, such as a processing agreement for a new supplier (supplier management), access rights (access control), or backups and monitoring for a new server (business continuity). The comment approves the change or states what must happen first.
4. The work itself follows the small change route. The merge requests link to the issue, and the issue is closed when the change and its documentation are done.

Joiners, movers and leavers follow onboarding and offboarding. Each of them has an issue, which is the big change record.

Security in projects (5.8)

• Every epic states, next to its goal and scope as in epics, its security requirements: which information it handles and its classification (information handling), whether personal data is involved, who needs access, and which suppliers it adds.
• An epic that brings a big change follows the big change route before its work starts.
• The definition of done includes a code review.

Changes to the ISMS (clause 6.3)

• Changes to the ISMS, such as a new product in scope, a new or changed policy, or a change of roles, are big changes. Their issue states the purpose of the change and its consequences, and links to the ISO 27001 certification epic.
• The change itself is a merge request on the handbook, reviewed by the Information Security Officer. Management approves changes to the scope and the policies.

Responsibilities

• The Information Security Officer owns this policy and reviews every big change.
• Infrastructure carries out infrastructure changes and maintenance windows, and runs the Ansible configuration of the servers.
• Project leads make sure the epics of their product state their security requirements.
• Employees make their changes through merge requests and review those of others.
• Management approves changes to the ISMS scope and policies.

Review: yearly by the Information Security Officer.