Which plans include Assurance?

Pro and above, and during a trial. Pro includes one evidence pack a month. Pro Team and Enterprise have no limit.

Any member of the organisation can read Coverage, Readiness, Exceptions, the AI register, Packs, sign-offs and Activity. Owners and admins see Settings and Policies and change them, download the Coverage CSV, correct a change's origin and mark a control not applicable. Owners, admins and any approver they name decide exceptions; owners, admins and project managers ask for packs and download them. Only an owner signs a quarter off.

Is our source code in a pack?

No. A pack carries names, sizes, fingerprints and links. A sampled finding gives its rule, its file and its line, never the code.

How does an assessor know a pack is the one we were sent?

The manifest lists every file with its SHA-256, and a root hash over the list. The verifier works both out again and compares them. Give your assessor the root hash from the email PRGuard sent you, and the verifier checks the pack against that too. It runs offline and sends nothing to us.

How long is a pack kept?

The file is kept for a year. After that the file is removed, and its entry stays with the root hash, so a copy you kept can still be checked.

Does Assurance change how audits run?

No. Audits run as they did, and Assurance reads their records. Three policies change what PRGuard does, and one is on from the start: an error needs an exception to be closed as won’t fix. The other two, skip markers switched off and a minimum score to merge, are yours to switch on.

Which frameworks does Readiness know?

Controls for the Cyber Resilience Act and the EU AI Act. You choose the ones you are assessed against.

Can we ask questions of it?

Yes. Insights answers questions about the ledger, the exceptions and the AI register in plain words, and each claim links to the record behind it.

PRGuard Assurance — The Guide

The Coverage tab: the share of changes audited in a quarter, and the list of gaps with their reasons.

01

Every Change That Reached Main, or a Release Branch.

The coverage ledger lists each change that landed on a default branch, or on a release branch you name, in the period and how it was governed. A gap is listed with its reason, not hidden.

In this part

The share of changes that were audited, and the groups the rest fall into: merged while failing, skipped with a marker, not audited and why.
One gap opened up: who merged it, who approved it, and what PRGuard recorded at the time.
Direct pushes, and changes from before PRGuard was connected, each marked as what it is.

Do it yourself

Open Governance, then Assurance, then Coverage.
Choose the period. A quarter is the usual one.
Read the gaps. Open any change to see its record.
Download the list as a CSV. The evidence pack carries the same file.

What it does not claim

Audited means PRGuard checked the change against the rules you enabled. It does not mean the change has no defects.

The Exceptions tab: each exception with its finding, who asked, who approved and its end date.

02

Not Fixing It Yet Needs a Reason and a Date.

An error-level finding is closed as won’t fix only under an approved exception. The approver is never the person who asked, and when the exception ends the finding reopens.

In this part

A won’t fix on an error, refused until an exception covers it.
The request: why, what limits the risk meanwhile, and until when. Then the approval, by someone else.
The register: waiting, in force, expired. And a finding PRGuard reopened when its exception ran out.

Do it yourself

Open the finding in its audit and choose Request an exception.
Give the justification, the compensating control and the end date.
An owner, an admin or an approver you have named decides. Nobody approves their own request.
Close the finding as won’t fix. The closing names the exception.
Revoke an exception from the register at any time. Its finding reopens at once.

What it does not claim

An exception records a decision and who made it. It does not say the decision was right.

The AI register tab: a quarter’s changes grouped by who or what wrote them.

03

Who or What Wrote Each Change.

Each change is classified by origin: a person, a person with an assistant, an AI agent or a bot. The register shows how each group fared against your rules, and who approved and merged.

In this part

The four origins, and the tools named in each.
How often each group’s changes had an error at their first audit, side by side.
One change opened up: the signals behind its origin, and how to correct one that is wrong.

Do it yourself

Open Assurance, then AI register, and choose the period.
Open a group to see its changes.
List your automation’s GitHub logins under Settings, so a bot is counted as a bot.
Correct a change’s origin from its record where you know better. The correction is journalled.

What it does not claim

Origin is classified from observable signals: the author, the branch and commit trailers. It is a classification, not ground truth.

The Readiness tab: a framework’s controls marked covered, partly covered or gap.

04

Where You Have Evidence, and Where You Have None.

An assessor asks about controls, not pull requests. Map a rule file to the controls it supports and Readiness shows, framework by framework, which controls have a rule that audits ran with.

In this part

A rule file mapped to the controls it supports.
One control’s page: the rule versions that carried it, the audits that ran, the findings and what became of them.
A framework’s list: covered, partly covered, gap, and what your organisation marked not applicable, with the reason. Then an owner signing the quarter off.

Do it yourself

In Context Studio, open a rule file and choose the controls it supports.
Open Assurance, then Readiness, and choose a framework and a period.
Open a control to see the evidence behind it.
Mark a control not applicable where it is outside your scope. A reason is required.
When the quarter is over, an owner reads its summary and signs it off.

What it does not claim

Covered means a rule file is mapped and audits ran with it. Whether a control is met is the assessor’s judgement.

The Packs tab: a generated evidence pack with its period, root hash and download.

05

The File You Hand Over.

Choose a quarter that is over and the frameworks you are assessed against. You get one ZIP with a manifest of hashes, and your assessor checks it without talking to us.

In this part

A pack being generated for a quarter, and the email that says it is ready.
What is inside: every change in the period, sampled audits for each control, your rules at the versions that ran, the exceptions, the policies and the journal.
The assessor’s side: the verifier passing the pack. Then one byte changed, and the same check failing.

Do it yourself

Open Assurance, then Packs, and choose Generate a pack.
Choose the quarter, the repositories and the frameworks.
Download the ZIP when the email arrives. The email carries the pack’s root hash.
Send the ZIP to your assessor, and the root hash by another route.
They run prguard verify pack.zip, or python3 verify.py from inside the pack.
For a signed pack they add --key with the key the email names, which PRGuard also publishes, so the check shows PRGuard made the pack.

What it does not claim

A pack is evidence for controls. It does not say one is satisfied. Your source code is never in it: names, sizes, fingerprints and links.

The Activity tab: the journal of changes made in Assurance, with who made each.

06

Everything That Was Changed, and by Whom.

The Activity tab is the journal of Assurance. It is append-only: an entry is added and never rewritten, and each one carries a hash of its own contents.

In this part

Settings, policies, exceptions, sign-offs and packs, each entry with who and when.
The journal filtered to one kind of event, or to one person.
An entry checked against its SHA-256, and the same entries in a pack, one to a line.

Do it yourself

Open Assurance, then Activity.
Filter by event, by what it was about, or by who did it.
Open an entry to see its record and its hash.
Read the line above the journal: whether every entry still links to the one written before it.

What it does not claim

An entry’s hash shows the entry is as it was written, and each entry is linked to the one before it, so an entry removed from the middle shows as a gap. Entries removed from the end show against the record of where the journal ended, kept beside it and in a daily checkpoint outside the database, and against any pack made before. None of it shows an entry was right, or that nothing was left unwritten.

The Policies tab: the organisation’s policies and which are switched on.

07

The Rules in Force, and the Day They Began.

Three policies change what PRGuard does for your organisation. Every change that merges is stamped with the policies in force that day, and the stamp is never rewritten.

In this part

Skip markers switched off: a marker in a title is ignored, the change is audited, and the journal says so.
A minimum score to merge: an audit under it fails its check, with the policy named.
A change from an earlier month, showing that month’s policies and whether PRGuard’s check was required on its branch.

Do it yourself

Open Assurance, then Policies. Owners and admins see this tab.
Switch a policy on or off. The change is journalled with your name.
The next change that merges is stamped with it. Earlier changes keep the policies of their day.

What it does not claim

PRGuard reads your branch rules on GitHub. It does not change them. Where it could not read them, the record says not known.

The Assurance settings tab: frameworks, reporting timezone, approvers and repository scope.

08

Switch It On. The History Is Read for You.

An owner or an admin switches Assurance on from the organisation page. PRGuard then reads the last 90 days from GitHub, so the first page you open is not empty.

In this part

The switch, the frameworks you report on, and the clock your quarters run on.
Which repositories each framework covers, and one left out, with the reason recorded.
History arriving from GitHub, with the changes from before PRGuard was connected marked as such.

Do it yourself

On the organisation page, switch Assurance on.
Under Assurance, then Settings, choose your frameworks and your reporting timezone.
Say which repositories are in scope for each framework. Give a reason for any you leave out.
Name your bot accounts, and anyone besides owners and admins who may approve an exception.
Map your rule files to controls in Context Studio.

What it does not claim

A change read back from before PRGuard was connected is listed and marked. It was not audited, and the ledger does not say it was.

Every Merge,
Accounted For.

One Quarter. One File.

Eight Parts. One Tab Each.

Every Change That Reached Main, or a Release Branch.

Do it yourself

What it does not claim

Not Fixing It Yet Needs a Reason and a Date.

Do it yourself

What it does not claim

Who or What Wrote Each Change.

Do it yourself

What it does not claim

Where You Have Evidence, and Where You Have None.

Do it yourself

What it does not claim

The File You Hand Over.

Do it yourself

What it does not claim

Everything That Was Changed, and by Whom.

Do it yourself

What it does not claim

The Rules in Force, and the Day They Began.

Do it yourself

What it does not claim

Switch It On. The History Is Read for You.

Do it yourself

What it does not claim

Evidence, Not a Certificate.

Good to Know.

Which plans include Assurance?

Who can see it?

Is our source code in a pack?

How does an assessor know a pack is the one we were sent?

How long is a pack kept?

Does Assurance change how audits run?

Which frameworks does Readiness know?

Can we ask questions of it?

Have the Answer Before You Are Asked.

We value your privacy

Every Merge,Accounted For.

One Quarter. One File.

Eight Parts. One Tab Each.

Every Change That Reached Main, or a Release Branch.

Do it yourself

What it does not claim

Not Fixing It Yet Needs a Reason and a Date.

Do it yourself

What it does not claim

Who or What Wrote Each Change.

Do it yourself

What it does not claim

Where You Have Evidence, and Where You Have None.

Do it yourself

What it does not claim

The File You Hand Over.

Do it yourself

What it does not claim

Everything That Was Changed, and by Whom.

Do it yourself

What it does not claim

The Rules in Force, and the Day They Began.

Do it yourself

What it does not claim

Switch It On. The History Is Read for You.

Do it yourself

What it does not claim

Evidence, Not a Certificate.

Good to Know.

Which plans include Assurance?

Who can see it?

Is our source code in a pack?

How does an assessor know a pack is the one we were sent?

How long is a pack kept?

Does Assurance change how audits run?

Which frameworks does Readiness know?

Can we ask questions of it?

Have the Answer Before You Are Asked.

Every Merge,
Accounted For.