Dalis finansų įstaigų turi veiklos tęstinumo planą, kuris realaus incidento metu greičiausiai neveiktų. Ne todėl, kad dokumentas būtų tuščias ar blogai suformatuotas, o todėl, kad jis neatsako į svarbiausią klausimą: kas tiksliai turi būti padaryta pirmąją incidento valandą, kad būtų apsaugoti klientai, lėšos, duomenys ir kritinės paslaugos?

Finansų įstaigos veiklos tęstinumo planas nėra tik formalus dokumentas licencijai, priežiūros institucijai ar vidaus tvarkų sąrašui papildyti. Finansų sektoriuje veiklos tęstinumas tiesiogiai susijęs su klientų lėšomis, mokėjimais, investicijomis, paskolų administravimu, platformų veikimu, asmens duomenimis, trečiųjų šalių paslaugomis ir reguliaciniais įsipareigojimais.

Todėl geras BCP — angl. Business Continuity Plan — turi atsakyti ne tik į klausimą „ką įmonė darytų sutrikus veiklai?“, bet ir į daug praktiškesnį klausimą: ką konkrečiai darome per pirmas 15, 30, 60 minučių ir pirmąsias 24 valandas?

Šis klausimas tapo dar aktualesnis įsigaliojus DORA — Skaitmeninės veiklos atsparumo aktui. DORA yra ES reglamentas dėl finansų sektoriaus skaitmeninės veiklos atsparumo, apimantis ICT rizikos valdymą, incidentų pranešimą, skaitmeninio atsparumo testavimą ir ICT trečiųjų šalių rizikos valdymą. Reglamentas taikomas nuo 2025 m. sausio 17 d.

Sutelktinio finansavimo paslaugų teikėjams veiklos tęstinumo plano reikalavimas taip pat aiškiai įtvirtintas ES teisėje. Reglamentas (ES) 2020/1503 nustato bendras sutelktinio finansavimo paslaugų teikimo, leidimų išdavimo ir priežiūros taisykles, o Komisijos deleguotasis reglamentas (ES) 2022/2116 detalizuoja priemones ir procedūras, kurios turi būti numatytos sutelktinio finansavimo paslaugų teikėjų veiklos tęstinumo plane.

Kitaip tariant, finansų įstaigos veiklos tęstinumo planas nėra vien gero valdymo rekomendacija. Daugeliu atvejų tai yra teisinės, reguliacinės ir praktinės veiklos atsparumo sistemos dalis.

Kas yra BCP ir kuo jis skiriasi nuo BCM?

Svarbu atskirti du dalykus: BCM ir BCP.

BCM — angl. Business Continuity Management — yra veiklos tęstinumo valdymo sistema. Ji apima organizacijos kontekstą, vadovybės atsakomybę, poveikio veiklai analizę, rizikų vertinimą, veiklos tęstinumo strategijas, planus, testavimą, stebėseną ir nuolatinį gerinimą.

BCP — angl. Business Continuity Plan — yra vienas iš BCM sistemos rezultatų: konkretus planas, pagal kurį organizacija veikia sutrikimo metu.

Pagal ISO 22301 logiką veiklos tęstinumo planas nėra atskiras „šablonas“. Jis yra platesnės veiklos tęstinumo valdymo sistemos dalis. Prieš rengiant BCP turi būti aišku, kokios veiklos yra kritinės, koks jų sutrikimo poveikis, kokie atkūrimo tikslai, kokios tęstinumo strategijos pasirenkamos ir kaip planas bus testuojamas. Kitaip tariant, BCP yra ne pradžia, o BCM proceso rezultatas. ISO 22301 yra tarptautinis veiklos tęstinumo valdymo sistemų standartas, skirtas organizacijų atsparumui trikdantiems incidentams stiprinti.

Finansų įstaigoms taip pat aktuali ISO/IEC 27031 logika, nes ji siejama su ICT pasirengimu veiklos tęstinumui. Praktikoje tai reiškia, kad BCP turi būti sujungtas su informacinių sistemų, duomenų, tinklų, debesijos, API, tapatybės nustatymo, mokėjimų ir išorinių ICT tiekėjų atkūrimu. ISO/IEC 27031 pateikia gaires, kaip užtikrinti, kad ICT būtų pasirengusios palaikyti veiklos tęstinumą.

Kodėl finansų įstaigos BCP negali būti bendrinis dokumentas?

Bendrinis veiklos tęstinumo planas dažnai apsiriboja tokiais scenarijais kaip patalpų praradimas, darbuotojų nebuvimas, techninės įrangos gedimas, tiekėjo sutrikimas ar duomenų praradimas. Tokia struktūra gali būti naudinga kaip pradžia, tačiau finansų įstaigai jos nepakanka.

Finansų įstaigos veikla dažniausiai vyksta per skaitmenines platformas, mokėjimų sistemas, klientų paskyras, API sąsajas, debesijos paslaugas, tapatybės nustatymo sprendimus, duomenų bazes ir išorinius ICT tiekėjus. Todėl BCP turi būti susietas su IT paslaugų tęstinumu, duomenų atkūrimu, mokėjimų tęstinumu, klientų lėšų apsauga ir reguliacinių terminų laikymusi.

Teisinerizika.lt ekspertų auditavimo metu atlikta Lietuvos finansų sektoriaus BCP analizė rodo, kad planuose dažnai yra įvardijamos bendros rizikos: darbuotojų negalėjimas vykdyti funkcijų, patalpų praradimas, techninės įrangos gedimai, platformos sutrikimai, duomenų praradimas, mokėjimo ar tapatybės nustatymo paslaugų teikėjų veiklos sutrikimai.

Viename iš analizuotų planų pagrindinės funkcijos siejamos su klientų galimybe prisijungti prie platformos, matyti informaciją apie paskolas ir lėšų likučius, vykdyti operacijas bei užtikrinti operacijų registravimą. Kitame plane veiklos tęstinumas siejamas su ypatingos svarbos paslaugomis ir klientų susitarimų administravimu.

Tai rodo teisingą kryptį: finansų įstaigos BCP turi prasidėti ne nuo abstrakčių rizikų, o nuo klausimo, kokias paslaugas, klientų interesus ir įsipareigojimus būtina apsaugoti net sutrikimo metu.

Kokius reikalavimus nustato DORA?

DORA finansų sektoriuje įveda platesnę operacinio atsparumo logiką. Ji nėra vien „IT saugumo“ ar „veiklos tęstinumo plano“ reglamentas. DORA apima visą ICT rizikos valdymo ciklą: nuo prevencijos iki incidentų valdymo, testavimo, atkūrimo ir trečiųjų šalių rizikos kontrolės.

Ypač svarbi DORA sąvoka — kritinės arba svarbios funkcijos (critical or important functions). Praktikoje tai reiškia, kad finansų subjektas turi suprasti, kurios funkcijos yra tokios svarbios, kad jų sutrikimas gali turėti reikšmingą poveikį paslaugų tęstinumui, klientams, rinkai, reguliacinei atitikčiai ar pačiai įstaigai.

DORA logika BCP kontekste reiškia, kad finansų įstaiga turi gebėti parodyti:

Klausimas Ką reikia turėti praktiškai
Kokios funkcijos yra kritinės ar svarbios? Kritinių paslaugų / funkcijų registrą
Kokios ICT sistemos jas palaiko? ICT priklausomybių žemėlapį
Per kiek laiko jos turi būti atkurtos? RTO / MTPD / MBCO matricas
Kiek duomenų galima prarasti? RPO pagal sistemas ir paslaugas
Kaip reaguojama į sutrikimą? Incidentų klasifikavimą ir BCP aktyvavimo kriterijus
Kaip atkuriama veikla? ICT reagavimo ir atkūrimo planus
Kaip įtraukiami tiekėjai? Kritinių ICT tiekėjų ir SLA registrą
Kaip patikrinama, ar planai veikia? Testavimo programą ir pratybų įrodymus

DORA įgyvendinamieji techniniai standartai detalizuoja, kad turi būti nustatyti kriterijai aktyvuoti ir deaktyvuoti ICT veiklos tęstinumo planus, ICT reagavimo ir atkūrimo planus bei krizių komunikacijos planus.

Dažniausios finansų įstaigų BCP klaidos

1 klaida. Nėra aiškių BCP aktyvavimo kriterijų

Dažnas planas aprašo rizikas, bet nepasako, kada įvykis tampa BCP situacija.

Finansų įstaiga turi aiškiai atskirti:

Lygis Apibūdinimas Tipinis valdymas
Nereikšmingas incidentas Nedidelis sutrikimas, neturintis reikšmingo poveikio kritinėms paslaugoms Įprastas incidentų valdymas
Reikšmingas incidentas Reikšmingas paslaugos, sistemos, tiekėjo ar duomenų sutrikimas Incidentų valdymas + vadovybės informavimas
Krizė/ Veiklos tęstinumo plano įvykis Sutrikimas veikia kritinę ar svarbią funkciją, klientus, mokėjimus, duomenis, reguliacinius terminus ar reputaciją BCP aktyvavimas ir krizės valdymo struktūra

BCP aktyvavimo kriterijai gali būti, pavyzdžiui:

  • neveikia klientų platforma ilgiau nei nustatytas toleruojamas laikas;
  • sutrikęs mokėjimų vykdymas;
  • prarasta arba sugadinta kritinė duomenų bazė;
  • nepasiekiamas kritinis ICT tiekėjas;
  • sutrikimas gali paveikti klientų lėšas ar investicijų / paskolų administravimą;
  • incidentas gali būti praneštinas priežiūros institucijai;
  • incidentas gali paveikti asmens duomenų konfidencialumą, vientisumą ar prieinamumą;
  • sutrikimas kelia reikšmingą reputacinę riziką.

Jeigu aktyvavimo kriterijų nėra, organizacija gali per ilgai „stebėti situaciją“, nors jau reikia veikti pagal BCP.

Praktinis testas: jeigu darbuotojas, atsidaręs BCP, per 5 minutes negali suprasti, kas aktyvuoja planą, kam skambinti, kokią paslaugą atkurti pirmiausia ir kada informuoti klientus, toks planas greičiausiai yra per daug teorinis.

2 klaida. Planas aprašo rizikas, bet ne veiksmus

Pirmoji praktinė BCP klaida — dokumentas tampa rizikų aprašymu, o ne veikimo instrukcija.

Plane gali būti parašyta, kad įstaiga susiduria su platformos sutrikimo, duomenų praradimo, tiekėjo neveikimo ar kibernetinės atakos rizika. Tačiau praktinis BCP turi atsakyti į daug konkretesnius klausimus.

Kas nustato, kad įvykis yra veiklos tęstinumo incidentas? Kas aktyvuoja BCP? Kas vadovauja incidento valdymui? Kokie veiksmai atliekami per pirmą valandą? Kur saugomas aktualus kontaktų sąrašas? Kada informuojami klientai? Kada informuojama priežiūros institucija? Kada pereinama į degradavusį veikimo režimą? Kada planas deaktyvuojamas?

Jeigu šių atsakymų nėra, dokumentas gali atrodyti tvarkingas, tačiau incidento metu jis bus mažai naudingas.

BCP neturi būti skirtas tik ramiam skaitymui. Jis turi veikti tada, kai neveikia platforma, vadovas nepasiekiamas, tiekėjas neatsiliepia, klientai pradeda klausti, kur jų lėšos, o IT komanda dar tik aiškinasi sutrikimo priežastį.

3 klaida. Nėra RTO, RPO, MTPD ir MBCO

Finansų įstaigai nepakanka parašyti, kad veikla turi būti atkurta „kuo greičiau“ arba „nedelsiant“.

Reikia nustatyti bent šiuos parametrus:

Parametras Ką reiškia
RTO Per kiek laiko paslauga ar sistema turi būti atkurta
RPO Kiek duomenų praradimo galima toleruoti
MTPD Maksimalus toleruotinas sutrikimo laikotarpis
MBCO Minimalus veiklos tęstinumo lygis, kuris turi būti palaikomas sutrikimo metu

Terminą MAO kartais galima sutikti kaip artimą MTPD sinonimą, tačiau praktikoje geriau pasirinkti vieną terminą ir nuosekliai jį naudoti visame dokumente. ISO 22301 logikoje patogiau remtis MTPD.

Teisinerizika.lt ekspertų praktikoje šie parametrai priskiriami konkrečioms kritinėms veikloms ar procesams. Pavyzdžiui, gerame BCP modelyje kritinei veiklai turi būti nustatyti MBCO, MAO, RTO, RPO ir pagrindimas, kodėl pasirinktos būtent tokios ribos.

Praktikoje tai reiškia, kad klientų prisijungimo funkcijai gali būti taikomas vienas RTO, mokėjimų vykdymui — kitas, klientų informavimui — trečias, o vidinėms administracinėms funkcijoms — dar kitas.

Jeigu RTO ir RPO nėra, vadovybė, IT, tiekėjai ir klientų aptarnavimas gali skirtingai suprasti, ką reiškia „skubiai“. Vienam tai bus 30 minučių, kitam — kita darbo diena.

4 klaida. IT atkūrimas nesusietas su verslo paslaugomis

Finansų sektoriuje IT nėra pagalbinė funkcija. Dažnai IT yra pati paslauga.

Jeigu neveikia platforma, klientas negali prisijungti. Jeigu neveikia mokėjimų integracija, nevyksta įmokos ar išmokos. Jeigu neveikia tapatybės nustatymas, negalima aptarnauti naujų klientų. Jeigu prarandami duomenys, kyla ne tik IT, bet ir teisinė, reputacinė bei klientų apsaugos problema.

Todėl finansų įstaigos BCP turi būti susietas su ICT veiklos tęstinumo planu ir IT atkūrimo procedūromis.

Įmonių neretai naudojamuose IT paslaugų tęstinumo planų šablonuose yra naudingi operaciniai elementai: atkūrimo strategija, atkūrimo tikslai, atkūrimo komanda, kontrolinis sąrašas, atkūrimo procedūros ir palaikomoji informacija. Tai nėra pagrindinis BCP standartas — normatyvinis veiklos tęstinumo pagrindas būtų ISO 22301, o ICT pasirengimo logikai aktuali ISO/IEC 27031 kryptis — tačiau kaip praktinis IT paslaugų tęstinumo plano pavyzdys toks šablonas yra naudingas.

Geras finansų įstaigos BCP turėtų aiškiai parodyti ryšį tarp verslo paslaugos ir ją palaikančių IT išteklių:

Kritinė paslauga Palaikanti sistema RTO RPO Kritinis tiekėjas
Klientų prisijungimas Platforma, autentifikavimo sistema 1 val. 15 min. Hostingas / IAM
Mokėjimų vykdymas Mokėjimų API, bankų sąsajos 2–4 val. 15–60 min. Mokėjimų partneris
Investicijų / paskolų administravimas Portfelio sistema, duomenų bazė 4–8 val. 1 val. Platformos tiekėjas
Klientų informavimas El. paštas, SMS, svetainė 1–2 val. Netaikoma Ryšių tiekėjai

Be tokio susiejimo BCP lieka per daug abstraktus. Jis sako, kad veiklą reikia tęsti, bet neparodo, kokias sistemas ir kokia eilės tvarka reikia atkurti.

5 klaida. Nėra failover, fallback ir rankinių alternatyvų

Finansų įstaigos BCP turi atsakyti ne tik į klausimą „kaip atkursime sistemą?“, bet ir į klausimą „kaip veiksime, kol sistema dar neatkurta?“

Čia svarbios trys sąvokos:

Sąvoka Ką reiškia
Failover Automatinis arba kontroliuojamas perjungimas į atsarginę sistemą, aplinką ar infrastruktūrą
Fallback Atsarginis veikimo būdas, kai pagrindinis sprendimas neveikia
Manual workaround Rankinė arba pusiau rankinė procedūra, leidžianti tęsti minimalią paslaugą

Finansų sektoriuje rankinės alternatyvos gali būti ribotos dėl saugumo, duomenų vientisumo ir reguliacinių reikalavimų. Tačiau kai kurios funkcijos vis tiek gali būti palaikomos degradavusiu režimu: klientų informavimas, incidento registravimas, užklausų priėmimas, kritinių mokėjimų statuso sutikrinimas, portfelio duomenų apsauga, naujų operacijų laikinas stabdymas.

Praktinis klausimas BCP peržiūroje turėtų būti toks: ar žinome, ką darome, kai pagrindinė platforma neveikia, bet klientų apsauga vis tiek turi būti užtikrinta?

6 klaida. Tiekėjų rizika tik paminėta, bet nevaldoma

Finansų įstaigos dažnai priklauso nuo išorės tiekėjų: mokėjimų, KYC, debesijos, duomenų centrų, el. parašo, SMS, el. pašto, klientų aptarnavimo, kibernetinio saugumo, IT priežiūros ar programinės įrangos tiekėjų.

Dažna klaida — tiekėjų rizika plane tik paminima, bet nėra operaciškai suvaldoma.

Tinkamas BCP turi atsakyti į šiuos klausimus:

  • ar tiekėjas yra kritinis?
  • kokią paslaugą jis palaiko?
  • koks jo SLA?
  • koks eskalavimo kontaktas?
  • ar yra alternatyvus tiekėjas?
  • ką darome, jei tiekėjas neveikia 1 val., 4 val., 24 val.?
  • ar tiekėjo sutrikimas turi būti pranešamas klientams arba priežiūros institucijai?
  • ar tiekėjo paslauga buvo testuota veiklos tęstinumo scenarijuose?

Todėl BCP, kuriame parašyta tik „sutrikus tiekėjo veiklai kreipiamasi į tiekėją“, yra nepakankamas. Tai nėra scenarijus. Tai tik reakcijos pradžia.

7 klaida. Pamirštamas darbuotojų tęstinumas

BCP dažnai daug dėmesio skiria sistemoms, patalpoms ir tiekėjams, bet per mažai — žmonėms.

Finansų įstaigoje reikia įvertinti:

  • kritinių darbuotojų nepasiekiamumą;
  • pavaduojančių asmenų modelį;
  • „key person risk“;
  • nuotolinio darbo pasirengimą;
  • pandemijos ar plataus masto darbuotojų nebuvimo scenarijus;
  • prieigą prie sistemų dirbant ne iš biuro;
  • vadovybės ir krizės komandos pasiekiamumą ne darbo metu.

Kai kuriuose analizuotuose planuose nurodoma, kad už plano įgyvendinimą atsako vadovas, o jam negalint atlikti funkcijų paskiriamas kitas darbuotojas. Tai gera pradžia, bet brandžiam BCP to nepakanka. Reikia aiškios pavaduojančių asmenų, sprendimų priėmimo ir atsarginių kontaktų struktūros.

8 klaida. Supainiojamas krizės valdymas ir BCP vykdymas

BCP ir krizės valdymas nėra tas pats.

Krizės valdymo komanda priima strateginius sprendimus: ar stabdyti paslaugą, kada informuoti priežiūros instituciją, kaip komunikuoti su klientais, ar aktyvuoti alternatyvų veikimo režimą, kaip valdyti reputacinę riziką.

BCP vykdymo komandos įgyvendina konkrečius atkūrimo veiksmus: IT atkūrimą, klientų aptarnavimą, mokėjimų operacijų valdymą, tiekėjų eskalavimą, duomenų atkūrimą, komunikacijos išsiuntimą.

Brandesniame plane šios rolės turi būti atskirtos:

Lygmuo Pagrindinė funkcija
Krizės valdymo komanda Sprendimai, prioritetai, komunikacija, reguliacinis vertinimas
Incidentų valdymo komanda Incidento koordinavimas, techninis ir operacinis statusas
IT / ICT atkūrimo komanda Sistemų, duomenų, infrastruktūros atkūrimas
Verslo funkcijų komandos Minimalios paslaugos palaikymas, klientų procesai
Compliance / Legal / DPO Reguliaciniai, sutartiniai ir duomenų apsaugos vertinimai

Kai kurių finansų įstaigų brandesnio požiūrio požymių: plane yra atskiros dalys dėl incidentų valdymo, krizių valdymo, alternatyvaus veiklos organizavimo, sutrikimų registravimo, ataskaitų teikimo ir plano tobulinimo.

9 klaida. DPO ir BDAR scenarijai neįtraukti į BCP

Nors veiklos tęstinumo planas nėra vien duomenų apsaugos dokumentas, duomenų apsaugos pareigūno DPO vaidmuo jame neturėtų būti pamirštas.

Jeigu incidentas paveikia asmens duomenų konfidencialumą, vientisumą ar prieinamumą, tai gali būti ne tik IT problema, bet ir galimas asmens duomenų saugumo pažeidimas.

Praktikoje tai reiškia, kad šie scenarijai turi būti susieti su DPO / BDAR vertinimu:

  • klientų platforma nepasiekiama dėl duomenų bazės sutrikimo;
  • duomenys sugadinami arba atkuriami iš senesnės kopijos;
  • įvyksta neteisėta prieiga prie klientų paskyrų;
  • nuteka klientų, investuotojų ar paskolų gavėjų duomenys;
  • sutrinka duomenų tvarkytojo teikiama paslauga;
  • neaišku, ar duomenys buvo pakeisti, sunaikinti arba prarasti.

BDAR prasme svarbi vadinamoji CIA triada: konfidencialumas, vientisumas ir prieinamumas. Prieinamumo incidentas, pavyzdžiui, duomenų ar sistemos neprieinamumas, tam tikromis aplinkybėmis taip pat gali būti asmens duomenų saugumo pažeidimas.

DPO neturėtų būti paskiriamas atsakingu už visą BCP. Tai vadovybės, rizikos, IT, operacijų ir atitikties atsakomybės sritis. Tačiau DPO turi būti aiškiai įtrauktas į scenarijus, kuriuose veiklos sutrikimas gali tapti asmens duomenų saugumo pažeidimu ir gali reikėti vertinti BDAR 33–34 straipsnių pranešimo priežiūros institucijai bei duomenų subjektams poreikį.

10 klaida. BCP netestuotas realiais scenarijais

Metinė peržiūra nėra tas pats, kas testavimas.

Peržiūra atsako į klausimą, ar dokumentas atrodo aktualus. Testavimas atsako į klausimą, ar organizacija iš tikrųjų sugeba veikti pagal planą.

Testavimo scenarijus Ką tikrina
Platformos neprieinamumas Sprendimų priėmimą, klientų informavimą, IT atkūrimo prioritetus
Mokėjimų tiekėjo sutrikimas Eskalavimo kontaktus, alternatyvas, klientų operacijų valdymą
Duomenų bazės atkūrimas Ar realiai pasiekiamas RPO, ar atkuriami teisingi duomenys
Kibernetinė ataka Incidento valdymą, izoliavimą, komunikaciją, DPO ir saugumo funkcijų įtraukimą
Vadovo / kritinio darbuotojo nepasiekiamumas Pavaduojančių asmenų modelį
Tiekėjo neveikimas 24 val. Sutartines, operacines ir komunikacijos priemones

Teigiamai ekspertų vertintuose planuose nurodoma, kad planas reguliariai testuojamas ne rečiau kaip kartą per metus, o testavimo sunkumai dokumentuojami ir naudojami planui tikslinti. Tai yra geras požymis, tačiau praktikoje svarbu ne tik įrašyti testavimo pareigą, bet ir turėti testavimo scenarijus, rezultatų registrą, veiksmų planą ir pakartotinį patikrinimą.

Mini pavyzdys: kaip galėtų atrodyti BCP aktyvavimo eiga

Laikas nuo incidento Veiksmas Atsakingi asmenys
0–15 min. Patvirtinamas incidentas, nustatoma paveikta paslauga, įvertinama, ar tai kritinė ar svarbi funkcija IT / Incident Manager
15–30 min. Įvertinama, ar viršijami aktyvavimo kriterijai; sprendžiama dėl BCP aktyvavimo Incident Manager / vadovas
30–60 min. Sušaukiama krizės valdymo komanda; įvertinamas poveikis klientams, mokėjimams, duomenims, tiekėjams ir reguliaciniams terminams CMT, IT, Compliance, DPO
1–4 val. Įjungiamas atkūrimo, failover arba fallback scenarijus; parengiama klientų ir vidinė komunikacija IT, Operations, Comms
4–24 val. Stebimas atkūrimas, dokumentuojami sprendimai, vertinamas pranešimų priežiūros institucijoms ir klientams poreikis CMT, Compliance, Legal, DPO
Po atkūrimo Atliekama poincidentinė analizė, atnaujinamas BCP, taisomos spragos, planuojamas pakartotinis testas Vadovybė / BCM Owner

Tokia lentelė neturi pakeisti viso plano, bet ji parodo, ko dažnai trūksta formaliuose BCP: aiškios laiko sekos, atsakomybių ir sprendimų logikos.

Kaip turi atrodyti praktiškas finansų įstaigos BCP?

Praktiškas finansų įstaigos veiklos tęstinumo planas turėtų apimti bent šias dalis:

BCP dalis Ką ji turi atsakyti
Kritinių paslaugų sąrašas Kokias paslaugas būtina palaikyti ar atkurti pirmiausia
BIA Koks sutrikimo poveikis klientams, finansams, reguliacinei atitikčiai, reputacijai, IT ir duomenims
RTO / RPO / MTPD / MBCO matrica Per kiek laiko ir kokiu minimaliu lygiu atkuriamos paslaugos
ICT priklausomybių žemėlapis Kokios sistemos, duomenys, API, tiekėjai ir infrastruktūra palaiko kritines paslaugas
Failover / fallback scenarijai Kaip veikiama, jei pagrindinė sistema ar tiekėjas neveikia
Tiekėjų scenarijai Ką darome sutrikus mokėjimų, KYC, debesijos, hostingo ar IT tiekėjui
Krizių valdymo struktūra Kas aktyvuoja planą, kas vadovauja, kas pavaduoja, kas priima sprendimus
Komunikacijos matrica Kada ir kaip informuojami klientai, darbuotojai, tiekėjai, priežiūros institucija
Teisinių ir sutartinių įsipareigojimų ryšys Kokie įsipareigojimai negali būti pažeisti arba turi būti eskaluojami
DPO / BDAR scenarijai Kada vertinamas galimas asmens duomenų saugumo pažeidimas
Testavimo programa Kokie scenarijai testuojami, kaip registruojami rezultatai, kaip taisomi trūkumai
Incidento įrašai ir įrodymai Kaip dokumentuojami sprendimai, veiksmai, laikai, komunikacija ir atkūrimas

Toks planas nebūtinai turi būti ilgas. Priešingai — realiam naudojimui jis turi būti aiškus, struktūruotas ir greitai pritaikomas.

Konfidencialūs priedai, tokie kaip tiekėjų kontaktai, infrastruktūros detalės, slapti techniniai duomenys ar eskalavimo kontaktai, neturėtų būti viešinami. Viešai skelbiama versija gali būti santrauka arba redaguotas dokumentas, tačiau vidinė versija turi būti operacinė.

Kokią žalą sukelia netinkamai parengtas BCP?

Žalos kategorija Praktinis poveikis
Klientų žala Klientai negali naudotis paslaugomis, matyti lėšų, vykdyti mokėjimų, gauti informacijos
Operacinė žala Sustabdomos kritinės paslaugos, stringa paskolų, investicijų, mokėjimų ar portfelio administravimas
Duomenų ir IT žala Prarandami, sugadinami arba laiku neatkuriami duomenys; neveikia sistemos ar integracijos
Reguliacinė žala Vėluojama informuoti priežiūros instituciją, neįrodoma, kad planai testuoti ir veikė
Teisinė / sutartinė žala Pažeidžiami įsipareigojimai klientams, partneriams, tiekėjams ar paslaugų naudotojams
Finansinė žala Patiriami atkūrimo kaštai, kompensacijos, negautos pajamos, klientų praradimas
Reputacinė žala Prarandamas klientų, partnerių ar priežiūros institucijų pasitikėjimas
Valdymo žala Sprendimai vėluoja, neaišku, kas atsakingas, trūksta incidento įrodymų

Būtent todėl BCP turi būti kuriamas ne kaip „dokumentas patikrinimui“, o kaip reali veikimo sistema.

Kokias klaidas verta pasitikrinti vadovybei?

Finansų įstaigos vadovybei verta užduoti kelis paprastus klausimus:

  • Ar žinome, kokios paslaugos yra kritinės arba svarbios?
  • Ar kiekvienai jų nustatytas RTO ir RPO?
  • Ar žinome, kokios IT sistemos palaiko tas paslaugas?
  • Ar turime tiekėjų eskalavimo kontaktus ir SLA?
  • Ar aišku, kada aktyvuojamas BCP?
  • Ar turime rankines ar alternatyvias procedūras, kol sistema neatkurta?
  • Ar planas buvo testuotas realiu scenarijumi?
  • Ar aišku, kas informuoja klientus?
  • Ar aišku, kada įtraukiamas DPO?
  • Ar žinome, kurie klientų, partnerių ir priežiūros institucijų įsipareigojimai gali būti pažeisti incidento metu?
  • Ar galėtume pagal planą veikti ne rytoj, o dabar?

Jeigu į bent kelis iš šių klausimų atsakymas yra „ne“ arba „reikėtų pasitikslinti“, BCP greičiausiai yra per daug formalus.

FAQ: dažniausi klausimai apie finansų įstaigos BCP

Kas yra finansų įstaigos veiklos tęstinumo planas?

Finansų įstaigos veiklos tęstinumo planas — tai dokumentuotas veiksmų planas, pagal kurį įstaiga veikia sutrikus kritinėms paslaugoms, IT sistemoms, mokėjimams, tiekėjams, patalpoms, darbuotojų prieinamumui ar kitiems svarbiems veiklos elementams.

Jo tikslas — apsaugoti klientus, lėšas, duomenis, paslaugų tęstinumą, sutartinius įsipareigojimus ir reguliacinę atitiktį.

Kuo BCP skiriasi nuo DRP?

BCP yra platesnis verslo veiklos tęstinumo planas. Jis apima žmones, procesus, paslaugas, klientus, tiekėjus, komunikaciją, reguliacinius įsipareigojimus ir IT.

DRP — angl. Disaster Recovery Plan — paprastai yra labiau techninis IT atkūrimo planas: kaip atkuriamos sistemos, duomenys, infrastruktūra, atsarginės kopijos ir techninės paslaugos.

Finansų įstaigoje BCP ir DRP turi būti susieti.

Ar DORA reikalauja turėti BCP?

DORA reikalauja, kad finansų subjektai turėtų ICT veiklos tęstinumo politiką, reagavimo ir atkūrimo planus, testavimo mechanizmus, incidentų valdymą ir priemones kritinių ar svarbių funkcijų tęstinumui užtikrinti.

Todėl DORA kontekste nepakanka turėti bendrą BCP. Reikia, kad veiklos tęstinumas būtų susietas su ICT rizikos valdymu, sistemų atkūrimu, tiekėjų rizika ir testavimu.

Ar BCP turi būti viešai skelbiamas?

Ne visoms finansų įstaigoms galioja vienodas reikalavimas viešai skelbti visą BCP. Kai kurių finansų sektoriaus dalyvių praktikoje viešai skelbiamos BCP santraukos arba redaguotos versijos, ypač kai tai susiję su klientų pasitikėjimu ir licencijavimo dokumentais.

Tačiau operacinė BCP versija dažnai turi konfidencialių priedų: kontaktus, tiekėjų eskalavimo duomenis, infrastruktūros informaciją, sistemų architektūrą, atkūrimo detales. Tokie priedai neturėtų būti viešinami.

Ar DPO turi būti įtrauktas į veiklos tęstinumo planą?

Taip, bet ne kaip viso BCP savininkas. DPO turi būti įtrauktas į tuos scenarijus, kuriuose sutrikimas gali paveikti asmens duomenų konfidencialumą, vientisumą ar prieinamumą.

Tai ypač aktualu, kai sutrinka klientų platforma, prarandami ar sugadinami duomenys, įvyksta neteisėta prieiga arba kyla poreikis vertinti pranešimus pagal BDAR 33–34 straipsnius.

Kaip dažnai reikia testuoti BCP?

Brandžioje praktikoje BCP turi būti testuojamas reguliariai, neapsiribojant vien metine dokumento peržiūra. Finansų įstaigai rekomenduotina atlikti stalo pratybas, IT atkūrimo testus, tiekėjų sutrikimo scenarijus, kibernetinės atakos scenarijus ir klientų komunikacijos testus.

Po kiekvieno testo turėtų būti parengtas trūkumų sąrašas, veiksmų planas, atsakingi asmenys ir terminas, kada trūkumai bus pašalinti.

Išvada

Finansų įstaigos veiklos tęstinumo planas neturėtų būti dokumentas stalčiui. Jis turi būti praktinis veikimo vadovas, kuris padeda apsaugoti klientus, lėšas, duomenis, sutartinius įsipareigojimus, reguliacinę atitiktį ir įstaigos reputaciją.

Dažniausia problema nėra ta, kad finansų įstaigos apskritai neturi veiklos tęstinumo plano. Problema ta, kad dalis planų yra per bendri: jie aprašo rizikas, bet ne veiksmus; mini IT sutrikimus, bet nesusieja jų su verslo paslaugomis; nurodo tiekėjus, bet neturi tiekėjo sutrikimo scenarijaus; kalba apie tęstinumą, bet nenustato RTO, RPO, MTPD ir minimalaus paslaugos lygio.

Geras BCP turi sujungti keturis dalykus: kritines paslaugas, ICT sistemas, klientų interesus ir sprendimų priėmimą laike.

Tik tada veiklos tęstinumo planas tampa ne formaliu atitikties dokumentu, o realia finansų įstaigos atsparumo priemone.

Ar jūsų veiklos tęstinumo planas veiktų realaus incidento metu?

Atliekame finansų įstaigų BCP / BCM atotrūkio vertinimą pagal ISO 22301, DORA, ICT veiklos tęstinumo, tiekėjų rizikos, klientų įsipareigojimų, BDAR incidentų ir praktinio testavimo kriterijus.

Peržiūros metu įvertiname ne tik tai, ar dokumentas egzistuoja, bet ir tai, ar pagal jį būtų galima veikti realiame incidente: aktyvuoti planą, apsaugoti klientus, atkurti kritines paslaugas, įtraukti tiekėjus, dokumentuoti sprendimus ir pagrįsti veiksmus priežiūros institucijai.

Galime padėti:

  • atlikti BCP / BCM atotrūkio vertinimus;
  • įvertinti DORA readiness;
  • sudaryti RTO / RPO / MTPD / MBCO matricas;
  • parengti kritinių paslaugų ir ICT priklausomybių žemėlapį;
  • parengti tiekėjų sutrikimo scenarijus;
  • parengti platformos neveikimo ar kibernetinės atakos scenarijus;
  • organizuoti BCP stalo pratybas;
  • integruoti DPO / BDAR incidentų scenarijus į veiklos tęstinumo planą.

Reikalinga praktinių klausimų lentelė prieš išsamų BCP/BCM ir IRT atsparumo trūkumų vertinimą?

Prisijunkite prie savo paskyros, kad galėtumėte parsisiųsti arba susisiekite su mumis el. paštu iš savo įmonės el. pašto ir mes Jums atsiųsime DORA veiklos tęstinumo (BCP) kontrolinį sąrašą (checklist) vadovybei.

Šis klausimynas skirtas finansų sektoriaus subjektų (ir jiems kritinių IRT paslaugų teikėjų) vadovybei greitai įsivertinti, ar organizacijos veiklos tęstinumo ir informacinių bei ryšių technologijų (IRT) atsparumo struktūra atitinka pagrindinius Skaitmeninės veiklos atsparumo reglamento (DORA, Reglamentas (ES) 2022/2554) lūkesčius.

Susisiekime

DORA veiklos tęstinumo (BCP) kontrolinis sąrašas vadovybei
Rizikų eksperto patarimai Veiklos tęstinumo eksperto praktika