Raportowanie compliance w ITSM —
automatyczne raporty NIS2 i GDPR

Compliance reporting to ostatnia rzecz którą IT Manager chce robić ręcznie — zbieranie log'ów z 20 systemów, Excel formulas, manual aggregation, 72-punktowy dokument na koniec miesiąca. Problem: z tym systemem audzior zawsze ma pytania, bo dokumentacja jest niekompletna albo niespójna. W tym artykule pokazuję, jak **zautomatyzować raportowanie compliance**, **budować evidence collection** w real-time, **dashboardy compliance** że wszystko jest OK, i **eksport PDF** gotowy do audytora w jedno kliknięcie. Cena: 0 godzin ręcznej pracy miesięcznie zamiast 5–8 godzin.

Co to jest compliance reporting i dlaczego jest ważne

Compliance reporting to dokumentacja dowodów że Twoja organizacja spełnia regulacje (NIS2, GDPR, ISO 27001, SOC 2). Audytor przychodzi i pyta: \"Pokaż mi dowód że kontrolowałeś dostęp do wrażliwych danych\". Odpowiedź nie może być \"wierzymy że tak\" — musi być \"tu są audit log'i pokazujące każdy dostęp i zmianę\".

Elementy compliance reporting:

• Audit trail: Immutable log (nie da się zmodyfikować czy usunąć) każdej akcji — kto zalogował się, co zmienił, kiedy, z którego IP
• Evidence collection: Automatyczne zbieranie dowodów (screenshot'y, eksporty, metryki) do folderu audytu
• Compliance dashboard: Real-time view na to czy jesteś compliant — SLA breach %, incident resolution time, patch lag
• Formal report: PDF gotowy do wysłania audytorowi — summary statystyk, dowody, policy review

Audit trail — immutable log każdej akcji w systemie

Audit trail to serce compliance reporting — każdy dostęp, zmiana, usunięcie musi być zalogowany. Format:

• Timestamp: Dokładny czas (UTC, z synchronizacją NTP)
• User: Kto zrobił akcję (login, ID pracownika)
• Action: Co dokładnie zrobił (create ticket, change status, assign to user, add attachment)
• Object: Czego dotyczy (ticket ID, database record)
• Old value / New value: Co się zmieniło (status: open → closed, priority: low → high)
• Source IP: Z którego IP/maszyny (audytor chce wiedzieć czy z sieci firmowej czy remote)
• Result: Czy akcja się udała (success/failure — jeśli ktoś próbował dokonać nieautoryzowanej zmiany, powinno być failure)

Evidence collection — automatyczne zbieranie dowodów

Zamiast ręcznego eksportowania raportów co miesiąc, system powinien kontinuralnie zbierać dowody w dedicated evidence folder/database:

• Monthly compliance snapshot:

  Co ostatni dzień miesiąca, system generuje: number of incidents, average resolution time, SLA compliance %, change requests reviewed/approved, patches deployed last month.

• Critical event logging:

  Na bieżąco: każdy dostęp do PII danych, każdy security incident, każda zmiana w access control, każdy failed login attempt (3+ failed = account lock).

• Policy evidence:

  Dokumenty (Change Control Policy, Incident Response Plan, Security Policy) z datą ostatniej review i approved-by signature.

• Training records:

  Security training completion (kto ukończył, kiedy, jaki score), phishing simulation results, incident response drill results.

Dashboardy compliance — real-time view na metryki

Compliance dashboard pokazuje na jednym ekranie czy organizacja jest compliant czy nie. Przykładowe widget'y:

• Incident Resolution SLA: Procent incydentów rozwiązanych na czas (target 95%). Red jeśli < 80%, yellow jeśli < 90%, green jeśli > 95%
• Change Control: Procent zmian reviewed/approved (target 100%). Nieautoryzowane zmiany = red alert
• Patch management: Procent systemów patched w ciągu RTO (CVSS 9+ w 24h, CVSS 7–9 w 7 dni). Red jeśli lag > RTO
• Access control: Liczba accounts z excessive privileges (admin gdy nie potrzeba). Powinno być 0
• Audit trail integrity: Czy audit log'i są kompletne i niezmodyfikowane (daily integrity check). Green = pass, red = fail
• Security incidents: Liczba i status incydentów (open, in-investigation, resolved). Resolved % vs. SLA

Tabela — co wymaga compliance reporting (NIS2, GDPR, ISO 27001)

ManageEngine SDP — wbudowane features dla compliance

ManageEngine ServiceDesk Plus ma native support dla compliance reporting:

• Immutable Audit Trail: Każda akcja w SDP logowana — create ticket, assign, comment, close. Nie da się usunąć czy zmodyfikować (nawet admin nie może)
• Custom Reports: Query builder — stwórz raport \"all incidents closed in last 30 days with SLA status\". Export to PDF, schedule monthly automated email
• Compliance Dashboard: Widget'y pokazujące SLA compliance %, incident resolution time vs. target, change approval rate, patch lag vs. RTO
• Change Control Workflow: Każda zmiana wymaga approval (defined by role), audit log pokazuje kto zaapproved i kiedy
• Archival policy: Tickets stasze 1+ roku automatic archive (can define retention 3/7 lat), archival stored encrypted i read-only

Krok po kroku — jak wdrożyć compliance reporting

• Krok 1: Define compliance requirements (2 dni)

  Przeanalizuj jakie regulacje się na Ciebie stosują (NIS2? GDPR? ISO 27001?). Dla każdej — zdefiniuj metryki compliance (SLA %, patch lag, incident resolution time).

• Krok 2: Configure audit trail (1 dzień)

  ManageEngine SDP: Admin > Audit Trail > Enable immutable logging dla: tickets, changes, access logs. Verify log destination (local database + offsite backup).

• Krok 3: Build compliance dashboard (2 dni)

  SDP: Dashboard > Create custom widgets dla compliance metrics. Add to CEO/CISO dashboard. Schedule daily refresh (system automatycznie aktualizuje values).

• Krok 4: Create monthly compliance report (1 dzień)

  SDP: Reports > Create template \"Monthly Compliance Report\". Include: incident count, SLA %, changes reviewed, patches deployed, security incidents. Schedule monthly export to PDF + email to CISO.

• Krok 5: Archive evidence (1 dzień)

  Setup policy: monthly PDF reports + full audit logs export to encrypted cloud storage (AWS S3 Glacier, 7-year retention). Test quarterly restores.

Najczęstsze pytania (FAQ)