Wersja 1.0 · 2026-06-14 · Softwise · kontakt: [email protected]

Regulamin świadczenia usługi wiseTax

Wersja: 1.0 · obowiązuje od 2026-06-14. Usługodawca: Softwise [dane rejestrowe: nazwa/forma prawna, NIP, adres — do uzupełnienia], kontakt: [email protected] (dalej „Softwise" / „Usługodawca"). Usługa: wiseTax — oprogramowanie SaaS dla biur rachunkowych (dalej „Usługa" / „wiseTax").

1. Definicje

Usługa / wiseTax — oprogramowanie udostępniane w modelu SaaS, wspierające pracę biura rachunkowego (ingest faktur, ekstrakcja danych, propozycja dekretacji, portal klienta, integracje KSeF/Comarch Optima).
Biuro — biuro rachunkowe (klient Usługodawcy) korzystające z wiseTax w celu obsługi swoich klientów.
Firma klienta / Klient końcowy — podmiot obsługiwany przez Biuro, którego dane są przetwarzane w wiseTax.
Użytkownik — osoba korzystająca z Usługi (pracownik Biura lub osoba z firmy klienta).
Treści — dane wprowadzone/zaimportowane do Usługi (faktury, dane kontrahentów, kategorie, reguły, notatki).

2. Charakter usługi — co wiseTax JEST, a czym NIE JEST

wiseTax jest narzędziem informatycznym (oprogramowaniem). Softwise dostarcza oprogramowanie, nie świadczy usług księgowych, rachunkowych ani doradztwa podatkowego w rozumieniu odrębnych przepisów.
Funkcje AI (ekstrakcja, klasyfikacja, dekretacja, walidacja) mają charakter wsparcia decyzyjnego (co-pilot). Ostateczną decyzję podejmuje i zatwierdza Użytkownik (księgowy Biura). wiseTax nie podejmuje autonomicznych decyzji wywołujących skutki prawne wobec osób.
Obliczenie podatków, generowanie i wysyłka deklaracji oraz JPK, podpis (kwalifikowany) i UPO realizowane są po stronie systemu ERP (Comarch Optima) i właściwych organów (KSeF/MF). Softwise nie jest bramką do organów podatkowych ani nie składa deklaracji w imieniu Użytkownika.
Za poprawność, kompletność i terminowość rozliczeń swoich klientów odpowiada Biuro (oraz, w zakresie swoich danych, Firma klienta). wiseTax dostarcza dane i propozycje; weryfikacja i akceptacja należą do Biura.

3. Zawarcie umowy, konta, role

Korzystanie wymaga rejestracji Biura (zatwierdzanej przez Usługodawcę) oraz akceptacji Regulaminu.
Role: administrator Biura, księgowy, użytkownik firmy klienta (portal) — z odrębnymi uprawnieniami. Biuro odpowiada za zarządzanie dostępami swoich użytkowników i ich klientów.
Użytkownik zobowiązuje się chronić dane logowania; dla kont o podwyższonych uprawnieniach zalecane jest 2FA.

4. Zasady korzystania

Zakaz: działań bezprawnych, wprowadzania danych bez podstawy prawnej, prób obejścia zabezpieczeń/izolacji najemców, nadmiernego obciążania (limity/rate-limit).
Treści pozostają własnością/odpowiedzialnością wprowadzającego; Softwise przetwarza je jako procesor wyłącznie w celu świadczenia Usługi (patrz Polityka prywatności + umowa powierzenia/DPA).

5. Płatności

Model: opłata wdrożeniowa/abonament (seats) + rozliczenie per pozycja + zużycie wiseAI (tokeny) — wg cennika/umowy.
Szczegóły, okresy i warunki wypowiedzenia określa umowa/cennik. Brak płatności może skutkować zawieszeniem dostępu (dane pozostają zachowane przez okres określony w umowie/Polityce).

6. Dostępność, wsparcie

Softwise dokłada starań o wysoką dostępność (best-effort; ewentualne SLA — w umowie). Możliwe przerwy serwisowe i zależność od dostawców (hosting, ERP, KSeF, GUS).
wiseTax integruje się z usługami zewnętrznymi (KSeF/MF, Comarch Optima przez connector, GUS/BIR). Softwise nie odpowiada za dostępność, zmiany API ani działanie tych systemów zewnętrznych.

7. Charakter „as-is", brak gwarancji wyniku

Usługa dostarczana jest „taka, jaka jest" (as-is) i „w miarę dostępności". Softwise nie gwarantuje bezbłędności ani kompletności wyników ekstrakcji, klasyfikacji i dekretacji AI — są to propozycje wymagające weryfikacji, a nie porada księgowa/podatkowa.
Dane wejściowe i ich legalność (podstawa prawna przetwarzania, zgody klientów końcowych, poprawność dokumentów) są odpowiedzialnością Biura/Firmy klienta.
Kopie zapasowe i ciągłość: źródłem prawdy rozliczeń pozostaje system ERP (Optima); Biuro odpowiada za własne kopie danych źródłowych. Softwise wykonuje kopie w zakresie potrzebnym do świadczenia Usługi, bez gwarancji odtworzenia danych wprowadzonych błędnie przez Użytkownika.

8. Ograniczenie odpowiedzialności

W najszerszym zakresie dozwolonym prawem Softwise nie odpowiada za: decyzje księgowe/podatkowe podjęte przez Użytkownika na podstawie propozycji wiseTax, skutki podatkowe i karno-skarbowe tych decyzji, błędy wynikające z niezweryfikowania wyników AI, dane wprowadzone przez Użytkownika, działanie systemów zewnętrznych (KSeF/Optima/GUS), szkody pośrednie, utracone korzyści, utratę danych po stronie Użytkownika.
Użytkownik jest zobowiązany do weryfikacji wyników AI przed ich wykorzystaniem (zatwierdzeniem, zaksięgowaniem, złożeniem deklaracji). Funkcja „auto-akceptacji po terminie" działa wyłącznie w ramach zasad ustalonych przez Biuro i nie zwalnia Biura z odpowiedzialności merytorycznej.
Całkowita odpowiedzialność Softwise z tytułu Usługi jest ograniczona do wysokości opłat wniesionych przez Biuro za 12 miesięcy poprzedzających zdarzenie (o ile umowa nie stanowi inaczej).
Ograniczeń z ust. 1–3 nie stosuje się do: winy umyślnej, szkód na osobie, oraz obowiązków Softwise jako podmiotu przetwarzającego dane osobowe (RODO art. 28) — w tym zakresie odpowiedzialność wynika z RODO i umowy powierzenia.

9. Własność intelektualna

Oprogramowanie, jego kod, interfejs i marka „wiseTax" pozostają własnością Softwise. Użytkownik otrzymuje niewyłączną, nieprzenoszalną licencję na korzystanie z Usługi w okresie obowiązywania umowy. Treści wprowadzone przez Użytkownika pozostają jego własnością.

10. Dane osobowe

Zasady przetwarzania, role (administrator/procesor), subprocesorzy i prawa podmiotów określa Polityka prywatności oraz umowa powierzenia przetwarzania (DPA) zawierana z Biurem. Co do zasady: Biuro/Firma klienta = administrator danych, Softwise = podmiot przetwarzający (procesor).

11. Zmiany regulaminu, prawo właściwe

Softwise może zmienić Regulamin z powiadomieniem; dalsze korzystanie oznacza akceptację (lub prawo wypowiedzenia).
Prawo właściwe: polskie. Spory — sąd właściwy dla siedziby Usługodawcy (o ile bezwzględnie obowiązujące przepisy nie stanowią inaczej).

Wersja 1.0 (2026-06-14). Do uzupełnienia danymi rejestrowymi Usługodawcy oraz warunkami umowy/cennika. W razie istotnych zmian zakresu — rekomendowana konsultacja z radcą prawnym.

Polityka prywatności wiseTax

Wersja: 1.0 · obowiązuje od 2026-06-14 · Usługa: wiseTax (Softwise) · Kontakt: [email protected].

1. Role: kto jest administratorem, a kto procesorem

wiseTax to SaaS B2B2B. Co do zasady:

Biuro rachunkowe / Firma klienta = administrator danych osobowych (decyduje o celach i środkach przetwarzania w ramach usług księgowych).
Softwise = podmiot przetwarzający (procesor) — przetwarza dane wyłącznie w celu dostarczenia oprogramowania, na udokumentowane polecenie administratora (umowa powierzenia/DPA, RODO art. 28).
W zakresie kont samego Biura (dane logowania, rozliczenia z Softwise) Softwise jest administratorem.

2. Jakie dane przetwarzamy

Konta/Użytkownicy: e-mail, rola, przypisanie do biura/firmy, logi dostępu.
Dane firm i kontrahentów: nazwa, NIP, adres, REGON (z GUS), kraj.
Dokumenty/faktury: numery, daty, kwoty, pozycje, kategorie, dane finansowe (koszty, VAT), pliki źródłowe (PDF/obraz/XML KSeF), notatki klienta dla księgowego (client_note).
Dekretacja i reguły: kategoryzacja pozycji, KUP/NKUP, reguły NL (nl_text).
wiseAI: treść zapytań i odpowiedzi czatu (wiseai_messages), podgląd wiadomości w meteringu (message_preview), zużycie tokenów.
(Docelowo) audio z kanału WhatsApp — po wdrożeniu, z odrębną podstawą i informacją.

3. Cele i podstawy prawne (art. 6 RODO)

Świadczenie Usługi i obsługa księgowa: art. 6 ust. 1 lit. b (umowa) oraz lit. c (obowiązki prawne księgowe/podatkowe administratora).
Bezpieczeństwo, audyt, zapobieganie nadużyciom: lit. f (uzasadniony interes).
Rozliczenia z Softwise: lit. b/c.

4. Subprocesorzy i transfery (do potwierdzenia regionów)

Podmiot	Cel	Region docelowy	Uwaga
Supabase (Postgres/Storage/Auth)	baza, pliki, uwierzytelnianie	EU (Central — Frankfurt)	DPA
AWS (Amazon Bedrock — Claude)	AI: ekstrakcja/dekretacja/wiseAI	eu-central-1 (Frankfurt) — `lib/ksef`/`lib/ai/bedrock.ts`	świadomie EU, nie OpenAI/US
Hetzner (hosting serwera)	hosting aplikacji (Docker)	EU — Norymberga (DE)	DPA (Hetzner GDPR DPA)
Comarch Optima (przez connector Morfeusz, infra Biura)	księgowanie/ERP	u Biura (on-prem/serwer Biura)	dane nie opuszczają środowiska Biura
KSeF / Ministerstwo Finansów	e-faktury (odbiór/wysyłka)	PL (organ)	podstawa: obowiązek prawny
GUS / BIR (REGON)	dane firm po NIP	PL (rejestr publiczny)	dane publiczne
Sentry	monitoring błędów	EU (data residency)	ograniczać PII w logach
cyber_Folks (SMTP)	e-maile transakcyjne	EU (PL)	DPA dostawcy

Transfery poza EOG: dążymy do ich uniknięcia (Bedrock EU). Każdy realny transfer wymaga podstawy (SCC) i ujawnienia.

5. Prawa podmiotów danych (art. 15–22)

Żądania (dostęp, sprostowanie, usunięcie, ograniczenie, przeniesienie, sprzeciw) realizuje administrator (Biuro/Firma klienta); Softwise jako procesor wspiera administratora. ⚠️ Stan: brak dedykowanych flow eksportu/usunięcia danych podmiotu — do zbudowania (patrz audyt). Napięcie: append-only audit_log (niezmienność dla ISO A.12.4) vs prawo do usunięcia — rozstrzygnąć: pseudonimizacja zamiast kasowania logu.

6. Retencja

Dane przechowywane przez okres świadczenia Usługi + okresy wymagane prawem (księgowe/podatkowe — co do zasady 5 lat). Po zakończeniu umowy — usunięcie/zwrot wg DPA. Logi audytowe — wg wymogów ISO/przepisów.

7. Bezpieczeństwo (art. 32)

Izolacja najemców na poziomie bazy (RLS) — dane firmy widzi tylko uprawniony; AI działa w sesji użytkownika (nie service-role).
Szyfrowanie w tranzycie (HTTPS/TLS); sekrety (tokeny KSeF) szyfrowane at-rest (AES-256-GCM, lib/crypto.ts).
Audyt append-only (RODO/ISO), nagłówki bezpieczeństwa + CSP, rate-limiting, 2FA dla super-admina (do włączenia).
Szczegóły i luki: docs/AUDYT_ISO_RODO.md, SECURITY_AUDIT.md.

8. Zautomatyzowane przetwarzanie / AI (art. 22)

Dekretacja i klasyfikacja AI to wsparcie decyzyjne — wynik zatwierdza człowiek (księgowy), więc nie stanowi wyłącznie zautomatyzowanej decyzji wywołującej skutki prawne. Reguła „auto-akceptacji po 10. dniu" działa w ramach polityki Biura i pod jego odpowiedzialnością; podlega informacji wobec klienta końcowego.

9. Naruszenia, kontakt

Procedura zgłaszania naruszeń (art. 33/34): Softwise jako procesor niezwłocznie informuje administratora o naruszeniu.
Kontakt w sprawach danych: [email protected].

Wersja 1.0 (2026-06-14). Hosting: Hetzner (UE, Norymberga). W razie istotnych zmian zakresu przetwarzania — rekomendowana konsultacja z radcą prawnym / IOD.

Umowa powierzenia przetwarzania danych osobowych (DPA)

Powierzenie Biuro (Administrator) → Softwise (Podmiot przetwarzający) zgodnie z RODO art. 28. Stanowi załącznik do Regulaminu/umowy o świadczenie usługi wiseTax.

Wersja: 1.0 · obowiązuje od 2026-06-14 · Kontakt: [email protected].

§1. Strony i rola

Administrator — Biuro rachunkowe korzystające z wiseTax (lub Firma klienta — wg ustaleń).
Podmiot przetwarzający (Procesor) — Softwise, dostawca wiseTax.
Procesor przetwarza dane wyłącznie na udokumentowane polecenie Administratora (poleceniem jest korzystanie z funkcji wiseTax oraz niniejsza Umowa).

§2. Przedmiot, czas, cel, charakter

Przedmiot: przetwarzanie danych osobowych zawartych w dokumentach księgowych i danych firm/kontrahentów wprowadzanych do wiseTax.
Cel: świadczenie usługi wiseTax (ingest faktur, ekstrakcja, propozycja dekretacji, portal klienta, integracje KSeF/Optima/GUS).
Czas: na czas obowiązywania umowy o świadczenie usługi.
Charakter: przetwarzanie zautomatyzowane w infrastrukturze chmurowej (UE).

§3. Rodzaj danych i kategorie osób (Załącznik A)

Kategorie osób: przedsiębiorcy/JDG, reprezentanci i pracownicy firm, kontrahenci, osoby wskazane na fakturach/dokumentach, użytkownicy systemu.
Rodzaje danych: dane identyfikacyjne i kontaktowe (imię/nazwisko, nazwa, NIP, REGON, adres, e-mail), dane finansowe (kwoty, pozycje faktur, VAT), treść dokumentów i notatek, dane logowania/logi, (docelowo) nagrania głosowe.
Brak (co do zasady) danych szczególnych kategorii (art. 9). Jeśli wystąpią — Administrator informuje Procesora.

§4. Obowiązki Procesora (art. 28 ust. 3)

Przetwarza dane tylko na polecenie Administratora; informuje, gdy polecenie narusza RODO.
Zapewnia poufność osób upoważnionych do przetwarzania.
Stosuje środki bezpieczeństwa (art. 32) — m.in. izolacja najemców (RLS), szyfrowanie w tranzycie (TLS) i sekretów at-rest (AES-256-GCM), kontrola dostępu per rola, dziennik audytowy append-only, kopie zapasowe, MFA dla kont uprzywilejowanych.
Dalsze powierzenie (sub-procesorzy) — patrz Załącznik B; Procesor zawiera z nimi DPA o równoważnych obowiązkach i informuje o zmianach (z prawem sprzeciwu Administratora).
Pomoc Administratorowi w realizacji praw podmiotów (art. 15–22) oraz obowiązków z art. 32–36 (bezpieczeństwo, zgłaszanie naruszeń, DPIA).
Zgłaszanie naruszeń — bez zbędnej zwłoki po stwierdzeniu informuje Administratora.
Po zakończeniu umowy — usuwa lub zwraca dane (wg wyboru Administratora) i kasuje kopie, chyba że prawo nakazuje przechowywanie.
Udostępnia informacje niezbędne do wykazania zgodności i umożliwia audyty/inspekcje.

§5. Sub-procesorzy (Załącznik B)

Administrator wyraża zgodę ogólną na korzystanie z sub-procesorów wymienionych w docs/SUBPROCESORZY.md (rejestr). Procesor informuje o zamierzonych zmianach; Administrator może wnieść sprzeciw.

§6. Transfery poza EOG

Przetwarzanie odbywa się w UE: hosting Hetzner (Norymberga, DE), baza Supabase (Frankfurt), AI AWS Bedrock eu-central-1 (Frankfurt). Procesor nie dokonuje transferów poza EOG; ewentualny transfer odbywałby się na ważnej podstawie (SCC) i byłby ujawniony.

§7. Odpowiedzialność

Odpowiedzialność stron zgodnie z RODO i umową główną. Procesor odpowiada w zakresie obowiązków nałożonych RODO bezpośrednio na podmiot przetwarzający.

Załącznik A — szczegóły przetwarzania

(jak §2–§3 powyżej; doprecyzować per umowa)

Załącznik B — lista sub-procesorów

Aktualna lista: docs/SUBPROCESORZY.md.

Wersja 1.0 (2026-06-14). Dane rejestrowe stron i ewentualny IOD uzupełniane przy zawarciu umowy z Biurem. W razie istotnych zmian — konsultacja z radcą prawnym.

Rejestr sub-procesorów wiseTax

Część dokumentacji RODO art. 28/30. „Status DPA" = czy zaakceptowano i zarchiwizowano potwierdzenie (PDF/link) w folderze compliance.

Wersja: 1.0 · obowiązuje od 2026-06-14. Administrator (Biuro) wyraża zgodę ogólną na poniższych sub-procesorów (DPA §5); o zmianach informujemy z prawem sprzeciwu.

Sub-procesor	Cel przetwarzania	Region docelowy	Gdzie zaakceptować DPA	Status DPA
Amazon Web Services (Bedrock — Claude)	AI: ekstrakcja, dekretacja, wiseAI	EU — eu-central-1 (Frankfurt)	DPA wbudowane w AWS Service Terms (AWS GDPR DPA — obowiązuje z umową AWS)	☐ pobrać „AWS GDPR DPA" do archiwum
Supabase	Baza (Postgres), pliki (Storage), uwierzytelnianie (Auth)	EU (wybrać/potwierdzić region projektu)	Dashboard → Organization → Legal/Compliance (akceptacja DPA)	☐ zaakceptować + region EU
Hetzner Online GmbH	Hosting serwera aplikacji (Docker)	EU — Norymberga (DE)	Hetzner GDPR DPA (Data Processing Agreement)	☐ pobrać/zarchiwizować DPA
Sentry	Monitoring błędów	EU data residency	Self-serve DPA (pobranie) + EU region	☐ zaakceptować, ograniczać PII w logach
cyber_Folks S.A. (SMTP)	E-maile transakcyjne (powiadomienia)	EU (PL)	DPA w panelu dostawcy	☐ zaakceptować

Podmioty NIE będące sub-procesorami (dla jasności)

Comarch Optima (przez connector Morfeusz) — działa w infrastrukturze Biura (on-prem/serwer Biura); dane nie trafiają do Softwise w tym torze. Relacja wg umowy Biura z Comarch.
KSeF / Ministerstwo Finansów — organ publiczny; podstawa: obowiązek prawny (nie powierzenie).
GUS / BIR (REGON) — rejestr publiczny; dane firm dostępne publicznie.

Jak „udokumentować" (do zamknięcia luki #1 z audytu)

Dla każdego sub-procesora zaakceptuj DPA w jego panelu / pobierz pre-podpisany dokument.
Zapisz potwierdzenie (PDF/screenshot/link) w jednym miejscu (folder „compliance").
Zaznacz status ☑ w tej tabeli + datę.
Przy zmianie sub-procesora — zaktualizuj rejestr i poinformuj Biura (prawo sprzeciwu, DPA §5).

Wzór roboczy Softwise. Wymaga uzupełnienia i akceptacji radcy prawnego/IOD.

wiseTax — Audyt zgodności ISO 27001 + RODO/GDPR

Rola audytora: senior security engineer + inspektor ochrony danych (DPO/IOD)
Data: 2026-06-10
Zakres: aktualny kod repozytorium wisePodatki (gałąź main, commit a88726f) — SaaS co-pilot dla polskich biur rachunkowych. Stack: Next.js 14.2.35 (App Router) + Supabase Postgres/RLS + AWS Bedrock (eu-central-1) + Vercel.
Metoda: audyt statyczny kodu. Każde ustalenie cytuje plik:linia. Stan żywej bazy (Supabase advisors, dump polityk, istnienie bucketu, regiony w dashboardach) NIE był weryfikowany — patrz sek. 8.
Powiązanie: dokument bazuje na poprzednim audycie bezpieczeństwa SECURITY_AUDIT.md (2026-06-09 + remediacja 2026-06-10) i go rozszerza o pełną perspektywę ISO 27001 (Annex A) oraz RODO. Status zamknięcia F-01…F-16 odniesiony w sek. 4.

1. Streszczenie wykonawcze

wiseTax prezentuje ponadprzeciętny jak na MVP poziom dojrzałości bezpieczeństwa technicznego. Izolacja najemców (tenant isolation) jest egzekwowana w warstwie bazy danych przez spójny model RLS oparty na funkcjach SECURITY DEFINER z przypiętym search_path (can_access_client, current_org_id, current_role_name — 0001_init.sql:256-291, wzmocnione w 0012). Sekrety KSeF (certyfikat + klucz prywatny) są szyfrowane at-rest AES-256-GCM (lib/crypto.ts, realnie wpięte w app/panel/biuro/klienci/actions.ts:288 i app/panel/klient/ksef/actions.ts:29). AI działa przez Bedrock w regionie EU (lib/ai/bedrock.ts:10). Audit log jest append-only z podwójną ochroną (row-level + statement-level TRUNCATE: 0004, 0015). Rate limiting został realnie wpięty (/api/upload, /api/demo/gate). MFA super-admina jest flag-gated i fail-closed (lib/auth/superadmin.ts). CSP została rozszerzona o default-src/script-src/connect-src (next.config.js:11-24).

Materialne ryzyko nie jest architektoniczne, lecz dotyczy zgodności RODO i higieny operacyjnej: brak warstwy dokumentacyjnej RODO (rejestr czynności art. 30, umowy powierzenia/DPA z subprocesorami, procedura naruszeń art. 33/34, DPIA), brak jakichkolwiek flow realizacji praw podmiotów (art. 15–22 — dostęp/sprostowanie/usunięcie/przenoszenie), napięcie retencja vs. prawo do usunięcia (audit_log append-only), oraz niedopracowany mechanizm zautomatyzowanej akceptacji kosztów (reguła 10. dnia — acceptance-sweep) bez jawnej oceny pod kątem art. 22. Pozostają też resztkowe ryzyka techniczne: hasła demo w historii gita (kod produkcyjny już je usuwa, ale rotacja to akcja otwarta), Next.js 14.2.35 z otwartymi „high" advisories (świadomie odroczone do migracji na Next 15), brak antywirusa na uploadzie, brak zdefiniowanego store'a dla klucza Optima/Morpheus.

Ogólny poziom ryzyka: ŚREDNI (Medium). Brak potwierdzonej w kodzie ścieżki wycieku cross-tenant. Dominującym wektorem ryzyka jest zgodność formalna RODO (dokumentacja + prawa podmiotów), która dla produktu przetwarzającego dane finansowe polskich firm jest warunkiem koniecznym przed komercyjnym uruchomieniem, nie tylko dobrą praktyką.

Liczność ustaleń: Critical 1 · High 3 · Medium 6 · Low 5 · Info 3

2. Mapa danych / PII + role administrator/procesor + przepływ

2.1 Inwentarz danych osobowych i wrażliwych biznesowo (A.8)

Kategoria danych	Gdzie	Wrażliwość	Dowód
NIP, REGON, nazwa, adres firmy/klienta	`clients` (`regon`,`address` — `0014_gus_fields.sql`), `contractors`	PII osób fiz. prowadzących DG (NIP=PESEL-pochodny)	`0001_init.sql`, `0014`
Dane kontrahentów (nazwa, NIP)	`contractors`, `document_extractions.data`	PII jednoosobowych DG	`0001`
Faktury (dane finansowe, kwoty, pozycje)	`documents`, `document_extractions`, `issued_invoices`	dane finansowe — szczególna wrażliwość biznesowa	`0010_issued_invoices.sql`
Notatki klienta dla księgowego	`documents.client_note`	wolny tekst → potencjalnie PII	`0013_document_client_acceptance.sql:7`
Pliki źródłowe (PDF/skany faktur)	Storage bucket `documents` (prywatny)	dane finansowe + możliwe PII na skanach	`0001:452`, polityki `0001:461-474`
Treść rozmów z wiseAI	`wiseai_messages.text`	wolny tekst, potencjalnie PII	`0016_wiseai_conversations.sql:21`
Podgląd zapytań do AI (metering)	`wiseai_token_usage.message_preview`	„skrót pytania" — komentarz deklaruje „bez PII pełnej treści", ale to skrót wolnego tekstu	`0008_wiseai_token_usage.sql:23`
Reguły dekretacji (nl_text)	`accounting_rules`	wzorzec→efekt; deklarowane „nie dane klienta"	`0018_rule_scope.sql:1-4`
Certyfikat + klucz prywatny KSeF	`ingestion_sources.config` (szyfrowane)	krytyczny sekret (tożsamość podatkowa firmy)	`0001:192`, `lib/crypto.ts`
Konta użytkowników (e-mail, rola)	`users`, Supabase Auth	PII	`0001`
Audio (WhatsApp voice)	docelowo (`feature='wiseai_voice'`)	dane głosowe — PII; jeszcze nie przetwarzane	`0008:20` (placeholder)
IP + user-agent	`audit_log.ip`, `audit_log.user_agent`	PII (dane telemetryczne)	`0004:13-14`, `lib/audit.ts:62-64`

2.2 Role RODO (administrator vs procesor) — KLUCZOWE dla B2B2B

Model 4-warstwowy (platforma / biuro / firma-klient / user-klienta). Przepływ:

`` PODMIOT DANYCH (kontrahent na fakturze, pracownik, klient indywidualny) │ dane trafiają do → │ FIRMA-KLIENT biura ── jest ADMINISTRATOREM swoich danych (faktury, kontrahenci) │ powierza przetwarzanie → BIURO RACHUNKOWE ── PROCESOR firmy-klienta (usługa księgowa) / jednocześnie ADMINISTRATOR własnych danych (konta, rozliczenia) │ powierza przetwarzanie (narzędzie SaaS) → SOFTWISE / wiseTax ── SUB-PROCESOR (dostawca oprogramowania) wobec biura; PROCESOR/SUB-PROCESOR danych firm-klientów │ korzysta z dalszych subprocesorów → Supabase / AWS Bedrock / Vercel / GUS / KSeF / SMTP / Sentry ``

Wniosek prawny: Softwise występuje w roli podmiotu przetwarzającego (procesor), a wobec danych firm-klientów biura — dalszego podmiotu przetwarzającego (sub-procesor). To wymaga łańcucha umów powierzenia (art. 28 RODO): biuro↔Softwise (DPA) oraz zgody na sub-przetwarzanie i DPA z każdym dalszym subprocesorem (Supabase, AWS, Vercel, Sentry, dostawca SMTP). Brak jakiegokolwiek śladu tych dokumentów w repo — to ustalenie R-01.

GUS BIR i KSeF/MF mają charakter szczególny: GUS to rejestr publiczny (pobranie danych podmiotu — lib/lookup/gus.ts), KSeF to organ administracji (obowiązek prawny — art. 6 ust. 1 lit. c). Nie są to klasyczni subprocesorzy w sensie art. 28, lecz odbiorcy/źródła w ramach realizacji obowiązku prawnego.

2.3 Podstawa prawna (art. 6)

Przetwarzanie faktur/kontrahentów: art. 6 ust. 1 lit. c (obowiązek prawny — ustawa o rachunkowości, ustawa o VAT, Ordynacja podatkowa) realizowany przez administratora (firmę), wykonywany przez procesora (biuro) narzędziem Softwise.
Konta biura/użytkowników: art. 6 ust. 1 lit. b (wykonanie umowy SaaS).
Telemetria/metering AI: art. 6 ust. 1 lit. f (uzasadniony interes — rozliczenie usługi), wymaga testu równowagi.
Status w kodzie: podstaw prawnych nie ma udokumentowanych nigdzie (brak polityki prywatności, klauzul informacyjnych art. 13/14). Ustalenie R-02.

3. Tabela subprocesorów

Nazwa	Cel	Region (deklarowany)	DPA potrzebny	Transfer poza EOG	Dowód / uwaga
Supabase (Postgres, Auth, Storage)	Główna baza danych, uwierzytelnianie, pliki	„EU / Frankfurt" (komentarz)	TAK (art. 28)	Nie, jeśli region EU i Auth/infra w EU — niezweryfikowane	`.env.local.example:1` komentarz; region NIE potwierdzony w dashboardzie (sek. 8)
AWS Bedrock	Model Claude (ekstrakcja/dekretacja/asystent)	`eu-central-1` (Frankfurt)	TAK	Nie (region EU wymuszony w kliencie)	`lib/ai/bedrock.ts:10` `AWS_REGION ?? 'eu-central-1'` — domyślnie EU; AWS DPA + zero-retention do potwierdzenia umownie
Vercel	Hosting Next.js, cron, edge/middleware	nieokreślony w repo	TAK	Możliwy (Vercel domyślnie US; funkcje/region do ustawienia)	`vercel.json` — brak deklaracji `regions`; ryzyko transferu jeśli funkcje serwerowe w US
GUS BIR1 (stat.gov.pl)	Lookup danych firmy po NIP (rejestr publiczny)	PL	Nie (rejestr publiczny, odbiorca)	Nie	`lib/lookup/gus.ts:24`
KSeF / Ministerstwo Finansów	Wymiana e-faktur (obowiązek prawny)	PL	Nie (organ, art. 6 lit. c)	Nie	`lib/ksef/*`, `.env.local.example:39-42`
Dostawca SMTP (cyber-folks)	Wysyłka powiadomień e-mail	PL (cyber-folks = pl)	TAK	Nie (jeśli PL)	`lib/email.ts:1` (`SMTP_`); UWAGA:* `.env.local.example:54-56` deklaruje `RESEND_API_KEY` (US) — niespójność, kod używa SMTP, env-example mówi Resend
Sentry	Monitoring błędów / APM	zależny od org Sentry (US lub EU)	TAK	Możliwy (Sentry US domyślnie)	`sentry.server.config.ts`, DSN z env; region NIE potwierdzony
OpenAI (fallback)	Deklarowany fallback AI (EU residency)	„EU data residency" (env)	TAK jeśli użyty	Możliwy	`.env.local.example:35-37`; w kodzie NIE używany — `openai` jest w `package.json:23`, ale brak call-site (provider robi tylko Bedrock — `lib/ai/provider.ts:86`). Martwa zależność.

Wniosek: żaden DPA nie jest udokumentowany w repo. Vercel i Sentry to realne ryzyko transferu poza EOG (domyślnie US). Niespójność SMTP/Resend w .env.local.example to dług dokumentacyjny.

4. ISO 27001 (Annex A) — kontrola / stan / dowód / luka / rekomendacja

Kontrola	Stan	Dowód (plik:linia)	Luka	Rekomendacja
A.5 Polityki bezpieczeństwa	❌	brak polityk w repo; `SECURITY_PLAN.md`, `BANKING_SECURITY_METHODS.md` to plany techniczne, nie polityki ISMS	Brak formalnej polityki bezpieczeństwa informacji, polityki dostępu, klasyfikacji danych	Opracować zestaw polityk ISMS (proces/dokument, nie kod)
A.8 Zarządzanie aktywami / PII inventory	⚠️	inwentarz wyprowadzalny ze schematu (sek. 2.1); komentarze klasyfikujące dane (`0008:23`, `0001:192`)	Brak formalnego rejestru aktywów i klasyfikacji danych	Sformalizować inwentarz PII (sek. 2.1 jako baza)
A.9 Kontrola dostępu — RLS	✅	`0001:256-360`, `can_access_client` + `current_org_id` + `current_role_name`, `FORCE RLS` + `REVOKE` na tabelach service-role (`0001:420-422`)	—	Utrzymać inwariant „RLS = granica"; zweryfikować na żywej bazie (sek. 8)
A.9 — hardening pending org	✅	`0012_rls_require_active_org.sql:20-27` — staff czyta dane klienta tylko gdy `organizations.status='active'`	—	Domknięte (było F-05)
A.9 — eskalacja roli	✅	trigger `prevent_role_change` (`0001:296-315`); RLS users self/staff-only	Niezweryfikowane na żywej bazie	Potwierdzić trigger w prod
A.9 — super-admin	✅	allowlista maili `lib/auth/superadmin.ts:4-11`; egzekwowane `app/admin-softwise/page.tsx:17,57`	Allowlista w env (nie tabela) — akceptowalne na MVP	Docelowo `platform_admins` z audytem nadań
A.9 — MFA	⚠️	`superAdminMfaSatisfied` fail-closed (`superadmin.ts:26-34`), enforce na panelu i akcji (`page.tsx:18,59`)	Flag-gated (`REQUIRE_ADMIN_MFA=false` domyślnie — `.env.local.example:21`); MFA dla zwykłych userów biura/klienta BRAK	Włączyć `REQUIRE_ADMIN_MFA=true` w prod; rozważyć MFA dla roli `admin` biura
A.12.4 Logowanie / audit append-only	✅	`0004:20-32` (UPDATE/DELETE block), `0015:6-17` (TRUNCATE block), `lib/audit.ts` jeden punkt	Brak hash-chaining/WORM; `logEvent` połyka błędy cicho (`audit.ts:51-53`); zdarzenia AUTH login/logout NIE są logowane (signIn po stronie klienta — `app/logowanie/page.tsx:34`)	Logować AUTH server-side; alert gdy `logEvent` pada; rozważyć eksport WORM dla pełnej niezaprzeczalności
A.12.3 Kopie zapasowe	⚠️	poleganie na Supabase backups (nieudokumentowane); `demo-purge` (`app/api/cron/demo-purge/route.ts`)	Brak udokumentowanej polityki backupu/odtwarzania, brak testów restore	Udokumentować RPO/RTO i backupy Supabase (proces)
A.12.6 Zarządzanie podatnościami	⚠️	Dependabot (`.github/dependabot.yml`), CI `audit-critical` blokujący (`.github/workflows/ci.yml`)	Next.js 14.2.35 — otwarte „high" (image-optimizer DoS, RSC DoS, request-smuggling) świadomie odroczone do Next 15 (SECURITY_AUDIT remediacja, F-04)	Zaplanować migrację Next 15 (breaking: async `params`/`cookies`) jako osobne zadanie
A.12.2 Ochrona przed złośliwym kodem (upload)	⚠️	magic-byte validation `app/api/upload/route.ts:42-47`, limit rozmiaru, dedup hash	Brak skanu antywirusowego wgrywanych plików (PDF/obraz)	Dodać AV-scan (np. ClamAV/usługa) w pipeline ekstrakcji
A.13 Bezpieczeństwo komunikacji — in-transit	✅	HSTS preload `next.config.js:28`; HTTPS wymuszony; SMTP secure 465 (`lib/email.ts:18-20`); GUS/KSeF przez https	—	OK
A.13/A.14 — CSP	⚠️	pełne CSP `next.config.js:11-24` (`default-src 'self'`, `connect-src` Supabase/Sentry)	`script-src` zawiera `'unsafe-inline' 'unsafe-eval'` (App Router hydration) — osłabia ochronę XSS	Docelowo nonce-based CSP (wymaga przebudowy middleware)
A.13 — CSRF	✅	origin-check w middleware (`middleware.ts:13-42`), exempt-list świadoma (cron/KSeF/mail)	—	OK
A.14 — szyfrowanie at-rest sekretów	✅	AES-256-GCM `lib/crypto.ts`, fail-closed bez klucza; wpięte w KSeF cert/token (`klienci/actions.ts:288`, `klient/ksef/actions.ts:29`, odczyt `ksef/sync.ts:70-72`)	`decryptSecret` toleruje wartości jawne (`crypto.ts:27`) — dla dev/migracji, ale ryzyko jeśli wartość zapisana plaintext przejdzie	Po migracji wymusić, że wszystkie `ingestion_sources.config` są `enc:v1:`
A.14 — rate limiting	✅	`checkRateLimit` w `/api/upload` (`route.ts:27`), `checkIpRateLimit` w `/api/demo/gate` (`gate/route.ts:29`)	Login (Supabase signIn po stronie klienta) bez własnego limitera — poleganie na limitach Supabase Auth; fail-open gdy tabela `rate_limits` niezmigrowana	Udokumentować limity Supabase Auth; rozważyć limiter przed login
A.14 — secure SDLC / sekrety	✅/⚠️	`.gitignore` chroni `.env*`; hasła demo dev-gated (`app/logowanie/page.tsx:13-20`)	Hasła demo nadal w historii gita (komentarz `page.tsx:12` to przyznaje); rotacja = akcja otwarta	Zrotować hasła (`[email protected]` i in.); rozważyć purge historii
A.14 — store klucza Optima/Morpheus	⚠️	`lib/erp/morpheus.ts`; komentarz ostrzega przed `organizations.settings`	Brak zaimplementowanego service-role-only store na klucz per-biuro (było F-07)	Zbudować tabelę sekretów `REVOKE ALL FROM anon,authenticated` + `FORCE RLS` przed prod-zapisem do Optimy
A.15 Relacje z dostawcami	❌	sek. 3 — subprocesorzy zidentyfikowani	Brak DPA z którymkolwiek subprocesorem; ryzyko transferu Vercel/Sentry	Zawrzeć DPA (Supabase/AWS/Vercel/Sentry/SMTP); ustawić region EU dla Vercel funkcji i Sentry
A.16 Zarządzanie incydentami	❌	brak	Brak procedury reakcji na incydent i zgłaszania naruszeń	Opracować procedurę IR + zgłaszanie do PUODO (72h) — łączy się z RODO art. 33
A.17 Ciągłość działania	❌	brak	Brak planu BCP/DR; backupy nieudokumentowane	Opracować BCP/DR (proces)
A.18 Zgodność	⚠️	audit_log pod ISO, szyfrowanie	Brak rejestru wymagań prawnych, brak mapowania na RODO/UoR	Rejestr zgodności + niniejszy audyt jako wejście

5. RODO/GDPR — artykuł / stan / dowód / luka / rekomendacja

Artykuł	Stan	Dowód	Luka	Rekomendacja
art. 6 — podstawa prawna	⚠️	sek. 2.3 (wyprowadzona)	Brak udokumentowanych podstaw, brak polityki prywatności	Opisać podstawy + polityka prywatności (dokument)
art. 13/14 — obowiązek informacyjny	❌	brak klauzul w repo	Brak klauzul informacyjnych dla podmiotów danych	Klauzule + polityka (dokument)
art. 28 — powierzenie / sub-przetwarzanie	❌	sek. 2.2, sek. 3	Brak DPA biuro↔Softwise i Softwise↔subprocesorzy; brak listy subprocesorów dla klientów	Wzorzec DPA + publiczna lista subprocesorów (R-01)
art. 15 — dostęp	❌	grep: brak endpointu/flow	Brak mechanizmu wglądu danych podmiotu	Endpoint/proces eksportu danych podmiotu (kod + proces)
art. 16 — sprostowanie	⚠️	edycja danych klienta przez UI (pośrednio)	Brak dedykowanego flow „sprostowanie na żądanie podmiotu"	Procedura obsługi żądań sprostowania
art. 17 — usunięcie / prawo do bycia zapomnianym	❌	brak `deleteUser`/erasure flow (grep)	Brak flow usunięcia; napięcie z append-only audit_log (`0004`,`0015`) i obowiązkiem przechowywania ksiąg (5 lat, UoR)	Procedura: usuwalne dane vs. dane objęte obowiązkiem retencji; audit_log = wyjątek (art. 17 ust. 3 lit. b — obowiązek prawny) — udokumentować
art. 18 — ograniczenie	❌	brak	Brak flagowania „ograniczone przetwarzanie"	Procedura
art. 20 — przenoszenie	❌	brak eksportu (poza `lib/erp/export.ts` — ERP, nie podmiot)	Brak eksportu danych podmiotu w formacie strukturalnym	Eksport JSON/CSV per firma-klient
art. 22 — zautomatyzowane decyzje	⚠️	auto-akceptacja kosztów reguła 10. dnia — `app/api/cron/acceptance-sweep/route.ts:46-63` (actorType:`ai`, status→`approved`, `auto_accepted=true`); dekretacja AI (`lib/ai/index.ts`)	Auto-akcept zmienia status dokumentu bez decyzji klienta. Czy to „decyzja wywołująca skutki prawne"? Argument ZA: to operacja księgowa rodząca skutki podatkowe. Argument PRZECIW: to brak sprzeciwu w terminie ustalonym umownie (default proceduralny), z powiadomieniem (`acceptance-sweep:81-87`) i audytem (`:55-60`), odwracalna przez biuro	Udokumentować jako decyzję proceduralną z prawem sprzeciwu PRZED 10. dniem (nagi są wysyłane); zapewnić ścieżkę odwołania/korekty po auto-akcepcie; rozważyć info w regulaminie. Dekretacja AI nie jest „w pełni zautomatyzowana" (biuro akceptuje) — niskie ryzyko
art. 30 — rejestr czynności	❌	brak	Brak RCPD/RCP	Opracować rejestr (procesor — art. 30 ust. 2)
art. 32 — bezpieczeństwo	✅	RLS, szyfrowanie at-rest (`crypto.ts`)/in-transit (HSTS), MFA (flag), rate-limit, audit	Backupy/AV/MFA-userów niepełne (patrz ISO)	Domknąć luki techniczne z sek. 4
art. 33/34 — zgłaszanie naruszeń	❌	brak	Brak procedury 72h do PUODO + powiadamiania podmiotów	Procedura naruszeń (łączy z A.16)
art. 35 — DPIA	⚠️	profilowanie AI + przetwarzanie na dużą skalę danych finansowych	DPIA prawdopodobnie wymagana: systematyczne, zautomatyzowane przetwarzanie (AI-dekretacja), dane finansowe na dużą skalę, planowane dane głosowe	Przeprowadzić DPIA przed prod (dokument)
art. 44+ — transfery	⚠️	sek. 3	Vercel/Sentry/OpenAI ryzyko transferu do US	Wymusić region EU lub SCC/DPF; wyłączyć martwy OpenAI lub potwierdzić EU

6. Top 10 ustaleń wg severity

#	Severity	Ustalenie	Dowód (plik:linia)
1	Critical	Brak łańcucha umów powierzenia (DPA) i listy subprocesorów (art. 28). Softwise jest sub-procesorem danych finansowych firm; bez DPA przetwarzanie jest niezgodne z RODO. Dotyczy też Supabase/AWS/Vercel/Sentry/SMTP.	sek. 2.2, sek. 3; brak dokumentów w repo
2	High	Brak flow realizacji praw podmiotów (art. 15–20) — dostęp, sprostowanie, usunięcie, przenoszenie. Grep nie wykrył żadnego endpointu/procedury.	brak `deleteUser`/eksport-podmiotu; `lib/erp/export.ts` to ERP, nie podmiot
3	High	Brak warstwy dokumentacyjnej RODO/ISMS — polityka prywatności, klauzule art. 13/14, rejestr art. 30, procedura naruszeń art. 33/34, DPIA art. 35.	sek. 4 (A.5/A.16), sek. 5
4	High	Next.js 14.2.35 — otwarte „high" advisories (image-optimizer DoS, RSC DoS, request-smuggling). Świadomie odroczone do Next 15.	`package.json:21`; SECURITY_AUDIT F-04
5	Medium	Auto-akceptacja kosztów (reguła 10.) bez jawnej oceny art. 22 i bez udokumentowanej ścieżki sprzeciwu/odwołania.	`app/api/cron/acceptance-sweep/route.ts:46-63`
6	Medium	Ryzyko transferu poza EOG: Vercel + Sentry (domyślnie US), `vercel.json` bez `regions`; Sentry DSN bez wymuszenia regionu.	`vercel.json`, `sentry.server.config.ts`
7	Medium	Hasła demo w historii gita (kod prod już je usuwa via `NODE_ENV`, ale historia je zawiera) — wymagana rotacja.	`app/logowanie/page.tsx:12-20` (komentarz przyznaje)
8	Medium	Brak antywirusa na uploadzie plików (PDF/obraz) — tylko magic-byte.	`app/api/upload/route.ts:42-47`
9	Medium	Brak store'a sekretu Optima/Morpheus (was F-07) — ryzyko wycieku klucza do org-members jeśli wstawiony do `settings`.	`lib/erp/morpheus.ts`; brak tabeli sekretów
10	Low	Zdarzenia AUTH (login/logout) nie trafiają do audit_log; `logEvent` połyka błędy cicho; niespójność SMTP/Resend w env-example; `connect-src`/`script-src 'unsafe-inline'`.	`lib/audit.ts:51-53`; `app/logowanie/page.tsx:34`; `.env.local.example:54-56`; `next.config.js:14`

7. Plan remediacji

Priorytet 1 — blokery przed komercyjnym uruchomieniem (głównie DOKUMENT/PROCES)

DPA + lista subprocesorów (art. 28) — wzorzec umowy powierzenia biuro↔Softwise, DPA z każdym subprocesorem (Supabase/AWS/Vercel/Sentry/SMTP), publiczna lista subprocesorów. [proces/dokument] — ustalenie #1.
Pakiet dokumentów RODO — polityka prywatności, klauzule art. 13/14, rejestr czynności art. 30 (ust. 2 dla procesora), procedura naruszeń art. 33/34, DPIA art. 35. [dokument] — #3.
Wymuszenie regionu EU — Vercel (regions w konfiguracji funkcji/projektu), Sentry (org EU), wyłączenie/potwierdzenie OpenAI fallback. [kod/konfiguracja] — #6.

Priorytet 2 — flow i hardening (KOD)

Prawa podmiotów (art. 15/17/20) — endpointy/procedury eksportu i usunięcia z jawnym wyłączeniem danych objętych obowiązkiem retencji (księgi 5 lat, audit_log). [kod + proces] — #2.
Migracja Next 15 — osobne, przetestowane zadanie (breaking: async params/cookies). [kod] — #4.
Art. 22 dla auto-akceptacji — udokumentować jako default proceduralny z prawem sprzeciwu, dodać ścieżkę korekty po auto-akcepcie. [kod + dokument] — #5.
Rotacja haseł demo + rozważenie purge historii gita. [proces] — #7.
AV-scan uploadu, store sekretu Optima/Morpheus (service-role-only). [kod] — #8, #9.

Priorytet 3 — domknięcia obronne (KOD/PROCES)

Logowanie AUTH server-side; alert na błąd logEvent; ujednolicenie env-example (SMTP vs Resend); rozważenie nonce-CSP; włączenie REQUIRE_ADMIN_MFA=true w prod; MFA dla roli admin biura; udokumentowanie backupów (RPO/RTO), BCP/DR, polityk ISMS (A.5/A.17). — #10 i pozostałe.

Bilans: dominują braki dokumentacyjno-procesowe RODO/ISMS (P1), nie wady kodu. Warstwa techniczna jest solidna; zgodność formalna jest niedojrzała.

8. Czego NIE dało się zweryfikować (dług weryfikacyjny)

Stan żywej bazy Supabase: supabase db advisors --type security (zero ERROR), dump rzeczywistych polityk RLS, potwierdzenie FORCE RLS na audit_log/jobs/rate_limits/system_logs, faktyczne wgranie migracji 0001–0018 w kolejności. Migracje 0006–0009 noszą notatki „wymaga migracji" — możliwa rozbieżność prod vs. plik.
Istnienie i prywatność bucketu documents w prod (plik tworzy go jako public=false — 0001:452-458, ale stan żywy niezweryfikowany).
Region Supabase (deklarowany „EU/Frankfurt" tylko w komentarzu env), region funkcji Vercel (brak regions), region organizacji Sentry — wymagają sprawdzenia w dashboardach.
AWS Bedrock zero-retention + DPA — region EU jest w kodzie (bedrock.ts:10), ale warunki umowne/retencja są poza repo.
Czy .env.local kiedykolwiek trafił do historii gita (poza zakresem audytu statycznego plików).
Faktyczna konfiguracja Supabase Auth rate-limits (login polega na niej, brak własnego limitera).
Realne treści przetwarzane przez AI (stub vs. Bedrock — AI_PROVIDER decyduje; w repo domyślnie stub).

Audyt wyłącznie do odczytu kodu — nie modyfikowano kodu aplikacji (zapisano jedynie niniejszy raport). Przed sign-offem ISO/RODO wykonać weryfikację żywej bazy (sek. 8) oraz domknąć Priorytet 1 (DPA + dokumentacja RODO).