Somebody asks who deleted a repository three months ago. Or whether a departed contractor cloned anything unusual. Or what the impact would be of requiring signed commits everywhere.
These are operations questions, and answering them requires a platform you can observe, govern and change safely — none of which is a default.
Start with the Enterprise Audit LogWhat this cluster answers
Section titled “What this cluster answers”The audit architecture
Section titled “The audit architecture”GitHub Enterprise produces audit events, Git events and API events; these flow through an audit stream to a SIEM or storage; which supports detection and investigation.
The three event categories are genuinely different, and treating them as one is the commonest mistake in this area:
Audit events — configuration and administrative actions. Retained by GitHub for 180 days.
Git events — clone, fetch and push activity. Retained for seven days, and on GitHub Enterprise Cloud accessible via the REST API. Seven days is shorter than most investigations start.
API request events — requests to enterprise endpoints. Public preview at the time of writing, available to enterprises using Enterprise Managed Users and GitHub Enterprise Cloud with data residency, and available only via audit log streaming. They do not appear in the web UI.
Streaming is where retention lives
Section titled “Streaming is where retention lives”GitHub’s audit log streaming sends events to Amazon S3, Azure Blob Storage, Azure Event Hubs, Datadog, Google Cloud Storage, Microsoft Purview or Splunk.
Two properties to design around:
Delivery is at-least-once. GitHub’s documentation states that GitHub uses an at-least-once delivery method and that due to certain network or system issues, some events may be duplicated. Any consumer must be idempotent, and a count of events is not a reliable metric.
Streams have a health model. A health check runs every 24 hours, misconfiguration emails enterprise owners, and a broken stream must be fixed within a bounded window before events are lost. A stream nobody monitors is a stream that silently stopped.
Audit log streaming covers the operational details including pausing behaviour and OIDC authentication.
Actions governance is a different discipline from workflow authoring
Section titled “Actions governance is a different discipline from workflow authoring”Pillar 4 teaches writing workflows. This cluster teaches deciding what an organisation permits.
Three articles, three scopes:
Actions governance — the settled controls: which actions may run, workflow permission defaults, fork pull request behaviour, artifact retention, runner policy.
Runner groups — the fleet: which runners which repositories may use, and the security boundary that represents. Not a self-hosted runner tutorial; Pillar 4 has that.
Actions policies — the newer, ruleset-based mechanism. Actions policies and workflow execution protections are both in public preview at the time of writing, and the article says so throughout.
Change management is the operational skill
Section titled “Change management is the operational skill”The article that ties the cluster together is policy rollout, because applying a new rule to two thousand repositories is a change-management problem rather than a settings change.
A vertical sequence: draft the policy; target pilot repositories; evaluate without enforcing; measure impact; fix exceptions; enforce; monitor.
Evaluate mode is the feature that makes this possible. A ruleset can be set to an enforcement status of evaluate, which does not enforce but reports which actions would violate it. Skipping that step is how a reasonable security rule stops every build in an organisation before lunch.
Automation, not clicking
Section titled “Automation, not clicking”At a few hundred repositories the web UI stops being a viable interface.
Enterprise API automation builds on Pillar 3’s API material with the operational patterns that matter at scale: pagination that does not miss records, rate-limit handling that does not hammer, GraphQL where REST would take a thousand requests, GitHub App authentication instead of a personal token, and — above all — read-only inventory before anything mutates.
The rule this cluster returns to: a script that modifies repositories must have a dry-run mode, must show the target set before acting, and must be restartable. A one-off script that mutated four hundred repositories and failed at 250 is a bad afternoon that could have been a good one.
Compliance, precisely
Section titled “Compliance, precisely”Compliance evidence is deliberately careful, because this is where enterprise content most often overclaims.
GitHub configuration can produce evidence and enforce controls. Audit logs show what happened. Rulesets show what was required. Access records show who could reach what.
No GitHub setting makes an organisation compliant with SOC 2, ISO 27001, PCI DSS, HIPAA or FedRAMP. Those are programmes with scope, policy, people and process. Tools support them; nothing in a settings page satisfies them.
Collecting logs is not monitoring
Section titled “Collecting logs is not monitoring”A distinction worth making before the audit articles, because the gap between them is where organisations lose time.
Collection is a stream to storage. It answers questions somebody asks.
Monitoring is detection: rules that fire when something happens, without anybody asking.
Most enterprises have the first and believe they have the second. The audit stream is configured, the SIEM ingests it, and no alert has ever been written. The data is genuinely useful for investigations and it detects nothing.
A short list of things worth alerting on, which most estates do not:
An enterprise or organisation owner being added. A ruleset being deleted or moved to disabled. A repository changing visibility from private or internal to public. A bypass of a protected branch. An audit stream health check failing. A large number of repository deletions in a short window. SSO being disabled.
Each is rare enough to alert on and consequential enough to want to know about within minutes. Writing seven detection rules is an afternoon and it converts a log archive into a control.
The honest caveat: alerting requires knowing what normal looks like, which requires the collection to have been running for a while first. Collection genuinely comes before monitoring — the failure is stopping there.
Learning objectives
Section titled “Learning objectives”By the end of this cluster you should be able to:
- Name the three audit event categories and state their retention and availability differences
- Explain why the seven-day Git event window makes streaming a requirement rather than an enhancement
- Design an audit pipeline that tolerates duplicate events and detects its own failure
- Govern which actions may run in an organisation, and at which scope
- Design a runner group topology that separates production from untrusted workloads
- Distinguish settled Actions controls from the preview policy mechanisms
- Roll out a rule to thousands of repositories using evaluate mode and a measured exception process
- Write enterprise automation that paginates correctly, respects rate limits and never mutates without a dry run
- State honestly what GitHub data does and does not evidence for a compliance programme
Enterprise use cases
Section titled “Enterprise use cases”A security investigation where somebody needs to know what a departed engineer accessed — and discovers the Git events expired.
A SIEM integration that must not double-count and must alert when it stops receiving data.
A supply-chain control requiring that only vetted actions run, applied consistently across organisations, without blocking teams that had a legitimate reason to use something else.
A runner fleet where a production deployment runner must not be reachable by a fork pull request.
A mandated policy change — signed commits, required review — that must reach every repository without breaking anybody.
An audit request asking for evidence that only authorised people could change production code, answered from data rather than assertion — and answered in an afternoon rather than a fortnight, which is what the difference between having an inventory and not having one actually costs.
What breaks at scale
Section titled “What breaks at scale”The operational realities that distinguish this cluster from a settings guide.
The web UI stops working as an interface. Not metaphorically — a page listing repositories becomes unusable past a few hundred, and there is no view that answers “which repositories lack a code owner”. Everything becomes API work.
Rate limits become a design constraint. A script iterating every repository in a large enterprise will hit them. Handling that properly — backing off, resuming, using GraphQL to reduce request counts — is the difference between a job that completes and one that half-completes nightly.
Event volume becomes a cost. A large enterprise generates a great deal of audit data, and streaming all of it including API request events has a real storage and ingestion bill. That is a decision to make deliberately rather than discover.
Change becomes risky. A settings change that affects one repository is reversible in a minute. One that affects two thousand is an incident if it is wrong, which is why rollout has its own article.
Nobody knows the whole estate. Past a certain size no individual has seen every repository, and decisions must be made from data rather than familiarity. This is the underlying reason inventory and metadata matter so much in the fleet cluster.
The common thread: every one of these is solved by automation plus data, which is why this cluster’s two most practically useful articles are the audit ones and the API one.