Change Control: Backup, Restore, and Documenting Changes

Backups should be performed regularly to ensure minimal data loss in case of an emergency. Recommended backup frequencies:

• Daily: Critical systems, such as databases containing business-critical data (renewals, contracts, etc.)
• Weekly: Systems with lower changes or less critical data
• Monthly: Archival backups of older systems

Only certain users should be allowed to restore backups to prevent unauthorized changes or data loss. Typically:

• Admins should have full control over backup and restore operations.
• Ensure that only trusted, experienced admins perform restores. If possible, require a second admin review for critical restores.
• Document every restore operation, including who performed it and why it was necessary.

Every change made to the system, especially database restores, configuration changes, or code updates, should be documented:

• Change Reason: Why was the change necessary? (e.g., restore due to data corruption, configuration change to fix SMTP)
• Time and Date: Record the exact time the change occurred.
• Person Responsible: Who performed the change?
• Change Impact: What was affected by the change? (e.g., downtime, data loss, access changes)

Before making any changes to system configurations, it is recommended to implement a review process:

• Document the proposed change
• Get approval from a senior admin or a team lead
• Test the change in a staging environment before deploying to production