Sharing a Veracly report with your developer, lawyer, or regulator

A Veracly report has three primary audiences. Each one reads it differently. The same PDF that lands in front of a developer as a backlog will land in front of a lawyer as a risk register and in front of a regulator as evidence. Here is how to hand it over to each.

One thing to settle before any of it. The report carries two identifiers: the Verification ID, printed in the integrity block on the disclaimer page, and the verify URL built from it. These are not two independent lifetimes. The URL is the ID in a path, they resolve against the same record, and neither can outlive the other, so quoting the ID is not a hedge against a dead link. What changes over time is what that record can still tell you. A paid-report anchor carries no automatic expiry and the retention sweep never touches it; the published policy sets no horizon at all, because the anchor is kept independently of the parent scan record and outlives it when that record is dropped at 12 months. A free-scan anchor is retired 60 days after signing: the signature and the stored SHA-256 are erased, and the second copy of that digest, held with the PDF record, is deleted on the same window. After retirement the URL still answers, but only to confirm that the report existed and when it was signed. The PDF prints a more conservative promise than either, that the verify URL is valid for 30 days from issue. Every cover note below is written on that basis: open the link yourself on the day you send it, and tell the recipient what they will find there later. A dead “independently verifiable” link in front of a regulator is worse than no link at all.

The report’s sections are not numbered, so the names below are what you will actually see as headings in the PDF. They appear in this order.

Sharing with your developer

What they need: Top Priorities and the Remediation Appendix. Everything else is context they can skim.

How to share: Forward the PDF, then create one ticket per Top Priority row in your tracker. Each ticket should carry: the violation title, the severity, the specific element selector from the remediation card, and the copy-paste HTML/CSS/JS fix. Do not file a single ticket saying “fix all accessibility issues”, that ticket will sit forever.

What to put in the cover note: “Top ten priorities are linked below as tickets. The PDF appendix has the fix snippet for each. Please take the criticals first; we have a re-scan scheduled for [date].”

Sharing with your lawyer or compliance team

What they need: The Per-Jurisdiction Scorecard, the Per-Jurisdiction Detail pages, and the Legal Disclaimer. They will care less about the specific HTML fix and more about the citations panel on each detail page.

How to share: Forward the PDF with the Verification ID. Most legal reviewers will independently confirm the signature before they cite the report, so handing them what they need upfront is faster than answering “is this authentic?” later. Include the verify URL as well if you have just opened it and it resolves. If this is a free-scan report more than 60 days old, say so in the note rather than letting them discover a retired record on their own.

What to put in the cover note: “Multi-jurisdiction scan dated [scanDate]. The legal-floor score on the AODA card uses Ontario’s 2.0-AA statutory bar; the cross-jurisdiction parity score uses 2.1 AA. Verification ID [id], printed in the integrity block on the final page. The signed record can be confirmed at veracly.app/verify/<uuid>, which also accepts a ?sha256= parameter so you can reconcile the file you are holding against the signed record yourself.”

Sharing with a regulator

What they need: The Executive Summary, every Per-Jurisdiction Detail page, the Methodology section, and the Legal Disclaimer. Regulators care about methodology and rigor; they will scrutinize the “what we did not evaluate” disclosure as much as the findings.

How to share: The PDF only. Do not send the dashboard link; regulators expect a fixed-snapshot document they can file. This is the one audience where the link-freshness rule is not optional: a regulator files your cover note and may open the link months later. There is no second, more durable route waiting behind the link, so do not promise one. The durable thing you control is the file itself: attach the PDF, record its SHA-256 in the cover note, and tell the regulator exactly what the endpoint will and will not still confirm by the time they read it.

What to put in the cover note: Be brief and specific. “Per your request of [date] regarding [reference number], please find attached our most recent multi-jurisdiction compliance scan for [domain], dated [scanDate]. The document is cryptographically signed; its Verification ID is [id], printed in the integrity block on the final page. The SHA-256 of the attached file is [digest]. Authenticity can be confirmed without contacting us at veracly.app/verify/[id]?sha256=[digest], which returns the signed record and checks it against the digest above. Veracly’s retention policy is published at veracly.app/.well-known/veracly-retention.json. If the record has been retired under that policy before you open the link, the endpoint will still confirm that this report was issued and on what date, but the signature and the fingerprint are erased at retirement and cannot be reissued by us or by anyone else, which is why the digest is stated here. The report was generated by an independent automated audit tool against WCAG 2.1 AA, GDPR, ePrivacy, EAA, ADA, UK Equality Act, and AODA. Methodology and scope limitations are documented in the methodology section of the attached document. We are at your disposal for any follow-up.”

That is longer than the version we used to publish here, which pasted a bare verify URL and left it at that. It is also longer than the version that replaced it, which told the regulator to email support for a fingerprint reconciliation after the record retired. That was worse than a dead link, because it was a promise we cannot keep: retirement erases the fingerprint from the anchor, and the same sweep deletes the only other copy of it. Proof that the report existed survives retirement. Proof that the bytes in front of you are the bytes we signed does not, unless someone wrote the digest down while it was still available. So write it down, in the cover note, on the day you send.

Sharing with a customer or B2B prospect

What they need: The cover page and Executive Summary. The full detail is available if asked for, but most enterprise procurement reviewers will file the report against a checklist after reading the cover.

How to share: Send the PDF as a transparency signal alongside your DPA or security questionnaire response. Frame it as proof that you monitor, not as a score to debate.

What to put in the cover note: “Attached is our current compliance scan, dated [scanDate]. We re-scan on a [monthly / weekly / daily] schedule and a material score drop triggers an internal review. The PDF is signed; the Verification ID and verification instructions are in the integrity block on the final page.” Say the cadence you actually run, it is set per site and Starter plans are monthly, not weekly.

Publishing the report on your own site

Some customers publish their Veracly reports on a public /accessibility or /trust page as a transparency signal. This is an unusually strong move for an SMB and rewards well, it is concrete evidence of audit cadence, the signature makes the claim falsifiable, and the page itself becomes a trust signal that closes B2B deals.

If you publish, link directly to the PDF. Do not extract screenshots, the value is the falsifiable signed document, not a screenshot anyone could fake.

Publishing a verify URL needs one extra habit, because a trust page is exactly the place a stale link does the most damage. Either replace the link each time you post a fresher report, or publish the Verification ID with a line saying how to check it. If you leave a link up, put a diary note to open it yourself every month, and re-publish rather than let it rot. This is a rule we hold ourselves to: we do not put verify URLs in our own outbound material, for exactly this reason.

What never to do

• Do not edit the PDF before sharing. Any byte change invalidates the signature, and the recipient’s verification will fail.
• Do not strip the disclaimer page. The integrity block lives there; without it the report cannot be verified.
• Do not re-export the PDF through a different viewer (some viewers re-encode the file on save). If you need a different format, generate it from the original.
• Do not redact findings before forwarding. If a regulator later requests the original and the redacted version was shared with the same number, that discrepancy is itself reportable.

See also: How to verify a Veracly report is authentic · Reading your first Veracly report