1. Purpose

This process defines how significant code changes are reviewed, approved, and deployed within Vertuna to reduce the risk of defects, security issues, or unintended impact on production systems.

2. Scope

This process applies to all significant code changes affecting:

• Production systems

• Security-related functionality

• Data handling, authentication, authorization, or encryption

• Infrastructure-as-code or deployment logic

• Public APIs or customer-facing behavior

Minor or low-risk changes (e.g., documentation updates, non-functional refactoring) may follow a simplified review path at the discretion of the Engineering Lead.

3. Definition of “Significant Code Change”

A code change is considered significant if it meets any of the following criteria:

• Impacts production behavior or availability

• Modifies security controls, authentication, authorization, or encryption

• Changes how customer or sensitive data is processed or stored

• Introduces new dependencies or major version upgrades

• Alters API contracts or externally visible behavior

• Requires database schema changes or data migration

• Addresses a high or critical vulnerability

4. Roles & Responsibilities

Change Author

• Prepares the code change

• Ensures adequate testing

• Documents the intent, scope, and risk of the change

Reviewer (Peer Engineer)

• Reviews the code for correctness, security, and maintainability

• Confirms tests and scans have passed

• Provides approval or requests changes

Engineering Lead

• Provides final approval for significant or high-risk changes

• Ensures process compliance

• Authorizes production deployment when required

5. Process Steps

Step 1: Change Preparation

• Code is developed in a non-production environment

• Automated checks are executed, including:

  • Build validation

  • Unit/integration tests (where applicable)

  • Static analysis and dependency scanning

• The change author prepares a pull request (PR) describing:

  • Purpose of the change

  • Impacted components

  • Risk level (low / medium / high)

  • Rollback considerations (if applicable)

Step 2: Peer Review

• At least one qualified peer engineer must review the change

• Review must cover:

  • Code quality and correctness

  • Security implications

  • Compliance with internal standards

  • Test coverage adequacy

• Review feedback must be addressed before approval

Step 3: Approval

• Medium-risk changes require:

  • Peer approval

• Significant or high-risk changes require:

  • Peer approval and

  • Explicit approval from the Engineering Lead

• Approvals are recorded via the version control system (e.g., pull request approval)

Step 4: Deployment

• Approved changes are deployed using controlled deployment mechanisms

• Only authorized personnel may deploy to production

• Deployment should follow established release procedures

Step 5: Post-Deployment Validation

• Production systems are monitored after deployment

• Any unexpected behavior is investigated immediately

• Rollback procedures are executed if required

6. Emergency Changes

In case of urgent security fixes or production incidents:

• Changes may be fast-tracked with Engineering Lead approval

• Peer review may occur after deployment if time-critical

• Emergency changes must be documented and retrospectively reviewed

7. Evidence & Record Keeping

The following artifacts serve as evidence of compliance:

• Pull request descriptions

• Code review comments and approvals

• Automated test and scan results

• Deployment logs (where available)

8. Review & Maintenance

This process is reviewed:

• At least annually, or

• Following a significant incident or system change

9. Ownership

• Process Owner: Engineering Lead

• Approved By: Company Leadership

• Version: 1.0

• Last review: 07 Jan 2026