Warszawa, 17 lutego 2011 roku

UWAGI Polskiej Izby Informatyki i Telekomunikacji [ PIIT]

w konsultacjach spoecznych w sprawie projektu Rozporzdzenia Rady Ministrw w sprawie Krajowych Ram Interoperacyjnoci, minimalnych wymagao dla rejestrw publicznych i wymiany informacji w formie elektronicznej oraz minimalnych wymagao dla systemw teleinformatycznych (projekt z dnia 10 lutego 2011 roku)
Polska Izba Informatyki i Telekomunikacji [PIIT] przedstawia ponisze uwagi do projektu rozporzdzenia z dnia 10 lutego 2011:

1. Par 2
Pkt 1) termin aktywa jest uyty tylko raz w tekcie rozporzdzenia, w par 2 pkt 5) proponujemy skasowanie tego punktu, a w pkt 5) uyd sowa zasoby; Pkt 3) definicja terminu autentycznod wzbudza dyskusje, gdy nie jest w peni zgodna z polsk norm PN200-I-2001 lub te nie opisuje tego, co ma opisywad. Moe, bowiem bardziej chodzid o jedno z dwch pojd: (a) uwierzytelnienie lub (b) identyfikacj podmiotu lub zasobu w postaci obiektu zgodnie z deklaracj a istniejcego w systemie teleinformatycznym, a nie o sam rzeczywisty podmiot czy zasb. Propozycja PIIT: niezbdna jest autopoprawka MSWiA. Pkt 5) termin dokadnod wydaje si byd niejasny... Proponujemy brzmienie: integralnod waciwod polegajca na zapewnieniu spjnoci i kompletnoci zasobw. W tym sensie sowo spjnod odpowiada angielskiemu consistency, czyli brakowi sprzecznoci. W przypadku systemu informatycznego oznaczad to bdzie w praktyce, e na dane zapytanie zawsze zostanie udzielona ta sama odpowied. Pkt 6) termin interesariusz uyty dalej tylko raz w tekcie rozporzdzenia proponujemy go pomind, natomiast w par 5 ust 2 pkt 3) bd pozostawid sowo interesariusz bez odwoywania si do terminu (proponowany termin jest zgodny z kolokwialnym pojmowaniem sowa interesariusz, wic nie musi byd dodatkowo tumaczony) lub te zamiast sowa interesariusz wprowadzid odpowiedni opis (patrz take uwaga 8.). Pkt 14) Proponujemy czytelniejszy zapis podmiot osob prawn, lub jednostk organizacyjn nieposiadajc osobowoci prawnej, lub organ administracji publicznej. Uycie lub wskazuje, e moe to byd jedna z przedstawionych w definicji form.

Uwagi PIIT do projektu Rozp. RM w sprawie Krajowych Ramach Interoperacyjnoci

Strona 1

Nowy punkt: Proponujemy zapis: polityki bezpieczeostwa - zestaw efektywnych, udokumentowanych zasad i procedur bezpieczeostwa, wraz z ich planem wdroenia i egzekwowania Uzasadnienie: W paragrafie 14 co najmniej dwukrotnie pojawia si pojcie polityka bezpieczeostwa, ktre naszym zdaniem wymaga zdefiniowania.

2. Par 3. Ust 1.
Proponujemy w definicji wprost odnied si do definicji interoperacyjnoci zapisanej w ustawie o informatyzacji (art. 3 punkt 18). Dlatego proponujemy brzmienie nastpujce: Krajowe Ramy Interoperacyjnoci stanowi zbir uzgodnionych definicji, wymagao, regu architektury systemw teleinformatycznych oraz procedur i zasad, ktrych stosowanie umoliwi rnym podmiotom oraz uywanym przez nie systemom teleinformatycznym i rejestrom publicznym wspdziaanie na rzecz osignicia wzajemnie korzystnych i uzgodnionych celw, z uwzgldnieniem wspdzielenia informacji i wiedzy przez wspierane przez nie procesy biznesowe realizowane za pomoc wymiany danych za porednictwem wykorzystywanych przez te podmioty systemw teleinformatycznych

3. Par 3. Ust 1. Pkt 1)

Proponujemy zamiast podmiotom gospodarczym wszdzie uyd zdefiniowanego w par. 1 pojcia podmiot; ta sama uwaga przy zapisie podmiot publiczny. Podpunkt c) i d) czy ten zapis jest potrzebny? Przy tak poszerzonych celach interoperacyjnoci mona zgubid zasadniczy cel, jaki jest zapisany w ustawie... Cele c) i d) s celami dla caej administracji, a nie dla interoperacyjnoci. Porwnaj uwaga 1 do par 2 pkt 14)

4. Par 3. Ust 1.
Brakuje zapisu dotyczcego realizacji usug ponadgranicznych, ktry powinien byd take celem dla KRI. Proponujemy nastpujcy zapis: g) efektywna realizacja drog elektroniczn ponadgranicznych usug administracji publicznej Uzasadnienie: Dziki takiemu zapisowi Rzd RP bdzie mg wykazad si realizacj zadao nakrelonych w grudniu 2010 przez e-Government Action Plan z 15 grudnia 2010, a konkretnie 2.2.3 oraz 2.4.1. Byd moe bdzie pierwszym rzdem wrd krajw czonkowskich, ktry wykona oczekiwane zalecenie zgrania Europejskich Ram Interoperacyjnoci z Krajowymi Ramami Interoperacyjnoci przynajmniej w podstawowym zakresie.

Uwagi PIIT do projektu Rozp. RM w sprawie Krajowych Ramach Interoperacyjnoci

Strona 2

5. Par 3 ust 2 punkt 2)

Proponujemy w tekcie tego punktu odwoad si nie tylko do art 13 ust 2 pkt 1 i art 18 punkt 1) podpunkt c) mwicego o zasadach rwnego traktowania rnych rozwizao informatycznych, ale take do zawartej w ustawie doskonaej definicji neutralnoci technologicznej (patrz take art 1 punkt 2), 3) i 4) ustawy o informatyzacji!!!) oraz art 3. Punkt 19). Brzmienie tego punktu: Opcja 1 (z zachowaniem dotychczasowej propozycji): (...) z zapewnieniem zasady neutralnoci technologicznej i rwnego traktowania rnych rozwizao informatycznych. Opcja 2 (tylko neutralnod technologiczna): (...) z zapewnieniem zasady neutralnoci technologicznej. Uzasadnienie: pojcie neutralnoci technologicznej zdefiniowane w ustawie zawiera ju nakaz rwnego traktowania rnych rozwizao informatycznych, a jest szersze. Std sugestia zastosowania tego wanie pojcia!

6. Par 4 ust. 1 pkt 1)

Propozycja: 1) ujednolicenie, rozumiane, jako zastosowanie sprztu oraz oprogramowania o tej samej architekturze i funkcjonalnoci i tych samych standardw, polityk, procedur i norm przez rne podmioty realizujce zadania publiczne; Uzasadnienie: Ujednolicenie rozumiane, jako m.in. zastosowanie tego samego typu sprztu jest posunite zbyt daleko. Dostatecznym opisem sytuacji jest zastosowanie sprztu oraz oprogramowania o tej samej architekturze i funkcjonalnoci.

7. Par 4 ust. 3
Analogicznie do propozycji przedstawionej powyej w pkt 5 i dotyczcej par 3 punkt 2)

Uwagi PIIT do projektu Rozp. RM w sprawie Krajowych Ramach Interoperacyjnoci

Strona 3

8. Par 5 ust. 2 punkt 3) Par 5 ust. 3 punkt 1) Par 5 ust. 4 punkt 2) Par 7 ust. 2 punkt 2) Patrz take: uzasadnienie do rozporzdzenia
W Par. 5 pojawia si pojcie rekomendacji i ich stosowania. W uzasadnieniu pojawiaj si nastpujce zapisy (podkrelenie PIIT): Pierwszy: Rekomendacje s dynamiczn czci Krajowych Ram Interoperacyjnoci. Ich stosowanie przez podmioty realizujce zadania publiczne powinno byd obligatoryjne w obszarze interfejsw czcych systemy informatyczne rnych podmiotw. Wewntrz systemu rekomendacje takie nie musz obowizywad, jednak racjonalne wydaje si stosowanie rozwizao proponowanych przez rekomendacje i w tym obszarze. Z uwagi na to, e delegacja ustawowa nie sytuuje adnego organu koordynujcego osiganiem interoperacyjnoci, jedynym rozwizaniem pozostaje przypisanie funkcji koordynacyjnych w tym zakresie ministrowi waciwemu do spraw informatyzacji. Takie podejcie wynika z przepisu art. 12a ustawy z dnia 4 wrzenia 1997 r. o dziaach administracji rzdowej. Drugi: Podstawowym narzdziem sucym uzyskaniu interoperacyjnoci s rekomendacje interoperacyjnoci. Naley zdawad sobie spraw, e czd tych rekomendacji pozostanie poza wpywem polskiej legislacji, jednak ich przyjcie jest nieuniknione z uwagi na ponadnarodowy charakter takich bytw jak chodby Internet. Zatem standardy i normy dotyczce takich bytw ustalane przez organizacje, ktrych kompetencje wynikaj nie z normy prawnej, a z powszechnie i nieformalnie przyjtej zgody nie mog zostad pominite. Jednoczenie ju dod dawno w dziedzinie produkcji i wiadczenia usug zauwaono, e efekt synergii dziaao rnych podmiotw uczestniczcych w danym rynku, mimo wystpujcej konkurencyjnoci, moliwy jest do uzyskania przy wsplnej zgodzie zainteresowanych stron, co do przyjmowanych standardw. Podobnie w przypadku interoperacyjnoci efekt synergii dziaao podmiotw realizujcych zadania publiczne moliwy jest do uzyskania, gdy rekomendacje interoperacyjnoci zostan wypracowane nie w sposb nakazowy, a w drodze szerokiego konsensusu. Wane jest jednak, aby stworzone zostay instytucjonalne ramy dla takich uzgodnieo oraz aby uzgodnienia byy atwo dostpne. Temu celowi suy umocowanie ministra waciwego do spraw informatyzacji do zarzdzania ustalaniem rekomendacji interoperacyjnoci i publikowania tyche uzgodnieo. Moliwod takiego umocowania nie wynika, co prawda explicite z delegacji art. 18 ustawy, niemniej implikowana jest ona zadaniami, jakie posiada minister waciwy do spraw informatyzacji na podstawie art. 12a pkt. 4 ustawy z dnia 4 wrzenia 1997 r. o dziaach administracji rzdowej.

Uwagi PIIT do projektu Rozp. RM w sprawie Krajowych Ramach Interoperacyjnoci

Strona 4

Niestety zarwno z zapisu w/w paragrafw, jak i z treci uzasadnienia wynika intencja wprowadzenia prawa powielaczowego. Minister waciwy ds informatyzacji w procesie, ktry nie jest sformalizowany (jak chodby dyskusja nad niniejszym rozporzdzeniem) i nie podlega adnej kontroli prcz enigmatycznego wypracowania w jawnym i otwartym procesie uzgodnieo z moliwie szerokim gronem interesariuszy moe dowolnie ksztatowad zasady dotyczce interoperacyjnoci skutecznie zaprzeczajce treci rozporzdzenia. Co wicej, bardzo wyranie zostao zapisane obligatoryjne korzystanie z rekomendacji (na razie w zakresie interfejsw, ale przecie tak wanie dziaa prawo powielaczowe na pocztku tylko niewielka czd, a potem cige powikszanie zakresu dziaania)! Na takie traktowanie zagadnieo interoperacyjnoci nie moe byd zgody. Nasze propozycje: Par 5 ust 2 punkt 3) skrelid (patrz take uwaga 1 definicja interesariusz) Par 5 ust 3 punkt 1) w brzmieniu: stosowanie struktur danych i znaczenia danych zawartych w tych strukturach, okrelonych w niniejszym rozporzdzeniu (Zacznik 1) Par 5 ust 4 punkt 2) skrelid. Niestety ten punkt jest tak niejasny i daje tak dowolnod interpretacji, e nie powinien si utrzymad. Natomiast par 7 ust 2 proponujemy w brzmieniu: Minister waciwy do spraw informatyzacji moe publikowad rekomendacje interoperacyjnoci organizacyjnej i semantycznej, ktrych stosowanie nie jest obligatoryjne Oraz dodad par 7 ust 3 w brzmieniu: Rekomendacje, o ktrych mowa powyej s wypracowywane w jawnym i otwartym procesie z zachowaniem zasady neutralnoci technologicznej i rwnego traktowania rnych rozwizao informatycznych. Uzasadnienie naszej propozycji: Jest dobr praktyk publikowanie rekomendacji. Rekomendacje z natury rzeczy chod zostay w propozycji wpisane w sposb sugerujcy ich obligatoryjne uycie, za w uzasadnieniu wprost mwi si o ich obligatoryjnym stosowaniu maj charakter wskazwki, sugestii, propozycji, natomiast ich egzekwowanie bdzie bardzo utrudnione. Dotyczy to zarwno organw kontrolnych ze strony administracji, jak te ze strony podmiotw kontaktujcych si z administracj. Rekomendacje w takiej formie jak proponowane (obligatoryjne, dowolnie zmieniane) nie maj umocowania w sensie kontroli finansowej procesw wdraania e-administracji. Po pierwsze, poniewa kady minister waciwy do spraw informatyzacji moe zmieniad rekomendacje w dowolnej chwili. Po drugie, zmiana rekomendacji nie wymaga wskazania budetu, z ktrego pokryje si te zmiany (zmiana rozporzdzenia wymaga takiej analizy). Moe to prowadzid do nadmiaru pracy, frustracji pracownikw, a nawet wrcz do nieuzasadnionych wydatkw z budetu.

Uwagi PIIT do projektu Rozp. RM w sprawie Krajowych Ramach Interoperacyjnoci

Strona 5

Inne jednostki administracji (np. ministerstwa) w trakcie przygotowywania aktw bdcych w ich gestii musz si kierowad zapisami ustaw i rozporzdzeo dot. Informatyzacji, natomiast rekomendacje nie maj takiego umocowania. Moe to prowadzid do powanych problemw. Rekomendacje ograniczone powinny byd do interoperacyjnoci organizacyjnej i semantycznej. Interoperacyjnod na poziomie technologicznym, gdzie podstaw s normy i standardy techniczne mona w atwy sposb zapewnid poprzez modyfikacj zacznika 2 do KRI. Nie widad powodu dla tworzenia dodatkowego prawa powielaczowego w postaci rekomendacji zawierajcych normy i standardy techniczne. Jednoczenie: czste zmienianie takich rekomendacji i traktowanie ich, jako obligatoryjnych znacznie podwyszy koszt uzyskania interoperacyjnoci technologicznej! Take: jeli Unia Europejska wskae na nowy standard technologiczny to jego uzupenienie w KRI powinno byd proste na drodze nowelizacji niniejszego rozporzdzenia.

Uwaga dodatkowa: w propozycji par 7 ust 2 punkt 1) pojawia si po raz jedyny pojcie otwartych standardw, ktre pojawio si w EIF 1.0, ale nie wystpuje ju w EIF 2.0. Owszem, dod podobn definicj otwartoci EIF zawiera (p. 5.2.1) wszak po wielu latach bezproduktywnej dyskusji, czym s otwarte standardy naley si jednak wystrzegad wprowadzania do polskiego prawa tego niejasnego i czsto stosowanego w sposb wycznie marketingowy pojcia.

9. Par 8 ust.1. pkt. 1)

Uwaga: Ograniczenie tylko do osb wystpujcych w PESEL znaczco moe utrudniad obsug osb nieposiadajcych numeru pesel - a docelowo moe powodowad wykluczenie cyfrowe osb nieposiadajcych obywatelstwa lub staego zamieszkania na terytorium RP, dlatego sugeruj delegacj umoliwiajc o wyrnienie cech osb nieposiadajcych numeru identyfikacyjnego PESEL i ich takie samo traktowanie (przykad: studenci zagraniczni studiujcy w polskich publicznych uniwersytetach).

10. Par 9
Paragraf 9 stanowi delegacj do publikacji na ePUAP tylko schematw dla obiektw okrelonych paragrafem 8 ust 1. To za mao dla ustanowienia interoperacyjnoci. Oczekiwaniem jest to, e wszystkie podmioty, ktre tworz rejestry s zobowizane w uzgodnieniu z ministrem waciwym do spraw informatyzacji przygotowad i opublikowad struktury danych wszystkich przetwarzanych przez siebie cech informacyjnych.

11. Par. 10 ust. 2 pkt. 1)

Zamiast waciciel usugi warto zastosowad termin usugodawca.

Uwagi PIIT do projektu Rozp. RM w sprawie Krajowych Ramach Interoperacyjnoci

Strona 6

Par 11 ust. 4 i nowy ustp 5

Proponujemy uzupenienie par 11 o ust 5 o treci: Dopuszcza si kodowanie znakw wedug standardu Unicode UTF-16 okrelonego przez norm ISO/IEC 10646-1 Information technology Universal Multiple-Octet Coded Character Set wraz z normami uzupeniajcymi lub norm j zastpujc.. Uzasadnienie: Praktycznie wszystkie systemy operacyjne, narzdzia developerskie i aplikacje wspieraj UTF-8 wymieniony w ustpie 4. Jednak dla wielu bardzo popularnych platform, takich jak Java czy Windows, natywnym formatem jest UTF-16. Dopuszczenie wykorzystania UTF-16 powinno, zatem uprocid i potanid tworzenie oprogramowania dla administracji. Naley rwnie pamitad, e KRI i zadania polskiej administracji wychodz poza nasz lokalny charakter, a zadania pan-europejskie czy te wrcz kontaktw z administracjami innych paostw bd wymagay zastosowania UTF-16 (np. kraje azjatyckie).

12.Par 12 ust. 1
Uwaamy, e niezalenie od dobrych intencji zawartych w tym ustpie moe on byd przyczyn wielu nieporozumieo. Jeli zakadamy, e w podmiocie realizujcym zadanie publiczne powinno byd dostpne oprogramowanie nieodpatne suce do odczytania przesanego pliku to otwiera si prawdziwy problem. C, bowiem moe powstrzymad kogo od wysania pliku w formacie, ktry jest odczytywalny za pomoc darmowego oprogramowania dostpnego na superkomputer XYZ?... Warunek zosta speniony... Rwnie zapis o powielaczowym prawie, czyli rekomendacjach interoperacyjnoci powinien byd wykrelony (patrz dyskusja w uwadze 8). Dlatego te proponujemy nastpujce rozwizanie: Par 12 ust 1 w brzmieniu: Jeeli dla pisma w formie dokumentu elektronicznego sucego do procedowania danej sprawy nie ustalono wzoru dokumentu elektronicznego systemy teleinformatyczne uywane przez podmioty realizujce zadania publiczne powinny umoliwiad przyjmowanie dokumentw w postaci elektronicznej w formatach plikw okrelonych w zaczniku 2 do rozporzdzenia (czd A, punkty 1 i 2). W przypadku przyjcia powyszej uwagi mona wykrelid par 2 punkt 9).

Uwagi PIIT do projektu Rozp. RM w sprawie Krajowych Ramach Interoperacyjnoci

Strona 7

W zaczniku 2, cz A naley zatytuowad: W celu wymiany zasobw informacyjnych przez podmioty realizujce zadania publiczne stosuje si: Jednoczenie w celu uatwienia wymiany danych i poprawienia interoperacyjnoci sugerujemy poszerzenie listy standardw o nastpujce formaty plikw: .xls Dokumenty w postaci sformatowanego arkusza kalkulacyjnego jako plik typu.xls Microsoft Corp .xlsx Dokumenty w postaci sformatowanego arkusza kalkulacyjnego jako plik typu.xlsx Microsoft Corp

Patrz take dyskusja dotyczca zacznika 2. Nasz propozycj uzasadniamy faktem, e wielokrotnie w praktyce e-administracji pojawiaj si pliki w formie arkuszy elektronicznych (np. RIO) Uzasadnienie: Tak jak par 12 ust 2 mwi o tym, e podmioty realizujce zadania publiczne powinny udostpniad zasoby w jednym ze standardowych formatw, tak mona rwnie oczekiwad, e informacja do takiego podmiotu (jeli nie zostao to sformalizowane) bdzie skierowana w jednym z tych wanie formatw. Zapis mwicy o istnieniu nieodpatnego oprogramowania moe prowadzid do nieporozumieo. Zaproponowana przez nas formua daje symetryczne warunki wszystkim stronom (interesariuszom spoecznym).

13.Par. 12 ust. 2
Ustp ten mwi tylko o plikach, a powinien wskazywad na dane zgodnie z tytuem zacznika 2.

14.Par 12 ust 3 (nowy)

Proponujemy dodatkowy zapis dotyczcy wymiany informacji pozwalajcy na atw weryfikowalnod dokumentw, promocj rozwizao wykorzystujcych podpis elektroniczny (i/lub podpis osobisty!). Propozycja zapisu par 12 ustp 3: W celu udostpniania zasobw informacyjnych przez podmioty realizujce zadania publiczne zaleca si formaty danych wspierajce w swojej specyfikacji podpis elektroniczny. Uzasadnienie: nie wszystkie popularne formaty danych wymienione w Zaczniku 2 do niniejszego rozporzdzenia maj w opisie formatu standardowo opisany sposb doczania podpisu elektronicznego. Nie oznacza to, e dokument stworzony w danym formacie nie moe byd podpisany elektronicznie, natomiast w przypadku, kiedy sposb integrowania podpisu nie jest opisany w standardzie wwczas kady edytor takiego formatu moe to robid na odmienny sposb. Niemoliwa jest wwczas automatyzacja procesw e-administracji, a kady taki dokument musi byd weryfikowany przez czowieka.

Uwagi PIIT do projektu Rozp. RM w sprawie Krajowych Ramach Interoperacyjnoci

Strona 8

Proponowany przez nas zapis nie ogranicza moliwoci wykorzystania wszystkich dopuszczonych formatw, natomiast zaleca stosowanie tych, dla ktrych dowolny edytor czy te dowolne oprogramowanie do odczytu bdzie mogo korzystad z faktu ustandaryzowania obecnoci podpisu elektronicznego.

15.Par 13 ust 1.
Proponujemy zapis: Projektujc system teleinformatyczny podmiotu realizujcego zadania publiczne sucy do realizacji zadania publicznego naley zapewnid realizacj przez ten system wymagao Web Content Accessibility Guidelines (WCAG 2.0) na poziomie A w zakresie dotyczcym interfejsu uytkownika przeznaczonego dla zewntrznych uytkownikw systemu. Zaleca si przystosowanie projektowanego systemu do wymagao na poziomie AA. Uzasadnienie: Po pierwsze, naley wskazad, e w sposb zgodny z wymaganiami WCAG powinny byd przygotowane systemy do realizacji zadao publicznych. W przeciwnym wypadku rozporzdzenie nakazywaoby stosowanie takich rozwizao do wszystkich, take wewntrznych, systemw. W przypadku np. uczelni publicznych byoby to ogromnym obcieniem. Po drugie, naley w absolutnie klarowny sposb wskazad, e wymagania dotyczce accessibility dotycz tej czci systemu teleinformatycznego, ktry jest zwizany z korzystaniem z niego przez zewntrznych uytkownikw. Trudno sobie wyobrazid, e interfejs dla wewntrznych developerw systemu take bdzie musia speniad wymogi WCAG. Po trzecie, zapewnienie dostpnoci dla osb niepenosprawnych jest wanym zadaniem, wszak przystosowanie systemw jest bardzo kosztowne. Warto zwrcid uwag, e Europejska Agenda Cyfrowa wprawdzie przywouje wymagao WCAG, ale po pierwsze limituje je tylko do internetowych stron publicznych i publicznych serwisw on-line, a take nie okrela, na jakim poziomie bd te wymagania. Uwaamy, e w pocztkowej fazie wdraania takich serwisw naley zadbad o wymagania na poziomie A wraz z rekomendacj na poziomie AA. Patrz take: uwaga 12 i 13.

16.Par 13 ust. 2.
Proponujemy, eby podstawowa lista wymagao stanowia zacznik do niniejszego rozporzdzenia. Dlatego te brzmienie tego ustpu zmienioby si na: Lista wymagao, o ktrych mowa w ust. 1 znajduje si w zaczniku 3 do niniejszego rozporzdzenia.

Uwagi PIIT do projektu Rozp. RM w sprawie Krajowych Ramach Interoperacyjnoci

Strona 9

17.Par 14 ust. 2 nowy punkt

Proponujemy dodad jako pierwszy punkt: Opracowanie, wdroenie i egzekwowanie instrukcji polityki bezpieczeostwa Uzasadnienie: dla podmiotw administracji publicznej obowizujce jest rozporzdzenie MSWiA z dnia 29 kwietnia 2004 r. (Dz. U. 2004 Nr 100, poz. 1024), nakadajce obowizek opracowania i posiadania formalnej instrukcji polityki bezpieczeostwa. Brak jest, wic zapisu o egzekwowaniu. W takim przypadku niniejszy zapis uzupenia ten brak.

18.Par 14 ust 2 nowy punkt

Proponujemy doczenie nastpujcego zapisu: Kadorazowo system podlegajcy odbiorowi po jego wdroeniu lub przebudowie musi podlegad zewntrznemu audytowi polegajcemu na zastosowani procedur testw penetracyjnych Uzasadnienie: Wszystkie zapisy par 14 nie pokazuj, w jaki sposb naleaoby sprawdzad bezpieczeostwo, nawet po zastosowaniu wszystkich nakadanych wymogw. Proponujemy uzupenid zapisy par 14 ust 2 przynajmniej o ten jeden zapis.

19.Par 14 ust 2 punkt 9)

Proponujemy brzmienie: zapewnienie, e pracownicy, wykonawcy i uytkownicy reprezentujcy stron trzeci odchodz z podmiotu, zaprzestaj wykonywad zadania lub zmieniaj stanowisko w sposb nienaruszajcy ustalonych zasad bezpieczeostwa informacji.

20.Par. 14 ust.5 (nowy)

Proponujemy dodanie nowego ustpu w brzmieniu: Podmiot realizujcy zadania publiczne prowadzi w formie pisemnej i wdraa polityk bezpieczeostwa informacji - dokument zawierajcy i rozszerzajcy polityk bezpieczeostwa w rozumieniu art39a ustawy o ochronie danych osobowych, na wszystkie informacje przetwarzane w podmiocie. Uzasadnienie: wiele podmiotw posuguje si dokumentem nazywanym polityk bezpieczeostwa informacji (patrz uwaga 18), a odnoszcym si jedynie do danych osobowych, co wynika wprost z rozporzdzenia do uodo. Jest okazja by rozszerzyd dziaanie tej polityki na wszelkie zasoby informacyjne i dokumentowe w podmiocie. W lad za polityk powinna powstad instrukcja zarzdzania systemem teleinformatycznym, zawierajca podstawowe procedury odpowiadajce zasadom bezpieczeostwa zawartym w polityce.

21. Par. 15 ust.2 pkt 3)

Proponujemy uzupenid: przetwarzanych w systemach danych podlegajcych prawnej ochronie w zakresie wymaganym przepisem prawa.
Uwagi PIIT do projektu Rozp. RM w sprawie Krajowych Ramach Interoperacyjnoci

Strona 10

Uzasadnienie: przykadowo: w odniesieniu do przetwarzania danych osobowych jest obowizek odnotowania identyfikatora uytkownika wprowadzajcego dane do systemu oraz kontroli udostpniania. Odnotowanie kadej operacji przetwarzania nie jest wymagane ustaw uodo.

22.Zacznik 2
Zamiast nagwka: Organizacja okrelajca norm lub standard Propozycja: Organizacja okrelajca format, norm lub standard Uzasadnienie: mona byo domniemywad z dalszego cigu tabeli, e firmy takie jak Adobe czy Microsoft okrelaj normy dlatego proponujemy poprawk w przedstawionym wyej brzmieniu.

23.Zacznik 2
Dot. Formatu PDF Proponujemy zmian: Jest: Adobe System Inc Jest: puste Propozycja: ISO Propozycja: ISO/IEC 32000

Uzasadnienie: Jest oczywistym, e naley wykorzystywad specyfikacj ISO.

24. Zacznik 2
Dotyczy formatu Open Document Format Jest .odt Jest: OASIS Jest: puste Propozycja: ODF Propozycja: ISO Propozycja: ISO 26300

Uzasadnienie: Format ODF jest dostpny w postaci standardu ISO, wic nie ma potrzeby utrzymywania go w postaci formatu OASIS tak jak miao to miejsce w poprzednim rozporzdzeniu Uwaga: dziki takiemu zapisowi mona take transferowad pliki typu.ods (arkusze kalkulacyjne) patrz dyskusja w uwadze 10.

25. Zacznik 2
Ze wzgldw opisanych w uwadze 13 doczyd do listy standardw formaty arkuszy kalkulacyjnych.xls i .xlsx .

Uwagi PIIT do projektu Rozp. RM w sprawie Krajowych Ramach Interoperacyjnoci

Strona 11

26. Zacznik 2
Proponujemy doczenie nastpujcego formatu: L.p. Format: Oryginalna Nazwa: Organizacja: Nazwa normy: 1.4 OpenXPS Open XML Paper Specification Dokumenty tekstowo-graficzne dostpne przez dowoln przegldark internetow ECMA ECMA-388

Uzasadnienie: otwarta, darmowa specyfikacja dla dokumentw tekstowo-graficznych obsugiwana przez dowoln przegldark internetow.

27. Zacznik 2
Dotyczy formatu GIF. Przywoana w rozporzdzeniu firma CompuServe zostaa przejta na pocztku poprzedniej dekady przez AOL, za w 2009 roku serwis zaprzesta dziaalnoci w swojej klasycznej wersji. Prawa do standardu GIF (z roku 1987!!!) wygasy i nikt si t specyfikacj nie opiekuje. Mamy zatem standard de facto nieumocowany w adnych normach. Zapis w takiej postaci jak by przywoany w rozporzdzeniu z 2005 roku naley zmodyfikowad! Propozycja 1: wykrelid Propozycja 2: wykrelid CompuServe, za sam standard pozostawid (ew. Okrelenie de facto standard).

28. Zacznik 2
Pozycje 4.1 i 4.3 wymagaj precyzyjniejszego rozrnienia! Propozycja: wykorzystad zapis HTML 4.01 i specyfikacj jako opisan norm ISO 15445:2000

29. Zacznik 2
Propozycja doczenia do listy formatw standardu HTML5 rozwijanego przez W3C, jako standardu rozwojowego dla publikacji on-line. W szczeglnoci istotne w kontekcie pojawiania si coraz wikszej iloci materiaw video, take publikowanych przez administracj.

Uwagi PIIT do projektu Rozp. RM w sprawie Krajowych Ramach Interoperacyjnoci

Strona 12

30. Zacznik 2 sekcja elektronicznego podpisywania

Warto si jeszcze zastanowid do dopisaniem do listy formatu CAdES (CMS Advanced digital Electronic Signatures, Podpis elektroniczny w formacie CAdES, ETSI TS 101 733). Uzasadnienie: Dyrektywa Usugowa UE obliguje kraje czonkowskie do udostpniania tzw. jednego okienka, poprzez ktre obywatele Unii Europejskiej bd mogli zaatwid elektronicznie swoje sprawy. Wtedy administracja publiczna w Polsce nie powinna zabraniad w takim razie uywania podpisw w formacie CAdES wszystkim obywatelom Unii.

Uwagi koocowe:
Nie moemy zgodzid si z argumentacj, e wprowadzenie wymogu stosowania metodyki ITIL (par 10 ust 3) nie bdzie miao adnego wpywu finansowego na jednostki realizujce zadania publiczne. Zwaszcza w sytuacji, kiedy ta metodyka nie jest powszechnie stosowana praktyce tworzenia systemw (np. uczelnie). Dlatego te prosimy o uwzgldnienie tej uwagi w uzasadnieniu do rozporzdzenia.

Uwagi PIIT do projektu Rozp. RM w sprawie Krajowych Ramach Interoperacyjnoci

Strona 13