GitHub outages make AI coding a vendor risk issue

Regulatory action

GitHub has reported recurring service degradation as AI-assisted coding and agentic development workflows drive far heavier use of repositories, pull requests, commits, and related infrastructure. According to the reported figures, GitHub planned for a 10x capacity increase in October 2025, then determined by February 2026 that it needed closer to 30x capacity. The company says it has more than doubled effective capacity in four months, moved 40 percent of monolith traffic to Azure, moved Git traffic to 30 percent Azure service, and brought repository replication to 99 percent.

This is not a new privacy law or trade commission enforcement action. The compliance issue is that existing laws already require organizations to manage the operational risk created by critical software platforms. GitHub outages can interrupt secure development, incident response, release approvals, vulnerability patching, audit evidence collection, and software supply chain controls.

The key legal and regulatory references are:

• The EU General Data Protection Regulation, Regulation (EU) 2016/679, effective May 25, 2018, including Article 32 security obligations for systems that process personal data.
• The FTC Safeguards Rule under the Gramm-Leach-Bliley Act, with the main amended safeguards compliance deadline of June 9, 2023, for covered financial institutions.
• The FTC Act, especially Section 5, which the Federal Trade Commission uses against unfair or deceptive data security practices.
• The SEC cybersecurity disclosure rules, effective September 5, 2023, with Form 8-K Item 1.05 incident disclosure obligations and annual governance disclosures phased in from December 18, 2023.
• The EU Digital Operational Resilience Act, Regulation (EU) 2022/2554, which entered into force on January 16, 2023 and applies from January 17, 2025.
• The NIS2 Directive, Directive (EU) 2022/2555, which EU member states were required to transpose by October 17, 2024.

What it requires

For compliance teams, the practical point is simple: GitHub should be classified according to the business process it supports, not merely as a developer convenience. If the organization uses GitHub for production code, security fixes, infrastructure definitions, CI/CD workflows, release approvals, or incident response scripts, then GitHub availability affects regulated operations.

Under GDPR Article 32, organizations must apply appropriate technical and organizational measures to protect personal data. That requirement is not limited to confidentiality. It also includes integrity, availability, and resilience of processing systems. If a GitHub outage prevents a team from deploying a privacy fix, rotating exposed credentials, reviewing code that handles personal data, or accessing audit history during a security incident, the outage becomes relevant to GDPR accountability.

Under the FTC Safeguards Rule, covered financial institutions must maintain a written information security program, assess risks, test safeguards, oversee service providers, and adjust controls when operations or threats change. A recurring dependency failure in a source code and CI/CD environment should therefore be reflected in the risk assessment. The compliance file should show who owns the risk, what compensating controls exist, how outages are monitored, and how the organization can continue essential security work if GitHub is unavailable.

Under FTC Section 5, the concern is different but related. If a company tells customers that it maintains strong security controls, rapid patching, controlled change management, or continuous monitoring, those claims need operational support. A firm does not violate Section 5 merely because a third-party service has downtime. The risk arises when public statements, security questionnaires, customer contracts, or procurement documents overstate resilience without a tested fallback.

Public companies should also evaluate SEC disclosure controls. The SEC cyber rules focus on material cybersecurity incidents and governance. A GitHub outage alone may not be a cybersecurity incident, and routine downtime will not usually be material. But the same dependency can become material if it prevents containment of a breach, delays a security patch, blocks access to evidence, disrupts a major product launch, or affects revenue systems. Disclosure committees should understand when developer-platform disruption is escalated from engineering status to legal, finance, and investor-relations review.

DORA is more prescriptive for EU financial entities. It requires ICT risk management, incident handling, resilience testing, and third-party risk controls. For banks, insurers, payment firms, investment firms, and other covered entities, GitHub may fall into the ICT third-party service provider inventory if it supports regulated services. Contracts, exit strategies, incident notification processes, concentration risk, and testing evidence matter. The compliance question is not whether GitHub is generally reliable. The question is whether the regulated entity can continue critical functions when the service is degraded.

NIS2 adds a similar operational discipline for essential and important entities across sectors such as energy, transport, banking, health, digital infrastructure, managed services, and public administration. It requires cybersecurity risk management measures and incident reporting through national law. Where software delivery is part of an essential service, dependencies in source control, build systems, and deployment pipelines should be treated as part of the operational risk model.

Compliance timeline

Immediate action should start with dependency classification. Compliance, security, engineering, and procurement teams should identify whether GitHub is used for production source code, infrastructure-as-code, secrets management workflows, release gates, incident response, regulated data processing, customer commitments, or evidence retention. That inventory should reference the official GitHub Status page and incident history, but it should not rely only on vendor uptime percentages. Internal impact is what matters for compliance.

Within 30 days, organizations should update their vendor risk records. The file should include GitHub’s role, affected business services, data categories, access model, recovery expectations, and alternative procedures. Teams should document which functions can continue during a GitHub outage and which cannot. If no workable alternative exists for urgent security patching, that gap should be assigned to an accountable owner with a due date.

Within 60 days, test the fallback plan. A tabletop exercise should cover at least three scenarios: GitHub web access degraded, Git operations delayed, and CI/CD workflows unavailable. The test should confirm whether engineers can access current code, validate emergency changes, preserve approvals, deploy a critical fix, and produce an audit trail. Compliance officers should ask for evidence, not verbal assurance.

Within 90 days, align contracts and customer commitments. Review service descriptions, security addenda, business continuity plans, SOC report mappings, and customer-facing security questionnaires. Statements about uptime, patching, secure development, and disaster recovery should match actual tested capability. If GitHub is embedded in regulated operations, procurement should check whether existing vendor terms provide adequate notice, support, audit information, subcontractor transparency, and exit planning.

For GDPR-covered processing, this review should already be complete because GDPR has applied since May 25, 2018. Any new AI coding workflow that changes repository volume, code generation practices, personal data handling, or release cadence should trigger a security and privacy review now.

For FTC Safeguards Rule entities, the main amended safeguards obligations have been enforceable since June 9, 2023. Covered firms should treat this as an update to the risk assessment and service provider oversight program, not as a future project.

For public companies subject to SEC rules, disclosure controls have been in effect since 2023 and 2024 depending on the issuer category and form. The immediate task is to define escalation thresholds. Engineering status pages should not be the only mechanism for deciding whether an outage affects material operations.

For DORA-covered entities, January 17, 2025 has already passed. GitHub dependencies used for regulated EU financial services should be in the ICT risk register, mapped to critical or important functions where applicable, and supported by contract, testing, and exit evidence.

Compliance officer guidance

Treat the current GitHub availability issue as a control test. The platform’s growth is being driven by the same AI-assisted coding tools that many organizations are adopting to increase engineering throughput. More code generation means more commits, more branches, more reviews, more automated workflows, and more pressure on source control and CI/CD infrastructure. That growth can improve delivery speed, but it also concentrates operational dependency in a small number of developer platforms.

The required response is practical. First, confirm whether GitHub is a critical service. Second, define what business functions fail when it is degraded. Third, test whether the organization can still perform urgent security work. Fourth, correct contracts and public statements that assume availability the organization has not verified. Fifth, make outage reporting visible to the right governance forum.

This does not require abandoning GitHub. It requires governing GitHub like the critical infrastructure component it has become for many software organizations. AI coding has changed the volume profile of development work. Compliance programs now need to catch up with that operational reality.