Právní informace

Provozní pravidla

Tato stránka popisuje, jak v Klikeru reálně řešíme zálohy, dostupnost, bezpečnostní incidenty a mazání dat. Záměrně se snažíme být konkrétní a nepřeprodávat — služba je v pilotní fázi a některé prvky se ještě dolaďují.

Účinnost: 14. 8. 2026 · Verze 1.1

1. Zálohy

1.1 Aktuálně používáme dvě nezávislé úrovně záloh

Hetzner Backups — denní snapshoty celého virtuálního serveru u poskytovatele hostingu (Hetzner Online GmbH, datacentrum HEL1 Helsinki). Retence 7 dnů (rotace nejstarší záloha automaticky zaniká). Snapshot obsahuje databázi i souborový systém aplikace.
Lokální snapshot databáze a příloh — noční cron na serveru v 03:00 UTC. Databázi zálohujeme příkazem VACUUM INTO, který pořídí konzistentní kopii v jedné transakci, aniž by aplikaci na dobu zálohy zastavil. Nahrané přílohy (doklady, archivy vyúčtování) se ukládají vedle ní jako komprimovaný archiv .tar.gz; databáze a přílohy z téhož běhu tvoří dvojici, která se obnovuje společně. Obojí míří do adresáře app/data/backups/. Retence 30 dnů, automatické prořezávání starších záloh.

1.2 Co aktuálně nemáme (a říkáme to rovně)

Offsite zálohy mimo Hetzner (např. Backblaze B2, S3) zatím nasazené nejsou. Plánujeme je doplnit; do té doby spoléháme na denní snapshoty Hetzner mimo aplikační server.
Pravidelné automatické testy obnovy probíhají v rámci CI/regression suite, ale ne formálním měsíčním cyklem.

1.3 Export dat zákazníkem

Nezávisle na zálohách na straně poskytovatele si zákazník může kdykoli stáhnout kompletní export dat své organizace přímo z aplikace (CSV / JSON / PDF). Doporučujeme tento export provést pravidelně — je to nejjistější způsob, jak mít data pod vlastní kontrolou.

2. Dostupnost

2.1 Cílová úroveň pro pilotní fázi

Službu provozujeme způsobem „best-effort". Pro pilotní fázi nesjednáváme formální SLA s garantovaným uptime procentem a náhradami. Naše interní cílová úroveň je dostupnost služby v pracovních hodinách (po–pá 7:00–19:00 SEČ) bez neplánovaných výpadků.

2.2 Co dostupnost ovlivňuje

Plánované deploye a úpravy — provádíme zpravidla bez přerušení provozu (rolling restart Node procesu, řádově sekundy). Server se při běžných úpravách nevypíná.
Aktualizace operačního systému / kernelu — vyžadují krátký restart serveru (řádově minuty). Probíhají nepravidelně, mimo pracovní hodiny.
Plánovaná údržba databáze (případné migrace schématu) — pokud by si vyžádala odstávku, upozorníme zákazníky e-mailem nejméně 48 hodin předem.
Mimořádné události (výpadek poskytovatele hostingu, DDoS, neočekávaná chyba aplikace) — řešíme jako incident podle čl. 3.

2.3 Status

Samostatnou veřejnou stránku se stavem služby (statuspage) zatím neprovozujeme a stav služby neukazujeme ani v patičce webu. V případě delšího výpadku informujeme zákazníky e-mailem — je to jediný kanál, na který se máte spolehnout.

3. Bezpečnostní a provozní incidenty

3.1 Detekce

Server píše rotující aplikační log (app/data/server.log, default 10 MB rotation).
Volitelný e-mail alert na console.error události s throttle 5 minut per error message prefix (zapnutý v produkci).
Audit log všech důležitých operací v databázi — kdo, kdy, co, stav před/po, IP, User-Agent — s detekcí anomálií (audit-alerts).

3.2 Reakce

Při zjištění incidentu postupujeme v tomto pořadí:

Triage — určení rozsahu, dotčených zákazníků a povahy incidentu.
Ohraničení — pokud hrozí pokračování incidentu, omezení přístupu (revokace tokenů, restart, dočasné odpojení).
Obnovení provozu — uvedení služby do funkčního stavu (restart, rollback změny, obnova ze zálohy).
Notifikace zákazníků — e-mailem na kontaktní adresu uvedenou v jejich účtu.
Post-mortem — u významnějších incidentů písemný rozbor s preventivními opatřeními.

3.3 Notifikační lhůty

Typ incidentu	Notifikace zákazníka
Porušení zabezpečení osobních údajů (čl. 33 GDPR) — únik, neoprávněný přístup, ztráta integrity	bez zbytečného odkladu, nejpozději do 72 hodin od okamžiku, kdy se o porušení dozvíme
Provozní incident s výpadkem nad 1 hodinu v pracovních hodinách	během trvání incidentu + e-mail s rekapitulací po obnovení
Plánovaná odstávka	nejméně 48 hodin předem e-mailem
Změna subdodavatele	nejméně 30 dnů předem (viz DPA)

3.4 Hlášení od zákazníka

Pokud zákazník zjistí provozní problém nebo bezpečnostní zranitelnost, prosíme o hlášení na podpora@kliker.cz. Bezpečnostní hlášení vyřizujeme přednostně.

4. Mazání dat

4.1 Smazání jednotlivého záznamu

V běžném provozu zákazník (správce) maže záznamy přímo v aplikaci (jednotku, vlastníka, předpis, platbu). Některé záznamy mohou být archivovány a dohledatelné v rámci historie, jiné jsou mazány natrvalo podle typu záznamu. Smazaný záznam je v databázi nadále dohledatelný v audit logu (snapshot stavu před smazáním + IP + uživatel) po dobu retence audit logu (zpravidla 24 měsíců).

4.2 Smazání celé organizace (tenantu)

Hard-delete celé organizace je možný jen při splnění dvou podmínek:

uživatel s rolí OWNER
v potvrzovacím dialogu zadá přesný název organizace jako kontrolu (confirm_name)

Při smazání organizace se okamžitě a kaskádově odstraní všechny související záznamy ze všech tabulek (jednotky, vlastníci, předpisy, platby, vyúčtování, dokumenty, kontakty, měřidla, allocation rules, settlement runs, atd.) prostřednictvím ON DELETE CASCADE.

Audit log si jako forenzní stopu ponechává denormalizovaný tenant_name_snapshot + tenant_id_snapshot i po smazání tenantu, aby šlo dohledat, kdo a kdy organizaci smazal.

4.3 Časové linie po ukončení smlouvy

Den od ukončení	Co se děje
0–30	Účet ve stavu „read-only export" — zákazník si může stáhnout kompletní export dat (CSV / JSON / PDF).
30	Účet je deaktivován; přístup do aplikace ukončen.
30–90	Provozní data jsou označena k mazání a hard-delete proběhne nejpozději k 90. dni.
do ~7 dnů	Hetzner Backups přirozeně zarotují a starší snapshoty obsahující data zaniknou.
do ~30 dnů	Lokální noční snapshoty zarotují a starší zálohy obsahující data zaniknou.
10 let	Vlastní účetní a daňové doklady poskytovatele (faktury za předplatné) — uchovány v rozsahu zákonné povinnosti dle zákona o účetnictví a DPH. Doklady, které vystavil zákazník ve své organizaci, se mažou spolu s provozními daty (viz řádek 30–90).
~24 měsíců	Záznamy v audit logu (kdo provedl jakou operaci) — bezpečnostní oprávněný zájem dle čl. 6 odst. 1 písm. f) GDPR.

4.4 Mazání na žádost subjektu údajů (čl. 17 GDPR)

Pokud subjekt údajů (vlastník, člen, nájemník) uplatní právo na výmaz, řídí se žádost DPA — žádost vyřizuje správce (typicky SVJ/BD). Kliker poskytuje správci nástroje v aplikaci (vyhledání, anonymizace, výmaz) a je mu nápomocen v rozsahu čl. 28 GDPR.

5. Ukázkové demo (demo.kliker.cz)

Demo je samostatná instalace aplikace s vlastní databází na stejném serveru. Nevidí do ostré aplikace a ostrá aplikace nevidí do něj: má oddělený databázový soubor, oddělené úložiště příloh i vlastní log a proces služby, který k datům zákazníků nemá přístupová práva. Data v demu jsou vymyšlená ukázka, žádná zákaznická.

Obnova každé 2 hodiny — plánovaná úloha přepíše databázi dema výchozí šablonou a službu restartuje. Vše, co návštěvník v demu vytvořil nebo změnil, tím nenávratně zmizí.
Žádné odchozí e-maily — v demu je odesílání pošty vypnuté na úrovni aplikace, takže z něj nelze nikomu nic poslat.
Zamčené provozní funkce — v demu nejde spravovat tarif a fakturaci, zvát uživatele, měnit heslo ani dvoufázové ověření, exportovat GDPR balík, smazat organizaci ani napojit banku.
Bez registrace a bez SLA — nechceme e-mail ani jiný údaj a demo nespadá pod cílové úrovně dostupnosti podle čl. 2; může být kdykoli vypnuté nebo obnovené.

Denní zálohy aplikace se dema netýkají — zálohuje se databáze ostré aplikace. Zbytky dat z dema, které se dostanou do snapshotů celého serveru u poskytovatele hostingu, zanikají rotací do 7 dnů. Do dema přesto nevkládejte skutečné osobní údaje.

6. Změny těchto pravidel

Tato Provozní pravidla aktualizujeme podle reálného stavu provozu. O podstatných změnách (např. změna retencí, nová úroveň záloh, nový režim dostupnosti) informujeme zákazníky e-mailem nejméně 14 dní předem. Aktuální verze je vždy dostupná na této stránce s datem účinnosti.