The audit asks what happened on every change. Today the answer is assembled by hand.
SOC 2 change management asks the same of every production change: reviewed by someone independent, tested, traceable to a work item. Warestack checks each one on the pull request, keeps the record per change for up to 365 days, and exports it when the auditor asks. It never reads the code.
Four weeks on one to three repositories. Success metric agreed before the install. Nothing blocks a merge unless you decide it should.
Each control becomes a rule that runs on every change.
The controls you already list for the audit, mapped to catalog rules that read GitHub, Linear and Jira metadata. Each one reports first; you decide which become required checks.
The production deployment review was approved by someone other than the person who requested it.
The pull request reached merge with the human approvals its branch prefix requires. Bot approvals never count.
Every pull request links to a Linear, Jira or GitHub work item, and every production deployment traces to a merged pull request (Rule 60).
A successful production deployment shows observed health, smoke or verification evidence.
Merges outside 9 to 6 local time are listed weekly, with the approver, for review.
Changes under paths you name carry an independent approval from an observed code owner.
Kept per change. Exported when asked.
For every production change: the pull request, the approver and whether they were independent, the checks that ran, the linked work item, the deployment and its review. Queryable in plain English, scheduled to Slack or email, exported as CSV.
365-day retention on Enterprise. Longer than a Type II observation period, so the evidence exists before the auditor asks for it.
Every run kept. A scheduled report keeps each run with its rows, so last quarter’s answer is still there this quarter.
Briefs for the reader. A written summary of one result for the audience that asked, with every claim linked to its evidence row.
One row of 186 this month. Export the month as CSV, or schedule the report to the compliance channel.
No exception in the report. The evidence exists before anyone asks.
The time saved is the smallest part of the return.
Evidence before the auditor asks. Approver, checks, tests and linked work item on record for every production change. An exception in the report stays for the whole observation period, and in every security review that reads it.
Caught at the pull request. Missing approvals, untested changes and scope drift are flagged before merge, not in the incident review. A year of Warestack for 40 engineers is about $2,400; one churned account costs more.
~1 hr → 20 min a day. SOC 2 reporting and enforcement per engineering leader. The record builds itself; the report is a query.
What Warestack reads, and what it never does.
The GitHub app requests metadata permissions only. It never requests contents access, so it cannot read code. The Jira app is an Atlassian Forge app; data residency follows your Jira site.
Pull requests, reviews, approvals, checks, workflow runs, deployments, branch protection; work item key, title, status and assignee from Linear or Jira.
The Warestack check and one comment per pull request; Slack messages; the Warestack panel on the work item. Only what a chain tells it to.
SSO/SCIM, SLA, 365-day retention, dedicated infrastructure on request. Security questionnaire and DPA on file.
Pilot success metric: an exportable record for every production change on the pilot repositories, and reporting time down from about an hour to 20 minutes a day.