EÚ regulácie pre tvorcov aplikácií v roku 2026: CRA, prístupnosť, NIS2, GDPR

Stručná verzia: štyri režimy, jeden plán pripravenosti#

Pre väčšinu softvérových tímov sú v roku 2026 dôležité štyri súbory pravidiel EÚ: akt o kybernetickej odolnosti (CRA) pre bezpečnosť produktov, Európsky akt o prístupnosti (EAA) pre služby určené spotrebiteľom, NIS2 pre kybernetickú bezpečnosť základných a dôležitých subjektov a ich dodávateľských reťazcov a GDPR pre osobné údaje. Viac sa prekrývajú, než líšia, takže jeden plán pripravenosti pokryje väčšinu práce.

Akt o kybernetickej odolnosti: hlásenia platia už teraz#

Podľa aktu o kybernetickej odolnosti platí hlásenie aktívne zneužívaných zraniteľností a závažných incidentov od 11. septembra 2026 a celý súbor povinností nasleduje 11. decembra 2027. Ak je váš produkt v rozsahu pôsobnosti, časť o hláseniach už platí, takže zneužívanú zraniteľnosť musíte vedieť odhaliť, posúdiť a nahlásiť už dnes.

Hlásiť sa dá iba vtedy, keď viete, čo váš produkt obsahuje, ako vám ľudia môžu chybu oznámiť a kto čo robí, keď sa nejaká nájde. To sú tri dokumenty: softvérový kusovník (SBOM), politika zverejňovania zraniteľností a postup pri incidentoch.

Ak boli časti vášho produktu napísané s AI asistentmi, počítajte s tým, že v nich sú zraniteľnosti, ktoré zatiaľ nikto nehľadal. Tie najčastejšie pokrýva náš checklist pred spustením aplikácie z vibecodingu a checklist Supabase RLS.

Generujte SBOM v CI

Softvérový kusovník (SBOM) obsahuje zoznam všetkých komponentov a verzií, ktoré váš produkt dodáva. Generujte ho automaticky pri každom vydaní v štandardnom formáte, ako je CycloneDX alebo SPDX, uložte ho spolu s vydaním a skenujte ho na známe zraniteľnosti.

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

# Skenovanie SBOM na známe zraniteľnosti (napr. nástrojom Grype)
grype sbom:./sbom.cdx.json --fail-on high

Zverejnite politiku zverejňovania zraniteľností a security.txt

Dajte výskumníkom aj zákazníkom jeden jasný spôsob, ako nahlásiť chybu: krátku stránku s politikou zverejňovania a súbor security.txt na adrese /.well-known/security.txt (RFC 9116), ktorý na ňu odkazuje. Použite zdieľanú monitorovanú schránku, nie osobný e-mail jedného človeka.

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

Postup pri incidentoch napíšte skôr, než ho budete potrebovať

Postup pri incidentoch (runbook) premení stresujúcu noc na sled krokov. Mal by uvádzať, kto má pohotovosť, ako sa určuje závažnosť, ako incident obmedziť a službu obnoviť, kto rozhoduje, či a komu treba incident nahlásiť, a ako sa zaznamenávajú dôkazy a časová os. Lehoty a kanály hlásenia, ktoré sa na vás vzťahujú, si nechajte potvrdiť právnikom a potom ich do postupu zapíšte.

• [ ]SBOM sa generuje automaticky pri každom vydaní a ukladá sa spolu s ním
• [ ]Skenovanie závislostí a kontajnerov v CI s pravidlami na opravu nálezov vysokej závažnosti
• [ ]Politika zverejňovania zraniteľností zverejnená; security.txt je online a neexpiroval
• [ ]Kontakt na koordinované zverejňovanie: zdieľaná monitorovaná schránka so šablónou potvrdenia prijatia
• [ ]Postup pri incidentoch s pomenovanými rolami, úrovňami závažnosti a krokom rozhodnutia o nahlásení
• [ ]Denník incidentu s časovými značkami vedený od prvého upozornenia (potrebný pre akékoľvek hlásenie)
• [ ]Proces na rýchle doručenie bezpečnostných aktualizácií používateľom s informáciou, čo sa zmenilo

Európsky akt o prístupnosti: webové aplikácie a e-shopy#

Európsky akt o prístupnosti platí od 28. júna 2025, najmä pre služby určené spotrebiteľom, ako sú e-commerce, bankovníctvo, doprava, e-knihy a telekomunikácie. Mikropodniky poskytujúce služby sú vyňaté. Technickou referenciou je norma EN 301 549, ktorá zhruba zodpovedá WCAG 2.1 AA; vývoj podľa WCAG 2.2 AA vás tam dostane s rezervou.

Ak predávate spotrebiteľom cez webovú alebo mobilnú aplikáciu, počítajte s tým, že prístupnosť je dnes produktová požiadavka rovnako ako bezpečnosť. Aj tam, kde sa na vás akt nevzťahuje, sa prístupné rozhrania ľahšie používajú, testujú aj automatizujú.

• [ ]Automatické kontroly (napríklad axe) v CI na kľúčových stránkach, ktoré pri nových porušeniach zastavia build
• [ ]Plná navigácia klávesnicou s viditeľným fokusom na každom interaktívnom prvku
• [ ]Prechod kritických ciest s čítačkou obrazovky: registrácia, vyhľadávanie, pokladňa, nastavenia účtu
• [ ]Farebný kontrast spĺňa úroveň AA pre text aj prvky UI, vo svetlej aj tmavej téme
• [ ]Formuláre majú popisky, zrozumiteľné chybové hlásenia a nespoliehajú sa iba na farbu
• [ ]Veľkosti cieľových plôch a správanie fokusu spĺňajú doplnky WCAG 2.2
• [ ]Animácie rešpektujú prefers-reduced-motion; žiadny obsah nebliká
• [ ]Vyhlásenie o prístupnosti a spôsob, ako môžu používatelia nahlásiť bariéry

NIS2 na Slovensku a v Česku#

NIS2 je už súčasťou národného práva v oboch krajinách: Slovensko ju transponovalo novelou zákona č. 69/2018 Z. z. a Česko v roku 2025 prijalo nový zákon o kybernetickej bezpečnosti. Či do rozsahu pôsobnosti patrí aj vaša firma, je právna otázka. Ak do neho patria vaši klienti, pocítite to tak či tak, pretože musia riadiť riziká dodávateľského reťazca a od svojich dodávateľov softvéru budú žiadať dôkazy.

V praxi tieto dôkazy vyzerajú ako zoznam pre CRA vyššie plus niekoľko organizačných položiek. Pripravte ich raz a použite pri každom bezpečnostnom dotazníku.

• Riadenie prístupu. Pomenované účty, viacfaktorové overenie, minimálne oprávnenia, odobratie prístupov do jedného dňa.
• Auditné logy. Kto čo urobil a kedy na produkčných systémoch a v administrácii.
• Šifrovanie. Pri prenose všade; v pokoji pri databázach a zálohách.
• Zálohy s testami obnovy. Záloha, ktorú ste nikdy neobnovili, je nádej, nie kontrolné opatrenie.
• Zdokumentovaná reakcia na incidenty. Postup vyššie, s kontaktnými cestami ku klientovi.

Nič z toho si nevyžaduje certifikát. Pripravenosť na SOC 2 alebo ISO 27001 (logy, riadenie prístupu, šifrovanie, zálohy, zdokumentovaná reakcia na incidenty) odpovie na väčšinu dodávateľských dotazníkov.

Článok 28 GDPR: podpíšte zmluvu o spracúvaní#

Keď dodávateľ spracúva osobné údaje vo vašom mene, článok 28 GDPR vyžaduje medzi vami písomnú zmluvu o spracúvaní osobných údajov (DPA). Týka sa to vášho hostingu, e-mailu, analytiky a nástrojov na podporu, ako aj agentúry, ktorá vašu aplikáciu vyvíja alebo udržiava, ak má prístup k produkčným dátam.

• [ ]Zoznam všetkých sprostredkovateľov, ktorí prichádzajú do styku s osobnými údajmi, s uvedením akých údajov a prečo
• [ ]Podpísaná DPA s každým z nich vrátane vášho partnera pre vývoj a údržbu
• [ ]Zoznam ďalších sprostredkovateľov a spôsob, ako dostávať upozornenia na zmeny
• [ ]Minimalizované dáta v neprodukčných prostrediach: žiadne surové produkčné dumpy na notebookoch
• [ ]Povinnosti oznamovania porušenia ochrany údajov medzi vami a každým sprostredkovateľom zapísané v DPA

Časté medzery v malých tímoch#

Medzery, ktoré spôsobujú problémy, sú zriedka exotické. Ide o bežné inžinierske návyky, ktoré sa vynechali, keď sa produkt staval rýchlo — a vyplávajú na povrch, keď klient prvýkrát pošle bezpečnostný dotazník alebo výskumník pošle e-mail, na ktorý nikto neodpovie.

• Bezpečnostnú poštu nikto nevlastní. Hlásenia chodia do schránky bývalého zamestnanca alebo do kontaktného formulára, ktorý nikto netriedi.
• Závislosti sú roky staré. Aktualizácia pôsobí riskantne, pretože chýbajú testy, a tak známe zraniteľnosti zostávajú v produkcii.
• Tajné kľúče sú v repozitári. API kľúče v kóde alebo v klientskych bundloch, často skopírované z príkladu vygenerovaného AI.
• Žiadne logy, ktoré by si ten názov zaslúžili. Keď sa niečo stane, nedá sa povedať, k čomu sa kto dostal.
• Prístupnosť sa nikdy netestovala. Vlastné komponenty vyzerajú dobre, ale nedá sa na ne dostať klávesnicou ani ich nedokáže prečítať čítačka obrazovky.
• Zmluvy zaostávajú za realitou. Do stacku pribudli nové nástroje bez DPA a zoznam ďalších sprostredkovateľov je neaktuálny.

Každú z týchto vecí opravíte raz a lacno, no ich objavenie počas incidentu je drahé. Ak vaša aplikácia vznikla rýchlo, pri rozhodovaní, kde začať, pomôže štruktúrovaná revízia, ako je tá v článku záchrana, refaktoring, alebo prepis.

Plán pripravenosti na 90 dní#

Väčšina tímov dosiahne obhájiteľný základ zhruba za štvrťrok, ak berie compliance ako inžiniersku prácu s vlastníkmi a termínmi. Na poradí záleží: začnite tým, čo už právne platí (hlásenia podľa CRA, EAA), a potom budujte dôkazy, o ktoré budú žiadať klienti.

1. 1. – 2. týždeň: potvrďte rozsah s právnikom; zinventarizujte produkty, sprostredkovateľov a osobné údaje; zverejnite security.txt a politiku zverejňovania.
2. 3. – 4. týždeň: SBOM a skenovanie závislostí v CI; napíšte postup pri incidentoch a raz si ho nacvičte.
3. 5. – 8. týždeň: audit kritických ciest podľa WCAG 2.2 AA; najprv opravte blokujúce problémy; pridajte do CI automatické kontroly prístupnosti.
4. 9. – 10. týždeň: podpíšte alebo aktualizujte DPA; sprísnite riadenie prístupu, MFA a auditné logovanie.
5. 11. – 12. týždeň: test obnovy zo zálohy; zhromaždite balík dôkazov (politiky, SBOM, výsledky auditov, postup pri incidentoch) na jednom mieste.

Regulátori aj veľkí klienti žiadajú to isté: dôkaz, že viete, čo dodávate, a čo urobíte, keď sa to pokazí.

Ako vám môže pomôcť Backloo#

Tento základ vieme nastaviť v rámci vývoja alebo plánu Care: SBOM v CI, kontakt na zverejňovanie zraniteľností, postup pri incidentoch, auditné logy a rozhrania podľa WCAG 2.2 AA. Naše plány údržby a SLA udržiavajú závislosti zaplátané a dôkazy aktuálne a naše weby staviame podľa WCAG 2.2 AA od začiatku.

S každým klientom, k ktorého osobným údajom máme prístup, podpisujeme zmluvu o spracúvaní osobných údajov podľa čl. 28 GDPR. Ak chcete vedieť, kde stojí existujúca aplikácia, Rescue Audit vám dá písomný prehľad bezpečnostných medzier. Sme inžinieri, nie právnici, preto pracujeme spolu s vaším právnym poradcom. S otázkami nás kontaktujte.