Why GitHub branch protection rules don't satisfy your SOC 2 auditor (and what does)
Branch protection enforces code review inside Git. But your auditor audits Jira. Here is why the disconnect happens during sample testing, the 3 blind spots that trigger audit findings, and how to bridge the gap without taking 100 manual screenshots.
The false sense of security in repository settings
Almost every engineering team preparing for their first SOC 2 Type II or ISO 27001 audit starts with the exact same assumption:
GitHub Repository Settings → Branches → Branch protection rule (main):
✓ Require a pull request before merging (1 required approval)
✓ Dismiss stale pull request approvals when new commits are pushed
✓ Require status checks to pass before merging
✓ Require conversation resolution before merging
On paper, this looks airtight. If nobody can push directly to main, and every pull request requires an approval from a teammate, you have enforced segregation of duties. Right?
Then audit season arrives. The auditor sends over a CSV of 40 random Jira tickets marked "Done" between July and October. They ask for evidence that each ticket was authorized, tested in staging, reviewed by an independent engineer, and deployed with zero unauthorized changes.
When you reply: "We have branch protection turned on in GitHub repo settings," the auditor shakes their head:
"Configuration settings show what your policy was supposed to do. I need sample evidence showing what actually happened on these specific 40 production changes."
How an auditor actually tests change management (SOC 2 CC8.1)
Under AICPA Trust Services Criterion CC8.1 (Change Management), the auditor must verify that changes to software across the production environment follow a documented lifecycle:
- Authorization: Was there a valid business request or ticket before code was written?
- Segregation of Duties: Did someone other than the author inspect and approve the change?
- Pre-Deployment Testing: Was the change verified in a non-production environment before production release?
- Completeness: Can you prove the exact code in the PR is what actually deployed to production?
GitHub branch protection controls the Git merge event. It knows nothing about the Jira ticket, the business justification, the QA sign-off comment, or the staging deployment tag.
The 3 blind spots that fail audits when relying on GitHub alone
Auditors sample Jira, not Git pull requests
Your auditor starts from the system of record: Jira Software. When they pick ticket DEMO-42, they want to see the PR link right there on the ticket. If a developer forgot to put the Jira issue key in their branch name or commit message, you have no traceable connection. You are forced to spend 20 minutes grepping git logs to find which commit matched that ticket description.
Branch protection has an "Include administrators" loophole
In many startups and scale-ups, repository admins (often tech leads, DevOps engineers, or CTOs) have bypass permissions enabled for emergency hotfixes. If an admin pushes a midnight hotfix directly to main or merges their own PR without peer review, GitHub allows it. When your auditor samples that ticket, you fail the segregation of duties test.
Unit tests passing in CI does not prove staging sign-off
SOC 2 CC8.1 and ISO 27001 A.8.32 require proof of testing in non-production environments. GitHub Actions shows that unit tests or lint checks passed. But auditors frequently ask: "Where is the confirmation that QA or product verified this in staging before production deployment?" That evidence lives in Jira comment threads or status transitions—completely invisible to GitHub branch rules.
The 3 approaches engineering teams use (and their trade-offs)
| Approach | Engineering Friction | Auditor Acceptance | Data Security / Egress |
|---|---|---|---|
| 1. Manual Screenshot Spreadsheet | Extremely High (3–4 hrs per sample; 120+ dev hours wasted per audit) | Moderate (Auditors question cropped images & missing timestamps) | Safe (Images stored locally in Google Drive) |
| 2. External Multitenant SaaS | Low (Automatic background gathering) | High (Automated reports) | Risky (Requires exporting source code, PR diffs, and Jira tickets to third-party US cloud databases) |
| 3. Native Atlassian Forge (EvidenceLog) | Zero (Auto-seals proof on Jira issue transition to Done) | Highest (Tamper-evident SHA-256 seal & 1-click CSV workpaper) | 100% In-Tenant (Zero external servers; data never leaves Jira Cloud) |
How in-tenant Jira verification bridges Git and audits
The cleanest way to solve the compliance gap is to place the gatekeeper at the moment of release inside Jira Software:
1. Continuous Background Inspection: As developers work normally in GitHub, GitLab, or Bitbucket, EvidenceLog listens to Jira issue transitions.
2. Transition Gatekeeping (Preventive Control): When an issue transitions to "Done" or "Deployed", EvidenceLog verifies that:
- At least one valid pull request is linked.
- The author of the pull request is distinct from the approver (
Author ≠ Approver). - Automated tests passed in CI.
- QA sign-off or acceptance criteria checklist exists.
3. Cryptographic In-Tenant Sealing: Once verified, a SHA-256 digest of the issue state, commit SHA, and approver handles is written to Atlassian Key-Value Storage (@forge/kvs).
When audit season arrives, the tech lead clicks [Export Auditor Workpaper]. In 5 seconds, you download a clean CSV table with every ticket key, PR link, approver name, and commit SHA already verified. Zero screenshots. Zero spreadsheets. Zero stress.
The Lead Engineer's 5-Point Audit Readiness Checklist
Run through this checklist before your next SOC 2 or ISO 27001 observation window:
feat/DEMO-9-tls-encryption) for automated linkage.qa-verified) or QA sign-off comment prior to closing release tickets.Stop gathering screenshots for your next audit
Install EvidenceLog free on Atlassian Marketplace. Test with up to 10 users forever with zero external servers and zero data egress.