EU regulace pro tvůrce aplikací v roce 2026: CRA, přístupnost, NIS2, GDPR

Ve zkratce: čtyři režimy, jeden plán připravenosti#

Pro většinu softwarových týmů jsou v roce 2026 důležité čtyři soubory pravidel EU: akt o kybernetické odolnosti (Cyber Resilience Act, CRA) pro bezpečnost produktů, Evropský akt o přístupnosti (EAA) pro služby určené spotřebitelům, NIS2 pro kybernetickou bezpečnost základních a důležitých subjektů a jejich dodavatelských řetězců a GDPR pro osobní údaje. Víc se překrývají, než liší, takže většinu pokryje jeden plán připravenosti.

Akt o kybernetické odolnosti: povinnost hlásit už platí#

Podle aktu o kybernetické odolnosti platí hlášení aktivně zneužívaných zranitelností a závažných incidentů od 11. září 2026 a plný soubor povinností následuje 11. prosince 2027. Pokud se akt na váš produkt vztahuje, část o hlášení už platí, takže zneužívanou zranitelnost musíte umět odhalit, posoudit a nahlásit už dnes.

Hlásit lze jen tehdy, když víte, co váš produkt obsahuje, jak vám lidé mohou o chybě dát vědět a kdo co dělá, když se nějaká najde. To jsou tři dokumenty: softwarový kusovník (SBOM), zásady pro hlášení zranitelností a postup pro řešení incidentů (runbook).

Pokud části vašeho produktu vznikly s AI asistenty, počítejte s tím, že v nich jsou zranitelnosti, které ještě nikdo nehledal. Ty nejčastější pokrývá náš produkční checklist pro aplikace z vibecodingu a checklist Supabase RLS.

Generujte SBOM v CI

Softwarový kusovník (software bill of materials) vypisuje každou komponentu a verzi, kterou váš produkt obsahuje. Generujte ho automaticky při každém vydání ve standardním formátu, jako je CycloneDX nebo SPDX, ukládejte ho k vydání a skenujte ho na známé zranitelnosti.

# Příklad pro Node.js: CycloneDX SBOM pro produkční strom závislostí
npx @cyclonedx/cyclonedx-npm --omit dev --output-file sbom.cdx.json

# Skenování SBOM na známé zranitelnosti (např. pomocí Grype)
grype sbom:./sbom.cdx.json --fail-on high

Zveřejněte zásady pro hlášení zranitelností a security.txt

Dejte výzkumníkům i zákazníkům jeden jasný způsob, jak chybu nahlásit: krátkou stránku se zásadami pro hlášení a soubor security.txt na adrese /.well-known/security.txt (RFC 9116), který na ni odkazuje. Používejte sdílenou schránku, kterou někdo sleduje, ne osobní e-mail jednoho člověka.

Contact: mailto:security@example.com
Expires: 2027-10-01T00:00:00.000Z
Preferred-Languages: en, sk, cs
Policy: https://example.com/security/disclosure-policy
Canonical: https://example.com/.well-known/security.txt

Sepište postup pro incidenty dřív, než ho budete potřebovat

Runbook promění stresující noc v posloupnost kroků. Měl by říkat, kdo má pohotovost, jak se určuje závažnost, jak incident omezit a službu obnovit, kdo rozhoduje, jestli se událost hlásí a komu, a jak se zaznamenávají důkazy a časová osa. Lhůty a kanály pro hlášení, které se na vás vztahují, si nechte potvrdit právníkem a pak je do runbooku zapište.

• [ ]SBOM se generuje automaticky pro každé vydání a ukládá se k němu
• [ ]Skenování závislostí a kontejnerů v CI, s pravidly pro opravu nálezů vysoké závažnosti
• [ ]Zásady pro hlášení zranitelností zveřejněné; security.txt dostupný a neexpirovaný
• [ ]Kontakt pro koordinované zveřejňování: sdílená schránka, kterou někdo sleduje, se šablonou potvrzení přijetí
• [ ]Postup pro incidenty se jmenovitými rolemi, úrovněmi závažnosti a krokem rozhodnutí o hlášení
• [ ]Záznam incidentu s časovými značkami vedený od prvního upozornění (potřebný pro jakékoli hlášení)
• [ ]Proces, jak uživatelům rychle dodat bezpečnostní aktualizace a říct jim, co se změnilo

Evropský akt o přístupnosti: webové aplikace a e-shopy#

Evropský akt o přístupnosti platí od 28. června 2025, převážně pro služby určené spotřebitelům, jako je e-commerce, bankovnictví, doprava, e-knihy a telekomunikace. Mikropodniky poskytující služby jsou vyjmuté. Technickým měřítkem je norma EN 301 549, která zhruba odpovídá WCAG 2.1 AA; vývoj podle WCAG 2.2 AA vás tam dostane s rezervou.

Pokud prodáváte spotřebitelům přes webovou nebo mobilní aplikaci, počítejte s tím, že přístupnost je teď produktovým požadavkem, stejně jako bezpečnost. I tam, kde se na vás akt nevztahuje, se přístupná rozhraní snáz používají, testují i automatizují.

• [ ]Automatické kontroly (například axe) v CI na klíčových stránkách, které při nových porušeních shodí build
• [ ]Plná navigace klávesnicí s viditelným fokusem na každém interaktivním prvku
• [ ]Průchod se čtečkou obrazovky po kritických cestách: registrace, vyhledávání, pokladna, nastavení účtu
• [ ]Kontrast barev splňuje AA u textu i prvků UI, ve světlém i tmavém režimu
• [ ]Formuláře mají popisky, srozumitelné chybové hlášky a nespoléhají jen na barvu
• [ ]Velikost cílových ploch a chování fokusu splňují doplňky WCAG 2.2
• [ ]Animace respektují prefers-reduced-motion; žádný obsah nebliká
• [ ]Prohlášení o přístupnosti a způsob, jak mohou uživatelé nahlásit bariéry

NIS2 na Slovensku a v Česku#

NIS2 je už v obou zemích součástí národního práva: Slovensko ji transponovalo novelou zákona č. 69/2018 a Česko v roce 2025 přijalo nový zákon o kybernetické bezpečnosti. Jestli se vztahuje přímo na vaši firmu, je právní otázka. Pokud se vztahuje na vaše klienty, pocítíte ji tak jako tak, protože musí řídit rizika dodavatelského řetězce a budou po svých softwarových dodavatelích chtít důkazy.

V praxi ty důkazy vypadají jako seznam pro CRA výše plus několik organizačních položek. Připravte je jednou a používejte je pro každý bezpečnostní dotazník.

• Řízení přístupu. Jmenovité účty, vícefaktorové ověřování, minimální oprávnění, odebrání přístupů do jednoho dne.
• Auditní logy. Kdo co kdy udělal v produkčních systémech a administracích.
• Šifrování. Při přenosu všude; v klidu u databází a záloh.
• Zálohy s testy obnovy. Záloha, kterou jste nikdy neobnovili, je naděje, ne kontrolní opatření.
• Zdokumentovaná reakce na incidenty. Runbook popsaný výše, s kontaktními cestami ke klientovi.

Nic z toho nevyžaduje certifikát. Připravenost na SOC 2 nebo ISO 27001 (logy, řízení přístupu, šifrování, zálohy, zdokumentovaná reakce na incidenty) odpoví na většinu dodavatelských dotazníků.

Čl. 28 GDPR: podepište smlouvu o zpracování#

Když dodavatel zpracovává osobní údaje vaším jménem, vyžaduje čl. 28 GDPR mezi vámi písemnou smlouvu o zpracování osobních údajů (DPA). To se týká hostingu, e-mailu, analytiky a nástrojů podpory — a také agentury, která vaši aplikaci vyvíjí nebo udržuje, pokud má přístup k produkčním datům.

• [ ]Seznam všech zpracovatelů, kteří přicházejí do styku s osobními údaji, s uvedením jakých údajů a proč
• [ ]Podepsaná smlouva o zpracování s každým z nich, včetně vašeho vývojového a servisního partnera
• [ ]Vyjmenovaní subzpracovatelé a způsob, jak dostávat oznámení o změnách
• [ ]Minimalizace dat v neprodukčních prostředích: žádné surové produkční dumpy na laptopech
• [ ]Povinnosti oznamovat porušení zabezpečení mezi vámi a každým zpracovatelem zapsané ve smlouvě

Časté mezery v malých týmech#

Mezery, které způsobují potíže, jsou málokdy exotické. Jde o běžné inženýrské návyky, které se přeskočily, když se produkt stavěl rychle — a ukážou se ve chvíli, kdy klient pošle první bezpečnostní dotazník nebo výzkumník pošle e-mail, na který nikdo neodpoví.

• Bezpečnostní poštu nikdo nevlastní. Hlášení chodí do schránky bývalého zaměstnance nebo do kontaktního formuláře, který nikdo netřídí.
• Závislosti jsou roky staré. Aktualizace působí riskantně, protože chybí testy, a tak známé zranitelnosti zůstávají v produkci.
• Tajné klíče jsou v repozitáři. API klíče v kódu nebo v klientských bundlech, často zkopírované z příkladu vygenerovaného AI.
• Žádné logy, které by stály za řeč. Když se něco stane, nedá se říct, k čemu se kdo dostal.
• Přístupnost se nikdy netestovala. Vlastní komponenty vypadají správně, ale nejde se k nim dostat klávesnicí ani je přečíst čtečkou obrazovky.
• Smlouvy zaostávají za realitou. Do stacku přibyly nové nástroje bez smlouvy o zpracování a seznam subzpracovatelů je zastaralý.

Každou z těchto mezer je levné jednou opravit a drahé ji objevit během incidentu. Pokud vaše aplikace vznikla rychle, pomůže vám rozhodnout, kde začít, strukturovaná revize, jakou popisujeme v článku záchrana, refaktoring, nebo přepis.

Plán připravenosti na 90 dní#

Většina týmů se dostane na obhajitelný základ zhruba za čtvrtletí, pokud k regulacím přistupuje jako k inženýrské práci s vlastníky a termíny. Na pořadí záleží: začněte tím, co už právně platí (hlášení podle CRA, EAA), a pak budujte podklady, o které si klienti řeknou.

1. Týdny 1–2: potvrďte si rozsah s právníkem; zinventarizujte produkty, zpracovatele a osobní údaje; zveřejněte security.txt a zásady pro hlášení zranitelností.
2. Týdny 3–4: SBOM a skenování závislostí v CI; sepište postup pro incidenty a jednou ho nacvičte.
3. Týdny 5–8: audit kritických cest podle WCAG 2.2 AA; nejdřív opravte blokující chyby; přidejte do CI automatické kontroly přístupnosti.
4. Týdny 9–10: podepište nebo aktualizujte smlouvy o zpracování; zpřísněte řízení přístupu, MFA a auditní logování.
5. Týdny 11–12: test obnovy ze zálohy; shromážděte balíček podkladů (zásady, SBOM, výsledky auditů, runbook) na jedno místo.

Regulátoři i firemní klienti chtějí totéž: důkaz, že víte, co dodáváte, a co děláte, když se to rozbije.

Jak vám Backloo může pomoct#

Tento základ vám můžeme nastavit v rámci vývoje nebo plánu Care: SBOM v CI, kontakt pro hlášení zranitelností, postup pro incidenty, auditní logy a rozhraní podle WCAG 2.2 AA. Naše plány údržby a SLA udržují závislosti zazáplatované a podklady aktuální a naše weby stavíme podle WCAG 2.2 AA od začátku.

S každým klientem, k jehož osobním údajům máme přístup, podepisujeme smlouvu o zpracování podle čl. 28 GDPR. Pokud chcete vědět, kde stojí vaše stávající aplikace, Rescue Audit vám dá písemný přehled bezpečnostních mezer. Jsme inženýři, ne právníci, takže pracujeme ruku v ruce s vaším právníkem. S dotazy se nám ozvěte.