Least privilege, enforced at the diff.
CC6.1 is one of the Trust Services Criteria a normal pull request can quietly weaken, because it is about logical access, and logical access often lives in code and configuration. The criterion asks that access to your systems and data be restricted to the users and processes that are authorized to have it. In practice that means least privilege: a role can reach what it needs for its job, and no more.
The shapes the same control failure takes.
CC6.1 rarely breaks with a line that says 'grant everyone admin'. It breaks in ordinary, reasonable-looking changes. These are the shapes that recur.
An access policy widens
An IAM role, security group, or grant gains broader actions or a wildcard, so a component can now do more than its job needs.
An authorization check is dropped
A route loses its role or ownership check, or an authorization middleware stops being applied to a new endpoint, so a request that should be rejected now succeeds.
A data grant broadens
A database role gains access to tables or rows it did not have, row-level security is loosened, or a service account is pointed at a database it had no reason to reach.
A default flips to allow
Access changes from default-deny to default-allow: a new resource ships world-readable, or a permission check defaults to true on an unknown case.
A privilege-escalation path opens
A lower-privileged actor gains a way to act as a higher one: an internal flag that bypasses the role check, or a token minted with more scope than the caller holds.
A refactor that drops an authorization check.
A route is being tidied up. The role check in the middle looks redundant next to the auth middleware, so it goes. The endpoint still requires a logged-in user, but it no longer requires the right one: now any authenticated user can delete any project.
- router.delete("/projects/:id", requireRole("admin"),- loadProject, deleteProject)+ router.delete("/projects/:id", loadProject, deleteProject)This removes the role check from a destructive endpoint. The auth middleware confirms the caller is signed in, but CC6.1 is about whether they are authorized for this action, and deleting any project is not something every user should be able to do. Restore the authorization check (a role or ownership check on the project) before the handler.
CC6.1 is sampled, not just stated.
In a SOC 2 examination, CC6.1 is not satisfied by a policy document saying you do least privilege. The auditor samples actual access: who and what can reach a given system, whether those grants match documented roles, and whether anything is broader than its purpose. A wildcard role, an endpoint missing its authorization check, or a service account with standing access it never uses is exactly the kind of exception that becomes a finding, and it usually entered the system in a single pull request months earlier. Catching the change at the diff helps keep those access exceptions out of the sample.
A review, not an attestation.
heygrc flags changes that touch CC6.1 and cites the criterion so the fix happens in the pull request. It does not run your audit or issue an opinion. It catches the access change early so the examination has fewer exceptions to explain. heygrc is in early access.