A PDF is not evidence until someone can verify it

Ask an auditor what the weakest part of most device-compliance evidence is and you will get the same answer: it is a PDF someone exported, and there is no way to tell whether it was edited afterwards. The report has a logo and a date. It may have been accurate when it was generated. It may also have been opened in a PDF editor and had one row changed from “fail” to “pass.” Nothing in the file tells you which.

That is a strange standard for an industry built on controls. We think a compliance document should carry proof of its own integrity, so every CybrOak evidence pack does.

What happens when a pack is generated

1. The pack is rendered as a PDF from your fleet's posture at that moment: devices assessed, per-control pass/fail for each framework, findings, and the remediation history in the window.
2. We compute the SHA-256 hash of the finished file. SHA-256 is a one-way fingerprint: change a single byte of the PDF and the fingerprint changes completely.
3. We register the pack under a unique Evidence ID together with that fingerprint, the organisation, the generation time, who generated it, the device count and the framework scores at the time.
4. The Evidence ID and a verification URL are printed inside the PDF itself.

What the auditor does

They open cybroak.com/verify/<id>. No login, no account. The page shows whether the ID is genuine, which organisation it belongs to, when it was generated, how many devices it covered and what the framework coverage was. It also shows the registered fingerprint. To confirm the file in their hands is the file we issued, they run one command on it:

shasum -a 256 evidence-pack.pdf
certutil -hashfile evidence-pack.pdf SHA256

If the output matches the fingerprint on the verification page, the document is unaltered. If it does not, someone changed it. There is no third state. Try it on the example pack.

Why this matters more for MSPs

An MSP handing a client a monthly compliance report is asking that client, and the client's auditor, to trust a document produced by the party being evaluated. A registered, verifiable pack changes that relationship: the client can independently confirm the report is exactly what the platform produced, with nothing added or removed. It is the difference between “trust us” and “check for yourself.”

What this does not prove

We want to be precise about the claim. Verification proves the document is the one we generated and has not been modified since. It does not, by itself, prove that the underlying Intune data was correct, or that the controls stayed in place after the report was produced. For the second problem we take daily posture snapshots so you can show a control held across a whole period rather than on one afternoon. For the first, the data comes from Microsoft Graph with read-only consent, and the security page describes exactly what we read and how we store it.

Evidence should be checkable by the people who have to rely on it. That is the whole idea.