Bank, partner czy dział zamówień pyta wprost: „macie ISO 27001? macie raport SOC 2?". Ta strona odpowiada uczciwie, jednym rejestrem: które kontrole platformy ipIII są dziś gotowe i dowodliwe, które są luką (GAP) z nazwanym planem domknięcia, a które elementy z definicji wymagają niezależnej jednostki certyfikującej / firmy audytorskiej i nie mogą być wystawione przez nas samych. To jest mapa gotowości (readiness), nie certyfikat i nie raport z audytu.
Zamiast jednego mglistego „pracujemy nad zgodnością" — rejestr per domena kontroli, z dowodem tam gdzie dowód istnieje. Podstawą jest dziś działający rdzeń evidence (import → incydent → evidence-package → retest → close, JWT/RBAC/audit na żywej PostgreSQL). Braki formalne (polityki ISMS, SoA, zewnętrzny audyt) są nazwane wprost, nie ukryte pod ogólnikiem.
Nie jest to pełne Statement of Applicability (SoA) — to selekcja reprezentatywnych obszarów czterech tematów Aneksu A (organizacyjne, ludzkie, fizyczne, technologiczne), z uczciwym stanem na 2026-07-05.
| Temat / obszar | Przykładowy wymóg | Stan wewnętrzny ipIII | Status |
|---|---|---|---|
| A.5 Organizacyjne — kontrola dostępu, klasyfikacja informacji | Polityka kontroli dostępu, role i odpowiedzialności, zarządzanie aktywami informacyjnymi. | RBAC działa technicznie (role/uprawnienia w JWT, egzekwowane na API — LIVE), ale brak spisanej, zatwierdzonej polityki ISMS i formalnego rejestru aktywów. | GAP |
| A.5 Organizacyjne — zarządzanie incydentami | Udokumentowany proces zgłoszenia, klasyfikacji, eskalacji i zamknięcia incydentu bezpieczeństwa. | Ścieżka incydent → evidence-package → retest → close działa na produkcji z audit-logiem (LIVE). Brak formalnej polityki IR podpisanej przez zarząd i planu ćwiczeń (tabletop) w cyklu. | częściowo gotowe |
| A.5 Organizacyjne — relacje z dostawcami | Ocena bezpieczeństwa dostawców/podwykonawców, klauzule bezpieczeństwa w umowach. | Brak formalnego rejestru dostawców i procesu oceny. Zależność od hostingu chmurowego (Fly.io) bez formalnej due diligence bezpieczeństwa dostawcy udokumentowanej u nas. | GAP |
| A.6 Ludzkie — świadomość i szkolenia, sprawdzanie przed zatrudnieniem | Screening kandydatów, cykliczne szkolenia z bezpieczeństwa, proces dyscyplinarny. | Brak sformalizowanego programu. Zespół mały, wiedza operacyjna nieudokumentowana jako program szkoleniowy. | GAP |
| A.7 Fizyczne — bezpieczeństwo fizyczne środowiska | Kontrola dostępu fizycznego do serwerowni/data center. | Dziedziczone od dostawcy chmury (odpowiedzialność współdzielona); brak własnego audytu fizycznego dostawcy — to normalne dla modelu SaaS, ale wymaga odniesienia się do certyfikatów dostawcy (np. SOC 2 dostawcy infrastruktury). | dziedziczone od dostawcy |
| A.8 Technologiczne — uwierzytelnianie, zarządzanie dostępem uprzywilejowanym | MFA, silne uwierzytelnianie, federacja tożsamości (OIDC/SSO). | JWT lokalny + RBAC działa (LIVE). Brak OIDC/JWKS i federacji z zewnętrznym IdP — patrz znane ograniczenia (P0). | GAP (P0) |
| A.8 Technologiczne — kryptografia | Szyfrowanie danych w spoczynku i w tranzycie, integralność dowodów. | Integralność evidence-package przez sha256 działa (LIVE). Brak mTLS na styku integracji oraz brak formalnego podpisu PAdES/TSA dowodów. |
GAP (P0/P1) |
| A.8 Technologiczne — logowanie i monitorowanie | Audit trail zdarzeń bezpieczeństwa, retencja logów, przegląd logów. | Audit-log działa na żywej PostgreSQL, powiązany z JWT/RBAC (LIVE). Brak sformalizowanej polityki retencji i harmonogramu przeglądu logów przez osobę niezależną od operacji. | częściowo gotowe |
| A.8 Technologiczne — zarządzanie podatnościami | Cykliczne skanowanie, priorytetyzacja (CVSS/EPSS/KEV), terminy łatania. | Wzbogacanie CVE działa offline z seedu (LIVE Fala 1); brak online lookupu w czasie rzeczywistym i formalnych SLA łatania — patrz znane ograniczenia (P1). | częściowo gotowe |
| A.8 Technologiczne — ciągłość działania ICT | Kopie zapasowe, testy odtwarzania, plan ciągłości. | Brak udokumentowanego, przetestowanego planu ciągłości/DR specyficznego dla platformy ipIII. | GAP |
| Statement of Applicability + audyt certyfikujący | Formalne SoA, audyt etapu 1/2, wydanie certyfikatu ISO 27001. | Nie dotyczy pracy zespołu dev — to zadanie wyłącznie akredytowanej jednostki certyfikującej po zamknięciu GAP powyżej. | wymaga jednostki |
SOC 2 nie ma jednej listy kontroli jak Aneks A — organizacja definiuje własne kontrole wobec pięciu kryteriów usługowych (TSC). Poniżej stan wobec każdego kryterium, w odniesieniu do dowodów platformy.
| Trust Service Criterion | Co sprawdza | Stan wewnętrzny ipIII | Status |
|---|---|---|---|
| Security (kryterium wspólne, CC1–CC9) | Kontrola dostępu, zarządzanie zmianą, monitorowanie, reagowanie na incydenty, ryzyko dostawców. | RBAC + JWT + audit-log + ścieżka incydent → evidence → retest → close (LIVE w warstwie technicznej). Brak formalnego rejestru ryzyka, polityk podpisanych przez kierownictwo, oceny dostawców. | częściowo gotowe |
| Availability | Monitorowanie dostępności, plan ciągłości, testy odtwarzania, SLA. | Brak formalnego SLA dostępności i przetestowanego planu DR dla ipIII jako usługi. | GAP |
| Confidentiality | Klasyfikacja i ochrona informacji poufnych, kontrola dostępu do danych klienta. | Dane dziś w jednej organizacji (brak multi-tenant) — patrz znane ograniczenia (P1); brak formalnej klasyfikacji danych i umów o poufności per klient wdrożonych operacyjnie. | GAP |
| Processing Integrity | Kompletność, dokładność i terminowość przetwarzania danych. | Integralność evidence-package (sha256, chain-of-custody) działa (LIVE); brak formalnego podpisu kwalifikowanego i znacznika czasu TSA. |
częściowo gotowe |
| Privacy | Zgodność z zasadami przetwarzania danych osobowych (powiązane z RODO). | Legal Trigger Engine wspiera identyfikację obowiązków (LIVE jako decision-support), ale to nie jest ocena zgodności ani polityka prywatności formalna dla usługi SaaS. | częściowo gotowe |
| Raport SOC 2 Type I / Type II | Opinia niezależnego biegłego rewidenta (CPA) o zaprojektowaniu (Type I) i skuteczności działania w czasie (Type II) kontroli. | Nie dotyczy pracy zespołu dev — wyłącznie licencjonowana firma audytorska może wydać taki raport, po okresie obserwacji kontroli (Type II zwykle 6–12 miesięcy). | wymaga jednostki |
Powiązane: pełny rejestr znanych ograniczeń → /known-limitations · mapowanie dowód → kontrola ram (ISO/NIST/CIS/DORA/NIS2) → /control-mapping · ocena skuteczności kontroli → /control-effectiveness · macierz statusów wszystkich elementów → /status-matrix.