Każdy program zgodności ma półkę dokumentów: polityki, opisy kontroli, procedury, z których każdy opisuje, jak organizacja zamierza się zachowywać. Dokumenty są konieczne. Nie są jednak miejscem, w którym zgodność rzeczywiście się udaje lub nie powodzi.
Luka między polityką a rzeczywistością
Polityka kontroli dostępu mówi o zasadzie najmniejszych uprawnień. Polityka szyfrowania mówi, że dane w tranzycie są chronione. Polityka retencji mówi, że dane osobowe są usuwane po zakończeniu ich celu. To prawdziwe oświadczenia dotyczące zamiarów.
Czy są one prawdziwymi oświadczeniami o twoim systemie, zależy wyłącznie od kodu: od polityki IAM, która została faktycznie wdrożona, od minimalnego poziomu TLS, który serwis faktycznie egzekwuje, od zadania usuwania, które faktycznie działa. Luka między dokumentem a wdrożeniem to dokładnie tam, gdzie audyty znajdują swoje ustalenia, i otwiera się ona za każdym zwykłym pull requestem.
Diff to miejsce, w którym kontrola zmienia stan
Kontrola nie degraduje się cicho. Coś ją zmienia: rola jest poszerzana, ustawienie szyfrowania jest usuwane, limit retencji jest usuwany. Każda z tych zmian to diff, autorstwa kogoś, zrecenzowany przez kogoś, z momentem, w którym można było to złapać.
Jeśli chcesz zarządzać kontrolą, zarządzaj momentem jej zmiany. Dokument polityki nie może tego zrobić; nie wie, że diff miał miejsce. Pull request to miejsce, w którym stan kontroli faktycznie się zmienia, więc to tam powinien być sprawdzany.
Dowody, które odzwierciedlają rzeczywistość
Efektem ubocznym sprawdzania kontroli na poziomie diff jest to, że twoje dowody przestają być historią, którą składasz na potrzeby audytu, a zaczynają być zapisem tego, co faktycznie się stało: ta zmiana dotknęła tej kontroli, oto klauzula, oto jak została rozwiązana, w wątku PR, z znacznikami czasu.
heygrc cytuje konkretną kontrolę dotyczącą zmiany, która ją dotyczy, więc ślad jest zakotwiczony w kodzie, a nie w dokumencie opisującym, co kod powinien robić.