GitHub Configuration Checklist for SOC 2 Compliance

If your company ships software, your GitHub organization is one of the first things a SOC 2 auditor will look at. Your source code is a critical asset, your CI/CD pipeline is the path to production, and your repository settings are the technical controls that prove — or disprove — that you actually do what your policies say you do.

The good news: GitHub gives you almost everything you need to satisfy the change management, access control, and vulnerability management portions of a SOC 2 audit. The bad news: none of it is enforced by default, and auditors are increasingly savvy about checking the actual settings rather than taking your word for it.

This guide is a practical GitHub SOC 2 compliance checklist. Work through it before your audit window opens, take screenshots (or better, connect an automation platform that collects evidence continuously), and you will walk into the audit with the engineering side of SOC 2 largely done.

If you are new to SOC 2 itself, start with our SOC 2 learning hub and the SOC 2 framework overview, then come back here for the GitHub-specific work.

Why GitHub Configuration Matters for SOC 2

SOC 2 is built on the Trust Service Criteria (TSC), and the Common Criteria (CC series) apply to every audit. Several of them land squarely on your source control platform:

• CC6 (Logical and Physical Access Controls): Who can access your code, how they authenticate, and how access is removed when people leave.
• CC7 (System Operations): How you detect vulnerabilities, monitor for anomalies, and respond to security events.
• CC8 (Change Management): How changes are authorized, tested, reviewed, and approved before reaching production.

When an auditor tests CC8.1 ("the entity authorizes, designs, develops, tests, approves, and implements changes"), the evidence they want is usually a sample of merged pull requests showing required reviews, passing status checks, and no direct pushes to your default branch. All of that is GitHub configuration.

Auditors have also learned the common gaps: organizations that require reviews but let admins bypass them, 2FA "policies" that are documented but not enforced, and offboarded contractors who still have repo access six months later. Every item below closes one of those gaps.

Organization Settings: Authentication and Access

Start at the organization level, because settings here cascade to every repository.

Enforce SSO or 2FA for everyone

• SAML/OIDC SSO (GitHub Enterprise Cloud): If you have Enterprise, connect GitHub to your identity provider (Okta, Entra ID, Google Workspace) and require SSO, not just enable it. This centralizes authentication, inherits your IdP's MFA policy, and makes offboarding a single-system operation.
• 2FA enforcement (all plans): Under organization security settings, require two-factor authentication for all members and outside collaborators. Note the sharp edge: when you flip this on, GitHub removes members who do not have 2FA enabled. Communicate first, enforce second.
• Prefer phishing-resistant factors. Encourage passkeys or hardware security keys over SMS. Some auditors now ask about factor strength, not just factor presence.

Lock down base permissions

• Set the organization base permission to "No permission" or "Read" — never "Write." Access to write code should come from team membership, not a default.
• Use teams synced to your IdP groups where possible, so access follows your HR system.
• Restrict who can create repositories (especially public ones) to avoid shadow projects outside your audit scope.
• Disable forking of private repositories unless you have a concrete need. A fork is a copy of your code outside your protection rules.

Manage outside collaborators deliberately

Outside collaborators (contractors, agencies) are the classic access-review finding. Require an approval workflow to add them, tag them for quarterly review, and set calendar-based removal dates for fixed-length engagements.

Branch Protection and Rulesets

This is the heart of SOC 2 change management evidence. GitHub's newer rulesets are preferable to legacy branch protection rules because they can be applied organization-wide, layered, and — critically — they produce evaluation history you can show an auditor.

Configure the following on your default branch (and any release branches) for every production repository:

• Require a pull request before merging. No direct pushes to main, ever, for anyone.
• Require at least one approving review (two for high-risk repositories). The author cannot approve their own PR.
• Dismiss stale approvals when new commits are pushed, so a reviewed PR cannot be silently changed after approval.
• Require review from Code Owners for sensitive paths — infrastructure code, auth logic, payment code — via a CODEOWNERS file.
• Require status checks to pass (tests, linting, security scans) before merging, and require branches to be up to date.
• Block force pushes and deletions on protected branches to preserve history integrity.
• Do not exempt administrators. "Include administrators" (or the ruleset equivalent of no bypass actors) is the setting auditors check first. If your CTO can bypass review, your control has an exception you will have to explain.
• Require signed commits if your risk profile warrants it — increasingly common for security-sensitive products.

Document a break-glass procedure for genuine emergencies: who can bypass, how it is logged, and the requirement for retroactive review. An auditor is fine with an emergency path; they are not fine with an undocumented one.

Code Review Requirements

Configuration forces reviews to happen; your process determines whether they are meaningful. For SOC 2, make sure:

• Your change management policy states the review requirement, and the GitHub settings match the policy exactly. A policy that says "two reviewers" while GitHub requires one is an audit finding waiting to happen.
• Reviews leave a trail. Approvals in the GitHub UI are your evidence — verbal approvals in Slack are not.
• Dependabot and bot-authored PRs follow the same rules, or you explicitly document the exception (for example, auto-merge for patch-level dependency updates with passing tests).

Secret Scanning and Push Protection

Leaked credentials are the most common way source control becomes a breach vector, and auditors know it.

• Enable secret scanning on all repositories. It detects committed tokens, keys, and credentials for hundreds of providers.
• Enable push protection, which blocks a push containing a detected secret before it lands in history. This converts an incident-response problem into a non-event.
• Define a triage process for alerts: revoke the credential first (rotation, not deletion — the secret is in history forever), then investigate exposure.
• Add custom patterns for internal secret formats (internal API keys, license keys) that GitHub's default detectors will not catch.

Secret scanning maps cleanly to CC6.1 (protection of credentials) and CC7.1 (detection of vulnerabilities and anomalies), and it is one of the easiest wins on this list.

Dependabot and Vulnerability Management

CC7.1 expects you to identify vulnerabilities; CC7.2 expects you to monitor and respond. For your application dependencies:

• Enable the dependency graph and Dependabot alerts on all repositories.
• Enable Dependabot security updates so patch PRs are opened automatically.
• Set SLAs by severity in your vulnerability management policy — for example, critical within 7 days, high within 30, medium within 90 — and make sure your actual alert-closure times back it up, because a Type II auditor will sample them.
• Do not let alerts rot. Hundreds of open, months-old critical alerts is a worse look than having no scanner at all, because it proves the control exists and is ignored. Dismissing an alert with a documented reason (not exploitable, dev-only dependency) is acceptable; silence is not.
• Consider code scanning (CodeQL) for static analysis on your main branches and PRs. It is not strictly required for SOC 2, but it strengthens your CC7 story considerably.

Audit Log Streaming and Monitoring

SOC 2 expects you to log security-relevant events and retain them. GitHub's organization audit log covers membership changes, permission changes, repo creation/deletion, ruleset changes, and more — but retention on the standard plans is limited.

• Stream the audit log (Enterprise) to your SIEM, S3 bucket, or logging platform so retention matches your policy (12 months is a common target, aligned to the audit period).
• Alert on high-risk events: ruleset or branch protection changes, org owner additions, 2FA requirement changes, repo visibility changes to public, and deploy key creation.
• If you are not on Enterprise, periodically export the audit log via API on a schedule and store it — a scheduled job is fine; the point is retention and reviewability.

Access Reviews and Offboarding

Access control findings are the most common SOC 2 exceptions across all systems, and GitHub is no exception.

• Quarterly access reviews: Export org members, outside collaborators, and their team/repo permissions. Have engineering managers attest that each person still needs their level of access. Keep the sign-off — the review itself is the evidence.
• Offboarding within your policy's SLA (24 hours is typical, same-day for terminations). With SSO enforced, deactivating the IdP account cuts off GitHub access immediately; without SSO, GitHub removal must be an explicit step on your offboarding checklist.
• Review non-human access too: personal access tokens, deploy keys, OAuth app grants, and GitHub App installations. Prefer fine-grained PATs with expiration dates, restrict which OAuth apps can be authorized against the org, and inventory deploy keys quarterly.
• Enforce least privilege: developers get Write, not Admin. Keep org owners to a small, named list (two to four people) and review it explicitly.

Mapping Table: GitHub Setting → Trust Service Criteria

Use this table to pre-map your GitHub controls for your auditor. Handing this over early shortens the evidence-request cycle noticeably.

CI/CD Workflow Security (GitHub Actions)

Your pipeline deploys to production, so it is in scope. Harden GitHub Actions with:

• Restrict allowed actions to those created by GitHub, verified creators, or an explicit allowlist. Pin third-party actions to a full commit SHA, not a mutable tag.
• Default workflow permissions = read-only. Grant write scopes per-job only where needed.
• Use environments with required reviewers for production deployments — this gives you a deployment approval gate with a built-in audit trail.
• Store secrets in GitHub Environments scoped to protected branches, or better, use OIDC federation to your cloud provider so there are no long-lived cloud credentials in GitHub at all.
• Require approval for workflow runs from forks on public repos to prevent secret exfiltration via malicious PRs.
• Protect the workflows themselves: changes to .github/workflows/ should require code owner review, since a workflow change is effectively a production change.

The Complete Checklist

Run through this before your audit window opens:

• SAML SSO required (Enterprise) or 2FA enforced org-wide
• Organization base permission set to Read or No permission
• Repository creation restricted; private repo forking disabled
• Org owners limited to a small, documented list
• Rulesets/branch protection on default and release branches, all production repos
• PR required, ≥1 approval, stale approvals dismissed, no self-approval
• CODEOWNERS covering sensitive paths
• Required status checks wired to CI tests
• Force pushes and branch deletion blocked; no admin bypass
• Documented break-glass/emergency change procedure
• Secret scanning and push protection enabled everywhere
• Custom secret patterns for internal credential formats
• Dependabot alerts and security updates enabled; SLAs defined and met
• Code scanning enabled on main branches (recommended)
• Audit log streamed or exported; retention ≥ audit period
• Alerts configured for ruleset changes, owner changes, visibility changes
• Quarterly access reviews performed and documented
• Offboarding checklist includes GitHub (or SSO covers it)
• PATs fine-grained with expirations; deploy keys and OAuth apps inventoried
• Actions restricted/pinned; default workflow permissions read-only
• Production deploys gated by environments with required reviewers
• No long-lived cloud secrets in Actions (OIDC federation preferred)

Frequently Asked Questions

Is GitHub itself SOC 2 compliant, and does that cover me?

GitHub maintains its own SOC 2 reports covering its infrastructure, and you should collect its report for your vendor management program. But that covers GitHub's controls, not yours. How you configure your organization — access, reviews, branch protection — is entirely your responsibility, and it is your configuration the auditor examines.

Do I need GitHub Enterprise for SOC 2?

No. Companies pass SOC 2 on the Team plan regularly. Enterprise makes several controls easier — SAML SSO, audit log streaming, org-wide rulesets — but 2FA enforcement, branch protection, secret scanning alerts on public repos, and Dependabot are available at lower tiers. Some advanced security features for private repos require paid add-ons; weigh that cost against the manual alternatives.

What evidence will my auditor actually ask for from GitHub?

Typically: screenshots of org security settings (2FA/SSO enforcement), branch protection or ruleset configuration, a sample of merged pull requests from the audit period showing approvals and passing checks, the current member and collaborator list with permissions, access review sign-offs, and offboarding evidence for anyone who left during the period. Compliance automation platforms collect most of this via the GitHub API automatically.

Do branch protection rules apply to every repository or just production ones?

Your SOC 2 scope defines which systems matter — typically anything that ships to production or handles customer data. Apply full protections to every in-scope repository. For prototypes and internal tooling, lighter rules are defensible, but document the distinction so your auditor sees a deliberate decision rather than inconsistency. Org-wide rulesets with targeted repository patterns make this manageable.

What is the most common GitHub-related SOC 2 finding?

Access-related exceptions: an offboarded employee or contractor whose GitHub access outlived your removal SLA, or missing quarterly access review documentation. Second place goes to admin bypass on branch protection — the control exists, but privileged users are exempted from it.

Can I automate this evidence collection?

Yes, and you should. Compliance automation platforms connect to GitHub via API and continuously verify 2FA enforcement, branch protection settings, open Dependabot alerts, and access lists — flagging drift the day it happens rather than the week before your audit. Developer-first platforms like LowerPlane ship a native GitHub integration that maps these settings directly to SOC 2 controls and collects the evidence automatically.

How AuditXYZ Helps

Getting GitHub configured is one piece of SOC 2; choosing the right automation platform and auditor is the other. AuditXYZ lets you compare compliance automation platforms side by side — including which ones have deep GitHub integrations for continuous evidence collection — and browse vetted SOC 2 auditors with real pricing and turnaround data. Start with your GitHub checklist, then let us help you assemble the rest of your audit stack.