Public Change Log / Release Notes — SOC2 Evidence

Document Version: 1.0 Date: May 20, 2026 Owner: Dominick Pham, CTO Classification: Internal Use

Executive Summary

This document describes Qwestly's public change log (release notes), which communicates product changes to users and stakeholders. The change log is published as a publicly accessible page on qwestly.com and updated for each meaningful production deployment. This satisfies SOC2 CC8.1 requirements for change management communication while remaining appropriately lightweight for a pre-seed startup.

SOC2 Trust Services Criteria Addressed

Criteria	Control Objective	Implementation Status
CC8.1	Change management — authorization, documentation, and communication of changes	✅ Implemented

Context: Startup-Appropriate Change Communication

Qwestly is a pre-seed startup with fewer than 10 employees and approximately 150 users on the platform. The pace of user-facing changes is measured in weeks, not days. A formal, structured release notes pipeline (e.g., semantic versioning with detailed changelogs per deploy) would be disproportionate to the current stage and team size.

Instead, Qwestly maintains a public changelog page at https://qwestly.com/changelog (or equivalent URL) that is updated when meaningful user-facing changes ship. This approach:

• Provides transparency to users about what's changing
• Creates an auditor-verifiable record of change communication
• Is sustainable for a small team — updates take minutes, not hours
• Scales naturally as the team and user base grow

Implementation Details

Change Log Format

Each entry in the public change log includes:

Field	Description
Date	When the change was deployed to production
Title	Brief summary of the change
Description	1–3 sentences on what changed and why it matters to users
Category	New feature, improvement, fix, or announcement

Source of Truth

The public changelog page on qwestly.com/changelog is the single source of truth. It is a static page deployed as part of the Qwestly marketing site (hosted on Vercel). Updates are made by editing the page content and deploying.

When Updates Happen

A changelog entry is added when a production deployment includes user-facing changes — new features, meaningful improvements, or fixes that affect user experience. Internal-only changes (infrastructure, refactoring, dependency updates) are tracked in GitHub commit history but do not require a public changelog entry.

Authorization

All production changes, including changelog updates, are:

• Authored by an engineer via a GitHub pull request
• Reviewed by at least one other engineer before merge
• Deployed via Vercel's automated CI/CD pipeline (connected to GitHub)
• Communicated via the public changelog if user-facing

Example Entry

May 15, 2026 — Resume import improvements
Candidates can now import their resume from LinkedIn in addition to uploading a PDF. 
This was the #1 requested feature from our waitlist users.
Category: New Feature

Evidence Locations

Evidence	Location	Type
Public changelog page	https://qwestly.com/changelog	Public URL
Changelog page screenshots	evidence/changelog-*.png	Screenshot (during observation window)
GitHub PR history	github.com/qwestly/*	Code change record
Vercel deployment history	Vercel dashboard → Deployments	Deployment record

Testing & Validation

Evidence Collection for Audit

During the SOC2 observation window (July 2 – October 2, 2026):

1. Screenshot the changelog page showing dated entries within the observation window
2. Cross-reference at least one entry to its corresponding GitHub PR and Vercel deployment
3. Verify the page is publicly accessible (load in an incognito browser or via curl)

Control Validation

Test	Frequency	Owner	Evidence
Changelog page is publicly accessible	Monthly	CTO	Screenshot or curl output
At least one entry added during period	Per observation window	CTO	Screenshot with date
Entry cross-references to a merged PR	Per observation window	CTO	GitHub PR link

Continuous Improvement

As Qwestly grows, the changelog process will evolve:

• Near-term (< 6 months): Manual updates to the static changelog page remain appropriate
• Medium-term (6–12 months, 500+ users): Consider generating changelog entries from GitHub release tags for consistency
• Long-term (1,000+ users): Evaluate dedicated changelog tools (Headway, Changefeed) with email/in-app notification

Review Cadence

• Monthly: CTO verifies changelog page is live and accessible
• Quarterly: CTO + CEO review whether the changelog process remains appropriate for the current user base size
• Annual: Full review as part of SOC2 audit preparation

Conclusion

Qwestly's public change log provides appropriate, sustainable change communication for a pre-seed startup. It satisfies CC8.1 requirements without imposing disproportionate process overhead. The control is in place, publicly verifiable, and will scale as the company grows.