The change inside the routine change.
ISO 27001:2022 A.8.32 (change management) asks for changes to information processing facilities and systems to follow change management procedures. In practice that means a change is planned, its impact (security included) is assessed, it is authorised, tested and communicated, there is a way back if it fails, emergency changes have their own handling, and records are kept.
Most of that sits in a ticketing or release process. The piece a pull request holds is the change itself, and whether what it actually does matches what was assessed and approved. The failure mode is rarely an unapproved change; it is an approved change that does more than anyone approved.
The shapes the same control failure takes.
A.8.32 weakens when the diff and the description drift apart, or when the safety net around a change is removed inside it. The recurring shapes:
The diff is bigger than its description
A pull request titled as a dependency bump, a rename or a cleanup also changes behaviour, and the impact assessment, if any, covered the title rather than the diff.
An infrastructure edit rides along
A security-relevant infrastructure setting (a network rule, an encryption flag, a retention period) changes inside a pull request about something else, so it never gets an impact assessment of its own.
The fallback is removed
A snapshot, a migration down-step, a feature flag or a blue-green switch that made the change reversible is deleted, so a failed change can no longer be backed out cleanly.
A change reaches production outside the pipeline
A script, a console step or a manual apply is added to the runbook for this change only, so it bypasses the path where changes are recorded and assessed.
An emergency change is never revisited
A hotfix merged under pressure (checks skipped, review waived) is never assessed after the fact, so the emergency path becomes a permanent shortcut with no record of why.
A provider upgrade that also removes a production safeguard.
A pull request titled "chore: bump database provider" upgrades the infrastructure provider version. The upgrade renamed an argument, and while fixing the plan, two lines on the production database change as well: deletion protection is turned off and the final snapshot on destroy is skipped. The description, the ticket and the approval all talk about a version bump.
resource "aws_db_instance" "primary" { engine_version = "16.4"- deletion_protection = true- skip_final_snapshot = false+ deletion_protection = false+ skip_final_snapshot = true}Besides the provider bump, this turns off deletion protection on the primary production database and skips the final snapshot on destroy. Together they remove both the guard against an accidental delete and the fallback if one happens, and neither appears in the pull request description. A.8.32 expects a change's impact to be assessed before it is authorised; this part of the change was not described, so it was not assessed. Revert these two lines, or split them into their own change with a stated reason and an impact assessment.
Security reading of the same pull request
heygrc reviews this pull request against A.8.32. Aevral, an AI security reviewer from the same company, reads the same diff for security flaws and posts at most two findings as leads with evidence, so the security side of the change is looked at whatever the title says.
What that contributes to A.8.32: part of evaluating a change before it is authorised. It is not the change approval, and it does not see emergency changes that never went through a pull request.
A.8.32 is sampled as a trail, one change at a time.
An auditor picks a set of changes from the period and traces each one: the request, the impact assessment, the approval, the test evidence, the deployment record, and for emergency changes, the after-the-fact review. The trail usually holds together at the level of the ticket. What it does not show is a change whose diff did more than its ticket said, and that is the gap an auditor finds when they open the pull request behind a sampled change and read the code instead of the title.
A review, not your change process.
heygrc flags changes whose security impact is not reflected in how they were described and cites the control so the fix happens in the pull request. It does not approve changes, run your change advisory process, or track emergency changes. It catches the moment a change does more than it says, at the diff.