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: 5. 5. 2026 · Verze 1.0

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 — noční cron na serveru v 03:00 UTC pomocí sqlite3 .backup 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

Aktuální stav služby je viditelný přímo na kliker.cz v patičce stránky. Samostatnou public statuspage zatím neprovozujeme; v případě delšího výpadku informujeme zákazníky e-mailem.

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	Účetní a daňové doklady (faktury) uchovány v rozsahu zákonné povinnosti dle zákona o účetnictví a DPH.
~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. 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.