Production configuration changes must have a rollback path

Control Statement: Changes to production configuration must have a rollback path defined before they are applied.

Description: A rollback path is a prepared way to return the configuration to its state before a given change: a previously installed package version that can be reinstalled, an export of the element taken before editing, or a documented reverse procedure. “We would delete it”, said after the fact, is not one. Changes made directly in production are the case this control exists for — a deployment pipeline usually keeps what it deployed, while a direct edit keeps nothing unless somebody chose to.

Rationale: Configuration changes in Creatio take effect for every user the moment they are saved. When a change misbehaves, the difference between a short incident and a long one is whether the way back was prepared while everything still worked. Reconstructing what a process or page looked like before, from memory, under pressure, is how a second incident gets caused while fixing the first.

Audit Procedure:

1. Confirm the organisation defines a rollback path for production configuration changes.
2. Sample recent changes and confirm each had one before it was applied.
3. Confirm each rollback path names the state it returns to — a package version, an export, or a documented procedure.
4. Confirm changes made directly in production are covered, not only those arriving as packages.

Remediation:

1. Decide the forms a rollback path may take and record them.
2. For changes arriving as packages, retain the previously installed version.
3. For direct changes, capture the element’s state before editing it.
4. When no way back can be defined for a change, refuse the change, not the rollback.

Default Value: Creatio applies configuration changes immediately. It records what changed, but does not maintain a prepared way back to the previous state; returning to it is a manual reconstruction unless one was prepared in advance.