Uważanym za idealny, lecz bardzo trudnym do osiągnięcia, modelem Polityki Bezpieczeństwa jest Globalna Polityka Bezpieczeństwa Systemów Informatycznych. Zakłada on posiadanie jednego dokumentu opisującego w sposób ogólny Zasady Bezpieczeństwa przyjęte w danej instytucji, popierane przez jej kierownictwo oraz przestrzegane przez użytkowników. Często ten rodzaj Polityki Bezpieczeństwa nazywany jest również Biblią Bezpieczeństwa. Model ten przywędrował do naszego kraju z państw "zachodnich" wraz z różnymi standardami bezpieczeństwa systemów informatycznych. Powodem trudności są dwa aspekty. Po pierwsze, standardy z dekady lat siedemdziesiątych czy osiemdziesiątych, na podstawie których stworzona jest metodyka Globalnej Polityki, dotyczyły hermetycznego środowiska rządowego czy akademickiego, posiadającego zazwyczaj pojedynczy system informatyczny, którego liczbę użytkowników przewyższają dzisiejsze pojedyncze klasy sieci lokalnych, pracujące na sprzęcie i oprogramowaniu komputerowym o nieco odmiennej filozofii działania i znacznie mniejszej popularyzacji. Po wtóre, kultura informatyczna zapoczątkowana w takich środowiskach pozwala na przypominanie o zasadach bezpieczeństwa, gdzie w naszych warunkach zasady te nie są zjawiskiem naturalnym, a nierzadko są traktowane jako brak zaufania. Przykładem może być wprowadzanie nowych Zasad Bezpieczeństwa dotyczących administrowania systemem. Dla administratorów pracujących w instytucji, mających ustalony schemat i określone nawyki każda nowa zasada, nawet najbardziej oczywista, której dotychczas nie było, staje się poważnym obciążeniem. Po jej zatwierdzeniu, mimo akceptacji kierownictwa, w wielu przypadkach niezwykle trudno jest ją egzekwować. Ta sama zasada już istniejąca, przedstawiona nowo zatrudnionemu administratorowi systemu, wydaje się naturalna i najprawdopodobniej będzie on jej przestrzegał.

Obecna infrastruktura informatyczna narzuca nam niejako układ, wg którego najlepiej kreować Politykę Bezpieczeństwa. Jeżeli chcemy, aby dokument ten spełniał swoje zadanie, powinien obejmować wszystkie rejony informatyczne i wszystkie niezbędne mechanizmy zabezpieczeń. Konieczne jest również, by była ona przeznaczona dla użytkowników systemów informatycznych, nie zaś była "ozdobą" informacji firmowej.

W większości przepadków kreowanie Polityki Bezpieczeństwa rozpoczyna się w czasie, gdy firma ma już pewien poziom rozwoju infrastruktury. Jeżeli dysponujemy sklasyfikowanym modelem infrastruktury, powinniśmy opracować wymagania dla poszczególnych klas systemów informatycznych. Wymagania te określają, jakie zasoby chronimy, przeciwko jakim zagrożeniom oraz jakie rozwiązania wykorzystujemy do ich ochrony. Dobrą praktyką jest zastosowanie systematyki wykorzystywania możliwości zabezpieczeń wg klucza kolejnych implementacji mechanizmów, czyli:

• najpierw wykorzystujemy wszystkie istniejące i adekwatne do rzeczywistych potrzeb mechanizmy standardowo obecne w systemach informatycznych

• równocześnie wprowadzamy istotnie podnoszące poziom bezpieczeństwa mechanizmy fizycznej i administracyjnej ochrony danych i zasobów

• w dalszej kolejności zabezpieczamy elementy o współczynniku ryzyka maksymalnego poprzez zastosowanie dodatkowych mechanizmów techniczno-programowych i fizycznych

• dla zasobów skrajnie wartościowych istotne jest przygotowanie rozwiązań zabezpieczeń niestandardowych, a więc takich, w których sama idea realizacji zabezpieczenia stanowi tajemnicę, lub mechanizmów niekomercyjnych;

• dla grup środków i mechanizmów zapewniających:
  • poufność

  • integralność

  • dostępność

  • rozliczalność

  • autentyczność

  • niezawodność.

Mając zestaw wymagań bezpieczeństwa dla poszczególnych klas systemów i znając mapę systemów instytucji istniejących oraz planowanych do wdrożenia, posiadamy pierwszy element polityki bezpieczeństwa - ogólne reguły bezpieczeństwa systemów informatycznych, umożliwiające określenie, jaki poziom zabezpieczeń jest pożądany.

Po określeniu wymagań, należy opisać funkcjonalny poziom bezpieczeństwa poszczególnych systemów w odrębnych dokumentach Polityki Bezpieczeństwa. Opis funkcjonalny może wzorować się na elementach wymagań odpowiadając wprost, czy dany system informatyczny je spełnia. W przypadku gdy element wymagań nie jest spełniony, Polityka Bezpieczeństwa powinna żądać usunięcia "usterki" lub jeżeli istnieje konieczność, aby system nie spełniał danego wymagania, należy fakt ten uzasadnić i zaznaczyć, iż jest to odstępstwo od standardu bezpieczeństwa dla danej klasy bądź grupy systemów.

Zgodnie z metodyką, polityka nie określa, w jaki sposób jest dokonywany proces bezpieczeństwa, a jedynie co jest chronione. Nie należy więc opisywać w dokumencie polityki funkcjonowania mechanizmów bezpieczeństwa.