Change Management Policy

Purpose and scope

Alta Vista (“the Company”) — the operator of the Alta Vista client-reporting product at myaltavista.com and The Alta Vista Way personal budgeting service at thealtavistaway.com.

This policy defines how changes to the Company’s software, database schema, infrastructure configuration, and vendor settings are proposed, tested, approved, deployed, and, when needed, reversed. It applies to every production install.

The Company is a small, founder-operated business. The Security Owner is the founder, who is also the sole engineer with production access. Where a policy refers to a governing body, that body is the Company’s ownership, which reviews the security program on the cadence stated in the Information Security Policy. Policies are written so that they apply unchanged as staff are added: every clause that says “personnel” binds any future employee or contractor from their first day.

Source control

• All application code, database migrations, hosting configuration, and CI definitions live in a private Git repository. The main branch is the deployable state of the product.
• Changes are made on branches and merged through pull requests. Commits are small and describe their intent.
• Secrets and real customer identifiers are never committed. Continuous integration fails any change that includes the Company’s customer configuration file or real customer domains in application code.

Automated gates before merge

Every pull request and every push to the main branch runs the continuous-integration pipeline, which must pass in full:

• Static analysis (lint) across the codebase.
• All database migrations applied in order to a fresh database, proving the schema builds from zero.
• Seeding of the test tenants, followed by the tenant-isolation security suite: an automated matrix that attempts cross-tenant reads and writes through every access path and must be refused by the database on every one.
• Unit tests for parsers, financial calculations, and integrations against captured vendor fixtures.
• A production build of the application.
• The customer-data guard described above.

A change that adds a new access path (table, policy, grant, role, or route touching customer data) must extend the isolation suite in the same change.

Schema-first deployment rule

Merging to the main branch deploys the application. A change that includes a database migration therefore may not merge until that migration has been applied to every hosted database, in canary order (public demo first, then the customer installs), and each database’s grants have been audited afterwards. “Tests green” is not the merge gate for a migration-bearing change; “schema live in production” is. This rule exists because of a production outage on 2026-08-04 caused by application code reaching production ahead of its schema; it was resolved by a revert within hours and the rule has been followed since.

Deployment and verification

• Deployments are performed by the hosting platform from the main branch (customer installs) or by an explicit command-line deploy (public demo). Each deployment is immutable and identified by its commit.
• After every deployment the Security Owner verifies the live install: the affected pages respond, the sign-in path works, and, for schema changes, the grants audit is clean.
• Data-writing integrations (bank sync, accounting sync, monthly roll) only ever write to draft or system-owned records; published customer reports are never modified by automation.

Rollback and emergency changes

• Rollback is a revert pull request through the same pipeline, or an instant redeploy of the previous immutable deployment on the hosting platform. Schema rollbacks are written as forward migrations.
• An emergency change (an active incident or outage) may be deployed by the Security Owner ahead of full review; the change is still committed through source control, and the pull request, test results, and rationale are recorded within one business day.

Dependencies and configuration

• Third-party libraries are pinned in the lockfile. Automated dependency-vulnerability alerts are enabled on the repository; high and critical advisories are addressed within seven days, others at the next routine update.
• Runtime configuration (environment variables, cron schedules, domains) is either versioned in the repository or set in the hosting platform’s environment by the Security Owner, and changes are noted in the project’s session log.

Review

Reviewed at least annually and on any material change.