Your auditor asks: "Can you show me the review history for every code change deployed to production in the last 90 days?" You pull up GitHub. You point to PR comments. The auditor asks follow-up questions: "How do you ensure every change was reviewed? How do you prove the reviewer was qualified? How do you demonstrate that security concerns were addressed before merge?"
If your answers involve "we trust the process" or "our team follows the guidelines," you have a compliance gap. Auditors need evidence, not assurances.
autter generates that evidence automatically, for every pull request, without changing your workflow.
The compliance burden on engineering teams
Regulated industries — healthcare, finance, government, and increasingly SaaS companies pursuing enterprise customers — require demonstrable controls over code changes. The standards vary (SOC 2, ISO 27001, HIPAA, PCI-DSS, FedRAMP), but the requirements converge:
| Requirement | What auditors look for |
|---|---|
| Change authorisation | Every change approved by an authorised reviewer before deployment |
| Separation of duties | The person who wrote the code is not the same person who approved it |
| Risk assessment | Evidence that security and quality risks were evaluated |
| Traceability | A complete chain from requirement → code change → review → deployment |
| Anomaly detection | Controls that flag unusual or high-risk changes for additional review |
Most engineering teams handle these requirements through manual processes: required reviewers on GitHub, branch protection rules, periodic access reviews. These controls work — but they generate sparse evidence that requires manual assembly for audits.
How autter automates compliance evidence
autter generates a structured, machine-readable audit record for every pull request. This record includes everything an auditor needs to verify your change management controls.
The audit record
For every PR that passes through the autter merge gate, a tamper-evident record is generated:
{
"pr": {
"number": 1842,
"title": "Add payment retry logic",
"author": "dev@acme.com",
"opened_at": "2026-03-15T14:23:00Z",
"merged_at": "2026-03-15T18:45:00Z"
},
"review": {
"autter_analysis": {
"completed_at": "2026-03-15T14:24:22Z",
"findings": {
"security": { "critical": 0, "high": 0, "medium": 1, "low": 2 },
"quality": { "critical": 0, "high": 1, "medium": 3, "low": 5 },
"conventions": { "violations": 4, "auto_fixed": 3 }
},
"risk_score": 42,
"risk_category": "medium"
},
"human_reviews": [
{
"reviewer": "senior-dev@acme.com",
"role": "code_owner",
"approved_at": "2026-03-15T17:30:00Z",
"comments": 2,
"addressed": true
}
],
"separation_of_duties": true,
"required_reviewers_satisfied": true
},
"compliance": {
"standards": ["SOC2-CC8.1", "ISO27001-A.12.1.2"],
"controls_verified": [
"change_authorization",
"separation_of_duties",
"security_review",
"quality_assessment"
],
"evidence_hash": "sha256:a3f2b1..."
}
}Risk-based review routing
Not all code changes carry the same risk. autter automatically classifies PRs by risk level and routes them accordingly:
# autter.config.yml
compliance:
risk_classification:
critical:
# Changes to auth, payments, or data handling require security team review
paths:
- "src/auth/**"
- "src/payments/**"
- "src/data/**"
required_reviewers:
- team: "@security-team"
- team: "@code-owners"
min_reviewers: 2
high:
# Changes to API contracts or database schemas
paths:
- "src/api/routes/**"
- "migrations/**"
required_reviewers:
- team: "@code-owners"
min_reviewers: 1
standard:
# Everything else
required_reviewers:
- team: "@code-owners"
min_reviewers: 1Continuous compliance monitoring
autter doesn't just generate records — it monitors for compliance drift:
- Missing reviews — PRs that bypassed the review process (admin merges, emergency hotfixes)
- Reviewer qualifications — reviewers who lack the required role for the risk classification
- Policy violations — merges that didn't meet the configured requirements
- Trend analysis — increasing risk scores, decreasing review quality over time
When a deviation is detected, autter creates a compliance event that can trigger alerts, workflows, or audit findings.
Audit-ready reports
When audit time comes, autter generates pre-formatted reports that map directly to compliance framework controls:
# Generate SOC 2 change management report
npx autter compliance report \
--standard soc2 \
--period "2026-01-01..2026-03-31" \
--format pdf \
--output ./audit/q1-change-management.pdfThe report includes:
- Total code changes in the period
- Review coverage percentage (target: 100%)
- Separation of duties compliance rate
- Security findings detected and resolved
- High-risk changes with full review chain
- Policy exceptions with justification
For different compliance frameworks
| Framework | What autter provides |
|---|---|
| SOC 2 (CC8.1) | Change authorisation evidence, review logs, risk assessment records |
| ISO 27001 (A.12.1.2) | Change management controls, operational procedure compliance |
| HIPAA (§ 164.312) | Access controls evidence, audit trail for PHI-touching code changes |
| PCI-DSS (6.3, 6.4) | Secure development lifecycle evidence, change control procedures |
| FedRAMP (CM-3) | Configuration change control, security impact analysis |
Getting started
# Enable compliance mode
npx autter init --compliance
# Configure your compliance framework
npx autter compliance configure --standard soc2
# Run a compliance gap analysis on your current process
npx autter compliance audit --period 90dThe gap analysis reviews your last 90 days of PRs against your chosen compliance framework and identifies where your current process has gaps. Most teams close the gaps within a single sprint — and from that point on, every PR generates audit-ready evidence automatically.
Compliance doesn't have to mean friction. With autter, it means evidence that generates itself.
