Change Management Policy

Synthetic Users

---

1. Purpose

This policy defines the controls and processes used by Synthetic Users to manage changes to production systems in a controlled, auditable, and secure manner, while minimizing risk to availability, security, and customer data.

2. Scope

This policy applies to:

• Application code
• Infrastructure and cloud configuration (Render, managed services)
• Security configurations (TLS/SSL, IAM, network controls)
• AI/LLM orchestration logic and agent behavior
• Third-party service integrations

The policy applies to all employees and authorized contractors with change privileges.

3. Change Classification

Changes are categorized as follows:

a. Standard Changes

Low-risk, repeatable changes with predefined procedures (e.g. dependency updates, configuration tuning).

• Pre-approved
• Logged automatically via version control and deployment tooling

b. Normal Changes

Planned changes that may impact production behavior.

• Require peer review and approval
• Tested prior to deployment
• Deployed via controlled CI/CD pipelines

c. Emergency Changes

Changes required to address active security issues, incidents, or service degradation.

• May bypass standard approval timelines
• Must be documented and reviewed retrospectively
• Common triggers: vulnerability remediation, security misconfiguration, platform incidents

4. Change Process

a. Request & Documentation

All changes are tracked through:

• Version control (Git)
• Pull requests with documented intent, scope, and risk
• Issue tracking where applicable

Each change includes:

• Description of the change
• Risk assessment (availability, security, data impact)
• Rollback considerations

b. Review & Approval

• All non-emergency changes require peer review prior to merge
• Security-impacting changes receive additional scrutiny
• Approval is enforced via repository protections

c. Testing

Changes are validated using:

• Automated tests where applicable
• Staging or controlled pre-production environments
• Targeted validation for security and configuration changes (e.g. TLS, access controls)

d. Deployment

• Deployments are executed via CI/CD pipelines
• Production access is restricted and role-based
• Infrastructure changes are managed via platform-native controls

e. Rollback

• Rollback procedures are defined per change
• Versioned deployments allow rapid reversion if required

5. Emergency Changes

Emergency changes:

• Are logged and traceable
• Are reviewed post-implementation
• Are limited to resolving the immediate issue

Post-incident reviews document:

• Root cause
• Actions taken
• Preventive controls

6. Security & Compliance Alignment

• Security-related changes follow the Vulnerability Management Plan
• Low, medium, and high-severity findings are remediated within defined SLAs
• TLS/SSL, IAM, and network changes are validated post-deployment
• Changes are auditable and retained for compliance purposes

7. Segregation of Duties

• No single individual can unilaterally approve and deploy high-risk changes
• Access to production systems is limited to authorized personnel
• Access is reviewed periodically

8. Monitoring & Logging

• System behavior and errors are continuously monitored
• Deployment activity is logged
• Security and operational alerts trigger investigation and remediation

9. Review & Maintenance

This policy is reviewed at least annually or upon significant changes to:

• Infrastructure
• Regulatory requirements
• Security posture