Transparency reports anyone can verify.
TransparencyKit keeps a tamper-evident record of government requests, abuse notices, subprocessor changes and where your infrastructure sits. From it, it publishes signed reports, including the disclosures the EU Data Act and the DSA require.
go install github.com/transparencykit/transparencykit/cmd/tkit@latest
So Sovereign Cloud SA (fictional), transparency report 2026
- Government and authority requests
- 29
- Requests rejected
- 13
- Accounts specified in requests
- 53
- Disclosures to third-country authorities
- 0
Signature valid, key ed25519:393c7a476c60c098
117 ledger records, open the full report
One ledger, every disclosure
Record each event once. Every publication is derived from the same chain of records, so the numbers in your report, your Data Act page and your DSA filing cannot drift apart.
-
Voluntary, following Ranking Digital Rights P11a
Transparency report
Government and authority requests by country, outcome, data type and customer notification, with third-country requests such as CLOUD Act orders shown on their own. Abuse notices by category and action.
-
Regulation (EU) 2023/2854, Art. 28
Data Act disclosure
The jurisdiction of every zone and the technical, organisational and contractual measures against foreign governmental access, on a stable URL your contracts can reference.
-
Regulation (EU) 2022/2065, Art. 15
DSA transparency data
Orders, notices and own-initiative measures for hosting providers, with exact figures in CSV files that follow the tab structure of the Commission's template.
-
GDPR Art. 28 practice
Subprocessor list and feed
The current list and a dated change history, with an Atom feed customers can subscribe to instead of scraping your website.
How it works
Three commands, run by your legal or trust team. Nothing to host but a bucket.
-
Record
Append each request or change when it happens. Records are validated, hash-chained and stored in an object-locked bucket. Case details stay private.
tkit record add gov_request -f req.json -
Publish
Aggregate a period, render every output and sign a manifest that lists each file's hash. Small counts are shown as ranges; zeros stay exact.
tkit publish --period 2026 -
Verify
Customers, auditors and journalists check the signature and every file with your public key. A rewritten past report fails the check.
tkit verify --pubkey acme.pub --chain \ https://transparency.acme.example
Proof, not prose
Most transparency pages are text a provider can change at any time. Each TransparencyKit publication commits to the one before it, so history can be extended but not rewritten.
previous none
files 14, signed
previous sha256 9a07…
files 14, signed
previous sha256 3fd2…
files 14, signed
Every file is listed in a manifest with its SHA-256 hash and signed with Ed25519. Change one byte and verification fails, naming the file.
Each manifest also commits to the head of your private ledger, so an auditor can prove which records a report was built from.
Built for providers who host in Europe
- One static binary. Written in Go with no third-party dependencies, so the supply chain is short enough to audit.
- Your storage, your keys. State lives in Exoscale SOS or any S3-compatible bucket you control. Nothing is sent to anyone else.
- Immutable by design. Records are append-only and object-locked. Mistakes are amended or retracted, never deleted.
- What you need. Two buckets on any S3-compatible storage: a private ledger bucket created with object lock, and a public one for reports. See the storage requirements.
- Private stays private. Case references and notes are hashed into the ledger but never appear in a published file.
- Open source. Apache-2.0. Read the specification, run the tests, change what you need.
- Not legal advice. Have counsel review your categorisations and the DSA mapping before you file.