SOC 2 Configuration Management Policy

Purpose and Scope

This policy outlines the procedures and controls for managing changes to our organization’s IT infrastructure, applications, and systems. It applies to all employees, contractors, and third parties who are involved in making changes to our production environment.

Change Management Process

Change Initiation and Approval

• Large change proposals are discussed and approved during biweekly architecture meetings.
• All application or infrastructure changes must be initiated through Git pull requests (PRs).
• PRs must undergo code review before they are merged and deployed.
• All configuration changes must be tested in the staging environment prior to being deployed in production.

Change Categories

Changes are categorized as follows:

• Standard: Regular changes that follow the normal process.
• Emergency: Urgent changes that may require an expedited process.

Change Implementation

• All code and infrastructure changes must be committed to Git repositories.
• Infrastructure is managed as code, with Dockerfiles describing VMs and TOML files for Fly VM configuration.
• Changes to production require merging to the “prod” branch in Git, which is restricted.
• Changes to staging require merging to the “main” branch in Git, which requires code review and successful CI.

Testing and Validation

• A staging environment, which mirrors production in all but scale, is used for testing changes before deployment.
• Continuous Integration (CI) checks must pass before merging changes.

Deployment

• Deployment is managed through Fly, using Docker containers and configuration files.
• Environment secrets are supplied via Doppler integration with Fly.

Post-Implementation Review

All production changes are logged in a dedicated Slack channel for change control.

Environment Management

• The organization maintains three separate environments: development, staging, and production.
• Environmental separation is enforced in Fly and Doppler.

Version Control

• Git is used for version control of all code and infrastructure configurations.
• Rollbacks can be performed to any previous code or infrastructure version.
• Database rollbacks may require reverting to a prior snapshot.

Access Control

• Access to make changes is restricted based on environment and Git branch.
• Only authorized individuals can merge changes to the “prod” and “main” branches.

Emergency Changes

• Emergency changes are coordinated via Slack.
• A fast review process with sanity checks (+1) is used for urgent situations.

Asset and Configuration Management

• An inventory of IT assets and configurations is automatically maintained through Fly command-line tooling.

Tools and Systems

The following tools are used for configuration management:

• Git: Version control and code review
• Fly: Deployment and infrastructure management
• Slack: Change coordination and logging
• Doppler: Secrets management
• Cloudflare: DNS and Zero Trust configuration

Policy Review and Update

This policy is reviewed and updated as needed during the biweekly architecture meetings.

Compliance and Audit

• All changes must comply with this policy.
• Regular audits will be conducted to ensure adherence to the policy and identify areas for improvement.

Training

• All personnel involved in the change management process will receive training on this policy and associated procedures.

Responsibilities

• All team members are responsible for adhering to this policy when proposing or implementing changes.
• The architecture team is responsible for overseeing the change management process and updating this policy.