GitHub Copilot SOC 2 and GDPR compliance: what engineering teams need to know

GitHub Copilot is in scope for your SOC 2 audit. If your engineers use it, you have a new vendor relationship with Microsoft/GitHub that processes your source code. Source code is not personal data in the GDPR sense, but it may contain secrets, customer data, and proprietary algorithms. And if Copilot handles code that touches personal data, there is a chain of custody argument your auditor will follow.

Here is what the documentation actually says, what controls map to which criteria, and how to make Copilot audit-ready in under a day.

GitHub Copilot compliance tiers

GitHub offers three Copilot tiers. Only two of them are appropriate for business use.

Copilot Individual: Consumer terms. Snippets may be retained for 28 days and used to improve the model. No DPA available. Not appropriate for any professional use involving company code or customer data.

Copilot Business: Business terms with a DPA. No training on your code. Prompts and suggestions are not retained after the session. SOC 2 report available. This is the minimum appropriate tier for any company under SOC 2 or handling customer data.

Copilot Enterprise: All of Business features plus fine-tuning on your own codebase, knowledge base integration with your docs, and additional admin controls. Same compliance posture as Business for SOC 2 and GDPR purposes.

The key decision is Business vs Individual. If any engineer is using an Individual license on company code, that is a finding. Company-paid Copilot subscriptions should always be Business or Enterprise.

SOC 2 documentation: what GitHub publishes

GitHub maintains a SOC 2 Type II report that covers GitHub's core platform, including Copilot. The report covers security, availability, and confidentiality. It is available through GitHub's trust portal at github.com/security or by request through your account team.

GitHub is owned by Microsoft, so GitHub Copilot also falls under Microsoft's broader ISO 27001 and ISO 27018 certifications. ISO 27018 specifically covers protection of personally identifiable information in public cloud environments, which is relevant if you have any concern about code containing PII.

For your vendor inventory entry: GitHub SOC 2 Type II, available through trust portal. Data types: source code, code comments, natural language prompts related to code. Risk tier: high (receives production code). DPA: GitHub Data Protection Agreement, available at github.com/customer-terms.

GDPR: does source code count as personal data?

This is where teams get confused. Source code is not personal data in most cases. But code can contain personal data: hardcoded test credentials with real email addresses, database queries that include example customer records, variable names referencing specific users, comments with ticket numbers tied to named users.

If your code might contain personal data, Copilot's handling of that code requires GDPR consideration. The DPA covers this: GitHub acts as a processor, your company is the controller, and the DPA includes SCCs for EU-to-US transfers. Sign the DPA if you have not already.

More practically: if personal data appearing in code is a concern, establish a policy that production data is never used in development environments. This is a security baseline that predates AI tools and protects you here as a side effect.

The training and code retention question

The question enterprise security teams ask about Copilot: "Is our code used to train the model?"

For Copilot Business and Enterprise, the answer is no. GitHub's policy is explicit: code from Business and Enterprise customers is not used to train Copilot or any other GitHub model. Prompts and suggestions are not retained after the session ends (beyond the duration needed to serve the request).

For code telemetry, GitHub does collect usage data (which features are used, which suggestions are accepted, error rates). This is not code content; it is operational telemetry. If even this is a concern, you can disable telemetry collection through admin settings.

Access controls: the CC6 requirements

For SOC 2 CC6, you need to control who has access to GitHub Copilot in your organization. The relevant controls:

License provisioning. Copilot Business/Enterprise licenses are assigned per user through your GitHub organization. Only add licenses through your standard onboarding process. Revoke immediately on offboarding.

Policy configuration. GitHub Copilot admin settings let you control: which GitHub organizations have Copilot enabled, whether Copilot can suggest code matching public repositories (this is the IP risk toggle), and whether Copilot Chat is enabled separately from code completion.

Audit log. GitHub Organization audit logs record Copilot policy changes and access grants. Make sure your security team has access to org-level audit logs and exports them to your SIEM or log aggregator.

IP risk: the code matching toggle. One control that SOC 2 auditors and legal teams ask about: Copilot can be configured to filter out suggestions that match public repository code above a certain length. This protects you from inadvertently including GPL-licensed or other restricted code in your product. Enable this in Copilot policy settings.

The "code sent to GitHub" concern in enterprise security questionnaires

Security questionnaires from enterprise customers will ask whether you use AI code completion tools and whether that means their data leaves your environment. The accurate answer for Copilot Business/Enterprise:

Source code is sent to GitHub's servers to generate suggestions. GitHub does not retain the code after the session. Code is not used for model training. The connection is encrypted in transit. The appropriate data handling terms are in place via the GitHub DPA.

If a customer's security team asks for evidence, point them to GitHub's trust documentation and your signed DPA.

What to document in your SOC 2 evidence

Evidence for CC9.1 (vendor management):

• GitHub Copilot vendor inventory entry (data received, risk tier, DPA reference)
• GitHub's current SOC 2 Type II report stored in vendor documentation folder
• Annual reassessment date on calendar

Evidence for CC6 (logical access):

• Screenshot or export of Copilot license assignments in GitHub organization admin
• Offboarding checklist confirming Copilot license revocation
• Copilot policy settings (training off, IP filtering on)

Evidence for CC1 (acceptable use):

• AI acceptable use policy naming GitHub Copilot, stating what data classifications are permitted in prompts

Quick compliance checklist

Getting GitHub Copilot audit-ready comes down to mapping its data flows to your SOC 2 and GDPR controls, confirming the DPA and sub-processors, and keeping that evidence current as the service changes. If you would rather a security leader owned that work than chase screenshots, book a call.

Want a security leader to run this?

Xorabyte is a fractional CISO for startups who can answer a blocked security questionnaire, so a blocked deal or an audit stops being your problem to carry alone. Book a call and you will leave with a clear path, not a sales pitch.