Not bugs. Changes that would show up in an audit. Nine families, mapped to ISO 27001:2022 and SOC 2. The list is the grain of the review, not 93 Annex A rows.
A compliance-relevant change is a diff that would matter in an audit: it moved who can reach what, what gets logged, how long a trail is kept, how a secret is held, or whether a control still has evidence. It is usually not a bug. Tests can stay green. The code can be shorter. The obligation is weaker after the merge than before.
heygrc does not run a fixed rules pack. It reads the pull request against the frameworks you selected (ISO 27001:2022 Annex A, SOC 2 TSC, GDPR, NIS 2, and the rest of the catalog) plus the company context you gave it. The families below are the shapes that review looks for. They are not every control in Annex A, and they are not a promise that every row will fire on every repository.
Change families and the clauses they usually cite
| Change family | ISO 27001:2022 | SOC 2 |
|---|---|---|
| Access control and authorization | A.5.15 to A.5.18, A.8.2 to A.8.5 | CC6 |
| Authentication | A.8.5 | CC6 |
| Logging, monitoring, and how long trails are kept | A.8.15, A.8.16 | CC7 |
| Data handling: new PII fields, exports, masking, deletion | A.8.10 to A.8.12 | CC6 |
| Encryption in transit and at rest, key handling | A.8.24 | CC6 |
| Secrets and credentials in code or config | A.8.24 | CC6 |
| Vendors and third parties: SDKs, subprocessors, outbound flows | A.5.19 to A.5.23 | CC9 |
| Retention and deletion rules | A.8.10, A.5.33 | CC6 |
| Audit evidence: approvals, CI gates, migrations | A.8.32, A.5.33 | CC8 |
The nine families
Access control and authorization: roles, permissions, row-level security, admin paths. A widened IAM role or a new unauthenticated route is this family. ISO 27001:2022 A.5.15 to A.5.18 and A.8.2 to A.8.5. SOC 2 CC6.
Authentication: MFA, sessions, credential handling. A privileged route that used to require a second factor and now only requires a session is this family. A.8.5. SOC 2 CC6.
Logging, monitoring, and audit trails, including how long they are kept. Treat this as illustrative: dropping audit-log retention from 365 days to 30 is A.8.15 and SOC 2 CC7.2. Monitoring sits next to it at A.8.16.
Data handling: a new PII field, an export, masking removed, a delete path that misses a store. A.8.10 to A.8.12. SOC 2 CC6 when the change is who can reach the data.
Encryption in transit and at rest, and key handling. A.8.24. SOC 2 CC6.
Secrets and credentials in code or config. A key pasted into source is an exposed secret. A.8.24. SOC 2 CC6.
Vendors and third parties: a new SDK, a subprocessor, an outbound data flow that did not exist yesterday. A.5.19 to A.5.23. SOC 2 CC9 when the change is a supplier relationship expressed in code.
Retention and deletion rules. A new table of identified events with no purge job. A.8.10 and A.5.33. SOC 2 CC6.
Audit evidence: approvals, CI gates, migrations that drop a required check. A.8.32 and A.5.33. SOC 2 CC8. A CODEOWNERS edit that removes a domain owner is this family.
How this sits next to the ISO-in-repo guide
Most of these families land in Annex A theme A.8, the technological controls. That is the same slice as the ISO 27001-in-repo guide: logging, authentication, access restriction, cryptography, change management. A few families also cite A.5 when the change is how you grant access, add a vendor, or keep records. The 93-control Annex A list is still the wrong grain. You do not implement 93 items as a code checklist. The Statement of Applicability is where those decisions live.
GDPR, NIS 2, HIPAA, CCPA, and the rest of the catalog reuse the same change families and cite their own clauses. The ISO and SOC 2 columns in the table are the usual landing. They are not the only landing.
Severity, and a change that improves a control
Severity is the compliance risk of merging the pull request as-is. A finding names the control so the team can decide on purpose. A pull request that restores MFA, lengthens retention, or removes a hardcoded key is not a finding. That change gets a note in the summary.
heygrc posts a neutral GitHub check by default. It does not certify you, write the Statement of Applicability, or replace an auditor. It is live as a GitHub App. Use it as a reviewer of the change.