diff --git a/inbox/uporzadkowane_notatki.md b/inbox/uporzadkowane_notatki.md
new file mode 100644
index 0000000..ad95a63
--- /dev/null
+++ b/inbox/uporzadkowane_notatki.md
@@ -0,0 +1,50 @@
+# Notatki ze spotkania
+
+## Spotkanie 1: Strategia patchowania i optymalizacja operacji
+
+**Tematy dyskusji:**
+- Zespół zdecydował o kontynuowaniu patchowania środowisk produkcyjnych i nieprodukcyjnych w okresie letnim, z wyjątkiem produkcji w Szwecji, Danii, Norwegii i Finlandii z powodu obecnych ograniczeń.
+- Leszek wyjaśnił, że konieczna jest zmiana w projekcie automatyzacji, aby umożliwić zatrzymanie patchowania na konkretnych rynkach, i potwierdził, że jest to wykonalne.
+- Omówiono potrzebę wykluczania lub nieustawiania niestandardowych polityk (w tym dynamicznych i statycznych) dla niektórych krajów.
+- Zespoły inżynieryjne i platformowe współpracują nad optymalizacją wymiany certyfikatów w całej Europie, aby zmniejszyć obciążenie operacyjne ze względu na skracające się okresy ważności certyfikatów.
+
+**Zgodność z RODO i Logowanie systemów:**
+- Dyskutowano nad wdrażaniem logowania systemów dla wszystkich usług w Europie. Logi będą wysyłane do Splunka i przekazywane do działu bezpieczeństwa, z wyłączeniem danych chronionych przez RODO.
+- Oleksandr wyraził obawy dotyczące niejasnych planów przyszłego gromadzenia logów – mogą one być zbierane bez odpowiedniej weryfikacji, co niesie ryzyko problemów ze zgodnością z RODO.
+- Leszek podkreślił, że wszelkie zmiany w zbieraniu logów mające wpływ na produkcję muszą wymagać procedury Change Request (CR) i obejmować wszystkie dotknięte elementy konfiguracji.
+- Zgodzono się na potrzebę ogólnoeuropejskiego rozwiązania zapewniającego zgodność logowania SecOps z RODO, unikając obsługiwania wyjątków na poziomie pojedynczych serwerów.
+- Zasugerowano konsultacje z Larsem Gehringiem w sprawach definicji i wymogów RODO (które są omawiane na firmowych szkoleniach bezpieczeństwa). Lars ma poprowadzić dyskusje z działem prawnym i compliance, a wszelkie przyszłe zmiany w zbieraniu logów powinny być przez nich zatwierdzane.
+- Uzgodniono, że konieczne jest dostarczenie przykładów chronionych danych oraz nazw plików do wykluczenia (zadanie ręczne, wymagające koordynacji z odpowiednim zespołem). Zgodzono się omówić kwestie zgodności RODO z Larsem na spotkaniu zaplanowanym na kolejny dzień.
+
+**Migracja sieci:**
+- Martin wyjaśnił, że ostatnia partia sieci serwerowych połączonych z backendowymi zaporami sieciowymi Checkpoint zostanie zmigrowana w środę o 3:00 rano. Ma to na celu zamknięcie przestarzałych zapór (End-of-Life) do końca czerwca.
+- Migracje w Finlandii i Szwajcarii zostały już zakończone. Backendowe zapory w Szwecji będą zmigrowane w nadchodzącej partii, natomiast zapory zwrócone w stronę internetu zaplanowano na pierwsze okno serwisowe po przerwie letniej.
+
+**Zadania następcze (Follow-up tasks):**
+- Prześlij plany urlopowe na okres letni (wszyscy uczestnicy).
+- Wdróż zmianę w projekcie automatyzacji, umożliwiającą zatrzymanie patchowania dla konkretnych rynków (Leszek).
+- Wyklucz kraje nordyckie z patchowania w lipcu, kontynuując patchowanie w czerwcu i sierpniu (wszyscy uczestnicy).
+- Przedstaw i wyślij konkretne przykłady danych chronionych przez RODO znalezionych w logach systemowych Dimie do analizy bezpieczeństwa (Oleksandr, wszyscy uczestnicy).
+- Zaplanuj spotkanie z Larsem, aby przejrzeć zgody prawne i zgodności dotyczące zmian w gromadzeniu logów (Kamil, TEAMS RM STO Quantum).
+
+---
+
+## Spotkanie 2: Migracja serwerów (Paweł)
+
+**Tematy dyskusji:**
+- Paweł poinformował, że testy migracji zostały wstrzymane w oczekiwaniu na licencje, które mają zostać dostarczone przez Adriana.
+- Paweł zadeklarował gotowość do wsparcia przy konfiguracji dostępu dla deweloperów oraz przygotowaniu środowiska przed migracją.
+
+**Zadania następcze (Follow-up tasks):**
+- Prześlij roadmapę projektu migracji oraz opisz, w jaki sposób zbudowana jest aplikacja i baza danych Oracle (Gregor).
+
+---
+
+## Spotkanie 3: Migracja i bazy danych (Gregor)
+
+**Tematy dyskusji:**
+- Gregor ma zgłosić Service Request (SR) o nadanie dostępu dla swoich użytkowników. Poinformowano go, że nie otrzyma uprawnień administratora systemu (sys admin), więc należy ustalić alternatywny sposób działania.
+- Główne założenia i rola w projekcie: Zmiksowanie (migracja) 3 istniejących instancji oraz podłączenie nowych do serwera SQL.
+- Harmonogram: Zespół Gregora ma rozpocząć pracę i wejść do projektu migracyjnego przed końcem czerwca.
+- Ustalenia: Należy uzyskać od Gregora roadmapę całego przedsięwzięcia w celu ustosunkowania się i zaplanowania własnej pracy w ramach tego projektu.
+- Podejście techniczne: Gregor wyjaśnił, że proces będzie specyficzny (równoległe wsparcie dla bazy Oracle i nowej SQL). Proces odłączania starych i przyłączania nowych systemów ma być płynny i "bardzo przyjazny dla użytkownika".