Change Management Policy

This Change Management Policy ("Policy") establishes the formal process for managing changes to FindTheBreach production systems, infrastructure, and application code. The objective is to minimize the risk of service disruption while enabling the rapid, secure delivery of platform improvements. This Policy is aligned with SOC 2 CC8 (Change Management), ITIL v4 change management practices, and ISO/IEC 27001:2022 Annex A.8.32.

Scope. This Policy applies to all changes affecting:

• Production application code, API endpoints, and frontend components
• Docker container images, Dockerfiles, and container orchestration configurations
• PostgreSQL database schemas, stored procedures, migrations, and configuration parameters
• Scanner tool integrations and configurations (all 35+ scanning tools)
• Network infrastructure, firewall rules, DNS records, and load balancer configurations
• Security controls including encryption configurations, authentication mechanisms (MFA/TOTP), and access control rules
• Third-party integrations, API keys, webhooks, and SSO configurations
• Operating system patches, library updates, and dependency upgrades

This Policy does not apply to changes in non-production development environments that are isolated from production data and infrastructure, though such environments should follow the spirit of this Policy as a best practice.

All changes are classified into one of three categories based on risk, complexity, and urgency. The category determines the approval workflow, testing requirements, and documentation level.

All Normal and Emergency changes must be initiated through a formal Change Request (CR). Standard changes are pre-approved but must still be logged for audit purposes.

Change Request Contents. Each CR must include:

• Description: Clear summary of the proposed change, including the business or technical justification
• Scope & Impact: Systems, services, and data affected (e.g., Docker containers, PostgreSQL databases, API endpoints, scanner tools)
• Risk Assessment: Likelihood and impact of failure, including potential data loss, downtime, or security implications
• Implementation Plan: Step-by-step deployment procedure including commands, configuration changes, and expected outcomes
• Rollback Plan: Detailed procedure to reverse the change if issues are detected (see Section 7)
• Testing Evidence: Summary of testing completed in staging/pre-production environments
• Scheduling: Proposed implementation window, preferring low-traffic maintenance windows for high-risk changes
• Communication Plan: Stakeholders to notify before, during, and after the change

Approval requirements are determined by change category. No change may be implemented in production without the required approvals, except as provided under Emergency procedures.

• Standard Changes: Pre-approved by the CAB as a class. Individual changes require only a peer code review (minimum one reviewer) before merge and deployment. All standard changes are logged automatically.
• Normal Changes: Require (a) peer code review by at least one qualified reviewer, (b) approval from the technical lead or engineering manager, and (c) approval from the CISO or designated security reviewer for changes affecting authentication, encryption, access control, or scanner tool configurations. The approver must not be the same person as the change requester (separation of duties).
• Emergency Changes: May be approved verbally by the CISO or on-call engineering lead for immediate implementation. Written approval, full CR documentation, and CAB retroactive review must be completed within 48 hours of implementation. All emergency changes are flagged for mandatory post-implementation review.

Separation of Duties. The person who develops a change must not be the sole approver or the sole deployer of that change to production. At minimum, a separate individual must review and approve the change before deployment.

All changes must be tested in a non-production environment before deployment. The level of testing required is proportional to the change category and risk.

• Unit Testing: Required for all code changes. Automated unit tests must pass with no regressions. New functionality must include corresponding test coverage.
• Integration Testing: Required for Normal and Emergency changes affecting API endpoints, database interactions, scanner tool integrations, or inter-service communication. Tests must validate end-to-end data flow within Docker-based staging environments.
• Security Testing: Required for changes affecting authentication (MFA/TOTP), authorization (RBAC), encryption (AES-256-GCM), input validation, or API security. Includes static analysis, dependency vulnerability scanning, and manual security review as appropriate.
• Performance Testing: Required for changes expected to impact query performance, API response times, or scanner execution times. Baseline performance metrics must be compared before and after the change in staging.
• Database Migration Testing: All PostgreSQL schema changes must be tested against a copy of production data (anonymized where necessary). Migration scripts must be verified for forward compatibility, idempotency, and rollback capability.

Emergency Exceptions. Emergency changes may have abbreviated testing requirements, but must include at minimum a smoke test in staging (or production canary) before full rollout. Full testing must be completed retroactively within 5 business days.

Changes are deployed to production following the approved implementation plan. All deployments must adhere to the following requirements:

• Deployment Pipeline: All code changes are deployed through the CI/CD pipeline. Direct manual changes to production systems are prohibited except during approved emergency procedures.
• Docker Image Versioning: All Docker images deployed to production must be tagged with a unique version identifier (e.g., git commit SHA or semantic version). The latest tag is never used in production.
• Maintenance Windows: High-risk Normal changes should be scheduled during designated maintenance windows (low-traffic periods). Customers must be notified at least 48 hours in advance for changes expected to cause downtime.
• Monitoring: Enhanced monitoring must be active during and after deployment. Key metrics include API error rates, response latencies, database connection pool utilization, scanner success rates, and container health status.
• Audit Logging: All deployment actions are logged with deployer identity, timestamp, change reference number, Docker image version, and deployment outcome.

Every change must have a documented rollback plan before implementation. The ability to revert a change quickly and safely is a critical requirement for production deployments.

• Application Rollback: Docker containers can be rolled back to the previous known-good image version within minutes using versioned image tags. The previous image version is always retained in the container registry for at least 30 days.
• Database Rollback: All PostgreSQL schema migrations must include a corresponding down-migration script. Before applying destructive migrations (column drops, table removals), a point-in-time database snapshot is taken. Rollback to the pre-change state must be achievable within the defined RPO (1 hour).
• Configuration Rollback: Infrastructure and application configuration changes are version-controlled. Previous configurations can be restored from the version control system.
• Rollback Triggers: A rollback must be initiated immediately if: (a) error rates exceed 5× baseline within 15 minutes of deployment, (b) critical functionality is degraded, (c) a security vulnerability is introduced, or (d) data integrity issues are detected.
• Rollback Authority: Any member of the on-call engineering team may initiate a rollback without additional approval. Rollback events must be documented and reported to the CISO within 4 hours.

Post-implementation reviews (PIRs) ensure that changes achieved their intended objectives and did not introduce unintended consequences.

• Mandatory PIR: All Emergency changes and any Normal change that resulted in a rollback, incident, or unplanned downtime require a formal PIR within 5 business days of implementation.
• Routine PIR: Normal changes are reviewed as part of the weekly engineering review. Standard changes are sampled monthly for quality assurance.
• PIR Contents: The review must assess: (a) whether the change achieved its stated objectives, (b) whether the implementation followed the approved plan, (c) any incidents or issues encountered during or after deployment, (d) effectiveness of testing and rollback procedures, and (e) lessons learned and improvement actions.
• Metrics Tracked: Change success rate, mean time to deploy, rollback frequency, emergency change ratio, and change-related incident count. These metrics are reported to executive management quarterly.

Comprehensive documentation is required for all changes to support audit readiness, incident investigation, and knowledge transfer. All change records are retained for a minimum of three (3) years.

• Change Log: A centralized, tamper-evident change log records every production change including: change reference number, category, requester, approver(s), implementation date/time, systems affected, Docker image versions (before and after), and outcome (success/rollback/partial).
• Code Review Records: All peer review comments, approvals, and discussions are retained in the version control system (Git). Pull request history serves as the primary code review record.
• Test Evidence: Test results, including pass/fail status and coverage reports, are archived for each change. Automated CI/CD pipeline logs serve as test evidence for automated tests.
• Deployment Records: CI/CD pipeline execution logs, deployment timestamps, and container image digests are retained as deployment evidence.
• Emergency Change Records: Emergency changes must have complete retroactive documentation including the CR, justification for expedited process, verbal approver identity, and retroactive CAB review outcome — all within 48 hours.

This Policy is reviewed at least annually by the CISO and approved by executive management. Ad-hoc reviews are triggered by significant change-related incidents, audit findings, or material changes to the platform architecture or deployment processes.

• Version Control: This Policy is maintained under version control. All revisions include a change summary, effective date, and approval record.
• Training: All engineering and operations personnel receive training on this Policy during onboarding and upon significant revisions. Refresher training is provided annually.
• Exceptions: Exceptions to this Policy require written justification, compensating controls, a defined expiration date, and approval from the CISO. Exceptions are tracked in the risk register.