Securing a GitHub organisation starts with the tokens and integrations it has not yet restricted: a classic personal access token with no expiry, an OAuth app any member authorised, or an Action referenced by a tag that someone else can move. This template is a tickable audit of GitHub organisation settings, each check tied to the setting name GitHub uses in its own documentation as checked on 8 November 2026. It covers sign-in and membership, personal access token policy, GitHub Apps and OAuth apps, base permissions and member privileges, Actions policy and the GITHUB_TOKEN, secret scanning and push protection, rulesets, and the audit log. It is written for organisation owners, platform engineers and security reviewers. For why each control matters and how GitHub credentials fit together, read the GitHub and GitHub Actions Security Guide; this page audits.
This is an independent guide from NHI Mgmt Group, based on GitHub's public documentation as of November 2026. It is not sponsored or reviewed by GitHub. Product features change, so confirm settings against GitHub's current documentation.
How to use this template
- Replace text in square brackets, such as [Organisation], [org name] and [SIEM], with your own details. Run the checklist per organisation; enterprise owners should also record which settings are enforced at enterprise level, because an enterprise policy overrides the organisation setting.
- Setting names in bold are quoted from GitHub documentation. GitHub renames settings and moves menus, so confirm the wording in your organisation's Settings pages when you audit.
- Mark each line Pass, Fail or Exception (link the risk acceptance), and keep evidence: a screenshot, an API export of the setting, or an audit log query.
- Some features depend on plan. SAML single sign-on enforcement is a GitHub Enterprise Cloud feature, and repository push protection requires GitHub Secret Protection. Where a feature is not in your plan, record the compensating control.
- Repeat the audit every quarter, and after any new owner, new integration or plan change.
1. Audit record
| Field | Value |
|---|
| Organisation, plan and enterprise | [org name], [Free / Team / Enterprise Cloud / Enterprise Server], [enterprise account if any] |
| Owners at audit | [number] owners: [names]; target 2 to [4] |
| Members, outside collaborators, bots | [numbers] |
| Installed GitHub Apps and approved OAuth apps | [numbers] |
| Auditor and date | [name], [date] |
2. Sign-in and membership
| Check | Result |
|---|
| Two-factor authentication is required for members, outside collaborators and billing managers. Note GitHub's warning: outside collaborators without 2FA are removed when you turn it on, including bot and service accounts that are outside collaborators. | [ ] |
| Where offered, "require secure methods of two-factor authentication" is on, so only passkeys, security keys, authenticator apps and GitHub Mobile are accepted, not SMS. | [ ] |
| Enterprise Cloud: Require SAML SSO authentication for all members is on, SSO recovery codes are stored in a password manager, and bots and service accounts have IdP identities so enforcement does not remove them. | [ ] |
| Owners are named people using individual accounts, between 2 and [4] of them; no shared owner login. | [ ] |
| Leavers are removed through the identity provider (SCIM where available) on their last day; no member account remains for someone who has left. | [ ] |
| Outside collaborators have an internal sponsor and an expiry date, and are reviewed each quarter. | [ ] |
3. Personal access token policy
| Check | Result |
|---|
| Tokens (classic) are restricted: Restrict personal access tokens (classic) from accessing your organizations is selected, or there is a dated plan to get there. Classic tokens have no expiry requirement and are not subject to approval. | [ ] |
| Fine-grained tokens require approval: Require administrator approval is selected (it is the default). Pending requests are reviewed within [5] working days. | [ ] |
| A maximum lifetime is set for fine-grained tokens below the 366 day default, for example [90] days, and for classic tokens if they are still allowed. Non-compliant tokens are blocked from the organisation, though the policy does not revoke them. | [ ] |
| Approved fine-grained tokens are reviewed quarterly; tokens owned by leavers or unused for [90] days are revoked. | [ ] |
| Automation uses GitHub Apps or OIDC rather than personal tokens on bot accounts. See the GitHub Personal Access Tokens Security Guide. | [ ] |
4. GitHub Apps, OAuth apps and keys
| Check | Result |
|---|
| OAuth app access restrictions are enabled. Without them, any OAuth app a member authorises can also reach the organisation's private resources. | [ ] |
| Each approved OAuth app and installed GitHub App has an owner, a business reason, the narrowest repository selection ("Only select repositories") and permissions reviewed against need. | [ ] |
| Apps unused for [90] days are uninstalled or have access denied; denied OAuth apps have their webhooks disabled automatically. | [ ] |
| Deploy keys are read-only unless write is needed, each has an owner, and unused keys are removed. See How to find unused GitHub deploy keys and SSH keys. | [ ] |
| App private keys and webhook secrets are stored in a secrets manager and rotated on a schedule. | [ ] |
The full review method is in How to audit GitHub Apps and OAuth apps in an organisation.
5. Base permissions and member privileges
| Check | Result |
|---|
| Base permissions are No permission or Read, not Write or Admin; access above that comes from teams. Base permissions do not apply to outside collaborators, and internal repositories stay readable to members even at none. | [ ] |
| Repository creation by members is limited to private (and internal where used); public repository creation is limited to a named team or owners. | [ ] |
| Members cannot change repository visibility, delete or transfer repositories. | [ ] |
| Forking of private repositories is disabled or limited to the organisation. | [ ] |
| Only owners or a named team can invite outside collaborators. | [ ] |
| Team maintainers and repository admins are reviewed quarterly; admin on a repository is given to a team, not to individuals. | [ ] |
6. Actions policy and GITHUB_TOKEN
| Check | Result |
|---|
| Actions policy allows only organisation actions and a named allow list of external actions and reusable workflows, not all actions. | [ ] |
| Require actions to be pinned to a full-length commit SHA is enabled, or every workflow pins third-party actions to a SHA. Tags can be moved; the 2025 tj-actions/changed-files compromise repointed version tags to a commit that dumped runner secrets into logs. | [ ] |
Default GITHUB_TOKEN workflow permissions are read-only (read access to contents and packages); workflows request more through a permissions: block per job. | [ ] |
| Allow GitHub Actions to create and approve pull requests is off (the default for new organisations), so a workflow cannot approve its own change. | [ ] |
| Approval for running fork pull request workflows from contributors is set to Require approval for all external contributors for public repositories. GitHub warns that first-time contributor settings can be met by getting a trivial change merged. | [ ] |
Workflows using pull_request_target are listed and reviewed: they run in the base branch context, with secrets, regardless of approval settings. | [ ] |
| Self-hosted runners are not available to public repositories, sit in runner groups limited to named repositories, and are ephemeral where possible. | [ ] |
| Secrets needed for deployment sit in environments with required reviewers, not as organisation secrets visible to every repository. Cloud access uses OIDC; see the GitHub Actions OIDC Federation Hardening Guide. | [ ] |
7. Secret scanning and code security
| Check | Result |
|---|
| Secret scanning is enabled on all repositories, through a security configuration applied at organisation level so new repositories inherit it. | [ ] |
| Push protection for repositories is enabled. It is off by default; it blocks partner patterns, and generic and custom patterns where enabled, on command line pushes, web commits, file uploads and REST API requests. | [ ] |
| Push protection bypasses raise alerts, and someone reviews each bypass within [2] working days. Consider delegated bypass so only reviewers can approve. | [ ] |
| Custom patterns exist for internal token formats, with push protection turned on for them. | [ ] |
| Open secret scanning alerts are triaged: the secret is revoked at its issuer, not only removed from the code. See How to revoke a leaked GitHub personal access token. | [ ] |
| Dependabot alerts and code scanning are enabled for repositories that ship code, with an owner for alert triage. | [ ] |
8. Rulesets
| Rule | Applied to | Result |
|---|
| Organisation ruleset targets default and release branches of all repositories (or a named set) rather than per repository branch protection only. | [pattern] | [ ] |
| Require a pull request before merging, with at least [1] approval and dismissal of stale approvals. | [pattern] | [ ] |
| Require status checks to pass, including the security workflows. | [pattern] | [ ] |
| Restrict deletions (on by default) and block force pushes. | [pattern] | [ ] |
| Require signed commits where the team can support it. | [pattern] | [ ] |
| Tag ruleset restricts creation, update and deletion of release tags to a release team or app. | [tag pattern] | [ ] |
| Bypass list is short, named and reviewed; no "everyone with admin" bypass. | [list] | [ ] |
9. Audit log and monitoring
| Check | Result |
|---|
| Enterprise Cloud: audit log streaming sends events to [SIEM]; otherwise the audit log is exported on a schedule. | [ ] |
| Alerts exist for new owners, OAuth app approvals, GitHub App installations, changes to PAT policy, Actions policy and rulesets, repository visibility changes and push protection bypasses. See the GitHub Audit Log Detection Guide. | [ ] |
Searches for removed members after 2FA or SSO enforcement (for example action:org.remove_outside_collaborator) are run and followed up. | [ ] |
10. Findings and sign-off
| Finding | Severity | Owner | Due date |
|---|
| [finding] | [high / medium / low] | [name] | [date] |
Sign-off: [reviewer], [date].
Implementation guidance
Order of work: start with settings that cannot break builds: OAuth app restrictions (after approving the apps in use), Actions create and approve pull requests off, and secret scanning. Then read-only GITHUB_TOKEN defaults, which break workflows that relied on write access: change the default, watch failed runs for a week, and add per-job permissions: blocks. Restricting classic tokens and SHA pinning come last because they need inventory: list the classic tokens in use from the audit log and the actions in use from workflow files, give owners a deadline, then switch.
Testing and rollback: trial each change on a test organisation or a pilot set of repositories first. Rulesets support an evaluate mode on Enterprise Cloud for watching what would be blocked before enforcing. Every setting here can be reverted by an owner, but removals caused by 2FA or SSO enforcement need re-invitations, so check the non-compliant list before switching.
Small and large organisations: a small team on the Free or Team plan can still require 2FA, restrict classic tokens, enable OAuth app restrictions, set read-only GITHUB_TOKEN and use rulesets. Large enterprises should set token, Actions and 2FA policy at enterprise level so new organisations inherit it, and stream the audit log.
Metrics: number of owners; classic tokens with organisation access (target 0); approved fine-grained tokens past [90] days; installed apps without an owner (target 0); repositories without push protection (target 0); workflows with third-party actions not pinned to a SHA; median time to revoke a leaked secret.
| Checklist section | NIST SP 800-53 Rev. 5 | NIST CSF 2.0 | ATT&CK |
|---|
| Sign-in and membership (2) | IA-2, AC-2 | PR.AA-01 | T1078.004 Cloud Accounts |
| Tokens and apps (3, 4) | IA-5, AC-6 | PR.AA-05 | T1528 Steal Application Access Token |
| Actions policy (6) | SR-3, CM-3 | GV.SC-07 | T1195.002 Compromise Software Supply Chain |
| Secret scanning (7) | IA-5 | PR.PS-01 | T1552.001 Credentials In Files |
| Audit log (9) | AU-2 | DE.CM-09 | |
Standards and references
Related NHI Mgmt Group resources: GitHub and GitHub Actions Security Guide · GitHub Personal Access Tokens Security Guide · GitHub Audit Log Detection Guide · GitHub Actions OIDC Federation Hardening Guide