Here are two different approaches you could take:

(1/2) Migrate to a new way of managing github repo configuration where some system governs what repos are allowed to exist, and ensures they are configured correctly per your company's engineering standards. One way to do this is a "git-ops" configuration-as-code approach where you declare the repos and their configuration in terraform and use the github terraform provider to manage this state via the github API. These terraform files describing the desired state of your repo resources would of course also be version controlled in some github repo.

With this approach, github org members are no longer allowed to manually create and configure repos with arbitrary configuration via the easy and familiar click-ops route through the github UI. You could require that all existing and new repos adhere to some standard policy for configuring branch protection, or enforce mandatory code review to terraform changes that propose adding new repos or adjusting the configuration of existing repos. See the github terraform provider: https://registry.terraform.io/providers/integrations/github/...

(2/2) Github exposes APIs you can use to enumerate all repos owned by an org and interrogate their configuration, such as how branches are named, branch protection rules, if reviews are required or tests must pass before merge, etc. You can use these APIs to build a custom repo audit compliance app. It might be a day or three of effort from one competent & motivated engineer to get a basic proof of concept app running that can be pointed at your github org to dump a giant compliance CSV report, provided the engineer is supported by an org admin who can grant the app the appropriate permissions.

I worked in a large enterprise with many github repos and saw both (!) of these approaches successfully applied by different teams at different times.

I reckon the first approach (switching to a git-ops approach to manage repo using terraform) is the superior solution, but would require changing what is responsible for governing your company's repos, and a corresponding change in engineering culture from "anyone can just create a repo" to "repos are created/modified by a controlled process" so you might need to build some support and buy-in for this kind of change. It would also need work to figure out how to reconfigure all the existing arbitrarily-configured github repos and wrestle them into standardised configuration without disrupting your company's ability to ship and support software.

The second approach doesn't require anyone else to change how they're working so there's less friction to rolling it out. This approach doesn't ensure repos are configured correctly but you can periodically run your custom github repo audit app to generate a non-compliance report and then chase up teams to fix their branch protection settings. I worked in a small team that built and delivered a custom internal github app to do this kind of repo audit in a fiefdom of the company that owned a few hundred randomly configured github repos that needed to be audited and configured for compliance purposes. Alas, this github app audit tool wasn't open sourced.