Is GitHub SOC 2 Compliant?

If your company stores source code on GitHub, GitHub will show up on security questionnaires from nearly every customer, partner, or auditor who does any due diligence. Source code is the most sensitive IP most software companies hold — it deserves more scrutiny than a productivity app. The question your team will eventually field is some version of: "Does GitHub have a SOC 2 report?"

Yes, it does. But what that report covers — and what it leaves squarely on your plate — is where the actual work is.

GitHub's compliance certifications

GitHub Enterprise Cloud maintains a SOC 1 Type 2, SOC 2 Type 2, and SOC 3 report, all issued by independent auditors. Beyond the SOC suite, GitHub also holds ISO/IEC 27001 and ISO/IEC 42001 (the AI management system standard) certifications, as well as CSA STAR Level 2. For a platform that sits inside nearly every engineering organization's supply chain, that's a credible compliance program.

Reports are released on a semi-annual cadence, covering rolling six-month audit periods. GitHub's security and compliance page provides an overview, and the trust center details current certifications and how to request the reports.

The SOC 3 is publicly available without authentication. That's the short-form report: it confirms that an auditor examined the controls and issued a clean opinion, without the operational detail the SOC 2 contains. For a customer who just needs confirmation that GitHub has been audited, the SOC 3 covers it.

The full SOC 2 Type 2 is the document that matters for serious due diligence. It contains the auditor's description of GitHub's controls and the actual test results. Accessing it requires a GitHub Enterprise Cloud subscription. If your organization runs Enterprise Cloud, the report is available directly in your organization security settings, under the Compliance section. Enterprise administrators can also pull it from enterprise settings. There's no separate request process; it's self-service within the console.

If you're on GitHub Team or a free organization without Enterprise Cloud, the path to the full SOC 2 report goes through a direct request to GitHub. They do make it available under terms of use, but it's not self-service the way it is for Enterprise Cloud customers.

What GitHub's report actually covers

GitHub's SOC 2 report is an auditor's assessment of the controls GitHub runs to keep its platform secure, available, and trustworthy. All five Trust Services Criteria fall within scope: Security, Availability, Processing Integrity, Confidentiality, and Privacy.

What the auditor examined is GitHub's side of the platform: the data centers, the network infrastructure, the employee access controls, the change management process for GitHub.com itself, platform-level incident response, and the systems that keep the service running across its global footprint. For a SaaS platform at GitHub's scale, these controls are well-established and the audits are routine.

GitHub Copilot Business and Copilot Enterprise are included in the SOC 2 Type 2 scope. That matters if you've deployed Copilot across your engineering team, because customers and auditors will ask whether the AI-assisted development tooling falls under a third-party audit. It does. You don't need a separate vendor SOC 2 for the Copilot component.

What the report says nothing about: your organization's repositories, your access settings, your branch protection configuration, or how your engineers authenticate. That layer belongs entirely to you.

The configuration that belongs to your organization

The shared responsibility line in developer tooling is worth stating precisely. GitHub operates and audits the platform; your organization configures how the platform is used. The gap between those two things is exactly what your own SOC 2 auditor will sample.

The controls that come up most often in audit prep, and where organizations are most likely to have gaps:

MFA enforcement for org members. GitHub doesn't enforce multi-factor authentication by default. Organization owners have to enable it as a requirement in the organization's security settings. If some engineers have MFA configured because they opted in individually, but it isn't enforced at the organization policy level, that's a finding. Auditors testing CC6.1 (access control) will ask for evidence that MFA is required — not just available. There's more on why this distinction matters in the MFA guide.

Branch protection on production branches. Change management criteria (CC8.1) is where auditors focus heavily for software companies. For a GitHub-hosted codebase, the primary evidence is branch protection on your main branch: required pull request reviews before merging, required status checks passing, and restrictions on who can push directly or force-push. None of this is on by default at the repository or organization level. You set it, you document it, and you need evidence it held across your entire audit window — not just that it was configured last Tuesday.

Audit log retention and review. GitHub Enterprise Cloud generates detailed audit logs covering member activity, repository access, admin actions, and organization configuration changes. You need to retain those logs for a period covering your audit window, and you need an actual review process — not just archiving. Auditors will look for both the evidence of logs and evidence that someone reviewed them for anomalies on a regular cadence.

OAuth application controls. Third-party applications can request OAuth access to your GitHub organization's data. Enterprise Cloud has controls to require administrator approval before any OAuth app is installed. Those controls should be active. Without them, individual developers can authorize integrations with broad repository access and no organizational visibility into what's been connected.

Periodic access reviews. Who has access to your GitHub organizations and repositories needs to be reviewed on a regular cycle — typically quarterly or at least annually. GitHub doesn't run these reviews. Your team pulls the member list, confirms that only current staff with a legitimate need retain access, removes anyone who shouldn't be there, and documents the review. It's a standard access control requirement under CC6.3, and it has to be yours to own.

Using GitHub's report in your own SOC 2 audit

When you go through your own SOC 2 audit, GitHub appears as a subservice organization — a vendor you rely on to operate controls that fall within your own scope. Your auditor will need you to account for this formally.

The steps in practice:

1. Pull GitHub's SOC 2 Type 2 report from your Enterprise Cloud organization settings
2. Identify which controls in your system description you're relying on GitHub to run (physical security, platform availability, network-level controls)
3. Confirm those controls appear in GitHub's report and show operating effectiveness for a period that overlaps your audit window
4. Document that review as a formal vendor risk activity with the date and what you verified

The third step is the one teams skip. You can't just name GitHub as a vendor and assume the report says what you need — you have to check and record that you checked. For a recent audit period, verifying takes less than an hour. But it needs to be in your files.

For a structured way to do this across all key vendors, a consistent vendor risk assessment process makes the documentation repeatable without rebuilding it from scratch each cycle. The approach for GitHub follows exactly the same pattern as what I covered for AWS in the shared responsibility model.

How to verify GitHub's current compliance status

For self-service verification:

• GitHub Enterprise Cloud org admins: Settings > Security > Compliance in your org settings
• The SOC 3 is publicly available at github.com/security without authentication
• GitHub's trust center lists current certifications and links to how reports are accessed
• Non-Enterprise customers can contact GitHub directly to request the SOC 2 under their terms

Check that the most recent report covers a period that includes the time window you're being asked about. Confirm the specific services your organization uses are within scope. For most organizations running standard GitHub Enterprise Cloud features including Copilot Business, they will be.

The compliance program is well-established and the documentation is accessible. The work on your side of the line — MFA enforcement, branch protection, access reviews, audit log monitoring — is real and needs to be yours. Nothing in GitHub's report covers those gaps for you.

Get the templates we actually use.

One practical email a week: a new template, a teardown of a real framework requirement, and the occasional honest tool review. No fluff, unsubscribe anytime.

Send me the templates

No spam. Unsubscribe in one click.