Skip to content

Appcircle Change Management Policy

Effective date: 2026-02-05 Last reviewed: 2026-02-05 Policy owner: Engineering Management (Security Program Owner)

Purpose

This policy establishes Appcircle's requirements for managing changes to its software, systems, and infrastructure in a controlled, consistent, and secure manner. Effective change management reduces the risk of unplanned outages, security vulnerabilities, and unintended impacts on customers and operations.

Scope

This policy applies to:

  • Software changes: All development, modification, and deployment of Appcircle's in-house developed software and services.
  • Infrastructure changes: Changes to Google Cloud Platform environments, including networking, compute, and database configurations, managed as infrastructure as code.
  • Configuration changes: Modifications to security settings, access controls, or system configurations across production environments.

Changes to corporate tooling and supporting systems are subject to equivalent controls, proportionate to risk.

Policy principles

  • Controlled promotion: Changes progress through defined environments (development → test → production) before reaching customers.
  • Peer review: All code changes are reviewed by at least one person other than the author before being approved for release.
  • Security integration: Security requirements and non-functional considerations (reliability, scalability) are evaluated as part of each change.
  • Auditability: Changes are tracked in version control with sufficient context to support retrospective review.
  • Production data protection: Production data is not used in development or testing environments.

Software development lifecycle

Change requests

Change requests originate from internal stakeholders, customers, or operational needs and may include feature enhancements, bug fixes, security improvements, and reliability changes. All change requests are reviewed and approved by management before entering the product backlog, with consideration of functional requirements and non-functional factors including security, reliability, and scalability.

Change backlog

The backlog consolidates the change requests and product roadmap. Changes are prioritised based on impact, urgency, strategic fit, and risk.

Development and environment progression

Separate environments are maintained for development, testing, and production. Changes follow this progression:

  1. Development environment: Code changes are authored and unit-tested.
  2. Testing environment: Impact assessment, integration testing, review, and approval occur before production promotion.
  3. Production environment: Changes are deployed after satisfying all required checks.

Code review and CI/CD

  • All code changes are managed in GitHub with full version history.
  • Peer review and approval of code changes are systematically enforced.
  • The CI/CD pipeline (Jenkins) runs automated checks and orchestrates environment promotions.
  • Changes are approved for production release only after passing all required automated and manual checks.
  • Release notes are communicated to customers and users, describing changes and any relevant security considerations.

Test data

Production data is not used in development or testing environments. This is prohibited by default and requires explicit management approval and documented security controls if exceptionally permitted.

Emergency changes

Emergency changes may be required in response to major incidents where standard sequential steps cannot be completed without unacceptable risk or delay.

Emergency changes require:

  • Management approval prior to execution.
  • Documentation of the justification and scope.
  • Retrospective completion of any skipped steps where applicable.
  • A post-implementation review to confirm no adverse effects.

Emergency changes are only performed where required under the Incident Response Plan.

Roles and responsibilities

  • Engineering Management (Policy Owner): Accountable for this policy; ensures implementation, enforcement, and revision. Approves emergency changes.
  • Engineering: Implements change management practices; coordinates across teams; reports non-compliance.
  • Developers: Follow change management steps for all in-scope changes; flag security and reliability concerns during development.
  • Customer Success: Triage and raise change requests from customers; support prioritisation with impact and urgency context.

Regulatory alignment

This policy supports compliance with:

  • SOC 2 (Trust Services Criteria — Change Management)
  • ISO/IEC 27001:2022 (A.8.32 Change management)
  • GDPR (Article 25 — Data protection by design and by default)
  • KVKK (Article 12 — Data security obligations)

Exceptions

Exceptions to this policy must be:

  • Documented with justification, scope, duration, and compensating controls.
  • Approved by the policy owner or an authorised delegate.
  • Reviewed before expiry and retired when no longer required.

Policy review and updates

This policy is reviewed at least annually and when significant changes occur to development practices, tooling, or regulatory requirements.

Note

This public policy describes Appcircle's change management requirements at a high level. Detailed internal procedures (including specific approval workflows, CI/CD pipeline configurations, rollback procedures, and environment-specific controls) are maintained separately and may be shared under appropriate agreements when required.

  • Information Security Policy
  • SDLC Policy
  • Incident Response Plan
  • System Access Control Policy
  • Logging and Monitoring Policy
  • Vulnerability Management Policy