A pull request can pass tests, clear security scanning, and still invalidate the evidence behind a compliance control.

The problem is timing. Most teams discover that impact during an audit or after a control narrative has already drifted away from production. By then, the code is merged and the person who understood the change has moved on.

The TestifySec platform evaluates a scoped question inside the pull request workflow: which compliance controls and framework criteria does this change affect?

From changed code to affected controls

The platform maintains watchpoints that connect specific code and configuration ranges to the evidence used by compliance controls. When GitHub sends a pull request event, the platform compares the exact base and head commits against the product's active compliance plans.

The resulting GitHub check is informational; it does not block a merge. It reports four signals:

  • Changed compliance watchpoints
  • Affected controls
  • Affected framework criteria
  • Hash-gated false positives

The check links to a page bound to that repository, pull request, base commit, head commit, and compliance plan. A later push cannot silently change the result being reviewed.

Judge pull request compliance impact showing two affected controls and six framework criteria

The summary stays visible beside the pull request's other engineering checks, with a direct link into the detailed control review.

GitHub compliance impact check linking to the TestifySec platform

A concrete example

In the illustrated example above, a change inside the monitored deployment configuration affected one watchpoint. the platform traced that evidence to two controls:

  • CM-2, Baseline Configuration
  • SC-8, Transmission Confidentiality and Integrity

Those controls mapped to six criteria across NIST 171 and SOC 2. The pull request did not need a generic warning that "compliance might be affected." It identified the exact review surface.

If no changed file overlaps active compliance evidence, the same check closes cleanly with zero impact. Hash comparison prevents unchanged evidence from becoming noise just because nearby lines moved.

Review the change while context is fresh

This moves compliance review into the same decision window as engineering review. The control owner can see what changed, the engineer can explain why, and the evidence can be refreshed before the pull request merges.

That creates a tighter operating loop:

  1. Code and configuration are linked to control evidence through watchpoints.
  2. A pull request changes a monitored range.
  3. Judge evaluates the exact commit pair against active plans.
  4. GitHub surfaces the result where the team already reviews code.
  5. The linked platform page shows the affected controls and criteria.

GitHub event attestations are a separate part of the integration. They create signed records of push, pull request, and pull request review deliveries. PR compliance impact uses those repository events to trigger analysis, but it does not claim that an impact result is itself an event attestation.

Compliance that follows the software

Change impact identifies configured evidence that may need review. It is not a determination that a control is satisfied or a guarantee that every relevant change has been detected.

The platform gives engineering and compliance teams the same answer, attached to the same pull request, before the decision becomes production history.

See the TestifySec platform