SOC 2, reviewed in the pull request.
SOC 2 is not a checklist of code rules. It is an attestation against the Trust Services Criteria, and most of those criteria are about policy, process, and evidence. A handful, almost all in the CC6 common-criteria family for logical access, are decided by what your code actually does. Those are the ones a review can catch before the audit period closes.
Most criteria are evidence. A few are decided by a diff.
An auditor samples your access controls, your change process, and your monitoring over a window, then writes an opinion. The control either operated effectively across that window or it did not. A single pull request that quietly weakens logical access or drops an encryption floor is the kind of exception that turns into a finding months later. heygrc reads the change while it is still a diff and names the criterion it touches, so the exception never enters the window in the first place.
The Trust Services Criteria a review can actually catch.
Each row is a real criterion reference and the kind of change that trips it. heygrc cites the criterion on the finding, not a vague posture note.
- CC6.1logical access controls
An IAM role or policy broadens, an authorization check is dropped on a route, or a new code path reaches data or an action it previously could not.
- CC6.2provisioning and deprovisioning
User or service-account creation stops requiring approval, or an offboarding path that revoked access is removed or short-circuited.
- CC6.6protection against external threats
A boundary weakens against the outside: a service that was internal becomes publicly reachable, a firewall or network restriction is loosened, or an external access point drops a protection.
- CC6.7protecting data in transit and movement
A TLS floor drops, certificate verification is disabled, an internal call carrying sensitive data moves to plain HTTP, or a new export sends data outside its boundary without the expected controls.
- CC6.8guarding against malicious software
A dependency-integrity check, signature verification, or allowlist is removed, or untrusted input reaches an execution path.
- CC7.2monitoring and anomaly detection
A pull request deletes a security log, an alert rule, or a metric, shrinking what the system can notice and flag in production.
- CC8.1change management
A release or migration path skips the review, approval, or rollback step the control expects before a change reaches a production system.
A one-line change that widens CC6.1.
A pull request fixes a permissions bug by giving the service account a broader role. It also hands every caller of this path write access to a resource that logical-access controls are supposed to restrict.
resource "aws_iam_role_policy" "worker" {
- actions = ["s3:GetObject"]+ actions = ["s3:*"] resources = [aws_s3_bucket.customer.arn]
}This widens the worker role from read-only to every S3 action on the customer bucket, including delete and policy changes. CC6.1 (logical access) expects access to be restricted to what the role needs. Scope the policy to the specific actions this change requires, rather than a wildcard, so the least-privilege story holds when the auditor samples it.
A review, not an attestation.
heygrc flags changes that touch a Trust Services Criterion and cites the criterion so the fix happens in the pull request. It does not perform your SOC 2 audit, issue an opinion, or replace your auditor or your control owners. It catches the change early so the audit window has fewer exceptions to explain. heygrc is in early access.