## Dlaczego to ważne

Większość kontroli urządzeń odpowiada sama za siebie. MDM raportuje szyfrowanie dysku, dostawca tożsamości — MFA, a platforma do zarządzania zgodnością pobiera jedno i drugie według harmonogramu. Aż wreszcie audytor pyta o czterech kontraktorów, projektantkę na prywatnym laptopie i doradcę, który nigdy nie był objęty agentem — a automatyzacja nie ma nic do powiedzenia.

Tę lukę zwykle łata się arkuszem kalkulacyjnym i folderem zrzutów ekranu na wspólnym dysku. Działa to, dopóki ktoś nie zapyta, kto potwierdził daną kontrolę, kiedy zrzut został wykonany i czy w okresie objętym audytem wciąż był aktualny. Wtedy odpowiedź jest już pogrzebana gdzieś w wątku na czacie.

**Checklista dowodowa** to program szkoleniowy, którego treścią jest zestaw ustawień urządzenia, a nie slajdy. Uczestnik dostaje instrukcje krok po kroku dla swojego systemu operacyjnego, zmienia ustawienie, przesyła dowód i podpisuje to samo prawne oświadczenie, którego używają Twoje pozostałe szkolenia. Na końcu powstaje zapis ukończenia, który audytor akceptuje.

> [!NOTE]
> Checklisty są dla osób, do których automatyzacja nie sięga. Jeśli MDM już raportuje daną kontrolę dla danej maszyny, zbieraj ją dalej właśnie tam — tamten dowód jest ciągły, a checklista opisuje stan z jednej chwili.

## Checklisty a kursy

Jedno i drugie to programy szkoleniowe i jedno i drugie kończy się podpisanym oświadczeniem. Różnica tkwi w tym, co jest pomiędzy.

| | Kurs | Checklista |
|---|---|---|
| **Treść** | Slajdy, potem sprawdzian wiedzy | Punkty kontrolne, każdy z instrukcjami dla poszczególnych platform |
| **Dowodzi** | Że uczestnik zrozumiał materiał | Że maszyna uczestnika jest skonfigurowana w określony sposób |
| **Ukończenie** | Każdy slajd obejrzany, quiz zaliczony, oświadczenie podpisane | Każdy punkt kontrolny potwierdzony, oświadczenie podpisane |
| **Dowód** | Zapis ukończenia | Zapis ukończenia plus przesłane zrzuty ekranu |

Program jest albo jednym, albo drugim — decyduje szablon, z którego go wypełnisz. Cała reszta — zaproszenia, terminy, przypomnienia, rejestr ukończeń, eksport do Vanta — działa identycznie w obu przypadkach.

## Dwie gotowe checklisty

### Endpoint Hardening

Siedem ustawień urządzenia, o których udowodnienie audytor prosi kontraktora:

| Punkt kontrolny | Dowód |
|---|---|
| **Szyfrowanie całego dysku** — FileVault, BitLocker lub LUKS | Zrzut ekranu |
| **Blokada ekranu z hasłem po wybudzeniu** | Zrzut ekranu |
| **Włączone automatyczne aktualizacje systemu** | Zrzut ekranu |
| **Działająca ochrona przed złośliwym oprogramowaniem** | Zrzut ekranu |
| **Menedżer haseł w użyciu** | Zrzut ekranu |
| **Włączony firewall** | Zrzut ekranu |
| **Hasło urządzenia zgodne z polityką** | Tylko oświadczenie |

Hasło urządzenia celowo opiera się wyłącznie na oświadczeniu: żaden panel ustawień nie pokazuje długości hasła, więc zrzut ekranu niczego by nie dowiódł.

Ochrona przed złośliwym oprogramowaniem to jedyny punkt kontrolny, który nie udaje, że na każdej platformie wygląda tak samo. Na Linuksie instrukcja mówi wprost, że desktop bez skanera działającego w czasie rzeczywistym to normalna odpowiedź, i prosi o zrzut środków zastępczych — automatycznego łatania i firewalla, który domyślnie odrzuca ruch przychodzący — oraz o napisanie tego w notatce. Udawana równoważność pogorszyłaby dowód, a nie poprawiła.

Dwie wartości są pytaniami szablonu zamiast liczb zapisanych na sztywno, bo trzy główne platformy do zarządzania zgodnością nie mogą się co do nich zgodzić, a wiążąca jest Twoja własna polityka:

- **Czas do blokady ekranu**, domyślnie 15 minut. Vanta akceptuje do 60, Drata oczekuje hasła w 60 sekund po blokadzie ustawionej na 15 minut, Secureframe sprawdza, czy to najwyżej 900 sekund.
- **Minimalna długość hasła**, domyślnie 8 znaków.

### Policy Acknowledgment

Wszystkie 22 polityki SOC 2 jako punkty kontrolne oparte wyłącznie na oświadczeniu, pogrupowane tak, żeby czytało się je spójnymi blokami, a nie jedną płaską listą: zasady postępowania, bezpieczeństwo informacji, dane, odporność i ład organizacyjny. Każdy punkt linkuje tam, gdzie trzymasz swoje polityki, a podpisane oświadczenie wymienia każdą politykę z nazwy — ogólny podpis pod „potwierdzam zapoznanie się z politykami” nie przetrwa pytania, o które konkretnie chodzi.

## Budowanie checklisty

1. **Wypełnij ją z szablonu.** Na pulpicie Szkoleń kliknij **Zbuduj z szablonu** i wybierz **Endpoint Hardening** albo **Policy Acknowledgment**. Odpowiedz na pytania inteligentnego szablonu — o nazwę firmy, menedżera haseł, czas do blokady ekranu.
2. **Przejrzyj punkty kontrolne.** Każdy ma tytuł, notkę „dlaczego to ważne”, którą czyta uczestnik, zasady dowodu oraz instrukcje dla poszczególnych systemów operacyjnych. Możesz je dowolnie edytować, dodawać własne i zmieniać kolejność.
3. **Dodaj instrukcje dla platform, których potrzebujesz.** Gotowe checklisty obejmują macOS, Windows 11 i Linuksa. Kroki dla Linuksa napisaliśmy celowo inaczej: zamiast ścieżki kliknięć przez środowisko graficzne, którego nie znamy, nazywają samo zabezpieczenie i podają niezależne od dystrybucji polecenie, którego wynik jest zrzutem — `lsblk` z urządzeniem `crypt` od LUKS, `systemctl list-timers` z timerem aktualizacji, `ufw status verbose` z domyślnym odrzucaniem. Zrzut terminala i tak jest lepszym dowodem niż panel ustawień. Uczestnik na platformie bez własnych instrukcji nadal zobaczy pierwsze dodane, a nie pustą kartę, a checklista wprost napisze, czyje kroki właśnie czyta.
4. **Opublikuj i zaproś.** Dokładnie tak jak przy kursie. Checklista nie opublikuje się bez co najmniej jednego punktu kontrolnego i oświadczenia.

## Co widzi uczestnik

Jedna strona, jedna otwarta karta naraz. Kit rozpoznaje system operacyjny po przeglądarce i pokazuje pasujące instrukcje; uczestnik może się przełączyć, a wybór zostaje zapamiętany.

Każda karta zawiera ponumerowane kroki, powód, dla którego dana kontrola ma znaczenie, i zasady dowodu. Uczestnik robi zrzut ekranu, upuszcza go lub wkleja na kartę, podaje nazwę urządzenia i datę wykonania. Potwierdzenie zwija kartę i otwiera następną.

**Metryczkę dowodu się wpisuje, a nie fotografuje.** Zamiast wymagać, żeby nazwa maszyny była widoczna na zrzucie, Kit prosi o nazwę urządzenia i datę wykonania jako osobne pola. Te dane są szyfrowane, można je przeszukiwać i zostają nawet po usunięciu samego obrazu.

Interfejs podpowiada, żeby przed zrzutem wyciszyć powiadomienia i żeby przesłać zrzut okna ustawień, a nie zdjęcie ekranu zrobione telefonem. To dwa najczęstsze powody odrzucania dowodów przez audytorów.

## Przegląd dowodów

Przesłanie dowodu zamyka punkt kontrolny. Przegląd to późniejszy triaż, a nie bramka — kontraktor nie czeka, aż ktoś zajrzy do skrzynki.

Kolejka pokazuje potwierdzone, ale jeszcze niesprawdzone dowody wraz z metryczką, dzięki której zrzut nadaje się dla audytora: platformą, nazwą urządzenia, datą wykonania i liczbą dni między zrzutem a potwierdzeniem. Dowód z datą wsteczną jest wskazany wprost, bo właśnie tego recenzent wypatruje.

**Zaakceptowanie** zdejmuje pozycję z kolejki. **Odrzucenie** wymaga uwagi, otwiera punkt kontrolny ponownie i wysyła uczestnikowi e-mail z Twoim uzasadnieniem. Nie cofa jednak zapisu ukończenia — szkolenie zostało ukończone, a przepisywanie tego faktu byłoby fałszowaniem historii, nie prośbą o lepszy zrzut.

Ponowne otwarcie punktu kontrolnego to prawdziwy dostęp, a nie tylko status: strona checklisty pozostaje dostępna dla osoby, która już skończyła, i pokazuje Twoją uwagę na tej jednej karcie, której zrzut trzeba zrobić jeszcze raz. Nowy zrzut przywraca punkt kontrolny do kolejki przeglądu jako świeży dowód do sprawdzenia. Dowód przesłany przed Twoim przeglądem zostaje w dokumentacji i nie da się go usunąć (właśnie o ten zapis pyta audytor), więc jest pokazywany obok nowego i oznaczony jako zastąpiony.

Odrzucony dowód zmienia za to rejestr: taka osoba przestaje liczyć się jako ukończona i przechodzi na etap **Dowód odrzucony**, wyświetlany przed wszystkimi innymi. To liczbę osób z ukończonym szkoleniem wręczasz audytorowi, więc nie obejmuje ona nikogo z zaległym dowodem.

## Dostęp i przechowywanie

**Dowody widzą wyłącznie administratorzy szkoleń na danym koncie**, a każde pobranie jest odnotowywane: kto, kiedy i który plik otworzył. Pliki są serwowane przez krótkotrwałe linki generowane osobno przy każdym kliknięciu, a nie przez adresy URL osadzone w stronie — więc dostęp do plików kończy się razem z dostępem danej osoby.

**Dowody są usuwane zgodnie z harmonogramem.** Każdy program ma okres przechowywania, domyślnie 395 dni — rok plus margines, którego potrzebuje okres objęty audytem Type II. Nocne zadanie usuwa pliki, gdy tylko przesłany dowód przekroczy ten okres. Inny okres dla konkretnego programu ustawisz przez `evidence_retention_days` w `training_create_program`.

Zapis ukończenia przetrwa to usunięcie, podobnie jak nazwa i skrót (hash) zawartości każdego pliku. Nawet gdy zrzutów już nie ma, nadal możesz udowodnić, co przesłano, kiedy, przez kogo — i że niczego nie podmieniono.

> [!TIP]
> Okres przechowywania liczy się od przesłania pliku, a nie od potwierdzenia. Odrzucenie dowodu kasuje potwierdzenie, więc liczenie od potwierdzenia restartowałoby zegar za każdym razem — odrzucone dowody byłyby jedynym rodzajem, który zostaje na zawsze.

## Eksport

Eksport CSV do Vanta zyskuje dla checklist kolumny dowodowe: status przeglądu, liczbę potwierdzonych punktów kontrolnych, łączną liczbę punktów, liczbę plików, nazwę urządzenia i przedział dat wykonania. Eksporty kursów pozostają niezmienione co do bajta — Vanta dopasowuje dane po dokładnej kolejności i brzmieniu kolumn.

Rejestr PDF dostaje osobną tabelę dowodów z punktów kontrolnych, umieszczoną pod główną.

### Jedna osoba, jeden plik

Eksporty rejestru obejmują wszystkich naraz. Gdy audytor pyta o jedną osobę, użyj **Pakietu dowodów** w jej wierszu. Archiwum powstaje w tle, a pobieranie rusza, gdy tylko będzie gotowe.

W środku jest wszystko, co mamy udokumentowane dla tej osoby, przemianowane tak, żeby folder dało się zrozumieć bez Twojego komentarza:

```
training-evidence-jane-doe-endpoint-hardening-20260114.zip
└── jane-doe-endpoint-hardening-20260114/
    ├── jane-doe-00-manifest.csv
    ├── jane-doe-01-certificate.pdf
    ├── jane-doe-checkpoint-01-full-disk-encryption-01.png
    ├── jane-doe-checkpoint-02-screen-lock-01.png
    └── jane-doe-checkpoint-02-screen-lock-02-superseded.png
```

Spis to ta część, którą audytor faktycznie czyta: jeden wiersz na plik, z platformą, nazwą urządzenia, datą zrzutu, datą potwierdzenia, werdyktem weryfikatora i jego uwagą, a do tego pierwotna nazwa pliku i suma kontrolna. Folder ze zrzutami bez spisu nic nie mówi komuś, kogo przy tym nie było.

Dwa stany oznaczamy, zamiast je ukrywać. Dowody przesłane przed werdyktem weryfikatora trafiają do archiwum z dopiskiem `-superseded` w nazwie: pominięcie ich zaciera ślad, a dołączenie bez oznaczenia sugeruje, że zostały przyjęte. Pliki usunięte już przez politykę przechowywania pojawiają się jako krótka notatka `.purged.txt` dokładnie w miejscu, w którym byłby zrzut, wraz z zachowaną nazwą i sumą kontrolną — pakiet, który po cichu by je pominął, zafałszowałby dokumentację.

Uczestnicy kursów nie mają zrzutów, więc ich pakiet to certyfikat i spis, a przycisk mówi wprost **Pakiet z certyfikatem**.

Pakiety wygasają po siedmiu dniach, a każde pobranie jest zapisywane: kto wziął archiwum i kiedy, plus wpis dla każdego pliku w tym samym dzienniku dostępu do dowodów, który powstaje przy pobraniu pojedynczego pliku. Dzięki temu pytanie „kto kiedykolwiek widział zrzuty tej osoby?" ma jedną pełną odpowiedź.

## Przypomnienia

Checklisty korzystają z tej samej sekwencji przypomnień co kursy: ponaglenie po zaproszeniu, ostatnie wezwanie, gdy zbliża się termin, przypomnienie o podpisaniu oświadczenia dla każdego, kto skończył treść, ale nie podpisał, oraz przypomnienie o zaległym szkoleniu — najwyżej trzy wysyłki w odstępie tygodnia.