Engineers heading into a first ISO 27001 often picture a giant code audit, or a certificate you pass the way you pass a test suite. It is neither. ISO/IEC 27001:2022 is a management-system standard. You build an information security management system (policies, risk treatment, roles, suppliers, incidents, and the rest). An accredited certification body audits that system and, if it conforms, issues a certificate. The GitHub repository is not the thing being certified.
This page is about the small slice that does live in the repo: the Annex A technological controls that a pull request can quietly weaken. It is the ISO 27001 sibling of the SOC 2 and HIPAA "what it actually checks" guides. It is not the control catalog (that is the framework hub), and it is not the "is there a GitHub App" question (that is its own answer).
The certificate is not a repo scan
A SOC 2 Type II report is an independent CPA firm's opinion on whether your controls, as you described them, were suitably designed and operated effectively over a period. A Type I report speaks only to design at a point in time. An accredited ISO 27001 certificate is different in kind: an accredited certification body attests that your management system conforms to the standard. Neither is a static scan of source. Neither is issued by a GitHub App. If a vendor implies that installing a reviewer "gets you ISO 27001", they are describing a different product than the standard.
Annex A of ISO/IEC 27001:2022 lists 93 controls across four themes (organizational, people, physical, technological). You do not implement all 93 as a code checklist. The Statement of Applicability records the controls you determined were necessary, why they are included, whether they are implemented, and why any Annex A control is excluded. Annex A is a reference set you check those decisions against, not a menu of 93 items to implement as code. Most of the 93 never appear in a diff: supplier contracts, physical offices, HR screening, risk-treatment paperwork. Treating the 93 as a repo audit is the wrong grain.
The Annex A slice that lives in code
The technological theme (A.8) has 34 controls. Even there, only a handful routinely show up in a pull request: logging (A.8.15), monitoring (A.8.16), cryptography and key handling (A.8.24), restricting access (A.8.3), authentication strength (A.8.5), configuration staying matched to a baseline (A.8.9), secure coding (A.8.28), change management (A.8.32), and information backup (A.8.13). If you can reason about who can reach what, how they prove who they are, what gets logged, how secrets are held, and whether a change still went through the process you wrote down, you are reasoning about most of the code-facing surface.
The rest of A.8 (networks, capacity, malware, clocks, and so on) is real, but it is usually decided in architecture and operations, not in a two-line application PR. The framework hub lists the triggers. This page is the mental model: ISO 27001 in a repo is those A.8 shapes, not the certificate and not the whole Annex A list.
A privileged path that quietly drops a second factor
A support team cannot mint an API token during an incident because the admin route requires MFA and the on-call phone is in a locker. A pull request removes the second-factor check and leaves the session cookie as the only gate. Tests stay green. The code is shorter. Review comments are about unblocking the incident. After merge, anyone who can obtain a valid session can mint a privileged token without the extra factor the path used to demand.
ISO 27001:2022 A.8.5 is about authentication strength. A privileged action that used to require a second factor and now only requires a session is weaker after the merge. Whether that is acceptable (a documented, time-boxed incident exception versus a permanent hole) is a risk decision for the team. The review's job is to name the control so the decision is made on purpose. A.8.3 (restricting access) can sit next to it if the token is how access is granted.
The reverse change, putting requireMfa back on the route, or routing incident token-minting through a break-glass path that is logged and expires, is cheap on the PR. Leaving the weaker path in place is the expensive version: six months later a certification-body sampler can ask how privileged actions are authenticated, and the context is gone.
Where heygrc fits, and the honesty boundary
heygrc is a GitHub App that reviews each pull request against the frameworks you selected and cites the Annex A control a change touches, for example A.8.5 on the MFA skip above, or A.8.15 when a privileged action stops being logged. It does not certify you. It does not run your ISMS. It does not write the Statement of Applicability, choose the certification body, or issue a certificate. Neither heygrc nor ISMS Copilot holds an ISO 27001 certification. Use it as a reviewer of the change, not as the management system.
If the question you actually typed was "is there a GitHub App for ISO 27001", the short answer is yes, and it lives on its own page. This guide is the other half: what that App would even be looking at, and why most of ISO 27001 will never appear in the diff.