Does GitHub's SOC 2 report cover our own SOC 2?

No. GitHub's own SOC 2 report covers the controls GitHub operates for its platform. Your examination covers how your company configures and uses GitHub: who has access, how it is authenticated, what is logged and how data in it is protected. Auditors read the vendor's report to decide what they can rely on, and the Vendor and Third-Party Risk Management Policy tells you to collect it at onboarding and annually.

What does the generator pre-fill when I arrive from this page?

The link on this page opens the generator with a preset that sets the source control to GitHub. The other answers (company, product, headcount, owners, data types, scope and review cadence) are yours to fill in. The policies render in your browser as Markdown; nothing is sent to a server and there is no signup.

Which policies change when I add GitHub to my answers?

5 policies name GitHub once it is in the intake: Access Control Policy, Change Management Policy, Secure Software Development Policy, Vulnerability and Patch Management Policy, Logging and Monitoring Policy. The free generator names it in scope, roles and procedures; the Audit Kit ($39 one-time) rewrites sections 4 and 5 of each policy with statements specific to how GitHub is configured, like the examples on this page. Refunds are available within 14 days on request.

SOC 2 policies for GitHub teams

Name: Policyseed
Author: Policyseed

GitHub is where code is reviewed and released, so it appears in the policies about change management, secure development, vulnerability handling, access to source code and what gets logged.

Source control and CI · Referenced by 5 of 22 policies · Generator preset available

The 5 policies that reference GitHub

With GitHub in your intake, these policies name it in their scope, roles and procedures. The other 17 policies in the set apply to your company regardless of tooling; the template index lists all 22.

P03 Access Control Policy: Defines how access to systems and data is requested, approved, provisioned, reviewed and removed.
P09 Change Management Policy: Requires that every change to production code, infrastructure and security-relevant configuration is proposed, reviewed, tested, approved and deployed through a controlled and traceable process.
P10 Secure Software Development Policy: Embeds security into how the product is designed, built, tested, dependency-managed and released so that vulnerabilities are prevented or found before they reach customers.
P11 Vulnerability and Patch Management Policy: Establishes how vulnerabilities in code, dependencies, infrastructure, endpoints and vendor services are discovered, rated, remediated within defined timeframes and verified.
P12 Logging and Monitoring Policy: Defines which security-relevant events are logged across the product, cloud and corporate systems, how logs are protected and retained, and how alerts are triaged and acted on.

What the Audit Kit writes for GitHub

The free generator fills in names. The Audit Kit goes further: Claude rewrites section 4 (Policy Statements) and section 5 (Procedures) of each policy using your full intake, so the text describes GitHub the way you actually run it. The statements below are examples of that output for GitHub; your own answers produce different text, and every statement should be checked against your configuration before management adopts it.

P03 Access Control Policy

Membership of the GitHub organisation is enforced through SAML single sign-on with the identity provider and SCIM provisioning, two-factor authentication is required for every member, and the organisation base permission is set to No permission. Repository access is granted to teams that mirror identity provider groups rather than to individuals, and outside collaborators require a ticket with an end date.

GitHub Actions workflows authenticate to the cloud provider with OpenID Connect federation and short-lived credentials, so no long-lived cloud access keys are stored as repository or organisation secrets. The production environment has required reviewers configured and its deployment branch rule is limited to main.

P09 Change Management Policy

The default branch of every deployable repository is protected by an organisation ruleset that requires at least one approving review from someone other than the author, dismisses stale approvals when new commits are pushed, requires review from code owners, requires the GitHub Actions status checks to pass, and blocks force pushes and deletions. The bypass list is empty, so organisation owners are not exempt.

P10 Secure Software Development Policy

Every pull request runs CodeQL code scanning, and secret scanning with push protection is enabled across the organisation so that commits containing credentials are rejected before they reach the remote. Code scanning alerts of High or Critical severity block merge until they are fixed or dismissed by the Engineering lead with a written reason.

P11 Vulnerability and Patch Management Policy

Dependabot alerts and Dependabot security updates are enabled on every repository. Critical dependency vulnerabilities are remediated within seven days and High within thirty days, and the open alert list is reviewed in the weekly engineering meeting with overdue alerts escalated to the Security Owner.

P12 Logging and Monitoring Policy

The organisation audit log is streamed to the central logging tool, and alerts fire on changes to organisation membership, repository visibility, rulesets and branch protection, personal access token approvals and GitHub App installations. The Security Owner matches each alert to an approved ticket weekly.

How to use this page

Open the generator with the GitHub preset and answer the remaining questions: company, product, headcount, other tools, data types, owners, scope and review cadence.
Download the 22 policies as Markdown. Read the sections that mention GitHub with the admin console open and fix anything that is not true of your setup.
Optionally buy the Audit Kit to have sections 4 and 5 tailored to GitHub and the rest of your stack, and to get Word documents, the TSC crosswalk, an evidence checklist, acknowledgment forms and a review calendar in one ZIP built on your machine.
Have management approve the policies, collect acknowledgments, and start producing the evidence the procedures describe. The CPA firm performs the examination.

Other tools

Cloud platforms: AWS, Google Cloud, Microsoft Azure, Vercel, Cloudflare

Source control and CI: GitLab

Identity providers: Google Workspace, Okta, Microsoft 365

Vendors and subprocessors: Supabase, Clerk

Frequently asked questions

Does GitHub's SOC 2 report cover our own SOC 2?: No. GitHub's own SOC 2 report covers the controls GitHub operates for its platform. Your examination covers how your company configures and uses GitHub: who has access, how it is authenticated, what is logged and how data in it is protected. Auditors read the vendor's report to decide what they can rely on, and the Vendor and Third-Party Risk Management Policy tells you to collect it at onboarding and annually.
What does the generator pre-fill when I arrive from this page?: The link on this page opens the generator with a preset that sets the source control to GitHub. The other answers (company, product, headcount, owners, data types, scope and review cadence) are yours to fill in. The policies render in your browser as Markdown; nothing is sent to a server and there is no signup.
Which policies change when I add GitHub to my answers?: 5 policies name GitHub once it is in the intake: Access Control Policy, Change Management Policy, Secure Software Development Policy, Vulnerability and Patch Management Policy, Logging and Monitoring Policy. The free generator names it in scope, roles and procedures; the Audit Kit ($39 one-time) rewrites sections 4 and 5 of each policy with statements specific to how GitHub is configured, like the examples on this page. Refunds are available within 14 days on request.

Policyseed provides governance policy templates and AI tailoring. It is not legal advice and not a compliance guarantee. Management adopts the policies; the CPA firm performs the SOC 2 examination.