{"id":"practice-statement-v1","title":"Preservation service practice statement","version":1,"status":"in_force","in_force_from":"2026-10-11","url":"https://trustbeat.eu/preservation/practice-statement","markdown":"# Preservation service practice statement, version 1\n\nWritten to ETSI TS 119 511 V1.1.1 §6.1 (OVR-6.1-01..09) and ETSI EN 319 401 §6.1.\n\n| | |\n|---|---|\n| **Provider** | Trustbeat s.r.o., Czech Republic (\"TrustBeat\"), `https://trustbeat.eu`, `hello@trustbeat.eu` |\n| **Service** | TrustBeat Document Anchoring, operated as a preservation service with storage (WST) for the preservation of general data (PGD) |\n| **Version** | 1, in force from **2026-10-11** |\n| **Language** | English. A translation, if any, is informative; the English text takes precedence. |\n\n## 1. Policies and profiles (OVR-6.1-02, 6.1-03)\n\n**Preservation service policy.** TrustBeat operates to the main policy of ETSI TS 119 511, OID\n`0.4.0.19511.1.1` (*\"policy for preservation services\"*, §4.3.2), without the additional requirements\nfor qualified preservation services (Annex A). A qualified status is not available for this goal:\nTS 119 511 Annex A note 2 reserves it for the preservation of qualified electronic signatures and\nseals. TrustBeat has not been assessed against this policy by a conformity assessment body; until it\nis, TrustBeat describes the service as *designed to* ETSI TS 119 511, not as conforming to it.\n\n**eIDAS.** The time-stamps in the evidence are qualified electronic time-stamps (Article 41) issued by\nqualified trust service providers on an EU Trusted List under Regulation (EU) No 910/2014 (eIDAS), as\namended by Regulation (EU) 2024/1183. The preservation service itself is not a qualified trust service\nunder that Regulation: it is neither a qualified preservation service, which the Regulation provides\nonly for qualified electronic signatures and seals (Articles 34 and 40), nor a qualified electronic\narchiving service.\n\n**Known deviation.** TrustBeat does not meet PRP-8.1-11 and PRP-8.1-12 (deletion of stored\npreservation objects before the end of the preservation period); see §6.\n\n**Supported preservation profiles.**\n\n| Profile | Goal | Storage model | Status | Document |\n|---|---|---|---|---|\n| `https://trustbeat.eu/preservation/profile/pgd-wst-v1` | PGD | WST | Active from 2026-10-11 | [profile-pgd-wst-v1.md](profile-pgd-wst-v1.md) |\n\nThe current and all earlier profiles are listed at `GET https://api.trustbeat.eu/v1/preservation/profiles`\nand published at `https://trustbeat.eu/preservation`, each profile at its identifier. The profile references the preservation evidence policy\n([evidence-policy-v1.md](evidence-policy-v1.md)), which states how evidence is created, renewed and\nvalidated in each period.\n\n**Scope.** Only *document anchors* (`POST /v1/anchor`, `POST /v1/anchor/batch`) are preservation\nobjects. Tamper-Evident Logs, AI decisions and Audit Trail use the same anchoring infrastructure but\nare not preservation objects under this statement. A document anchor is a preservation object when it\nwas submitted from **2026-09-14 00:00 UTC** onwards and its batch has an RFC 4998 evidence record;\nthat is when TrustBeat began creating such records. An anchor carries its profile and the end of its\npreservation period from the moment it is assigned, and never changes profile\n(`GET /v1/anchor/{id}/status`, field `preservation`). Earlier anchors keep their existing proofs but\nare not covered.\n\n## 2. How the preservation goal is achieved (OVR-6.1-04)\n\nThe goal is PGD: proof that a submitted hash value existed at a given time and has not changed since,\nkept verifiable for the preservation period.\n\n1. **Submission.** The subscriber computes the SHA-256 hash of its data and submits only the hash.\n   TrustBeat never receives, stores or sees the data. Anything other than a 64-character hexadecimal\n   SHA-256 value is rejected. The response carries the preservation object's identifier.\n2. **Evidence.** Hashes are collected in batches at fixed 10-minute boundaries. Each batch's hashes\n   form an RFC 4998 hash tree whose root is time-stamped by an EU qualified time-stamping authority\n   (§4). Validation data for the time-stamp (certificate path, OCSP response or CRL) is collected and\n   embedded in a copy of the token, leaving the issued token unchanged. Each hash then has an RFC 4998\n   evidence record. Details: evidence policy §1.\n3. **Preservation period.** 30 years from submission, on every plan including the free plan, unless a\n   subscriber agreement states otherwise. Stored per object as `preserve_until`.\n4. **Renewal.** Before the last time-stamp in a record stops being verifiable (90 days before its\n   signing certificate expires, or earlier if TS 119 312 assesses its algorithms as weakening),\n   TrustBeat adds an RFC 4998 time-stamp renewal (§5.2). One renewal time-stamp covers many batches.\n   Evidence policy §4.\n5. **Limits of a hash-only service (OVR-6.2-08).** The evidence proves the existence of the *hash*.\n   It proves the existence of the data only while SHA-256 stays collision-resistant, and only if the\n   subscriber kept the data and computed the hash correctly. TrustBeat cannot re-hash data it never\n   received, so it offers no hash-tree renewal (RFC 4998 §5.3) in profile `pgd-wst-v1`. If SHA-256 is\n   assessed as weakening, TrustBeat will notify subscribers by email and state in a new evidence\n   policy version whether and how new hash values can be submitted.\n6. **Validation.** Evidence records are standard RFC 4998 and can be validated without TrustBeat\n   software (for example with EU DSS); trust anchors are the EU Trusted Lists. TrustBeat keeps signed\n   copies of every version of these lists it loads, so a TSA's qualified status on a past date can\n   still be shown. Evidence policy §5.\n\n**Protocol.** TrustBeat offers its own REST API (`https://api.trustbeat.eu/docs`), not the\nTS 119 512 protocol (PRP-8.1-02 is a recommendation). The profile maps each operation to its\nTS 119 512 equivalent.\n\n## 3. Availability of submitted data objects and evidence (OVR-6.1-05)\n\nThe submitted data object is the hash value. TrustBeat stores it, the batch's hash tree, the\ntime-stamp tokens as issued, the copies with validation data, the renewals and the Trusted List\nsnapshots, for the whole preservation period.\n\n- **Retrieval.** At any time during the preservation period:\n  - the subscriber, authenticated, retrieves the evidence record, proof and status of its own objects\n    and the export-import package (§5);\n  - anyone holding an object's identifier retrieves its evidence record and proof from the public\n    endpoints (`GET /v1/public/proof/{id}/evidence-record.ers`), so a relying party can verify\n    without an account. The identifier is the only key; the hash reveals nothing about the data.\n- **Storage.** One PostgreSQL database on a dedicated server at Hetzner Online GmbH, Germany. Evidence\n  is built on request from the stored tree and tokens; the stored tokens are never modified.\n- **Backups.** Daily, encrypted before they leave the server, stored in a second EU country\n  (Scaleway, France) in storage that cannot be overwritten or deleted from production; integrity and\n  restore are tested: integrity weekly, a full restore every three months. **Recovery point: up to 24 hours.** If the database were lost,\n  submissions accepted since the last daily backup, and their evidence, could be lost; the subscriber\n  would hold identifiers that no longer resolve and would need to submit those hashes again (with a\n  later time). Reducing this to minutes is planned.\n- **Copies held by the subscriber.** The subscriber can download its evidence records and\n  export-import packages at any time and is advised to keep them with the data. An evidence record\n  remains verifiable without TrustBeat until its last time-stamp expires; renewed records must be\n  downloaded again after a renewal.\n- **Availability target.** No contractual availability level for the free, Developer and Business\n  plans; an Enterprise subscriber agreement may set one. A failure of the time-stamping authority\n  delays evidence but never loses an accepted submission: hashes stay pending until a batch is\n  time-stamped, by the fallback TSA if needed.\n\n## 4. External organisations (OVR-6.1-06, EN 319 401 §6.1)\n\n| Organisation | Role in the service | Obligations relied on | Applicable policy / practice |\n|---|---|---|---|\n| **SK ID Solutions AS**, Estonia | Primary time-stamping authority (EU qualified) since 2026-07-01 | Issue RFC 3161 time-stamps under its qualified TSA policy; keep certificate status (OCSP) available | Its Time-Stamping Authority Practice Statement (ETSI EN 319 421), version 9.0 in force from 2026-02-20, and its terms and conditions for the time-stamping service: `https://www.skidsolutions.eu/resources/time-stamping-principles-and-conditions-for-use/` |\n| **EuroCert Sp. z o.o.**, Poland | Fallback time-stamping authority (EU qualified) | As above; certificate status via CRL | Its certification policy and practice statement for qualified trust services (0-PT-025, version 5.1 in force from 2025-10-20, Polish): `https://eurocert.pl/repozytorium/Polit_certyf_i_kodeks_post_certyf/Kwalifikowane/aktualne/` |\n| **European Commission** and **national Trusted List operators** | Publish the EU List of Trusted Lists and national Trusted Lists | Keep the TSAs' qualified status published and signed | ETSI TS 119 612 |\n| **Hetzner Online GmbH**, Germany | Hosting of the application and database servers | Physical security, power, network, hardware | Its terms, data processing agreement and ISO/IEC 27001:2022 certification of the Nuremberg and Falkenstein data centres |\n| **Scaleway SAS**, France | Offsite encrypted database backups; storage of evidence packages | Durable storage, object lock | Its terms and data processing agreement |\n| **Seznam.cz, a.s.**, Czech Republic | Delivery of notifications (renewal problems, end of period, hash algorithm warnings) | Deliver email | Its terms |\n\nThe TSAs and Trusted List operators are relied on only through what they publish and sign; their\nstatements can be checked independently of TrustBeat. No external organisation has access to\npreservation objects, except as the hosting and backup providers of encrypted or stored data.\n\n## 5. Export-import package (OVR-6.1-07, 6.1-08)\n\n**How to request one.** The subscriber requests a package itself, at any time during the\npreservation period, without contacting TrustBeat:\n`GET https://api.trustbeat.eu/v1/preservation/export?from=<time>&to=<time>`, authenticated with the\naccount's API key or portal session, or with the *Export package* button in the portal\n(`https://trustbeat.eu/preservation-export`), which calls the same endpoint. One package covers the\naccount's preservation objects submitted in a window of at most 31 days; longer periods are exported as\nconsecutive windows. A subscriber that cannot use either can ask `hello@trustbeat.eu` from the\naccount's email address.\n\n**How it is produced.** Format `trustbeat-export-import-v1`:\n\n- a ZIP, **not encrypted** (it contains hashes and public evidence only; it travels over TLS);\n- `manifest.json`: selection, profiles, and per object the hash, submission and anchoring times,\n  `client_ref`, profile and end of preservation period, with the SHA-256 and size of every other file;\n- `objects/<id>.ers`: the RFC 4998 evidence record with embedded validation data and all renewals,\n  byte-identical to the public endpoint;\n- `trusted-lists/`: the signed EU List of Trusted Lists and each relevant national list in force at\n  each evidence time-stamp;\n- the same inputs give the same bytes.\n\nPackages are released only to the authenticated account, for its own objects. Every release is\nrecorded **before** it is sent (time, selection, counts, SHA-256 and size of the package); without a\nrecord no package is sent, and records are never changed or deleted (OVR-7.16-04). TrustBeat does not\ntransfer packages to another preservation service; the subscriber passes them on.\n\n## 6. Deletion and the end of the preservation period (OVR-6.1-09)\n\n**No deletion during the preservation period.** Neither the subscriber nor TrustBeat deletes a\npreservation object before its preservation period ends; TrustBeat does not delete on request either.\nThis deviates from TS 119 511 PRP-8.1-11 (*\"a preservation service with storage shall allow to delete\nstored POs\"*) and PRP-8.1-12. The reason: each evidence record is built from **all** the hashes of its\nbatch, which belong to many subscribers. Removing one hash would make the evidence records of every\nother object in that batch unverifiable or would require altering stored evidence, which the service\nnever does. The hash itself reveals nothing about the data, and the subscriber can make the evidence\nuseless to itself simply by discarding the data.\n\n**Closing an account** does not end the preservation period. The account's objects stay preserved and\nrenewed until their periods end, and remain retrievable by identifier from the public endpoints. After\nclosure there is no authenticated access and no notifications; the subscriber should download an\nexport-import package before closing.\n\n**At the end of the preservation period** of an object:\n\n1. TrustBeat stops renewing its evidence.\n2. TrustBeat notifies the subscriber by email at the account's address and makes the export-import\n   package of the object available.\n3. **30 days later** TrustBeat deletes the object's link to the account and its metadata\n   (`client_ref`, description), whether or not the package was downloaded, and stops serving its\n   evidence. The hash, hash tree and time-stamps of its batch are shared with the other objects of\n   the batch and stay until the last of them has reached this step; then they are deleted too. Every\n   deletion is logged.\n\nThe first preservation periods end in 2056.\n\n## 7. Termination of the service (EN 319 401 §6.1, OVR-7.12)\n\nIf TrustBeat stops the service, it follows its termination plan:\n\n- **at least 6 months' notice** by email to every account and on `trustbeat.eu` (as fast as possible\n  if the termination is unplanned);\n- preservation and renewal continue until the stop date, and exports stay open;\n- shortly before the stop date, a **last time-stamp renewal** of all evidence, with the qualified TSA\n  whose certificate expires latest, and a **final export-import package for every account**;\n- the public evidence and verification endpoints stay online for **12 months** after the stop date;\n- no successor is promised; a transfer to another preservation service happens only with notice to\n  each subscriber, who may refuse;\n- arrangements ensure the plan can be carried out, and its costs covered, even if the managing\n  director cannot act or the company is insolvent.\n\nAfter TrustBeat stops, a subscriber keeps its evidence verifiable beyond the last time-stamp by having\nthe evidence record time-stamped again elsewhere.\n\n## 8. Management of this statement (EN 319 401 §6.1)\n\n- **Approval.** This statement, the profiles and the evidence policy are approved by TrustBeat's\n  managing director (*jednatel*), who has final authority over the practices of the service and\n  ensures they are implemented.\n- **Review.** At least once a year, and whenever a profile, the evidence policy, an external\n  organisation in §4 or the service's infrastructure changes materially.\n- **Changes.** Registered subscribers are notified by email at least 14 days before a material change\n  takes effect, as in the terms of service. The revised statement is published once approved. Every\n  version stays available with the dates it was in force.\n- **Publication.** At `https://trustbeat.eu/preservation/practice-statement`, alongside the profiles\n  and the evidence policy (`https://trustbeat.eu/preservation`) and the terms of service\n  (`https://trustbeat.eu/terms`).\n","html":"<h1>Preservation service practice statement, version 1</h1>\n<p>Written to ETSI TS 119 511 V1.1.1 §6.1 (OVR-6.1-01..09) and ETSI EN 319 401 §6.1.</p>\n<table>\n<thead>\n<tr>\n<th></th>\n<th></th>\n</tr>\n</thead>\n<tbody>\n<tr>\n<td><strong>Provider</strong></td>\n<td>Trustbeat s.r.o., Czech Republic (&quot;TrustBeat&quot;), <code>https://trustbeat.eu</code>, <code>hello@trustbeat.eu</code></td>\n</tr>\n<tr>\n<td><strong>Service</strong></td>\n<td>TrustBeat Document Anchoring, operated as a preservation service with storage (WST) for the preservation of general data (PGD)</td>\n</tr>\n<tr>\n<td><strong>Version</strong></td>\n<td>1, in force from <strong>2026-10-11</strong></td>\n</tr>\n<tr>\n<td><strong>Language</strong></td>\n<td>English. A translation, if any, is informative; the English text takes precedence.</td>\n</tr>\n</tbody>\n</table>\n<h2>1. Policies and profiles (OVR-6.1-02, 6.1-03)</h2>\n<p><strong>Preservation service policy.</strong> TrustBeat operates to the main policy of ETSI TS 119 511, OID\n<code>0.4.0.19511.1.1</code> (<em>&quot;policy for preservation services&quot;</em>, §4.3.2), without the additional requirements\nfor qualified preservation services (Annex A). A qualified status is not available for this goal:\nTS 119 511 Annex A note 2 reserves it for the preservation of qualified electronic signatures and\nseals. TrustBeat has not been assessed against this policy by a conformity assessment body; until it\nis, TrustBeat describes the service as <em>designed to</em> ETSI TS 119 511, not as conforming to it.</p>\n<p><strong>eIDAS.</strong> The time-stamps in the evidence are qualified electronic time-stamps (Article 41) issued by\nqualified trust service providers on an EU Trusted List under Regulation (EU) No 910/2014 (eIDAS), as\namended by Regulation (EU) 2024/1183. The preservation service itself is not a qualified trust service\nunder that Regulation: it is neither a qualified preservation service, which the Regulation provides\nonly for qualified electronic signatures and seals (Articles 34 and 40), nor a qualified electronic\narchiving service.</p>\n<p><strong>Known deviation.</strong> TrustBeat does not meet PRP-8.1-11 and PRP-8.1-12 (deletion of stored\npreservation objects before the end of the preservation period); see §6.</p>\n<p><strong>Supported preservation profiles.</strong></p>\n<table>\n<thead>\n<tr>\n<th>Profile</th>\n<th>Goal</th>\n<th>Storage model</th>\n<th>Status</th>\n<th>Document</th>\n</tr>\n</thead>\n<tbody>\n<tr>\n<td><code>https://trustbeat.eu/preservation/profile/pgd-wst-v1</code></td>\n<td>PGD</td>\n<td>WST</td>\n<td>Active from 2026-10-11</td>\n<td><a href=\"/preservation/profile/pgd-wst-v1\">profile-pgd-wst-v1.md</a></td>\n</tr>\n</tbody>\n</table>\n<p>The current and all earlier profiles are listed at <code>GET https://api.trustbeat.eu/v1/preservation/profiles</code>\nand published at <code>https://trustbeat.eu/preservation</code>, each profile at its identifier. The profile references the preservation evidence policy\n(<a href=\"/preservation/evidence-policy\">evidence-policy-v1.md</a>), which states how evidence is created, renewed and\nvalidated in each period.</p>\n<p><strong>Scope.</strong> Only <em>document anchors</em> (<code>POST /v1/anchor</code>, <code>POST /v1/anchor/batch</code>) are preservation\nobjects. Tamper-Evident Logs, AI decisions and Audit Trail use the same anchoring infrastructure but\nare not preservation objects under this statement. A document anchor is a preservation object when it\nwas submitted from <strong>2026-09-14 00:00 UTC</strong> onwards and its batch has an RFC 4998 evidence record;\nthat is when TrustBeat began creating such records. An anchor carries its profile and the end of its\npreservation period from the moment it is assigned, and never changes profile\n(<code>GET /v1/anchor/{id}/status</code>, field <code>preservation</code>). Earlier anchors keep their existing proofs but\nare not covered.</p>\n<h2>2. How the preservation goal is achieved (OVR-6.1-04)</h2>\n<p>The goal is PGD: proof that a submitted hash value existed at a given time and has not changed since,\nkept verifiable for the preservation period.</p>\n<ol>\n<li><strong>Submission.</strong> The subscriber computes the SHA-256 hash of its data and submits only the hash.\nTrustBeat never receives, stores or sees the data. Anything other than a 64-character hexadecimal\nSHA-256 value is rejected. The response carries the preservation object's identifier.</li>\n<li><strong>Evidence.</strong> Hashes are collected in batches at fixed 10-minute boundaries. Each batch's hashes\nform an RFC 4998 hash tree whose root is time-stamped by an EU qualified time-stamping authority\n(§4). Validation data for the time-stamp (certificate path, OCSP response or CRL) is collected and\nembedded in a copy of the token, leaving the issued token unchanged. Each hash then has an RFC 4998\nevidence record. Details: evidence policy §1.</li>\n<li><strong>Preservation period.</strong> 30 years from submission, on every plan including the free plan, unless a\nsubscriber agreement states otherwise. Stored per object as <code>preserve_until</code>.</li>\n<li><strong>Renewal.</strong> Before the last time-stamp in a record stops being verifiable (90 days before its\nsigning certificate expires, or earlier if TS 119 312 assesses its algorithms as weakening),\nTrustBeat adds an RFC 4998 time-stamp renewal (§5.2). One renewal time-stamp covers many batches.\nEvidence policy §4.</li>\n<li><strong>Limits of a hash-only service (OVR-6.2-08).</strong> The evidence proves the existence of the <em>hash</em>.\nIt proves the existence of the data only while SHA-256 stays collision-resistant, and only if the\nsubscriber kept the data and computed the hash correctly. TrustBeat cannot re-hash data it never\nreceived, so it offers no hash-tree renewal (RFC 4998 §5.3) in profile <code>pgd-wst-v1</code>. If SHA-256 is\nassessed as weakening, TrustBeat will notify subscribers by email and state in a new evidence\npolicy version whether and how new hash values can be submitted.</li>\n<li><strong>Validation.</strong> Evidence records are standard RFC 4998 and can be validated without TrustBeat\nsoftware (for example with EU DSS); trust anchors are the EU Trusted Lists. TrustBeat keeps signed\ncopies of every version of these lists it loads, so a TSA's qualified status on a past date can\nstill be shown. Evidence policy §5.</li>\n</ol>\n<p><strong>Protocol.</strong> TrustBeat offers its own REST API (<code>https://api.trustbeat.eu/docs</code>), not the\nTS 119 512 protocol (PRP-8.1-02 is a recommendation). The profile maps each operation to its\nTS 119 512 equivalent.</p>\n<h2>3. Availability of submitted data objects and evidence (OVR-6.1-05)</h2>\n<p>The submitted data object is the hash value. TrustBeat stores it, the batch's hash tree, the\ntime-stamp tokens as issued, the copies with validation data, the renewals and the Trusted List\nsnapshots, for the whole preservation period.</p>\n<ul>\n<li><strong>Retrieval.</strong> At any time during the preservation period:\n<ul>\n<li>the subscriber, authenticated, retrieves the evidence record, proof and status of its own objects\nand the export-import package (§5);</li>\n<li>anyone holding an object's identifier retrieves its evidence record and proof from the public\nendpoints (<code>GET /v1/public/proof/{id}/evidence-record.ers</code>), so a relying party can verify\nwithout an account. The identifier is the only key; the hash reveals nothing about the data.</li>\n</ul>\n</li>\n<li><strong>Storage.</strong> One PostgreSQL database on a dedicated server at Hetzner Online GmbH, Germany. Evidence\nis built on request from the stored tree and tokens; the stored tokens are never modified.</li>\n<li><strong>Backups.</strong> Daily, encrypted before they leave the server, stored in a second EU country\n(Scaleway, France) in storage that cannot be overwritten or deleted from production; integrity and\nrestore are tested: integrity weekly, a full restore every three months. <strong>Recovery point: up to 24 hours.</strong> If the database were lost,\nsubmissions accepted since the last daily backup, and their evidence, could be lost; the subscriber\nwould hold identifiers that no longer resolve and would need to submit those hashes again (with a\nlater time). Reducing this to minutes is planned.</li>\n<li><strong>Copies held by the subscriber.</strong> The subscriber can download its evidence records and\nexport-import packages at any time and is advised to keep them with the data. An evidence record\nremains verifiable without TrustBeat until its last time-stamp expires; renewed records must be\ndownloaded again after a renewal.</li>\n<li><strong>Availability target.</strong> No contractual availability level for the free, Developer and Business\nplans; an Enterprise subscriber agreement may set one. A failure of the time-stamping authority\ndelays evidence but never loses an accepted submission: hashes stay pending until a batch is\ntime-stamped, by the fallback TSA if needed.</li>\n</ul>\n<h2>4. External organisations (OVR-6.1-06, EN 319 401 §6.1)</h2>\n<table>\n<thead>\n<tr>\n<th>Organisation</th>\n<th>Role in the service</th>\n<th>Obligations relied on</th>\n<th>Applicable policy / practice</th>\n</tr>\n</thead>\n<tbody>\n<tr>\n<td><strong>SK ID Solutions AS</strong>, Estonia</td>\n<td>Primary time-stamping authority (EU qualified) since 2026-07-01</td>\n<td>Issue RFC 3161 time-stamps under its qualified TSA policy; keep certificate status (OCSP) available</td>\n<td>Its Time-Stamping Authority Practice Statement (ETSI EN 319 421), version 9.0 in force from 2026-02-20, and its terms and conditions for the time-stamping service: <code>https://www.skidsolutions.eu/resources/time-stamping-principles-and-conditions-for-use/</code></td>\n</tr>\n<tr>\n<td><strong>EuroCert Sp. z o.o.</strong>, Poland</td>\n<td>Fallback time-stamping authority (EU qualified)</td>\n<td>As above; certificate status via CRL</td>\n<td>Its certification policy and practice statement for qualified trust services (0-PT-025, version 5.1 in force from 2025-10-20, Polish): <code>https://eurocert.pl/repozytorium/Polit_certyf_i_kodeks_post_certyf/Kwalifikowane/aktualne/</code></td>\n</tr>\n<tr>\n<td><strong>European Commission</strong> and <strong>national Trusted List operators</strong></td>\n<td>Publish the EU List of Trusted Lists and national Trusted Lists</td>\n<td>Keep the TSAs' qualified status published and signed</td>\n<td>ETSI TS 119 612</td>\n</tr>\n<tr>\n<td><strong>Hetzner Online GmbH</strong>, Germany</td>\n<td>Hosting of the application and database servers</td>\n<td>Physical security, power, network, hardware</td>\n<td>Its terms, data processing agreement and ISO/IEC 27001:2022 certification of the Nuremberg and Falkenstein data centres</td>\n</tr>\n<tr>\n<td><strong>Scaleway SAS</strong>, France</td>\n<td>Offsite encrypted database backups; storage of evidence packages</td>\n<td>Durable storage, object lock</td>\n<td>Its terms and data processing agreement</td>\n</tr>\n<tr>\n<td><strong>Seznam.cz, a.s.</strong>, Czech Republic</td>\n<td>Delivery of notifications (renewal problems, end of period, hash algorithm warnings)</td>\n<td>Deliver email</td>\n<td>Its terms</td>\n</tr>\n</tbody>\n</table>\n<p>The TSAs and Trusted List operators are relied on only through what they publish and sign; their\nstatements can be checked independently of TrustBeat. No external organisation has access to\npreservation objects, except as the hosting and backup providers of encrypted or stored data.</p>\n<h2>5. Export-import package (OVR-6.1-07, 6.1-08)</h2>\n<p><strong>How to request one.</strong> The subscriber requests a package itself, at any time during the\npreservation period, without contacting TrustBeat:\n<code>GET https://api.trustbeat.eu/v1/preservation/export?from=&lt;time&gt;&amp;to=&lt;time&gt;</code>, authenticated with the\naccount's API key or portal session, or with the <em>Export package</em> button in the portal\n(<code>https://trustbeat.eu/preservation-export</code>), which calls the same endpoint. One package covers the\naccount's preservation objects submitted in a window of at most 31 days; longer periods are exported as\nconsecutive windows. A subscriber that cannot use either can ask <code>hello@trustbeat.eu</code> from the\naccount's email address.</p>\n<p><strong>How it is produced.</strong> Format <code>trustbeat-export-import-v1</code>:</p>\n<ul>\n<li>a ZIP, <strong>not encrypted</strong> (it contains hashes and public evidence only; it travels over TLS);</li>\n<li><code>manifest.json</code>: selection, profiles, and per object the hash, submission and anchoring times,\n<code>client_ref</code>, profile and end of preservation period, with the SHA-256 and size of every other file;</li>\n<li><code>objects/&lt;id&gt;.ers</code>: the RFC 4998 evidence record with embedded validation data and all renewals,\nbyte-identical to the public endpoint;</li>\n<li><code>trusted-lists/</code>: the signed EU List of Trusted Lists and each relevant national list in force at\neach evidence time-stamp;</li>\n<li>the same inputs give the same bytes.</li>\n</ul>\n<p>Packages are released only to the authenticated account, for its own objects. Every release is\nrecorded <strong>before</strong> it is sent (time, selection, counts, SHA-256 and size of the package); without a\nrecord no package is sent, and records are never changed or deleted (OVR-7.16-04). TrustBeat does not\ntransfer packages to another preservation service; the subscriber passes them on.</p>\n<h2>6. Deletion and the end of the preservation period (OVR-6.1-09)</h2>\n<p><strong>No deletion during the preservation period.</strong> Neither the subscriber nor TrustBeat deletes a\npreservation object before its preservation period ends; TrustBeat does not delete on request either.\nThis deviates from TS 119 511 PRP-8.1-11 (<em>&quot;a preservation service with storage shall allow to delete\nstored POs&quot;</em>) and PRP-8.1-12. The reason: each evidence record is built from <strong>all</strong> the hashes of its\nbatch, which belong to many subscribers. Removing one hash would make the evidence records of every\nother object in that batch unverifiable or would require altering stored evidence, which the service\nnever does. The hash itself reveals nothing about the data, and the subscriber can make the evidence\nuseless to itself simply by discarding the data.</p>\n<p><strong>Closing an account</strong> does not end the preservation period. The account's objects stay preserved and\nrenewed until their periods end, and remain retrievable by identifier from the public endpoints. After\nclosure there is no authenticated access and no notifications; the subscriber should download an\nexport-import package before closing.</p>\n<p><strong>At the end of the preservation period</strong> of an object:</p>\n<ol>\n<li>TrustBeat stops renewing its evidence.</li>\n<li>TrustBeat notifies the subscriber by email at the account's address and makes the export-import\npackage of the object available.</li>\n<li><strong>30 days later</strong> TrustBeat deletes the object's link to the account and its metadata\n(<code>client_ref</code>, description), whether or not the package was downloaded, and stops serving its\nevidence. The hash, hash tree and time-stamps of its batch are shared with the other objects of\nthe batch and stay until the last of them has reached this step; then they are deleted too. Every\ndeletion is logged.</li>\n</ol>\n<p>The first preservation periods end in 2056.</p>\n<h2>7. Termination of the service (EN 319 401 §6.1, OVR-7.12)</h2>\n<p>If TrustBeat stops the service, it follows its termination plan:</p>\n<ul>\n<li><strong>at least 6 months' notice</strong> by email to every account and on <code>trustbeat.eu</code> (as fast as possible\nif the termination is unplanned);</li>\n<li>preservation and renewal continue until the stop date, and exports stay open;</li>\n<li>shortly before the stop date, a <strong>last time-stamp renewal</strong> of all evidence, with the qualified TSA\nwhose certificate expires latest, and a <strong>final export-import package for every account</strong>;</li>\n<li>the public evidence and verification endpoints stay online for <strong>12 months</strong> after the stop date;</li>\n<li>no successor is promised; a transfer to another preservation service happens only with notice to\neach subscriber, who may refuse;</li>\n<li>arrangements ensure the plan can be carried out, and its costs covered, even if the managing\ndirector cannot act or the company is insolvent.</li>\n</ul>\n<p>After TrustBeat stops, a subscriber keeps its evidence verifiable beyond the last time-stamp by having\nthe evidence record time-stamped again elsewhere.</p>\n<h2>8. Management of this statement (EN 319 401 §6.1)</h2>\n<ul>\n<li><strong>Approval.</strong> This statement, the profiles and the evidence policy are approved by TrustBeat's\nmanaging director (<em>jednatel</em>), who has final authority over the practices of the service and\nensures they are implemented.</li>\n<li><strong>Review.</strong> At least once a year, and whenever a profile, the evidence policy, an external\norganisation in §4 or the service's infrastructure changes materially.</li>\n<li><strong>Changes.</strong> Registered subscribers are notified by email at least 14 days before a material change\ntakes effect, as in the terms of service. The revised statement is published once approved. Every\nversion stays available with the dates it was in force.</li>\n<li><strong>Publication.</strong> At <code>https://trustbeat.eu/preservation/practice-statement</code>, alongside the profiles\nand the evidence policy (<code>https://trustbeat.eu/preservation</code>) and the terms of service\n(<code>https://trustbeat.eu/terms</code>).</li>\n</ul>\n"}