Every key and certificate, what it opens, and which services hold it.
What the auditor asked for: every certificate and key behind a critical function, and how each one gets replaced. The model writes it from what it finds.
For each key: what it opens, which services hold it, whether you marked it critical, when it was last replaced, who approved that, and its replacement plan.
What the auditor gets- Card authorizationthe card processor key and the processor's client certificate
- Disputesthe card processor key
- Nightly settlement jobthe processor key and the bank's file-drop key
- Deploy pipelinethe card processor key, for the release smoke test
- API gatewaythe TLS certificate for the public payments API
Retention is set by you, not by a plan tier: up to ten years on every plan.
The auditor gets the register as a signed PDF and CSV, and for each rotation who prepared it (the model), who approved and signed, when it ran and when the old key went off.
The register as the auditor reads it, and the record of one rotation from 10:31 to 11:09.
Every read, approval and step lands in an append-only, hash-chained log, as DORA's logging rules ask: change any entry and the broken chain shows it.
No SOC 2 or ISO 27001 report yet: Bitting is five months old, and its first external penetration test is booked for Q1 2027.
EU onlykeys, logs and backups
Register, logs, backups and key ciphertext stay in Stockholm. Key values never leave your network.
Subprocessors are EU-only. What we hold of a key is ciphertext under a wrapping key that stays in your network, so we cannot open it.
Bitting UAB is registered in Vilnius and computes in Stockholm. The model reads masked text there; key values and raw text stay with you.
A credential service that supports a critical function enters your register of information, and the management body approving your third-party policy will ask where it sits.
