PRGuard for compliance
Auditors don’t ask whether you review code — they ask you to prove the control operated on every change.
PRGuard turns each pull request and push into an audit-ready record: what was checked against your standards, what failed, who signed off, and how it was fixed.
Evidence, generated automatically.
payments-api · pull request #482
Add retries to the Stripe webhook
Audited against payments.md, version 3
Failed: non-idempotent-handler
Assigned to Priya Nair
Fix approved by Dafydd Rees
Re-audited: passed, score 100
An auditor’s question is simple: show that your code-review control operated on every change last quarter.
Scattered PR comments can’t answer it — some were acted on, some waved through, some scrolled past.
A complete, attributable record can.
Without PRGuard
“We review our code” — but the proof lives in review threads and people’s memories. Demonstrating that a specific standard was checked on every change becomes an archaeology project, repeated at every audit.
With PRGuard
Every change was audited against your written standards, every finding has an owner and an outcome, and every fix links back to the audit that raised it. “Can you prove it?” is answered by a record, not a reconstruction.
Four things a control owner needs — documented standards, enforcement, attribution, and coverage — produced as a by-product of every audit.
Each finding is recorded with a verdict and a governance score, and traced end to end — from first flag, to the approved fix, to the re-audit that closes it. A per-change history you can hand an auditor.
Your policies live as plain-language governance rules and are applied identically to every change, across repositories and teams — the same control, provably consistent, not left to individual reviewers.
Nothing lands without a person’s sign-off. Each fix records who approved it and when, so the record shows human accountability, not an automated rubber stamp.
Pull requests and direct pushes are both audited by default, and any change that reaches a default branch without an audit is listed with the reason. Make PRGuard’s check required on the branch and an unaudited change cannot merge. Exemptions such as skip markers are off until you enable them per repository: a deliberate policy decision, not a loophole. Your attestation covers what actually shipped, not just what went through a PR.
An auditor asks three things: did every change go through the gate, what happened to the ones that didn’t, and can you show the record is complete. PRGuard Assurance answers from records it was already keeping.
Every change that reached a default branch, or a release branch you name, in the period, and how it was governed: audited and passed, merged failing, bypassed with a skip marker, or not audited and why. The population an assessor samples from, with nothing left out quietly.
A finding your team decides to live with gets a justification, a compensating control, an approver who is not the requester, and an end date. When it ends, the finding reopens.
Map each rule file to the controls it supports in the Cyber Resilience Act and the EU AI Act. Readiness shows which controls have a rule that audits actually ran with, and which are gaps.
One ZIP for the period: the ledger, the controls, the rules at the versions that ran, sampled audits, the registers and the journal. Every file is listed with its SHA-256 and one root hash covers the list, so it can be checked offline. Your source code is never in it.
What the records are. PRGuard’s records are append-only and hashed on export, and each journal entry is linked to the one written before it. A pack is signed with PRGuard’s published key, so it shows who made it and whether a copy has changed since, and its journal’s chain shows no entry was removed from its middle. That is not the same as tamper-proof, and neither shows the records were right.
What PRGuard records under the EU AI Act, article by article, and under the Cyber Resilience Act, requirement by requirement.
A single finding, captured against a written standard — the unit of evidence your audit trail is built from.
The rule it breaks, by its name in your own rule file.
Where, and what goes wrong: the file and line, and the consequence in plain words.
How to fix it: a summary, a prompt for your AI assistant, or a patch.
Who owns it, and later who approved the fix.
non-idempotent-handler
Payments
Details
billing/webhooks.py:14
A retried webhook charges the customer twice. Stripe redelivers events after timeouts, and nothing here records what has already been processed.
Non-idempotent payment handler: in handle_webhook(), the charge is written at line 14 without checking ProcessedEvent. Because event.id is never recorded, a redelivered event re-executes the whole charge path — violating your rule that payment webhook handlers must be idempotent.
handle_webhook() with a guard: ProcessedEvent.objects.get_or_create(stripe_id=event.id), returning early when the event was already processed.
View rule: payments.md
Illustrative example. Findings are advisory by default — a person approves every fix before it lands.
PRGuard doesn’t certify your compliance — it produces the evidence that makes demonstrating your code-governance controls easier. How that evidence maps to a given control is a conversation for you and your auditor.
Supports change-management and secure-development evidence — that code changes are reviewed against defined standards, with a logged, attributable trail of findings and their resolution.
Helps evidence secure code-review activity — including checks for issues like insecure handling of sensitive data, recorded per change with an outcome.
Whatever standards your organisation must uphold — architectural, security, or data-handling — write them as rules and get a consistent, reviewable record that they were enforced.
A note on scope. PRGuard produces evidence to support your compliance and audit programs. It does not itself certify compliance with any standard or regulation, and nothing here is legal advice. Whether and how PRGuard’s records satisfy a specific control is a determination for you and your auditor.
AI usage is part of your subscription, not a bill on the side. Every plan includes a set monthly AI credit allowance, and each audit draws from it — no separate API key to bring, no separate token invoice. And if a busy month needs more, top-up credits are available anytime and roll over.