Nəzarət altındakı qurumda governance-ın adi governance-da olmayan bir tələbi var: hər nəzarət aylar sonra üçüncü tərəfin yoxlaya biləcəyi sübut istehsal etməlidir. Məhz bu bir məhdudiyyət dizaynı dəyişir. Siz işləyən sistem qurmursunuz — konkret tarixdə işlədiyini göstərmək mümkün olan sistem qurursunuz.

Bundan yeddi təcrübə çıxır və hər biri çərçivəyə görə yox, müfəttişin sualına görə yoxlanıla bilir.

Nəzarət altında governance-ın fərqi nədir?

Üç fərq var və onlar bir-birini gücləndirir.

Sübut yükü tərsinə çevrilir. Nəzarət altında olmayan təşkilatda nəzarət nəsə pozulana qədər adekvatdır. Nəzarət altında isə sübut edilənə qədər qeyri-adekvatdır. Artefakt buraxmayan mükəmməl icra olunmuş giriş baxışı baş verməyib.

Əhatə kənardan diktə olunur. Hansı datanın kritik olduğunu siz seçmirsiniz; tənzimləyicinin hesabat tələbləri seçir. Bu, əslində faydalıdır — governance-dakı ən çətin mübahisəni, prioritetləşdirməni aradan qaldırır.

Vaxt qrafiki sabitdir. Yoxlama dövrləri proqramın hazır olub-olmamasından asılı olmayaraq gəlir; bu isə adi müəssisələrin müzakirə edə bildiyi, nəzarət altındakı qurumların isə edə bilmədiyi şəkildə «dar və tam» yanaşmanı «geniş və yarımçıq» yanaşmadan üstün edir.

Azərbaycanda maliyyə qurumları üçün dayaq nöqtəsi Mərkəzi Bankın 2022-ci ilin aprelindən qüvvədə olan və ISO/IEC 27000 seriyası üzərində qurulmuş Banklarda informasiya təhlükəsizliyinin idarə edilməsi haqqında Qaydaları, həmçinin Şəxsi məlumatlar haqqında Qanun və onun şəxsi məlumatları emal edən informasiya sistemləri üçün nəzərdə tutduğu qeydiyyat rejimidir.

Təcrübə 1 — hər nəzarəti sübut buraxacaq şəkildə dizayn edin

Təcrübə belədir: hər nəzarət üçün dizayn mərhələsində qərar verin ki, o hansı artefaktı istehsal edir, artefakt harada saxlanılır və nə qədər müddətə saxlanılır. Cavab «lazım olsa bərpa edərik»dirsə, nəzarət auditə hazır deyil.

Konkret olaraq bu belə görünür. Giriş baxışı görüş deyil — kimin girişi olduğunu, kimin baxdığını, nəyin ləğv edildiyini və səbəbini göstərən tarixli qeyddir. Tərifin təsdiqi konsensus deyil — təsdiqləyəni, tarixi və əsaslandırması olan glossary yazısıdır. Keyfiyyət istisnası düzəldilmiş sətir deyil — pozuntunu, qərarı, qərarı verən adamı və nəticəni göstərən tapşırıqdır.

Bunu əvvəldən etməyin əlavə xərci kiçikdir. Yoxlamadan iki həftə əvvəl geriyə doğru qurmağın qiyməti isə banklarda governance təlaşının ən çox rast gəlinən mənbəyidir.

Təcrübə 2 — tətbiqi təsnifat idarə etsin

Təcrübə belədir: data aktivlərini bir dəfə təsnifləndirin və maskalama, saxlama müddəti, giriş təsdiqi marşrutu və rezidentlik təsnifatdan mexaniki olaraq çıxsın — hər sistemdə onu quran adamın qərarı ilə yox.

Uğursuzluq forması budur: təsnifat sxemi siyasət sənədində yaşayır, tətbiq isə hər platformada ayrıca qurulur. Onlar ayrılanda — və həmişə ayrılır — müfəttişin oxuduğu təsnifat, reallığı idarə edən isə tətbiqdir.

Praktiki tələb budur ki, təsnifat platformaların oxuya biləcəyi yerdə yaşasın. Təsnifatı aktivin atributu kimi saxlayan catalog və həmin atributu istehlak edən platformalar — ikisini uyğun saxlayan quruluş budur. Bu, sənəd anbarı yerinə avtomatlaşdırılmış catalog seçməyin konkret səbəblərindən biridir: təsnifat abzas yox, maşın oxuya bilən fakt olmalıdır.

Təcrübə 3 — hesabat göstəriciləri üçün lineage sütuna qədər getsin

Təcrübə belədir: nəzarət hesabatında görünən hər göstərici üçün mənbə sistemindən hər çevrilmə mərhələsindən keçərək hesabatdakı rəqəmə qədər sütun səviyyəli lineage saxlayın.

Bu, tənzimlənən qurumda ən yüksək dəyərli governance artefaktıdır və səbəbini demək lazımdır. Müfəttiş göstəricinin necə hesablandığını soruşanda mövcud cavablar bunlardır: bir adamın yaddaşı, proses qurulanda yazılmış sənəd, ya da real koddan və sorğu tarixçəsindən yaradılmış lineage qrafiki. İlk ikisi tez-tez səhv olur — vicdansızlıqdan yox, proses dəyişdiyi, sənəd isə dəyişmədiyi üçün.

Avtomatik lineage-in gündəlik işdə daha vacib olan ikinci faydası da var: dəyişiklik istehsalata çıxmazdan əvvəl təsir təhlili. Mənbə sütununun tipindəki dəyişiklik yenidən dərcdən sonra edilən kəşf yox, təsirlənən hesabatların görünən siyahısına çevrilir.

Əhatəni dar saxlayın. Bütün mühit üzrə sütun səviyyəli lineage bahalıdır və lazım deyil; hesabat göstəriciləri üzrə isə yoxlamanı sadə edən şey elə odur.

Təcrübə 4 — giriş baxışları dövri və sabit artefaktlı olsun

Təcrübə belədir: hər həssas aktiv üzrə qrafikli baxış, adlı baxıcı və qərarların tarixli qeydi.

Bunun davamlı olub-olmamasını üç detal həll edir.

Baxıcı İT yox, biznes sahibi olmalıdır. Kimin girişi olduğunu İT deyə bilər; bunun hələ də uyğun olub-olmadığını yalnız biznes deyə bilər.

Defolt ləğv olmalıdır. Baxılmamış girişin qaldığı baxış baxış deyil. Heç kimin təsdiqləmədiyi giriş öz-özünə bitməlidir.

Dövr təqvimə yox, həssaslığa uyğun olmalıdır. Ən həssas aktivlər üçün rüblük, qalanlar üçün illik. Hər şey üzrə vahid illik dövr heç kimin düzgün etməyə vaxtı olmayan baxış doğurur.

Bunu işlək edən rol bölgüsü — owner cavabdeh, steward məsləhətçi, custodian icraçı — data stewardship rolları və işlək RACI məqaləsində açılıb.

Təcrübə 5 — saxlama və silmə həqiqətən icra olunsun

Təcrübə belədir: təsnifat üzrə müəyyən edilmiş saxlama müddətləri avtomatik işlər kimi tətbiq olunur və silmə jurnal yazısı buraxır.

Tənzimlənən qurumlarda kağız siyasətin olub mexanizmin olmadığı yer ən çox buradır. Siyasət deyir ki, münasibət bitəndən sonra müştəri qeydləri müəyyən müddət saxlanılır; reallıqda heç nə silinmir, çünki silmək risklidir və heç kim bunun üçün mükafatlandırılmır.

Nəticə yalnız uyğunsuzluq deyil. Məqsədini yaşamış datanın saxlanması hər insidentin partlayış radiusunu genişləndirir və hər yoxlamanın əhatəsini böyüdür.

VERIFY: Azərbaycanda maliyyə və şəxsi məlumatlar üçün saxlama müddətləri bir neçə sənəddə müəyyən olunur — sahə üzrə bank qaydaları, Şəxsi məlumatlar haqqında Qanun və arxiv qanunvericiliyi — və tətbiq olunan müddət qeydin növündən asılıdır. Konkret müddətləri avtomatik silmə işlərinə kodlaşdırmazdan əvvəl hüquq məsləhətçisi ilə dəqiqləşdirin.

Mühəndislik məqamı konkret müddətlərdən asılı olmayaraq qüvvədə qalır: silmə heç kimin icra etmədiyi əl işi yox, jurnalı olan qrafikli mexanizm olmalıdır.

Təcrübə 6 — datanı change control-a daxil edin

Təcrübə belədir: sxem dəyişiklikləri, çevrilmə məntiqindəki dəyişikliklər və giriş modelindəki dəyişikliklər tətbiq relizləri ilə eyni change control prosesindən keçir və təsdiqin bir hissəsi kimi data təsiri qiymətləndirilir.

Qurumların çoxunda tətbiqlər üçün yetkin change control var, data üçün isə yoxdur. Mənbə sistemində sütunun tipini dəyişən developer sənədləşdirilmiş reliz prosesinə əməl edir; həmin dəyişikliyin səssizcə üç tənzimləyici hesabatı sındırması isə sonradan aşkarlanır.

Lineage mövcud olandan sonra mexanizm sadədir: dəyişiklik sorğusuna aşağı axındakı təsir siyahısı əlavə olunur və təsirlənən hesabat sahibləri dəyişiklik çıxmazdan əvvəl razılaşır və ya etiraz edir. Lineage olmadan bu, komandaların son tarix təzyiqi altında atladığı əl araşdırmasıdır.

Təcrübə 7 — bir nəzarət dəstini bir çox tənzimləməyə xəritələyin

Təcrübə belədir: nəzarətləri bir dəfə tətbiq edin və hər nəzarətdən onun ödədiyi hər tənzimləyici tələbə xəritə saxlayın.

Aİ müştərilərinə xidmət edən Azərbaycan bankı eyni anda Mərkəzi Bankın informasiya təhlükəsizliyi tələbləri, Şəxsi məlumatlar haqqında Qanun, ekstraterritorial əhatəsi tətbiq olunduğu hallarda GDPR və — AI sistemləri işə salırsa — ISO/IEC 42001-in idarəetmə sistemi gözləntiləri ilə üzləşə bilər; sonuncunun doqquz məqsəd altındakı 38 Annex A nəzarəti isə ISO 27001 ilə əhəmiyyətli dərəcədə üst-üstə düşür.

Bunları ayrı-ayrı proqramlar kimi tətbiq etmək təkrarlanan nəzarətlər, bir-birinə zidd sənədləşmə və rejimlərin sayı ilə xətti artan yoxlama yükü doğurur. Xəritəsi olan vahid nəzarət dəsti isə hər yeni rejimi proqram yox, boşluq təhlili edir.

Xəritənin özü auditorların ən çox dəyər verdiyi nəticədir, çünki «X tələbini necə ödədiyinizi göstərin» sualına bir baxışla cavab verir. Bunun AI idarəetmə sistemi üçün necə işlədiyi ISO/IEC 42001 auditinin əslində nə tələb etdiyi, sərhədlərarası tərəfi isə Azərbaycanda data rezidentliyi və şəxsi məlumat qanunu məqaləsindədir.

Müfəttişlər əslində nə istəyir?

Layihələr üzrə suallar beş nöqtədə cəmlənir və onları əvvəlcədən məşq etməyə dəyər:

Bu dataya kimin girişi var və sonuncu dəfə nə vaxt baxılıb? Cavabı giriş baxışının artefaktıdır.

Bu hesabat göstəricisi necə hesablanıb? Cavabı sütun səviyyəli lineage-dir.

Təsnifatınızı və bu aktivin orada yerini göstərin. Cavabı siyasət sənədi yox, catalog-dakı atributdur.

Bu dataya ehtiyac qalmayanda nə baş verir? Cavabı saxlama işi və onun jurnalıdır.

Bu dataya görə kim cavabdehdir? Cavabı sahiblik qeydidir — və ən tez-tez yaxşı cavabı olmayan sual budur, çünki sahiblik şəxsə yox, komandaya verilib.

Bu beşinə bir günortada cavab verə bilən proqram yetkinlik balından asılı olmayaraq yaxşı mövqedədir. Sual başına bir həftə hazırlıq tələb edən proqramın isə governance yox, sənədləşdirmə problemi var — bunlar fərqli düzəlişlərdir və ən çox rast gəlinən data governance çətinlikləri məqaləsində açılıb.

Əsas məqamlar

  • Nəzarət altında sübutu olmayan nəzarət baş verməyib. Hər nəzarətin hansı artefaktı buraxdığını dizayn mərhələsində qərara alın.
  • Təsnifat siyasətdəki abzas yox, maskalama, saxlama və girişi idarə edən maşın oxuya bilən atribut olmalıdır.
  • Sütun səviyyəli lineage-i konkret olaraq hesabat göstəriciləri üçün saxlayın. Bütün mühit üzrə lineage bahalıdır və nadir hallarda lazımdır.
  • Giriş baxışlarına biznes baxıcısı, defolt olaraq ləğv və həssaslığa uyğun dövr lazımdır.
  • Saxlama və silmə jurnalı olan qrafikli işlər kimi icra olunmalıdır. Tətbiq olunan müddətləri hüquq məsləhətçisi ilə dəqiqləşdirin.
  • Sxem, çevrilmə və giriş dəyişikliklərini lineage-dən çıxan təsir siyahısı ilə birlikdə change control-dan keçirin.
  • Bir nəzarət dəsti tətbiq edin və onu hər rejimə xəritələyin. Auditorların ən çox dəyər verdiyi artefakt həmin xəritədir.

Yukon Labs nəzarət altındakı qurumlarda OvalEdge tətbiqini təsnifat, lineage və giriş baxışı əvvəldən sübut istehsal edən nəzarətlər kimi konfiqurasiya edilmiş halda həyata keçirir. Yoxlama dövründən əvvəl kənardan baxış lazımdırsa, data və AI hazırlıq qiymətləndirməsi yuxarıdakı beş sualı birbaşa yoxlayır. Regional çərçivə üçün Azərbaycanda data governance məqaləsinə baxın.