From f22c4bb0b1e29ca2c21f1ff0409c9ac7efd9ff5b Mon Sep 17 00:00:00 2001
From: ValueOn AG <p.motsch@poweron.swiss>
Date: Thu, 11 Jun 2026 16:44:00 +0200
Subject: [PATCH] ims

---
 TOPICS.md                                     |   3 +-
 c-work/_CHANGELOG.md                          |   3 +-
 e-compliance/ims/00_IMS-Handbuch.md           |   2 +-
 .../ims/02_fuehrung/organisationsreglement.md |  74 ++++++++----------
 .../02_fuehrung/organisationsreglement.pdf    | Bin 0 -> 80685 bytes
 .../02_fuehrung/personen-rollen-mapping.md    |  57 ++++++++++++++
 .../02_fuehrung/personen-rollen-mapping.pdf   | Bin 0 -> 81199 bytes
 .../rollen-verantwortlichkeiten.md            |  24 +++---
 e-compliance/ims/03_planung/risikoregister.md |   2 +-
 .../04_unterstuetzung/dokumentenregister.md   |   1 +
 .../ims/04_unterstuetzung/kommunikation.md    |   8 +-
 .../07_verbesserung/massnahmen-register.md    |   2 +-
 e-compliance/ims/cockpit/IMS-Cockpit.html     |   2 +-
 13 files changed, 116 insertions(+), 62 deletions(-)
 create mode 100644 e-compliance/ims/02_fuehrung/organisationsreglement.pdf
 create mode 100644 e-compliance/ims/02_fuehrung/personen-rollen-mapping.md
 create mode 100644 e-compliance/ims/02_fuehrung/personen-rollen-mapping.pdf

diff --git a/TOPICS.md b/TOPICS.md
index 2e68b98..8b66b01 100644
--- a/TOPICS.md
+++ b/TOPICS.md
@@ -102,4 +102,5 @@ Lade immer zuerst diese Datei. Dann gezielt die passende(n) Referenz-Datei(en).
 | IMS (ISO 9001 + 27001) | e-compliance/ims/00_IMS-Handbuch.md | Integriertes Managementsystem: Kontext, Politiken, Risiko/SoA, Audit, KVP; Betriebsprozesse in ims/05_betrieb/ |
 | IMS Management-Cockpit | e-compliance/ims/cockpit/IMS-Cockpit.html | Offline-HTML zur Navigation/Einsicht aller IMS-Dokumente; neu bauen via build_cockpit.py |
 | Pendenzen / Massnahmen | e-compliance/ims/07_verbesserung/massnahmen-register.md | Zentrale Pendenzenliste (CAPA), Quelle fuer Cockpit-Pendenzenseite |
-| Organisationsreglement | e-compliance/ims/02_fuehrung/organisationsreglement.md | Operative Aufgabenverteilung, Operations-/VR-Meetings (Vorschlag Silvan Winiger, POL-Freigabe ausstehend) |
+| Organisationsreglement | e-compliance/ims/02_fuehrung/organisationsreglement.md | Operative Rollen, Meetings (generisch); Amtsinhaber im Mapping |
+| Personen-Rollen-Mapping | e-compliance/ims/02_fuehrung/personen-rollen-mapping.md | Zentrale Zuordnung Funktion → Person (OR + IMS-Fachrollen) |
diff --git a/c-work/_CHANGELOG.md b/c-work/_CHANGELOG.md
index 7d95716..1eb7eaa 100644
--- a/c-work/_CHANGELOG.md
+++ b/c-work/_CHANGELOG.md
@@ -14,8 +14,9 @@ Skip: reine Refactors, Formatting, Lint, Dep-Bumps, Test-only, Wiki-Tippfehler.
 
 ## 2026-06-11
 
+- 2026-06-11 | docs | wiki | **IMS: Personen & VR im Organisationsreglement** — Vollständige Namen, VR-Mitglieder, FT/OP-Rollencodes, Mitarbeitende Stephan Schellworth / Ida Dittrich; PDFs neu.
 - 2026-06-11 | docs | wiki | **IMS: MFA umgesetzt nachgeführt** — M-01 erledigt, R-03/SoA A.5.17+A.8.5 auf Umgesetzt, Zugriffsmanagement und Rechtsanalyse aktualisiert.
-- 2026-06-11 | docs | wiki | **IMS: Organisationsreglement** — `02_fuehrung/organisationsreglement.md` aus Vorschlag Silvan Winiger; Kommunikation/Rollen/R-01 ergänzt; M-14 POL-Bestätigung in Arbeit.
+- 2026-06-11 | docs | wiki | **IMS: Organisationsreglement** — `02_fuehrung/organisationsreglement.md`; Kommunikation/Rollen/R-01 ergänzt; M-14 VR-Freigabe in Arbeit.
 
 ## 2026-06-10
 
diff --git a/e-compliance/ims/00_IMS-Handbuch.md b/e-compliance/ims/00_IMS-Handbuch.md
index 5d31525..181cb65 100644
--- a/e-compliance/ims/00_IMS-Handbuch.md
+++ b/e-compliance/ims/00_IMS-Handbuch.md
@@ -30,7 +30,7 @@ Gesamte PowerOn AG inkl. Entwicklung, Betrieb und Produktmanagement der **PORTA
 | Kapitel (ISO) | Ordner | Inhalt |
 |---|---|---|
 | 4 Kontext | `01_kontext/` | Kontext & interessierte Parteien, Geltungsbereich |
-| 5 Führung | `02_fuehrung/` | QM-Politik, IS-Politik, Rollen, Organisationsreglement |
+| 5 Führung | `02_fuehrung/` | QM-Politik, IS-Politik, Rollen, Organisationsreglement, Personen-Mapping |
 | 6 Planung | `03_planung/` | Risikomethodik, Risikoregister, SoA, Ziele/KPI |
 | 7 Unterstützung | `04_unterstuetzung/` | Kompetenz/Schulung, Kommunikation, Dokumentenlenkung, Register |
 | 8 Betrieb + Annex A | `05_betrieb/` | Operative Prozesse & Sicherheits-Controls |
diff --git a/e-compliance/ims/02_fuehrung/organisationsreglement.md b/e-compliance/ims/02_fuehrung/organisationsreglement.md
index da2ce11..0b2bc79 100644
--- a/e-compliance/ims/02_fuehrung/organisationsreglement.md
+++ b/e-compliance/ims/02_fuehrung/organisationsreglement.md
@@ -1,6 +1,6 @@
 <!-- docId: IMS-05-04 -->
 <!-- status: entwurf -->
-<!-- version: 0.1 -->
+<!-- version: 0.2 -->
 <!-- owner: Patrick Motsch -->
 <!-- approver: Geschäftsführung PowerOn AG / Verwaltungsrat -->
 <!-- approvedDate: -->
@@ -11,9 +11,8 @@
 # Organisationsreglement
 
 **Dokumenttyp:** Grundlagendokument (Führung, operative Organisation)
-**Quelle:** Vorschlag Silvan Winiger (SoHa Treuhand AG), Juni 2026 — zur Bestätigung im Verwaltungsrat (POL).
 
-Regelt die **operative Aufgabenverteilung**, **Meetingstruktur** und **Kommunikationswege** der PowerOn AG. Ergänzt die IMS-Rollen in [rollen-verantwortlichkeiten.md](rollen-verantwortlichkeiten.md) (ISB, QMB, Audit etc.) um die geschäftliche Führungs- und Koordinationsstruktur.
+Regelt die **operative Aufgabenverteilung**, **Meetingstruktur** und **Kommunikationswege** der PowerOn AG. Ergänzt die IMS-Fachrollen in [rollen-verantwortlichkeiten.md](rollen-verantwortlichkeiten.md). Personen und VR-Zugehörigkeit: [Personen-Rollen-Mapping](personen-rollen-mapping.md).
 
 ## 1. Zweck
 
@@ -25,21 +24,27 @@ Regelt die **operative Aufgabenverteilung**, **Meetingstruktur** und **Kommunika
 
 | Ziel | Beschreibung |
 |---|---|
-| Entlastung Patrick | Fokus auf Roadmap, Personalplanung und operative Entscheidungsprozesse |
-| Entlastung Philipp | Fokus auf Strategie, Growth und Investoren/Kapital |
-| Entlastung Dominic | Fokus auf Network, Sales und Support Operations |
+| Entlastung Geschäftsführung | Fokus auf Roadmap Entwicklung, Personalplanung und operative Entscheidungsprozesse |
+| Entlastung Leiter Strategie & Kapital | Fokus auf Strategie, Growth und Investoren/Kapitalbeschaffung |
+| Entlastung Leiter Vertrieb & Support Operations | Fokus auf Network, Sales und Support Operations |
 | Struktur & Kommunikation | Regelmässige, thematisch getrennte Meetings mit klarer Moderation |
 
 ## 3. Aufgabenverteilung (operativ)
 
-| Person | Schwerpunkt | Bemerkung |
-|---|---|---|
-| **Patrick Motsch** | Roadmap Entwicklung, Personalplanung, Prozess für operative Entscheidungsfindung | Geschäftsführung, IMS-Rollen gebündelt (siehe Rollenmatrix) |
-| **Dominic** | Network, Sales, Unterstützung Business Development & Support Operations | |
-| **Philipp** | Strategie, Support Growth Management, Lead Invest-Themen / Kapitalbeschaffung | |
-| **Silvan Winiger** | Treuhänderische & buchhalterische Leistungen, Testing, Akquise | Extern (SoHa Treuhand AG) |
-| **Chris** | Business Development, organisatorische Führung und Koordination; Bindeglied zwischen Operations, Entwicklung, Akquise und Kundenbetreuung; Auffangbecken für Patrick | Voraussetzung Tätigkeit für PowerOn — siehe Abschnitt 6 |
-| **Stephan** | Abstimmung zum weiteren Vorgehen, Einsatzfähigkeit | Fokus Entlastung Dominic — Bedarf im POL klären |
+| Rolle | Code | Amtsinhaber | VR | Schwerpunkt |
+|---|---|---|---|---|
+| **Geschäftsführung** | GF | Patrick Motsch | ja | Roadmap Entwicklung, Personalplanung, operative Entscheidungsfindung; CEO, CTO; IMS-Fachrollen gebündelt |
+| **Leiter Vertrieb & Support Operations** | VSO | Dominic Largo | ja | Network, Sales, Unterstützung Business Development & Support Operations |
+| **Leiter Strategie & Kapital** | SK | Philipp Graf | ja | Strategie, Support Growth Management, Lead Invest-Themen / Kapitalbeschaffung |
+| **Finanzen und Treuhand** | FT | Silvan Winiger | ja | Treuhänderische & buchhalterische Leistungen, Testing, Akquise |
+| **Leiter operative Koordination und Produktmarketing** | OP | Chris Winiger | nein | Business Development, organisatorische Führung und Koordination, Produktmarketing; Bindeglied zwischen Operations, Entwicklung, Akquise und Kundenbetreuung; Entlastung der Geschäftsführung im Tagesgeschäft |
+
+### 3.1 Weitere Mitarbeitende PowerOn AG
+
+| Name | Funktion |
+|---|---|
+| Stephan Schellworth | Mitarbeitender |
+| Ida Dittrich | Mitarbeitende |
 
 ## 4. Meetingstruktur
 
@@ -47,19 +52,19 @@ Regelt die **operative Aufgabenverteilung**, **Meetingstruktur** und **Kommunika
 
 | Feld | Inhalt |
 |---|---|
-| Teilnehmende | Patrick, Dominic, Chris; anfangs ggf. Silvan als Support |
+| Teilnehmende | Patrick Motsch (GF), Dominic Largo (VSO), Chris Winiger (OP); bei Bedarf Silvan Winiger (FT) |
 | Inhalte | Daily Business, operative Entscheidungsfindungen, Zahlen |
-| Moderation | Chris (Vorschlag) |
+| Moderation | Chris Winiger (OP) — Vertretung: Patrick Motsch (GF) |
 | Eskalation | Bei Bedarf kurzes Sync Operations → Verwaltungsrat |
 
-### 4.2 Verwaltungsrat (POL)
+### 4.2 Verwaltungsrat
 
-| Feld | Aktuell | Ziel |
-|---|---|---|
-| Frequenz | wöchentlich | bald zweiwöchentlich, mittelfristig monatlich |
-| Teilnehmende | Verwaltungsrat |
+| Feld | Regelung |
+|---|---|
+| Mitglieder | Patrick Motsch, Dominic Largo, Philipp Graf, Silvan Winiger |
+| Frequenz | Übergang: ab Juli 2026 zweiwöchentlich; ab Q4 2026 monatlich |
 | Inhalte | Strategische Entscheidungen, relevante operative Themen, finanzielle Situation |
-| Physisch | Quartalsweise Abendessen (Vorschlag) |
+| Physisches Treffen | Quartalsweise (Abendessen / strategischer Austausch) |
 
 Details zur IMS-internen Kommunikation: [kommunikation.md](../04_unterstuetzung/kommunikation.md).
 
@@ -67,24 +72,11 @@ Details zur IMS-internen Kommunikation: [kommunikation.md](../04_unterstuetzung/
 
 | IMS-Bezug | Wirkung |
 |---|---|
-| R-01 Schlüsselpersonenrisiko | Operative Entlastung und Koordinationsrolle (Chris) als **kompensierende Massnahme** — ersetzt keine technische Vertretung |
-| Kap. 5.3 Rollen | Operative Rollen hier; IMS-Fachrollen (ISB, QMB, Auditor) in [rollen-verantwortlichkeiten.md](rollen-verantwortlichkeiten.md) |
-| Kap. 7.4 Kommunikation | Meetingrhythmus in [kommunikation.md](../04_unterstuetzung/kommunikation.md) nachgeführt |
-| Kap. 9.3 Management-Review | VR/POL dient als strategisches Review-Gremium; formales IMS-Management-Review zusätzlich gemäss [management-review.md](../06_bewertung/management-review.md) |
+| R-01 Schlüsselpersonenrisiko | Operative Entlastung und Rolle **Leiter operative Koordination und Produktmarketing (OP)** als kompensierende Massnahme — ersetzt keine technische Vertretung |
+| Kap. 5.3 Rollen | Operative Rollen hier; IMS-Fachrollen in [rollen-verantwortlichkeiten.md](rollen-verantwortlichkeiten.md) |
+| Kap. 7.4 Kommunikation | Meetingrhythmus in [kommunikation.md](../04_unterstuetzung/kommunikation.md) |
+| Kap. 9.3 Management-Review | Verwaltungsrat als strategisches Review-Gremium; formales IMS-Management-Review zusätzlich gemäss [management-review.md](../06_bewertung/management-review.md) |
 
-## 6. Offene Entscheidungen (POL)
+## 6. Inkrafttreten
 
-Folgende Punkte sind **Vorschlag** und bedürfen der Bestätigung im nächsten POL:
-
-| Nr. | Entscheidung | Zieltermin |
-|---|---|---|
-| 1 | Feedback zur Aufgabenzuteilung (Abschnitt 3) | Nächstes POL |
-| 2 | Personalsituation nächste drei Monate | Nächstes POL |
-| 3 | Chris übernimmt Moderation Operations-Meetings (sofern für PO tätig) | Nächstes POL |
-| 4 | Startdatum neue VR-Meetingfrequenz und Übergangsplan | Nächstes POL |
-
-Nach POL-Bestätigung: `status` auf `freigegeben` setzen, `approvedDate` und ggf. `version` 1.0.
-
-## 7. Inkrafttreten
-
-Gültig ab Bestätigung durch Verwaltungsrat. Bis dahin als **Arbeitsgrundlage** für die vorgeschlagene Meetingstruktur.
+Gültig ab Freigabe durch den Verwaltungsrat. Anpassungen an Rolleninhalten in diesem Dokument; Personenwechsel im [Personen-Rollen-Mapping](personen-rollen-mapping.md).
diff --git a/e-compliance/ims/02_fuehrung/organisationsreglement.pdf b/e-compliance/ims/02_fuehrung/organisationsreglement.pdf
new file mode 100644
index 0000000000000000000000000000000000000000..0fbd1370d13c3cc1c952d211de371ea018961f78
GIT binary patch
literal 80685
zcma&NQ*bU!6lfXSwtZsTwrwXTwr$(ClP~s(ZQHhu`S0*n-KnX0Ydv&V@9J8;b~m}A
zs5l)HJqHZ=U4B{#3_B4ck-f1s3@<N(xRs5InG+F%xQ&sEnW&kGy{Q?4teKsKizN{=
zBP$C(Ka8`BlbMk%jK@ZgwoLpXJ6!Ln#+z<|wi1JMpK)L>p&;TW!iLDa2s_KUS=n%F
z_{(W}5_xpe^^iP-96N42N#YmP11dQ#gw(A<;LjsO$SZIzwmd_4JS6p8nL&B<(%1dn
z36wCxzhB<~;@;nnZzTVr0&wX_0!X0JkkGwu{2wpwFQ>Od>G;QezMgb59)=PK)U5#Z
zHKN+kel0Y4QV1TfMx2rbd33cd2-WFB+(7Qm0uZZJWshi>uRA9}jgZC@i=7(Yzvjvw
zpA7j4zNn%}sNG9}c(Qp!|K>vBlIlorXf`gPA=dMZu>PbJV~V4#evn*x|BwNjQ&jC)
zg;@w{JvuMO)MUySU9%Jvf4qx<s&c_3WIk(0Hw3tpHW}rfD#j)cOcyqqBP_4=Wo4r6
z_~EJ+*Er}D*16~hX^-xKNm=345mO0Rl5eq6P)thLb<$$IV%DB-lHKAcE+~TbJ8w`8
zN?=PhmOS4O0DX$x;wllTZmnnoJ8wBa3z2}aO)+FquTgof282=@7IR)?17BhG*bn)@
z<RHMd*P?Lu+++mBCb`3FW`M9q753uy`OSZdH>7?wNk^W=h8g+YA96I${5Ij0GyF;Z
z^?5tTz@Hq@=d9hW4*|ZH_bBCC=AcX1_<<2@M?pBUBab%vY(#;51+_|HBzpa0BnSe<
zLSOWM4=}AOp|Gi{rREUu=M<zK)iQ#PVxC?{3JXsk%x38Qc?f?+1XTk|aa8`;-}iZY
zu1(Qa;?|~~PUH`(3+z>Rx_;Qr_*Fl&2k<?=dQN$EmzCY~y!5;OgGbzD&^{Klq|wqd
zLC+W)LD2<B?^n$8iZz~<o+>m)74#ieTvtOra1AkYc6R<d`vQ}sAwFv_x0L%x)8GB(
z<&a9EamDN3w2A7!0!q&9-(bijG#f`GW0;d2`XS`*Ad|@(^&7wEj&Iv82?6lEZ1N;N
zH1kUZ!VrN<SDhuIk^78%Lv;c%Y28^$=0=y^fgOTj1xMs2ElaLJ{N|2ev6;IRLNCLQ
zFt3KwP>$cNKd`ue!_Svk(KQK46?<z|&%5;A(8_hevYH;N8=T{rLz~<yA(W@IX%5nc
zQkZYOKukdhY06kN;Wyc_oZ|TXi3Mt2@~;M6QbEAV6zDw>0_&ExlpxsQ;0(4*Q<rbp
zxN!{YM~SbltcVy!j$O8s9v*-m#hL0nYWB0Rl@A$H1IldkIfh6N9^kJlWqcNh?H5I+
zDvlUaq0YoRq)F|#)kUQp=ay?#6)1X?ANED(TsS^}nDkPB-K9NJN_eh=?7bLalPLn`
z-G(JCOAs(e#K7USc*53;N|A*RrAU$;la1pLjVM(c`CD7F4pS?eXMU9)#HPUR?v<_n
z#1NAM@5I+=$zoJ)#vrz0QWlm3e+0{G_M7YEeTwVR?N|ovDvessEu;SJIE^@tjyXUK
zD8|-6t>)s{8F&+irP(6OsyzYKHRoYx*?|e3p|KpJcS*&?!XS;088XHa*bbnU#jq?5
z?L?3QB$cHIEpiXaWQJWj4e`67>&Y+V$*-6<$2d}|d#!70r>@H#$D65YespHtNr{g!
zZ+rA;r_q^is>+~w9hGVjqwkuLJhlQznvXFEJqTi@;#_OKI>lkjahzqOt=`?H2T(9)
ztuW~R&<?g&bW^0Z!iwQaQO8Bcl=pI1hXNW~7BZ<O;+yn7o?01R^p0ljwgBQ5gxl#k
zc#0WmCJbpt%Z&O(6b&4z?Bvr?BAX7T)NYkS=4uN^s;gyJXg{N^QSGCZi|j0uyEA#s
zT}WP_-WzFr<q@15<a;hWk$)c5u&-zF=fr#GOF#MCNdHA+)LvLIrKc$`%#2%a_~eh=
z_53|lPF$0G$3ogHDhY24f4D8)aOG$zqo@{c+jYw{UJGl`l9k;lZc5ry$I+&ffjc~B
zDV|;)J_0eWVh?f*dr8N>Ur`B!P)h%W-d5f@*Va&&d}{u1QE!A2-W0pd)8t~HMROzE
z9aHRRoVp;J)s^q*xYrS}j&?k~d84x5Ro+FMG_921&J>$3rU5URP}c*Qnh|(A8r>b>
zxwCg>t|QmW)ujZ?cC2P?$I3JxA-uN4)E|#_-otb~t+yW4hEE3Zw2r_wRE4T3IN})?
zW^1q2(pFU0tu-~&chT+Cop3qUdYmUa81y^!Z?cG_#gUrvZ&Jw)vqLOu(KKF2xQRD_
zNuj!5O-!QP&Z(QPB5Wt=Yncd)>r=H@gbQu~>$~k^w3Imv$}IAzf!)uDw%vG_(pJ>!
z@a^WUP7`#kt2v=9Ph%YYs%@j4c&lPQC#t}yC1&LH&ZX?+(fBi@h=Ae6piBg0+DYDC
z{hSzZ`MjTcsBrTSG3~%t&64*x1h%|)Sh16&WP9pD{k_Q-f<F9Sdl&P`yMO^f!k|W3
z+}^^sTm+>mmZA2MB7E~u2%``p^L8EL=F1%3%-?+Ra5zJQ_PqfE5US@FUod2yj<&<q
zrbbx&y@#f=3WeUV%qL>lSaW@y2ae)%AGDbtKK>T-Uz$Qobk3y+-ULhf8nU@mVq$_x
zF=0+k-yM4VT1l;LYem@)se3whMdGQ8U?wJzFf27D$^y?7sJj_lPztwIKyJ6SnwHI<
z|8b$}3TUda?~8vcKQ<bnpcU#|gB3>-!G`m_V-si~`YX1L<2$*)1~oT<8tgjXW@EPb
ztyUEOrxU}^PXD>Il7mIu_m|M7tj-0-%+B=xq=5fQ{{tMD82|qf1P3SU|4b0Wx>E61
zt;oHv^=D0ib6c2u`@l1KKwO;IL*aeld47w%-3WI%B0qkTQ8JEyBa;GTyKLc0KdPcy
zl2XET0pDL?YyMX92`l1Kemw#VyYyJp`?qDV0$<k;-?2nK-^T)&POkX|{vGYv6O1K{
z>e_nHg=o;mB^av)0`vlUKRpjahY!WyPk>VK3}m|_HI}2F=wmgQP%@Q?h-xD^=ou{a
z#AP(0lWre00HU-=?6Ev6iKy~$-E4FcG8&veT^Kr67?t5y`E8Allvqr2v%tlMzGe>#
ztKwi5RfSOt<NkX5vIUpN%YCi}mZW^Lu&8ATfJ|5)Ta0<W-Rc_xd{k-YqX@}|^Z`wX
z6{|(ss;s0SL7H)>#tOhs^vn8RYm&hxW$LjuRV+105TjY#m_RhI7}Bu?1gSW+IgYYp
zAeH(`7UWUBcpgc_gEK`!!H7Aqph$~amWlK^@Oyb;IaJXXmt}<<_>0w`(G=80_w0|$
zFb58cNd2`Ka_?q<Mcyr#J;elYlfj$TUgqiM7&y$SB^S{b+1=D*Zo{-Fm+A|w04(pL
z4{lQ?*wDD&zD1x#o;_$9Q|Od(i9+03?3fBzZU(q2CFC{x5p@u|P2s}n$hG)?MfoF;
zs$>y&-2c{q+Z}LnbhaJAD+aVeA#gOJXJv<O%kc9<+2!<Z-$up%xqNbYOz6$&0?6CW
zYDgD>yjY*z<l*`s)vL~A5yT7Vbc=8<Aep~`rn(Hmk4N{YHhPTX7~C_(;c8i*jPd-M
zMt6g}otmZNh>vG0v!?~L_-&r!B^o>ko85-<3b&)S`i$o%dxPu@nn2lvr@%ILY!{|a
zygot0#L+e-gLvGEr5*83XU6Cw{1b(cYFQst;Wk!6VzUdLZ|$Y97~{O7TrLGLGK42{
z!$E2MQ~wRo>>LHgn$?H#PnYUyOx((8Ebjn!`&_K#I$0r&F$ITKL!%aJ+3er`hs*Zg
ze$CO_k&i|&EVEV1>P!8zwd#U)Ke(Tn0>!Dgwc9@}Jf%XYlLZPt4S3ucyADDJc;`SX
z4$UCOy+bz04^mbDYYNhF)Arel!J|~-N<9Sa*AF*93?hNY-0}z|g@p_13kY2Zd_Md~
zlsd2n^bjH$RE1B}>u&!eq~LIi;0Cr<FcB)j7A2KsBe@Iuc%SgZvfXThL^_v0Lx#GL
zJ);UtKm@^Cc546kuD>9M2=)UMUzHeZ5dZDE#ShE;`r<!$&!|1aW6%>{gsI*p)2IHZ
zEXV&b$2AB#b&WBe`1}GWQxJ5nsgl#i*<MOK4bVm)Z9H?}6r{3Cb;B<(HX_stiAl2X
zDu3@$@nid4da~X-(4EdcJ1!cVHh*7l{odbgLjT`3!ri)|p~IB6(PM*rMv4VL=#dOx
z^NAmMt`T7qO3V|E&z67AM*rMo*G@yASKVYQj<a^JUjcI+7I^rrvUgqIxf=|VtO&D<
z+nBUIzh95f*Y)WF-N)&{1;X5ahOS+xrAw&Lj8lbWX=QT-f2uJdpc5ayj3t22D=OiZ
zswAuy{-DzpF2XW&LSsKUJKyV17gh*f_dMl^1Y55jsuyMjm2<#qgN$m^+YG~JL;*kg
za5616yMIIdcOdDaEoRN9FUpg$5CwEI_@$f->0dHZ>Q@{wXkm#mGA)41_$o<3O>0KI
zS$saG`@e{lnA<FZ3@cDf{#^LJ61aR~1u4oRjkW?-p~1q56dj!OIfY0eeh-GQc!d7A
z!vXhlHa^PKL+TtPjcBU(OC{;&a{AG-!VNV*2_59`2Zn_@90GUsVZrRqtZEN99LA#b
zohu6~mm<vrs~D=kj!X2V!m=0FgO@iab7y?WK9z@Z0`Fi_IuxFx(6Je<kVS-$7|{uH
zkq{J3m?2_vDLDwdWI&tHtd%kP9bw0uZ$qEy_4!~NsAT@AXo3;<l)1(LQ=`=nia@Y5
z+?8T)vG^V%^h1X7rU_JaU>_sq$K)oSbAG{+2^7+dMFw8Jd*BAMCX1RFM($0z<OpaZ
zt3OD{^hsviCJ+|M>H0~&3!bdSdkSoW7HS>Ap?9zC`&oU0<NO7w$=`P;9))RsM90QO
zqUlfUCJqRQ9yKqWaT!@99&gxMnCpg<f*wc+j=M@5bRs9iPHma=J90|Q@KPa!ZIa$K
z%IE;&t!p5crdho0fPZFYQM|G93~I-gkdN+0;lfvHT{{F!uNSTPePJ~0fYQyRu2iFU
z)o*l+g4dY5o>>;!MhsV5eg+5i@>l9Q5}Qa!SQZd|pjbv4J?q;XMOWD4^Uxhgt3ty!
z_H$Ml{z39iV<<(5?7)$Tx8`<eQI$e&S=3^IYUPQN{tlb2yDx$(t`L;^6W*S{qO`*#
zSp8O8<<RzwuJC6>d#uH&+H7BYwyit;TKP)#LLd3Wp8!U&^A`bUE1lCMFx!*n!E*|;
z0EGha$&=(MxwW3`O$9sHs!=7o*CS6S>Vr*RcS6GIc?IhLjL;Tib@R<g)=|A4S{LI!
z0D!EdcBjtfVRGjr#8XQ4eArJv>4aTVBut6MQ(_Zl5~wHl(ZH)rdBR99lhRHfc^PvC
z(;Idbv5LX>VhOvz2*+*QWAh^XoN<0g(04Do(;amI4UO^W!X3vW&$TsOfzOyeKut-o
zdeelDNvkf_AuK;V30m_QB-|VN@44yXkA?%}?y;ANicYQ^?>~P)8kUAK1kz4}zTJXa
zEpb7Yl9}zr4ObtyiteSWba1_rHCmaJq>zW6Gs5)@_{i&U>P8kAuA-J6$CO}_kL%jT
z?h?iTky$c6b-HZh&NKz@N&B3%Ta{`v_n_I|i`z&9ct(dU<mevHA=65r<82qO&CWr(
z7-8d{tHumQ2L_YKuObCtOcnJGSh!#tiT8;{8EYgxdznL!$na3atC+=BkgajpY-0yp
zV=buIXL_+n?}jD{y93xWnr$U{WCNqYL}$fz5Qir3FX<-;PyMG=IRcN$AW6|u_M_+b
zgs4*yA&hMXB9I!N=mXF)CyTj1R?c;ay2(Ow)ih@uX~_l4ilr_gX7$TGb@oI$!QPwk
zO{^3Vwz}mbf)$r2^Y6TE0nz+gIf81R!#qJ-WhkcXS9^WS(%LE`;`cpQ+ntoQih!Wg
zOOwp2vg=5h)>9{hBO7q-sC{<Z_T8&K^X_g2T_bsp9iU`-FYfL&^1cRzo~)V3(MMpO
z%<5`S&dDHREp{{95?yxe#?@C{@n|`}jsq|{=`G19>7BMKVvWg=-$5poj?T7UA84=c
z!NvT27o6;7ITfOZ$Y-j<*z#5}-bwrIH6A@Ko(0=<nce`>QI!K9-dtS`JB8v~pMcnj
z%yS!L%7L`e;Siv%M3gJc(erfY(iwi4HCw|d9qjNH4vQ^So`XqxJBvQXqU~KjKo7?Q
zLv1@|)Pup_z(a#c$IzN;rMfE*XfQig`;m|I`MPVddk!-q2<PWPE8FRiP+KxAi;W(;
zm2`lYu1X~u`0Xf&*1)gahQ8`EDzh>Fw6+cgI9mC{yO&&|I=}@$9?2)G-5PCeA{quK
z+LXUc=``Nks0*L`xu88PD`q2!jM2+%!Qfv+S;Y=DcB13{t9RsHn{{@E{hbQdvA+Vs
zsT$o|ULolpTmHoNTE&vAo4N5Gh1)kSUD30%Dq#VJEY4Qg^7>p#ODHh>NmR`CntVMl
zkgbolcq{M=x~$59{{Mo>%>Vx|nVI>25pA37NWGsLXLtp0;r1Z?Aie?t1Pk<8BJ;s3
ze@`2Ah|UZB|A|D!7m9Kv*}C9cbofj~v+TlA_xIgDqVM_313S;?6o(yN?k@(iR3BPe
z4c#b&w~;dP`+S`OiM;vzct8cO$e44r%^&~?Gs5q1^7-)N^W**e48;6r+5A45V@-5}
z9?Tt*LU*^|#C6O|TJ#b1rOQ%Nw#?PLFjQw2N3*)I`j`c3A*?dc^*4lI%m);V#K}%#
z6htN=ssQPCdGA`#z(HDrxd4~MlPJ%dlsS%wfB8?n=vv@Kt)S+)cTv{x=|`_|G7Mp6
z#caPAojhf)F$OD&uJviY9LIXFX=#|!EI_0+-A(6h$U7|mOne&8c2;&Jy>?-Od<`%I
zb6llKs2FhmeMgMF*{=#1e185oy?x^#=xNtOMi<(|U=r9_2(jaksh|q7YA5_`E?Z_G
z@!44{Jg=>y3$zE5q(G}3nNx@&+qi92x$O$U4+L4y8wrJ#GGXOdsUf$$^s@GJz9^%#
zd=BEmX$FDOm-l)W12ac<L@T7RYqFJ2fWX2U417c<qi6c~u>>1hHSq_~9rlr8Z5O|-
ziF?d`f%N0JW0W|>(JDhMFKsxw%3K4|AL_s-zshsQTuIeF5TG4M|63;a3uSf1%4&Jv
zcFAk4rd^;om5OtlNEY+YRs-lJ)NST2z+X?4wO9XRJH?%@9q>c6`Ptccy;>GU51`Q4
znhCjLO#`kgu`}-9@b4mlM=ct=mi40l+;|P)sSwgsq_Z;<O1W$OhuiXtV68}@8c%@A
zY}agVtQ5SolU}B=tS?>UW}p#_)t|Yg9b6-;zeI$~^1u-fIff~5L^a?D;F##Yd-L-6
zyhhyp{`heOV&Tn0^zS{yqxA#+m*q@<pYK11^O<_6Ym!d@sJ-(ZVV_wpBs~3dwQ8P)
zI@03%_SfU<`0m@Jhr9@-gC^0%<78o?OPmCIFWxyF9Munngi$@xqmV+B4~p$*K)P~q
z0-#)BjLF0$vgv`E<G7=lzU@?23shWuC9pp`>rZPo%C0dwZm1OX_~f24Vt%MUS80Sw
zJz;ZV`XC5DT`zC7d6$l1wN(P3yy8_j94Nb|#a6{}{K`4IY;Gy4i|x)|_$rA^TjZ$2
zug0ZPSjp@Z{}d%$SmR7K`Oh`B^y~#epXZ>hQ}v6vY}nM6$*EfvKR<SQrl-hiR#vZ8
z1EO#@?sy~d)npS%@=!-jljbmspdRc6p3hIw#ONzyY`trARLNS0loqgZ(tJv@iri8S
z+`ud77Z>z690jW=(nNQP%P}BQx(s)~Q}>{Uotq@NgyU;R!+tFFjnm#eRLvm7*JIW{
z8%;!)^)3T5{c|WO6zFyGk9o@29Ctw53&P2DM$&nMUoq=vy7Q#2@~e4Sg_#@JyALty
z?9ubmd5{7J&TZ!6j9LmOcqKpMuqG6~CoG2PZSIr0NNCPV#NDu1qJdQ8`jnUpC7*x;
zB~?z%_ka>xZOdiOvG`Q%P^DI6MH2tPIuKZFBp-65Pf1tuu}TSs4x-j)s+rO?lE*FM
zfMZ6Ps#J)H4m%Pt*3ylS%xR0{(A139lO}jwaH)<kCqdLYYKDYdS<F39prLPY6`oir
z(x676)f-krFR>j6MbUYSm8p-I;8y}2sUri^WJ{X0Bqee4Qlkowm)YGnZ6Vq%5ZfuZ
zSw{gY(Alxo^_|u=v{WQ%;(sPBtVCC3#w!7vJjFd`a6GS+86lha`9uUb${Kle>g1M&
zSd^_qRJ*3-Ek#f()*6!=!=ln@E4lP#xXcyF#i%5q9b{M@GNc<}|E07rXfvo*NikNr
zuu>_U2+h)3Ih;?03L8NyrX1f~a$Y|T?&$_F>nb+m0xmQxf^O1CZdSl#8e~g6-O^+&
z1m~^2`)?+<6^@0PW#oIxO%>!}_EClIO#YrGv<>`#YjbH_1=HMM5pe1;I+5;IwWSLu
zkR?JGkvqz(AWOI_|K(>v(_mhnLoW2leN9oOhYzz!gTiZ_P|gAJVk22c<K1sIR7UZD
znarW|YS}+Xu#QY~ixkF}o%4XOELJ)SA^Q_x!3fzzAUDZfS=DjW$aeCXlT?_$F+E)#
z0^V7k)RystGHqgKpoDEnpuelA9ho^&-P=teoj{abm_eBjG6I9pGpKy%pElQBT0}%Z
zx|~LJ-8rAJHKwoAs^<U@uW|a^`<O$w%|e839qDufQ?YXdKOZ0lE_u>{fBA<QX(}@)
zGOEpXy|Hizht1i+q<ADbv5Crm=PEf+cD`e3r2z6H9Jz9VO0DagyE@C!6|V=znVv<K
zfdlPz8mwTQ4vVB<oUhSA6_4>luW4m<I-T8CC#5o440fW)a)eh|BpwpZwL<Gd4s^LE
zCcmEPb_vuiVz%urQoHj^djG&RLDl~j=A1%#S`lMd{!+%Y;hy$sCA|X<D=K`+fqyr8
zzNdII6xYIQLk}~~X4Y{@ra|D?Tbm9Xo4&>_w~I2H%r=e=RiYfS63~Oo#?{rOH@<EC
zT-Tssz62sLdUxbky-M%#Vot+bsZ?q#lfH4h$Mw36+R@kRl7wqfO34L|QTU!(7}+(8
z<}f@g8?5&4BdHxbbmgKv$oxF6_vE+QPE}Ej0sO4?AQ?CHiwr5WzZ;Cc+cbtn%V!HC
z?{;}L$m&;S(;i#mN!-#q6PW}wderq^>bt>)m4QJ8XFryR5CpD4hvm35iJmw3a*{Lq
zCIq0Kuo@OYdk*+%WMW}6BO_-)0cVe`<Z?|s!!U70*P0n-8yW_a=sOQxN-R<G(rrGv
zy0)N~ROz*{cQ7G0y(H)4ErrFFswzHp87;z$Y#76s{B)e4<+ezR%aeo8uuqc#(R<57
z@9f4~|H#vjm4VY2aPKt_;M9`2(7wG?N$(Scfi%AH^`+iCcfaSKIFq@tNTaN6f3AH$
zJQe6!0p<H&sfXo%l7s(8Dv^nZgOQo_|0~zX%E`p_Kbyi*E@(}a(G?bVDMc{o1frlU
zEJ>;&D&oB$s_3z*fB@PkFsNvvJ3-Z&gD{dJ<=QUId26xemC`81O6mNTjn!2H+iR7-
ze_Nuo|JJrhhsy3`W(RB>`|tk#@ML;ha5=YfolbRdK#_*j%n1(_o!$2z3b%`G!GwI!
zhs-adQhItFZ_;swAjyaLX^+6^CBAigAPHZgp84n2{-G8|SpwaQF0fC|HAs7owUmby
z{vr(_18{lioirKH-Y9BT@N+TFZE7Duzg-pHCb5{D;C1;=oQV8#3db1u8HLrgJGKf4
zZ~gXV_=MTXBX7i*3wd+)O<J5;T&!{HhbJV%AD0Vqh!85}KOqPs^!KUM7Y!t3in~9d
z-=WIwBd5x3c}F!~5%Mp3eSTZ-n+Be>Jf;~4d~~Dou?$#}F&$X{p!B^U?VW=w00c4v
zf`+PN#1D6em$zB;G-4T*gT(`O#EEa*AK{*~USLna4idrtg{}fgQ!Xa=1T<plz~%wa
zoZ)&n11t>m@i5WJB${0w(k0<mBEIj9P!$R=(RXPjDbRaFlduDSo(^V<OpSVhkA>j9
zLWdz#K`wW$E}Y3NDOKT@s48eGs1+%H?WVaxev&Y1aSJXA>QEhagmJ}46+1IWQ_b6_
z8GGfH0#*dQQKu;Hp)Gqn?LeCcjdn!ND6wJ>)Fij259!E0|9tfQ#hTI>U?IqJyn_Ss
z`-HmIv9wLEVbmAfJn*Z)8(9^M4b_%AUGp3GC~U9;im451CBIu8?4H4CwI=#tV3;8M
z@YhY56~NYc_8$gqyblV^s+l3U(e!XSL-jxa-aJTP+fqAYJ9{rkq{51Y+$mPV(-dKz
z5EHXx&x*d7>pJs(LUYB54HBzLz{QCP1NH%e0e*wp;{e`sr9wn6ZcN{gZTm494`|$K
zpK5<X%zNF{jZ{1-qB~KJkApc@5p5923)0wkK6$wQQyL6yES(8KMVVPXrIM!aw2~Za
z{Cq|60+)h79}yj%G+K)?v00xo+8vbNm;M<3K3U{fWT?cPvR(u;Z#9n(sO5x;lK*Ob
zW4UL*=%M2+9MYQlGMF6rRaAFNm-E+p8StaTt$(-`9KwbAgmqk2t5J>?mG00keSW!D
zo9`Ntp=iO3y!P?I7bOA6hWYw7@6a3zCNAv+qW9~S-9OwP?^<OTBt4D8JUEEyf9FMv
zG0ggScz(qBw?C0r?K{mrL#UbRPPG?|0qV~e%q<{h;Q5@)T=ZRz($;k}d^xDCB+eGf
zR#K&0y&fjlt`bupxA~mb^+`cTK13lrJ;Ia02h~H$QanEA+tVeCGw}8>jrrB9uxjD&
zN{z58duoGY=JR)S(-RdPt7yEN)uoI#?hd^*12b{yjzBWM955?)v&0<1fa3rZcy2#6
zE7?YD%sQ1l8AhXWFa+m0YOYR)d3_PzWG8pw*Sl%_L*9T>jS~OQ(EKsf1>j2=2lA%W
z%3^*KN+n5YEDqgBd@0;vc*p<llyNTdpw9Njqjj0Nd!{r$Xt6{vp`v6fAMJ0}n&?)W
zPK7`$BL7ZP>|<Cub9BUw_HFjOfN67NHH+>5&(G(|oomaZ!`-AL@?<Aou2r@d1U{UW
zCH&M(qd{A)Ll}exR)mD5#0sO6j0)T<`vj{9v6*=JRrx=ikK2#0h^BZ_h#n}lAT&z<
z!83G4H-uCB#2Gsb>rii_o$*i1$Ruz@f3M7SqEmqkS}TAiE|a&5bA{4a@IGg#VUAYD
z*dgm)Y5nxEi6PaV%$+`ueD+>hOkPNA{>gJ;)8^*rZfJ@%zI0QC<{>?w-jN&d#Ompi
zEsl>ai4FJUEj$y5h7yYLmkg&;Ify)inq!IOkpPcJoFMVF;e-0q&EkT^DfB$vpFB-f
zgu1UQ%|G1w41H(WEkF`ZJUYM%nK38m^C=5Gm9tG&BkkoIS2laUP{R5HGGnrqI3EX@
z{*t4%;Usoqf){*I$nSGHnYYu)#r0Bc&yHEq0rCbf0R`%TMu<3IO<fTzX^m(N(q>mq
zd+3=W-fIM$yvHtC$Gai8+5ZQ=BXXPYro((qiGYQ;oQl3IB6~@IzH^2#p7;HL=K+dx
zpXQ5V=BwaQfBB<hnN0>$v9_-=%HD~lfe0|(+Xq5+T7hmPu@c44<Il8?Mw$~%Neqh=
zjL=`DNu_Bt+V~~)urE9aV18g?fr)nz_+^SCk$5|qL66yT0A;ifa6NCBK`>^^sdIy=
z|AAwp?ws5^BGC^d$6+uaq{-ASH6@2}mMGoo3n5(7$kgSuUB^{%pMs%mi$r((>$}S5
z<RscY8VX^f!$IY+u-5qK<NS|0yWH%Su!J8#)O2jGjsf?|<e7fU<muz!gSay%dh&F}
z<|@30=H8jjZGxK*L$IE1tvy72tl9(95j@pj;vNaF#=-%C2t}69M`VzE>_PuBqW+wz
zf26&;-L&)bl-#KWAEPo+?A;DQc?i<&=Y7$ia1ix*#MSX@2)c}JO5BZL+A0JJ7Kv{f
zv>0uvly&rMQ4v9O$6aP%vQczs73|wolvZ-ftUF-0diowF|M)nWf8?KH@21|8)ap;5
zr<{(w&mZvjdP#eeBFD;-GtKNT{DKWwR~?WvUkDbF8k8&PXR#4lvQ@=#_U8DF+aL~&
zJNMW&h|^?YacDtbU_S`r-YpK7MVg+qi415>8vbC40{LeA4l(?v0$Xh-lz!1Ykp|?I
z&YIWfO=Kk@7?b=g+-P#O{Na^Mo8w7y!{({)<EenJEVraYhC7R5a1QK0M4wEPMd_;%
z4gthM9~+2mA261*GHj@<J5(8V6AlXCdiJkqXyWLx7zv-I!jww(oO9hFysy-l;y-PH
zHC^wZtnmeZ&=+hQP9XdXNUyM`f)Yq1`Zi@Uz)L8OlGxrrw@{<+p&v*)<n0pe``AAl
z-1Ea7qIo8)LR+!}D9ze1DpC7vQPWr=*W!H4IKgBfn$q*a8z{Mh&wnTa={E(_dlFHv
z>N(c_EEkO@?BNf#ZYm@Pb?;2qaR&w8D=W)uOQKSb4&LB#yIgvi9KxSO<7P)8AmT{D
zjA1m!q6Kjse~A;xo!i_Ns1k7;Zv_4cgt-G}w|>DcT|f>pOP{P6U2Sl+@f7(OfnJ==
z-Fe@sDOggp#owh>(e<x?@Te2DevA4`ZY8n+TI5{gr98DnsQ_e7tqhgX12(jmgy06_
z234#o{oga0U|fu!yW@eCMXSehLSlP8`Z$^Chpv}nmw%Ck^tWyI)2OoyJKw2~cV?eN
zV6p4zC5%grsJbYigDPJ4E~^8v?nI;=WN&`%PpYus@?V%Elx5-FF{qq{`q**DzHJ&S
zHQ4y)+fR(OPW=kr06sUQWdHT){C`waizb}>Z=UDUq})<B$&+uLk6FiNOgl#Mts>&&
zDfm<$RG0Uj)&I;aA>;1co~N?rmGypH2}V)~_k#bT9Ar2kDEjyBCQ;d;XZE$Uwz<EN
z%CgAtBN&PTnJ_DkEZl)X?xEzwO5phIXY=qMh-Y76-}QOt7`n6m=WTNvATGz{uRQTz
z2duFC!?&gA-m!|tT^q=uKUFAAy9|R0@kgl<Ji7L@JFgH`${K`eOt3|GIcgrcaU<x~
zM_zbxCoCG=jYhh*kY)(wVHh;4UJ9j>WhXW!@z7K&6O`c5&|pv7$03+nu!vnz;@oOD
z5IW!9BM*^llK*trTalWJxXW!XCpEZUXO5i>L~!O@IPVT~FmXENjEp38aG6eamQ;y5
z`5Z4uS{O(~CnO9`CToasc1`4(jKq>)+V*@@e2bHNRQl*WEj7{vcDV*kb7yy_<QeZ_
z_N8cBL*i~-<0OpG@^48;6jC40Y3kfIG*-&cG(J!E-4fQ4+8%Lm#@3gSEi>PAQDWHc
zy4#Gh&#CYl5`s4JxaBA5Q4^zY`p7#Cjv=mKqdK25j785R8Gi~X@OMf0^)(Xe*s~yZ
zQw-NySyswXKYcZzS2IEe_PZk9;X`J)>iPUZ(`MnnGlh%*XLy`Gmz3x$JQ9y^tqsRC
zkqEA}xYON!h`O4Z*hnF(8Npb?;i)sR;f}^3fpxpJ-U8s?K?3=)IoK)Oo9yJgD*GW<
zBXtkV9DyNBId6@g?sy-Cmv*fEEX1#=n_^AUuYgljuX91Ge0?#-J#RH0o@HGMS|V}D
zXrE|=AAEJd1_enAiuf9$-UPG-imh9L{XRG$!A2!5xJVEyy;R}@I$Y!<X~z7UUk=0;
z)F&&8($!?0-n*tFG9oT>V{NduM>$ajOQF?IA`?IvoX?mE>8M7gIzaJAUsht25njw+
zm7SEsKxscZ$kE<9H?&goJ9!2050fo0i~;`hkZecy(=+5&>(%L}XXzmo;WD3pOb1gc
zbzTW;-%)f9dT;A)@%)QCI}H}C|C*2Q*z)Xb=t;c#(!EKbT*bwlR1l$<A`wNk83L1R
z41K1xomo@9klH?E%oBs-fH;mjczavUKi~}Fn6KrT+Bz&V4}yLm2QwW{53D~auRNAf
zU+%{l#kshJI9J70FR@eyJTwdBsjDUY4c|9yBslm0f4D?(xG49)$h43gUacPcxw-lp
zhK73UlJ9fktYi<gTV~}*Q2upA>c&bkph@l2slo(FGim)$T?s2B<|$9PaRFuetTYin
zh9kE99(@Blf}^m_v7X*(e|u}UQVHU~PRg*dhrfrd-4Vp1F#X#oAvtU=Ldl$)sEeYQ
z27L?8aIRno+B`v?$ex~oY{UW?$ozI8qtYge*Y~trPe`EWm;tw^+HwndtlEvh9Ru#Y
z1Cmiw!LZ@Enbl~R)l#i%z#O`U9=4GW;NW^Sr1NYAndCr2t1&Q8YzV||M~PNXXcG9A
z<*#B~`KM-JprK=c=us`j--dj*p(s$eQ5Z3OAIyCKyR@uX!o}DF%~H}t4KOFU`=gVa
z+Uubu{^GR9!kz3R0(V5+fr4V+KFW^2-gZ5fm%AwhnR;h;^hdFPn^B3eBSJFhvSLlh
zv)@W8c{H8?{c^mL{RI54KR(KwpkG*vh>$g|=H-rS+PnriR42Xl<L2cb32fiY!g&v>
zo4+~<OoOY-`Z(e*<tYX|zR$2653<a30Edb#txyF@a{l-8C}3}ds91OBmlT<6a^xTA
zY>gaEJ-#UchXC1igNqz=0)Wl+aB$xs(4n3={6D#fz`gkw5L|>51U@Bl>00qi8l#iE
zMpd5b!OxP}=p3Gb#?d0Nc82m!p#uy=C%4Xvx=3se8@`{fky5>qsEuKoguf`=kcwSM
z!i3$i!D>+L#P9(WJVvH6cKRY@Zg@yM6wPb+Ja+L43bt!~ONsm(PsJ2ze(?&Kyb!#h
zG7!3HWsh@#1fmWk2jVE<%lR=bNLrgYqc9*uVc8O+;}D4EAA`al=xC8)gWQi?))M}j
z{f(TFctc4|vF)#g3V@U=(s<n6@Rq_UM{S-u=1;i$lsY!i8cj`miR-XBbe$%os-=N<
zL-@i*{6A9v1@hbx_&gIT9%##XWn92$mgm+utDGDmpW;J{niR?~D-!JyvmprVyd@yM
zUUF&?6<dD{Z6VOZwez&WQh697;he2>=5374r*15Hc&evq$fWuW`v_qGdfLEPl`6vz
zQoI_uTd==<k7dB4#tLsT#8K#Tz@x}>OX^K|#F-;=8);I`QMx+Oy5K>ejrYXv2QK|C
zR4OLvJe?JxdGrahw|1UgoUhQrnq@4=k)=)RXcmsGjmvZvEn}1SVvv@-O>Ax_=w-k=
z2oncp8B*Jk3i5m(I}}C<cqy|24jr0QXzouKd(WjIuSP(D!6S$wKN{CqR&=A$x2!73
z)6?A&=o4+b1x$kafR3jE8Vu<<W3fb&kxP+aA&{l}d=warS-?LuhjCzc;=O4x?75i$
zH{>aF_r)Z48Add#kopikK7%nJYC`TlMX&~^f@)B1Gzo|amccL)21xO98|pi)1v<=S
zu{t7|AA^Tv@-vY*kivWf78g}Y%R@D6IS-iWqzQ1EQpRlJF&S^I0B`mhIt+1XU>cRV
zJiL*v7cw}HqK$F%6?CW%eDa!ASR^l2P)lW73mEr~%wl@Y4n}<t(%}J(l{!5iV#wTl
zXx*cM36weE03a!H7_bPRjNcx!7$0cy9e8pHJD|)ziZoYgw=Dvpa!5zC=O@FMX9(bb
zeSmr1$S)lAe$B9!pZqffdNfUecji>aZsiQ}y<LCpN!WgW2VhwELVitYjR-{068g3Y
z4(P<c3k;7yC^;bNwnN*X5!(@gaR((~d5u{?Oh+wQ(cpdvp<kgbQKt3!RhY7Z$_8@1
zAjBUF44a`~Za!Wm+PA1AGT*`1Pg-k+mR`cS84Enb1H*YMYB+aA_<J?;Pl@A~rfH$5
zR!Y6cemOC#6d2frzHlop!IS@AG#S(XlN|iNG#M8QBjf*<CS&7bVgH{s*)=z$s_JU%
z>6W(zgi<0fL`@$fXK)k*wvmlx0}%#TO@QVZej)`_g`}ENa1<RzAH+q(fu^7j%}NEB
z4y&85R1Eq25ZMTn^U1BVg<#UD&Tswe@5g2BzaPFWZ-sS>wx(D9&n;l15Jib*EWnt>
zRK+~OfXP5P)c8UH$D;QG<qVV3DK}}zcL5(I89kLz&4)R(@Bsc?FE(;YN<b$Ob)SUr
zCMyX$-_}R#uYSnJcSwSnp{b_gS(n>CC79QJx7d(4d8c{FJ_}&m&$0HSW~=2DlR{rO
z;+ycb4q~CdpLSVs2~cM&R*phe&>pPXK!>2fJM8qdToH8WV8A^F)B^WHjz%W+pT`4p
zU;+O5j2zTjtGKnnjtVgGRAx%$ebiAU)J;6_-_sS@$VD3O98o(@-%FI9-E}!{IK=y?
zmaT{T=iv79jLgWftiqj6da=mX_*TGJ!rpsaNKY@+2S3a+g4t%U_ZE@?F<{wX(gD|H
z{!OcjoF?XEh8wV4Vfwn%!d$kL3imixu$;E;^(b3Jy_(cGVbzI&pz`#bGcpv&t;FMS
z!h}6wiwT4Ry^v-LUGQH7mR*BgX*0)3bE@rx{d{OQRu1lLPoDkwV6Ubd5NkNxuZPVp
z+68U$4#1&<J?Iz5TO1X_oKVBqmU%}=%1T&$E%NP<wm|<0Gy)J`o&9UbYvu~b0bWXx
zo?J_C&5Zq^AN{j@-2i92t#`pe$Q=TQc*v}iI|5*L;NAe3dvHCjm_giQpl^^3#8;}p
zO;nd8$iqRSJicb<f*tfXq=z@;q=D;zpJ>eE-}<k@-x0C*FG+)$QNv7#o*4n|R>+P*
z|Kdrg@89Qo{f4yqpZZCtm;Gr8Rj6DCoj%k@dxYGeHqs$s1lNFaJmWzmRtPx>U`zfh
z>{7|txPjhBI<M%g_0U#~R=0)aE{$^+pRbf)N*)q-R*ZsR#Sek-72iiha#75nk@F~*
z&`uvcedqJT+W0{NwKvKi*Z4Qgx^u;ad5T`uLT(pe-_Y0wwwL~44*|caH5SqglCnh4
z0ZRe2m8{&sI-^;@>v}#HC6!1A_LdKQe)W;O(?6IR@WP<!pz<L10fK?R0n6T_pUN!^
zXfbJ}2Fu_I`6U}u+ofI0B&8gs&cuzgti)Eme{M}1X01G%H=%$`K=HjP71zinzxE5x
z#Qbkbjul<3?S#8Ojs35MwD-wwXU123y5F9FUuQT-=pIBPFrtH4MY$qXlggMLM0?fI
zQ>9C5iY8P;^@KE4V>8M)pt^bzsAEc=3eeCzpeea4ZK2WH|N9X{*}<gtDI(5lr{$j1
zJyg`I7sn$9qmx4*QKKS0OTfY|NinE@G<I>9D&w<!k&pnNi3@uxC$Gyz@;U{$`ulfW
z=$~o0O6EI@x@UuDF==>wKHuMz?YA9m%x*`oam`;9Bi74tvfe4Yy%jVZCvjfE<0@sC
ze&bLSl^DWQpL2A@^xQg!<mZ0h2zz|La5??$Wp=%1gVvijXk!tZ-=IO=upv-1Cn{-~
zKQfWj#nU6cA8Q@d7^bV>9&Ew`&sYML)mm+|dtS*eH-8?&?$&n+9*|B8AWUNt7R0Cl
zNKt5YbycMB{ENAefiyTLbm`u%&{@C<H*Z*|(?j!?W;Z0M?JPZafWdI;IBgF!AO!XJ
z;?}~#z!A9Z*D0bscrS9zNXKJ~q59~(@K+3^$Fhsw)1e@hK6k`Eb8GR{kp;Mn6OE~@
zl)B(Gv=wo(931Cj))sD0(WltP?DJu^)XdD(R9KeLX;V8xgs$ss--xpt6ycc)4!mKV
zv5!@OeM!7;8X7`Q53v0f=!yUv<xEW~w2lBv=`yK9Ka+`%fBs2RW^j|u>jEbWHUaoB
zTH#QJwf%Nv${jF7I#a>cA#M15K>j%uTEm*pTfOJ5!y_@|*^aUAU4J=tyl(0k5S!Jj
zx5LA7v^`$B?lRc2(=$1CJPThoRoaRfD+HDoS+`YYP%NK-Gu6^m#q$Crm$hvR#Udlm
zP{*&17FpTJnWC#Eno>|{r#2|@C*$L28s{Vpt`xe^PzgGZSRSrctng>fy8(NBNmI<x
zwX)jkV@X@On}e7nRU#JlHx|Ce$J7s-DxIq?;M8*9Ed_~j1*m`}@IS-Sk+M@!Oil9H
zlQvq;Kiy&Nd+R*wq|=9PNz7p;(#=eLJbFx(hM3C=Iy-?z&XuAQAd8a5#6ic&3Vg)t
zSY4vU^jZ2xiXBNE#e5gJIzBMC<n?dQMHme1daYkJ?`77v`)O0NpOV%@p5E8Oj?X3&
zxtMba0e)UYoWq95Ys_pwg%MRlF;xcU;X`FKRYW%PVUVroiWZ{)rp2vt2$maHWSr}-
z>JEjmHk~wn6@j^`ZVh?aEu}nwAtJ{**~a*!)mrr@vGdsNYWjCOQv7IU`-6*^?_+SL
z_gB2_wxXKYD)fv|gM3$ITtz7?@*lKu-RUV+p{sq8heMB5dA6%0gEXhxWij%h7*_nQ
z@)3r+&}kRSd^lzoVC<R%I4-4GyI9^@*r<Zhts?kOTeJRoXn=x3o)<EzMnh0{k8^l8
z9l}g}<dhB$ffA?3l|^#XpCuWLYxAz>4J19US0$^r5B)d`*h?3vLzVx07Ik6=SCa^g
zQ?{#qzUQrWx2Xa+vxg4mPOEoY%?{&;SwIjC+78qj3+iJp<tQC6GM2QWjyZ(f%!A`_
z-RNN)tI7Pknt(a&TZhlC-pRwvQS-&bR1Gulx{J_Ph?oJT%NZ{n1g`HlRJI+-uAswv
z9^Qt368_zLVpDc>g*vt>=*HOTQ2{CPa<%fnfF39y=-J-VatEF%cwT~(VB`o?_OGlp
zqiAUwG#wyv-fCa>0MU)E=+P9(*0d&tExpkxRB?!T;&04uaL>l<<jr0_hu4~`28{Kt
z_Z~NM6m;LE^+~-Z!qcA3G#@0KanCdL@B+KO<-l0Ok`^J-5%V3c1-cqhZN146dV2Bz
z>4UnQflp^dO~2hb=xFS#W@GBspkvb!DJX;jH8qK~P_4h*T8*Bx*!Dq0u=7V#@=)5o
zzRBr}H4VBe7S<sXb&tTBUi*!=5RIs8MC6+E*!a~|U_@rmLT2!GR2?iSfU)?`pw-3p
zSmv!CS(`xp0O{qe$tW>p>hoWkf6y`BS^vIo;TC^g7p?I8zj=6{_YNn0Wi-;0SBFQ(
zAI)3~4r>dlffAZgOGS>GgT6twqJgQsrE}pO5q%Uo(SHFPhK2r43q#<;@SaCR1ghOl
zzn1mS0MzB9r~>r`6JbUx-mdI~2_lP@zrXXd?tI@pZEVj4PID(L1@n33M2R>zPBXop
ze>ThC|FCN)R#ObVCdOF@K#(3k0Cno=oWZ;ZJ-SZ;*CK}E)vSc6bUPLl;>;;3Shhc*
z{YptRl)jn>O1VI`FdhoZ(J=7@M(T*wrTNLVS|J$adv7x8)72+I5N2j;2pDiT0I>|i
z`s0ki{dd2LM@_cAtEso&CzBfjw8%q8_xL#Xz_#U*-(o;kHe@IZK*!tcCEqw3m%f?u
zwUC}^ocCG;du&=o#@5j@&Op+>C(tMfkF8mTd;KoT$aCy1%%EqICSx?(XLaFqp?xEn
z2OmRIw46y(k0`_WliYWDo&2R;urp0NOL)0f2-3D?IB9kBe}p(WhaEUSb?h<96BJOO
z3B+CvEH+q5S%rs!=IO7Xu2-?KI<6W}2FS*kX?6o|9%9R<=@HGC^gA-wM!i8>XYZhS
zfB4L>|9jn|=jd>V&py+jfU*L~PD@oXCIVgLFfh#AfSm?AF?Egx@^f4?Zm34m%!Ulg
z-V5A5%Zn?S!E2%Mi&QN`G9?l)>Wfl>q93YD2aM{&b2&98E~)Dd@!9PTZZG6x`b*id
zq&wj4C@Z+__=`#-8VmvZlm1H<=LK@-3E8YC-aV(wSOn3)SF#8O*9o>@RIbFjs2!Pn
z(!NIT+W19(4?;VL>8xd;e3~Vf0dJu&H<CDrL#=fqjE=?tKau2KI6ErWq4ogZk~vFH
z$YbSGh1$fzOa=4OgC~io<fZ8d`m7~#oLiyWoYf<8RfD`cW2n%)-zZ0S^cKqEIl67%
z{2uGWHqtSFp~gyKIz&V0_J#~!$)n)8C7_5`_hEKsAyAEtT}{{o3m8w2BGwB?XP)C0
zg-e*ZQAmWsTh<+UF%jg&W}x|JAvu|0W>HVu?lL%ObOE+q|EzLY{+b%+A2j)}BB%Q=
zmlN8$hoQ{Ace%LydkBpg@pYCCXHCCE&M39&i7D}YNgc$<-ve6zSoC@|ONkqoB%mi~
zx92Tn2q};ZLp?1AeHKwIp7+jjbRDzl<R<e9l`~}MLtKp3r^)S;@I7cl{$c{uEEwW|
z$1fW5h{Lu+&~H7$K6|7-gP+7|=?p4UO_6Z<rJ<u-q`1yBo7NzcZ&0T)#u3YjldY7A
z`km_ztlOc*NA&a&4F?&^c_COwyc3$cYWdb5ID@%?lP3TGMBKOiR5s#Ga2sN5C+|yT
z)%i~DnXf1yp6hxUQPBFn2fEPhOMdf~^K4hg@5$LtpaVqFU>^vXk4a2@MbO<w#dKKL
z<AHDS+yuCcj-L73znyKzATKF%=oPp*SVIpLsr>F*)HL<nG&Q|vhQNbVmW?=~BQ+8#
z@uCNbV^WQ|+GDo;$<HTp5T85=lb8zr4#J7k+j~^X_o=v<`gJ$y1m8u7XKkKnyOvRQ
zog&UKHwauXA9%9j;8s}GM^agW`M5FK^e$8P_Yw2QCNyjtms`Hp4nwS>-*4nR&vCoM
z$Z(uykUGLZ9NoZhclFeE5X(=Gj{ND3G+89hWZ;a$56Cz?Y(-RKIacbyC9(rIFtr#K
zv-Fj7j_c=QVStan?7HUaqEiPvKNt7xzr4Q|{cR%4vWfl9&{ZS`1%B7YD{I{C<%vN3
zWB2i)06fkr!*zKXZ(HD7poqH)WW56K>C~NDwgMkLVSDpFsVXABfJRjRTwkIbv6ym$
zp#`B+QEwMpBxG>)iLdldPDQj4ge;x>b{h-1D<RnMuDWM^XNstPvX0JOXR=B<hi<P|
zULL=X%j_DV5TxFFPs%JF<lShDy2#0_mk8pEN6#<)JKz1g^0RMt6@4@a%<I)ytbXKU
zO&t3H!I}r5d1LiN=kQQohhw!L^zkMrqX4rhjO2xI3+%=6VcC6`tvLtd)m2fwa*_SX
zl-BDwaqV?)%2F;mww2ktPIOkQ{ooa|f&0i&52T6P@xu9|dwmZ0)uGUzmA<y21aK&w
zB6t*?h>~tS6Y6|y*mbRzxO(fn<khu<AB{CI4gr?B8CdFt9Wx&uxSUqjCKQFHjk<pJ
zjA8r+P*2Gp#+KTu*dg+FQc`!NO=d_(jNo0Jc`8z8rOrNVv>_mPC2*;;{sON}_QyJ|
zN>q?8c$YlZDnR14Dl3C|z^F?T-3WnmP;}N{rMNhf!3+4^)M>gpYwljGWT65>rFo66
zcI#kkq`ill_i5s|R%ouA!$qLCz_5XiQk$X1TF=72p0)Nrf0~4Qh-wGwtL+s|=YW<2
zk3G(U;ju7nHMj7->zHgAHa|BilQm{?1VEk81P{Jt2_aLwSb~7Sz3~-9sgN-(G4iCh
z1@x0q4x5ar)~2$TS=?<_X3QsGm?`R~76{6j(Sn4-9=yF}++Z?b*l^%q8vy{Rf${7c
z;XEyb(X)QuluQDc%UL_tles~K-Z0UPj*SXkHtE-AlaABXy6;55yy=xSeM99_jRw^n
zjLVw4t(!L|)}&z@!_pq#tQ0H%dqN6bP=R7NVuGqIl}S^;T$4M3L-|L7=aD5`CZr^N
zO7Mx9&%Y4FW%Vz|V9b1j|Nh}pIq#t7cJ7$(m)3eCjDv)e*DSw<%8wCDjmuEXAiPx9
zau=yF>KI!f(ytfl&8n7{zT42O>@ZorQO^Nb=a@v}*hOI`R0yW1ADP%z{x`<nG0M`W
z*%mFk%kHvm+vu`gUAAqTUAApoUAAqb%SNxlUElled&a)w?sLZZxtN)eGc#h&jEv_o
z?oM`NdVEzQR{qv$W`TnF?auMKs?Nglnj5ZK2h@XSVa;-e@c7rh!RiW=#FeJkH9_l?
zN5?zLTSI9lQQu!hePMRvI1E~qaWvb(N%A#Z_im@Ri5BNH#`$GhBBgBf+swPuMNGNh
z48w$0=tiyI?t}1yH6$_hW92=QQR*x6JT$B}cDBc*p{0}ehFE^?l5B@v6<fZA^lwnO
zNe-@0{?zMr$x^;0Q@S+HH;C#S)Q<RuGQ4cC>F?w<x^q#MOH_Bdqv>I%-=W^gNN=g3
zW;Nl4I*k1-BLZNkL_NOVa{nQvzCGt~GBB-!RnB+<n(z?t^WBjA$q#0|nyb!7bLkeR
zDJ&M7*(5cTosu!@l-r}tXzG?bawCh$olC4Zm}#|QdR>=T<I(u6tj>R}w_wgC@?~Uy
zIVaW3q_pEv*V(VA4e)zsIH^e<A_B=pDrzF8wfVhR=X(5Uv2ezmeW%}U+Zc6FqGO!r
z#f2b?-%++RSdMTuCSoQDjIzRH+dKXHChayWIC!hvF7*4_#ST*s<abNmKb9r&@oe1@
zYVU1Oe$HmHUGmttco*qe-e<Rl4+4lQrkk?ip((7y;+p6(>gblM9^4Cau}(s*qYfmO
zTe#L3PCMJx0%RMPw^Maywl5sEb(V~AFHd^hVoh3yIHy;ML)9w;+VlP~H%DrrQ$!91
zzgJU6;C`FG8_tGJ<K9p<_ybzY<W2<ymwtK3*G|W#^OC1fFU_KexH+Jor2jd+Rhg=J
zmCIGD_u%8!*Wu1qQD3ofcH~tSXB(yU-iE@<^QY|{8nWipwKEvVx@O4;&-zZyK`l0^
z5%7(RS>uefBuW7fp?fY~mZeJ^Qxq@UOFQy7=$WkcQ<#u9OJLVRs=BL3<)j&utZ-qe
zzgI`Lj37JM&G?6#84cQ^OM?|q2mOuoM(d4sn{|s5tXMjWt(&483Eo6H9`Dgqu(9a8
zSadhJT%F+X<a1RW<Cb^f^4I3aYe)j=->hbsnjx76_Q!|ykUfOQ_=T6Ea2R31n@OK9
zGSM&N-n^g8y}Pq>{&`<1oQOY7N!BOX?tujgPy?T0Xd`22s3W8340~g=yEx#^_iXL9
zbSU&4PDI&CcQLllt<KxqzJ=9Azb2v>naxE|L4n5R>**qV)TPt;WaF28{isOpwlZk+
z@UU+dcL|6+?rRO=l?r)GLYyxBogZ@I`Lrlv)zo7q{_ZHxWil{FY-4lxH`h1khX8<t
zgU&*ohEWpaBQz{nHlg9fzp21ACZ?dIj&&@=k!eYbEy|I7se^+FY$-#_pd235kG)c?
zbqt4Z6{kbQ7A{K6@b+26S&46JoC=@(mY=jB1;+I+LeM7_K_OvGdyytpYdxG271#-7
z5m_$=)D2UBe5g4U(t5(zwRsF*0VTG?z?{$7(+Twu_!Xu$+Uw7_lS1_0rts~jU^`Uk
zU{A>9l)p8NXz4fAVY7cFetlGwlpOdEW<s<Z8OoC_@fQ%x9>NGSL#;W^MTO||WP<rn
zv`mP*q6|->0u<h0PoE5<C4_jfB`oZb>tY2b%STyPi7Mz7$RQ;}Jv=RG@f>EuJ0g7)
z;Dkc&H=05}Q`vFg`IN52?j8<2KM?m%!|#v{sStsJeE7YB4!9(JeXEZ@>Z9TZd2{Un
zH20YYivtQIYmyNBH6K|@M6Ef*Eym=-s|Emj3u@t+vAz`<rQ1UQ)lee3x@V3}zqeSO
zKvifKw)z&Fg7KHe*9Dm_59G(eZ2~-a2#RJ3HtcTz?_D3Jo5hDeN|QQvs-U@2o+Z*D
zHc`zVeNb*vC>b0C1x_mLLRk?0q{58bn2;b(zz7u@oW#1Kg@7{1tQA$d{w-b%^h2_a
zUsdtf?C+3~5lQUxRO!EencA<m&<+pqZ6!-7M|d{kq!FSWn{$wp@osXl(Jw6k@y5A^
z{gGY~Um&B-xKRIt2LFF|L5Gct^S`U^ddbsKn?lGTH(pWPc8Jj@Ws>(n%pu#+NN>dQ
z1VX72`u*Cd#&3IVvlapkf!H=GF0SsbE!xKycUN49(KP-e75t&%PlId24q4X?-_G$E
z1~sv(It%nTlKnTWS+Pui2=Lp<v=fZ_(L8&reg5d*L?t}`W6hZ}m{$0X(uEv;SD5?R
zor@~4efmbKJJ?R8hlf}R?@RMolhMbynm>{K>~pE?qe(DJeM)%vVvIOpW`n#auh%{;
z_uYt9U!-C6kFz2`z!y;*yX)(~PjaKfemARqAxF-ohJ1c8?*(U>gVd6x(&|?Lf-E@P
zkoFvWLlh07YA}RYUzA@XxThkLm7$elS^_ZFRvfH>Rkm_T_0FP#lOC~{l|@gYmiSqu
zdO~WjnTdW8ZV_$@u5?d1R0c7p@sC)B&4fe!h_I-fq+D<?CN%y8-vk6SEgsvW^J5dy
zx|>T_N3e7*sRCNl5L>UNkE80Hj@*3+U;hPM9e$IynL87|?4-|t4+cJ%C-2F{dZ}p}
z*uqltQZo^#XLh;cK*6xR_F96uWZZS`b(~*NUKpQbuAyWq{_@#n+ci-?)?m|-M=HX^
z!rTS3twvMsve!o*=jM*F>}lptlsEZRc>IyuH_VJO&uQ&Ge^Ac=q}%@iEdO_9lh`@9
z{=Z<E{0~^fU;akv%VP#FFC(oRAQ(2@ksuu$fj?S!LNt(>c<%QpR4K3mvC_U(*{RmH
z(c;bP&mBKl=_Z(3(G#Ku1PlGX0Dme+IfZU`!(1T{EUZ8Ju4;0l^<;bbZmipLfMAJ}
zYysem13LMZCr|CH2Fi?HeE$rv#ArO-1Flf-j+tlu2k2v}XrdRTT?^tvdsiOX{$egM
zl=S3wjUin;u%Em~zdmILCx)<3H>+S>J8y@T5Y!cLrQSI!j|%w7{|7Cv6G<zNSKd9v
z4rqgu$`gxW#qwk7u-s{i<oWz#fi5BfWawz9jrjyiL3C2VinmmnR)2L>g!pwq*d55r
z!3#7BG&rW}&BMT1UqhZB*H85$9>r20sT~k0X|n6-6QH@Q)R)*EE&nWfa*6(D>Vtz3
zp})Z)LWZMZ$ipyb=`Og?x6`(pIF1(~r*FHeRz!w0Y2nY(<>LHxd92unm>KZo8f<1z
zhz=4h5Ge>>bby*+sWI1<!B8l!mz(4Wm69p0hn^((aZg6O*Rt2rj}^@bxWbU4u83mT
z$9-RVv~&=8&_~F%)DPUpuxK?}iyDDV(ler^=+i5GlC8=ZJBl1@S{HuA^8#xm8sxy=
zWa|b?`*J)}JL5JhPcKMdtC3f8nLzXXEgYK%b)<B5t8%t+QtP;Sv|V_5Uqw1Qmr>fp
zHQ^?8KfESC;r1qQtp?Cc^{8C%l;yPQk{`qtU^wHO)>(P}fHw#h75@LDkL|x57pi(X
zm=ZB+Di~Rr8oMy6xEi_q^M-`IlP#l&h`k4q&VN$yIk{OGIGLC@xj2cKnORsE*qOOG
zxY+d=l}(-PU7d_gor&1kfL~K)lytIpbsz#31N--X|9Q!%Ld2-*WN7E?VCZCOXY9!+
zP2}R_YRV`Id|%Ae&C=LZSyDtm;Qw@3$<6ZL*MWExGhzS{g1EcFJbXl`-$tW1im()3
z%*!qr!wLNjIU}k9Nd*zQDaHieklJv?w#>c(AFbbJCUT=@(DbXX-{!IcR(TQr>3)rI
zdMuR7QlM&w#6}+03_bS!|6r^CwypnfY$a`LXl}}=VQB&^bjHrf$|z-OX>Q>{#LUjl
zC~9wG@1){jXbiOR{~9Wzh^33OqN$Upy{&`2ovED*5f`Jh9k6togZ+Ohr~PZ3|EZYT
zzctkq4V`SA|6^iBCsPwkV;6fTU{n8T$<@}*`JWE_)2cHO@FFOqikzXdH4z)@Ka=xc
z#n{+5Ia&X^J+m)AAb**fr&7S^`yk9r#h?&OAt*;ED_8P(cDA>*nVWmrdXAde+5!{1
zs%=MYY}}{4%&aOqOHpZQRj}bgiw(>iUSQ14JYrt-w0Q-$UV`}WawVx)cgK^__iq_K
zzY1=A2&*o5k{V)6>5OqE*9aqErwGIU@Vw`lVyAj<mnHuDfsP~~_(i9)vNFNIB%hY=
zaZOe6z-rxSV%*#_!Ek-m*9vD+bA%<e;qf~lT$@r1HWl}q<mlfIjlMYDFYO%cg{_X2
z8i3Pt&y~$OO}n$^C(;hB`G4Be9QmYrPp!4SD`#URXm{s!Id0za9X)!8=qzo>G+}0L
zv5ot<F}vcitEoP<K}<dT`SQo?zkV0;k(&C;WLCHM!fbEj&)PQa!F#oqp=-`OcBJ{f
z0?VW{cc{oD=4viycGgRVOr=K^zY53HKb;gr1PtEk@T8+YO8n&w){vKJn>|MhHlic`
z{imsO#wuot32w5UZqh2IJc5E=@aJ0ncE^pL#wdY`9kDe_-?jDFKmQW*5&23lr&3t3
zHdOz$vOe}yx4r{is+hiL`kKm6UtP|cIU_aq7&P=_6(`Pk3b$&^OrE-~?b3(T`sI6E
z*t6^+?Z4xnyF&VHZ+T~7<3;znr+xO9)9FQSp4B>4EfvK@eGw;To;ww^Z<q--ER>Nc
z21+_@hLvuXrE>^aKt;!5>vGL;t>rkNrBcbE{de6zQwTIE$QAEZn~Rz>-Aq`g9dxZf
zexJWqdM*>SBceBL*s@lRsis7D0e#qf0Z;h@j79mtPaFwzuGD=O^;K*MjA?Cs(ACD}
zj*E8dMFJUV4D;6R>x+M9H|Ashm0nL{AaHEX`0L5uh;xRi$XA4m=!~Zlw6HnKbRX$9
z3GY2kZC@rPU=FKtgz6Sws%y@Fe%1o7EWJistHgAXV6~PLk6vdeTSR><`5S905MGx^
z<GsOtGOGs-Yex>ZpT}ddtWLB1evbNzCPx8^sl!6b;%m%%KdVRX8^<asXp7EE#dMcc
zm#)F^pa+S+!m_cz`^L)oiaHwGGbtupMQ3a!ZCYxASZV*)bfW|8-stsI(4w6Kp*2KT
zdlS3toSP22L*RnPu84jPH=bo{L3!e;uWC~4PZ*tZreAQBH#iiYG6*tTq@re*TExKh
z1$=yer;ERc{^gwkLEjcob5n1}f3)E>r@sDMs~V@;=Reqw@qM}KI&5<xM@4)QxYgsv
z=<<ytB*Y+PR!`Fe(GAEFsYsb&!kcdP$eA}u%EwI6aVKym^qAG&E}nEUsi$>#Q$3g=
z_p?(~HPJt1lMkg0p&|LPg#GOU=N7MWz4QqEZW@2a*WTP#(1w9(oJ{|p759wab`!F@
zpeCM)^P&gf@z{s2>03lcfNN(MlR~Hps1uG0Gh|CeQQ9f_!Iw8Sfu_^e`O=fr;@a2I
zo+x^#rA<PRmxHj?bJ=y9vEsXp_Xzt425MODj8Ih{1LbcfwMc7-d7S7p**eG#*l}yN
zL)q@A1NfQzy8?TgfRmQ;OK{F}(f```c*fJvFf|E7{!mjdq=24d288REDafB%5v5=3
z)YX_x=}%$bYWeMtFL~^$Do?AQ$uiJz6;=)s&dvf(?<;;EGj=45wt67^2!Ux2RJ@0?
z@&esJ4&>tsJtgZ3rLJ?n7EJKH^?t5|S}|d!NveDJ{C_(k3hcySaQx}aJA==i^TX>e
ztwa<Pd@e@pqc&`Hs1Qi0q+7h~GRza~j`oS(o1FI|LhkcTkFE#t$KcM=%6W(KI_LdM
z%7#fwIaX42IdfOGf~m^AL4%QKLt=1nse+kGno&wTj+)wG*UQ=a=WbK_nhCC&e>O`%
z?Yi~7PAAZU_xc|b{?9*`uDe#GmWrKm-*UkS;B&r@RsT-MEMu*ns%YFCx8+UtJ(_iD
zB|vU^NIh0{(L?;(%{lY8?=9BttB`vSi%s3!BV`|3-Bjxv9xyQ_{{$x{gq({bJBQY8
zC(rveIGY|I=NXD4SNCt*Nsl`1C#9A@#t6@Qn_jO3N9(d%-}or>3^nx^)$~>s&j*QD
z;4z-sWa((n=&+i!mcv#qMQ@JqeO8rq$8TwiJXY1nIRwtQzocK^PY0y>s3{scp?Z}x
z=0aG|QTpv0_%h!P*!1FH3Y9f4*FGd>`d@NtvLMYlL@3M_{;LaU_d1!l@#5ix-ZOr9
zJx<!`*eo)Rsr&4E=3q1MA$F33Lm-&}HZsO?%n2G3G&#__ll+gpMYWJ~=T&^2wGsmb
zJAfVMJc+s-O!HCMsF6xsiqHX;aUNr+A*dK8YrIKnI#Mmjp3d<GK<s6Yy_R*Rr=s}y
z(SPAy@}|v2PDW~BOLgxA=WBTOv3B!BN>z~^O6WSfmQqt)>`dUytRN=b99zH;wWOP5
zv6O#3e0TPGjo$3ImVaCL!SEpvpaGU9px~m9hIu+10``qj;xu4(E~cEz1>ei2vNjr_
ziaMKuS5J3Q;`GzK$&H{TSrtrJwbUv7AD8H#4Fn#$xIA!=CEP~T<tE?mp_);Mg2NqL
zK;Ih)<;jUL@WZ>uj2XF&vQTomZx7=D)E;v4#;r|MX$i|BH6!^(P*55riGFUTk#P1d
zd)?gULJBKsK^U2EBhK3lVXK>A2SP6B%NxHz%#J}qp432ZdG9*4*h8zK&nM^VB>(G|
z0dc?$SuG`>k>!=j;qc-t)_%P~fEn|c`3|xKbBI+d00Y7!Wac*ed`#VHvzj-~?1t;I
z-1fkB#`O=)pHAFpu`qA2)xOAWo>7D+Cs4*ZN4(&Xo;7T6QxQzf5|=<j$Q&gM^@M7U
z(#H8-!1N`*{aR&~XBjVPY4*QHKnEIO$%2f79ktz=+UGcV#a#oz3-X&)fJFqH5@UaX
zk`}TOOeJ02Mzxh=sOMpBwXc2GMr%f+(`rtS$l_5x=aTQL|68%kOCb|)zqnDg*-1OZ
z<d2ZAUy!Gji@YWE*+(-N8?9Z>xem5F=F}BOwuqOZ|2PdgWB-8vOaM3Wv_fc?9b}y^
zDStQdOl)*iNV)^;ApNtpN8PH6`XQS*a>_ePgKw7eDf7#S-pWCg1~m&<Pun`ISd<6P
z-5G~qn}IS}oDy;paW<t4QCxXc1uO34cu+ZJN+f>QR#!alrhCSHG#6jlzaz#04BqQF
z{l>cP!Rq$X?)1*UA;c_n6xMK2UvVL$0CVLWn2c)?N3CW!Hi3Woez_Un-iF_-!4Bs(
zdJ&LyVa0}ubAhzohuZyEva@Rn=LI1*e5pM55`>6X96A>}SV={fRlo5xL36R<Tf1$~
zli3<^eTkq?`fsFQ@Sci_I6@IF`obV-?^7e#I|+F29x)b|43qn9gGt25G)rVKgOQqI
zE8o+&()i)95=S}{<~9$^k#b<7oi4R@qC&p*-Rt}7`u^-`SGbD~|M2_5T7p&I;To5;
zAQcac|2$}l61^?je#2<fb*tq#zojs@&3q#4Ur)3BtdofzFOLv<{WEf_qx^A;oqpzC
z8P9^j1<|YkWIN!E5u#XNiYlfw-J_&^qT994d)3kW!AwP;I8DN1XX96RXQ9-CN`GzE
z{zchx`0Cp_HE}^B?qq#7BH1Hsj&wd4<tPi^qy<k|RiX3@Bc_n-o7`$?PwGJw!Uoen
z<L^!KlTj%NT{l?$_7yt2T$?p;0LB>ViSLtw*ffZnNGy>^EETC~yaq8#)A8nW!SS2j
zX5F5e=5XqSjf^TnKJDy#88}1T2<ctL{M@!o!o@C4{B?vtT|O*baV%_3f>KqSu_od&
zf?7KYUYVwiwpOg|r0{BQ8-6T)AunZ7)W4DNE>2&G^$(ySz4!W@c>Dm_Ox#prh21mO
zzZuHG*7GRx;R@gapd|Kik_N_@v(&0AU2nW;tyjOVOz`yY>lek(v#Ujh0V9!yKT6zt
zhTJpBDi+igEas;V>YLj5>7^6G{x;2m4u@G|%XRDf`YLpA9i&x;n4T6+1;VBh!8lf7
zhHAodx^^|C!wnA}D-6FU>T>t~g$GM2Ltn|T@qU8-?o*vHXRl#6AT&T@4%I?zwV1WK
zl$H)$wCmLzM_vPm!LZTVR4sMdTbDPUdlR@CAGAQfep|_{9_0(JdGGpvRkAG=&BQS8
zgG@Gb^M=#bvT?eZxL!IgwZOTZX2yY;igNE~Ai3|t>GK04%g`(WEYl2Q4+Az6419xd
zx=L9R=x@eL-6WYyTVMsg;nusn*K&X<NOJ3*wf`a+=kLJK-Dt7s(_2G?vsay98<XF;
zu-b91ccA(TY%;2op()}GEK`S$wkbPVg~;V{eB-Ou`jEldkNH4aTPL%GrXjLmIQl0P
zqklpC^X)uW-B~uG%{5(F1y~hV(_5$dY5xn5YuHlL=~y2?nhvJ3apL$mOuOH~zwNuq
z{I(XElfu6xhiW6Csy)L+!oew{#e`Q;H{Nzz>v;)jGL7DwnwY!)hi0tNKI(KbKz9S<
zMt*a_)N4H!Z*y@iL-vsBV4GlbSJ0Fh)wN!nSY!4S(?Rtv_03e*Tkm!6o#xclTTE-*
zUk90(IDc{gSN<`&?^6dl$f{bRzg;ln;ETI|!7z8zz%{&sZGIPIc>CPdj-p)<X)Kp+
zIJ4M2c$)>o62KY-OgAD}h+;B7Sm7=_3^-f9B6ZF<J7($CSvnHF>R<P^Ri}It(oFf+
z5$M?Wl}O)>38kG5n9tMxbV>>?^}svUEDsDdK(4kEp&`R#GWac7nK(|C#;y$v0lU8F
z%U8LxE%vy+!Acq#n*AmG>RKEBsWl*gd_mGXuon+DMzTP@ua+8la$^4R+DG?xTPGAj
zMqg^_1PnR6fq{e8<9*t}Wx5vly$2OW;Q}!aEZbw~XKhpUKtp6TUxTgrOafA)J06-d
zJZq%JKk;!*@a{l%U?#<Mj5mWn4%Z9w=F1!&B1~sxKL}>{vwi^lK<+n$>v}b7I;>M1
z>aw}!W5t>I8*|$&(}{7JQ@*59y4*LL>o0(Ri(IVZ9KT9pxw|eU1cR`IIZ78%(KsGj
z&93IV{a0Q`SG=?3v@2?K(~iz5f0=)cn?Adw2nELW4@73Ie*9x9ei%37?jdI@!${wk
zEN=Vvq4nNa_KZajmVbA;GGj*IURNq1Qc$ZCP3fP|?ke#(n-Rc_?}K*0ckrt&fQML!
zIbUp)x*OT?n2A2i8L2z1>t&jaEj71cXkcpS>*lLA=WmOav;|#i=8!zR|4;M&GLlk#
zV8w2_B51LuCxE}s+v%62im<eoLfCxE+0gBKhr);X=P=unwVYISX(3s%=xH#nK@6DD
zL}z61K?U9^WQm{Xb0pyj!TWDjRjB6fj4dF21gJD(*>-qDnfJ&g7E6(VC9se3dyB1A
z{c51I=E#`BoUG!m^5DCEcw>`0^wbxHibNrkxA+YUWyT(N=;Z8Nqb_722z^>=U5Obj
z5$^4SB@nMCKpqpvqpG$lyae6|tBPkLY>=>ugCd8?N;50%)~3Ci>w5c<oil24y!_|%
zLex{urI>TacM|Fc6<87YH8>V*><DTha>x)g@e)oB23;k?%T`<*QiP|trMj;Pw~n~p
z8`5V^mF>mA>KAIKvwn6S%P<+iY;C_3NIguEtRkp=>4TeAGJrRjm2`e4YhAMM=5mb`
z)xvbd8^~?_vr8>Aqv#T(hKw4-ND7EMTnCAoO|`nV?V8rPO!#K&!UyNrY&|?)lN1Cp
za<VWyKs5(pQF%PsZqcMd>q}ctK3;YiX=!BumVDmoMMXt@@577|5|ZM=is)*Kst%QS
z;l9`|xvK26ynwo|zjbZ)yPwUwU}wU7xLLS&dH@QCKgCS1zfmLWapOH9nZtQ;E<^9=
z+HFz}F}lR*Ynm_l5}I!4%?~AJ%zpOKstySAUy73&?Pc6{H{9th=!^X1=(MEJOA68_
zN7XG;IjC95o(9;MwglEdgJ~#8-uy&4H4laGkirz}CJHdbh6KSwm~BYRx6Izf>brg0
zl2Y)PjlATiv~jKJW{o~xj7eE_#b-=Bem_cz4nZYK5~S>dyg{9X?IwZ&izXq73j?d8
zU;xtgUO*UDa%E*AnRwCs@bGX&MTPk6!PMi_*x1<ndw2G)hBb)ufI)R~n9|P9jgu3z
zw#}TZEFEp_bGI&fOnAEH#~M1lRV*y5Ss#F{y?q@lmoG?QY+vAuyI26?X^EAUpK!tE
z)#q7JyhBuzU+IMx8}1b_!Nm6>HK0)_?hvFnuABEAAGF2!{z35lR`mVBrEbYJUpy}l
zZl@2o-HQe>q8~CEQC`6mgUomqWeW7M2}GpKImW1EEOhu}+S~cL_m9=C<;0B6O(oWk
z0--O6VHlyQz;`eY73GY<I1Fw>M8&vjs9DHzl-0Xtt{r7nyBS(1Hk;cOdl-G53dHAh
z5n}meO>E^6I}oe1YKFs?K^n@V{oJ$nm?h`UUVzxjb5Uv(4;yVxYm8!IvGr>0c8|A)
zTE2RPV4qaM1#YMF*ciS9HX2@tVc)QFyeUTpFiFAB&re@Jcig5?$My{p5;0s<%<Q!u
zsADLsxacX6p%y4w7#S7z_4T#2xx2Wym{?F@BMcoXli>~*m`o@W2T60<>$>ycn<bUh
z*Vh*`6!aDpw6wI8mQwKYZrX5^Sv&qQz;)4-5=L$aFM1{PgxS&qN<cYzS-hV2CNeUU
zrE*y@ABH&yZ!{4ho=0uBVkq+BTybbz`k)-qN8B(Wt^+r)FIx|KJUD&6fmsBOG%O_T
z$JjZi*cgLQuD58vyaRuQuUDd@!`A3Dwh@ktu&CCBp<*SX_9JA`PZ&iI!R5ZQJ26tt
z^iv;pQYmUV@WIlq%(~=Yh<U3812^TJIfC~46qlPu4(6%Rf$Y-yz3+;DuzS#9e9NP8
zt>ONb05rgj2Nw<jwZS($8}8}%(cA$x#rqfuWPeU#zkfX{e4$5=+-l_7K;lxy1%W=!
z7#UFX#-Ayi&E_8l6@jX=MVd9O?>q6}$>*LnH8o~tW?5TV{h0hgOH1SI?3^QS?nOHE
zAI)eCH8N!M(DVKEE{E6sdZ&Yxjjg%89me)M87~ZgWm0?EtXWie5o$EVV|GDx`R3sw
zlY^E2<8~jsY*I}{r^|A&)ONGArMVd$14FB3rKOGzQH^-~K;l4|Z8?aQM2X&xp<$!w
zTJop=hpVTjr?4<+Q*D@hAUL9?LnXF*pu4jgBy=fr3=vEr6~#v?>LZ{w`#$fp<?m}Q
zH{O9EO*FI=!CohdReW>H?{5=ebw@|evG~_Hl6pGNI+K;2lbJXvskWtCA_et98Mz^0
z_%_97y^BRfU-?5pp-s!b!UGZuS!EpBSKL{L31^%Nd3n7b{B*Qz%T2A%MmQsDv)-pd
zh{i3PK!n0+!fbyxfyVg=&%bt9K22zRRurtw6s?B~Hm|mnM5khz7lMr@p+_A&O6y1U
zp#4R2)ILkYj_C+251ps#CDcGZ3W+h6UQjbx2fW;DUOgWqCT3=4rmm#M#o_}|$<56@
z@*OB`eNd-YRt5^?mzA9^3`eIi=;7ky#EKVXmKHvPwA1Suv#mA9ctKYQFBqe*xsGuu
z?gYvZ6&T#^e*ivweOGJsHXBVRbNRh_czB|sqE^})_h8s6L;&F9&%X}%qWb1L0<O^~
zB}n(3PiNRUIs5KLzH?;7YH5(Z!Z%wNoaYL&!(R!VeXZN5>s0REOAzWW6Yg?^5Bx&S
z*QV^Cm<kR2VM{|fR%_Ez+28t6?+q}Nw1r1T=xtm;?u4+mY-ur-=|0V6ClFm0{AOET
zQNs9+aJw?uAjC|bdBOSn?5@hGwwg-&2hDJ{kF}ol?ep+liArQ31M}G-=nmK)%=>C&
zG30*pu>B&#mNs4*X(Q>Dl4^A+!W=#?M$l*J9i^pkNYXom9%{C3X$qsWHt7;%g^>cz
z?~<_XR@KZg=+QC_?XwqGHy2%gA6~w;+i^L(&)1u)b8~wxJgg~$K-+5a5fFa=-sN$3
zu+C~u;OY+e@H5yx@dODH)&a*uan!PKF3BNNra0h|3UK%XpEi1{OULF%lJMEPGaeb~
z{c?T1>%Ujiwqs>wr7d$1>PSd!iiLVwgbQzI7eIr7ezqq&Dj_MK%crHHvbeL;`#FiT
zjYEpm?=R{P;ZrnBlBs-8Uv5^JnJ;__v#tH@S>+avYXws^RfEp0r+cH>Gu{|rXg-Ol
zBHwR4KY^;NHA4?DcAv2Z)=w*~>=dg->tM(h%;&bag~TJZ=&ns$>1f4cJFa%l1td4n
z*|+eXYfrzCr%r_J#o8Zvr#0XC3E)b23r@6i1%;Eb>SvBfIr5`GyVrA2V|u~CyhPq|
zas3|f#FQ@}swXj!)Yc<+UMy}2?G2-Wg=m!Si@;;(1$$LRCk49~Q{sDg=nWkX{QRt~
zt>u*O?r@*oDJ&%Ue6p$p1`8LKowea21wiZMe4bayq%p`T$XjMo5UFB@au+>=lrs5t
z>c>YvK)53^LA;COxfThb9ZSg4;a*+*(MtcBo|)|fxN391+Q~^uYT{WPeh8=>@TI%N
zzw<o6ML6%scMdT_7`#_B@_gOvACAU~j*ecf(~jUhThkhVK*J`XrF5k`bIO=Lp*#;c
z!}U=09rhZM;)~v4&%inwU}-RJGafZG2O!Eg;s9|<vBfd@F!OAi@NqMQc{;V@2|grE
zV=%%H?X6pl>CA%%)P3A9MdXS!{5!MLQ?gpF0$K_=7M4&tpIs03)!h6x$f`y<l$ELE
z7EQk`buVzviz`$4kd<fS?x!&8rzYwN!-TEKH5y2f65i8TFE#Y{C4pNhu;IGuJ<u`e
z_qtfx+09(s^}d~C9UmWygsF2G`^S`Cbnf2t`Mllty+60T+-$>#iv-y1agh=X4=OGZ
zV|P*9aY1~<=wg0C6?2o}%S7rb(I*^x<gI#tUasHWMZSfGy6^gO3JUsToKE#qmLTl>
zq9^Q937RV8heSU-kD0yT_kNc3_5Da7m6R=YRmK#{idA~=S7ZH)fB9RMB1y^}HPK#p
z6OxkV%>UMWiev0S*)sHDD831)*P6Np(<W}UmYUq`*p$$NlbIX6=e>mbQWBP<0HW9)
zzMGGxY6RcSadbYLlra51O8?M<(VRtR(n@yyZDnIcXwmGeL!o)}Wh#=(3j5$e!je}W
zW6=UiiG&@ljc8f02q_v9F~gNeAW|&k^|)ZsvDjT|i_kI+1q52l{?+_AWNUL1Emp!*
z>vJy{>4%IAD<p6M-(}3+^f~Mg*!z84K)+ne+_g8L=l_Nhl}ty7mrW^F@4ICgn1LHS
zvPjDqt1Lr&`SlycHMh9^@m0y4j$o1P>H|q&Y;sy}9=3^Y5<W;;%z@9zs#snMY&qEi
zeQ)jT5nUYr>_*W0MAp{UR?nAT!m?!BA_JOfZ=60yV*GUqR4J$yOb=wsFgCf2DG@x8
zG0rfgec5i^jp`<rP;<gsU&ioO%h+>Ae=+%`NAM@QT!W7JH2h)^T+?hh2MlBIhy|>Y
zD%|AMCL&h%1FN_1_c`V6lO!|G@Jao?epO8d%w+n{`@S^7ZA_^caS+7YQFdzuLF@K=
zYceee8%r+6A^@x%Iqa;@f_Xw7S%3N+EwUUchhb3DXo@LSFiU5pTuiL*-J7|5*&%R~
zVxXcL3qW9fmNf3Hg$4_h!D9S8S?%lazwzTEIE2;3u0cpyQnv7iItF8NlQ@)GlHQ}?
z{V^p~5`!>~S|$RbX2E=(--yUQG(SK8^W$8DXR!OL=jGwyLEYt~kV@NDoln37p{qFA
z;MRYB-@zV)ea|>yttP7t7)QXv!8JBEF8K1^;V2>yzuHGNkb<&hM-stEECwFwBx7Rw
zA+RupSb*>&hHtLS88Xm)#BtHvWDlQj)T>NQJftp%_Wi}+-Jm5h^11{eOVYC6$^1Bp
zZ*0YHPOSlV9<7W$9J=hjw1qB;zZro7tZ7C(i^4{Pe+t@4G*Kr@qlup-gNinrFlnPF
z^3OT=HL?Y6YBxVe@ezDt<6@)Sq`5>}_~Lv<;(z}Rczx+}=hm~&<uYumI~4L7VR@dA
zU41fO^7yk*vip9*i9{$=8oGf&wN>UpewnMth*N{U04z9%f-UD>FL<DpYdjx;(hTQv
zly#d(9&3u~pIC}EdbaU;c2?(i2cK#v_`3J8m13fY4Xq%e(#g$KUM5DOo87*b5<fxa
zF=y>&c5)CJ4TPFbo1I?#gkTsNm?WWeqvD3Nh*didx)NBbm&b3GfUvq5Cn|SPL`q>0
zn(!N4|Da<!4jo(gNyl@KJU0HBAvC(jy8r^Qy7EcSo1doyUJ4GU-Ji0w%MOv7HW-&$
zJm#j&T$9q{Ht8rXzlvnNS0I7ctcW_5&+4Ia&sSCPdyv`%WHHf;DwrB2)wP_Ma83`H
z$YAQX$u@G^CA43K^2y}n%Hs(IKOdWBE3K_=AC0sb>5Xx`zhNSV*Xj5Cy#S))v&TEq
z11}%K#cYWx2aSk9Jd<<_Ly;f0Fg+>DSTsP0=Ww>Xv9Z4X*Do?nHNIbDd&u+Y^8GR~
zsX{L5!C!JQaUT!%eo1L*fRjix%m*jH%N`d7hT-&`pV$SZ#Plyr`uW<xv4puBa#Use
z*~4fo##9Z}<kaG<ixlk0RLf%7R$1Apq9Wc1e?(p~pi+_j{TmY3lmw{Q&6ayIKhj1t
zV%y$CDumK1IkGjx8)MugZOdvKZ0)6M9=m=|L*|U-9-U&4=#H)KschaKDucim!dU+A
zur187q52aG2Z`q!+Ev>Ua6?BW%sXaLnUeYni_H#PZ2bI(db-I6j!P00#`*!TCB!6g
zX>6+Es;Cn^yzaf9e=jO4E3>n+UGxq9gDbhz<Np5sS;4P^>zpoFX%<{2sK2mR-Fw()
z3<y=CY>}bjq07t5Pv2r|YUn*Z-*kV_pus?0@Am92ZnCnlb+-e{#Ib~-0P&JyiL#eg
zE%$BdlPhOgB0RkB^&mPbY9bc@`x{2fFXoYXhg`Njv4b|Ick7|WbQYxYMXiyGC;d*3
zijEHQQ%$#x@jT?rUn_FNeX=|Zc(!G3A51@?AVd2(JzeB*jYdIaNo)ygS7I)SuNpXZ
z)THZ?d@e$u;gDI!R%<0)6dG!(J_AgKLGqZk3@@8K9{s^*+MZd-J>Y(1OPjSt@ZmTq
zbrW5#wLI8=P4`hVFpSvIY8`tUWoG$gmRbf18F+XAlPO++1VwLqTR4v}Je;SR97L32
zpCF<`+@wQ_3s|40#24^<wb4Qg9u2&%P;2Pd2i&^0dz>i=;twMwc;th|J@b{zAF^w$
zxODbCYMYB)W_S3ZkqB(8t-Tp6lWH%*5ee?SdbaiS(&}_OT<#8zULoXJ<}d>z$Q<Md
zUofy0T^6|X)sA#H?NgF{bQLuf)wMgjWrXq~6mXrpOAO#}Fn`dc6NSs(l0<&v0+rBE
zb@ecL-FkC=dUBPMle1*V139F#%HHEKMdg&3!6d>?j$hlO9D1k+8?B^MT0@Q9Imoo(
zml3^%LD69%aj!qCt`rG%@#Vv8W%p-MEoX;JIlPSln>9$4+Uk<aD^MoLjg-n@qR?YF
z$m5D@BJJ%zjt@RMK3-m0x)gNS^WFvQtOB{w<j;2_3j+`%epUVaY#k4315BLPgWJ8^
zmMV?Sjg6J6imZm1n!e$~J0QF8e_E~xee)!cie#JO6+QO|>A`To!JDk;9C_FZi;K&9
zKcWPFYj$$dyVeDULkS(o^?-<Lz1rloUw^;55$tt8ttBH~jaa1%IgB_^mE1s8tO)$Z
zkBX?*<>$M2GTmX{+Yy8ZGl&!Uo8Hz?(ScYv41_y~c}m*h&%D&*%+==ijZI*jw%DF3
zouC}d42BA!c)<PcE2n}X-k+_Yu(y}M23yrYQ$&kETeuM)@UXOOv!bY~oFXNK_?KNA
z>Zov=yt7HTn>kh<vPnxgg*6c8z);_dzcRD4mbMWOj%uE1@~)6KylrF7W6$au_-u&I
zFmy&G`T)ZKj$Fezshs}FmS+_SZh_ntP7_xtW^e>wjX_%@2zZ}NjL)~Q?|PU`9gU6m
zWr80Si+^6@zwQL%5WeAP6)Ra3=ji8yM+_ALX|Aug7tLWC%QLi9Wu?5ld@jGUnS+6l
ziZEi7?3MC4Y+SGa{3{E--`cgyrJ&2Lx!}j2=c~;$)@KMs`&>pky7${)q>GF5uYJPL
z{mTs21Stp}eJW-W`RG97dOjw{d=3mwZULaH&ePCPb9Hf{vxhzOL!N1d(GF4MPteA5
zjKjtQ?E-ho@Q78Alg<5muPP@uU8~nMHF;gtGlg6W$v#Xy92iLCJ%f?(iP^i1fEBKb
zHO^3|DkQ=C0M{kfSvxW?A6ejV)1!Iwv1ZYS8|~O_LBr6t)W&_z$%V@iaHiUMF3#jx
z+#vJ;y{E!rohz_fJ{~#r?qZQo%d_#F(6f3<j@hiLq;Xz-_r&6|K4qB%^(6%lkwr%z
z8UvfoG19B})?6S~J{m8o6Ll+y96fVHk!(4Rlr@328^{MXZCcxQym(O~-?zUW-Bnan
zm~H~WDZ8f<hmk#wfgFiYz(Y|(C#~0=ALvM2F=Hj{w>w>dYd(Ywme1yh8es?G7!e=<
zJrt~-^)%fk|NgZ5E+^ysa33sU6GYV9*7mjh^CN}o*1VS=4KCDU&@};1OtiBdgl>tQ
zpCHy%;IiB2?T5JdFiS&dJ96-+)Eg`{U7ipJ(<}C=pz0|EFN56b-@jgry6uW;YHCVK
z3AOXGG2#W4QX|YtKCz8*O;m6qaEJsA8>G`l*#RU0AhlZ*yswjNdP$h4d{_#9XTS8n
zpJ9rER%Hvtr>Jzb&mGT-4y!%ujXvzWCe*ZM$biEWQn1UX_W!2l<F@Gvn_XG9;Cei}
zK4|+w?ePxO%f>)+L{s%&ADV_oac?a%6kX|UdwA|PWT4Rr^h%YVgsqO!H#K08h?g+b
zB=3QgPc$a}WY8TBu2W_VRUi04aGeykTCn(s&tcC%Lt{1VXYP-ogZ7-50}+o4ODE_!
zPe;dwx;jQwSo3%Fk<UHZ#pcM!NLr2Bsp%Qz7?41OM2f~4Aw%T)(E9b8wU!HWL4cNu
z@gYr+NUEv0l8vS1+ns`6<=FY#!|6Z)^0kWb5|1dgjp7N!DKZ??^;U0>@o3!T<z*TV
zDw$DGNXl6?ro>O=E$B|opm@nHDDwT`K6q+*GW1@zV=EaM8F~4*$z$!soZ+<Wi6R+K
zyb1uZX}0-E8%!$USD?57!a|!Q*$D00Dr)Xqhe{uu&+|*_9WgCb(|#>sRfg&?YAR}Q
z`~WN3{ebQ~(${KSDWbY2ueHbdZ#)5Y?Pos+?S9@g{=Cm%uhT?U+&xFEZ;MMbu(p2k
z_kI`OFB8KEF?_%5ZP=%29rQBcB1qe3alJepUew6NWd5*h1&VJmLxoe~oRHSRK3iM!
zkc~Q)l$3ZsUjnJ-{@5JTCrRK!;VOO-r~_VA#re<>Pz9SF*INJO4|L}n^aSy{UG6vi
z!O)F#51Iy`FXfKT@G9}7CZLmNw%<A4F9g3<fsviHFfovuK7ae}cUwdlHqdXaQAcqA
zJAhUx`YimWIsey4OI$q+3YwRfH!CYk|6EGBUPJXJl8K7M1>^t>>R4i_8(i&McLXdw
zBtwOTu`%iCOfFERv$C|59_7Ni6ADu%!dW2}Epadby{C5~%7zHaOkuvS1TRJ&+;o8J
z*zyHtZtPs_LJ0z(FJAL;PSzkm@C^=l^~95Xs>_?=6m>g1oc3S7RD6uM=$n2>?^B)G
zH+VpJ#+D8n6@+tk_kHm`KXdD_k+FbHM$o-yjV^-W(Q2#haC7EyeaylG?as#8GNr&V
z(gHJ%HrUh|QSUcKT`GH3+CNvV<|Mm2r&kn-)!#2rf!nLhnj!o2^o^aJy}Z}{Ru3)p
z8{Jdn;@^h(hS1Q^W?h`;PR&m|cAL9m9ELc-qPUC(S5`j!z&tRHce>st1>z^wyY=2j
zK3BcGtgJ4_!;$xQJYp5frMB0n5ffVzXGR+8xA}PgZu8mP7L_-xsgu^$)<Mbm)D#V(
zcKj8MBdTX4<BEBS!i#8v*<ffS3Q9^8z&m{GsV5o;F17u4sH8)AEFr<Y3x+gnz%xGi
z@Ng!SEnl;r@XF9!g1MHu{1}j#_jv3FjUH+Nf;rmj5Znmw-M1(t)5ah8USxYqf`CP7
zAQFBs_J<a9weUsH#y~Rq63fSD?u}6M3^v`q(bR13Q{+uB2hrn3>GNLI*|KA#-nFtX
zP?5d$D#FQV$5}J$sT3K1<R<kg-uz@96```-pXUwQX3Fd{LWinVtPdBNxBdy86-b)b
zM29pRd{k&TV+=!rc9X>rOs~6IA4L`TLaxLSV)@H}bH$A)_w?cZ{>Kj)Su<t=$P^{;
zLNN~rCdP=`(7}Bvw#L%vg=PpA>BOLZAtK~tGU-*<+`}o%=wX}I4I9L8aG5DBx>Pl+
z-3EAF*9ZGIv+B2I!l1MDQmSPNVhE~y{U=K6Ow6?65HfPqNGUQ@7zm>~E(^JW_*2iF
zW2fVj6Ky)oq;Zo5%>`G>5sZZ2c#sV3<tcEs9@qP9a?!&^etGt0ZXB4TKPuBr`8YW#
zDJe&-S|STyw{}xZJF2RhnwnUN$w7Ez^02Qtl?EtYD~FA?yX<!ZKLGTYlTlvUj4WxB
zE#9lwJGr?X9UTr#5oo-ayRpgs*r^EzcRM?|wYAq#QE=gdcZEo@iSv}vDkl9#*IqgE
zS8jm$!_kq^5ukMNla@uQ`FjQVhG{|DXv5{ez(L!t-{#s<Gojv1W^I!4P)YlDA7#y2
z0&5keQt(0h0$QTQI-w+C0hs62V*(AeU_H)bNq2hKP{o7*MHbvI5?56|g5ri4gpPD`
z1`mMG%1&F2+LLw94&|)l6>meXR0xm#(9O?AF>s-vIEjsUohS_oL>}}lutS_UU|Qe~
z_svH0s<L)VH8>HNpKKXCvV7upBFlBA{6}Okb_d4u@i-P~heoNfevBzj*S5O0_JK=>
zQ3LjIF9o#JCrVXI`4D0C8FFT+xG{6y>cyQG<;ZARS(&fE?&H$Y6vCyj2UhF4jeHp^
zCs6Xu|83TUfsVekv}C};UbWm=7!_McC6G6JsHKV?O4Y*WIe-mv<kWG0f3IG4SZ1kB
zhI;40cjvKH9*Zqj#!=OhpKq{SloKg7aPb5cEKJufnT2Koh7`g9QPAA%Qj!DfGoxSU
z?&#=f;^N}w#(|E&z(6-OH5DR442g>6K+MO8j)}gqv}9sxo|2lnva)<~a#X8lL!bgS
zGc)re5u$)|l)4c$Qi4nx%sg^L;1W?%TpaSzLpe9Cvhv^Ko~o(~C3kmwdj;Sz4?8F3
z63kVKnp*6)Z@>V_)z!7bvx6e(PsQlf3&4K2m!F+GQdFq&De$Lpb~KR}v0fEb9hcjs
zCa`;*U?_2i6B84_sBQJFzUg$HGzAKp$M7hh#mmAwGbh*ccJCATS?aA$RH0O2u@x@T
z0$TZzR2$wv`QX`|rmRx3sAQart1G|HZ2;R+gf>w9nJ5<x7R6%Jt*)x7s;tze6#|d6
z5)fUA3b(E=HFG*-d4;{BpvafgGS-5m)S>0FAi=!2IKn#dz}68(&~rd0DM^%#__YKn
zA6*<7xTg7qi{lMzjq;}y*$;gHxm8=Gh}iOs`84a$h3Ffxm{GD6lPgoCq3T{|^3&^D
zeKV6SL+$SveHmQ4T4hk9@(B`loaFRU4Egkp*Fk@oMl>Vs(&pxN?64Ni>fzxMhBR+K
zyIjO>QEyyhrO4F~rq~2BSd+=Lk0EBPt)(SZclVdU@El{~BA}2R9sK}HO)QgGNp)m5
zAOzu44PymOGU}+s&7G2>*3!Zb^m1}?v8JZSc5U7nqswfzK0fbD6)Hufq~%9XWEUjb
zQbANU8{KdJITNO%(;cRlAu9$>_F|cWf}8?>!EV5(p1S(yAmInH=)C&h@yt?s28L{&
zr{$~7w*DJbs~@Pml~j_{R8+6)vwkb{^9@t8s_5j%FfsA*?t(#Iv9WP-^74Ou1jJJ@
z#MMo3$Y0vcpq6QKPwUdB@n$j5F;z8IfmpX$t1sy7B`5={+ML4>|MTb1+v{Pxxw)Aq
zL3eUx`JIRC4>HApX?U=o8b4n?;y<UZoE)1`P-7(|B_!;&yFG!S>GkzBkW-~&l@f7N
zy*gh8177sx-CgCT_esMQx?Kx_grefb1gPlT6^%NP^gr<7b{Fiy$R0=4N-VlIjW?T4
zp0uv4JR+`UO`oi^w%TsC$;HG2j~@oeqeuK;V%balqa;X0MMW1E7fnq~WkOUG5sP&R
zl99q2lMB63<43WuFn7N8f?s-Hc7Ve<08@$)*`%%2KurzOWCPx*KOQLs`b3|y#g5X8
z5QVZVbJTmIdN;-MA<EM>rcmNp5M>bH<KEz5(BLNd$|;6h0>V|$M%FTknL=Y@>QMMi
zEqwmKFU}|AR$ql{R`zyhMw92+k|A3Uj2R~Nz(-~{%BwRY!I>42A2T#Rkv{Vmz7{gm
zl->P(_pm8mUGI)$@1v6lYYHajRu7MfHH5&#&10D&E{>%IkD-8lJo%*o>SjnIoX9~V
z7I#>!US+{j(m3}02LH~Ou87Ks30oE2GXq{Hv3P%f|2wDMR<CQ-spBkN<?UV~DTDg}
zR0s*PL!yOb0=aZ5Dv>h*oSdAjn?Sq&)5P&cXD7W*>-AbgQERIkH-IAE#>(n^W4Wrq
zVoI@;Lp7Nz?9fvH8^Lb9kz6p(;kkM&sDE#}%e_y)*UQc=Y+{q*L*35L&)C>l&-RL@
zJ`D&xpibZAceRz#6fp!r0PA(GnT%L#yjV&<0&^-uj}G_r^t9dXc(`)4DH;qe5KoC4
zX{8t>aZo^o4Vljo`lBc=l0w>1Z#6tTd{lDudaKiQf8edO^aLCl(Pp=|r?}VzW3{C6
z{QdpCCW})tEbK0u*Du_W7kUQtu9l)WggD~-0RRj%0LvO>cKUtX{H!%&EL9hLHXCGK
zqkZKQQKL=R2$0+BTD<O8mF4A9{B|S>*todanb~B+bQ3ALh1p`6K9J(#I&Jo|(>gf9
z0GU|R^`Q44;4@)>Ldft9(q0VGH=2Ssn(l%^_ysmwKR-JoBcsESSjKxDyh)U8sYE?;
zOGkts;xT;C<+uH!NQ7>Fp7+HRMK~(PVbM^)Lr5SK_IY^X1TJ}ee0=NCp~K}I8}m6H
zx+4<pMl{Pkp*ddzbj(cU?x0}PpmeRBJ5<!9UrhKckkvT68cw{W9x`nBcnan7Oba3U
z!6<m<jYrYF?HgBwi@FknUQ`3;VA_Y}Gty|rMWEt8AQX{JwIt@j^eyc~(o9cE{NNec
z^~C*<{qP^!>Uk7O@E6Ufvz4W7@gHL;31&7nD~l7ul9b;|afnumtFaKcX`?z_cGtMb
z<42tVGgpiXex5HgIiVe%+@JuID?jifYVIFM{^DiA;1u^z7FJy7aG^m(#>P2Fyub<Y
zKAS7Z>2d>lC<eW)L(krPqQ273^A$O3HdKoJYS33A8U62s_}_7Ht*oteEFFI?tH!VL
zvhhLevqEGf`(=S>Ywi}7RW&`F&6A3Yi_^}^9A*6Z)3L547b-;+iWFFmo*|~9;_R%o
zK4}@Ks+N<R(d%?P@kgbstE<aLzpm7Z@2UYiIMHMc)83QLVSOJDq7)p3Q-KN@2IBp&
z=+L*P$3bs2&UT}D{K~EFaUoz5<W49F3tsZ`v1KKo4Iwj=Z`SzK_j9X5K@iZ~)kKSq
zV3`R=5PdjziDqS*A5WIzlIqx*t+uS@>Di$Gsg@vBT-F8*8$ec3%uHG9C8e(f!>~d&
zI{%)WoGdTLrg1c_Z_Ujq?yfQM@Q_dv(G}HD&~S;ctBM5f4ZV6$p?fJ+AUohE<IaQJ
z9d@Lc)Q>yzWhT=wGWuU!wE_PA{p;;DhMUhzg#WpqruN6@^>%B$$(o#~1WnEaiP%~0
zj28kck8ZVW4{JYxs=Xp^rAJ9uGZzV2w%S4hLJ7t{==KKtUEvU26bl6a`g_w_838Z%
zBXoJqRKFo`2Ba+}aZk+`!KuA6Q#0FmK!5-nmwGJsQ*<3Suqi{4ZJ!)o1Y*FciM;SC
zaub)v$`M5^p}CVDm1qBjHN_&AizaGF`tS~6ejL3X;f!TZZ3MP^+s@mvvBYv?ZEdZB
zQ6X30!`1)iPddzC${*ztC~{2H_1`h<+1d@Iq>8j%tSA*yi~o$n=8f{Quq~`^zKle2
zZf<U-t*ANj=#iI{xMleY=TRa}YF3mB6f?^bVW($j$4C^>KIu4-058UIGYjPY3Oo(n
zp@uP@Yn)e;ySVy)I6B9G%DO&^hg*|vb22ASwr$(CZDX=AxhC7TF*QxLIl12Ryw&&H
zz4x5G|7We=TKfVQ7k7Mi*1&3>1`il&5ND_RGEfhm#We!Q2yo<D*Djjbm)F+TWCG;L
zl8!Gf_`Gf>?~Z2T5fUi&K?fDZcD}UChUYm;pSzn}qS&T1MKQ9HH-$k#!(q=iH#b+^
zpZy>2uK<vyfl-*UnmGrS^b!Xi9q1T7m`Pj*0~{*B+53Ls;6o(hm%z*RHiCl0i?Ot5
zm%P`WoSYmVhYy%P`O>41L48X@rVwsCDnCh-{>Iuq@(i|ZTq5FgVqs(diV&rpYyhr#
zU>)yryE}Y4Cy2tYlV|n9hqdR#K!}fxee&%oDk?f!!4w<;9q5D;CEXlbX2;gi8kJuk
zPG=|dI{DhWuN*xj*M$7Qj^lyDhXKvxaWD254eks^te&=vi%3=0rrekmumr|t=|a6L
z?FSiA$ymn9j+B9`W$eDDv27Zg<uc-CkiZO~`7qJahAC~i9tm+uEwNX;mL5%13~el}
z)2f@6rkSz*=&k-&tf?Ls>g&PeHTw~tNxT!}Pm^hdd%&Sf8aUV|rwpz$b}B62^Rp=&
zb9!>nG?G4s!g1RJGg?gS!-0}-*o>PYc*zeUBq>Lr)bq)eAO_6w_<g`YxSs)U0R+dG
zHoS8!^V|{u`>*P<cE*!e{G`cIUv8}GdL;<DMWvs9EC@FY!yBI2Uo*L+zc5IF|M^Ma
zeQ;~5!|fZ~^fPwWxGgOM0|PA$mS|E}zpH0Zn_^lj+QRYi@$T-fw1WmOqny0#%<MEc
zCbc*@zMaCox)c5PZ+v`QT#-Uw=<Mtf5fDNLjKB<y0%UX=xRhxaX{>B*b-e?UC@g#5
z7X{uIuL3?h`-8y6l9Z&dh{)g?1oLNsiw(q{KjgEsEvDioN7>B2fe{K}MdJ9nQe*J;
zmM@>r&(~XL$o!LWbS#K@5`Lm<UPCGYHXv@V&5_IZY-M_u|9#)d!$TNi6B2Bt$biIF
z7}^hkUq`Q1vl`esf%#k^jHII$82o@s+lsbeDp?K&ZcIei$`HU`5D_0Zvh8x`K9M4d
zD=KI>nXuI{Ynf02p%LZh(=o(uUVZxw=MvvMUx*s2`{1GNp)O3s3%@uWlWerIC@1IU
z`fd01%Vl#4VaW(@o4y%VKLrH^%?iBQ0$ZHi13pBMbY|^WIj-ORTuV#79rBW;Mg34D
zico8U=|0e1YsM803HyiTF^!R!IpN=q_2)g4%^9g#vDn4WyxMTy0wf|jT#&jQ9Deud
zXhcRyTuUyr$wbTkg0?J}j2e3?xO&O#Yfl(1lrRRJjzND@z8$580Hy0*gE}W}e5Gn?
zDy_T_NJ?B|Y#M0}I_~k8eTRJb5S8cOqLPHrluMg4i>UhznHh&~lvE}L$Avsy_qgUw
zwaG}9UF|F_kJEeK4l0;>K>>kZx96)w=Twfr6)c4eiiuQ4NH-R(l1hz7&Vmbw4rNqW
zgZEzD{*=LaY<nFR;rKeQs;#ZAuD<eoZ6pgFJY5n_++$R($N7zKPwU>Y`5KP?PTwl)
z@WvAw8rqkC!=#KeHt~2*8+7&HNzB_8a6CtvZ3p$&KuzuF@Nh(YbRU%S?SsreLF!wC
z8KCY1+Fm-0x~Ud07k@m@2Ke6$gb9MtW`<*7WC_dByyB<cVKiam>5AzI5{M}p!9i}(
z4x8xZ<|>o*J8eXvQ#CX;rjJ%eC~V=76ryJCpv^0cM~NyZTwxpJoS&YHQnJ56N-8E&
z*qYj+P9GI4<rq0TyR5IT15i_*nRPz!la(dBY?&v^tb~PwR{&0DZ)PT@rG;xnSQA2e
zIuN|Dko=KH<m=dkTxg{h97h%Q0?15JH#aLQE7;(a)J6<REDCCL16x%3QADjhJs-#Q
zdm$kr<bxpv4pRO&3^M1cT=Mc1_8V<ZH@m~TyJ%HzY8g+eT_j#sC-jKn{XfrD!ncYv
zgu!7{<E++7I=Z$mf1}%OR_nh@D=ON`@&A_8vW(&zUW}>d`o6&Q?B@cRK=5UAeBEtI
zS-0IcQ`$4i>pFQGtd2i!rdazxTAxrZW>(?Z-T+4LMcL1FwSjB8B5-NcQh?{L#nO#q
zQ1k~p4fLdYS+QSPdx>%8BU}wdwRUj9U?`lYonMay!eE|cc2w8F_!ptSU|}CM7lQMa
z01r8J^svKJ5>7ut>?CCc95lH4FrPHP^?B)0*84Ki7?^^yFh#ao<{BX3MWbJX6DL#)
zXMAev5mPRx=!t@8h4U3FZnMV?-qZlf=x8Q)cA8f+&8_n<@SNw~Ngi*sXnG`q&w^LC
zqH5=F?`~*V(A+)UY|D)4&H#LlNs{|f1I$rjk&WqS3)|asQ&YB5QscKW3dt04aS2R}
zj3rZ0WP^erxyH3~U?q^bCpFdbzdxS;74UB3sO>MnXpWCUyx$ZV%~bPQNEN6=M4=Np
z1+Q;g^hc(ks$x?v4IP+)dSCxu5g;8Ukw>KW+2M!Bd>L0D%Z7!GEF_5YxAyja=^u<}
zwf`GEEEt{?3>)d1x)X@HA8Wf7O!DJL8aoGHgq85(k|RYCwKN)-crjKmoOpH!2@C+{
zK!t^!DN(S|3-lH=H(#v8W$zeLo1qV!NG4AKnuq-Clw|U~E({utkRfau)%KT?I2op#
zeI5Eq9s+<j^Z0jv?}>#?l0fA|Rui=Sl(FZ_e`S&Hw*uf`Zf7fMx`b{V;Ya;`qUTa$
zrmZ)F6>SJ;2`Q}XP6qU@tSbISu#IWUri8v*i(5aZ<Bc$xioK+7IDeyjk`{wg2Pt{R
z9dzp-Tw;Fi8+P?Bc0V#$ymGKm1!Vg6Nakn-wi`xI7o<1l7_6iQaxS@Sc|278US8bY
zh-JtVTnFJzWh%j<+-ud5E`(x`vm3qy88zcfev88g0(Yo-OjbB3GGBRIl~Nv|JO4C6
z*^Im5>(T0)HgyS6%_~KVME=ykry}dc%*@Y^5i71ZM#jV569WesLxn-D*+0gN2$z+X
z0{d5rN}0S6bcnuW(^)}FEa|MY+N2^X3KsV4oqN-n7#XUT6qqU|d_dvqm(|ZGXxvKj
zon@Q^DUDiPb8av>yWe#??SJAHPXGaBa(4308;fSIUa7T@Ji23bj}VtIE_84bNQu-&
z4DR&z2W6fBeY?TZ3m&Aua7@7@OOb=uGEXw|MiX>&bkZ`NPdbRAM1h6v@bHM`cPzA)
zsl=S?-vj5><&~cD)-tR0{iXeJCIx-2fX%DBBrNVyp~7Q_rl{@cq*`m*NhhR;#S>S!
z;DTcCUxp-tSw<iTL$*jM=vWm3v9!+4j?d@(fIaulv_X3LKZNBgR-t5~RjA!au|x@@
zoy2Yio$kv=H;GtCM6Cl+JW97>HR=fArhV<}1o1E7;SIO97SGWGJ7fF%p+(el#Xn)O
zf&z9)`O}mzJ>xk#{~B}rsw(14CZOFGLoI^>b;@(UT`z<0g%nBNJl&mzD$YR3-2N8$
z_76!$qR;wppN`<mbg#*10x}}vW|zN+l4=Oo-0z|531P(f6u`~!47Pg~Pe|>`qbLfr
zKYF5mf){RB4=2SOQ?crh<x!@N5^A8H<Z7{;*!1J&dE>f$7FZ9_&qEdD#AWABqys7R
z)qgFiEp<e29hi$LIQEuJ)bw{&)p}d@J!-!G@NkazwXCu`ke#%`PC8)_QMAjfVPzl{
z3n%iK3BYT2*Tx}kh%ljs1l@?}0lB?EKUlLJ-j%|B8Aw$A!YEtn!=bfMRdtoOLj{63
zd{~#;$yoW%-QGDk#tpKCd<Eh~^i8`la~V`T%P-`W{N)s4FKAT)<wevfDk_TE$x3<A
zM}m%EFtbEs^np5|NBDU7G6rBK@DYR9O!~ZDw=rv(T1#<)C+NZdc8?Q<Yj^H3#n`i_
zQ<v4)m)VCYf$98bR_XNgv{%>W^Ya>T-E_z33q^1+@+xh3mepa$8kuv8r|nOsGpcE5
zq^71G@F92Fa%2M=9~>Nfc!UI6a%d!k=QZ^lS@_*Nj-IsS;-U&XJbc(>OtTyGke!dW
z_ckkgT$n$z|0&lj8CwMkR=sTB)fw^e<Lmq6qfSho7#OOcMr;8kbq2af=yS)*3-EV@
zHUaLqanuPw3(t*5yhIApZlK3UO-vzM%iUsby-OZTSbz~(PESu?v*i#|Dl096{sIjs
z=)kL$mX$KALr|HR+J-9YF?Zx8mUOmW<<QbqiMHG$Qoz6vihqp?g%PhW_=L#M13<Ba
zh{3|besDQ8PkBl434(GXN(!w-Rg7pCh}oN*z+L>>^0qc0xj`cExfb#Q`4JQZE|tt2
zfy)?##v<Xph?6!xGfqRpsP(;mabd(s*ImA4^57q%w-!jC{}*EB2~|*7ZKXCZV+A#>
z_bIxeX!;%qsf5b0`^Q(?iVO#Bdzm#!1}qsLoj>!%qv2m7O23vVc1V{Y8gdKWB%0uA
zMF%__RFsyMBJ)2P{wzkaj9|Cc7N5`L^?IAZ$>h)S6ysz1@ebw(DT_Uih14aHq2=gh
zK0!zOa_n%##d!O0HFbAquIU%rkp%TQB#pq-Zf7e`bfnV+Rb(En@jG#({8+x?&{CH0
zGRo7O+z+`C$)CyRNXbR%Sy^Sg9C6YGZ`7EZE(?pH`@u$g;M-BR+sxyGLq=_Oi=w2W
z&<9-DE$`{)Z%n-;dU_Sj5oQ7bPVym&0-I1BW8pwI!;!d{>Xn9yr;y(1zaGIl?iNTM
z8LoY1*9a++Ck)1bVZ-4AIhIKAs1VKqJpe*QtgdfEO&IkddW?;aJH@-@wB+954Q`rE
zQcaB92pqi0=@M1?@$u0E0NVh3((gT3V6Mw7D4%A+z0cei7lkGBC;Z=F1oG9N*51<6
z5%Wf&k_4In*S}{En;mX<_Z2Ff4x0$ikk|f-y0)}g>Z^STw931G9D4rN8SQ<)>bg5u
zpSkn3veMGi^E(=36jOH%G{ASnf_d=7ns@=!NI($*UUhP<1w$({BLjy3FS&$E3@tfI
z9!;%)54ET8BpD;%?Rb7@NEF!LozaZ7(tLcpeNap@zhGDG>f(8Xv8f$E)dLTFZEa8O
z#F#O|mz&)#r;{px<o2|(=LjA3-2aSv-&CqqofenP(fzRUr_=pnU{F)sKtc&aD@~+O
z(ZS)0bIaf5@XW#7!oq1KY&KLqzwQ{6ElE+U*S)g7{<8BZ;L3mXR}v44^UJRgu9vyA
zAo6dRx!JW9D(L8oDk=nnaJ(Q8Zx;vHOekvkK=6R@)96kephO#94{U4@jNY)bH&0K`
zDp+G`MTr+Rm4s*6(3omHZ4r!OVq*gLeogBZ8mO=XPW*&QT*Ar>IRaxWW-d-&Emg3O
zI7&1&D3mHT#F$S#a@7AUDi(fNj<(CE4>|G02e1->u?d-&|Lt^1qh1pu91dZdS6S*%
zHSK6EEUaC{AaA|S$V5iwF1nU+%|%8|IQc?GUEDNzUws>0+z{bf7xXH^g8`PNlW9*e
zsx@gX?f+)*bha*%-iz?aXX?w(2cF11Z8}fDSlGdBv#KOvBH`Lb^>#s}Jj<6dbXys?
z0@|Jti^KFKJvkKHa#XnAX+9?>?%=pQ)YF<hDC{dy%gBTC17E#20HYDT>L$2_>b!bl
z^hfP=>F51sE<Yq>0#(Z#?@I)eI>hkxXWdfAtL49*R;_SYT|UB2m!Qo2on2U6tvNX?
zzF&PC^<~>}SDl=f+iBk#Q+cg6QU(J`&;5?yt~C}kElD;=`(QI=4~|I}9SP1EUS40B
z^g539G)3=tC<aNb_;Y<$*}A)`tGm13+c(6B5{^z&tN!NZqA3dp1!hTnr<{m&`~oTY
z3v+tMnTXf*I6~k}X|z;s<|y@w(A`JM=_ZXqM;;)adf)CG0Nu3$0n$Ik>J=N|UvI^D
zMGBQdOH&gY8yl~Wv3qBCLEW5nb9gX#xptAJjtCSCYv4@Xj-sWxHxFJMqs5<OGcRvz
zpw%afOu|tt@sPbKFy?P~DN8vz$8TVK%lSb^fP{>U=!J!?1huSaAd$+m{|yfA?hOAF
z@D>{%<-}~?EoO53?vGIw7f^G)<BgEXAn#2ry#)_&Zu;K668kN!uN!j+{0+iRTC;5#
z7#L{z*8-?20XKK~9{j#AL+j;P=^&`>OMyvw1-ZQMF6MWK(=|0UOt6J>SMzz8@Lk_Q
zOwn-Z8O|#(OGe2Ew0y&q!<~=k+|K)wA|fG+Cm3R+STPdCNr1aCna%_Z1a|9P6?Jvj
z?L7pkY)TQSs`QD<q}EhPhsZnyk&!H`&Fx`#3}uT4jy#6Jh!cWb)sjIKB&z_lIJyT5
zg2<}G>mpUy5TkB&v>c>*vgb((_sN*cR#jsg$~NYm)zHu&{_bAg+Ipm<!8tzXND5+M
z>-!#Is@uUsoX34<r?nOxHIyue7}6hQxHlJ%6nOT-7oIRjB2>inH@p`kSXU35hu7v`
zcFZ69z0bckbpDBnzYakDy{RyoG37{K){?Hgz-(UGg<COoc33A|YjgQnniaw3Z=90P
zR*HfhJ*6M~jWNUf9sB*z<6F0f$m`||_kB=zE#}5x$`uynXCFO^LiJ~v+^Q-K5kB#C
z&L_R^%{Tk%S*(PZtUkf^g=0oIxLL7=^Yc<ZFNxm##`ij!vcP#aiN(^f`74PCpFMQQ
z<ba^Y-*#%#@mW|ta*Z^c0Y4j!f7r%gR4ZddN>P#MJ!7r?1TPI{M3N}4%P$0rQ%#`O
z^gRfF{CIwTUNp$>3AoCmpClN13O6C?R=zEc)mKu|GT6Gd)h3^G4hZ<H(P`z?N3M98
zyX0#!MTsObRb-n!a3=KGixc>~6L0|db73AKl+enFO5(Te2=~stBOuZh@($T_4pz-u
zauihhC5TQ^&3>!P>)`eP(B~}X!2#i<rlz^F(%H#LDK$s|CY@=gBvO#(?D5ryNFXmi
z-=nv{?GYpS`ettw{_aj{t%vG|M;<k4W5=b=Jz&;eZuNcwGP_Hfhnt%inNm;)Z-}#1
z3SM&QHz+7EK)#vH<%kh4&dtsBxY~dvy;Tq97fXjh77R1~ReFY%{XUmO9&nQ$prxVF
zdjHIfkdmG9df9nJ6TSQ3DIp=QI5|`>NWS)~_FGiwTV3PbOzw982f>;|8>WQIC1>4q
zeS_miV?{#j0iEFR65jiQ=9gLu--`ua8_6Z&d1Y)C=H}Y${`?CIgUX)%D6--(L>_VJ
zX-f~YIr~ur!Q(4h9ksw$(+Eq3!Nqcp&+VYOJi^B2ehRClr77xv2K5a(E4m=CJj8@T
zuSrmH&*G9>jWK4p0m!C_L?ld2Px}D(G%isEZ?Q4Ie;ju_A~fXDY~G(Pv&q`r?;5Or
zl6xM?9)clQFa|*eq9yNwwPTuZkznbH5q)pu;G5fLn$JBWa7FEH1G>6N-46w{!-YEb
z^<U}yBL}AD+xm5{1OBl)JQzIju6v1GPs6~%D)kk;R@$g*B}EX69a5qDA?r%;J3D;0
zoM74sl%=LAfhRzq{wGL^T@^$Tb0Y`wa}F(;O@PqTa~i1ssky6MyF$G#pxwawrk&j|
z;^Ne)Q(@<R89){A`KRU9S_EHqYJ7HL+{0l5R#!a=B)D7sui25-*xPsgM10v<SS~}`
zT)%4PE$g~ek)B|@pTz(ST6#e$HnpV<up)AEpZ8M~dY{hk5(Pp@OkE3zR-gKe1_UZ=
z+c&hbTW!7U@yCJLqSND7Z?8cbnkpcSzLP{k%^<PIIdSPp#1lLNE^SNGA}js(@2@}z
zVL|l)Tj2BgdX9Nmv51Ac?VaFsx$pVeucy&s2C(IRzT*allfVGu_%Kk{I#>%jHwab5
z>{Vx0uR4ngW&6%~bmIx&PHFrsa*JL1S7T$6TxddW5Dj%OmeEa$N@U?C#)h70;m{G{
z;^NUUG3g(U1R_)TtSq1kIiurP#%N<JD=U5d%|;#AtQT#-de}KXC-~V=<cG|~(j@jR
ztMBfQ$NAH7u|QRAt^djUXs<m-_T$Bt059)bmB9z=G4g^vE(g8L7z{o3_3JO)9)K^}
z3=hX{v_<C(<D|(A%YnocjGJNb_mUhc$(~-B)@l7X7kFLk@q0aYe^u$n{iuRmi$N-<
z?xR0=d>&UGm<lZslB)!JO0CnR-~DFWb!G%|Dzmoy&gtuk_7?YN1@^iH#hmXI7VkX6
z(hwslAZgh8#~!mJ{2hkCA0m@AV9Nm5J0wITU9JGqpml$cOwfX!EL`8Q?5E%-c7A}8
zwz9ICTJzK&VV+KkJSr}AVYx_-det;g1KM0)9*cNz6>DTMio#Isfp`p=tbMXdF^rWr
zrLnvH#}4v2BL3UzY$&5&Ap$=}h`+uHw;ohIT`ng}HA*yX>+I{u>mYJ%+hgyU?O)>w
z24gYw%>Z_>6}C*U(Xl1niSERMPzTZ_7f#3Ls;9p(Z&Mj+@g}yoZdY^rYSrrPB~wig
zlKnxCx<Ip$gtT{d=vrW>w0s8cYQye#hzugvUutMrb8t$@8)SCoiM)nQ&J7P)(Y;@D
z&}qC;n0TDdcTBaAA_heUMamTX+-~>BGf%9R90XB}2EXj03a>+#SJeRc=vkvrDE%Zb
zSpqZH^>df#MUG^s$Tsvd>N?l7`P~e_F5jo*(=S@>kRR>u6L5RG+S^}p_C6zqMl=lz
z8$&nk?ackRoqfE2X?Am)%`=jBm)FzFT|9^s6~4C~;~Dh{%~Av&RDfr{_4PlwGP~_&
zT10^Pnt?;bBN6Hi=0F(wJ9tDT!!IjI&CS-fsjSQba8_l|$%lnTiagxi!v!^|y&98x
zJM?CN(C3kHvk{q(V_jzz9Ug2k({`$mGrw<TR&A<=TEOQkv74){t~p9vzOa(fJg`~=
z&v(GITS*%_LqG^>Et^v>uJ~)H2e21RZ`Y<u%-oxXjz7>(#0R$fHSJm${<OT`TL}E=
z^k9Nk;GaHrh~4YrGG26Jz=0bnQbLfYG=wrSjEwKfk}d7(;_dWH_3fu)jo%YZiPR!f
z3`yA5&HMdL68DYU4a2pOO)LnnfHY8Ea!jfM@h8KqT`Va&sIa!>@;Zqe_@p7<-xE7_
za=|%;>+5aV2-=<A*GJ;;0dy#L#teab4v<g+<>VLVs^&;n_f?MKoxZ@^eJeo|{@M>!
zO*>XHndiZznKG{b*K~%iWx3_$moILoTX;U+HyPGnuwVy<fHWZ2@KrWp<gm=#=PJyD
zXm;(hwx%V_qm4#{`KIZ(hx`z{DT=nx(DXX#>a^l`+F@<pUxuExK<En(H{2;{a+Jm`
zyc~YZ(YY6$&7!@G(le`3P*s^A1*a}#E#gZ#Y;bUcRP9GfKCkq`F$G?xaX%EctF4;S
z?u{oij_)pZzV4Bxj&gE|A~i<L@S(W{F|ViN!+P_kM1pXk;sW?K13IS7m;@M!;_SrC
zW~YOJh{#~$cXJA~|Dw{{+Xb;FiYLch{^2+ceRZ;0UTfJ@@&JWmBt}9>Ky)eKSkU_G
z>hxgpMiaqBY+g&8I(gfW1qX%~Sfu*;A!lEJ!Awg_Ysb0W+`@dUoQmQfMcc5=R}2JM
zIeGDc9m+Q>@xDi3OP-l38o=^4v)UHc*H=9$a&;*`E;#EK1S443$N{)pV+#c6kio&h
z9Yq{;F+5x6@IXx?CDcC6yc4F=j?2ea;*DMb9-gdNy<|g1in9W%E^1rgP8yBBpc{_5
z;Wg0E2msd1{vaVi9K5}so&-2CeJoRN8@d1<1YDH{8DL6w2F^l}mWf@5o<}7n+61E-
z>T2EZGv9%rxNg?;nN~oWbze0Of>@Cf4_uUC8`r_NHUU({74yby+1b@g>0baF`}PJA
zGfYNhiW9P8=s$0%*ZT%4xPyJh8t^KDkV5;EKU{OX9)q7vX9>aFalTk@w<+iiF!J9#
zyGc|8N1mVO0UtbeX>0_*&#GSzzhm1t()gK7{^HBW+<PO^^G`+vk1gWiAn8RBu~udo
zHXyv<!dy>Ox7Js0PfV=0Y-#K7RoTSozG`2#|6-WAgGGcibF5!Xi==`k9tJ-6*G|38
zcplCxGdXi=(jEIarN4%*>}b)k_t00m2zuNV{5@uHU*_3Z*VvsbtKf>VQma;5xIBm^
zH@%khm;3k@P4!3NOZ8NFP$~r2)l=h5N~Yd+x$;zx$CV@Se^S3gLJ|kuN~QhD-TzhS
z%MF4LX;BgbpE-}Zi4r8)e((fXMd5xD2$$QYfhfAmaU}$V7S8PH@9vkp&iBWSClIyS
z5C8r#PR%YNQse3yIhL2&V8yuYl}=}KI%uJ~fIb9M#+QEo_T1hMN-8W&+SxIE0N?Uj
zDBe{S!zDNdV$fCP<(}4Yz}Kv-tgNrZ!OIIOAE01OnaZjoz>XOf7momZpR@w>(2vD8
zT>}GR*>+N2!m!%J6)vZRr)ojM2#TtCO<UmG@U^W58ZGXPol61Eyr)MW^J^T6Z;EiX
z6WJ`hu$Gq>U>P)utN<|zIXO3Xw--NtXGt_clqRB5)``jS|29inQ60cr;K{wXz^|;T
zI<m0nKP!F}TI*Cy{jtNQMtFRdotNj&D0sN`(mo#`6Rzco!A<uaKtTU~Z@JPeZV0ce
z;Lm45i<;Ah34sM?LF1=siF6A8HB>k8bJ$jD2t81$k7xLYz+#{cqltX9JOzKM58jVQ
zkn9V=9?HQ4@cNyd#DBZ}bb@-A#H$uJ;a@g9c{iW8cYw6<<U|_#jG1h@@%2oK-<B!P
zhiNW~!y$-5E}R`z!VV9gk%=V@o1QWiYLq{Er8&$#KW4MN0KpX&{8u?Gih7@xlX*CM
zm~d352E?9UeQoyPy1AQosD^0<ggLc0&-R1Cv+}<wN+SJ(BdY33I2iN}L023%a|{VA
zmA|HI&V9`niN!s7jz{z&oOE&N(j-?3x4b_Wt&}`O=0a#Ta6$zj(-GVNXy62wkZ`y-
z@;+C7SHWryvEGi1G$<D49<zX+IuS7oMOE>agtL!y+^Fj6N)M3u2OO7K`{U@MshOF0
zg;<$nQOOajLcDx_bqXLGyVYW+BQ-wp6&KN^Bj>`-?ja6QWpS|qL*hu{X%7(=A>0V4
zE&-^HyaSpqKU}1w+~h7E&NxlA`gKH{!3#gXQf%Yr<mK7h+WIDK0ngL_)pD4MDq%RE
z0U4*%+nECO(y5p7w}!ShE)EW$3`dTM8k05}=;7sH=Y~aL1%Y#}FvNeqaQ6|TL{s%W
z<dgWhJ|A`C^uu<CFf$x!3BQg&M@{eV(oz%87{M+zt*x!~Indh%B_j34UK_ngZ;hY@
zWSu8Zmw(G7@`iL#HQiWp=w#_=BNOmyDtAESC1K-AbKLkup0YvP=73o$N=}DZHVCQ&
zxv?8!V}Ot*%%Cs04+f;f2bP%luDlJI!P>CmtTgVKO!oSV(_Kl<#mbCWGqts~|6Ocx
z^02Z-oT7+sCf$zjY~6eF0WOBUon8NWjf}2FgOkurDYQY*jslIAUgajsM>=W|3q&Sn
zDN3G(DgET1-1tMewA~5G$rT{1zXxReO(2cgg2e-FI%_j9<uWr9{fJKH5#^(AU^5zq
zkd@}x%#5j9xF*FR%xNa9@T5s#OXYVo*G}i8tETYXxjl$nnru0aFmaz^G|ZUa!}J+3
zuuZ(F(AM#?Xiiu}gopatlI<c368coNU@3z`>C<GZl3VAfQ&ZkEJ*lZl630;&&RGrz
zBoFf4mw(?zM|*5~S&YUL&JNd&HvousD|0VcEF^`=*CWGiVWY0n+Lnq6t7YMB2qp~d
z^rhw1t!|gq7%S`XmWY$C@wENNF97oc5!Bb{Rk*lQP5q^RP?8H`P))Srucpy;D`3L{
zfnrID+oC&!Fkv88I^v8ot_xpWE>}9ROQyGoeRvr71?x)O(LgGl6axVX5!t7E6FU_y
zq+d`&!-E<F+7+Q^07Dou*Qmk8<?IYU|Mje1)7ID5*l9jxN;HZQwxTbHtY~;)eO+7o
z#rY)V2yZf&!&S>FbJ-jo6r5o)_WN(0hM^V*S`@I8N+sWK_+&`yrBl$zPPZ%O^K)`~
z0B;;{1*#ICykDB)JkZL}Tu<4xQbnr5j<_1v$fD1NWizZj|EZVhIr2P2%)&Q&Ab_33
zbjjc9&=}FqU-k`Cms3nI0XndW76%j4Ro};Z0x=&?z&~AHJkFILNc)FF5wy{~zqbMa
zJPYXm06wa8WNu#kb}AoT)rf5=0$#FAQIi2nk>O6Am$7jTV|u2@b}0K*ei<*lHY=Cw
z(~6-%{I?CzFKT9qC?bT>x>8Nu)PeGVxQarj?zn>iQa%FVTQ|pfg5%1*r8r{_s_2QZ
zmfXvWh}?_sQ(^~QW~n^KHY`gMqY#!Dd*Z)dVWX;>v`&qS*e1tosZK?ATrsfE<7iPa
zISNdkfBb@frM;zkq4UgH&+rrd0m4j8y$ZPQ{{!g8WKI#16s#;PsMoKE#@-XD(x~-W
z<_+4wtu~?FX@Zw+?x&~cFU0?2?*_YKA=OC^SZ!vf0kAhMHI>h;MZK!Iqm+k<)4|Ao
zQxetkYYZJm9~%oV@A>1ai?egy-(F_PcYvd<m&9<fo4W>GW)GhH2FBS@=dB$6?zTYK
zXq5QeI+c1SDLgzp0(@eh+W4B<Gr)ZTDo~Vp?OhWj#cNblO_h|aPF!FJnUftIEt%2c
zDBQ$vMvDUKg43q0ZS3v!!;I6M!oQ|el(%tFaay>$r%jbEzO)(jE0zZo2;h0uGa_K&
z&ao3gDL^AYhIoNNjoz6Z9N>TFsFi}DT~6)@1Bs?i<b@we2$|_%toV4sXNU7ehfB&?
zu~V)gd7g&z+eE7AVH9FUka;6?mjr!7loXQW!PCjAByMHc^4y!APf`N2BnhbqHRXbM
zq(Y0|Xm=^A>Fx&bdaDzH^-U@iN`#FPd@OA^&+sp}v@;}JG=54>{fdi1g?nnLF!?^X
zMdQlKncbfk1Nk2gxdLyqnYj|h++oVe$NEQ_a!a`2Rxr-TzX+=OS8?OMsDCGE*~1Mo
zfl@;;@d}&zSA0qQ;Q$wKd*y=M>rho4z#t#PMa!COhym+#3|dFAV#G+^ABNF^u`!K?
z19uaN6#urI*g<W{iQ-Se`YFoFT26ynDibn@h5%bGLRjBW`tpt};QQG9I59byufsEF
z>b<wOx7`Xu13hycWsfmqzF`k&N)OJS8tKe2!^*0vvYw;!;d!<VB<F;O(fPTVnORv7
zXv<WH+PcG(?9J@v@L5@snd*JY46X&9*6!}=;v$_2nU$5~<m8Z$kkOSm8}{OITRX1o
z92^|2O>G<YyqKY=J*IYKl`$vd6+s_Cia5-13IJ6D2^nHiT<l4mR!)wS0VQaaU1eh}
zEiIiFW^A2xi2P(>VS%9~E+M-+N8OB-v1~mJkax{ZXx41el$4ZEP@Y}bk0Qy)U;>Cz
z$-w+y?>c!G@{X~MG>#NWgfHG;Z65Qpwx_nC!I`^Y(JY5^_mJ7J9vY6n8Hmy~9TknN
z4yvjFo;4ge%MNE~c*1xAhEbY<;1UT;@UU?|!dK6uG9Ox4ITmyiVRe047L&#`fC_iN
zo-4GCTt<0ku%B4?9`qP-GCm%I&3OOtP$-p*jmPj0_a_lgvv51#HP(Y@kJv%Fm-N4c
zEl6D|-?*8Wof>x?z3lcn-jyzH$4}|~7tZ>gFUHg`#U7>{>)UOd(dunK%Njc>nS)L1
zS={3O={dBy6Vxxaz#u(pi~m|ML@9xVS<MLTQhC3>58h4*)WnNcYB7aume@o-XQ7_R
zNS-fJB4Z_p?#*t<+}<%0*+RVg4t5kjZSP=Z^WAB82<RB8YZ#1~0iy1n^x>GNmPVTy
z>w)PS^O?yD3mqLii|f|>1fxJi$XL7xC+%<1fe>Ub7)<1Ur^FjuUa6=nD$W7(>hr>Z
zC!0Ks|G2DxmII!#SAJfeJO$cpDSN-+wbSh0a2S-F#NPWj4$;!3jEwZ@>1mC+3~+G`
zJ++b1{b(h)GYfj|+U)7!|23MO`_ObM0raGuon>d|%Z!K3b1Hi1t-6&>>Zz##p6<iB
zK6K7lk|Y`9juzW3EVN+cKsPXYfc4|ud@0WON)s4VN}{QzWQrplL<y_ItpIMt_B%5#
zGhWImHnoIk0n8~SQ(*g6%ej+6h%S?$fChiY5SSs$di-fxUNLbeo#i7Ijax#0l7PSA
zEh;}<7Cxz{0lfjqiF2ASJXdKzgy!gB<R@1q{8w6m<Af1bg_bXQF08z>koTxS{x!-O
z`NUFb=k~x()H3Hx)4<^BASPY$5fWV_g%{-^;X#x4-*tb;-O+4%YHGKnV8o?Tn}%>_
z56B^A*m};F+>a9`FR|1e8V|JhN4W&rAith~sm+DJ?hk_+;{3`*k4(NqZ2;X&Z1%2_
z>g<pn8D^?lA{kv)(vq7xdz7-$&$bi6e;=(mc7J5oyqF&zUJwVqfLso_NX$iN`U~)6
zj+~UQIZIv=LMx6R$1?bE%?DKm1(_|Ebe#wUNmWdXQhJa@JCFhh!-OlxZ5e-6|8BNf
zoi`a>|MLe3c%}FCT4!O!iO#{9x(zFSP<TP?dzFh?wSLd*+^HRKP*YP|Bm5@`QmQI!
z91(QVb?Ga^h#55#YhhMct+3_Lk+ZXtx3_0Tp|GM=T`^h-V~srnLS@FjWCTb8*@Qr}
z#GU_qsK}sXJksdudVD48KWYrFb6Q=)z+(@(KmY+v)U*yBXf_10hvVbpfLc+;!>Jf_
z?nN&}Vv%Y}PPy3XXbc4f1sLtKVkTerhlYkquwmyC7u*`sMaBXgA1^g}-%=+JL}?E!
z9ofwi#347TD=R&jVK^lATa`OLwjqUg=9mR}=3$jLDZ2V`CzjxR$6V0V-@a#n6Fg$x
zWXra%-TbCA&{WjaQ|V>{89tAYGT>)VW5I#yYIUR=)7xYdhogqg%`Jp?6#e@bwa2YE
z)zk))$}6pSpBNe-;`*od>!pYuauiTJ`%PJsu7v!Pt4S0UQMBPF|3rg?ENyLhftzuA
zd;9ko3|52?10Dp-fXCF{jc%`dcX2T}C+B0k0@aDRC9O=^BtmoZ5Bsk-IwgWImKL&L
z;Z+DYKe7*}U7JU4yS8WC?AGlV86WpkLwlbj{Hlpt{BHd~bu1-mn&L)W6$MN0J6neY
zzO$;D6TLjKueVA5;^b&$-z%oW?lW(mZm@#9aF4@9+=)#X(4J`i4k~ZID1<T<tRUV0
z#=|u?ui?<K(pm!^S069`v>FYD@9rAkO|lW1YUKgFi23;uTB>+bJF+od4H+}>bu%@~
zKwHtY`O)*ze!{-4AWmpT@UF72zda*b6mLv^_`}+qriu#W0T)mru#hUhuE*aS;OIDa
z_JD<fQIgkKRN3wK-+Sk=<#aU<;rQLy=mOCDKuHZfmW+&zjlYmT1s=Ppj*<YjKi=GF
zN=kQk_r=9UDTXz)+@krBITh8{v28G`-uWnHJ#^9fx;kcHv}=!Y5SEUOi({atFTF-V
z>y6;U_D3}AJKNMNNr}fCCQTl>L6px;E@YyNEfc?`W79=g#9(U_9zqaxitRC?C#OQI
z*QAGSl4LiL7|azA=|c5kYRaKkkC{Bshi#ox9=Y>XcW+rd5KZKE_ENZJF3?m-rp%wk
z7BkVG;>j+xs)V);q}k2osw3sb*6-nkpFM5Q2TMro(}KND4F3sQ6tqE^?8eHTZt<DT
zi^$FG&CN?I0pVdv`onE{v8mw`5p{U(7&9~+aUxwKt6;gmP%2X|JW%2E-E6RYe4Atq
zh90b=l_ekt%kM|Ke?jaXt0WsOl`t{s)*g#^akX4F93x>|WiC(=gzykkDk7Cj<rebo
zUY;pK;1YLg%lpwb^h3nT?&7PCrfHJN3Q=WkxV}3^*FZT3t>#Zdrexz3inAhz*2)TN
z2uI4IwI8XeDcRY7HXv3uHgq*K0KP?{>WGO&ED0OykPkjaa8(XiWB2C+pEDT_n;k?z
z?e^!5p-`wVMXsEo=#itld+6x?y`NgZNghxI+D@>E4C8pp^H2#AWo>gv1;JE#fUQwe
zQ6VLUMS&Le(ev?~$&EL?pv4&;tG28<IGZh73Xr7>4Y%|2EY<R3;4gto`mTD&pm)Gk
z1$ZAoh8y7vA~SN>+TA6)tj8%pfNPr9v$yc`6EQN{ad99o$*9M{Dj;?G{<jgK4e0|u
z@nWLwB5g@w7*T6rQr_u~LhYM2f+-IJ)ShJ39vdSW3Kzlj(B2JY9yz^t=r>BGF9TR8
zW|H@r&<d05aYxT@UA!LZSm2&XQ%K)@cj*KlB_M^cw9*WMwxoB8j2y=U?c<<R*>hU{
z8ntTX_aZpCtP5stv$2LbPW_Hg^Fh{1W1yw?e$4eCb`$uo9Ta940i(vI?z2voi=e~%
z!rDc~1^Blc!H8KG6RYLXIdF@jLUUP?kz`(Ke)Pa~<A5y&e<iL#@A6+{XW-!2Zok&L
z9yr>VGjTzPf=`Uaz=B_3902J^62_TL=Y`FU1`rdTPw_tqt+a$34*YByH~1Tt_z^Nv
zPn*nI$o8*EKc9m<7i_<FY>0g=2}V6)&ryfKj16Uymvm9gdg}NQ#UalS4QQWiaA_cP
zj~KSDsHyqeR$p9QT@4h>QBg@?3}Z(9u*o6<^2P`luT2TU`NR(fWXKY-F}xt-)uQP;
zidZi0(s1-*NeVI}ikEMPt~@{;%FKQqFj5Y5+n#R1QkB-8r7*w!e~D4;1@h->tAF4P
z1wiS2IYN=S=`1?c%@1w|shEl#J8ieO(LiuKd$pD>Qd>tR>Cgywdj^*f7pMdU45CA?
z&AxcRRe$mI?~+1|q6@AI`82mM(@<CE%ALXH$IB|h4g7MNc5E&TRXPu1t>NEe_;XB`
z@)up7RJTIHfK4+p(L%T>rz9mCqPF0-I?}GQs;%xWcQUk!vks+h(37ZoiC#UyH`2jE
zk%=EbIQ1F_xA0sT$?Y%V4_=J9(-KIVd%4mFUvUdLa~UToDS7!zv{<dC36la-WuQl;
zmO^jGtEZ;s0^n7M2#%2hJyDSF4Ue5n)M0e>GjNFiQ)GR7Uc(Xb^QJ%ITBrL0j7;n2
ztI1CMrE?Q`#8-}&`l~{=XX%!@43HNehIXqzFU4jxdR4#w(ivb80`GyR|0aGzx7`Hu
zgzb`N-63TGn(cCZxEJ0UynZKdALVy$zS_Q+S<Uv@5r<pXQ)P7)$|`7D$ggdb;a8V7
zFjrJJ<`HVDUtV3k`dz;mh4Cfu5;bbWuoO0BZRieSM7oeH7DyHs0IY_9z?OA$(FDFF
zCl1%XS|}8Sy=Z`JX3mfti5y#$*4moQqYjR~nMgRS9qKf<F@{9ZgaXo$fPf;<F90BY
z_USg}&dCdjyE~Q}GQn`lTo`$ISwI>b$QO9VS!HqXvhi{;N0wxwekq6Jy??5{y}Prv
zv2NI~e;e$hn_p2^Rp#a9kI#<!&9sXxvRJ6V!OZo0eI<PUUq|ii)Re5Otfl2IDmF+_
zH&9Y)hODJ)sS#{t5(V?jF}D&ItCaYTRU-OVSLh!??BhLw`6P&OG>?k67lTdsC3u!i
zb2m;>wutFbijYjc8x+e0;M}sUiP5CBKa^B;Ul5uR3P<`N^S)xL$b9ifol=w^OQxu4
zJyTY5Gxzq!n|?;S3MnEkjtwNvAb|r!l(n_lD>(e$LOc)hF2>|2g8>GGYZw3aMibol
zJ+H^h@*4`|CBG!Wz<v2BskGM6I0EJ`KwHg^iIP~Lb@jw(-7FuX&YSgyQ;;ObDRD<$
zAgU{2M{<VP=m<CvKl;98Ike?Ac{eQ}!`Z{ZB(H@LwkS5|xg>a;91H)moDqe9xdW7|
zrWxKy3A(#CeY^i<?tKM~?922x_xkU2WEEx(tOu4d=#r-F8{9yGvuA=dc=^vgK{hc?
z4rt{^7G)2tbq+$p><^94e_KFmNag8!)}SCE;dx5hn!a}2;($d2N585gH*S^ipYTZe
z5UoZh0t*(MsjuHCcZPhJ!{m$7z!s2oXcg(0n0`6f9-nx{;yIK{+XdpHJW6q)`QJaW
zsCy5ou=X3)RaGsXfzN+o+ZN~9R4mzlT3A>Je}RS^?Z5K{?ghIGJM_K1IV!L^1cnrn
z`<~G~Ts%CuaA6$QGHPiB2ZaCw0qdo`eLOS9P?ltt%qg+q;r8d*oxsuXivD@EvW6<4
zv#2^km=b!t_4*Pq1z8+R;SKFWmIp@k<kE7F?qOP7rwlx@aLhuiUc08P{i%o<rowF(
zCa(>JRc%-(w%b}M4;z;W#ykf0jv%E2gVttn*cjEqbuMf;42WyR%ViHe{D>c_rbai}
zdjiG&NZm#UOB1)g_?j|4HkSXAs5+syuXoHSG=Pa<tcO_L+f;J@Mc_s0v#+nX)?R;G
zsRsWcp5_n9XuW>I(ZWxeKS0lRm)D&N4fdr~q83hv3+1aP&c_2N4+V0|P0R!%4OL4I
ztkU_by<;8ouR%5%qFfy9wkNS|pndq7Tt|4MzXYkB1jf#$y3~=xaNrECO@m;XRNF7(
zukfePCqy@_j;xY*XYpcject!A(SXG6i^L3-z~xed8@K+Nv|S$1SX*ycKC1a%Kya0S
zoue@1vNVJ!&kgK7AIeU2QAVx$KURh)iV;kTE@)IyRC3ii0}1V<f{v6laxx5pH9t$t
z;ABuiCMLoky<HJFcz8NGI#h2=O|-dvm@h0uNvsgdtIzFTyu)EtrTY1;o%k8_v8TAn
zL!qDCdbQyrBMrAy;!!{=22hM!tJ_0>0D^K=FM*Bbc=qJwV4f3T;ZTo$GbX_S&Nqew
zL3mpA4N=$Vks;!?)Rot@x8sgc8Q5lQVs-m$psVN{mm1ZxwCSsw4ZoY7Gf`*r+5ad)
z<-Z3--I17CBeb$aqNVtUEhQk3;71#Rz~}6lyy81%8UqQ*r#XiXrCnh%*mTnV{GFTg
z1Y+Bw!Vqj|@#M^H;a$~^8_!|SQBgOdWH-uqTg^ZZ@VupLl90j|h3IW;I5%KYLSMkx
zw_#w?o`*>fDod;XX)g8z-*(V#j1DrIJe<Djd7S|QnG_gBB}tKv!+k6#Q+pB#3i<qc
zK*iCz*jI<JAQZM_Yi)%=*QDA0{$g@46>{%o(R<aV)w!(&H#u=<t;b&=M&C3~$Klh*
zY}f4}kt3#p<chB@vb=Qp6}A{!a>SlPUm)88${MR}>nD(?(4#bsQRiqa6oI21gY!^?
z!B0lkhNF@suR?(SbOOYSV7eGT2$O%bj3`Yiiax0`1|;h~Bc{~yWhY!1Dk26^B_NT8
z2dR6{v`EL*<-Fha<p_yFj|G*djov#|-w*^Nhj-fwM1$ZdG{0QRh(~0eP=1k=D*}qu
zE4qq|y`AAgG{@RaJSo?GA^ZETuO+E*8rE!KwJuLiaEXXWi>0aE`UBC^%>HU={Z|ap
z-d-UgDxGTA?)4lbh|>H6MuXhnHJV-lnBZgMU2RWMKt@hRMuvu9Uvrh-5`Il>51DB(
zQgQz3>hg^uBW;KDd`{6D6nsQgFk#KsWo#Wb{)$WJ#WQpkQ*>N6_$m7pePaIRiDnWq
zjtIG<y)uj7PB;OVh#ERB@h_ZT`jM)djg{4KO+Pjt6bwIG+)g2q;HG0ye^?m{vtGdZ
zrYYd|>gh3L$liG7pkK=}j@+UIdk%zEpB5T&VFBF=W;I)6x3BL&r@~E}D2GdQ5ryE_
zH;p_%P_3+~s9&>X%K1U2fa-yu%o7Ld$}92IIl<MgSpi@X06g$}onBQ$Rsi?d;kF=Q
zfCu$(zq<jGfR01AnXD_yns?5hl)B^`Z2L^%&h$A1J{AvzW(alcITnm1m!K0eH1J-$
z5L6P%oySn0t5>GnANIMZ=A(qp!DtbI)Qz<<JijJ6Qk2#0fOBk?>vc|h2yuxQ-9%TS
zoat&h#@(*{to(W0?{w}qnn<J&NJtE?_FNm;`(cYi>cc+S?vCS4uCmv@$7|A^LUrz?
zE-)7{lG~XkX<JPA$y-c_9lm+#%81P~R}ds4!kA04K)+-1F!<7Mj}>IyOCdypdzyk_
z62d{H+b=O~eU~0Pwxl4;6nFH0B1L*~u;uuJR*h0b&B4yGys|PSE1v{|CXy*hgYfS`
zlZ}Uu4-+l|?mpO%`DyzjWW3&qP2&l~lt2;~ZK9^O+?XQ{<O6`bB02f?#kGiZ!`!JX
zH3ktL!L7IN*Az1V5p^;mQmajF(%~{$aGf@<S5y7L#K2|MM-O;!Jk%n;(N)7~=;&T|
z68x9u<_zB)(G(&q^%>NwaJd<HZDMUExj>RTi^X?dCA`@~mBt?qB7BBc95ljZf=4^B
zi70zw{Y<6YV~1Qb){RB@V-Q`7B#@;F=($MgU}nvQz||i-5PYxb#%q#6Tiw|Sl&mGX
zqDu(TxIv2U4ILdF?V-LN`6E%9O8?YQuv<}r4#j4<>zM*5s!ji+3xN6G2@>j9aI(wn
zfuaA#_s#EcD)ZmJe}G+bYXkBV%C_InVtIhC;6Z1MUE(3VV5o{Dl(N7b4-6_{fz%vu
zl~Wt&|NRtrwa%GjQ}(<=WJ5797(Y<_hCJV1*JaEh_1r!%Lf8(RK(^VIZI(G)n;lCq
z*l<TbH~>~f$LX`m!t#CVPZzi6rOL^T9Lq7PYMO<he~b~E{;F+Z-G&z(7dOsDN2cGg
z-{WC-Y1ghsnF+A0Bx44kg$v<PTHO(2WCWck#~LA`DWk`}(RuaE;?3RxSsn9M{3i`o
zOff97-8VT3Uw-1RA5tp0bDo9cr$dbJt*cP-W8*XaN(Ipj-@kVPeGLENbR5+|b{1g8
zMt94qX3*Y8-!L&#zb!5%5b-IS;-cWvz{sVAMYRIrA|MZ0Od12&AwGv~oA-e=Js$aY
z<q2CWHnfwgtNg6I22F;)dbvPN3dMQBojY`A*R(YQ9Ub|(x(qI@OY%k741~%Ph#-BB
zmX7Z6YOB{eudGRH;nOIGoqHOiHRJGij93<7DrPEpK%i}eBEyiJP;~n~mzvV(DAm`m
zU)MRBsG@`ytQ+VR<m3RIp#TEPFHFfQJJ3mSe8HCW;NXZmX9n9X3>F_P*PYS~n^h`;
zF(KKmdIlu)8}PLOJ@&}loV<`(y^;-w&5_tZWBCuzG~4anTwRUusu69@&U4j7>cCuF
z3ZzEzQS{=1I4FLiBa+_dxdxn>bd-vU%qMMz{R;T@iu`GJ|M*#aa-(NMF=azg95d$-
z@@)qrDdEVRCcC90;4MG>efg6TAP`I6$fz4CXs=OO>z;1*hNj(JjI?&L1*o4nKbtQG
zd(-eaC<wIRC>~&AclU5+ifH49asRDb&CY&yt{J=sytU3!VOcz2PoI{(W=RQP*ezq=
z<s81gEs;RW-^6-kvibyldj7;?ToP5Hr>3W;rbZDZ&9uT}Lv0#^9TKp)bTB$5)ZeqT
z!~3zur796&jw6o&<VMf`{Z#D%0;hjCZ5`Y7@D4pWND`a=m6xABJv{;Y1{)qA>H@!H
zGHBe`toDOWfcU3~JT>k24@JGo4uH504$L~BZ34p!x#D)%^s;kua0m!80t1l6i%~aT
zq?K$W5>ofz;bVX@i1f?0g3zc4T(#h-pM77o_YGamjr@&FJt>GJFywwQ%}FtcZXfF0
z=BR{p-%mU2AOn3wmbTXW+$d)9J3k9Tua9SJs(X&LfO<UyP+xaV#Pi$7%#3`31q)?i
z-(8038}Swq@VqG^VzQYse55)!G}Kfrc}WhHS5^S4awwv1Du|h%?eR30B&X8?^A+8X
zcs!A-G{qEWq_OR3`DBrgk8k8E$qM0?ejeVcPXux54BZ#k^jrXwCsIgbM5ar>bUf;5
z!?gTP{P?gnDq=PC8P-O42gQtT8ip<Gz*Hkmf7$Y{6PwK+QcG!WT`6kp1ujt#aocF3
zYWz+OhsGI}jFD8GmCNxd=WU41=~NrFRJm!Xb;krtEG4Q&II+x~N(|p4S!aB^2SM{{
zGthrl-_|pvSO|J-aFR;fG>n7F&jM;`D|W+0S5>}P9G6hx2?rqh%b<kj<mAu`o;3&-
z1(J(9uXC9M`m*6gfgr%;Lh6s32^blN2X_+tNkzTaJ<H0JuYyV1P#uOB%Jcx`Mp2cE
zlQY7w)l_+cy1Wqq9|2SkX9k?EGJE#3f<dg8CDsyca$*v=&-2byJ@bA6xV?iVFar+o
z;UA7;b!;8s6XRn;)%W%iyDE%Pq4#TbeT%}XZ>nwrOdl(5WF-us5+Ro{eRYp=@qnh1
zv+XK3aW{yBH~6aWi5y8_F0%woG37N+s3?`+g(nx#wbip3(BQ~3J>M|q&`O)lu_TKI
zb90eLM@Me&^dmQQn=7bsyqEqG#*HWvIPelgnqR9D_*(*R1DF7qG&I=>1ahUw8NSD|
zY5iG?F8aN&@ix<WC99x-h=`EHEfCyFva25$1t42M{SqK_AVrWvDadXb^JI%#B;@nb
zgfKx~nUrY93cF}g=>vTE&62dq=}NH`?3Qr(W6#wK=fZ`{#!#YG^iAl$cr&*oBkoic
zboCfr-T$$4&hc@*U)PS^sBvR7wr$(CZQHih#x@(<w%yon{GRXgd;8aXnn~u&IWzaZ
z&)#cY%XGVm-+Csy=G%tsny0)UmqEfTNiySRz~D>~4;0dHihfeZ7oN7Pbe<;=(Y<op
z{Z`-}myT|n{FhY~0V;L+N8;F?#<lQsU~BG=XN{-{PUZ2>&;kF=?_uj7>rQA8^D8cC
z=0r;ZC$c=Nl8`*}hAL_^0Vqi_yquMP5N}V%15PobDIy@;3}t#ySHUt*0DTD#KE9nT
z+2!j}W{Kr5(V5j%4N_c5HeW~W^rrb;(0d;1dX2Oz`8pbHJvB9L?dP($#FC0JD)h0U
zU2~)Q(b*dXV4NbLug`+Y+72UPFTP^Srmd^1>*#nJ&Gu(=vorPwHvn6`y7&0zZa0{E
z`)6@yhafTp69WTH6m+mLe>>9QG6r#-0?@<*ONBJQPV$(Fs%oyj!tVV)i_2(a3IiMP
zVIvWex#F=-{Zwr3AA#$}QIg<jJ@||*Q)bq-wzO1KI4}?3R`E~zW915iJvHaRloBWp
z_P|)WaQdzhBT@tir}&2Sts+lnJh305yxiD;x<DUgC@E>ap`jF;MmZJ}LJ(QfNsgQ&
z2DZaxOCWrp9-t;))m*)-wJ9)|fbhnU{xZ#wpm2GbTmx8B*E_99Ul_T~0$;;Uc`AbF
zOG3%obh-sF^U>oHa6Tv?IK8TW&OR|lg+xeTd&u{4l}QYJ3L#53a`dUpj!zqKbFm(P
z&|9Y$YS*R>w7clpfIi${5ZE~lIackIez2N067vy7^$|U5NwQ}e0Swu`JPtufHQj(O
zuojBLf?0pj<m!sK6m=VG3#6?!!Y$5ptdk>fKS6Ny5I>>stYObIq&2xuaXfJLyeZAs
zc;d?8C)1`btb5NtF-lSc)T6~&Ir}ncbG9t$C>sA_3Y)de%l=kMpHIn{Hv!rtE}3&x
z#fwmXmq=$lxQbqUo~G1|fIH+X2bhAgQK_?cYbs`iUZ7Oxr0m}||D#n^1u~XO1NmhO
zEI_Dm1<Exw!(2NWot&KXaA-QVG+9}f+`@TJo`s9U`dO5l<Apv2+|_{y5o83%QX|$x
zf5(n3;BG>C6a~n#S#DVd2yy{4;i8$}zD5~ri0QU^yzL$G_|aep`vp4t9W#SsYW_5C
z0`V^NwsyBX0K3w<buD=d(T5>wBA}RzdVpjASU>>3$fPyvdtL+_G9H?Cc+K*6p!e@7
z>M3eEL<ohG*CDiMc47mor|9?l`fRC^+wEfYkE1b;v7oA|xVX6ePWvJ7Io*T7>lW57
zX=*!mYdbqThlBr}H{vr6B5n)?M<L8GnCD*fJF>f_C5U0fQ8ZK(pk<$&Uv{}4Bc{B<
zj!8+aj@BI%7XJ2ocT`nH=Of*&kie20ilMl{riLt8hGiU|^nf76KtEwr+w@XAm^)b&
zIGM}+C*W?>DUbAW^T3>*YHxYs&~lwH@VVP;zX-h|d(T|;GjW|f_aFh1Z*LkSi;deI
z&(UVxoVJ!Mw9h>D5KE76R&qU?jcJG6KM6g@PJP48TGF-1@jC_OPDhmt0^A%$P|<*<
zbCq4%!TY}iz(NxCMy&n3q0MIPL_B{_$T&OZVV)TRamgaMXp5NNzE*Ep3*;6`I}Sym
zC(l_Opa{Y`s!1~aV+m#&HS)jn!=jI8G#}`6GS*z)b5L37{rm31l0|%P%i=(k2GGZB
zY$gvL!DKhBXfdJznw%F;v`HzmSeS(&b^+TjdP>@AKq*OyKWS9Y!VW&AH47cAJoZU6
zB-X&i%*_0~&BxTtOiRrKrV0iOH!Ytqs+hu9JE$ecbZtE=Yk4_sBpx4yRRYI*_Yn&L
zB1q7p7?}!8*ac^ZNTR5|sHy3pSOPB1)RrxK3v^E%4ziQTFsM$hf{BNRhmUW2e*W%N
zI<!0$ESTUT^15UPXjg8mZ`g1D!HyOIHMea_uNx^qH&RvY=xC?Y>jWlX2SN}mmi2(V
zYPT=ACOj7g&P3%6c0NVvhcJYej>_ita@ym5D%hpWFZN7XhTE`NY?u+thu>vLawEP?
z0b*_&fx*x}$$yrVmj3RQ{!WUKkg^SQjDR2_*(q5l06(fO+YZS>Cz6##`5ux%j7Co%
zXKD&}1t~Bnm0N=o{d%qY<nu`VaqHW6&N%cQ1BVX9!DFA~jqhcjyHt$D%xf7b#!0#&
z4E>KK)KoP)x!SVXp8xN<+p69QkX4_aGyz6skhmvHGtkIog-9E@VeZ+NqEGXuffn60
zfB7=sy7c>VZN||tq^Rf^{=f;(jD^r_soS=M3?gZbZ!slR2LnA6cup4K88>0pU`4R+
zXU)dkRIAg@dw!uSbt^F#;$m_z7wg&O0<)OveADxHNi*{Vtb}K%YiE<go)Wo^DKlz%
z$li^~MKn&$2Bh6z%qk|Ts+R;OzcVt*0G^|6G(gZWVBlb4LNFR}=|u7T(XSJD9kpgd
zNlQ63?H8wYs|;1pZh8nvM+Rp7`{Nj39Y;_KW{&UQd@>j(ENG3N4_vr_ytnajsdTvu
zV8PMe(3<(h$<4|cO8z0C5-BQZVB3GHY=}d}5$s0Ph+Wi~Rwm3>eWRr7dVVB}pkI_t
zEGg<(&aivW>-X+)z1?M58&JKN1QrfeNOrnV<Y@9`>CCCC&1TQ3{AerxOwv$L)*zq6
zLg2e~{rKzUX+t)fEik~9YkfEhOmHCf2RlGUFl53FR$!SYEk(iKL}(mZ2X+(y1l7ef
z=-5+Gz-MZee{W8<kW+fgu>xlP3_)2Da2eY>IGmi<b^|SSicBFMN~lD(iPz3;z|E5}
z^-~Zn3AMnZA}gjTnaa%SG=6s%TUPXqPXOIzSAFC?gt|sMaG~9K?EdzvY^Td6GQ?9P
zB`RMH=3mk*Z)1f$z6X+Gqz1{s0|;!oEJjz;`eyx1^L<94Yh{LdL{484dBCa?BOW4N
zwJ&E{2(xz8p{oL0l^p`BO@!_n+x7-!NEcXdYs79%+4#?ys+K<>(>mbqM2m8aTkw^q
zfOSInY*xU?(T;D|)bHjx=W;`hqerIwBw{TqPjZ<=M`pel=O9$9N$Q3jE9L=525qQd
ze}6tHDe%(|8}3=fnp_k#a4rK77Xk7D;M~!nNC4TcH1cwC56_R`{f6x`iRYri(WIRd
zQxn#9mU?CxI)IpEant8{dP{;MMncZfZ~&Q${2XcZ5@s_Y&dW*1P*Ks^`g}g?P@t7Q
z3Xrc97n6;a8?Rf~nC$$;LL|lbhA7p(cG7<3)Ny`(o=)<6w4rL^u!5qtZsVff0&S*W
zna+=A7F_A!R^tM&(vi#MSXf#b>Lp|UV9D2G7=&l=PfIMV6&9j^5ps6E2Q0Dx$+8HG
zVz?MgC@I<AqVfFt`YV0s6Obs@*4I16f_#$&{~QBU^xHk|Na=rm6Q&r9kq8-U>j)|u
z0!0Sc7|pkWR3`mMK)stu7L|W}Sn;A3Rjev6=XLsfGrMcBG9brdA9qJCbQ0oaU9r5e
z0njl9_Ub?*SWiAEY2igNm87xfg9ubyF<8zMcDq`P6vAr4y$NXEudW}s)2sI=aLm;e
zp<%s-PLL|5D{?BFk*O$Ba^qD!iGFEMUU)H|lYeypI=8nfUi*ybagMppszq=$oNwZD
zk~G%y*`}V^19~gJo~LK-KKH*2{GQ2gD~8L~s+hn^wH+A{snr%dVail{36kIwS%2mS
zE=G@^Mv?8N*ZMVj9J$Z;UohFD?t?62>x$*a1t7nN=#zJa+&pxVa&mTYHa$lbz|PP3
z%Kmp70{Ga^v_R12@WNGYVN}8QRbfJdTJ5)Ra6|OwsNw(;GCq$72M0$PDVi1}k%&kH
zO+Z~WCOZ1c^0HR-#909+ZrmNyZoWVxW!OKsTqChW5F&?wFA^wdmjPL@s=vd-!^MVv
z9P6~Sl(tq@OxaT`4GbVE87`sk7E<KN7h9TZnt*0$;x8`nBP^oGQxAkZ{AIQw?Z^^q
zK=%mr_Vt8JOg>^KZHPk1ptuXa5Bu_S{jHa)bpm`&HCr8(6_wut8DkC$Kj4F=j5XEL
zPyu`T+abL_Cy?idQGqGDfPrx|lgs^l$-V<<HS=*8h|-KCZRsUd%$c&Yv$6o`j(!~J
zplUApn9GU(=_cATjl@WcK`Rg%vF&p+D`*jyge{U}(#wFX6$a|R``T;`>}hw8=3ux4
zEq`)5oakd=h|>{yP6xR4pM%EFEbzLtnbU{AcT1B$LaR^Bfxs``HI0GkVVvIY&2c!y
zQYlXFVUO*lWU+C6E%i`;Y<zKjtv*+yKXxv4>pa1saqnJ+8$)Ewg_9zt3#H#~1QD7Y
zb8|nTz5nYOearre;(qWWt)&1(1@(YXThM@1UA-w{AB_k;7eZEffR3G0VZ1=v;UmC5
zf#}~n#EwE?jAecYWpQ>5G=&(~O29uhh0!0lXFuVHag`hX#u$5aZmHFan4P+`xv8Y0
zBXXjvgho|H#Z_6Zr7u6TRH@#jcP)iPB&npYzq3TG4rm3-YrLf<<FdPA>>4tFb)K4v
zDqVAfk?7asU6j)xW}FbtIw>Km`?oHRMSpBok@Sr%pwiFhVeRBx<XnUemsI8C{5_J`
zH>u#1X^|5tkUegtRg>1WwY5BzK1&FL%>z|aQ`IGdDN``c!MfZsaDwca`MPX1e|>#h
zX~+f8H;CclVq!-}M{1a%c?Q9##>maKMMOdN|Js+}WPdIU$Kq|YT-Oo0f%UQ$xy4iB
zV8n}sfB~?yj|YOUTLNe(C^dHu-4)<XWj31ozisRwK0RAUMd{IGc{;fGK+@XA9RS@F
z_ls3UW#x_>Oe_>~q6Qq?-wKDIRNOCvql-A-M3CU%0D5w3zHu-lPJ2;{baRS=Qh6Du
zKOs(}QIhmuCWg_7-TZG=VYgR`W~LmbDSvvAQxHOono=6x`yG9pNI!R@C~*Y*ROU2A
z!R_Km=V(t!Q9q&Nj2|+##tGgU3;f@{C|+-BFCH&D2b!6DILp7IR`I*E?ON`ptu^ou
zn6P1{9pQSEKG=U&R`tB^khj>tZ{Wd|)I!z6L!MKgBHSRJ=T*X{3Z0>`2%5iS*3W)a
zM(s3SG>Vn;`tY5N5vjm{7Y(0IwpyIxxi%zFm%4mQk;M5}^omcVw*}P8_*H#2^}9i2
z({eD%oOr6YFFwaJxgFlmbQlA=C4m?>7Z;)M$J_*bGI{lylNo_wp9m&Ul~!7Aa&q3@
z-fmA$=Lxg>RN-HJ4+tna5@K*zxuKj%<<@~aMx5PwWo7kkmYKT5jj%x{Sz1llWZ4#@
z3ij}#{G{POaS^lZS~RSztkdH^24-ukwOcSSFi@Cu!9q&!yC^1A(GNenI)3}Uo&t>E
zGoADjOCZVfxBush|34%kisb9oADE2jC7u(9f}+AIXEmfa7YDAjch1sG0JpXmYmFT(
zHHemK^KW41(KdB3J5a&LxFc^LpY+}T_OHJ_uYr_;KmjMRk_sRUVUV1_A27+j7hK;O
zKb#LQ39CTx%Ie^VDtD@7`@Y5D0k<hG9D2VDlj%^@n25W_XCXphqLGP<?8#9f>+|z(
zN9PJn4^7A1aOJLGV<IQx$P+P(K13a=C0T5#elffRyC{R}S&}*j`Wb7M*VK&WUum!Z
z%gal85s|47NkrY<aEudu^x+6yFpA4*;I%ik=Wjy$w=Wt7hJ<$$QZNmZRg>oh#r0Q8
zUpMV=Qq9`5tGsS<uHE#>{Y&`$y|l#v`S@qVMnXflz^RmQ)l1HF-`gOg84=wObcacg
z`Xr^sau=}(&&@_e$Pe-&s6A7!7=aK=!x#@~Cz}E;@x@qu0&uW^n2Cwj>($SHa|elg
zh7z(0gAq+tiSFVPl4>achkl0djfS4T$M|44UFh=${RKSmzcf$4xQhi5r`2AMok1Dw
z9B_Ve;vse6XbG;SlipF&y?yBh{q6_%D4n}1%4@Nx{L`3`3)xkDMMXU&ou2vozGpYk
zdg{*q><fOYmq4h-)glbk^p5y)@XrO;@?s$x2A36cWu2{{`_jshGao65OG`T%dhrxh
zL>@*E<%U{9gqsr1pEdvO2Sg70zaJ0)!vgy7?&VcGKy#Oo@eeT8?tFb7Bqr_w+MCLy
z*Ew+lbaZq&f*ylBH!LU!H41?s{E3LMm2jeU8#Z^F3l5Kevy%@^D+i1zx(;lzLKtXQ
zV9-BDpuqzHZmN!k#=n~ZB=@V$%<OFGCf?tzn+S9p1`MlfOD{|5rPIH7x%s)J&FF4F
z<;pTRBGM$9A@F52MPKR<My#!^)4a*&Zdo&MgxXvhR%D5eEkV&rGA0h!+niT`ktQGs
z>l2uz;Lno-v7*>RPF16rMU`DPNJg1R?rcYsuB<GRmCcu`V@s2METU{+Ss#GvB+ZlU
zZoo<lB%n<q6<Z$^A<1Q~H>2jLUUG`6>kL>gg1``N`=PF?7FLqJHP=2g*FoZN8HE2W
zIiB@~(m_>%50MT9!c0RV!vn-hghUF#OiSM?L=EzTU<>U97N-QQ>R4+EWOtVxB^<d3
z{~2Mc_nf(OVrjcOzoy2{$cHB}fr1OK$1`PCe8qU~WC$Kp!0C|wv!J?K7HtS~4BjwA
zhym;U=)BhdC0ZZh2}vOho69KyY(g2GwTJNQW^Vwf`_$aFrHz29nVWs)8fn%Jw>ZWt
zNH{zu*MbY?b!mAKSO)0sku|D4fOd5{y)F(mZi$yj2p+=uIf|VBH><-xCJ`)MXX-3h
zKckF*-R86|Hvz8~3pa0Y^M+y@?iM9t5+??O#pL_NMXmn_wIUk->q%iy5T=;raA6-7
zQtgWOF~Csf``W)doWPF{H_m9w%mfHFG_<swpTj@osQ90hr1NRXC*di@b=-+n(@cQ~
zz_^~<BS3`u!hHM}qU<D*nJ9R)s>Wc55~dSEFCuK<c-m*<zU*!FhdnN@TUA>*C;M|K
z(;(mP+S=OZ{?KUinH=nkYjsuh5W`V4jy@xWR8!dn7qqG}JNIc|t^qVb>Rm=yJkcq;
z@ugQ3zOig-NlB3vrPEb*cD@4=sH^Mi9^ZS6fTqM%dKvw^B*LOt59AdrdGKPD6Z->&
z%W_5h{Z<8a_{ZP9x|UeUxj`)2!;l8@u*U{Q4<TYK3KCs8XtaA(gj{pT55e7G)*f4R
zAgH|(Du@C2VvcUAhxG3`XbNqhP@cKMs#u%RN(zoaN*Hw@3wcWhnc)DG`c=D}iH)Am
zJZ0E2riMv@dg#07zrCWRRAfB|Tn#ewkEECFJAx}OoOlcE*2~rHtt|is+*iOFnN@uw
zr)<HgBSeb!di1cuS9?8h?f=Jo1|PSVucMvxKf?=`>)9e;_UB_`5-LV3YlkjD36H=^
zf{E7L?D78simrM^1;V`^8Chy7I?&YNg6S;aB@AuLK%)vE3m%DW0&<4|R{Wv4kOvGv
z*eWR~FtRa0u;#(ZMfXAf6DzhDp@~756&kA1<t2LL)Xv4l#>&D%GdV@V0y=DwrwTXZ
zfia=vfXmLx`10)k><*~8fq=4SoF6|JUk}<q0Rujum;_p>J3jYQz`n?=#2iZ&lVjFp
z$;CIX=W9WpADCio0zL<)XPt^d0Ri(Ow74@mG|Kv#D`0;O^h*GeU3^Ro;v*76J6$DQ
z_ZM=^cTG<j<8RH_als7kR#vY7O=1Yh?$y@n)6&ugf)?=HxJMi-D*k;0_T}dT0QtVa
z!0B+LQgU*1%@P^1I&kAqJFqOl#E`IMNQDsi{^jb8ZLZs8=SaHW)^+4%vut?*B3x}U
zAuHu~s_k=AK)6&(3qHS}kCBa!ml;kM(a9m$zPJu)5ezw^H|+Sk^x0KjjPW0zet8Ly
zzqr2ohF_{!Vnsrw^gUoF(rY>uk>-NCb9tk3^DqVCQJI8uh(UIU@usTk_8y2)f9xDs
zBOW2nXKU}id&<?Vy6B0~a>21eUI$rE6oH8U?PeH&G4Um)&q_~b-Oqqs@)XE~9AY=A
z6^2P`x~-h6!r_N2Iu*yoIFeyhY16k3hR@u%-0t#rmzSSmFO?4uCZYjDGIBUM90nn|
z>8AM+Ed~H9Sh&Ex(*n{z3kwSxDk>%&IYMMCeEk1Vo1yTS_?sOB(IK#?c(R&_qLOy>
zDwr;*Kw{Aw5HU|hMWyC7jXRQ>mI_?{%}zgFjMRGW{3(o_dlWNUS!GRRNk-rY%PT9j
zqk=})tFx;f&(mEB6c!frN%Mt_(P5^<SZwsQdB)1(cH2(wi~|sYWtElOUKb~ee@Rgh
zNVst>Mo&Kau24f^v&<cD_5I#9!jTBB)|)E}3kw?>m;e#r4R4}^iIb6&pP`?N$zR~Q
z`TF`YFDPe)HA185lQ@JHP`TUfIC0=&M4JwTeVgc@wOB*h`T<rxfQ0_N@jF-SBg=o<
z=as9Mwio@c*OlZ0<AmcRHZvzbaB*FU7&N<Iz4z@Eaxw9-v9Un7TS-|NkP#2FL#Mky
zoH)8T8MD$@Hbyn?4{C{3r3=!Un<9oB6P?u3z=33(0Za${9u5drmR71yP#qNF*`#FV
zlZ(>A@MybSoGAeXDj;ZI+4?wnIIZ3PqbQp}905*zsY-PeBL`_+xwnzEiCu0-O6C@5
zB7Kkt6V^x)CXUycZeN^Z(X!Gi+Hjw`1}o$xaU~U{7q4h5ypw<}J35V-bH#eobkbhJ
zparJzmQosqOkB0jp*K2iI0>f4LvBZK`6}X&fKZq}Cl4|RpP&Wz-k|NmU@OSTO^6`Y
z#8Brh^Lw9>vR)AngbFitFh8l$^AZ7O6dKqicHUocJ3BYF+HJ~!tY)dIlD0@k?VJGS
z2Ke?8;M4&0x8E;M+6iFgWp$d>vsKG1*9E0LJ%Di!e<p~qRP@N#639HjorTIf(^7OC
z^WO2U?dtM%B`HvgF8)(CdgwM}%m_v(|0)U>R`3Dq?)G#vrJYt*&AS2;bmG$7+>(}-
z_V5@OM)TrOxG8<!RaOCA@B=Vj9Hmwc8QUCRZFxgMhj;S*-nka<pxWA<jVF|%Ob9;q
zU_*)L|KtC4TPWV<=?QF70OhAzB|7(_0RsaM2TM;Ka<nLTA2L#gKJr@euG!)}_%&ox
zIOeqesJNOQ;_hVe%+1&tLTuS-i?r3w`Q%r>qYj{nzGaW2r<wGB9V6$9pUK!{htZdy
zhZB{qGdDP4S*}q}8H*gdy>%4U`PRW1cWi)*rEZ{LC9PsvR)>(^DeAvC`*VJA^}X@y
zLjQWb*}AwG%vg(}*jxe(T}QCAm0@Z-+H`HaqJmw%b8TZ~VP_%QVFv_Ul#%5qi}9a)
zk_J4L^|$B4$WIJ7b4OKVlkUVBNHlK8cKW@%ykW<ub+wu%G2M(k*Sm8Ny*%fiEZ@nd
zQ<hjGF)yk&Xo@3ptW?EHIXNeF<+1ZuUiY=eD_-urJpGhH=1J%f3rfpjEm8?(s03BZ
zVx}iLH7Du!Y$w1X6Yp@NR~a)%XObDylGQB4oV1ejAY=Amg?SH~_n8nHHE6V3Y%;TR
z0WSu@$@xm4B^Z*_E)aodka$5h(ojK64{(!argVGUwy;E4L&y+P%8Bx1Bxn(w@XKP_
zc07-_{<9HV=J#V_Pc)b{w$+!Hx3_y48lv1HE49Efoe9LniE_ik!2`KxxD!{0SY~Y5
zK(g5cH8m78G$@iR(;X=j8k1rQ0&IcCj)J~sn-0sDGB6hbU;-W2-RF;9^tzo`a8N|T
z1r%ZuK9u`X$|%m@1Ei#uW=>XKMsOgCV>m1^>i0A=PE~6r#2?^=e)1efqs;JOLB})t
zK(B0UYRdO?im`X9=~2=GjG<gmN!vCTP~S)0MSUmV*3!^{Sd<5u^W77|Km0?+4o9{9
z50dTdJ^;Lbm82bmkuHbnaG%;2RbL2$$&rq0q8>oT_}{Agd%njWP*ZUq93=W1x26)S
z2pk*7r0{*1F=lhK*>bs@%s%{8Aw=%2wr=P`WtWPGwn&g&`}>=RU{h^R1K*fC@(IJv
zeQtcosTh<-^e}G98(p1kboRh_FXkK4-a#-*fsdS_25s%?cBiNVttf6?)7-;U*=P_%
z6x3)v>p$AGW;M1|w=N=cOyPtO4>6dU1h(NsP$INS=P0^~wU@ZKu9D55L(B}6AdK<>
z<>Jhy)=UJ~b+m2zii%*bj&o%Mjjpzwnvb{V9?yLdLq|oY^+}7jJx=C4#o=1631^-e
z(5_|*n4f|SkvH}MI6_0Xpee9ZM3g0cZlFSFbrg7V$9p8=+x}l4hlQlSSn-=o@8RI0
zAqdNgeprlq@EgP{#1X^zC>sl#nhsI%z|GuydU}3?>4>n0Q+pE%_2uD><xh5PYXoG<
zD?&piY}xEKt2e;}?*`9TyaISZH&%awga@M)%^?H@ciEg~e}zm5BXcP3iV7l&g1#c-
znrJ}q2Y~SpRFj5M-Yz-n06-Uj34bc$Eaf6<ntsZDgBk0{Y4$N?!qg1pNB$+}2X?Nv
z@9#Xu9*FYXg!-Z0pd$Ji5z$FaF@r`R{=;_o-$F`uV_?}it`75m(q#>ah64iNAM9@L
zkNRJa0R1GLQ|q&;*vmu8BzDC3rk6<drylgg#1zn*kNt)Rq?}BYXZV4AN7?s<M><6@
zq99&Nvf|j;4=9B3#Ei-vi1qOmRgBqnFunF?=iB_zb6X8L#=g6U9x_g1ie@k(F!<fE
za-iiU&-*~mO?1*v9vdA-%)trFHb5(>uc?FTzy|U8X`o)*9aX)jVbF-CU_^jDjeJU)
z;_8-$+5(q^(`MNgTIYwGLmK9M5uf3#hN5Qdw5f7@G)P*QmpKkire6Xod|#*1nTl44
zhp!LzjFzI}ocDDXX8aKU*F)n=o2Km2O$_C5y~0o5@d~J(#G;(gk5psy0CJ)`n)xdB
zZODi7I<bF%PQ@1*5x~>&+W^r5@R7JcER^ONFdqfrmxhLXk)Z`9ZytLV?N@bN=V#|>
z!krI3lfG#kz*10GMzMQOqUnv}QxL}HH=9+Ho|e+Y(pnYDK_I_qyVf8Ynib>r@%mVF
z2XAIHXaK|0AeInI%9qD7RW<{$0hOcEfMtrtlDx#Dk~0a(u^9*sty`0B(nSfW!Gs~+
z6WGCI@zOg;Wkjy|b=JCMwY6A3W>s(2(b)a*v~fBnDI;!Kv_6JL+*~23<yiD-a>IxG
z3+uqU%wBAQtjMg?s(r|6tJCy;#_zR}*IUt`o@zi3g!|ji$Ks)`c2X5<-4@7S0B;ya
zE{B7WhlPcc4^(N_L$FYg1MMRJ#kK*x!0wywq5PzMpX~nJ^)7C#XdyG#Pjt<(lHrE9
zu&2)FFDF4ciRaqvfHPQJI2l+0NsJliK+J?{48wz8@2!4Tlv<AbJWB?5@@iPJ!uGU+
zyS2X0=A6@NYY87mNS#E#A5P+s5%X;o1vpUkz~@W?4S`7E{b?J=mBjw%uYN7Hj`zl4
z3ZzlEn_hOwA4DEQQ}0b!ev1$EfA{uj<6SzJi$=QaVr$N_2tH24HSM0&^?jFC7T_(6
zn`~emX3P2&#8@i^Lp;ArP=gS4>~4sm#SG8~VoFO%$K!E7O?zJ(!WB2?(EjqNsHhpA
z9@EpvDAfn*T(&}c2?i#5b5qrJVTSAxz%4wh7*7lol$4rv;?6wmOQj4v271syD&ex+
z@tFgM+tnr|OwgK9x7SP5%&~B`mQq^c1<Yb%-WfWX0a2qB1%ljk6b`pb!yQ?Kkfh}r
zu(a^~+YK%$0rK6*79WSh4ckdJXYy?NPskm1pW*Z^^LXs7UCrBolG6Qpx7gb&z=Ff-
zH4Kqw?2@XC-6r7<@+ol*-G!QTiX2J=(EPHM1P!-=(Fy<i%^Lun)lqg4YQSwOQsBgc
z{GbE@EfQ_>+pC%~+W>|lT^;WHnYjyd7o45!5Y|afI^cQnCxQqfl1l8T2mj{chQHsC
z31aZ&FFz_B$Q)J4c4&s(wmTP3|G0SPAs_NoF#+ku7gP64{-sROVms#fMt(Kry_$YX
z(>cf@n@*++X@odfJyE)O%DUw;ZRBdt39_k)*^_|3b$E2VW|5$5`ge&l_Pa}mHa!(O
zyWI@`Es6Pg+TnelaJ8tUMSIKueAT^lw>UX=<^z`D6)_q5fpYBSa9+bFq5w0(0Y^<m
z#hL!cF7zQfI>FcH^Yhg<e9#l8S11B1K%?4~hw4H(4PW?#tELxl2YtrI8mwOg##VrY
ztWZ22$d2fC@$lpXdIpk?faU0Rw>LoWm)WL*%KV~7oVAc`ooZthG4V)0ki(VDZZ}L8
zA4pZi2?bJ!N2hKrEv>h$++R`o-!|O$%`JN9!p&T_&BxQq2<#})QvdJi8vj}C=o;Y-
zWZ>9*B5q-2P*@?Pds;_vGo-nes;U5EGeDX6kxg_Y(qLbOAMoNFLGCa56V6E0bP1Zk
zM?*`?4N$IjxL*OYilGBXp$w6;z!UL$c`^yWX%|Qya)UR}pvUndfEm7KtP$rLRHydw
z3B+&_@agQ#8fXf4iekd_bsJHzxoIXq&5~YI;%_u*0}NxJ{lwkD_2%Wp>2k>dNoL8}
z?Q>FY#D%)PJ+FKo@&_%Nu;avABMA~TUR5+&e9mLsDYlgppqECzi1sbp&WX1kmZPv@
z8IVRcXJB^(Pf<EF*-fnbjjC;pYO1X&`V15HhG{}jG%$idDK7l%ig;*m037%!OJUvw
zBHjcN2OlzMsPuot%__?q=IR|w8%-OV{}_oD%ju@2=3$oI?$Hh{(LcDZ7fRRe^?^7g
zl%`@@aGrCU(M%j29^&!&`~hgMKpS_ZR`&-!4qSLY8mE|Ikc(fi4oC$B4y}Avpe4@;
zcVh#9cm;03TY!MXw3g+~9L#CInnjO5dI}1_cGsj?t+AdFHC*r=5)WfIH@Dey;;1=-
z&S?3my}i9N2rPajni~}2D>km*!V6F<0jZ0qS$fp008G=-SlrIe4^YBp+V}VZ2(<op
z9vL8{?&oP~nIHC+g(ORu+?yl_wM`$*xl0F-)7Emm+HJqXHyPbCX`Wbxnuv{>C6SDW
z@f@NjJoJO&-<_dLS4+*+bhS3S-4+1($;!=*9ND*U!+OQ|OMd(1c*sRoDUbmMRwL*K
z!8)ko(b3@40C+;!?YA1-XSM;fF4=Hex@E>?%<^W^lJo^LBNP~k`SOy8B9O{<u5I7L
z%gKlxDIzf$XSi_^LSc}gqR3b^`_DDUzMi2=`c{2*s88<qQb+>5&$UyLBZ&cIdSr`<
z=C+mdVym_k)pu@0G9Kr<{Tx(SSj5tVT=I6O$(Nx5ZgbW_IeF{?{l#L6LQ;wiI4y;_
z1e`nJ@3yhx0r2%3*4ebhs*$vBsDANuL-pGzz+|oAPKFb*)0M17ec`VI!{VF3FWg<i
z7c_-D0kh17jZNY}^z{vt%|)y`xuGSa{kv-g|8vcsr$7t}Z~=8YydJN%I+Bx<^9>k?
z$PGX+i?v6SQS=nF5JhHf(fTqc&D_=0OjVbFWF=r)Gq<>y^82?vQ|3IDgcHrNTL)0W
z?&0A_#Ka_86GWi65O$btWNme|z29&)<jfk28yYG~O3Z9r(8BMr9s_2;&MIA-Q-KJt
zyOD>yqpYm6P96oY4%ho-fMomn_S%In&w?sgSZlHzRHPy1Az~g>CxLj?mOYiwo~oW=
zzuxJ29H%=)I|X^7N%Li5!TsITDTF@c?mP*$)THw+N*YGPud%$ozN*P(WI9)OOBcAi
z_gviK1rRf^;op-)URN#LrVQw%)(R-QP-Ng4aA&luTY&usP-Ot0RIA;ZlDfXSf<hf!
z=UbzgBQX>bnJx1Eb%AnUCUxU<T5_&4&@l9Nzt(GWA|oObNJvh5jm(j27>r+gOWHu&
zBNq{c4(b)dhRpYB5FweLYP>I?Jm2-6Ual^w+B8l3W;i>aNyfGL6vZW*#v-~0k%&H*
zmRQ1FP-)fAoSuO*Z_JmQ=-4|FtheBB^NDV48eCk5_Op1|f@VbfQZ0H)D@Mz)d@40n
zCjyvRi$Q}u(}~*o3?M$kI1B`u1d_sJD3DjXqy-T!uCU{BxKPkZ4r9VL(op6z^UyB>
zEtdMJM!%mhLWYKhZf<VC7c5X18u}HO(n0+sC&xTGJ~lfxVqk@&z*Q<A=^!02J2Xj8
zNdY3c3i|tjPT%Wm7$9%$?Cf-Hm+9Er-rn~6I|{V;_sF?!Mm5ql>Ya}(MCpI`>Zz;X
zayp5ig$fW_!~jW*63LSP<%<Kax!(FiAoR}`-Vg4I%8KWUHD+MM%>nY|(e*17a%O*D
zh&VA%raHq2celaf7nI!Go<mw{y6N%Xl#~<}Kuov1tfs1dTzjT@!@!~1WV|wcHy)*;
z6E<fL#OeWF-&2|F*_*T1T)EOlz-V*6TwO>~NHPk%FQNQd0C&3IPi%qleUDh^B7Qg1
z07#$xQ$$M6zH;aWXla45I#8g}($fK)XQxW5muXBMI=c7MW$2i`@bE|mNJ)G{br&zK
zofE7vXG=-@5j6jM{=y;LKX9HB7zsN$F;iqYc{Evo^)ze^&N_JFF!Rp;-g-7PGXx`{
zq|`)}mb}Lrr@Fc3<=SZahVndJ7}u`0-Lj9J(v*!89|qm-d(0P^`=yeDgP{_d;M5q?
z?`&mScsUEb2EF6F*j!(-(n)#lM9jsB`p2Ks=b-BK1phjB?>l3jpeU}`utUXkos((q
zTj>|y^*<ztaO=x$-36BTk%LDsM&Uq|MeJhGcR7=`{K}l+(0crm^Y#LYIg7>XXMlzE
zpOI;7Oo1atSR8lQ2wx!X0PYT+s*(!uP~#$syScS2S)oH1e(a0uu8_=~^uPPiKrObK
z{N0(=GcowpT32UqdC4NG`0n?6<UkeeuzWD+xGg7Vvl%lnjZJoeR1y&O=+&|#-^kBQ
zPESq_8Z*kO7K;QSPcaH0^}&Oc?2eC3_X!41Tmr(!1`V1@Ka5_^A8>S&^t;vkp%WSX
zA{v0e?(gw&X}w0f6?mYaX57d@z5)dn5Jk2J#IpeZG-$%wB`E3{=5ZdjfykWks3-u*
zpS^YE){%=CP7!5!+Fz1YK;fayP*9oT{s;@LqoR`XRLE}%<i7Ohx3zI%Yowjvi}s|x
zs>dDZ(5V|55^b07#*lpEMt|M=7wYp)4eghyM5v<FB@vxu3kXUwkUQP29!=Hw+IO_z
zH=(80qAS%yDHmsaT^$b1d?mYmHH;nap>c|~!ZPXUGLY%CO_un+5PYgW9r@NyxSnQF
zy<r6Dwsv85ClKhc(#pUo;qJjk$k2i=CF8Kur>l4Pzv>@#y^!?PV<0A`eAmzez2Od>
z(CCM;Pc0d1$dMqegA+UR`T5yO5oOkxc`Ueil&ZTv-^!(1YAAwN?k&r7ukjVlssq&I
zf0VPMMCDnry(l4!C<2jY%y+8t5fHV95T5~hM}IHpRX7FhRvOg>gORpv*rE&mY+qM@
z;%#80ar`dTyCZkFp&2>tlr;5Ji8u;8my{-KM%=~gLo>~(%Ea`sIuSDHq<=k0v%c1z
zZn-p)<D(nxmRe9{-F)kPyWKf$oz5UO#P`ZFaSC?fbInaOtz04K@G@h=-xF!<Fm}gT
zx1{El)`f*02-f|y))%+WJronK+QUM^8Iel*hRPuY(=A~92V%rh4cgq9xF)<Q)`8Jq
z#EizivtR!;xprP}3PstyY30r#_EK1Yv~<F9z4)2ut4{Cq@8v$^_8pGh3c(<+&c2V{
z1MQ7=Ns!V=pZiC>!^NJeGY5h`7)%yO23bOz;Cfihco{B1Y@>1E_<K<6v7X8C+=Vc~
z`j2&vg)E$DYF10X@wch#hmCZaJ%-bz#1<aZ6L4_+pK*IOj+{PU^G1U8ZFQ4cY9Hg%
z3epnww}M~I3wxFNmchJ6v-A}-(2e@Ub^G<bmm+=g$YE4mn2nqn>uFWN*PQDu^zMEy
z@*CaO*4Og0Oz{SyX>GceEHsdL*07XZ^NkL#zY8&Y>SU0zRW(;Gv*?_ws!n<459hIU
zXHi6e?!WA;v0M6f3-8-1l9L-g>oI02wW!9r3n%0K5WSE8^UmrqxuX1c*rwT}pQ(02
z%8Fe3jRvU>hKkEO?>kX)@Bh&Mfm0xO9eq64{+s^L^L1Fe&_zQFobxP7sxp|;lIae_
z##7Oij3^Ot47Ht!+!Q9@_`zPIam#6pJ)trDIT*9M%h@<Iw`fRN^I*Sv$o&{S+I4Tl
zKzBwp0uvBrA~=9$iBpkx)n`#Pt_=nnfP?rLa;-b*eNPVP{q;fhNci~ix_u>ebpF<T
zqUSFc#4urDg8$Rd6>oUP9dN{#Klx0(unn&=Wj*&WYp;Ru4TN6tIp$Bq*FiZhxo`?v
zQvIVYG7ZvRkLv>OnTFybrpm#4G`-h~OUHHhQAPVE%Lz%1b33gu%#>EoFDo4yT^Gbn
z{@lwAQ1@q=7y96TkNG|am?1x4)jJa|afC7Eqlwp#S9sbfaeZW;jywyAcmH<2;njBi
zP9Alh<V^(P<>I4&|Hpm~702KM7KH`0gybtgpg4m+)?7nx1zmBjAb4vo(ootGotCuZ
zWe_kq<M{mL{E~c_Kkok<z?*M4N6x|$n!yaKid{C~5L0sNv}m+^&h`hXGu`>d*IM+W
z(yqsp1~{{;1XaA>oJ~Bpl~nbW)DG7>SDXRd)`Wfp^Y_k_-O)}IRH=NCBQEeCO|tW;
zecLya{sg`bWaqI2Cf6KR<J2ahuD5ztG!>yARdm6<p^Q-y9%u-g{Cf#QRTZ7X%!y@G
zLkQ?~O_?>;PC{AO&pKbr{!i{QGkDfCbf`qA32Ku0oBdPliVKe!k&<XBt52P|-VY?^
z3qQBJy`HXO{yW0A?@h-8_nLw(Y_<((DUez%ko3P|T(@^I$wfI4i*O{?AYNcd9YDHp
zR82hiaMQ1K?qi=txogew{{1R+g-<Xl+VD1{QY7_B&ADPJnJ%Bi`ea%>q40(|BQKt_
zHjHm(IOy?bb=XsGJOA0kVXWrz>pSu(S1L?D8pl6*+++q=SofOk2F~l*w>Iwhth*>Z
zS!IU*eIPSz%IldJ$@!mmy<1-0cB-BGCVp4)BFW@~)b@JtC{~f%bc#T371g~@n(RN+
z9znPFbH@XYA%If`S98IF(Wmii1ws&VCBSnbk)f<lDvkIuSQIm1w6NqZf}T&dgxaaU
z6$_9R>hqzu-Bxq38mXJoV23|MYv!UPu81VKbI8k~L#!Pd{a|l*>rMm^t6e3LzRiS_
z|2t`g_31IfjXwduLZ6C)QLXj8E*Iq%XRSQqT_Q5V3~HYR6<%;BR4H?shR$glK_*t5
z>yFEn??l%}9S{=Qs<8mZ#c+rQ16lm~fTmO_gyz6<NsP1Laf0(ZiLL=5eOHyORl+5>
zWkXALA;p4%YyQ0FQ}*BM%49EzHw(hTipD)8E;=+c<SrQn*?_x;U<>zRl-65|u%`Ep
z6AOru!_;wN{eQ>l-`;|NgOrATA?H3qXRRq)W~+TOUM_OXYG{|0yq{4F)|{e}i=L>z
ziw$L#F=U|7?!Ls&ibHVXbnQ2=-LRCRKiOAxV$}uh#NE<>qkaCQVUI}=Z5VolmdkwB
zOL!~DJQ|_Ib~Wi_&u2hgD`pZ~$*QYftYKuw^l;;KGcVb8A9ivdkzkgehU4;uz(HbR
zO{Ax&SHJ$SFI8{sesy&)y=*)C<b7zo{@)73^dxR3&#X*qtHpzpjfJq?h1TV%cIw;f
zjR65EnR5aMPlxR60#9Qd#7Pz)ZxOXMuD+brdf|S-V`slf@yB_E>30!z)bnuL+Skh$
znad7aIh>N`P*N@Bpc+IO=xAcbTGbVg-Y4c4x%;`9S@WTkuByq7QQ5KHzhU-B@AQYr
zFMn_Ib(N*m(7ndz%qt)IMpQ>)oFQ0IK?pQqnMFB<Qz=#dGo%ls*O3SLlbW-dRY@D=
zVHQLV9mc5L2xh8?Ag0ZiZRctH_GP|RV6vSG*QCgBPRR#DmgCId)%@hQ^2Wy!Ey{Y@
zSDrUs`1kCz8$LM5C^N0Bf{~pq9LP2Kp$*<ly?x`x7DPDOF}~>npO9p#`~uy|#Q%#%
z_bPRuby6ox=={Bs#TgkvdrA<uJK|^A^uA+*ophP4f0LzrU5y@6*s-moLFVE=cYnE$
zNBQMO@scyjXZJtvXAob)FXUllB)vbfD*V4jqI3xc1P^%<f({!($=#Vhx<b40oxZ{n
zCCfjhd&)L<2<{KQK9a2aT!V+G$JS~0(rQ+prf0{I4646<V8R3u+RL`0B{937iQ1L%
zC-V$LO<T(ooWv*^PNk(xsuh$a==DHGOPHPMO)(ieI~NsG13D%#WN$q!Vv*a^Ld=oR
zq-$Ow@hj~(<Fabwo<Q+XbgP^bISRt%Yl`bn;iX^TVl0fmk5i(C%;T9?lG?iQ-70r-
zaM*RBa;3)0%e<Cd%Co2<7g^!lwP*~Y4j<hXwmmiiZ`#F}6$7Dzfy09rYW49b-{tX6
zy1bqu?J;++#ZgX%dj2^2b>_IZ1Of4wd)6Z@MgcGCA)DLPMz-9|-%`9pQ~OKYCf%fp
zg)ggnGy9Tz`dY7)S=nI?DmK4;w!F?(Q`Nd=2WRKa)5y95JAURxN%m%b;&xKOpUZQz
zYuOw~4oZuH`pXi;j~tYhVnJ!ErfWLC3uS8RXnY?hF;Y4=+|oOLxHudv2qBmNS)v_)
ztjDH`<D1du^mD;GW#<P%YE+%xdF!<BbCXz}+xqoFng}yzy(a0TS`}RL74^oWqlfE&
z&sj-`L7R)C%^!#BFy_~U*!a4|6#Td!=u0e$rnMU1^%@!LTsUzhrcv}p53hDI&Umw~
zub0Hbt8LbiaUkKN#xcWOe9HTZL|OL*?+Ekd7>btIL)?8)H`dTA>>2tQWo(3yAvDX{
zixYAhZK%8({f{nCYJ1fEpB7z!IV72C1!Uj=3;%GC71xphm9uMXYAUuhd$`+`bdw9D
zdR4Kr{a8{?v{E4EJq`1KlO+xe_8i1Fh(`epB#0v`LNvK@4z`?j7pjew0XsyjQ_5&*
zxbLY{QlO_n-ZV>Mh-PB>jx|5tyHuZ^rZwIIM~5$WTl7~UV}J`9ox4(~&DT%aMnBA?
zo}B4C@^6>Z*sMPQ(vX-?&yB4RiA#YDJrC5ui{b*LR?Em{9ow28%X-sPbp_Q|?_0Kz
z1gJ5}D$KEAP{MpBuDmX1Hs3Q|&$f7}9u8T2fF!C;uwUU*)%8H_++vY*nYNmtot2ym
zeiTc~8tVi_$~lmQCx~ovdxAj-L60saAI^;FH~Qcwi@)6zO$L*wF4=mf1)~C@L}TzM
z1+B^e(->@X3Rh|AZY1ySq72{k(JiRKm)^$B;rnWFyYJ|1vq;C8^}yo6UZdm{d8hwR
z^4_XXV<jhGY{e$h6<?~!7geK0t5ttSjWvi6=5E+knh5f^O~%fG(Dg{-b_D;<X3!0f
ziVU|^(2iS%?z6w99Wt1}DYrebPG<@E^1Yzy!yvE54}T=g*-w5rYUZ~LnSTbSXU291
z#^j+Z=+d=cbBh<JYbtAYlmr=3jp<!hyMVO1=L%-xBS6f?;DSPd5X5M+1687`eHVGP
zVshPQ_#vZpDk%(8tPXb7rjik={|JLG!n(?!Yi_DKoThsl-yOqx$v9ErmxwCbd~rA}
zQv#LDT-yCu^Q-meh|J7_se;9?MID%I=pT_$eF4sbx~Qk9rzz^tEzRUlxKZ}jzo$CI
zks$=PQMSB7A2#<#gHP{An7Vdmq1nL`SoSK@e{$-$zGQcx(UrIyQl|eZ?zpaQaL1zo
zzKABi2RuB1{IL$wZQ;W7@_xD;zJs`UEj-~t_d=yw0<Op%Ngg*$gf(G5iz~;BD5|P8
z39c_{Ha{#aJb4+bSKg$6Pu8f=94&#~sA)J<i5xzi-UZ|D_%%C}oI{~-wS9GX9V$vV
zx@5v6;bc3Cvg$SDs|&fNOC&mfg1B#A*Nc&BcZr|dncu_L9=iqDO#7^`$+AvIAim3D
zW|bm@l-LhCTq@MJ(AC`!oK0V846s#A0N<_`)swXL2h{C{=m!I**F_XJUhJGq25Fh0
z@ybN_rxeORL;_u;kd2&%?G%F(Cnd{++cV!~@e(Gj*Zgj8aevbm@6u#XZ+7zdo@LJ$
ze}9@_%x3iXnWKCr0$<U=CjMPVXbkH@%6a3VVu!iqGS=M>V`CN~JZ)7f2KX?Y&sBfn
z{@^2!)aA<Me?#&-h{}{knI<Ys^Jt9pPpUAZ6@+=9gcssna7&|UY-vfo=0)3CwHcf^
zI!aAXLU;0ek>K;x@n%4yI6}CAd%e{4%kc(5i%CoQc_y=>L2OuMjc|DthM%^M?!gcN
zyd3osEx{f~8#H@~Jb^3yhw_g$`=h(88y|O~6pDdSNVRX}PbrZl-iy>)?K;hT%eR)D
z9|9JKTD-U)*kXK?xFfzVJidoECC}Q|TJut}+6tSHQ7~!4Yp-S%lER1InCy@-5b9IU
zgQ|b0xZ}dCu+Ogeb^swkK{RYzcSx^ACT%W9uS1J#h0_K~{!gn8ce_d95T44#UxKD}
zuk2(geTQgEITA5;HgQcKKbIF#s&rqzE1u8a=bT1v=31}ak4W+V$~%y!neH7!M8VI~
z{%m@r`cO|-IqpNQtY&6wP3gnYY{aG?!F2}~^w8mr%+^n8qUV?7hu$`uJFE_70~t9i
zvXOL*n;u~Sw4yaC`c5lj(tcLj(uU>r2I_4`hHlSN)wUF^<u9?HM+Dnha`^N*T&8^8
zwir<&4y)rzmm1?MHC$?oR86y_%-~f8>lPMKm!C8()g%ha(f=!R$*on|0V$msGe|qr
zI-JUXJcKqoYDyQlO1WZmYQ*q}PkXp)RJJfomF~faY#-Zu<GLbq--xZ*uy36hWF^L=
zMUP)3+P_@RE)?C&XR|V!@+Xt}zh!x4w9hdWp(XGaE0#@2sU$3Y%Rid-a902K@vU~t
zEgm?-o!UT!2=Xp3-@L5M?DkKCN?ISS)1<(`S%?77Y*BhurSKcgZ~q{cDb?%L(Qjp)
ze|2=(u=5^sN|QdeL;6eq+#YOxc;Xw(OqFLosE-ot2+v28pGC<Mi!#>FXnVLWu<%Rc
zK70;|Ejv;w#`?dKv`d4w1y+Psb0EVrwcVL=dhS^Bm`VTZRl1ML5*CbY*9;Do#^tb-
zFbLT$(`U@dSU9@b3NIVi-A?Z(N&J+L8YUTN&&l!ZfPE#0&X@ejB;sB1L=|oIT<%-J
z4>ygaW_v<4I6-6x&sLWSaX7tEOmTt|y5}Q0ANp&Z)&}J;1BF!>HCIHrZ?KpuNiY>q
zl#&Q#g$SV$2Uu-EedXif^l&}injeaPmXw@-1PAv?73Nc}yAienm#PB{5o*pqkPxOp
zLc`;~y6SnF`QBxn*`53%&HH+y+o4f#R);J`zKT#{<)Os*he4=s9&;6C2`p`qG<+4l
zrz)xJiKego2&!PcBFsS=D6-V=pJL2uvkd5%Kv7bx7jT^r{}ac}`K!y7(|wQQ2aoV?
z{yC!Qpo+f&#6;kjofpWpf`q2vCNjP_7TRg!bTDn5EsKB5t*T0ZtZ8&>Ze&XfChBwr
z3XefXc;F8v*5?6tbxItf=0-H$hm#MHwX4;i3Vh}Pq$seiDZ5B2=LU<vyUg4h1zLOA
zCCCg@{_GL1HSu<LaChI6cuV3nAM1nyOHB|BGDfG}i}(2Wt{xVC7N0ZA&U4qN#VA#q
z!pWmmsAe18I|#yKEK`@Xkd#`&(vrB=v#N_*__7U4Kcfo*G4T6V7{PX3{WHT;NV=J4
zFH~Q~@h?U+y^u0m$fMFMlqr441zw?I(jo1stb5BJhXlUZx;qx6R7Yu6z{(RuBY}}@
z_af1^HFkU2{p<9=Kbf5#>K+?B$T43;lXJUG+=NKWj>S#o>PvU+X-n-8l?Pn}xccTA
zKJAAjI^_I5-gghJFU;Z(iQaul;>A~r)o8OrXJH!0_LW>nkm@x<M?jfOaE}?P0KR`T
z%*pLpIh?odZe8(aN}W~X>)V>Qdzf?IHew|ZS{weWZM+zbc9f*%(}Nmk>!JG#;`!*-
z-(#!Q4wHT>Is#Qbh(-#d%kBkcCiRyzZ8p}?hTng-eUZ1rf0)m|_e$VQ?M$3qoJ<XE
z|9fO_WCh2<Ovpg^-vb^VdNE5I7gHxfdNCVA7gG^aV|x=*dKFIxQ$l(Tc_S-RV;6d5
zS0k7I`wvN5LvvI5|2;>+(8<=B5cqusCsPwkV;6fTLPl14VS5`_TRUe$R(57SK6-Ua
z6BmpB9@9&hTAEw90MGcpr`S6wI~W=RuOMRTW@&6H?qujmFJ$TBtYGRSY;WseZ)a-f
zLdZccX$KsbgZ+QUMd;$>YDzC-YG)4oK}H5<26jF^xc~p2JaR5|-F?u9Ft)pB*<oQ5
zX0<5-!+Q%Q#gRp#4g&*tAPxg>&^*yVK|zP;G)^cCz(v{%&_E#}PGuFi@+HGbi^$pA
zY@a{u)^eE}nLE6}vjm>rNY*;InYlZh-KH}a!VVCy7z}y?0t+C!ZzX3E&EeWHp{^uF
z;-}F>=I&)}1l<RFd7&prER8@`_$f}hvHpzA`V=FR;wz#l;n$(L_#<p`Q+%bW58jLf
zLvE3QKf`rPj#!GLiC)KOL2gllKZ8`!){vAy{=dG?DLAv}Yx7aZX2(Xyww=5&JGO1x
z)*IV)(y^0{?R0G0oXj^<HDAsAYwpfjb<WMc*!AqSf6ueF(=gR$bXXKd3~Up`it!0!
zAAcQhVpA=Yy_b}MJ(Z(+3q8#U<_}$;Sq_p$1~L|Zzt0Nph*rCh&5v!m5+!pUoDeF`
ze6T7&-`GHomK_3*S}O<>$Xv?Ygq{`ziG!*YA%)2Mi!)5OFuFH#Azt?BXw_ym*c8%c
zc1eEitfx`yHL<xO1Cx1c1--2D7>T{ZGl_D5Qmr<I2C#Ah!r}mtH>2LLFFay%i7cH=
z+Phu~rT3Svka|xJ1vMe8)C`5=z^~lEHlNSwz~kD0esEuD5+SsRnCkliMTYoyI;V<@
ztIO|tP+955;9yeYX3tDP;gqf8D;LlCx2y{24`zpw3NVx9TZB!~Ec&tN)m3m}clJMj
zNNbS_IFb>#&`hFFXg>V=f#1cZP{x>}0_ORtB`nYPCIh87%h&X*x1|Ff0$tpKMpEY`
zg3;wds4KzTDe!r>{J11&AiR)aE&R@>&W3&=t2IY<_%W5{8wo9aj|RPZum(iV497{6
zWp(ga&|A;~4}mG^=7@+OHFGpRo?P)GD`A+fuK0U;<~yv+Gr~4+C%<1?EL{n6NqKJV
z+45gYwcDX>IFilx`x4WDuGULzwy~M7vAMqJEX}KFr^8{Z|CNhtJ=SG{bMM)tk9mqu
z=C7I!^9g!W{)XO?7x<5evP<1W3w$4cjn`kI=EBTgLJ#sv9%+sD45!@zU=Uw}KLVWx
zqtI4{!bFnuwyQ^J&Heb(^Ku0URhg2pTd@=`&`AFLzV}v%)#<z<?!2!5d)|<8kS;nt
zT!~vF@PzhCNI{uXdsdm8D}LMBZMkdTWfw8m-wNyYg$<7mPut^pJ^Ns~piq51Vw$+p
z;8m{nQzmk+Mjhc%HJ(bRR_>+DzLKrey?AW4ol|JQ!V9yh5?QNWs1e82p4$?~KpnY;
zx0I<VDvRtPeA@Efl}adY*I?k$#m(TCM&pSH(zju>LhjdOFelU7wtFpY@rLJtMOlB2
z<($UZKpO;>bXLAp6b-Qc{G<6WaV$*79pUNo^pvgOlr0vHQa+=KJu`t$GJt-IlDJRR
ze(Sltroymi#g;QLJ!)|b(yB9d>?#RU>PyX?v}f3!cQG#qG$SkAE=zF1fq;IJ-q!OV
zbeAG8b2F<s8-6^Da3}5{Ayg{Y^a~E-gw&Nm&A?1d4(^Xb*>k?&pAtr9WR+*(RLVD0
zx3Vl6|Mbzpi}mVsbp6jnU^0-*`7Xv#%=ba<9OFPAVmn(|YipepmhwfR?C3YvS9z_y
zf#`^3jeH8eN9cLEmfmABw;tMqV@E@zCOfLB8aI1AMur&Jz$grU{|lFqW6Q;0X-t+Z
zEJ}djv%AXcQy3T8utwENYVMs#2)M3}j&6M_uhV`?O=KzL{rI5VN;Pc-7Jgt3W(VF^
z?NZRzaQFr{fX*!Q;=2#8$Z$QV6=z;f4$#aOG`dxkXTminbFy%rrj;YKB|qGu9F*dD
zSVT{KcWR&tL^Gv0oBM^E+4FlYgC?Wyo@Y%c=wKmJ++|X!^M0f`c@a0z=y3Apqxz3p
zPIPDPUwh)-PaOWcYPb+T(F=&scYa#pjfPalr^fmVrW&e(iGE&u21++l6F%F2#mJ4B
zm44L;wfO~aXU|it8zdi?;$f}6zt}L>SG=^;K#oPG=N&h?Wlp)Is;*V*7QZ;f;2q{&
zy0e|o8w2{I05ZOk91rK^hnbz!5>N~gaK5wT#zgD7HznR#9gVxW`HQ+ApM-Py5nK<U
zGldfT44#16v?)&?pFJ#rD&BH;gJJ@z@~5T1c?rJRhB1#fDSA=ukJGO0*@LGw9+B#<
z{a|NfLpe|4iBRvo3vHC36TRFM`hR&{p$dD$os=#dBX5wD+NLgYNLbW049M?^z^7;9
zOGJI6Q|NoTFEHp@-R|&mM7<n&9vaw{MA3d+`CkC)skB@JuZZ36j#^rrr?jAxx^IHZ
z-P9?IM=Ta^p1Zf<_;9Jt$Q^9pa&l6}C9$5;(7c#cV{)o4*|6ODY|N3YX;Q>hR~#9F
z@2)w%4gaR_0g3lc=cEK*0{ewaBZZ8cxl4f$jjy2WOniy*qa6+!p)FG;oxzYHKvQ;6
zy}e#n^q8@3U4U_!bYUdt$Y`w^j-b|3)%541BWI1a1Rp`)1@~DYLDHfGpQ(p8?aNIn
z^unKYjYLKzyAXX)bw~8X#bUD@0YtydQmkV8m(^B-5vPjN0_W?u$5NN6ov2v)Am^sF
z8!4YX<69?sXUJI;;fuIhiVM5S^nkE2b8^w<FKb^T)lc)umfY#N*^WMjZgol6N-x|$
zuxXSYuXB*g5vWImyoddAO-Yzs)Y~1=i#!uQYn2rIFV33gji{4tKPwA6#HsSqN88RB
z^rqGycee+)?8?&YS9#~F#Z&mLv*C?>a=Pw&z8G8RyjRX`z=2UYRpO0Idy3?IurJT9
ziHH)Q&z@o&f7{&Qm_kt~Uw@#QULP*jmREv#EbY%8hhYZ{!j!Z;#Tcu#upD3@0q4ue
zAN8>f#x`Tvdb<KV?Q<}EPo(HrT~on7qeE+ssu-&GG?(aP_0xXD#d#w0tvW!e-im+c
zauN!Z(UyX-1hph*Y--pR-U1mk76)iO)y|zysP0&^<loA@<~Jq62fCBQXrDqiD|gN}
z^ogJQGM1`UkAdNF{@b^TNQqq1hX23^;bEanUSJ9rQoc7=VqZ(}wK|TIDD_>J<BWWu
zJVSC99PmWLc<@j!|77PpL0g>3VW@UH6+8A9Bq;RCqUjxX*>J6uc;z~5T1xva)K4BJ
zKE6N)y#|e$<*8z(iVA_BJ<-$~5yiV}5WUw9ZfN$kupj)ZPM7DgZQy5E3Wyc}?Jce_
z+oDZw&W~AzJE?0F5!bD$?#^?j`wSVA9cu>q7odj6o-gMx&^vu<tueLJjbMYJQ$F~R
zF^V7;9Ab`5Jve#+6CgvWdgho<VvX6Yfk=qrmcE9SL~lcEq;u7oN3MZ&#ly@msLJ;5
zb+8M6FOJ%I#YOMxSXz2&qJFJ$*){}D59Y9fa5?tRO>Ebln?g;-w^w*{51rQ4Y0PRk
znLX37@Kp_Z&SkZvu=AG{CHZ_$l<6L~#yUacWdFvioYEzmF3QzgCrKr5(&NMPHc7?8
z6!W$X?MBh<{gyf?&0E?s7K$%hUnxL4CsKPAKwA?T0YC*ZylQa~-BXqo`Px%j`00pR
z)oS*ptF1_O{FEY#!^(!*F{wm{VCbHdmNH$1>{rb-s~c9Dk=W6T96#_?;nvSp3x{D7
ztZ9rhce5aFzNMji%DE^w&re?t^$xdH2eMy9U6gML>+KtOlCAjYFJop~1#TJrK=LjN
z$ifNjFW@3CXLlXOE%7`Ps%KL18$`9sNA0NGc0|G~Q4ltmE#<F%g-y>=wyt-UC2CuP
zGZ?A?<$oPqqy%PHb)DP$y`P7uIF~}kQQ^X-_B<R4%v_?`8Zu6g_;LB=tx#5eG*n<z
z<1bVS`swn6xUeoECZOX(p(Fm1YzMJZ$f56n?T>)bf4QkYJPmr%lIpX29>6QHQmt9D
zJK)aZP&{M4Xe?k6EkyxKJ}O?!@2UO^hom+n=TCghD5%lB37AXBZhvJRl{k8rb3-N2
z?1-I8eJO33*k@(>^0C%*jh4Ipit~YuT^bc#WM3i?z=>`2QHoIeYi4Fo=AX(JQ-aeU
zI{h_qTx|f{R%N_0T`1Zh$&4KHtBLOtm4pvp*vL<t6A{dO2udfx*xKKocYQ4wka>}#
zc1uK}JHW8{I~ATdjSvz`51#6*|445*NI^HgyPne;e4&YX4P6`A#@gAe+KiG4POtq>
zX<*1F&bwX=l6s|rTNVbqSb@d1y!U<vyWuV-*e@DqASAFv;DLmPXgku$=6YtT7;1&(
z{wqH~b9IhpEvR1O6OQ|j*e|a@$o4tMA$3LXI??a~du-aA;jY3Gp>3Y=PY3B|{wB>y
zhcG2YPhK=KY9_6{W>{O<u9`2>aUV*Uu5NiK^Ocp4g`oH!#WzXPNs{Zps8^@%VcFH%
z`w-r6*)R%x$2bB(upp;@;iEW+xQ8*a$Xag)9KG$P@nQgV5x05{71w1l9Zb6*k0v+y
z2WXz|M=2iV%ZQUjJ9W}`%Q0S@s4q05WOTft6j1iVao0&{A%OxC*@^|yS1v5>B#1p@
z$68aG)`a5IMUDGj1F_ks*ckQA^~|Km51`cnN;gEA&O}cbz42-V$ZcDIT1K4P{M2my
z2NU%fHHtjuIX?{k-C<-fEk>;I#JSK&gUZK`YP^^w9K8nTXYb}@y#duWq!x-FX4vN&
z-Cojr-+_ev>gsY7zn}TR-85Yhva#s_o@K}jgl}Fu33?geXfAS#D%6nfzANRa*CW5y
z!fzXGyTlutKKyaN5}FF{yW+R!N^)+KdX0Gx<DJoO@JtShj!$szBN2(Mx)OE1y}K}a
z0P~*}Bv*#h4B-ydM8YQC`F(>d!F>OI8U<}*dxZFor{i^MKKydO5QQxL!AUML9)-P<
z4r1o}#Y(L~w^_pd6wZI@;CWI=YD(8{^auu>*@6~Dhn5^mctDR(=&PU}yL(?|G#OI8
zf(<v1s?(S1E)*-SB~}!4b4fT)TXQ3MJhO9VZKMIyj@2rb2{YT^D^jH-Ybb;h1dVZD
zkAEmctm|2uGHD%aeRp6}bs6{SH1hfBc%5g-;m)n@q;u-uh?e0sGe{h_JxnxscThXx
z+L^XGE5X;syev8V5XJSyBb1Gr;axAyR1b0*@pfy9L2Wh()H%kmXDX*e;w8#<r(F>o
zH`z5}x^%qc0*qUP)x7gp%ASw^%)}$J+suMov1BD~Z2rsYA1T#G=2r}sLHk0^h_RKy
zzDSY%WUqaBi8a;?zWc+BI!K;>jMAC%-tSgo>pk&T^`WDrJOKik(4IL!11H!}2w5vY
zB>f~nm-;W`CL!STc8)9cDmw;n-NMjr%J(>n@uK#qySy|aGO#zF()Lt*Bm|c(aGpd_
zw+Fsuz>n`WRMWM8T8CYOb0Ak^0XY^9upISZS2p{XZ!v(*aDhb*Vi&I&oaAR>c%p)<
z1q5v=n24E!i`BsZ=l(kF<-4tSlPIj*4mcWM6hCk;k!e}f?cC8L|EoJ8m$WuDP|84G
z)K&^-%TEGrbPT@`0u^Ri)8>vb#n|z<2j_a3p|i$+TdIB*Bb-{;&W-b%5ny($xhFO*
z^w5doz^92}$80lRuP0Eh=EwGS^4%Df)p3fE*e>-F-;Hs#E*E$cJGZSy^w;yzO^8jL
z8l@ZvZ$>Q##fdU`t_n9TIWsC+baF?k%fk6XgrL@{i96xMw9*jey&2OL^pUAadWwBw
z>>Tb(1%{3tsZlni+lPB}2*N+}?3J7b+c7O2*?v}hJ)P^D7~61|rA=yu?S6LE)9DM6
zP5}1AE`NpeyUWOIyO7&EZCs#%&E2yLg~4BMvjz(sYREMRgZ=47X5Ek2;xt(B7F$4C
ztqYxV1^F|^IrfMyK3!9)S=ng<KR^9^{Ff&=xYg<r=-XynY8q`8;EmX(KkuKw{9^fc
z51a|gX&td(P{5h{2Nbb_O^);4Jv`DbiXwHnJD3yF>m}bQj-G*48-E$rd*NFO+rfFC
zj?;SgPI-eDCs7XDS1WG70iziBkDwIcU6ii$zEryk#456=lr5r)>P;jiz9v5&_xRKZ
z$bxn0kxX6BEc4!AUNpvo0xey0m1NBagOMvypDQXdX#0yiIkeJ{Y`yvLuts4G2Ef0x
zJ*mQW^EtfLwtJn-*|<o79oh`aVpB^rXXD!NwK!3^?&<EkC|x*K^Qf~GS2wT~ejXcd
zw><6{u(vlD@UAx~)BK$%x3z>1a*B;jU-nj4x(Dh!ZU;UtS3C}D{&u4#S}1Md3AO?_
z);Tt)El&_-p>^r%!`n%@?n1^2$E-J=u|&^(yJM*|JK?nOB69fn17r6)o~Id!&t-YV
zpdA~g5BTVp16lql3?<&6ncJ8ENq^Sm_-BSKbY$9Lhgt?Qfv0yc-kq}`Ir8La20M%m
z55wOOL(l1?F}~->c@@vWk1w0;5h@YMZ}f0@Sy?Yl-dfM;LsWdXmY`_DP)%}@zzKXh
zft2Y84+e$z5Ld{FY~R6UZkjDDt(r&vzZSxs7@p8|+`gI5`QFxFdkHMZk=x`Cd<Liw
z;qBJRR}0xCL*_$9E?YfXgF&;BFNi+vgA!}~k;&Bfvcx%iUn#LN{y~v|1jcAasFfD0
z7&rp=yP48yb-|=*Xd-f{)Pb3UYpUWEr2-0{Y`Cd{<(1?EiTBJ{ZR!4B6&<MrjO!P+
z*5Kdcq9Np$pCHuEN0dc#i+Rjs{vlW{cfrgeG^-rFq68+hdMp!b8p}~Ul&=d$*a!#v
z%Vl_xP}YS})4WLgG@T3G{fPHagyL-}%he(&h*mODVB=IveVCwj6Xc`KI)U`;tR-#5
z;=Gz1xFDBHX^!Z<tU=N>nG)!6sjOy=KOi({zbH-LN?eNo(GBQUgjO%xr3y5G-j!vh
z`%I^fGh<jqQ8wMeb8|>l`4?M8<i+>U)&12di9tDIa4OPndcE)MM4!@{?gM>{V)KA(
zBjS$V+AYzN8e?DNIdHbXL)o*c<YL&L-?g$IbyA$uDUWiKmRHvDW4>wR`Nux}4mtZV
zq^%m2mTM6&2R<KpZMpQg@;nH-!XG2cYa&SKXKX+@BKr5B$$I#EX;HTV`en}6I{knh
zlqsC+1qpwZ$JwL>^6u^aAy@<`3Fzs1Y5Xlqq1Y;`6;w6-aPAeir8CVmc2EV8diM)V
z=Ds&347kW<EZyH>!YliQwP#Qmr?HE>+kfT`Di(v<izPMSD8?Lx!1Jo9crH%hm5trg
zhLR~)#yBk0h#z`uGN<ZbbY`o|_+*Z&t(5BFHw!Gt*_gn7t%sW#`Pg4f(bFN-w5i;{
zN6Ij?`z#Dh3FgJpY2{$Y;65M9AuxHR!RMI8$EDTS@oV#9Fc&=Ul!3b9EBap7ard#-
zbA|mlak*ZPx9Izs{F<oJ`8CswIaw5NoQh$ea<(CDd*rqXp`}H_oU8Bw%{5Lnr>S*;
zzB<&WYwzKd5V)Zt&*Pm^3T0*5LGqiSVo|(F$vx^TzTa^4_nbn#BRSq$XYJ+`!%f-m
z#``j~tW0Wz-lDX$l>CkEcWVm}-r<C3W=_VS5cy~XIlfJ-DW2|sBsz$3@b}ePXl;KF
zRr`XVH{dz^6D57}tXSvd!v56t;=zjXO;Es)4I<Riyb!O{5iv)53Kx^yEg<Qa_Cqec
z!tI`C;jF9NU;2!Ea{dYqkeJ<rvw{=%a?oDt2#31{rR=<R5ULDL+e2>E84*=u(%1c=
zm#gf#Hzd67(JUMe!(-?Ftiab96lM`Wx36AMa_Y4!asTZ&$sryx_#OdE=`@`dJe#&K
zc-JxY(0;a>>bQ~xaL(18BOja7ERX%cu;7)n3KBz~oe2VWf;_V-ISu?sACRbSz<ap<
z^7fPM?WXq%Zx_DbiWNTN(P=0p6-A1%Pop?3WNBAIpoh#+h?9eVuZ3xdj0%*$gy~ZX
z(5G%D)h(~B>~y?y);_92^Z>5b(vA?kb27P@=>C4;PHt-g-cLlsyQavZM6kwVB!rlo
z-9f0d99=@hHUbkyNX_!)w{lZSrGykeldT8l9AADkh;dV9!om2BnZm^>v#2LtWzLjq
zB`6%wUGD*TyV@6)$j%5oBz+q!h5YU#XVl0J)h%n7o)j(Fx}DzaPBbp=qRfc|y<3C#
zvQh&f9kP-0t!Nw~JTW_GZuu!&m4XfqI=?dc{8XeZCf>Gs1<~_-q?c&hMDTRbYoP`R
zS4IG#Jxx$Eh+VU@&V8`2NcvVj`%J6Gv3|s;kS1u#pPZ=|>A`YUnt#mX69QV@!1zxQ
z-H=$-4cP_#0&{1<M!%wqby<x(_xY?$Dxz%sO=bgpbBOy%rwdJWUcwsc9;BpfJV3jH
zX%Kz#X>r+!{;HK^>+RmSOCrU@V+_REY1Xh8AzAa~HSDOBjnwiB1-2DvbeOou!3fdC
zdduQWt^2pp(kc2HAW#^PUh^4+(0OLx?uy$V9UOA&*rw7jaBxf?AnyN_?IcFa;UY}j
zQ`W?_8e$KvRdlm|@-BMbwzR!*SYYXeAoq08X{-ro@NL7CH5Xp9D+j~&w6w~2HVDr|
zth@3qbvQ3knz({{w)f903gY>zet3RRWLO%gnZc{!hOZH^SCQ9dh@@lS;9ECj%l<OA
zeamb2CqzPYWx)D7VgLnY$ADeWRy&7*BLw5D5{`65D;;XalARkfKVP{kWA9z@W#!Oq
zUs{@^94ge`{K<J@RY+2kpRHiM5wxf9zV>`JlbnxbIu7vDH}$cynA7&mKkr}H1k#hL
z!VY9)_1R`XC3S>DPE}r2y+PUndD7zFE*#1hzko~Yb7&dU0)E+U0(qe=tAIbEEIi%v
z)c&y{Tk*AVYRHFbz=nvHr?}l#?R6kXA!zfPja}voiZuSVNA*i7y_sP0;nZFOw_kL$
z=hEuGx;zwwIui!IpxR!Wx|IcG0Tb@u20dZxe|D+uF*+c7%JCDiCmqCe=~KPiKa;4A
zQ1(6+ml8@@jkO{BBJjQr3oAm5^jnLpe%`Ll%gp#(z`Za!`dZ|gfwh}P3?32CwcGi6
zLq$FuEwyB2U9h0MOt1KiCvo8V#%Y?rZBTsBX7QaJ0CMfE3Ugl2bw-0m^I|tr2uZ3I
zj|0fjPd5e{RGUsYB&f&1?IG4k{c)2qqE6cZtsit`OBAPp@<>04NOVEa^Vkfu-xYG+
zJU(ZC((`0qEX(-Kmu$bA60{Ox6NXGs>&$YTI>9`C$X>p9wy$Rt15PXaKW6Ys*n;X#
z*cWJ_efM=2>5afWAb5$M3GV=Y-W5O#6m<K|#P;z_5Qn(1&sz1k4YsyiM5=CcavVhP
zIO_dC%F#vE0o^ly65*r8q5I#)cswT1l|Bcz?R+&34&-5YLJ1+eCs0v(L)22W-i~Oa
z5`Cq$e%w~Z4>-!Gd>(Q_X@!4Yh;d(}<Km%`(2f30k*Yv_2DW}-V#3qn7lQ?&moxC8
zSTeBqyN`w$_Ra#VHlyOb{~Bt9!SF&j^%lv3k2!}?Ja8hBjhe{V&<MGpCwxSxCr;lQ
zfmid>jD}$;ACi3C0p(BgCx|&8?6Lmx5&c8q%E@*3TzBu0P9c08hGr+PGgC;b)!@j|
zKW{y`UnzB+X5lx!q?)LvGT3u=&g$;1X7i%RM^DstZ&Xl2=Fa6PrUA}c{SeVAJAP-t
zeAu_>@ZV<>w4J<yKMO3K>%V=XI{v)xA-5vT!ZBOGCXQzyD4UvgriWpl5V8rKE-C?s
z2O2){>rr!ZLc~N`$Q})jOut9W>BEL2OZlem$|uAs>Vw7qqwyA#7nBa!j2lV<alw91
zLrNp3NeLpQZ@+gB1Kp<>A!sU51iXQ<g>8v|*V_hqiQB~$PGG(fB2Wmxk?6xfhuI#V
zVDz5C1rU-;fG6dVpTRaI3;4ugkrD4_&hpZ{AqgXS*^s;bN;O=T4{X~AmMP9U^hL?6
z@9Y&cq{j{1FYGz~S*9ClIiIa+%e=m}zg7@$w*=<{{U^=*j~+|6h+e%M9Y%*r6gGlZ
z5V}^l$?7$dxAw&gP-<2sq4^0->vaBhCXe(4oG5rA@1j|wg&>V8Jnw-<I^XLC>>1En
zrLWWPy3UwEKfGe!+05g#7sf-BtD06_c_8|?#`^577jxPut^)9b{8NbI7|!<;^mBRz
zUcn}$f6c4S<y<i_=~|`GZYjRK5y)X3wHth|g!FHuJhX{H&~L&e8Ey>;GLHxLw=PO<
zwRe31uS$bsRw1}Wg{q9WS8oa4W5_*5GkHczhdKvp9aTL=E;X~-i+vr-Lgu+I2VuoZ
z1aA2d7!N`o6y;;NLYby3`&y|!&@fg~y)GAjRmlRu3<XB(Bwe5_?5-prr@I<Dm3bIc
zc|GN3a1lNvw+{Si8O1IMp6y9}_s$`3MK5PdCi63cURI|zToC~j{Kn?D)s<bILY<hN
zMRayYQ_Of6>6@jclI)yx<RpmVV7C*0Kon{=(IIn;*Bg(}M&MWItSAA08^)m#=dA?a
zYD_?VlHZfd?rl54_OPtUsZ;}x9WAk37CD|fYA*TSV@=;eSaK*8q4!9??%`4*jg{~A
z24Vp(S8Uve5!z+J&&3b+OM^Nqm+lEcfvXaPz|o#YGEdc&pJR{&F4v%|Bf`oRoPQGf
z<$=sp^GG|kT2e#ktqXAkkNmDK9#)Lwn?%v4{FFldhUA+>A8QgjkIu7j^YG6OK9KJX
zZ-}G~Eg6VY<>OA?L*;JUF<fRW4)chVYQ%AuwqA2RVTk2;N2|?{40g+HgvV9ORFoc3
zxt{K)qNXu(ZAlSdRUwBc-}l`~LE=Wj*<QlosQvXQHHl-fTcNIcG1C_a>fvw>8ogmY
zR!!}0*d>A#7~-I<^8I#Z+h)_fs`t}vvLB7Y=e-JUyaCVA>+b<q%};A#^=bh3fypVh
zYDowEb=*N1mn+8L=*%|SQ<M|z->5AoIEHL-V70&^#ZVfig%HSl83Y(3L_v+A1%979
z0h?}P%Xyt6!7R#Qo04-4M?=a_FY>=6@2!EO;ztxzxKh@^bdebh0ykM-8U+M8r`=0Z
zB!{TwNc&rf4wgI$(vXS{>o%$XZoDK8jymtir1sjcI^PAxoDQK0AM&7;Xy4{#feBRM
z(KOamVia_@q)y}~csUd6F0mo+J!_>7=_H+dOr=Ebaxwj*I@&=hd&gwN$ld|(+GNo~
zy7DA8XRueuypZje9JYNI7|bpAKj4FokmkuOvw!!?9hM3%Elj@Ttmvc)F;5Ux4f!l2
z9Tc>$z!Bw&f@Bu8!gr#4J$qVk+lhg+97`jq4rIueuTCFeB%F@n{n1834vdU<l>@ZP
z%%iY&&_{gdl4}9mVQAx2!jU<soTwXT9J+Q@xOwXQd-I85r;HGv6y+m>a(K=U$+Acw
z%-A!X4itk7HlS{*M6jhnRpEZ7!XV@_^aEK{Izdqf!L5h?{OFb}M2D(VTle=s2Gt}c
zG{@Ms{4*2Zju)wH9eybd<Ug%*l9JRAY~Y(EoDLz;x|ZnT<H#FJsPjyTM9GrlYs+>p
zo6OaCldLbDL3O(}kt3{3&{TQ8#PtkhG2_l+>#gyC*82#LbraE}3)j7C8a2Z<r9;9<
z-{M%9dYFVsy<iP-kowR9(eq2z{>Z56uJ7p^V+5)pnwCuR<TsE)vBdBH8ezZ+tg7Tp
z!$y0V`#waj@9K`|3I^<TVEx|V)91ldT$dW}cOU~z79>W2=p2xgMT_X1mY7RaJ_&pK
z&9{ICIViGN4kmbm>@DG_OUy5(6&>f9XdEhfYit(fb8BygU;=F(fJy-QkoCpdI)FbM
zk?RL-eI*)5mf}oWvN^j6_)Z}jM?B(QYv&Mw-)p`9xXpiJ<zrL<YPr^%5IHy!Hq%KC
zI!)^JtC_y|yH{T-J!}uq*fr<%gjjJaB}t8BLjBRZ?c1B)a*}-{u#y*7E^W%jvi8$O
zn~*8H1{!j+(OEqxZNCX@o{-<-{xVRXo;<X|vRz0-LZRB(dF42^yIi;qrB1RS(Zn-t
z%6H-j<2C*VbY%+0kd4S125C83;&KgRBIS3_tz-?6?JeIsty43-j87rUREEw~-rCZ<
zbp`g*NWah(*nYWvDo4>RtKOBJ1E@DB8&rDV(tEi}oz2WSd-dCP#dr+5i*jW}I{j4J
zXw0WLL%u*l>(~Q6)Wj4!CtIz;5R{DO7lw4ZC%BqcsRaMxqW9#Q9bCu`#m{N0d+D{k
zRQTzK?(%pWtOVLpP`i|nRq5j@E27uFb$w`Ai<zmhoGZwvq@z@&gWOS^1+;yB`z<zU
zPyVv*H>h79ni}u7Ys1LfzYGp+9p*t{bz11nv_u3__52#&bMWfi6v#E06`yX@6+-T;
z(QzzLWe+6)<GZ#=PU<M;Qk`BqDI<a=Nd33R6>-qA98hN#$5WTNpYtWDQ}?o6LDbrq
znAn(IGk=P^_j<E$+d>6R(4vkk+SgWI6^H%q1|bQ3`C2SN#f3ipkWGP4G5JCi{O(cW
zsip7;66<B50gcD0SEpvJK`v}xq|NWPXG>YO7&S7+HjdSp4xzqwFdq!zzN}BJ+AQ3<
z?Rr?WF7u_8<D>${zF0iHVCTWa2St78TO$C{Hl*q8iw}^mGS8bCcxUVTr89<4jP3rT
zma99f+cH5}@^Av^1&{8!@LLk`P~V5&ZVxRYGVVlas`J}XD4f%eW4*l@@PVPEEAQ`R
zU60HcS4O_+E!~K^^-Al|m^HNG%K~}H#rm9+<-5e6r(tpYE74O_j9CFy6}4+H1~D{k
zcUo{KsJS~S4Ygs(vOcL;Pzza9;DOsDGzkOonB^9m>fHSdlBofEW3g~Wjru`3Xd&@3
zU9VFN{i*X4%UFX=fe2blOpanXBTSMHT&1bzBQC!9>CYQnPQRc~{<M&z|6-zl^>rxG
zljsGxx$H>IT`E~Bqk?`Nf2zn#kQ2MI$8$-)FPY?vw4~_dG+E>(j?c0(4=$Dc!auph
zL5q~TLKDo<_QP2$OYbD>0^>)=pl^#n8VzL<?;)yDnb!sR;jg-8D8bB_ee`Ap8ri}C
zFDyG9;xI4nwGeQ_A~>3*cnX$(n*(qWhK_zB&E5i}ms*KFCa$H}#Ql(g7Sx5{lPD#_
zpbh0;8$;Gpkg(*CS;SC2NOVFnDtaEC+~PV_gcLxKP1YdSNDvtvX6V}+ZxJn@AsP9{
z@B5$t%oFWfRj58t2E<R?cH2DUymJ*SVtzdX2xw8Ud6fx+4M&()!28V1H9GzZA{tn2
zyr!(%zGjOL+0`3`N{c%96Fc_>u`0J8>%40HK3Jk_qW+;AxER<HOc7L?TR~(}cW}!n
zTMy@2d`c9FbR03v&N*WYwZTzDa>`NX&Y-erU&{pPiCLzmC?Net)WQI1jcr9RL1cmE
zq=@5$Jq3zoi!FpG=l<7U=}Pl~cOOiq+*VCx{0`|Z0M4i>4m%xq%u>Sn876s?lPS02
zachNNdH_k#(HGf4db)Wjhk$1m1?>KPYf@G$<R#^xpNyOU_8q7TkQ;D}nIzBw=m6lf
z66#wXlNV>eeIe*txrobgqYNV1AGv`;a-Pj(Ld3YUSZZ<Btp6*L<F+Yay7@_j@<?aE
zfi(p5DV4G_-`Qvlyetb4j%WvnAwVzV;!+cU!`}ncinFa^;8Weet%10*k<-xXHwa?z
zKNW}^t*Mh;d81<{;D7qpT`Gkp!oGE2IJdyBlRiK32l^DdC;|fYdqF~Vhe0ol5me5P
zO?v%dGsX=HxH6-~+5?ac>~MekT%2pq@G;pl^tW>>Ur$tP&ulQ-$MvI|rZu&aM0|lS
z>TUP_2SSqV{}7V@i-!D$A(fqN803gpSihM`M<-_@=5LzuKhcx_8&hOv<mCEql;YZ=
zhK=1nanw)W9z%gO&T#EZo~T~`3)Tn+hrPy)qH1agU{j(;iex~+E?LiKjz;1iW39;f
zJQ(WWo$iULe^V?SB9zfAeNFm_Ttn!MYmAd~WF{%(+8T$yNs5eq0f2o9{isRODciX$
zut75RQBsq^`#)J_%*!<l)9Y~dVj~t{Abpj{kcZL-<068k$dxFFeglvJ6tb{}Lq!0H
zG{$txXxx%S^a(oUK|RhAbc%Wv3m6JiJGhdW4PnCYrT%=obTzyQ{CVyn9utay&qx;1
z5rv^>ne(0;z9<F(I^L-1hH|~XU!%i-rIzbau5=vTMBSk0R&5NnBq*q+!z$|G%7pJo
zIi6fPfoxT-!{~@-UzV+F-l<b-H96c(+PbK%s#6W!JUF<rF95p)6d>o#1RrNo(vRW9
zr~9Vx>_aa1xn=81e@$Fl61)Ywn4~6pJ{oBy=h$cJW5SMfNmx{zjIRFNq;ixM_jNa@
z)-rcmZKz3|-aC2m1**=Ru4i~)jdgBC<=j#~@!r;3_igOy&?8$_<P_a#OAE-+O&z7n
zzA+{(g>ON}tyaPD)IAk-(omze{7|vht^i9=Yz3DjchT_MRmPL!;CKwn{_fb4hIB{N
z_$pel07`w`xDlu3cOWqxQ2sjb5`mA`PmJKbGvn#@#qmsO&|v@kLTP?H>Wn&b!R275
zt$MtOEupQkt*S&LfdMy@Mj-ozD|+M4O_6OPyCO3uv_Ryv2K#voo7u;+3wu$Xms`jN
z56!RWH~V@}b_6l&{b0FPg25vVriZF600_TlJ7gLnj;pwxNom{MAbmtDpv|>om5uuI
zz24VD(X5%$7h7%43s}FuO~h~AF&wrq)N5xK`gK>B@t5Dx7~b(m=yU@PsHXnU?5IlX
z=xcNC;e)Cwdd$@k(jyc^J>U$+DlzT44BT^VV3Za}?yEx%elnrK&sXk6#qdyw6PAc9
zKtc$W2KtK9_G&QOk*`Kg1&V&P$X6Yew9KQ<N<)(rW2!3u7wT4F`qLf*a&;vk#1K}c
z0e*Weih}}V?5U9sS+w#<HHB&dOuA?US)y98WbBf7#x5i?Lw_u@T&$T}l>~ag&5tNQ
zK7stO3)$QBuV1lyM*>4(52^$`^b)JIzDHpWsc0!2FOJw-`^z5ZUWJa`X$Kliw@mtI
zPB*>{x9S*q=;{a7hj9JIY6~1D7`@*3%rdNmS8fLH<fLc`;!8Iw={!O9O?f7G5~4T*
zq}9G@$&xzb4gT5HZFko7g2DVv*II>)J8_{qTPO}&Ro~~)G*Py&23y?{k7lSpZ^VLg
z7C=o2m?>zq@<Z!*P0@af?|qQ>N16FOk9fLg+&|d<O5K-NmZ3EluH4$lckV1)y&&SU
z*uCLjwkM$&<dagtBE(9FdHo;oM3z&fe$F+>h+!qNoWlpmnPKBbD-uzAQM;f|G8P5E
zD8Ebo_7Tk!s!7U*e-a0*kBVIFex;9ZSA`w|_e6zO>b%piWJv9k_tam+PaJy9J`pi^
z5)Gw*0vph<1`w=CmEu+iY0)b5$FPtS<wPIdY2JTcch3k6D$w$+ht0{-I6WgM94Zcq
zU_RN3JjNsRd>j}fp~qx~e!&GssdW!yg&2SBlzp`ppX1mT-Jf3Iu8~~E=s(Yf#_;`u
zMa{;I8V12Nm<_{_#_%4Gbk&dF+qNujf;~$YNi81C<^C-7IZpODRtBD;{6KrG`IWzN
z;t4Y}MfGPB{rvjC7K7uo>`m(?9H25NccrSy^I`|oqVt<=7p&?KtZnPHb_wXJooS57
zmElZ{blSNQf5gDU{%M41S9tT+zpwR2jMR<(l>d_SOso)(?J<~*M39FOu5P~p-bF;;
z&!z3%<(an>--Q~BBT>(~d2-y4J@C{@Hmga}ORVz?)AZHRMERIrL>N!-QKTS%#Cchz
z3^uj0tD|SV)|$A7r+mg*d+B9>F<O06OuuXCLd@x7j>?;YC29E&QoDg#RjS}EZjGeH
z@`fPDLTbGQ6O8uzh>)RShMe5br`xSC)tpIBi34lALtW!L@5hLXke!d`A=*s(bXaAH
zi;#Lsdw^`R;V;#{lrEvT!v+Do2$M*uq;r@o#;)dQ9^P4Wx-Z_Ii!wS3zMm;v1UR*2
zD586H0TRzfnCtkS!<5q&{w1Q`Ksp~P9m4wWLA<#s$o5Jy(%c7AAFNQ<qpc2HqNu*g
zF+O5!H=CnBGY%h0eMU5BGtemU;`ALgx_Lc(Gw6P=EAAYh11g9&Ko+gGV43o!O?+M(
z!psD*?q*=nN7j5~b1?|{!MTH94I)?rP_(=tRYso>IJI`c!#GG(0n#jpN?>g+R7dCj
z7OQeN0EnM;+X0B|*8T~-$Oy|+V!TURMQqI{F#XnmaKr(zYgcCbKJ3NRpW1p-7kPHn
znjKtW67B;~ba~~o#Ke2$Y^_*D_Zm)S@H0QR+Fnu*YQ^}e9nwZ9l)tp|B)oh&qPo;=
z!ebpADEP~2jRjw~rJg-PwnqPnAFB&Non(E<u1I~Ny0X*0*w(@9w8P-yn`*#iUt0@J
z1(g=t`J)FC%0rc4!sBulw8En`y%I$Cdl?!0^TiXj0oolq{wonlip83k&m`Me&OS%D
z+u&{j{{#;XcK|0|Jjjq`Y_4vyk`gX1!GO?>`~&LqaDpmZu+|q=*Qf{85!0$6lJ$Z!
z*v2-<##z#1h#VBk_i?eSR{2m{kh#U@B;bnL;>b4kHyzi5t=^ScX{>TbG=i9rLMFoQ
zo&MDiu7}d-KWGv5|67avRx&aDwnrG7xD#nH60vgVFsKu0F%hv4G3ziWTX>p$ml%}n
z?3}+Vj6_P`Uz*wxG5^=&|3|Mdu`>R5xk5JyKm;{F4w==GozIDRG;dl46P1}13l2zE
z{Tb!6lJG-A_|C6<RO(=}0!Wr@LS{qG8eJEtnxtfBRAsOMT<4XSS)D(EWUmjgIoHQh
zJ~tqQO4~t};QR}7$jOF*G}`0^CExayy@Llg|8o2SmfG6id~yrZvV5fnxa@9Y`qv}u
m7+y@+!;QlE|E`FWvw@?tyQ7IIEGHuiCl@R^xtP2-?Ee63Gq!^O

literal 0
HcmV?d00001

diff --git a/e-compliance/ims/02_fuehrung/personen-rollen-mapping.md b/e-compliance/ims/02_fuehrung/personen-rollen-mapping.md
new file mode 100644
index 0000000..efeb683
--- /dev/null
+++ b/e-compliance/ims/02_fuehrung/personen-rollen-mapping.md
@@ -0,0 +1,57 @@
+<!-- docId: IMS-05-05 -->
+<!-- status: entwurf -->
+<!-- version: 0.2 -->
+<!-- owner: Patrick Motsch -->
+<!-- approver: Geschäftsführung PowerOn AG / Verwaltungsrat -->
+<!-- approvedDate: -->
+<!-- nextReview: 2027-06-11 -->
+<!-- classification: intern -->
+<!-- isoRefs: 9001:5.3; 27001:5.3 -->
+
+# Personen-Rollen-Mapping
+
+**Dokumenttyp:** Record (Zuordnung Funktion → Person)
+
+Zentrale Zuordnung **namentlicher Amtsinhaber** zu den Rollen im IMS und Organisationsreglement. Bei Wechsel wird ausschliesslich diese Tabelle angepasst.
+
+**Stand:** 2026-06-11
+
+## 1. Verwaltungsrat und operative Führung
+
+| Rolle | Code | Name | VR | Bemerkung |
+|---|---|---|---|---|
+| Geschäftsführung | GF | **Patrick Motsch** | ja | CEO, CTO |
+| Leiter Vertrieb & Support Operations | VSO | **Dominic Largo** | ja | |
+| Leiter Strategie & Kapital | SK | **Philipp Graf** | ja | |
+| Finanzen und Treuhand | FT | **Silvan Winiger** | ja | Treuhänderische & buchhalterische Leistungen (SoHa Treuhand AG) |
+| Leiter operative Koordination und Produktmarketing | OP | **Chris Winiger** | nein | PowerOn AG |
+
+Rollenbeschreibungen und Aufgaben: [organisationsreglement.md](organisationsreglement.md).
+
+## 2. Weitere Mitarbeitende PowerOn AG
+
+| Name | Funktion |
+|---|---|
+| **Stephan Schellworth** | Mitarbeitender |
+| **Ida Dittrich** | Mitarbeitende |
+
+## 3. IMS-Fachrollen
+
+| Rolle | Amtsinhaber | Kontakt |
+|---|---|---|
+| Oberste Leitung (Geschäftsführung) | Patrick Motsch | p.motsch@poweron.swiss |
+| Informationssicherheits-Beauftragter (ISB) | Patrick Motsch | p.motsch@poweron.swiss |
+| Qualitätsmanagement-Beauftragter (QMB) | Patrick Motsch | p.motsch@poweron.swiss |
+| Dokumentenlenkungs-Verantwortlicher | Patrick Motsch | p.motsch@poweron.swiss |
+| Datenschutzverantwortlicher | Patrick Motsch | p.motsch@poweron.swiss |
+| Betrieb / DevOps & Incident-Verantwortlicher | Patrick Motsch | p.motsch@poweron.swiss |
+| Drittdienst-/Lieferanten-Verantwortlicher | Patrick Motsch | p.motsch@poweron.swiss |
+| Interner Auditor | *noch zu benennen (extern)* | — |
+
+Rollenbeschreibungen: [rollen-verantwortlichkeiten.md](rollen-verantwortlichkeiten.md). Risiko-Eigner je Eintrag: [Risikoregister](../03_planung/risikoregister.md).
+
+## 4. Pflege
+
+- Änderungen nur hier; kein Duplikat in Organisationsreglement oder Rollenmatrix.
+- Bei Wechsel: Zeile ersetzen, `Stand`-Datum im Header aktualisieren, betroffene Person informieren.
+- Freigabe durch Geschäftsführung; wesentliche Änderungen im nächsten Verwaltungsrat zur Kenntnis.
diff --git a/e-compliance/ims/02_fuehrung/personen-rollen-mapping.pdf b/e-compliance/ims/02_fuehrung/personen-rollen-mapping.pdf
new file mode 100644
index 0000000000000000000000000000000000000000..85c7d335f3b4c4d6ea79f4526bd9b4f6456e0687
GIT binary patch
literal 81199
zcma&MV{j)xx9%I;#>BR5+qP}nwrwYqWMbRa#Qw*&edj&r-nzSLpW1akb=O+mPj}V&
z^7L;tnWCsT9TPnV4B2f#dMOM$AtRxKu{8`YFN3(1t*e<cA%nQBk*k@gnTdm`8H22u
zy@jhKAu}r%2R}cIi>tGlksXZZMhoslJWbo(pSt;V!Pj<%enTJ%cXmR^v5;4!*TRMA
zS7zzkT#@@Xs>TU(^qlQ;G5j8X>jtflL1QHp3xv8|=+`-$fo{av^M@z*cklh_tVh>w
zsUZUe1Nz{*2ZkT6C>P(a_bDoVS0Sdcj)!a7(A4Qj!yc}mcmMaZ$2uMsetCiZ>V!@2
z(X{!2{5&IaN0Z@ooUs~b`b-y~Kj0aYlfu@hf@Qqjxq(sa<3LO37CW3&pKtEYt%PDj
z1)iGTtg-cgyMkWeZ*gQ`g<D;4MMg`IM-UEP$MytgjV1j!W1t%?IJ?Z|+mm9nmt$_$
zmxCNqMq?!>c#M3g=x~9Fdf_1~SeybV?!<x}B%w0+X}NZd=&<-wmK3&ZUD4X^7$wpP
zA*vm&vsr0oo<UK>_h_w?u!HCD`d*X=^1%HZl-S>*iOMFFpdr#u*NC@$*#Dw~eah)t
zBxNXA<B%9VyKA7I4x`=Bg|~HNKvY(Q4n&1mfm?TxRvbS$Ob#GeZyt$jYW2iOb)b|C
zA#Uf9KsibdA(X_0?a)CJQd?Nqd`RD&D5bPCbBnk*gBOerAg5uDVZWW43VvoXIe;I9
z+d-Dw*XMrBr*nY3iFAXkw=PctSdQg@dXU8RHA;>H|Ce57czuvGk>pX)vyUTG-SEHL
zpbkQv4-j=D{JX9^6iFdu#4Yzf1#Y6)K>T0-`<PJ1=gxm&>7`A=`RB_`?Y}&ALMvx8
zyFXw#Z9mVe6Pwfb4_@z1h;jUlo6|TADUt;1cH~Jnq<<ycb0%7RqFj@<$LX&bldL`L
zMAu_cx=QX2+$ls8tKw15NJ!iT<VzD`*S>&7JI5op6Hw3Sf460|oVRa7Cw&JyZ(WB<
z3S1Dh@sRzMn;yH8k0k6Opa{OSx8;~Cxr1E8LmepRmi@PX<BKtgpV|85;Gat6HX>@3
zd)t=B122w%y@xPZ);Z_Dr18Jx`@bUy1WRLL*Lq~Y1Q2^&)tnfx-~*D4BEp$4SbOU*
zZEJ(IS;@*jdH`7yF+GN35=p7Bu`&ZB)1cl1H2*1*2l6PReJL;*38j_MpLz-Hbsc1f
zECD;<e)gR80YgpWhT*SHjDG3=)L^nsQSEs9(m|}-?0aAacQ7EQsEb3#Eh)*?Ef<O#
z`yhLQ=}LXW^0S>V6bhwOq_k6<TL+xs^=nEh^+40Lo|5!nD;sH+p=~ik;PbAl@9Wk%
zy`0rYpI`pRcc0gPJ|7giomLlxK4}bq_w8gB?(~(!@Cip>yVrz6?>BRsaZ)hH5OC#e
z4z9B0CBuoz%}s#W>PW6v{*G{yL|m5|H?`_kNWBALz1tVKBgP98cW&>1qX!L1DyDd+
zo7MPe@%k|(P);jmRl-b++et~|@2-Vfcl(^aE;ffU)k|rf32R<!audQS<+TpPC{fAl
zF)R7WU3Unir42h_mP)DhUb|3$O{+nh4OMI0d)|2xjPlnT31P6#$av*1bW^@Ir;|IL
zYOO&vOd#k{afE3mX`EQ^OEwt`xOs#}B@kOFs&tz&Emy?Ed(4ZHhgkMLXAk8*nYE{T
z>;*t((mYq}#eQWC#dw>`E)_3M56*MqH+oj&OaZQgjJ_K0M=+MHEHU#?<8+Vt9{t>)
z!18z`xn%QaAPuzh1gp|8slIQyLsC`D*<I5po;X>FR|pAWH{}a$sAq9+V2c2AA|DSC
zl}Xkq;bY?%iHIP&)pZ4X8gjz$_6{1k(FFVGc=~;E3XEbH<&BZ#!I?|P>YThl*-MKt
z<Un)COd_Fign2D;CwC&u+$e8RvwPJ#<p|3pXNimXSea6iz?3bI!U=f<?D7uN)q5@p
zik`x1^^L)~Mr3_`Z);haQ6eT-np(@nIq62uX<E^9A=7B{<IyjH(nJWwvkeV<VDyPn
z_(Js-4PIclq$7;})!v&>u|-m-5OwR{b5GZ?skV5gyMSD>>n&?7eZ|w0W<wKhC`+|=
zle<4+P;bIg;YWe}=|!J&-ci5vvspF&ZhizW^h6wuTi1#o++F@4*ceBAH$>F11jdVn
z>EGs55eIRdMW9EYq!GoB*yc61+SaR8%qJ>UqWUkXjdSV}x}w0THxOWimUbkbY+mAY
zB+`*3Iz4<^?m$(fH_o>&&3<f)4x(kWTAPJkApdI0*Z6&b*0-unXvuTqrQ($W>`KQL
z%X{pW`XVPEF%8lsfI}GLZ*0Y-n|~qmgnmhJ-(&A7?rXKD&3F-7BB|C}*G45&pDVA=
zvfH7J^XWBEDa0=1Cgc<1IG>+-lLx`3+~$v&xOz-H*}agRtqx@(mFbR9wiM?wX<wvc
zLPGM~p=jTNOcm@!vSHn?+CjQ=3~$+Nm3MKUYwh%FB?DB4$aG#jyk}}qHNz#nVbyws
zsaij0Mi{l2yYBwrK|@<-_CO2ZS!|Z9df99}(wm6`+EJO3mGi`(bzD9|d+llBE6@H-
zsaZ&C&?EWhPxkJE?h+>9oy1DJ*N(6be6yMFBe99~Q%-797fE=@$T1(w6^6Dvr>9Qs
zaGG}2Q$x(&38tFP)bs!y#-Mv~%r3Jn^oNU*&bvP-By0ntlDSivj2ju-b3^^bY%3$J
zE#veT`IIiIne9`dBYUMp(TuMnJM74~-F=Uu4<$+5+PiN_9OH3K8#8_!6s)H$FA395
z$Vm%7c-9=%b*L6i;~TsVm(}#uE!_}!(_h%O4d;s-$`w#y{BEYHZLp9|==QIr!;Xfw
z39Eth{44}GZM)G_)|)L83gti7gq+Z7*U{GYPAm==R8T@1Fez_4_l<Z+IqHmleG5iO
z=V*GJ(tdH6=O`V=!7rLV95s@#p_?6OZDY`m_dO*{nvSnuFbwXVEi`KV^_Von6nTLq
z)<v{@@(d(8M~AR~2^Nvk=<(WU#&h*^LoEJsQy9_^W-SRPSR~<A1iTRl1iakracXAY
z70xX=&=7{Yy{5ojyyua{g2A^La6=7cXjO3BVTOB<B29D7YrRunLRc+wAV8!A69wkq
z-i5*_Q^|b(ro4F75##-q8p8_-76th`2Z8L(_%Sv39R691a-b;P*p3+8r*#;9R@i(m
zbx5Bu<4S-|xPVEA#PGYayT_^<4;AD{8yrr>;lwkf`;Q_v0)UhMdRzk26tAU2md?i2
z65-s@WMH2JMzag3z_A6IT;BzkU%xefY-ERQ1}e2JRdSK-wqWHcKDUe?sZ6}RuqP%j
zlm#Yn^d;C_Tqq4y`-B8BF-1w$r>8DK51Jeejkxitmp{YxU8EZkwe!T^JzFW|j7=%P
z`-=eeBE}xZ%-;0>^>Y7a|FM5u|93W!nVI>&+Q1&%b^8PMTRnrK6A&{`f_~$m>t~2g
zyN%|U;?t0W;SUtd@#mtxT_Uk)ktBCg8TrPIag$j;$M8lig}oOUh##$q$d*~l^_zrk
z7l|mPz3n^lz=EzEJd)<0M~5-*pN}_{lU-JMB$29ya*J4(;><<$rviemglz$a8cx@?
z+s*P?x}spI3Ll!t9~rm0G$L)R1J#>QLTMNwIpY>6A{Tsr_>iy-C&;ZVvREs7(SXZX
zc~RuoDj;02QB|bR15Co*N@6ngp@g#w+<Bf9aqGaCVw}RT7#jiuU7CfBAxt47QZ54Y
zeRX6KG?T!gD14`Gt%3#s>jX~^6<C3k7qYN(=6oy`5Oa7#W?86`38g_%zw_TI#$=dD
zirl2&D3GbZeR*yZjmrAmN9Nd45a&FTVfds7y|Gy<04;j_%aa_o*aIblu%(#N=wN)8
zX3$Y-hEa1dlo8RGUd`Ztl+G#lrIGDBQgk2}cn4)xID{!l?C^yC*PdZS;SEmTV<r7i
zMaYD}JgwEPF^C10lzZY(@lV2<T2M>!Gc&9>q(M#Gv3c2lQaDPcbuCFVrQJ|P=wi>-
zxa<E3YX1wiCe4ucz=6&%7#tn%X!hS+<QVjYoE`VM4>|KLfb+Wb=?#|1U3wZ9^d?H>
ztTki?tFs8{uwYVE!`cwNdfTAO-u5<UOXX-9)jr8;$4xhE6WAKk3>SBVIT%t6gWy`z
z!J1N3=Ws;=a5Z6A2F`2E|B|cY*s!IT2e|Mqu-3Gx50v)Q*8Lm6v~2iLP3gpRxH1QD
z*I*j@H)_omO4V?z>0-?L{;d_YHKf|yfm~&=LZyi_Yukh*v$+X@>fO->M=b?-liL}G
zwPefAe?-F=U!ZD(`BV4*3SvSB>$?n9x0bowBH2KVsb<-r731`U48OVNPM^I{dXXe+
z5T+{m=rZwm_};7w=<ErJkAWhhZ28(Q`nZ5ElN}nNECV|HxQ&284C&iaq9)V5)!tG0
zji&qS8u702HoNDmtM8-X<Cwl+#w5rVLy}t<-a;E4Bq~a<*qE6SiwY(sXEnHV?3j=q
zsc^FYXk^C+8S*ZKnmW3cTs3WS+gk3)DRDyOJ{6P<k)`C`KhjA4BQSp_w-qXuUtE*M
zvwr;L_F;$sKE{#urBEYrP`ph{15B@HhyA=8cc-F|XIIQOZ@bE<$8}uY(E;0;t-ML#
zAWS%pumQ^!jj~#(vHzd^I4t_5RlTSMud<V(F_g}7DcF0ok({SPge_(dmZO`m1HsLc
zXz(S~EN7Ccl*L%0WY7_@5*t*?5`w78`01}$seV$$PJ+A)X9jNG`KECt>hN89$e@V0
z_#MQzi@Q0l+7(NiisfJWn^wy5_nM?8lbSlk3vA5ar=scbcwj|U0C<~K&WS0aQ#guc
z9NVkX=ph@PiGn<|su{U0Abb<(Y%Kom6FjKexFc$_Bu9rd?~q10b8h{9CKow`NM?~a
z&WdDTmlM@r`s-Z5*;eZ;mBZ`0JEIr_;zjrX=T#<Oy5*JdI<D^4J+bBBQV5`G%ZSnb
zi!o1Ih-8zkc}}n*S6V*$7cU}}zxk%;f8A%Mt6Da<g3u#Y-3yCq8_Va#9g6o}%*e?g
zJtOWxogbrYrQ0<;vOC-}G+aE*Dx|!BPYvaGj^{dw5Wvl<fEp%-ym^JBZ`s@L`n?`)
z7r4C;tUc5;aoAM;Y4{+Z01e-V+OEha>F%vlt9nN~Op1!EfJpV>CkiUpmWsMZZK0)<
z{7D5fpIa0$P!(P_iBaw_Nl#%ilMRmm<nZQV+Zm<4uw+3HSp8ICnbAqIVb2m4LxtQK
z+;tRJqZa!t>UV?kr;7|ovK$9@n_j2tqEN&pHT5LVf`?9?p$^9$I9dj!P`EEn2Yx`Z
zmTvIID(D=>^pxe2{*|m=N*1)KVunEfgH~P>9aB?FXA0e-KFi^L?EGyC=?+qCo_mRP
zD1^+B2&%lOUzk31V!nm)-Kfo-ZX7iwPhujXWpdYpCh%hE1BMlYE0csz`@#pTQRwPD
zjjP%(av|pYju7WV#V9{>%PEO))sQ%PB`H7JtAdVDfE{}^;D->AeuO@4+e^Z_csx%6
zY2MW~J<4xLo5S79Um6+`fLNJ|@7%bbLLSBazMvIBY*fHw4<8g6VX2{vbRMfTO&}l=
z3q{n?51;_zA+9ilQfgjV7EDvW<^fa3kz}&|a)E$jPb3D8&7{g%As%3MOjsTVRLlwx
ztEklfoQi4lFb@gFoy7xcMpc0E)x@V8owA>|#}s%J_tDT~7gjkEd&p8EVO09m=jj{s
zsSMZw6n?`-6YqPV2&cNf_SkzXaqfcyz7Ka_Hw65jx@}nBnHvLUBa9<!R+tff28z5|
z4pv+<<t5<_io-ts1#_O|Qh9ShxF^z`wEAY(g)5_l_=6+eZe|J`>5jf2(+_(-)sk3H
z(pE(wGGfB{+zqx+UghtW)KG2Hk-XWRQYx)9a~mP8<QeW;6My(J<aL4vU2lz)OeXIx
zGHhiyad>5KrhZ5BGy|$8(8}Gpn9ENd4qAg-tCqGkhCrP`B6P|t-CvQx?SDW?nk$N)
z2L+OHcoXY$X+}@3&sNZm`reaAi!F$vp1Ny#ATF4TGwS6p2fXIBSuXkpL9j@9g&q|M
z9x~(^KdVA<g*%S_0(Fyy?o{FnhAT8YJ;~iIW66p@$$w@g*6pbxpM|2WVBWRHrW~c)
zm~g%qLnV`4Lq5qZqgaRwBhd*O>SgA}+j*N*V)B-0=6Af^M#d~GftMpl%W<>d$ta$`
z>wa<C$%^DnNpfm!BKEjaZ%unx5bJYuDEEq@j}g9<*&3a~t`Y`d9n<r63l=%F;|R!W
zjN-#dNcRIBl@Dli2L;!Vx>-H8RKbd4x#}g_r<~fzXwmPIzB86&3@WTXcsTa_{`>PB
z5S}7(_1`@Y(|<8N|C@6$5wbJ0F#k^=jFpLv^}jlx8BQxzRf$eDk27)P(xNV8;Ir1E
z9AL0gEnTD`;zp{Nz`$r$o=NsV@!UvUn8+zZw2Z>y1<VkcEo6`=<KhJ_7Otck@>wTW
zG?VG}VY|{U@7~UB!YtC8ZjO^L&$iC%+M{ZRYKJQNP-J0sOK@YQ!N*9eBwIAx@I*hp
z*z~cv`#YLe9sgfMxe#A9xhQ&EFD>KPM9<KV3h1ZQQ%PX(ps!@}ZB&$hW>>jw5{QNa
zf)m~BjPmJU-V`wW7+>&~`h~Hutmy86eU(qUFw#}&I()XSNlpvIBBAN&rxvQ_JbmMl
zJdj4w$U4c6EP15EpTPn(QV-S6*3|VOAN3XerQOK98Xy;cV2P}L-Le*U*ECL^2K5Ge
zP1b=Ztq+r&q<_uakA5Z%DA4_)L-KpxhH)?7<$+dn5+{*D<GAku;*kxkK=d6UG9`z>
zbYR4ZBZ$I<w1CK$8yqJu1@Gw){CeXB^-KTCJrm|_1bEzQ3!YiNHx?B6j;;h-(2o2P
zAwU4E7saGlgwi0<dG}_J8rO1y6)@g`c`H5S1)DN2ASF+WKKA)%va3R0?EE@)NwXwS
zrCY*QT<&W)zIWI=V1RDH{*7>s0enK&EXRs$mgA-C5WWd~&?RbD3B9pt#Gj`irZeL*
zGarvVoMp`#%|UqgBZ?2;!ns`;-~jKPxP=Gzmw>*~v3v-uVcZeiG`3I$J&;pODP;f4
zwW6hY1AC!sXbaj*7u08T?6z|Hvo7NGiTIp{NxNj~rrdNTjU1s}r4VfAq=+_-`&J@F
z2_h%4KnXk}+@yp|Em2ou9mo^>C|+V1aWL;02qTsRgdUTuNd31cta2Yc^=>6V#ksKN
zEzIGoB7w~rZPGI}=D8%F=;)##je-*^W52B^cLcHUv?1Tga4SoaJjKeGKkz;j9zz;M
z=ZWSB<RjB%Z@*)Ci)Tx~6Z;05ELvfY<KgO)E(tBVpi;V7=P~It94l7i@;N|#^v4_;
zlumu0`<Sjg?YcTol&Z>f%L&h&(2vzU@akY_Eoj!t=vwZQk+BI8PH3i}ME#GdwCH}I
z;3^?qHMt*;0L@73%`Vq6K?SxRLtR-tQeQhV5bOe~OlnZ8P>@g%@VE7{X3`qnyxIjt
zhLo5wG6jkY$s<nA$_Ig`{G^NmO*5efUj4|3gT8D*5!qb%6qCYx8^CB6zkr*EjKyJq
zAop6o!-Mt2)crICj7>4i=<?uK(BzFE0!N4Lg+(zDLNX!>tWmT7v!EPp1g3JFTV9Y|
z4K<2IpMDY=)`fBdDIGWUZZg&{8G6-#&YHqDbKDM>Cls%!RZ3VHn<>n0qOKW?nRuzG
znS1Rf3wb-IuQ%zjKWrxxLz_!1gwIaMf&rX|Vx_5+p!Mp-X;q|}!C5#%LdS6*7PE;F
zhkP|&qrJ6rzVf|BqkxLx<Ue7rkq*w*^G$2bu!R&8X1{GN`?VM9z9~|Uv55x#pzd_x
zQUzaV(Q2Aaw7x~|2VjP>teumxVkx|JJ0dL-Q+zA@@k$uCfTm~a>2X)qgMPe#(aUzR
z!m0Dmg~8rW(lm>oU|~u({#L5hh+17&s?EqwFNnBdn?0<4JMHX@Fdect3|{j|@a~(B
zje7d6gxl%x4Vm|-`-R=O=69L+4;U%Pt=?~4@9JnVZizXE60rMti%v4`%nPN%;W9ax
zujwLMqjQ@O6hLFUvbuUAS11!k!7Ec=9zAzw+h+`iUlVblcZDVi>{9F|d3U3Im{f;!
z_#bXAKw|WLRVZj<wlT&3dzd9~?7`j6)cP<dh^a5_kT6X2e9Wk7Br15~joX5*r%T&1
zWNZ#T$5<+59l{$`MiSm)jCSzZ9Ie+l3B9qXTikFw8oyjPfQii@BGBifJ7?dxD!(N5
z_T}ntXQN*14L+TM*4U{C*xT@=IM~4dwGG*>1D75GQ%Ir;>x}zaV9c6eYrf567!Se>
zC#UvcAK!*|rYS@P`ZE-S2Z9Jd*9Nyp*E2VPZG;4`SINruGMzi)DZRSwh=<o0NN?6Z
z%$_Pj=WDxhpYajMb@H|6%vo^6$9&uw?RY40Fo34kf4*coqxf3*&J%=hq~Hhl&EoUq
zb3frR5Lf1R545N6k1ex;pkewPPR3iylN!N=H(*IJC8P2h_rSqmiVIJ8qRBE*m|*R6
z#vJz!6p&^C(W^?m3TESYE%{oQGr|Z(;{w`29;78?Bg$aid%1I@9o0LOaL(Hz4glZ$
zHL~M}JyCmJSA@P|51FqTqFpKvRClF0P-?_;pSH(Ii#_(-8*AG2i0m4$D3sw>IF*Fd
zmy{>4MzdTzkqBtE<Us-xJ=^n_fWeX9hw2VrO0@qgWPSU}GnTO1xwGRR^7c9Ue2<!+
zB1yF_<(|aMSTPuYA}Rci`IQQj%iNCHpC$<Y3WCe_5i5NJL}b=)*1GS|;HE66^W2&R
zOJA`2va^3XT^Xp}tMaG&TYr0<IBNP9eO08fyGaBUrZ!w<dWoV7s0oe=eA*wx*ip)d
zhwNgeQWa%_<`EEXCg9speB!&(2u?9^%|MgP@(|MZWh~_An|e{j-^=nn`5V-LOHR`#
za%)%xv5W?u?oxKOxjvJN#Iw_eX_RNnWIk<m{<RWWIxql0bATFSs_er>;V9h03_&A)
zQ?<FoN;cbfK%nI|MbI5nwx%!J+p5!QYu22w3g&ycD0UHdD&m~r8&$`{wyZ(%F2S?m
ztsq~^ukBCtbBA8Ndjb}lcY1T2V(@oc^I=;Ut_pWC1*ib7F@`WYD>k8lm3N@19R(90
z6<+W<`whE=mQpLM8oJnOsKUAiT$5K1agyY>cEXJx)WrCW`%Fl8NGuwCVMu}U9E2}V
zYN)UD_2>W+&AxNg-GNjp>>sEMilSoIq}<VyOf5vJ9EXkuygp&dl6hS(OI;y^jDj)C
z;;sMHd|^v_aVmbTwGp{q`StMZQPJD-cF-Q$xMrG*?K#IrNk?p-y)v5Ian|D^<1NC&
z)#WdjtCAQZW_lR)9t+<fZx2&3Y?U&hrqidC4Vb9%KPOz}oz%l~Y!j<zqDavI_GvX7
z>rWLohs0&JoJ`Es$U7w(o@Y9FwQ2ocSbk7n#W<`57w~HjdrS%tj_+Wn=n1>yL^9|-
zna}F!5)7aU^rIfX7Bs1)8dU563Gt+6f5KFR;K=_p%tJM3wtX86^~Fy2=6`#5IfSJB
zX*gkb*>zBNR?+d8%4IG<^sdKo0gT(<0PRi$YH{?pDPtRsLgrf__VT1U$V<G7Bv>?y
z*q(DW!0=$%`Vps}pWDDXUuYkfn!vaAudErtnv^g&#L)27_xau6_Y=Upvh{bQ?vJJF
zfv?dVVKzt)L|@5@+st(jmw@yIBz)GFL&^9A47U;w*<4cVX@-aEC3ACdVjYkc<oPIY
z=s^nSAEKP;uV976WY8lb)`7vt1<SRA?hrxV%)@*GEEq7*$V#Misg&ZZv)WA-lBL}|
z$5R8VHKYt+E95nGc&466a-yOdR-dkHS+~bblgG`V)ggW~uDm+F0^h&_ji+-rMb<L3
zS*XF+a`GP2!hbtehBf(ETP5b?sm*jSWSE(J?v2sZbC!O7$sOLweVx|?$32C4Rg<ux
znwq5E-~FC$LnzpJ1aBQKNw8g3xH;EF+G<$H*7~~s)6<36{MT<6E{O)uT|!<#pAf~=
z7iq+x9thcPU*u`KGu_kTZ-rzoiq>y3Bnh~-7typ;2WD2LgWU<JNJ~wdc7-2)=JLhD
zM49kh<sH^M<#v`#lJ{>c`R#x>Z(C5s{GX}Izd#h@mbpT$!oR*_dG+Aq-{Ba@9k7`1
zo*<k(Z>Qg=O@P0HV%0#i%y>@KMO->!-|Kn+BaWpd%2p6%-eiXG=D2f593SG>IbD_o
zJdtNLQn|XPa_^(E@Njg$B;GmQ7P}^>s3smx#BDiBSspxmASKw?QNyErX@+PT-6Mn&
zWVzyGASa#ont4P6KyVAy=<^;s$mL`I+=H3j#`Qe7k9IMdAe_iaR`Lnya=J}b-41RD
z1R|vL=X-#V)11e+f4A2E%9<^<ZX+sBY@VIJhx$mFdf`Ypxu`GhXm-6=`TN)0{L-6N
zTY{d?Q<Q!Q2l1NUv%cjBAk@Dp8QozQxElTry^J7c8&9x=Y*1uBOnkKfj+aUF9^Wi?
z*I(yr;{W`+g$w+t-$I!FjfN@F;xK0%ZRo{zY(k_<zPHH%@w5;@{!<79{5L2ncuGtp
zX?t2UUN0jtjo<SlRZ5C4=TmFgzeaYC$mTeS<^`<sX1{hq(3Z##kl?%<x-;VTU{O^B
z{(=?j^GJ!EjEi*eR%xT9v#0z_%jPP-2gMxO!{Veby1cb7Ki}0vhy&c(7z@?N_Jjmc
zinOtavPaFu#u_I->9p7%91@qwgebkPw{s@Iz=&st)xHNb6B4gBb-j_o**qMj61XMk
z7U}d~mvkHox#`MFj{S7`=3lMOWcV{x4vB|q`SS6ryv<RIqYfhlJEz+UIF)*~Kpo}-
z9eEpJNbgI5QdWcTR=C-h(^A`Fu$%k!Au@lLDq#>W>nX^1nrgGG$V%)F<>Cz<J$z>m
znE+I}5P(M3BTk>}NW!T-_vBc%0@+4PtxeqlX%NEjoQjHxu{e{_eqryQP*GIFJT8un
z1p@U(T6v1G`a@+Ne6LRhO>u;zv8xJ0J2aQ{m2aDAA`zG}8+c?I=#@>St|FU}71~hh
zxI}^)BGul0>c2?W82mn7!uzrj^?{eNko_hzyelkt4~-SEX}%U}S@DDgup0m$Y_{ST
zOXFr_9vBY@UXK(mpoV2M4v=PMI@NEb7nAE_5>K!-IPa4FAlhlHz4)M3CL9Dll^h|A
z*shM5Vx-a4t>eU0Dz-K+)@Us=`<TKW)E?LhTY*DZHYDwdN~EI!4+v_JGR0~|Hfl`q
z!6FS{yZ4m=&m^Edc$T6{tY{Fj0ZrhVI^i^72E<-3pdPH94v^Bc+c^i$=-?#V%n6aY
zA<KU+X*5g3`Djp><-h=BfHKfEbH7fgb73Cnm2+k_R%sblYCq<;7!5$+Sdal~)+rSc
z&yW&Q6MTLd7%!Rxl8$v~RIm<7{Opn#(B!O0|2u|QD1CqTkiuX-0whdG0N4DqQht7P
z&Wv@Bibdu(QYCHh`Y$2<jVZ{jx}gmiBU5C-BbW`9{@4C|QBVa{9<jkrWud;5uqQ7N
zQG9CPY}L(<K^>!GOCWWkSdBr+Fvk<t`k1=I!Uwf}G31&WFuG8fMAc%(K+5p9fVNmE
z5ks^PMVLc`L@|)EMxi(Vm+Jbe;M}y3ZZKdygZfd8`h##q1^o6!HtSQr$2xx6Mj!_)
z`rJafHb)YOn*_V*m-!k-lMvF|bYdS*9+81@bY}_(c|O1uI5;SWwkITz1eP3_7gKZ~
zU%w@Jw%A-8AOmYAEO<eh(i0$#jqf4N)YjhIzm=|$y+Ncn7OtL}>P<CRO%vUNwn%f2
z;Z3#gs#aEn-f7D)!f;Z2-$)~i^aIk*bgJ^-X#_Ll|KEc7|7Zjk6DRBcL?hTZSvmhJ
zjkw~5Rz(|YRomuciHwG01i-MsO}9&68#xMvz}gc6f+O4OZz63Qe^cf}!%|l&DfNRd
zA&apFA68kiA|q#Dkz6xGMP*wW=SRV)JUBeTN#7?2?7aQt1$@7qcr57YskL3JzwC6f
z!4E<e{juaSPFfwlL){W35mP~G`~vpo@R@z>C!*e8yoNF|uw;OXhK|fpejkwv4fQGf
zN~jME<y-=t0Q#nHmK!Qo5#izU{emMhQ3)lD7!m;qHt_Hs>BqwJfQg8=hfyK~GzGTm
zdCD43uF>@P2eShX{Ui0!(2!`PZ-phB(TT{($O*|16a)zd+FAN#OoUND*S3R!LJy~?
z1R8*uh*Ii4%t=gLAOO3gbkdSbPZA^j3VdM_s_aS}KbR!<1oWru=V?j|B%*bVb!lH#
zUu!fAdK%*0af!FctUPzOkN-Y)WXp;i#Qysa)u~PLXkUtFNO~1i!EkydGW=zf8^k_!
zd;l*Q7z;)KtqQa$W6-p!NNHkDYRC=C6|TQ!AFA%2%e!cji{>c(Qir)kxT8si6IY!S
z1S(I&IU+-j>`piVClTNc?VHFT;16Ur-v#;!Y}qBOCvoBoZHcjk2*3w#L)_x?vW6ZX
zQk*Mf1k#Z?`A&*Yg4ZU!U9bw$ZvYU(gmr=KOtsf3g*kFY2R-9wdTjKoFafAB@C9|O
za7RN5>%goH0%^iL0x~&<fi|U@F=(e9g#rW~F);zTARhD)iI_|Fjtbz}$BGGIJctIO
zZ?DCF;6{tYX@dOmuOfVSYvH{ogYK9Z=Mdi22YnO(Qc!Lj`4GZ>KU!nlbnlq-lLYS^
z2B~8L7Z%xy(*`rZ*n0Cn#ZypUKTifdhI9o#1{uhgLn#TBNZfm^ffUC!2z;U5Si`~y
z+RCMYYm9JQMM;*-qP1C;?Dry0l;CAW+ma#t;wK9nm2rC1Er}bG?AHc$i+4_{!1#Pf
z=3FAfc`&KIhU!4kKNnh^bw4R6rLe*(u4J9Qdh(ms5oCxW_^Q)UKL<N^yY1#8Qej_-
z>C~zT^u;-AP&y_Ix{-(?UQq_jC7EWjL?u=Xmx}J(U0FTjy?e4;KJ=L~C-;S^F3VeT
z*X8}1jIxR3l^D&?a)pnmvqv(2Zze4UcSYTcv5VD+<4z???8RHf4`PpT#c<NF*s%C+
zOhHG=ROBl{^6XvT7uE*XuqUTI%=QXWPXjtiT`4d8HQc{)CI^0&j}CtBoMAtwG&~Fn
z(Y6HHyDbQPiWKduRXGt{lxa>?jtr?9kPInW(iBat$dnB!D8`InI%*Y-jjX~N5?81p
zDO#;&pPD7smDD0aM%iy@`Q`GB77Fnz!etS)@^M6JQpjmDIk^Ps$M6q_N9WyWy4kV|
z3v01A?{B6f4LI08wkB$9awe2^hkGrUolpLFn7ELKCS-LQetT|KeYM1UZeA8oxXgym
z*HDIdvcLxEjB_>wBO|KtRH+FgqeW4TB1Zr5d|kFEqt-hFy#?CWOE54=IicHFsdiDv
zEO-xHLpmdH%$!Q{%v1&zGqW<IVlr#i^6UrF!8FrW?<tUAAvHz3D|z48U-n<sX`!2&
zkQuayfE@ShMqwi|2~~}!jtWyOb#+!Qu)NQ{V*I7L(CisESR&D{8|XSh@sC}Fi?g^$
zWDTdCMJV74$U7|!kRUqNd;fBilaph0KkYRM2X&aI8K91(;XvBO4<^{r7L?5``-n${
zodw$U1Inqw*29%yG0Zk#a#86-FjmpTO>$IUirb!8jxr%}NcB(B*3`*LQqt;RHJRi+
zhB&UDDgqyi{1b-cEZ_8G(w$=Kb%%;DmNZA=925eH<gXJ1Gftio6DFKQ5?OAnZKLZj
zy><VBh|=-6fXyC3p|1^8UqVQO3|zyu7AIP+2x{8pr5JbH3W^0tKy9hQrun!}&{wsU
zF=zl?&F<@UKUkIez@7Z8Wy4uj60%6o|6ymfUW{Kpo@pzv_C;K}nLxynemX4inbrb{
z114<RNS+)=MXK8EX<aNH7JZC5Y=tSn$tkWhQ!~q=_JD1gg{E*JA%UT_HdR2Z(2a(H
z*KY{&{W;RY(_i<~*-1jjF2f*`l{TM`zO+5Ni!oXrfOUs!{WjgkzCUN$jv?eZmIZe!
zO!`xZ+Axh=Jxm>?I~~oWQZr-jZr|xx6wbL1?z4_+r}CVv9BvZbti-qosxAxC{UYQD
zGC*9<(#a`|Y_=NvTiiZoxZHY@x7Cv&C(({?#Sd^uNwBIF6l>$B8RtH+d?|65lULol
zy0!S5Z&fa4S0z2)Jut@zg=^Sk{Pe^l1S5I(Pu;f@Rem&!<I#F_c&pC?!ZepwW6SU8
z>r$4$1pNL8^yEcd+`gAf4;Ybo6Z?gru=r2Fc>C#C#T;*3^n{L#e~(|zr#4n5E_!|w
zH7jkv@F6@)BQ+~c`jv&x(<V+w*U`ZBJlz*W{#@NEQS4leK#WDWMV&5EYQ}c?!y2H&
z;Vl{zecW({&vWx^x3{qbd(24sH(Dify#@KPolejuC;}r|MZ+{yX42VFXrBB?uH{fM
z>_vdA!biuYBJ5&22UA%mGf5NL9HU%}o58c1ZpJmg(%NY?<k}<2JsanZ$Kl%E;${66
z#q14bVYZPXoh3<zN?^R`l871##<ljXn7h1+%BKIVl=#gRZ|sCmrU(D7>FxV7^i}U%
zq1dpFtBND4T&SNefkxGiS6hp6wPuf?H3iF<QEc8;x(O+Ud9JiIB(U80gx%GpC7OB;
zQ5L9#NJ`|a26cUykWwKEYPimk_Bme#aq*|w=VkI<>lnM{%f-PdYJp3lWp;k@bPmT|
zxrSyWs9!?0ehTP6pjSP9;lvWMc&qifXVXp254ex2BcE<Om8R90cAeGarD6aKjU*AI
zE9BvRtF6%Un!jv$ZMFb|Z+lbebvv#;eKcI{@sM7g(I_i>nOccXHNHB;@OL~U__X7u
zv-|(CB7GsyJFmM8+Sahc%h<-sHn{BEgE2mhl46AXln{NQh^QpDFstc^Rig|ePFK=1
z@x8%YvS;Xt3)nd}-_#+i^tlMXnD87$#9XD<>VkMgu<*TxHblDMlOjuZyLCquk2gbj
z?=MLV3E-~u`s(*#Dyg)Tg@T{b67YFj2Wf=vGUZapI&Uow-5OweKtK2tpQfcI#1Y!g
z-AH`<P@Q}~GLpa)h9PT(d&=ytG`O%=!aSjDJF5~QLI^wWMI{w64PT3?eFX<0Hg~7i
z#7hd^pwJVrF4C0?f#rI+N;q73rsn;#M~}~W-~8K1<!JSrDZypxXO>aKpgDh}VYP3h
zDW2c<SF?`^wwID;G_RH(BD)Gm=RK%YmlC(CJk44Lp(-O`S<mzUk^xctxb$sKh`-DU
zDY>i+jqN0n#NF*+j|hdQZB%|aQ3kkMGXHf@>D#BjFg55eR(TN$-u0K)w(k|z;`AW)
zK1iHAFBp`pJ^F*o4e2#tJC1c*p}g=|F40bFAe`K^Dd1Ciyds)4AG=*<iDrE?=TLE6
z>ATUuaBCrv=Xu9w%pZA)L~b~9K`GaYa&v^_NG%U?bH0ww51Pj6W31=SCfI|xXlgA$
zlo%JhjOnabCYA2{qNVvXQH>u~fnv-_z!RB#B{WZmm*kc+;*IUxr{2lL#SySIZTZqm
z;IZvy8HoH|`jCqP=tFCf5DnUr)eDoq!*-^LHew(@yh<Zb_OeKUeW5z!m!Vbg*-e8X
zcDO)Ndwb9uOic4;COUWN*As={N<v2&-&Sjy*JrBZyO(Z2CIzEnMt|%@-~%T7ksXcj
zpgp7Y<OPzBHdj>x+}e;c?N0R7?G{lwpW#n`u*z^n^efD{wgHCx{l;u-kJ|x`4qit@
zt#W-F;rtEX046}J=k!|v6to3Sf5ut`Dl>74(J+b<>cpf%{L;NXJePA@_MDo3$j^Rz
zphvj?O`oVOQ-%}b#+K0MhM%x2At3zgTil;y#uMw>4bEdnw0BvDr~=%-tN0p%rWxYG
z+?1KAyN^Y%d{;c-G|nYIWloA;zK$X5gr7C124yKLGb}ffORRZAgqB|OxKH_Snz**X
zHur!FKwmgOt)Zf-RC#Scu#$BC!W2nJ_DG2)b*sAjb&rf^N}xybygD8LU7*rn+>$_J
zj1bJ)HnHne*R}WUBH})ao5;cIca43y>x>Jznn&iN6Q2TUBaqn!idZ)~nlnxZ(tjB3
zY>EgdLsQ4@#xHI9(qjd-V996-!A4S;jhVa&XjC?TdYiJ!u=jk-JNok>F;ug*9%8CO
zu=h82-%4k40!b+E#G;C)_tM0HgD#48RHO+umnWuKszy4Gn~68$PoKc0+gv|O_<Y`M
zwh|XsH<mE(cGTP92$C2nhI%^E4c*gvP~PCr!5>)uDP32?@Qfcxlq)>s*2kmcdybCa
zPW$XhlCq(^JG<Q@tBzV8hGc`*J)QCf8;b-vECC`}dvr!YJ^aQ~TgTxe+7z~n#$)f_
zs!Dzm_zLpY@{+zFyub{)cm!#0x#8YyCi3r&)lv*X8ga*03_zg#42}mZ1f(JDGn=(A
zEPpoU{v1pXu(yUd4uI3O%U{$UIZ;vR3OEvFE`t&&G1uvFPw5IwZNX8yM1Ez4`^Cyg
zzK=k<^X0`gEH7T<-|vLr7mzemNR}v@nhEh^F15t1D?d)h_tafU`M;XU!TVt88tDhI
zni|`1l`SB)3xKe8&R=57Q>X&bCQH3DF?5r+=<Rv8`te89RvIBfC@ffRh#KK&K2dev
zbnI+d)(g0O_{*l%9mAU9zpFa44%LO1h2lFN!l+X+8$DJ*0yUHb+mKYBQ;^F#$67-V
z{f2&<QvUdLhVSF1_6^LiD6ii7)Kd#G$8hfv83o0l@~Fi%b!9l)Tw{enuIIC{jys0n
zoYmC+vCpO=0GG+kc~r6T3)8~4&cR`^7oR{@n{##14EiZW7w|Vc0p0HvPL~Yg0qBJ#
zj8twS*sXhR65^^ZN&rW*<yGYVKINU#e642iP{b!C8Bxg7yJg4as|@Tu*tY`}vmn2v
zyz1^8+`ISouixA^6!+=Gjj`{y)wtxwOoG5n9QVe_$R5VM&S#2Rb{D%EU;5h-!CDGl
z2f~S_-&X90;eklz#Bb^=bacP#(F}MR%3b@ww;-bgaptjIGalAt_i4I3ky(bWEVQ?g
z$*>WEUyIU+WMntBk_uEabX1mfyJ73gJAY!KL#>;pGG_HHJACo$6~JpXL3dGxzG-X|
zkR@%2lJBah)9>C|67vi=ZoRHh??H67dZOeUH(y4VxrD$sFh;v#n&y7TN?)3&>4(@c
z#&iLC5Ba@JsB3@2j)`>~48ACBGDAA0hqP%gtPy&s3So%rp|OghlNMD4JpIu-=F=eW
z`gn16&*bmz$oi@@bXsC;TQ}#4+s1&vXbw}3izVB+Q~_koIo6(v&*CO27XXxJG`W5c
zcNfrbm+us*<>8HznIC&_3`|H|f1>%=+4*hsCh~OsJiBi8PRGK?X-kJWC^+~;7z#Wk
zv3V}_)M8=U>g`~>b#fgMZvJd!EoRK=aY8yD3Y{ywc)@<<mkJOM{24+;mLB$ElbItW
z$k$FmJ8E%9TbrJWdw9N_r#F;-_-j!!wUl4Xd>A4ue)nPO;}4g4Z)0uUZZR`ciz2_U
z0fMcM{VP@CR?*y>vPK{exCVSi$Hhjny*4Foqe}d!(~SA$aHECeY*Uup;qX((qu>P!
zLO%%MqjRViR>FYmvg?iQwI3BFN@16xY>JR_>41b(3wL_06xq8|A9|~5_hz5Q2Cj=!
zl3q3N_{g^}6tQ0YGbjSHz+fysn$m3zGpl>V{H!b)bnNiE<bZwk6{5=`4uB@MhynJ#
zqLw#Lot3u$D~@)xU~lwWMY)@wdTEE<@|9`6fpwlqG#)|pelq!*j`oR}?avtj8<mkj
z#hNl3(d-bBN>2ab=xDorcTJhru4lbH8Q@IXq=GAeP&E9&NMZ=9&tkd4qu%Vji4Ac)
zp=H^tV|mQ^{x`Nujc$f4zEw_sZU0L9#nI^0D!*N~s0KrVs3UW~jkv<;@l|$UPndu@
z)rc+Rp_h-iE!<omPSzvgw!@d<UGHIP$OkHFd@|GkMRiXPtgFtH)CJB9@`k#*!s6R#
zPF#k)lEDNpGiG4$Yft%;KZsX8XN9fnaAwDYL;@a<b8i@11*IOZ)v*83Fca)Si$VVu
z6B1MW;1&^{{IhhJGowg=?|X$DGK`$CrvtXiww;={cy!5EIqW8{Ufu`h?D*%ff^Vse
zu&8)x*%4$<qk_X-RD0sOFK*Xkd^95V4e^cr4I`J$#_&=vJ1BWsgj>P2fF9k=_Sn{%
z{89GaO`FX#5nxRICHahDP5f(TN1C9o@*`&X)2cuKk)@n(TLN4hae9{D{j>couy>`b
zOI9Kxl}QL(6HRUf!;-@buCxff7Hl1VFstFCOB1Ss>l{J7yRh4)-h|nHmf?l<N_SD~
z*Tq$jz3EJRwiHu-JoL2qRYQvih4-9h!5kbUB&aW66$2>$!HW;IZTTx>)b}RGGy68=
zr=pB8R~S2w?ZUJvxq*NLRM*QG<Cv^KM1isWh{Iq_@`%brRp%sA?(atTjFPD+YGs$-
zjk|RH4PUr-WaR2yEe%o7c6LV0@oj7>w%dUr1;Ds7Moj8jN*GH^a$01$KaCTu5=S9E
zh|L1-F=+d2FWTaX6tV`gJF>r+)t99^E$aYOF5|rYpz8!5-~gsQ5BnnBJ{O)U)8yXi
zd@zIk2?(1xdg-{~Irc{J!8n=bheaN{)w9P6$vqPBpvzMa{bq!O(G~7Ie+|sskng*9
ze^&yc(-V!rn-{jn-J`zhQ9!jU=cXh{oYzMJVLd;S*dDT&81kOjbXw$04haD7b1dv5
zEebu?hv4g!!Hxc@<!P%<E`0ammW*V0x(rzoE*MLws~+jSfF<h{jYsUKt3dj`J8I%^
zk8eSK0hvAf=L=<82LzIstDq+^2x`U!$2a)Ak@q;F=S`LKuiug+d#7W}S0RxYE`I_7
zbY{VH06G$pz`I&#$X0B_abL>3M{I0SS%5_%^y2F6Z1G)e%3j_D5Q*S+7VA(K5`d#v
znp6w{5Q8udy<=YNhz8OEsU2#(Coft>8GnNfS?lRpF$Z*-03d=Gilm7SCl*^QVt_lQ
zC<g0A2XTWEq!?n!jJTZqNjHxr7g8XM4J{;_znD;o1mC!7-U<??1}K2&D);w5-HI0y
zdLjnDaAL&-NXWd)2NOw-1YB4-R4oYRCjj*$LDnl5;sUu+#uK8M1?GX&I-Zu5NcCF`
z@^n<v6MJeE|0EYE>JuolVr&F43j2V1+I{Ma^W}>{NR{!Xkz&E`AC=WA_V<MTP>cB_
z15szL=A*rDu9`C6ingE*%*7l%@gx@z42pynViiiY;7tpZLBwwumH7sMJSu*T^yrMd
zIM3gS0*FD($pbNTy(FoT_2w7>G}$M23C~Q$prwz9^~$$?i1`VgnG5tb0*6CW8MpC}
zZ1cDv>aX~yUxO7t#84UXQVN>^&PIWZAk`=&z^?%u-!i%x9zP{UZwTQ>3hYZ3+(Vpk
zw(6f%Wstl+1M*Qs4p>kMli(1z%0n)klHp0PXmC#E5WE&d*+J7HtmWXs1Km$1so-Je
z5MH-6;lXF%bI6`xb4njCLhpUxvW~8{nS0yJLO=XC_ByMtnQK9RovQ8@K+8}MM2aD#
zw?R=%^bSBlAf<o2Y?UPqyYcr0fI#voZ~hOgoaw)_au#NG#{Y?xGjTC-{a04LjbWpx
zy86a*va=lnjI5>KJFbU;$*M^S>vJa-Ea(Y#ge(>;zJ}S}PrvC$Xeowl!VXak5thXc
zbG(4UvN7B#b+Kg0EJs#iwINkbmUnJS&eF12Dn~JThS=!wvE2k4%yiZFefoC1<<k3d
zz<Ui00`y=c;HapguKZ5v7m^Pe86{+`_jIt{Vb|vE0h9<aoI{6@5>tJG2<*reNnp$7
zrJD%y094#3#QUeEq=JlQ<O~wfv$lHGoK@p-nq-mqVsSZ|CmG2<%OK_h9a(YX>e;1H
z@lZ$n4STtbmxrNpUm+zR^nsc9(>k<t1%gT|p%1)YJao*a=d<R8eqbZsy<p|M_S>cH
z2bl2OZE3>U&AYou6>HQJEr6J^0~)r~<3uChO1u7Aekqw!aYN?XgMsG2z`9$lh^Qm|
zM%fPx?ST-<o)aeQo}5x$#FA2V#v=#=EOXnPaUCx)-Wxg22WRYULP=35^<07)v^1H_
z*7ndJk&cyLTC8N5x6Bp)2z`A$I)?*;CMkxo{9STK8cvvqOW-PKwVJ+h+VhDv!<FrG
zOnk0i%bT1P?B^uzMG!iD5jCrAraYjc8?vV9Tot9N0`ly`;*byxE+Mh1o`fbn&|pv;
zUzf97@RxG2qnmmlxNSWu_W(TqY4|oH226w76d20^XVO95aVUQmqULo|#kUUXUeXVj
z>kthT2O8lZ?Kn9Ggddc}1ZfBrvzW@dK0nQ>bI$G32(d8c@raE0L?J{rRs~TS#S30#
zAM0sKMJKN_ofYAgLDJ&tSBlROoAVL;o7@{3($Ui2?nwX7K``n{@I2)GhXYP#U+dkV
z+CH2|l$N;=3QJx5UOJ8dK*1$hA5l<FX>z6`xQuYX(bOHSl^~=cA;hdD>*2p9$FOrJ
zt6z8_GD<RB$LQ-PZx6j3U8RhqeZP``qT9Z;oW{+-({qCw4c=j3l~r?D-Na{Ov#=Y}
ztDD=xOakN&`$p>anSX(<<b%KqnpXG4{9RHC|MY6eck-*SX7C+(_3|mH00Y0C6V)j?
zCTkMcVRKM&RYOw%uk1KYom?(OK3;r--8MXYg;d}1IZr`vK>X6@W!?f-&PToPMc{4#
z6pNL}l$fO#aw*d$??ygTKB48Z(UhnS9L3Ob_n(Zu?xiRF3o8(cop0LboVr&FS_S>Y
z#WVALhZlYF=httBUwuC3zo>A(_TS4pAu;nfJ8~}daSjC7!?OU;d#lDr%EwD`0N3nD
z(3XCxqx<z)JAv2kH3Cm>Ew8AzZaXtnj5E-Obc=29p#h-{fyDf_qNfv$qu|Jy<xCOg
zjU}v5hfUEG4ue_CKFf1l?N3)j#)jg@bp^QE?(YnQi$I5~UVy&$Ms8l8(SGZ%x?BaC
zl~RPOk^Lwjxm>hX2`wwqvR`4UFgo#ND{bP}x^JKDpGV_}buEzb?th$eWKaoskGGg_
zLwuP<OD_(7y1&yucRV+{#=-+~x4SE*8?R0+uV4v;IqmIn-?bb$u1$l`u@CTc)I1tz
zHTAOe=2;s$lU4&7D`-r3uT0)<ocZeU?hxO*t$$&F(qcM_m;#EWaPmy&C3A)5o%Y;F
z3Mw#aZ#+pYoOYAUBuWu&<|=v{D7@Y#-9*MPk1f*Ay{r5JE1xHOKnDV8q+~_9KA2wU
z^%FjT(<5H8N|{7!u;V;ukrtg|=oK!pr8WsX>3fT7&NKCLnrpZmA1XA+A$6h+idzAw
zI*qI78qX^-5fd#{0()LV9|^mW>P#wlMB#^}rpAP#8AWr1zusy;>!L=tWRrbFb_9*d
zH~!)$2gqg2pUT*g?<4NO?BvthCA}EidivbQ%ufo}WQfKlYgeQ-gDAm@hp3P1im(0&
zsHqctj?(p)zMXuLBLP1Yy8^mmsLB-BM|hT;c@R(2kq;C<IzGDF9<Wcj&Fu$`3_C$H
zwlp`L6~dc|nf8(_iXe7DpH&b$w$_y14b^aJI}}E6Cz)kGptBotBH7uOztle+(9thK
zYx3D1=_N1S%o=`4Q~|?-B3>e@MStpfWl(0sjb~529;{1~nvH<eWRQr)=3-w9Te3bL
zi0ZBIQ!9$VZ@v-HA>Oza?Q;L@id^GSDu;Bd@QY%>J`4o5c*m9vrp1VWrfXMJ7wsee
ze;E75@XEGr+t?M`wr$&HB^BGYQL$~OVjC6PwrwXBy|wqg@4a)rd*1!tmtPB6V~jr9
z=)JW*`|R_faHUqzOSBo8>2SKp-UqYPjGUnu-8DsK*llRO?~JGqVqkJasf=7bx{WLJ
z(pj7tEggfvk&gBUxRua)hvM=iC4W+V{aLtVu3jQcl+>@7>{Bi+pJiqroW$CIpbv{G
z+2t|AY&sg|c1SAekMArM?i>gq*MpQ7Wv9K=s7z91g)rg>>m6=xmFZ*{davpec|j&5
zQ?sgDAULZN(SPPWYSIb?bh>jEf3u*J1~VP*$am57oaKzL)6^u*EU&O6aoqZ3-s$DL
z<3o2V^wp%Noem?4O6WD??u(Ly2~zP!Y&(L1#1bKv4bnne3lY|$Vc&Fo3;3M~WjwW>
z)|Fj}H?=gvJBpHnVfaJ)z?HLMU=QC-B1QA4xydYCjlAZ5eZetv74Hc69cR%peBwWZ
zbmspa(wSK~{>Nf`CMFK{e+}uE=vJ~iCJ!6eTixQ28?(b;=`GHT1IjR$;3SGeall$M
zg|&ew>@Yq=Hm7TWgpmPA-lY79C`xHqS_P|F^)Ewo?I*snpO}x&?{$>?$cD_(<n;OO
z-RttBf#Kn|VM9)LKHFT!JT=!YSKtsp%myHuCpPUZ4g#m7&%kA@lucYXx^j7-3yN$c
zHMTYk73N1no<M1YcU>O_3Q6W8;6Sz<cX+@GyfCl&qCW7i7lP&!xf95CKqFH?h(ss%
z?k2-E@cSFs&0~Zx%%Q84e+r*Ef_4YYt5ZAu-zmzr@vzUHPr^S{9t0woWmZ_QLp;ia
zGmc1teV}7sU355x&hu_ba%vTv*53L2K`zrbP850L-_dfw6@BF%Po)Kga=5r&o)jb+
zEPX@a$P`;&)byb7dbrZ;1viHfF3PR3wa5@9f!9W>Ykru;*!z|RNx7=sHDVo+j^e78
z*w|)6>T?OOfHEtN9hs=Bwvw>b=LY5aD~mB7Pz!UW*tcl&tb+qT3G<LDb5XWKxBcp`
z9=$6{&UZTr^aGl?Mtn#3qW;a2xg{F*RWP}iJ92KH#}PAF(wh@64u4I$1a_Ki@6N-w
z69Prb&aT)VzTOH4Zejd6l%W0D@RAfvU>C6c5g^NcwH2qDE-f@LTr)~K1j4dPa^}1Q
z!-HgF+GgH>Vl_x#u#Ap|1$&@9Nzc`B=Kij{fzG+6WWTc~a>Z0y*Y4(R*xB;uD*l-Q
zZc4qhmuvfdPgZ;6;gNUMNWHv4t!9({AUwwLR?wxbs+sT1nsc{doP{|#lDli0j@xp~
z=1GK!_t|3NgoHi(u@vritpt53S9r5@g<9h*E^0w`F_neKl4hI~BiTf4eFWXXcQdaI
zgcfwYjz3z~FEiu1q0Rk1Xb2O3sHgq3{EEo^ByRPbCIjE<noSc~G<n>r&p&&K_hl?U
zVxkO}Z)02_8xpK6C`U1_H&*AQuT9gA0@!pwA^dSI2%J5)#&G7T)GVA?=^1Qf-M<ca
zL{f6*?kNuGYMweux#jHOpDw+sFRSw&PgN$G!f6y(f3>jGY+!!f2>IPF+`V+zMU$p6
zu&$YCJKaXtYS<5YMj0*6FP=7b#+O!1lEQ4Yw&pRmY3r7RsL1GM3t#e=nuP1}*jUl-
zZtLg?h?7gi946saYCWs`aKRC%r*Y3Ysfat$BE5r{{jG5eQ5B$IGEuE6p#0Sva?mni
zBQtSmY{P3AzRJ?joa+@-W`-qaaW`k35Dd{!e~P2@+u#p37uuZOX_s<Ffc1egYcGQj
zv0Q^97{wfGi<ATe&#r7nip*VudpDYXFFEmHFz`tjrZ3vw%KM3eKSYrsVzMWKG(=p4
zKbF}UQ7~nmHxLNoKwIm;tNp_+XJ8iw8xAS#8B;L+-j1*bP$(IFv)F{!oD#=+D_QKV
zvor7)%0!xrN4p~tsb4@kUC$((rM1WeF!)jpt&~W14oNF46<+oO18d00@4}yOo|(O$
z9-`uND^DGplbC}GK^&;iMHafeV(V181h5ja!u^`G#>g3l-9m{wH>AWmGJc?AXvS6l
z!Pl|;Utjk>G~Hok{WtHXn<y8X$%q(w{SHIW5{9N9OGG0kxp+ku=38dr2ed*S*$6B;
zLiE)=gs>(pCS4?PJ<-Y1OyS4Zl|5vj_Bw6icwAfVi}`_UJMZHl<g&{grS&VBV542-
zkK3~A)Lojl@5YinU-U;3UM%$&+TeOS@4~!>fXl8-%9p0MX6S7}&Sz&1N$&OiJ5sg5
zceQx7=)3&bknX1Y=O=8{oVgqY{<Ho+?lD|n#J&PYdCq$YrW*(SHnzH&Yq!YtMo2y4
zcyBLkT9_Yx?YNTXp3htKI;~7hos`zI)}&#g$#TXv1==EL#)NXl2+4|)s_5a33dUuI
zzlizb;iDyql)<Ws$g>x{%-}D<E%UkKtA7!j16LKope(+LzNo!u-C5qz!n45_D;R5A
zGJ6eP%n5~wg8NwhS(qRM{OK`u<VS2)?C9<4C76xSa4AfBWMJG;|1o~bSf$gBE+Gnl
zS3TvjitgC4odJWC%N5Se;7Q;^5a?B~FSBPfN3SZ1SS>vafnpGKYOl|w@51z)-AJ=H
zB0DxD<=govwpH+0Z=L3Ics2>ANmydO9BM}E$K>a5%Q>R6diwzP5xuAV4;bM1|H1$p
z>%WOs-K5Egbw<>XXI~h)(nzAEWMeW!5R>-N0s+=b&=-j*Ozd^eDPp@HTDfV$-=J}0
zuK1pD$K9S?KOOPI)GmE#RlJ}p&cf<+`g}ZTZ4~8N;f?aeTtqrdlRnpV_%J#&y*;*;
z?RjE9RB>Z1pIH)~T|CNDr#BaZ6$Y=~=0Z#`Yt9az*U9$AjdH$%bucy5&`T4~gb8qb
zs*dd*>B@Aez4+YX36_qnDqr39mYv|Gk(c1+<#k)9U2sx7J45$0hmMP4e7xnwFgw27
zbH_8feQHvjHwN}is17YehR6;`i8>U@9P?m|ks~CK&x96UzaQ^f3!4P>;fKJ7WN@SM
z!pN&&oG1r*3p+|u!pFA)Eh~oQNK7}|hkdhXa6$6XXAaT{(+MMqEll9%ni-rE3-VNy
z!Nd1{QtWe?kiw9`05#i%^MvOU2}}WF+XBB9&S6)OLyjS(^-w=J-Qmq5f=*4$lM%xR
zbBlHRX12qcHHxc+Q@`Yn$ZPJ%bU<9Dvp~}sRw<tvLGShcNNO%sODsf$Aw%DnUAqyU
za1g=`tQ9BJo39uMM!JDG{tbz_!I<2=*4=*L^&(|dHbXX5c5_EzfBMFjO$%qk5)}>x
zTY{X2SU0nWX+c*$j-K6ZS02i(U^UJ<9;0(8+Uj2FJ^dX#?@DR=O_d@+UGQ_M#iaJK
zGFEP$KZT4wy>VsEb@geCF*J6QL*ZV%>Ejcmq?5JezeA1XU$Q0tgS%no{I?cgy77~i
zgM^47&-@|d>w{!NnYlVp0gfI2Kn*jyNVw2&0)VvrV4bqO8;2v@tn`Z|J~wg5j4m%4
zFDT~)aSzRlGqM?AavRC1Uvtd3NqStc67}X+Eo8qp(q|J&@>eBLQ+GH#J(XSkArrbh
z!1Xf2bGmJP4t!m%AWazqnCF^RdohFbg1yjKW@uNZvLo8z*SS1Dsrfk|lPIQcS>~uU
zv*LC_(*0R!b5huic<F!(KTkaZnhlb+`>qd7@W-(#^5h2MheX9foQ1ICs>4^vkjze0
z!Yu=w#i(aB3Svp})$@lK6OBy6RS8r{&?M88jbIW_ykzC@H!m))blRqstG9-kN*0S>
zFB9h>uGU?aE~^1XCQC_@{trfG`~N!6%>Q1nsT((LIY5XS`piG5C65tgN^b!xL^&^q
z-Zj&Rp#P8t6CJ@6+3C{-r*Z-u68rUjEY9%ZWG4sq2R{p!F_2vy{QCwrY2VMpx*{%r
zW@f!#?~dp>GsgJMWP2Mrmy*lCACh~>{SX}#hvJ<i4|J4pL-Mt6?Qr2?i*E#3v*P-}
zPKsqJ`53!D2BQQcZMG|lGFvYbj~Vuz?xDi^<nY9~Ln1MdgKAL{Vv2WWPEoV+)V>~^
zT%xsoBjXw}*-cnn`R`<7ldlv)@MA*ON-Qgp)vHXKOXm)?8J@?@+UQ7@5$Es^T}=Xb
z+w0tUYTWoc?%u$)N<B;eyY*QArTA6V!`_6DK~urd(!|J_LB++;`R_Nx?Hp|wgoW+g
z33dMZG6xq6JqIHr2PX$16B9EtJsT4jJ13higR+T}or|N9i4!5~Ur|<>LBi3_#hwt*
z-tM2@{re?@3L%54qk*lHy@8{Nt&s<V6rr=DiwT1W;C)dOR|_K(WeH(^{{JbR$n|fH
zP{bmb;Qa~V#M~5SVSk4BuGM=X2}$BcJ#UlJAJJWtF(4}t{{p0m(Z+BG)CPZT%Ixa%
z()g}tAl7RJPQLi~t}iNJlojF~?^YS5MMF3*1gN%&ujOJ)(P7^G2V4EiasGeUO3KE-
z%!EP1!WhuHkBx(cLDIy+%-orfiH(gx#Ln8zQN`ZC2w>y?vs4CQ3uh-q6Gss{8+$uj
z6I*9OP6jDkKr=vlyT5t?{$rf~<U0Q85~yh4Xyf#ki4`49j4h0u?HmC^{WX${jjhw)
z6Zm^nCqfp0O;zL!oU900|B`#k|GT{)D+dS5zuGhF;sZR+#4LpzO3xc^Y9a~=e*#YV
zr?PT6w?}(xON*JAr;W$3sf~@B^>C%lu(h?@q^GH6d3y;m4UGyWOh}Qwsr@sQnW=l!
zv#vIez{YbRFK&(mCCm0`66)>^{pVNywKqY<Id@`RlnJd7*7yp+Pv{APuv6~$TocR`
zug%hge?HKWcnf;gX)iC2*Ei0i;eA+9Rot^&H5?l?^N2TCUG}lW8rK|RPN{pqc?;8~
z5QR>`{w6W}=R>0>=KGg+Hs;($+fvn=<5SnA^(u9%ljbMF7LD0o<7p0kQog5DTiuqi
zvf#J6aXBA0Zukrz-2ZGZsmm~CVrsI9`M5T{<hHG<Jhp~U+5ho;YWiRQ7yOZu5@$U9
zz3AL@XYF)llV<O|Qp>;vkdq5H+f`s5m*NT$9!Fo!;mFE-PM0Znui#T*pZI%{0`PDB
zw>sQu$PeOwc!D(KWm=}sP=X9;iGH6pv`<+^O)$cY*V2w#MwR^}rxW<GQoGr9t*bGN
zuVPDN#oTjcHS+hbM16$6(8;M3<gX0Wel4wzJl3pkL6#_{&6~WW(AQR$v1Ck1&O8JT
zNH1f>7)@YTjF`$()wEoAlUP0D#DqS{&eQy}{+UaJ-*y(a=GLCHFFV>Ne>fbU<z`u|
zQq)qAoYm*CvS+zcfO`fRp+iF$7^5JhQm0sGr<vOa&Y)9u%r`Dp99EhR{hP{_>|1}=
z{Jn($lLB4xT(&r?NzqP)w%bBh`{DKYX{F^bQaQkT(S$B)Wt(V<hvn0S&gOHM-9wp|
z_5HvSH{(p%byi=-6i1uX)&pLyUu-*XwVKD5kwP<T?z}qxXLqAMW?$%ZHTnWZW{kcb
z?F>1l7z=%bISEg=%Yh3TBTRM?ZW3|dQ`L55qWott%7-X#@FY8C{AQ=kaZA&xw6%&&
z=JA)SIdJK82C{_JN0Pp=qyXS`fiT()DBxP&t6Mp+zxg~IiDq$}=JR#XQ#3yCS4<fc
zR2Exd+WApAbXPx8PEJ#JRwDX+L3QB@1Q)WO=qoe}1GHzPjJL3@zBPk<yjf(*M#8$O
zDv*Wd|7<tvo9!!|t_n(|Qvjrf$Z~f=hpkh?erGUD(8wj>kHPwrEG-BRZ1rVL^4&4R
zGmf-#_Od$rf@69CCi4{JtP=Amm>&NRoOjyT^T;@_bTGOW|ElX+TfT!e&l&aA-&&Pe
zmEM10Kg#F%vSYu+nG6~Jng2$Y3$4Q^hJXN#gh@SB6X?5trtq)iDMsAMM)&Ml<HS7l
zWF0qrHv;!*?aiWbN8?%=`&ZSyDKcMMRaIlXV^;YPnqX>T=>^PhA6PfI<*OwJsJD}N
zQ$BWPHUif4l%u42f1kJ~yq4?W?Kw5E46J9}H*WV`*s7j+0G(>3ACZKs@UIby2{m9%
zK~mZ(mgdbJ8AH)&X@BlYY;x&oYfTW@*U~1&&&`J0=(^~*Nni5W#C?E%00A~AbAqd=
zje_tqm7J$BKtD`y9B=ODdfResv_;x%t9kP^{^taCHvl#*IZj~4W8Uw|=y1xzz#t_N
zO@3cfH#nb;eF}&(&IIVRT39KLjj9s8A?-2rTQ#5E;RUyCMfq{%6KOgMw!+e0{K<*`
z@!hZAhYW4;!_Dq+(!o%z0g87pmY%?ChylEuA;+X0AyhR^R|4@qH(pQW5KG2P)QL6s
zpZ|LjB7jNs2gM#wz0-T&I^Dm-X(b>T<8d-z9<*SpLj;3MCf?v?m7*VEwzZCRUuVA;
z5^$ZZyLa4+Jp{Fvl+W6i)i~{5P}Gf6$gz;9%bB^b=1-LG^y?2r8W4ekO6E_MQx8+%
zvR73Px?D`(J$0JURgH00{p~E@s#mS<blL$Hywm#_^LzTSaMiISxlrVU{h9-U51WlM
zQu#X#y_BVL;#d9ps0~k&&%v}~Gd^O&eafM#vo8FfPL8QRJ+INOUj<w{7_91M?#a8D
z>Lyy>a506w@{X{gg2_19v$APyw{pE+g0kq|<UB&K<ZAvIJMlrM^{B)`dW7JtyW!<h
zV7Ml$`IVPk*FaNmUQKsd@vNU{2^Q_KMV6N4gchSgYcX``Lge}Y&wE+<`{)f#q5HBL
z89V<8*O%1G`*ELS4;6V`J4CmV#!N6XDpIdq9dE|#9;<E)RDrVQ#ma~HRPS?kRVKI@
zyD+)w+<#30<xVF9J60@=z-!7Ex64sG4U<{MA!V0s#|&f&HrQ68e*h@M-&)2<jwxPa
zj5-@~dz|l~yRaI3=B$FZy&7=K*4EpWQ?7VTHoDocY{XDGHhD-N^C-6w!~jGTqZRHr
z6)lMtcvt&q-COiUmz|bXhKHiq=)r&CUgEmNSx!cBZbNnF2<vNb`k{LLNK#di4MOlL
ztC~VnUG#+i#56xD%nXy?0J*r6c)o;hHEetOYK6}9u$pgE=-%Ky;7tQ0m0!VG4+Z^r
zFc{<;gZQ!k^h{J4r!$_Xb$N9pTm@AYIgjr5dGX^<w+2`IrX*DmA=MJcw7)~5Ulss(
zY+~{NA4{+a|DB6$vx{;{Ap!=we-3qLD1<vZO5Ydv4n1n<Cc<3F@vb$L{jGYRizjAf
ztU^mj7NHTr=O;OZVWP<AdMYtT_oC<ZT@JXAk`|buF&F%-^#G>2DP{opoSwYVE7<f1
zIQUT&<c8O_W0M`E8tQCPj!x1)arrF<;E>gl^B9<4DDC&pPonKs>-d?_51DSki_r&I
zwEWS)+=HiXvd%`-E!Qh~Voa|&FUoB8Y^GdJsZZOnBSk~KK$d&LH@S!59vy)hY8-Hb
zhPqZTK~03wHH)1C48XIM(A48A*-PqYyWb`+`0Q57Gd)UqNJ_H)F#;;U2n*(<>}<%b
zPE_89NlR`TaGv1bEd9-Y!YDEH<|}C-DnXUg)~r=pI)r%a=T!RGb*wd~*E=p}cL~oQ
z<Z&$cEc?9{IX@RL^7M)sR+=8Qf{jZDf5m|xm(TMQ*Jd3|p{+G{JmuKiY?)F0I<SGi
z2>Cl`&>H#q|Fr>JM3V|39k$>#J|ujdL{rg`5y5Hp(EW5z+U_;W&g%QDVu;D_%ymAQ
zPRC5oL%K_Q5gJs?AYCo1(4rCU+_xv}0xkN=q%lf}i9}fxGK4W@5x-cl$43Lp(38XQ
zIyO3DdDh+1?;<&QOaECh)?5Fbj^l5Pt1gUAPwjTEbSwh&0tX=tXZ0m#QgRR%j=u4j
zCNbnn`a@&bN1TiG*wz-jMh!L?*Wq*j%yUatWUO<9%^u{=hvKbm6Bti0xxowNndd-w
z+@g?~=>Bp_+RWOu$1&>jC7<d|JMN6;pH~-fdL;ia1^xFFWcVTSFp+0^2|Mp9f$s6Q
z_s$_BF^N#Q-`41a42;u+`cr5r$u{y`^-J|1_DeA&Q=zW2+5Oe_j5L!aR*sa2S3WyE
ze_Y<5JZuZLQDN_YpIeEu=-FRkljNu1g7BRMPEeq>MB1$xuDfhB9p*I^<g}QLh5i$1
zHlK7dP-ErcLau&<Z?u&?Y_QQy-6`Xm(>ueP<^yf|zcPRo@lQ}jm87{Bw~lqX^mr{h
znBAMI=n<ugyKk+<g|!z*-mCOhXYQVtE`}|?u2K=@*JF>@X2Fv_Kxa$kflv%H^NyQy
zmsS)=O);Pg%D&1imvp7<MZm2w{=NS0L|++|;*eGS<!@gh(~H%aeS07bAs%?%$?y&R
z*a<}92}F|Nnno*N)6{LR-skMU*{oOXsHpcRj#x=4f6Awx;FN;W*9?)|{+gZHl!-sz
zrjEV($zPKPO<NQVogJ@K5o4qYzX+$+iiBILX|1glZ8I*k+}(l~jaR@!Q5f+L6W+$^
zDYlXZ7}9H}$C2CjEsK$hQna9R%IY_L8OUlbc^*tYj6a0<4pw5{2veq7g@wzt7md|2
z&e9ln@2*~9>@1sFcqo90)SW7E?HF)PC8?NG{bDvdzE@w@#!D+16Y{fe6tLgV99gVc
z-PKc}g=r(HFhKV(cgz<u5f8$$3^h;_n)z;9RWew2@4iI;d#omB=O1`5r_lEl4;t;p
z>uo>Q7;$tPguR9MYs?^<i!K+jRF=@tf{Jv!m|@9lV9^`YTbZb(OnQCiiRD@coW^@C
z;IH47a?1yK0xMqIeqZIR3x!irOuInib)7t6G}WveuEs7G4hu~%uE!ZMASNPQyXgpS
z+c0{30A?AIiH~8DZse}dYK(@bA4Xd)OAPtVXrYrhV_^d%-zUs!o99aIZ33Lks%z!H
zM8?@WfVvyb7k+wa2y=9+<8Pw#ITcho%yjovUV@BAw9_~Id<DtSp`~faN>U+oz8GEm
zs<zsvck*T0lhW47D5kCp&mWBZ0m0yxANzDO%UN@h1#f*tTlx#6g0tbZUH!QC8K5<6
zsAzSp_P|a0(^xsMyzM95Zed?{U1WY+3C~F4-H<`F5K~s4U?X5*mC~TYs;C=nx~_CR
z2RE2R?o5o$-2E*xR%jk{+UX%X0lbmVOd#b-m)XlqOv`{RxH8B($jk*ec}jJq8!Os~
zE!m`By+eH+aC3#%s@GOy%JL1m6?WWS20GSh_S>aj)c5y^Jsm_<Es@{O=rOQGopDf1
zozyUO?;z_q0`#w++u9K{bHepyQgtWh+k3CmAQ=1@!*7%IaONWDO!t=9bN78t7B2|x
zQ%(+<x-}LK1TT75-7S^L-vl+2{|N*-c0I*Xw<Ch7$9-nAG(Q{@gG$_S4>ijILi7<U
zZH1{xaT)c0OOz*!lBTk011Mm}7hTyhSC;t>=Qn5xLj%)41YaF1qd&Cz_z};EyZd%x
zK}Lw@$ad9I!jF#3K3;lgUvFvzf0ELbSU3VGhZlf2Xg%De?p>s5f!?`Oq7}>$aYM5{
zgnU*vRQA<{SMt``m`%k4>VI%ioM2hPHU8$uRYBW*Spga3lTlvuepsB(OzY1xxbRTz
z<-I`YVNZJguzfk-;I3-btY|Tgv8YOC8V?nxX0Od`HcZAwWsZ3hOK5Xmt*^e`{F>yV
z9cK7c63X1ZQ-IM6iJKvH5EhQ&qEu~bzT17}wspihSxmYhM>cHf9P^d>Rk`Z1NeGjp
zZA!y4Y4zeAQu0B$8g&jhSsH}<JZEy*y$`H*N3*5RyEFge=}L_l0KTq7TsXg4Cz8T1
zzSTwiVLIKP3C|m4k9RMw#-E!=kSR}en5q-e;gFFo(+Qz7wc~k`l{F=&ZlG^s;OqLU
zI{QzPmXtYdO2&XZtltl_-csTcJ-pw(w1tqO4UcbrI<LoH5-LJco(iF}O(z34?`;Yn
zW}kzs3s!QHl_dqFNg~HV*!oc*hGXsFL3_V&kHL$5MV`V5j_}`qtExgYcBXFt<l~!4
zJ%&x2dxTk+Ttbl~DM&oqFrSy`N<~~9trdIv1p0UdSA{$8)%`20+`fmN2t+s%sl54b
zXb4lbn0-elrz&+pa{<WX6036bNbxW)Zw&reU4F8t7;aUyWuXPodT3Q#V<G+cWh^8)
zbQbDqDc2V5?HrezkF4xr>%+y<<8u)YHRmFZEuV1+X-ben&?`_3=;$Hj0>t0}NTLO-
zY&6<(`sa<97=)i5VixK?##}mLx~~YI*%dbDeam0S?M`}Gxy*y4_|w(Bl0dakg|dpk
zb|v?&T1js_K`bP*Q<<w0J=Yg2B*^9_LtX%F>z7qxkr6=~FF9aXCrS*czH;d&Y&6m8
z*tBg}<uvA<t_ka(VYP90e@Rr}PtVRoa|hP!heqc1V7)<+45=+?KKgjxW}u;wd9&d4
zQZFnl?0Fw#5Eqva6H-J~n^(0j#|`trbk0#_qv3h0`TA4SVz>R-xD9e5#EYGYeXILM
zZhu<D`0^V$ycRpw1Dq+02kRo_mbTS8c^|DqjIOHjf;Yb5n$B!re9H7k4~=S{5Z{Fu
ziQ!KAO=sP$?wp?R5B7Eoa^1v0Ju>9)r7C+>OIed|)+S8>RgfSW3KG{pkdDnlz}zL#
zMLP-o4KTrhaN(xw67npvwlR8cUN<Ba+^54Y_$aJhsybOB59gzjmtF7}5)R)F5+j3=
z2@?e<dcd!dr=dFup+F*uiDN=RYRKsUvc3B)6eFp;Jb_fKaCUHT@Yk<jV$*vQ4-+FJ
zBk%8>S#fnMU}ygQ>SRzQ?d@wvN2V?7*_oL-+S+HX9dzihw2co{w7Sa}7#P#uZ#H&z
zHPD<sKmpM`0ncut{_w}emX^Lk`RkXTCxx;05e>d2=bo(CmltR4KIbX^^@1_`Kt(Z~
zJnwkGO-^_B0`E5>@Au9%3odzLxw$Y~J=m?D)bKxh!6V`26->}bji!+%fFBxwgiD>G
z44Xzm29GAaoSwQ*Ew?SkrgW~$F{JYazrY5e1SbOCLEKf8)B9u4xD4PGV=5u0!OM`A
zZyPzclvQn~XdGFsZ<g$!^tgY)Kcxv1$uDYRDi7HLS*BLf??3lbQylE(oV-UZIIVZT
zi7q`ArbKYF(quPBDJB$IEmv=Ld1<KSss9q_k<35GZg(0P!4t<s!3{R(8B~rnVNbVl
z_44)g)zixvwXWB(c?AcD4-*kJeW?ZHF%*`ZbrndF^A*hv4GVgDdRkiCoSmJG%_%YA
z2KJRnu?O>w$CQZzr8w-qyK&>0CKlJ$*5=pccjxCfH8qu#kn`}YTeFv1Ih^WaJ8Mb`
zA=ZTzz7TjoZRi40K-syOJRWz(GBV>Oa+y&d2H9}0)IWng4q9$Rk>tfVV^BEtfY~Dt
zxS)bv`mUj$H|}-0v3h(0GVvX#nTcBuF|&^`(fT1=ZcyU90^-6}%TZCGt90sH2u6jO
zRck_#F%pn_;WFvQ41W^B<h-*vGEh$SQth`>Dr(vDLenfwJ7=SbdZ`5gobuKTe(PPb
z^L0Ht)5LIJR!Qv+j^Zh17b=ubStPa<%%9>n4N#;0x&625plj|mx3s%RE`RHyU9@=8
z)1zpduLp%M)X1S5jT~!mY>Jpb;D;$gee&+u6NQuMy#2sJV0G4T(}vYuM{ZpCoa2Uu
z`izWBz#S9P<I*%V)J{%L+45$dBm;ltj7E^dgNOG$-d}FBdEBnH+E`dw8(UkUY;Z_<
zpx&6rwI@v*MTF)dhJ)Rw=TsN3@6R*XS@=F~c0o(W)l_skEappW)|;Ce8&T2Fw5pbx
zYG~orh(`Cs_mo)|16hcb=xpih)(WpAe)xU3czAdS2>~}$hsp<l!fV=>W4Z;nIjMm|
zmM}#TLKRSwf21Hkyj5r2<$gB(dCB3z-7}z$gp|bJX-Be*ZEX7eZ49L5;J_&w?<!kD
zSLaD*yxe0v11mYjres4nzcw&ECpZ+(y6B{PzOe8sZy+$FVKFYuKcRp{#=dpQjb)Hv
z%CUfl$Lro#N6V(n#Oh>-BfL8EeIl4})Z7tBFpN6X=63^djJMG2OPj^xn8xR?{FSM~
z)i8m^<)-4u6b!Qhkl{qsh`k3Xy@)Q9KPV2`C#jfGZ2@H=vy|Ng8i)tMQASd8YR0Q?
z&)4ghPkRXo85tQVODQqYcmPy#ad8dd08(2YRB7eq0fKp@rN?uFfWA(;*mzjcVucwc
z1y4Y&bh<{YD~(Z}kQG96MyM+;Bb<s`0WyU7`Zv2DZy!EB%hkH;^(Nyvd|uq#+z}BG
zORe=gP^`a%-#|y7;`VqWdS=`FuTaOuNp_u%r`R|+dTxhs*fXQGG)P`x8?Exsa)j7m
zF9lD&R;|@_%D3;t3G@~Tw%Nn_;*j&SDcZ;<LIR|1s3}IOt((ewn?Gv3-V7vcU=iWE
z>*o;L!K^HrnoMLmk8{}YMHU6V*_8b%20ZZNW@)@mkclkgoa6V&ZG~fXC8f4B^<b8_
zm9Evz)8I_8N_YT0)5$*Y7RV|3T_vI@Vy{`~ZlOU_3lFuFp;S|GrMe_RHm@fG@RQV*
z(n1(G$t_$L6>Fyyx#3BRR57B$P(BBa1azxqB~uh?q)c7w^!erWd57<Zr;p8MOg7Kc
z)%x<x%#JfROL9NJwwk>71UNVy?zelZEN1vFZf_sH`kO}{K!HL!ptwj5TINp0*`&(k
zdz_N~_NTC^!#Ce)S$&D)KfAX^!^6FvudcTJcB)#oEG;dyW%fcG2&hajkdF(oVGV5k
zsnJkRc4UXeCFFB>wNzB*x3;=J$FVlCNDzAcMEt<K3kQial<(-uOv^L!gpQ#$wZA>7
z+`w=yp{u57(7JYYt~GkZ8oe2qjial`_gc-4A%EAJqI)xPo3aY(>MSX57p+EVqt6n^
z<1)Vi$0acbl)5gpHRG}#RyyUpCDqZ|HSwHjPrj0+jD_w*+Z}kNHs1R3V~cwUjJ0wG
zhLN)9WeiC=@F79E)v{Bed%{3Hhu?5={_gWYm(M4xCDxbF)+KYAFKP<u4yA?$tC#Be
ziA&!N@}i1L0&*v+#Cw0=9Wog3`B`0E%^}~}<~F@mP(b|oXju**3+EQ?)nUT<0PAFb
zo>j=C(#t8xTV#+Es-lN*6+Qu#F#5FX#YWzPxxq7ny^G<x6bhmoip$bsU!I?8rTs|D
z$nt)>Y;n8X%1%sd;9efQ_b>1Bp}oMn_1MFPJ8R2x3O0r7zf&~ycmec(io}SFj9jkK
z{>gK)qSXh6f=Nt6;X-@jm_B(#aTa`n?XK!G=s6(C8@a`nj&ab(TxZl`G;Cn@1~21)
z1;8o!2K)H^)RRs8$MpdE@x+z~=ztWp{t$hn*Y`?vCvIFo-pB1iSgugRuRSX*IkV}~
zzo~$IZUL$N$z^X>&DD2}v|^}DS(#F9-sIat=N!kZm@=g|X;~KbZZeZzN`kHsROpgi
zy}l#~!5y{LLS1i9BB-STE4GX7JuSUnx3h(<?bP{g_v=yS;o+fhs5+;SUsTC?`}TE@
z_v>BH`%}yF^(JhXu)pmNCkg&wzv2QBW(WB#C)h{Scl1w)A}&%qnegvQbn%DoxyxRk
z7pu3o;jbYfZreT_0s?+$#}mC2#c*43bOaqLffEIM;Hdj&QPbyqUQe<<J|FQU60#*O
z%IKn*(Ms>VYAk>7E`H0BCrY{@C)f$CgHuqS_}!RIu#em;TZG&X#5N#wTTxY^TgNO{
zQ<0e-nh>~iFma)Fy%$qmNI<jagB97qcJfkJ4B@#t49{kf5TxBj=<T~Rm@(^&TgtA!
zF0CyI&YOO<DKrj0PlR(?V(#6GTky!E&6`6g5wpRx5H1Q7B1EFYr@IjHhl>Wk9OlnE
z6uC)m5Ll!l0YPfny_g*aZ>+DQM2nkfeeMJyNXy8ufCCQjZTj?ekNs|+o$tpv<nxux
zZEGEB-fsvIi8Q!a+2kVio*U-ADVY8P^VIZ_@>2NcxZg-FIYq4xFG_B-`17on9|-&-
z<CD6x&<(WXuz^yd_PmakMe>p$i%I6FJ1Zv-sA700*8*NgvNkq0x;}j37R8(9>5z;&
zqjcHgqc0P{N`ciNx<DHS(MhF@37`oKF$Te{i?*w-l-JP&nqyXaG6pwVMjl&w^GVNL
z0zXjY>U7K|Vdn#38m7zGp%{XO%%PQ3Va6xc;W0YzS-gC3W|TXR5=}kA#`Su7RW<3+
zljuJ0dQu5C(IunAfZ%V2*{l=<tXl7^NVUMMEjSqp-=J;Dpr^g(%;IxNd(&=d5ap2B
z4FVg6lT9dtnA^+cqN06nU(Mu8_W@3do|1CJACBco!l=C(5+pzdgW>aNxu?zV+Lsr9
zANo6H6<qRyvbi6`AqcCh_`c+V)DAU|^n_$_6x=9ssW6b5In!BQJv`gM?Ck81k24MK
z{?4zi=llD6b?2i3N^Ki;UVdY^j-n*}8^76IdpjVu9i#Y_s>~JukAQ`Nsjsh}^WnM0
zQiLOVv5Tl90cOn#CxjB84>-_CLPz(7V`d082jYVdTVI+npr`$a;iR+98a!L8RhbyO
zPgxA<`Gdx@Mnh=mc>zS4sAad6@o^Me-;CFoQU&TXTpqnYaM5{T16de*Jp}Q#qWSYl
z1o~&#r+|%k167g~ir7gKut=jZqc&;+-;BL)J!`<acH>h7Fa9ScHYU<_s&k~d57uWm
z9uCgi%X5z#m#$q7r$I~2zM$t2^V68@@}oYZ`{`Wq_WKbB0)b#j$Ql~uMyWg5MUEl^
zRu$@;L1;A+rkq=?z@Ao)(d<v8Mi}RV%$o$VXcJ_=gc6kDleL$VlN#S!*c1bSmz|G|
zWMf@SNCjb)b}q)UQc>dXS*<(Cv16p}GghvqM|&ZW0I2D-*y_fP35246NDxTXE3Qci
zTef1MDuJYUy8mYO53QMUq;vy@rw{_74!i#D7kEg^u44l`?r`Rw%gQ%3fI|Cl>yIy5
zQ#S5#{o@$lQ^EeY^HY{)(LQ|L8tp=h+sveqb6jfFIt|G=u29x%30xt^ldxU+q!uFQ
zY*`hr3!#-?79F+l7h}DIx|Sm&*6|)ADOBwy=~_;!xb}-+9;uvMSuBCT=L6ubVk^s=
z2SaTJIwLHvZ|Lx0HF{lt&H?E7?D7hC$ISzCHeI01Mj@mZ%OKf6Q{;m#NK4E#67d)0
z-k&b3udl6*izC%k<BcQTL7YvK@0E#45p-4$`jU%^`M9_9O-xOFI|@fZzju6l-r+<;
zGnl;f6+NdApNvDNo2?EQiJ!S9Lsqt%-jBp!NYPMDN-4@bPsR*Su_%&lmX)0-Eads=
z2hT$a$W&zEd_&-z5C;~$-f&CeLs*N1Z`m130aIEgL$m^WWr!K4X<BZ9uD)=|Wz*}b
z%lPZjD2jn1TQ=X1Wphs{^#h&>qWN&3o0y_Q^v34)63*7ND>lVp1`djuwoD^3B=i*K
z8|^t+`S|vAzbEZEEQpgE>G{7D6A{OxvZ{)yB9C?PxOIR2IWI3S&&tYj*3<tBS8^$b
zy}iBD0$+Pq*&WbQ%-D<&f1ocrcQ8-r;VMK}!$ZVE78e&EzeQJ7(Rp~hewU_3fr7Z&
z?%JMTXJKaT1Qf`QFoz-m@RDqSw3AvX_if>mGkZ}yEUf2cFES!xEE*5z6|E_bX=v6y
zhjmAEuZ8j5YG6K%8KG=mYv}w@uigDuTN~N2rt8{hE@DR9k{nTwEH^!_O{wb#;|~b%
zkX{ZCXE|)cVIWyz8-nVks0*UYI`%C!sagc@^I%9AM3#}|Y6)kBx~hs#f8#-*T*eK9
zi$?bcKhUX`Cl)ey80jo2)0UsSSdL1agcmDK_jX^CJyi7cL$)+phhBymncf*C76F3#
z?(TqMif4d8(cRn>$|VR3<E|tF5+UEk|Jf#H+$PECeK=R_^Y(PP)<gpuIlV$qZQ$Dj
za9x{SP89gD`{Cl;@`0lsdCFz?S=E-DI=k-GjYZDWTYQiR_|{fdUi21;)#qXG_;;RN
zo4UHGHQ(EuZ}$#fz~q@{&;x#w+RG6<qhTsK&vELh9q4e_B`0}*SJYHg*KY5W5zPIm
zfbG;-tPg{QE=`+87$$o|9R7_HSX@KZ#ohR2<JIZ$@vqiT7WBD5`?Qu>JKQG79O6^x
zgqTUOD?1be_q8Cy<+MsG$kAJS8P<F<A~#S-I*i0_wI`M3!XeH+yy(qre$1+6Y~acJ
zH&Gzd`YDnd9dfz(%J@0qlIe`(y7YUwoG}d~-MxpgK?jG2iwg@E0`@yz+izRT0Btn>
z<K56)AIOkTRWC0~$DK+a9qVQ9X6L4<LSuam&=TucW?fWO&*1(oKwbDfF8&I6^}v@5
zXPw{?Idc#0LbJ!h9skunbiWZA6O;RXKmqvH^!T_}wKEjE5-LFJ0T9=Gxz1s?`hI&Y
z(Cv0yO-i)<bD1`H|L2~n#2T{VuYhlS$nd%yzCQCulWlh0ZGpH@{aE3@>1+%X?TLg!
zfw%&hCZz07XC)t|F4u9^)&V?izBNTEUO9*f1Q|?mkL%q>P6bV@H%mcbXD6N&x}uJ{
zkOq#XU@g}FeqqsiNl{ffSyB@I51SaoLBS?jdxKCXQ?xvIgO*S-O90lMfu1K{c}9CR
zO+79Q<t*d)Z2?bM%i4_lj^!0xVOe`9DuWW8zkxq{j=_v%cJFx8lZrSOf6fwzv5O=V
zD4dT*zl|Xntak?5=W8gAE_y>-ef?djz{juo)0fz<TY(t3Z&+GIO6En`dU>Ef2MPc(
z*T>6~dcTGF3DUB>TwY#2htJ8>USCi}2tGpgQuz!zCWs&Qg&EIx<;wX&!1=~Z;N$e^
zay^yh2~5#0hk=&%{U!+E{QT@|m*8{vBAq2(5{z4ql8IP8GQg;om(d}Q9gTyF9}uc@
zH8j**oSkXyp!a<dry8NOgBAJWwQ(I{FmZu9KpoTFqZQ<2bN<|^%E?Vu>vl|xUsZHX
zAXbC34N?sT1Q2>np~ZiqcQ3+Wgnh>tr7utw6z92z=@4zN9_pJ7&$qws(!BmyG4H{S
zbm%mvrf*qj;X32s#Af$DQEfjHWArGh6a0YOQDL^q;a@Hr4Ig-SHqWEsUc({qsGN{v
zGOZ}CpH<&JGQX%zUL;0-PR502*3pAR!=!Zx_bj?G<Byh)#Eoc2-UuW^%@|T7U5p`N
ziKpoV=z(?X=9Vo_9^~-%&94VH6%`f6>i|%S&WVIUME660Mk3&MSJco+?RMh>1QHkY
zXmPvEb{D{z4<?1?wLYMN+X6d;f8&Q72vW~{oNSSQf82hTlX1Gg3lg>tBy4PH`C9z(
zkxY4G*3E|k6XM?Q5|1k?(%uS0yTHbWAML__(dqpvEhaX|To=-c81yOm3Qa|uE6C3H
zf_W^UdJM)xFSq>Xk0-<TRz)>6H6^9^>RH(+vHWt$Atoj7=z6&ZN*G}nc>KCGl1alX
ze`0^2>J4(9mvL6zMD$}`423__UwSwv=pw)sS%R_2Djlsehtnd1YEQbu_ggRVRn6%#
zps)nwZ1O3+zo~e+tUE%dmln-AA5O0JTE39GyaIHy&`=yuRQ*;5CSj4>noA8tmbzQ+
zpE?cbsdWN8Q{=~?D<kww^y$T8#SJvcy1?ZVjEFwzzYhl0C^Lkp_etYlC5A5N&!6(z
z@91l2ET{g+ksjD<&5qg=c0adpgpBcUaHy-PVL*m9dsiR&+>xDc3=a>d(Wsu7oKlVg
z3V=%>ub&b$K&%a^UA<muIyVz|(^4_orw$ZOF%eU;wy=1;Rq!nzIeWc7?#oBKQZZWK
z7NN3MJOVpLgn_u)=<YHaj=8wFNaaQ*H4F?+KB+_(|ADvx*{&HFE71W#wmaAZOC?W=
z+U<I1DI+5zFCR00s6C%On3^?KDC2?q>y5}H%j~EHDuv)HKujNQu0?`$h-PIOIp?)a
zr3c3Q={e<=hz6ozx0;|LU3CyS1vx0Tj|Jtf@B1vm*K$k=yt*cjmHXLmTz+-!CtrK*
zUY=CG+|MA-;{+D$9S4kW^9$6_Hoo$AzUMd>384gNK3{g$Y?Czhx*0G(Nm{3|Jw5E7
z)yPC;PMJ3X#5R~9!YHtgNNS*;tgN_6haHNGi@lyM08(>zWQOsRIAE?|87~po9=GDx
z*}woG3pP2bwHoIK2<K~b__5m^Zr8m*koC0pn)<-cWe!fTDzPNSz~d)2IPCA|0$<Aj
zW@jZt1kk2W-*9|y3JF5{daX2S$oHW8P|8J~gkCjg{}^hCsfR*9^6>CvW@hT0Nh;TB
zs9uLNQW84@?SViXiZ676s(tJH2~7u1|I6ISh~#)G2au(+w6KsG=ES%a3{@t?S|SoD
zwl@a8qjMz80t?JYX1Xf}Ekf*Hw})xl@BvhAY@KgI2)sd_zvN*Zt$+dH>F@FAiY0kh
zmNmpEes6Pk+<pF1@iye7Ymk=Or982#a|iQ?E*Uh;598?U`Qmwc;?iLyWd<4lN&B8T
zJP(3Pqph~Z#gWVTF%1i_J1a-igaZ3e6Vxb5e?$AvTHg_>64}d=-kC}@N7?Ne-NJB;
z-d_G+*xkx3>9UWH-`LpL%DU}tbWu{i(LRRH|EZg;3keBn{Eqe1uK9_}W_??PMIR$j
z7?WP-!orIekPE{8PTSp}K=i13yW0K0>!O>Rnc3m6KlJ{NOQb@v(DL#)WNc&X#6V5;
zIveZPX*QkHr1GjYan#)0+%FNElB_}4inpY3K>37V^lMhU;5-t4ItUVhoPq-B?HxAy
z*aHO!o5~IcB5_|HLr`GnoIcg+?Fo-;a4-YHhPTmIXlY<3-b_nfegvS*yWDpJhxfJK
zg4kPY;9Lpr+&0K1Qb+H3pJls?1DlCP!Q!PEdPDL%ns_6pqre$_h~#54c7~|9`x|av
zsjD`3$#ch;0_m_L^ms07Y}n9JZkyTWC`n(t6=7twW2~5TRSJzhauRzKuYWKN3sc(c
z&hi9qGG_D`qC!+F)`khsTK#~`3?RvEphcJtIw-K1GJ+yTxz3~yqWivF8$lWHOs2#h
zY!Ro=vE)jab9{eyCoL@_Ys!QVo~#5~AnFdr$N=aq*}p5vT3-@5*9gWel@Qn~NQjt3
zDz)sAvp<0zIcVLyW(^+(Dl?%)o1%uXT?hN!<=*bqwDPr)An;_hgmRIb2#hjM?~%eP
z13k4Un3N1TT#^(S3e519(_Ah;_Sj?V(DCr-NShWtan!g@bI!$L2rd3ME;xN_Su%``
z`_(S1T;!mkZ?2uGD?2)gba|QyF9!z&pzEk*Q+UD4#&)tvTSY}fLjwyD84$NjF6I@7
zQXlzC`JmxuhuwC-#~U5`c!Z}m19R$llh^XqR!&Y^Tbn)OPZS>X?dT*w%#`@O+pVpf
z>gubA2$-<`+X4jHgjtG672{sRE6?oNOV_vA{o$eEAwcTj2Mx1iBhD|fHIw|7;kt{y
zzP*-h-}RM+MgraIjOs+?f#OyiZ)MGDd@B{D63~9Td>X>}8o@*%eyFGALwpUjAYG0_
z2{$_E5XE?ZMP}?TVi#3j{Gz%jxVAJidiOW)rLC4KwMVP2EsAM}OP;zM$zX1~f$Jaj
zqM(9-G2&~pIuRP=@Z6{yAp2M`fU>|XuIshNWo7NAN>D-&U)fSvMEQix1m>#@`H%1*
z%r>;A!%+;9HjNS^y(kl`j!kuK?LFr<!#d2vZgNP;Po#>bvH^n16U2-XF(anj<?~xl
zilO1s(o!G(?T3Yf3AhU(cZ}v$Yxz<Z4nWE`@3(0K8Y=3-!h$|GTg75~K}2)`C4cVp
zzLqL#2xSwmM;|88fn(d<-JN>reyN2vDe|p5@2&erSv00-DSJgzUY`D9VRpD^-}xg%
zkPvOFL?((c2tqJBSbk%pb8$Ab_mp0Zn}dUcv9q(QD?2J2Jw5Hj#6++#5jZl2JrOSh
zDmv=Y!h*4hS#nCs($eD5(LuGYHNFbS)YO!80$4uBFjYNrxHzd4h*|g${{_5+m>Bqj
zyK+uydHFw=dnzi<mE7Fy>=Xc(dDuA67oaYa)zqTDeFG3A7Z;Z{k2dne(_h1v&u@0y
z-F$3Z;Ua?Nj{!f7vLXpRiF7L{YdBpmGy&6V2SJM29~&D3u(svb+J@s<l4J--Zi9n7
zW>0gkjO-kbo1IU<XDK&25e1S7MV8nIb0}p8k}bG>W&J0&nzBksA`&sqE-rlDH~y>(
zKeYkbpRqELAQ23P@0Ar573JmHG=iYvmi!_M5n)!fC8m!1%rDTl<m7pBT1Hyn6go7V
z=EUgd=LZ-^?wC3vaJu%0#Kj4+KjRj_<s*y216DM@u(7<Lt&mPj5Pebm5Sz7C3W+RE
zn2s~|oe94Yi5ezJGP*E^8>sHICq2Hb)HX8O&{zMC(v!iqtyTs$EE^+c!%9jkL6c8g
zd+GO+sYfx?E@^CR#SCrItQ;IHrcd?qwatO=6!F3~QVL%VW{i#}g*F~f{TN`v*jQLl
zb#r^}56d<(Dg-35BO~vjsfc6}$|(<Q`vk$fE1@hQiH9AuxVVx54}xxD14KDFxo8uU
zL)#Xw^x;KT8*lITg<mR#BqU`AkEG|s+LD2k)@z-we_a!%rTsogCqr5U*zEaI1qC?;
zzWi<fPhEBO&whdrM3GtbKcg8XboBID+>eWw>n*+4$d=N`Jmr)URFsr2tJA(qv$J&*
z)2gUsh)_|nv2Fr^U(wMqa`N(jy!pja(8Sb@vB;iVO(7O(a*k`#CUK|HP|;O2mH}9|
zUa8IR?#3?#saT&u6FWUUeSO)FH8V5y!0${dFS~V@l_pi}n}h}Vq4DGSBldIR($S$2
z2{~F^LR{Q-v(p1WO|P!50GcWdqlA!)^2O;Q=<Qio-pxgBa+f4bq0^-RASix48v`;r
zw}r!w#JzxLyLaaAK*=6PREy8MG>kTyj2|^GEj_?5XHFh1H8<O=x5!1s0xm!Fkwp&q
zLPfI``$dS8h=_>H&(E8fn8*aHD8d(g$4^2Ct4}KMLXI8Az(C*n+6j8@e%=BsXAeXv
zN_d^7S_3&HP?Od5aPDxZ1P~LwOXu54&Vv<7GtH3i3~OB#&ju)tTNp!#rh$}!j#_76
zp-^DPdCSNLoBYF6P=;1Ah!{hnqiT@&Ow7GcVdrP#b1E;xG|Rg?Ga|`yZAcNV`bG>A
zyI{l99pu%S5MWFT$qwloA4#703SJ7Bs7r7Eyt`W$Ew6Tlv-Qx5hc*NeajAzzMH_&j
zW9KqY5EVt!fJTu+KODtr0J|Dc3nj2qi^l9%s#lmZ7uS#AT;tsu(H2rVGGeNtdZfeZ
zBoyuL?&5IRZgjg;96L<Ymf!3okkGsJK?D;s*(aDw#FI&-AQL*_!^p|Wy7IUBJ&ql&
zwYSshG+(XM6*f1!a=nqqT3cG4tu0p6nNKK|u&X9<hVFatW5U_4){_b3+CNo}1orN1
zcDVKM`*_;AhK{Y1f2iB~`WhJ->DpXU*QNrX2guWR_+D<LH~bs`!-w`f(@cV|HkvP?
z8-hBPp+kjve0<z&b=Y6JTo(xf<&UMn4!2Yc6yM9I#01Y{50Ng62`86w&|MA-3mcXg
zzS?Ma+3kBRDLDd#gty-A?kXxWMq4f}KYM?Fugc_*2o1f>;_(f0;DMY1zO5!N3MTq_
zcK-$-8gGjlrM7xKTzo85Bg_@&yw+=^p2Iz5V-dp*m~h~mt6Ds6m*r(;l6<zr@tD}y
zSs7WRgS2DGIR#mw8Q$PxVmd8$(~~+_LT@tBCaZz(fs>gnfJDgPHNs95!Z+&tSL)9E
z0@yiL8(&{rLqo&;p=gFX9o%uGP00jZG7ASdX|X6?$g-PW5d;EPUyr*Y@<J>XqtHkQ
zz(q)a6864-<NzFbJUl$B;eq|dY-_U_ZrTH4?Rpf89l;qNeN^-e<<7t$lfX2sty^T|
z#5hJgX7EZZ9t}sH5_cI^JY0pcS;o0wy&xo9v-*R`?$)(Sg8A>_{hpM4XCT`9Wm8fp
zMuos)(qM{+CR*aNAbJ+I!l@=l#lEl%Y`S8;h`xCDEw$VV#d!0kR9VVWHh2%w6!=qX
z>*YlWp^3`xC0K+@MU@zETr?5w&f6=TWU<3eZ&Q~H3ceoCQ`sSH9$dh0NSD5#2UJ|r
z2!3LvLZIY#5ayPgs4yXcg+@l%2t0rd@H&~v&+c#qL@0XQjeU>qJi?xm_Om59D^_Ik
z-AdpWLK!_A0z4dSY)dOE9Sesai>k59JgmH6yDVVoNxqpt+M3%1r4<eLC$l7CVq!GY
zG6(6Wr){fRav_qGAqW9wsOh3ADo##XtK${{s%qIe>D`WpW2gU%qjL<Xtm~tAxHZ|f
z?a9+*+qNd#w%uf7a!s~vdzx%>a=qtytM9ja?>T$_&sx8=wn}M7M~9F8?-DD%i#nX(
zB-2$adrt<3wH*Rb2_!0)0u2fb=xwiP&$p|~L2o1uIP!Yz!tM9{e82?QjbJi1yu`<S
z({exyLS`o4jLDJj$3~liz-wbi13d<UWhNX^^xo__x|LaeJVlC2s$+Y$+LD^5XPW|)
zTB2leX$vqmfUTgKn|-a7kh%~E!wy+*e>prnTw01v<7`;ln4MMJT4mwoC8H)`D5|ES
z;}+&n6%O1UeDa{d@KP#AaUlGOHwSjJ*Op>hJLbrj`IC;B+5haK<@M#|#oKEXFaH|}
z;m5q1+KJE8^~PF*H6_U}bRc$3>MVEs4TPP?uu{5>y^~1OS{}FDrKGEwi;N;$Wg!ky
zg7FW!zQTD^*uxOPMtueE{bQ|+K#=<$y0mHrG>lJ!wZtTCtN9{0wN_+mW}Ec$6XD>|
zj^=)dtl<SVWGJ%lP{Ip?`kfjm3oj!7;L%w*qN*h}wlkvf?mT`?vB>47iyD;LyFr*6
z!>C0#X4_U9hVA@o=WSX4%W{2nb+w#XA(#K%)!)E?0V|kVx=b8Zj)k@sAJd+_)kspZ
zNZZAVS|PRgWDGWM<Qp6N{0h*(8OinM&!4nqHAh}O%3r_SvV4W|sF5c$%ggwSS!GFZ
z(zCN;#Ea-3bezb5U>pxCe{MqHQRpTujLB^MoSNL(#RV=d?%2$Xf#n=69x&7(&P?^D
zqaHkqYXpoE;K;SCT{Lklt*x!e_{)<e9$#F1_q?6BJDQF|h^N>G9h4W@`p~f$o@Xz9
z?rw66Vw=(yM$1ax6a)qig+AZh++1~i_I<p+0zjGuMnUpQ#w=LkODuR)fJ4|o25~Kn
z-|G}t&-;bFH<5^MJRkepFbWbM#^Qo)(q3CqQc_$jK4AXjNsmAV_AU;ZLb&p({322M
z8)NgxJJ7muiHOgIg^m3?T$FC29=PU#b-dH{?(prLAQHb;p3M^<){YAUAucB7$)~%p
zu<&RZQ*an`pc6)vcynx#6;n%RRCawhl@;FuoNVW|eDsi19sCnJmKP2m1~i?^v(Rlc
zurm<8a@ss5B2`h7d}ET&8W5AI3-zwFA814^V-X`eTnet1zWbWWzG-Zh!-Sho0yBu_
z%}hrZs<h>DB*Z1P$Wi`Uax`8(xUslSr*2x3YR3Mvr|Mskrh06Mk2|yH%tu@X@lK#0
zZH6W80jDl$z(B8@GPus@sjz(auf{OUsfhv82!?11hi!MvC^4}Qd&=)aW;~2Ri@p%S
ziP-`r9#1X=(O?e8@BIeCeT;bXAULMfp`B})=VpJ{f0dUt(;j@{CyfsJa-)^k%Yo3%
zDt!#2fw-X<Uhph_nn}fd1%V3u&rbsH16y0|u3zD%p0P8>Z0Hyn8R=-TL=!vvTs#6>
z6;o5t=8un$cXxNC?KSwA<m6?iXQse0X~fC#Z58g-9T~oT{r;VsJ3{CSy{#Q00zyc?
z5tyNozl=^jw=yjgt)-2Pu9trzg+<T%g24O2mH%f)Um&<xqLLIA5gA;)VBQRHv4J@9
z2EBK-#Z+A7D4RGoFhU?KNgQ66s}0`X^5paQzxUJ{vixEi84YBafFJLi(~ydX^^e_a
zb>Q|nTb`QXf8Td>cNd1(galhIG$64NhW16^*U@XytOB-9U_Ms}C26k#20!4^wxr9S
zOp=3v8x_&DGz9P$M8pTqEZdyfPo(go@^V@(W^8rL8fKILXhiwBGz_tuSD!w^*@QQb
z7oz&AUU+Cbs0$PEf-jE8BpWTP%1JpnzT3Tha#>tLSTe%frf-H-Pl17fGXk$Rz!oR>
zfDaKUol!$2$GzIey}0PpE-zV9*at<T2(>1d<_+DsW?XI`zkgU3-4KD99rpEDf6gPx
zoQZ}Fi$na(vlZvfUn0ES8L7+OezjLeBO+4bT5`TsCQ9}<v_<|z<mglW)k{WiTl`Rg
zgfZxJ6#A?3?FbD7C{6bo)G>bJBUN2pVd;rLQtT3K-9UTLeviN8GwA&tQF-nyGEoRk
zxuhwhkfzU&g=y$UNo9OsOvuA!k9*Ekn~Y@1#n!^&IIZXHpq#k}<R3t_Jy$6@t8)A`
ze=&GKOr#=Qx}k7|RB9|@23$aNFumLgyyxonmkiEh>+6sRC)J#)wzj&u`ttL&kt}r3
zRB;$_w^5lM*VpfRTK5)B*KiDX`j(l8Hy+T?&_4VdCZ$|43CDZdpsNQDV!l@Y<5|)y
zTd2PVYHCM^hr{9{`=IQvA7p;<QeVT(0CgYG_R?U~O|^iz_~UuT-|wbBR1l0VBMb{8
zQ&^7n6+h(;qY)cVS4>ZkKupmH4swfb$V4wEN13e8aU&9)y1t<yZKNVxVGD<(05xL=
zZBAh<QdB|V3fmz2{PbLulH(0hQZa$T#?%IN>L`CP+sMhud3}8yfSPj6tnz@L%uL}W
zi(FY2B`h4gd~kX@Gcz$QEnG{&>R{5-{-F8!q>o%8ABRTd0!y`^SnALhKxT@(xmjLb
z#s;UPF=9+)RZyev-=fx!Bx>pI{y47N3l0_`9|+F3m-545lsQ-BmY1in+h}#X*&W*5
zMXPjGOMg=BB=NL7VL%M)`*p4owpFMh3=X3jYq?h3-no6bif*%6rT;FisAwa{zbdI^
z5&3;+A-azH+dT8LuQOyk!I#akb=OH{-8P>LX^%+H>!fY4TK?GSBJBfdeL}hD8HHy%
z0~oy*WnY(-dhV(6fW;9D0p7nq7H=E^qdwqip(or*i+oGlij6ZK;i@UBw1e^oLf|}X
zeY<}k4CG2?MRp#HeG&Q#7Wz?rAvk9N@Q{;74?E1oVGP5>j#8G9rZOuJbBS|XpO@~X
zJul-80m(S?lVrQ4F8&gpwEERJu|hR)#;2z4(Pe^)9w>;GI8<1%o87MPrUp<(N7Feo
zQ+%4Kt{s1Y=RCI#@;IXf(<2dlR=nC}Ra-whH$%hxrmm?b8x~AAM&NTyl-!T(XNe4r
zXh=hw-`<{`oV1aW8oQNINTP_1jb~<JDxQQQ8xRD^HLRTjD}l^Csi~IV{qfvy|95K#
zZ9f4fb9@xy{l<tW=IYM^>HsAo3Z0Niczv6~KQj51<(qP;=)err^ZNIS0O=@^JUp$}
z7C$Wd%a{UL7A$N;0YR*vm6z8`-#~ba-QTDo!LY<2*a(-DodDGR7@M^qlAk|QIXJ(E
zTM92MI#3kSNTY#?7hwg#iDw0qzyM$lRA}g#5(PVhKu>;C)5UUZ){Y^K8G8STWYQ#{
zdC1R9N+#Xw!l2O#8N#MgZ+|I{m0`}_*I}68B>;Fc_kZ{I9$45U@zjoF)q&ej>3cr>
zS3mN6mjN8i^=w&9m(Z0n?5NLI^jvDxwB=@?ycGd0KADZf(SX5)O~ua$wjp)Nl+b5u
zVe8jaoDn8-k*D+x*DA^<X%RS0ppr-IL6`o)CFbY8VQ0@m*CXSPS58)H{|ujQ$!x8F
zHp8f?{IrH_gXNR}u0`i9_lL^WrG?#%7{*+|br9ZUh7v5wy;d#hd<X_Phv7@0Q4`L@
z*I0ZYaEGeLY>9&+L&fW&l>7+Y@uv~Wddvl1k51pTu~Ue8PAN(x;+F<KHCYd4MqXaD
zSW)>gG9LDx7&yonDimtX?lF2;xU{4M*uRohO67&1gY_jF&+?mNNN1$gCKORou&`(D
z+#1is$WXPUz*I5e{R>vUtb9g7<5rOGEaAjUY1HVN^MJ|OuGa3f{fS*T0R)tZnTb0u
zEZV&~rIudusP>gTLR`YwkbwyxB~lYUu+!HUm~lcY2Nfhe?@sy~#}rJm1UYCe<0K<@
zBwj~HCpE+Aq@5^I6j;~}506+^W1zK6C1zdz9yqNmEq9l-lv=LuFYb>qE9i6kZ(iLc
zV)2v+6&%|)Ms7zX)>zR^I3k5FoVdUR<rjhfHY5?uGy*{wvPVck$EXm9rFL|*e?I5=
z@40oP4lv07AuL<A3?UP(MD0R~A&MXAAa*tAa9cXMNx(uPYUz*URk{_cR!0ak?QL5p
zh<gbOtG~Vd@f_8^GrGSYQb;pf^a~a%(0`YdKUE3SBaXA<uQBKE%0jLr0=jK6)KVx=
zhdj^Q^%D4AaG~VQ)7@E!;xv@Z?W(}ne@HSCy;g_&^aNj~dQ3**kr5F$JN-nIRD-!^
zR|l`hg%RhH0XM@V$o5%0KBY64qA<Yj=!xbDUbucej1+TJ#j;(NSD7YKsGeqmyV+uV
z)0dC;jr;alU_Dqr7gdl8mxCvP9;DD)M^#)?;(*}NKO3EY>?NC^>F1=X^|s`5)O7vf
z?iA-^QE7W1J7I~Pc)}>6Xq!>Z#z-m_M&v#1kJsj=jYC`?ZbAbIx)IR>a(e;3ux2}a
z%LRQhkf{6xkv24kgKHtG>MC!C3IwtEu+Fy=G4h|gJ+p938)Wl&3d9TOo3^9oGN^bK
zU&t%?%P7QN&?*JW3Tcv6R1~w4lyakv1RcO&W{5@^0(3%-@bU0v48Tm_!w0aL_4zz+
zqt`OD7GniZ(1ZT%9w!Lb?A&9Dab!)UEU9rUaSTxc)A_H=lBuaF&(6)~=QZHE>5A4D
z3g=|vQ`+z-t;LQpGUpLb-JeKfQq#~#Nl7{Qj@)6xnFVZoaB%Qp;Sy*`ArTNB*EF+a
zVRv&ldeV{$3o7vN@SzjYO|H;`w%%S|+iV=Mp?)lWr`$7S?Bys}b+WxzXT-;kukRC&
zI?=geV5ou`G5M4<>F6RM&+RWSz~2$tIJm>cQ3n7mJU1Ni5h+N!f*v0=F@<a_c8hrQ
zE_p3r0Y+pgEiG-$hEq(bw4@aJ3pAjh1Fu$6TEe0ZL2Y7c6QZog(w>`8+|hECO-ElT
z+I){l0RuxQP8AsfBVL#P36YlzfMW6C0|f<r;Bsmn@{;1?1Z75)6j}?a7*Wm;GdI}*
zyZAL_t*t<EgGAtSE%*iUBQOwLDv2c=mnjg9Rl;ilCv|KZIR2DL>s#Hz{IH|0n|$-c
z!9ON1Es#LpZ^Vof>cG&N3T-~7avD0XQ*=Yov^@|~F||Y2Pb!=8bbD<(nKem9EE#W|
zKXXMRVPC>as7e*vrArYFd4z5fOmMZL{2va=OG-+R`JW7b6(L!Kb69DM&t>p=zD?s~
z@Mn66eP{mp4(1Cfi#>;h)G3j!<=|;PPEYr8Y=6Yfbo+2Md3R^7=^N6X2=zHAjlkSy
zYa>r|q|*phXdb4qnlM~;EMI<TAxn4}>0wUpi`;<Z$LxKi<gE0ptTI-HIN^*pV$4II
ziN)CUV6EN%^{C5r`tiX&y(X(!QBqOp1E?S7JN;b6)JtSwP|+M_ArRmqAEd~)4$(0d
z4sbObj*YHbt}lNI?wR`Q9;D;;1IazzrPu5lAzAW-(HJmnIK3f96DS@P!dRjEL8ypT
zb*-rJBi=-hF>$e{c(+^@JUe_rjWda=2@x9s12@^7qDntMKDq&58-P#xyaw{kby)=E
zQ%!jGS$bn5v1I;){Tm2JzWUSBQ&KW)-XK&QPwVgU_v~S_-SzIiT!qVi6X6;1+D}o}
zhAvZmr8k~VdH0Wf_upEhy>C~YcjxNUcRrSuT6%iEM*~b^>Mj8W_zqYw4<1<KFMt{e
zC?deCPOLR!Xl10Q;}GB_6?2QBB}K}kspWr1?JhV;!tj4Po*Nt#1@?C*G-It)Z*MPe
z6w{0^*p<7wc<!O>Y6nntzyn`v>r)#sX7teIW|#BngbE<JJuUA!Ku13JJ)_<?mS|O_
z#%6JLJuLs}aJ%Rq&=fb2P{Pnk6)8}(x4+`r@^d~svp4_o!*MxuCPY22_862UNl~NM
zwY<Lmvhyh5!hiKw5)X^(%kN<Bm)X=n@~@aVSvBP<=;#Y7Dg*;?d>{~CCnwl+2x?h>
zP`~ig$WASwL>pfBZ)^~Z+;DI-O-;=xSYc{KiWfE(hh<vRnrc055sYABV*>Ynb;}kS
zsGuEA{DfLu!qN;m9Ah+kHdbFPMX;ARQZyzoggPeJ_`7<<h~HUc4E&HBU8i?1a>9!@
zU?l=$6EZRX+v%c4ohC*Y9KtrAvecn!>d{(gXq$>b?s~0}iHyu$R1MRbvy7Z@(uIt=
zxM|Y9`Zl__A;PsT=v9Ol11wc1!;WG^Yr;y}@6F)pY+WR+2jTI%DR6EscmmIq=^O!5
zK|7E2ijsthgi9;++Xc1q%=hHM+lqi?(Dt-gET#|X$)VVmgTnnz(>XbDJLl!0p4QAk
zL2t2IdM=zV_{zNj7_I147r`x5$JG;)A8L<tAKzDV`9UEQs2Y|yA0n8PK}M=ywTtbq
z7XP|iw8CI@zY}&i2WI5$?8545&B|eY|J}P$SGpa0)xmYSo%*#Qh0k&$dBDHq-1qqH
zT4P?*f@FiV7dAuo;Fxs5f#96+<@J?Wul-n0Q}m9PVt~|=KgWB8y{ogTs;le0Z9|MG
z{^&HN@^4NKnzC?UK&Heu%JCS7FOZVIF{gH%i1=KN!v)@yMoQ$Sk5aA(-Mpn7Z&Dd`
z<N@NT=k3lO&|S+BApMdpU$GJX^^}j5CsQjlH#V}fv-5cyyLEKs*Unlsg$03^X%}kh
zh(N)x1x(lOC|a0%@#4iY{rHn)=ILbxwEAR{NjQil9C9=UME?ydVJ$=FTm{Cr?4R@m
zNXW>Do><sQP)mvi5-Gg<U*X{H&hSqGZ?WM~PR!>0$8@&u{V}TIJZkngykRmK<h{wo
zx1fHmO`p40V&BE}bz@F}zk%3^Yc|dO{r%1VngLbC|K={wo!<v$aJ?)u4Ft7)DKH_g
zAeZ~i+5GNss=B(G8Ma{dYAzQOzVjQ1ISMW<-Dw$S(I^Rl?)wnsP{-prkJG-Sh)D3l
z35FOcR<uM>BH(UJq%i{nf$e%{d2Q`=TQ@-pyHa?HDno)YsTFnNAu?}%L<H+fQ(NdA
zW9h<y1FvBa;<zApm1JN!$qE21j_kpLATlfPI!P5a#AsR^EC#5b?06Hyywhj1RMprA
zvyAy>G&D4bzqwVlv>YjEaE;A6kb+p*d%uO7>bCO|=knayYOO^@4kpPV2KPl8?#;#_
z1)Tl#fhWwC2oZ5vh4*9v>+EKC_uTx;f%$X4=lS=B&Ob5n*M7*qH|0jtrkrU@TGAC4
zm`%&OaLcAn_UnXet<E2dGa}gh4U_U&N|CT5rwjwD7}I>;u-^~ezjnEcylzhO+y{2m
zU~UW~Utv*x_A;O-RDG7pt*Fux;S*nHe=_*oe6_2Z!HSR0>=kUAKW2i1n-Qx&KQH<2
zDbbVH@Lo$>8ZhT7u~0HPcO?<-y@w8&<R93uYO4mE;(_HY*FekV|Et0Hr%g0Ql`=+z
z6g7$7GuGNK@RA@VB#E-xyaKRT)p#0BpM$W+kLTy-1p}bC{3@4Wf?)6|%!H&%`L-xV
zUr9;JVC&jOn|#8_-~Y2(r-e@+x%_4J@_VBxN(7OqBKy>V6QTEBtib1;fIYyU3-b!0
zgj9@I5Wj7QyLIdx0g<lYcgV(buqwXdqrj3cf%KAUc3YjE2e$`+KKEk|91u>btD7n+
zoE#mMQUVoV(wKLOBLr#B9$&qQ1akB8+<Wp}A2E`yZ}vvu@9w15x~YG<=hBciv|sAn
z17_{zR?jCOvpc7{ySj>zDFp`e1v^<L<0X}Rg@O_T<eQls&S>$XoSYo@s|{GvTlFA*
zu{0QD!BFGhC1+S!@3V>I{x@m<S{fQH_s=W{$yv#-mmOEMQM(Tw5)$Hy6NC8!<ZHic
zzD9<;)i&Hs=X?Wj5UdHbAxgL$a<)yEH#mMYHYCJu&<PG7;k^%NZn3%Gy-47-fm|Yv
zPsVzFcDB{_&%e-6sH~}vLQ76V<YDLT*0fOTv!8_!ygs5;k@MfH8(_&WxLMEfdF(Zp
zhS}NOPGPmQG)4W+puR$9M&$>T1)EUlH3~}Z{kY^&V~QTC2eN4*;qjAGQ{KQmjZ0L{
zS7glZ7t0fe2n~5Oll!OBY@#OTn+BV&<es~-yI?RDj6tA*Xz{yX&8X&E1X!A4c<&oI
z_~!PR=5zNjTwz;lzpid#*F!$tP=StJ9TmM_ME~SmYoG45|341<2ZJZRbx)D&DHvE-
zrQX8V3Tt((#BgG<LuzziWL*h<C;M*}<IFn&vNW{C@B|1n{{%^~D+4K_Z{#3;&7vi-
z3lMsEOab*j)pr$ZSE$$dbQ@S-wX^DnogF)L%5B{){i*#w|1{rPiQvmlj?IjZx!Z5R
z>Z(VA1b3_cH9623d-<%Nh%Y$_%cX0Z>sRi)WnPykG7yaQu^NCuOV3Niq%^kzRzyzD
z^M0~I&(rx`f<Op~sY^c5%2TgVzd%Jz+lE$Fi;brp{unS@bh!WS=`lz}Qw4<4cajLG
zX(WzVM{YfdID%)urEP9pU}O09?G*?i%&R_N3w%Cb&$0|D7P9iRz7w1-^*%rQb~pT(
z25h-s@3;YBBrw1@KJ@F??m!Lb+#p01vqzmpz49zFg#8=W(TxXyJEiio$}M#2UyY7R
za-#{kLe$s7SVT1{Dv^bm7#n(|hCzpmi;G7^N2h%_5Qt3Tv$2B8<&2JFn4*j=EiLu+
zHyd<dGheg;>tW~ooZwe|p)WEwYoplL%-*{{?&nX(MFN#IHGU`WBRzJUS&tW60(^XL
zl?ESd$H?<`xSR|!qc9BE*RQ{Iy8*svGb{|d!3Lcxl#4beG#e6AFm{^J&r@=+IBRNo
zN~h)HT;O%B+xPX{?Ny}@_oEVWEgGqerkCO1@p(+Se=?+4NUj3xDWz7EVfU*|=a~`6
zvDC`q8<&p<+FR_OW!URx6!Y(|uz2U`7KRv!{)t0YKlfN9;qNd6{t%h00b2&Z-XS3(
z>2mv%2Cn;oWCG{)WZ`;`Wj_T!vGe?uw3U_B)S4#$2=jJO<Wh613(G}t)~Tj~>d|I<
zb6LfMD%m26P!tAh4#cC$WbKkvieN0gD2?6hK6a4L5%J$vW<r>J3lR7*g8lSWc=Vv^
z=ySMOt5BloT4r8{Uk8wDS|5APZ2lULGa8GbZ~AkHEwg8Ujf^hpj&~&-gxHfVI&(QZ
zS3doXew$2Ji!-sob-kM1SF2KQE1qn8kn9V5)CHQ2B&5BvLe>I0q~+6bSL%1aL8KG8
z{00smorP0M+90zvPvA3bbgF;IjOwAvMyK^cVdix_-!auf3Lg*|5Ghsgb-mpm%Q&%I
zv=>A%8u+q{D!dL|R#^?;qh}4?Aq*41WC_e%*Uz1z7uk{_BHPf<sO#KQ=6BNoyL_LV
z$FN|zLw>ZsPr&2lVrO^B)$@!P65co@Yz*DFw=?_ScJ}f9rODNGCf7*bO<qqgXW<}1
zRQTR%ly}5CBvTQ1PywF(*4O{!$n3V6X%PYDYdQ`!uSAF!m_1?0YS6Gsx^HHpnyZaX
zV`=FRz*&_+Cm#|TE_8Qu3lr3&@oY%!Y1f+uLZ3&*O-5wi4z(SX^mwpE%-bnKPW(O<
znKdaIYW|<E#I7zjy5=acdBRFYbHHj1Jl_G+ZUtS)Gyx%~rF2%ksQj;?9>88Ozg?Ru
zvG8mfI{ZXG5%1sb)3j}7{L}n?|3d)i<!6Rg;Ga6SkJ;<wHePUL#DN<wR6>xaG=wrS
zjEL*Zlr8D(<m>QF@#&*yi`x@Tj?f}g436K{&0YN}iTlRmis910E*6NFPZ}UEIVx3-
z_=|DIHii@(R8Z4=d7VfOeA1Bb?+NWYIpAEvb#*rE1Z|G*>%+1506LU2ZHB-z3rHvd
za`Fqam9wNP`zl9qj$hzyzZRnjQ}sbr(Tx^Q<hnC!CXea=HJzq!UTS{%?StFl8kUFm
zRfg?1EZBh|APvaXQ_02;AC{VXUxm68&8&UaR5ypZx6+ER+%z6{lOKXNM$#1+nqDVf
zot7U@*{{v{$uQ963w`0`fjcEliqyD;m&0#9I`^cvUa*r<dS){UtSl9z;L?SxL3}BL
z4GOB4s`*IH<CC60rohWE?t{X1u~Adnz42hd@!7@B(>>DEQBEpWq``<DIyC=5%;(|o
zu->#O5ieYzI1j$fh>mGJDgj2KI5R%I*<o)WA~MkM&71=5zo_)~c7Du>;>j_$Ul>k(
zZ>_AB=UNuEJV2osiIGqe5M2s5<hT63It312(L`_-o6{1fN!m7K#ev}i7OCDo$e9;l
zFw@e~+Hq<#|6x8_MosaLqIJlc3Ijn_PF}o!hw=?ey!R2<lBXvN`?0*tEVqUA^;J&_
zU7X8~^UwMO!3gFzvH|Ya_y+=X@W8;pjv@}a7@mz&Sb(OH5^Aqz?g{g0`{m;+@kWmT
zFK=dyUXmdb#aX^3(2Wh;Nh5I=^h1$1d<GgC{=k~q7bql%gSYp~g8(PGmv!=OLl?k<
zfUD9V9ZbpAz)2{=BBArp<EYp~n_xskU9IbV`Wp}w*Ug+d)ACQX>aD^-5Gz#Tg^M(7
z<v#e@DuAlEY~GM1JF{{r{TpCo-`*gihsdZ+ae|i({pKw6dfq_!cd*Y`{hoyoQfQy@
zhieYkqwq6ntihN&P8aKK*7-gDMt+-THwlX1$a8bN-~-3b4GjSJS^3+3HKvs_m7m$<
zFTQ;Ay%!<_|3qZa=mH)Nl3pYcTScZ}J;Dnv%=LIxOI_9W`1pGBmbU(0rFFFKtM+Bv
zZ^r36SVTxOhq{H-2x@5JA>f05?a=Fp<K?<ClQX9w-LZ>R`fKRIfff~W4}GPJpvP0r
z-)#o>WsaR~jl<ER60R^arE;a2+ns1)({oXOsrUPWss0FjiJmGiO1S`sdP<y0@#Nbs
zcdqL3m~uG&FPe8qNMiq6snkC?`@ai(ctG&M%}Qe6)8~;lk%A=K4;}!kDBMQ^;e6ZJ
zA4z{Xri6gd%#}6u&FzxU>HfIk1fnME;om=|$(aR28eDxNhq4lDtZ3K0lBp~%do5IF
z(1&31*y8G{$M$w$VnIRT&W`B=_?G8<(XOf(F2OMngRU$q^RS8qzGh`*Wql=1K0Z)c
zKLuOzWM(Y^cJz?AcsStuq~@cCd@Q`_8W<4EwvqY}hSnr3b34vIRS6P?Q&i4r+5q2%
zk4+WOXmM}sR0443-QD__RIw;N$--HVWHa!>TArSOWzZn948$np<XqicUwrwUB+&#>
z8i`8S#wW)9+brosbpUUHH|OF4zoN48=*N$~v!Yj_wGPFUpF8YogvV!Dxw(E!f`@A_
zZFBxIVOlO2JoMiH1oZE><}1yj`ml;}{yb*1$XRWeU|4WgG=AFV2*<GBgSF$ohHRt;
z(F3G<d53-qECg6HnaD@UQ}CyF<NbUD$-WTmp&X0@uiw!@{I|<jC$O7YymDa^{$<01
zZ}WM32S^)FjHhx;o5`jbUr#6dZkghInC76^AA%_4!Z=VRZ1M1!m|0V?87NbrM);$a
zn?mjKqBq;}5nN!wf0xmrsP}3)nul?O3P*NmK<xR})npy6o4b02Xqcu$nA3RiZa)}2
zEB~9MB+@@PqOPidgF$Z>bir{o$B@8M`D?o7)Z28CP}HsGaKs?OMIW0cO>(7h%lB)+
zQpsIpHkft;Cqw`;4Z#(F22OAZ35SXz?sMdK6)a~F>ukwL17l$BG4mN{5)d;{R26?q
zIC)FQj;O9IcLRxkz;T(eJB})xoSu$Th>=MWl^nJ#z{}%TrvS3CTg|pQQe)#(xQNc}
z*%!9953z_U3k&ra5=RnGdx)?IVMai82|#t^9?*XI=`1DXDtGa4#$~G2rz7G7Uhqjp
zv5lXdn`>ud<CC}rJWu~u%V8?2gyD1sWSmlNr}NcICSS_l>RVg6IXQtc964qhOu8tb
zhnJIs2Ns151kSb0829bM&0CBTP1Wb{yTq^cxyT#GpEf&$8DU6^__YK&YI=Vc7aMs;
z33h4dY;3H~f!;PK5vezhny3W^D+Dbd>pXF~v?`Op7u-qRcw@n-lc}SPOu(n9+zyeO
zh>a`FdE*^%$_{Ol4Q8PzITdVCFQ^je%3+9&0YVx#gTCN7=$8`jUu6D%<z>hM)`}Ht
zsd3M2ve#FX=0b8VR%*nSp{=d`?_!IKmyIp_6h(A1@pf!y>)z`-;9}U>+V-ti%jjy<
zI||*DKpO<^D9~!@Rcx|;q@fnFLS$f;pyX<pGEDr*i93`_-5r;lSO&uSdqBqD1k#v2
zNZkLXqb40wE+Zqsm*`{;Q9kMhHobljS!tHt%$TN`dqNz-oOaw2Pnra_M1Dte?Q~YU
zauVN-$DPQz(T4K~6Za`v!;IxURG$e0+r*0+Z5=O@_JmbLc(AuM$u=TCzE@QXmNF=W
zAyu|Asb!WXCHXzWgNBAAVGMQtob|9@@*vM`Y4tWL%6-%G$4DIE%uwxEJ%DJpu=Ie%
zKvI}c9T{#58+De{G?$lKE(vc#Fk@h+EiSEWbvds@TUw1Zho5wgrS3m|0hk|%z}^PW
zf`y$bnlF6=lH3pjYNF+THI1%Y02>wv6iZUv7TzI*3InmyVJDn1UHGChxsv`}GQ9=t
z!^40tSXbf>22yFH7zjv+$lhI>*eP(qeS#Vq?lc(CE(qQI7{ZV_M)l6lXJ`0%uV;0d
zHa<Saj&sSAqLECn<-LJqg+ue}>)P5cPAADncoRXKE?SluOXl#PpmdYb)xWhGhFY9x
zk-$zWm2|)1oi44HMnNk()ux!o&&A~qym7!4s7!eBdTESxM=M2hIpxqw5vdG4;%-<Y
zi#i*UO}Fy+r(UY(!21wB1K;G10Cp1HDSxX&YeYA9**ip2MlsF|=)fjgoXpHuy&v!K
z#NT=S|LOAKaV`Hu+CLl&r;FlS-SP+UETI1b_^8s5dHC?#sJ(Sn!?&df_{cIuP5LcF
zhB|a!M#nUa8JHv5pzK!oWjys-EuF7V%LfPW-!?$MX;>s8i4aC=OEh&;`pf)d%L^R4
zVh{RBzY_@Gx;o4e99Q%%#u{@{M~#Oz=UiTd=UjZ76g%iNOW{4XW?dW~fv~{X6aW1R
z8(Gz;b!uG5J~389eJZ-+f`NS=ONWZdnQ!v^^Edn}-7WPCy+`(Xy07R@5N1lsmH&0$
zA3!%Ia}1ZHU}I%Py?#YB_8L!-My<;<uh#}{wQ=<h6TB>QUp+lPA^x9xH`wL#DUNc$
zYBMthfW4_HDc@b2)hnCYOL&>N?2YU;B~dM?qUkYu*;)Dc&L3Z$ot$$2_OM940~~Fg
zB!;u?>^0~zYv5!R7-vVEwzB!VS_5FCP~viGRq7n2@bK^m@QJ-^;;L)T0QUu`KvCwi
zbBUJ}uU1htRZ_A%afTseNpf(oU_pzea23B9DfF)mN}aN@wzJa@HBNO5qe?C>Yvrcq
z`r+o5I$5&t(rVPFSmvKEfah7qgn)%R%RvOC0F3|{><I=na%XmMfd7rNMhb>*DXBda
zB$_gw8+IfiWTu0$?Ck-c74|(UOj6F0gK`bY<1~!lIzmkkqX09U%nPBbIPfc?q>v;p
zo=#>3aSP*?$KKRjq7s+|NpN|HDL2F;HCo(8n{#P(R~LZSTb>ZCZ&IUBB5V}nV`;;A
zgnhxKn<n9=^;L50Q(O=#*i%b^$@9i798*@#==!|q&-<{?5qO))$dM@G2~|!y)<4pe
zTf_yogmF6lO;Fjlf*boq{ToU19&Vrslp2bOXXxa=qD$frdpQ5wD`(^$`^qYRM)_!N
zI<_Q33|Plw&^n4G6Gqbh5R49twP_R_xT{En_}8U`b{Y#V6h8{KPf<3uGFsFUncx95
z1lTeW!n*pBmv>|VpU1Ap@rj8%9o_*`uf4s!?G_kX=;`Z7JB(@b4Ld+ndT{d4NMnf}
zQdU)!^%$88%eAQ|IVU`f%FD^f$jpR5TcSqP)*YhcXyP!3&&-s}Q14Y{bjkOya&uD`
z7wJ&QsHh+(Cx?WDjH<xduoIWt+Hv9F<m7B=Y~8Tq!wf;~Hnk<Ih&~xB5BvyJ#9@h5
z0H_*B$Y7JAA`hC>GIE@BC_&4tN^2`=Y3bZhW2?+V<fk7$eqd;cOUUld(llYEFIi0i
z<XuxEniYE#B_$;klt(A_qev1mm;j<w5-|VQxlG&zzhi78jUh!4;fvQ>nMePs>8`1-
zcjC!kFw5rJJ!CPggNEa80-|({M}@;H1FC9(XAK9=y2BL`7C)AcVU%hhxJUvMG-TX|
zK;>~%>P-hL$BJ$utgcVTYSOR<P~mRZvjsL0ODOM*cH{Hk0w2Rq#>S$tneHDR3Z#;-
z@fiQ%{vzUS5^no`jrAbfEq0LRDg7^g3sRTbCw4k|r`k<NFRQJVZ@H7l;Zu75g{!Xn
zi!lvMk-I79`gSW<lzQv0(uVd5mLStQR@c~ndiJeu1a(WzFi5~*z`y4WQHo(<R?<T{
zRo?IKgSL|cH1VR8noS{_BsP)HS!u@8ljaJQ$k+&?da~*>ws*`#wh-^WfgQz7+1XoK
ze{<X&1Ug1)>j$EzfvCF&Lm1|%h0$jEdO(`STt?FTe0w|Z!nzed!3Yo$G8QkyN&Q=R
zAOzV11`}byj)7ooaiyZJs5lGEtIzWX9_;ckeq*u%TK0Ixo_V>s@)T$@B^-T**N!uL
zL!nS|5_|7sI7Ew=GBVPqr>E8GGQh<(_|!^9|FebQ&Mfe`bF;gf|My5%&O_s=1kjUq
zc9xZuCo>j0$EE15x8hnlp{J$>c)Abg`q0^<iIQYYJ6i0wu+V}L{awK50oI3i^Q9=A
ziZ&pyghW$K$rMLAkP=phM*-ZDeKjLDBTmXOCZ(8Y9?UU0Lty(>%c+Axh(3cLpB8`G
z5SSrLyZvaJUomkfoaDn7jGIG#k$}J9Ehs--7Cfn_0lfi93A36nyjQ6}gy!gB_!oBu
zJQbb5ar`iwLi3kgXEweW$a_>E{~GCpd}5)rb9-PbYLR`WX<%@55S^y@2#GF|%!l$2
z|DehD@47Ge?r0`0C8bMJF#J-fRYSO=8)P3nWHswU?#l&}n^58gjR)HMqg)JakXJ{*
z-0DnV`-f2tac=pdTP9DU#-DyVCTmwob!JeH3^PS7fs8&ganV(sBT`xESL=!3zmJw|
z+dr~vo-7X!FNpnLK+cEUB<7;ieffAYM~=$ZT*WW(A?3%9qv_vq%?DHl1X(N=bsY%=
zNmWb>le>{c+mZYULxn5GY?yvmtu|S&%$ba=|M>$1ywZAmtTM4;MQ7nmU56AuC_Ewd
zJ<CKbTfXIX?9}wztEs825&n||DODCU3=2ByI`@`hM30z>HM1zJl-qFX$l2P;+u5<8
zP*~EbE*mX}vc;SMp)zA1G6E!lEJ7e!;>LeISZGi@7GZRCJ+_?rA2kNoF{Q3y;Jyc)
zFMxn1YFY~qG#dih!?Ce3K&>d{<x&hh_hgVF`H^BuPPx$HU<?HX1sLr!VkT7kgM)*`
z*s!w+^RD%2BBTBekCz%fZz&T8qI3rq4jg9j;*c9v6%`&VFq{(mEz0d5+mOOLvn+zV
zbFj*r6rFvz<BM=Uqt0mRZ{O0v2_7+TvSi!VZdU0HG!-@VRJzzfhR?&KjQCkoSa6`)
z8Xf6|v{u=Kp~xX~^B=-Hihg|y+GCbnYH9<CWfhiuPmJ{tv3-;Kby7qR*$OBgeWq-Q
zS3-VCRV0dvDBAE7f1*G_7B)6~z|FY5y}ddLgB32shz9}F?>@PAqub-wRa8XI#r4>x
zKz(9vK_^o>fzZ_S(~jy!r&tii;)g6)SS13^&#c2Km!{#{&h2Se+jUzerpNu1ke(+A
z-zwr}-&<c$Eo*VArnnJzdH&-2&ekD;&y1?(cn@#P>usW+I5}GBxALjb`;42X8>~Q2
z+~Y72H)0b;v?toX1IpVk3L(t-%SiXDc(~@~)tow(T5G`L>f_~~7Ndc%-Cg6m33ftL
ztz4iNF)uG%OBGLQM>e{%K7Bf_cDi~AXe*jBKYCu=kKfl7#0g0c+Ew=PvtvSw<crP=
zdsv&*R8fIE;08(r=2PU?_4s@I9UNxQ9<VSligOzZE4qCDd+)q9TrTFpoU08D&H%j+
zl+-X_$;en+`w96`;BlDhC<$Qu;mw{VCwFyqU0ht0U|2!REtnsfQ&UroZi89&%tb2e
zp^Mhl*0KPjU0bBRuyjmpEF%L$$u$aEPxyCiKSaacvrWC?<T%VB(xl-VMERVg0%ppX
zQt?}Qc3p%84E6@$K?G69m~JBma%!|XO$OLTNe&Z<fgAymPE>E^#%u=l=!pY;*p^x4
z;X5C7x8{Wd(F7hRPlaoid`*=k%DfqDF%$hs-mDVK3TT@E+T9%PT2dZt{cb+^nbWpB
zu=s>tE!gXXuwS4BL2HzWF08DnX78EY@SL2UoZQr65FVzaAKa!VyBa<bQM<>EF=PD^
z7t%Gd3YOaor83R@12s<X%?9ho*9o>D=z&@~Spssfygs!17sRg73bK(B2@{hp?a}ZT
z7mFpsQ4*#VmV6aK2zN21LQ=UD9wDEurRh=xZgI!f+@Gz3KSeBUFQ{}hO%qL)i7INs
z^xZHz`^z}#G=CW~CmAPGoE6%)RFqpmI8YX@{Y*(o&dU0;0kOQXp{t<*@GTORN6f5Z
ziP%_&-{GSLSLA>-c7HD5IfL=A$zBB1W_R8Y0)_fg=)x6(9x<}JhmP*o^Qi@#<N=kh
z?FgH|IEJS@2Nf?-+B%DrA4HuC*c#R4<x*l;6ljqj-5<{xJa|*{T3lf<YD=mEGg-1F
z09iU;e>*qFS|vXU{t~dL@1lncdIwxpfcF7pxZ&@CWJdN|ySrqUbvXG5aE)_%c0YW5
zMU0GgobAbr)9Y}s@<|=P{cS*KMf!kGxEOD}NL^GILe%P?kaxVJQ2VNlV9Lt~wI^A*
z$Ie8C!c8zWxOYRDOU~dG@|9BQOFtHhndE&2w8F%C?9uaEC!f1I7Pv>^B+^%(U3$Ss
z2}mI<tyF`+E$N*?BZsj7yIANHj_l^YMlG6oJqV7@>w+2E>};V9ldEy5-pE?1jC2fM
zk2&tdt^)tHgTm}0U{qVze%8uz6SR9>SUJl$1OIjd7%|&ILX|u^CvIV6NDgZflFUo>
z&u+Lb9I%BTD&lJNPQL{XMo!M{wrj2H{-cdq6K8}-_=Fe?Eckh*evpnNVXWCyZs_cY
zKQZC?B>$7pa&z!u|F6a|gTJ8(AHl<QbV+Ol?Ef0|^Ek<K!1ilK2RYUfVbsI-9CQfG
z*ik0<NEgJcCXXLc>~js#fcD9H=Xyf7@FA=6>gvC(bwyQGRY1WUHMIoB5N700>r5gb
zZ;XKP+88gKNBm$whAbf)%?C1GDV(~ah~efb2}3WEq#!e*c=>wh!VA=)Oz-CcBV~V=
z&FLmAbxF-xGRxclml)L^Ab-BL@(12f0F>67EfkTH#;Q}*^x%4sf~nZP(|UUw1q8>l
zR%+-Yv~^?>4~=lQr*R2!fl5%oAUgEi?2Q9l^%oz%PASw#`k>n2PxBvU8tUrYIn&tu
zc$tN`0bfp2kIjXlO6EXp)%<&me~#&s|Dx-Y>Xu6wuxmyn{19%;E>6yZsL5YdN7{8#
zwb9+>NrF~!(xKE1d=gbJ)~h4<N;*&=GX4_?r(WaW7Mu$sx&B4`$%ip}S`2A@FIV#5
zBmP6qT*gsKN?!gFEk>(x+$7&r8R$`|q0rm$?5?i90C*K5f@9<W4;18k!(&Gibr@a!
zbR6RU6j^WY*Dyr<+^LV)mZ@HUBh$LMDzXzl>6`>!@#W*izRKY38T!Re1LTE=!QHCQ
zOR*V^9@THZb^2L_z`NlYzKY+_Z#Tj`VLRtqwM+c~&2+jv+zW3FT)&gIjqp1)U2R`X
zuVi`eh{LVxsj@i<W#%`|=hZaG@T*H3m@BFq^9nWAEv>9vt=26>Vtfg>M2*}qEP+j4
z8@z)UmM$QR0g}b}0IMM&uw~U$IF4_@g~PqC76L_KC+aVokv%9!BF7%7wYFycsDq<#
zCK3i~i#o+)j3H4tu7GqTAfO2J3jj!;U7EGIQ__6G?vBNVOc0zhH%4x5CXfaP@&z8T
zmYJM<?0noT5ycs(U&`S4?w_h|@9wOut?D=I-UfQ<=a$t~mHBx1<FX=GnRl^8777$N
zS-4l%m&4}%wb#r{PRh#4T3Gz1W``7Y1tq4W%UZaU7{OK~Qm{-P^C)q%Nr~@RCZJQf
zK>rlt80!wmBSDO%eN?=?7-+;V#<OUgy>XPXK}?HOgk<*FpjgTW=aFqmh$5}|sidm=
zg3yFeFx(57ONFT-^TiK!Qc-?1iK4pYOj*s<+{+7Z>KW}SxRAIgCV)7d1P%~U*4AdO
z;P6+4cpv1Qjmc34{0$1$F8=L}#Jlo)T#uFJ)#uAgeo2IZ`|?p-VWpvQ1k7K6wwf0m
zDKSsy;(^h!SvE+MJL3hXAW4o>?1nr~R9nn}<OH$N?tdVD^li~%aLaY#Zc0FgtDBQq
zUJE01L2TAzQSdk^2L4wW6AA%KJ19p@GpvCUba!w1cK_Sl>k1m#hxu{#_22363d}56
zH!Nk~C2i?fxc+!2k9cYDvR`|G>|$J;(8`aj%I;X}oP>l~9~z(kwt&=-%G0;Z0YO5-
z^W@YueeKwV{vY9-eX0&TxRt_x!Xo5@wHh1=ez59HQhlY|8T4iel`l*Mn@856Q>15R
z{%vn_eBv2{XJ0058-R=QD8-HDcmKqy?lq{w)@N8-S-EfqKKF%vTby@Ov3UP!ettge
z1sZas@6HFf7i=$V(f9UdsljRy7?VlvyGQnL@$lfngmKtPX`~hG75ohZtQPn7@ywV)
zSd&;YCdGz^+MZ{20!G5h`{vY2>nnlIqN;FVO6akc>r2FBWN|EoH?$8~UKr7nON%}F
zhbeKLQt*g^(H~-U+SRRXPlYTn<*vIhxveN{YC}RXT~<oD*tpCv=FzZs1j+3fbk+ky
z#;8ABW<!TUfw)$jT-M;j&$z)V8g!GrCs54Klx=jdRB@{ds^qcJ(Y%)g)p5Ojy<;Y!
zeoO>oJ;bV>#^U=g0xwFRy}d;>cKX{&)%Xu_w0}rO>h$A}=6}ij0eZGOJ?~U#u`ewX
zv~b#;DPKKsJ{~~1D3DvOVkQ`=s9Jhp6;4!k4z(=52iR$ea&WX;pTxF-_Tg)C9pT}=
zVx%?_7+dSA5(g5){xi5%4T33BZQu02!k<E)5M8i3vPxbZMGHlBx!=}C{1dt^64F%y
zmP!n6T>Gk1cX>ghtv#W6sOEeAL6riw4#JR2(h#D&H?a5LQFfvV(`(fKu`xzc3}aGs
zLZgbJlB?DlNN6YKw<o8PlVK37`C4EGC4urYFcJRf?TWy`!_(8#qk3U#qRsBZd|@R@
zWP?~*d2aLM8w#x~(a&q?z)xq0ImJyH4Ef~Is|gz(uD_)gj|5sVfMVPl-EIN|5R{90
zF>Dm)vj-n1%d7w^r+U<zF$oS19swK(!o#w6kfvIX3=y}vwyd_T4R@5<z$SeYtIK->
zT}9`(#Hfz7RbSO?=-u?3nI`MI-OoZ){(Dg59f_G0LJMmITC!j0Vmtx~ev}~yeAbTH
zGp>EQA%Kv4ifiyt+65+^T_^R=-`QCYAhs<k48e{TN6yk3)>-AS@f`XLocb+FcB729
z)dcha&soSO3MqV1h}y=6a|I?P^m&YZYer`6IheG-($u<N=3-Cqtp{Dk=pdts!>Oz8
z*J&V-Nr6#VoEYIS)XRD@xhD~?kjJkFR2;2~QQ3zEqOd1fX)6r4B+m5p6_JCfkb5nO
z-m5mQ%x=xQ%85H^J^ltU`J{R{44pn^xoi)L95Lr7l~Xy(^3ms&+hAzP5qk`Nfo%0J
zZK$%T8%Lr>kJL0qou&Js7&QzVl#3z^elol^6qzV_6%6#J6Chp$(MS72nEaz-LTOY{
z^iG*JAX)bwHl>j-J>kYs5iy7?28q-^NZos+MmVf2<*wS5AtVSr=2x6Hc<oevMG%Y_
z+HK7j4TPuA{BkKH9-eVR`9)H$5GYnJ?<_R-a)Jxi9Bni4pj`KX?CZV0mZZU{U$cSL
zx;#0-B_bj%lBRL(3qVgb`>Un(Uok{mTe*a&bc$`8=X0PSO4Cmm4RSx1C<X;!f{%%F
zu{lKn895pm85)97<tV+y|DN0)G}B_D=K9^)=@Ust+6L+IoUAt>_=u`t!j`4W)G}mD
zg-htkJ9rjdcw9U1DNBVuK6mp(I{_I>gxua%kx6hT9FI#x109?27tS~BNL9_+(sHP}
z5Bob53_pA9P63kOrbA(0Xeld;p8xu$Dd6_%=`p6u-gsoAU&}HL-=YM0^oLfR78r74
z0o@8_)mvn@ukS#o!cD6vr*l*xg&@_NMlK+zR#cbQt=TYV|0GjDbw^O<jRke)7JKNN
z;A&Sd1F#4H9{9dattcWZfV=PT{2*b32X*tjy8@Gdj(wMztP9GTSN5Oe+N5l3yA0uu
zv{{7jtnLU+5bD^otQd>VfhS~W;5~T3s3ep-k0IVyugp0=?Q&4fM+lvQ(82>~8fv0>
ze@}2GE34ZA=h!UO>6~^G;u0^oiY`Yw(O0*RxnBEP`tiEm>D+BJl1L$tkQiR=xioO}
z!4?JAg?_T%9mknmWvzXS)1*Iz>ex$}XDMVNw>3@F{xR+=|6^S2@Xb?KMr@9yoFEAi
z#$1vW`W=&((T8DsG(YoR3LygA!xRjY5DqHMZjpKGoAl_h1qES-xP#vlDbka@4d)-U
zDwIMRP7cnc<>g6P`9v5rkqk*%gntj3?7ZK<W5R{Q-3J-6JZ*mjkJUM{YdnFN<4FRd
zOw`nt8nVTKd;pMFBq!g#xE7JFpFNeO!63pTxb^a(N;U%!QAZ;pwVI?x9d46(mnri)
zHPxTYjNF#J41o8>OCz$1t{O&5Pyf0T@3%NRYxw4XrVwtS&!}FB%frZL9b-Mg4U*hh
zD7y13=F1waF#fO?`EF>*Nh@3`c(enXfU+mn$6UfQddNL()li5(3emYh0$HMfo`aMI
zX4X^yT>U})LHCNTd?x91RUI8b$y$O7x`Ys|E2QY&;L*|19_s6n9}=ah^e+ts+hrx_
z5Ny`F?n!{6+VnfR0GR)sK%w?|N85~U7>2Lkzxp0dX8im253oyatwFv*S$6xGtPk+z
zyy#3Zi@c;4jFl0DQa^CV0s@O!AvOD5<kb56R-Xc{*0~a`OP_a$tSR~j;`)o;kmuTJ
zJB>M|p4<9|3EO}Z$TnNE%rb^*vSJ7Z>hBl^`oSvcxx80cS-)-l>E!XaR5`hkV?9Py
zP5mM07j49@zhYBRyWvUC&4Y8%p5c4!`*_$@(z&ZqY62`PNtpg<VM2J6mUqM$>47K8
zF-C}J%IGm~^q$=_cr$lER>!;r|4D-lQw)o2_f3w%ho6}0LrNuQ)}vtTbdU+YWd%xp
zbZpvBDL;zw+qVv&kKtdej)OYL_6Jyz(cO}&8MN2YS4_;5uL}$DMBkN7aZzw-VdPRn
zBU=D*5s-&|Oc(>$AwH)~tJi@Q10MM|<#8KJcC?eLtGvwIdQHZ^dO1K%3dMQ;of~vV
z=adyAJw5rkx(qIzbJ9iVG=$0%h#+l`j-LMUYOBX8x3p1f{?jO%gJ%k(CH-(US}c<=
z1v3TQKfoqjk#SH?D5`CrTTN+Xgqn(qYMrx@I#PJvs-8hXP7cr+@*$vnLzOJE0vr{`
z=55#x4vu)Tr?Fi_Ve!#&+$hbk*`&gm;*)Hvra?lhfUgbcu}9|S<OMA173?_d4#Wl;
zOMif-*)Ff9sw#w6jVN;t-m6AZdzPXSAT^SQq8A&;N%0FEk@P;-#sAEty+l-GE^#yT
zxBu5y<WJlC$IqgZ8$D}^No#_l=vn*VuR9ot@ki#gS<UVKZ+U6&OP`bgfmrfJMpIu-
zca6$c`*gE6IOXPSq_vYJK=aJ?*>o|`lZwwtL7)Xk@c<jMyN5GfNEbJR`)}QHX6CbF
z&EVbtt!0K9>&FB3)M@E!rj!7N?GgrF_TlT>A_=toO^ka6n|I)+$1gmlMNuUN8U_X$
z8Wd5|3`;zA)W%WRK>_Pad!u7Q{XGj?yq{~_suJPmIPw@kZuI=$FV$`!aQcVK#-U9Q
z@6dyjB%$$NS=s5+(-W|7u;T%uF7QhxgT{l+W;fsnh<}R6lT*I`P}D1J0f_71z^onG
zIv}ioJ9dX%FDpA6hkzhGz#mz>2zBE{TFF`>K4lLcJ{l;4NV{y!4~Y!NRSTN@)k~$l
zZ|Guf<Y#2+K|v&eA@`ekR*F${`%vdLTP3*be#(9a8R#Rju(8_bK{1ox`IR4XeLQVl
z)qSi5)axODdb_H_pWi;Fr{&{+uu>NE-ldzq5pNLz&zmA5CY#AaN2&vZgN;>^m*h~n
zrTMTbha&2xf|z+(?oXqMayrd0ROr6MV+q_P$)-5N4Xsa0Ckx-de;>X|v_!aNn1i?M
z6+xUlL-)ZoJr}^_jS$ipmg&?l8H;?{FfF_LA4%sJURSq8;n<CBHnwfswr$(C)yB4+
z#%5!qvDGxb`+IKwo+rsUd+)R6T62!^4vEv__UOpfuoqZck$q%y+8G$O@FO$L41;B>
zZD%&yO%f{^Zarx#tVJ#{2%?U$B(;S7S`N(%Oj%>;25Z;TbI$uv+w<uTD(MQdGMlbR
z<~Rxz%?Kjd2h~{qXVUJ3PEY*S)mDIi*4WWEtW*f`+~h2sv11eu`7;N=(pDZsh^?wZ
zTb`Cs;)(=*3y?()%gf876S`;;DheW#aM|E84f12djfMaNl@Dz^ZN+C`7#Z468Xyt#
z+3+eaSGfrx?m%%ISuEEFIyXvcT%4SdM(t)QlT;PW2zUq(jd12by2{)|X(hdQKXaTF
z>eS>E@IC)=q2~3Y9+2BRS^;~&L4LgB3CynD6Fee3EXc<Gej+!;aZ0oS?H<->%*K|Q
z7GUUO&5fjt4j>Wo88TN7DSjVOS8;aS<R={j6Z3`K{Q5_RC^(;80-}`q_CvTRUBHzm
zALwgq<kF+Uk!5?mqtBz3wOU|G6%FO*BaMxX-ai;b?dY{uQepcnZ4<<gD&afw;YV5A
zs^JG%0Ura{0WfN6vEvKoOOw&_#<6K{uE!LuEpENfcHhV;Dt`NhkjyO@(oTF}5EKna
zwgCJR(C9#nB!g6x+cDwEm9R|w$wwW^2!3N)q7x_Ls!eGC=*#bxWK7RjimhRHMJk^A
zZeBSTuUxl=leA;*!u}?hyC)lSr>mlA#Ompp@3aWo&gIs9+mv7TRt(@VN}4B2W!?%J
zo-5&lLK;moOzHk2(3O`h@K!zDSiS3eEAmXp#4t_$!>*11l|GA?Jh88JBl;ZNo{#se
z6*I-HI{6ts6u5;JvGK9tf)25`>Xu<ivMh8e&$lKG$+u{%rZE?Uk|M{?UEP6rcQzSx
zh8as01>s>V*N?gemVFB7OK=GZ9qcKtUYE1Wtbd5lt*vR1<4be+JL_h)Ebf6m@YyzM
zWn3#Z(CHdzXz1!bSG*;cRZY-fOqA?dnlz5j-zov)6d^-HHdOX57%@l5ReKIyeSLjr
z=et;rj;*bpcsyPJwtD^G_07{^IQ_0;X?K?>It&XF6I~p1xVdmA+UY6|af1rb!~;u(
zte{@%gqpf~zM<0I!#}I5SY#?AJMd8xF|viyi5|mr9A3QO4bvEDaP)pc=C&CNTYGzY
z8X8=fM{t|OzlIZ)O2hqi7r>MfC=ZUnSh{%jz8N!G3<#(AhV-qfKyNa65Tdfu)QGmo
z5M?AKWwEKL9EVOd9t%PkS=vQ`k}D3j+ihDYa;OoYCSTWGzpQsEF`0qz$C3Xq&yu2Y
z`#Zf3u%>Qy+mXI7^IL_!MqLWjgfW&yQgs>hi(nRGC#B&0P(W~hsdt=zVvdW5k-_#;
z?&qtL8T%DOmT%@6(pa3FHR0!DKLVk*E-$q1Et}}~vGYL#_@N-M3t9^7x@m)8b)96E
zW6GLi2DZ`^&vZhV@&g52!jKyJL0@2PR7XYgf#RvPRSRjFcD7bX+nvPQ+?m*?$KV0N
z;F@6pB53Rp&vfK<`F|7m;2inWT5kv>RU=Pl&E44dpTA?4r3Y!oO0shgWYgzuTQg8K
z|G^TqXj_#3sgk*vmbGXGv`O5u7ivnEp#ChA&wKHdy!ic{(KG>0$k$FVMHS;R=kK;O
ztV+LtQk|D}aM${eUR@o?SSk+|lrORZp}`lb)Ygu0?{0Q+aWTN9>)zI8XJ7V+<Uf5D
zEsYptQ*BKY`4sZh1R_L`5uD3S*pmaDySIVUgzPv9kY%&dwgM33g61N{v%h_fGue?c
zZ1?**Iu!__!w?S&^$a>^hs4!&G;aa%E{ygLcYFZ5(zbm)bsN!-DP}6Dl!A7MYzSCD
z0KdqzE&F>x6dW=Ex^86M3L4P+_ZIgSHy<H}!Y$|)S+Y2_gEdeN_<3`_T+Qooxz^!q
zifbyYt}ZDl>A2f<1U#qvFa&*~x@9e$Cmx;W=NEABKMThECP5@kq2Q=QnT88IOMXW8
zwY7yXjX8^livzUm(~GNK&lAM7SJ(*|nYHnT!{Xwf0q@T0>KFp#J5^HH(j#$Hw>Y$r
zWh=1Elha-h<d_(z%o<xh%7+W5YeJ_B`TvAGO?niOUTz;*Gt(WdPo3Isl7>F_S{;|5
zSLGjAYrZFMQ05;dK?>~8V&-u0dJ;I>ZCKLRQ-lv##vfrD5YJ0*<Z`g=QU<1A<T+?=
zde}<4mpG$QQSWxw$RWTjP=%BXX}i`qWE{T#O9Ct;5pSfr&zrg&wl1WL55&y#6JD0t
zVGvhr!b|pug<b27*7ZPcp{(;r3`XjL%^`{~th0tR%RjbImT{B7`v7dlL}tsO9v4&X
zm3=3*)n9+!-Pm$SAMDwjNHPHWn4R79;S-qrmJK~-EI^a<;fpmZXO)PsGR7(5_`yg`
zUkfNDsR^e|8re9(XLRPFLscg}Nk$}^cvx9k(K`LiEi802%wTF@!0<B)iDOEsOm#!r
z^32yaa&lHyGR6`KQP`z$efOTQ5g<Z@txAz;z(n0}M@Xbf8cSMQ9!sU*GR*Bca<@VE
zHQ^w8NQ^@o6slPG`1k|_b`}@!UuDB9)4@WCE~9VCc7b-~=EkPuP6tk`7^tOvOJ>7Z
z5r&DndUtmhgFz240Xr0dV6$!n<W+kEp>>h@FmPsSZ?KDLDtMw0I(lkbJ1ZGa2kBr}
zaz8k;<(cjx=5b)gtRH_?ASsObw**OeYzBuyf2aIjR$l(|mn<4NW>VS?&@lpnh~#JF
zp#c1-rhFG98-rL*4)uFj7AZO-V}iLk+%=@ouuOg(ZtUxg{$IZ*+K)T`feYr5_c%BV
zC@wz76kkFg$Nc3|Y*v2jXbEoeRZ-}FY~kkWxv90*t&W0!Hayl0R)MVg%#<lG8l&WW
zdAgxy9vejZ=uJ!Sfiy$9jwX5x_rjH{Lfdk*=lZPU6G(CK3BsXMzBwzA`ErjPDLF*)
zI{#8?nr<dWDDb=-;&Wc&oZ+fa|IfP3g_(Aj-S@&`ciMJRFvO+QP#*U4tKX~=>WeMU
zXwnvzN!UrxP&ck-NBw0A-7^-njF7)Jr<c&VwVROkez2;UsjFWRo&L<qssMP7`mq2(
z!-$ECg$2Q6%&iB-8*flA_$FrEj+&l&W;P%}=S~%>sLT8akd6$^2M#7M!8(tj6wRGH
zy!mA@Pg&8MJ|DXA0C{hdlQNkKm%xIfyQwqxgPWI~JDl=EN-bJk*vNkHOw|~dhAY&A
zq#38AC!<1Cp!QZp-~HlP9>K6AmsDEZxsqw`fj{8g>t?6dx<06ODFrMNs+i*JcZsvv
zm$fUmzAlF&x9XF<;xk!OQALwt3LBCC_RZ6em%p3xxg5bk?mQc#F<`<&@pzm78NrwZ
zKU9frk-Qv*a0{V%WCPey01#9+^N<s7VIjYnHNpJ_`C@L_ZRaYO#d8EzWx!?Z=;U;I
zQQrr&)Ty#X_^6?hIi_BFb^td|*35Td^c2)0ud1B5mQ)%Go3q5dJsf%QHvu6Gw>{0V
z_b}Qz-QeF{t`iS;UlqH(cF|$pVremj8ZiG-=J}he90|RUl%uuC4j(~aGvzURTQ;^D
z=UN}KiruTTG^6qcQYeGgRG0}632ObhGs0MPYmVHNIBFaa*zKb9-#B(Qsl$4~eziyK
z)m2P>pQ~x>0GZVTe<xW|VBUtWJ_D>1qUZBMCe985d*%VRH+ff^8eIKyU8hm&IR(-y
zWO{OorMQRT5-l>foY--XxN_(tMF$6qDJj990XT5aYPOW(pur1SfVc>d7Xa6e0YwVP
zcBNBPP<VWPiX1fVnoGVA7mX$FnVOlhb+9(D$kGGEEK6H{&$HW7Tyatg&c;K?Jd_tm
zYgaH^NeMnKddAAiwze0GIY&b6j4^<GrL>e{ywY^T%Fb-}4>lq><~Kx{uJzNdYnSee
zi;GOMpW{t6Q%6-)^$nYsjaKM$gQ^SxeDmNck9S&^fR&C?A<xR%+Sni!2am1LfN2<>
zDKI0syk1m<3P!}$^#QQR0wl{4Y^u>xFp-p0N2}(Go13r9-A_QGSl`&_91rqM9{h6x
zP|@%7dm?3a{3K2@njjM~)zuSLHU^3eurXR}2dPfMOG3S$OBGjqeO&dS6<4mQtmJq3
zb34Chv^u1~=9q9#DRLU-V_UVdxe3rQhV~mkqu5VBsOjOwu~cMn7DI^C+%efMlJ<Jr
zOq3$(B7KSI-mh;Sc{6MGsc<bdm7!sMMoy8cW~=h5T#;$0(()74y-9xPPG9=4UQm8@
z13I_28h*#D*h#L1o|+|a4cu>%3(|D9i@E0BxkCo4Kb~jj?mrK{i~^o1@2W;C)@xY6
z%5|NY5NS1jd&5+y{~}6(PiFsK7`zlac@{&lmsuas>~-w9IC#n8h<X6Bf}<}{m=J{g
z9%e|{8+QBHOU}*R%iZ!EQv|y>=P&=?F$D0jpX-32FAzkk-NC4XAE?8GhqOCx<Kl-I
zEYKtXBxFK9FD@>w3UYKEND?uzD7v7AS}Y8V)s+>U+Ntv*Zv2FMmc2ruX6lH4aQP+@
z$si<7L0@E0&~8KWU^Rb6M@LJI1GqNm>8b5)Y*=z<*qWF?)Uw>d->qaQQ!lr**R=u7
z($pV(;3aI5=rb>b0>TxJ5#8uATR`^+^!5!z%*;OGr|n3>D4=+Y(MJ6RdHysi)Vlya
zr@HO#>Z<B*!OU?-#UJn?Gp5=a8K{6g{q2Y`kQ>PJ!>q!R|BZ=xJeSY=e8ss7Xf+FQ
znMg8Br0p4{)ht<Zb8~V4>5gFn`LKFE<%HX5;Mo@X3Z2wgn^8Lu8nNSdJ1=aNkb)zY
zV)ly(StkNCaPPI%7TDA79WTJ}2wQ*WbviY~#*}0r@tzIx7`y;Yocqo1)@jKY`Q9f>
z`2?*wvj76Wbl)-oW`KG2u)o0N6i=f(yN@%mpO(YH{k7ar`?2}O^R@O|i}BR6+^6>!
z4xM-JD$*1pYax;xF;gV-ZZm|~;)Iv?FZ%nx{_(fmuNdCP0P=b&P*hMa2#w!bkm_r<
zC7k0?p%)^^YLC$I3u?@lNV@_=gr^XLTSquCD9rJ!@1Sh1?!o2|lR8O+C+0AQLl2y%
zTygFSqu-e0k1wosej(<jFK=zBsOgEF>Z_pBRM7BLSLzrl&MjAK_8Q#CAdyI`7#i*_
z(`o`*!OA*cndyYw-Z+P*EMT3drJ>2x-ee~E@pK>KGK`fVg1bRZ%<lQEmuo2yhg~dl
za~r7iiv`%bd6#*Y5u;@_d3k@1r4G!hxaHau#ERrk+UYf9_3iDg&t%V&B47(ZH8j-q
zDPSs;O!Kg>wvAjM`{%x{+AUvS-&ULQ0rU-Gq@;wz@$s<+R(OF?D5@!Pt9=Pch~vMm
zWjOiozenQ<Hrs9*h&{l5v6pxxQsZJKN`!#{u(XdyqOUt5XecNRPcHpc;6r6MTL!*u
z?jrtuwvCA~pv&=ga`S_vw@)|(x+$KQYs#vs-FaBpD3l~kxcEPnjzDR6Uxvq*aKDKm
z!NCFa<n}_-P)OXak~Z1aG$obF3eZ4e+-Q>&**`2y<57Es-)bW6u9Yp!xy;i#ej%qJ
zgqgIYHN6iy`?-*R?!{2!3I(VwXp4h8B#<xApOK?}LMfO&W^GRry)_pFzI{=>-qv3}
zUG)sLviNaVqM_CZx^?bZ?`5nv2@aWYU}YTRdzC*repc7?zwc7E*}-oTz?IcQHNrz)
z(4HaOB3=|!!={Uzqq7NHzGOGfe^kfpHeWVNRPy@?oKKLb!GM>Ho=vw~oe{V<CDE3<
zeM^(Z{aErzOlPzQ)XRi519pvjAr!L;Fsj@H>US@GCv*ATzRwJpL;7XGn75ag;qWKC
zL;`XJjoQ;$!4aPbW>D2OIvxrNzP`R5e_bw;<_~BhzXl!=Q1qlE;IQ+<xl<}_gLh51
z`wA*58au7C^+}syLr!yaT5u?Gt;Urc;l%~XBfsM#<~X!z+1S`-CVmXf*VpQ{VPayU
zu;_z@l|S@SO{-%ZefD<$^nX1A7{TXynPt{MlIPFB&zHb|NI(?H*Ighm88Jw{APoma
zg;mXIN^>m@UhnFer<($fwwLS8-EDP<)*6d%U>C7=4KTY<p(prbZy%qGeg6(_zCLe&
zl!9O(7mBhfAPixck|+=`$-Woe+?hUJj4q3+LGa7#;fkyFXyp38B@h6|6gMt|AI7N+
zC>kuJeUtMLVKA}Cq$Q4&sF00?g?Hl%#pXxm6CU^q*RXNX(+QNxSS26gPPNi(_B213
zUP9ee!40g*U4sKmwJYoD#tW}?H~tkAq`Zj9Rf#2|?rl0Jh(Gyph5t55$ZO(vG<Oti
zLH~Ck9s!0#a2r-M3zJh<-~+|;N5)V;<7isL*1Wf}VS1s<{IBPi==*zln-lWM_o&UJ
zrbwYP8PS@TyxD=bVP*>wh7ss)vwqEKYOR%CQZc^U&8RRu$`Yu3bDub&Fl*yDFIgA6
zA|A=5ctav^u%Ni9srH+-&wmSt$@|7q@=C)|Ej7uWl2g(eX#j_QPT-A>QLx|ia5Pio
z^A_U;JovvfPr$f~4UwSJ)rgZt9qJl%aeC?{bLngiuA!INUDvmB<pKR30QV%Dzb4La
zwWRvpl$i(FU2|1UGcA*m745*g4`@C06@CtczBNiA)Z*(92W$IAeK`f@gX{RPk&J@N
zOSrSoS229)<SAH=l_g|k9FM$siz_3KB8c-sEhECsh!)OU{tN&jhXdaaiGX1NV`SgT
znggJ@%gXu(7;AUGJ`a<V_W|uq_44b2BoPJ%1_M#QQGo|G6odwqPzd2v)Wm8e$%Y+=
zr`;u&*T4Dc$ClMY<}`gL4tWtw^lLEa?_<#5!2mZ^PfP3H?GTdZ^;ULnu51hc&-N_@
zhD{@;we{tf<;?QgAN;(6ys{Pycb^IsSzJ*WQmqh#^4j7rjfZ2lwze6*lnZz4S-2vd
zZcVH5Bq!FO=w(?`M;o24tH4MTkc15g%~J^$D1g{d?IWjaP|c&tuNbAGOr`d8q03fR
zSIEm3$~16f$Uc=&H?eIDLG_Rq$oDm2X9N?`r;tl*42zNFvo>1La@8)o#5D8-ZInP@
zigw~@s%u1)Wo|EYjVyGNIbDSieoIYczom9kml8l^K!LE(lFIS|u@NJaL9oy<v<cII
z{2<y!e}Tm<L$5i}nE~0`<3x!>E+KqI*#33FT0XVB(^ptm=V0Q;mz+e!L(uP?HZQqq
zx^OxIk0s=C#Q0fMTPu$~f;9ne945kq{eFB=ANUe$i0~IlDFcVcB?)Xw6@$H>`0I9m
z2&ntCy!PeIfU237bM6Ld-T}Wf&L>1PGA`eW2j+EoWeHdY7#@(dYQ2DVbta=eE)IT~
zk60K1!o>xOLf|)>qYkquw%&71w(IXPCctiUR-c!M--nHtKeTmIxf6ez8Zm_%lgVoO
z{qnLt@Pk$vUGVj^I3xs1!g{oL02`@()%OHoC<}ZY+#gL5CPtcOb!KM+1RFYfdhX9r
zJOvuTzbdkY^pw-^)RKChr0N;wKm=ey|J^YlLVaO9`2$gLn#@WPI$l#}G(rv217Q#q
zF?2HPxA{=<wua}3&+k#wS;@`$9L_Q<@Uy<Y{&_Gw)^aWn=ki8V9V5(m9Gz>xL@C`|
z{<j-?O@)K!EHKvqnjnpCV{G0S)P01qt4iP4wsd4<C`vLJs(X6g0SVOg%}u}m17=W5
z@*1O@VL=LUNxT>GDz+kcsoJUIq0&{QGT}kHk|zAq&tLl1*s1v;Y`UY6MvAZ}MkbG8
z5^PFRy?N;L`!&Qo3&@Y5eG#@^+YKP7zogU<g9s&@J=BjF-}BIwIzgel^F`IMw_;V4
zoI_MF8$f;+EE{D<0#NE#-AWb?MghyTQR}!m7A4vdH1B`=CCll^22S`|6qX+;FFW@{
z*FLz3R=Vw1YdhQ901SAbh&?)|_EtgFid#>F9R2n9aaExHX6Poc!*Y%g|Cc~_7x{mN
z7asTXCBW=2z`-I?ieAwLU4{}Fg`ENutG(49_yrVQ&8jMd2LlR<^mGiMslx-)Q^Zdk
z-kF6?6GRa@7T*Ho4g;+CBTEr47=W-<R#aqSXNF+QhntV#htUx)u@t3^Nt_cNuGQ-!
ze(ci4!^6SO#zr?iL&gR=YE_^PH{yjkrQ(Fo$<F-p9Qf=BsJVfFvS(a8Jm%NKPEf#r
z4=5&qR_d<b!wj%5vM95}mdE0ncUyMzFX;dJttbdgv9<u8gUhpCRk4teWeIx1IRiR%
zW8F2dzXtjx0Ld;fE)MYtiK&aB8m{jPISx(RTh8=bD^5Zvlc$Z%D?pPN0kV5_bp~{F
zbb+7+0uSCX=c=lIAHf5Kg#bW)AUJq75~-Y$5<|O8j-mnFG~59!M>shwVg*tu41RE>
zc5{d4ZpAg4;iqi_WyL&4L68_vr(D=-<-K~>!VC~D)z(HR7~p4O=jUUA+e>nK1a=^)
zM_vL$iRcSE`7V2YT@Yv5;Wwx#1@Z^q-_ZC=9b2MAq@1xI>{NDLuPWM7cyFO#TwxKW
zNHQjycmXlQ0Wr~BUDMGEF{Z=8i9PBG;$pu39?e^!Va?4zf}RJC9r7l`cB%wK@=qVr
z5R92WDPvA%D*Hhe?6S8|HslDWS-mJsM$29GLJh7UT*;XvKIX9;vs$O2Z76*9=G9KG
zucxBo9A~*=WGD$87?O$8>Cq?%*=-*kUaSNFtYG5-L!$?ze^ypjbTl+9dJ4qI*o1`t
zp*F+eu?V-iiDJWGQ3>R=lf|VS7}c=c(t*UHHy~o3hK5GNXBK}fJtG~s{aZZ&{Fv#D
zyoEEEc@HQS_VTLQ$kNQf3oEOu_2a@OH*522UeB|=N>o->j46x7%&`&Xq}Uvc^#!J?
zk`6mAp3FlK!WGrkygrwwOMl2w5y*IPFUL<m2Ch-VVRI~<?+gRpHY1UUt~Xk%i;Ih!
znpgl4;4Oc$l$nc(OMr2Jo7o@WzWMw6v;J1iiD-sKHzackFQV~u*mdE;$BZ=}iug9w
zO>ec1vW*8;IfR6P){Mpz|HSs6_IdUCrSrw`>vc8t&@|~Jg~P%n09;aEDh}P@$FGO3
zDuuYj`1p7r+^wvl0?3Gm*=5lGO`1HuG#$6vTrokj7zk>OU84`uo}VUx92c9?*2INm
zngvV;0v->ER+m?6Pf?we5;<h#7E?<yA_(Yv-CU^w1u7tDU)}yVeLSl_=uno=B8>tk
zy;7$+j#GfNt=`|v*}|!GAgAyMHj_OpfQe`(i;yJf$#g8uvuayy7jJq<UxyX(k-C<N
zF-TOl7u`+5ksqJM%DZO2Z8_~KW6}XrdP^&hKqjr(;4&DWG@b_2;G=XPx_T9JN<t_u
zTu=lVhELLgdvDTpW3m@!<|RguXklvbl>2$WOx>tV078S6K3tg6?0tm*GY$>x5_=x5
zd0kzb+a0##K-O~9)ydmrV|Gsga|3)=8E|O;`rFT!zq(0al@$%zwevMAY&S*a{r!M(
zk8m!8xLo|$-x|m~z@LXIIM-2jp77oEt?%vicPA^-h%N1?7(enDF=YlLR(utQizxbl
z_4N3AJfoXYQOmyy5_0O++S-<pk@5Hx96|TuRJ<j7(OXdkU4#c1FOJizM@;QbuD5-m
zpd)((e(v5#cGGO{%_kDeP$z|+cyXX43U&m3-4#oAdV2$#6hQf@QH{a7WW>b8$Hms)
zfE+6hK7fprWr)09x@WQU0Dc465{WfyI4-GSfVekZI(Iv9ju2mQ)+TGSdoler=&T25
zqVG5p80n@1UneL966dnEIAIK>7~#Za8!U}Z*;eW_(<Y)P?(UpL^}cm;C!84JV`~~I
z*~qF{S2Q3L_J{{A&3|89T6=H)x-`7mXtgaZ1vAy5Dz%gX!_X5hZ)cj>i8WuJtg7Nv
z>{;Jj{k{7;)@c_6T%4KhIEVS4Vu}_#jqSJRqv%geI7?@BWV62HIY@L~=Pt(mf`U=!
zzZ)8LEfV@!`|kG_AO;1l-`UV8X4970qp>b)H|a{F@@&*4%DK6x^%ZdnS6>fwCaYfV
zeY^uy!WPLG5R1wyVXe}M<!FS}E8=FSdbFn*_wA>^qLc6OW7n9o$mdd-Gg39IBwTb-
z3n1h6VMY0mS`SzdnziV3+w8J)^8qgg(dor%ur(Nx%pMSdXOw(NG1gQ?$_Q|i=4SN!
zJ+`sM*uy9g(ke*`<fP~kTnH=TI(NNKw*RvcTNe&u;Y>AIG<P;uR(5sy7#pM9A*-~(
zvYZPgB#86E!@&c&XZTasN7xn|xj?en6fG?jG&CrZJj*>f3p$H(8Uk#Q)~=GFcBdZO
zmntw90bl~%H+>gRK8*T3*l<uJqD52^QhwA2GO8%9;6vo())p={J|=J=$`iP3aheZw
zb1pUOW~3kB#Q}<3CgZH|5g{jYhCr`uVrItwY=-&QOv{tB6&O>cu!^pIKA^sjxsO4k
z+|kj}gIH1oS@7Q%Aw24!;Dn>u`3K2y{tyH{xJK56$;^<)a&$oJk7_7_$>PkwGt~$n
zV*>9q1HIql4{2$54-b<AP21B+)r3w=<I)5^ESPh7IqZ4dPUj#0s1YOos<mzEMdg%<
zinU6TU;p!yk7!F{UyIO`H~KH8gXhBJvP&r_o%m70j4y^J$N2oA>3-Zdr2WHClp;R`
zV=emnwVfVuCwg)GhL(lLnTqich#08xM)rU78Lb)|YaYEMmRO=mVO|n2bx9nf$)F_Y
z)vhrNQ|m7Y3B6@oAxBtQC?S}YL#n0OE$!I|?i=Vkj8#>kKHV3p2wJ_Jd37Ie&;8y9
zV#dzOE*sNUZ~NS=1<IrKJX5ZGbD+JgR50I#nWAqUgK$Mg@IljHXGo~a20TDT&>N@-
z6i)WZBzFS8K8}jXf3Op_m_NY5#X=BQl;BxSdI=gODkYG@_^FzTnwyW%@WIVJczb()
zgXxZPgwuEv3HRsYj~7gJ?`#HS%BvzHW*oVkc5AnxMDIq=*Ze{RA-6UiA)>>v%9aqq
z!h0Mp^FP97M3K3a_r!&f#X(<@@y)a#1cSf?hib{gsqdDZ^#Gs?z=S^&bCq!uH_trd
zyv2%l=C=5lF=J^3@+1FH3IaRVyZ3iKQ!hkCUSh*=Ur;f_tf<(OmbhUPkiby~!f#<^
zdvUOwT-Qg1-x+d7#3KO#FdnDJ`;+0<6F@)7<ktDDDfRJ^F^eBFz5PX^{@nn2YH9}P
z&BuQu08&n-DzgH>&`=Ki;gQZzOsGiLQ*5|)4}yweys={PhvNPG#g*gsoXl?mIR&=x
z`tNEXCph=^F~TOv%+Za;goe?atB2ZN3VaV0JjAC16mc+MB%EBp?1OYt23opl4($-1
z{|+@udZKFfHw~N66^#jTW>C(^QeEHC(OTh?aoerfL+jyrIAvfhmIxTnYbk5T&zh?y
z#)4!-_*ml7Wd|go!VmPQoU7@SdHMU{%;_jAFZkZ{VkM3Uemyq7bZW~l-^NjoHY$Dh
zpR9uFPcF#||428*2%;ppr(3My+<|<&Xpr~^=v4fn5dl1%pdAn`03VGH#6oGW1M^V;
zeraqh5FK7*_U5&3)pgy#b8&u=A=>lkH|?L%4J-u>6;yi<WZJ&Cenk-+0rNR^nHgy<
zZ0$ASTttdX_UldJ;W=?0AFod(_wW`b!$vTCO%h4*<N^h3GZk|Xn^1XrP1xq>Y^lq9
zYI)O;TwB55(E4?mX1&yqS}d57{lVQVRxiJXX-p`!zs}p2ZMK&hCu|xmx|{nx{%)R4
zNXtoDmuyU+leSg~>o}Kun%xQ@|G+-<t#Fi>qA0N_x9J+O+3qoam<xDq=J!=LYNQ!5
z0O9@i{i$@Mw~JiOR=*AM2f!P~RmkIF=3`^y764V*^Aau==0d+Le6erBD029wf226=
zI3RzpaI=RWFJ8>b^BqHbqHMG&A>wb(^OuXTg4A<;ZqPX_KAaq^kTm9;YcN()EvE6|
zkN5Tf8)_YALB3_9dqoXwc~M7t;k|nQXG`u`jrF9DW27FEpO2>r$cTmZ%0gVI2H*>3
z!Nx$O@WHH|^J?<o^Vgt`M)!O3C>7E;-0d$;X*?3Ik(u`v?0}_5#y|T9^oedgD<xyS
z4)Jy8IYb|)lG+Z>nuh+%tH0r`Ok3<=o#rbBl_c1!hQqwkq-a4%y7x9E(Bp;}gRx{~
zWD^N^|IYf}7{ise=F$J~tE#G-oSiVx$|^Sm>Rhf;R~aT2Mr%vWPH~p}F~BW6ubNB_
z7M7Nocj3)G8c3%OJ^^~rKq}#i!pXT4m&f%MHB895NuSS4%-o4+u8vAZ@+Hhta=|$U
zg%L@!4HbgIYz!{1Thl#7l!&zTI<T||{M!pHD+BV~D3+c^BaOSrw&n`#22UxS_MYJk
ztqb@ZZQU(9fs)eqdcXARmk=8+yU!>@fvH=%Do&@AC&;JN4RkMR${BJv2|)A9RS`Dc
z0Y)c+@3(INbXHH*O{59Gr9_FF0P=$x1hhoFGhn}F#$po~iu87S3TEg3Uby7$;e@bF
zanS=WNIVrr5R+EnL_PeskT8mNOCgLYP`L7>awvCPBj2qZao6QqI*WJt&PO@ot!4(&
zM<}7`o%%zSs?C1F`;GE?#&<3AjIL*xO+J%CAJPPIxOS?1>x_NdZPvuyksD-78>>Hw
zaQo=^WZf!B)%?#gcRZR~w=N?M2B*WE;2oLeMaI#?fM~6_v{hH!5PZ#pY@Z}0PWB_V
z@ii$0#-VEb)o4M}C!!E5!XZ~(Rn@uS#~$<%1_sgB=kxRR4t&U8Zl7=jRDedcrwG-H
zau)gf6Rws~$P@G#2Ya}22^d=e60%~+L?An&&&|u58|WEGI|G)ZyS-mQ!appwl++fN
zyb^3h>>JdZYe-4Q27w%|Tuz5kio{@=5^gAvVgd$DTUl9y9o50A>i@Rk{%;<!BbOeQ
z`kj8>HYQ-l$<~H{&ejFb>&MrLZy|#x7L)Odt3x7+Aw4s?OIsl=b=1{`m|FqL1YR!5
zu~?I14PnrWYZPUm_;)xHb@OFtB0nu19S=ac+U<D_%qm6>okg<5&Vx@S8x<*}0H<9r
zW!NpjP?G`Iix5`ix~W!zdq{)E$0rcOMI@lNJ8z^d+9QqyGtg&3#o?iy1T{~7Lru8Z
zq6;vLf%X$`H_w}o54YPD7bJx>cc0&Br3nw}#?GSZMOX)VEOGa#uT}~qXrj7!tmJ~%
zq)U7|H$X3qei0v7v0spEKdMAw$2KC5Zq35!4xOQPYH^s_2pHGc9@o}bQ}!Dr{uQAO
zLDj?z0;T->dvDZZR}<jCPg{=gB@*)`k~;j5Lq}!okhG|-Y+7h^E^jt(ZtXA;FICXb
zNH4&uxZ9^6S!R56-zb)?-yZ;RNh(jrvf{qrwV<0iJ~|>0@aq6*uRt4jwO${O5Em|T
z5S?2>Im9g>R1c(z3YT6nC)k>AjJLT7K)eD+@HQYIF{5o|D-UZnpl-=4n30MKu-&z2
z*J^EK#f%oAK@wn&=I6J1PaU^LF_^6U?dt042?0x7jpYS}_=-;$wDJMeN<iu&YK{Rd
zI{?#kHkEX62mq9@*^d4G00M3Bolg!3sr!CbUJ-z^Z6(bXq3|XRLTfibcj49z<g~Tj
zto1qW3QWiLPg^F}peEy>=18RyU_OT#h>qY<{ku1I>usyMo~_m8bl3(UKRNmN(PIZz
z9@wv#e<<(1oR4@Ys)e$^!0LnpAlQf1yt<oQngCA-r{i{$=iCl})}<KD$h6M7id)%A
zS(d$IWrhMHvs_sgQwCDmE_5CH`MH^KqQ#`96O1=c!>Ejs)RdWP=Ks0pIW{u&%HC<t
zj|?dMTn<ZO^t*8>aV9f@%#3a`)84UhU24~rp+VzCq~LSCKgdIcg+(k+%BSpdnSL25
z;<aQSR#3z#GF&R9Dki7egws)4NW#4rMYE5W41#amw9Tb2Rgb2BLk&n|7-`%=0VZor
z_j25jJ?<2Bn!o=zF)h6b{lMQNenD3%5VFYry}3mijIptavbBVLuQ0M~a&Uj66nLTi
z{S1gf0dAmvx6jk{c6VxOYM~Jm38fJTR;liIDvE)U4x-q+J^DcQw1uaJhPnDOkgNnu
zYZjK4(tiGQWXWE{mU5vx@#qFh*aJNLn1qB>dy*Iw55g|1oxHuiuJ0S}rh-LtX;V{G
zS($~M8+zme_EXRt*m<>kYdR3&bwBo4aGaBK-ovK^*6seV0+4K9-(GtO71>aQi|fr+
zLQ1qGyu>U+8l(`fJ9B4}y3#e%95;HrPZIQJ=w~2Lwduahta#DPUBVc{?k`ec%guW3
zV`O2p0-7ru8*5tJ#%A;NxAlS3z4y{KKY*BljYLZkdtI~gm@#6MSudjQMUjJN!k^Qv
zZ3FfnK$QV}Qtb}wDw>9xN=glIJ#Wnt&ZJOC6!ypmH$|!g*|g2G8L9cMK*P}2^Twdl
zg@S}aC@D4LH9AkBX*hBHEoBpZpHfU5I^>rG4rHNElNj0JO!Gq#^~Ij=>`HA}&6at_
zH{<!mYzm&OzcD=W8EoSF5Xl$|8Ode5Mb$QgteIK3i>3nk$<DvVLJfX9-F{-&nunG)
zpnor2v7#H(z0!!C(TUS>uAE6v*NXyX))LTQ&kW)YenW`QFiu0kX2IkzSxS_(ZW$rO
zORJptTy9hh(xX_g&2-d-tbB}1K#Qeura9m{jEJ$Zv4@8T@C6GNg@%3wrgTu>DJijz
zPfjdOOqkdqsqj@Q$GXXfERM`F)6#%QuA;#~pwsvI8Ue^#dwP1@yX3mJcXoCH{)_`H
z{(VZG+i|Uo%|_RgDsjf2zYH|h@VQ;Y(8Gm@t>S<rMyXWk|MJCw|GCkQClubXO@PN+
zRbBObxy}lVxVb>Syn26xL(Ux>h>#{1$kk?<;O{kA{eV(f*mufE&on>zla`jo28iia
zRy5Q#PwLOLZ<)B%TTEAH?<Zr_^dc4<fml7j>w6}bJAZrrny*ma3>a-LR%(mMipj=-
z&m~eg58zG@21%_j(e_D2E)(~%jezvojuLW8&ebCiKuZgZ)qw()k(mkLJbTpIeazzu
zFfe@oUWHE>ijIzDfs`dS)%Nn!JGj7_a<`Rr9YYJg7ydqi`v=Zf1|#L5AYqQIpolIH
zu%1S3!P$pTo#x&J-`mee=0;$oR8(4MGE(>16V$iXecYSP-%y@sixavucG?bb(pqwH
z6C<Fz{7(d;^S{*ca52@wlU$nP23>8;i?8OP*P(Y^ms%UkR(q%~Tu6DiQ9A;;{SIqh
zPYG}G_tBUOgvIeCMxCl=8(hru-^#xPZvG)bMA}~M=>KL*96NmSVHOQWS;8p=eOEB+
zEUeBO4R0hYyXY#STCiHWc?MWm{~4JkCX~41L?!V@O$db&4&m<MX{u=e4>dlbq=!e_
zvJD1=@yCIr{wmqR>EOE`9n@00*`M8c12dx^?F|h^S66J}%I^U`#}3uek1B^lPCE1Q
zwpy{0GdSdblS>1_9)o&L<XgqL>DlS&VN+&#^-{4A<QZlmqyc!avc1WP*#Y6usVhME
z*rY{Q9f0|Z8xM|QnsKjIFnlU&P)rLD*!?*<DR0#3vH=ek)=n5ZEL5Vx2BOIJfp`|+
zM~g0^ONy$IX%Y8v2Z+p>jEMn|{JGoL9^LtfkyJ6(XM<%qMO0q8Ohwgco=>pQdTMHE
ze~Sgpf!vqD!p=@^9IcE~Lh=6eSIvY&JqAr<W0IZ9y*RRu{MfIDz+yxGnURAEwJ3Fz
zh7^+1Tp?j;CQ6t4wd0vOf5+}N!WQ)OdJL6DDAm%euj`|cxvx}@ucnEUeROW|c32hz
zeI^RM&gnA$7otz~zsLUdQ|@OuG;f$8`t7|~eMv-m?DTSQD){@bQF8R4%c;1WjG3C<
zfv<+gy)R?~jhKkZX=qvoptro?Q(A*Cj_G9+O?gt}4R8|Ye&0XasbVaevrmMVj??uw
z7TbCB%Z<edDt+Zy9<;t<+4X>${EvEmoTM@*{ufFZGm22O1?#=KViZLE5yWSZ!SSD~
zMKx|=ht+0H;ZUR<JC4|*j-8v@Pl8R%46dK$2KSUsw{&A?J<{ghYEj3*7t*rCt%!RB
z1L)>?HQ88xHm4#+J&doX8MZgNvu#%<3IYt{eKNn**|*+)z1{7ewa;de8WZ~Dn7M?y
z3ApDcn^&(Ab^BOw5bldLcbj_RZdlXu%Id>H4~6P~+8Rna<{wE&*6d>=;f~3qd_(1u
zf$0-6?SL4w)_}HjC9R8WiFaZS6tkdn>=`tCO|4%vm_bqXY+1c`ioX&SA}^n^-Y9+M
z`)V*a`*U>wxpR-}uu3${uXo^Q@JN5FTNa`+HsJZu=ybWS?#hK=2nLe_l0}i!DZCL8
zH(7yC6yI!GJoz5deqvyDvT!L%w1Kz5^*aZ5mX_T*VDfF|=5aHVZlCFFIk}Aw^%NYO
z@O#3(oin%J*P@AVV`sy(j>gC2tdgu$<DKwV>+k()L+em}lX=D}I_PFY(uRY^UsqxS
zipUW(JXp=#SsNKOp*P$cZH%4)FN&LewzfBl^DK!*;u)R#)@*c;1-7u%Jd4dvuRn{i
z`Wxhsa@Dn0uW}e%YiiE;7LOKj^yg8;fbPHiys1a#P8<K*8j_0#A^QndIjy+Xh8s8Y
z!w92a;PdX<38k_k8f?pa%J*~!5mjZLgJz?2Cu8N6-S^!Xh4+6L|G=pbe2zb!>;KJu
z82CG_U+SZy2QPS+q|_MA=*aa2;}EFnOGlN7IfvWNMQ@1`ap7^+Y29&~;!J6ceh$a&
z?Qu7cEG!vQ*F8F}9q~TJj`u#8Ffp9djKKuOm<bPITjN$0Tn|{)OzMJx2H_$;h27{+
z`#w+tdVfPu12O?Yf<Av~J-t5-pBRNJMR6?HSm6J(^d*~~@rRrV6;D6YFYP01%-Juz
zEV}9-{DYxa{Z0gv3H4A;$}U|(meo5n#b!ae8u8uWy)#hUB-FY1k7xJW@fmpTKWgaT
z<hdbfaqnieMp-f%1?6SKV;e$vDW8Aw0@VGv*53p0KPUX3gDj9Au^U~9m$@RC3(+MT
zC#$?2RCqpe&&HlbB>R54-tz0Zqfy3Or1+A6__+Bg5q3B(pyC>Rz@o5$mXUo036*9E
z##?F`tYRoH6oqatL>tRmW6+bAy$k~;XI#HO++Wg<izkDBg7^!K7bw}-!n0Um)p06@
zoZ`yvT$W5$E;u@ndNN&a{cXiRsvY{x>3}P{MpVQ9&DG3%M@8LGMdN6rXVn$JZA}?Q
zv7+^)?Tz=Kpvn}A9rJ+Wwa71~5A57d2NL-^QC!3mncZ;NOwyW#yWbhu&{c(h)G&np
z3TKXy@<K=065LN3sj2E2WlgT289~5kXvwa#brH$IdDi<{3H<9RH%DMg$AC(Lnxr9J
zxHUM#sr>sXD_R;oZS8MQzV9QM<?ru1eLjD$<NkYxZ)hziLl4@*ZXEVa=xLBTZIFyV
z;@o%kuqeg35le8T)*)VC$eloXan;Sd1n@I&^d91$#d+&33I6>kc85<gDcSTjrcoyM
zOV7JzE1RvH#{OhkI;HZ3Ij1aLur*F>WjgE+WOv$E?Y#Kj&t<CN_5%(1j3*st5S{Cv
zB7Q0pEUahUP80Xd{97k)V$OYxfxIfy{~yRKyUIouW=g^5J>RxhkKJ0=fvKO>{77<z
zAoahz_>^lX?Rvx@w@Vt{r_Bx?>yM$k26+<!#}L3NgR8q_!yM51u?is!xf<mCJDI6s
zKqiCqDpVXRX}q}XK8jI5zKqsoupJwa6&ea)bl%l+v72a`)8Rxu#%kxIB(I7kd2%T#
zU_h)Nnc#7DdGsX%h}GV*X#ZB?>HlA};>OH4(dO@fUtvH^$)w))L7#_uo4Z~S@je+D
zVGeb`iiRMx2dbPkLrd?hlPDWI!F|{5+JCC|qX7sBZP)q@#=~@k4g*>G`iQPlErRaE
zc14Q&+v^nfX9`0TLgt=2N4u0;XxpZa{O>d?DxSrQ{!jUTudCC)$b8uley?ghK;mOS
zLqqOSP*DtddI`7jF2(4)wTWu`?z*snm^jUxBsc!|J_Ebj5O9$)FfJ85#~5t2<tyxU
zZzn6oPS}kda#9bnO2Jyw)bcTs4fk-MEV4$7l)5~Z1=(?lPF-#ShIX2k(+sBvYEEr>
zp<Q^}ns9Y5{%Sd55ycvZAEW29p8q1g6J{NcQsKCsc5xIiqOF%Oi?3$a*DTdCabS78
z^|@V??tF+ieTYi3D9pfh`$FI%v$7>IP&R1Xcs!74H1)i`KAc^#pa1K7WV-R+3dHhP
z(n66{mEK;54>uPZVW$_p*IVPv|CcW&1f+D{DI7clva1_Booxs=MUbLZ%=V<_N>2Nw
z=Ov$m;}%ti>nh97655#O(a!a+moEypU5-jP74MOhdg@^fhzij0<gE3YYd(WdtS?H>
z3k!?ZBN=^lvt5&l6N7)FoYB6SkI`R&zLpzm%jx0!&Cl7_evHki&ZM{_u;RiH=%R8<
z3QT7*>VfA-A4sobkBX;t=XGn+cB-Rnh+KNiF?&(0G*KZeTQ57VvxHqM0&BozI~}e?
zndyRB0EQyZRj{}9Z@}uC09&j$``JKc!DR8D^Rqtq&=8aCjEX8|PL4<**91=&yp?w6
z)`KI2c)WXZ%MCs$#a#6Tx}8Pv2c7<P`cV6{UWCZSdo`OYGJ@`mFn(Xu_lnsA=Ozc)
z3j4qoYsH2-1Eh!(dugNWrGK7*3Lj63E6tK+=hV-h9q;E5U!pIR5fo&<@N%jGzs6$p
ziH3xa_>w}7n!+hPSwDKi`v_gWB9f&mKV|zXwswgg4!=H9YzN#!M`$ND==U?~*8a}U
zPa+xBe*3_J2_bfrZ%0pI^*k4Ms1Qu$8-<#+RU|r%Q#PK-NSoFusz@^Ehm4i7I5(JK
zF?Dq<DWwH;OcKbx20El-cW1>|W1lHE{34Rqx(TKgwWj^SlHnLOd8Z0g#49&cH=m-*
zKfoo}n17z6#f(@cvaY6d_7Qqi@8;oh>O<wrOjcI-thiO?&_pk>!+Gk^8O0nudHmk-
z+6=z!l3-O1h7JYZ9=u4qpI7A`pKr?5%?x?JrDr{^YAV$8$MKJI=cQ!`h^PGXepv}B
zcyTZJ{N7HAl|I3?(q+2(ACh*NW;JXAIelBXSG=<~2IZ`(PU}$dg<bQN4ffjVwspI>
zyKmkmw%s_1b1y3Lw~JGE(@KFn-dnvZmOye)Mhw&+wh%$&keoCtYI_ZR^Tj<Vb8~0Y
zhXkpy@`cg1UyDaeqoKkO!by;2x<SYW9O}6KS)DH5fBUBG;vuBRG#Fg8&x$^`NECQ%
z-2BcEW94qtCZE=*for{{-F$NPav$<LFAFp3baS@raJq?LeNBo_Y*<PoOu)lfW>Yq=
z*FrOBW^Qof#+RB!F&IC(-pxAa&$+o-mW-^m+d#&JgpZlTig5F*94HZIKM=krE>vJD
zS>_D$^he!X$Eb2-8f2EU6G4X1uIMUF%4@cx@of$~zC@|-*9`o-<Oa+kDb%YVgNN7z
zM?-9QmW^m!-Q&~KacnswJ+5V2+#oe;N?jc%Qu1O|g0UXxSchD!aba*4AihC7327lg
z9NQ41D^zlE<aN2xY_1MDAYz|U$I8N?rPIiOo`v|*ElVI;NEABP;l1~&|NT3w^%gun
zdbQVPxCR*q+|bzk)nZ+NLF!J%Q5MbAY}c`Wd)%fLgF%qSq{Idu9K}dHN)#9cpiVwi
zmmu{zCUzS*wu0EUTjuJksQw1uaz&&-O;OfhPK-m67PIjc^|^Beo(cMQB+CtODH4OE
zQT0LtivQN!4An0zmB?1;Y8X4%D7X>Eu(hqTPf?{^09km#$Yyt^n8Xl_7&3~HtXKi#
zj{)+8J1wykFv*(I?dLi$Y9K0fMo%)(>P#@rp>}6*)z+RSik@z&@GT#G!de2EoxEKB
zuU2;l&aQS#4BR=7Y+jsoDn8NohX14=YzDMe^MWQ;?V{ZYWm^1Ewc2#r4d*o2Lx^GS
zN8M#fAWu5w9IS}lkEQO$2=DENJqTzh@Y{tQc;y&A2kW{ZLy27SyOJC9mXWXCi)ucM
z3hDv~$0A$<6h~v`e#%h<W^sFG?Q~;KAGw1r-vqR_`Ea|Zv**T0QIOP`-{*7*$!dD9
zVkJKT#B59+C=>``%uWYT6`J~Yu~!=w_X8$8Ih`|UQJ7Lqu<K5>tZ>687(y}jH70#a
zbM?^-{kz1zIQA>%sj7fvRPol!qglB!s8rVSzNfk$?cc}b=6;(iS^ZejgUN-)i;fux
zauwD`JwrW9(}ZqorTmK@<7oSHrbiMPLU;#d+b8^S>tH<e>|u<hcXu9|6FiA+zdG|f
zx1Re;ZZ|qZncER{=8w|uo7yH%0y^M}Xy$*&#}_OZ?<Ct9DaxoApwHz$j8D+U7a8&(
zQm!N9j@+H%b<09r7xBHcdcuUNrdFHi=CW?<!`jN5pSgDRO$K<f#zhwBi44ZgBcaL^
z2pJ46nSUm(JD}tpi9~7~Xu|8!P{T2#5~ql!I#5;At|MPxDzsc7F$5ANeEYgtieA4@
z{@lq%i(G%|6XGx*u)(3oIU9pOlgG*_M+hr(9Co@=YHVX@co;gLz1AAysF?!3T`%gV
z8C{R4JCCuCMlP>QC?5PcdD%>|awC(~$?$*Es5?l6ddVT1xsAK1hNn);R)%-x(Buh{
zrft^)?(Xn^(wFYh<<4&P@cEzTE|#MGonp>q_WGWudM*ZE)y*M^rYACieJSI*`B=5f
z+IAK18GyMt4-uKMCKCrdOcx8aU-)<eMAG^^`GRjq-iI;SvM948#Tj1B(Sa#d7WBd}
zkJRuY{J%Xi=$hNw(r@_Dch~HOr;d-)GgB~J0$!v9y!CvU(5a3QZsA_9^aJvILD1te
z(!QU|t!j}P*VrOlT}KdRY+!gXMFIbgcA1`NpQ{s^vrLi5o$*5zuha4PKIhiYlO&C5
zXdF`GTjk%h=rZ3WTAePvR)Li}>z)rGt0NtL{0|%n0c!j){}(?0BfGL^-5Z@n8F^i$
zEyx&{jM4R1iz;c+qi-w@$e0L?=@%ijKhr$%VOBZkSN*$zkf0Dcj_rG-*AlZ%x8v85
zrS;-jBbC6vYfkrjDUlG~s-<7T<_)i$6lnuT=*xLhaSnC~Eg#=kmQZT+U(l2<79aA?
zqPOyG*B{1Y1b-A9D$>pVnm|M$EYSUId7}By%v3uWK(4N3<!DbEz}0TXVI0Hv1Qzu0
z(ar4kPg;`am(<5!op$%w-K<7(3fL55nV7fzqC)5;>okl#Hm2l*?DXYLD;rI;JI+jf
z-sS3@X*w%k65o%Bc5)O58TEL~1^VnUW5k@+CRMJqCRgitG?r*u=E+&XYl=3ktYWS{
z>Dp?^lvHE?U*=NVYjlIsda~w_c4zgtRXe;ywz})efAf^{#Oc*Z5Rjhr^VX?tW16cx
zfRWfgb^S`{jn01~wdKIMb77K~nvfMgd6DY+ay!3N_OP7K$!;l}P8s}`<CE33z*2&q
zBv`6kF(spxwEV5`c-G5R^WVp}`fZOy;0pKX0u>^}x3Y5Usye$bFas)OW4u9|3K#cx
z6nJ)<%Bwn6z<6QT2dP}SL64qcJNx3Rv)iVF?}ST+?1=-?AI9gdP|KrJ|4>$%0?T1T
zlu&1Q0lLB*YPNWki9u%jqYa_oKeQeq7mzq|qh;c3|0_v*bm-e)CFpgBa(pv8J!xkb
z&UH`Oj6Ysw2WYHe!8rCT;85w@j>?HckR7u9CR|KKV_R(qa`8PK48D^k&iH9yQGoWJ
zp3Dz9R&(inDV|Ov-j`0*(AO^HzZKzmXf3xo5^KN-BSUz%yG=>L8H{5|5|uGLA2awd
z-srVAsYVznt-)xxBPx7@#ZpUwse+=GMyM!82#-3%?hF~IoQ!0I>-W|EQ0`b(am5P_
z9grz5q~7o#?gDOAHy9$+LSQg4Op}zB*MD`@`z-st*EYK^^+lHd^;ExGtLVG|S%Pv6
zq0Gihg}H-CWMC0%4P_ZDV~IR+4Zgo7rQ$E$K;<!1(MDB-lPpkVY2QC3STp9CFtC84
zq}(XvJ|)?az{~xk*PYvQp9_yq^rzqg$!ti~A0bi_aIBt7<a%LZb8s^`e_Siwj7bKV
z&YrfV4ojPwG9YUj!<HA>+KPoXQ;EuJm>C}UgUO8rz^P7!OWe|g&i82gF}i-O_ESl~
zGKd@n);(<xN$tXD>1VHnXR}cIFHR{6<Ft-_;`J8(zHZ*W2Qpu2g4PqgaA2tkp+m;(
zad`2aoZK_OCd?6VW!ru3{j?gV=~Oy>vI*DjWOxTbc#3D~l@*cENLpT&)Ol8S^N3ur
zV;f|4Lm&ly-v%?(p?7d@bOuR3`}~FG%QW%DgzguloDTB1EE{#&0CJH}xP)w2S33Lt
z%Eu9rKaT#c6*<juh7GXtgwRQ0raHVx4Qx-`o%Q`VI}A+aWQ2Oa0S|F56w~J3>6A1h
z(Q#n&P`m!pU;n$UafHf;AqL!iOD(^yBQiZoK|kO7$MzRi$;V{hffUKo|Mm5bL81iB
zw&>WlZQI5k+qP}nwrzW6k8Rtw?LE5lopW!z8}FTX|FSc(x~nUqdv#~6m3gC3gEBXK
z5vqP_SH%Sns#ZIE@(YvkZqdV)zt0~Hb5ciUHs`&YYj>QfVpsLV#*W7QKKeZDW{fyY
zYvX^gjTf!SmXgG5W=Q>FBjjLFtN_&tIi^PSI5AJb;TPotX(Z9QZQmhgQ*xzfvoKCJ
zeg7ld7x_4TLx0WNFNHF(HFk1#G%>LGk7Z|Q3B|%hz(DXHgNKLykA=0fi6a61A8P|=
z6A=?5J7W`iWe<B30(x~hLrW7QXL=<UL+Af;NZ1&dnb7}tjJ$!PjT6D|czH(?V+$i^
zJ4XUWR(fGOYZn_^CjwS>W<EZ8H49^B^Z(fN;wBbm=FYzn{}p2AsAO+o^m_#n6ITl(
z6EQ~v4|*XBXD4|RM`1e~dplbbTW10edI{U#iP_uzXI=!(jxHwj(k8ZMzb9m5U}j+F
z<AeI&_vD^^t>fm6I*hi{P0J1m89%2*5fIi_Bq4?%5_ufp&jWHCaEIc70tg5=Os9TE
zp${z5QHTNv3UV$Z&s881Mp8`9-fr{yWxJlk+{E1J1)M4H@<F`b$<55&>Et?-u^4&?
zgTbKR=O0iA+H)^4n_vdjfev;fArd!(A~OFdV=d@5)W-`xNo-*Vu*y$y)`QVDI_F)2
zK!T@$qKH?I;_L^r#ZB>(qBe9l8U(sc3j7MyBQa_rh9Y_!tqHnK4g3mFO<PM`3c8n$
zraGs?EI(#on;=?(iy!+!dA5T|u~hz9S`PGDf#fatIww#te0OO%L>w8&Q1W{`FR(9C
z<3h4HvExdR!f||#uQ2z;A`fwI12$fMl6=}$iJw5?Qtl@Bx+FjtRHFbUNIFoGX}XKr
zvz-U>end;7I=9U#pFVd$M7h6}PNmn(>WYw@!c!;UWtGoB=pCL#kee*gW@BgoCCe}L
zM@sm^s4wgXhtOOsTPKU=v5!pg^SwKy!INEHRS-QbQ~oUQCoizw=X*BrtS(>x*jJKB
z5IG{I=BZGDKK_%|sq*^v=GPxoUba0nl+?7-J6BjVW9#^jll$uTvnpU9m<?Paz)XgB
z87ft?7<AdIyYSrZ@;?L8TO|TcrTMQlljss!PDZ|PyIJMS8FH0@JioPs<aj@%!4>9t
zo8R<yb$~-4N?MVL>b-<fyIt^g#hAMIzaLj$Rs;-$mNKn{K6%wxQLbgQ7D!IMX3~8l
zAtaxWA=ZyKk`c1PvC?H&96Xlvmb8FFAWM7LBO-{+9F5PW*ZfFI>1S&yM=maXN0qq8
zSQqW&j_OJzs~~U4udF>=|7)oZI<*bQa(LBm&<tqnyhP`lT6mjU8j3H|y_)ws9d-x)
zadK|Ox=e8#zM1qh&G1T(sM;`{qcj(6>#cYJgGQ9!=q6g=`uJ=7qZBb0V)7DvmQ(ad
zZ+fD?=m`J<`56KYbRLRAUK<V*PRZY^8K*J#<IBj;<HuKFOu=kJSGYzd`m6rrtsJY<
zbxYWF*D!L`n0lNcGC5j>UCaN9{12auJh$$$DkbmFLtBsKfql1K#KJ%ul-my`3<?ZQ
zujk$Tv+0t2&E1%3;##9ug(`-0<YBEE?2Ae~g-)I9d%1lTYnOY;#C!*b;Gl&UT5}bG
zR)b&@ma9FNC6<92LM=}jV{=qC$#eLu<&!IgVE%!@;ERi!0i{OMxiI{%V6;+}aypoU
z@ng@uj;3VW^Vp(%AlGt1<8rVa1YI(_Kq87dx#8-o<s@+;OvfGe_50$2weW&97Mffx
zvzjd{fmS?#ZkL>}U&Vg+t)sTmuy@UtBQPUsc>>I;D|X^G2~FZh)t$I^)ShQKKNm1F
zJKQc?V95cGZko>4^EmW?EI(@}yCnx^G7Nt|?l>V-BG2>(8ugsmm0s1rOjH*7uS5A;
zfxzEV1||gMH=#804<xtpY-<0E@uBOjnhX^E@5JPkWD@7c7(-FtXVojzV||dl93`#Y
zEn+D0clq*Db@ZQ#I(q|=G0R%HR9uhHs|qc>mlQ5N<Y&ju#z;*zBvVx`wg%KpQJ}$b
zNZf&UP9w+G>!GrkY#AuT0D(7m<$teXoXDdZ)oW>akHR6qx;i?#4QV`1N2#@uWnfQ}
zL$Yf%G?nPMfw^d%I6rkOLA#^j+gwt#W?9$2d3Xi-yCJPO^9oWa%>n_V2L(AsY;zJP
z3+GuHS$td4lYR0b3GU}*l(bK$Mv6dWQ?kniO6;s&^@U98%=#zp4Z)z}rK~?L(~4bB
zV=XDm*nvhT)AwIBe^qm%yYfct3H!dW_#SJZL;OUpK|(+IXb86((->Zx8m<{@DGH|s
zcyQ^--H1(iZ8u90nzE|=Y7*)S3O_F2W>~g~zR>=JwfR!AqHV2tX{iF73C}J%ZudxE
za7t9)snjq3aEQV<EV}gMIH5EJ3`9vu`--zaUsarBby10d(?>x2&XXDwZ0X*YdS`bw
z9pn`(>wbOXFBC*@K8MZ~iSf~UO4X&$c>4GpqVretRJa?I;89e(t^_WM@y<6+czj6E
ziD-Xabnnd{ziw~~*K{8RI~yCydJ;~BdLLeEBL<!8<(<=Q=68q6AC7jByReUafRSsP
zy2!$#Q`OQVd?qHpz8T-Z=^I@@JkkCDLDcE?gjc}n<;rnWL#-u>3}DMqN>R<E=NWiK
z9Q<a~(&IcO1)S7;6I>o=E|@)H(RuRSy$vTv%XG#bp#oP^k}_`y^%RE}MXj1r(sW5i
zWw+*IPGwA!B5u3mNML;r%yDh_c7%?Jy!X4N#ds6gu3ehQq}|M23Vo=31!U&pOO;;i
zu#oX>8M9~&h7F}OWtP=C8gxa@80xq98CHpx#&S=MHfo^p>MT`EF<u-wYPH39@%pd1
zE{pJzmc@8YJ-lh&@6#Zb{%&a`GAP=G=mV-bq9iVtnC0@r`DK-%m)O6rw;7B%RbCW2
z-+jE4xy<ZG#nJ^iH*efa_#7HPIMF$S%_9n3$JLQt+f`)*giV-}inRP#`x>cyn@_jq
z%`VJ$_S5&Mi9=O+VgH3nC-?Zb0Ja)|bc)Y&G9cTWgvLp=*BQOcJ%v%HDDQuL*}P~(
zm16r{Rn+;1B0poi{fb_1X6xl(Z;;cjJl%esXR+o_DxY-@jImE{_fzi=Lo2QK+LaA(
za#U{hpC-mb1yWw9_czx>I5EICPf_-fc6VsTP(<>7ph%{7C(CseRX`pqNAqW4m;pnO
zrLC_q#;UE%$Efhhi{+#*`j`e2J29+%-2tBVxv0M960|I?X~5snp|z*g^fiZ?E3`8D
z>7a3Oo(R0_4qz$|e}3z7;`5i&lmRgZwWeh5XxJ7#B-3jw57Kz5UOAsrJhEiVeN=cY
z?udmC_9ThYyoT;n?O$!{6TbCluGFZUC5OlP?>#8MCvr*}ZUPU%K!KaQLl!Ni{=QrZ
zeJz1E>e<hu)DB$EG7FOB=u^6(lg~Abhfeeg&iAhpwEr+V4A<?YVa8H|0Ya=Tn?7=t
zkJefJsoH`{PwhAW$KYn<<qdSuYt)!qohf0gtmMb&ji%a;C^^^w>AQ1qL$<Gj`r=!6
zy19yN2fjp?hqI8<-sKFlE#Bec_?nl0l(<6_cHN!n>AGTk%9J+Qx2C6iPuB1_^yL^$
z_Rg5uXiDpH!`r6sk_$dzh{DSQ23cTL3yxkwlaeM^xpXWbvPSFCfWt?0%h*6qqO&11
z(z)%*C)Gf|<!0g&P+{HtH`I-L7)Ry2=Aw6dCMh{H)v(dDY8wKr2YFJ7zZ(1ZKDPVO
zO};ksS1UYzh(hD)G+{NG!j|P&^iLIH!DYR)sEg8yoOH1_%Jh&+V+*fodSLsXtl|x;
zF5>M+7f}^Y(#!MP9#Q4e4AY(s&35s_)2<pI^+)<DI-)OYf0>kaZlw0Q6isbpgcMRT
z{XZ>Ef+zCwVqbf53qKtZt2)iT4AnL9P7Dc>IP@IweUmB_5c-~JNeR<+umP1kv-(lR
zIkA1c$jM`0WiI_Z)o@5wf!d}xb2kgZmIrFu*WByEtAdQxQ15VCwPd#2sOySdA-y95
zPm(ns{Z+IatH50&P<Ze1fNZSLfkIBw3O3hK>{8E5!3IWUzab>M0;JBWJx6%7Qh6bR
z`7*wme^43OO4bd|G6d}#&<4Y`fPDXkmdTTIs=Kf3{XVZkl%31K;wZ48(t4jy_~&kr
zZ4DV_$NV_`^4G|#z8Wi0YjBsU1pIXQ09;sB;1W=9!BOBS#XA7(<a6nIp#~x#_22Is
zPA-C8wIurO-Ue|>tyF3^?2fsz*%dCCuA2&(MamF?Qcg>j3wmotpy5@AW&H`y7z8wW
zcBB>(aytI8jEkLq%DN%pX?DiWq`jB5P93o@{`gpHx<<=B{KWY{#jcEtEVHc;@ngj{
z`6x!Hj+mL*llZ6c#*|_WgwFm<oz)m5@2N1{nl2S@6J<qC_|?XDi-^O7FKrj3F9-`{
zJqKkFq3#~-ExP_I9F%^SrE*Jzr#(is8JP)BoP`aEr2|fL)_<Wh93rEgJlM)@3%=Gw
zyMw5UY-j0eQE5R;1E$m7R2&@kiSup{1*2N4<dT5|E|F)pt>}B2!)$zv3HFP|8Vm_6
z<$osPCfJK~vbmd^DFI(&e)=g0&|F`j-Uw>Y_=e{CD@y4V2-dOSIIO1NT`v+|Xpc#g
zJK9}TD!9iz`RyS2#@DPl?GUD@;K_qbLdB?c*aBrM(_Q;RJn2IY+1(=tZoanmwG<Q&
zT5_KxnIyiI9QDtsXH;gr?kR*PTqcYR*D(%H04T_5GkhEi4*MiV20`oNn7yyVG+tCn
zP1vo0UD<V&L<h|-$fMa!?iqr+=S6~B=_cZQ*-nl4({h3bE9wW?C<O&)I2DlXWYTq7
zQjoupNTza$_#Y=aR}#pfv16Snbz4Ho#j?gzpMmK7Yix|#&Q?}Z<X5uQF=7u$xz1E?
z7@hHYCBQ>_fNEx(+v3c8!xtmfB^9C^+7%xp?&C>hFb!&~@zj;zSflb6Xbn!x3YK1@
z^P6`|ir%0~JA5k{s2S$fc8{0j;cr300W~#QGW9n;U^h)y*c?ncDbI3*CHxPs{RF*C
zU}P8BWo0Tbci**&w7W6Njqryi+wMP2&0qf5KMBo6Pu=l*3#GXaNqxpVC-KfG_c$iU
z#b@VOPmyqhR^5p@zuH|$Jt=dHN}^lCS^98?8Ui5`?}Gjz=3w4U45OeuOpg%X$qbw>
z&1XvYYZ0(AP!3YD$tcXV3;;9V9~LSN+MQCa*KocI2hZ~&VpG}yqZc5EtXAYGTI7^i
z{9`)UB42s6*n_8Xqv?>EHB9J5B%S^=cfr^{TB5~4_c!>9G`08QXLI|P)<znT9q4VM
zS&;LMzQWatGKPX!K@g}<4Y((Qgu0$}sngc6){n<F)i-hfoW{Pt9q;lj+1<I+oOCYy
zn~*cT=7tF4_C^VY9*^tBT)WcO=f!y2nO4O|pQAW`xCL{NGQArl85;mDB0e5WQK`(P
zlXcEe?HMb`;duyh+-cSXCQS~E7;hYJIHe{n!fHSHs${MvF|u$->~^xj)+|{Fn_5O#
z{39j$N&HHHGHKpP8BljK*_O$2UhTDSZqO%MfDb^;sDkA9Cdi%1pZp%gc0Us-Yfc=+
z<?vuh1P{%nG_ZmV1rf9Ygfq?qbg4!dcJQSx9u_#$ZgXO!?po<POnG1CQQuWxbXQl#
zga;27Q`=ulP6eSe_^*=4>JNc;4ft@qhHJZzF6uFBv5sYHEx;zir7Xui*p$pR3oHgv
z=&#X90qo*6gOmJB49}IZwUPl_3#VchpksAVfw_Jz`gk82+{B8i_5w}^8U7r*mrA!T
z>vrwyk&ft2$tG>g43^Q;6}Oi`+wu`X7@ff^g@A`y*0#H&&M<Vo974O^Wa@12J(Q_k
z#t5Yqb#P&+Gf0`;X&#DB3O;usI`C?u+A-NoHt6wJsQR&foc|_9Wptck#P-U({v5=(
zT37IYh+f&&!1?R>=qAJ_&Ww`}hPNP90AfX%yj6#rmR=eaFFU!z*Joq>C4g0J)5M-~
zVq9yC^4^K*4*JT{B)-5rH+By9r2s;~jMONf(e1}RJptgGd-F<3hw7Y_jO@59xtq=N
zO^j_k$<`*e!gRm9?d|df$iM@7Ws|#wSMN45+biPoPM_p&WOeuKMx^)G+o?qd1|N0}
zLS=ism)`Otw73Wsc);YBRP9FLSVQ=ZagIHujnB}OXi;*S!Y#<Snxyn31-4p01^n1)
zPfMrCmii#H8OYz{UtF&E&4Dw5J8i)g4)Hs4fr1mt+vGYQKEc2rASzH*xC1%C|GVM6
zz|u3YYUe9Q|1A1QWj(&?*KykF*{^8y;vmRn{b|DvIA#z91`SFTIza5s=ufk&gsUcr
zO5G)>tl5EA<Zbrjc8^bs04v;*9Lv)6%r@@}=0RpSF4WRBS5DD<HW<4V@wufSfv~^M
zmqjiM$<bR34{H+ApqJWAKa?oyFkiq~Z-3IsnvaX*->1nWFEO=5b~dgH--r{D?V0U)
zjM9Z>F^{@jb9Dn+<KwpRcFX6Q1N!)Y1n&L-H!awYa@$DwA|>12@nvgsrG2K#=W^iX
zbj4w}=IbzOrUBO$nqn=4W?5hb-}MAg65NukIeD0t?I~iYbj<$Xo=EgOvOAMVw-ZVa
zFD8YFKQ?xM<bItK`(Bk(2->${{DO&oKbGN}K~>}lntO-|5cg+Ujen!xMM0n$b*Q5!
z;eY)E;@Q6pk|j-vrnf`g_Apcj8Gg$kj`6)h$gg}0etF;Nh)|A5`JjWw$<BUn_SSmK
z7^dKTumnUF0&kWTPoBc1<xicB@SvCf3~>dU%JCgq<)Yq2*Q$Nt8?g}TLiL2G=km>Z
zEAY1dIZR+ai`*l9<~2Zi4)3r|xn0UB9X1~}a@p<G8VZ^he~0tw7!unUh)kivl_AVM
z{7H?K_794bN??d)0AFjhih;&+f1E3uRTD^>g&-i6NE@6xzN08vQ!FI&$$_3JTwO~!
z7W>SK)s`Hftn5s~W7xX3wFdre7Y!n}`U;|YHKrtzSHf*3y$Nf%+6_4m+oF8>4>2%>
z#bcFF(^!`5xnfHo!bT|AUpCW=h`c_GiuzsBr};|o5j5UI0i36`JWq?LFj~<>o|Qv2
z?RkpIO@Nms`y9-(tB$x0o#S?T@S0RMwI!nOrWRh;WQM=jrK*M{{utk&<GL(kH*q5Z
zKsTUA0Ya_(fFjTY;y{Lp_B(?r&WwH?QOR@{$IT&4c{8@0z>D{}yXU7#9F=^|;6k{=
z^zO*pi7vG*!w2FF(dHS!M%W#<tw*diEyljsbMSJBo4j{j(Zz6}pnL5o>bxYkOAhfq
zJ-@sabg_Bt4fKd^pOozk%vO~`%e9z?9haB1u0nEBX%PTL{;!ec9RV1`8>UnR9LjH_
z$p)AwNfEa~x>b(0di{WX#2Ku+B{6^Hm-(b6(w@D6VJKK|F^Jg)N!(pa!Psi6H6&I2
zaIQ7Cl}pWZHb8md2KQ?;rv48`ROrYSbY1l@p|zu;x=V1>i`eCZy}t{`mCHdLCE^;;
zWD|~p!1*;4+}GzYO2+Q#!ztuz6YLhMgwK7oSu^#JI`cK<ywYbiR*DTUJB1dctc*aE
zTj6F#KK9o$bhPlb?aKEsk<#=XK1+i$0{OADTDh1p*l#DYu#8^mFu7*&ap|>oeA+yy
zOoeaz<$$iZ3ch#sT>UH!oME8nE_Yk;7X270{}PqEe&$-xri%m4(opSFFSjLaPu<o*
zw6utr^5nlDI43C<G_|f#)`$Cb?LC|l0=JdrxV=-$z^zO>iPY&Um;W>?x<~!Q4;YTC
zFUU7IlHzQ1)$PpC-<PX5J(VM8XHmiS6{n}C7Hs!?T3Z0{j3z`gaWDjh$VJ1-^6sF|
zaQAEy>A=OoJk@9+w~w5t^anv~!?61&iu>eSu`I}j{jKlAffD7NB7-Cuf~})|CtRy1
zV2bt>Dj|AYg4Zt_09*M7eQ=eHwWa)Y<1_ZnK^Yt%Hh&0h1^vg%L3^b$9QqEByz9<E
zuqrtH5TQ+HOhlDYUl&v_Ps#IeSZK?mMJODS+s^+@p0_I~%p!i_NUgB+!s|fn=~r=*
zOE_%s+X9x{X*NB0K7DEEv2*6R<8nRCaV=ZQIZt<ibYelXA{LZ>$t!6cAcig{3jq2Y
zVQyV~Hu)=KP^_jA=lSl(+fSyiht4a!L+EKYR_Kyjr?HG!1U|+-o$R8BxkC|_4lGwb
zP8Q~~4ze*aDp2kQvR^SkpQ?pex1z49%kj}!`?MO)BYC}!W(@C>gVDuASN)wUrM)@%
zX(}4VHB|;Nf+Zd`A;jG55k$H5^adohDLG+`*sMTqH!qD?LQvs5#d>hT@g1~Ll#4tI
z8q#mV6gp0cSuOE4Ypy~oLH?Nb?l76ByJKmE<PzUQ+_%wE(C;a7PL<?D&9av9Rl$<A
z$LYiFT;uvN%A7#JyDj)IJ1r2*AqSzrirOK<6Rm6RfsedRG3fZX>nDrXPg&Ap>SMQ0
z043i?a)qW{7)J-C4tx-QZA>b(w;6m6u6usoxgY8uyuOvs5#zdXtREo~m<h7dH%Hoa
zMzCzP=3g_pgn%|TAifJYH+U8`LpA}wz`S{&@t^1tT^1wHBVH?$$|xIullcJOT*3k3
z*&<V&_prwLX9)=#55S&aYB-+)8f-R#5!KQhy@Pvqarl^c)WJAA&04l%cx&GL#(mZD
zu{u7%!1h9oP80VyNI}|IZyBtaE&p~JS_NMNSTY0RJ6@v@TF;z^gFp7C$0uAmwrSM#
z?Ci70a7QCDU4+QFocM`{N}AYK!)&2-3U2nV-o<ZwmbUi}OU!*Bq@E5sO|=1yzU^o-
z=0Y2G6+oDtmR6Z>2H{z7^|#(-4p*g$Q@7A>_WoJLLEIy1Cs)VChGl`8nLHY9xEc|M
zmHF+4@Hz$#zV*YlZ0`$u4?K2%L&QYZ2CaWf3?L%z8?fowYUk3khoD|oK@+cOWq{9F
zvT>mm6ex9P9)2pkubsFZNlFq`fQR~<zdBE?3yN#<u@-JM0rnO>)m_bJk@7On#z|rL
zroB{^aM)h@=WljT!N01=?}J6wT<!!^QAIf9R_9kY7^E+eCM}P2W0AM|1>9I)K}eex
z^2zkz$qDXS1^g9Z=I)WB@{bMKjjxMSML1DSZj5MsjXP-5-bw~20&MxPvCDc#l*HZh
zsCh4=GZRQTnK^9a@{5l4Tv^|&&qsu<H=*YZs_V0<Ut3b*H{nt@=ndQYdq8E6+6mTM
zft!dq?I5a4m*(B^okVepc=)xvl2FECtPR#5f%9`xR2gEV-&Sme@vyNdJ?C=`{m$U%
zYmsLL)L|Mibc#pYVdv`&9{GH_(wd!p&5ZayyXG^Q#E$J7r)mDNP4-2T&3kz)m1l2N
zl>3gNGafXaAG@83PgK2p7C?$}u|3$R(tN=#Ml}g+53)h*kDY=Vb<rW!_C-swLUs`-
z2aiEOqzizO&uXCkDWCh{@jZ`0$DMV(D($yey7y^{*M^UYA2LOyGtYkE1o`qMbMx-m
zv6WdOby4a6HHTBm8dQJIwnPKrd!)NeX9Vm4!b9+e|0w0>U72iwh+@B!*fE&};1Cz~
zU8fee&Dx#^N6}+WiUkK8M|BiPKEBK{sC(&8By_qw{G@J-!)*dl<#YVd!CUL#KpKW4
zm=JPs4j!d9OeIn0?T9=s)?ZfV$7N;wjHQIc>me(cUi9~!5c^#+E*?Ay#b|SeSQ-2~
zu<Zv84Tc7{1Sk-tf}R)AlAhV$eLT#tZ(ho3Co0~1#84v)k_W`8uUH0n!a0oWnFF3=
z+(g=jTF?b0;VVKdarVIoxQ35<JPcjwgy`onS?;1>ijd>k9({zDU=xuuH_zdF%e_}J
z75`-vf{nD^Og_C%gFRdSs_pz~t;}_nna}u!VycG1;LzDQyQi;))r+hEB~jbGNnRC!
zE04W|I(gm-R9LJ0?2{ht`N*Qv|A<w<cKR0PGO%o6;Ng|x?E9&g)CxZv%WMggFrFT-
zd}h{}4w7w3&?a=YxD*&B+3=N5kBWl>Bqq{A=5%Om_A_EZA1WL{!Z+<eE+JMyA1Hp4
z+FMjkKr&<}Za4|R1@ki<KAn_0HHet5<H<b?@Q7>-uenq~>H~;1Y*!e#!8XwAk6m2R
z6xs(qEEzvEkv=3unC;m)YTpHP06wW0a8f?$B~)_?zfT-G3E@%JJP-8;yb!#X4XG<-
zn&GNkVEcBkbV>G!FJe|hSD%0(9d_VRQSTW>xo)K8VvdR})7Hk(Mq#|&3bYTz-*of8
zddxk-dJVF)sGZ7Dn6O$wC|cnr>v!<p+Sl*N67$LlEw9L07mE*b`NZeI1i@4J*DV^Y
zc<B`3`Onmn1zz_+Z&Gd5`Z@!yTMU_WqignEE!<9rVcZ0HD(N*<$08%O)|VfBXtPFf
zl~SOj--7IC(7qRd-?M8l@-`s@8(!@$R|<(qcgjU}EAbso$?Voq2f<H@@S9^5q0RIH
zep4<f&>Qez`P@+Ix`=r--VKF3%8icMMZgx7D$;+v`bu$LLY`1tNHbGA)!32hDH_P~
zsF+mW?dzGBvaWpD@hjINuq%dvxMB0b$zLku%QaouHp=vq4P(XC>ho~d6)j-R5FxeB
zGx*!X9!mpqdukxkm_`AWwo>nhmSIBj>VaQZ5$%#-SYOo+9vuSL^m2Elv%WLwWOVAn
z6<`5@?`_nrZte2r>qYe}qH{W%V<y9hKP)X3WfmkOrvVg(dYt$IqL6Y3PMBi6KDY(9
z1Ajv2Mez9AQBRCG9>jRpV*(nI{9auS9y;*$MrBMcBpSKxXb5GqNpakf@<<O~YWtVM
zQbH;4y~hT0PgWACt$g>k;R<;;W8=PzkZ%exmcQ6;4C<|1dZq;UZ%bhV$9tPdJXO{(
zCcyAq?f}=vgp?{d{w55_B{NYh!tdK^NerX3Eydxz@VUBpSTRiQ5JX?_kqZtOlI{?E
zZHVo^IL|{b!n`^7fPFT8z!5jLX2Q)>OgecFSGeuPaGEhYEW(ki62{%wdM)&Z!Bya#
zuD5{E+pV_apH;6?kb6YsdAeVSn8qx$Cq?{Jhnyh(?sq2z{V@{C@e&G08fZYQO`M3`
z4RzIvnZ1Tp3x{^l=nM0)YVL5uEEOO_{R7x0H(+PBXExiX@-*8n^VKAD)hF-96Yv(j
z^%-#6^12b$pep4)I6cE!BkrKTg*^o6a?21Loz+frfq0Ioj?{XNWyl%_RF_<=5K7Is
z6aw}n4GU=mC!jIB#OL$KZ_{IJxu|n0kWD^nQ+lQ0Xh{C;MLI(C*%mnd=ah^BTf#b+
zHZqf*|33RiqYzK$qGv^d=me<({%AMR!IE2E5=_Bi%O-8}-b?KGwCj;X;;`ek>yv-N
z=>!7*IUhoi=3`MNIe{WPn%a6sl#KR)*opKUCwFSgB{t-<ccaW9gQ)9}v5df7HfCU4
zM>|OQ@Qj2I!8_nnn<RQzSB}W$66zL#2dv|U-M0T4m8ta!6ej2tev!m7M}0u{q)cFC
zY5F~PO(#u|X^NnF*k>u}xUgdlnjlXEAgj0yrVH`s&C`O*P86W^OcGvYFjKB#efAhN
z;bH>kuQohFU}U_jtW<~eA|gvCUBqu)a;@YJNSZk1a0GS=C#t47hwcMqF7A5&z5+t1
z86&t?1-ZzeT<)tAl58RnGqx<JV}&4tZSebQVN6Lt6=;k!NZ363fn*ltE<mIqVC&Jp
zpgrP6DB$&~TmBvhfSQE(=BRs?f9K*ma3Yng!*3*$`7Y|6B*ZlY8hPjOXG4gz?!>xz
z+4Cn7>OE5<5wm4^+jAVurt>sD#2d=yklgM}WbvyKG?m|Ouss8r&A75z`)WNP^uEGl
z-GudM!*w5<$IUQJY2i^bcG;I^o~I$xu317HB)+r&^!!q^zcQ<P8hZOD7?M@tOiQP^
z3mS>Rnd6Tr$LP@mtE)KDF_GUFet#mj4s^$K1p*E`(be~P^|{d$wj?G897q6D1PBp9
zx(3B%kR!Tg#TF8k&ci;`d6$sEhJ=?ZfCTOlyu}=K3Hd~|qT@UhjYCBqjLo8a9_-Cv
zO(4tzknq5svwv9H260Ct^86sIZ$$!0Qk{uQcjkAbeyb2o!kuz$bg&D<9JW1uJrumM
z@G>YTYq>U<5I8vEx6q0YIZf*gsG7d}yVu+(KJN`u+qLBPhFEbaCP|ECf&bNe=s%p@
zb&`3(vy%IxRMwn>ZtbUwJSAOzmu$$zN^AA3xc9-ob58nzO=+MuJAGn>Zo8BSk4Uk<
z|BwC5?q=yOlq$)BNE64jxxk4%jK_F0*_AOERVE^P6rlBVh0`^Rk(kdtuZkr^rmy1g
zqF&YXCO(xUO9>)RX?Iui!8Lh+TJoK?(DujeTPccmRpqh#N{VWmyivLDBcqS2%-PJG
zqffv6K$P2{r#MeWxXVwao!WecBjg7lw4N>COI1{%Yr4%U3|7%-acNk$XNt3VokCy)
z8>KhT?D$${IDSD}%}cNSz0yxV^nlyjU@g#=jLM~yq*@<aNdcwqqx(zCTGULH`AS||
zIRmje1K^SDGNAqYS8uUHb3Vdy)TnlMVrqQUp$#c#|2{Ohdy)^1-esXT*BTK>(Mvgb
z=-}10!=Gm`|7W&IR}i7AR>!eWg)I~hi1*GWC8@K7Q)PDJyqo|6FKzRXGvc^)HK5)s
zj=MhVDECKPr~ZAflAx_AF|jG9cJTuH@ZbHBZ7T%?UaJ~{NPl}pbsXlW8;Cf>&A$>c
z3Qm;C=NvLzvgvn%;7^ZIPc8WufLJdJ4G0_#y?Rw^4N@WdVr@RRLtFCl<*2a<)=BiH
z3=p-A<HcYQ_f>r=l@_74J=c@sE$JVvTqk89w&jx9B|8sBUT~@t-&%fv_F+wLUtB4<
zYV-WL!B5tHN}UN@LQHqiI?kT#9?JwJ@sp`!FBlZpC3SJQ6MY{(yF=uN$hdRGnXX?&
zp-}Dsmi69Fz!$2buAIM@bprx#Tsi5Ew`3F2?mrrbrtIN0UuLiyPL{XaY~K~Wd<}~;
z%0y2QQ6_mL6{PN=7`V{%gIR(7pq8Gbbfm@=%Z8*90WAa({%0<e&?Hp2Gv)_OiYxa^
zFvdpA?d761RjOyDpryo{481N<l-I6rbYl%xc>)M6QCYIp%rJ3YVCCl8uekV<*S{ao
zxdQ@%1+#*V{>zE}HFu!|uOio^<}zcok7*=n4D$N*d}+dSK~8K+9&e=sz9i!BlHwxM
zvm}u_SU#&t+}ITMOPjKZLl&uzMJ8zD9VheXmflI$g~l(ALBA4#bZYV>o)aXaa<6OB
z6UzD)aDl9tBa{|-YMG({FLXN{!Z0tcjSyhNVrc4>crxbAok8dbLq|X17H@vy8?8hi
z6W20K!U3>A3#uaEX~fb|z{ZN7?P2Q~Fep;6Y(j7!cv?YeWjzm1u0J}}_+-fdJ1jx2
zkpR*<Ob`$E-ojcw!_smuzxzP}Xy@7wD&YNq^l;zU9k%%h`B%#5gnW7iAP^#=i^@|5
z+m4X`q(0~7?oe>o;E;jp;x%R5jx<|+NNzvKlv~w+U)i{>301iKSQb?pj(`$f6ZKDI
zfklB<AdA7%-3lX<dV*WWS$jD);!~rDB;yDn_pcaYs0>acQc_R5_J@>2`dg=n&&{$l
zMWizBMJx>9H(1vM5`>qi&x_g5*;2uocUeOSa-S$iB&*B^KYh>`^V&3(a62WtrLe|L
zvDj#VV^$KbF40JvolLnD&e|&dG6IN#PJc*_GcwG}*!exP$)Jv&+LE$k!EVTh{G?_1
zF&_b4lDVYL(31E&r8=ds+VJ%)&qzx$p?_d?tz7=dav=`E+n>4tgK=EWWr4)FGh1qL
z)NXAS%W~NiGTvhlAimHVu%izr`;<x8neT761>Teg2t{;AiNZpxVq;U`0mD2=sg~qe
z#lWPw0b3_y%S6sXsNKVg!eGb~I9gMsxbj5DOu=CI*WW0HCPIC5qB^(2Y!Sb`@&)>o
zxF|>k>h}SJ>W%_l8^bDJotgCcLuF1H6mn)oi*^Jc7}#N}`&?gX&+#(a(+_lTDcw!g
zXwPjk*vAc^n5H+k5k>p}FYE2~{SORDmj8z#`QL2FUoxbUvkkp00W-rdXVTHhnShCj
z>3?KT{vVnm2RrNk#ZufDR@buIY(w(h)$1PxftKh}(nJAtTyO4YlgTX3+BU*~)+oiz
znMfoYmwCK(3r)5jZns`=>R=VH3T4jTkKcu%WE6rVS40$yCQKB!2`AE&Hw;%`jF2D#
zHArSCHF_hKHh((|t^oNKKv@iCkWeS`R|syxILfpK^qWGU3jrb>NQv+3TeN>8-ZGb8
z5V2Q|jX(fOMj}FCN*4da2@!Dw!v&gv^wby3f|8p#hLH>+of^o9QP~z~CX~z&*_WJx
z@~@2DuCS`Jgmm76t5xPni_d0kOkfNh1Bqv3-k^m_YvA=o{=KWVv}$U__;jOmdfOu>
zNcuAV#<QK>HT|!J!gRO7z?`h}U(2X25jNM)FlRs*7|uqSONd?O4TFAkt=&@5PO4Lx
zoWK2**<i~HKpB1w{njo@LB_3lW>2GeKZFy($<WiBSJFsS6-J_G=~s7qD<?HIHuYnh
z&A9|hvNrYAwl+E`g8zzf2}$Ftn}`Fw=RulSIxDIQ>q(;@E}M9#Fzjbz6eF<7gO01~
zoj!_tq|L`1th)F_)|E?Wfp5vwiziLKo$JqHNcq<8b3gX!P|iuxsU-i*e>ew9dHDc4
z<f*l35Mz;PK8PIl1T(5dS2{Q+q&i9c0R*nrzl3DqdO2zKT*xj|EZ{_2;3%N--O0{7
zsMFhQO|#k1Y)%^x_co<8@ba4X9mTsLhQ{^Fmie}7Li^|ey4w~KdiB^CSV^6OojR7`
z3Q2jGGEh-|K4zMxF{UZJZVPM&dfV>%C=cu12wWO`T9SQy%Krxy09c2F+A(cRl1dYO
zIAk6{sQ?rW(6SNJUN6&9$qZ2E`01;mN`N!W7f^fQeJ_Uw4`o&Mlh2af=7gwIOIBmF
zdwOh^4n{K%F#);9Un&n6%vit#VPN1q#%Ux^7hDP;e+E*PX3GpY%u0^Esgb2-;w(`p
zhfcmWHbX;yMX!K@`-ODf%I@*hGqFI_@i(bluK0w_F7u4-CtHkdta7+<Y>}x6u~<gr
zU9Ty{MFU&qnTPg~OcY(l<}^g7Pck&>+!lW4XLg2U_6EkNXXqZkL3rv;UU0z@l2s#^
z(Pf=p9S4gFBq*>(_)u~nZoRPfNdQrH^5t)3fvp*Pp3bp%o19!2WeJo~NygD21L|Qx
zbOstfne_c?qqr2h$<9$8wSfMP0Af43`VLy^RrYJi+d$o@g<9lxz;mGI7H&2Z*NhcL
zpEsdr9?>;e-99e-MB?L@si_&WBxq5xmU*&b3FUI6B5*XLK#;VVfRy=MouHg>FQP8^
zF~wkmmB*-6z0KK(Ze10!yQ{Cf91t%sKG)4>?bj7=E5smjn-)k%tjgQquCL8KT{G${
z9Q=3-f8F@`T^HGDTe}(Qy5GmuKX~}-n9B{{^R%A^i!<;=1j65DATY7)qduokpl08x
zTF=E=k9{>T<L$k)JeM~+DF%}{zGpL?cb1jlMHv1H)_IZc>H{E+TzY?1uGPD;`nzx5
z&YljJXFptW(fS2dq;sw~bdH8`*B!Py=N%Geu!DKS;W`2_?I~I!l1cg}M<BQ09<6(W
z58#n^?U=G@#2GBbinz3i(r&H!dhZJ-SLl4n8C{0BNwTfV!R*In@uKvVlHufH>w!gi
zxWut9ZGq!NfFsk~<l)fBkE;imocAY$WBO&PAg?Ahcw1O?nO$W|85X;`H$nL)OZZ2$
zzkrB;dxItsm!p$hwB-Md0l}Fe!#gC4*<+H!8Qf1T-Fsm%H|jbr8o{W$Ck}$xY-ZH{
z92XyiG_~icu4tv=R!JVx->%5QpgT2%ar>4%!vH?qrv-a4lHSW1ejha$B$q|7u%78T
zM+qRb->M0j8v#MGCCPW<K(b&Lb%(`jug4e(`FBVgzHc?##2xPQv|iI$$(Q1xDp;|H
zx7nN8w=Y}sO5nZ<Xbp9WwGj{n;P%exi}-K1|Mtl3_DQAB3}vFvO^~l_H~7;l;gdUG
z4(DX#E%2)Eb`N$kP;tQ|$VzK`jx_j!U}&05rvovb6iSK|Ls;49a&h>cPYI`276m0g
z0>dnTUQ(yDnzb`wbNqnWE{U~PK{8ZHbMXuTYvMja!h@b7jb$wY>PsL$1|P%<Eb26(
zO^+7~-f3J3qenh}gh6bdrmRiBl%CN3;e96Tw}czr<xRh7y!{C)WLg)`J|CVp2mf2s
zq+=eJ+-XiMJ{ex^+3Ps>i;Tysy1>su2D3DGj`Nvlae5C|7T>7hU$9rKVgZc2s#<mf
zUMB8vzP{AGy1^AAsiuH*{W|}21p2VG=lwEx{2AZS)sa%Fg%iB4e=~RnmeBf8RuIKi
zC~^QWB*6ZZ%m5gXxu6(7Wd1f`k3RjwxX$%=5PwUJ<;Gb{%FFNqMS9^#Huqrx3Uz@I
zm;u6jCHKNqS@xuGe04=<f{^$tiB7u@%a)#t!}J<%{K_V-S<vo~NSd58M>0~FjZ8C=
zRb@>R<<5fld2jqaVxQUd)Wxy?2h?W$f1|d#qKWCRkigi)oj{9$fQ3zmUX4JDk${<i
zNrzs^!qeo}MXzXQ=lttoAW-~`G_@o6k2pf{{}<U=*#2)|r=8`615`j6zIPgV#fAyJ
z*Qp?pOetp}LQY02t_L#UMxt&EV0=Ad>pl3fy_p8~FAVpGC7>kMNKgTa=v^_+fyhV;
zwVp_YVM?`GPteIgumA{O-rVw;9-QRa@iCKoIrit^?J9Gm5EJ=+%pGsYMmWuSt;im4
z*G5Py+wSm{#H{mil(2Q8{&;BeQ>Q>O{{OCvle2-Nv%8~-DHI0-2PZoeDXFO3AE^HY
DW42YE

literal 0
HcmV?d00001

diff --git a/e-compliance/ims/02_fuehrung/rollen-verantwortlichkeiten.md b/e-compliance/ims/02_fuehrung/rollen-verantwortlichkeiten.md
index ca7c9c5..b59fe25 100644
--- a/e-compliance/ims/02_fuehrung/rollen-verantwortlichkeiten.md
+++ b/e-compliance/ims/02_fuehrung/rollen-verantwortlichkeiten.md
@@ -12,21 +12,23 @@
 
 **Dokumenttyp:** Grundlagendokument (ISO 9001 / 27001 Kap. 5.3)
 
-Aufgrund der kleinen Teamgrösse (2-5 Personen) werden Rollen gebuendelt. Bündelung ist zulässig; entscheidend ist die dokumentierte, namentliche Zuweisung. Wo Funktionstrennung fehlt, greifen kompensierende Massnahmen.
+Aufgrund der kleinen Teamgrösse (2-5 Personen) werden Rollen gebuendelt. Bündelung ist zulässig; entscheidend ist die dokumentierte Zuweisung. **Namentliche Träger** stehen zentral im [Personen-Rollen-Mapping](personen-rollen-mapping.md) — diese Matrix enthält nur Funktionen.
 
 ## 1. Rollenmatrix
 
 | Rolle | Verantwortung / Befugnis | Träger |
 |---|---|---|
-| Oberste Leitung (Geschäftsführung) | Gesamtverantwortung IMS, Freigabe Politiken, Ressourcen, Management-Review | Patrick Motsch (p.motsch@poweron.swiss) |
-| Informationssicherheits-Beauftragter (ISB / CISO-Funktion) | ISMS-Pflege, Risikobeurteilung, SoA, Steuerung Annex-A-Controls | Patrick Motsch |
-| Qualitätsmanagement-Beauftragter (QMB) | QMS-Pflege, Prozesssteuerung, KVP, Audit-Koordination | Patrick Motsch |
-| Dokumentenlenkungs-Verantwortlicher | Pflege Header-Standard, Dokumentenregister, Review-Zyklen | Patrick Motsch |
-| Datenschutzverantwortlicher | DSG/DSGVO, AVV-Management | Patrick Motsch |
-| Betrieb / DevOps & Incident-Verantwortlicher | Server, Deployment, Backups, Vorfallbehandlung | Patrick Motsch |
-| Drittdienst-/Lieferanten-Verantwortlicher | Drittanbieter-Inventar, AVVs, Subunternehmer | Patrick Motsch |
+| Oberste Leitung (Geschäftsführung) | Gesamtverantwortung IMS, Freigabe Politiken, Ressourcen, Management-Review | → Mapping |
+| Informationssicherheits-Beauftragter (ISB / CISO-Funktion) | ISMS-Pflege, Risikobeurteilung, SoA, Steuerung Annex-A-Controls | → Mapping |
+| Qualitätsmanagement-Beauftragter (QMB) | QMS-Pflege, Prozesssteuerung, KVP, Audit-Koordination | → Mapping |
+| Dokumentenlenkungs-Verantwortlicher | Pflege Header-Standard, Dokumentenregister, Review-Zyklen | → Mapping |
+| Datenschutzverantwortlicher | DSG/DSGVO, AVV-Management | → Mapping |
+| Betrieb / DevOps & Incident-Verantwortlicher | Server, Deployment, Backups, Vorfallbehandlung | → Mapping |
+| Drittdienst-/Lieferanten-Verantwortlicher | Drittanbieter-Inventar, AVVs, Subunternehmer | → Mapping |
 | Risiko-Eigner (Risk Owner) | Verantwortung je wesentlichem Risiko/Asset | gemäss [Risikoregister](../03_planung/risikoregister.md) |
-| Interner Auditor | Unabhängige Prüfung des IMS | **Extern, noch zu benennen** (Unabhängigkeit erforderlich) |
+| Interner Auditor | Unabhängige Prüfung des IMS | → Mapping (extern, Unabhängigkeit erforderlich) |
+
+Amtsinhaber: [personen-rollen-mapping.md](personen-rollen-mapping.md) Abschnitt 2.
 
 ## 2. Hinweis zur Funktionstrennung
 
@@ -38,8 +40,8 @@ Da derzeit zentrale Rollen bei einer Person liegen, sind folgende kompensierende
 
 ## 3. Operative Organisation
 
-Die geschäftliche Aufgabenverteilung, Meetingstruktur (Operations, Verwaltungsrat) und Koordinationsrollen sind im [Organisationsreglement](organisationsreglement.md) geregelt. Dort adressiert die vorgeschlagene Struktur auch die Entlastung zentraler Personen (kompensierende Massnahme zu R-01).
+Die geschäftliche Aufgabenverteilung, Meetingstruktur (Operations, Verwaltungsrat) und Koordinationsrollen sind im [Organisationsreglement](organisationsreglement.md) geregelt. Die operative Entlastungsstruktur adressiert das Schlüsselpersonenrisiko (R-01) als kompensierende Massnahme.
 
 ## 4. Pflege
 
-Änderungen an der Rollenzuweisung werden hier nachgeführt und im Management-Review bestätigt. Operative Anpassungen zusätzlich im Organisationsreglement. Bei Teamwachstum sind Rollen zu entflechten (insb. interner Auditor, Release-Freigabe vs. Entwicklung).
+Änderungen an Rolleninhalten in dieser Matrix bzw. im Organisationsreglement; **Personenwechsel nur** im [Personen-Rollen-Mapping](personen-rollen-mapping.md). Wesentliche Änderungen im Management-Review bestätigen. Bei Teamwachstum Rollen entflechten (insb. interner Auditor, Release-Freigabe vs. Entwicklung).
diff --git a/e-compliance/ims/03_planung/risikoregister.md b/e-compliance/ims/03_planung/risikoregister.md
index fe4beeb..8e39073 100644
--- a/e-compliance/ims/03_planung/risikoregister.md
+++ b/e-compliance/ims/03_planung/risikoregister.md
@@ -17,7 +17,7 @@ Bewertung gemäss [Risikomanagement-Methodik](risikomanagement-methodik.md). W =
 
 | ID | Risiko | Kategorie | W | A | R | Klasse | Behandlung | Owner | Annex-A-Bezug |
 |---|---|---|---|---|---|---|---|---|---|
-| R-01 | Schlüsselpersonenrisiko (Wissen/Zugriffe auf eine Person konzentriert) | Organisation | 3 | 4 | 12 | hoch | Vertretung, Dokumentation, Break-Glass; operative Entlastung via [Organisationsreglement](../02_fuehrung/organisationsreglement.md) (Chris, Rollenverteilung) | Patrick Motsch | A.5.2, A.5.4 |
+| R-01 | Schlüsselpersonenrisiko (Wissen/Zugriffe auf eine Person konzentriert) | Organisation | 3 | 4 | 12 | hoch | Vertretung, Dokumentation, Break-Glass; operative Entlastung via [Organisationsreglement](../02_fuehrung/organisationsreglement.md) (Rolle OP) | Patrick Motsch (GF) | A.5.2, A.5.4 |
 | R-02 | Abfluss sensibler Inhaltsdaten an externe LLM-Provider (OpenAI/USA) | Datenschutz | 3 | 4 | 12 | hoch | Neutralisierung, AVV/DPA + EU-SCC, Zero-Retention prüfen | Patrick Motsch | A.5.14, A.8.12 |
 | R-03 | MFA auf Admin-/Server-Zugängen | Zugriff | 1 | 2 | 2 | niedrig | Umgesetzt (Juni 2026); periodische Rezertifizierung halbjährlich | Patrick Motsch | A.5.17, A.8.5 |
 | R-04 | Backup nicht wiederherstellbar (Restore nie getestet) | Verfügbarkeit | 2 | 4 | 8 | mittel | Restore-Test durchführen & protokollieren | Patrick Motsch | A.8.13 |
diff --git a/e-compliance/ims/04_unterstuetzung/dokumentenregister.md b/e-compliance/ims/04_unterstuetzung/dokumentenregister.md
index d49c154..a40fd12 100644
--- a/e-compliance/ims/04_unterstuetzung/dokumentenregister.md
+++ b/e-compliance/ims/04_unterstuetzung/dokumentenregister.md
@@ -21,6 +21,7 @@ Zentrales Verzeichnis aller gelenkten IMS-Dokumente. Massgeblich für Status, Ow
 | IMS-05-02 | Informationssicherheitspolitik | `02_fuehrung/informationssicherheitspolitik.md` | Patrick Motsch | entwurf |
 | IMS-05-03 | Rollen & Verantwortlichkeiten | `02_fuehrung/rollen-verantwortlichkeiten.md` | Patrick Motsch | entwurf |
 | IMS-05-04 | Organisationsreglement | `02_fuehrung/organisationsreglement.md` | Patrick Motsch | entwurf |
+| IMS-05-05 | Personen-Rollen-Mapping | `02_fuehrung/personen-rollen-mapping.md` | Patrick Motsch | entwurf |
 | IMS-06-01 | Risikomanagement-Methodik | `03_planung/risikomanagement-methodik.md` | Patrick Motsch | entwurf |
 | IMS-06-02 | Risikoregister | `03_planung/risikoregister.md` | Patrick Motsch | entwurf |
 | IMS-06-03 | Statement of Applicability (SoA) | `03_planung/statement-of-applicability-soa.md` | Patrick Motsch | entwurf |
diff --git a/e-compliance/ims/04_unterstuetzung/kommunikation.md b/e-compliance/ims/04_unterstuetzung/kommunikation.md
index 222412e..d7407c9 100644
--- a/e-compliance/ims/04_unterstuetzung/kommunikation.md
+++ b/e-compliance/ims/04_unterstuetzung/kommunikation.md
@@ -23,11 +23,11 @@ Regelt, **was, wann, mit wem und wie** im Kontext des IMS kommuniziert wird.
 | Incidents | sofort | Melder -> Incident-Verantwortlicher | definierter Meldeweg |
 | Release Notes / Changes | je Release | Release-Verantwortlicher -> Team | CHANGELOG, Wiki |
 | Management-Review-Ergebnisse | nach Review | Leitung -> Team | Protokoll |
-| Operations-Meeting | wöchentlich | Patrick, Dominic, Chris (+ ggf. Silvan) | Meeting (Moderation: Chris, Vorschlag) — Daily Business, operative Entscheide, Zahlen |
-| Verwaltungsrat (POL) | wöchentlich → Ziel: zweiwöchentlich/monatlich | VR | Strategie, Finanzen, Eskalation aus Operations |
-| POL — physisches Treffen | quartalsweise (Vorschlag) | VR | Abendessen / strategischer Austausch |
+| Operations-Meeting | wöchentlich | GF, VSO, OP (+ ggf. FT) | Meeting — Moderation OP; Daily Business, operative Entscheide, Zahlen |
+| Verwaltungsrat | ab Jul 2026 2-wöchentlich, ab Q4 2026 monatlich | VR | Strategie, Finanzen, Eskalation aus Operations |
+| VR — physisches Treffen | quartalsweise | VR | Abendessen / strategischer Austausch |
 
-Details und offene POL-Entscheide: [Organisationsreglement](../02_fuehrung/organisationsreglement.md).
+Rollencodes und Amtsinhaber: [Personen-Rollen-Mapping](../02_fuehrung/personen-rollen-mapping.md). Details: [Organisationsreglement](../02_fuehrung/organisationsreglement.md).
 
 ## 2. Externe Kommunikation
 
diff --git a/e-compliance/ims/07_verbesserung/massnahmen-register.md b/e-compliance/ims/07_verbesserung/massnahmen-register.md
index bc67287..693e25b 100644
--- a/e-compliance/ims/07_verbesserung/massnahmen-register.md
+++ b/e-compliance/ims/07_verbesserung/massnahmen-register.md
@@ -32,7 +32,7 @@ Zentrale Liste aller Korrektur- und Verbesserungsmassnahmen. Das [Management-Coc
 | M-11 | Risikoworkshop zur Validierung des Risikoregisters | Patrick Motsch | Risiko | 2026-06-03 | 2026-06-30 | offen |
 | M-12 | Asset-Inventar erstellen (A.5.9) | Patrick Motsch | Doku | 2026-06-03 | 2026-08-31 | offen |
 | M-13 | Politiken formal freigeben (Status entwurf -> freigegeben) | Patrick Motsch | Doku | 2026-06-03 | 2026-07-31 | offen |
-| M-14 | Organisationsreglement und Meetingstruktur im POL bestätigen | Patrick Motsch | Review | 2026-06-11 | 2026-06-30 | in Arbeit |
+| M-14 | Organisationsreglement administrativ durch Verwaltungsrat freigeben | Patrick Motsch | Review | 2026-06-11 | 2026-06-12 | in Arbeit |
 
 ## Pflegehinweis
 
diff --git a/e-compliance/ims/cockpit/IMS-Cockpit.html b/e-compliance/ims/cockpit/IMS-Cockpit.html
index e369447..a74ce01 100644
--- a/e-compliance/ims/cockpit/IMS-Cockpit.html
+++ b/e-compliance/ims/cockpit/IMS-Cockpit.html
@@ -2127,7 +2127,7 @@ Expecting `+Ze.join(", ")+", got '"+(this.terminals_[Ne]||Ne)+"'":Dt="Parse erro
   }
 `;function lYe(i,a,u=!1){var R,B,j;const d=i;let p="default";(((R=d==null?void 0:d.classes)==null?void 0:R.length)||0)>0&&(p=((d==null?void 0:d.classes)||[]).join(" ")),p=p+" flowchart-label";let v=0,b="",y;switch(d.type){case"round":v=5,b="rect";break;case"composite":v=0,b="composite",y=0;break;case"square":b="rect";break;case"diamond":b="question";break;case"hexagon":b="hexagon";break;case"block_arrow":b="block_arrow";break;case"odd":b="rect_left_inv_arrow";break;case"lean_right":b="lean_right";break;case"lean_left":b="lean_left";break;case"trapezoid":b="trapezoid";break;case"inv_trapezoid":b="inv_trapezoid";break;case"rect_left_inv_arrow":b="rect_left_inv_arrow";break;case"circle":b="circle";break;case"ellipse":b="ellipse";break;case"stadium":b="stadium";break;case"subroutine":b="subroutine";break;case"cylinder":b="cylinder";break;case"group":b="rect";break;case"doublecircle":b="doublecircle";break;default:b="rect"}const E=gm((d==null?void 0:d.styles)||[]),_=d.label,A=d.size||{width:0,height:0,x:0,y:0};return{labelStyle:E.labelStyle,shape:b,labelText:_,rx:v,ry:v,class:p,style:E.style,id:d.id,directions:d.directions,width:A.width,height:A.height,x:A.x,y:A.y,positioned:u,intersect:void 0,type:d.type,padding:y??(((j=(B=mh())==null?void 0:B.block)==null?void 0:j.padding)||0)}}async function Hcn(i,a,u){const d=lYe(a,u,!1);if(d.type==="group")return;const p=await pJ(i,d),v=p.node().getBBox(),b=u.getBlock(d.id);b.size={width:v.width,height:v.height,x:0,y:0,node:p},u.setBlock(b),p.remove()}async function Ucn(i,a,u){const d=lYe(a,u,!0);u.getBlock(d.id).type!=="space"&&(await pJ(i,d),a.intersect=d==null?void 0:d.intersect,ive(d))}async function Dwe(i,a,u,d){for(const p of a)await d(i,p,u),p.children&&await Dwe(i,p.children,u,d)}async function Vcn(i,a,u){await Dwe(i,a,u,Hcn)}async function Gcn(i,a,u){await Dwe(i,a,u,Ucn)}async function Kcn(i,a,u,d,p){const v=new R0({multigraph:!0,compound:!0});v.setGraph({rankdir:"TB",nodesep:10,ranksep:10,marginx:8,marginy:8});for(const b of u)b.size&&v.setNode(b.id,{width:b.size.width,height:b.size.height,intersect:b.intersect});for(const b of a)if(b.start&&b.end){const y=d.getBlock(b.start),E=d.getBlock(b.end);if(y!=null&&y.size&&(E!=null&&E.size)){const _=y.size,A=E.size,P=[{x:_.x,y:_.y},{x:_.x+(A.x-_.x)/2,y:_.y+(A.y-_.y)/2},{x:A.x,y:A.y}];await cGe(i,{v:b.start,w:b.end,name:b.id},{...b,arrowTypeEnd:b.arrowTypeEnd,arrowTypeStart:b.arrowTypeStart,points:P,classes:"edge-thickness-normal edge-pattern-solid flowchart-link LS-a1 LE-b1"},void 0,"block",v,p),b.label&&(await sve(i,{...b,label:b.label,labelStyle:"stroke: #333; stroke-width: 1.5px;fill:none;",arrowTypeEnd:b.arrowTypeEnd,arrowTypeStart:b.arrowTypeStart,points:P,classes:"edge-thickness-normal edge-pattern-solid flowchart-link LS-a1 LE-b1"}),await aGe({...b,x:P[1].x,y:P[1].y},{originalPath:P}))}}}const Jf=((gYe=(dYe=qt())==null?void 0:dYe.block)==null?void 0:gYe.padding)||8;function Wcn(i,a){if(i===0||!Number.isInteger(i))throw new Error("Columns must be an integer !== 0.");if(a<0||!Number.isInteger(a))throw new Error("Position must be a non-negative integer."+a);if(i<0)return{px:a,py:0};if(i===1)return{px:0,py:a};const u=a%i,d=Math.floor(a/i);return{px:u,py:d}}const Ycn=i=>{let a=0,u=0;for(const d of i.children){const{width:p,height:v,x:b,y}=d.size||{width:0,height:0,x:0,y:0};Xe.debug("getMaxChildSize abc95 child:",d.id,"width:",p,"height:",v,"x:",b,"y:",y,d.type),d.type!=="space"&&(p>a&&(a=p/(i.widthInColumns||1)),v>u&&(u=v))}return{width:a,height:u}};function Iwe(i,a,u=0,d=0){var b,y,E,_,A,P,R,B,j,W,ee;Xe.debug("setBlockSizes abc95 (start)",i.id,(b=i==null?void 0:i.size)==null?void 0:b.x,"block width =",i==null?void 0:i.size,"sieblingWidth",u),(y=i==null?void 0:i.size)!=null&&y.width||(i.size={width:u,height:d,x:0,y:0});let p=0,v=0;if(((E=i.children)==null?void 0:E.length)>0){for(const de of i.children)Iwe(de,a);const ie=Ycn(i);p=ie.width,v=ie.height,Xe.debug("setBlockSizes abc95 maxWidth of",i.id,":s children is ",p,v);for(const de of i.children)de.size&&(Xe.debug(`abc95 Setting size of children of ${i.id} id=${de.id} ${p} ${v} ${de.size}`),de.size.width=p*(de.widthInColumns||1)+Jf*((de.widthInColumns||1)-1),de.size.height=v,de.size.x=0,de.size.y=0,Xe.debug(`abc95 updating size of ${i.id} children child:${de.id} maxWidth:${p} maxHeight:${v}`));for(const de of i.children)Iwe(de,a,p,v);const oe=i.columns||-1;let be=0;for(const de of i.children)be+=de.widthInColumns||1;let ge=i.children.length;oe>0&&oe<be&&(ge=oe),i.widthInColumns;const ae=Math.ceil(be/ge);let ne=ge*(p+Jf)+Jf,se=ae*(v+Jf)+Jf;if(ne<u){Xe.debug(`Detected to small siebling: abc95 ${i.id} sieblingWidth ${u} sieblingHeight ${d} width ${ne}`),ne=u,se=d;const de=(u-ge*Jf-Jf)/ge,X=(d-ae*Jf-Jf)/ae;Xe.debug("Size indata abc88",i.id,"childWidth",de,"maxWidth",p),Xe.debug("Size indata abc88",i.id,"childHeight",X,"maxHeight",v),Xe.debug("Size indata abc88 xSize",ge,"padding",Jf);for(const pe of i.children)pe.size&&(pe.size.width=de,pe.size.height=X,pe.size.x=0,pe.size.y=0)}if(Xe.debug(`abc95 (finale calc) ${i.id} xSize ${ge} ySize ${ae} columns ${oe}${i.children.length} width=${Math.max(ne,((_=i.size)==null?void 0:_.width)||0)}`),ne<(((A=i==null?void 0:i.size)==null?void 0:A.width)||0)){ne=((P=i==null?void 0:i.size)==null?void 0:P.width)||0;const de=oe>0?Math.min(i.children.length,oe):i.children.length;if(de>0){const X=(ne-de*Jf-Jf)/de;Xe.debug("abc95 (growing to fit) width",i.id,ne,(R=i.size)==null?void 0:R.width,X);for(const pe of i.children)pe.size&&(pe.size.width=X)}}i.size={width:ne,height:se,x:0,y:0}}Xe.debug("setBlockSizes abc94 (done)",i.id,(B=i==null?void 0:i.size)==null?void 0:B.x,(j=i==null?void 0:i.size)==null?void 0:j.width,(W=i==null?void 0:i.size)==null?void 0:W.y,(ee=i==null?void 0:i.size)==null?void 0:ee.height)}function hYe(i,a){var d,p,v,b,y,E,_,A,P,R,B,j,W,ee,ie,oe,be;Xe.debug(`abc85 layout blocks (=>layoutBlocks) ${i.id} x: ${(d=i==null?void 0:i.size)==null?void 0:d.x} y: ${(p=i==null?void 0:i.size)==null?void 0:p.y} width: ${(v=i==null?void 0:i.size)==null?void 0:v.width}`);const u=i.columns||-1;if(Xe.debug("layoutBlocks columns abc95",i.id,"=>",u,i),i.children&&i.children.length>0){const ge=((y=(b=i==null?void 0:i.children[0])==null?void 0:b.size)==null?void 0:y.width)||0,ae=i.children.length*ge+(i.children.length-1)*Jf;Xe.debug("widthOfChildren 88",ae,"posX");let ne=0;Xe.debug("abc91 block?.size?.x",i.id,(E=i==null?void 0:i.size)==null?void 0:E.x);let se=(_=i==null?void 0:i.size)!=null&&_.x?((A=i==null?void 0:i.size)==null?void 0:A.x)+(-((P=i==null?void 0:i.size)==null?void 0:P.width)/2||0):-Jf,de=0;for(const X of i.children){const pe=i;if(!X.size)continue;const{width:G,height:xe}=X.size,{px:U,py:Be}=Wcn(u,ne);if(Be!=de&&(de=Be,se=(R=i==null?void 0:i.size)!=null&&R.x?((B=i==null?void 0:i.size)==null?void 0:B.x)+(-((j=i==null?void 0:i.size)==null?void 0:j.width)/2||0):-Jf,Xe.debug("New row in layout for block",i.id," and child ",X.id,de)),Xe.debug(`abc89 layout blocks (child) id: ${X.id} Pos: ${ne} (px, py) ${U},${Be} (${(W=pe==null?void 0:pe.size)==null?void 0:W.x},${(ee=pe==null?void 0:pe.size)==null?void 0:ee.y}) parent: ${pe.id} width: ${G}${Jf}`),pe.size){const Pe=G/2;X.size.x=se+Jf+Pe,Xe.debug(`abc91 layout blocks (calc) px, pyid:${X.id} startingPos=X${se} new startingPosX${X.size.x} ${Pe} padding=${Jf} width=${G} halfWidth=${Pe} => x:${X.size.x} y:${X.size.y} ${X.widthInColumns} (width * (child?.w || 1)) / 2 ${G*((X==null?void 0:X.widthInColumns)||1)/2}`),se=X.size.x+Pe,X.size.y=pe.size.y-pe.size.height/2+Be*(xe+Jf)+xe/2+Jf,Xe.debug(`abc88 layout blocks (calc) px, pyid:${X.id}startingPosX${se}${Jf}${Pe}=>x:${X.size.x}y:${X.size.y}${X.widthInColumns}(width * (child?.w || 1)) / 2${G*((X==null?void 0:X.widthInColumns)||1)/2}`)}X.children&&hYe(X),ne+=(X==null?void 0:X.widthInColumns)||1,Xe.debug("abc88 columnsPos",X,ne)}}Xe.debug(`layout blocks (<==layoutBlocks) ${i.id} x: ${(ie=i==null?void 0:i.size)==null?void 0:ie.x} y: ${(oe=i==null?void 0:i.size)==null?void 0:oe.y} width: ${(be=i==null?void 0:i.size)==null?void 0:be.width}`)}function fYe(i,{minX:a,minY:u,maxX:d,maxY:p}={minX:0,minY:0,maxX:0,maxY:0}){if(i.size&&i.id!=="root"){const{x:v,y:b,width:y,height:E}=i.size;v-y/2<a&&(a=v-y/2),b-E/2<u&&(u=b-E/2),v+y/2>d&&(d=v+y/2),b+E/2>p&&(p=b+E/2)}if(i.children)for(const v of i.children)({minX:a,minY:u,maxX:d,maxY:p}=fYe(v,{minX:a,minY:u,maxX:d,maxY:p}));return{minX:a,minY:u,maxX:d,maxY:p}}function Xcn(i){const a=i.getBlock("root");if(!a)return;Iwe(a,i,0,0),hYe(a),Xe.debug("getBlocks",JSON.stringify(a,null,2));const{minX:u,minY:d,maxX:p,maxY:v}=fYe(a),b=v-d,y=p-u;return{x:u,y:d,width:y,height:b}}const Qcn=Object.freeze(Object.defineProperty({__proto__:null,diagram:{parser:Mcn,db:zcn,renderer:{draw:async function(i,a,u,d){const{securityLevel:p,block:v}=mh(),b=d.db;let y;p==="sandbox"&&(y=Dr("#i"+a));const E=Dr(p==="sandbox"?y.nodes()[0].contentDocument.body:"body"),_=p==="sandbox"?E.select(`[id="${a}"]`):Dr(`[id="${a}"]`);Ume(_,["point","circle","cross"],d.type,a);const P=b.getBlocks(),R=b.getBlocksFlat(),B=b.getEdges(),j=_.insert("g").attr("class","block");await Vcn(j,P,b);const W=Xcn(b);if(await Gcn(j,P,b),await Kcn(j,B,R,b,a),W){const ee=W,ie=Math.max(1,Math.round(.125*(ee.width/ee.height))),oe=ee.height+ie+10,be=ee.width+10,{useMaxWidth:ge}=v;Fg(_,oe,be,!!ge),Xe.debug("Here Bounds",W,ee),_.attr("viewBox",`${ee.x-5} ${ee.y-5} ${ee.width+10} ${ee.height+10}`)}PF(sRe)},getClasses:function(i,a){return a.db.getClasses()}},styles:qcn}},Symbol.toStringTag,{value:"Module"}));return bm});
 </script>
-<script>window.IMS_DATA = {"docs": [{"id": "00_IMS-Handbuch.md", "path": "00_IMS-Handbuch.md", "chapter": "00", "title": "IMS-Handbuch -- Integriertes Managementsystem PowerOn AG", "filename": "00_IMS-Handbuch.md", "meta": {"docId": "IMS-00", "status": "entwurf", "version": "0.1", "owner": "Patrick Motsch", "approver": "Geschäftsführung PowerOn AG", "approvedDate": "", "nextReview": "2027-06-03", "classification": "intern", "isoRefs": "9001:4-10; 27001:4-10"}, "html": "<h1>IMS-Handbuch -- Integriertes Managementsystem PowerOn AG<\/h1>\n<p>Dachdokument des integrierten Managementsystems (IMS) der PowerOn AG. Das IMS deckt <strong>ISO 9001 (Qualität)<\/strong> und <strong>ISO/IEC 27001 (Informationssicherheit)<\/strong> gemeinsam ab. Beide Normen teilen die High-Level-Structure (Annex SL, Kapitel 4-10); dieses Handbuch und die referenzierten Dokumente bilden ein einziges, doppelt verwendetes Dokumentenset.<\/p>\n<h2>1. Zweck<\/h2>\n<p>Das IMS stellt sicher, dass PowerOn<\/p>\n<ul><li>Produkte und Dienstleistungen in gleichbleibender Qualität liefert (ISO 9001),<\/li><li>Informationen und Kundendaten vertraulich, integer und verfügbar hält (ISO 27001),<\/li><li>gesetzliche, vertragliche und regulatorische Anforderungen erfüllt,<\/li><li>sich kontinuierlich verbessert (KVP) und auditierbar bleibt.<\/li><\/ul>\n<h2>2. Geltungsbereich (Kurzfassung)<\/h2>\n<p>Gesamte PowerOn AG inkl. Entwicklung, Betrieb und Produktmanagement der <strong>PORTA Enterprise KI-Plattform<\/strong> (<code>api.poweron.swiss<\/code>). Vollständige Fassung: <a href=\"01_kontext/geltungsbereich-scope.md\">01_kontext/geltungsbereich-scope.md<\/a>.<\/p>\n<h2>3. Aufbau des IMS (Navigationskarte)<\/h2>\n<table><thead><tr><th>Kapitel (ISO)<\/th><th>Ordner<\/th><th>Inhalt<\/th><\/tr><\/thead><tbody><tr><td>4 Kontext<\/td><td><code>01_kontext/<\/code><\/td><td>Kontext &amp; interessierte Parteien, Geltungsbereich<\/td><\/tr><tr><td>5 Führung<\/td><td><code>02_fuehrung/<\/code><\/td><td>QM-Politik, IS-Politik, Rollen, Organisationsreglement<\/td><\/tr><tr><td>6 Planung<\/td><td><code>03_planung/<\/code><\/td><td>Risikomethodik, Risikoregister, SoA, Ziele/KPI<\/td><\/tr><tr><td>7 Unterstützung<\/td><td><code>04_unterstuetzung/<\/code><\/td><td>Kompetenz/Schulung, Kommunikation, Dokumentenlenkung, Register<\/td><\/tr><tr><td>8 Betrieb + Annex A<\/td><td><code>05_betrieb/<\/code><\/td><td>Operative Prozesse &amp; Sicherheits-Controls<\/td><\/tr><tr><td>9 Bewertung<\/td><td><code>06_bewertung/<\/code><\/td><td>Internes Audit, Management-Review, Monitoring<\/td><\/tr><tr><td>10 Verbesserung<\/td><td><code>07_verbesserung/<\/code><\/td><td>Korrekturmassnahmen/KVP, Massnahmenregister<\/td><\/tr><tr><td>Mappings<\/td><td><code>mappings/<\/code><\/td><td>SoA/Annex-A-, ISO-9001-Klausel-, CACC-Crosswalk<\/td><\/tr><tr><td>Cockpit<\/td><td><code>cockpit/<\/code><\/td><td>HTML-Management-Cockpit (Generator + generierte Datei)<\/td><\/tr><\/tbody><\/table>\n<h2>4. Dokumentenpyramide<\/h2>\n<ol><li><strong>Ebene 1 -- Politiken / Handbuch:<\/strong> dieses Handbuch, QM-Politik, IS-Politik, Geltungsbereich, Ziele.<\/li><li><strong>Ebene 2 -- Verfahren / Prozesse:<\/strong> Risiko, Change, Incident, internes Audit, Management-Review, KVP.<\/li><li><strong>Ebene 3 -- Arbeitsanweisungen / Runbooks:<\/strong> BCM-Runbook, Datenbank-Handling, Deployment.<\/li><li><strong>Ebene 4 -- Records / Nachweise:<\/strong> Risikoregister, Audit-Berichte, Schulungsnachweise, Logs, Massnahmenregister.<\/li><\/ol>\n<h2>5. Verantwortung der obersten Leitung<\/h2>\n<p>Die Geschäftsführung verpflichtet sich zum Aufbau, Betrieb und zur kontinuierlichen Verbesserung des IMS, stellt die erforderlichen Ressourcen bereit, gibt die Politiken frei und führt das Management-Review durch (Details: <a href=\"02_fuehrung/\">Führung<\/a>, <a href=\"06_bewertung/management-review.md\">Management-Review<\/a>).<\/p>\n<h2>6. Dokumentenlenkung<\/h2>\n<p>Alle gelenkten Dokumente tragen einen einheitlichen Metadaten-Header und werden über Git/Forgejo versioniert und per Pull-Request-Review freigegeben. Verfahren: <a href=\"04_unterstuetzung/dokumentenlenkung.md\">04_unterstützung/dokumentenlenkung.md<\/a>. Zentrale Übersicht: <a href=\"04_unterstuetzung/dokumentenregister.md\">04_unterstützung/dokumentenregister.md<\/a>.<\/p>\n<h2>7. Status des IMS<\/h2>\n<p>Aufbauphase (Fast-Track). Ziel: ein gelebtes, audit-reifes IMS; Auswahl der Zertifizierungsstelle ist bewusst nachgelagert. Offene Punkte werden im <a href=\"07_verbesserung/massnahmen-register.md\">Massnahmenregister<\/a> geführt.<\/p>", "text": "<!-- docid: ims-00 --> <!-- status: entwurf --> <!-- version: 0.1 --> <!-- owner: patrick motsch --> <!-- approver: geschäftsführung poweron ag --> <!-- approveddate: --> <!-- nextreview: 2027-06-03 --> <!-- classification: intern --> <!-- isorefs: 9001:4-10; 27001:4-10 --> # ims-handbuch -- integriertes managementsystem poweron ag dachdokument des integrierten managementsystems (ims) der poweron ag. das ims deckt **iso 9001 (qualität)** und **iso/iec 27001 (informationssicherheit)** gemeinsam ab. beide normen teilen die high-level-structure (annex sl, kapitel 4-10); dieses handbuch und die referenzierten dokumente bilden ein einziges, doppelt verwendetes dokumentenset. ## 1. zweck das ims stellt sicher, dass poweron - produkte und dienstleistungen in gleichbleibender qualität liefert (iso 9001), - informationen und kundendaten vertraulich, integer und verfügbar hält (iso 27001), - gesetzliche, vertragliche und regulatorische anforderungen erfüllt, - sich kontinuierlich verbessert (kvp) und auditierbar bleibt. ## 2. geltungsbereich (kurzfassung) gesamte poweron ag inkl. entwicklung, betrieb und produktmanagement der **porta enterprise ki-plattform** (`api.poweron.swiss`). vollständige fassung: [01_kontext/geltungsbereich-scope.md](01_kontext/geltungsbereich-scope.md). ## 3. aufbau des ims (navigationskarte) | kapitel (iso) | ordner | inhalt | |---|---|---| | 4 kontext | `01_kontext/` | kontext & interessierte parteien, geltungsbereich | | 5 führung | `02_fuehrung/` | qm-politik, is-politik, rollen, organisationsreglement | | 6 planung | `03_planung/` | risikomethodik, risikoregister, soa, ziele/kpi | | 7 unterstützung | `04_unterstuetzung/` | kompetenz/schulung, kommunikation, dokumentenlenkung, register | | 8 betrieb + annex a | `05_betrieb/` | operative prozesse & sicherheits-controls | | 9 bewertung | `06_bewertung/` | internes audit, management-review, monitoring | | 10 verbesserung | `07_verbesserung/` | korrekturmassnahmen/kvp, massnahmenregister | | mappings | `mappings/` | soa/annex-a-, iso-9001-klausel-, cacc-crosswalk | | cockpit | `cockpit/` | html-management-cockpit (generator + generierte datei) | ## 4. dokumentenpyramide 1. **ebene 1 -- politiken / handbuch:** dieses handbuch, qm-politik, is-politik, geltungsbereich, ziele. 2. **ebene 2 -- verfahren / prozesse:** risiko, change, incident, internes audit, management-review, kvp. 3. **ebene 3 -- arbeitsanweisungen / runbooks:** bcm-runbook, datenbank-handling, deployment. 4. **ebene 4 -- records / nachweise:** risikoregister, audit-berichte, schulungsnachweise, logs, massnahmenregister. ## 5. verantwortung der obersten leitung die geschäftsführung verpflichtet sich zum aufbau, betrieb und zur kontinuierlichen verbesserung des ims, stellt die erforderlichen ressourcen bereit, gibt die politiken frei und führt das management-review durch (details: [führung](02_fuehrung/), [management-review](06_bewertung/management-review.md)). ## 6. dokumentenlenkung alle gelenkten dokumente tragen einen einheitlichen metadaten-header und werden über git/forgejo versioniert und per pull-request-review freigegeben. verfahren: [04_unterstützung/dokumentenlenkung.md](04_unterstuetzung/dokumentenlenkung.md). zentrale übersicht: [04_unterstützung/dokumentenregister.md](04_unterstuetzung/dokumentenregister.md). ## 7. status des ims aufbauphase (fast-track). ziel: ein gelebtes, audit-reifes ims; auswahl der zertifizierungsstelle ist bewusst nachgelagert. offene punkte werden im [massnahmenregister](07_verbesserung/massnahmen-register.md) geführt. ", "nextReview": "2027-06-03", "overdueReview": false, "zuPruefen": []}, {"id": "01_kontext/geltungsbereich-scope.md", "path": "01_kontext/geltungsbereich-scope.md", "chapter": "01_kontext", "title": "Geltungsbereich (Scope) des IMS", "filename": "geltungsbereich-scope.md", "meta": {"docId": "IMS-04-02", "status": "entwurf", "version": "0.1", "owner": "Patrick Motsch", "approver": "Geschäftsführung PowerOn AG", "approvedDate": "", "nextReview": "2027-06-03", "classification": "intern", "isoRefs": "9001:4.3-4.4; 27001:4.3"}, "html": "<h1>Geltungsbereich (Scope) des IMS<\/h1>\n<p><strong>Dokumenttyp:<\/strong> Grundlagendokument (Pflichtdokument ISO 9001 4.3 / ISO 27001 4.3)<\/p>\n<h2>1. Scope-Statement<\/h2>\n<blockquote>Das integrierte Managementsystem der PowerOn AG umfasst die <strong>Entwicklung, den Betrieb, das Produktmanagement und den Support der PORTA Enterprise KI-Plattform<\/strong> (Multi-Tenant-SaaS, <code>api.poweron.swiss<\/code>) sowie die zugehörigen unterstützenden Prozesse der gesamten PowerOn AG.  Es deckt <strong>ISO 9001:2015<\/strong> (Qualitätsmanagement) und <strong>ISO/IEC 27001:2022<\/strong> (Informationssicherheit) ab.<\/blockquote>\n<h2>2. Eingeschlossen<\/h2>\n<ul><li>Software-Entwicklung (SDLC), Release- und Change-Management.<\/li><li>Betrieb der Plattform auf Infomaniak Public Cloud (Schweiz): <code>api.poweron.swiss<\/code>, <code>db.poweron.swiss<\/code>.<\/li><li>Entwicklungs-/Deployment-System (Forgejo, CI/CD).<\/li><li>Produktmanagement, Anforderungsmanagement, Kundensupport.<\/li><li>Verwaltung von Drittdiensten/Subunternehmern (inkl. externe LLM-Provider).<\/li><li>Unterstützungsprozesse: Personal/Kompetenz, Beschaffung, IT-Sicherheit, Dokumentenlenkung.<\/li><\/ul>\n<h2>3. Standorte und Mittel<\/h2>\n<ul><li>Cloud-Infrastruktur: Infomaniak (Schweiz).<\/li><li>Verteiltes Klein-Team; Arbeitsmittel und Remote-Zugriff gemäss <a href=\"../05_betrieb/02_Zugriffsmanagement_IAM_PAM.md\">Zugriffsmanagement<\/a>.<\/li><\/ul>\n<h2>4. Schnittstellen und Abhängigkeiten<\/h2>\n<ul><li>Externe LLM-Provider (Primär OpenAI/USA) -- Inhaltsdaten verlassen zur KI-Verarbeitung die Schweiz; abgesichert über AVV/DPA + EU-SCC und Neutralisierung. Siehe <a href=\"../05_betrieb/20260528_drittanbieter-inventar.md\">Drittanbieter-Inventar<\/a>.<\/li><li>Authentifizierungs-Dienste (Microsoft Entra, Google), E-Mail-Dienste.<\/li><\/ul>\n<h2>5. Ausschlüsse / Nichtanwendbarkeit<\/h2>\n<ul><li>ISO 9001 Kap. 8.3 (Entwicklung) ist <strong>anwendbar<\/strong> (PowerOn entwickelt eigenes Produkt) -- kein Ausschluss.<\/li><li>Annex-A-Controls von ISO 27001 werden nicht pauschal ausgeschlossen; Nichtanwendbarkeit wird einzeln im <a href=\"../03_planung/statement-of-applicability-soa.md\">SoA<\/a> begründet (z. B. rein physische Rechenzentrums-Controls, die beim Cloud-Provider liegen).<\/li><\/ul>\n<h2>6. Begründung kompensierender Massnahmen<\/h2>\n<p>Aufgrund der kleinen Teamgrösse ist eine vollständige Funktionstrennung nicht überall möglich. Wo Controls eine grössere Organisation voraussetzen, greifen kompensierende Massnahmen (Vier-Augen-Prinzip bei Releases, Protokollierung privilegierter Zugriffe, externe Vergabe des internen Audits). Diese sind in den jeweiligen Betriebsdokumenten und im SoA dokumentiert.<\/p>", "text": "<!-- docid: ims-04-02 --> <!-- status: entwurf --> <!-- version: 0.1 --> <!-- owner: patrick motsch --> <!-- approver: geschäftsführung poweron ag --> <!-- approveddate: --> <!-- nextreview: 2027-06-03 --> <!-- classification: intern --> <!-- isorefs: 9001:4.3-4.4; 27001:4.3 --> # geltungsbereich (scope) des ims **dokumenttyp:** grundlagendokument (pflichtdokument iso 9001 4.3 / iso 27001 4.3) ## 1. scope-statement > das integrierte managementsystem der poweron ag umfasst die **entwicklung, den betrieb, das produktmanagement und den support der porta enterprise ki-plattform** (multi-tenant-saas, `api.poweron.swiss`) sowie die zugehörigen unterstützenden prozesse der gesamten poweron ag. > > es deckt **iso 9001:2015** (qualitätsmanagement) und **iso/iec 27001:2022** (informationssicherheit) ab. ## 2. eingeschlossen - software-entwicklung (sdlc), release- und change-management. - betrieb der plattform auf infomaniak public cloud (schweiz): `api.poweron.swiss`, `db.poweron.swiss`. - entwicklungs-/deployment-system (forgejo, ci/cd). - produktmanagement, anforderungsmanagement, kundensupport. - verwaltung von drittdiensten/subunternehmern (inkl. externe llm-provider). - unterstützungsprozesse: personal/kompetenz, beschaffung, it-sicherheit, dokumentenlenkung. ## 3. standorte und mittel - cloud-infrastruktur: infomaniak (schweiz). - verteiltes klein-team; arbeitsmittel und remote-zugriff gemäss [zugriffsmanagement](../05_betrieb/02_zugriffsmanagement_iam_pam.md). ## 4. schnittstellen und abhängigkeiten - externe llm-provider (primär openai/usa) -- inhaltsdaten verlassen zur ki-verarbeitung die schweiz; abgesichert über avv/dpa + eu-scc und neutralisierung. siehe [drittanbieter-inventar](../05_betrieb/20260528_drittanbieter-inventar.md). - authentifizierungs-dienste (microsoft entra, google), e-mail-dienste. ## 5. ausschlüsse / nichtanwendbarkeit - iso 9001 kap. 8.3 (entwicklung) ist **anwendbar** (poweron entwickelt eigenes produkt) -- kein ausschluss. - annex-a-controls von iso 27001 werden nicht pauschal ausgeschlossen; nichtanwendbarkeit wird einzeln im [soa](../03_planung/statement-of-applicability-soa.md) begründet (z. b. rein physische rechenzentrums-controls, die beim cloud-provider liegen). ## 6. begründung kompensierender massnahmen aufgrund der kleinen teamgrösse ist eine vollständige funktionstrennung nicht überall möglich. wo controls eine grössere organisation voraussetzen, greifen kompensierende massnahmen (vier-augen-prinzip bei releases, protokollierung privilegierter zugriffe, externe vergabe des internen audits). diese sind in den jeweiligen betriebsdokumenten und im soa dokumentiert. ", "nextReview": "2027-06-03", "overdueReview": false, "zuPruefen": []}, {"id": "01_kontext/kontext-und-interessierte-parteien.md", "path": "01_kontext/kontext-und-interessierte-parteien.md", "chapter": "01_kontext", "title": "Kontext der Organisation & interessierte Parteien", "filename": "kontext-und-interessierte-parteien.md", "meta": {"docId": "IMS-04-01", "status": "entwurf", "version": "0.1", "owner": "Patrick Motsch", "approver": "Geschäftsführung PowerOn AG", "approvedDate": "", "nextReview": "2027-06-03", "classification": "intern", "isoRefs": "9001:4.1-4.2; 27001:4.1-4.2"}, "html": "<h1>Kontext der Organisation &amp; interessierte Parteien<\/h1>\n<p><strong>Dokumenttyp:<\/strong> Grundlagendokument ISO 9001 / 27001 Kap. 4.1-4.2: Bestimmung des organisatorischen Kontexts und der relevanten interessierten Parteien samt deren Anforderungen.<\/p>\n<h2>1. Organisation<\/h2>\n<p>PowerOn AG ist ein Schweizer Software-Unternehmen und betreibt die <strong>PORTA Enterprise KI-Plattform<\/strong> -- eine Multi-Tenant-SaaS-Lösung mit Feature-Store-Modell, AI-Agent-Workspace und mandantenweiter Datenneutralisierung. Zielkunden sind mittlere bis grosse Unternehmen in datenschutzsensiblen Branchen (Finanzwesen, Treuhand, Immobilien, Beratung). Sehr kleines Team (2-5 Personen).<\/p>\n<h2>2. Externe Themen (Kontext)<\/h2>\n<ul><li>Regulatorik: CH nDSG/revDSG, EU-DSGVO, für Bankkunden FINMA-Rundschreiben 2018/3 &amp; 2023/1, GLKB Cloud Assessment (CACC).<\/li><li>Markt: hohe Erwartung an Datensouveränität (CH-Hosting), KI-Transparenz, Nachweisbarkeit (ISO 27001/9001 als Einkaufskriterium).<\/li><li>Technologie: Abhängigkeit von externen LLM-Providern (OpenAI USA u. a.), Cloud-Hosting Infomaniak (CH).<\/li><li>Bedrohungslage: Web-/Cloud-Angriffe, Lieferkettenrisiken, KI-spezifische Risiken (Prompt-Injection, Datenabfluss).<\/li><\/ul>\n<h2>3. Interne Themen (Kontext)<\/h2>\n<ul><li>Kleines Team -&gt; Rollenbuendelung, eingeschränkte Funktionstrennung (kompensierende Massnahmen).<\/li><li>Hoher Automatisierungsgrad (Forgejo CI/CD, Infrastruktur, Wiki-basierte Doku).<\/li><li>Wissenskonzentration auf wenige Personen (Schlüsselpersonenrisiko).<\/li><\/ul>\n<h2>4. Interessierte Parteien und Anforderungen<\/h2>\n<table><thead><tr><th>Interessierte Partei<\/th><th>Wesentliche Anforderungen<\/th><\/tr><\/thead><tbody><tr><td>Kunden (inkl. Banken/Treuhänder)<\/td><td>Datenschutz, Vertraulichkeit, Verfügbarkeit (SLA), Nachweise/Zertifikate, Auditierbarkeit<\/td><\/tr><tr><td>Endnutzer<\/td><td>Funktionierende, sichere, performante Plattform; Datenschutzrechte<\/td><\/tr><tr><td>Geschäftsführung/Eigner<\/td><td>Wirtschaftlichkeit, Reputation, Compliance, beherrschbares Risiko<\/td><\/tr><tr><td>Mitarbeitende<\/td><td>Klare Prozesse, sichere Arbeitsmittel, Kompetenzentwicklung<\/td><\/tr><tr><td>Aufsicht/Regulatoren<\/td><td>Einhaltung Datenschutz- und Finanzmarktvorgaben<\/td><\/tr><tr><td>Lieferanten/Subunternehmer<\/td><td>Klare Verträge, AVVs, Sicherheitsanforderungen<\/td><\/tr><tr><td>Zertifizierungsstelle<\/td><td>Normkonformes, gelebtes, nachweisbares Managementsystem<\/td><\/tr><\/tbody><\/table>\n<h2>5. Geltungsbereich des IMS<\/h2>\n<p>Festlegung in <a href=\"geltungsbereich-scope.md\">geltungsbereich-scope.md<\/a>.<\/p>\n<h2>6. Wesentliche Prozesse (Prozesslandkarte)<\/h2>\n<pre class=\"mermaid\">flowchart LR\n    subgraph fuehrung [Führungsprozesse]\n        F1[\"Strategie &amp; Management-Review\"]\n        F2[\"Risiko- &amp; Compliance-Management\"]\n    end\n    subgraph kern [Kernprozesse]\n        K1[\"Produktmanagement &amp; Anforderungen\"]\n        K2[\"Software-Entwicklung (SDLC)\"]\n        K3[\"Release &amp; Change Management\"]\n        K4[\"Betrieb &amp; Support der PORTA-Plattform\"]\n    end\n    subgraph support [Unterstützungsprozesse]\n        S1[\"Beschaffung &amp; Lieferanten\"]\n        S2[\"Personal &amp; Kompetenz\"]\n        S3[\"IT-Sicherheit &amp; Infrastruktur\"]\n        S4[\"Dokumentenlenkung\"]\n    end\n    F1 --&gt; K1 --&gt; K2 --&gt; K3 --&gt; K4\n    F2 --&gt; K2\n    support --&gt; kern<\/pre>", "text": "<!-- docid: ims-04-01 --> <!-- status: entwurf --> <!-- version: 0.1 --> <!-- owner: patrick motsch --> <!-- approver: geschäftsführung poweron ag --> <!-- approveddate: --> <!-- nextreview: 2027-06-03 --> <!-- classification: intern --> <!-- isorefs: 9001:4.1-4.2; 27001:4.1-4.2 --> # kontext der organisation & interessierte parteien **dokumenttyp:** grundlagendokument iso 9001 / 27001 kap. 4.1-4.2: bestimmung des organisatorischen kontexts und der relevanten interessierten parteien samt deren anforderungen. ## 1. organisation poweron ag ist ein schweizer software-unternehmen und betreibt die **porta enterprise ki-plattform** -- eine multi-tenant-saas-lösung mit feature-store-modell, ai-agent-workspace und mandantenweiter datenneutralisierung. zielkunden sind mittlere bis grosse unternehmen in datenschutzsensiblen branchen (finanzwesen, treuhand, immobilien, beratung). sehr kleines team (2-5 personen). ## 2. externe themen (kontext) - regulatorik: ch ndsg/revdsg, eu-dsgvo, für bankkunden finma-rundschreiben 2018/3 & 2023/1, glkb cloud assessment (cacc). - markt: hohe erwartung an datensouveränität (ch-hosting), ki-transparenz, nachweisbarkeit (iso 27001/9001 als einkaufskriterium). - technologie: abhängigkeit von externen llm-providern (openai usa u. a.), cloud-hosting infomaniak (ch). - bedrohungslage: web-/cloud-angriffe, lieferkettenrisiken, ki-spezifische risiken (prompt-injection, datenabfluss). ## 3. interne themen (kontext) - kleines team -> rollenbuendelung, eingeschränkte funktionstrennung (kompensierende massnahmen). - hoher automatisierungsgrad (forgejo ci/cd, infrastruktur, wiki-basierte doku). - wissenskonzentration auf wenige personen (schlüsselpersonenrisiko). ## 4. interessierte parteien und anforderungen | interessierte partei | wesentliche anforderungen | |---|---| | kunden (inkl. banken/treuhänder) | datenschutz, vertraulichkeit, verfügbarkeit (sla), nachweise/zertifikate, auditierbarkeit | | endnutzer | funktionierende, sichere, performante plattform; datenschutzrechte | | geschäftsführung/eigner | wirtschaftlichkeit, reputation, compliance, beherrschbares risiko | | mitarbeitende | klare prozesse, sichere arbeitsmittel, kompetenzentwicklung | | aufsicht/regulatoren | einhaltung datenschutz- und finanzmarktvorgaben | | lieferanten/subunternehmer | klare verträge, avvs, sicherheitsanforderungen | | zertifizierungsstelle | normkonformes, gelebtes, nachweisbares managementsystem | ## 5. geltungsbereich des ims festlegung in [geltungsbereich-scope.md](geltungsbereich-scope.md). ## 6. wesentliche prozesse (prozesslandkarte) ```mermaid flowchart lr subgraph fuehrung [führungsprozesse] f1[\"strategie & management-review\"] f2[\"risiko- & compliance-management\"] end subgraph kern [kernprozesse] k1[\"produktmanagement & anforderungen\"] k2[\"software-entwicklung (sdlc)\"] k3[\"release & change management\"] k4[\"betrieb & support der porta-plattform\"] end subgraph support [unterstützungsprozesse] s1[\"beschaffung & lieferanten\"] s2[\"personal & kompetenz\"] s3[\"it-sicherheit & infrastruktur\"] s4[\"dokumentenlenkung\"] end f1 --> k1 --> k2 --> k3 --> k4 f2 --> k2 support --> kern ``` ", "nextReview": "2027-06-03", "overdueReview": false, "zuPruefen": []}, {"id": "02_fuehrung/informationssicherheitspolitik.md", "path": "02_fuehrung/informationssicherheitspolitik.md", "chapter": "02_fuehrung", "title": "Informationssicherheitsrichtlinie (ISMS-Dachdokument)", "filename": "informationssicherheitspolitik.md", "meta": {"docId": "IMS-05-02", "status": "entwurf", "version": "1.0", "owner": "Patrick Motsch", "approver": "Geschäftsführung PowerOn AG", "approvedDate": "", "nextReview": "2027-06-03", "classification": "intern", "isoRefs": "27001:5.2,5.1; 9001:5.2"}, "html": "<h1>Informationssicherheitsrichtlinie (ISMS-Dachdokument)<\/h1>\n<p><strong>Dokumenttyp:<\/strong> Richtlinie <strong>Geltungsbereich:<\/strong> PORTA Enterprise KI-Plattform, gesamte PowerOn AG <strong>Version:<\/strong> 1.0 <strong>Status:<\/strong> Entwurf zur internen Freigabe <strong>Owner:<\/strong> Geschäftsführung PowerOn AG <strong>Letzte Aktualisierung:<\/strong> 02.06.2026 <strong>Deckt ab (CACC):<\/strong> 49, 52, 56<\/p>\n<hr>\n<h2>1. Zweck und Geltungsbereich<\/h2>\n<p>Diese Richtlinie definiert die grundlegenden Vorgaben, Prinzipien und Verantwortlichkeiten für die Informationssicherheit bei PowerOn. Sie ist das Dachdokument des Informationssicherheits-Managementsystems (ISMS) und verweist auf die detaillierten Einzelprozesse.<\/p>\n<p>Der Geltungsbereich umfasst alle Systeme, Daten, Mitarbeitenden und Dienstleister, die an der Bereitstellung der PORTA-Plattform beteiligt sind — insbesondere die Infrastruktur bei Infomaniak (<code>api.poweron.swiss<\/code>, <code>db.poweron.swiss<\/code>), das Forgejo-basierte Entwicklungs- und Deployment-System sowie alle im Drittanbieter-Inventar gelisteten externen Dienste.<\/p>\n<h2>2. Sicherheitsziele<\/h2>\n<p>PowerOn verfolgt die klassischen Schutzziele der Informationssicherheit:<\/p>\n<ul><li><strong>Vertraulichkeit:<\/strong> Kundendaten (Inhaltsdaten, insbesondere Berufsgeheimnisdaten) sind nur autorisierten Personen und Prozessen zugänglich.<\/li><li><strong>Integrität:<\/strong> Daten und Systeme sind vor unbefugter oder unbeabsichtigter Veränderung geschützt.<\/li><li><strong>Verfügbarkeit:<\/strong> Die Plattform und die Kundendaten stehen im Rahmen der vereinbarten Service Levels zur Verfügung.<\/li><li><strong>Nachvollziehbarkeit:<\/strong> Zugriffe und Änderungen an kritischen Systemen sind protokolliert und auditierbar.<\/li><\/ul>\n<h2>3. Organisation und Verantwortlichkeiten<\/h2>\n<p>Aufgrund der kleinen Teamgrösse (2–5 Personen) werden Rollen gebündelt. Eine vollständige Funktionstrennung ist nicht in allen Bereichen möglich; wo sie fehlt, greifen kompensierende Massnahmen (Vier-Augen-Prinzip bei Releases, Protokollierung privilegierter Zugriffe).<\/p>\n<table><thead><tr><th>Rolle<\/th><th>Verantwortung<\/th><th>Träger<\/th><\/tr><\/thead><tbody><tr><td>Informationssicherheits-Verantwortlicher (ISO/CISO-Funktion)<\/td><td>Pflege des ISMS, Risikobeurteilung, Richtlinienfreigabe<\/td><td>Patrick Motsch (p.motsch@poweron.swiss)<\/td><\/tr><tr><td>Datenschutzverantwortlicher<\/td><td>Einhaltung DSG/DSGVO, AVV-Management<\/td><td>Patrick Motsch (p.motsch@poweron.swiss)<\/td><\/tr><tr><td>Drittdienst-Verantwortlicher<\/td><td>Verwaltung externer Dienste, Subunternehmer<\/td><td>Patrick Motsch (p.motsch@poweron.swiss)<\/td><\/tr><tr><td>Betrieb / DevOps<\/td><td>Server, Deployment, Backups, Incident-Handling<\/td><td>Patrick Motsch (p.motsch@poweron.swiss)<\/td><\/tr><tr><td>Geschäftsführung<\/td><td>Gesamtverantwortung, Freigabe Richtlinien<\/td><td>Patrick Motsch (p.motsch@poweron.swiss)<\/td><\/tr><\/tbody><\/table>\n<h2>4. Grundsätze<\/h2>\n<ol><li><strong>Need-to-Know &amp; Least Privilege:<\/strong> Zugriff nur im erforderlichen Umfang (Details: <code>02_Zugriffsmanagement_IAM_PAM.md<\/code>).<\/li><li><strong>Sichere Standardkonfiguration:<\/strong> Systeme werden nach anerkannten Standards gehärtet (Details: <code>12_Netzwerk_und_Infrastruktursicherheit.md<\/code>).<\/li><li><strong>Verschlüsselung:<\/strong> Daten werden bei Übertragung und Speicherung verschlüsselt (Details: <code>04_Verschluesselung_und_Schluesselmanagement.md<\/code>).<\/li><li><strong>Nachvollziehbare Änderungen:<\/strong> Alle Produktivänderungen durchlaufen den Change-Prozess (Details: <code>08_Change_Management.md<\/code>).<\/li><li><strong>Vorfallreaktion:<\/strong> Sicherheitsvorfälle werden klassifiziert, behoben und gemeldet (Details: <code>07_Incident_Response_und_Meldewesen.md<\/code>).<\/li><\/ol>\n<h2>5. Risikomanagement<\/h2>\n<p>PowerOn führt mindestens jährlich sowie anlassbezogen (z. B. bei wesentlichen Architekturänderungen) eine Risikobeurteilung der für Kunden relevanten Systeme durch. Identifizierte Risiken werden bewertet (Eintrittswahrscheinlichkeit × Auswirkung), behandelt (vermeiden / vermindern / übertragen / akzeptieren) und dokumentiert. Ergebnisse werden auf Anfrage berechtigten Kunden und Prüfern offengelegt.<\/p>\n<h2>6. Verbindlichkeit und Schulung<\/h2>\n<p>Diese Richtlinie ist für alle Mitarbeitenden und Hilfspersonen verbindlich. Neue Mitarbeitende werden im Onboarding auf die Richtlinie verpflichtet; eine Auffrischung erfolgt jährlich (siehe <code>03_Mitarbeitersicherheit_und_Screening.md<\/code>).<\/p>\n<h2>7. Überprüfung<\/h2>\n<p>Die Richtlinie wird mindestens jährlich sowie bei wesentlichen Änderungen überprüft und durch die Geschäftsführung freigegeben.<\/p>\n<h2>8. Stand der Umsetzung / Lücken<\/h2>\n<table><thead><tr><th>Thema<\/th><th>Status<\/th><th>Geplante Massnahme<\/th><\/tr><\/thead><tbody><tr><td>ISMS nach ISO/IEC 27001 zertifiziert<\/td><td>Nicht vorhanden<\/td><td>[ZU PRÜFEN: Zertifizierung geplant? Zeithorizont?]<\/td><\/tr><tr><td>Dokumentierte Rollenzuteilung<\/td><td>In Arbeit (dieses Dokument)<\/td><td>Namentliche Zuordnung ergänzen<\/td><\/tr><tr><td>Jährliche Risikobeurteilung<\/td><td>[ZU PRÜFEN]<\/td><td>Erstdurchführung terminieren<\/td><\/tr><\/tbody><\/table>", "text": "<!-- docid: ims-05-02 --> <!-- status: entwurf --> <!-- version: 1.0 --> <!-- owner: patrick motsch --> <!-- approver: geschäftsführung poweron ag --> <!-- approveddate: --> <!-- nextreview: 2027-06-03 --> <!-- classification: intern --> <!-- isorefs: 27001:5.2,5.1; 9001:5.2 --> # informationssicherheitsrichtlinie (isms-dachdokument) **dokumenttyp:** richtlinie **geltungsbereich:** porta enterprise ki-plattform, gesamte poweron ag **version:** 1.0 **status:** entwurf zur internen freigabe **owner:** geschäftsführung poweron ag **letzte aktualisierung:** 02.06.2026 **deckt ab (cacc):** 49, 52, 56 --- ## 1. zweck und geltungsbereich diese richtlinie definiert die grundlegenden vorgaben, prinzipien und verantwortlichkeiten für die informationssicherheit bei poweron. sie ist das dachdokument des informationssicherheits-managementsystems (isms) und verweist auf die detaillierten einzelprozesse. der geltungsbereich umfasst alle systeme, daten, mitarbeitenden und dienstleister, die an der bereitstellung der porta-plattform beteiligt sind — insbesondere die infrastruktur bei infomaniak (`api.poweron.swiss`, `db.poweron.swiss`), das forgejo-basierte entwicklungs- und deployment-system sowie alle im drittanbieter-inventar gelisteten externen dienste. ## 2. sicherheitsziele poweron verfolgt die klassischen schutzziele der informationssicherheit: - **vertraulichkeit:** kundendaten (inhaltsdaten, insbesondere berufsgeheimnisdaten) sind nur autorisierten personen und prozessen zugänglich. - **integrität:** daten und systeme sind vor unbefugter oder unbeabsichtigter veränderung geschützt. - **verfügbarkeit:** die plattform und die kundendaten stehen im rahmen der vereinbarten service levels zur verfügung. - **nachvollziehbarkeit:** zugriffe und änderungen an kritischen systemen sind protokolliert und auditierbar. ## 3. organisation und verantwortlichkeiten aufgrund der kleinen teamgrösse (2–5 personen) werden rollen gebündelt. eine vollständige funktionstrennung ist nicht in allen bereichen möglich; wo sie fehlt, greifen kompensierende massnahmen (vier-augen-prinzip bei releases, protokollierung privilegierter zugriffe). | rolle | verantwortung | träger | |---|---|---| | informationssicherheits-verantwortlicher (iso/ciso-funktion) | pflege des isms, risikobeurteilung, richtlinienfreigabe | patrick motsch (p.motsch@poweron.swiss) | | datenschutzverantwortlicher | einhaltung dsg/dsgvo, avv-management | patrick motsch (p.motsch@poweron.swiss) | | drittdienst-verantwortlicher | verwaltung externer dienste, subunternehmer | patrick motsch (p.motsch@poweron.swiss) | | betrieb / devops | server, deployment, backups, incident-handling | patrick motsch (p.motsch@poweron.swiss) | | geschäftsführung | gesamtverantwortung, freigabe richtlinien | patrick motsch (p.motsch@poweron.swiss) | ## 4. grundsätze 1. **need-to-know & least privilege:** zugriff nur im erforderlichen umfang (details: `02_zugriffsmanagement_iam_pam.md`). 2. **sichere standardkonfiguration:** systeme werden nach anerkannten standards gehärtet (details: `12_netzwerk_und_infrastruktursicherheit.md`). 3. **verschlüsselung:** daten werden bei übertragung und speicherung verschlüsselt (details: `04_verschluesselung_und_schluesselmanagement.md`). 4. **nachvollziehbare änderungen:** alle produktivänderungen durchlaufen den change-prozess (details: `08_change_management.md`). 5. **vorfallreaktion:** sicherheitsvorfälle werden klassifiziert, behoben und gemeldet (details: `07_incident_response_und_meldewesen.md`). ## 5. risikomanagement poweron führt mindestens jährlich sowie anlassbezogen (z. b. bei wesentlichen architekturänderungen) eine risikobeurteilung der für kunden relevanten systeme durch. identifizierte risiken werden bewertet (eintrittswahrscheinlichkeit × auswirkung), behandelt (vermeiden / vermindern / übertragen / akzeptieren) und dokumentiert. ergebnisse werden auf anfrage berechtigten kunden und prüfern offengelegt. ## 6. verbindlichkeit und schulung diese richtlinie ist für alle mitarbeitenden und hilfspersonen verbindlich. neue mitarbeitende werden im onboarding auf die richtlinie verpflichtet; eine auffrischung erfolgt jährlich (siehe `03_mitarbeitersicherheit_und_screening.md`). ## 7. überprüfung die richtlinie wird mindestens jährlich sowie bei wesentlichen änderungen überprüft und durch die geschäftsführung freigegeben. ## 8. stand der umsetzung / lücken | thema | status | geplante massnahme | |---|---|---| | isms nach iso/iec 27001 zertifiziert | nicht vorhanden | [zu prüfen: zertifizierung geplant? zeithorizont?] | | dokumentierte rollenzuteilung | in arbeit (dieses dokument) | namentliche zuordnung ergänzen | | jährliche risikobeurteilung | [zu prüfen] | erstdurchführung terminieren | ", "nextReview": "2027-06-03", "overdueReview": false, "zuPruefen": ["8. Stand der Umsetzung / Lücken", "8. Stand der Umsetzung / Lücken"]}, {"id": "02_fuehrung/organisationsreglement.md", "path": "02_fuehrung/organisationsreglement.md", "chapter": "02_fuehrung", "title": "Organisationsreglement", "filename": "organisationsreglement.md", "meta": {"docId": "IMS-05-04", "status": "entwurf", "version": "0.1", "owner": "Patrick Motsch", "approver": "Geschäftsführung PowerOn AG / Verwaltungsrat", "approvedDate": "", "nextReview": "2027-06-11", "classification": "intern", "isoRefs": "9001:5.1,5.3; 27001:5.1,5.3"}, "html": "<h1>Organisationsreglement<\/h1>\n<p><strong>Dokumenttyp:<\/strong> Grundlagendokument (Führung, operative Organisation) <strong>Quelle:<\/strong> Vorschlag Silvan Winiger (SoHa Treuhand AG), Juni 2026 — zur Bestätigung im Verwaltungsrat (POL).<\/p>\n<p>Regelt die <strong>operative Aufgabenverteilung<\/strong>, <strong>Meetingstruktur<\/strong> und <strong>Kommunikationswege<\/strong> der PowerOn AG. Ergänzt die IMS-Rollen in <a href=\"rollen-verantwortlichkeiten.md\">rollen-verantwortlichkeiten.md<\/a> (ISB, QMB, Audit etc.) um die geschäftliche Führungs- und Koordinationsstruktur.<\/p>\n<h2>1. Zweck<\/h2>\n<ul><li>Entlastung der zentralen Rollenträger (insb. Geschäftsführung und technische Schlüsselpersonen).<\/li><li>Klare Verantwortlichkeiten in Entwicklung, Betrieb, Vertrieb und Verwaltung.<\/li><li>Strukturierte Kommunikation zwischen Operations, Strategie und Verwaltungsrat.<\/li><\/ul>\n<h2>2. Ziele<\/h2>\n<table><thead><tr><th>Ziel<\/th><th>Beschreibung<\/th><\/tr><\/thead><tbody><tr><td>Entlastung Patrick<\/td><td>Fokus auf Roadmap, Personalplanung und operative Entscheidungsprozesse<\/td><\/tr><tr><td>Entlastung Philipp<\/td><td>Fokus auf Strategie, Growth und Investoren/Kapital<\/td><\/tr><tr><td>Entlastung Dominic<\/td><td>Fokus auf Network, Sales und Support Operations<\/td><\/tr><tr><td>Struktur &amp; Kommunikation<\/td><td>Regelmässige, thematisch getrennte Meetings mit klarer Moderation<\/td><\/tr><\/tbody><\/table>\n<h2>3. Aufgabenverteilung (operativ)<\/h2>\n<table><thead><tr><th>Person<\/th><th>Schwerpunkt<\/th><th>Bemerkung<\/th><\/tr><\/thead><tbody><tr><td><strong>Patrick Motsch<\/strong><\/td><td>Roadmap Entwicklung, Personalplanung, Prozess für operative Entscheidungsfindung<\/td><td>Geschäftsführung, IMS-Rollen gebündelt (siehe Rollenmatrix)<\/td><\/tr><tr><td><strong>Dominic<\/strong><\/td><td>Network, Sales, Unterstützung Business Development &amp; Support Operations<\/td><td><\/td><\/tr><tr><td><strong>Philipp<\/strong><\/td><td>Strategie, Support Growth Management, Lead Invest-Themen / Kapitalbeschaffung<\/td><td><\/td><\/tr><tr><td><strong>Silvan Winiger<\/strong><\/td><td>Treuhänderische &amp; buchhalterische Leistungen, Testing, Akquise<\/td><td>Extern (SoHa Treuhand AG)<\/td><\/tr><tr><td><strong>Chris<\/strong><\/td><td>Business Development, organisatorische Führung und Koordination; Bindeglied zwischen Operations, Entwicklung, Akquise und Kundenbetreuung; Auffangbecken für Patrick<\/td><td>Voraussetzung Tätigkeit für PowerOn — siehe Abschnitt 6<\/td><\/tr><tr><td><strong>Stephan<\/strong><\/td><td>Abstimmung zum weiteren Vorgehen, Einsatzfähigkeit<\/td><td>Fokus Entlastung Dominic — Bedarf im POL klären<\/td><\/tr><\/tbody><\/table>\n<h2>4. Meetingstruktur<\/h2>\n<h3>4.1 Operations-Meeting (wöchentlich)<\/h3>\n<table><thead><tr><th>Feld<\/th><th>Inhalt<\/th><\/tr><\/thead><tbody><tr><td>Teilnehmende<\/td><td>Patrick, Dominic, Chris; anfangs ggf. Silvan als Support<\/td><\/tr><tr><td>Inhalte<\/td><td>Daily Business, operative Entscheidungsfindungen, Zahlen<\/td><\/tr><tr><td>Moderation<\/td><td>Chris (Vorschlag)<\/td><\/tr><tr><td>Eskalation<\/td><td>Bei Bedarf kurzes Sync Operations → Verwaltungsrat<\/td><\/tr><\/tbody><\/table>\n<h3>4.2 Verwaltungsrat (POL)<\/h3>\n<table><thead><tr><th>Feld<\/th><th>Aktuell<\/th><th>Ziel<\/th><\/tr><\/thead><tbody><tr><td>Frequenz<\/td><td>wöchentlich<\/td><td>bald zweiwöchentlich, mittelfristig monatlich<\/td><\/tr><tr><td>Teilnehmende<\/td><td>Verwaltungsrat<\/td><\/tr><tr><td>Inhalte<\/td><td>Strategische Entscheidungen, relevante operative Themen, finanzielle Situation<\/td><\/tr><tr><td>Physisch<\/td><td>Quartalsweise Abendessen (Vorschlag)<\/td><\/tr><\/tbody><\/table>\n<p>Details zur IMS-internen Kommunikation: <a href=\"../04_unterstuetzung/kommunikation.md\">kommunikation.md<\/a>.<\/p>\n<h2>5. Beziehung zum IMS<\/h2>\n<table><thead><tr><th>IMS-Bezug<\/th><th>Wirkung<\/th><\/tr><\/thead><tbody><tr><td>R-01 Schlüsselpersonenrisiko<\/td><td>Operative Entlastung und Koordinationsrolle (Chris) als <strong>kompensierende Massnahme<\/strong> — ersetzt keine technische Vertretung<\/td><\/tr><tr><td>Kap. 5.3 Rollen<\/td><td>Operative Rollen hier; IMS-Fachrollen (ISB, QMB, Auditor) in <a href=\"rollen-verantwortlichkeiten.md\">rollen-verantwortlichkeiten.md<\/a><\/td><\/tr><tr><td>Kap. 7.4 Kommunikation<\/td><td>Meetingrhythmus in <a href=\"../04_unterstuetzung/kommunikation.md\">kommunikation.md<\/a> nachgeführt<\/td><\/tr><tr><td>Kap. 9.3 Management-Review<\/td><td>VR/POL dient als strategisches Review-Gremium; formales IMS-Management-Review zusätzlich gemäss <a href=\"../06_bewertung/management-review.md\">management-review.md<\/a><\/td><\/tr><\/tbody><\/table>\n<h2>6. Offene Entscheidungen (POL)<\/h2>\n<p>Folgende Punkte sind <strong>Vorschlag<\/strong> und bedürfen der Bestätigung im nächsten POL:<\/p>\n<table><thead><tr><th>Nr.<\/th><th>Entscheidung<\/th><th>Zieltermin<\/th><\/tr><\/thead><tbody><tr><td>1<\/td><td>Feedback zur Aufgabenzuteilung (Abschnitt 3)<\/td><td>Nächstes POL<\/td><\/tr><tr><td>2<\/td><td>Personalsituation nächste drei Monate<\/td><td>Nächstes POL<\/td><\/tr><tr><td>3<\/td><td>Chris übernimmt Moderation Operations-Meetings (sofern für PO tätig)<\/td><td>Nächstes POL<\/td><\/tr><tr><td>4<\/td><td>Startdatum neue VR-Meetingfrequenz und Übergangsplan<\/td><td>Nächstes POL<\/td><\/tr><\/tbody><\/table>\n<p>Nach POL-Bestätigung: <code>status<\/code> auf <code>freigegeben<\/code> setzen, <code>approvedDate<\/code> und ggf. <code>version<\/code> 1.0.<\/p>\n<h2>7. Inkrafttreten<\/h2>\n<p>Gültig ab Bestätigung durch Verwaltungsrat. Bis dahin als <strong>Arbeitsgrundlage<\/strong> für die vorgeschlagene Meetingstruktur.<\/p>", "text": "<!-- docid: ims-05-04 --> <!-- status: entwurf --> <!-- version: 0.1 --> <!-- owner: patrick motsch --> <!-- approver: geschäftsführung poweron ag / verwaltungsrat --> <!-- approveddate: --> <!-- nextreview: 2027-06-11 --> <!-- classification: intern --> <!-- isorefs: 9001:5.1,5.3; 27001:5.1,5.3 --> # organisationsreglement **dokumenttyp:** grundlagendokument (führung, operative organisation) **quelle:** vorschlag silvan winiger (soha treuhand ag), juni 2026 — zur bestätigung im verwaltungsrat (pol). regelt die **operative aufgabenverteilung**, **meetingstruktur** und **kommunikationswege** der poweron ag. ergänzt die ims-rollen in [rollen-verantwortlichkeiten.md](rollen-verantwortlichkeiten.md) (isb, qmb, audit etc.) um die geschäftliche führungs- und koordinationsstruktur. ## 1. zweck - entlastung der zentralen rollenträger (insb. geschäftsführung und technische schlüsselpersonen). - klare verantwortlichkeiten in entwicklung, betrieb, vertrieb und verwaltung. - strukturierte kommunikation zwischen operations, strategie und verwaltungsrat. ## 2. ziele | ziel | beschreibung | |---|---| | entlastung patrick | fokus auf roadmap, personalplanung und operative entscheidungsprozesse | | entlastung philipp | fokus auf strategie, growth und investoren/kapital | | entlastung dominic | fokus auf network, sales und support operations | | struktur & kommunikation | regelmässige, thematisch getrennte meetings mit klarer moderation | ## 3. aufgabenverteilung (operativ) | person | schwerpunkt | bemerkung | |---|---|---| | **patrick motsch** | roadmap entwicklung, personalplanung, prozess für operative entscheidungsfindung | geschäftsführung, ims-rollen gebündelt (siehe rollenmatrix) | | **dominic** | network, sales, unterstützung business development & support operations | | | **philipp** | strategie, support growth management, lead invest-themen / kapitalbeschaffung | | | **silvan winiger** | treuhänderische & buchhalterische leistungen, testing, akquise | extern (soha treuhand ag) | | **chris** | business development, organisatorische führung und koordination; bindeglied zwischen operations, entwicklung, akquise und kundenbetreuung; auffangbecken für patrick | voraussetzung tätigkeit für poweron — siehe abschnitt 6 | | **stephan** | abstimmung zum weiteren vorgehen, einsatzfähigkeit | fokus entlastung dominic — bedarf im pol klären | ## 4. meetingstruktur ### 4.1 operations-meeting (wöchentlich) | feld | inhalt | |---|---| | teilnehmende | patrick, dominic, chris; anfangs ggf. silvan als support | | inhalte | daily business, operative entscheidungsfindungen, zahlen | | moderation | chris (vorschlag) | | eskalation | bei bedarf kurzes sync operations → verwaltungsrat | ### 4.2 verwaltungsrat (pol) | feld | aktuell | ziel | |---|---|---| | frequenz | wöchentlich | bald zweiwöchentlich, mittelfristig monatlich | | teilnehmende | verwaltungsrat | | inhalte | strategische entscheidungen, relevante operative themen, finanzielle situation | | physisch | quartalsweise abendessen (vorschlag) | details zur ims-internen kommunikation: [kommunikation.md](../04_unterstuetzung/kommunikation.md). ## 5. beziehung zum ims | ims-bezug | wirkung | |---|---| | r-01 schlüsselpersonenrisiko | operative entlastung und koordinationsrolle (chris) als **kompensierende massnahme** — ersetzt keine technische vertretung | | kap. 5.3 rollen | operative rollen hier; ims-fachrollen (isb, qmb, auditor) in [rollen-verantwortlichkeiten.md](rollen-verantwortlichkeiten.md) | | kap. 7.4 kommunikation | meetingrhythmus in [kommunikation.md](../04_unterstuetzung/kommunikation.md) nachgeführt | | kap. 9.3 management-review | vr/pol dient als strategisches review-gremium; formales ims-management-review zusätzlich gemäss [management-review.md](../06_bewertung/management-review.md) | ## 6. offene entscheidungen (pol) folgende punkte sind **vorschlag** und bedürfen der bestätigung im nächsten pol: | nr. | entscheidung | zieltermin | |---|---|---| | 1 | feedback zur aufgabenzuteilung (abschnitt 3) | nächstes pol | | 2 | personalsituation nächste drei monate | nächstes pol | | 3 | chris übernimmt moderation operations-meetings (sofern für po tätig) | nächstes pol | | 4 | startdatum neue vr-meetingfrequenz und übergangsplan | nächstes pol | nach pol-bestätigung: `status` auf `freigegeben` setzen, `approveddate` und ggf. `version` 1.0. ## 7. inkrafttreten gültig ab bestätigung durch verwaltungsrat. bis dahin als **arbeitsgrundlage** für die vorgeschlagene meetingstruktur. ", "nextReview": "2027-06-11", "overdueReview": false, "zuPruefen": []}, {"id": "02_fuehrung/qm-politik.md", "path": "02_fuehrung/qm-politik.md", "chapter": "02_fuehrung", "title": "Qualitätspolitik", "filename": "qm-politik.md", "meta": {"docId": "IMS-05-01", "status": "entwurf", "version": "0.1", "owner": "Patrick Motsch", "approver": "Geschäftsführung PowerOn AG", "approvedDate": "", "nextReview": "2027-06-03", "classification": "öffentlich", "isoRefs": "9001:5.2"}, "html": "<h1>Qualitätspolitik<\/h1>\n<p><strong>Dokumenttyp:<\/strong> Politik (Pflichtdokument ISO 9001 5.2) <strong>Geltungsbereich:<\/strong> Gesamte PowerOn AG<\/p>\n<h2>1. Unser Qualitätsverständnis<\/h2>\n<p>Die PowerOn AG entwickelt und betreibt mit der PORTA-Plattform sichere, zuverlässige und nutzbringende KI-Lösungen für datenschutzsensible Branchen. Qualität bedeutet für uns: zugesagte Funktionalität, Verfügbarkeit und Sicherheit verlässlich zu liefern und kontinuierlich zu verbessern.<\/p>\n<h2>2. Grundsätze<\/h2>\n<ol><li><strong>Kundenorientierung:<\/strong> Wir verstehen Kundenanforderungen und setzen sie nachvollziehbar in Produkt und Service um.<\/li><li><strong>Nachvollziehbare Prozesse:<\/strong> Entwicklung, Release und Support folgen dokumentierten, wiederholbaren Prozessen (siehe <a href=\"../05_betrieb/20260528_feature_release_bugfix.md\">Feature-/Release-/Bug-Prozess<\/a>).<\/li><li><strong>Qualität vor Tempo:<\/strong> Vier-Augen-Prinzip, Staging-Verifikation und Akzeptanzkriterien vor jedem Produktiv-Release.<\/li><li><strong>Datenschutz &amp; Sicherheit als Qualitätsmerkmal:<\/strong> Qualität und Informationssicherheit sind untrennbar (integriertes Managementsystem).<\/li><li><strong>Faktenbasierte Entscheidungen:<\/strong> Wir steuern über Kennzahlen (siehe <a href=\"../03_planung/ziele-und-kennzahlen.md\">Ziele &amp; Kennzahlen<\/a>).<\/li><li><strong>Kontinuierliche Verbesserung:<\/strong> Abweichungen werden als Chance verstanden und über den <a href=\"../07_verbesserung/korrekturmassnahmen-und-kvp.md\">KVP-Prozess<\/a> behandelt.<\/li><\/ol>\n<h2>3. Verpflichtung der Leitung<\/h2>\n<p>Die Geschäftsführung verpflichtet sich zur Erfüllung anwendbarer Anforderungen, zur Bereitstellung der nötigen Ressourcen und zur fortlaufenden Verbesserung des Qualitätsmanagementsystems. Qualitätsziele werden in <a href=\"../03_planung/ziele-und-kennzahlen.md\">Ziele &amp; Kennzahlen<\/a> festgelegt und im <a href=\"../06_bewertung/management-review.md\">Management-Review<\/a> bewertet.<\/p>\n<h2>4. Verbindlichkeit<\/h2>\n<p>Diese Politik ist für alle Mitarbeitenden verbindlich, wird kommuniziert (<a href=\"../04_unterstuetzung/kommunikation.md\">Kommunikation<\/a>) und mindestens jährlich auf Angemessenheit überprüft.<\/p>", "text": "<!-- docid: ims-05-01 --> <!-- status: entwurf --> <!-- version: 0.1 --> <!-- owner: patrick motsch --> <!-- approver: geschäftsführung poweron ag --> <!-- approveddate: --> <!-- nextreview: 2027-06-03 --> <!-- classification: öffentlich --> <!-- isorefs: 9001:5.2 --> # qualitätspolitik **dokumenttyp:** politik (pflichtdokument iso 9001 5.2) **geltungsbereich:** gesamte poweron ag ## 1. unser qualitätsverständnis die poweron ag entwickelt und betreibt mit der porta-plattform sichere, zuverlässige und nutzbringende ki-lösungen für datenschutzsensible branchen. qualität bedeutet für uns: zugesagte funktionalität, verfügbarkeit und sicherheit verlässlich zu liefern und kontinuierlich zu verbessern. ## 2. grundsätze 1. **kundenorientierung:** wir verstehen kundenanforderungen und setzen sie nachvollziehbar in produkt und service um. 2. **nachvollziehbare prozesse:** entwicklung, release und support folgen dokumentierten, wiederholbaren prozessen (siehe [feature-/release-/bug-prozess](../05_betrieb/20260528_feature_release_bugfix.md)). 3. **qualität vor tempo:** vier-augen-prinzip, staging-verifikation und akzeptanzkriterien vor jedem produktiv-release. 4. **datenschutz & sicherheit als qualitätsmerkmal:** qualität und informationssicherheit sind untrennbar (integriertes managementsystem). 5. **faktenbasierte entscheidungen:** wir steuern über kennzahlen (siehe [ziele & kennzahlen](../03_planung/ziele-und-kennzahlen.md)). 6. **kontinuierliche verbesserung:** abweichungen werden als chance verstanden und über den [kvp-prozess](../07_verbesserung/korrekturmassnahmen-und-kvp.md) behandelt. ## 3. verpflichtung der leitung die geschäftsführung verpflichtet sich zur erfüllung anwendbarer anforderungen, zur bereitstellung der nötigen ressourcen und zur fortlaufenden verbesserung des qualitätsmanagementsystems. qualitätsziele werden in [ziele & kennzahlen](../03_planung/ziele-und-kennzahlen.md) festgelegt und im [management-review](../06_bewertung/management-review.md) bewertet. ## 4. verbindlichkeit diese politik ist für alle mitarbeitenden verbindlich, wird kommuniziert ([kommunikation](../04_unterstuetzung/kommunikation.md)) und mindestens jährlich auf angemessenheit überprüft. ", "nextReview": "2027-06-03", "overdueReview": false, "zuPruefen": []}, {"id": "02_fuehrung/rollen-verantwortlichkeiten.md", "path": "02_fuehrung/rollen-verantwortlichkeiten.md", "chapter": "02_fuehrung", "title": "Rollen, Verantwortlichkeiten und Befugnisse", "filename": "rollen-verantwortlichkeiten.md", "meta": {"docId": "IMS-05-03", "status": "entwurf", "version": "0.1", "owner": "Patrick Motsch", "approver": "Geschäftsführung PowerOn AG", "approvedDate": "", "nextReview": "2027-06-03", "classification": "intern", "isoRefs": "9001:5.3; 27001:5.3"}, "html": "<h1>Rollen, Verantwortlichkeiten und Befugnisse<\/h1>\n<p><strong>Dokumenttyp:<\/strong> Grundlagendokument (ISO 9001 / 27001 Kap. 5.3)<\/p>\n<p>Aufgrund der kleinen Teamgrösse (2-5 Personen) werden Rollen gebuendelt. Bündelung ist zulässig; entscheidend ist die dokumentierte, namentliche Zuweisung. Wo Funktionstrennung fehlt, greifen kompensierende Massnahmen.<\/p>\n<h2>1. Rollenmatrix<\/h2>\n<table><thead><tr><th>Rolle<\/th><th>Verantwortung / Befugnis<\/th><th>Träger<\/th><\/tr><\/thead><tbody><tr><td>Oberste Leitung (Geschäftsführung)<\/td><td>Gesamtverantwortung IMS, Freigabe Politiken, Ressourcen, Management-Review<\/td><td>Patrick Motsch (p.motsch@poweron.swiss)<\/td><\/tr><tr><td>Informationssicherheits-Beauftragter (ISB / CISO-Funktion)<\/td><td>ISMS-Pflege, Risikobeurteilung, SoA, Steuerung Annex-A-Controls<\/td><td>Patrick Motsch<\/td><\/tr><tr><td>Qualitätsmanagement-Beauftragter (QMB)<\/td><td>QMS-Pflege, Prozesssteuerung, KVP, Audit-Koordination<\/td><td>Patrick Motsch<\/td><\/tr><tr><td>Dokumentenlenkungs-Verantwortlicher<\/td><td>Pflege Header-Standard, Dokumentenregister, Review-Zyklen<\/td><td>Patrick Motsch<\/td><\/tr><tr><td>Datenschutzverantwortlicher<\/td><td>DSG/DSGVO, AVV-Management<\/td><td>Patrick Motsch<\/td><\/tr><tr><td>Betrieb / DevOps &amp; Incident-Verantwortlicher<\/td><td>Server, Deployment, Backups, Vorfallbehandlung<\/td><td>Patrick Motsch<\/td><\/tr><tr><td>Drittdienst-/Lieferanten-Verantwortlicher<\/td><td>Drittanbieter-Inventar, AVVs, Subunternehmer<\/td><td>Patrick Motsch<\/td><\/tr><tr><td>Risiko-Eigner (Risk Owner)<\/td><td>Verantwortung je wesentlichem Risiko/Asset<\/td><td>gemäss <a href=\"../03_planung/risikoregister.md\">Risikoregister<\/a><\/td><\/tr><tr><td>Interner Auditor<\/td><td>Unabhängige Prüfung des IMS<\/td><td><strong>Extern, noch zu benennen<\/strong> (Unabhängigkeit erforderlich)<\/td><\/tr><\/tbody><\/table>\n<h2>2. Hinweis zur Funktionstrennung<\/h2>\n<p>Da derzeit zentrale Rollen bei einer Person liegen, sind folgende kompensierende Massnahmen verbindlich:<\/p>\n<ul><li><strong>Vier-Augen-Prinzip<\/strong> bei Code-Review und Produktiv-Releases (<a href=\"../05_betrieb/20260528_feature_release_bugfix.md\">feature_release_bugfix.md<\/a>).<\/li><li><strong>Protokollierung privilegierter Zugriffe<\/strong> (<a href=\"../05_betrieb/11_Logging_und_Monitoring.md\">Logging &amp; Monitoring<\/a>).<\/li><li><strong>Internes Audit wird extern vergeben<\/strong>, um Unabhängigkeit sicherzustellen (<a href=\"../06_bewertung/internes-audit.md\">Internes Audit<\/a>).<\/li><\/ul>\n<h2>3. Operative Organisation<\/h2>\n<p>Die geschäftliche Aufgabenverteilung, Meetingstruktur (Operations, Verwaltungsrat) und Koordinationsrollen sind im <a href=\"organisationsreglement.md\">Organisationsreglement<\/a> geregelt. Dort adressiert die vorgeschlagene Struktur auch die Entlastung zentraler Personen (kompensierende Massnahme zu R-01).<\/p>\n<h2>4. Pflege<\/h2>\n<p>Änderungen an der Rollenzuweisung werden hier nachgeführt und im Management-Review bestätigt. Operative Anpassungen zusätzlich im Organisationsreglement. Bei Teamwachstum sind Rollen zu entflechten (insb. interner Auditor, Release-Freigabe vs. Entwicklung).<\/p>", "text": "<!-- docid: ims-05-03 --> <!-- status: entwurf --> <!-- version: 0.1 --> <!-- owner: patrick motsch --> <!-- approver: geschäftsführung poweron ag --> <!-- approveddate: --> <!-- nextreview: 2027-06-03 --> <!-- classification: intern --> <!-- isorefs: 9001:5.3; 27001:5.3 --> # rollen, verantwortlichkeiten und befugnisse **dokumenttyp:** grundlagendokument (iso 9001 / 27001 kap. 5.3) aufgrund der kleinen teamgrösse (2-5 personen) werden rollen gebuendelt. bündelung ist zulässig; entscheidend ist die dokumentierte, namentliche zuweisung. wo funktionstrennung fehlt, greifen kompensierende massnahmen. ## 1. rollenmatrix | rolle | verantwortung / befugnis | träger | |---|---|---| | oberste leitung (geschäftsführung) | gesamtverantwortung ims, freigabe politiken, ressourcen, management-review | patrick motsch (p.motsch@poweron.swiss) | | informationssicherheits-beauftragter (isb / ciso-funktion) | isms-pflege, risikobeurteilung, soa, steuerung annex-a-controls | patrick motsch | | qualitätsmanagement-beauftragter (qmb) | qms-pflege, prozesssteuerung, kvp, audit-koordination | patrick motsch | | dokumentenlenkungs-verantwortlicher | pflege header-standard, dokumentenregister, review-zyklen | patrick motsch | | datenschutzverantwortlicher | dsg/dsgvo, avv-management | patrick motsch | | betrieb / devops & incident-verantwortlicher | server, deployment, backups, vorfallbehandlung | patrick motsch | | drittdienst-/lieferanten-verantwortlicher | drittanbieter-inventar, avvs, subunternehmer | patrick motsch | | risiko-eigner (risk owner) | verantwortung je wesentlichem risiko/asset | gemäss [risikoregister](../03_planung/risikoregister.md) | | interner auditor | unabhängige prüfung des ims | **extern, noch zu benennen** (unabhängigkeit erforderlich) | ## 2. hinweis zur funktionstrennung da derzeit zentrale rollen bei einer person liegen, sind folgende kompensierende massnahmen verbindlich: - **vier-augen-prinzip** bei code-review und produktiv-releases ([feature_release_bugfix.md](../05_betrieb/20260528_feature_release_bugfix.md)). - **protokollierung privilegierter zugriffe** ([logging & monitoring](../05_betrieb/11_logging_und_monitoring.md)). - **internes audit wird extern vergeben**, um unabhängigkeit sicherzustellen ([internes audit](../06_bewertung/internes-audit.md)). ## 3. operative organisation die geschäftliche aufgabenverteilung, meetingstruktur (operations, verwaltungsrat) und koordinationsrollen sind im [organisationsreglement](organisationsreglement.md) geregelt. dort adressiert die vorgeschlagene struktur auch die entlastung zentraler personen (kompensierende massnahme zu r-01). ## 4. pflege änderungen an der rollenzuweisung werden hier nachgeführt und im management-review bestätigt. operative anpassungen zusätzlich im organisationsreglement. bei teamwachstum sind rollen zu entflechten (insb. interner auditor, release-freigabe vs. entwicklung). ", "nextReview": "2027-06-03", "overdueReview": false, "zuPruefen": []}, {"id": "03_planung/risikomanagement-methodik.md", "path": "03_planung/risikomanagement-methodik.md", "chapter": "03_planung", "title": "Risikomanagement-Methodik", "filename": "risikomanagement-methodik.md", "meta": {"docId": "IMS-06-01", "status": "entwurf", "version": "0.1", "owner": "Patrick Motsch", "approver": "Geschäftsführung PowerOn AG", "approvedDate": "", "nextReview": "2027-06-03", "classification": "intern", "isoRefs": "27001:6.1.2,6.1.3,8.2,8.3; 9001:6.1"}, "html": "<h1>Risikomanagement-Methodik<\/h1>\n<p><strong>Dokumenttyp:<\/strong> Verfahren (Pflichtdokument ISO 27001 6.1.2) <strong>Geltungsbereich:<\/strong> Informationssicherheits- und Qualitätsrisiken im IMS-Scope<\/p>\n<h2>1. Zweck<\/h2>\n<p>Dieses Verfahren legt fest, wie PowerOn Risiken und Chancen identifiziert, bewertet, behandelt und überwacht -- für ISO 27001 (Informationssicherheitsrisiken) und ISO 9001 (Risiken/Chancen für die Prozess- und Produktqualität).<\/p>\n<h2>2. Vorgehen<\/h2>\n<pre class=\"mermaid\">flowchart LR\n    id[\"1 Identifikation (Assets, Bedrohungen, Schwachstellen, Prozessrisiken)\"] --&gt; an[\"2 Analyse (Eintritt x Auswirkung)\"]\n    an --&gt; ev[\"3 Bewertung gegen Akzeptanzkriterien\"]\n    ev --&gt; tr[\"4 Behandlung (vermeiden/vermindern/übertragen/akzeptieren)\"]\n    tr --&gt; mo[\"5 Überwachung &amp; Review\"]\n    mo --&gt; id<\/pre>\n<h2>3. Bewertungsskala<\/h2>\n<p><strong>Eintrittswahrscheinlichkeit (W)<\/strong> und <strong>Auswirkung (A)<\/strong> je 1-4:<\/p>\n<table><thead><tr><th>Stufe<\/th><th>W (Wahrscheinlichkeit)<\/th><th>A (Auswirkung)<\/th><\/tr><\/thead><tbody><tr><td>1<\/td><td>selten (&lt; 1x/Jahr)<\/td><td>gering (kaum spuerbar)<\/td><\/tr><tr><td>2<\/td><td>möglich<\/td><td>spuerbar (begrenzt, intern)<\/td><\/tr><tr><td>3<\/td><td>wahrscheinlich<\/td><td>erheblich (Kunde/Daten betroffen)<\/td><\/tr><tr><td>4<\/td><td>sehr wahrscheinlich (laufend)<\/td><td>kritisch (Datenverlust, Ausfall, Rechtsbruch)<\/td><\/tr><\/tbody><\/table>\n<p><strong>Risikowert = W x A<\/strong> (1-16).<\/p>\n<table><thead><tr><th>Risikowert<\/th><th>Klasse<\/th><th>Vorgabe<\/th><\/tr><\/thead><tbody><tr><td>1-3<\/td><td>niedrig<\/td><td>akzeptieren, beobachten<\/td><\/tr><tr><td>4-8<\/td><td>mittel<\/td><td>Behandlung planen, terminiert<\/td><\/tr><tr><td>9-12<\/td><td>hoch<\/td><td>Behandlung priorisiert, zeitnah<\/td><\/tr><tr><td>13-16<\/td><td>sehr hoch<\/td><td>sofortige Massnahmen, Leitung informieren<\/td><\/tr><\/tbody><\/table>\n<h2>4. Risikoakzeptanzkriterium<\/h2>\n<p>Risiken der Klasse <strong>niedrig<\/strong> können ohne weitere Massnahme akzeptiert werden. Ab <strong>mittel<\/strong> ist eine dokumentierte Behandlung mit Owner und Termin erforderlich. Restrisiken ab <strong>hoch<\/strong> müssen von der obersten Leitung formal akzeptiert werden.<\/p>\n<h2>5. Behandlungsoptionen und Bezug zum SoA<\/h2>\n<p>Für Informationssicherheitsrisiken werden Massnahmen primär aus den <strong>ISO 27001 Annex-A-Controls<\/strong> abgeleitet; die Anwendbarkeit und Umsetzung wird im <a href=\"statement-of-applicability-soa.md\">Statement of Applicability<\/a> dokumentiert. Umsetzungsmassnahmen und Restrisiken werden im <a href=\"risikoregister.md\">Risikoregister<\/a> geführt; offene Massnahmen laufen ins <a href=\"../07_verbesserung/massnahmen-register.md\">Massnahmenregister<\/a>.<\/p>\n<h2>6. Turnus<\/h2>\n<p>Risikobeurteilung mindestens <strong>jährlich<\/strong> sowie <strong>anlassbezogen<\/strong> (wesentliche Architektur-/Prozessänderung, schwerer Incident, neuer wesentlicher Lieferant). Ergebnisse fliessen ins <a href=\"../06_bewertung/management-review.md\">Management-Review<\/a>.<\/p>", "text": "<!-- docid: ims-06-01 --> <!-- status: entwurf --> <!-- version: 0.1 --> <!-- owner: patrick motsch --> <!-- approver: geschäftsführung poweron ag --> <!-- approveddate: --> <!-- nextreview: 2027-06-03 --> <!-- classification: intern --> <!-- isorefs: 27001:6.1.2,6.1.3,8.2,8.3; 9001:6.1 --> # risikomanagement-methodik **dokumenttyp:** verfahren (pflichtdokument iso 27001 6.1.2) **geltungsbereich:** informationssicherheits- und qualitätsrisiken im ims-scope ## 1. zweck dieses verfahren legt fest, wie poweron risiken und chancen identifiziert, bewertet, behandelt und überwacht -- für iso 27001 (informationssicherheitsrisiken) und iso 9001 (risiken/chancen für die prozess- und produktqualität). ## 2. vorgehen ```mermaid flowchart lr id[\"1 identifikation (assets, bedrohungen, schwachstellen, prozessrisiken)\"] --> an[\"2 analyse (eintritt x auswirkung)\"] an --> ev[\"3 bewertung gegen akzeptanzkriterien\"] ev --> tr[\"4 behandlung (vermeiden/vermindern/übertragen/akzeptieren)\"] tr --> mo[\"5 überwachung & review\"] mo --> id ``` ## 3. bewertungsskala **eintrittswahrscheinlichkeit (w)** und **auswirkung (a)** je 1-4: | stufe | w (wahrscheinlichkeit) | a (auswirkung) | |---|---|---| | 1 | selten (< 1x/jahr) | gering (kaum spuerbar) | | 2 | möglich | spuerbar (begrenzt, intern) | | 3 | wahrscheinlich | erheblich (kunde/daten betroffen) | | 4 | sehr wahrscheinlich (laufend) | kritisch (datenverlust, ausfall, rechtsbruch) | **risikowert = w x a** (1-16). | risikowert | klasse | vorgabe | |---|---|---| | 1-3 | niedrig | akzeptieren, beobachten | | 4-8 | mittel | behandlung planen, terminiert | | 9-12 | hoch | behandlung priorisiert, zeitnah | | 13-16 | sehr hoch | sofortige massnahmen, leitung informieren | ## 4. risikoakzeptanzkriterium risiken der klasse **niedrig** können ohne weitere massnahme akzeptiert werden. ab **mittel** ist eine dokumentierte behandlung mit owner und termin erforderlich. restrisiken ab **hoch** müssen von der obersten leitung formal akzeptiert werden. ## 5. behandlungsoptionen und bezug zum soa für informationssicherheitsrisiken werden massnahmen primär aus den **iso 27001 annex-a-controls** abgeleitet; die anwendbarkeit und umsetzung wird im [statement of applicability](statement-of-applicability-soa.md) dokumentiert. umsetzungsmassnahmen und restrisiken werden im [risikoregister](risikoregister.md) geführt; offene massnahmen laufen ins [massnahmenregister](../07_verbesserung/massnahmen-register.md). ## 6. turnus risikobeurteilung mindestens **jährlich** sowie **anlassbezogen** (wesentliche architektur-/prozessänderung, schwerer incident, neuer wesentlicher lieferant). ergebnisse fliessen ins [management-review](../06_bewertung/management-review.md). ", "nextReview": "2027-06-03", "overdueReview": false, "zuPruefen": []}, {"id": "03_planung/risikoregister.md", "path": "03_planung/risikoregister.md", "chapter": "03_planung", "title": "Risikoregister", "filename": "risikoregister.md", "meta": {"docId": "IMS-06-02", "status": "entwurf", "version": "0.1", "owner": "Patrick Motsch", "approver": "Geschäftsführung PowerOn AG", "approvedDate": "", "nextReview": "2026-12-03", "classification": "vertraulich", "isoRefs": "27001:6.1.2,8.2; 9001:6.1"}, "html": "<h1>Risikoregister<\/h1>\n<p><strong>Dokumenttyp:<\/strong> Record (Ergebnis der Risikobeurteilung) Bewertung gemäss <a href=\"risikomanagement-methodik.md\">Risikomanagement-Methodik<\/a>. W = Wahrscheinlichkeit, A = Auswirkung, R = W x A. Behandlungsmassnahmen mit Owner/Termin laufen ins <a href=\"../07_verbesserung/massnahmen-register.md\">Massnahmenregister<\/a>.<\/p>\n<p><strong>Stand der Erstbeurteilung:<\/strong> 2026-06-03 (Entwurf -- in einer Erst-Risikoworkshop-Sitzung zu validieren).<\/p>\n<table><thead><tr><th>ID<\/th><th>Risiko<\/th><th>Kategorie<\/th><th>W<\/th><th>A<\/th><th>R<\/th><th>Klasse<\/th><th>Behandlung<\/th><th>Owner<\/th><th>Annex-A-Bezug<\/th><\/tr><\/thead><tbody><tr><td>R-01<\/td><td>Schlüsselpersonenrisiko (Wissen/Zugriffe auf eine Person konzentriert)<\/td><td>Organisation<\/td><td>3<\/td><td>4<\/td><td>12<\/td><td>hoch<\/td><td>Vertretung, Dokumentation, Break-Glass; operative Entlastung via <a href=\"../02_fuehrung/organisationsreglement.md\">Organisationsreglement<\/a> (Chris, Rollenverteilung)<\/td><td>Patrick Motsch<\/td><td>A.5.2, A.5.4<\/td><\/tr><tr><td>R-02<\/td><td>Abfluss sensibler Inhaltsdaten an externe LLM-Provider (OpenAI/USA)<\/td><td>Datenschutz<\/td><td>3<\/td><td>4<\/td><td>12<\/td><td>hoch<\/td><td>Neutralisierung, AVV/DPA + EU-SCC, Zero-Retention prüfen<\/td><td>Patrick Motsch<\/td><td>A.5.14, A.8.12<\/td><\/tr><tr><td>R-03<\/td><td>MFA auf Admin-/Server-Zugängen<\/td><td>Zugriff<\/td><td>1<\/td><td>2<\/td><td>2<\/td><td>niedrig<\/td><td>Umgesetzt (Juni 2026); periodische Rezertifizierung halbjährlich<\/td><td>Patrick Motsch<\/td><td>A.5.17, A.8.5<\/td><\/tr><tr><td>R-04<\/td><td>Backup nicht wiederherstellbar (Restore nie getestet)<\/td><td>Verfügbarkeit<\/td><td>2<\/td><td>4<\/td><td>8<\/td><td>mittel<\/td><td>Restore-Test durchführen &amp; protokollieren<\/td><td>Patrick Motsch<\/td><td>A.8.13<\/td><\/tr><tr><td>R-05<\/td><td>Ausfall Schlüssel-Lieferant (Infomaniak / LLM-Provider)<\/td><td>Lieferkette<\/td><td>2<\/td><td>3<\/td><td>6<\/td><td>mittel<\/td><td>BCM/DR-Plan, Exit-Strategie, Provider-Alternativen<\/td><td>Patrick Motsch<\/td><td>A.5.19, A.5.30<\/td><\/tr><tr><td>R-06<\/td><td>Sicherheitsluecke durch verspäteten Patch<\/td><td>Technik<\/td><td>2<\/td><td>3<\/td><td>6<\/td><td>mittel<\/td><td>Patch-/Schwachstellenprozess einhalten<\/td><td>Patrick Motsch<\/td><td>A.8.8<\/td><\/tr><tr><td>R-07<\/td><td>Unzureichende Log-Aufbewahrung/Manipulationsschutz<\/td><td>Nachweis<\/td><td>2<\/td><td>3<\/td><td>6<\/td><td>mittel<\/td><td>Retention &amp; Integritätsschutz festlegen<\/td><td>Patrick Motsch<\/td><td>A.8.15<\/td><\/tr><tr><td>R-08<\/td><td>Fehlerhafte Release führt zu Produktionsstörung<\/td><td>Qualität<\/td><td>2<\/td><td>3<\/td><td>6<\/td><td>mittel<\/td><td>Staging-Verifikation, Vier-Augen, Rollback<\/td><td>Patrick Motsch<\/td><td>A.8.31 (9001:8.5)<\/td><\/tr><tr><td>R-09<\/td><td>Prompt-Injection / Missbrauch KI-Funktionen<\/td><td>KI/Technik<\/td><td>3<\/td><td>2<\/td><td>6<\/td><td>mittel<\/td><td>Eingabebereinigung, Read-only DB-Zugriff, Rate-Limit<\/td><td>Patrick Motsch<\/td><td>A.8.28<\/td><\/tr><\/tbody><\/table>\n<h2>Pflegehinweis<\/h2>\n<p>Neue Risiken fortlaufend ergänzen, R bei Massnahmenwirkung neu bewerten (Restrisiko). Restrisiken der Klasse hoch+ erfordern formale Akzeptanz durch die oberste Leitung (Vermerk in Spalte Behandlung oder im Management-Review-Protokoll).<\/p>", "text": "<!-- docid: ims-06-02 --> <!-- status: entwurf --> <!-- version: 0.1 --> <!-- owner: patrick motsch --> <!-- approver: geschäftsführung poweron ag --> <!-- approveddate: --> <!-- nextreview: 2026-12-03 --> <!-- classification: vertraulich --> <!-- isorefs: 27001:6.1.2,8.2; 9001:6.1 --> # risikoregister **dokumenttyp:** record (ergebnis der risikobeurteilung) bewertung gemäss [risikomanagement-methodik](risikomanagement-methodik.md). w = wahrscheinlichkeit, a = auswirkung, r = w x a. behandlungsmassnahmen mit owner/termin laufen ins [massnahmenregister](../07_verbesserung/massnahmen-register.md). **stand der erstbeurteilung:** 2026-06-03 (entwurf -- in einer erst-risikoworkshop-sitzung zu validieren). | id | risiko | kategorie | w | a | r | klasse | behandlung | owner | annex-a-bezug | |---|---|---|---|---|---|---|---|---|---| | r-01 | schlüsselpersonenrisiko (wissen/zugriffe auf eine person konzentriert) | organisation | 3 | 4 | 12 | hoch | vertretung, dokumentation, break-glass; operative entlastung via [organisationsreglement](../02_fuehrung/organisationsreglement.md) (chris, rollenverteilung) | patrick motsch | a.5.2, a.5.4 | | r-02 | abfluss sensibler inhaltsdaten an externe llm-provider (openai/usa) | datenschutz | 3 | 4 | 12 | hoch | neutralisierung, avv/dpa + eu-scc, zero-retention prüfen | patrick motsch | a.5.14, a.8.12 | | r-03 | mfa auf admin-/server-zugängen | zugriff | 1 | 2 | 2 | niedrig | umgesetzt (juni 2026); periodische rezertifizierung halbjährlich | patrick motsch | a.5.17, a.8.5 | | r-04 | backup nicht wiederherstellbar (restore nie getestet) | verfügbarkeit | 2 | 4 | 8 | mittel | restore-test durchführen & protokollieren | patrick motsch | a.8.13 | | r-05 | ausfall schlüssel-lieferant (infomaniak / llm-provider) | lieferkette | 2 | 3 | 6 | mittel | bcm/dr-plan, exit-strategie, provider-alternativen | patrick motsch | a.5.19, a.5.30 | | r-06 | sicherheitsluecke durch verspäteten patch | technik | 2 | 3 | 6 | mittel | patch-/schwachstellenprozess einhalten | patrick motsch | a.8.8 | | r-07 | unzureichende log-aufbewahrung/manipulationsschutz | nachweis | 2 | 3 | 6 | mittel | retention & integritätsschutz festlegen | patrick motsch | a.8.15 | | r-08 | fehlerhafte release führt zu produktionsstörung | qualität | 2 | 3 | 6 | mittel | staging-verifikation, vier-augen, rollback | patrick motsch | a.8.31 (9001:8.5) | | r-09 | prompt-injection / missbrauch ki-funktionen | ki/technik | 3 | 2 | 6 | mittel | eingabebereinigung, read-only db-zugriff, rate-limit | patrick motsch | a.8.28 | ## pflegehinweis neue risiken fortlaufend ergänzen, r bei massnahmenwirkung neu bewerten (restrisiko). restrisiken der klasse hoch+ erfordern formale akzeptanz durch die oberste leitung (vermerk in spalte behandlung oder im management-review-protokoll). ", "nextReview": "2026-12-03", "overdueReview": false, "zuPruefen": []}, {"id": "03_planung/statement-of-applicability-soa.md", "path": "03_planung/statement-of-applicability-soa.md", "chapter": "03_planung", "title": "Statement of Applicability (SoA) -- ISO/IEC 27001:2022 Annex A", "filename": "statement-of-applicability-soa.md", "meta": {"docId": "IMS-06-03", "status": "entwurf", "version": "0.1", "owner": "Patrick Motsch", "approver": "Geschäftsführung PowerOn AG", "approvedDate": "", "nextReview": "2026-12-03", "classification": "vertraulich", "isoRefs": "27001:6.1.3,AnnexA"}, "html": "<h1>Statement of Applicability (SoA) -- ISO/IEC 27001:2022 Annex A<\/h1>\n<p><strong>Dokumenttyp:<\/strong> Pflichtdokument (ISO 27001 6.1.3 d) <strong>Stand:<\/strong> 2026-06-03 (Entwurf)<\/p>\n<p>Dieses SoA listet alle 93 Annex-A-Controls (2022) mit Anwendbarkeit, Begründung, Umsetzungsstatus und Verweis auf das umsetzende Dokument. Status: <strong>Umgesetzt / Teilweise / Geplant / N/A<\/strong>. Offene/teilweise Punkte sind im <a href=\"../07_verbesserung/massnahmen-register.md\">Massnahmenregister<\/a> geführt.<\/p>\n<p>Legende Anwendbarkeit: <strong>Ja<\/strong> = anwendbar; <strong>N/A<\/strong> = nicht anwendbar (mit Begründung). Cloud-Betrieb bei Infomaniak (CH): bestimmte physische Controls liegen beim Provider (Anwendbar, \"geerbt\").<\/p>\n<h2>A.5 Organisatorische Controls<\/h2>\n<table><thead><tr><th>Control<\/th><th>Titel<\/th><th>Anwend.<\/th><th>Status<\/th><th>Referenz / Begründung<\/th><\/tr><\/thead><tbody><tr><td>A.5.1<\/td><td>Informationssicherheits-Politiken<\/td><td>Ja<\/td><td>Umgesetzt<\/td><td><a href=\"../02_fuehrung/informationssicherheitspolitik.md\">informationssicherheitspolitik.md<\/a><\/td><\/tr><tr><td>A.5.2<\/td><td>Rollen &amp; Verantwortlichkeiten<\/td><td>Ja<\/td><td>Umgesetzt<\/td><td><a href=\"../02_fuehrung/rollen-verantwortlichkeiten.md\">rollen-verantwortlichkeiten.md<\/a><\/td><\/tr><tr><td>A.5.3<\/td><td>Aufgabentrennung<\/td><td>Ja<\/td><td>Teilweise<\/td><td>Klein-Team; kompensierend Vier-Augen-Prinzip, externes Audit<\/td><\/tr><tr><td>A.5.4<\/td><td>Verantwortung der Leitung<\/td><td>Ja<\/td><td>Umgesetzt<\/td><td><a href=\"../00_IMS-Handbuch.md\">00_IMS-Handbuch.md<\/a>, Management-Review<\/td><\/tr><tr><td>A.5.5<\/td><td>Kontakt zu Behörden<\/td><td>Ja<\/td><td>Geplant<\/td><td>Meldewege (EDOEB/FINMA) in <a href=\"../05_betrieb/07_Incident_Response_und_Meldewesen.md\">Incident Response<\/a> festhalten<\/td><\/tr><tr><td>A.5.6<\/td><td>Kontakt zu Interessengruppen<\/td><td>Ja<\/td><td>Teilweise<\/td><td>Security-Quellen/CERT-Feeds; formalisieren<\/td><\/tr><tr><td>A.5.7<\/td><td>Threat Intelligence<\/td><td>Ja<\/td><td>Teilweise<\/td><td><a href=\"../05_betrieb/10_Schwachstellenmanagement.md\">Schwachstellenmanagement<\/a><\/td><\/tr><tr><td>A.5.8<\/td><td>IS im Projektmanagement<\/td><td>Ja<\/td><td>Umgesetzt<\/td><td><a href=\"../05_betrieb/15_Sichere_Softwareentwicklung_SDLC.md\">SDLC<\/a>, Tech-Workshop<\/td><\/tr><tr><td>A.5.9<\/td><td>Inventar der Werte (Assets)<\/td><td>Ja<\/td><td>Teilweise<\/td><td><a href=\"../05_betrieb/20260528_drittanbieter-inventar.md\">Drittanbieter-Inventar<\/a>; Asset-Inventar ergänzen<\/td><\/tr><tr><td>A.5.10<\/td><td>Zulässige Nutzung von Werten<\/td><td>Ja<\/td><td>Geplant<\/td><td>Acceptable-Use in IS-Politik konkretisieren<\/td><\/tr><tr><td>A.5.11<\/td><td>Rückgabe von Werten<\/td><td>Ja<\/td><td>Geplant<\/td><td>Offboarding-Checkliste (<a href=\"../05_betrieb/03_Mitarbeitersicherheit_und_Screening.md\">Mitarbeitersicherheit<\/a>)<\/td><\/tr><tr><td>A.5.12<\/td><td>Klassifizierung von Information<\/td><td>Ja<\/td><td>Teilweise<\/td><td>Klassifizierungsschema (Header <code>classification<\/code>); ausweiten<\/td><\/tr><tr><td>A.5.13<\/td><td>Kennzeichnung von Information<\/td><td>Ja<\/td><td>Teilweise<\/td><td>Header-Klassifizierung; Daten-Labeling ergänzen<\/td><\/tr><tr><td>A.5.14<\/td><td>Informationsübertragung<\/td><td>Ja<\/td><td>Umgesetzt<\/td><td><a href=\"../05_betrieb/04_Verschluesselung_und_Schluesselmanagement.md\">Verschlüsselung<\/a>, TLS, <a href=\"../05_betrieb/neutralisierung-detail.md\">Neutralisierung<\/a><\/td><\/tr><tr><td>A.5.15<\/td><td>Zugangssteuerung<\/td><td>Ja<\/td><td>Umgesetzt<\/td><td><a href=\"../05_betrieb/02_Zugriffsmanagement_IAM_PAM.md\">Zugriffsmanagement<\/a>, RBAC<\/td><\/tr><tr><td>A.5.16<\/td><td>Identitätsmanagement<\/td><td>Ja<\/td><td>Umgesetzt<\/td><td><a href=\"../05_betrieb/02_Zugriffsmanagement_IAM_PAM.md\">Zugriffsmanagement<\/a><\/td><\/tr><tr><td>A.5.17<\/td><td>Authentisierungsinformation<\/td><td>Ja<\/td><td>Umgesetzt<\/td><td><a href=\"../05_betrieb/02_Zugriffsmanagement_IAM_PAM.md\">Zugriffsmanagement<\/a> — MFA Admin/Server (R-03, Juni 2026)<\/td><\/tr><tr><td>A.5.18<\/td><td>Zugangsrechte<\/td><td>Ja<\/td><td>Umgesetzt<\/td><td><a href=\"../05_betrieb/02_Zugriffsmanagement_IAM_PAM.md\">Zugriffsmanagement<\/a><\/td><\/tr><tr><td>A.5.19<\/td><td>IS in Lieferantenbeziehungen<\/td><td>Ja<\/td><td>Umgesetzt<\/td><td><a href=\"../05_betrieb/17_Subunternehmer_Management.md\">Subunternehmer<\/a><\/td><\/tr><tr><td>A.5.20<\/td><td>IS in Lieferantenvereinbarungen<\/td><td>Ja<\/td><td>Teilweise<\/td><td>AVVs vervollständigen (OpenAI Zero-Retention)<\/td><\/tr><tr><td>A.5.21<\/td><td>IS in der IKT-Lieferkette<\/td><td>Ja<\/td><td>Teilweise<\/td><td><a href=\"../05_betrieb/20260528_drittanbieter-inventar.md\">Drittanbieter-Inventar<\/a><\/td><\/tr><tr><td>A.5.22<\/td><td>Überwachung der Lieferantenleistung<\/td><td>Ja<\/td><td>Geplant<\/td><td>Review-Turnus Lieferanten festlegen<\/td><\/tr><tr><td>A.5.23<\/td><td>IS bei Nutzung von Cloud-Diensten<\/td><td>Ja<\/td><td>Umgesetzt<\/td><td>Infomaniak (CH); <a href=\"../05_betrieb/12_Netzwerk_und_Infrastruktursicherheit.md\">Netzwerk/Infra<\/a><\/td><\/tr><tr><td>A.5.24<\/td><td>Incident-Management Planung<\/td><td>Ja<\/td><td>Umgesetzt<\/td><td><a href=\"../05_betrieb/07_Incident_Response_und_Meldewesen.md\">Incident Response<\/a><\/td><\/tr><tr><td>A.5.25<\/td><td>Bewertung von IS-Ereignissen<\/td><td>Ja<\/td><td>Umgesetzt<\/td><td><a href=\"../05_betrieb/07_Incident_Response_und_Meldewesen.md\">Incident Response<\/a><\/td><\/tr><tr><td>A.5.26<\/td><td>Reaktion auf IS-Vorfälle<\/td><td>Ja<\/td><td>Umgesetzt<\/td><td><a href=\"../05_betrieb/07_Incident_Response_und_Meldewesen.md\">Incident Response<\/a><\/td><\/tr><tr><td>A.5.27<\/td><td>Lernen aus Vorfällen<\/td><td>Ja<\/td><td>Teilweise<\/td><td>Post-Incident-Review -&gt; <a href=\"../07_verbesserung/korrekturmassnahmen-und-kvp.md\">KVP<\/a><\/td><\/tr><tr><td>A.5.28<\/td><td>Sammlung von Beweismitteln<\/td><td>Ja<\/td><td>Teilweise<\/td><td>Logs/Forensik in <a href=\"../05_betrieb/11_Logging_und_Monitoring.md\">Logging<\/a><\/td><\/tr><tr><td>A.5.29<\/td><td>IS während Störung<\/td><td>Ja<\/td><td>Umgesetzt<\/td><td><a href=\"../05_betrieb/06_Business_Continuity_und_Disaster_Recovery.md\">BCM/DR<\/a><\/td><\/tr><tr><td>A.5.30<\/td><td>IKT-Bereitschaft für BC<\/td><td>Ja<\/td><td>Umgesetzt<\/td><td><a href=\"../05_betrieb/20260528_bcm_runbook.md\">BCM-Runbook<\/a><\/td><\/tr><tr><td>A.5.31<\/td><td>Gesetzliche &amp; vertragliche Anforderungen<\/td><td>Ja<\/td><td>Umgesetzt<\/td><td><a href=\"../05_betrieb/18_Analyse_Recht_und_BestPractice.md\">Recht/BestPractice<\/a>, AGB<\/td><\/tr><tr><td>A.5.32<\/td><td>Geistiges Eigentum<\/td><td>Ja<\/td><td>Teilweise<\/td><td>Lizenz-/OSS-Compliance dokumentieren<\/td><\/tr><tr><td>A.5.33<\/td><td>Schutz von Aufzeichnungen<\/td><td>Ja<\/td><td>Umgesetzt<\/td><td><a href=\"../05_betrieb/13_Datenaufbewahrung_Loeschung_LegalHold.md\">Datenaufbewahrung<\/a><\/td><\/tr><tr><td>A.5.34<\/td><td>Datenschutz &amp; PII-Schutz<\/td><td>Ja<\/td><td>Umgesetzt<\/td><td><a href=\"../05_betrieb/security-overview.md\">security-overview.md<\/a>, DSGVO-Funktionen<\/td><\/tr><tr><td>A.5.35<\/td><td>Unabhängige IS-Prüfung<\/td><td>Ja<\/td><td>Geplant<\/td><td>Externes <a href=\"../06_bewertung/internes-audit.md\">internes Audit<\/a><\/td><\/tr><tr><td>A.5.36<\/td><td>Konformität mit Politiken<\/td><td>Ja<\/td><td>Teilweise<\/td><td>Audit + Konformitätskontrolle<\/td><\/tr><tr><td>A.5.37<\/td><td>Dokumentierte Betriebsabläufe<\/td><td>Ja<\/td><td>Umgesetzt<\/td><td>Runbooks in <code>05_betrieb/<\/code><\/td><\/tr><\/tbody><\/table>\n<h2>A.6 Personenbezogene Controls<\/h2>\n<table><thead><tr><th>Control<\/th><th>Titel<\/th><th>Anwend.<\/th><th>Status<\/th><th>Referenz / Begründung<\/th><\/tr><\/thead><tbody><tr><td>A.6.1<\/td><td>Sicherheitsüberprüfung (Screening)<\/td><td>Ja<\/td><td>Teilweise<\/td><td><a href=\"../05_betrieb/03_Mitarbeitersicherheit_und_Screening.md\">Mitarbeitersicherheit<\/a>; Hintergrundprüfung klären<\/td><\/tr><tr><td>A.6.2<\/td><td>Arbeitsvertragsbedingungen<\/td><td>Ja<\/td><td>Teilweise<\/td><td>IS-Klauseln in Verträgen ergänzen<\/td><\/tr><tr><td>A.6.3<\/td><td>Awareness, Schulung &amp; Ausbildung<\/td><td>Ja<\/td><td>Geplant<\/td><td><a href=\"../04_unterstuetzung/ressourcen-kompetenz-schulung.md\">Kompetenz/Schulung<\/a><\/td><\/tr><tr><td>A.6.4<\/td><td>Disziplinarverfahren<\/td><td>Ja<\/td><td>Geplant<\/td><td>Verfahren in HR-Doku festhalten<\/td><\/tr><tr><td>A.6.5<\/td><td>Verantwortung nach Beendigung<\/td><td>Ja<\/td><td>Teilweise<\/td><td>Offboarding; NDA-Fortgeltung<\/td><\/tr><tr><td>A.6.6<\/td><td>Vertraulichkeits-/NDA-Vereinbarungen<\/td><td>Ja<\/td><td>Teilweise<\/td><td>NDA-Vorlage sicherstellen<\/td><\/tr><tr><td>A.6.7<\/td><td>Remote-Arbeit<\/td><td>Ja<\/td><td>Umgesetzt<\/td><td><a href=\"../05_betrieb/02_Zugriffsmanagement_IAM_PAM.md\">Zugriffsmanagement<\/a>, VPN/Geräte<\/td><\/tr><tr><td>A.6.8<\/td><td>Meldung von IS-Ereignissen<\/td><td>Ja<\/td><td>Umgesetzt<\/td><td><a href=\"../05_betrieb/07_Incident_Response_und_Meldewesen.md\">Incident Response<\/a><\/td><\/tr><\/tbody><\/table>\n<h2>A.7 Physische Controls<\/h2>\n<p>Eigene Büro-Infrastruktur minimal (Remote-Team); Rechenzentrums-Controls liegen beim Cloud-Provider Infomaniak (CH) und werden über dessen Zertifizierungen (ISO 27001) geerbt.<\/p>\n<table><thead><tr><th>Control<\/th><th>Titel<\/th><th>Anwend.<\/th><th>Status<\/th><th>Referenz / Begründung<\/th><\/tr><\/thead><tbody><tr><td>A.7.1<\/td><td>Physische Sicherheitsperimeter<\/td><td>Ja (geerbt)<\/td><td>Umgesetzt<\/td><td>Infomaniak RZ-Zertifizierung<\/td><\/tr><tr><td>A.7.2<\/td><td>Physischer Zutritt<\/td><td>Ja (geerbt)<\/td><td>Umgesetzt<\/td><td>Infomaniak<\/td><\/tr><tr><td>A.7.3<\/td><td>Sicherung von Büros/Räumen<\/td><td>Ja<\/td><td>Teilweise<\/td><td>Home-/Büro-Grundschutz<\/td><\/tr><tr><td>A.7.4<\/td><td>Physische Überwachung<\/td><td>Ja (geerbt)<\/td><td>Umgesetzt<\/td><td>Infomaniak<\/td><\/tr><tr><td>A.7.5<\/td><td>Schutz vor physischen/umweltbed. Bedrohungen<\/td><td>Ja (geerbt)<\/td><td>Umgesetzt<\/td><td>Infomaniak<\/td><\/tr><tr><td>A.7.6<\/td><td>Arbeiten in Sicherheitsbereichen<\/td><td>N/A<\/td><td>N/A<\/td><td>Keine eigenen Sicherheitsbereiche<\/td><\/tr><tr><td>A.7.7<\/td><td>Clear Desk / Clear Screen<\/td><td>Ja<\/td><td>Geplant<\/td><td>Regel in IS-Politik aufnehmen<\/td><\/tr><tr><td>A.7.8<\/td><td>Platzierung &amp; Schutz von Geräten<\/td><td>Ja<\/td><td>Teilweise<\/td><td>Endgeräte-Richtlinie<\/td><\/tr><tr><td>A.7.9<\/td><td>Schutz von Werten ausserhalb<\/td><td>Ja<\/td><td>Teilweise<\/td><td>Geräteverschlüsselung<\/td><\/tr><tr><td>A.7.10<\/td><td>Speichermedien<\/td><td>Ja<\/td><td>Teilweise<\/td><td>Verschlüsselung, sichere Löschung<\/td><\/tr><tr><td>A.7.11<\/td><td>Versorgungseinrichtungen<\/td><td>Ja (geerbt)<\/td><td>Umgesetzt<\/td><td>Infomaniak<\/td><\/tr><tr><td>A.7.12<\/td><td>Verkabelungssicherheit<\/td><td>Ja (geerbt)<\/td><td>Umgesetzt<\/td><td>Infomaniak<\/td><\/tr><tr><td>A.7.13<\/td><td>Instandhaltung von Geräten<\/td><td>Ja<\/td><td>Teilweise<\/td><td>Patch/Wartung Endgeräte<\/td><\/tr><tr><td>A.7.14<\/td><td>Sichere Entsorgung/Wiederverwendung<\/td><td>Ja<\/td><td>Geplant<\/td><td>Lösch-/Entsorgungsregel<\/td><\/tr><\/tbody><\/table>\n<h2>A.8 Technologische Controls<\/h2>\n<table><thead><tr><th>Control<\/th><th>Titel<\/th><th>Anwend.<\/th><th>Status<\/th><th>Referenz / Begründung<\/th><\/tr><\/thead><tbody><tr><td>A.8.1<\/td><td>Endgeräte der Nutzer<\/td><td>Ja<\/td><td>Teilweise<\/td><td>Endgeräte-Richtlinie, Verschlüsselung<\/td><\/tr><tr><td>A.8.2<\/td><td>Privilegierte Zugangsrechte<\/td><td>Ja<\/td><td>Umgesetzt<\/td><td><a href=\"../05_betrieb/02_Zugriffsmanagement_IAM_PAM.md\">Zugriffsmanagement<\/a><\/td><\/tr><tr><td>A.8.3<\/td><td>Informationszugriffsbeschränkung<\/td><td>Ja<\/td><td>Umgesetzt<\/td><td>RBAC, Mandantentrennung<\/td><\/tr><tr><td>A.8.4<\/td><td>Zugriff auf Quellcode<\/td><td>Ja<\/td><td>Umgesetzt<\/td><td>Forgejo-RBAC<\/td><\/tr><tr><td>A.8.5<\/td><td>Sichere Authentisierung<\/td><td>Ja<\/td><td>Umgesetzt<\/td><td><a href=\"../05_betrieb/02_Zugriffsmanagement_IAM_PAM.md\">Zugriffsmanagement<\/a> — MFA Admin/Server (R-03, Juni 2026)<\/td><\/tr><tr><td>A.8.6<\/td><td>Kapazitätsmanagement<\/td><td>Ja<\/td><td>Umgesetzt<\/td><td><a href=\"../05_betrieb/16_Kapazitaetsmanagement.md\">Kapazitätsmanagement<\/a><\/td><\/tr><tr><td>A.8.7<\/td><td>Schutz vor Schadsoftware<\/td><td>Ja<\/td><td>Teilweise<\/td><td>Endpoint-Schutz, Dependency-Scans<\/td><\/tr><tr><td>A.8.8<\/td><td>Management techn. Schwachstellen<\/td><td>Ja<\/td><td>Umgesetzt<\/td><td><a href=\"../05_betrieb/10_Schwachstellenmanagement.md\">Schwachstellen<\/a>, <a href=\"../05_betrieb/09_Patch_Management.md\">Patch<\/a><\/td><\/tr><tr><td>A.8.9<\/td><td>Konfigurationsmanagement<\/td><td>Ja<\/td><td>Teilweise<\/td><td>.env-Trennung; IaC/Konformität ausbauen<\/td><\/tr><tr><td>A.8.10<\/td><td>Löschung von Information<\/td><td>Ja<\/td><td>Umgesetzt<\/td><td><a href=\"../05_betrieb/13_Datenaufbewahrung_Loeschung_LegalHold.md\">Datenaufbewahrung<\/a>, DSGVO-Löschung<\/td><\/tr><tr><td>A.8.11<\/td><td>Datenmaskierung<\/td><td>Ja<\/td><td>Umgesetzt<\/td><td><a href=\"../05_betrieb/neutralisierung-detail.md\">Neutralisierung<\/a><\/td><\/tr><tr><td>A.8.12<\/td><td>Verhinderung von Datenabfluss<\/td><td>Ja<\/td><td>Teilweise<\/td><td>Neutralisierung, Read-only DB-Zugriff KI<\/td><\/tr><tr><td>A.8.13<\/td><td>Sicherung (Backup)<\/td><td>Ja<\/td><td>Teilweise<\/td><td><a href=\"../05_betrieb/05_Backup_und_Wiederherstellung.md\">Backup<\/a>; Restore-Test offen (R-04)<\/td><\/tr><tr><td>A.8.14<\/td><td>Redundanz von Verarbeitungseinrichtungen<\/td><td>Ja<\/td><td>Teilweise<\/td><td>Provider-Redundanz; dokumentieren<\/td><\/tr><tr><td>A.8.15<\/td><td>Protokollierung (Logging)<\/td><td>Ja<\/td><td>Umgesetzt<\/td><td><a href=\"../05_betrieb/11_Logging_und_Monitoring.md\">Logging &amp; Monitoring<\/a><\/td><\/tr><tr><td>A.8.16<\/td><td>Überwachung von Aktivitäten<\/td><td>Ja<\/td><td>Teilweise<\/td><td>Monitoring ausbauen<\/td><\/tr><tr><td>A.8.17<\/td><td>Uhrzeitsynchronisation<\/td><td>Ja<\/td><td>Umgesetzt<\/td><td>NTP (Infra)<\/td><\/tr><tr><td>A.8.18<\/td><td>Nutzung privilegierter Hilfsprogramme<\/td><td>Ja<\/td><td>Teilweise<\/td><td>Einschränkung/Protokollierung<\/td><\/tr><tr><td>A.8.19<\/td><td>Software-Installation auf Betriebssystemen<\/td><td>Ja<\/td><td>Teilweise<\/td><td>Deployment über CI/CD<\/td><\/tr><tr><td>A.8.20<\/td><td>Netzwerksicherheit<\/td><td>Ja<\/td><td>Umgesetzt<\/td><td><a href=\"../05_betrieb/12_Netzwerk_und_Infrastruktursicherheit.md\">Netzwerk/Infra<\/a><\/td><\/tr><tr><td>A.8.21<\/td><td>Sicherheit von Netzwerkdiensten<\/td><td>Ja<\/td><td>Umgesetzt<\/td><td>TLS, Reverse Proxy<\/td><\/tr><tr><td>A.8.22<\/td><td>Trennung von Netzwerken<\/td><td>Ja<\/td><td>Teilweise<\/td><td>Umgebungstrennung prod/int<\/td><\/tr><tr><td>A.8.23<\/td><td>Web-Filterung<\/td><td>Ja<\/td><td>Teilweise<\/td><td>CORS, Egress-Kontrolle<\/td><\/tr><tr><td>A.8.24<\/td><td>Nutzung von Kryptographie<\/td><td>Ja<\/td><td>Umgesetzt<\/td><td><a href=\"../05_betrieb/04_Verschluesselung_und_Schluesselmanagement.md\">Verschlüsselung &amp; Schlüsselmgmt<\/a><\/td><\/tr><tr><td>A.8.25<\/td><td>Sicherer Entwicklungslebenszyklus<\/td><td>Ja<\/td><td>Umgesetzt<\/td><td><a href=\"../05_betrieb/15_Sichere_Softwareentwicklung_SDLC.md\">SDLC<\/a><\/td><\/tr><tr><td>A.8.26<\/td><td>Anforderungen an Anwendungssicherheit<\/td><td>Ja<\/td><td>Umgesetzt<\/td><td><a href=\"../05_betrieb/15_Sichere_Softwareentwicklung_SDLC.md\">SDLC<\/a><\/td><\/tr><tr><td>A.8.27<\/td><td>Sichere Systemarchitektur &amp; Engineering<\/td><td>Ja<\/td><td>Teilweise<\/td><td>Architektur-Prinzipien dokumentieren<\/td><\/tr><tr><td>A.8.28<\/td><td>Sicheres Codieren<\/td><td>Ja<\/td><td>Umgesetzt<\/td><td><a href=\"../../../d-guides/coding-conventions.md\">Coding-Conventions<\/a>, Review<\/td><\/tr><tr><td>A.8.29<\/td><td>Sicherheitstests in Entw./Abnahme<\/td><td>Ja<\/td><td>Teilweise<\/td><td><a href=\"../../../d-guides/testing-strategy.md\">Testing-Strategie<\/a>, Staging-Verifikation<\/td><\/tr><tr><td>A.8.30<\/td><td>Ausgelagerte Entwicklung<\/td><td>N/A<\/td><td>N/A<\/td><td>Keine ausgelagerte Entwicklung<\/td><\/tr><tr><td>A.8.31<\/td><td>Trennung Entw./Test/Produktion<\/td><td>Ja<\/td><td>Umgesetzt<\/td><td>env-prod/env-int, Staging<\/td><\/tr><tr><td>A.8.32<\/td><td>Change Management<\/td><td>Ja<\/td><td>Umgesetzt<\/td><td><a href=\"../05_betrieb/08_Change_Management.md\">Change Management<\/a><\/td><\/tr><tr><td>A.8.33<\/td><td>Testinformation<\/td><td>Ja<\/td><td>Geplant<\/td><td>Umgang mit Produktivdaten in Test klären<\/td><\/tr><tr><td>A.8.34<\/td><td>Schutz von Systemen bei Audit-Tests<\/td><td>Ja<\/td><td>Teilweise<\/td><td>Auditzugriffe kontrolliert<\/td><\/tr><\/tbody><\/table>\n<h2>Pflege<\/h2>\n<p>Bei jeder wesentlichen Änderung von Controls/Risiken aktualisieren. Das SoA wird im <a href=\"../06_bewertung/management-review.md\">Management-Review<\/a> bestätigt. Teilweise/Geplant-Einträge spiegeln sich im <a href=\"../07_verbesserung/massnahmen-register.md\">Massnahmenregister<\/a>.<\/p>", "text": "<!-- docid: ims-06-03 --> <!-- status: entwurf --> <!-- version: 0.1 --> <!-- owner: patrick motsch --> <!-- approver: geschäftsführung poweron ag --> <!-- approveddate: --> <!-- nextreview: 2026-12-03 --> <!-- classification: vertraulich --> <!-- isorefs: 27001:6.1.3,annexa --> # statement of applicability (soa) -- iso/iec 27001:2022 annex a **dokumenttyp:** pflichtdokument (iso 27001 6.1.3 d) **stand:** 2026-06-03 (entwurf) dieses soa listet alle 93 annex-a-controls (2022) mit anwendbarkeit, begründung, umsetzungsstatus und verweis auf das umsetzende dokument. status: **umgesetzt / teilweise / geplant / n/a**. offene/teilweise punkte sind im [massnahmenregister](../07_verbesserung/massnahmen-register.md) geführt. legende anwendbarkeit: **ja** = anwendbar; **n/a** = nicht anwendbar (mit begründung). cloud-betrieb bei infomaniak (ch): bestimmte physische controls liegen beim provider (anwendbar, \"geerbt\"). ## a.5 organisatorische controls | control | titel | anwend. | status | referenz / begründung | |---|---|---|---|---| | a.5.1 | informationssicherheits-politiken | ja | umgesetzt | [informationssicherheitspolitik.md](../02_fuehrung/informationssicherheitspolitik.md) | | a.5.2 | rollen & verantwortlichkeiten | ja | umgesetzt | [rollen-verantwortlichkeiten.md](../02_fuehrung/rollen-verantwortlichkeiten.md) | | a.5.3 | aufgabentrennung | ja | teilweise | klein-team; kompensierend vier-augen-prinzip, externes audit | | a.5.4 | verantwortung der leitung | ja | umgesetzt | [00_ims-handbuch.md](../00_ims-handbuch.md), management-review | | a.5.5 | kontakt zu behörden | ja | geplant | meldewege (edoeb/finma) in [incident response](../05_betrieb/07_incident_response_und_meldewesen.md) festhalten | | a.5.6 | kontakt zu interessengruppen | ja | teilweise | security-quellen/cert-feeds; formalisieren | | a.5.7 | threat intelligence | ja | teilweise | [schwachstellenmanagement](../05_betrieb/10_schwachstellenmanagement.md) | | a.5.8 | is im projektmanagement | ja | umgesetzt | [sdlc](../05_betrieb/15_sichere_softwareentwicklung_sdlc.md), tech-workshop | | a.5.9 | inventar der werte (assets) | ja | teilweise | [drittanbieter-inventar](../05_betrieb/20260528_drittanbieter-inventar.md); asset-inventar ergänzen | | a.5.10 | zulässige nutzung von werten | ja | geplant | acceptable-use in is-politik konkretisieren | | a.5.11 | rückgabe von werten | ja | geplant | offboarding-checkliste ([mitarbeitersicherheit](../05_betrieb/03_mitarbeitersicherheit_und_screening.md)) | | a.5.12 | klassifizierung von information | ja | teilweise | klassifizierungsschema (header `classification`); ausweiten | | a.5.13 | kennzeichnung von information | ja | teilweise | header-klassifizierung; daten-labeling ergänzen | | a.5.14 | informationsübertragung | ja | umgesetzt | [verschlüsselung](../05_betrieb/04_verschluesselung_und_schluesselmanagement.md), tls, [neutralisierung](../05_betrieb/neutralisierung-detail.md) | | a.5.15 | zugangssteuerung | ja | umgesetzt | [zugriffsmanagement](../05_betrieb/02_zugriffsmanagement_iam_pam.md), rbac | | a.5.16 | identitätsmanagement | ja | umgesetzt | [zugriffsmanagement](../05_betrieb/02_zugriffsmanagement_iam_pam.md) | | a.5.17 | authentisierungsinformation | ja | umgesetzt | [zugriffsmanagement](../05_betrieb/02_zugriffsmanagement_iam_pam.md) — mfa admin/server (r-03, juni 2026) | | a.5.18 | zugangsrechte | ja | umgesetzt | [zugriffsmanagement](../05_betrieb/02_zugriffsmanagement_iam_pam.md) | | a.5.19 | is in lieferantenbeziehungen | ja | umgesetzt | [subunternehmer](../05_betrieb/17_subunternehmer_management.md) | | a.5.20 | is in lieferantenvereinbarungen | ja | teilweise | avvs vervollständigen (openai zero-retention) | | a.5.21 | is in der ikt-lieferkette | ja | teilweise | [drittanbieter-inventar](../05_betrieb/20260528_drittanbieter-inventar.md) | | a.5.22 | überwachung der lieferantenleistung | ja | geplant | review-turnus lieferanten festlegen | | a.5.23 | is bei nutzung von cloud-diensten | ja | umgesetzt | infomaniak (ch); [netzwerk/infra](../05_betrieb/12_netzwerk_und_infrastruktursicherheit.md) | | a.5.24 | incident-management planung | ja | umgesetzt | [incident response](../05_betrieb/07_incident_response_und_meldewesen.md) | | a.5.25 | bewertung von is-ereignissen | ja | umgesetzt | [incident response](../05_betrieb/07_incident_response_und_meldewesen.md) | | a.5.26 | reaktion auf is-vorfälle | ja | umgesetzt | [incident response](../05_betrieb/07_incident_response_und_meldewesen.md) | | a.5.27 | lernen aus vorfällen | ja | teilweise | post-incident-review -> [kvp](../07_verbesserung/korrekturmassnahmen-und-kvp.md) | | a.5.28 | sammlung von beweismitteln | ja | teilweise | logs/forensik in [logging](../05_betrieb/11_logging_und_monitoring.md) | | a.5.29 | is während störung | ja | umgesetzt | [bcm/dr](../05_betrieb/06_business_continuity_und_disaster_recovery.md) | | a.5.30 | ikt-bereitschaft für bc | ja | umgesetzt | [bcm-runbook](../05_betrieb/20260528_bcm_runbook.md) | | a.5.31 | gesetzliche & vertragliche anforderungen | ja | umgesetzt | [recht/bestpractice](../05_betrieb/18_analyse_recht_und_bestpractice.md), agb | | a.5.32 | geistiges eigentum | ja | teilweise | lizenz-/oss-compliance dokumentieren | | a.5.33 | schutz von aufzeichnungen | ja | umgesetzt | [datenaufbewahrung](../05_betrieb/13_datenaufbewahrung_loeschung_legalhold.md) | | a.5.34 | datenschutz & pii-schutz | ja | umgesetzt | [security-overview.md](../05_betrieb/security-overview.md), dsgvo-funktionen | | a.5.35 | unabhängige is-prüfung | ja | geplant | externes [internes audit](../06_bewertung/internes-audit.md) | | a.5.36 | konformität mit politiken | ja | teilweise | audit + konformitätskontrolle | | a.5.37 | dokumentierte betriebsabläufe | ja | umgesetzt | runbooks in `05_betrieb/` | ## a.6 personenbezogene controls | control | titel | anwend. | status | referenz / begründung | |---|---|---|---|---| | a.6.1 | sicherheitsüberprüfung (screening) | ja | teilweise | [mitarbeitersicherheit](../05_betrieb/03_mitarbeitersicherheit_und_screening.md); hintergrundprüfung klären | | a.6.2 | arbeitsvertragsbedingungen | ja | teilweise | is-klauseln in verträgen ergänzen | | a.6.3 | awareness, schulung & ausbildung | ja | geplant | [kompetenz/schulung](../04_unterstuetzung/ressourcen-kompetenz-schulung.md) | | a.6.4 | disziplinarverfahren | ja | geplant | verfahren in hr-doku festhalten | | a.6.5 | verantwortung nach beendigung | ja | teilweise | offboarding; nda-fortgeltung | | a.6.6 | vertraulichkeits-/nda-vereinbarungen | ja | teilweise | nda-vorlage sicherstellen | | a.6.7 | remote-arbeit | ja | umgesetzt | [zugriffsmanagement](../05_betrieb/02_zugriffsmanagement_iam_pam.md), vpn/geräte | | a.6.8 | meldung von is-ereignissen | ja | umgesetzt | [incident response](../05_betrieb/07_incident_response_und_meldewesen.md) | ## a.7 physische controls eigene büro-infrastruktur minimal (remote-team); rechenzentrums-controls liegen beim cloud-provider infomaniak (ch) und werden über dessen zertifizierungen (iso 27001) geerbt. | control | titel | anwend. | status | referenz / begründung | |---|---|---|---|---| | a.7.1 | physische sicherheitsperimeter | ja (geerbt) | umgesetzt | infomaniak rz-zertifizierung | | a.7.2 | physischer zutritt | ja (geerbt) | umgesetzt | infomaniak | | a.7.3 | sicherung von büros/räumen | ja | teilweise | home-/büro-grundschutz | | a.7.4 | physische überwachung | ja (geerbt) | umgesetzt | infomaniak | | a.7.5 | schutz vor physischen/umweltbed. bedrohungen | ja (geerbt) | umgesetzt | infomaniak | | a.7.6 | arbeiten in sicherheitsbereichen | n/a | n/a | keine eigenen sicherheitsbereiche | | a.7.7 | clear desk / clear screen | ja | geplant | regel in is-politik aufnehmen | | a.7.8 | platzierung & schutz von geräten | ja | teilweise | endgeräte-richtlinie | | a.7.9 | schutz von werten ausserhalb | ja | teilweise | geräteverschlüsselung | | a.7.10 | speichermedien | ja | teilweise | verschlüsselung, sichere löschung | | a.7.11 | versorgungseinrichtungen | ja (geerbt) | umgesetzt | infomaniak | | a.7.12 | verkabelungssicherheit | ja (geerbt) | umgesetzt | infomaniak | | a.7.13 | instandhaltung von geräten | ja | teilweise | patch/wartung endgeräte | | a.7.14 | sichere entsorgung/wiederverwendung | ja | geplant | lösch-/entsorgungsregel | ## a.8 technologische controls | control | titel | anwend. | status | referenz / begründung | |---|---|---|---|---| | a.8.1 | endgeräte der nutzer | ja | teilweise | endgeräte-richtlinie, verschlüsselung | | a.8.2 | privilegierte zugangsrechte | ja | umgesetzt | [zugriffsmanagement](../05_betrieb/02_zugriffsmanagement_iam_pam.md) | | a.8.3 | informationszugriffsbeschränkung | ja | umgesetzt | rbac, mandantentrennung | | a.8.4 | zugriff auf quellcode | ja | umgesetzt | forgejo-rbac | | a.8.5 | sichere authentisierung | ja | umgesetzt | [zugriffsmanagement](../05_betrieb/02_zugriffsmanagement_iam_pam.md) — mfa admin/server (r-03, juni 2026) | | a.8.6 | kapazitätsmanagement | ja | umgesetzt | [kapazitätsmanagement](../05_betrieb/16_kapazitaetsmanagement.md) | | a.8.7 | schutz vor schadsoftware | ja | teilweise | endpoint-schutz, dependency-scans | | a.8.8 | management techn. schwachstellen | ja | umgesetzt | [schwachstellen](../05_betrieb/10_schwachstellenmanagement.md), [patch](../05_betrieb/09_patch_management.md) | | a.8.9 | konfigurationsmanagement | ja | teilweise | .env-trennung; iac/konformität ausbauen | | a.8.10 | löschung von information | ja | umgesetzt | [datenaufbewahrung](../05_betrieb/13_datenaufbewahrung_loeschung_legalhold.md), dsgvo-löschung | | a.8.11 | datenmaskierung | ja | umgesetzt | [neutralisierung](../05_betrieb/neutralisierung-detail.md) | | a.8.12 | verhinderung von datenabfluss | ja | teilweise | neutralisierung, read-only db-zugriff ki | | a.8.13 | sicherung (backup) | ja | teilweise | [backup](../05_betrieb/05_backup_und_wiederherstellung.md); restore-test offen (r-04) | | a.8.14 | redundanz von verarbeitungseinrichtungen | ja | teilweise | provider-redundanz; dokumentieren | | a.8.15 | protokollierung (logging) | ja | umgesetzt | [logging & monitoring](../05_betrieb/11_logging_und_monitoring.md) | | a.8.16 | überwachung von aktivitäten | ja | teilweise | monitoring ausbauen | | a.8.17 | uhrzeitsynchronisation | ja | umgesetzt | ntp (infra) | | a.8.18 | nutzung privilegierter hilfsprogramme | ja | teilweise | einschränkung/protokollierung | | a.8.19 | software-installation auf betriebssystemen | ja | teilweise | deployment über ci/cd | | a.8.20 | netzwerksicherheit | ja | umgesetzt | [netzwerk/infra](../05_betrieb/12_netzwerk_und_infrastruktursicherheit.md) | | a.8.21 | sicherheit von netzwerkdiensten | ja | umgesetzt | tls, reverse proxy | | a.8.22 | trennung von netzwerken | ja | teilweise | umgebungstrennung prod/int | | a.8.23 | web-filterung | ja | teilweise | cors, egress-kontrolle | | a.8.24 | nutzung von kryptographie | ja | umgesetzt | [verschlüsselung & schlüsselmgmt](../05_betrieb/04_verschluesselung_und_schluesselmanagement.md) | | a.8.25 | sicherer entwicklungslebenszyklus | ja | umgesetzt | [sdlc](../05_betrieb/15_sichere_softwareentwicklung_sdlc.md) | | a.8.26 | anforderungen an anwendungssicherheit | ja | umgesetzt | [sdlc](../05_betrieb/15_sichere_softwareentwicklung_sdlc.md) | | a.8.27 | sichere systemarchitektur & engineering | ja | teilweise | architektur-prinzipien dokumentieren | | a.8.28 | sicheres codieren | ja | umgesetzt | [coding-conventions](../../../d-guides/coding-conventions.md), review | | a.8.29 | sicherheitstests in entw./abnahme | ja | teilweise | [testing-strategie](../../../d-guides/testing-strategy.md), staging-verifikation | | a.8.30 | ausgelagerte entwicklung | n/a | n/a | keine ausgelagerte entwicklung | | a.8.31 | trennung entw./test/produktion | ja | umgesetzt | env-prod/env-int, staging | | a.8.32 | change management | ja | umgesetzt | [change management](../05_betrieb/08_change_management.md) | | a.8.33 | testinformation | ja | geplant | umgang mit produktivdaten in test klären | | a.8.34 | schutz von systemen bei audit-tests | ja | teilweise | auditzugriffe kontrolliert | ## pflege bei jeder wesentlichen änderung von controls/risiken aktualisieren. das soa wird im [management-review](../06_bewertung/management-review.md) bestätigt. teilweise/geplant-einträge spiegeln sich im [massnahmenregister](../07_verbesserung/massnahmen-register.md). ", "nextReview": "2026-12-03", "overdueReview": false, "zuPruefen": []}, {"id": "03_planung/ziele-und-kennzahlen.md", "path": "03_planung/ziele-und-kennzahlen.md", "chapter": "03_planung", "title": "Ziele & Kennzahlen (Qualität und Informationssicherheit)", "filename": "ziele-und-kennzahlen.md", "meta": {"docId": "IMS-06-04", "status": "entwurf", "version": "0.1", "owner": "Patrick Motsch", "approver": "Geschäftsführung PowerOn AG", "approvedDate": "", "nextReview": "2027-06-03", "classification": "intern", "isoRefs": "9001:6.2; 27001:6.2,9.1"}, "html": "<h1>Ziele &amp; Kennzahlen (Qualität und Informationssicherheit)<\/h1>\n<p><strong>Dokumenttyp:<\/strong> Pflichtdokument (ISO 9001 6.2 / ISO 27001 6.2) <strong>Messperiode:<\/strong> Kalenderjahr 2026 (Erstfestlegung)<\/p>\n<p>Ziele sind messbar, terminiert und einem Owner zugeordnet. Die Messung erfolgt gemäss <a href=\"../06_bewertung/monitoring-messung.md\">Monitoring &amp; Messung<\/a>; Bewertung im <a href=\"../06_bewertung/management-review.md\">Management-Review<\/a>.<\/p>\n<h2>1. Qualitätsziele (ISO 9001)<\/h2>\n<table><thead><tr><th>ID<\/th><th>Ziel<\/th><th>Kennzahl (KPI)<\/th><th>Zielwert<\/th><th>Owner<\/th><\/tr><\/thead><tbody><tr><td>Q-1<\/td><td>Stabile Releases<\/td><td>Anteil Releases ohne Rollback/Hotfix &lt; 48h<\/td><td>&gt;= 95 %<\/td><td>Patrick Motsch<\/td><\/tr><tr><td>Q-2<\/td><td>Schnelle Fehlerbehebung<\/td><td>Einhaltung Bug-SLOs (kritisch 24h)<\/td><td>&gt;= 90 %<\/td><td>Patrick Motsch<\/td><\/tr><tr><td>Q-3<\/td><td>Nachvollziehbarkeit<\/td><td>Releases mit vollständigen Release Notes/CHANGELOG<\/td><td>100 %<\/td><td>Patrick Motsch<\/td><\/tr><tr><td>Q-4<\/td><td>Kundenzufriedenheit<\/td><td>Bearbeitete Support-Tickets in SLA<\/td><td>&gt;= 90 %<\/td><td>Patrick Motsch<\/td><\/tr><\/tbody><\/table>\n<h2>2. Informationssicherheitsziele (ISO 27001)<\/h2>\n<table><thead><tr><th>ID<\/th><th>Ziel<\/th><th>Kennzahl (KPI)<\/th><th>Zielwert<\/th><th>Owner<\/th><\/tr><\/thead><tbody><tr><td>S-1<\/td><td>Risiken unter Kontrolle<\/td><td>Offene Risiken Klasse hoch+<\/td><td>0 unbehandelt<\/td><td>Patrick Motsch<\/td><\/tr><tr><td>S-2<\/td><td>Aktuelle Systeme<\/td><td>Kritische Schwachstellen gepatcht innert SLA<\/td><td>100 %<\/td><td>Patrick Motsch<\/td><\/tr><tr><td>S-3<\/td><td>Wiederherstellbarkeit<\/td><td>Erfolgreiche Restore-Tests pro Jahr<\/td><td>&gt;= 2<\/td><td>Patrick Motsch<\/td><\/tr><tr><td>S-4<\/td><td>Zugriffssicherheit<\/td><td>Admin-/Server-Zugänge mit MFA<\/td><td>100 % (erreicht Juni 2026)<\/td><td>Patrick Motsch<\/td><\/tr><tr><td>S-5<\/td><td>Awareness<\/td><td>Mitarbeitende mit jährlicher IS-Schulung<\/td><td>100 %<\/td><td>Patrick Motsch<\/td><\/tr><tr><td>S-6<\/td><td>Vorfallreaktion<\/td><td>Incidents innerhalb Zielreaktionszeit behandelt<\/td><td>&gt;= 95 %<\/td><td>Patrick Motsch<\/td><\/tr><\/tbody><\/table>\n<h2>3. IMS-Aufbauziel (2026)<\/h2>\n<table><thead><tr><th>ID<\/th><th>Ziel<\/th><th>Kennzahl<\/th><th>Zielwert<\/th><th>Termin<\/th><\/tr><\/thead><tbody><tr><td>IMS-1<\/td><td>Gelebtes, audit-reifes IMS<\/td><td>1 internes Audit + 1 Management-Review durchgeführt<\/td><td>erfüllt<\/td><td>2026 Q3<\/td><\/tr><tr><td>IMS-2<\/td><td>Dokumentenpflege<\/td><td>Dokumente ohne überfälliges Review<\/td><td>100 %<\/td><td>laufend<\/td><\/tr><\/tbody><\/table>\n<h2>4. Pflege<\/h2>\n<p>Zielwerte werden jährlich im Management-Review überprüft und neu festgelegt. Abweichungen lösen Massnahmen im <a href=\"../07_verbesserung/massnahmen-register.md\">Massnahmenregister<\/a> aus.<\/p>", "text": "<!-- docid: ims-06-04 --> <!-- status: entwurf --> <!-- version: 0.1 --> <!-- owner: patrick motsch --> <!-- approver: geschäftsführung poweron ag --> <!-- approveddate: --> <!-- nextreview: 2027-06-03 --> <!-- classification: intern --> <!-- isorefs: 9001:6.2; 27001:6.2,9.1 --> # ziele & kennzahlen (qualität und informationssicherheit) **dokumenttyp:** pflichtdokument (iso 9001 6.2 / iso 27001 6.2) **messperiode:** kalenderjahr 2026 (erstfestlegung) ziele sind messbar, terminiert und einem owner zugeordnet. die messung erfolgt gemäss [monitoring & messung](../06_bewertung/monitoring-messung.md); bewertung im [management-review](../06_bewertung/management-review.md). ## 1. qualitätsziele (iso 9001) | id | ziel | kennzahl (kpi) | zielwert | owner | |---|---|---|---|---| | q-1 | stabile releases | anteil releases ohne rollback/hotfix < 48h | >= 95 % | patrick motsch | | q-2 | schnelle fehlerbehebung | einhaltung bug-slos (kritisch 24h) | >= 90 % | patrick motsch | | q-3 | nachvollziehbarkeit | releases mit vollständigen release notes/changelog | 100 % | patrick motsch | | q-4 | kundenzufriedenheit | bearbeitete support-tickets in sla | >= 90 % | patrick motsch | ## 2. informationssicherheitsziele (iso 27001) | id | ziel | kennzahl (kpi) | zielwert | owner | |---|---|---|---|---| | s-1 | risiken unter kontrolle | offene risiken klasse hoch+ | 0 unbehandelt | patrick motsch | | s-2 | aktuelle systeme | kritische schwachstellen gepatcht innert sla | 100 % | patrick motsch | | s-3 | wiederherstellbarkeit | erfolgreiche restore-tests pro jahr | >= 2 | patrick motsch | | s-4 | zugriffssicherheit | admin-/server-zugänge mit mfa | 100 % (erreicht juni 2026) | patrick motsch | | s-5 | awareness | mitarbeitende mit jährlicher is-schulung | 100 % | patrick motsch | | s-6 | vorfallreaktion | incidents innerhalb zielreaktionszeit behandelt | >= 95 % | patrick motsch | ## 3. ims-aufbauziel (2026) | id | ziel | kennzahl | zielwert | termin | |---|---|---|---|---| | ims-1 | gelebtes, audit-reifes ims | 1 internes audit + 1 management-review durchgeführt | erfüllt | 2026 q3 | | ims-2 | dokumentenpflege | dokumente ohne überfälliges review | 100 % | laufend | ## 4. pflege zielwerte werden jährlich im management-review überprüft und neu festgelegt. abweichungen lösen massnahmen im [massnahmenregister](../07_verbesserung/massnahmen-register.md) aus. ", "nextReview": "2027-06-03", "overdueReview": false, "zuPruefen": []}, {"id": "04_unterstuetzung/dokumentenlenkung.md", "path": "04_unterstuetzung/dokumentenlenkung.md", "chapter": "04_unterstuetzung", "title": "Lenkung dokumentierter Information", "filename": "dokumentenlenkung.md", "meta": {"docId": "IMS-07-03", "status": "entwurf", "version": "0.1", "owner": "Patrick Motsch", "approver": "Geschäftsführung PowerOn AG", "approvedDate": "", "nextReview": "2027-06-03", "classification": "intern", "isoRefs": "9001:7.5; 27001:7.5"}, "html": "<h1>Lenkung dokumentierter Information<\/h1>\n<p><strong>Dokumenttyp:<\/strong> Verfahren <strong>Geltungsbereich:<\/strong> Alle gelenkten Dokumente des IMS<\/p>\n<p>ISO 9001:2015 Kap. 7.5 und ISO/IEC 27001:2022 Kap. 7.5 verlangen, dass dokumentierte Information erstellt, freigegeben, aktuell gehalten, geschuetzt und gelenkt wird. Dieses Verfahren beschreibt, wie PowerOn das umsetzt -- bewusst schlank und werkzeuggestützt über Git/Forgejo.<\/p>\n<h2>1. Einheitlicher Metadaten-Header<\/h2>\n<p>Jedes gelenkte IMS-Dokument beginnt mit folgendem Header (HTML-Kommentar, im gerenderten Markdown unsichtbar, vom Cockpit ausgewertet):<\/p>\n<pre class=\"code\"><code>&lt;!-- docId: IMS-XX --&gt;\n&lt;!-- status: entwurf | freigegeben | abgelöst --&gt;\n&lt;!-- version: 0.1 --&gt;\n&lt;!-- owner: &lt;Name&gt; --&gt;\n&lt;!-- approver: &lt;Name/Gremium&gt; --&gt;\n&lt;!-- approvedDate: YYYY-MM-DD --&gt;\n&lt;!-- nextReview: YYYY-MM-DD --&gt;\n&lt;!-- classification: öffentlich | intern | vertraulich --&gt;\n&lt;!-- isoRefs: 9001:&lt;klausel&gt;; 27001:&lt;klausel/AnnexA&gt; --&gt;<\/code><\/pre>\n<table><thead><tr><th>Feld<\/th><th>Bedeutung<\/th><\/tr><\/thead><tbody><tr><td><code>docId<\/code><\/td><td>Eindeutige Dokument-ID (Schema: <code>IMS-&lt;Kapitel&gt;-&lt;Laufnr&gt;<\/code>)<\/td><\/tr><tr><td><code>status<\/code><\/td><td><code>entwurf<\/code> (in Arbeit), <code>freigegeben<\/code> (gültig), <code>abgelöst<\/code> (ersetzt/veraltet)<\/td><\/tr><tr><td><code>version<\/code><\/td><td>Semantisch: 0.x = Entwurf, ab 1.0 = freigegeben; Minor bei inhaltlichen Änderungen<\/td><\/tr><tr><td><code>owner<\/code><\/td><td>Fachlich verantwortliche Person (Pflege)<\/td><\/tr><tr><td><code>approver<\/code><\/td><td>Freigebende Person/Gremium<\/td><\/tr><tr><td><code>approvedDate<\/code><\/td><td>Datum der letzten Freigabe<\/td><\/tr><tr><td><code>nextReview<\/code><\/td><td>Spätestes nächstes Review (Standard: +12 Monate)<\/td><\/tr><tr><td><code>classification<\/code><\/td><td>Schutzbedarf gemäss IS-Politik<\/td><\/tr><tr><td><code>isoRefs<\/code><\/td><td>Abgedeckte Normklauseln/Annex-A-Controls<\/td><\/tr><\/tbody><\/table>\n<h2>2. Lebenszyklus<\/h2>\n<pre class=\"mermaid\">flowchart LR\n    draft[\"entwurf (0.x)\"] --&gt;|\"PR-Review + Freigabe\"| released[\"freigegeben (&gt;=1.0)\"]\n    released --&gt;|\"Änderung\"| draft\n    released --&gt;|\"ersetzt durch Nachfolger\"| retired[\"abgelöst\"]<\/pre>\n<ol><li><strong>Erstellen/Ändern:<\/strong> Auf Branch, Inhalt + Header pflegen.<\/li><li><strong>Freigabe:<\/strong> Pull Request mit Review durch zweite Person (Vier-Augen-Prinzip); Merge = Freigabe. <code>status<\/code> -&gt; <code>freigegeben<\/code>, <code>version<\/code> &gt;= 1.0, <code>approvedDate<\/code> + <code>nextReview<\/code> setzen.<\/li><li><strong>Versionierung &amp; Historie:<\/strong> Git/Forgejo ist die verbindliche Versions- und Änderungshistorie (Commit = Änderungsnachweis).<\/li><li><strong>Ablösung:<\/strong> Ersetzte Dokumente erhalten <code>status: abgelöst<\/code> und einen Vorwärts-Link zum Nachfolger; sie werden nicht gelöscht (Nachvollziehbarkeit).<\/li><\/ol>\n<h2>3. Review-Zyklus (\"gepflegt\")<\/h2>\n<ul><li>Jedes Dokument hat ein <code>nextReview<\/code>-Datum (Standard 12 Monate, anlassbezogen früher).<\/li><li>Das <a href=\"../cockpit/\">Management-Cockpit<\/a> listet überfällige und anstehende Reviews automatisch auf der Pendenzen-Seite.<\/li><li>Reviews werden im <a href=\"dokumentenregister.md\">Dokumentenregister<\/a> nachgeführt; fällige Reviews erzeugen bei Bedarf einen Eintrag im <a href=\"../07_verbesserung/massnahmen-register.md\">Massnahmenregister<\/a>.<\/li><\/ul>\n<h2>4. Schutz und Zugriff<\/h2>\n<ul><li>Vertrauliche Dokumente folgen der Klassifizierung der IS-Politik; das Repository ist zugriffsgeschuetzt (Forgejo-RBAC).<\/li><li>Externe Verteilung nur in freigegebenem Stand; das Cockpit kann als in sich geschlossene HTML zum Teilen erzeugt werden.<\/li><\/ul>\n<h2>5. Externe Dokumente<\/h2>\n<p>Extern vorgegebene Dokumente (Normtexte, Verträge, AVVs der Lieferanten) werden im <a href=\"../05_betrieb/20260528_drittanbieter-inventar.md\">Drittanbieter-Inventar<\/a> bzw. als Records referenziert und als solche gekennzeichnet.<\/p>", "text": "<!-- docid: ims-07-03 --> <!-- status: entwurf --> <!-- version: 0.1 --> <!-- owner: patrick motsch --> <!-- approver: geschäftsführung poweron ag --> <!-- approveddate: --> <!-- nextreview: 2027-06-03 --> <!-- classification: intern --> <!-- isorefs: 9001:7.5; 27001:7.5 --> # lenkung dokumentierter information **dokumenttyp:** verfahren **geltungsbereich:** alle gelenkten dokumente des ims iso 9001:2015 kap. 7.5 und iso/iec 27001:2022 kap. 7.5 verlangen, dass dokumentierte information erstellt, freigegeben, aktuell gehalten, geschuetzt und gelenkt wird. dieses verfahren beschreibt, wie poweron das umsetzt -- bewusst schlank und werkzeuggestützt über git/forgejo. ## 1. einheitlicher metadaten-header jedes gelenkte ims-dokument beginnt mit folgendem header (html-kommentar, im gerenderten markdown unsichtbar, vom cockpit ausgewertet): ``` <!-- docid: ims-xx --> <!-- status: entwurf | freigegeben | abgelöst --> <!-- version: 0.1 --> <!-- owner: <name> --> <!-- approver: <name/gremium> --> <!-- approveddate: yyyy-mm-dd --> <!-- nextreview: yyyy-mm-dd --> <!-- classification: öffentlich | intern | vertraulich --> <!-- isorefs: 9001:<klausel>; 27001:<klausel/annexa> --> ``` | feld | bedeutung | |---|---| | `docid` | eindeutige dokument-id (schema: `ims-<kapitel>-<laufnr>`) | | `status` | `entwurf` (in arbeit), `freigegeben` (gültig), `abgelöst` (ersetzt/veraltet) | | `version` | semantisch: 0.x = entwurf, ab 1.0 = freigegeben; minor bei inhaltlichen änderungen | | `owner` | fachlich verantwortliche person (pflege) | | `approver` | freigebende person/gremium | | `approveddate` | datum der letzten freigabe | | `nextreview` | spätestes nächstes review (standard: +12 monate) | | `classification` | schutzbedarf gemäss is-politik | | `isorefs` | abgedeckte normklauseln/annex-a-controls | ## 2. lebenszyklus ```mermaid flowchart lr draft[\"entwurf (0.x)\"] -->|\"pr-review + freigabe\"| released[\"freigegeben (>=1.0)\"] released -->|\"änderung\"| draft released -->|\"ersetzt durch nachfolger\"| retired[\"abgelöst\"] ``` 1. **erstellen/ändern:** auf branch, inhalt + header pflegen. 2. **freigabe:** pull request mit review durch zweite person (vier-augen-prinzip); merge = freigabe. `status` -> `freigegeben`, `version` >= 1.0, `approveddate` + `nextreview` setzen. 3. **versionierung & historie:** git/forgejo ist die verbindliche versions- und änderungshistorie (commit = änderungsnachweis). 4. **ablösung:** ersetzte dokumente erhalten `status: abgelöst` und einen vorwärts-link zum nachfolger; sie werden nicht gelöscht (nachvollziehbarkeit). ## 3. review-zyklus (\"gepflegt\") - jedes dokument hat ein `nextreview`-datum (standard 12 monate, anlassbezogen früher). - das [management-cockpit](../cockpit/) listet überfällige und anstehende reviews automatisch auf der pendenzen-seite. - reviews werden im [dokumentenregister](dokumentenregister.md) nachgeführt; fällige reviews erzeugen bei bedarf einen eintrag im [massnahmenregister](../07_verbesserung/massnahmen-register.md). ## 4. schutz und zugriff - vertrauliche dokumente folgen der klassifizierung der is-politik; das repository ist zugriffsgeschuetzt (forgejo-rbac). - externe verteilung nur in freigegebenem stand; das cockpit kann als in sich geschlossene html zum teilen erzeugt werden. ## 5. externe dokumente extern vorgegebene dokumente (normtexte, verträge, avvs der lieferanten) werden im [drittanbieter-inventar](../05_betrieb/20260528_drittanbieter-inventar.md) bzw. als records referenziert und als solche gekennzeichnet. ", "nextReview": "2027-06-03", "overdueReview": false, "zuPruefen": []}, {"id": "04_unterstuetzung/dokumentenregister.md", "path": "04_unterstuetzung/dokumentenregister.md", "chapter": "04_unterstuetzung", "title": "Dokumentenregister", "filename": "dokumentenregister.md", "meta": {"docId": "IMS-07-04", "status": "entwurf", "version": "0.1", "owner": "Patrick Motsch", "approver": "Geschäftsführung PowerOn AG", "approvedDate": "", "nextReview": "2027-06-03", "classification": "intern", "isoRefs": "9001:7.5; 27001:7.5"}, "html": "<h1>Dokumentenregister<\/h1>\n<p>Zentrales Verzeichnis aller gelenkten IMS-Dokumente. Massgeblich für Status, Owner und nächstes Review ist der Header im jeweiligen Dokument; das <a href=\"../cockpit/\">Management-Cockpit<\/a> wertet diese automatisch aus. Diese Tabelle dient der manuellen Gesamtübersicht.<\/p>\n<table><thead><tr><th>docId<\/th><th>Dokument<\/th><th>Pfad<\/th><th>Owner<\/th><th>Status<\/th><\/tr><\/thead><tbody><tr><td>IMS-00<\/td><td>IMS-Handbuch<\/td><td><code>00_IMS-Handbuch.md<\/code><\/td><td>Patrick Motsch<\/td><td>entwurf<\/td><\/tr><tr><td>IMS-04-01<\/td><td>Kontext &amp; interessierte Parteien<\/td><td><code>01_kontext/kontext-und-interessierte-parteien.md<\/code><\/td><td>Patrick Motsch<\/td><td>entwurf<\/td><\/tr><tr><td>IMS-04-02<\/td><td>Geltungsbereich / Scope<\/td><td><code>01_kontext/geltungsbereich-scope.md<\/code><\/td><td>Patrick Motsch<\/td><td>entwurf<\/td><\/tr><tr><td>IMS-05-01<\/td><td>Qualitätspolitik<\/td><td><code>02_fuehrung/qm-politik.md<\/code><\/td><td>Patrick Motsch<\/td><td>entwurf<\/td><\/tr><tr><td>IMS-05-02<\/td><td>Informationssicherheitspolitik<\/td><td><code>02_fuehrung/informationssicherheitspolitik.md<\/code><\/td><td>Patrick Motsch<\/td><td>entwurf<\/td><\/tr><tr><td>IMS-05-03<\/td><td>Rollen &amp; Verantwortlichkeiten<\/td><td><code>02_fuehrung/rollen-verantwortlichkeiten.md<\/code><\/td><td>Patrick Motsch<\/td><td>entwurf<\/td><\/tr><tr><td>IMS-05-04<\/td><td>Organisationsreglement<\/td><td><code>02_fuehrung/organisationsreglement.md<\/code><\/td><td>Patrick Motsch<\/td><td>entwurf<\/td><\/tr><tr><td>IMS-06-01<\/td><td>Risikomanagement-Methodik<\/td><td><code>03_planung/risikomanagement-methodik.md<\/code><\/td><td>Patrick Motsch<\/td><td>entwurf<\/td><\/tr><tr><td>IMS-06-02<\/td><td>Risikoregister<\/td><td><code>03_planung/risikoregister.md<\/code><\/td><td>Patrick Motsch<\/td><td>entwurf<\/td><\/tr><tr><td>IMS-06-03<\/td><td>Statement of Applicability (SoA)<\/td><td><code>03_planung/statement-of-applicability-soa.md<\/code><\/td><td>Patrick Motsch<\/td><td>entwurf<\/td><\/tr><tr><td>IMS-06-04<\/td><td>Ziele &amp; Kennzahlen<\/td><td><code>03_planung/ziele-und-kennzahlen.md<\/code><\/td><td>Patrick Motsch<\/td><td>entwurf<\/td><\/tr><tr><td>IMS-07-01<\/td><td>Ressourcen, Kompetenz &amp; Schulung<\/td><td><code>04_unterstuetzung/ressourcen-kompetenz-schulung.md<\/code><\/td><td>Patrick Motsch<\/td><td>entwurf<\/td><\/tr><tr><td>IMS-07-02<\/td><td>Kommunikation<\/td><td><code>04_unterstuetzung/kommunikation.md<\/code><\/td><td>Patrick Motsch<\/td><td>entwurf<\/td><\/tr><tr><td>IMS-07-03<\/td><td>Lenkung dokumentierter Information<\/td><td><code>04_unterstuetzung/dokumentenlenkung.md<\/code><\/td><td>Patrick Motsch<\/td><td>entwurf<\/td><\/tr><tr><td>IMS-07-04<\/td><td>Dokumentenregister<\/td><td><code>04_unterstuetzung/dokumentenregister.md<\/code><\/td><td>Patrick Motsch<\/td><td>entwurf<\/td><\/tr><tr><td>IMS-09-01<\/td><td>Internes Audit<\/td><td><code>06_bewertung/internes-audit.md<\/code><\/td><td>Patrick Motsch<\/td><td>entwurf<\/td><\/tr><tr><td>IMS-09-02<\/td><td>Management-Review<\/td><td><code>06_bewertung/management-review.md<\/code><\/td><td>Patrick Motsch<\/td><td>entwurf<\/td><\/tr><tr><td>IMS-09-03<\/td><td>Monitoring &amp; Messung<\/td><td><code>06_bewertung/monitoring-messung.md<\/code><\/td><td>Patrick Motsch<\/td><td>entwurf<\/td><\/tr><tr><td>IMS-10-01<\/td><td>Korrekturmassnahmen &amp; KVP<\/td><td><code>07_verbesserung/korrekturmassnahmen-und-kvp.md<\/code><\/td><td>Patrick Motsch<\/td><td>entwurf<\/td><\/tr><tr><td>IMS-10-02<\/td><td>Massnahmenregister<\/td><td><code>07_verbesserung/massnahmen-register.md<\/code><\/td><td>Patrick Motsch<\/td><td>entwurf<\/td><\/tr><\/tbody><\/table>\n<h2>Betriebsdokumente (Kap. 8 / Annex A) -- <code>05_betrieb/<\/code><\/h2>\n<p>Die operativen Prozess- und Sicherheitsdokumente (Zugriffsmanagement, Verschlüsselung, Backup, BCM/DR, Incident, Change, Patch, Schwachstellen, Logging, Netzwerk, Datenaufbewahrung, Exit, SDLC, Kapazität, Subunternehmer, Mitarbeitersicherheit) liegen in <code>05_betrieb/<\/code>. Ihre Zuordnung zu ISO-27001-Annex-A-Controls und ISO-9001-Klauseln steht im <a href=\"../03_planung/statement-of-applicability-soa.md\">SoA<\/a> bzw. in den <a href=\"../mappings/\">Mappings<\/a>.<\/p>\n<h2>Hinweis zur Pflege<\/h2>\n<p>Header-Felder (<code>owner<\/code>, <code>status<\/code>, <code>nextReview<\/code>) werden direkt im Dokument gepflegt. Bei neuen Dokumenten hier eine Zeile ergänzen. Die verbindliche Review-Fälligkeit zeigt das Cockpit.<\/p>", "text": "<!-- docid: ims-07-04 --> <!-- status: entwurf --> <!-- version: 0.1 --> <!-- owner: patrick motsch --> <!-- approver: geschäftsführung poweron ag --> <!-- approveddate: --> <!-- nextreview: 2027-06-03 --> <!-- classification: intern --> <!-- isorefs: 9001:7.5; 27001:7.5 --> # dokumentenregister zentrales verzeichnis aller gelenkten ims-dokumente. massgeblich für status, owner und nächstes review ist der header im jeweiligen dokument; das [management-cockpit](../cockpit/) wertet diese automatisch aus. diese tabelle dient der manuellen gesamtübersicht. | docid | dokument | pfad | owner | status | |---|---|---|---|---| | ims-00 | ims-handbuch | `00_ims-handbuch.md` | patrick motsch | entwurf | | ims-04-01 | kontext & interessierte parteien | `01_kontext/kontext-und-interessierte-parteien.md` | patrick motsch | entwurf | | ims-04-02 | geltungsbereich / scope | `01_kontext/geltungsbereich-scope.md` | patrick motsch | entwurf | | ims-05-01 | qualitätspolitik | `02_fuehrung/qm-politik.md` | patrick motsch | entwurf | | ims-05-02 | informationssicherheitspolitik | `02_fuehrung/informationssicherheitspolitik.md` | patrick motsch | entwurf | | ims-05-03 | rollen & verantwortlichkeiten | `02_fuehrung/rollen-verantwortlichkeiten.md` | patrick motsch | entwurf | | ims-05-04 | organisationsreglement | `02_fuehrung/organisationsreglement.md` | patrick motsch | entwurf | | ims-06-01 | risikomanagement-methodik | `03_planung/risikomanagement-methodik.md` | patrick motsch | entwurf | | ims-06-02 | risikoregister | `03_planung/risikoregister.md` | patrick motsch | entwurf | | ims-06-03 | statement of applicability (soa) | `03_planung/statement-of-applicability-soa.md` | patrick motsch | entwurf | | ims-06-04 | ziele & kennzahlen | `03_planung/ziele-und-kennzahlen.md` | patrick motsch | entwurf | | ims-07-01 | ressourcen, kompetenz & schulung | `04_unterstuetzung/ressourcen-kompetenz-schulung.md` | patrick motsch | entwurf | | ims-07-02 | kommunikation | `04_unterstuetzung/kommunikation.md` | patrick motsch | entwurf | | ims-07-03 | lenkung dokumentierter information | `04_unterstuetzung/dokumentenlenkung.md` | patrick motsch | entwurf | | ims-07-04 | dokumentenregister | `04_unterstuetzung/dokumentenregister.md` | patrick motsch | entwurf | | ims-09-01 | internes audit | `06_bewertung/internes-audit.md` | patrick motsch | entwurf | | ims-09-02 | management-review | `06_bewertung/management-review.md` | patrick motsch | entwurf | | ims-09-03 | monitoring & messung | `06_bewertung/monitoring-messung.md` | patrick motsch | entwurf | | ims-10-01 | korrekturmassnahmen & kvp | `07_verbesserung/korrekturmassnahmen-und-kvp.md` | patrick motsch | entwurf | | ims-10-02 | massnahmenregister | `07_verbesserung/massnahmen-register.md` | patrick motsch | entwurf | ## betriebsdokumente (kap. 8 / annex a) -- `05_betrieb/` die operativen prozess- und sicherheitsdokumente (zugriffsmanagement, verschlüsselung, backup, bcm/dr, incident, change, patch, schwachstellen, logging, netzwerk, datenaufbewahrung, exit, sdlc, kapazität, subunternehmer, mitarbeitersicherheit) liegen in `05_betrieb/`. ihre zuordnung zu iso-27001-annex-a-controls und iso-9001-klauseln steht im [soa](../03_planung/statement-of-applicability-soa.md) bzw. in den [mappings](../mappings/). ## hinweis zur pflege header-felder (`owner`, `status`, `nextreview`) werden direkt im dokument gepflegt. bei neuen dokumenten hier eine zeile ergänzen. die verbindliche review-fälligkeit zeigt das cockpit. ", "nextReview": "2027-06-03", "overdueReview": false, "zuPruefen": []}, {"id": "04_unterstuetzung/kommunikation.md", "path": "04_unterstuetzung/kommunikation.md", "chapter": "04_unterstuetzung", "title": "Kommunikation (intern und extern)", "filename": "kommunikation.md", "meta": {"docId": "IMS-07-02", "status": "entwurf", "version": "0.1", "owner": "Patrick Motsch", "approver": "Geschäftsführung PowerOn AG", "approvedDate": "", "nextReview": "2027-06-03", "classification": "intern", "isoRefs": "9001:7.4; 27001:7.4"}, "html": "<h1>Kommunikation (intern und extern)<\/h1>\n<p><strong>Dokumenttyp:<\/strong> Verfahren (ISO 9001/27001 Kap. 7.4)<\/p>\n<p>Regelt, <strong>was, wann, mit wem und wie<\/strong> im Kontext des IMS kommuniziert wird.<\/p>\n<h2>1. Interne Kommunikation<\/h2>\n<table><thead><tr><th>Was<\/th><th>Wann<\/th><th>Wer -&gt; Wem<\/th><th>Kanal<\/th><\/tr><\/thead><tbody><tr><td>Politiken, Ziele, IMS-Änderungen<\/td><td>Bei Änderung / jährlich<\/td><td>Leitung -&gt; Team<\/td><td>Wiki, Teammeeting<\/td><\/tr><tr><td>Risiken, offene Massnahmen<\/td><td>laufend<\/td><td>ISB/QMB -&gt; Team<\/td><td>Massnahmenregister, Cockpit<\/td><\/tr><tr><td>Incidents<\/td><td>sofort<\/td><td>Melder -&gt; Incident-Verantwortlicher<\/td><td>definierter Meldeweg<\/td><\/tr><tr><td>Release Notes / Changes<\/td><td>je Release<\/td><td>Release-Verantwortlicher -&gt; Team<\/td><td>CHANGELOG, Wiki<\/td><\/tr><tr><td>Management-Review-Ergebnisse<\/td><td>nach Review<\/td><td>Leitung -&gt; Team<\/td><td>Protokoll<\/td><\/tr><tr><td>Operations-Meeting<\/td><td>wöchentlich<\/td><td>Patrick, Dominic, Chris (+ ggf. Silvan)<\/td><td>Meeting (Moderation: Chris, Vorschlag) — Daily Business, operative Entscheide, Zahlen<\/td><\/tr><tr><td>Verwaltungsrat (POL)<\/td><td>wöchentlich → Ziel: zweiwöchentlich/monatlich<\/td><td>VR<\/td><td>Strategie, Finanzen, Eskalation aus Operations<\/td><\/tr><tr><td>POL — physisches Treffen<\/td><td>quartalsweise (Vorschlag)<\/td><td>VR<\/td><td>Abendessen / strategischer Austausch<\/td><\/tr><\/tbody><\/table>\n<p>Details und offene POL-Entscheide: <a href=\"../02_fuehrung/organisationsreglement.md\">Organisationsreglement<\/a>.<\/p>\n<h2>2. Externe Kommunikation<\/h2>\n<table><thead><tr><th>Was<\/th><th>Anlass<\/th><th>Wer -&gt; Wem<\/th><th>Kanal<\/th><\/tr><\/thead><tbody><tr><td>Datenschutzvorfall / Meldepflicht<\/td><td>gesetzliche Frist<\/td><td>Datenschutzverantw. -&gt; EDOEB/Betroffene/FINMA<\/td><td>gemäss <a href=\"../05_betrieb/07_Incident_Response_und_Meldewesen.md\">Incident Response<\/a><\/td><\/tr><tr><td>Sicherheits-/Compliance-Nachweise<\/td><td>auf Anfrage<\/td><td>Leitung -&gt; Kunde/Prüfer<\/td><td><a href=\"../05_betrieb/security-overview.md\">security-overview.md<\/a>, SoA-Auszug<\/td><\/tr><tr><td>Wartung / Maintenance Window<\/td><td>mind. 5 Werktage vorab<\/td><td>Betrieb -&gt; Kunden<\/td><td>E-Mail/Statusseite<\/td><\/tr><tr><td>Lieferantenanforderungen<\/td><td>bei Beauftragung<\/td><td>Lieferanten-Verantw. -&gt; Lieferant<\/td><td>Vertrag/AVV<\/td><\/tr><\/tbody><\/table>\n<h2>3. Grundsatz<\/h2>\n<p>Externe sicherheits-/datenschutzrelevante Kommunikation wird ausschliesslich über die benannten Rollen geführt und im freigegebenen Stand verteilt.<\/p>", "text": "<!-- docid: ims-07-02 --> <!-- status: entwurf --> <!-- version: 0.1 --> <!-- owner: patrick motsch --> <!-- approver: geschäftsführung poweron ag --> <!-- approveddate: --> <!-- nextreview: 2027-06-03 --> <!-- classification: intern --> <!-- isorefs: 9001:7.4; 27001:7.4 --> # kommunikation (intern und extern) **dokumenttyp:** verfahren (iso 9001/27001 kap. 7.4) regelt, **was, wann, mit wem und wie** im kontext des ims kommuniziert wird. ## 1. interne kommunikation | was | wann | wer -> wem | kanal | |---|---|---|---| | politiken, ziele, ims-änderungen | bei änderung / jährlich | leitung -> team | wiki, teammeeting | | risiken, offene massnahmen | laufend | isb/qmb -> team | massnahmenregister, cockpit | | incidents | sofort | melder -> incident-verantwortlicher | definierter meldeweg | | release notes / changes | je release | release-verantwortlicher -> team | changelog, wiki | | management-review-ergebnisse | nach review | leitung -> team | protokoll | | operations-meeting | wöchentlich | patrick, dominic, chris (+ ggf. silvan) | meeting (moderation: chris, vorschlag) — daily business, operative entscheide, zahlen | | verwaltungsrat (pol) | wöchentlich → ziel: zweiwöchentlich/monatlich | vr | strategie, finanzen, eskalation aus operations | | pol — physisches treffen | quartalsweise (vorschlag) | vr | abendessen / strategischer austausch | details und offene pol-entscheide: [organisationsreglement](../02_fuehrung/organisationsreglement.md). ## 2. externe kommunikation | was | anlass | wer -> wem | kanal | |---|---|---|---| | datenschutzvorfall / meldepflicht | gesetzliche frist | datenschutzverantw. -> edoeb/betroffene/finma | gemäss [incident response](../05_betrieb/07_incident_response_und_meldewesen.md) | | sicherheits-/compliance-nachweise | auf anfrage | leitung -> kunde/prüfer | [security-overview.md](../05_betrieb/security-overview.md), soa-auszug | | wartung / maintenance window | mind. 5 werktage vorab | betrieb -> kunden | e-mail/statusseite | | lieferantenanforderungen | bei beauftragung | lieferanten-verantw. -> lieferant | vertrag/avv | ## 3. grundsatz externe sicherheits-/datenschutzrelevante kommunikation wird ausschliesslich über die benannten rollen geführt und im freigegebenen stand verteilt. ", "nextReview": "2027-06-03", "overdueReview": false, "zuPruefen": []}, {"id": "04_unterstuetzung/ressourcen-kompetenz-schulung.md", "path": "04_unterstuetzung/ressourcen-kompetenz-schulung.md", "chapter": "04_unterstuetzung", "title": "Ressourcen, Kompetenz, Awareness & Schulung", "filename": "ressourcen-kompetenz-schulung.md", "meta": {"docId": "IMS-07-01", "status": "entwurf", "version": "0.1", "owner": "Patrick Motsch", "approver": "Geschäftsführung PowerOn AG", "approvedDate": "", "nextReview": "2027-06-03", "classification": "intern", "isoRefs": "9001:7.1-7.3; 27001:7.1-7.3,A.6.3"}, "html": "<h1>Ressourcen, Kompetenz, Awareness &amp; Schulung<\/h1>\n<p><strong>Dokumenttyp:<\/strong> Verfahren (ISO 9001/27001 Kap. 7.1-7.3, Annex A.6.3)<\/p>\n<h2>1. Ressourcen (7.1)<\/h2>\n<p>Die Geschäftsführung stellt die für Betrieb und Verbesserung des IMS erforderlichen Ressourcen bereit: Personal, Cloud-Infrastruktur (Infomaniak), Entwicklungs-/CI-Systeme (Forgejo), Tooling sowie Budget für externe Unterstützung (z. B. internes Audit, Penetrationstests).<\/p>\n<h2>2. Kompetenz (7.2)<\/h2>\n<table><thead><tr><th>Kompetenzbereich<\/th><th>Anforderung<\/th><th>Nachweis<\/th><\/tr><\/thead><tbody><tr><td>Sichere Softwareentwicklung<\/td><td>Kenntnis SDLC, Secure Coding, Review<\/td><td>Code-Reviews, Schulungsnachweis<\/td><\/tr><tr><td>Betrieb/DevOps<\/td><td>Deployment, Backup/Restore, Incident-Handling<\/td><td>Runbooks, durchgeführte Tests<\/td><\/tr><tr><td>Datenschutz/Compliance<\/td><td>DSG/DSGVO, AVV, ISO-Grundlagen<\/td><td>Schulungsnachweis<\/td><\/tr><tr><td>Informationssicherheit<\/td><td>Risiko, Annex-A-Controls<\/td><td>Schulungsnachweis<\/td><\/tr><\/tbody><\/table>\n<p>Kompetenzluecken werden im Management-Review identifiziert und über Schulung/externe Unterstützung geschlossen. Kompetenznachweise (Zertifikate, Kursteilnahmen) werden als Records abgelegt.<\/p>\n<h2>3. Awareness (7.3 / A.6.3)<\/h2>\n<ul><li>Alle Mitarbeitenden werden im Onboarding auf IS-Politik, QM-Politik und Meldewege verpflichtet.<\/li><li>Jährliche Auffrischung zu Informationssicherheit und Datenschutz (Ziel S-5: 100 %).<\/li><li>Anlassbezogene Sensibilisierung nach relevanten Incidents.<\/li><\/ul>\n<h2>4. Schulungsnachweis (Record-Vorlage)<\/h2>\n<table><thead><tr><th>Datum<\/th><th>Person<\/th><th>Thema<\/th><th>Form<\/th><th>Nachweis<\/th><\/tr><\/thead><tbody><tr><td><\/td><td><\/td><td><\/td><td><\/td><td><\/td><\/tr><\/tbody><\/table>\n<h2>5. Pflege<\/h2>\n<p>Schulungsplanung und -nachweise werden jährlich aktualisiert; offene Schulungen laufen ins <a href=\"../07_verbesserung/massnahmen-register.md\">Massnahmenregister<\/a>.<\/p>", "text": "<!-- docid: ims-07-01 --> <!-- status: entwurf --> <!-- version: 0.1 --> <!-- owner: patrick motsch --> <!-- approver: geschäftsführung poweron ag --> <!-- approveddate: --> <!-- nextreview: 2027-06-03 --> <!-- classification: intern --> <!-- isorefs: 9001:7.1-7.3; 27001:7.1-7.3,a.6.3 --> # ressourcen, kompetenz, awareness & schulung **dokumenttyp:** verfahren (iso 9001/27001 kap. 7.1-7.3, annex a.6.3) ## 1. ressourcen (7.1) die geschäftsführung stellt die für betrieb und verbesserung des ims erforderlichen ressourcen bereit: personal, cloud-infrastruktur (infomaniak), entwicklungs-/ci-systeme (forgejo), tooling sowie budget für externe unterstützung (z. b. internes audit, penetrationstests). ## 2. kompetenz (7.2) | kompetenzbereich | anforderung | nachweis | |---|---|---| | sichere softwareentwicklung | kenntnis sdlc, secure coding, review | code-reviews, schulungsnachweis | | betrieb/devops | deployment, backup/restore, incident-handling | runbooks, durchgeführte tests | | datenschutz/compliance | dsg/dsgvo, avv, iso-grundlagen | schulungsnachweis | | informationssicherheit | risiko, annex-a-controls | schulungsnachweis | kompetenzluecken werden im management-review identifiziert und über schulung/externe unterstützung geschlossen. kompetenznachweise (zertifikate, kursteilnahmen) werden als records abgelegt. ## 3. awareness (7.3 / a.6.3) - alle mitarbeitenden werden im onboarding auf is-politik, qm-politik und meldewege verpflichtet. - jährliche auffrischung zu informationssicherheit und datenschutz (ziel s-5: 100 %). - anlassbezogene sensibilisierung nach relevanten incidents. ## 4. schulungsnachweis (record-vorlage) | datum | person | thema | form | nachweis | |---|---|---|---|---| | | | | | | ## 5. pflege schulungsplanung und -nachweise werden jährlich aktualisiert; offene schulungen laufen ins [massnahmenregister](../07_verbesserung/massnahmen-register.md). ", "nextReview": "2027-06-03", "overdueReview": false, "zuPruefen": []}, {"id": "05_betrieb/02_Zugriffsmanagement_IAM_PAM.md", "path": "05_betrieb/02_Zugriffsmanagement_IAM_PAM.md", "chapter": "05_betrieb", "title": "Zugriffsmanagement (IAM / PAM)", "filename": "02_Zugriffsmanagement_IAM_PAM.md", "meta": {}, "html": "<h1>Zugriffsmanagement (IAM / PAM)<\/h1>\n<p><strong>Dokumenttyp:<\/strong> Richtlinie &amp; Prozess <strong>Geltungsbereich:<\/strong> Alle Zugänge zu PORTA-Systemen (Server, Datenbank, Admin-UI, Drittdienste) <strong>Version:<\/strong> 1.0 <strong>Status:<\/strong> Entwurf zur internen Freigabe <strong>Owner:<\/strong> Betrieb / DevOps <strong>Letzte Aktualisierung:<\/strong> 02.06.2026 <strong>Deckt ab (CACC):<\/strong> 25, 36, 37, 66, 67, 68, 69<\/p>\n<hr>\n<h2>1. Grundprinzipien<\/h2>\n<p>PowerOn gewährt Zugriffe ausschliesslich nach <strong>Need-to-Know<\/strong> und <strong>Least Privilege<\/strong>. Kein Mitarbeiter erhält mehr Rechte, als für seine Aufgabe erforderlich sind.<\/p>\n<h2>2. Zugriffsebenen der Plattform<\/h2>\n<table><thead><tr><th>Ebene<\/th><th>Beschreibung<\/th><th>Berechtigte<\/th><\/tr><\/thead><tbody><tr><td><strong>SysAdmin (Admin-UI)<\/strong><\/td><td>Höchste Stufe in der PORTA-Admin-UI: DB-Export/Import, Mandatsverwaltung, Feature-Steuerung<\/td><td>Patrick Motsch<\/td><\/tr><tr><td><strong>Server-Zugang (SSH)<\/strong><\/td><td><code>ubuntu@api.poweron.swiss<\/code> / <code>api-int<\/code> — Vollzugriff auf Anwendung und Konfiguration<\/td><td>Patrick Motsch<\/td><\/tr><tr><td><strong>Datenbank<\/strong><\/td><td>DB-User <code>poweron_dev<\/code> auf <code>db.poweron.swiss:5432<\/code><\/td><td>Patrick Motsch<\/td><\/tr><tr><td><strong>Mandats-Administrator (kundenseitig)<\/strong><\/td><td>Verwaltet Nutzer innerhalb des eigenen Tenants<\/td><td>Kunde selbst<\/td><\/tr><tr><td><strong>Endnutzer<\/strong><\/td><td>Nutzung der gebuchten Features<\/td><td>Kunde<\/td><\/tr><\/tbody><\/table>\n<blockquote><strong>Offener Punkt (kompensierende Massnahme nötig):<\/strong> Der SSH-Zugang erfolgt aktuell über den geteilten Benutzer <code>ubuntu<\/code>. Für Nachvollziehbarkeit auf Personenebene ist entweder (a) Umstellung auf personalisierte SSH-Accounts oder (b) lückenlose Protokollierung jeder SSH-Sitzung mit eindeutiger Personenzuordnung erforderlich. → siehe <code>11_Logging_und_Monitoring.md<\/code>. <strong>[ZU PRÜFEN / UMZUSETZEN]<\/strong><\/blockquote>\n<h2>3. Zugang zu Kundendaten im Klartext (#25, #66)<\/h2>\n<p>Mitarbeitende von PowerOn greifen auf Inhaltsdaten eines Kunden im Klartext <strong>nur<\/strong> zu, wenn:<\/p>\n<ol><li>der Kunde dies für einen konkreten Fall (z. B. Support-Ticket) freigegeben hat, <strong>oder<\/strong><\/li><li>eine rechtskräftige behördliche Anordnung dies zwingend verlangt, <strong>oder<\/strong><\/li><li>ein schwerer technischer Störfall den Zugriff temporär erfordert — mit unverzüglicher nachträglicher Information des Kunden.<\/li><\/ol>\n<p>Jeder solche Zugriff wird protokolliert (Datenbank-Export/Import wird serverseitig geloggt, siehe <code>datenbank-handling.md<\/code> Abschnitt 6).<\/p>\n<h2>4. Authentifizierung (#68)<\/h2>\n<table><thead><tr><th>System<\/th><th>Authentifizierungsmethode<\/th><th>MFA<\/th><\/tr><\/thead><tbody><tr><td>PORTA Endnutzer<\/td><td>Microsoft Azure AD OAuth / Google OAuth / lokales Login<\/td><td>[ZU PRÜFEN: MFA erzwungen?]<\/td><\/tr><tr><td>Admin-UI (SysAdmin)<\/td><td>Lokales Login / Session<\/td><td><strong>MFA erzwungen<\/strong> (umgesetzt Juni 2026)<\/td><\/tr><tr><td>SSH-Server<\/td><td>SSH-Key<\/td><td>[ZU PRÜFEN: Key + Passphrase? Bastion?]<\/td><\/tr><tr><td>Drittdienste (OpenAI etc.)<\/td><td>API-Keys in <code>.env<\/code><\/td><td>n/a<\/td><\/tr><\/tbody><\/table>\n<p><strong>Vorgabe:<\/strong> Für privilegierte Zugänge (SysAdmin, SSH, DB) ist Zwei-Faktor-Authentifizierung zu konfigurieren. SMS-/mobile TAN ist möglichst zu vermeiden; bevorzugt App- oder Hardware-Token.<\/p>\n<p><strong>Stand Juni 2026:<\/strong> MFA auf Admin-UI (SysAdmin) und Server-Zugängen umgesetzt. Endnutzer-MFA über IdP (Azure AD/Google) und SSH-Details siehe unten — offene Punkte bleiben markiert.<\/p>\n<h2>5. Berechtigungsvergabe, -änderung und -entzug (#67)<\/h2>\n<table><thead><tr><th>Ereignis<\/th><th>Massnahme<\/th><th>Frist<\/th><\/tr><\/thead><tbody><tr><td>Onboarding<\/td><td>Zugänge gemäss Rolle einrichten, Minimalprinzip<\/td><td>Bei Eintritt<\/td><\/tr><tr><td>Rollenwechsel<\/td><td>Berechtigungen anpassen, nicht mehr benötigte entziehen<\/td><td>Innert 5 Werktagen<\/td><\/tr><tr><td>Offboarding<\/td><td><strong>Alle<\/strong> Zugänge sofort sperren: SSH-Key entfernen, Admin-UI deaktivieren, API-Keys rotieren, DB-Zugang entziehen<\/td><td>Am letzten Arbeitstag<\/td><\/tr><tr><td>Rezertifizierung<\/td><td>Vollständige Überprüfung aller Zugänge und Berechtigungen<\/td><td>Mindestens halbjährlich<\/td><\/tr><\/tbody><\/table>\n<h2>6. Privilegierte Zugriffe (PAM) (#36, #37)<\/h2>\n<p>Privilegierter Zugriff (SSH, DB-Admin, SysAdmin) wird nur sorgfältig ausgewählten, geschulten Personen gewährt. Aufgrund der Teamgrösse ist die Anzahl privilegierter Personen sehr klein, was das Risiko begrenzt. Kompensierend zu fehlender vollständiger Funktionstrennung gilt:<\/p>\n<ul><li>Protokollierung privilegierter Aktionen (Export/Import, Deployments, DB-Zugriffe).<\/li><li>Vier-Augen-Prinzip bei produktiven Releases (siehe <code>feature_release_bugfix.md<\/code> / <code>08_Change_Management.md<\/code>).<\/li><li>Regelmässige Stichprobenprüfung der Protokolle.<\/li><\/ul>\n<h2>7. Zugangsbeschränkung auf IP/Domain (#69)<\/h2>\n<p>[ZU PRÜFEN: Ist der Admin-/Server-Zugang auf bestimmte IP-Adressen beschränkt? Falls ja, dokumentieren. Falls nein, als geplante Massnahme aufnehmen.]<\/p>\n<h2>8. Stand der Umsetzung / Lücken<\/h2>\n<table><thead><tr><th>Thema<\/th><th>Status<\/th><th>Massnahme<\/th><\/tr><\/thead><tbody><tr><td>Personalisierte SSH-Accounts<\/td><td>Offen<\/td><td>Umstellung oder vollständige Sitzungsprotokollierung<\/td><\/tr><tr><td>MFA auf privilegierten Zugängen<\/td><td><strong>Umgesetzt<\/strong> (Juni 2026)<\/td><td>Halbjährliche Rezertifizierung<\/td><\/tr><tr><td>Halbjährliche Rezertifizierung<\/td><td>Neu<\/td><td>Erstdurchführung terminieren<\/td><\/tr><\/tbody><\/table>", "text": "# zugriffsmanagement (iam / pam) **dokumenttyp:** richtlinie & prozess **geltungsbereich:** alle zugänge zu porta-systemen (server, datenbank, admin-ui, drittdienste) **version:** 1.0 **status:** entwurf zur internen freigabe **owner:** betrieb / devops **letzte aktualisierung:** 02.06.2026 **deckt ab (cacc):** 25, 36, 37, 66, 67, 68, 69 --- ## 1. grundprinzipien poweron gewährt zugriffe ausschliesslich nach **need-to-know** und **least privilege**. kein mitarbeiter erhält mehr rechte, als für seine aufgabe erforderlich sind. ## 2. zugriffsebenen der plattform | ebene | beschreibung | berechtigte | |---|---|---| | **sysadmin (admin-ui)** | höchste stufe in der porta-admin-ui: db-export/import, mandatsverwaltung, feature-steuerung | patrick motsch | | **server-zugang (ssh)** | `ubuntu@api.poweron.swiss` / `api-int` — vollzugriff auf anwendung und konfiguration | patrick motsch | | **datenbank** | db-user `poweron_dev` auf `db.poweron.swiss:5432` | patrick motsch | | **mandats-administrator (kundenseitig)** | verwaltet nutzer innerhalb des eigenen tenants | kunde selbst | | **endnutzer** | nutzung der gebuchten features | kunde | > **offener punkt (kompensierende massnahme nötig):** der ssh-zugang erfolgt aktuell über den geteilten benutzer `ubuntu`. für nachvollziehbarkeit auf personenebene ist entweder (a) umstellung auf personalisierte ssh-accounts oder (b) lückenlose protokollierung jeder ssh-sitzung mit eindeutiger personenzuordnung erforderlich. → siehe `11_logging_und_monitoring.md`. **[zu prüfen / umzusetzen]** ## 3. zugang zu kundendaten im klartext (#25, #66) mitarbeitende von poweron greifen auf inhaltsdaten eines kunden im klartext **nur** zu, wenn: 1. der kunde dies für einen konkreten fall (z. b. support-ticket) freigegeben hat, **oder** 2. eine rechtskräftige behördliche anordnung dies zwingend verlangt, **oder** 3. ein schwerer technischer störfall den zugriff temporär erfordert — mit unverzüglicher nachträglicher information des kunden. jeder solche zugriff wird protokolliert (datenbank-export/import wird serverseitig geloggt, siehe `datenbank-handling.md` abschnitt 6). ## 4. authentifizierung (#68) | system | authentifizierungsmethode | mfa | |---|---|---| | porta endnutzer | microsoft azure ad oauth / google oauth / lokales login | [zu prüfen: mfa erzwungen?] | | admin-ui (sysadmin) | lokales login / session | **mfa erzwungen** (umgesetzt juni 2026) | | ssh-server | ssh-key | [zu prüfen: key + passphrase? bastion?] | | drittdienste (openai etc.) | api-keys in `.env` | n/a | **vorgabe:** für privilegierte zugänge (sysadmin, ssh, db) ist zwei-faktor-authentifizierung zu konfigurieren. sms-/mobile tan ist möglichst zu vermeiden; bevorzugt app- oder hardware-token. **stand juni 2026:** mfa auf admin-ui (sysadmin) und server-zugängen umgesetzt. endnutzer-mfa über idp (azure ad/google) und ssh-details siehe unten — offene punkte bleiben markiert. ## 5. berechtigungsvergabe, -änderung und -entzug (#67) | ereignis | massnahme | frist | |---|---|---| | onboarding | zugänge gemäss rolle einrichten, minimalprinzip | bei eintritt | | rollenwechsel | berechtigungen anpassen, nicht mehr benötigte entziehen | innert 5 werktagen | | offboarding | **alle** zugänge sofort sperren: ssh-key entfernen, admin-ui deaktivieren, api-keys rotieren, db-zugang entziehen | am letzten arbeitstag | | rezertifizierung | vollständige überprüfung aller zugänge und berechtigungen | mindestens halbjährlich | ## 6. privilegierte zugriffe (pam) (#36, #37) privilegierter zugriff (ssh, db-admin, sysadmin) wird nur sorgfältig ausgewählten, geschulten personen gewährt. aufgrund der teamgrösse ist die anzahl privilegierter personen sehr klein, was das risiko begrenzt. kompensierend zu fehlender vollständiger funktionstrennung gilt: - protokollierung privilegierter aktionen (export/import, deployments, db-zugriffe). - vier-augen-prinzip bei produktiven releases (siehe `feature_release_bugfix.md` / `08_change_management.md`). - regelmässige stichprobenprüfung der protokolle. ## 7. zugangsbeschränkung auf ip/domain (#69) [zu prüfen: ist der admin-/server-zugang auf bestimmte ip-adressen beschränkt? falls ja, dokumentieren. falls nein, als geplante massnahme aufnehmen.] ## 8. stand der umsetzung / lücken | thema | status | massnahme | |---|---|---| | personalisierte ssh-accounts | offen | umstellung oder vollständige sitzungsprotokollierung | | mfa auf privilegierten zugängen | **umgesetzt** (juni 2026) | halbjährliche rezertifizierung | | halbjährliche rezertifizierung | neu | erstdurchführung terminieren | ", "nextReview": "", "overdueReview": false, "zuPruefen": ["2. Zugriffsebenen der Plattform", "4. Authentifizierung (#68)", "4. Authentifizierung (#68)", "7. Zugangsbeschränkung auf IP/Domain (#69)"]}, {"id": "05_betrieb/03_Mitarbeitersicherheit_und_Screening.md", "path": "05_betrieb/03_Mitarbeitersicherheit_und_Screening.md", "chapter": "05_betrieb", "title": "Mitarbeitersicherheit und Screening", "filename": "03_Mitarbeitersicherheit_und_Screening.md", "meta": {}, "html": "<h1>Mitarbeitersicherheit und Screening<\/h1>\n<p><strong>Dokumenttyp:<\/strong> Richtlinie &amp; Prozess <strong>Geltungsbereich:<\/strong> Alle Mitarbeitenden und Hilfspersonen mit Zugang zu Kundendaten <strong>Version:<\/strong> 1.0 <strong>Status:<\/strong> Entwurf zur internen Freigabe <strong>Owner:<\/strong> Geschäftsführung <strong>Letzte Aktualisierung:<\/strong> 02.06.2026 <strong>Deckt ab (CACC):<\/strong> 23, 35, 37<\/p>\n<hr>\n<h2>1. Vertraulichkeitsverpflichtung (#23)<\/h2>\n<p>Alle Mitarbeitenden und Hilfspersonen werden bei Eintritt schriftlich zur Geheimhaltung sämtlicher Inhaltsdaten der Kunden verpflichtet — insbesondere zur Wahrung des Bankkunden- und sonstigen Berufsgeheimnisses. Die Verpflichtung gilt <strong>zeitlich unbefristet<\/strong> und besteht auch nach Beendigung des Arbeitsverhältnisses fort.<\/p>\n<p><strong>Nachweis:<\/strong> Unterschriebene Geheimhaltungsvereinbarung (NDA) im Personaldossier. <strong>[ZU PRÜFEN: liegen NDAs für alle aktuellen Mitarbeitenden vor?]<\/strong><\/p>\n<h2>2. Sorgfältige Auswahl und Hintergrundprüfung (#35)<\/h2>\n<p>Vor Gewährung von Zugang zu Berufsgeheimnisdaten im Klartext werden Mitarbeitende sorgfältig ausgewählt und überprüft.<\/p>\n<table><thead><tr><th>Prüfschritt<\/th><th>Durchführung<\/th><\/tr><\/thead><tbody><tr><td>Identitätsprüfung<\/td><td>Bei Einstellung<\/td><\/tr><tr><td>Strafregisterauszug<\/td><td>[ZU PRÜFEN: wird verlangt?]<\/td><\/tr><tr><td>Referenzprüfung früherer Arbeitgeber<\/td><td>[ZU PRÜFEN]<\/td><\/tr><tr><td>Prüfung auf einschlägige Sanktionslisten<\/td><td>[ZU PRÜFEN]<\/td><\/tr><\/tbody><\/table>\n<blockquote><strong>Hinweis:<\/strong> Punkt #35 verlangt eine Überprüfung „entsprechend den Standards des Instituts für eigene Mitarbeiter\". Für FINMA-Kunden ist mindestens ein aktueller Strafregisterauszug üblich. Falls dies aktuell nicht erfolgt, als Massnahme aufnehmen.<\/blockquote>\n<h2>3. Schulung und Awareness<\/h2>\n<table><thead><tr><th>Massnahme<\/th><th>Häufigkeit<\/th><\/tr><\/thead><tbody><tr><td>Sicherheits- und Datenschutz-Onboarding<\/td><td>Bei Eintritt<\/td><\/tr><tr><td>Auffrischungsschulung (inkl. Phishing-/Social-Engineering-Awareness)<\/td><td>Jährlich<\/td><\/tr><tr><td>Schulung zu dieser Richtlinie und zur IS-Richtlinie<\/td><td>Bei Eintritt + bei Änderungen<\/td><\/tr><\/tbody><\/table>\n<p><strong>[ZU PRÜFEN: Findet eine strukturierte Schulung statt? Falls informell, formalisieren und dokumentieren.]<\/strong><\/p>\n<h2>4. Überwachung privilegierter Mitarbeitender (#37)<\/h2>\n<p>Mitarbeitende mit privilegiertem Zugriff auf kritische Klartextdaten werden:<\/p>\n<ul><li>sorgfältig ausgewählt und geschult,<\/li><li>durch Audit-Trails überwacht, die regelmässig (mindestens stichprobenweise) ausgewertet werden (siehe <code>11_Logging_und_Monitoring.md<\/code>),<\/li><li>bei Offboarding sofort entzogen (siehe <code>02_Zugriffsmanagement_IAM_PAM.md<\/code> Abschnitt 5).<\/li><\/ul>\n<h2>5. Stand der Umsetzung / Lücken<\/h2>\n<table><thead><tr><th>Thema<\/th><th>Status<\/th><th>Massnahme<\/th><\/tr><\/thead><tbody><tr><td>NDAs für alle Mitarbeitenden<\/td><td>[ZU PRÜFEN]<\/td><td>Vollständigkeit sicherstellen<\/td><\/tr><tr><td>Strafregisterauszug bei Einstellung<\/td><td>[ZU PRÜFEN]<\/td><td>Einführen falls nicht vorhanden<\/td><\/tr><tr><td>Dokumentierte jährliche Schulung<\/td><td>[ZU PRÜFEN]<\/td><td>Formalisieren<\/td><\/tr><\/tbody><\/table>", "text": "# mitarbeitersicherheit und screening **dokumenttyp:** richtlinie & prozess **geltungsbereich:** alle mitarbeitenden und hilfspersonen mit zugang zu kundendaten **version:** 1.0 **status:** entwurf zur internen freigabe **owner:** geschäftsführung **letzte aktualisierung:** 02.06.2026 **deckt ab (cacc):** 23, 35, 37 --- ## 1. vertraulichkeitsverpflichtung (#23) alle mitarbeitenden und hilfspersonen werden bei eintritt schriftlich zur geheimhaltung sämtlicher inhaltsdaten der kunden verpflichtet — insbesondere zur wahrung des bankkunden- und sonstigen berufsgeheimnisses. die verpflichtung gilt **zeitlich unbefristet** und besteht auch nach beendigung des arbeitsverhältnisses fort. **nachweis:** unterschriebene geheimhaltungsvereinbarung (nda) im personaldossier. **[zu prüfen: liegen ndas für alle aktuellen mitarbeitenden vor?]** ## 2. sorgfältige auswahl und hintergrundprüfung (#35) vor gewährung von zugang zu berufsgeheimnisdaten im klartext werden mitarbeitende sorgfältig ausgewählt und überprüft. | prüfschritt | durchführung | |---|---| | identitätsprüfung | bei einstellung | | strafregisterauszug | [zu prüfen: wird verlangt?] | | referenzprüfung früherer arbeitgeber | [zu prüfen] | | prüfung auf einschlägige sanktionslisten | [zu prüfen] | > **hinweis:** punkt #35 verlangt eine überprüfung „entsprechend den standards des instituts für eigene mitarbeiter\". für finma-kunden ist mindestens ein aktueller strafregisterauszug üblich. falls dies aktuell nicht erfolgt, als massnahme aufnehmen. ## 3. schulung und awareness | massnahme | häufigkeit | |---|---| | sicherheits- und datenschutz-onboarding | bei eintritt | | auffrischungsschulung (inkl. phishing-/social-engineering-awareness) | jährlich | | schulung zu dieser richtlinie und zur is-richtlinie | bei eintritt + bei änderungen | **[zu prüfen: findet eine strukturierte schulung statt? falls informell, formalisieren und dokumentieren.]** ## 4. überwachung privilegierter mitarbeitender (#37) mitarbeitende mit privilegiertem zugriff auf kritische klartextdaten werden: - sorgfältig ausgewählt und geschult, - durch audit-trails überwacht, die regelmässig (mindestens stichprobenweise) ausgewertet werden (siehe `11_logging_und_monitoring.md`), - bei offboarding sofort entzogen (siehe `02_zugriffsmanagement_iam_pam.md` abschnitt 5). ## 5. stand der umsetzung / lücken | thema | status | massnahme | |---|---|---| | ndas für alle mitarbeitenden | [zu prüfen] | vollständigkeit sicherstellen | | strafregisterauszug bei einstellung | [zu prüfen] | einführen falls nicht vorhanden | | dokumentierte jährliche schulung | [zu prüfen] | formalisieren | ", "nextReview": "", "overdueReview": false, "zuPruefen": ["1. Vertraulichkeitsverpflichtung (#23)", "2. Sorgfältige Auswahl und Hintergrundprüfung (#35)", "2. Sorgfältige Auswahl und Hintergrundprüfung (#35)", "2. Sorgfältige Auswahl und Hintergrundprüfung (#35)", "3. Schulung und Awareness", "5. Stand der Umsetzung / Lücken", "5. Stand der Umsetzung / Lücken", "5. Stand der Umsetzung / Lücken"]}, {"id": "05_betrieb/04_Verschluesselung_und_Schluesselmanagement.md", "path": "05_betrieb/04_Verschluesselung_und_Schluesselmanagement.md", "chapter": "05_betrieb", "title": "Verschlüsselung und Schlüsselmanagement", "filename": "04_Verschluesselung_und_Schluesselmanagement.md", "meta": {}, "html": "<h1>Verschlüsselung und Schlüsselmanagement<\/h1>\n<p><strong>Dokumenttyp:<\/strong> Konzept <strong>Geltungsbereich:<\/strong> Speicherung und Übertragung aller Kundendaten der PORTA-Plattform <strong>Version:<\/strong> 1.0 <strong>Status:<\/strong> Entwurf zur internen Freigabe <strong>Owner:<\/strong> Betrieb / DevOps <strong>Letzte Aktualisierung:<\/strong> 02.06.2026 <strong>Deckt ab (CACC):<\/strong> 43, 44, 45, 46, 70, 71, 72<\/p>\n<hr>\n<h2>1. Verschlüsselung bei der Übertragung (in transit) (#70)<\/h2>\n<table><thead><tr><th>Verbindung<\/th><th>Schutz<\/th><\/tr><\/thead><tbody><tr><td>Endnutzer → <code>api.poweron.swiss<\/code><\/td><td>HTTPS / TLS [ZU PRÜFEN: TLS 1.2 / 1.3? Ältere Versionen deaktiviert?]<\/td><\/tr><tr><td>Anwendung → Datenbank <code>db.poweron.swiss<\/code><\/td><td>[ZU PRÜFEN: TLS/SSL auf PostgreSQL-Verbindung aktiv?]<\/td><\/tr><tr><td>Anwendung → LLM-Provider (OpenAI etc.)<\/td><td>HTTPS / TLS (durch Provider-APIs)<\/td><\/tr><tr><td>System-E-Mail (Azure Communication Services)<\/td><td>TLS<\/td><\/tr><\/tbody><\/table>\n<p><strong>Vorgabe:<\/strong> Alle externen Verbindungen über TLS 1.2 oder höher; ältere Protokolle deaktiviert.<\/p>\n<h2>2. Verschlüsselung im Ruhezustand (at rest) (#70)<\/h2>\n<table><thead><tr><th>Datenort<\/th><th>Verschlüsselung<\/th><\/tr><\/thead><tbody><tr><td>PostgreSQL-Datenbank (Infomaniak Managed DB)<\/td><td>[ZU PRÜFEN: At-Rest-Verschlüsselung durch Infomaniak aktiviert? Standard bei Managed Databases bestätigen]<\/td><\/tr><tr><td>VM-Speicher (Infomaniak)<\/td><td>[ZU PRÜFEN: Volume-Verschlüsselung]<\/td><\/tr><tr><td>Backup-/Export-Dateien (JSON)<\/td><td><strong>Aktuell unverschlüsselt<\/strong> — siehe Hinweis unten<\/td><\/tr><\/tbody><\/table>\n<blockquote><strong>Wichtiger offener Punkt:<\/strong> Die JSON-Exporte aus <code>datenbank-handling.md<\/code> enthalten <em>alle<\/em> Kundendaten im Klartext und sind aktuell nicht verschlüsselt. <strong>Massnahme:<\/strong> Export-Dateien verschlüsselt ablegen (z. B. AES-256 / GPG) und Aufbewahrungsort absichern. → siehe <code>13_Datenaufbewahrung_Loeschung_LegalHold.md<\/code>.<\/blockquote>\n<h2>3. Verarbeitung bei LLM-Providern (in use)<\/h2>\n<p>Zur KI-Verarbeitung werden Inhaltsdaten an externe LLM-Provider übermittelt (Primär: OpenAI, USA). Während der Verarbeitung liegen die Daten beim Provider. Schutzmechanismen:<\/p>\n<ul><li>Übertragung ausschliesslich über TLS.<\/li><li>Vertragliche Absicherung über AVV/DPA und (für US-Provider) EU-Standardvertragsklauseln. <strong>[ZU PRÜFEN: Verträge abgeschlossen — siehe <code>17_Subunternehmer_Management.md<\/code>]<\/strong><\/li><li>Zero-Data-Retention-Vereinbarung (Daten werden nicht für Provider-Training genutzt). <strong>[ZU PRÜFEN: Enterprise-Tier / Opt-out aktiviert?]<\/strong><\/li><\/ul>\n<h2>4. Schlüsselmanagement-Modelle (#43–46, #71)<\/h2>\n<p>Der Katalog beschreibt vier Modelle. Aktueller Stand und Angebot von PowerOn:<\/p>\n<table><thead><tr><th>Modell<\/th><th>Beschreibung<\/th><th>PowerOn-Angebot<\/th><\/tr><\/thead><tbody><tr><td><strong>A — Kundenkontrolliert<\/strong><\/td><td>Schlüssel nur für vom Kunden zugelassene Nutzer/Prozesse<\/td><td>[ZU PRÜFEN: technisch möglich?]<\/td><\/tr><tr><td><strong>B — Anbieter verwaltet (Standard)<\/strong><\/td><td>Schlüssel im Speicher von PowerOn/Infomaniak, PowerOn verwaltet<\/td><td>Aktueller Stand: Infomaniak Managed Keys<\/td><\/tr><tr><td><strong>C — Anbieter-Speicher, Kunde verwaltet remote<\/strong><\/td><td>Schlüssel bei PowerOn, Verwaltung durch Kunde<\/td><td>[ZU PRÜFEN]<\/td><\/tr><tr><td><strong>D — Kunden-Schlüsselspeicher (BYOK)<\/strong><\/td><td>Schlüssel in kundenseitigem Key Store<\/td><td>[ZU PRÜFEN: BYOK angeboten?]<\/td><\/tr><\/tbody><\/table>\n<p><strong>Realistische Aussage für das Assessment:<\/strong> Aktuell wird Modell B (anbieterverwaltet über Infomaniak) genutzt. BYOK/kundenkontrollierte Schlüssel sind [ZU PRÜFEN: nicht / in Planung].<\/p>\n<h2>5. Schlüssellebenszyklus (#72)<\/h2>\n<p>Anforderungen für sichere Erzeugung, Speicherung, Archivierung, Abfrage, Verteilung, Sperrung und Löschung von Schlüsseln:<\/p>\n<table><thead><tr><th>Phase<\/th><th>Vorgabe<\/th><th>Status<\/th><\/tr><\/thead><tbody><tr><td>Erzeugung<\/td><td>Durch Infomaniak Managed DB / etablierte Bibliotheken<\/td><td>[ZU PRÜFEN]<\/td><\/tr><tr><td>Speicherung<\/td><td>Getrennt von verschlüsselten Daten<\/td><td>[ZU PRÜFEN]<\/td><\/tr><tr><td>API-Keys (OpenAI etc.)<\/td><td>In <code>.env<\/code> auf dem Server, nicht im Git<\/td><td>Umgesetzt (Konfiguration getrennt)<\/td><\/tr><tr><td>Rotation<\/td><td>API-Keys bei Offboarding/Verdacht rotieren<\/td><td>[ZU PRÜFEN: Rotationsintervall definieren]<\/td><\/tr><tr><td>Sperrung/Löschung<\/td><td>Bei Vertragsende Schlüssel vernichten (Krypto-Löschung)<\/td><td>siehe Dok 13<\/td><\/tr><\/tbody><\/table>\n<h2>6. Stand der Umsetzung / Lücken<\/h2>\n<table><thead><tr><th>Thema<\/th><th>Status<\/th><th>Massnahme<\/th><\/tr><\/thead><tbody><tr><td>At-Rest-Verschlüsselung DB bestätigen<\/td><td>[ZU PRÜFEN]<\/td><td>Bei Infomaniak verifizieren, dokumentieren<\/td><\/tr><tr><td>Export-Dateien verschlüsseln<\/td><td>Offen<\/td><td>AES-256/GPG einführen<\/td><\/tr><tr><td>BYOK-Angebot<\/td><td>[ZU PRÜFEN]<\/td><td>Entscheidung für regulierte Kunden<\/td><\/tr><tr><td>Schlüssel-Rotationsintervall<\/td><td>Offen<\/td><td>Festlegen<\/td><\/tr><\/tbody><\/table>", "text": "# verschlüsselung und schlüsselmanagement **dokumenttyp:** konzept **geltungsbereich:** speicherung und übertragung aller kundendaten der porta-plattform **version:** 1.0 **status:** entwurf zur internen freigabe **owner:** betrieb / devops **letzte aktualisierung:** 02.06.2026 **deckt ab (cacc):** 43, 44, 45, 46, 70, 71, 72 --- ## 1. verschlüsselung bei der übertragung (in transit) (#70) | verbindung | schutz | |---|---| | endnutzer → `api.poweron.swiss` | https / tls [zu prüfen: tls 1.2 / 1.3? ältere versionen deaktiviert?] | | anwendung → datenbank `db.poweron.swiss` | [zu prüfen: tls/ssl auf postgresql-verbindung aktiv?] | | anwendung → llm-provider (openai etc.) | https / tls (durch provider-apis) | | system-e-mail (azure communication services) | tls | **vorgabe:** alle externen verbindungen über tls 1.2 oder höher; ältere protokolle deaktiviert. ## 2. verschlüsselung im ruhezustand (at rest) (#70) | datenort | verschlüsselung | |---|---| | postgresql-datenbank (infomaniak managed db) | [zu prüfen: at-rest-verschlüsselung durch infomaniak aktiviert? standard bei managed databases bestätigen] | | vm-speicher (infomaniak) | [zu prüfen: volume-verschlüsselung] | | backup-/export-dateien (json) | **aktuell unverschlüsselt** — siehe hinweis unten | > **wichtiger offener punkt:** die json-exporte aus `datenbank-handling.md` enthalten *alle* kundendaten im klartext und sind aktuell nicht verschlüsselt. **massnahme:** export-dateien verschlüsselt ablegen (z. b. aes-256 / gpg) und aufbewahrungsort absichern. → siehe `13_datenaufbewahrung_loeschung_legalhold.md`. ## 3. verarbeitung bei llm-providern (in use) zur ki-verarbeitung werden inhaltsdaten an externe llm-provider übermittelt (primär: openai, usa). während der verarbeitung liegen die daten beim provider. schutzmechanismen: - übertragung ausschliesslich über tls. - vertragliche absicherung über avv/dpa und (für us-provider) eu-standardvertragsklauseln. **[zu prüfen: verträge abgeschlossen — siehe `17_subunternehmer_management.md`]** - zero-data-retention-vereinbarung (daten werden nicht für provider-training genutzt). **[zu prüfen: enterprise-tier / opt-out aktiviert?]** ## 4. schlüsselmanagement-modelle (#43–46, #71) der katalog beschreibt vier modelle. aktueller stand und angebot von poweron: | modell | beschreibung | poweron-angebot | |---|---|---| | **a — kundenkontrolliert** | schlüssel nur für vom kunden zugelassene nutzer/prozesse | [zu prüfen: technisch möglich?] | | **b — anbieter verwaltet (standard)** | schlüssel im speicher von poweron/infomaniak, poweron verwaltet | aktueller stand: infomaniak managed keys | | **c — anbieter-speicher, kunde verwaltet remote** | schlüssel bei poweron, verwaltung durch kunde | [zu prüfen] | | **d — kunden-schlüsselspeicher (byok)** | schlüssel in kundenseitigem key store | [zu prüfen: byok angeboten?] | **realistische aussage für das assessment:** aktuell wird modell b (anbieterverwaltet über infomaniak) genutzt. byok/kundenkontrollierte schlüssel sind [zu prüfen: nicht / in planung]. ## 5. schlüssellebenszyklus (#72) anforderungen für sichere erzeugung, speicherung, archivierung, abfrage, verteilung, sperrung und löschung von schlüsseln: | phase | vorgabe | status | |---|---|---| | erzeugung | durch infomaniak managed db / etablierte bibliotheken | [zu prüfen] | | speicherung | getrennt von verschlüsselten daten | [zu prüfen] | | api-keys (openai etc.) | in `.env` auf dem server, nicht im git | umgesetzt (konfiguration getrennt) | | rotation | api-keys bei offboarding/verdacht rotieren | [zu prüfen: rotationsintervall definieren] | | sperrung/löschung | bei vertragsende schlüssel vernichten (krypto-löschung) | siehe dok 13 | ## 6. stand der umsetzung / lücken | thema | status | massnahme | |---|---|---| | at-rest-verschlüsselung db bestätigen | [zu prüfen] | bei infomaniak verifizieren, dokumentieren | | export-dateien verschlüsseln | offen | aes-256/gpg einführen | | byok-angebot | [zu prüfen] | entscheidung für regulierte kunden | | schlüssel-rotationsintervall | offen | festlegen | ", "nextReview": "", "overdueReview": false, "zuPruefen": ["1. Verschlüsselung bei der Übertragung (in transit) (#70)", "1. Verschlüsselung bei der Übertragung (in transit) (#70)", "2. Verschlüsselung im Ruhezustand (at rest) (#70)", "2. Verschlüsselung im Ruhezustand (at rest) (#70)", "3. Verarbeitung bei LLM-Providern (in use)", "3. Verarbeitung bei LLM-Providern (in use)", "4. Schlüsselmanagement-Modelle (#43–46, #71)", "4. Schlüsselmanagement-Modelle (#43–46, #71)", "4. Schlüsselmanagement-Modelle (#43–46, #71)", "4. Schlüsselmanagement-Modelle (#43–46, #71)", "5. Schlüssellebenszyklus (#72)", "5. Schlüssellebenszyklus (#72)", "5. Schlüssellebenszyklus (#72)", "6. Stand der Umsetzung / Lücken", "6. Stand der Umsetzung / Lücken"]}, {"id": "05_betrieb/05_Backup_und_Wiederherstellung.md", "path": "05_betrieb/05_Backup_und_Wiederherstellung.md", "chapter": "05_betrieb", "title": "Backup und Wiederherstellung", "filename": "05_Backup_und_Wiederherstellung.md", "meta": {}, "html": "<h1>Backup und Wiederherstellung<\/h1>\n<p><strong>Dokumenttyp:<\/strong> Konzept &amp; Prozess <strong>Geltungsbereich:<\/strong> Alle Kundendaten auf <code>db.poweron.swiss<\/code> <strong>Version:<\/strong> 1.0 <strong>Status:<\/strong> Entwurf zur internen Freigabe <strong>Owner:<\/strong> Betrieb / DevOps <strong>Letzte Aktualisierung:<\/strong> 02.06.2026 <strong>Deckt ab (CACC):<\/strong> 75, 87 <strong>Verweist auf:<\/strong> <code>datenbank-handling.md<\/code>, <code>bcm_runbook.md<\/code><\/p>\n<hr>\n<h2>1. Backup-Strategie (mehrschichtig)<\/h2>\n<p>PowerOn sichert Daten auf zwei Ebenen (vgl. <code>datenbank-handling.md<\/code> Abschnitt 4):<\/p>\n<table><thead><tr><th>Ebene<\/th><th>Mechanismus<\/th><th>Verantwortung<\/th><\/tr><\/thead><tbody><tr><td><strong>Infrastruktur<\/strong><\/td><td>Snapshots der Infomaniak Managed PostgreSQL<\/td><td>Infomaniak / Betrieb<\/td><\/tr><tr><td><strong>Anwendung<\/strong><\/td><td>Vollständiger JSON-Export aller 13 Datenbanken via Admin-UI oder Script<\/td><td>Betrieb (SysAdmin)<\/td><\/tr><\/tbody><\/table>\n<p>Token- und AuthEvent-Tabellen sowie die Testdatenbank werden vom Export ausgeschlossen.<\/p>\n<h2>2. Anforderung #75 — die drei Pflichtelemente<\/h2>\n<p>Punkt #75 verlangt explizit drei Dinge. Stand und Massnahmen:<\/p>\n<h3>2.1 Angemessener Schutz der gesicherten Daten<\/h3>\n<ul><li>Backup-Dateien enthalten alle Kundendaten und sind als vertraulich klassifiziert.<\/li><li><strong>Offen:<\/strong> Export-Dateien aktuell unverschlüsselt → Verschlüsselung einführen (siehe Dok 04).<\/li><li>Ablage nur auf gesicherten Speichern, nicht auf persönlichen Geräten/Cloud (vgl. <code>datenbank-handling.md<\/code> Abschnitt 6).<\/li><\/ul>\n<h3>2.2 Überwachung der Datensicherung<\/h3>\n<ul><li><strong>Offen / [ZU PRÜFEN]:<\/strong> Werden Infomaniak-Snapshots automatisch überwacht (Erfolg/Fehler-Alerting)?<\/li><li><strong>Massnahme:<\/strong> Automatisiertes Alerting bei fehlgeschlagenem Backup einrichten; Backup-Status mindestens wöchentlich kontrollieren.<\/li><\/ul>\n<h3>2.3 Test der Wiederherstellungsverfahren<\/h3>\n<ul><li>Das technische Restore-Verfahren ist in <code>bcm_runbook.md<\/code> Abschnitt 2 vollständig dokumentiert (pg_dump/pg_restore + Migrations-Tool).<\/li><li><strong>Offen:<\/strong> Es fehlt ein dokumentierter, regelmässiger Restore-Test.<\/li><li><strong>Massnahme:<\/strong> Mindestens <strong>vierteljährlich<\/strong> einen Restore-Test auf der INT-Umgebung durchführen und protokollieren (Datum, getestete DB, Dauer, Ergebnis, Tester).<\/li><\/ul>\n<h2>3. Backup-Frequenz und Aufbewahrung<\/h2>\n<table><thead><tr><th>Anlass<\/th><th>Aktion<\/th><th>Aufbewahrung<\/th><\/tr><\/thead><tbody><tr><td>Vor jedem Deployment<\/td><td>Export via Admin-UI<\/td><td>bis zum nächsten erfolgreichen Deployment<\/td><\/tr><tr><td>Vor DB-Migrationen<\/td><td>Export + beschriftet archivieren<\/td><td>mind. 90 Tage<\/td><\/tr><tr><td>Wöchentlich<\/td><td>Archiv-Export<\/td><td>[ZU PRÜFEN: Aufbewahrungsdauer festlegen, z. B. 90 Tage]<\/td><\/tr><tr><td>Infrastruktur-Snapshot<\/td><td>automatisch (Infomaniak)<\/td><td>[ZU PRÜFEN: Intervall &amp; Retention bei Infomaniak]<\/td><\/tr><\/tbody><\/table>\n<h2>4. Wiederherstellungsziele (RTO/RPO)<\/h2>\n<table><thead><tr><th>Parameter<\/th><th>Zielwert<\/th><th>Bemerkung<\/th><\/tr><\/thead><tbody><tr><td>RTO (Recovery Time Objective)<\/td><td>[ZU PRÜFEN, Vorschlag: ≤ 4 h]<\/td><td>Restore dauert lt. Runbook „wenige Minuten bis 1 Stunde\"<\/td><\/tr><tr><td>RPO (Recovery Point Objective)<\/td><td>[ZU PRÜFEN, Vorschlag: ≤ 24 h]<\/td><td>Abhängig von Snapshot-/Export-Frequenz<\/td><\/tr><\/tbody><\/table>\n<blockquote>Hinweis: RTO/RPO müssen zu den im SLA gegenüber Kunden zugesagten Werten passen (AGB Anhang B). Aktuell im AGB-Entwurf RTO ≤ 4 h / RPO ≤ 1 h — das erfordert häufigere Sicherungen als die aktuelle wöchentliche Praxis. <strong>Abgleich nötig.<\/strong><\/blockquote>\n<h2>5. Restore-Test-Protokoll (Vorlage)<\/h2>\n<table><thead><tr><th>Datum<\/th><th>Getestete DB<\/th><th>Quelle (Backup)<\/th><th>Dauer<\/th><th>Ergebnis<\/th><th>Tester<\/th><\/tr><\/thead><tbody><tr><td><\/td><td><\/td><td><\/td><td><\/td><td><\/td><td><\/td><\/tr><\/tbody><\/table>\n<h2>6. Stand der Umsetzung / Lücken<\/h2>\n<table><thead><tr><th>Thema<\/th><th>Status<\/th><th>Massnahme<\/th><\/tr><\/thead><tbody><tr><td>Backup-Verschlüsselung<\/td><td>Offen<\/td><td>siehe Dok 04<\/td><\/tr><tr><td>Backup-Monitoring/Alerting<\/td><td>[ZU PRÜFEN]<\/td><td>Einrichten<\/td><\/tr><tr><td>Regelmässiger Restore-Test<\/td><td>Offen<\/td><td>Vierteljährlich + Protokoll<\/td><\/tr><tr><td>RTO/RPO mit SLA abgleichen<\/td><td>Offen<\/td><td>Werte festlegen &amp; Frequenz anpassen<\/td><\/tr><\/tbody><\/table>", "text": "# backup und wiederherstellung **dokumenttyp:** konzept & prozess **geltungsbereich:** alle kundendaten auf `db.poweron.swiss` **version:** 1.0 **status:** entwurf zur internen freigabe **owner:** betrieb / devops **letzte aktualisierung:** 02.06.2026 **deckt ab (cacc):** 75, 87 **verweist auf:** `datenbank-handling.md`, `bcm_runbook.md` --- ## 1. backup-strategie (mehrschichtig) poweron sichert daten auf zwei ebenen (vgl. `datenbank-handling.md` abschnitt 4): | ebene | mechanismus | verantwortung | |---|---|---| | **infrastruktur** | snapshots der infomaniak managed postgresql | infomaniak / betrieb | | **anwendung** | vollständiger json-export aller 13 datenbanken via admin-ui oder script | betrieb (sysadmin) | token- und authevent-tabellen sowie die testdatenbank werden vom export ausgeschlossen. ## 2. anforderung #75 — die drei pflichtelemente punkt #75 verlangt explizit drei dinge. stand und massnahmen: ### 2.1 angemessener schutz der gesicherten daten - backup-dateien enthalten alle kundendaten und sind als vertraulich klassifiziert. - **offen:** export-dateien aktuell unverschlüsselt → verschlüsselung einführen (siehe dok 04). - ablage nur auf gesicherten speichern, nicht auf persönlichen geräten/cloud (vgl. `datenbank-handling.md` abschnitt 6). ### 2.2 überwachung der datensicherung - **offen / [zu prüfen]:** werden infomaniak-snapshots automatisch überwacht (erfolg/fehler-alerting)? - **massnahme:** automatisiertes alerting bei fehlgeschlagenem backup einrichten; backup-status mindestens wöchentlich kontrollieren. ### 2.3 test der wiederherstellungsverfahren - das technische restore-verfahren ist in `bcm_runbook.md` abschnitt 2 vollständig dokumentiert (pg_dump/pg_restore + migrations-tool). - **offen:** es fehlt ein dokumentierter, regelmässiger restore-test. - **massnahme:** mindestens **vierteljährlich** einen restore-test auf der int-umgebung durchführen und protokollieren (datum, getestete db, dauer, ergebnis, tester). ## 3. backup-frequenz und aufbewahrung | anlass | aktion | aufbewahrung | |---|---|---| | vor jedem deployment | export via admin-ui | bis zum nächsten erfolgreichen deployment | | vor db-migrationen | export + beschriftet archivieren | mind. 90 tage | | wöchentlich | archiv-export | [zu prüfen: aufbewahrungsdauer festlegen, z. b. 90 tage] | | infrastruktur-snapshot | automatisch (infomaniak) | [zu prüfen: intervall & retention bei infomaniak] | ## 4. wiederherstellungsziele (rto/rpo) | parameter | zielwert | bemerkung | |---|---|---| | rto (recovery time objective) | [zu prüfen, vorschlag: ≤ 4 h] | restore dauert lt. runbook „wenige minuten bis 1 stunde\" | | rpo (recovery point objective) | [zu prüfen, vorschlag: ≤ 24 h] | abhängig von snapshot-/export-frequenz | > hinweis: rto/rpo müssen zu den im sla gegenüber kunden zugesagten werten passen (agb anhang b). aktuell im agb-entwurf rto ≤ 4 h / rpo ≤ 1 h — das erfordert häufigere sicherungen als die aktuelle wöchentliche praxis. **abgleich nötig.** ## 5. restore-test-protokoll (vorlage) | datum | getestete db | quelle (backup) | dauer | ergebnis | tester | |---|---|---|---|---|---| | | | | | | | ## 6. stand der umsetzung / lücken | thema | status | massnahme | |---|---|---| | backup-verschlüsselung | offen | siehe dok 04 | | backup-monitoring/alerting | [zu prüfen] | einrichten | | regelmässiger restore-test | offen | vierteljährlich + protokoll | | rto/rpo mit sla abgleichen | offen | werte festlegen & frequenz anpassen | ", "nextReview": "", "overdueReview": false, "zuPruefen": ["2.2 Überwachung der Datensicherung", "3. Backup-Frequenz und Aufbewahrung", "3. Backup-Frequenz und Aufbewahrung", "4. Wiederherstellungsziele (RTO/RPO)", "4. Wiederherstellungsziele (RTO/RPO)", "6. Stand der Umsetzung / Lücken"]}, {"id": "05_betrieb/06_Business_Continuity_und_Disaster_Recovery.md", "path": "05_betrieb/06_Business_Continuity_und_Disaster_Recovery.md", "chapter": "05_betrieb", "title": "Business Continuity (BCP) und Disaster Recovery (DRP)", "filename": "06_Business_Continuity_und_Disaster_Recovery.md", "meta": {}, "html": "<h1>Business Continuity (BCP) und Disaster Recovery (DRP)<\/h1>\n<p><strong>Dokumenttyp:<\/strong> Konzept &amp; Plan <strong>Geltungsbereich:<\/strong> PORTA-Plattform und zugehörige Infrastruktur <strong>Version:<\/strong> 1.0 <strong>Status:<\/strong> Entwurf zur internen Freigabe <strong>Owner:<\/strong> Geschäftsführung / Betrieb <strong>Letzte Aktualisierung:<\/strong> 02.06.2026 <strong>Deckt ab (CACC):<\/strong> 3, 79, 87 <strong>Verweist auf:<\/strong> <code>bcm_runbook.md<\/code>, <code>05_Backup_und_Wiederherstellung.md<\/code>, <code>drittanbieter-inventar.md<\/code><\/p>\n<hr>\n<h2>1. Zweck<\/h2>\n<p>Dieser Plan stellt die kontinuierliche Leistungserbringung und die Wiederherstellung der PORTA-Plattform im Katastrophen- und Störfall sicher. Die operativen Schritte sind im <code>bcm_runbook.md<\/code> dokumentiert; dieses Dokument liefert den organisatorischen Rahmen (Szenarien, Rollen, Ziele, Tests).<\/p>\n<h2>2. Kritische Komponenten und Abhängigkeiten<\/h2>\n<p>Aus dem Drittanbieter-Inventar ergeben sich die geschäftskritischen Abhängigkeiten:<\/p>\n<table><thead><tr><th>Komponente<\/th><th>Anbieter<\/th><th>Auswirkung bei Ausfall<\/th><\/tr><\/thead><tbody><tr><td>VM-Hosting &amp; DB<\/td><td>Infomaniak (CH)<\/td><td><strong>Totalausfall<\/strong> der Plattform<\/td><\/tr><tr><td>Primärer LLM-Provider<\/td><td>OpenAI (USA)<\/td><td>KI-Features (Chat, Agent, Automation) nicht verfügbar — Ausweichen auf Anthropic/Mistral möglich<\/td><\/tr><tr><td>Auth<\/td><td>Microsoft Azure AD / Google OAuth<\/td><td>Login für betroffene Nutzer nicht möglich<\/td><\/tr><tr><td>Zahlungen<\/td><td>Stripe<\/td><td>Neue Abos/Zahlungen schlagen fehl<\/td><\/tr><tr><td>System-E-Mail<\/td><td>Azure Communication Services (CH)<\/td><td>Einladungen/Benachrichtigungen werden nicht zugestellt<\/td><\/tr><\/tbody><\/table>\n<h2>3. Szenarien und Reaktion<\/h2>\n<table><thead><tr><th>#<\/th><th>Szenario<\/th><th>Reaktion<\/th><th>Referenz<\/th><\/tr><\/thead><tbody><tr><td>1<\/td><td>API antwortet nicht / Timeouts<\/td><td>Service-Neustart<\/td><td><code>bcm_runbook.md<\/code> §1<\/td><\/tr><tr><td>2<\/td><td>Datenverlust / fehlerhafte Migration<\/td><td>Backup-Restore<\/td><td><code>bcm_runbook.md<\/code> §2<\/td><\/tr><tr><td>3<\/td><td>Fehlerhaftes Release<\/td><td>Rollback (Git/Forgejo)<\/td><td><code>bcm_runbook.md<\/code> §3<\/td><\/tr><tr><td>4<\/td><td>Ausfall LLM-Primärprovider<\/td><td>Umschalten auf alternativen Provider (Anthropic/Mistral)<\/td><td>[ZU PRÜFEN: Failover-Konfiguration dokumentieren]<\/td><\/tr><tr><td>5<\/td><td>Totalausfall Infomaniak-Region<\/td><td>Wiederaufbau aus Export-Backup<\/td><td>siehe unten<\/td><\/tr><\/tbody><\/table>\n<h2>4. Verfügbarkeitsüberwachung (#79)<\/h2>\n<ul><li>Health-Check-Endpunkt: <code>GET /api/admin/health<\/code> (liefert 200 OK bei intaktem Betrieb).<\/li><li>[ZU PRÜFEN: Existiert ein automatisiertes Uptime-Monitoring, das den Health-Check periodisch prüft und bei Ausfall alarmiert? Falls nicht: einrichten (z. B. externer Monitor + Alert an Betrieb).]<\/li><\/ul>\n<h2>5. Wiederherstellungsziele<\/h2>\n<table><thead><tr><th>Parameter<\/th><th>Zielwert<\/th><th>Quelle<\/th><\/tr><\/thead><tbody><tr><td>RTO<\/td><td>[ZU PRÜFEN, Vorschlag ≤ 4 h]<\/td><td>mit SLA abgleichen<\/td><\/tr><tr><td>RPO<\/td><td>[ZU PRÜFEN, Vorschlag ≤ 24 h]<\/td><td>abhängig von Backup-Frequenz<\/td><\/tr><\/tbody><\/table>\n<h2>6. Geografische Trennung / Backup-Standort<\/h2>\n<blockquote><strong>Offener Punkt:<\/strong> Punkt #3 / FINMA verlangt angemessene Redundanz. Aktuell liegen Prod und Backup in der Infomaniak-Umgebung. <strong>[ZU PRÜFEN: Liegen Snapshots/Backups in einer getrennten Infomaniak-Region oder einem getrennten Rechenzentrum? Falls nicht, geografisch getrennte Backup-Ablage als Massnahme aufnehmen.]<\/strong><\/blockquote>\n<h2>7. Tests und Überprüfung<\/h2>\n<table><thead><tr><th>Test<\/th><th>Häufigkeit<\/th><th>Status<\/th><\/tr><\/thead><tbody><tr><td>Restore-Test (DB)<\/td><td>Vierteljährlich<\/td><td>siehe Dok 05 — neu einzuführen<\/td><\/tr><tr><td>Rollback-Übung<\/td><td>Halbjährlich<\/td><td>[ZU PRÜFEN]<\/td><\/tr><tr><td>LLM-Failover-Test<\/td><td>Halbjährlich<\/td><td>[ZU PRÜFEN]<\/td><\/tr><tr><td>BCP-Review (Aktualität)<\/td><td>Jährlich<\/td><td>neu<\/td><\/tr><\/tbody><\/table>\n<h2>8. Kommunikation im Notfall<\/h2>\n<table><thead><tr><th>Rolle<\/th><th>Kontakt<\/th><\/tr><\/thead><tbody><tr><td>Betrieb / DevOps (Server-Zugang)<\/td><td>Patrick Motsch — p.motsch@poweron.swiss<\/td><\/tr><tr><td>Drittdienste / Eskalation<\/td><td>Patrick Motsch — p.motsch@poweron.swiss<\/td><\/tr><tr><td>Kundeninformation (bei Vorfall)<\/td><td>siehe <code>07_Incident_Response_und_Meldewesen.md<\/code><\/td><\/tr><\/tbody><\/table>\n<h2>9. Stand der Umsetzung / Lücken<\/h2>\n<table><thead><tr><th>Thema<\/th><th>Status<\/th><th>Massnahme<\/th><\/tr><\/thead><tbody><tr><td>Automatisiertes Uptime-Monitoring<\/td><td>[ZU PRÜFEN]<\/td><td>Einrichten + Alerting<\/td><\/tr><tr><td>Geografisch getrenntes Backup<\/td><td>[ZU PRÜFEN]<\/td><td>Klären / umsetzen<\/td><\/tr><tr><td>Dokumentierte Tests<\/td><td>Offen<\/td><td>Testplan etablieren<\/td><\/tr><tr><td>LLM-Failover dokumentieren<\/td><td>Offen<\/td><td>Konfiguration festhalten<\/td><\/tr><\/tbody><\/table>", "text": "# business continuity (bcp) und disaster recovery (drp) **dokumenttyp:** konzept & plan **geltungsbereich:** porta-plattform und zugehörige infrastruktur **version:** 1.0 **status:** entwurf zur internen freigabe **owner:** geschäftsführung / betrieb **letzte aktualisierung:** 02.06.2026 **deckt ab (cacc):** 3, 79, 87 **verweist auf:** `bcm_runbook.md`, `05_backup_und_wiederherstellung.md`, `drittanbieter-inventar.md` --- ## 1. zweck dieser plan stellt die kontinuierliche leistungserbringung und die wiederherstellung der porta-plattform im katastrophen- und störfall sicher. die operativen schritte sind im `bcm_runbook.md` dokumentiert; dieses dokument liefert den organisatorischen rahmen (szenarien, rollen, ziele, tests). ## 2. kritische komponenten und abhängigkeiten aus dem drittanbieter-inventar ergeben sich die geschäftskritischen abhängigkeiten: | komponente | anbieter | auswirkung bei ausfall | |---|---|---| | vm-hosting & db | infomaniak (ch) | **totalausfall** der plattform | | primärer llm-provider | openai (usa) | ki-features (chat, agent, automation) nicht verfügbar — ausweichen auf anthropic/mistral möglich | | auth | microsoft azure ad / google oauth | login für betroffene nutzer nicht möglich | | zahlungen | stripe | neue abos/zahlungen schlagen fehl | | system-e-mail | azure communication services (ch) | einladungen/benachrichtigungen werden nicht zugestellt | ## 3. szenarien und reaktion | # | szenario | reaktion | referenz | |---|---|---|---| | 1 | api antwortet nicht / timeouts | service-neustart | `bcm_runbook.md` §1 | | 2 | datenverlust / fehlerhafte migration | backup-restore | `bcm_runbook.md` §2 | | 3 | fehlerhaftes release | rollback (git/forgejo) | `bcm_runbook.md` §3 | | 4 | ausfall llm-primärprovider | umschalten auf alternativen provider (anthropic/mistral) | [zu prüfen: failover-konfiguration dokumentieren] | | 5 | totalausfall infomaniak-region | wiederaufbau aus export-backup | siehe unten | ## 4. verfügbarkeitsüberwachung (#79) - health-check-endpunkt: `get /api/admin/health` (liefert 200 ok bei intaktem betrieb). - [zu prüfen: existiert ein automatisiertes uptime-monitoring, das den health-check periodisch prüft und bei ausfall alarmiert? falls nicht: einrichten (z. b. externer monitor + alert an betrieb).] ## 5. wiederherstellungsziele | parameter | zielwert | quelle | |---|---|---| | rto | [zu prüfen, vorschlag ≤ 4 h] | mit sla abgleichen | | rpo | [zu prüfen, vorschlag ≤ 24 h] | abhängig von backup-frequenz | ## 6. geografische trennung / backup-standort > **offener punkt:** punkt #3 / finma verlangt angemessene redundanz. aktuell liegen prod und backup in der infomaniak-umgebung. **[zu prüfen: liegen snapshots/backups in einer getrennten infomaniak-region oder einem getrennten rechenzentrum? falls nicht, geografisch getrennte backup-ablage als massnahme aufnehmen.]** ## 7. tests und überprüfung | test | häufigkeit | status | |---|---|---| | restore-test (db) | vierteljährlich | siehe dok 05 — neu einzuführen | | rollback-übung | halbjährlich | [zu prüfen] | | llm-failover-test | halbjährlich | [zu prüfen] | | bcp-review (aktualität) | jährlich | neu | ## 8. kommunikation im notfall | rolle | kontakt | |---|---| | betrieb / devops (server-zugang) | patrick motsch — p.motsch@poweron.swiss | | drittdienste / eskalation | patrick motsch — p.motsch@poweron.swiss | | kundeninformation (bei vorfall) | siehe `07_incident_response_und_meldewesen.md` | ## 9. stand der umsetzung / lücken | thema | status | massnahme | |---|---|---| | automatisiertes uptime-monitoring | [zu prüfen] | einrichten + alerting | | geografisch getrenntes backup | [zu prüfen] | klären / umsetzen | | dokumentierte tests | offen | testplan etablieren | | llm-failover dokumentieren | offen | konfiguration festhalten | ", "nextReview": "", "overdueReview": false, "zuPruefen": ["3. Szenarien und Reaktion", "4. Verfügbarkeitsüberwachung (#79)", "5. Wiederherstellungsziele", "5. Wiederherstellungsziele", "6. Geografische Trennung / Backup-Standort", "7. Tests und Überprüfung", "7. Tests und Überprüfung", "9. Stand der Umsetzung / Lücken", "9. Stand der Umsetzung / Lücken"]}, {"id": "05_betrieb/07_Incident_Response_und_Meldewesen.md", "path": "05_betrieb/07_Incident_Response_und_Meldewesen.md", "chapter": "05_betrieb", "title": "Incident Response und Meldewesen", "filename": "07_Incident_Response_und_Meldewesen.md", "meta": {}, "html": "<h1>Incident Response und Meldewesen<\/h1>\n<p><strong>Dokumenttyp:<\/strong> Prozess <strong>Geltungsbereich:<\/strong> Alle Sicherheits- und IT-Vorfälle der PORTA-Plattform <strong>Version:<\/strong> 1.0 <strong>Status:<\/strong> Entwurf zur internen Freigabe <strong>Owner:<\/strong> Betrieb / Geschäftsführung <strong>Letzte Aktualisierung:<\/strong> 02.06.2026 <strong>Deckt ab (CACC):<\/strong> 19, 20, 27, 86<\/p>\n<hr>\n<h2>1. Zweck<\/h2>\n<p>Dieser Prozess stellt eine schnelle, effektive und angemessene Reaktion auf Sicherheits- und IT-Vorfälle sicher und regelt die <strong>Meldepflichten gegenüber Kunden<\/strong> — insbesondere die für FINMA-Kunden kritische <strong>24-Stunden-Meldung<\/strong>.<\/p>\n<h2>2. Vorfallklassifizierung (#86)<\/h2>\n<table><thead><tr><th>Stufe<\/th><th>Definition<\/th><th>Beispiel<\/th><\/tr><\/thead><tbody><tr><td><strong>P1 — Kritisch<\/strong><\/td><td>Bestätigte Verletzung von Vertraulichkeit/Integrität/Verfügbarkeit kritischer Daten; erfolgreicher Cyberangriff<\/td><td>Datenabfluss, Ransomware, DB-Kompromittierung<\/td><\/tr><tr><td><strong>P2 — Hoch<\/strong><\/td><td>Teilweise erfolgreicher Angriff; wesentliche Störung ohne bestätigten Datenverlust<\/td><td>Eingedrungener, aber isolierter Angreifer; längerer Totalausfall<\/td><\/tr><tr><td><strong>P3 — Mittel<\/strong><\/td><td>Sicherheitsrelevantes Ereignis ohne unmittelbare Kundenauswirkung<\/td><td>Verdächtige Login-Versuche, einzelne Schwachstelle<\/td><\/tr><tr><td><strong>P4 — Niedrig<\/strong><\/td><td>Geringfügig, kein Kundenbezug<\/td><td>Fehlkonfiguration ohne Exposure<\/td><\/tr><\/tbody><\/table>\n<h2>3. Reaktionsablauf<\/h2>\n<pre class=\"mermaid\">flowchart TD\n    A[Vorfall erkannt] --&gt; B[Erfassen &amp; Klassifizieren P1-P4]\n    B --&gt; C{Kundendaten betroffen?}\n    C --&gt;|Ja| D[Sofortmassnahmen: Eindämmen, Beweise sichern]\n    C --&gt;|Nein| E[Beheben &amp; dokumentieren]\n    D --&gt; F[Kunde benachrichtigen - Frist 24h bei P1/P2]\n    F --&gt; G[Behebung &amp; Root-Cause-Analyse]\n    E --&gt; G\n    G --&gt; H[Abschlussbericht &amp; Lessons Learned]\n    H --&gt; I[Ticket schliessen, Massnahmen tracken]<\/pre>\n<h2>4. Meldepflichten gegenüber dem Kunden (#19, #20, #27)<\/h2>\n<table><thead><tr><th>Auslöser<\/th><th>Meldefrist<\/th><th>Empfänger<\/th><\/tr><\/thead><tbody><tr><td>Erfolgreicher/teilw. erfolgreicher Cyberangriff auf kritische Daten/Prozesse (#19)<\/td><td><strong>≤ 24 h<\/strong> nach Feststellung<\/td><td>Kunde (Sicherheitskontakt)<\/td><\/tr><tr><td>Wesentliche Verletzung Vertraulichkeit/Integrität/Verfügbarkeit (#19)<\/td><td><strong>≤ 24 h<\/strong><\/td><td>Kunde<\/td><\/tr><tr><td>Sonstige wesentliche nachteilige Entwicklungen (#20)<\/td><td>unverzüglich<\/td><td>Kunde<\/td><\/tr><tr><td>Verletzung des Berufsgeheimnisses (#27)<\/td><td>unverzüglich<\/td><td>Kunde<\/td><\/tr><\/tbody><\/table>\n<p><strong>Begründung der Frist:<\/strong> Der Kunde (FINMA-Institut) muss seinerseits die FINMA fristgerecht informieren (Art. 29 FINMAG). Die 24-h-Meldung von PowerOn ermöglicht das.<\/p>\n<h2>5. Meldeinhalt<\/h2>\n<p>Jede Meldung an den Kunden enthält, soweit bekannt: Art des Vorfalls, betroffene Datenkategorien/-mengen, betroffene Tenants/Personen, wahrscheinliche Folgen, bereits ergriffene und geplante Massnahmen, Ansprechpartner. Folgeberichte nach Vereinbarung; Abschlussbericht mit Root-Cause-Analyse innert <strong>72 h<\/strong>.<\/p>\n<h2>6. Meldewege und Kontakte<\/h2>\n<table><thead><tr><th>Funktion<\/th><th>Kontakt<\/th><\/tr><\/thead><tbody><tr><td>Interner Incident-Koordinator<\/td><td>Patrick Motsch — p.motsch@poweron.swiss<\/td><\/tr><tr><td>Kundenmeldung (Kanal)<\/td><td>Telefon + verschlüsselte E-Mail an den im Vertrag definierten Sicherheitskontakt<\/td><\/tr><tr><td>Eskalation Drittdienste<\/td><td>Patrick Motsch — p.motsch@poweron.swiss<\/td><\/tr><\/tbody><\/table>\n<h2>7. Beweissicherung (Forensik)<\/h2>\n<p>Bei P1/P2 werden vor der Bereinigung betroffener Systeme Beweise gesichert: relevante Logs exportieren (siehe <code>11_Logging_und_Monitoring.md<\/code>), Zeitstempel und handelnde Personen festhalten, Snapshots/Abbilder erstellen wo möglich.<\/p>\n<h2>8. Kleines Team — kompensierende Massnahmen<\/h2>\n<p>Eine 7×24-Besetzung ist nicht vorhanden. Kompensierend:<\/p>\n<ul><li>definierte Rufbereitschaft der Betriebsverantwortlichen,<\/li><li>automatisiertes Alerting (siehe Dok 11), das Vorfälle auch ausserhalb der Arbeitszeit meldet,<\/li><li>klare Eskalationskette.<\/li><\/ul>\n<p><strong>[ZU PRÜFEN: Rufbereitschaft und Erreichbarkeit konkret festlegen.]<\/strong><\/p>\n<h2>9. Stand der Umsetzung / Lücken<\/h2>\n<table><thead><tr><th>Thema<\/th><th>Status<\/th><th>Massnahme<\/th><\/tr><\/thead><tbody><tr><td>Dokumentierter Incident-Prozess<\/td><td>Neu (dieses Dokument)<\/td><td>Intern freigeben &amp; üben<\/td><\/tr><tr><td>Kundenmelde-Kontakte je Vertrag<\/td><td>Offen<\/td><td>Im Vertrag/AVV festhalten<\/td><\/tr><tr><td>Alerting für Out-of-hours<\/td><td>[ZU PRÜFEN]<\/td><td>siehe Dok 11<\/td><\/tr><tr><td>Incident-Log / Register<\/td><td>Neu<\/td><td>Anlegen<\/td><\/tr><\/tbody><\/table>", "text": "# incident response und meldewesen **dokumenttyp:** prozess **geltungsbereich:** alle sicherheits- und it-vorfälle der porta-plattform **version:** 1.0 **status:** entwurf zur internen freigabe **owner:** betrieb / geschäftsführung **letzte aktualisierung:** 02.06.2026 **deckt ab (cacc):** 19, 20, 27, 86 --- ## 1. zweck dieser prozess stellt eine schnelle, effektive und angemessene reaktion auf sicherheits- und it-vorfälle sicher und regelt die **meldepflichten gegenüber kunden** — insbesondere die für finma-kunden kritische **24-stunden-meldung**. ## 2. vorfallklassifizierung (#86) | stufe | definition | beispiel | |---|---|---| | **p1 — kritisch** | bestätigte verletzung von vertraulichkeit/integrität/verfügbarkeit kritischer daten; erfolgreicher cyberangriff | datenabfluss, ransomware, db-kompromittierung | | **p2 — hoch** | teilweise erfolgreicher angriff; wesentliche störung ohne bestätigten datenverlust | eingedrungener, aber isolierter angreifer; längerer totalausfall | | **p3 — mittel** | sicherheitsrelevantes ereignis ohne unmittelbare kundenauswirkung | verdächtige login-versuche, einzelne schwachstelle | | **p4 — niedrig** | geringfügig, kein kundenbezug | fehlkonfiguration ohne exposure | ## 3. reaktionsablauf ```mermaid flowchart td a[vorfall erkannt] --> b[erfassen & klassifizieren p1-p4] b --> c{kundendaten betroffen?} c -->|ja| d[sofortmassnahmen: eindämmen, beweise sichern] c -->|nein| e[beheben & dokumentieren] d --> f[kunde benachrichtigen - frist 24h bei p1/p2] f --> g[behebung & root-cause-analyse] e --> g g --> h[abschlussbericht & lessons learned] h --> i[ticket schliessen, massnahmen tracken] ``` ## 4. meldepflichten gegenüber dem kunden (#19, #20, #27) | auslöser | meldefrist | empfänger | |---|---|---| | erfolgreicher/teilw. erfolgreicher cyberangriff auf kritische daten/prozesse (#19) | **≤ 24 h** nach feststellung | kunde (sicherheitskontakt) | | wesentliche verletzung vertraulichkeit/integrität/verfügbarkeit (#19) | **≤ 24 h** | kunde | | sonstige wesentliche nachteilige entwicklungen (#20) | unverzüglich | kunde | | verletzung des berufsgeheimnisses (#27) | unverzüglich | kunde | **begründung der frist:** der kunde (finma-institut) muss seinerseits die finma fristgerecht informieren (art. 29 finmag). die 24-h-meldung von poweron ermöglicht das. ## 5. meldeinhalt jede meldung an den kunden enthält, soweit bekannt: art des vorfalls, betroffene datenkategorien/-mengen, betroffene tenants/personen, wahrscheinliche folgen, bereits ergriffene und geplante massnahmen, ansprechpartner. folgeberichte nach vereinbarung; abschlussbericht mit root-cause-analyse innert **72 h**. ## 6. meldewege und kontakte | funktion | kontakt | |---|---| | interner incident-koordinator | patrick motsch — p.motsch@poweron.swiss | | kundenmeldung (kanal) | telefon + verschlüsselte e-mail an den im vertrag definierten sicherheitskontakt | | eskalation drittdienste | patrick motsch — p.motsch@poweron.swiss | ## 7. beweissicherung (forensik) bei p1/p2 werden vor der bereinigung betroffener systeme beweise gesichert: relevante logs exportieren (siehe `11_logging_und_monitoring.md`), zeitstempel und handelnde personen festhalten, snapshots/abbilder erstellen wo möglich. ## 8. kleines team — kompensierende massnahmen eine 7×24-besetzung ist nicht vorhanden. kompensierend: - definierte rufbereitschaft der betriebsverantwortlichen, - automatisiertes alerting (siehe dok 11), das vorfälle auch ausserhalb der arbeitszeit meldet, - klare eskalationskette. **[zu prüfen: rufbereitschaft und erreichbarkeit konkret festlegen.]** ## 9. stand der umsetzung / lücken | thema | status | massnahme | |---|---|---| | dokumentierter incident-prozess | neu (dieses dokument) | intern freigeben & üben | | kundenmelde-kontakte je vertrag | offen | im vertrag/avv festhalten | | alerting für out-of-hours | [zu prüfen] | siehe dok 11 | | incident-log / register | neu | anlegen | ", "nextReview": "", "overdueReview": false, "zuPruefen": ["8. Kleines Team — kompensierende Massnahmen", "9. Stand der Umsetzung / Lücken"]}, {"id": "05_betrieb/08_Change_Management.md", "path": "05_betrieb/08_Change_Management.md", "chapter": "05_betrieb", "title": "Change Management", "filename": "08_Change_Management.md", "meta": {}, "html": "<h1>Change Management<\/h1>\n<p><strong>Dokumenttyp:<\/strong> Prozess <strong>Geltungsbereich:<\/strong> Alle Änderungen an Produktivsystemen der PORTA-Plattform <strong>Version:<\/strong> 1.0 <strong>Status:<\/strong> Entwurf zur internen Freigabe <strong>Owner:<\/strong> Entwicklung / Release-Verantwortlicher <strong>Letzte Aktualisierung:<\/strong> 02.06.2026 <strong>Deckt ab (CACC):<\/strong> 81, 82, 83 <strong>Verweist auf:<\/strong> <code>feature_release_bugfix.md<\/code><\/p>\n<hr>\n<h2>1. Bestehender Prozess (Basis)<\/h2>\n<p>Der Kern des Change-Managements ist bereits in <code>feature_release_bugfix.md<\/code> dokumentiert und auditkonform aufgebaut: zentrale Erfassung, Priorisierung, Tech-Workshop, Feature-/Bugfix-Branches, Code-Review (Vier-Augen-Prinzip), Staging-Verifikation gegen Akzeptanzkriterien, Release in Produktion, versionierte Release Notes und CHANGELOG. Deployment erfolgt automatisiert über Forgejo-CI/CD.<\/p>\n<p>Dieses Dokument ergänzt die für das CACC fehlenden Aspekte (#82 Frozen Zones, #83 Konfigurationskonformität) und fasst die Risikobewertung/Genehmigung formal zusammen (#81).<\/p>\n<h2>2. Change-Kategorien und Genehmigung (#81)<\/h2>\n<table><thead><tr><th>Kategorie<\/th><th>Beispiel<\/th><th>Risikobewertung<\/th><th>Genehmigung<\/th><\/tr><\/thead><tbody><tr><td><strong>Standard<\/strong><\/td><td>Routine-Bugfix, kleinere Anpassung<\/td><td>gering<\/td><td>Code-Review (2. Entwickler)<\/td><\/tr><tr><td><strong>Normal<\/strong><\/td><td>Neues Feature, API-Änderung<\/td><td>mittel<\/td><td>Tech-Workshop + Review + Staging-Verifikation<\/td><\/tr><tr><td><strong>Major<\/strong><\/td><td>Neue Version, DB-Migration, Architekturänderung<\/td><td>hoch<\/td><td>Tech-Workshop + Review + Staging + Backup vor Deployment + explizite Release-Freigabe<\/td><\/tr><tr><td><strong>Emergency<\/strong><\/td><td>Kritischer Hotfix / Sicherheitspatch<\/td><td>situativ<\/td><td>Verkürzt: Fix + Review + sofortiges Deployment, Nachdokumentation innert 24 h<\/td><\/tr><\/tbody><\/table>\n<p>Jede Major-Änderung erfordert vor dem Deployment einen Export-Backup (siehe <code>datenbank-handling.md<\/code> / Dok 05).<\/p>\n<h2>3. Frozen Zones und Maintenance Windows (#82)<\/h2>\n<p>PowerOn ermöglicht kundenseitig definierte <strong>Frozen Zones<\/strong> (Zeiträume ohne Änderungen, z. B. Jahresabschluss einer Bank) und <strong>Maintenance Windows<\/strong>.<\/p>\n<table><thead><tr><th>Element<\/th><th>Regelung<\/th><\/tr><\/thead><tbody><tr><td>Frozen Zone<\/td><td>Auf Kundenwunsch im Vertrag/SLA definiert; in diesen Zeiträumen keine nicht-kritischen Deployments<\/td><\/tr><tr><td>Maintenance Window<\/td><td>Geplante Wartung wird mind. 5 Werktage im Voraus angekündigt<\/td><\/tr><tr><td>Notfalländerung in Frozen Zone<\/td><td>Nur bei kritischen Sicherheitsvorfällen, mit Kundeninformation<\/td><\/tr><\/tbody><\/table>\n<p><strong>[ZU PRÜFEN: Werden Frozen Zones aktuell technisch/organisatorisch berücksichtigt? Falls neu, als Prozessvorgabe etablieren.]<\/strong><\/p>\n<h2>4. Standardisierte und sichere Konfiguration (#83)<\/h2>\n<table><thead><tr><th>Element<\/th><th>Regelung<\/th><th>Status<\/th><\/tr><\/thead><tbody><tr><td>Konfigurationsdateien<\/td><td><code>.env<\/code> pro Umgebung (<code>env-prod.env<\/code>, <code>env-int.env<\/code>), getrennt, nicht im Git<\/td><td>Umgesetzt<\/td><\/tr><tr><td>Infrastruktur als Code<\/td><td>[ZU PRÜFEN: Werden Server-Konfigurationen versioniert/reproduzierbar gehalten?]<\/td><td>[ZU PRÜFEN]<\/td><\/tr><tr><td>Konformitätskontrolle<\/td><td>Regelmässige Prüfung, dass Produktivkonfiguration dem Soll entspricht<\/td><td>[ZU PRÜFEN: etablieren]<\/td><\/tr><tr><td>Härtung<\/td><td>siehe <code>12_Netzwerk_und_Infrastruktursicherheit.md<\/code><\/td><td><\/td><\/tr><\/tbody><\/table>\n<h2>5. Nachvollziehbarkeit (Auditnachweis)<\/h2>\n<p>Jede Änderung ist nachvollziehbar über: Issue/Ticket, Feature-/Bugfix-Branch, Pull Request mit Review, CI/CD-Pipeline-Lauf in Forgejo, Commit-Historie, CHANGELOG-Eintrag. Rollbacks sind über Git/Forgejo dokumentiert (<code>bcm_runbook.md<\/code> §3).<\/p>\n<h2>6. Stand der Umsetzung / Lücken<\/h2>\n<table><thead><tr><th>Thema<\/th><th>Status<\/th><th>Massnahme<\/th><\/tr><\/thead><tbody><tr><td>Change-Kategorisierung formalisiert<\/td><td>Neu<\/td><td>Übernehmen<\/td><\/tr><tr><td>Frozen Zones<\/td><td>[ZU PRÜFEN]<\/td><td>Prozess verankern<\/td><\/tr><tr><td>Konfigurations-Konformitätsprüfung<\/td><td>[ZU PRÜFEN]<\/td><td>Etablieren<\/td><\/tr><\/tbody><\/table>", "text": "# change management **dokumenttyp:** prozess **geltungsbereich:** alle änderungen an produktivsystemen der porta-plattform **version:** 1.0 **status:** entwurf zur internen freigabe **owner:** entwicklung / release-verantwortlicher **letzte aktualisierung:** 02.06.2026 **deckt ab (cacc):** 81, 82, 83 **verweist auf:** `feature_release_bugfix.md` --- ## 1. bestehender prozess (basis) der kern des change-managements ist bereits in `feature_release_bugfix.md` dokumentiert und auditkonform aufgebaut: zentrale erfassung, priorisierung, tech-workshop, feature-/bugfix-branches, code-review (vier-augen-prinzip), staging-verifikation gegen akzeptanzkriterien, release in produktion, versionierte release notes und changelog. deployment erfolgt automatisiert über forgejo-ci/cd. dieses dokument ergänzt die für das cacc fehlenden aspekte (#82 frozen zones, #83 konfigurationskonformität) und fasst die risikobewertung/genehmigung formal zusammen (#81). ## 2. change-kategorien und genehmigung (#81) | kategorie | beispiel | risikobewertung | genehmigung | |---|---|---|---| | **standard** | routine-bugfix, kleinere anpassung | gering | code-review (2. entwickler) | | **normal** | neues feature, api-änderung | mittel | tech-workshop + review + staging-verifikation | | **major** | neue version, db-migration, architekturänderung | hoch | tech-workshop + review + staging + backup vor deployment + explizite release-freigabe | | **emergency** | kritischer hotfix / sicherheitspatch | situativ | verkürzt: fix + review + sofortiges deployment, nachdokumentation innert 24 h | jede major-änderung erfordert vor dem deployment einen export-backup (siehe `datenbank-handling.md` / dok 05). ## 3. frozen zones und maintenance windows (#82) poweron ermöglicht kundenseitig definierte **frozen zones** (zeiträume ohne änderungen, z. b. jahresabschluss einer bank) und **maintenance windows**. | element | regelung | |---|---| | frozen zone | auf kundenwunsch im vertrag/sla definiert; in diesen zeiträumen keine nicht-kritischen deployments | | maintenance window | geplante wartung wird mind. 5 werktage im voraus angekündigt | | notfalländerung in frozen zone | nur bei kritischen sicherheitsvorfällen, mit kundeninformation | **[zu prüfen: werden frozen zones aktuell technisch/organisatorisch berücksichtigt? falls neu, als prozessvorgabe etablieren.]** ## 4. standardisierte und sichere konfiguration (#83) | element | regelung | status | |---|---|---| | konfigurationsdateien | `.env` pro umgebung (`env-prod.env`, `env-int.env`), getrennt, nicht im git | umgesetzt | | infrastruktur als code | [zu prüfen: werden server-konfigurationen versioniert/reproduzierbar gehalten?] | [zu prüfen] | | konformitätskontrolle | regelmässige prüfung, dass produktivkonfiguration dem soll entspricht | [zu prüfen: etablieren] | | härtung | siehe `12_netzwerk_und_infrastruktursicherheit.md` | | ## 5. nachvollziehbarkeit (auditnachweis) jede änderung ist nachvollziehbar über: issue/ticket, feature-/bugfix-branch, pull request mit review, ci/cd-pipeline-lauf in forgejo, commit-historie, changelog-eintrag. rollbacks sind über git/forgejo dokumentiert (`bcm_runbook.md` §3). ## 6. stand der umsetzung / lücken | thema | status | massnahme | |---|---|---| | change-kategorisierung formalisiert | neu | übernehmen | | frozen zones | [zu prüfen] | prozess verankern | | konfigurations-konformitätsprüfung | [zu prüfen] | etablieren | ", "nextReview": "", "overdueReview": false, "zuPruefen": ["3. Frozen Zones und Maintenance Windows (#82)", "4. Standardisierte und sichere Konfiguration (#83)", "4. Standardisierte und sichere Konfiguration (#83)", "6. Stand der Umsetzung / Lücken", "6. Stand der Umsetzung / Lücken"]}, {"id": "05_betrieb/09_Patch_Management.md", "path": "05_betrieb/09_Patch_Management.md", "chapter": "05_betrieb", "title": "Patch Management", "filename": "09_Patch_Management.md", "meta": {}, "html": "<h1>Patch Management<\/h1>\n<p><strong>Dokumenttyp:<\/strong> Prozess <strong>Geltungsbereich:<\/strong> Betriebssystem, Laufzeitumgebung, Abhängigkeiten der PORTA-Plattform <strong>Version:<\/strong> 1.0 <strong>Status:<\/strong> Entwurf zur internen Freigabe <strong>Owner:<\/strong> Betrieb / DevOps <strong>Letzte Aktualisierung:<\/strong> 02.06.2026 <strong>Deckt ab (CACC):<\/strong> 78<\/p>\n<hr>\n<h2>1. Geltungsbereich<\/h2>\n<table><thead><tr><th>Ebene<\/th><th>Beispiel<\/th><th>Patch-Verantwortung<\/th><\/tr><\/thead><tbody><tr><td>Managed Infrastruktur<\/td><td>VM-Host, PostgreSQL (Infomaniak)<\/td><td>Infomaniak (Managed) + Betrieb<\/td><\/tr><tr><td>Betriebssystem (Ubuntu)<\/td><td>Sicherheitsupdates<\/td><td>Betrieb<\/td><\/tr><tr><td>Laufzeit / Python<\/td><td><code>requirements.txt<\/code>-Abhängigkeiten<\/td><td>Entwicklung/Betrieb<\/td><\/tr><tr><td>Anwendungsabhängigkeiten<\/td><td>Bibliotheken (z. B. LangChain, SDKs)<\/td><td>Entwicklung<\/td><\/tr><\/tbody><\/table>\n<h2>2. Maximale Fristen (#78)<\/h2>\n<p>Punkt #78 verlangt definierte Höchstdauern bis zum Einspielen von Patches:<\/p>\n<table><thead><tr><th>Kritikalität<\/th><th>Beschreibung<\/th><th>Maximale Frist<\/th><\/tr><\/thead><tbody><tr><td>Kritisch<\/td><td>Aktiv ausgenutzte / kritische Schwachstelle (CVSS ≥ 9)<\/td><td><strong>48 Stunden<\/strong><\/td><\/tr><tr><td>Hoch<\/td><td>CVSS 7,0–8,9<\/td><td>7 Tage<\/td><\/tr><tr><td>Mittel<\/td><td>CVSS 4,0–6,9<\/td><td>30 Tage<\/td><\/tr><tr><td>Niedrig<\/td><td>CVSS &lt; 4,0<\/td><td>nächstes Wartungsfenster<\/td><\/tr><\/tbody><\/table>\n<h2>3. Ablauf<\/h2>\n<ol><li><strong>Erkennung:<\/strong> Sicherheitsmeldungen verfolgen (Ubuntu Security, GitHub Dependabot/Advisories, Provider-Statusseiten). <strong>[ZU PRÜFEN: Wird Dependabot o. ä. in Forgejo/Repo genutzt?]<\/strong><\/li><li><strong>Bewertung:<\/strong> Kritikalität einstufen, betroffene Systeme bestimmen.<\/li><li><strong>Test:<\/strong> Patch auf INT-Umgebung (<code>api-int.poweron.swiss<\/code>) einspielen und verifizieren.<\/li><li><strong>Freigabe &amp; Deployment:<\/strong> Über regulären Change-Prozess (Dok 08); bei kritischen Patches als Emergency-Change.<\/li><li><strong>Dokumentation:<\/strong> Patch, Datum, Version im CHANGELOG/Ticket festhalten.<\/li><\/ol>\n<h2>4. OS- und Abhängigkeits-Updates (technisch)<\/h2>\n<p>Abhängigkeiten werden beim Deployment via <code>pip install -r requirements.txt<\/code> aktualisiert (siehe <code>bcm_runbook.md<\/code>). OS-Patches: <code>apt<\/code>-Updates auf den VMs via <code>unattended-upgrades<\/code> (aktiv auf allen VMs). Konfiguration: Sicherheitspatches werden automatisch installiert, aber Services werden <strong>nicht<\/strong> automatisch neugestartet (<code>needrestart = 'l'<\/code>). Der Restart erfolgt kontrolliert beim naechsten Deployment oder manuell bei kritischen Patches.<\/p>\n<h2>5. Stand der Umsetzung / Lücken<\/h2>\n<table><thead><tr><th>Thema<\/th><th>Status<\/th><th>Massnahme<\/th><\/tr><\/thead><tbody><tr><td>Definierte Patch-Fristen<\/td><td>Neu (dieses Dokument)<\/td><td>Übernehmen<\/td><\/tr><tr><td>Automatisches Vuln-Tracking (Dependabot)<\/td><td>[ZU PRÜFEN]<\/td><td>Aktivieren<\/td><\/tr><tr><td>Unattended-Upgrades OS<\/td><td>✅ Aktiv<\/td><td>Patches auto-installiert, Service-Restart manuell (<code>needrestart='l'<\/code>)<\/td><\/tr><tr><td>Patch-Protokollierung<\/td><td>[ZU PRÜFEN]<\/td><td>Im CHANGELOG mitführen<\/td><\/tr><\/tbody><\/table>", "text": "# patch management **dokumenttyp:** prozess **geltungsbereich:** betriebssystem, laufzeitumgebung, abhängigkeiten der porta-plattform **version:** 1.0 **status:** entwurf zur internen freigabe **owner:** betrieb / devops **letzte aktualisierung:** 02.06.2026 **deckt ab (cacc):** 78 --- ## 1. geltungsbereich | ebene | beispiel | patch-verantwortung | |---|---|---| | managed infrastruktur | vm-host, postgresql (infomaniak) | infomaniak (managed) + betrieb | | betriebssystem (ubuntu) | sicherheitsupdates | betrieb | | laufzeit / python | `requirements.txt`-abhängigkeiten | entwicklung/betrieb | | anwendungsabhängigkeiten | bibliotheken (z. b. langchain, sdks) | entwicklung | ## 2. maximale fristen (#78) punkt #78 verlangt definierte höchstdauern bis zum einspielen von patches: | kritikalität | beschreibung | maximale frist | |---|---|---| | kritisch | aktiv ausgenutzte / kritische schwachstelle (cvss ≥ 9) | **48 stunden** | | hoch | cvss 7,0–8,9 | 7 tage | | mittel | cvss 4,0–6,9 | 30 tage | | niedrig | cvss < 4,0 | nächstes wartungsfenster | ## 3. ablauf 1. **erkennung:** sicherheitsmeldungen verfolgen (ubuntu security, github dependabot/advisories, provider-statusseiten). **[zu prüfen: wird dependabot o. ä. in forgejo/repo genutzt?]** 2. **bewertung:** kritikalität einstufen, betroffene systeme bestimmen. 3. **test:** patch auf int-umgebung (`api-int.poweron.swiss`) einspielen und verifizieren. 4. **freigabe & deployment:** über regulären change-prozess (dok 08); bei kritischen patches als emergency-change. 5. **dokumentation:** patch, datum, version im changelog/ticket festhalten. ## 4. os- und abhängigkeits-updates (technisch) abhängigkeiten werden beim deployment via `pip install -r requirements.txt` aktualisiert (siehe `bcm_runbook.md`). os-patches: `apt`-updates auf den vms via `unattended-upgrades` (aktiv auf allen vms). konfiguration: sicherheitspatches werden automatisch installiert, aber services werden **nicht** automatisch neugestartet (`needrestart = 'l'`). der restart erfolgt kontrolliert beim naechsten deployment oder manuell bei kritischen patches. ## 5. stand der umsetzung / lücken | thema | status | massnahme | |---|---|---| | definierte patch-fristen | neu (dieses dokument) | übernehmen | | automatisches vuln-tracking (dependabot) | [zu prüfen] | aktivieren | | unattended-upgrades os | ✅ aktiv | patches auto-installiert, service-restart manuell (`needrestart='l'`) | | patch-protokollierung | [zu prüfen] | im changelog mitführen | ", "nextReview": "", "overdueReview": false, "zuPruefen": ["3. Ablauf", "5. Stand der Umsetzung / Lücken", "5. Stand der Umsetzung / Lücken"]}, {"id": "05_betrieb/10_Schwachstellenmanagement.md", "path": "05_betrieb/10_Schwachstellenmanagement.md", "chapter": "05_betrieb", "title": "Schwachstellenmanagement", "filename": "10_Schwachstellenmanagement.md", "meta": {}, "html": "<h1>Schwachstellenmanagement<\/h1>\n<p><strong>Dokumenttyp:<\/strong> Richtlinie &amp; Prozess <strong>Geltungsbereich:<\/strong> Alle für Kunden relevanten Systeme der PORTA-Plattform <strong>Version:<\/strong> 1.0 <strong>Status:<\/strong> Entwurf zur internen Freigabe <strong>Owner:<\/strong> Betrieb / Entwicklung <strong>Letzte Aktualisierung:<\/strong> 02.06.2026 <strong>Deckt ab (CACC):<\/strong> 54, 59, 63, 84<\/p>\n<hr>\n<h2>1. Zweck<\/h2>\n<p>Kontinuierliche Identifizierung, Bewertung, Behandlung und Nachverfolgung von Schwachstellen in den für Kunden relevanten Systemen.<\/p>\n<h2>2. Identifizierungsmethoden (#63)<\/h2>\n<table><thead><tr><th>Methode<\/th><th>Häufigkeit<\/th><th>Status<\/th><\/tr><\/thead><tbody><tr><td>Automatisiertes Dependency-Scanning (Bibliotheken)<\/td><td>kontinuierlich<\/td><td>[ZU PRÜFEN: Dependabot/Scanner aktiv?]<\/td><\/tr><tr><td>Schwachstellen-Scan der Server/Endpunkte<\/td><td>[ZU PRÜFEN, Vorschlag: quartalsweise]<\/td><td>[ZU PRÜFEN]<\/td><\/tr><tr><td>Penetrationstest durch unabhängige Dritte<\/td><td>jährlich<\/td><td><strong>[ZU PRÜFEN: bisher durchgeführt? Sonst erstmalig planen]<\/strong><\/td><\/tr><tr><td>Interne Code-Reviews<\/td><td>pro Change<\/td><td>Umgesetzt (siehe Dok 08)<\/td><\/tr><\/tbody><\/table>\n<h2>3. Bewertung und Behandlung (#84)<\/h2>\n<ol><li><strong>Dokumentation:<\/strong> Jede Schwachstelle wird mit Quelle, betroffenem System und CVSS-Score erfasst.<\/li><li><strong>Bewertung:<\/strong> Einstufung nach Kritikalität.<\/li><li><strong>Massnahme:<\/strong> Behebung über Patch- (Dok 09) bzw. Change-Prozess (Dok 08), nach den dort definierten Fristen.<\/li><li><strong>Nachverfolgung:<\/strong> Offene Schwachstellen werden bis zur Behebung in einem Register getrackt.<\/li><li><strong>Reporting:<\/strong> Status mindestens quartalsweise intern; auf Anfrage für berechtigte Kunden/Prüfer einsehbar.<\/li><\/ol>\n<h2>4. Unabhängige Audits (#54, #59)<\/h2>\n<p>Punkt #54/#59 verlangen regelmässige unabhängige Audits und die Bereitstellung <strong>vollständiger Auditberichte<\/strong> (nicht nur Zertifikate).<\/p>\n<ul><li><strong>Aktuell:<\/strong> [ZU PRÜFEN: Es liegen bisher keine externen Audit-/Pentest-Berichte vor.]<\/li><li><strong>Massnahme:<\/strong> Jährlichen externen Penetrationstest beauftragen; Bericht ablegen und berechtigten Kunden zugänglich machen. Behobene Schwachstellen dokumentieren.<\/li><\/ul>\n<h2>5. Schwachstellen-Register (Vorlage)<\/h2>\n<table><thead><tr><th>ID<\/th><th>Datum<\/th><th>System<\/th><th>Beschreibung<\/th><th>CVSS<\/th><th>Status<\/th><th>Behoben am<\/th><\/tr><\/thead><tbody><tr><td><\/td><td><\/td><td><\/td><td><\/td><td><\/td><td><\/td><td><\/td><\/tr><\/tbody><\/table>\n<h2>6. Stand der Umsetzung / Lücken<\/h2>\n<table><thead><tr><th>Thema<\/th><th>Status<\/th><th>Massnahme<\/th><\/tr><\/thead><tbody><tr><td>Externer Pentest<\/td><td>[ZU PRÜFEN / fehlt]<\/td><td>Jährlich beauftragen<\/td><\/tr><tr><td>Dependency-Scanning<\/td><td>[ZU PRÜFEN]<\/td><td>Aktivieren<\/td><\/tr><tr><td>Schwachstellen-Register<\/td><td>Neu<\/td><td>Anlegen<\/td><\/tr><\/tbody><\/table>", "text": "# schwachstellenmanagement **dokumenttyp:** richtlinie & prozess **geltungsbereich:** alle für kunden relevanten systeme der porta-plattform **version:** 1.0 **status:** entwurf zur internen freigabe **owner:** betrieb / entwicklung **letzte aktualisierung:** 02.06.2026 **deckt ab (cacc):** 54, 59, 63, 84 --- ## 1. zweck kontinuierliche identifizierung, bewertung, behandlung und nachverfolgung von schwachstellen in den für kunden relevanten systemen. ## 2. identifizierungsmethoden (#63) | methode | häufigkeit | status | |---|---|---| | automatisiertes dependency-scanning (bibliotheken) | kontinuierlich | [zu prüfen: dependabot/scanner aktiv?] | | schwachstellen-scan der server/endpunkte | [zu prüfen, vorschlag: quartalsweise] | [zu prüfen] | | penetrationstest durch unabhängige dritte | jährlich | **[zu prüfen: bisher durchgeführt? sonst erstmalig planen]** | | interne code-reviews | pro change | umgesetzt (siehe dok 08) | ## 3. bewertung und behandlung (#84) 1. **dokumentation:** jede schwachstelle wird mit quelle, betroffenem system und cvss-score erfasst. 2. **bewertung:** einstufung nach kritikalität. 3. **massnahme:** behebung über patch- (dok 09) bzw. change-prozess (dok 08), nach den dort definierten fristen. 4. **nachverfolgung:** offene schwachstellen werden bis zur behebung in einem register getrackt. 5. **reporting:** status mindestens quartalsweise intern; auf anfrage für berechtigte kunden/prüfer einsehbar. ## 4. unabhängige audits (#54, #59) punkt #54/#59 verlangen regelmässige unabhängige audits und die bereitstellung **vollständiger auditberichte** (nicht nur zertifikate). - **aktuell:** [zu prüfen: es liegen bisher keine externen audit-/pentest-berichte vor.] - **massnahme:** jährlichen externen penetrationstest beauftragen; bericht ablegen und berechtigten kunden zugänglich machen. behobene schwachstellen dokumentieren. ## 5. schwachstellen-register (vorlage) | id | datum | system | beschreibung | cvss | status | behoben am | |---|---|---|---|---|---|---| | | | | | | | | ## 6. stand der umsetzung / lücken | thema | status | massnahme | |---|---|---| | externer pentest | [zu prüfen / fehlt] | jährlich beauftragen | | dependency-scanning | [zu prüfen] | aktivieren | | schwachstellen-register | neu | anlegen | ", "nextReview": "", "overdueReview": false, "zuPruefen": ["2. Identifizierungsmethoden (#63)", "2. Identifizierungsmethoden (#63)", "2. Identifizierungsmethoden (#63)", "4. Unabhängige Audits (#54, #59)", "6. Stand der Umsetzung / Lücken", "6. Stand der Umsetzung / Lücken"]}, {"id": "05_betrieb/11_Logging_und_Monitoring.md", "path": "05_betrieb/11_Logging_und_Monitoring.md", "chapter": "05_betrieb", "title": "Logging und Monitoring (Sicherheitsprotokollierung)", "filename": "11_Logging_und_Monitoring.md", "meta": {}, "html": "<h1>Logging und Monitoring (Sicherheitsprotokollierung)<\/h1>\n<p><strong>Dokumenttyp:<\/strong> Konzept <strong>Geltungsbereich:<\/strong> Protokollierung und Überwachung der PORTA-Plattform <strong>Version:<\/strong> 1.0 <strong>Status:<\/strong> Entwurf zur internen Freigabe <strong>Owner:<\/strong> Betrieb / DevOps <strong>Letzte Aktualisierung:<\/strong> 02.06.2026 <strong>Deckt ab (CACC):<\/strong> 88, 89, 90, 91, 92, 93, 94<\/p>\n<hr>\n<h2>1. Vorhandene Protokolle<\/h2>\n<table><thead><tr><th>Protokoll<\/th><th>Inhalt<\/th><th>Ort<\/th><\/tr><\/thead><tbody><tr><td>Anwendungslog<\/td><td>App-Ereignisse<\/td><td><code>/srv/gateway/shared/logs/log_app_YYYYMMDD.log<\/code><\/td><\/tr><tr><td>Systemlog<\/td><td>Service <code>gateway<\/code><\/td><td><code>journalctl -u gateway<\/code><\/td><\/tr><tr><td>AuthEvent (DB)<\/td><td>Login-Protokoll<\/td><td>DB-Tabelle (vom Export ausgeschlossen)<\/td><\/tr><tr><td>Export/Import-Log<\/td><td>DB-Operationen durch SysAdmins<\/td><td>serverseitig (siehe <code>datenbank-handling.md<\/code> §6)<\/td><\/tr><tr><td>CI/CD<\/td><td>Deployments<\/td><td>Forgejo<\/td><\/tr><\/tbody><\/table>\n<h2>2. Protokollierung des Zugriffs auf Kundendaten (#88, #94)<\/h2>\n<ul><li>Zugriffe auf Kundendaten im Klartext (z. B. DB-Export/Import) werden serverseitig geloggt.<\/li><li><strong>Anforderung #94:<\/strong> Eindeutige Identifizierung von Benutzerzugriffen auf Tenant-Ebene für forensische Analyse.<\/li><li><strong>Offener Punkt:<\/strong> Da der SSH-Zugang über den geteilten <code>ubuntu<\/code>-User läuft, ist die Personenzuordnung auf Server-Ebene aktuell eingeschränkt. → personalisierte Zugänge oder Sitzungsprotokollierung erforderlich (siehe Dok 02). <strong>[ZU PRÜFEN/UMZUSETZEN]<\/strong><\/li><\/ul>\n<h2>3. Kundenzugang zu Protokollen (#88)<\/h2>\n<p>Punkt #88 verlangt, dass Protokolle dem Kunden jederzeit (ggf. in Echtzeit) zur Verfügung stehen.<\/p>\n<p><strong>[ZU PRÜFEN: Können Kunden ihre Tenant-bezogenen Logs einsehen/exportieren? Falls nicht vorhanden, als Massnahme aufnehmen — z. B. Log-Export pro Mandant oder API.]<\/strong><\/p>\n<h2>4. Automatische Analyse und Ereigniserkennung (#89, #90)<\/h2>\n<table><thead><tr><th>Element<\/th><th>Status<\/th><\/tr><\/thead><tbody><tr><td>Etablierter Logging-/Monitoring-Prozess<\/td><td>[ZU PRÜFEN]<\/td><\/tr><tr><td>Automatische, proaktive Loganalyse (SIEM/Alerting)<\/td><td><strong>Offen<\/strong> — kleines Team, kein SIEM<\/td><\/tr><tr><td>Anomalie-/Schwellwert-Alerting<\/td><td>[ZU PRÜFEN]<\/td><\/tr><\/tbody><\/table>\n<p><strong>Kompensierende Massnahme (kleines Team):<\/strong> Statt eines vollwertigen SIEM ein leichtgewichtiges, automatisiertes Alerting (z. B. Log-Monitor, der bei definierten Mustern — fehlgeschlagene Logins, Fehlerraten, Health-Check-Ausfall — eine Benachrichtigung an die Rufbereitschaft sendet). <strong>[ZU PRÜFEN/EINFÜHREN]<\/strong><\/p>\n<h2>5. Schutz der Protokolldaten (#91)<\/h2>\n<table><thead><tr><th>Anforderung<\/th><th>Status / Massnahme<\/th><\/tr><\/thead><tbody><tr><td>Schutz vor unbefugtem Zugriff<\/td><td>Logs auf Server, nur über privilegierten Zugang erreichbar<\/td><\/tr><tr><td>Schutz vor Veränderung/Löschung (Integrität)<\/td><td><strong>Offen<\/strong> — Logs aktuell auf demselben Server, kein Write-Once. <strong>Massnahme:<\/strong> Logs an einen getrennten, append-only/write-once Speicher weiterleiten<\/td><\/tr><tr><td>Aufbewahrungsdauer<\/td><td>[ZU PRÜFEN, Vorschlag: mind. 12 Monate, sicherheitsrelevante Zugriffslogs 3 Jahre]<\/td><\/tr><\/tbody><\/table>\n<h2>6. 7×24-Analyse (#92) und SOC-Schnittstellen (#93)<\/h2>\n<ul><li><strong>#92 (7×24-Analyse):<\/strong> Mit 2–5 Personen nicht als Vollbetrieb leistbar. Kompensierend: automatisiertes Alerting + Rufbereitschaft (siehe Dok 07).<\/li><li><strong>#93 (Schnittstellen zum Kunden-SOC):<\/strong> [ZU PRÜFEN: Kann Log-Streaming/Export an ein Kunden-SOC bereitgestellt werden (Syslog, API)? Falls nicht, als optionales Angebot dokumentieren.]<\/li><\/ul>\n<h2>7. Stand der Umsetzung / Lücken<\/h2>\n<table><thead><tr><th>Thema<\/th><th>Status<\/th><th>Massnahme<\/th><\/tr><\/thead><tbody><tr><td>Personenbezogene Nachvollziehbarkeit (Tenant-Ebene)<\/td><td>Teilweise<\/td><td>personalisierte Zugänge / Sitzungslog<\/td><\/tr><tr><td>Log-Integritätsschutz<\/td><td>Offen<\/td><td>append-only/getrennter Speicher<\/td><\/tr><tr><td>Automatisches Alerting<\/td><td>Offen<\/td><td>einführen<\/td><\/tr><tr><td>Aufbewahrungsdauer definiert<\/td><td>Offen<\/td><td>festlegen<\/td><\/tr><tr><td>Kundenzugang zu Logs<\/td><td>[ZU PRÜFEN]<\/td><td>klären<\/td><\/tr><\/tbody><\/table>", "text": "# logging und monitoring (sicherheitsprotokollierung) **dokumenttyp:** konzept **geltungsbereich:** protokollierung und überwachung der porta-plattform **version:** 1.0 **status:** entwurf zur internen freigabe **owner:** betrieb / devops **letzte aktualisierung:** 02.06.2026 **deckt ab (cacc):** 88, 89, 90, 91, 92, 93, 94 --- ## 1. vorhandene protokolle | protokoll | inhalt | ort | |---|---|---| | anwendungslog | app-ereignisse | `/srv/gateway/shared/logs/log_app_yyyymmdd.log` | | systemlog | service `gateway` | `journalctl -u gateway` | | authevent (db) | login-protokoll | db-tabelle (vom export ausgeschlossen) | | export/import-log | db-operationen durch sysadmins | serverseitig (siehe `datenbank-handling.md` §6) | | ci/cd | deployments | forgejo | ## 2. protokollierung des zugriffs auf kundendaten (#88, #94) - zugriffe auf kundendaten im klartext (z. b. db-export/import) werden serverseitig geloggt. - **anforderung #94:** eindeutige identifizierung von benutzerzugriffen auf tenant-ebene für forensische analyse. - **offener punkt:** da der ssh-zugang über den geteilten `ubuntu`-user läuft, ist die personenzuordnung auf server-ebene aktuell eingeschränkt. → personalisierte zugänge oder sitzungsprotokollierung erforderlich (siehe dok 02). **[zu prüfen/umzusetzen]** ## 3. kundenzugang zu protokollen (#88) punkt #88 verlangt, dass protokolle dem kunden jederzeit (ggf. in echtzeit) zur verfügung stehen. **[zu prüfen: können kunden ihre tenant-bezogenen logs einsehen/exportieren? falls nicht vorhanden, als massnahme aufnehmen — z. b. log-export pro mandant oder api.]** ## 4. automatische analyse und ereigniserkennung (#89, #90) | element | status | |---|---| | etablierter logging-/monitoring-prozess | [zu prüfen] | | automatische, proaktive loganalyse (siem/alerting) | **offen** — kleines team, kein siem | | anomalie-/schwellwert-alerting | [zu prüfen] | **kompensierende massnahme (kleines team):** statt eines vollwertigen siem ein leichtgewichtiges, automatisiertes alerting (z. b. log-monitor, der bei definierten mustern — fehlgeschlagene logins, fehlerraten, health-check-ausfall — eine benachrichtigung an die rufbereitschaft sendet). **[zu prüfen/einführen]** ## 5. schutz der protokolldaten (#91) | anforderung | status / massnahme | |---|---| | schutz vor unbefugtem zugriff | logs auf server, nur über privilegierten zugang erreichbar | | schutz vor veränderung/löschung (integrität) | **offen** — logs aktuell auf demselben server, kein write-once. **massnahme:** logs an einen getrennten, append-only/write-once speicher weiterleiten | | aufbewahrungsdauer | [zu prüfen, vorschlag: mind. 12 monate, sicherheitsrelevante zugriffslogs 3 jahre] | ## 6. 7×24-analyse (#92) und soc-schnittstellen (#93) - **#92 (7×24-analyse):** mit 2–5 personen nicht als vollbetrieb leistbar. kompensierend: automatisiertes alerting + rufbereitschaft (siehe dok 07). - **#93 (schnittstellen zum kunden-soc):** [zu prüfen: kann log-streaming/export an ein kunden-soc bereitgestellt werden (syslog, api)? falls nicht, als optionales angebot dokumentieren.] ## 7. stand der umsetzung / lücken | thema | status | massnahme | |---|---|---| | personenbezogene nachvollziehbarkeit (tenant-ebene) | teilweise | personalisierte zugänge / sitzungslog | | log-integritätsschutz | offen | append-only/getrennter speicher | | automatisches alerting | offen | einführen | | aufbewahrungsdauer definiert | offen | festlegen | | kundenzugang zu logs | [zu prüfen] | klären | ", "nextReview": "", "overdueReview": false, "zuPruefen": ["2. Protokollierung des Zugriffs auf Kundendaten (#88, #94)", "3. Kundenzugang zu Protokollen (#88)", "4. Automatische Analyse und Ereigniserkennung (#89, #90)", "4. Automatische Analyse und Ereigniserkennung (#89, #90)", "4. Automatische Analyse und Ereigniserkennung (#89, #90)", "5. Schutz der Protokolldaten (#91)", "6. 7×24-Analyse (#92) und SOC-Schnittstellen (#93)", "7. Stand der Umsetzung / Lücken"]}, {"id": "05_betrieb/12_Netzwerk_und_Infrastruktursicherheit.md", "path": "05_betrieb/12_Netzwerk_und_Infrastruktursicherheit.md", "chapter": "05_betrieb", "title": "Netzwerk- und Infrastruktursicherheit", "filename": "12_Netzwerk_und_Infrastruktursicherheit.md", "meta": {}, "html": "<h1>Netzwerk- und Infrastruktursicherheit<\/h1>\n<p><strong>Dokumenttyp:<\/strong> Konzept <strong>Geltungsbereich:<\/strong> Netzwerk, Server und Rechenzentrumsanbindung der PORTA-Plattform <strong>Version:<\/strong> 1.0 <strong>Status:<\/strong> Entwurf zur internen Freigabe <strong>Owner:<\/strong> Betrieb / DevOps <strong>Letzte Aktualisierung:<\/strong> 02.06.2026 <strong>Deckt ab (CACC):<\/strong> 95, 96, 97, 98, 99<\/p>\n<hr>\n<h2>1. Härtung und Basiskonfiguration (#95)<\/h2>\n<table><thead><tr><th>Element<\/th><th>Vorgabe<\/th><th>Status<\/th><\/tr><\/thead><tbody><tr><td>Server-Härtung (Ubuntu)<\/td><td>nach anerkanntem Standard (z. B. CIS Benchmark)<\/td><td>[ZU PRÜFEN: angewendet?]<\/td><\/tr><tr><td>Nicht benötigte Dienste/Ports deaktiviert<\/td><td>ja<\/td><td>[ZU PRÜFEN]<\/td><\/tr><tr><td>Regelmässige Validierung der Basiskonfiguration<\/td><td>mind. jährlich<\/td><td>[ZU PRÜFEN: etablieren]<\/td><\/tr><\/tbody><\/table>\n<h2>2. Netzwerksegmentierung und Mandantentrennung (#96)<\/h2>\n<table><thead><tr><th>Element<\/th><th>Beschreibung<\/th><th>Status<\/th><\/tr><\/thead><tbody><tr><td>Trennung App / DB<\/td><td>Anwendung (<code>api.poweron.swiss<\/code>) und Datenbank (<code>db.poweron.swiss<\/code>) auf getrennten Hosts<\/td><td>Umgesetzt<\/td><\/tr><tr><td>Trennung Prod / Int<\/td><td>Produktiv- und Integrationsumgebung getrennt<\/td><td>Umgesetzt<\/td><\/tr><tr><td>Mandantentrennung (Multi-Tenancy)<\/td><td>Logische Trennung der Kundendaten innerhalb der Anwendung über Mandate/Berechtigungen<\/td><td>Umgesetzt (logisch)<\/td><\/tr><tr><td>Netzwerksegmentierung (Firewall-Zonen)<\/td><td>[ZU PRÜFEN: wie ist der Netzverkehr segmentiert?]<\/td><td>[ZU PRÜFEN]<\/td><\/tr><\/tbody><\/table>\n<blockquote><strong>Hinweis für regulierte Kunden:<\/strong> Die Mandantentrennung erfolgt logisch (gemeinsame DB-Instanz, getrennte Mandate/Berechtigungen), nicht physisch pro Kunde. Das ist für SaaS üblich, sollte aber im Assessment transparent gemacht werden.<\/blockquote>\n<h2>3. Netzwerkschutzmassnahmen (#97)<\/h2>\n<table><thead><tr><th>Massnahme<\/th><th>Status<\/th><\/tr><\/thead><tbody><tr><td>Firewall<\/td><td>[ZU PRÜFEN: Infomaniak-Firewall / OS-Firewall (ufw/iptables) konfiguriert?]<\/td><\/tr><tr><td>Web Application Firewall (WAF)<\/td><td>[ZU PRÜFEN: vorhanden?]<\/td><\/tr><tr><td>IDS/IPS (Intrusion Detection/Prevention)<\/td><td>[ZU PRÜFEN: vorhanden?]<\/td><\/tr><tr><td>TLS-Terminierung / Reverse Proxy<\/td><td>[ZU PRÜFEN: nginx o. ä.?]<\/td><\/tr><\/tbody><\/table>\n<h2>4. Schutz vor netzwerkbasierten Angriffen / DDoS (#98)<\/h2>\n<table><thead><tr><th>Massnahme<\/th><th>Status<\/th><\/tr><\/thead><tbody><tr><td>DDoS-Schutz<\/td><td>[ZU PRÜFEN: durch Infomaniak bereitgestellt?]<\/td><\/tr><tr><td>Anomalie-Erkennung im Datenverkehr<\/td><td>[ZU PRÜFEN]<\/td><\/tr><tr><td>Rate-Limiting<\/td><td>Teilweise (z. B. Export max. 2/Min — siehe <code>datenbank-handling.md<\/code>)<\/td><\/tr><\/tbody><\/table>\n<h2>5. Physische Sicherheit und Versorgung (#99)<\/h2>\n<p>Die physische Sicherheit wird durch den Rechenzentrumsbetreiber <strong>Infomaniak<\/strong> (Schweiz) gewährleistet:<\/p>\n<table><thead><tr><th>Element<\/th><th>Zuständigkeit<\/th><th>Nachweis<\/th><\/tr><\/thead><tbody><tr><td>Physische Zutrittskontrolle<\/td><td>Infomaniak<\/td><td>[ZU PRÜFEN: Infomaniak-Zertifikate/RZ-Doku beilegen, z. B. ISO 27001]<\/td><\/tr><tr><td>Stromversorgung / USV / Notstrom<\/td><td>Infomaniak<\/td><td>Infomaniak-Rechenzentren (CH)<\/td><\/tr><tr><td>Kühlung / Brandschutz<\/td><td>Infomaniak<\/td><td>Infomaniak-Dokumentation<\/td><\/tr><\/tbody><\/table>\n<p><strong>Massnahme:<\/strong> Aktuelle Sicherheits-/Zertifizierungsnachweise von Infomaniak einholen und als Evidenz dem Assessment beilegen.<\/p>\n<h2>6. Stand der Umsetzung / Lücken<\/h2>\n<table><thead><tr><th>Thema<\/th><th>Status<\/th><th>Massnahme<\/th><\/tr><\/thead><tbody><tr><td>Server-Härtung nach CIS<\/td><td>[ZU PRÜFEN]<\/td><td>Anwenden &amp; dokumentieren<\/td><\/tr><tr><td>WAF / IDS / IPS<\/td><td>[ZU PRÜFEN]<\/td><td>Bedarf klären, ggf. einführen<\/td><\/tr><tr><td>Infomaniak-Zertifikate als Evidenz<\/td><td>Offen<\/td><td>Einholen<\/td><\/tr><tr><td>Firewall-Konfiguration dokumentieren<\/td><td>[ZU PRÜFEN]<\/td><td>Festhalten<\/td><\/tr><\/tbody><\/table>", "text": "# netzwerk- und infrastruktursicherheit **dokumenttyp:** konzept **geltungsbereich:** netzwerk, server und rechenzentrumsanbindung der porta-plattform **version:** 1.0 **status:** entwurf zur internen freigabe **owner:** betrieb / devops **letzte aktualisierung:** 02.06.2026 **deckt ab (cacc):** 95, 96, 97, 98, 99 --- ## 1. härtung und basiskonfiguration (#95) | element | vorgabe | status | |---|---|---| | server-härtung (ubuntu) | nach anerkanntem standard (z. b. cis benchmark) | [zu prüfen: angewendet?] | | nicht benötigte dienste/ports deaktiviert | ja | [zu prüfen] | | regelmässige validierung der basiskonfiguration | mind. jährlich | [zu prüfen: etablieren] | ## 2. netzwerksegmentierung und mandantentrennung (#96) | element | beschreibung | status | |---|---|---| | trennung app / db | anwendung (`api.poweron.swiss`) und datenbank (`db.poweron.swiss`) auf getrennten hosts | umgesetzt | | trennung prod / int | produktiv- und integrationsumgebung getrennt | umgesetzt | | mandantentrennung (multi-tenancy) | logische trennung der kundendaten innerhalb der anwendung über mandate/berechtigungen | umgesetzt (logisch) | | netzwerksegmentierung (firewall-zonen) | [zu prüfen: wie ist der netzverkehr segmentiert?] | [zu prüfen] | > **hinweis für regulierte kunden:** die mandantentrennung erfolgt logisch (gemeinsame db-instanz, getrennte mandate/berechtigungen), nicht physisch pro kunde. das ist für saas üblich, sollte aber im assessment transparent gemacht werden. ## 3. netzwerkschutzmassnahmen (#97) | massnahme | status | |---|---| | firewall | [zu prüfen: infomaniak-firewall / os-firewall (ufw/iptables) konfiguriert?] | | web application firewall (waf) | [zu prüfen: vorhanden?] | | ids/ips (intrusion detection/prevention) | [zu prüfen: vorhanden?] | | tls-terminierung / reverse proxy | [zu prüfen: nginx o. ä.?] | ## 4. schutz vor netzwerkbasierten angriffen / ddos (#98) | massnahme | status | |---|---| | ddos-schutz | [zu prüfen: durch infomaniak bereitgestellt?] | | anomalie-erkennung im datenverkehr | [zu prüfen] | | rate-limiting | teilweise (z. b. export max. 2/min — siehe `datenbank-handling.md`) | ## 5. physische sicherheit und versorgung (#99) die physische sicherheit wird durch den rechenzentrumsbetreiber **infomaniak** (schweiz) gewährleistet: | element | zuständigkeit | nachweis | |---|---|---| | physische zutrittskontrolle | infomaniak | [zu prüfen: infomaniak-zertifikate/rz-doku beilegen, z. b. iso 27001] | | stromversorgung / usv / notstrom | infomaniak | infomaniak-rechenzentren (ch) | | kühlung / brandschutz | infomaniak | infomaniak-dokumentation | **massnahme:** aktuelle sicherheits-/zertifizierungsnachweise von infomaniak einholen und als evidenz dem assessment beilegen. ## 6. stand der umsetzung / lücken | thema | status | massnahme | |---|---|---| | server-härtung nach cis | [zu prüfen] | anwenden & dokumentieren | | waf / ids / ips | [zu prüfen] | bedarf klären, ggf. einführen | | infomaniak-zertifikate als evidenz | offen | einholen | | firewall-konfiguration dokumentieren | [zu prüfen] | festhalten | ", "nextReview": "", "overdueReview": false, "zuPruefen": ["1. Härtung und Basiskonfiguration (#95)", "1. Härtung und Basiskonfiguration (#95)", "1. Härtung und Basiskonfiguration (#95)", "2. Netzwerksegmentierung und Mandantentrennung (#96)", "3. Netzwerkschutzmassnahmen (#97)", "3. Netzwerkschutzmassnahmen (#97)", "3. Netzwerkschutzmassnahmen (#97)", "3. Netzwerkschutzmassnahmen (#97)", "4. Schutz vor netzwerkbasierten Angriffen / DDoS (#98)", "4. Schutz vor netzwerkbasierten Angriffen / DDoS (#98)", "5. Physische Sicherheit und Versorgung (#99)", "6. Stand der Umsetzung / Lücken", "6. Stand der Umsetzung / Lücken", "6. Stand der Umsetzung / Lücken"]}, {"id": "05_betrieb/13_Datenaufbewahrung_Loeschung_LegalHold.md", "path": "05_betrieb/13_Datenaufbewahrung_Loeschung_LegalHold.md", "chapter": "05_betrieb", "title": "Datenaufbewahrung, Löschung und Legal Hold", "filename": "13_Datenaufbewahrung_Loeschung_LegalHold.md", "meta": {}, "html": "<h1>Datenaufbewahrung, Löschung und Legal Hold<\/h1>\n<p><strong>Dokumenttyp:<\/strong> Konzept <strong>Geltungsbereich:<\/strong> Alle Kundendaten (Inhaltsdaten, Metadaten) der PORTA-Plattform <strong>Version:<\/strong> 1.0 <strong>Status:<\/strong> Entwurf zur internen Freigabe <strong>Owner:<\/strong> Datenschutzverantwortlicher / Betrieb <strong>Letzte Aktualisierung:<\/strong> 02.06.2026 <strong>Deckt ab (CACC):<\/strong> 1, 2, 38, 72 <strong>Verweist auf:<\/strong> <code>datenbank-handling.md<\/code><\/p>\n<hr>\n<h2>1. Legal Hold (#1)<\/h2>\n<p>Punkt #1 verlangt, dass der Kunde Inhalte (inkl. Metadaten) für rechtliche Zwecke aufbewahren und exportieren kann.<\/p>\n<table><thead><tr><th>Funktion<\/th><th>Status<\/th><\/tr><\/thead><tbody><tr><td>Daten eines Mandats vollständig exportieren (JSON)<\/td><td>Umgesetzt (Admin-UI / Script, siehe <code>datenbank-handling.md<\/code>)<\/td><\/tr><tr><td>Gezieltes „Einfrieren\" einzelner Datensätze gegen Löschung (Legal Hold)<\/td><td><strong>[ZU PRÜFEN: technisch vorhanden? Sonst als Massnahme / manuelle Prozedur dokumentieren]<\/strong><\/td><\/tr><tr><td>Forensischer Export in lesbarem Format<\/td><td>Umgesetzt (JSON)<\/td><\/tr><\/tbody><\/table>\n<p><strong>Manuelle Legal-Hold-Prozedur (Übergang, falls keine Funktion vorhanden):<\/strong> Auf Kundenanfrage wird ein vollständiger Export des betroffenen Mandats erstellt und gesichert abgelegt; betroffene Daten werden von automatischen Löschroutinen ausgenommen.<\/p>\n<h2>2. Aufbewahrung und Löschung pro Datenkategorie (#2)<\/h2>\n<p>Punkt #2 verlangt konfigurierbare Aufbewahrungsfristen pro Datenkategorie mit sicherer Löschung/Anonymisierung und Ausnahmemöglichkeit.<\/p>\n<table><thead><tr><th>Datenkategorie (DB)<\/th><th>Aufbewahrung<\/th><th>Löschung<\/th><\/tr><\/thead><tbody><tr><td>Chat-Konversationen (<code>poweron_chat<\/code>)<\/td><td>[ZU PRÜFEN / festlegen]<\/td><td>[ZU PRÜFEN: automatisch?]<\/td><\/tr><tr><td>Chatbot-Logs (<code>poweron_chatbot<\/code>)<\/td><td>[ZU PRÜFEN]<\/td><td>[ZU PRÜFEN]<\/td><\/tr><tr><td>RAG-Wissensdaten (<code>poweron_knowledge<\/code>)<\/td><td>bis Kunde löscht<\/td><td>manuell<\/td><\/tr><tr><td>Abrechnungsdaten (<code>poweron_billing<\/code>)<\/td><td>gesetzliche Frist (CH: 10 Jahre Geschäftsbücher)<\/td><td>nach Frist<\/td><\/tr><tr><td>Auth-/Login-Protokoll (<code>AuthEvent<\/code>)<\/td><td>[ZU PRÜFEN, Vorschlag: 12 Monate]<\/td><td>[ZU PRÜFEN]<\/td><\/tr><\/tbody><\/table>\n<blockquote><strong>Offener Punkt:<\/strong> Aktuell besteht <strong>keine automatische, kategorienbasierte Löschroutine<\/strong>. Daten bleiben, bis ein Mandat/Datensatz manuell gelöscht wird. <strong>Massnahme:<\/strong> Aufbewahrungsfristen je Kategorie definieren und — soweit möglich — automatisierte Löschung/Anonymisierung implementieren, mit Ausnahmemechanismus (Legal Hold).<\/blockquote>\n<h2>3. Löschung bei Vertragsende (#38)<\/h2>\n<p>Nach Vertragsende und erfolgter Datenmigration darf PowerOn keine lesbare Kopie der Berufsgeheimnisdaten mehr besitzen.<\/p>\n<table><thead><tr><th>Schritt<\/th><th>Vorgehen<\/th><th>Status<\/th><\/tr><\/thead><tbody><tr><td>Datenexport an Kunden<\/td><td>vollständiger JSON-Export<\/td><td>Umgesetzt<\/td><\/tr><tr><td>Löschung aus Produktiv-DB<\/td><td>Mandat und zugehörige Daten löschen<\/td><td>[ZU PRÜFEN: vollständige Löschroutine pro Mandat?]<\/td><\/tr><tr><td>Löschung aus Backups/Exports<\/td><td>Krypto-Löschung (Schlüssel vernichten) bzw. Löschung der Export-Dateien<\/td><td>[ZU PRÜFEN]<\/td><\/tr><tr><td>Löschung bei Subprozessoren<\/td><td>LLM-Provider: keine Speicherung (Zero-Retention)<\/td><td>[ZU PRÜFEN: vertraglich]<\/td><\/tr><tr><td>Löschbestätigung<\/td><td>schriftliche Bestätigung an Kunden<\/td><td>Neu — Vorlage erstellen<\/td><\/tr><\/tbody><\/table>\n<h2>4. Schlüssellöschung (#72)<\/h2>\n<p>Sichere Löschung von Verschlüsselungsschlüsseln am Ende des Lebenszyklus — siehe <code>04_Verschluesselung_und_Schluesselmanagement.md<\/code>.<\/p>\n<h2>5. Datenschutz-Hinweise (aus bestehender Doku)<\/h2>\n<p>Aus <code>datenbank-handling.md<\/code> übernommen und verbindlich: Export-Dateien enthalten alle Kundendaten, dürfen nicht auf unsicheren Speichern abgelegt werden und sind nach Gebrauch zu löschen. Zugriff auf Export/Import nur für SysAdmins, serverseitig geloggt.<\/p>\n<h2>6. Stand der Umsetzung / Lücken<\/h2>\n<table><thead><tr><th>Thema<\/th><th>Status<\/th><th>Massnahme<\/th><\/tr><\/thead><tbody><tr><td>Kategorienbasierte Aufbewahrungsfristen<\/td><td>Offen<\/td><td>Definieren<\/td><\/tr><tr><td>Automatische Löschung/Anonymisierung<\/td><td>Offen<\/td><td>Implementieren<\/td><\/tr><tr><td>Legal-Hold-Funktion<\/td><td>[ZU PRÜFEN]<\/td><td>Funktion oder manuelle Prozedur<\/td><\/tr><tr><td>Löschbestätigung bei Vertragsende<\/td><td>Neu<\/td><td>Vorlage erstellen<\/td><\/tr><\/tbody><\/table>", "text": "# datenaufbewahrung, löschung und legal hold **dokumenttyp:** konzept **geltungsbereich:** alle kundendaten (inhaltsdaten, metadaten) der porta-plattform **version:** 1.0 **status:** entwurf zur internen freigabe **owner:** datenschutzverantwortlicher / betrieb **letzte aktualisierung:** 02.06.2026 **deckt ab (cacc):** 1, 2, 38, 72 **verweist auf:** `datenbank-handling.md` --- ## 1. legal hold (#1) punkt #1 verlangt, dass der kunde inhalte (inkl. metadaten) für rechtliche zwecke aufbewahren und exportieren kann. | funktion | status | |---|---| | daten eines mandats vollständig exportieren (json) | umgesetzt (admin-ui / script, siehe `datenbank-handling.md`) | | gezieltes „einfrieren\" einzelner datensätze gegen löschung (legal hold) | **[zu prüfen: technisch vorhanden? sonst als massnahme / manuelle prozedur dokumentieren]** | | forensischer export in lesbarem format | umgesetzt (json) | **manuelle legal-hold-prozedur (übergang, falls keine funktion vorhanden):** auf kundenanfrage wird ein vollständiger export des betroffenen mandats erstellt und gesichert abgelegt; betroffene daten werden von automatischen löschroutinen ausgenommen. ## 2. aufbewahrung und löschung pro datenkategorie (#2) punkt #2 verlangt konfigurierbare aufbewahrungsfristen pro datenkategorie mit sicherer löschung/anonymisierung und ausnahmemöglichkeit. | datenkategorie (db) | aufbewahrung | löschung | |---|---|---| | chat-konversationen (`poweron_chat`) | [zu prüfen / festlegen] | [zu prüfen: automatisch?] | | chatbot-logs (`poweron_chatbot`) | [zu prüfen] | [zu prüfen] | | rag-wissensdaten (`poweron_knowledge`) | bis kunde löscht | manuell | | abrechnungsdaten (`poweron_billing`) | gesetzliche frist (ch: 10 jahre geschäftsbücher) | nach frist | | auth-/login-protokoll (`authevent`) | [zu prüfen, vorschlag: 12 monate] | [zu prüfen] | > **offener punkt:** aktuell besteht **keine automatische, kategorienbasierte löschroutine**. daten bleiben, bis ein mandat/datensatz manuell gelöscht wird. **massnahme:** aufbewahrungsfristen je kategorie definieren und — soweit möglich — automatisierte löschung/anonymisierung implementieren, mit ausnahmemechanismus (legal hold). ## 3. löschung bei vertragsende (#38) nach vertragsende und erfolgter datenmigration darf poweron keine lesbare kopie der berufsgeheimnisdaten mehr besitzen. | schritt | vorgehen | status | |---|---|---| | datenexport an kunden | vollständiger json-export | umgesetzt | | löschung aus produktiv-db | mandat und zugehörige daten löschen | [zu prüfen: vollständige löschroutine pro mandat?] | | löschung aus backups/exports | krypto-löschung (schlüssel vernichten) bzw. löschung der export-dateien | [zu prüfen] | | löschung bei subprozessoren | llm-provider: keine speicherung (zero-retention) | [zu prüfen: vertraglich] | | löschbestätigung | schriftliche bestätigung an kunden | neu — vorlage erstellen | ## 4. schlüssellöschung (#72) sichere löschung von verschlüsselungsschlüsseln am ende des lebenszyklus — siehe `04_verschluesselung_und_schluesselmanagement.md`. ## 5. datenschutz-hinweise (aus bestehender doku) aus `datenbank-handling.md` übernommen und verbindlich: export-dateien enthalten alle kundendaten, dürfen nicht auf unsicheren speichern abgelegt werden und sind nach gebrauch zu löschen. zugriff auf export/import nur für sysadmins, serverseitig geloggt. ## 6. stand der umsetzung / lücken | thema | status | massnahme | |---|---|---| | kategorienbasierte aufbewahrungsfristen | offen | definieren | | automatische löschung/anonymisierung | offen | implementieren | | legal-hold-funktion | [zu prüfen] | funktion oder manuelle prozedur | | löschbestätigung bei vertragsende | neu | vorlage erstellen | ", "nextReview": "", "overdueReview": false, "zuPruefen": ["1. Legal Hold (#1)", "2. Aufbewahrung und Löschung pro Datenkategorie (#2)", "2. Aufbewahrung und Löschung pro Datenkategorie (#2)", "2. Aufbewahrung und Löschung pro Datenkategorie (#2)", "3. Löschung bei Vertragsende (#38)", "3. Löschung bei Vertragsende (#38)", "3. Löschung bei Vertragsende (#38)", "6. Stand der Umsetzung / Lücken"]}, {"id": "05_betrieb/14_Exit_und_Transition.md", "path": "05_betrieb/14_Exit_und_Transition.md", "chapter": "05_betrieb", "title": "Exit- und Transitionsmanagement (Repatriierung)", "filename": "14_Exit_und_Transition.md", "meta": {}, "html": "<h1>Exit- und Transitionsmanagement (Repatriierung)<\/h1>\n<p><strong>Dokumenttyp:<\/strong> Konzept &amp; Plan <strong>Geltungsbereich:<\/strong> Beendigung der Dienstleistung und Rückführung von Daten/Funktionen <strong>Version:<\/strong> 1.0 <strong>Status:<\/strong> Entwurf zur internen Freigabe <strong>Owner:<\/strong> Geschäftsführung / Betrieb <strong>Letzte Aktualisierung:<\/strong> 02.06.2026 <strong>Deckt ab (CACC):<\/strong> 4, 5, 6, 22<\/p>\n<hr>\n<h2>1. Zweck<\/h2>\n<p>Dieser Plan stellt sicher, dass ein Kunde die ausgelagerten Funktionen geordnet zu sich oder einem Drittanbieter zurückführen (repatriieren) kann, ohne dass kritische Daten verloren gehen oder der Betrieb des Kunden gefährdet wird.<\/p>\n<h2>2. Kündigungs- und Vorlauffristen (#4, #22)<\/h2>\n<table><thead><tr><th>Element<\/th><th>Regelung (gemäss AGB-Entwurf)<\/th><\/tr><\/thead><tbody><tr><td>Ordentliche Kündigung<\/td><td>3 Monate zum Vertragsmonatsende<\/td><\/tr><tr><td>Ankündigung neuer Subunternehmer<\/td><td>30 Tage im Voraus, Widerspruchsrecht<\/td><\/tr><tr><td>Vorlauf für geordneten Rücktransport bei Kündigung durch PowerOn<\/td><td>ausreichend für Migration (siehe Weiterführungspflicht)<\/td><\/tr><\/tbody><\/table>\n<blockquote>Hinweis: Punkt #4 nennt als Richtwert ~6 Monate Vorlauf. Prüfen, ob 3 Monate Kündigungsfrist + Exportfenster + Weiterführungspflicht in Summe ausreichend sind, oder ob die Frist für regulierte Kunden vertraglich verlängert wird.<\/blockquote>\n<h2>3. Datenexport (#5)<\/h2>\n<p>Der Kunde kann <strong>jederzeit<\/strong> alle relevanten Daten exportieren:<\/p>\n<table><thead><tr><th>Datenart<\/th><th>Export<\/th><\/tr><\/thead><tbody><tr><td>Inhaltsdaten (Mandate, Chats, Dokumente, Wissensdaten)<\/td><td>vollständiger JSON-Export (Admin-UI/Script)<\/td><\/tr><tr><td>Zugriffs-/Protokolldaten<\/td><td>[ZU PRÜFEN: AuthEvent/Logs separat exportierbar?]<\/td><\/tr><tr><td>Format<\/td><td>JSON (offen, maschinenlesbar, kein proprietäres Lock-in)<\/td><\/tr><\/tbody><\/table>\n<p>Der Export ist unabhängig von Zahlungsstreitigkeiten verfügbar (vgl. AGB §18.4).<\/p>\n<h2>4. Weiterführungspflicht bei gescheiterter Repatriierung (#6)<\/h2>\n<p>Sollte die Rückführung scheitern, führt PowerOn die Leistung für einen definierten Zeitraum weiter, damit der Kunde einen zweiten Versuch unternehmen kann.<\/p>\n<table><thead><tr><th>Element<\/th><th>Regelung<\/th><\/tr><\/thead><tbody><tr><td>Weiterführungsdauer<\/td><td>mind. 6 Monate (gemäss AGB §11.3)<\/td><\/tr><tr><td>Bedingungen<\/td><td>zu bisherigen Vertragsbedingungen<\/td><\/tr><\/tbody><\/table>\n<h2>5. Transition-Ablauf (Runbook)<\/h2>\n<pre class=\"mermaid\">flowchart TD\n    A[Kündigung / Exit-Entscheid] --&gt; B[Exit-Plan aktivieren, Ansprechpartner benennen]\n    B --&gt; C[Vollständiger Datenexport JSON]\n    C --&gt; D[Übergabe an Kunde/Drittanbieter, Formatklärung]\n    D --&gt; E[Verifikation: Daten vollständig &amp; lesbar beim Kunden]\n    E --&gt; F{Repatriierung erfolgreich?}\n    F --&gt;|Nein| G[Weiterführung bis zu 6 Monate, 2. Versuch]\n    F --&gt;|Ja| H[Löschung bei PowerOn inkl. Backups]\n    H --&gt; I[Schriftliche Löschbestätigung an Kunden]<\/pre>\n<h2>6. Löschung nach Exit<\/h2>\n<p>Siehe <code>13_Datenaufbewahrung_Loeschung_LegalHold.md<\/code> Abschnitt 3. Nach erfolgreicher Migration: vollständige Löschung inkl. Backups und Bestätigung an den Kunden.<\/p>\n<h2>7. Stand der Umsetzung / Lücken<\/h2>\n<table><thead><tr><th>Thema<\/th><th>Status<\/th><th>Massnahme<\/th><\/tr><\/thead><tbody><tr><td>Exportfunktion<\/td><td>Umgesetzt<\/td><td>—<\/td><\/tr><tr><td>Export von Logs/Zugriffsdaten<\/td><td>[ZU PRÜFEN]<\/td><td>sicherstellen<\/td><\/tr><tr><td>Exit-Plan je regulierten Kunden<\/td><td>Neu<\/td><td>im Vertrag konkretisieren<\/td><\/tr><tr><td>Löschbestätigungs-Vorlage<\/td><td>Neu<\/td><td>erstellen<\/td><\/tr><\/tbody><\/table>", "text": "# exit- und transitionsmanagement (repatriierung) **dokumenttyp:** konzept & plan **geltungsbereich:** beendigung der dienstleistung und rückführung von daten/funktionen **version:** 1.0 **status:** entwurf zur internen freigabe **owner:** geschäftsführung / betrieb **letzte aktualisierung:** 02.06.2026 **deckt ab (cacc):** 4, 5, 6, 22 --- ## 1. zweck dieser plan stellt sicher, dass ein kunde die ausgelagerten funktionen geordnet zu sich oder einem drittanbieter zurückführen (repatriieren) kann, ohne dass kritische daten verloren gehen oder der betrieb des kunden gefährdet wird. ## 2. kündigungs- und vorlauffristen (#4, #22) | element | regelung (gemäss agb-entwurf) | |---|---| | ordentliche kündigung | 3 monate zum vertragsmonatsende | | ankündigung neuer subunternehmer | 30 tage im voraus, widerspruchsrecht | | vorlauf für geordneten rücktransport bei kündigung durch poweron | ausreichend für migration (siehe weiterführungspflicht) | > hinweis: punkt #4 nennt als richtwert ~6 monate vorlauf. prüfen, ob 3 monate kündigungsfrist + exportfenster + weiterführungspflicht in summe ausreichend sind, oder ob die frist für regulierte kunden vertraglich verlängert wird. ## 3. datenexport (#5) der kunde kann **jederzeit** alle relevanten daten exportieren: | datenart | export | |---|---| | inhaltsdaten (mandate, chats, dokumente, wissensdaten) | vollständiger json-export (admin-ui/script) | | zugriffs-/protokolldaten | [zu prüfen: authevent/logs separat exportierbar?] | | format | json (offen, maschinenlesbar, kein proprietäres lock-in) | der export ist unabhängig von zahlungsstreitigkeiten verfügbar (vgl. agb §18.4). ## 4. weiterführungspflicht bei gescheiterter repatriierung (#6) sollte die rückführung scheitern, führt poweron die leistung für einen definierten zeitraum weiter, damit der kunde einen zweiten versuch unternehmen kann. | element | regelung | |---|---| | weiterführungsdauer | mind. 6 monate (gemäss agb §11.3) | | bedingungen | zu bisherigen vertragsbedingungen | ## 5. transition-ablauf (runbook) ```mermaid flowchart td a[kündigung / exit-entscheid] --> b[exit-plan aktivieren, ansprechpartner benennen] b --> c[vollständiger datenexport json] c --> d[übergabe an kunde/drittanbieter, formatklärung] d --> e[verifikation: daten vollständig & lesbar beim kunden] e --> f{repatriierung erfolgreich?} f -->|nein| g[weiterführung bis zu 6 monate, 2. versuch] f -->|ja| h[löschung bei poweron inkl. backups] h --> i[schriftliche löschbestätigung an kunden] ``` ## 6. löschung nach exit siehe `13_datenaufbewahrung_loeschung_legalhold.md` abschnitt 3. nach erfolgreicher migration: vollständige löschung inkl. backups und bestätigung an den kunden. ## 7. stand der umsetzung / lücken | thema | status | massnahme | |---|---|---| | exportfunktion | umgesetzt | — | | export von logs/zugriffsdaten | [zu prüfen] | sicherstellen | | exit-plan je regulierten kunden | neu | im vertrag konkretisieren | | löschbestätigungs-vorlage | neu | erstellen | ", "nextReview": "", "overdueReview": false, "zuPruefen": ["3. Datenexport (#5)", "7. Stand der Umsetzung / Lücken"]}, {"id": "05_betrieb/15_Sichere_Softwareentwicklung_SDLC.md", "path": "05_betrieb/15_Sichere_Softwareentwicklung_SDLC.md", "chapter": "05_betrieb", "title": "Sichere Softwareentwicklung (Secure SDLC)", "filename": "15_Sichere_Softwareentwicklung_SDLC.md", "meta": {}, "html": "<h1>Sichere Softwareentwicklung (Secure SDLC)<\/h1>\n<p><strong>Dokumenttyp:<\/strong> Richtlinie <strong>Geltungsbereich:<\/strong> Entwicklung der PORTA-Plattform <strong>Version:<\/strong> 1.0 <strong>Status:<\/strong> Entwurf zur internen Freigabe <strong>Owner:<\/strong> Entwicklung <strong>Letzte Aktualisierung:<\/strong> 02.06.2026 <strong>Deckt ab (CACC):<\/strong> 100, 101, 102 <strong>Verweist auf:<\/strong> <code>feature_release_bugfix.md<\/code><\/p>\n<hr>\n<h2>1. Basis<\/h2>\n<p>Der grundlegende Entwicklungs- und Release-Prozess (Anforderungen, Tech-Workshop mit Architektur-/Schnittstellenanalyse, Branches, Code-Review, Staging-Verifikation, Release Notes) ist in <code>feature_release_bugfix.md<\/code> dokumentiert. Dieses Dokument ergänzt die <strong>sicherheitsspezifischen<\/strong> Aspekte gemäss #100–#102.<\/p>\n<h2>2. Sicherheit über den Entwicklungszyklus (#100)<\/h2>\n<table><thead><tr><th>Phase<\/th><th>Sicherheitsmassnahme<\/th><th>Status<\/th><\/tr><\/thead><tbody><tr><td>Anforderungen<\/td><td>Sicherheits-/Datenschutzanforderungen je Feature im Tech-Workshop berücksichtigen<\/td><td>[ZU PRÜFEN: explizit Teil des Workshops?]<\/td><\/tr><tr><td>Design<\/td><td>Bedrohungsbetrachtung bei Architekturänderungen (betroffene Daten, Schnittstellen, Drittdienste)<\/td><td>Teilweise (Tech-Workshop prüft Abhängigkeiten zu Drittdiensten)<\/td><\/tr><tr><td>Implementierung<\/td><td>Sichere Coding-Praktiken, Secrets nicht im Code (<code>.env<\/code>-Trennung)<\/td><td>Umgesetzt<\/td><\/tr><tr><td>Tests &amp; Review<\/td><td>Code-Review (Vier-Augen), Staging-Verifikation<\/td><td>Umgesetzt<\/td><\/tr><tr><td>Security-Tests<\/td><td>SAST/DAST/Dependency-Scan in der CI/CD-Pipeline<\/td><td><strong>[ZU PRÜFEN: in Forgejo-Pipeline integriert?]<\/strong><\/td><\/tr><\/tbody><\/table>\n<h2>3. Standards und Frameworks (#101)<\/h2>\n<table><thead><tr><th>Standard<\/th><th>Anwendung<\/th><th>Status<\/th><\/tr><\/thead><tbody><tr><td>OWASP Top 10<\/td><td>Berücksichtigung gängiger Web-Schwachstellen in Reviews<\/td><td>[ZU PRÜFEN: als Review-Checkliste verankert?]<\/td><\/tr><tr><td>NIST / anerkannte Frameworks<\/td><td>Orientierung<\/td><td>[ZU PRÜFEN]<\/td><\/tr><\/tbody><\/table>\n<p><strong>Massnahme:<\/strong> OWASP-Top-10-Checkliste als fester Bestandteil des Code-Reviews aufnehmen; ggf. automatisiertes SAST-Tool (z. B. Bandit für Python) in die Pipeline integrieren.<\/p>\n<h2>4. Keine Produktivdaten in Entwicklung/Test (#102) — WICHTIG<\/h2>\n<blockquote><strong>Direkter Konflikt mit aktueller Praxis:<\/strong> <code>datenbank-handling.md<\/code> (Abschnitt 3) beschreibt das Übertragen von <strong>Produktionsdaten auf die Testumgebung<\/strong> als regulären Use-Case. Punkt #102 verlangt jedoch ausdrücklich, dass <strong>produktive, dem Berufsgeheimnis unterliegende Daten NICHT für Entwicklung und Test<\/strong> verwendet werden.<\/blockquote>\n<p><strong>Erforderliche Massnahme (Entscheidung nötig):<\/strong><\/p>\n<table><thead><tr><th>Option<\/th><th>Beschreibung<\/th><\/tr><\/thead><tbody><tr><td>A — Verbot + Anonymisierung<\/td><td>Prod→Int-Migration nur mit vollständiger Anonymisierung/Pseudonymisierung der Inhaltsdaten. Klartext-Berufsgeheimnisdaten nie auf Int.<\/td><\/tr><tr><td>B — Synthetische Testdaten<\/td><td>Entwicklung/Test ausschliesslich mit synthetischen Testdaten (<code>poweron_test<\/code> ist bereits vom Export ausgeschlossen).<\/td><\/tr><tr><td>C — Streng kontrollierte Ausnahme<\/td><td>Prod-Daten auf Int nur in eng begrenzten, protokollierten Ausnahmefällen mit Kundengenehmigung.<\/td><\/tr><\/tbody><\/table>\n<p><strong>Empfehlung für FINMA-Kontext:<\/strong> Option A oder B. Die aktuelle Beschreibung in <code>datenbank-handling.md<\/code> ist entsprechend anzupassen.<\/p>\n<h2>5. Stand der Umsetzung / Lücken<\/h2>\n<table><thead><tr><th>Thema<\/th><th>Status<\/th><th>Massnahme<\/th><\/tr><\/thead><tbody><tr><td>SAST/DAST in Pipeline<\/td><td>[ZU PRÜFEN]<\/td><td>Integrieren<\/td><\/tr><tr><td>OWASP-Review-Checkliste<\/td><td>[ZU PRÜFEN]<\/td><td>Verankern<\/td><\/tr><tr><td>Prod-Daten in Test (#102)<\/td><td><strong>Konflikt<\/strong><\/td><td>Praxis ändern (Anonymisierung/synthetische Daten) + Doku anpassen<\/td><\/tr><\/tbody><\/table>", "text": "# sichere softwareentwicklung (secure sdlc) **dokumenttyp:** richtlinie **geltungsbereich:** entwicklung der porta-plattform **version:** 1.0 **status:** entwurf zur internen freigabe **owner:** entwicklung **letzte aktualisierung:** 02.06.2026 **deckt ab (cacc):** 100, 101, 102 **verweist auf:** `feature_release_bugfix.md` --- ## 1. basis der grundlegende entwicklungs- und release-prozess (anforderungen, tech-workshop mit architektur-/schnittstellenanalyse, branches, code-review, staging-verifikation, release notes) ist in `feature_release_bugfix.md` dokumentiert. dieses dokument ergänzt die **sicherheitsspezifischen** aspekte gemäss #100–#102. ## 2. sicherheit über den entwicklungszyklus (#100) | phase | sicherheitsmassnahme | status | |---|---|---| | anforderungen | sicherheits-/datenschutzanforderungen je feature im tech-workshop berücksichtigen | [zu prüfen: explizit teil des workshops?] | | design | bedrohungsbetrachtung bei architekturänderungen (betroffene daten, schnittstellen, drittdienste) | teilweise (tech-workshop prüft abhängigkeiten zu drittdiensten) | | implementierung | sichere coding-praktiken, secrets nicht im code (`.env`-trennung) | umgesetzt | | tests & review | code-review (vier-augen), staging-verifikation | umgesetzt | | security-tests | sast/dast/dependency-scan in der ci/cd-pipeline | **[zu prüfen: in forgejo-pipeline integriert?]** | ## 3. standards und frameworks (#101) | standard | anwendung | status | |---|---|---| | owasp top 10 | berücksichtigung gängiger web-schwachstellen in reviews | [zu prüfen: als review-checkliste verankert?] | | nist / anerkannte frameworks | orientierung | [zu prüfen] | **massnahme:** owasp-top-10-checkliste als fester bestandteil des code-reviews aufnehmen; ggf. automatisiertes sast-tool (z. b. bandit für python) in die pipeline integrieren. ## 4. keine produktivdaten in entwicklung/test (#102) — wichtig > **direkter konflikt mit aktueller praxis:** `datenbank-handling.md` (abschnitt 3) beschreibt das übertragen von **produktionsdaten auf die testumgebung** als regulären use-case. punkt #102 verlangt jedoch ausdrücklich, dass **produktive, dem berufsgeheimnis unterliegende daten nicht für entwicklung und test** verwendet werden. **erforderliche massnahme (entscheidung nötig):** | option | beschreibung | |---|---| | a — verbot + anonymisierung | prod→int-migration nur mit vollständiger anonymisierung/pseudonymisierung der inhaltsdaten. klartext-berufsgeheimnisdaten nie auf int. | | b — synthetische testdaten | entwicklung/test ausschliesslich mit synthetischen testdaten (`poweron_test` ist bereits vom export ausgeschlossen). | | c — streng kontrollierte ausnahme | prod-daten auf int nur in eng begrenzten, protokollierten ausnahmefällen mit kundengenehmigung. | **empfehlung für finma-kontext:** option a oder b. die aktuelle beschreibung in `datenbank-handling.md` ist entsprechend anzupassen. ## 5. stand der umsetzung / lücken | thema | status | massnahme | |---|---|---| | sast/dast in pipeline | [zu prüfen] | integrieren | | owasp-review-checkliste | [zu prüfen] | verankern | | prod-daten in test (#102) | **konflikt** | praxis ändern (anonymisierung/synthetische daten) + doku anpassen | ", "nextReview": "", "overdueReview": false, "zuPruefen": ["2. Sicherheit über den Entwicklungszyklus (#100)", "2. Sicherheit über den Entwicklungszyklus (#100)", "3. Standards und Frameworks (#101)", "3. Standards und Frameworks (#101)", "5. Stand der Umsetzung / Lücken", "5. Stand der Umsetzung / Lücken"]}, {"id": "05_betrieb/16_Kapazitaetsmanagement.md", "path": "05_betrieb/16_Kapazitaetsmanagement.md", "chapter": "05_betrieb", "title": "Kapazitätsmanagement", "filename": "16_Kapazitaetsmanagement.md", "meta": {}, "html": "<h1>Kapazitätsmanagement<\/h1>\n<p><strong>Dokumenttyp:<\/strong> Prozess <strong>Geltungsbereich:<\/strong> Personal- und IT-Ressourcen der PORTA-Plattform <strong>Version:<\/strong> 1.0 <strong>Status:<\/strong> Entwurf zur internen Freigabe <strong>Owner:<\/strong> Geschäftsführung / Betrieb <strong>Letzte Aktualisierung:<\/strong> 02.06.2026 <strong>Deckt ab (CACC):<\/strong> 80<\/p>\n<hr>\n<h2>1. Zweck<\/h2>\n<p>Sicherstellung ausreichender Personal- und IT-Kapazitäten für eine kontinuierliche, vereinbarungsgemässe Leistungserbringung.<\/p>\n<h2>2. IT-Ressourcen-Kapazität<\/h2>\n<table><thead><tr><th>Ressource<\/th><th>Überwachung<\/th><th>Status<\/th><\/tr><\/thead><tbody><tr><td>Server-Auslastung (CPU/RAM/Disk)<\/td><td>[ZU PRÜFEN: Monitoring vorhanden?]<\/td><td>[ZU PRÜFEN]<\/td><\/tr><tr><td>Datenbank (Grösse, Verbindungen)<\/td><td>Infomaniak Managed DB Metriken<\/td><td>[ZU PRÜFEN]<\/td><\/tr><tr><td>LLM-Provider-Kontingente (Rate Limits, Token-Budget)<\/td><td>Provider-Dashboards<\/td><td>[ZU PRÜFEN]<\/td><\/tr><tr><td>Speicher (Backups/Exports)<\/td><td>manuell<\/td><td>[ZU PRÜFEN]<\/td><\/tr><\/tbody><\/table>\n<p><strong>Massnahme:<\/strong> Schwellwerte definieren (z. B. Disk &gt; 80 %, DB-Verbindungen &gt; 80 %) und Alerting einrichten (gemeinsam mit Dok 11).<\/p>\n<h2>3. Personal-Kapazität (kleines Team)<\/h2>\n<p>Bei 2–5 Personen ist die Personalkapazität ein erhöhtes Risiko (Schlüsselpersonen-Abhängigkeit).<\/p>\n<table><thead><tr><th>Risiko<\/th><th>Kompensierende Massnahme<\/th><\/tr><\/thead><tbody><tr><td>Ausfall einer Schlüsselperson<\/td><td>Dokumentation aller kritischen Prozesse (dieses Wiki), Zugangs-Notfallregelung<\/td><\/tr><tr><td>Wissenskonzentration<\/td><td>Vier-Augen-Prinzip, gemeinsame Reviews, dokumentierte Runbooks<\/td><\/tr><tr><td>Bei Wachstum<\/td><td>Kapazitätsplanung bei Neukunden-Onboarding<\/td><\/tr><\/tbody><\/table>\n<p><strong>[ZU PRÜFEN: Gibt es eine Vertretungs-/Notfallregelung für den alleinigen Server-Zugang?]<\/strong><\/p>\n<h2>4. Kapazitäts-Review<\/h2>\n<table><thead><tr><th>Aktivität<\/th><th>Häufigkeit<\/th><\/tr><\/thead><tbody><tr><td>Review IT-Auslastung<\/td><td>mind. quartalsweise<\/td><\/tr><tr><td>Review Personal-/Projektlast<\/td><td>laufend / bei Neukunden<\/td><\/tr><tr><td>Skalierungsentscheid Infrastruktur<\/td><td>bei Bedarf (Infomaniak skalierbar)<\/td><\/tr><\/tbody><\/table>\n<h2>5. Stand der Umsetzung / Lücken<\/h2>\n<table><thead><tr><th>Thema<\/th><th>Status<\/th><th>Massnahme<\/th><\/tr><\/thead><tbody><tr><td>Ressourcen-Monitoring mit Schwellwerten<\/td><td>[ZU PRÜFEN]<\/td><td>Einrichten<\/td><\/tr><tr><td>Schlüsselpersonen-Vertretung<\/td><td>[ZU PRÜFEN]<\/td><td>Notfallregelung dokumentieren<\/td><\/tr><tr><td>Quartals-Review<\/td><td>Neu<\/td><td>etablieren<\/td><\/tr><\/tbody><\/table>", "text": "# kapazitätsmanagement **dokumenttyp:** prozess **geltungsbereich:** personal- und it-ressourcen der porta-plattform **version:** 1.0 **status:** entwurf zur internen freigabe **owner:** geschäftsführung / betrieb **letzte aktualisierung:** 02.06.2026 **deckt ab (cacc):** 80 --- ## 1. zweck sicherstellung ausreichender personal- und it-kapazitäten für eine kontinuierliche, vereinbarungsgemässe leistungserbringung. ## 2. it-ressourcen-kapazität | ressource | überwachung | status | |---|---|---| | server-auslastung (cpu/ram/disk) | [zu prüfen: monitoring vorhanden?] | [zu prüfen] | | datenbank (grösse, verbindungen) | infomaniak managed db metriken | [zu prüfen] | | llm-provider-kontingente (rate limits, token-budget) | provider-dashboards | [zu prüfen] | | speicher (backups/exports) | manuell | [zu prüfen] | **massnahme:** schwellwerte definieren (z. b. disk > 80 %, db-verbindungen > 80 %) und alerting einrichten (gemeinsam mit dok 11). ## 3. personal-kapazität (kleines team) bei 2–5 personen ist die personalkapazität ein erhöhtes risiko (schlüsselpersonen-abhängigkeit). | risiko | kompensierende massnahme | |---|---| | ausfall einer schlüsselperson | dokumentation aller kritischen prozesse (dieses wiki), zugangs-notfallregelung | | wissenskonzentration | vier-augen-prinzip, gemeinsame reviews, dokumentierte runbooks | | bei wachstum | kapazitätsplanung bei neukunden-onboarding | **[zu prüfen: gibt es eine vertretungs-/notfallregelung für den alleinigen server-zugang?]** ## 4. kapazitäts-review | aktivität | häufigkeit | |---|---| | review it-auslastung | mind. quartalsweise | | review personal-/projektlast | laufend / bei neukunden | | skalierungsentscheid infrastruktur | bei bedarf (infomaniak skalierbar) | ## 5. stand der umsetzung / lücken | thema | status | massnahme | |---|---|---| | ressourcen-monitoring mit schwellwerten | [zu prüfen] | einrichten | | schlüsselpersonen-vertretung | [zu prüfen] | notfallregelung dokumentieren | | quartals-review | neu | etablieren | ", "nextReview": "", "overdueReview": false, "zuPruefen": ["2. IT-Ressourcen-Kapazität", "2. IT-Ressourcen-Kapazität", "2. IT-Ressourcen-Kapazität", "2. IT-Ressourcen-Kapazität", "3. Personal-Kapazität (kleines Team)", "5. Stand der Umsetzung / Lücken", "5. Stand der Umsetzung / Lücken"]}, {"id": "05_betrieb/17_Subunternehmer_Management.md", "path": "05_betrieb/17_Subunternehmer_Management.md", "chapter": "05_betrieb", "title": "Subunternehmer- und Unterauftragsverarbeiter-Management", "filename": "17_Subunternehmer_Management.md", "meta": {}, "html": "<h1>Subunternehmer- und Unterauftragsverarbeiter-Management<\/h1>\n<p><strong>Dokumenttyp:<\/strong> Prozess <strong>Geltungsbereich:<\/strong> Alle externen Dienste und Unterauftragsverarbeiter <strong>Version:<\/strong> 1.0 <strong>Status:<\/strong> Entwurf zur internen Freigabe <strong>Owner:<\/strong> Patrick Motsch (Drittdienst-Verantwortlicher) <strong>Letzte Aktualisierung:<\/strong> 02.06.2026 <strong>Deckt ab (CACC):<\/strong> 16, 31, 48, 53 <strong>Verweist auf:<\/strong> <code>drittanbieter-inventar.md<\/code><\/p>\n<hr>\n<h2>1. Basis<\/h2>\n<p>Das vollständige Inventar aller Drittdienste ist in <code>drittanbieter-inventar.md<\/code> dokumentiert (Verantwortlicher: Patrick Motsch). Dieses Dokument ergänzt die <strong>Compliance-Sicht<\/strong>: Datenschutz-Status, Datenstandort, Widerspruchsrecht und Sanktionsprüfung.<\/p>\n<h2>2. Compliance-Ergänzung zum Inventar (#48, #31)<\/h2>\n<p>Für jeden Unterauftragsverarbeiter, der Inhaltsdaten verarbeitet, sind folgende Angaben zu führen (Ergänzung zum bestehenden Inventar):<\/p>\n<table><thead><tr><th>Anbieter<\/th><th>Rolle<\/th><th>Datenstandort<\/th><th>AVV/DPA<\/th><th>EU-SCC (falls Drittland)<\/th><th>Zero-Retention<\/th><\/tr><\/thead><tbody><tr><td>OpenAI (USA)<\/td><td>LLM (primär)<\/td><td>USA<\/td><td>[ZU PRÜFEN]<\/td><td>[ZU PRÜFEN]<\/td><td>[ZU PRÜFEN: Enterprise/Opt-out]<\/td><\/tr><tr><td>Anthropic (USA)<\/td><td>LLM (alternativ)<\/td><td>USA<\/td><td>[ZU PRÜFEN]<\/td><td>[ZU PRÜFEN]<\/td><td>[ZU PRÜFEN]<\/td><\/tr><tr><td>Mistral (EU/FR)<\/td><td>LLM (alternativ)<\/td><td>EU<\/td><td>[ZU PRÜFEN]<\/td><td>n/a (EU)<\/td><td>[ZU PRÜFEN]<\/td><\/tr><tr><td>Perplexity (USA)<\/td><td>LLM + Websuche<\/td><td>USA<\/td><td>[ZU PRÜFEN]<\/td><td>[ZU PRÜFEN]<\/td><td>[ZU PRÜFEN]<\/td><\/tr><tr><td>Tavily (USA)<\/td><td>AI-Websuche<\/td><td>USA<\/td><td>[ZU PRÜFEN]<\/td><td>[ZU PRÜFEN]<\/td><td>n/a<\/td><\/tr><tr><td>Infomaniak (CH)<\/td><td>Hosting/DB<\/td><td>Schweiz<\/td><td>[ZU PRÜFEN]<\/td><td>n/a (CH)<\/td><td>n/a<\/td><\/tr><tr><td>Google Cloud (USA)<\/td><td>STT/TTS/Translate<\/td><td>USA<\/td><td>[ZU PRÜFEN]<\/td><td>[ZU PRÜFEN]<\/td><td>[ZU PRÜFEN]<\/td><\/tr><tr><td>Microsoft Azure (CH/EU)<\/td><td>Auth + E-Mail (CH-Region)<\/td><td>CH/EU<\/td><td>[ZU PRÜFEN]<\/td><td>[ZU PRÜFEN]<\/td><td>n/a<\/td><\/tr><tr><td>Stripe (USA/IE)<\/td><td>Payment<\/td><td>USA/EU<\/td><td>[ZU PRÜFEN]<\/td><td>[ZU PRÜFEN]<\/td><td>n/a<\/td><\/tr><tr><td>Twilio (USA)<\/td><td>SMS<\/td><td>USA<\/td><td>[ZU PRÜFEN]<\/td><td>[ZU PRÜFEN]<\/td><td>n/a<\/td><\/tr><\/tbody><\/table>\n<blockquote><strong>Wichtig für FINMA-Kunden:<\/strong> Inhaltsdaten gehen an den primären LLM-Provider OpenAI (USA). Für regulierte Kunden ist zu klären, ob (a) ausreichende vertragliche Absicherung (AVV + SCC + Zero-Retention) vorliegt und/oder (b) ein auf EU/CH-LLM beschränkter Betrieb angeboten wird (z. B. Mistral EU oder CH-gehostetes Modell).<\/blockquote>\n<h2>3. Widerspruchsrecht des Kunden (#16)<\/h2>\n<table><thead><tr><th>Element<\/th><th>Regelung<\/th><\/tr><\/thead><tbody><tr><td>Information über neuen wesentlichen Subunternehmer<\/td><td>30 Tage im Voraus (gemäss AGB §12.2)<\/td><\/tr><tr><td>Widerspruchsfrist Kunde<\/td><td>14 Tage, aus sachlichem Grund<\/td><\/tr><tr><td>Folge bei berechtigtem Widerspruch<\/td><td>ausserordentliches Kündigungsrecht des Kunden<\/td><\/tr><\/tbody><\/table>\n<h2>4. Weitergabe der Pflichten (#53)<\/h2>\n<p>Alle Subunternehmer werden vertraglich auf gleichwertige Sicherheits-, Datenschutz- und Vertraulichkeitspflichten verpflichtet. Kunden können diese bei Bedarf (mittelbar) auditieren.<\/p>\n<p><strong>[ZU PRÜFEN: Liegen die DPAs/AVVs der grossen Provider (OpenAI, Microsoft, Google, Stripe) abgelegt vor? Diese sind als Evidenz für das Assessment zentral.]<\/strong><\/p>\n<h2>5. Sanktionsprüfung<\/h2>\n<p>Subunternehmer werden vor Einsatz und periodisch gegen einschlägige Sanktionslisten geprüft. <strong>[ZU PRÜFEN: erfolgt das? Sonst einführen.]<\/strong><\/p>\n<h2>6. Pflege<\/h2>\n<p>Das Inventar wird bei jeder Änderung (neuer/entfallender Dienst) aktualisiert; Verantwortlich: Patrick Motsch. Review mindestens jährlich.<\/p>\n<h2>7. Stand der Umsetzung / Lücken<\/h2>\n<table><thead><tr><th>Thema<\/th><th>Status<\/th><th>Massnahme<\/th><\/tr><\/thead><tbody><tr><td>AVV/SCC/Zero-Retention je Provider<\/td><td>[ZU PRÜFEN]<\/td><td>Verträge prüfen &amp; ablegen<\/td><\/tr><tr><td>Compliance-Spalten im Inventar<\/td><td>Neu<\/td><td>ergänzen<\/td><\/tr><tr><td>Sanktionsprüfung<\/td><td>[ZU PRÜFEN]<\/td><td>einführen<\/td><\/tr><tr><td>EU/CH-only-LLM-Option für FINMA-Kunden<\/td><td>Offen<\/td><td>Entscheidung<\/td><\/tr><\/tbody><\/table>", "text": "# subunternehmer- und unterauftragsverarbeiter-management **dokumenttyp:** prozess **geltungsbereich:** alle externen dienste und unterauftragsverarbeiter **version:** 1.0 **status:** entwurf zur internen freigabe **owner:** patrick motsch (drittdienst-verantwortlicher) **letzte aktualisierung:** 02.06.2026 **deckt ab (cacc):** 16, 31, 48, 53 **verweist auf:** `drittanbieter-inventar.md` --- ## 1. basis das vollständige inventar aller drittdienste ist in `drittanbieter-inventar.md` dokumentiert (verantwortlicher: patrick motsch). dieses dokument ergänzt die **compliance-sicht**: datenschutz-status, datenstandort, widerspruchsrecht und sanktionsprüfung. ## 2. compliance-ergänzung zum inventar (#48, #31) für jeden unterauftragsverarbeiter, der inhaltsdaten verarbeitet, sind folgende angaben zu führen (ergänzung zum bestehenden inventar): | anbieter | rolle | datenstandort | avv/dpa | eu-scc (falls drittland) | zero-retention | |---|---|---|---|---|---| | openai (usa) | llm (primär) | usa | [zu prüfen] | [zu prüfen] | [zu prüfen: enterprise/opt-out] | | anthropic (usa) | llm (alternativ) | usa | [zu prüfen] | [zu prüfen] | [zu prüfen] | | mistral (eu/fr) | llm (alternativ) | eu | [zu prüfen] | n/a (eu) | [zu prüfen] | | perplexity (usa) | llm + websuche | usa | [zu prüfen] | [zu prüfen] | [zu prüfen] | | tavily (usa) | ai-websuche | usa | [zu prüfen] | [zu prüfen] | n/a | | infomaniak (ch) | hosting/db | schweiz | [zu prüfen] | n/a (ch) | n/a | | google cloud (usa) | stt/tts/translate | usa | [zu prüfen] | [zu prüfen] | [zu prüfen] | | microsoft azure (ch/eu) | auth + e-mail (ch-region) | ch/eu | [zu prüfen] | [zu prüfen] | n/a | | stripe (usa/ie) | payment | usa/eu | [zu prüfen] | [zu prüfen] | n/a | | twilio (usa) | sms | usa | [zu prüfen] | [zu prüfen] | n/a | > **wichtig für finma-kunden:** inhaltsdaten gehen an den primären llm-provider openai (usa). für regulierte kunden ist zu klären, ob (a) ausreichende vertragliche absicherung (avv + scc + zero-retention) vorliegt und/oder (b) ein auf eu/ch-llm beschränkter betrieb angeboten wird (z. b. mistral eu oder ch-gehostetes modell). ## 3. widerspruchsrecht des kunden (#16) | element | regelung | |---|---| | information über neuen wesentlichen subunternehmer | 30 tage im voraus (gemäss agb §12.2) | | widerspruchsfrist kunde | 14 tage, aus sachlichem grund | | folge bei berechtigtem widerspruch | ausserordentliches kündigungsrecht des kunden | ## 4. weitergabe der pflichten (#53) alle subunternehmer werden vertraglich auf gleichwertige sicherheits-, datenschutz- und vertraulichkeitspflichten verpflichtet. kunden können diese bei bedarf (mittelbar) auditieren. **[zu prüfen: liegen die dpas/avvs der grossen provider (openai, microsoft, google, stripe) abgelegt vor? diese sind als evidenz für das assessment zentral.]** ## 5. sanktionsprüfung subunternehmer werden vor einsatz und periodisch gegen einschlägige sanktionslisten geprüft. **[zu prüfen: erfolgt das? sonst einführen.]** ## 6. pflege das inventar wird bei jeder änderung (neuer/entfallender dienst) aktualisiert; verantwortlich: patrick motsch. review mindestens jährlich. ## 7. stand der umsetzung / lücken | thema | status | massnahme | |---|---|---| | avv/scc/zero-retention je provider | [zu prüfen] | verträge prüfen & ablegen | | compliance-spalten im inventar | neu | ergänzen | | sanktionsprüfung | [zu prüfen] | einführen | | eu/ch-only-llm-option für finma-kunden | offen | entscheidung | ", "nextReview": "", "overdueReview": false, "zuPruefen": ["2. Compliance-Ergänzung zum Inventar (#48, #31)", "2. Compliance-Ergänzung zum Inventar (#48, #31)", "2. Compliance-Ergänzung zum Inventar (#48, #31)", "2. Compliance-Ergänzung zum Inventar (#48, #31)", "2. Compliance-Ergänzung zum Inventar (#48, #31)", "2. Compliance-Ergänzung zum Inventar (#48, #31)", "2. Compliance-Ergänzung zum Inventar (#48, #31)", "2. Compliance-Ergänzung zum Inventar (#48, #31)", "2. Compliance-Ergänzung zum Inventar (#48, #31)", "2. Compliance-Ergänzung zum Inventar (#48, #31)", "4. Weitergabe der Pflichten (#53)", "5. Sanktionsprüfung", "7. Stand der Umsetzung / Lücken", "7. Stand der Umsetzung / Lücken"]}, {"id": "05_betrieb/18_Analyse_Recht_und_BestPractice.md", "path": "05_betrieb/18_Analyse_Recht_und_BestPractice.md", "chapter": "05_betrieb", "title": "Analyse: Rechtliche Aspekte und Best Practices", "filename": "18_Analyse_Recht_und_BestPractice.md", "meta": {}, "html": "<h1>Analyse: Rechtliche Aspekte und Best Practices<\/h1>\n<p><strong>Dokumenttyp:<\/strong> Befund- und Risikobericht (intern) <strong>Geltungsbereich:<\/strong> Gesamtes e-compliance-Wiki (PORTA-Plattform) <strong>Version:<\/strong> 1.0 <strong>Stand:<\/strong> 01.02.2026 <strong>Erstellt für:<\/strong> PowerOn AG, Birmensdorferstrasse 94, 8003 Zürich (CHE-491.960.195) <strong>Ansprechpartner:<\/strong> Patrick Motsch — p.motsch@poweron.swiss<\/p>\n<blockquote><strong>Hinweis:<\/strong> Dieser Bericht ersetzt keine anwaltliche Beratung. Er dokumentiert den Stand der Wiki-Dokumentation nach der Firmendaten-Anpassung und benennt Lücken sowie Widersprüche zwischen vertraglichen Zusicherungen (AGB) und beschriebenem Umsetzungsstand.<\/blockquote>\n<hr>\n<h2>1. Durchgeführte Anpassungen (01.02.2026)<\/h2>\n<table><thead><tr><th>Massnahme<\/th><th>Umfang<\/th><\/tr><\/thead><tbody><tr><td>Rechtsträger<\/td><td><code>PowerON GmbH<\/code> → <strong>PowerOn AG<\/strong> (CHE-491.960.195)<\/td><\/tr><tr><td>Markenschreibweise<\/td><td><code>PowerON<\/code> → <strong>PowerOn<\/strong> in AGB und allen <code>legal/<\/code>-Dokumenten<\/td><\/tr><tr><td>Stammdaten AGB §1.1<\/td><td>Birmensdorferstrasse 94, 8003 Zürich, p.motsch@poweron.swiss<\/td><\/tr><tr><td>Gerichtsstand AGB §23.2<\/td><td>Zürich, Schweiz<\/td><\/tr><tr><td>Datumsfelder AGB<\/td><td>Stand / Gilt ab / Anhänge: <strong>01.02.2026<\/strong>; nächste Überprüfung: <strong>01.02.2027<\/strong><\/td><\/tr><tr><td>Ansprechpartner/Rollen<\/td><td>Patrick Motsch in offenen Namens-/Kontaktfeldern (Dok. 01, 02, 06, 07)<\/td><\/tr><\/tbody><\/table>\n<p><strong>Nicht geändert (bewusst):<\/strong> Inhaltliche AGB-Zusicherungen; technische <code>[ZU PRÜFEN]<\/code>-Fakten (At-Rest, Pentest-Nachweis etc.). MFA auf Admin-/Server-Zugängen seit Juni 2026 umgesetzt.<\/p>\n<hr>\n<h2>2. Rechtlicher Rahmen<\/h2>\n<h3>2.1 Anwendbares Recht<\/h3>\n<table><thead><tr><th>Rechtsgebiet<\/th><th>Relevanz in der Dokumentation<\/th><\/tr><\/thead><tbody><tr><td><strong>Schweizer DSG<\/strong> (revDSG)<\/td><td>Primärrecht für Daten in der Schweiz; AGB §6.4, security-overview Kap. 9.2<\/td><\/tr><tr><td><strong>DSGVO<\/strong><\/td><td>Anwendbar bei EU-Betroffenen / grenzüberschreitender Verarbeitung; Betroffenenrechte in security-overview<\/td><\/tr><tr><td><strong>FINMA-Rundschreiben 2018/3, 2023/1<\/strong><\/td><td>Auslagerung an Cloud/IT-Dienstleister; CACC-Mapping in <code>00_README_Prozessuebersicht.md<\/code><\/td><\/tr><tr><td><strong>Bankgeheimnis (Art. 47 BankG)<\/strong><\/td><td>AGB §13.2; erhöhter Schutz für Berufsgeheimnisdaten<\/td><\/tr><tr><td><strong>Berufsgeheimnis StGB (Art. 321)<\/strong><\/td><td>Medizinische/sonstige Berufsgeheimnisse; gleiche Behandlung wie Bankdaten in AGB<\/td><\/tr><tr><td><strong>Schweizer Obligationenrecht / ZGB<\/strong><\/td><td>B2B-Verträge, AGB-Geltung, Gerichtsstand Zürich<\/td><\/tr><\/tbody><\/table>\n<h3>2.2 Vertragshierarchie (AGB §1.4)<\/h3>\n<ol><li>Individueller Dienstleistungsvertrag<\/li><li>AVV (Auftragsverarbeitungsvertrag)<\/li><li>SLA<\/li><li>AGB<\/li><li>Anhänge A, B, C<\/li><\/ol>\n<p><strong>Empfehlung:<\/strong> Für FINMA-regulierte Kunden immer individuellen Vertrag + AVV abschliessen; AGB allein genügt regulatorisch nicht.<\/p>\n<h3>2.3 Auftragsverarbeitung und Drittlandtransfers<\/h3>\n<ul><li><strong>Speicherung Inhaltsdaten:<\/strong> Schweiz (Infomaniak) — konsistent dokumentiert.<\/li><li><strong>LLM-Verarbeitung:<\/strong> Primär OpenAI (USA) — temporärer Datenabfluss; erfordert AVV/DPA, EU-SCC, TIA, Zero-Data-Retention (<code>17_Subunternehmer_Management.md<\/code>, AGB §7.2).<\/li><li><strong>Neutralisierung:<\/strong> Technisches Modul reduziert PII vor externem LLM-Call (<code>neutralisierung-detail.md<\/code>); nicht standardmässig für alle Tenants aktiv (<code>security-overview.md<\/code> Kap. 7.6).<\/li><\/ul>\n<h3>2.4 Melde- und Auditpflichten<\/h3>\n<table><thead><tr><th>Pflicht<\/th><th>AGB / CACC<\/th><th>Umsetzungsdokument<\/th><\/tr><\/thead><tbody><tr><td>24h-Meldung Cyberangriffe<\/td><td>AGB §14, CACC #19<\/td><td><code>07_Incident_Response_und_Meldewesen.md<\/code><\/td><\/tr><tr><td>FINMA-Drittbegünstigung<\/td><td>AGB §17.2<\/td><td>Prozess neu dokumentiert<\/td><\/tr><tr><td>Audit-Rechte (vollständige Berichte)<\/td><td>AGB §17.3<\/td><td><code>10_Schwachstellenmanagement.md<\/code> — Pentest fehlt<\/td><\/tr><\/tbody><\/table>\n<hr>\n<h2>3. Best-Practice-Einordnung<\/h2>\n<h3>3.1 Stärken (implementiert / dokumentiert)<\/h3>\n<table><thead><tr><th>Bereich<\/th><th>Status<\/th><th>Nachweis<\/th><\/tr><\/thead><tbody><tr><td>DSGVO-Betroffenenrechte (Self-Service)<\/td><td>Implementiert<\/td><td><code>security-overview.md<\/code> Kap. 2<\/td><\/tr><tr><td>Mandantentrennung (logisch)<\/td><td>Implementiert<\/td><td><code>security-overview.md<\/code> Kap. 3<\/td><\/tr><tr><td>RBAC<\/td><td>Implementiert<\/td><td><code>security-overview.md<\/code> Kap. 4<\/td><\/tr><tr><td>Parametrisierte DB-Queries, CSRF, Rate Limiting<\/td><td>Implementiert<\/td><td><code>security-overview.md<\/code> Kap. 6<\/td><\/tr><tr><td>Change Management / Vier-Augen<\/td><td>Dokumentiert<\/td><td><code>feature_release_bugfix.md<\/code>, <code>08_Change_Management.md<\/code><\/td><\/tr><tr><td>Fail-safe Neutralisierung<\/td><td>Konzept + Code-Karte<\/td><td><code>neutralisierung-detail.md<\/code><\/td><\/tr><tr><td>Drittanbieter-Inventar<\/td><td>Vollständig<\/td><td><code>drittanbieter-inventar.md<\/code><\/td><\/tr><tr><td>BCM-Runbook (operativ)<\/td><td>Vorhanden<\/td><td><code>bcm_runbook.md<\/code><\/td><\/tr><tr><td>JSON-Export / Exit<\/td><td>Vorhanden<\/td><td><code>datenbank-handling.md<\/code>, <code>14_Exit_und_Transition.md<\/code><\/td><\/tr><\/tbody><\/table>\n<h3>3.2 Lücken (transparent benannt)<\/h3>\n<table><thead><tr><th>Thema<\/th><th>Risiko<\/th><th>Quelle<\/th><\/tr><\/thead><tbody><tr><td>Keine ISO 27001-Zertifizierung<\/td><td>Mittel — AGB spricht von «Streben»<\/td><td>AGB §8.1, <code>01_Informationssicherheitsrichtlinie.md<\/code><\/td><\/tr><tr><td>Kein granulares Consent-Management<\/td><td>Mittel (Art. 7 DSGVO)<\/td><td><code>security-overview.md<\/code> Kap. 2.6<\/td><\/tr><tr><td>PII-Filter nicht Standard<\/td><td>Hoch bei sensiblen Daten<\/td><td><code>security-overview.md<\/code> Kap. 7.6<\/td><\/tr><tr><td>Kein SIEM / 7×24-SOC<\/td><td>Hoch für FINMA-Kunden<\/td><td><code>11_Logging_und_Monitoring.md<\/code><\/td><\/tr><tr><td>Geteilter SSH-User <code>ubuntu<\/code><\/td><td>Hoch — fehlende Personen-Nachvollziehbarkeit<\/td><td><code>02_Zugriffsmanagement_IAM_PAM.md<\/code><\/td><\/tr><tr><td>Log-Integrität (kein write-once)<\/td><td>Hoch<\/td><td><code>11_Logging_und_Monitoring.md<\/code><\/td><\/tr><tr><td>Kein externer Pentest-Nachweis<\/td><td>Hoch — widerspricht AGB<\/td><td><code>10_Schwachstellenmanagement.md<\/code><\/td><\/tr><tr><td>AVV/SCC bei LLM-Providern ungeklärt<\/td><td>Hoch<\/td><td><code>17_Subunternehmer_Management.md<\/code><\/td><\/tr><\/tbody><\/table>\n<h3>3.3 OWASP / ISO 27001<\/h3>\n<p>Die Plattform adressiert OWASP Top 10 präventiv (<code>security-overview.md<\/code> Kap. 9.3), ohne formale Zertifizierung. Die <code>legal/<\/code>-Prozesse bilden eine <strong>Grundlage für ISMS<\/strong> nach ISO 27001, sind aber grösstenteils im Status «Entwurf» mit vielen <code>[ZU PRÜFEN]<\/code>-Markierungen.<\/p>\n<hr>\n<h2>4. Widersprüche: AGB-Zusicherung vs. dokumentierter Umsetzungsstand<\/h2>\n<blockquote>Die AGB wurden inhaltlich <strong>nicht<\/strong> abgeschwächt. Die folgenden Punkte sind <strong>Compliance-Risiken<\/strong>, solange der Umsetzungsstand nicht angeglichen wird.<\/blockquote>\n<h3>4.1 Verschlüsselung at-rest (AGB §9.1, Anhang C)<\/h3>\n<table><thead><tr><th><\/th><th>AGB<\/th><th>Dokumentierter Stand<\/th><\/tr><\/thead><tbody><tr><td>Zusage<\/td><td>Alle Inhaltsdaten AES-256 at rest<\/td><td><code>[ZU PRÜFEN]<\/code> Infomaniak DB; JSON-Exporte <strong>unverschlüsselt<\/strong><\/td><\/tr><tr><td>Referenz<\/td><td><code>20260603_PowerON_AGB_v1.0_1.md<\/code> §9.1<\/td><td><code>04_Verschluesselung_und_Schluesselmanagement.md<\/code> §2; <code>security-overview.md<\/code> §5.1 (nur Secrets)<\/td><\/tr><\/tbody><\/table>\n<p><strong>Empfehlung:<\/strong> At-Rest bei Infomaniak verifizieren und dokumentieren; Export-Verschlüsselung (AES-256/GPG) einführen; ggf. AGB-Formulierung präzisieren («Inhaltsdaten in der Produktiv-DB» vs. «Backup-Exporte»).<\/p>\n<h3>4.2 Penetrationstests (AGB §8.4)<\/h3>\n<table><thead><tr><th><\/th><th>AGB<\/th><th>Dokumentierter Stand<\/th><\/tr><\/thead><tbody><tr><td>Zusage<\/td><td>Jährlich, unabhängig, volle Berichte auf Anfrage<\/td><td>«Bisher keine externen Pentest-Berichte»<\/td><\/tr><tr><td>Referenz<\/td><td>AGB §8.4<\/td><td><code>10_Schwachstellenmanagement.md<\/code> §4<\/td><\/tr><\/tbody><\/table>\n<p><strong>Empfehlung:<\/strong> Jährlichen Pentest beauftragen; Bericht archivieren; oder AGB-Frist erst nach erstem Test aktivieren.<\/p>\n<h3>4.3 RTO / RPO (AGB Anhang B)<\/h3>\n<table><thead><tr><th><\/th><th>AGB<\/th><th>Dokumentierter Stand<\/th><\/tr><\/thead><tbody><tr><td>Zusage<\/td><td>RTO ≤ 4 h, RPO ≤ 1 h<\/td><td>Wöchentliche Export-Praxis; RPO eher ≤ 24 h<\/td><\/tr><tr><td>Referenz<\/td><td>Anhang B<\/td><td><code>05_Backup_und_Wiederherstellung.md<\/code> §4<\/td><\/tr><\/tbody><\/table>\n<p><strong>Empfehlung:<\/strong> Backup-Frequenz erhöhen (täglich inkrementell) oder SLA/AGB-Werte an reale Kapazität anpassen.<\/p>\n<h3>4.4 Geografisch getrenntes Backup-RZ (AGB §11.2)<\/h3>\n<table><thead><tr><th><\/th><th>AGB<\/th><th>Dokumentierter Stand<\/th><\/tr><\/thead><tbody><tr><td>Zusage<\/td><td>Backup-RZ in der Schweiz, geografisch getrennt<\/td><td><code>[ZU PRÜFEN]<\/code> — nur Infomaniak-Umgebung<\/td><\/tr><tr><td>Referenz<\/td><td>AGB §11.2<\/td><td><code>06_Business_Continuity_und_Disaster_Recovery.md<\/code> §6<\/td><\/tr><\/tbody><\/table>\n<p><strong>Empfehlung:<\/strong> Infomaniak-Region/Snapshot-Standort klären; Evidenz beilegen.<\/p>\n<h3>4.5 MFA und Logging (AGB Anhang C)<\/h3>\n<table><thead><tr><th><\/th><th>AGB<\/th><th>Dokumentierter Stand<\/th><\/tr><\/thead><tbody><tr><td>Zusage<\/td><td>MFA verpflichtend; Logs 3 Jahre, write-once, Kundenzugang<\/td><td>MFA <strong>umgesetzt<\/strong> (Admin/Server, Juni 2026); kein write-once; SIEM offen<\/td><\/tr><tr><td>Referenz<\/td><td>Anhang C<\/td><td><code>02_Zugriffsmanagement_IAM_PAM.md<\/code>, <code>11_Logging_und_Monitoring.md<\/code><\/td><\/tr><\/tbody><\/table>\n<p><strong>Empfehlung:<\/strong> Log-Shipping auf append-only Storage; leichtgewichtiges Alerting. MFA Admin/Server erledigt (Juni 2026).<\/p>\n<h3>4.6 Produktivdaten in Testumgebung (CACC #102)<\/h3>\n<table><thead><tr><th><\/th><th>Anforderung<\/th><th>Dokumentierter Stand<\/th><\/tr><\/thead><tbody><tr><td>Verbot<\/td><td>Keine Berufsgeheimnisdaten in Dev/Test<\/td><td>Prod→Int-Migration als Regelfall beschrieben<\/td><\/tr><tr><td>Referenz<\/td><td><code>15_Sichere_Softwareentwicklung_SDLC.md<\/code> §4<\/td><td><code>datenbank-handling.md<\/code> §3<\/td><\/tr><\/tbody><\/table>\n<p><strong>Empfehlung:<\/strong> Option A (Anonymisierung) oder B (synthetische Daten); <code>datenbank-handling.md<\/code> anpassen — <strong>kritisch für FINMA-Assessment<\/strong>.<\/p>\n<h3>4.7 Anhang A: Rechenzentrumsbetreiber<\/h3>\n<table><thead><tr><th><\/th><th>AGB Anhang A<\/th><th>Übrige Dokumente<\/th><\/tr><\/thead><tbody><tr><td>Stand<\/td><td><code>[RZ-Anbieter primär]<\/code> Platzhalter<\/td><td><strong>Infomaniak<\/strong> (Schweiz) klar benannt<\/td><\/tr><tr><td>Referenz<\/td><td>AGB Anhang A §A.1<\/td><td><code>00_README<\/code>, <code>drittanbieter-inventar.md<\/code><\/td><\/tr><\/tbody><\/table>\n<p><strong>Empfehlung:<\/strong> Anhang A mit Infomaniak (primär + DR-Standort) füllen — keine inhaltliche AGB-Änderung der Zusagen, nur Vervollständigung.<\/p>\n<hr>\n<h2>5. Priorisierte Massnahmenliste<\/h2>\n<table><thead><tr><th>Prio<\/th><th>Massnahme<\/th><th>Aufwand<\/th><th>Rechtliches Risiko<\/th><\/tr><\/thead><tbody><tr><td>P1<\/td><td>AVV/DPA + SCC + Zero-Retention mit OpenAI (und weiteren LLM-Providern) abschliessen und ablegen<\/td><td>Mittel<\/td><td>Hoch<\/td><\/tr><tr><td>P1<\/td><td>Prod-Daten in Test: Prozess ändern (Anonymisierung/synthetisch)<\/td><td>Mittel<\/td><td>Hoch (FINMA)<\/td><\/tr><tr><td>P1<\/td><td>Backup-Exporte verschlüsseln<\/td><td>Gering<\/td><td>Hoch<\/td><\/tr><tr><td>P2<\/td><td>Externen Pentest beauftragen (jährlich)<\/td><td>Mittel<\/td><td>Hoch (AGB §8.4)<\/td><\/tr><tr><td>~~P2~~<\/td><td>~~MFA auf privilegierten Zugängen~~<\/td><td>—<\/td><td><strong>Erledigt<\/strong> (Juni 2026)<\/td><\/tr><tr><td>P2<\/td><td>RTO/RPO mit Backup-Frequenz abgleichen<\/td><td>Mittel<\/td><td>Mittel (Vertrag)<\/td><\/tr><tr><td>P2<\/td><td>Anhang A: Infomaniak eintragen<\/td><td>Gering<\/td><td>Gering<\/td><\/tr><tr><td>P3<\/td><td>Personalisierte SSH-Accounts oder Sitzungsprotokollierung<\/td><td>Mittel<\/td><td>Mittel<\/td><\/tr><tr><td>P3<\/td><td>Log-Integrität (append-only / separates Log-Storage)<\/td><td>Mittel<\/td><td>Mittel<\/td><\/tr><tr><td>P3<\/td><td>Automatisches Uptime-Monitoring + Alerting<\/td><td>Gering<\/td><td>Mittel<\/td><\/tr><tr><td>P3<\/td><td>Strafregisterauszug / NDAs für alle Mitarbeitenden verifizieren<\/td><td>Gering<\/td><td>Mittel<\/td><\/tr><tr><td>P3<\/td><td>ISO-27001-Zertifizierung planen oder AGB-Formulierung «strebt an» beibehalten<\/td><td>Hoch<\/td><td>Niedrig (wenn ehrlich kommuniziert)<\/td><\/tr><\/tbody><\/table>\n<hr>\n<h2>6. Offene Punkte zur Klärung (Rückfragen an PowerOn AG)<\/h2>\n<p>Die folgenden Punkte konnten aus den Dokumenten <strong>nicht<\/strong> verifiziert werden und sollten intern geklärt werden:<\/p>\n<ol><li><strong>Telefonnummer<\/strong> für Incident-Rufbereitschaft (aktuell nur E-Mail Patrick Motsch).<\/li><li><strong>Trennung Rollen:<\/strong> Patrick Motsch trägt alle Rollen (CISO, DPO, GF, DevOps) — für Audits ggf. formale Zuordnung oder externe DPO-Unterstützung erwägen.<\/li><li><strong>Infomaniak:<\/strong> At-Rest-Verschlüsselung, DR-Region, ISO-Zertifikate als PDF beilegen.<\/li><li><strong>OpenAI:<\/strong> Enterprise-Tier mit Training-Opt-out — Vertragsversion und Speicherort dokumentieren.<\/li><li><strong>Schweizer/EU-only LLM<\/strong> für FINMA-Kunden: Ist Mistral EU oder self-hosted Modell produktiv anbietbar?<\/li><li><strong>Legal Hold:<\/strong> Technische Funktion vorhanden oder nur manuelle Prozedur?<\/li><li><strong>Kundenzugang zu Logs:<\/strong> API/Export pro Mandant geplant?<\/li><li><strong>BYOK:<\/strong> Angebot gewünscht für regulierte Kunden?<\/li><li><strong>Rechtliche Prüfung AGB<\/strong> durch Fachanwalt vor Veröffentlichung gegenüber Bankkunden.<\/li><li><strong>Weitere Ansprechpartner<\/strong> bei Team-Wachstum (Vertretung Schlüsselperson).<\/li><\/ol>\n<hr>\n<h2>7. Dokumentenübersicht (Stand nach Anpassung)<\/h2>\n<table><thead><tr><th>Datei<\/th><th>Rolle<\/th><\/tr><\/thead><tbody><tr><td><code>20260603_PowerON_AGB_v1.0_1.md<\/code><\/td><td>Vertragsgrundlage B2B (Stammdaten aktualisiert)<\/td><\/tr><tr><td><code>security-overview.md<\/code><\/td><td>Kundeninformation Sicherheit/Datenschutz<\/td><\/tr><tr><td><code>neutralisierung-detail.md<\/code><\/td><td>Technisches Datenschutz-Modul<\/td><\/tr><tr><td><code>legal/00<\/code>–<code>17<\/code><\/td><td>CACC/FINMA-Prozessdokumentation<\/td><\/tr><tr><td><strong><code>legal/18_Analyse_Recht_und_BestPractice.md<\/code><\/strong><\/td><td>Dieser Befundbericht<\/td><\/tr><\/tbody><\/table>\n<hr>\n<p><em>Nächste planmässige Überprüfung dieses Berichts: 01.02.2027 oder nach wesentlicher Änderung an AGB, Infrastruktur oder regulatorischen Anforderungen.<\/em><\/p>", "text": "# analyse: rechtliche aspekte und best practices **dokumenttyp:** befund- und risikobericht (intern) **geltungsbereich:** gesamtes e-compliance-wiki (porta-plattform) **version:** 1.0 **stand:** 01.02.2026 **erstellt für:** poweron ag, birmensdorferstrasse 94, 8003 zürich (che-491.960.195) **ansprechpartner:** patrick motsch — p.motsch@poweron.swiss > **hinweis:** dieser bericht ersetzt keine anwaltliche beratung. er dokumentiert den stand der wiki-dokumentation nach der firmendaten-anpassung und benennt lücken sowie widersprüche zwischen vertraglichen zusicherungen (agb) und beschriebenem umsetzungsstand. --- ## 1. durchgeführte anpassungen (01.02.2026) | massnahme | umfang | |---|---| | rechtsträger | `poweron gmbh` → **poweron ag** (che-491.960.195) | | markenschreibweise | `poweron` → **poweron** in agb und allen `legal/`-dokumenten | | stammdaten agb §1.1 | birmensdorferstrasse 94, 8003 zürich, p.motsch@poweron.swiss | | gerichtsstand agb §23.2 | zürich, schweiz | | datumsfelder agb | stand / gilt ab / anhänge: **01.02.2026**; nächste überprüfung: **01.02.2027** | | ansprechpartner/rollen | patrick motsch in offenen namens-/kontaktfeldern (dok. 01, 02, 06, 07) | **nicht geändert (bewusst):** inhaltliche agb-zusicherungen; technische `[zu prüfen]`-fakten (at-rest, pentest-nachweis etc.). mfa auf admin-/server-zugängen seit juni 2026 umgesetzt. --- ## 2. rechtlicher rahmen ### 2.1 anwendbares recht | rechtsgebiet | relevanz in der dokumentation | |---|---| | **schweizer dsg** (revdsg) | primärrecht für daten in der schweiz; agb §6.4, security-overview kap. 9.2 | | **dsgvo** | anwendbar bei eu-betroffenen / grenzüberschreitender verarbeitung; betroffenenrechte in security-overview | | **finma-rundschreiben 2018/3, 2023/1** | auslagerung an cloud/it-dienstleister; cacc-mapping in `00_readme_prozessuebersicht.md` | | **bankgeheimnis (art. 47 bankg)** | agb §13.2; erhöhter schutz für berufsgeheimnisdaten | | **berufsgeheimnis stgb (art. 321)** | medizinische/sonstige berufsgeheimnisse; gleiche behandlung wie bankdaten in agb | | **schweizer obligationenrecht / zgb** | b2b-verträge, agb-geltung, gerichtsstand zürich | ### 2.2 vertragshierarchie (agb §1.4) 1. individueller dienstleistungsvertrag 2. avv (auftragsverarbeitungsvertrag) 3. sla 4. agb 5. anhänge a, b, c **empfehlung:** für finma-regulierte kunden immer individuellen vertrag + avv abschliessen; agb allein genügt regulatorisch nicht. ### 2.3 auftragsverarbeitung und drittlandtransfers - **speicherung inhaltsdaten:** schweiz (infomaniak) — konsistent dokumentiert. - **llm-verarbeitung:** primär openai (usa) — temporärer datenabfluss; erfordert avv/dpa, eu-scc, tia, zero-data-retention (`17_subunternehmer_management.md`, agb §7.2). - **neutralisierung:** technisches modul reduziert pii vor externem llm-call (`neutralisierung-detail.md`); nicht standardmässig für alle tenants aktiv (`security-overview.md` kap. 7.6). ### 2.4 melde- und auditpflichten | pflicht | agb / cacc | umsetzungsdokument | |---|---|---| | 24h-meldung cyberangriffe | agb §14, cacc #19 | `07_incident_response_und_meldewesen.md` | | finma-drittbegünstigung | agb §17.2 | prozess neu dokumentiert | | audit-rechte (vollständige berichte) | agb §17.3 | `10_schwachstellenmanagement.md` — pentest fehlt | --- ## 3. best-practice-einordnung ### 3.1 stärken (implementiert / dokumentiert) | bereich | status | nachweis | |---|---|---| | dsgvo-betroffenenrechte (self-service) | implementiert | `security-overview.md` kap. 2 | | mandantentrennung (logisch) | implementiert | `security-overview.md` kap. 3 | | rbac | implementiert | `security-overview.md` kap. 4 | | parametrisierte db-queries, csrf, rate limiting | implementiert | `security-overview.md` kap. 6 | | change management / vier-augen | dokumentiert | `feature_release_bugfix.md`, `08_change_management.md` | | fail-safe neutralisierung | konzept + code-karte | `neutralisierung-detail.md` | | drittanbieter-inventar | vollständig | `drittanbieter-inventar.md` | | bcm-runbook (operativ) | vorhanden | `bcm_runbook.md` | | json-export / exit | vorhanden | `datenbank-handling.md`, `14_exit_und_transition.md` | ### 3.2 lücken (transparent benannt) | thema | risiko | quelle | |---|---|---| | keine iso 27001-zertifizierung | mittel — agb spricht von «streben» | agb §8.1, `01_informationssicherheitsrichtlinie.md` | | kein granulares consent-management | mittel (art. 7 dsgvo) | `security-overview.md` kap. 2.6 | | pii-filter nicht standard | hoch bei sensiblen daten | `security-overview.md` kap. 7.6 | | kein siem / 7×24-soc | hoch für finma-kunden | `11_logging_und_monitoring.md` | | geteilter ssh-user `ubuntu` | hoch — fehlende personen-nachvollziehbarkeit | `02_zugriffsmanagement_iam_pam.md` | | log-integrität (kein write-once) | hoch | `11_logging_und_monitoring.md` | | kein externer pentest-nachweis | hoch — widerspricht agb | `10_schwachstellenmanagement.md` | | avv/scc bei llm-providern ungeklärt | hoch | `17_subunternehmer_management.md` | ### 3.3 owasp / iso 27001 die plattform adressiert owasp top 10 präventiv (`security-overview.md` kap. 9.3), ohne formale zertifizierung. die `legal/`-prozesse bilden eine **grundlage für isms** nach iso 27001, sind aber grösstenteils im status «entwurf» mit vielen `[zu prüfen]`-markierungen. --- ## 4. widersprüche: agb-zusicherung vs. dokumentierter umsetzungsstand > die agb wurden inhaltlich **nicht** abgeschwächt. die folgenden punkte sind **compliance-risiken**, solange der umsetzungsstand nicht angeglichen wird. ### 4.1 verschlüsselung at-rest (agb §9.1, anhang c) | | agb | dokumentierter stand | |---|---|---| | zusage | alle inhaltsdaten aes-256 at rest | `[zu prüfen]` infomaniak db; json-exporte **unverschlüsselt** | | referenz | `20260603_poweron_agb_v1.0_1.md` §9.1 | `04_verschluesselung_und_schluesselmanagement.md` §2; `security-overview.md` §5.1 (nur secrets) | **empfehlung:** at-rest bei infomaniak verifizieren und dokumentieren; export-verschlüsselung (aes-256/gpg) einführen; ggf. agb-formulierung präzisieren («inhaltsdaten in der produktiv-db» vs. «backup-exporte»). ### 4.2 penetrationstests (agb §8.4) | | agb | dokumentierter stand | |---|---|---| | zusage | jährlich, unabhängig, volle berichte auf anfrage | «bisher keine externen pentest-berichte» | | referenz | agb §8.4 | `10_schwachstellenmanagement.md` §4 | **empfehlung:** jährlichen pentest beauftragen; bericht archivieren; oder agb-frist erst nach erstem test aktivieren. ### 4.3 rto / rpo (agb anhang b) | | agb | dokumentierter stand | |---|---|---| | zusage | rto ≤ 4 h, rpo ≤ 1 h | wöchentliche export-praxis; rpo eher ≤ 24 h | | referenz | anhang b | `05_backup_und_wiederherstellung.md` §4 | **empfehlung:** backup-frequenz erhöhen (täglich inkrementell) oder sla/agb-werte an reale kapazität anpassen. ### 4.4 geografisch getrenntes backup-rz (agb §11.2) | | agb | dokumentierter stand | |---|---|---| | zusage | backup-rz in der schweiz, geografisch getrennt | `[zu prüfen]` — nur infomaniak-umgebung | | referenz | agb §11.2 | `06_business_continuity_und_disaster_recovery.md` §6 | **empfehlung:** infomaniak-region/snapshot-standort klären; evidenz beilegen. ### 4.5 mfa und logging (agb anhang c) | | agb | dokumentierter stand | |---|---|---| | zusage | mfa verpflichtend; logs 3 jahre, write-once, kundenzugang | mfa **umgesetzt** (admin/server, juni 2026); kein write-once; siem offen | | referenz | anhang c | `02_zugriffsmanagement_iam_pam.md`, `11_logging_und_monitoring.md` | **empfehlung:** log-shipping auf append-only storage; leichtgewichtiges alerting. mfa admin/server erledigt (juni 2026). ### 4.6 produktivdaten in testumgebung (cacc #102) | | anforderung | dokumentierter stand | |---|---|---| | verbot | keine berufsgeheimnisdaten in dev/test | prod→int-migration als regelfall beschrieben | | referenz | `15_sichere_softwareentwicklung_sdlc.md` §4 | `datenbank-handling.md` §3 | **empfehlung:** option a (anonymisierung) oder b (synthetische daten); `datenbank-handling.md` anpassen — **kritisch für finma-assessment**. ### 4.7 anhang a: rechenzentrumsbetreiber | | agb anhang a | übrige dokumente | |---|---|---| | stand | `[rz-anbieter primär]` platzhalter | **infomaniak** (schweiz) klar benannt | | referenz | agb anhang a §a.1 | `00_readme`, `drittanbieter-inventar.md` | **empfehlung:** anhang a mit infomaniak (primär + dr-standort) füllen — keine inhaltliche agb-änderung der zusagen, nur vervollständigung. --- ## 5. priorisierte massnahmenliste | prio | massnahme | aufwand | rechtliches risiko | |:---:|---|---|---| | p1 | avv/dpa + scc + zero-retention mit openai (und weiteren llm-providern) abschliessen und ablegen | mittel | hoch | | p1 | prod-daten in test: prozess ändern (anonymisierung/synthetisch) | mittel | hoch (finma) | | p1 | backup-exporte verschlüsseln | gering | hoch | | p2 | externen pentest beauftragen (jährlich) | mittel | hoch (agb §8.4) | | ~~p2~~ | ~~mfa auf privilegierten zugängen~~ | — | **erledigt** (juni 2026) | | p2 | rto/rpo mit backup-frequenz abgleichen | mittel | mittel (vertrag) | | p2 | anhang a: infomaniak eintragen | gering | gering | | p3 | personalisierte ssh-accounts oder sitzungsprotokollierung | mittel | mittel | | p3 | log-integrität (append-only / separates log-storage) | mittel | mittel | | p3 | automatisches uptime-monitoring + alerting | gering | mittel | | p3 | strafregisterauszug / ndas für alle mitarbeitenden verifizieren | gering | mittel | | p3 | iso-27001-zertifizierung planen oder agb-formulierung «strebt an» beibehalten | hoch | niedrig (wenn ehrlich kommuniziert) | --- ## 6. offene punkte zur klärung (rückfragen an poweron ag) die folgenden punkte konnten aus den dokumenten **nicht** verifiziert werden und sollten intern geklärt werden: 1. **telefonnummer** für incident-rufbereitschaft (aktuell nur e-mail patrick motsch). 2. **trennung rollen:** patrick motsch trägt alle rollen (ciso, dpo, gf, devops) — für audits ggf. formale zuordnung oder externe dpo-unterstützung erwägen. 3. **infomaniak:** at-rest-verschlüsselung, dr-region, iso-zertifikate als pdf beilegen. 4. **openai:** enterprise-tier mit training-opt-out — vertragsversion und speicherort dokumentieren. 5. **schweizer/eu-only llm** für finma-kunden: ist mistral eu oder self-hosted modell produktiv anbietbar? 6. **legal hold:** technische funktion vorhanden oder nur manuelle prozedur? 7. **kundenzugang zu logs:** api/export pro mandant geplant? 8. **byok:** angebot gewünscht für regulierte kunden? 9. **rechtliche prüfung agb** durch fachanwalt vor veröffentlichung gegenüber bankkunden. 10. **weitere ansprechpartner** bei team-wachstum (vertretung schlüsselperson). --- ## 7. dokumentenübersicht (stand nach anpassung) | datei | rolle | |---|---| | `20260603_poweron_agb_v1.0_1.md` | vertragsgrundlage b2b (stammdaten aktualisiert) | | `security-overview.md` | kundeninformation sicherheit/datenschutz | | `neutralisierung-detail.md` | technisches datenschutz-modul | | `legal/00`–`17` | cacc/finma-prozessdokumentation | | **`legal/18_analyse_recht_und_bestpractice.md`** | dieser befundbericht | --- *nächste planmässige überprüfung dieses berichts: 01.02.2027 oder nach wesentlicher änderung an agb, infrastruktur oder regulatorischen anforderungen.* ", "nextReview": "", "overdueReview": false, "zuPruefen": []}, {"id": "05_betrieb/20260528_bcm_runbook.md", "path": "05_betrieb/20260528_bcm_runbook.md", "chapter": "05_betrieb", "title": "Runbook: Plattform-Core (PowerOn Gateway)", "filename": "20260528_bcm_runbook.md", "meta": {}, "html": "<h1>Runbook: Plattform-Core (PowerOn Gateway)<\/h1>\n<p>Dieses Dokument beschreibt die drei häufigsten Betriebsszenarien für die PowerOn-Plattform. Es richtet sich an alle, die im Notfall handeln müssen — auch ohne tiefes technisches Vorwissen. Die konkreten Befehle sind für die Person gedacht, die den Server-Zugang hat (typisch: Entwickler oder DevOps).<\/p>\n<p><strong>Kurze Systemübersicht:<\/strong> Die Plattform läuft auf einem Server bei Infomaniak (<code>api.poweron.swiss<\/code>). Alle Kundendaten liegen in einer separaten PostgreSQL-Datenbank (<code>db.poweron.swiss<\/code>). Codeänderungen werden über das interne Git-System (Forgejo) automatisch deployed.<\/p>\n<table><thead><tr><th>Umgebung<\/th><th>Server<\/th><th>URL<\/th><\/tr><\/thead><tbody><tr><td>Produktion<\/td><td><code>ubuntu@api.poweron.swiss<\/code><\/td><td><code>https://api.poweron.swiss<\/code><\/td><\/tr><tr><td>Integration (Test)<\/td><td><code>ubuntu@api-int.poweron.swiss<\/code><\/td><td><code>https://api-int.poweron.swiss<\/code><\/td><\/tr><\/tbody><\/table>\n<hr>\n<h2>1. Produktivumgebung neu starten<\/h2>\n<p><strong>Wann nötig?<\/strong> Die API antwortet nicht mehr, Requests laufen in Timeouts, oder nach einem Konfigurationswechsel soll alles frisch gestartet werden.<\/p>\n<p><strong>Was passiert dabei?<\/strong> Der laufende Prozess wird gestoppt und neu gestartet. Die Datenbank und alle gespeicherten Daten bleiben dabei vollständig erhalten. Nutzer merken einen kurzen Unterbruch von typisch wenigen Sekunden.<\/p>\n<h3>Normalfall: Service neu starten<\/h3>\n<p>Auf dem Produktionsserver einloggen und den Service neu starten:<\/p>\n<pre class=\"code\"><code>ssh ubuntu@api.poweron.swiss\nsudo systemctl restart gateway<\/code><\/pre>\n<p>Danach prüfen, ob alles wieder läuft:<\/p>\n<pre class=\"code\"><code>sudo systemctl status gateway<\/code><\/pre>\n<p>Den Health-Check aufrufen — wenn er <code>200 OK<\/code> zurückgibt, ist alles gut:<\/p>\n<pre class=\"code\"><code>curl https://api.poweron.swiss/api/admin/health<\/code><\/pre>\n<h3>Kompletter Neustart (inkl. Abhängigkeiten neu laden)<\/h3>\n<p>Wenn sich seit dem letzten Deploy neue Bibliotheken geändert haben oder nach einem manuellen Eingriff am Server:<\/p>\n<pre class=\"code\"><code>ssh ubuntu@api.poweron.swiss\ncd /srv/gateway/current\nsource .venv/bin/activate\npip install -r requirements.txt --no-cache-dir\nsudo systemctl restart gateway<\/code><\/pre>\n<h3>Wenn der Service nicht startet<\/h3>\n<p>Wenn der Neustart nicht hilft oder der Service sofort wieder abbricht, hilft ein Blick in die Logs:<\/p>\n<pre class=\"code\"><code># Systemlogs der letzten 100 Zeilen\nsudo journalctl -u gateway -n 100 --no-pager\n\n# Anwendungslogs des heutigen Tages\ntail -100 /srv/gateway/shared/logs/log_app_$(date +%Y%m%d).log<\/code><\/pre>\n<p>Wenn der Fehler unklar ist, kann die App auch direkt im Vordergrund gestartet werden — dann erscheint die Fehlermeldung sofort im Terminal:<\/p>\n<pre class=\"code\"><code>cd /srv/gateway/current\nsource .venv/bin/activate\ngunicorn app:app --bind 0.0.0.0:8000 --timeout 600 \\\n  --worker-class uvicorn.workers.UvicornWorker --workers 1<\/code><\/pre>\n<hr>\n<h2>2. Backup einspielen (Datenbankwiederherstellung)<\/h2>\n<p><strong>Wann nötig?<\/strong> Nach einem Datenverlust, einer fehlerhaften Migration oder wenn ein früherer Datenbankstand wiederhergestellt werden muss.<\/p>\n<p><strong>Was passiert dabei?<\/strong> Die Anwendung wird kurz gestoppt, damit während dem Restore niemand inkonsistente Daten sieht. Die bestehenden Daten werden durch den Backup-Stand ersetzt. Danach wird die Anwendung wieder gestartet. Je nach Datenmenge dauert der Restore wenige Minuten bis zu einer Stunde.<\/p>\n<p><strong>Wichtig vor dem Start:<\/strong> Immer zuerst einen aktuellen Snapshot erstellen, bevor man ein älteres Backup einspielt — so kann man auch den Zustand kurz vor dem Restore noch wiederherstellen, falls etwas schiefläuft.<\/p>\n<h3>Schritt 1: Aktuellen Stand sichern (Sicherheitskopie)<\/h3>\n<pre class=\"code\"><code>ssh ubuntu@api.poweron.swiss\n# DB-Passwort aus der Konfiguration lesen:\ngrep DB_ /srv/gateway/current/.env\n\n# Alle Datenbanken sichern (Dateien landen in /tmp/)\nfor DB in poweron_app poweron_management poweron_billing poweron_chat \\\n           poweron_chatbot poweron_trustee poweron_realestate \\\n           poweron_knowledge poweron_workspace; do\n  pg_dump -h db.poweron.swiss -U poweron_dev -p 5432 \\\n    -Fc $DB &gt; /tmp/backup_${DB}_$(date +%Y%m%d_%H%M%S).dump\ndone<\/code><\/pre>\n<h3>Schritt 2: Anwendung stoppen und Backup einspielen<\/h3>\n<pre class=\"code\"><code>sudo systemctl stop gateway\n\n# Einzelne Datenbank wiederherstellen (Beispiel: poweron_app)\npg_restore -h db.poweron.swiss -U poweron_dev -p 5432 \\\n  -d poweron_app --clean --if-exists \\\n  /pfad/zum/backup_poweron_app_DATUM.dump\n\nsudo systemctl start gateway<\/code><\/pre>\n<h3>Backup einspielen über das Migrations-Tool (alle Datenbanken)<\/h3>\n<p>Wenn ein vollständiges JSON-Export aus dem projekteigenen Migrationstool vorliegt:<\/p>\n<pre class=\"code\"><code>ssh ubuntu@api.poweron.swiss\ncd /srv/gateway/current\nsource .venv/bin/activate\nsudo systemctl stop gateway\n\n# Hilfe zum Import-Script anzeigen:\npython scripts/script_db_export_migration.py --help\n\nsudo systemctl start gateway<\/code><\/pre>\n<h3>Schritt 3: Verifizieren<\/h3>\n<pre class=\"code\"><code>sudo systemctl status gateway\ncurl https://api.poweron.swiss/api/admin/health<\/code><\/pre>\n<hr>\n<h2>3. Rollback auf die vorherige Version<\/h2>\n<p><strong>Wann nötig?<\/strong> Ein frisch deploytes Update verursacht Fehler oder unerwünschtes Verhalten, das vorher nicht da war. Statt stundenlang zu debuggen, fährt man die Plattform einfach auf den letzten stabilen Stand zurück.<\/p>\n<p><strong>Was passiert dabei?<\/strong> Der Code auf dem Server wird auf einen früheren Git-Commit zurückgesetzt. Die Datenbank bleibt unverändert — nur der Anwendungscode wird ausgetauscht. Das dauert typisch unter 2 Minuten.<\/p>\n<p><strong>Hinweis zu Datenbank-Migrationen:<\/strong> Wenn das neue Update auch Datenbankänderungen enthielt, kann ein reiner Code-Rollback zu Inkompatibilitäten führen. In diesem Fall zusätzlich einen Datenbank-Restore (Szenario 2) in Betracht ziehen und vorher mit dem Entwicklungsteam absprechen.<\/p>\n<h3>Rollback über Git (empfohlen, schnellster Weg)<\/h3>\n<pre class=\"code\"><code>ssh ubuntu@api.poweron.swiss\ncd /srv/gateway/current\n\n# Die letzten 10 Deployments anzeigen — den gewünschten HASH notieren\ngit log --oneline -10\n\n# Auf den gewählten Stand zurücksetzen (HASH ersetzen, z.B. \"b04211be\")\ngit reset --hard &lt;COMMIT_HASH&gt;\n\n# Konfigurationsdatei neu setzen\ntest -f env-prod.env &amp;&amp; cp env-prod.env .env &amp;&amp; rm -f env-*.env\n\n# Abhängigkeiten prüfen\nsource .venv/bin/activate\npip install -r requirements.txt --no-cache-dir\n\n# Service neu starten und prüfen\nsudo systemctl restart gateway\nsudo systemctl status gateway\ncurl https://api.poweron.swiss/api/admin/health<\/code><\/pre>\n<h3>Rollback über Forgejo (sauberer, hinterlässt Protokoll)<\/h3>\n<p>Diese Variante ist etwas langsamer (Tests laufen durch), aber der Rollback wird im Git-Verlauf sichtbar und ist für alle nachvollziehbar.<\/p>\n<pre class=\"code\"><code># Lokal: einen Revert-Commit erstellen und pushen\ngit revert HEAD  # oder den spezifischen Commit angeben\ngit push origin main\n# → Forgejo startet automatisch Tests und deployed danach<\/code><\/pre>\n<h3>Rollback auf der INT-Umgebung<\/h3>\n<p>Gleiche Schritte wie oben, aber mit diesen Werten:<\/p>\n<ul><li>Server: <code>ubuntu@api-int.poweron.swiss<\/code><\/li><li>Branch: <code>int<\/code> statt <code>main<\/code><\/li><li>Env-Datei: <code>env-int.env<\/code><\/li><li>Health-Check: <code>https://api-int.poweron.swiss/api/admin/health<\/code><\/li><\/ul>\n<hr>\n<h2>Referenz<\/h2>\n<table><thead><tr><th>Was<\/th><th>Wo<\/th><\/tr><\/thead><tbody><tr><td>Prod-Server<\/td><td><code>ubuntu@api.poweron.swiss<\/code><\/td><\/tr><tr><td>Int-Server<\/td><td><code>ubuntu@api-int.poweron.swiss<\/code><\/td><\/tr><tr><td>App-Pfad auf Server<\/td><td><code>/srv/gateway/current<\/code><\/td><\/tr><tr><td>App-Logs<\/td><td><code>/srv/gateway/shared/logs/log_app_YYYYMMDD.log<\/code><\/td><\/tr><tr><td>System-Logs<\/td><td><code>journalctl -u gateway<\/code><\/td><\/tr><tr><td>Datenbank-Host<\/td><td><code>db.poweron.swiss:5432<\/code><\/td><\/tr><tr><td>Datenbank-User<\/td><td><code>poweron_dev<\/code><\/td><\/tr><tr><td>Health-Check Endpoint<\/td><td><code>GET /api/admin/health<\/code><\/td><\/tr><tr><td>CI/CD Pipeline<\/td><td><code>.forgejo/workflows/main_porta-main-platform-core.yml<\/code><\/td><\/tr><\/tbody><\/table>", "text": "# runbook: plattform-core (poweron gateway) dieses dokument beschreibt die drei häufigsten betriebsszenarien für die poweron-plattform. es richtet sich an alle, die im notfall handeln müssen — auch ohne tiefes technisches vorwissen. die konkreten befehle sind für die person gedacht, die den server-zugang hat (typisch: entwickler oder devops). **kurze systemübersicht:** die plattform läuft auf einem server bei infomaniak (`api.poweron.swiss`). alle kundendaten liegen in einer separaten postgresql-datenbank (`db.poweron.swiss`). codeänderungen werden über das interne git-system (forgejo) automatisch deployed. | umgebung | server | url | |---|---|---| | produktion | `ubuntu@api.poweron.swiss` | `https://api.poweron.swiss` | | integration (test) | `ubuntu@api-int.poweron.swiss` | `https://api-int.poweron.swiss` | --- ## 1. produktivumgebung neu starten **wann nötig?** die api antwortet nicht mehr, requests laufen in timeouts, oder nach einem konfigurationswechsel soll alles frisch gestartet werden. **was passiert dabei?** der laufende prozess wird gestoppt und neu gestartet. die datenbank und alle gespeicherten daten bleiben dabei vollständig erhalten. nutzer merken einen kurzen unterbruch von typisch wenigen sekunden. ### normalfall: service neu starten auf dem produktionsserver einloggen und den service neu starten: ```bash ssh ubuntu@api.poweron.swiss sudo systemctl restart gateway ``` danach prüfen, ob alles wieder läuft: ```bash sudo systemctl status gateway ``` den health-check aufrufen — wenn er `200 ok` zurückgibt, ist alles gut: ```bash curl https://api.poweron.swiss/api/admin/health ``` ### kompletter neustart (inkl. abhängigkeiten neu laden) wenn sich seit dem letzten deploy neue bibliotheken geändert haben oder nach einem manuellen eingriff am server: ```bash ssh ubuntu@api.poweron.swiss cd /srv/gateway/current source .venv/bin/activate pip install -r requirements.txt --no-cache-dir sudo systemctl restart gateway ``` ### wenn der service nicht startet wenn der neustart nicht hilft oder der service sofort wieder abbricht, hilft ein blick in die logs: ```bash # systemlogs der letzten 100 zeilen sudo journalctl -u gateway -n 100 --no-pager # anwendungslogs des heutigen tages tail -100 /srv/gateway/shared/logs/log_app_$(date +%y%m%d).log ``` wenn der fehler unklar ist, kann die app auch direkt im vordergrund gestartet werden — dann erscheint die fehlermeldung sofort im terminal: ```bash cd /srv/gateway/current source .venv/bin/activate gunicorn app:app --bind 0.0.0.0:8000 --timeout 600 \\ --worker-class uvicorn.workers.uvicornworker --workers 1 ``` --- ## 2. backup einspielen (datenbankwiederherstellung) **wann nötig?** nach einem datenverlust, einer fehlerhaften migration oder wenn ein früherer datenbankstand wiederhergestellt werden muss. **was passiert dabei?** die anwendung wird kurz gestoppt, damit während dem restore niemand inkonsistente daten sieht. die bestehenden daten werden durch den backup-stand ersetzt. danach wird die anwendung wieder gestartet. je nach datenmenge dauert der restore wenige minuten bis zu einer stunde. **wichtig vor dem start:** immer zuerst einen aktuellen snapshot erstellen, bevor man ein älteres backup einspielt — so kann man auch den zustand kurz vor dem restore noch wiederherstellen, falls etwas schiefläuft. ### schritt 1: aktuellen stand sichern (sicherheitskopie) ```bash ssh ubuntu@api.poweron.swiss # db-passwort aus der konfiguration lesen: grep db_ /srv/gateway/current/.env # alle datenbanken sichern (dateien landen in /tmp/) for db in poweron_app poweron_management poweron_billing poweron_chat \\ poweron_chatbot poweron_trustee poweron_realestate \\ poweron_knowledge poweron_workspace; do pg_dump -h db.poweron.swiss -u poweron_dev -p 5432 \\ -fc $db > /tmp/backup_${db}_$(date +%y%m%d_%h%m%s).dump done ``` ### schritt 2: anwendung stoppen und backup einspielen ```bash sudo systemctl stop gateway # einzelne datenbank wiederherstellen (beispiel: poweron_app) pg_restore -h db.poweron.swiss -u poweron_dev -p 5432 \\ -d poweron_app --clean --if-exists \\ /pfad/zum/backup_poweron_app_datum.dump sudo systemctl start gateway ``` ### backup einspielen über das migrations-tool (alle datenbanken) wenn ein vollständiges json-export aus dem projekteigenen migrationstool vorliegt: ```bash ssh ubuntu@api.poweron.swiss cd /srv/gateway/current source .venv/bin/activate sudo systemctl stop gateway # hilfe zum import-script anzeigen: python scripts/script_db_export_migration.py --help sudo systemctl start gateway ``` ### schritt 3: verifizieren ```bash sudo systemctl status gateway curl https://api.poweron.swiss/api/admin/health ``` --- ## 3. rollback auf die vorherige version **wann nötig?** ein frisch deploytes update verursacht fehler oder unerwünschtes verhalten, das vorher nicht da war. statt stundenlang zu debuggen, fährt man die plattform einfach auf den letzten stabilen stand zurück. **was passiert dabei?** der code auf dem server wird auf einen früheren git-commit zurückgesetzt. die datenbank bleibt unverändert — nur der anwendungscode wird ausgetauscht. das dauert typisch unter 2 minuten. **hinweis zu datenbank-migrationen:** wenn das neue update auch datenbankänderungen enthielt, kann ein reiner code-rollback zu inkompatibilitäten führen. in diesem fall zusätzlich einen datenbank-restore (szenario 2) in betracht ziehen und vorher mit dem entwicklungsteam absprechen. ### rollback über git (empfohlen, schnellster weg) ```bash ssh ubuntu@api.poweron.swiss cd /srv/gateway/current # die letzten 10 deployments anzeigen — den gewünschten hash notieren git log --oneline -10 # auf den gewählten stand zurücksetzen (hash ersetzen, z.b. \"b04211be\") git reset --hard <commit_hash> # konfigurationsdatei neu setzen test -f env-prod.env && cp env-prod.env .env && rm -f env-*.env # abhängigkeiten prüfen source .venv/bin/activate pip install -r requirements.txt --no-cache-dir # service neu starten und prüfen sudo systemctl restart gateway sudo systemctl status gateway curl https://api.poweron.swiss/api/admin/health ``` ### rollback über forgejo (sauberer, hinterlässt protokoll) diese variante ist etwas langsamer (tests laufen durch), aber der rollback wird im git-verlauf sichtbar und ist für alle nachvollziehbar. ```bash # lokal: einen revert-commit erstellen und pushen git revert head # oder den spezifischen commit angeben git push origin main # → forgejo startet automatisch tests und deployed danach ``` ### rollback auf der int-umgebung gleiche schritte wie oben, aber mit diesen werten: - server: `ubuntu@api-int.poweron.swiss` - branch: `int` statt `main` - env-datei: `env-int.env` - health-check: `https://api-int.poweron.swiss/api/admin/health` --- ## referenz | was | wo | |---|---| | prod-server | `ubuntu@api.poweron.swiss` | | int-server | `ubuntu@api-int.poweron.swiss` | | app-pfad auf server | `/srv/gateway/current` | | app-logs | `/srv/gateway/shared/logs/log_app_yyyymmdd.log` | | system-logs | `journalctl -u gateway` | | datenbank-host | `db.poweron.swiss:5432` | | datenbank-user | `poweron_dev` | | health-check endpoint | `get /api/admin/health` | | ci/cd pipeline | `.forgejo/workflows/main_porta-main-platform-core.yml` | ", "nextReview": "", "overdueReview": false, "zuPruefen": []}, {"id": "05_betrieb/20260528_datenbank-handling.md", "path": "05_betrieb/20260528_datenbank-handling.md", "chapter": "05_betrieb", "title": "Datenbank-Handling: Exports, Imports, Backups & Datensicherung", "filename": "20260528_datenbank-handling.md", "meta": {}, "html": "<h1>Datenbank-Handling: Exports, Imports, Backups &amp; Datensicherung<\/h1>\n<p>Dieses Dokument beschreibt, wie die PowerOn-Plattform ihre Datenbanken verwaltet — von der strukturierten Datensicherung über flexible Export- und Import-Werkzeuge bis hin zur sicheren Wiederherstellung.<\/p>\n<hr>\n<h2>1. Datenbankübersicht<\/h2>\n<p>Die Plattform betreibt <strong>13 separate Datenbanken<\/strong> auf dem Datenbankserver <code>db.poweron.swiss<\/code>. Jede Datenbank gehört einem fachlichen Bereich:<\/p>\n<table><thead><tr><th>Datenbank<\/th><th>Inhalt<\/th><\/tr><\/thead><tbody><tr><td><code>poweron_app<\/code><\/td><td>Benutzer, Mandate, Berechtigungen, Features — Kern der Plattform<\/td><\/tr><tr><td><code>poweron_management<\/code><\/td><td>Workflows, Prompts, Verbindungen (Connections)<\/td><\/tr><tr><td><code>poweron_billing<\/code><\/td><td>Abonnements, Rechnungen, Stripe-Daten<\/td><\/tr><tr><td><code>poweron_chat<\/code><\/td><td>Chat-Konversationen und Nachrichten<\/td><\/tr><tr><td><code>poweron_chatbot<\/code><\/td><td>Chatbot-Feature: Konversationen, Logs<\/td><\/tr><tr><td><code>poweron_knowledge<\/code><\/td><td>RAG-Wissensdatenbank, Dokumentenindizes<\/td><\/tr><tr><td><code>poweron_workspace<\/code><\/td><td>Workspace-Daten<\/td><\/tr><tr><td><code>poweron_trustee<\/code><\/td><td>Treuhand-spezifische Daten<\/td><\/tr><tr><td><code>poweron_realestate<\/code><\/td><td>Immobilien-Daten<\/td><\/tr><tr><td><code>poweron_commcoach<\/code><\/td><td>CommCoach-Feature<\/td><\/tr><tr><td><code>poweron_neutralization<\/code><\/td><td>Content-Neutralisierung<\/td><\/tr><tr><td><code>poweron_teamsbot<\/code><\/td><td>Microsoft Teams Bot<\/td><\/tr><tr><td><code>poweron_test<\/code><\/td><td>Testdaten (wird bei Exports ausgeschlossen)<\/td><\/tr><\/tbody><\/table>\n<hr>\n<h2>2. Export<\/h2>\n<p>Ein Export erstellt eine vollständige Kopie aller Daten in einem lesbaren JSON-Format. Er dient als Grundlage für Backups, Migrationen zwischen Umgebungen (z. B. Prod → Int) und als Sicherungspunkt vor grösseren Änderungen.<\/p>\n<h3>2.1 Export via Admin-UI (empfohlen)<\/h3>\n<p>Im SysAdmin-Bereich der Plattform gibt es einen integrierten Export-Button. Er erzeugt eine JSON-Datei, die direkt heruntergeladen wird.<\/p>\n<ul><li><strong>Zugriff:<\/strong> Nur für SysAdmins (höchste Berechtigungsstufe)<\/li><li><strong>Umfang:<\/strong> Alle Datenbanken oder einzelne auswählbar<\/li><li><strong>Dateiname:<\/strong> <code>migration_backup_YYYY-MM-DD_HH-MM.json<\/code><\/li><li><strong>Rate-Limit:<\/strong> Max. 2 Exports pro Minute (Schutzmassnahme gegen versehentliche Mehrfachausführung)<\/li><\/ul>\n<p>Auch sehr grosse Datenbanken werden sicher übertragen, ohne dass der Server dabei überlastet wird.<\/p>\n<h3>2.2 Export via Script (für Entwickler / Server-Zugriff)<\/h3>\n<p>Direkt auf dem Server kann das Export-Script ausgeführt werden:<\/p>\n<pre class=\"code\"><code>ssh ubuntu@api.poweron.swiss\ncd /srv/gateway/current\nsource .venv/bin/activate\n\n# Alle Datenbanken exportieren\npython scripts/script_db_export_migration.py --pretty\n\n# Nur bestimmte Datenbanken\npython scripts/script_db_export_migration.py --db poweron_app,poweron_management\n\n# Ohne Metadaten (kleiner, für Archivierung)\npython scripts/script_db_export_migration.py --exclude Token,AuthEvent\n\n# Mit Zusammenfassung (zeigt Tabellen- und Zeilenanzahl)\npython scripts/script_db_export_migration.py --summary<\/code><\/pre>\n<p>Das Script erstellt automatisch zwei Dateien:<\/p>\n<ul><li><code>migration_export_TIMESTAMP.json<\/code> — vollständige Daten<\/li><li><code>migration_export_TIMESTAMP_structure.json<\/code> — nur Tabellenstruktur, keine Daten<\/li><\/ul>\n<h3>2.3 Was wird beim Export ausgeschlossen?<\/h3>\n<p>Aus Sicherheits- und Datenschutzgründen werden folgende Tabellen <strong>nie<\/strong> exportiert:<\/p>\n<ul><li><code>Token<\/code> (aktive Login-Sessions)<\/li><li><code>AuthEvent<\/code> (Login-Protokoll)<\/li><li><code>poweron_test<\/code> (Testdatenbank)<\/li><\/ul>\n<hr>\n<h2>3. Import<\/h2>\n<p>Ein Import spielt einen zuvor erstellten Export wieder ein. Typische Anwendungsfälle:<\/p>\n<ul><li>Wiederherstellung eines früheren Datenstands<\/li><li>Migration zwischen Umgebungen (z. B. Produktionsdaten auf die Testumgebung übertragen)<\/li><li>Initialisierung einer neuen Instanz<\/li><\/ul>\n<h3>3.1 Zwei Import-Modi<\/h3>\n<p><strong>Replace (Ersetzen):<\/strong> Löscht alle bestehenden Daten (ausser geschützte System-Objekte, siehe unten) und schreibt den Backup-Stand vollständig neu. Verwenden bei vollständiger Wiederherstellung.<\/p>\n<p><strong>Merge (Zusammenführen):<\/strong> Fügt nur Datensätze ein, die noch nicht existieren (anhand ID). Bestehende Daten bleiben unverändert. Verwenden wenn nur fehlende Daten ergänzt werden sollen.<\/p>\n<h3>3.2 Import via Admin-UI<\/h3>\n<ol><li>JSON-Datei hochladen<\/li><li>Validation läuft automatisch (prüft Format-Version, Struktur, System-Objekte)<\/li><li>Import-Modus wählen: <code>replace<\/code> oder <code>merge<\/code><\/li><li>Import starten — Ergebnis zeigt Anzahl eingespielter Datensätze pro Tabelle<\/li><\/ol>\n<p>Auch sehr grosse Backup-Dateien können problemlos importiert werden, ohne den Server zu überlasten.<\/p>\n<h3>3.3 Geschützte System-Objekte<\/h3>\n<p>Beim Import werden drei kritische Objekte <strong>nie gelöscht oder überschrieben<\/strong>, unabhängig vom Import-Modus:<\/p>\n<ul><li>Root-Mandat<\/li><li>Admin-Benutzer<\/li><li>Event-Benutzer<\/li><\/ul>\n<p>Falls diese Objekte im Backup andere interne Kennungen hatten als in der Zielumgebung, passt das System alle betroffenen Verknüpfungen <strong>automatisch<\/strong> an. Das verhindert inkonsistente Daten nach dem Import.<\/p>\n<h3>3.4 Import via Script<\/h3>\n<pre class=\"code\"><code>ssh ubuntu@api.poweron.swiss\ncd /srv/gateway/current\nsource .venv/bin/activate\nsudo systemctl stop gateway\n\n# Import-Script (Pendant zum Export-Script)\n# Datei übergeben, Modus wählen\npython scripts/script_db_export_migration.py --help  # zeigt alle Optionen\n\nsudo systemctl start gateway<\/code><\/pre>\n<hr>\n<h2>4. Backups &amp; Datensicherung<\/h2>\n<h3>4.1 Backup-Strategie<\/h3>\n<p>Die Plattform verfügt über ein durchdachtes, mehrschichtiges Sicherungskonzept:<\/p>\n<p><strong>Infrastruktur-Ebene:<\/strong> Der Datenbankserver läuft auf der Infomaniak Public Cloud, die Snapshot-Funktionalitäten für Managed Databases bereitstellt.<\/p>\n<p><strong>Anwendungs-Ebene:<\/strong> Über die integrierte Admin-UI kann jederzeit ein vollständiger Export aller Datenbanken erstellt werden — on-demand, gezielt pro Datenbank oder als Gesamtexport. Die Backup-Dateien sind vollständig portabel und können auf jedem Speicher archiviert werden.<\/p>\n<h3>4.2 Empfohlene Backup-Praxis<\/h3>\n<table><thead><tr><th>Zeitpunkt<\/th><th>Aktion<\/th><\/tr><\/thead><tbody><tr><td>Vor jedem Deployment<\/td><td>Export via Admin-UI, Datei lokal speichern<\/td><\/tr><tr><td>Vor Datenbank-Migrationen<\/td><td>Export erstellen und beschriftet archivieren<\/td><\/tr><tr><td>Wöchentlich<\/td><td>Export als Archiv-Backup ablegen<\/td><\/tr><\/tbody><\/table>\n<hr>\n<h2>5. Datenbankmigrationen (Struktur-Änderungen)<\/h2>\n<p>Wenn sich das Datenmodell weiterentwickelt — z. B. durch neue Felder oder Tabellen — stellt die Plattform dedizierte Hilfsprogramme bereit, die Datenbankstruktur kontrolliert und sicher anzupassen:<\/p>\n<table><thead><tr><th>Programm<\/th><th>Zweck<\/th><\/tr><\/thead><tbody><tr><td><code>script_db_adapt_to_models.py<\/code><\/td><td>Passt die Datenbankstruktur automatisch an den aktuellen Code an (mit Vorschau-Modus ohne Änderungen)<\/td><\/tr><tr><td><code>script_db_audit_legacy_state.py<\/code><\/td><td>Analysiert den Datenbankzustand vor einem Bereinigungsschritt<\/td><\/tr><tr><td><code>script_db_migrate_*.py<\/code><\/td><td>Datenmigrations-Programme für spezifische Features<\/td><\/tr><tr><td><code>script_db_init_automation2.py<\/code><\/td><td>Erstellt die Datenbankstruktur für das Automation-Feature<\/td><\/tr><tr><td><code>script_db_init_chatbot.py<\/code><\/td><td>Erstellt die Datenbankstruktur für das Chatbot-Feature<\/td><\/tr><\/tbody><\/table>\n<p>Beim Start der Anwendung prüft die Plattform ausserdem automatisch, ob alle benötigten Tabellen vorhanden sind, und legt fehlende selbstständig an.<\/p>\n<hr>\n<h2>6. Datenschutz-Hinweise<\/h2>\n<ul><li>Export-Dateien enthalten <strong>alle Kundendaten<\/strong> (Mandate, Benutzer, Chats, Dokumente, etc.) und sind entsprechend zu behandeln<\/li><li>Dateien dürfen <strong>nicht auf unsicheren Speichern<\/strong> (persönliche Dropbox, E-Mail, etc.) abgelegt werden<\/li><li>Export-Dateien sollten nach Nutzung gelöscht werden wenn sie nicht mehr benötigt werden<\/li><li>Der Zugriff auf Export/Import ist auf SysAdmins beschränkt und wird serverseitig geloggt<\/li><\/ul>\n<hr>\n<h2>Zusammenfassung: Datenbankoperationen im Überblick<\/h2>\n<table><thead><tr><th>Aufgabe<\/th><th>Wie<\/th><\/tr><\/thead><tbody><tr><td>Fehlende Tabellen beim Start anlegen<\/td><td>Automatisch beim Plattform-Start<\/td><\/tr><tr><td>Datenbank-Export / Backup<\/td><td>Admin-UI (ein Klick) oder Entwickler-Script<\/td><\/tr><tr><td>Datenbank-Import / Wiederherstellung<\/td><td>Admin-UI mit geführtem Prozess oder Entwickler-Script<\/td><\/tr><tr><td>Infrastruktur-Snapshots<\/td><td>Infomaniak Cloud (Serverebene)<\/td><\/tr><tr><td>Struktur-Anpassungen bei Updates<\/td><td>Kontrolliert durch Entwickler-Hilfsprogramme<\/td><\/tr><tr><td>Datenbankpflege &amp; Bereinigung<\/td><td>Admin-UI<\/td><\/tr><\/tbody><\/table>", "text": "# datenbank-handling: exports, imports, backups & datensicherung dieses dokument beschreibt, wie die poweron-plattform ihre datenbanken verwaltet — von der strukturierten datensicherung über flexible export- und import-werkzeuge bis hin zur sicheren wiederherstellung. --- ## 1. datenbankübersicht die plattform betreibt **13 separate datenbanken** auf dem datenbankserver `db.poweron.swiss`. jede datenbank gehört einem fachlichen bereich: | datenbank | inhalt | |---|---| | `poweron_app` | benutzer, mandate, berechtigungen, features — kern der plattform | | `poweron_management` | workflows, prompts, verbindungen (connections) | | `poweron_billing` | abonnements, rechnungen, stripe-daten | | `poweron_chat` | chat-konversationen und nachrichten | | `poweron_chatbot` | chatbot-feature: konversationen, logs | | `poweron_knowledge` | rag-wissensdatenbank, dokumentenindizes | | `poweron_workspace` | workspace-daten | | `poweron_trustee` | treuhand-spezifische daten | | `poweron_realestate` | immobilien-daten | | `poweron_commcoach` | commcoach-feature | | `poweron_neutralization` | content-neutralisierung | | `poweron_teamsbot` | microsoft teams bot | | `poweron_test` | testdaten (wird bei exports ausgeschlossen) | --- ## 2. export ein export erstellt eine vollständige kopie aller daten in einem lesbaren json-format. er dient als grundlage für backups, migrationen zwischen umgebungen (z. b. prod → int) und als sicherungspunkt vor grösseren änderungen. ### 2.1 export via admin-ui (empfohlen) im sysadmin-bereich der plattform gibt es einen integrierten export-button. er erzeugt eine json-datei, die direkt heruntergeladen wird. - **zugriff:** nur für sysadmins (höchste berechtigungsstufe) - **umfang:** alle datenbanken oder einzelne auswählbar - **dateiname:** `migration_backup_yyyy-mm-dd_hh-mm.json` - **rate-limit:** max. 2 exports pro minute (schutzmassnahme gegen versehentliche mehrfachausführung) auch sehr grosse datenbanken werden sicher übertragen, ohne dass der server dabei überlastet wird. ### 2.2 export via script (für entwickler / server-zugriff) direkt auf dem server kann das export-script ausgeführt werden: ```bash ssh ubuntu@api.poweron.swiss cd /srv/gateway/current source .venv/bin/activate # alle datenbanken exportieren python scripts/script_db_export_migration.py --pretty # nur bestimmte datenbanken python scripts/script_db_export_migration.py --db poweron_app,poweron_management # ohne metadaten (kleiner, für archivierung) python scripts/script_db_export_migration.py --exclude token,authevent # mit zusammenfassung (zeigt tabellen- und zeilenanzahl) python scripts/script_db_export_migration.py --summary ``` das script erstellt automatisch zwei dateien: - `migration_export_timestamp.json` — vollständige daten - `migration_export_timestamp_structure.json` — nur tabellenstruktur, keine daten ### 2.3 was wird beim export ausgeschlossen? aus sicherheits- und datenschutzgründen werden folgende tabellen **nie** exportiert: - `token` (aktive login-sessions) - `authevent` (login-protokoll) - `poweron_test` (testdatenbank) --- ## 3. import ein import spielt einen zuvor erstellten export wieder ein. typische anwendungsfälle: - wiederherstellung eines früheren datenstands - migration zwischen umgebungen (z. b. produktionsdaten auf die testumgebung übertragen) - initialisierung einer neuen instanz ### 3.1 zwei import-modi **replace (ersetzen):** löscht alle bestehenden daten (ausser geschützte system-objekte, siehe unten) und schreibt den backup-stand vollständig neu. verwenden bei vollständiger wiederherstellung. **merge (zusammenführen):** fügt nur datensätze ein, die noch nicht existieren (anhand id). bestehende daten bleiben unverändert. verwenden wenn nur fehlende daten ergänzt werden sollen. ### 3.2 import via admin-ui 1. json-datei hochladen 2. validation läuft automatisch (prüft format-version, struktur, system-objekte) 3. import-modus wählen: `replace` oder `merge` 4. import starten — ergebnis zeigt anzahl eingespielter datensätze pro tabelle auch sehr grosse backup-dateien können problemlos importiert werden, ohne den server zu überlasten. ### 3.3 geschützte system-objekte beim import werden drei kritische objekte **nie gelöscht oder überschrieben**, unabhängig vom import-modus: - root-mandat - admin-benutzer - event-benutzer falls diese objekte im backup andere interne kennungen hatten als in der zielumgebung, passt das system alle betroffenen verknüpfungen **automatisch** an. das verhindert inkonsistente daten nach dem import. ### 3.4 import via script ```bash ssh ubuntu@api.poweron.swiss cd /srv/gateway/current source .venv/bin/activate sudo systemctl stop gateway # import-script (pendant zum export-script) # datei übergeben, modus wählen python scripts/script_db_export_migration.py --help # zeigt alle optionen sudo systemctl start gateway ``` --- ## 4. backups & datensicherung ### 4.1 backup-strategie die plattform verfügt über ein durchdachtes, mehrschichtiges sicherungskonzept: **infrastruktur-ebene:** der datenbankserver läuft auf der infomaniak public cloud, die snapshot-funktionalitäten für managed databases bereitstellt. **anwendungs-ebene:** über die integrierte admin-ui kann jederzeit ein vollständiger export aller datenbanken erstellt werden — on-demand, gezielt pro datenbank oder als gesamtexport. die backup-dateien sind vollständig portabel und können auf jedem speicher archiviert werden. ### 4.2 empfohlene backup-praxis | zeitpunkt | aktion | |---|---| | vor jedem deployment | export via admin-ui, datei lokal speichern | | vor datenbank-migrationen | export erstellen und beschriftet archivieren | | wöchentlich | export als archiv-backup ablegen | --- ## 5. datenbankmigrationen (struktur-änderungen) wenn sich das datenmodell weiterentwickelt — z. b. durch neue felder oder tabellen — stellt die plattform dedizierte hilfsprogramme bereit, die datenbankstruktur kontrolliert und sicher anzupassen: | programm | zweck | |---|---| | `script_db_adapt_to_models.py` | passt die datenbankstruktur automatisch an den aktuellen code an (mit vorschau-modus ohne änderungen) | | `script_db_audit_legacy_state.py` | analysiert den datenbankzustand vor einem bereinigungsschritt | | `script_db_migrate_*.py` | datenmigrations-programme für spezifische features | | `script_db_init_automation2.py` | erstellt die datenbankstruktur für das automation-feature | | `script_db_init_chatbot.py` | erstellt die datenbankstruktur für das chatbot-feature | beim start der anwendung prüft die plattform ausserdem automatisch, ob alle benötigten tabellen vorhanden sind, und legt fehlende selbstständig an. --- ## 6. datenschutz-hinweise - export-dateien enthalten **alle kundendaten** (mandate, benutzer, chats, dokumente, etc.) und sind entsprechend zu behandeln - dateien dürfen **nicht auf unsicheren speichern** (persönliche dropbox, e-mail, etc.) abgelegt werden - export-dateien sollten nach nutzung gelöscht werden wenn sie nicht mehr benötigt werden - der zugriff auf export/import ist auf sysadmins beschränkt und wird serverseitig geloggt --- ## zusammenfassung: datenbankoperationen im überblick | aufgabe | wie | |---|---| | fehlende tabellen beim start anlegen | automatisch beim plattform-start | | datenbank-export / backup | admin-ui (ein klick) oder entwickler-script | | datenbank-import / wiederherstellung | admin-ui mit geführtem prozess oder entwickler-script | | infrastruktur-snapshots | infomaniak cloud (serverebene) | | struktur-anpassungen bei updates | kontrolliert durch entwickler-hilfsprogramme | | datenbankpflege & bereinigung | admin-ui | ", "nextReview": "", "overdueReview": false, "zuPruefen": []}, {"id": "05_betrieb/20260528_drittanbieter-inventar.md", "path": "05_betrieb/20260528_drittanbieter-inventar.md", "chapter": "05_betrieb", "title": "Drittanbieter-Inventar: Plattform-Core", "filename": "20260528_drittanbieter-inventar.md", "meta": {}, "html": "<h1>Drittanbieter-Inventar: Plattform-Core<\/h1>\n<p>Dieses Dokument listet alle externen Dienste und Plattformen auf, mit denen die PowerOn-Plattform direkt integriert ist. Es basiert auf einer Auswertung des Quellcodes (Stand: Mai 2026).<\/p>\n<p><strong>Verantwortlicher für alle Drittdienste:<\/strong> Patrick Motsch — p.motsch@poweron.swiss<\/p>\n<hr>\n<h2>1. KI-Provider (LLM)<\/h2>\n<p>Diese Dienste liefern die KI-Intelligenz der Plattform. Fällt einer aus, sind die entsprechenden AI-Features nicht mehr verfügbar, je nach Konfiguration kann auf einen anderen Provider ausgewichen werden.<\/p>\n<h3>OpenAI<\/h3>\n<table><thead><tr><th>Feld<\/th><th>Wert<\/th><\/tr><\/thead><tbody><tr><td><strong>Kategorie<\/strong><\/td><td>LLM-Provider<\/td><\/tr><tr><td><strong>Verwendung<\/strong><\/td><td>Chat-Completions, Embeddings für RAG/Suche, Bildgenerierung (DALL·E). Primärer AI-Provider.<\/td><\/tr><tr><td><strong>Kritikalität<\/strong><\/td><td>Ja — Ausfall betrifft Chat, Agent, Automation-Features<\/td><\/tr><tr><td><strong>Ansprechpartner<\/strong><\/td><td>Patrick Motsch — p.motsch@poweron.swiss<\/td><\/tr><tr><td><strong>Statusseite<\/strong><\/td><td>https://status.openai.com<\/td><\/tr><tr><td><strong>Vertragslaufzeit / Kündigung<\/strong><\/td><td>unbefristet<\/td><\/tr><\/tbody><\/table>\n<h3>Anthropic (Claude)<\/h3>\n<table><thead><tr><th>Feld<\/th><th>Wert<\/th><\/tr><\/thead><tbody><tr><td><strong>Kategorie<\/strong><\/td><td>LLM-Provider<\/td><\/tr><tr><td><strong>Verwendung<\/strong><\/td><td>Chat-Completions, Agent-Workflows als Alternative zu OpenAI<\/td><\/tr><tr><td><strong>Kritikalität<\/strong><\/td><td>Nein — nur wenn als aktiver Provider konfiguriert<\/td><\/tr><tr><td><strong>Ansprechpartner<\/strong><\/td><td>Patrick Motsch — p.motsch@poweron.swiss<\/td><\/tr><tr><td><strong>Statusseite<\/strong><\/td><td>https://status.anthropic.com<\/td><\/tr><tr><td><strong>Vertragslaufzeit / Kündigung<\/strong><\/td><td>unbefristet<\/td><\/tr><\/tbody><\/table>\n<h3>Mistral AI<\/h3>\n<table><thead><tr><th>Feld<\/th><th>Wert<\/th><\/tr><\/thead><tbody><tr><td><strong>Kategorie<\/strong><\/td><td>LLM-Provider<\/td><\/tr><tr><td><strong>Verwendung<\/strong><\/td><td>Chat-Completions und Embeddings als Alternative zu OpenAI<\/td><\/tr><tr><td><strong>Kritikalität<\/strong><\/td><td>Nein — nur wenn als aktiver Provider konfiguriert<\/td><\/tr><tr><td><strong>Ansprechpartner<\/strong><\/td><td>Patrick Motsch — p.motsch@poweron.swiss<\/td><\/tr><tr><td><strong>Statusseite<\/strong><\/td><td>https://mistral.ai/status<\/td><\/tr><tr><td><strong>Vertragslaufzeit / Kündigung<\/strong><\/td><td>unbefristet<\/td><\/tr><\/tbody><\/table>\n<h3>Perplexity AI<\/h3>\n<table><thead><tr><th>Feld<\/th><th>Wert<\/th><\/tr><\/thead><tbody><tr><td><strong>Kategorie<\/strong><\/td><td>LLM-Provider (mit Web-Zugriff)<\/td><\/tr><tr><td><strong>Verwendung<\/strong><\/td><td>Chat-Completions mit integrierter Websuche<\/td><\/tr><tr><td><strong>Kritikalität<\/strong><\/td><td>Nein — optionaler Provider<\/td><\/tr><tr><td><strong>Ansprechpartner<\/strong><\/td><td>Patrick Motsch — p.motsch@poweron.swiss<\/td><\/tr><tr><td><strong>Statusseite<\/strong><\/td><td>https://status.perplexity.ai<\/td><\/tr><tr><td><strong>Vertragslaufzeit / Kündigung<\/strong><\/td><td>unbefristet<\/td><\/tr><\/tbody><\/table>\n<h3>Tavily<\/h3>\n<table><thead><tr><th>Feld<\/th><th>Wert<\/th><\/tr><\/thead><tbody><tr><td><strong>Kategorie<\/strong><\/td><td>AI-Websuche<\/td><\/tr><tr><td><strong>Verwendung<\/strong><\/td><td>Echtzeit-Websuche für AI-Agenten und LangChain-Workflows<\/td><\/tr><tr><td><strong>Kritikalität<\/strong><\/td><td>Nein — betrifft nur Research-/Agent-Features<\/td><\/tr><tr><td><strong>Ansprechpartner<\/strong><\/td><td>Patrick Motsch — p.motsch@poweron.swiss<\/td><\/tr><tr><td><strong>Statusseite<\/strong><\/td><td>https://status.tavily.com<\/td><\/tr><tr><td><strong>Vertragslaufzeit / Kündigung<\/strong><\/td><td>unbefristet<\/td><\/tr><\/tbody><\/table>\n<hr>\n<h2>2. Infrastruktur &amp; Hosting<\/h2>\n<h3>Infomaniak (Server &amp; Datenbank)<\/h3>\n<table><thead><tr><th>Feld<\/th><th>Wert<\/th><\/tr><\/thead><tbody><tr><td><strong>Kategorie<\/strong><\/td><td>Cloud Hosting / Managed Database<\/td><\/tr><tr><td><strong>Verwendung<\/strong><\/td><td>VM-Hosting für Prod- und Int-Server (<code>api.poweron.swiss<\/code>, <code>api-int.poweron.swiss<\/code>), PostgreSQL-Datenbank (<code>db.poweron.swiss<\/code>)<\/td><\/tr><tr><td><strong>Kritikalität<\/strong><\/td><td><strong>Ja<\/strong> — Totalausfall der Plattform bei Ausfall<\/td><\/tr><tr><td><strong>Ansprechpartner<\/strong><\/td><td>Patrick Motsch — p.motsch@poweron.swiss<\/td><\/tr><tr><td><strong>Statusseite<\/strong><\/td><td>https://status.infomaniak.com<\/td><\/tr><tr><td><strong>Vertragslaufzeit / Kündigung<\/strong><\/td><td>unbefristet<\/td><\/tr><\/tbody><\/table>\n<hr>\n<h2>3. Authentifizierung &amp; Login<\/h2>\n<h3>Microsoft Azure AD (OAuth)<\/h3>\n<table><thead><tr><th>Feld<\/th><th>Wert<\/th><\/tr><\/thead><tbody><tr><td><strong>Kategorie<\/strong><\/td><td>Auth / Identity Provider<\/td><\/tr><tr><td><strong>Verwendung<\/strong><\/td><td>Login via Microsoft-Konto (OAuth 2.0). Auch Basis für Microsoft 365 Datenzugriff.<\/td><\/tr><tr><td><strong>Kritikalität<\/strong><\/td><td>Ja — Login für Microsoft-Nutzer nicht möglich bei Ausfall<\/td><\/tr><tr><td><strong>Ansprechpartner<\/strong><\/td><td>Patrick Motsch — p.motsch@poweron.swiss<\/td><\/tr><tr><td><strong>Statusseite<\/strong><\/td><td>https://status.azure.com<\/td><\/tr><tr><td><strong>Vertragslaufzeit / Kündigung<\/strong><\/td><td>Kundenseitig<\/td><\/tr><\/tbody><\/table>\n<h3>Google OAuth<\/h3>\n<table><thead><tr><th>Feld<\/th><th>Wert<\/th><\/tr><\/thead><tbody><tr><td><strong>Kategorie<\/strong><\/td><td>Auth / Identity Provider<\/td><\/tr><tr><td><strong>Verwendung<\/strong><\/td><td>Login via Google-Konto. Auch Basis für Google Workspace Datenzugriff.<\/td><\/tr><tr><td><strong>Kritikalität<\/strong><\/td><td>Ja — Login für Google-Nutzer nicht möglich bei Ausfall<\/td><\/tr><tr><td><strong>Ansprechpartner<\/strong><\/td><td>Patrick Motsch — p.motsch@poweron.swiss<\/td><\/tr><tr><td><strong>Statusseite<\/strong><\/td><td>https://www.google.com/appsstatus<\/td><\/tr><tr><td><strong>Vertragslaufzeit / Kündigung<\/strong><\/td><td>Kundenseitig<\/td><\/tr><\/tbody><\/table>\n<hr>\n<h2>4. Daten-Konnektoren (Dateiablage, Kalender, Kontakte)<\/h2>\n<p>Diese Dienste sind optionale Verbindungen, die Endkunden in ihrer Mandanten-Konfiguration aktivieren können. Ein Ausfall betrifft die Kunden, die diesen Konnektor aktiv nutzen.<\/p>\n<h3>Microsoft 365 (SharePoint / OneDrive / Outlook / Calendar)<\/h3>\n<table><thead><tr><th>Feld<\/th><th>Wert<\/th><\/tr><\/thead><tbody><tr><td><strong>Kategorie<\/strong><\/td><td>Datei- &amp; Kommunikationsplattform (Konnektor)<\/td><\/tr><tr><td><strong>Verwendung<\/strong><\/td><td>Dateizugriff auf SharePoint/OneDrive, E-Mail-Lesen und -Senden via Outlook, Kalender-Integration via Microsoft Graph API<\/td><\/tr><tr><td><strong>Kritikalität<\/strong><\/td><td>Nein (nur für Kunden mit aktivem MS365-Konnektor)<\/td><\/tr><tr><td><strong>Ansprechpartner<\/strong><\/td><td>Patrick Motsch — p.motsch@poweron.swiss<\/td><\/tr><tr><td><strong>Statusseite<\/strong><\/td><td>https://status.office365.com<\/td><\/tr><tr><td><strong>Vertragslaufzeit / Kündigung<\/strong><\/td><td>Kundenseitig (eigenes Microsoft-Konto des Kunden)<\/td><\/tr><\/tbody><\/table>\n<h3>Google Workspace (Drive / Gmail / Calendar / Contacts)<\/h3>\n<table><thead><tr><th>Feld<\/th><th>Wert<\/th><\/tr><\/thead><tbody><tr><td><strong>Kategorie<\/strong><\/td><td>Datei- &amp; Kommunikationsplattform (Konnektor)<\/td><\/tr><tr><td><strong>Verwendung<\/strong><\/td><td>Dateizugriff auf Google Drive, Gmail lesen/senden, Google Calendar, Google Contacts via Google APIs<\/td><\/tr><tr><td><strong>Kritikalität<\/strong><\/td><td>Nein (nur für Kunden mit aktivem Google-Konnektor)<\/td><\/tr><tr><td><strong>Ansprechpartner<\/strong><\/td><td>Patrick Motsch — p.motsch@poweron.swiss<\/td><\/tr><tr><td><strong>Statusseite<\/strong><\/td><td>https://www.google.com/appsstatus<\/td><\/tr><tr><td><strong>Vertragslaufzeit / Kündigung<\/strong><\/td><td>Kundenseitig<\/td><\/tr><\/tbody><\/table>\n<h3>Infomaniak (kDrive / Kalender / Kontakte)<\/h3>\n<table><thead><tr><th>Feld<\/th><th>Wert<\/th><\/tr><\/thead><tbody><tr><td><strong>Kategorie<\/strong><\/td><td>Datei- &amp; Kommunikationsplattform (Konnektor)<\/td><\/tr><tr><td><strong>Verwendung<\/strong><\/td><td>Dateizugriff auf kDrive, Infomaniak Calendar, Infomaniak Contacts via Personal Access Token<\/td><\/tr><tr><td><strong>Kritikalität<\/strong><\/td><td>Nein (nur für Kunden mit aktivem Infomaniak-Konnektor)<\/td><\/tr><tr><td><strong>Ansprechpartner<\/strong><\/td><td>Patrick Motsch — p.motsch@poweron.swiss<\/td><\/tr><tr><td><strong>Statusseite<\/strong><\/td><td>https://status.infomaniak.com<\/td><\/tr><tr><td><strong>Vertragslaufzeit / Kündigung<\/strong><\/td><td>Kundenseitig<\/td><\/tr><\/tbody><\/table>\n<h3>FTP<\/h3>\n<table><thead><tr><th>Feld<\/th><th>Wert<\/th><\/tr><\/thead><tbody><tr><td><strong>Kategorie<\/strong><\/td><td>Dateikonnektor<\/td><\/tr><tr><td><strong>Verwendung<\/strong><\/td><td>Generischer FTP/SFTP-Zugriff für Kunden mit FTP-Verbindung<\/td><\/tr><tr><td><strong>Kritikalität<\/strong><\/td><td>Nein (nur für Kunden mit aktivem FTP-Konnektor)<\/td><\/tr><tr><td><strong>Ansprechpartner<\/strong><\/td><td>Patrick Motsch — p.motsch@poweron.swiss<\/td><\/tr><tr><td><strong>Statusseite<\/strong><\/td><td>Kundenseitig<\/td><\/tr><tr><td><strong>Vertragslaufzeit / Kündigung<\/strong><\/td><td>Kundenseitig<\/td><\/tr><\/tbody><\/table>\n<hr>\n<h2>5. Ticket-Systeme (Konnektoren)<\/h2>\n<h3>ClickUp<\/h3>\n<table><thead><tr><th>Feld<\/th><th>Wert<\/th><\/tr><\/thead><tbody><tr><td><strong>Kategorie<\/strong><\/td><td>Projektmanagement / Ticketing (Konnektor)<\/td><\/tr><tr><td><strong>Verwendung<\/strong><\/td><td>Aufgaben und Tickets lesen/erstellen/aktualisieren via ClickUp API v2 und OAuth<\/td><\/tr><tr><td><strong>Kritikalität<\/strong><\/td><td>Nein (nur für Kunden mit aktivem ClickUp-Konnektor)<\/td><\/tr><tr><td><strong>Ansprechpartner<\/strong><\/td><td>Patrick Motsch — p.motsch@poweron.swiss<\/td><\/tr><tr><td><strong>Statusseite<\/strong><\/td><td>https://clickupstatus.com<\/td><\/tr><tr><td><strong>Vertragslaufzeit / Kündigung<\/strong><\/td><td>Kundenseitig<\/td><\/tr><\/tbody><\/table>\n<h3>Jira<\/h3>\n<table><thead><tr><th>Feld<\/th><th>Wert<\/th><\/tr><\/thead><tbody><tr><td><strong>Kategorie<\/strong><\/td><td>Projektmanagement / Ticketing (Konnektor)<\/td><\/tr><tr><td><strong>Verwendung<\/strong><\/td><td>Tickets lesen/erstellen via Jira REST API<\/td><\/tr><tr><td><strong>Kritikalität<\/strong><\/td><td>Nein (nur für Kunden mit aktivem Jira-Konnektor)<\/td><\/tr><tr><td><strong>Ansprechpartner<\/strong><\/td><td>Patrick Motsch — p.motsch@poweron.swiss<\/td><\/tr><tr><td><strong>Statusseite<\/strong><\/td><td>https://jira-software.status.atlassian.com<\/td><\/tr><tr><td><strong>Vertragslaufzeit / Kündigung<\/strong><\/td><td>Kundenseitig<\/td><\/tr><\/tbody><\/table>\n<h3>Redmine<\/h3>\n<table><thead><tr><th>Feld<\/th><th>Wert<\/th><\/tr><\/thead><tbody><tr><td><strong>Kategorie<\/strong><\/td><td>Projektmanagement / Ticketing (Konnektor)<\/td><\/tr><tr><td><strong>Verwendung<\/strong><\/td><td>Tickets lesen/erstellen via Redmine REST API<\/td><\/tr><tr><td><strong>Kritikalität<\/strong><\/td><td>Nein (nur für Kunden mit aktivem Redmine-Konnektor)<\/td><\/tr><tr><td><strong>Ansprechpartner<\/strong><\/td><td>Patrick Motsch — p.motsch@poweron.swiss<\/td><\/tr><tr><td><strong>Statusseite<\/strong><\/td><td>Kundenseitig<\/td><\/tr><tr><td><strong>Vertragslaufzeit / Kündigung<\/strong><\/td><td>Kundenseitig<\/td><\/tr><\/tbody><\/table>\n<hr>\n<h2>6. Payment<\/h2>\n<h3>Stripe<\/h3>\n<table><thead><tr><th>Feld<\/th><th>Wert<\/th><\/tr><\/thead><tbody><tr><td><strong>Kategorie<\/strong><\/td><td>Payment Provider<\/td><\/tr><tr><td><strong>Verwendung<\/strong><\/td><td>Abonnement-Management, Zahlungsabwicklung, automatische Steuerberechnung (CH MwSt). API-Version <code>2026-01-28<\/code>.<\/td><\/tr><tr><td><strong>Kritikalität<\/strong><\/td><td><strong>Ja<\/strong> — Neue Abonnements und Zahlungen schlagen fehl bei Ausfall<\/td><\/tr><tr><td><strong>Ansprechpartner<\/strong><\/td><td>Patrick Motsch — p.motsch@poweron.swiss<\/td><\/tr><tr><td><strong>Statusseite<\/strong><\/td><td>https://status.stripe.com<\/td><\/tr><tr><td><strong>Vertragslaufzeit / Kündigung<\/strong><\/td><td>unbefristet<\/td><\/tr><\/tbody><\/table>\n<hr>\n<h2>7. Messaging &amp; Kommunikation<\/h2>\n<h3>Azure Communication Services (E-Mail)<\/h3>\n<table><thead><tr><th>Feld<\/th><th>Wert<\/th><\/tr><\/thead><tbody><tr><td><strong>Kategorie<\/strong><\/td><td>Transaktions-E-Mail<\/td><\/tr><tr><td><strong>Verwendung<\/strong><\/td><td>Systemmails (Einladungen, Passwort-Reset, Rechnungen) via <code>DoNotReply@poweron.swiss<\/code>. Endpunkt: <code>mailing-poweron-prod.switzerland.communication.azure.com<\/code><\/td><\/tr><tr><td><strong>Kritikalität<\/strong><\/td><td><strong>Ja<\/strong> — Einladungs- und Benachrichtigungs-E-Mails werden nicht zugestellt<\/td><\/tr><tr><td><strong>Ansprechpartner<\/strong><\/td><td>Patrick Motsch — p.motsch@poweron.swiss<\/td><\/tr><tr><td><strong>Statusseite<\/strong><\/td><td>https://status.azure.com<\/td><\/tr><tr><td><strong>Vertragslaufzeit / Kündigung<\/strong><\/td><td>unbefristet<\/td><\/tr><\/tbody><\/table>\n<h3>Twilio (SMS)<\/h3>\n<table><thead><tr><th>Feld<\/th><th>Wert<\/th><\/tr><\/thead><tbody><tr><td><strong>Kategorie<\/strong><\/td><td>SMS-Gateway<\/td><\/tr><tr><td><strong>Verwendung<\/strong><\/td><td>SMS-Versand (z. B. 2FA, Benachrichtigungen)<\/td><\/tr><tr><td><strong>Kritikalität<\/strong><\/td><td>Nein — nur wenn SMS-Feature aktiv genutzt wird<\/td><\/tr><tr><td><strong>Ansprechpartner<\/strong><\/td><td>Patrick Motsch — p.motsch@poweron.swiss<\/td><\/tr><tr><td><strong>Statusseite<\/strong><\/td><td>https://status.twilio.com<\/td><\/tr><tr><td><strong>Vertragslaufzeit / Kündigung<\/strong><\/td><td>unbefristet<\/td><\/tr><\/tbody><\/table>\n<hr>\n<h2>8. Google Cloud Services<\/h2>\n<h3>Google Cloud Speech-to-Text / Text-to-Speech<\/h3>\n<table><thead><tr><th>Feld<\/th><th>Wert<\/th><\/tr><\/thead><tbody><tr><td><strong>Kategorie<\/strong><\/td><td>Sprach-KI (STT/TTS)<\/td><\/tr><tr><td><strong>Verwendung<\/strong><\/td><td>Sprache-zu-Text-Transkription und Text-zu-Sprache-Synthese für Voice-Features<\/td><\/tr><tr><td><strong>Kritikalität<\/strong><\/td><td>Nein — betrifft nur Voice-Features<\/td><\/tr><tr><td><strong>Ansprechpartner<\/strong><\/td><td>Patrick Motsch — p.motsch@poweron.swiss<\/td><\/tr><tr><td><strong>Statusseite<\/strong><\/td><td>https://status.cloud.google.com<\/td><\/tr><tr><td><strong>Vertragslaufzeit / Kündigung<\/strong><\/td><td>unbefristet<\/td><\/tr><\/tbody><\/table>\n<h3>Google Cloud Translate<\/h3>\n<table><thead><tr><th>Feld<\/th><th>Wert<\/th><\/tr><\/thead><tbody><tr><td><strong>Kategorie<\/strong><\/td><td>Übersetzungsdienst<\/td><\/tr><tr><td><strong>Verwendung<\/strong><\/td><td>Automatische Übersetzung von Inhalten<\/td><\/tr><tr><td><strong>Kritikalität<\/strong><\/td><td>Nein — betrifft nur Übersetzungsfeatures<\/td><\/tr><tr><td><strong>Ansprechpartner<\/strong><\/td><td>Patrick Motsch — p.motsch@poweron.swiss<\/td><\/tr><tr><td><strong>Statusseite<\/strong><\/td><td>https://status.cloud.google.com<\/td><\/tr><tr><td><strong>Vertragslaufzeit / Kündigung<\/strong><\/td><td>unbefristet<\/td><\/tr><\/tbody><\/table>\n<hr>\n<h2>9. Schweizer Geodienste (öffentliche APIs)<\/h2>\n<p>Diese Dienste sind öffentlich zugängliche Schnittstellen des Bundes und der Kantone. Kein Login, kein Vertrag erforderlich — aber ein Ausfall beeinträchtigt Geo-Features.<\/p>\n<h3>swisstopo MapServer &amp; Geocoding<\/h3>\n<table><thead><tr><th>Feld<\/th><th>Wert<\/th><\/tr><\/thead><tbody><tr><td><strong>Kategorie<\/strong><\/td><td>Geodaten / Kartendienst<\/td><\/tr><tr><td><strong>Verwendung<\/strong><\/td><td>Adress-Geocoding, Karteninformationen, Parzellen-Identifikation via <code>api3.geo.admin.ch<\/code><\/td><\/tr><tr><td><strong>Kritikalität<\/strong><\/td><td>Nein — betrifft nur Immobilien-/Geo-Features<\/td><\/tr><tr><td><strong>Ansprechpartner<\/strong><\/td><td>Patrick Motsch — p.motsch@poweron.swiss<\/td><\/tr><tr><td><strong>Statusseite<\/strong><\/td><td>https://www.geo.admin.ch<\/td><\/tr><tr><td><strong>Vertragslaufzeit / Kündigung<\/strong><\/td><td>Kostenloser öffentlicher Dienst<\/td><\/tr><\/tbody><\/table>\n<h3>STAC API (swisstopo)<\/h3>\n<table><thead><tr><th>Feld<\/th><th>Wert<\/th><\/tr><\/thead><tbody><tr><td><strong>Kategorie<\/strong><\/td><td>Geodaten (Satellitenbilder / Rasterdaten)<\/td><\/tr><tr><td><strong>Verwendung<\/strong><\/td><td>Zugriff auf georäumliche Katalogdaten via <code>data.geo.admin.ch<\/code><\/td><\/tr><tr><td><strong>Kritikalität<\/strong><\/td><td>Nein — betrifft nur Geo-Features<\/td><\/tr><tr><td><strong>Ansprechpartner<\/strong><\/td><td>Patrick Motsch — p.motsch@poweron.swiss<\/td><\/tr><tr><td><strong>Statusseite<\/strong><\/td><td>https://www.geo.admin.ch<\/td><\/tr><tr><td><strong>Vertragslaufzeit / Kündigung<\/strong><\/td><td>Kostenloser öffentlicher Dienst<\/td><\/tr><\/tbody><\/table>\n<h3>ÖREB-Kataster WFS (Kanton Zürich)<\/h3>\n<table><thead><tr><th>Feld<\/th><th>Wert<\/th><\/tr><\/thead><tbody><tr><td><strong>Kategorie<\/strong><\/td><td>Geodaten / Rechtliche Grundlagen Grundstücke<\/td><\/tr><tr><td><strong>Verwendung<\/strong><\/td><td>Abruf öffentlich-rechtlicher Eigentumsbeschränkungen (ÖREB) für Parzellen via <code>maps.zh.ch<\/code><\/td><\/tr><tr><td><strong>Kritikalität<\/strong><\/td><td>Nein — betrifft nur Immobilien-Features (ZH)<\/td><\/tr><tr><td><strong>Ansprechpartner<\/strong><\/td><td>Patrick Motsch — p.motsch@poweron.swiss<\/td><\/tr><tr><td><strong>Statusseite<\/strong><\/td><td>https://www.zh.ch/de/direktion-der-justiz-und-des-innern/geoinformation.html<\/td><\/tr><tr><td><strong>Vertragslaufzeit / Kündigung<\/strong><\/td><td>Kostenloser öffentlicher Dienst<\/td><\/tr><\/tbody><\/table>\n<h3>Geodienste.ch (Amtliche Vermessung ZH)<\/h3>\n<table><thead><tr><th>Feld<\/th><th>Wert<\/th><\/tr><\/thead><tbody><tr><td><strong>Kategorie<\/strong><\/td><td>Geodaten / Amtliche Vermessung<\/td><\/tr><tr><td><strong>Verwendung<\/strong><\/td><td>WFS-Abfragen für Parzellensuche via <code>www.geodienste.ch<\/code><\/td><\/tr><tr><td><strong>Kritikalität<\/strong><\/td><td>Nein — betrifft nur Immobilien-Features<\/td><\/tr><tr><td><strong>Ansprechpartner<\/strong><\/td><td>Patrick Motsch — p.motsch@poweron.swiss<\/td><\/tr><tr><td><strong>Statusseite<\/strong><\/td><td>https://www.geodienste.ch<\/td><\/tr><tr><td><strong>Vertragslaufzeit / Kündigung<\/strong><\/td><td>Kostenloser öffentlicher Dienst<\/td><\/tr><\/tbody><\/table>", "text": "# drittanbieter-inventar: plattform-core dieses dokument listet alle externen dienste und plattformen auf, mit denen die poweron-plattform direkt integriert ist. es basiert auf einer auswertung des quellcodes (stand: mai 2026). **verantwortlicher für alle drittdienste:** patrick motsch — p.motsch@poweron.swiss --- ## 1. ki-provider (llm) diese dienste liefern die ki-intelligenz der plattform. fällt einer aus, sind die entsprechenden ai-features nicht mehr verfügbar, je nach konfiguration kann auf einen anderen provider ausgewichen werden. ### openai | feld | wert | |---|---| | **kategorie** | llm-provider | | **verwendung** | chat-completions, embeddings für rag/suche, bildgenerierung (dall·e). primärer ai-provider. | | **kritikalität** | ja — ausfall betrifft chat, agent, automation-features | | **ansprechpartner** | patrick motsch — p.motsch@poweron.swiss | | **statusseite** | https://status.openai.com | | **vertragslaufzeit / kündigung** | unbefristet | ### anthropic (claude) | feld | wert | |---|---| | **kategorie** | llm-provider | | **verwendung** | chat-completions, agent-workflows als alternative zu openai | | **kritikalität** | nein — nur wenn als aktiver provider konfiguriert | | **ansprechpartner** | patrick motsch — p.motsch@poweron.swiss | | **statusseite** | https://status.anthropic.com | | **vertragslaufzeit / kündigung** | unbefristet | ### mistral ai | feld | wert | |---|---| | **kategorie** | llm-provider | | **verwendung** | chat-completions und embeddings als alternative zu openai | | **kritikalität** | nein — nur wenn als aktiver provider konfiguriert | | **ansprechpartner** | patrick motsch — p.motsch@poweron.swiss | | **statusseite** | https://mistral.ai/status | | **vertragslaufzeit / kündigung** | unbefristet | ### perplexity ai | feld | wert | |---|---| | **kategorie** | llm-provider (mit web-zugriff) | | **verwendung** | chat-completions mit integrierter websuche | | **kritikalität** | nein — optionaler provider | | **ansprechpartner** | patrick motsch — p.motsch@poweron.swiss | | **statusseite** | https://status.perplexity.ai | | **vertragslaufzeit / kündigung** | unbefristet | ### tavily | feld | wert | |---|---| | **kategorie** | ai-websuche | | **verwendung** | echtzeit-websuche für ai-agenten und langchain-workflows | | **kritikalität** | nein — betrifft nur research-/agent-features | | **ansprechpartner** | patrick motsch — p.motsch@poweron.swiss | | **statusseite** | https://status.tavily.com | | **vertragslaufzeit / kündigung** | unbefristet | --- ## 2. infrastruktur & hosting ### infomaniak (server & datenbank) | feld | wert | |---|---| | **kategorie** | cloud hosting / managed database | | **verwendung** | vm-hosting für prod- und int-server (`api.poweron.swiss`, `api-int.poweron.swiss`), postgresql-datenbank (`db.poweron.swiss`) | | **kritikalität** | **ja** — totalausfall der plattform bei ausfall | | **ansprechpartner** | patrick motsch — p.motsch@poweron.swiss | | **statusseite** | https://status.infomaniak.com | | **vertragslaufzeit / kündigung** | unbefristet | --- ## 3. authentifizierung & login ### microsoft azure ad (oauth) | feld | wert | |---|---| | **kategorie** | auth / identity provider | | **verwendung** | login via microsoft-konto (oauth 2.0). auch basis für microsoft 365 datenzugriff. | | **kritikalität** | ja — login für microsoft-nutzer nicht möglich bei ausfall | | **ansprechpartner** | patrick motsch — p.motsch@poweron.swiss | | **statusseite** | https://status.azure.com | | **vertragslaufzeit / kündigung** | kundenseitig | ### google oauth | feld | wert | |---|---| | **kategorie** | auth / identity provider | | **verwendung** | login via google-konto. auch basis für google workspace datenzugriff. | | **kritikalität** | ja — login für google-nutzer nicht möglich bei ausfall | | **ansprechpartner** | patrick motsch — p.motsch@poweron.swiss | | **statusseite** | https://www.google.com/appsstatus | | **vertragslaufzeit / kündigung** | kundenseitig | --- ## 4. daten-konnektoren (dateiablage, kalender, kontakte) diese dienste sind optionale verbindungen, die endkunden in ihrer mandanten-konfiguration aktivieren können. ein ausfall betrifft die kunden, die diesen konnektor aktiv nutzen. ### microsoft 365 (sharepoint / onedrive / outlook / calendar) | feld | wert | |---|---| | **kategorie** | datei- & kommunikationsplattform (konnektor) | | **verwendung** | dateizugriff auf sharepoint/onedrive, e-mail-lesen und -senden via outlook, kalender-integration via microsoft graph api | | **kritikalität** | nein (nur für kunden mit aktivem ms365-konnektor) | | **ansprechpartner** | patrick motsch — p.motsch@poweron.swiss | | **statusseite** | https://status.office365.com | | **vertragslaufzeit / kündigung** | kundenseitig (eigenes microsoft-konto des kunden) | ### google workspace (drive / gmail / calendar / contacts) | feld | wert | |---|---| | **kategorie** | datei- & kommunikationsplattform (konnektor) | | **verwendung** | dateizugriff auf google drive, gmail lesen/senden, google calendar, google contacts via google apis | | **kritikalität** | nein (nur für kunden mit aktivem google-konnektor) | | **ansprechpartner** | patrick motsch — p.motsch@poweron.swiss | | **statusseite** | https://www.google.com/appsstatus | | **vertragslaufzeit / kündigung** | kundenseitig | ### infomaniak (kdrive / kalender / kontakte) | feld | wert | |---|---| | **kategorie** | datei- & kommunikationsplattform (konnektor) | | **verwendung** | dateizugriff auf kdrive, infomaniak calendar, infomaniak contacts via personal access token | | **kritikalität** | nein (nur für kunden mit aktivem infomaniak-konnektor) | | **ansprechpartner** | patrick motsch — p.motsch@poweron.swiss | | **statusseite** | https://status.infomaniak.com | | **vertragslaufzeit / kündigung** | kundenseitig | ### ftp | feld | wert | |---|---| | **kategorie** | dateikonnektor | | **verwendung** | generischer ftp/sftp-zugriff für kunden mit ftp-verbindung | | **kritikalität** | nein (nur für kunden mit aktivem ftp-konnektor) | | **ansprechpartner** | patrick motsch — p.motsch@poweron.swiss | | **statusseite** | kundenseitig | | **vertragslaufzeit / kündigung** | kundenseitig | --- ## 5. ticket-systeme (konnektoren) ### clickup | feld | wert | |---|---| | **kategorie** | projektmanagement / ticketing (konnektor) | | **verwendung** | aufgaben und tickets lesen/erstellen/aktualisieren via clickup api v2 und oauth | | **kritikalität** | nein (nur für kunden mit aktivem clickup-konnektor) | | **ansprechpartner** | patrick motsch — p.motsch@poweron.swiss | | **statusseite** | https://clickupstatus.com | | **vertragslaufzeit / kündigung** | kundenseitig | ### jira | feld | wert | |---|---| | **kategorie** | projektmanagement / ticketing (konnektor) | | **verwendung** | tickets lesen/erstellen via jira rest api | | **kritikalität** | nein (nur für kunden mit aktivem jira-konnektor) | | **ansprechpartner** | patrick motsch — p.motsch@poweron.swiss | | **statusseite** | https://jira-software.status.atlassian.com | | **vertragslaufzeit / kündigung** | kundenseitig | ### redmine | feld | wert | |---|---| | **kategorie** | projektmanagement / ticketing (konnektor) | | **verwendung** | tickets lesen/erstellen via redmine rest api | | **kritikalität** | nein (nur für kunden mit aktivem redmine-konnektor) | | **ansprechpartner** | patrick motsch — p.motsch@poweron.swiss | | **statusseite** | kundenseitig | | **vertragslaufzeit / kündigung** | kundenseitig | --- ## 6. payment ### stripe | feld | wert | |---|---| | **kategorie** | payment provider | | **verwendung** | abonnement-management, zahlungsabwicklung, automatische steuerberechnung (ch mwst). api-version `2026-01-28`. | | **kritikalität** | **ja** — neue abonnements und zahlungen schlagen fehl bei ausfall | | **ansprechpartner** | patrick motsch — p.motsch@poweron.swiss | | **statusseite** | https://status.stripe.com | | **vertragslaufzeit / kündigung** | unbefristet | --- ## 7. messaging & kommunikation ### azure communication services (e-mail) | feld | wert | |---|---| | **kategorie** | transaktions-e-mail | | **verwendung** | systemmails (einladungen, passwort-reset, rechnungen) via `donotreply@poweron.swiss`. endpunkt: `mailing-poweron-prod.switzerland.communication.azure.com` | | **kritikalität** | **ja** — einladungs- und benachrichtigungs-e-mails werden nicht zugestellt | | **ansprechpartner** | patrick motsch — p.motsch@poweron.swiss | | **statusseite** | https://status.azure.com | | **vertragslaufzeit / kündigung** | unbefristet | ### twilio (sms) | feld | wert | |---|---| | **kategorie** | sms-gateway | | **verwendung** | sms-versand (z. b. 2fa, benachrichtigungen) | | **kritikalität** | nein — nur wenn sms-feature aktiv genutzt wird | | **ansprechpartner** | patrick motsch — p.motsch@poweron.swiss | | **statusseite** | https://status.twilio.com | | **vertragslaufzeit / kündigung** | unbefristet | --- ## 8. google cloud services ### google cloud speech-to-text / text-to-speech | feld | wert | |---|---| | **kategorie** | sprach-ki (stt/tts) | | **verwendung** | sprache-zu-text-transkription und text-zu-sprache-synthese für voice-features | | **kritikalität** | nein — betrifft nur voice-features | | **ansprechpartner** | patrick motsch — p.motsch@poweron.swiss | | **statusseite** | https://status.cloud.google.com | | **vertragslaufzeit / kündigung** | unbefristet | ### google cloud translate | feld | wert | |---|---| | **kategorie** | übersetzungsdienst | | **verwendung** | automatische übersetzung von inhalten | | **kritikalität** | nein — betrifft nur übersetzungsfeatures | | **ansprechpartner** | patrick motsch — p.motsch@poweron.swiss | | **statusseite** | https://status.cloud.google.com | | **vertragslaufzeit / kündigung** | unbefristet | --- ## 9. schweizer geodienste (öffentliche apis) diese dienste sind öffentlich zugängliche schnittstellen des bundes und der kantone. kein login, kein vertrag erforderlich — aber ein ausfall beeinträchtigt geo-features. ### swisstopo mapserver & geocoding | feld | wert | |---|---| | **kategorie** | geodaten / kartendienst | | **verwendung** | adress-geocoding, karteninformationen, parzellen-identifikation via `api3.geo.admin.ch` | | **kritikalität** | nein — betrifft nur immobilien-/geo-features | | **ansprechpartner** | patrick motsch — p.motsch@poweron.swiss | | **statusseite** | https://www.geo.admin.ch | | **vertragslaufzeit / kündigung** | kostenloser öffentlicher dienst | ### stac api (swisstopo) | feld | wert | |---|---| | **kategorie** | geodaten (satellitenbilder / rasterdaten) | | **verwendung** | zugriff auf georäumliche katalogdaten via `data.geo.admin.ch` | | **kritikalität** | nein — betrifft nur geo-features | | **ansprechpartner** | patrick motsch — p.motsch@poweron.swiss | | **statusseite** | https://www.geo.admin.ch | | **vertragslaufzeit / kündigung** | kostenloser öffentlicher dienst | ### öreb-kataster wfs (kanton zürich) | feld | wert | |---|---| | **kategorie** | geodaten / rechtliche grundlagen grundstücke | | **verwendung** | abruf öffentlich-rechtlicher eigentumsbeschränkungen (öreb) für parzellen via `maps.zh.ch` | | **kritikalität** | nein — betrifft nur immobilien-features (zh) | | **ansprechpartner** | patrick motsch — p.motsch@poweron.swiss | | **statusseite** | https://www.zh.ch/de/direktion-der-justiz-und-des-innern/geoinformation.html | | **vertragslaufzeit / kündigung** | kostenloser öffentlicher dienst | ### geodienste.ch (amtliche vermessung zh) | feld | wert | |---|---| | **kategorie** | geodaten / amtliche vermessung | | **verwendung** | wfs-abfragen für parzellensuche via `www.geodienste.ch` | | **kritikalität** | nein — betrifft nur immobilien-features | | **ansprechpartner** | patrick motsch — p.motsch@poweron.swiss | | **statusseite** | https://www.geodienste.ch | | **vertragslaufzeit / kündigung** | kostenloser öffentlicher dienst | ", "nextReview": "", "overdueReview": false, "zuPruefen": []}, {"id": "05_betrieb/20260528_feature_release_bugfix.md", "path": "05_betrieb/20260528_feature_release_bugfix.md", "chapter": "05_betrieb", "title": "Auditkonformer Prozess: Feature-Entwicklung, Releases und Bug-Management", "filename": "20260528_feature_release_bugfix.md", "meta": {}, "html": "<h1>Auditkonformer Prozess: Feature-Entwicklung, Releases und Bug-Management<\/h1>\n<p><strong>Dokumenttyp:<\/strong> Prozessbeschreibung / SOP <strong>Geltungsbereich:<\/strong> Softwareentwicklung, Release Management, Bugfixing <strong>Version:<\/strong> 1.0 <strong>Status:<\/strong> Entwurf zur internen Freigabe <strong>Owner:<\/strong> Entwicklung / Produktverantwortung <strong>Letzte Aktualisierung:<\/strong> 28.05.2026<\/p>\n<hr>\n<h2>1. Zweck des Dokuments<\/h2>\n<p>Dieses Dokument beschreibt einen auditkonformen Prozess für:<\/p>\n<ul><li>die strukturierte Aufnahme, Bewertung und Umsetzung von Feature-Requests,<\/li><li>die Durchführung technischer Workshops vor Implementierungsbeginn,<\/li><li>die kontrollierte Entwicklung über Branches, Reviews und Staging-Verifikation,<\/li><li>die versionierte Erstellung von Release Notes,<\/li><li>die Erfassung, Priorisierung, Bearbeitung und Dokumentation von Bugs,<\/li><li>die Nachvollziehbarkeit von Entscheidungen, Änderungen, Verantwortlichkeiten und Freigaben.<\/li><\/ul>\n<p>Ziel ist es, einen nachvollziehbaren, wiederholbaren und prüfbaren Entwicklungs- und Release-Prozess sicherzustellen.<\/p>\n<hr>\n<h2>2. Prozessübersicht<\/h2>\n<p>Der Gesamtprozess besteht aus zwei Hauptsträngen:<\/p>\n<ol><li><strong>Feature-Entwicklung &amp; Releases<\/strong><\/li><li><strong>Bug-Management &amp; Bugfixing<\/strong><\/li><\/ol>\n<p>Beide Stränge folgen gemeinsamen Prinzipien:<\/p>\n<ul><li>zentrale Erfassung aller Anforderungen und Fehler,<\/li><li>dokumentierte Bewertung und Priorisierung,<\/li><li>nachvollziehbare technische Entscheidungen,<\/li><li>Vier-Augen-Prinzip vor produktivem Release,<\/li><li>dokumentierte Release Notes,<\/li><li>klare Verantwortlichkeiten,<\/li><li>prüfbare Nachweise in Tickets, Branches, Pull Requests und Changelogs.<\/li><\/ul>\n<hr>\n<h2>3. Prozessbild<\/h2>\n<pre class=\"mermaid\">flowchart TD\n\n    A[Feature Request oder Bug Report geht ein] --&gt; B{Art des Eingangs}\n\n    B --&gt;|Feature Request| F1[Zentrale Erfassung&lt;br/&gt;z. B. GitHub Issues, Linear, Notion]\n    F1 --&gt; F2[Priorisierung nach Kundenwert,&lt;br/&gt;strategischer Relevanz und Aufwand]\n    F2 --&gt; F3[Feature mit hoher Priorität&lt;br/&gt;für Tech Workshop vormerken]\n    F3 --&gt; F4[Tech Workshop mit beiden Entwicklern]\n    F4 --&gt; F5[Architektur-, API-, Datenmodell-&lt;br/&gt;und Schnittstellenanalyse]\n    F5 --&gt; F6[Aufwandsschätzung,&lt;br/&gt;Aufgabenverteilung und Akzeptanzkriterien]\n    F6 --&gt; F7[Dokumentation im Issue&lt;br/&gt;oder internen Ticket]\n    F7 --&gt; F8[Entwicklung auf Feature Branch&lt;br/&gt;feature/kurzbeschreibung]\n    F8 --&gt; F9[Commits mit aussagekräftigen Messages&lt;br/&gt;z. B. feat:, fix:, chore:]\n    F9 --&gt; F10[Code Review durch zweiten Entwickler]\n    F10 --&gt; F11{Review bestanden?}\n    F11 --&gt;|Nein| F12[Überarbeitung durch Entwickler]\n    F12 --&gt; F10\n    F11 --&gt;|Ja| F13[Merge in Main/Development Branch]\n    F13 --&gt; F14[Deployment in Staging]\n    F14 --&gt; F15[Finale Verifikation gegen Akzeptanzkriterien]\n    F15 --&gt; F16{Verifikation bestanden?}\n    F16 --&gt;|Nein| F12\n    F16 --&gt;|Ja| F17[Release / Push in Produktion]\n    F17 --&gt; F18[Release Notes erstellen und versionieren]\n    F18 --&gt; F19[CHANGELOG.md und /changelog aktualisieren]\n\n    B --&gt;|Bug Report| G1[Zentrale Erfassung&lt;br/&gt;z. B. ClickUp Formular]\n    G1 --&gt; G2[Initiale Antwort gemäß Schweregrad]\n    G2 --&gt; G3[Triage durch Mitarbeiter 1]\n    G3 --&gt; G4[Prüfung auf Vollständigkeit&lt;br/&gt;und Reproduzierbarkeit]\n    G4 --&gt; G5[Klassifizierung:&lt;br/&gt;Kritisch / Hoch / Mittel / Niedrig]\n    G5 --&gt; G6[Zuweisung an zuständigen Entwickler]\n    G6 --&gt; G7[Fix auf Bugfix Branch&lt;br/&gt;fix/kurzbeschreibung]\n    G7 --&gt; G8[Code Review durch Mitarbeiter 1]\n    G8 --&gt; G9{Review bestanden?}\n    G9 --&gt;|Nein| G10[Nachbesserung durch Entwickler]\n    G10 --&gt; G8\n    G9 --&gt;|Ja| G11[Merge analog Feature-Prozess]\n    G11 --&gt; G12[Staging-Verifikation]\n    G12 --&gt; G13{Fix verifiziert?}\n    G13 --&gt;|Nein| G10\n    G13 --&gt;|Ja| G14[Release in Produktion]\n    G14 --&gt; G15[Dokumentation in Release Notes / CHANGELOG]\n    G15 --&gt; G16[Melder informieren und Ticket schließen]<\/pre>\n<hr>\n<h2>4. Rollen und Verantwortlichkeiten<\/h2>\n<table><thead><tr><th>Rolle<\/th><th>Verantwortung<\/th><\/tr><\/thead><tbody><tr><td>Entwickler 1<\/td><td>Teilnahme am Tech Workshop, Entwicklung, Review, ggf. Triage<\/td><\/tr><tr><td>Entwickler 2<\/td><td>Teilnahme am Tech Workshop, Entwicklung, Review, Release-Durchführung<\/td><\/tr><tr><td>Mitarbeiter 1 / Triage-Rolle<\/td><td>Prüfung eingehender Bug Reports, Klassifizierung, Reproduzierbarkeit, Zuweisung, Review von Bugfixes<\/td><\/tr><tr><td>Mitarbeiter 2 / Entwicklungsrolle<\/td><td>Umsetzung von Bugfixes auf separatem Branch, Dokumentation technischer Änderungen<\/td><\/tr><tr><td>Release-Verantwortlicher<\/td><td>Durchführung des Releases, Pflege der Release Notes, Aktualisierung von CHANGELOG.md und /changelog<\/td><\/tr><tr><td>Produkt-/Business-Verantwortlicher<\/td><td>Bewertung von Kundenwert und strategischer Relevanz bei Feature Requests<\/td><\/tr><\/tbody><\/table>\n<hr>\n<h1>5. Feature-Entwicklung &amp; Releases<\/h1>\n<h2>5.1 Feature-Request-Prozess<\/h2>\n<p>Eingehende Feature-Requests werden zentral gesammelt. Mögliche Systeme sind:<\/p>\n<ul><li>GitHub Issues,<\/li><li>Linear,<\/li><li>Notion,<\/li><li>ein internes Produkt-Backlog.<\/li><\/ul>\n<p>Jeder Feature Request muss mindestens folgende Informationen enthalten:<\/p>\n<table><thead><tr><th>Pflichtfeld<\/th><th>Beschreibung<\/th><\/tr><\/thead><tbody><tr><td>Titel<\/td><td>Kurze, eindeutige Beschreibung des gewünschten Features<\/td><\/tr><tr><td>Beschreibung<\/td><td>Fachliche Beschreibung des Bedarfs<\/td><\/tr><tr><td>Nutzen<\/td><td>Erwarteter Mehrwert für Kunden, Nutzer oder internes Team<\/td><\/tr><tr><td>Quelle<\/td><td>Kunde, interner Stakeholder, Entwickler, Support oder Management<\/td><\/tr><tr><td>Prioritätsbewertung<\/td><td>Bewertung nach definierten Kriterien<\/td><\/tr><tr><td>Status<\/td><td>Neu, in Bewertung, geplant, in Umsetzung, umgesetzt, abgelehnt<\/td><\/tr><\/tbody><\/table>\n<h2>5.2 Priorisierung<\/h2>\n<p>Die Priorisierung erfolgt anhand folgender Kriterien:<\/p>\n<table><thead><tr><th>Kriterium<\/th><th>Beschreibung<\/th><th>Bewertung<\/th><\/tr><\/thead><tbody><tr><td>Kundenwert<\/td><td>Relevanz für Nutzer oder Kunden<\/td><td>1 = gering, 2 = mittel, 3 = hoch<\/td><\/tr><tr><td>Strategische Relevanz<\/td><td>Beitrag zur Produktstrategie<\/td><td>1 = gering, 2 = mittel, 3 = hoch<\/td><\/tr><tr><td>Implementierungsaufwand<\/td><td>Technischer und organisatorischer Aufwand<\/td><td>1 = gering, 2 = mittel, 3 = hoch<\/td><\/tr><\/tbody><\/table>\n<p>Alternativ kann eine MoSCoW-Kategorisierung verwendet werden:<\/p>\n<table><thead><tr><th>Kategorie<\/th><th>Bedeutung<\/th><\/tr><\/thead><tbody><tr><td>Must have<\/td><td>zwingend erforderlich<\/td><\/tr><tr><td>Should have<\/td><td>wichtig, aber nicht kritisch<\/td><\/tr><tr><td>Could have<\/td><td>optional, wenn Kapazität vorhanden<\/td><\/tr><tr><td>Won't have<\/td><td>bewusst zurückgestellt<\/td><\/tr><\/tbody><\/table>\n<p>Features mit höchster Priorität werden für den nächsten Tech Workshop vorgemerkt.<\/p>\n<hr>\n<h2>5.3 Tech Workshop vor Implementierungsbeginn<\/h2>\n<p>Vor der Implementierung priorisierter Features findet ein Tech Workshop statt.<\/p>\n<p><strong>Teilnehmer:<\/strong><\/p>\n<ul><li>beide Entwickler,<\/li><li>optional Produkt-/Business-Verantwortlicher bei fachlicher Klärung.<\/li><\/ul>\n<p><strong>Inhalte des Tech Workshops:<\/strong><\/p>\n<ul><li>Analyse architektonischer Auswirkungen,<\/li><li>Prüfung betroffener Systeme, Schnittstellen und Datenmodelle,<\/li><li>Definition möglicher API-Änderungen,<\/li><li>Definition neuer Endpunkte,<\/li><li>Prüfung von Abhängigkeiten zu Drittdiensten,<\/li><li>Aufwandsschätzung,<\/li><li>Aufgabenverteilung,<\/li><li>Definition von Akzeptanzkriterien,<\/li><li>Festlegung von technischen Risiken,<\/li><li>Dokumentation der Entscheidung.<\/li><\/ul>\n<p><strong>Auditnachweis:<\/strong><\/p>\n<p>Das Ergebnis des Tech Workshops wird dokumentiert, z. B. als:<\/p>\n<ul><li>Issue-Kommentar,<\/li><li>internes Ticket,<\/li><li>kurzer Workshop-Vermerk,<\/li><li>technische Entscheidungsnotiz.<\/li><\/ul>\n<hr>\n<h2>5.4 Entwicklungsprozess<\/h2>\n<p>Jedes Feature wird auf einem separaten Feature Branch entwickelt.<\/p>\n<p><strong>Branch-Konvention:<\/strong><\/p>\n<pre class=\"code\"><code>feature/kurzbeschreibung<\/code><\/pre>\n<p><strong>Beispiele:<\/strong><\/p>\n<pre class=\"code\"><code>feature/user-export\nfeature/payment-dashboard\nfeature/api-rate-limit<\/code><\/pre>\n<p><strong>Commit-Konvention:<\/strong><\/p>\n<p>Commits sollen aussagekräftige Messages enthalten, vorzugsweise nach dem Muster der Conventional Commits.<\/p>\n<p><strong>Beispiele:<\/strong><\/p>\n<pre class=\"code\"><code>feat: add user export endpoint\nfix: correct validation for release note dates\nchore: update dependency configuration<\/code><\/pre>\n<hr>\n<h2>5.5 Code Review<\/h2>\n<p>Vor jedem Merge ist ein Code Review durch den jeweils anderen Entwickler erforderlich.<\/p>\n<p><strong>Review-Fokus:<\/strong><\/p>\n<ul><li>Codequalität,<\/li><li>Sicherheit,<\/li><li>Konsistenz,<\/li><li>Architektur,<\/li><li>Einhaltung der Akzeptanzkriterien,<\/li><li>potenzielle Seiteneffekte,<\/li><li>Lesbarkeit und Wartbarkeit,<\/li><li>Auswirkungen auf Schnittstellen oder Datenmodelle.<\/li><\/ul>\n<p><strong>Auditkontrolle:<\/strong><\/p>\n<p>Ein Merge darf nur erfolgen, wenn das Review dokumentiert und freigegeben wurde.<\/p>\n<hr>\n<h2>5.6 Staging-Verifikation und Release<\/h2>\n<p>Nach bestandenem Review erfolgt:<\/p>\n<ol><li>Merge in den Main- oder Development-Branch,<\/li><li>Deployment in die Staging-Umgebung,<\/li><li>finale Verifikation gegen die Akzeptanzkriterien,<\/li><li>Release bzw. Push in Produktion,<\/li><li>Dokumentation im Release-Prozess.<\/li><\/ol>\n<p>Die produktive Veröffentlichung darf erst erfolgen, wenn die Staging-Verifikation erfolgreich abgeschlossen wurde.<\/p>\n<hr>\n<h1>6. Release Notes<\/h1>\n<h2>6.1 Grundsatz<\/h2>\n<p>Release Notes werden mit jedem Merge bzw. Release erstellt und versioniert.<\/p>\n<p>Es wird semantische Versionierung verwendet:<\/p>\n<pre class=\"code\"><code>MAJOR.MINOR.PATCH<\/code><\/pre>\n<p><strong>Beispiel:<\/strong><\/p>\n<pre class=\"code\"><code>1.4.2<\/code><\/pre>\n<h2>6.2 Inhalt einer Release Note<\/h2>\n<p>Jede Release Note enthält mindestens:<\/p>\n<table><thead><tr><th>Abschnitt<\/th><th>Inhalt<\/th><\/tr><\/thead><tbody><tr><td>Versionsnummer<\/td><td>z. B. 1.4.2<\/td><\/tr><tr><td>Datum<\/td><td>Datum des Releases<\/td><\/tr><tr><td>Neue Features<\/td><td>kurze Beschreibung, ggf. Nutzen für User<\/td><\/tr><tr><td>Behobene Bugs<\/td><td>Liste der korrigierten Fehler<\/td><\/tr><tr><td>Breaking Changes<\/td><td>prominent hervorgehobene inkompatible Änderungen<\/td><\/tr><tr><td>Technische Änderungen<\/td><td>interne Infrastruktur-, API- oder Architekturänderungen<\/td><\/tr><\/tbody><\/table>\n<h2>6.3 Ablageorte<\/h2>\n<table><thead><tr><th>Ablageort<\/th><th>Zielgruppe<\/th><th>Inhalt<\/th><\/tr><\/thead><tbody><tr><td><code>CHANGELOG.md<\/code> im Wiki-Repository<\/td><td>technische Zielgruppe<\/td><td>vollständige Release-Historie<\/td><\/tr><tr><td><code>/changelog<\/code><\/td><td>intern / technisch<\/td><td>ausführliche Details je Release<\/td><\/tr><tr><td>Produktbereich<\/td><td>Endnutzer<\/td><td>kurze, nicht-technische Zusammenfassung, derzeit optional<\/td><\/tr><\/tbody><\/table>\n<h2>6.4 Verantwortlichkeit<\/h2>\n<p>Verantwortlich für die Release Notes ist der Entwickler, der den Release durchführt.<\/p>\n<hr>\n<h1>7. Bug-Management &amp; Bugfixing<\/h1>\n<h2>7.1 Eingang und Erstreaktion<\/h2>\n<p>Bug Reports werden zentral erfasst, z. B. über ein ClickUp Formular.<\/p>\n<p>Jeder Bug Report soll mindestens enthalten:<\/p>\n<table><thead><tr><th>Pflichtfeld<\/th><th>Beschreibung<\/th><\/tr><\/thead><tbody><tr><td>Titel<\/td><td>Kurze Fehlerbeschreibung<\/td><\/tr><tr><td>Beschreibung<\/td><td>Was ist passiert?<\/td><\/tr><tr><td>Erwartetes Verhalten<\/td><td>Was hätte passieren sollen?<\/td><\/tr><tr><td>Tatsächliches Verhalten<\/td><td>Was ist tatsächlich passiert?<\/td><\/tr><tr><td>Reproduktionsschritte<\/td><td>Schritte zur Nachstellung des Fehlers<\/td><\/tr><tr><td>Schweregrad<\/td><td>Kritisch, Hoch, Mittel, Niedrig<\/td><\/tr><tr><td>Screenshots / Logs<\/td><td>falls vorhanden<\/td><\/tr><tr><td>Melder<\/td><td>Person oder Quelle des Reports<\/td><\/tr><\/tbody><\/table>\n<h2>7.2 Initiale Antwortzeiten<\/h2>\n<table><thead><tr><th>Schweregrad<\/th><th>Beschreibung<\/th><th>Initiale Antwort<\/th><\/tr><\/thead><tbody><tr><td>Kritisch<\/td><td>Produktionsausfall, Datenverlust<\/td><td>innerhalb von 2 Stunden<\/td><\/tr><tr><td>Hoch<\/td><td>wesentliche Funktion defekt<\/td><td>innerhalb von 1 Werktag<\/td><\/tr><tr><td>Mittel<\/td><td>eingeschränkte Funktion, Workaround möglich<\/td><td>innerhalb von 2 Werktagen<\/td><\/tr><tr><td>Niedrig<\/td><td>kosmetisch oder selten auftretend<\/td><td>innerhalb von 5 Werktagen<\/td><\/tr><\/tbody><\/table>\n<hr>\n<h2>7.3 Triage und Priorisierung<\/h2>\n<p>Die Triage wird durch Mitarbeiter 1 durchgeführt.<\/p>\n<p><strong>Aufgaben der Triage-Rolle:<\/strong><\/p>\n<ul><li>Prüfung auf Vollständigkeit,<\/li><li>Prüfung auf Reproduzierbarkeit,<\/li><li>Rückfrage bei unvollständigen Reports,<\/li><li>Klassifizierung nach Schweregrad,<\/li><li>Zuweisung an zuständigen Entwickler,<\/li><li>Dokumentation der Entscheidung im Ticket.<\/li><\/ul>\n<p><strong>Schweregrade:<\/strong><\/p>\n<table><thead><tr><th>Schweregrad<\/th><th>Definition<\/th><\/tr><\/thead><tbody><tr><td>Kritisch<\/td><td>Produktionsausfall, Datenverlust, sicherheitsrelevanter Vorfall oder vollständige Nichtnutzbarkeit<\/td><\/tr><tr><td>Hoch<\/td><td>zentrale Funktion defekt, erhebliche Nutzerbeeinträchtigung<\/td><\/tr><tr><td>Mittel<\/td><td>eingeschränkte Funktion, Workaround vorhanden<\/td><\/tr><tr><td>Niedrig<\/td><td>kosmetischer Fehler, seltenes Randverhalten, geringe Auswirkungen<\/td><\/tr><\/tbody><\/table>\n<hr>\n<h2>7.4 Ziellösungszeiten / SLOs<\/h2>\n<table><thead><tr><th>Priorität<\/th><th>Initiale Antwort<\/th><th>Angestrebte Lösung<\/th><\/tr><\/thead><tbody><tr><td>Kritisch<\/td><td>2 Stunden<\/td><td>24 Stunden<\/td><\/tr><tr><td>Hoch<\/td><td>1 Werktag<\/td><td>3 Werktage<\/td><\/tr><tr><td>Mittel<\/td><td>2 Werktage<\/td><td>2 Wochen<\/td><\/tr><tr><td>Niedrig<\/td><td>5 Werktage<\/td><td>nächster Release<\/td><\/tr><\/tbody><\/table>\n<p>Die SLOs sind Zielwerte. Abweichungen müssen im Ticket nachvollziehbar begründet werden.<\/p>\n<hr>\n<h2>7.5 Fixing und Release<\/h2>\n<p>Die Umsetzung erfolgt durch Mitarbeiter 2 bzw. den zuständigen Entwickler.<\/p>\n<p><strong>Branch-Konvention:<\/strong><\/p>\n<pre class=\"code\"><code>fix/kurzbeschreibung<\/code><\/pre>\n<p><strong>Beispiele:<\/strong><\/p>\n<pre class=\"code\"><code>fix/login-timeout\nfix/export-validation\nfix/payment-status-mapping<\/code><\/pre>\n<p><strong>Ablauf:<\/strong><\/p>\n<ol><li>Bugfix Branch erstellen,<\/li><li>Fehler reproduzieren,<\/li><li>Ursache analysieren,<\/li><li>Fix implementieren,<\/li><li>Tests bzw. Verifikation durchführen,<\/li><li>Code Review durch Mitarbeiter 1,<\/li><li>Merge analog Feature-Prozess,<\/li><li>Deployment in Staging,<\/li><li>finale Verifikation,<\/li><li>Release in Produktion,<\/li><li>Dokumentation in Release Notes / CHANGELOG,<\/li><li>Information an Melder,<\/li><li>Ticket schliessen.<\/li><\/ol>\n<hr>\n<h1>8. Kontrollpunkte und Auditnachweise<\/h1>\n<table><thead><tr><th>Kontrollpunkt<\/th><th>Beschreibung<\/th><th>Nachweis<\/th><\/tr><\/thead><tbody><tr><td>Zentrale Erfassung<\/td><td>Alle Requests und Bugs werden in definierten Systemen erfasst<\/td><td>Issue, Ticket, Formular<\/td><\/tr><tr><td>Priorisierung<\/td><td>Bewertung anhand definierter Kriterien<\/td><td>Prioritätsfeld, Score, Kommentar<\/td><\/tr><tr><td>Tech Workshop<\/td><td>technische Analyse vor Implementierung<\/td><td>Workshop-Kommentar, Ticketnotiz<\/td><\/tr><tr><td>Akzeptanzkriterien<\/td><td>fachliche und technische Erfolgskriterien<\/td><td>Ticketbeschreibung<\/td><\/tr><tr><td>Branching<\/td><td>getrennte Branches je Feature oder Bugfix<\/td><td>Git Branch<\/td><\/tr><tr><td>Commit-Konvention<\/td><td>nachvollziehbare Änderungshistorie<\/td><td>Git Commit History<\/td><\/tr><tr><td>Code Review<\/td><td>Vier-Augen-Prinzip vor Merge<\/td><td>Pull Request Review<\/td><\/tr><tr><td>Staging-Verifikation<\/td><td>Prüfung vor Produktion<\/td><td>Testkommentar, Checkliste<\/td><\/tr><tr><td>Release Notes<\/td><td>versionierte Dokumentation jeder Änderung<\/td><td>CHANGELOG.md, /changelog<\/td><\/tr><tr><td>Bug-Triage<\/td><td>Klassifizierung und Zuweisung<\/td><td>Bug Ticket<\/td><\/tr><tr><td>SLO-Überwachung<\/td><td>Prüfung von Antwort- und Lösungszeiten<\/td><td>Ticket-Zeitstempel<\/td><\/tr><tr><td>Ticketabschluss<\/td><td>Abschluss mit nachvollziehbarem Ergebnis<\/td><td>Status, Kommentar, Melderinfo<\/td><\/tr><\/tbody><\/table>\n<hr>\n<h1>9. Definition of Done<\/h1>\n<p>Ein Feature oder Bugfix gilt erst als abgeschlossen, wenn folgende Kriterien erfüllt sind:<\/p>\n<ul><li>Umsetzung auf separatem Branch erfolgt,<\/li><li>aussagekräftige Commits vorhanden,<\/li><li>Code Review durch zweite Person durchgeführt,<\/li><li>Review-Kommentare wurden bearbeitet,<\/li><li>Merge in Main/Development erfolgt,<\/li><li>Staging-Verifikation erfolgreich abgeschlossen,<\/li><li>Akzeptanzkriterien erfüllt,<\/li><li>Release Notes aktualisiert,<\/li><li>CHANGELOG.md bzw. /changelog aktualisiert,<\/li><li>bei Bugs: Melder informiert,<\/li><li>Ticket geschlossen oder auf erledigt gesetzt.<\/li><\/ul>\n<hr>\n<h1>10. Risiken und Kontrollen<\/h1>\n<table><thead><tr><th>Risiko<\/th><th>Auswirkung<\/th><th>Kontrolle<\/th><\/tr><\/thead><tbody><tr><td>Unklare Anforderungen<\/td><td>Fehlentwicklung, Rework<\/td><td>Akzeptanzkriterien und Tech Workshop<\/td><\/tr><tr><td>Fehlende Priorisierung<\/td><td>falsche Ressourcenallokation<\/td><td>Scoring oder MoSCoW<\/td><\/tr><tr><td>Direkter Merge ohne Review<\/td><td>Qualitäts- und Sicherheitsrisiken<\/td><td>verpflichtendes Vier-Augen-Prinzip<\/td><\/tr><tr><td>Unvollständige Release Notes<\/td><td>fehlende Nachvollziehbarkeit<\/td><td>Release-Checkliste<\/td><\/tr><tr><td>Bugs ohne Triage<\/td><td>falsche Dringlichkeit<\/td><td>definierte Triage-Rolle<\/td><\/tr><tr><td>SLO-Verletzungen ohne Begründung<\/td><td>fehlende Steuerbarkeit<\/td><td>Ticketkommentar bei Abweichung<\/td><\/tr><tr><td>Produktivfehler nach Release<\/td><td>Nutzerbeeinträchtigung<\/td><td>Staging-Verifikation vor Produktion<\/td><\/tr><\/tbody><\/table>\n<hr>\n<h1>11. Empfohlene Ticket-Templates<\/h1>\n<h2>11.1 Feature Request Template<\/h2>\n<pre class=\"code\"><code>## Feature Request\n\n### Titel\nKurzbeschreibung des Features\n\n### Beschreibung\nWas soll umgesetzt werden?\n\n### Nutzen\nWelchen Mehrwert liefert das Feature?\n\n### Quelle\nKunde / intern / Support / Management\n\n### Priorisierung\n- Kundenwert: 1 / 2 / 3\n- Strategische Relevanz: 1 / 2 / 3\n- Implementierungsaufwand: 1 / 2 / 3\n\n### Akzeptanzkriterien\n- [ ] Kriterium 1\n- [ ] Kriterium 2\n- [ ] Kriterium 3\n\n### Technische Hinweise\nBetroffene Systeme, APIs, Datenmodelle oder Schnittstellen\n\n### Entscheidung Tech Workshop\nKurzprotokoll / Ergebnis<\/code><\/pre>\n<hr>\n<h2>11.2 Bug Report Template<\/h2>\n<pre class=\"code\"><code>## Bug Report\n\n### Titel\nKurzbeschreibung des Fehlers\n\n### Beschreibung\nWas ist passiert?\n\n### Erwartetes Verhalten\nWas hätte passieren sollen?\n\n### Tatsächliches Verhalten\nWas ist tatsächlich passiert?\n\n### Reproduktionsschritte\n1. Schritt 1\n2. Schritt 2\n3. Schritt 3\n\n### Schweregrad\nKritisch / Hoch / Mittel / Niedrig\n\n### Auswirkungen\nWelche Nutzer, Systeme oder Daten sind betroffen?\n\n### Workaround\nJa / Nein / Beschreibung\n\n### Anhänge\nScreenshots, Logs, Videos\n\n### Triage-Ergebnis\n- Vollständig: Ja / Nein\n- Reproduzierbar: Ja / Nein\n- Zugewiesen an:\n- Zieltermin:<\/code><\/pre>\n<hr>\n<h2>11.3 Release Note Template<\/h2>\n<pre class=\"code\"><code># Release Notes\n\n## Version\nx.y.z\n\n## Datum\nTT.MM.JJJJ\n\n## Neue Features\n- Beschreibung des Features und Nutzen\n\n## Behobene Bugs\n- Beschreibung des behobenen Fehlers\n\n## Breaking Changes\n- Keine / Beschreibung der Änderung\n\n## Technische Änderungen\n- API, Infrastruktur, Datenmodell oder Abhängigkeiten\n\n## Verantwortlich\nName des Release-Verantwortlichen\n\n## Referenzen\n- Issue / Ticket / Pull Request<\/code><\/pre>\n<hr>\n<h1>12. Freigabe und Review des Prozesses<\/h1>\n<p>Dieser Prozess sollte regelmässig überprüft werden, mindestens jedoch:<\/p>\n<ul><li>bei wesentlichen Änderungen am Entwicklungsprozess,<\/li><li>bei Einführung neuer Tools,<\/li><li>nach grösseren Incidents,<\/li><li>vor externen Audits,<\/li><li>mindestens einmal jährlich.<\/li><\/ul>\n<table><thead><tr><th>Freigabefeld<\/th><th>Eintrag<\/th><\/tr><\/thead><tbody><tr><td>Prozessverantwortlicher<\/td><td><\/td><\/tr><tr><td>Fachliche Freigabe<\/td><td><\/td><\/tr><tr><td>Technische Freigabe<\/td><td><\/td><\/tr><tr><td>Datum der Freigabe<\/td><td><\/td><\/tr><tr><td>Nächste Überprüfung<\/td><td><\/td><\/tr><\/tbody><\/table>\n<hr>\n<h1>13. Kurzfazit<\/h1>\n<p>Der beschriebene Prozess stellt sicher, dass Feature-Entwicklung, Bugfixing und Releases kontrolliert, nachvollziehbar und auditfähig durchgeführt werden. Durch zentrale Erfassung, klare Rollen, dokumentierte Priorisierung, Tech Workshops, Branching-Konventionen, Code Reviews, Staging-Verifikation und versionierte Release Notes entsteht ein robuster Entwicklungsprozess mit belastbaren Nachweisen für interne und externe Prüfungen.<\/p>", "text": "# auditkonformer prozess: feature-entwicklung, releases und bug-management **dokumenttyp:** prozessbeschreibung / sop **geltungsbereich:** softwareentwicklung, release management, bugfixing **version:** 1.0 **status:** entwurf zur internen freigabe **owner:** entwicklung / produktverantwortung **letzte aktualisierung:** 28.05.2026 --- ## 1. zweck des dokuments dieses dokument beschreibt einen auditkonformen prozess für: - die strukturierte aufnahme, bewertung und umsetzung von feature-requests, - die durchführung technischer workshops vor implementierungsbeginn, - die kontrollierte entwicklung über branches, reviews und staging-verifikation, - die versionierte erstellung von release notes, - die erfassung, priorisierung, bearbeitung und dokumentation von bugs, - die nachvollziehbarkeit von entscheidungen, änderungen, verantwortlichkeiten und freigaben. ziel ist es, einen nachvollziehbaren, wiederholbaren und prüfbaren entwicklungs- und release-prozess sicherzustellen. --- ## 2. prozessübersicht der gesamtprozess besteht aus zwei hauptsträngen: 1. **feature-entwicklung & releases** 2. **bug-management & bugfixing** beide stränge folgen gemeinsamen prinzipien: - zentrale erfassung aller anforderungen und fehler, - dokumentierte bewertung und priorisierung, - nachvollziehbare technische entscheidungen, - vier-augen-prinzip vor produktivem release, - dokumentierte release notes, - klare verantwortlichkeiten, - prüfbare nachweise in tickets, branches, pull requests und changelogs. --- ## 3. prozessbild ```mermaid flowchart td a[feature request oder bug report geht ein] --> b{art des eingangs} b -->|feature request| f1[zentrale erfassung<br/>z. b. github issues, linear, notion] f1 --> f2[priorisierung nach kundenwert,<br/>strategischer relevanz und aufwand] f2 --> f3[feature mit hoher priorität<br/>für tech workshop vormerken] f3 --> f4[tech workshop mit beiden entwicklern] f4 --> f5[architektur-, api-, datenmodell-<br/>und schnittstellenanalyse] f5 --> f6[aufwandsschätzung,<br/>aufgabenverteilung und akzeptanzkriterien] f6 --> f7[dokumentation im issue<br/>oder internen ticket] f7 --> f8[entwicklung auf feature branch<br/>feature/kurzbeschreibung] f8 --> f9[commits mit aussagekräftigen messages<br/>z. b. feat:, fix:, chore:] f9 --> f10[code review durch zweiten entwickler] f10 --> f11{review bestanden?} f11 -->|nein| f12[überarbeitung durch entwickler] f12 --> f10 f11 -->|ja| f13[merge in main/development branch] f13 --> f14[deployment in staging] f14 --> f15[finale verifikation gegen akzeptanzkriterien] f15 --> f16{verifikation bestanden?} f16 -->|nein| f12 f16 -->|ja| f17[release / push in produktion] f17 --> f18[release notes erstellen und versionieren] f18 --> f19[changelog.md und /changelog aktualisieren] b -->|bug report| g1[zentrale erfassung<br/>z. b. clickup formular] g1 --> g2[initiale antwort gemäß schweregrad] g2 --> g3[triage durch mitarbeiter 1] g3 --> g4[prüfung auf vollständigkeit<br/>und reproduzierbarkeit] g4 --> g5[klassifizierung:<br/>kritisch / hoch / mittel / niedrig] g5 --> g6[zuweisung an zuständigen entwickler] g6 --> g7[fix auf bugfix branch<br/>fix/kurzbeschreibung] g7 --> g8[code review durch mitarbeiter 1] g8 --> g9{review bestanden?} g9 -->|nein| g10[nachbesserung durch entwickler] g10 --> g8 g9 -->|ja| g11[merge analog feature-prozess] g11 --> g12[staging-verifikation] g12 --> g13{fix verifiziert?} g13 -->|nein| g10 g13 -->|ja| g14[release in produktion] g14 --> g15[dokumentation in release notes / changelog] g15 --> g16[melder informieren und ticket schließen] ``` --- ## 4. rollen und verantwortlichkeiten | rolle | verantwortung | |---|---| | entwickler 1 | teilnahme am tech workshop, entwicklung, review, ggf. triage | | entwickler 2 | teilnahme am tech workshop, entwicklung, review, release-durchführung | | mitarbeiter 1 / triage-rolle | prüfung eingehender bug reports, klassifizierung, reproduzierbarkeit, zuweisung, review von bugfixes | | mitarbeiter 2 / entwicklungsrolle | umsetzung von bugfixes auf separatem branch, dokumentation technischer änderungen | | release-verantwortlicher | durchführung des releases, pflege der release notes, aktualisierung von changelog.md und /changelog | | produkt-/business-verantwortlicher | bewertung von kundenwert und strategischer relevanz bei feature requests | --- # 5. feature-entwicklung & releases ## 5.1 feature-request-prozess eingehende feature-requests werden zentral gesammelt. mögliche systeme sind: - github issues, - linear, - notion, - ein internes produkt-backlog. jeder feature request muss mindestens folgende informationen enthalten: | pflichtfeld | beschreibung | |---|---| | titel | kurze, eindeutige beschreibung des gewünschten features | | beschreibung | fachliche beschreibung des bedarfs | | nutzen | erwarteter mehrwert für kunden, nutzer oder internes team | | quelle | kunde, interner stakeholder, entwickler, support oder management | | prioritätsbewertung | bewertung nach definierten kriterien | | status | neu, in bewertung, geplant, in umsetzung, umgesetzt, abgelehnt | ## 5.2 priorisierung die priorisierung erfolgt anhand folgender kriterien: | kriterium | beschreibung | bewertung | |---|---|---| | kundenwert | relevanz für nutzer oder kunden | 1 = gering, 2 = mittel, 3 = hoch | | strategische relevanz | beitrag zur produktstrategie | 1 = gering, 2 = mittel, 3 = hoch | | implementierungsaufwand | technischer und organisatorischer aufwand | 1 = gering, 2 = mittel, 3 = hoch | alternativ kann eine moscow-kategorisierung verwendet werden: | kategorie | bedeutung | |---|---| | must have | zwingend erforderlich | | should have | wichtig, aber nicht kritisch | | could have | optional, wenn kapazität vorhanden | | won't have | bewusst zurückgestellt | features mit höchster priorität werden für den nächsten tech workshop vorgemerkt. --- ## 5.3 tech workshop vor implementierungsbeginn vor der implementierung priorisierter features findet ein tech workshop statt. **teilnehmer:** - beide entwickler, - optional produkt-/business-verantwortlicher bei fachlicher klärung. **inhalte des tech workshops:** - analyse architektonischer auswirkungen, - prüfung betroffener systeme, schnittstellen und datenmodelle, - definition möglicher api-änderungen, - definition neuer endpunkte, - prüfung von abhängigkeiten zu drittdiensten, - aufwandsschätzung, - aufgabenverteilung, - definition von akzeptanzkriterien, - festlegung von technischen risiken, - dokumentation der entscheidung. **auditnachweis:** das ergebnis des tech workshops wird dokumentiert, z. b. als: - issue-kommentar, - internes ticket, - kurzer workshop-vermerk, - technische entscheidungsnotiz. --- ## 5.4 entwicklungsprozess jedes feature wird auf einem separaten feature branch entwickelt. **branch-konvention:** ```text feature/kurzbeschreibung ``` **beispiele:** ```text feature/user-export feature/payment-dashboard feature/api-rate-limit ``` **commit-konvention:** commits sollen aussagekräftige messages enthalten, vorzugsweise nach dem muster der conventional commits. **beispiele:** ```text feat: add user export endpoint fix: correct validation for release note dates chore: update dependency configuration ``` --- ## 5.5 code review vor jedem merge ist ein code review durch den jeweils anderen entwickler erforderlich. **review-fokus:** - codequalität, - sicherheit, - konsistenz, - architektur, - einhaltung der akzeptanzkriterien, - potenzielle seiteneffekte, - lesbarkeit und wartbarkeit, - auswirkungen auf schnittstellen oder datenmodelle. **auditkontrolle:** ein merge darf nur erfolgen, wenn das review dokumentiert und freigegeben wurde. --- ## 5.6 staging-verifikation und release nach bestandenem review erfolgt: 1. merge in den main- oder development-branch, 2. deployment in die staging-umgebung, 3. finale verifikation gegen die akzeptanzkriterien, 4. release bzw. push in produktion, 5. dokumentation im release-prozess. die produktive veröffentlichung darf erst erfolgen, wenn die staging-verifikation erfolgreich abgeschlossen wurde. --- # 6. release notes ## 6.1 grundsatz release notes werden mit jedem merge bzw. release erstellt und versioniert. es wird semantische versionierung verwendet: ```text major.minor.patch ``` **beispiel:** ```text 1.4.2 ``` ## 6.2 inhalt einer release note jede release note enthält mindestens: | abschnitt | inhalt | |---|---| | versionsnummer | z. b. 1.4.2 | | datum | datum des releases | | neue features | kurze beschreibung, ggf. nutzen für user | | behobene bugs | liste der korrigierten fehler | | breaking changes | prominent hervorgehobene inkompatible änderungen | | technische änderungen | interne infrastruktur-, api- oder architekturänderungen | ## 6.3 ablageorte | ablageort | zielgruppe | inhalt | |---|---|---| | `changelog.md` im wiki-repository | technische zielgruppe | vollständige release-historie | | `/changelog` | intern / technisch | ausführliche details je release | | produktbereich | endnutzer | kurze, nicht-technische zusammenfassung, derzeit optional | ## 6.4 verantwortlichkeit verantwortlich für die release notes ist der entwickler, der den release durchführt. --- # 7. bug-management & bugfixing ## 7.1 eingang und erstreaktion bug reports werden zentral erfasst, z. b. über ein clickup formular. jeder bug report soll mindestens enthalten: | pflichtfeld | beschreibung | |---|---| | titel | kurze fehlerbeschreibung | | beschreibung | was ist passiert? | | erwartetes verhalten | was hätte passieren sollen? | | tatsächliches verhalten | was ist tatsächlich passiert? | | reproduktionsschritte | schritte zur nachstellung des fehlers | | schweregrad | kritisch, hoch, mittel, niedrig | | screenshots / logs | falls vorhanden | | melder | person oder quelle des reports | ## 7.2 initiale antwortzeiten | schweregrad | beschreibung | initiale antwort | |---|---|---| | kritisch | produktionsausfall, datenverlust | innerhalb von 2 stunden | | hoch | wesentliche funktion defekt | innerhalb von 1 werktag | | mittel | eingeschränkte funktion, workaround möglich | innerhalb von 2 werktagen | | niedrig | kosmetisch oder selten auftretend | innerhalb von 5 werktagen | --- ## 7.3 triage und priorisierung die triage wird durch mitarbeiter 1 durchgeführt. **aufgaben der triage-rolle:** - prüfung auf vollständigkeit, - prüfung auf reproduzierbarkeit, - rückfrage bei unvollständigen reports, - klassifizierung nach schweregrad, - zuweisung an zuständigen entwickler, - dokumentation der entscheidung im ticket. **schweregrade:** | schweregrad | definition | |---|---| | kritisch | produktionsausfall, datenverlust, sicherheitsrelevanter vorfall oder vollständige nichtnutzbarkeit | | hoch | zentrale funktion defekt, erhebliche nutzerbeeinträchtigung | | mittel | eingeschränkte funktion, workaround vorhanden | | niedrig | kosmetischer fehler, seltenes randverhalten, geringe auswirkungen | --- ## 7.4 ziellösungszeiten / slos | priorität | initiale antwort | angestrebte lösung | |---|---:|---:| | kritisch | 2 stunden | 24 stunden | | hoch | 1 werktag | 3 werktage | | mittel | 2 werktage | 2 wochen | | niedrig | 5 werktage | nächster release | die slos sind zielwerte. abweichungen müssen im ticket nachvollziehbar begründet werden. --- ## 7.5 fixing und release die umsetzung erfolgt durch mitarbeiter 2 bzw. den zuständigen entwickler. **branch-konvention:** ```text fix/kurzbeschreibung ``` **beispiele:** ```text fix/login-timeout fix/export-validation fix/payment-status-mapping ``` **ablauf:** 1. bugfix branch erstellen, 2. fehler reproduzieren, 3. ursache analysieren, 4. fix implementieren, 5. tests bzw. verifikation durchführen, 6. code review durch mitarbeiter 1, 7. merge analog feature-prozess, 8. deployment in staging, 9. finale verifikation, 10. release in produktion, 11. dokumentation in release notes / changelog, 12. information an melder, 13. ticket schliessen. --- # 8. kontrollpunkte und auditnachweise | kontrollpunkt | beschreibung | nachweis | |---|---|---| | zentrale erfassung | alle requests und bugs werden in definierten systemen erfasst | issue, ticket, formular | | priorisierung | bewertung anhand definierter kriterien | prioritätsfeld, score, kommentar | | tech workshop | technische analyse vor implementierung | workshop-kommentar, ticketnotiz | | akzeptanzkriterien | fachliche und technische erfolgskriterien | ticketbeschreibung | | branching | getrennte branches je feature oder bugfix | git branch | | commit-konvention | nachvollziehbare änderungshistorie | git commit history | | code review | vier-augen-prinzip vor merge | pull request review | | staging-verifikation | prüfung vor produktion | testkommentar, checkliste | | release notes | versionierte dokumentation jeder änderung | changelog.md, /changelog | | bug-triage | klassifizierung und zuweisung | bug ticket | | slo-überwachung | prüfung von antwort- und lösungszeiten | ticket-zeitstempel | | ticketabschluss | abschluss mit nachvollziehbarem ergebnis | status, kommentar, melderinfo | --- # 9. definition of done ein feature oder bugfix gilt erst als abgeschlossen, wenn folgende kriterien erfüllt sind: - umsetzung auf separatem branch erfolgt, - aussagekräftige commits vorhanden, - code review durch zweite person durchgeführt, - review-kommentare wurden bearbeitet, - merge in main/development erfolgt, - staging-verifikation erfolgreich abgeschlossen, - akzeptanzkriterien erfüllt, - release notes aktualisiert, - changelog.md bzw. /changelog aktualisiert, - bei bugs: melder informiert, - ticket geschlossen oder auf erledigt gesetzt. --- # 10. risiken und kontrollen | risiko | auswirkung | kontrolle | |---|---|---| | unklare anforderungen | fehlentwicklung, rework | akzeptanzkriterien und tech workshop | | fehlende priorisierung | falsche ressourcenallokation | scoring oder moscow | | direkter merge ohne review | qualitäts- und sicherheitsrisiken | verpflichtendes vier-augen-prinzip | | unvollständige release notes | fehlende nachvollziehbarkeit | release-checkliste | | bugs ohne triage | falsche dringlichkeit | definierte triage-rolle | | slo-verletzungen ohne begründung | fehlende steuerbarkeit | ticketkommentar bei abweichung | | produktivfehler nach release | nutzerbeeinträchtigung | staging-verifikation vor produktion | --- # 11. empfohlene ticket-templates ## 11.1 feature request template ```markdown ## feature request ### titel kurzbeschreibung des features ### beschreibung was soll umgesetzt werden? ### nutzen welchen mehrwert liefert das feature? ### quelle kunde / intern / support / management ### priorisierung - kundenwert: 1 / 2 / 3 - strategische relevanz: 1 / 2 / 3 - implementierungsaufwand: 1 / 2 / 3 ### akzeptanzkriterien - [ ] kriterium 1 - [ ] kriterium 2 - [ ] kriterium 3 ### technische hinweise betroffene systeme, apis, datenmodelle oder schnittstellen ### entscheidung tech workshop kurzprotokoll / ergebnis ``` --- ## 11.2 bug report template ```markdown ## bug report ### titel kurzbeschreibung des fehlers ### beschreibung was ist passiert? ### erwartetes verhalten was hätte passieren sollen? ### tatsächliches verhalten was ist tatsächlich passiert? ### reproduktionsschritte 1. schritt 1 2. schritt 2 3. schritt 3 ### schweregrad kritisch / hoch / mittel / niedrig ### auswirkungen welche nutzer, systeme oder daten sind betroffen? ### workaround ja / nein / beschreibung ### anhänge screenshots, logs, videos ### triage-ergebnis - vollständig: ja / nein - reproduzierbar: ja / nein - zugewiesen an: - zieltermin: ``` --- ## 11.3 release note template ```markdown # release notes ## version x.y.z ## datum tt.mm.jjjj ## neue features - beschreibung des features und nutzen ## behobene bugs - beschreibung des behobenen fehlers ## breaking changes - keine / beschreibung der änderung ## technische änderungen - api, infrastruktur, datenmodell oder abhängigkeiten ## verantwortlich name des release-verantwortlichen ## referenzen - issue / ticket / pull request ``` --- # 12. freigabe und review des prozesses dieser prozess sollte regelmässig überprüft werden, mindestens jedoch: - bei wesentlichen änderungen am entwicklungsprozess, - bei einführung neuer tools, - nach grösseren incidents, - vor externen audits, - mindestens einmal jährlich. | freigabefeld | eintrag | |---|---| | prozessverantwortlicher | | | fachliche freigabe | | | technische freigabe | | | datum der freigabe | | | nächste überprüfung | | --- # 13. kurzfazit der beschriebene prozess stellt sicher, dass feature-entwicklung, bugfixing und releases kontrolliert, nachvollziehbar und auditfähig durchgeführt werden. durch zentrale erfassung, klare rollen, dokumentierte priorisierung, tech workshops, branching-konventionen, code reviews, staging-verifikation und versionierte release notes entsteht ein robuster entwicklungsprozess mit belastbaren nachweisen für interne und externe prüfungen. ", "nextReview": "", "overdueReview": false, "zuPruefen": []}, {"id": "05_betrieb/neutralisierung-detail.md", "path": "05_betrieb/neutralisierung-detail.md", "chapter": "05_betrieb", "title": "neutralisierung-detail.md", "filename": "neutralisierung-detail.md", "meta": {}, "html": "<p># Neutralisierung<\/p>\n<p><strong>Stand:<\/strong> 2026-04-16<\/p>\n<hr>\n<h2>1. Grundidee<\/h2>\n<p>Neutralisierung passiert dort, wo <strong>Content entsteht oder ins System einfliesst<\/strong> — nicht als nachgelagerter Filter vor dem Modell-Call. Wenn Content einmal neutralisiert ist (z. B. im RAG), bleibt er neutralisiert. Kein doppeltes Verarbeiten.<\/p>\n<hr>\n<h2>2. Wer fordert Neutralisierung?<\/h2>\n<p>Drei Quellen, von breit nach spezifisch:<\/p>\n<table><thead><tr><th>Quelle<\/th><th>Flag im Code<\/th><th>Bedeutung<\/th><\/tr><\/thead><tbody><tr><td><strong>Feature-Instanz<\/strong><\/td><td><code>DataNeutraliserConfig.enabled<\/code> (hat <code>featureInstanceId<\/code> + <code>mandateId<\/code>)<\/td><td>Alle Daten in dieser Feature-Instanz werden neutralisiert. Betrifft jeden Content-Einstieg innerhalb dieser Instanz.<\/td><\/tr><tr><td><strong>Chat-Workflow / Session<\/strong><\/td><td><code>ServiceCenterContext.requireNeutralization<\/code> (gesetzt z. B. vom AI-Workspace oder Automation)<\/td><td>Dieser Workflow/Turn: jeder Content, der hier verarbeitet wird, wird neutralisiert.<\/td><\/tr><tr><td><strong>Dokument oder Quelle<\/strong><\/td><td><code>FileItem.neutralize<\/code>, <code>FileFolder.neutralize<\/code>, <code>DataSource.neutralize<\/code>, <code>FeatureDataSource.neutralize<\/code>, <code>FeatureDataSource.neutralizeFields<\/code><\/td><td>Dieses konkrete Objekt: Content daraus wird neutralisiert, egal ob die Feature-Instanz oder der Workflow es sonst fordern würden. <code>FileFolder.neutralize<\/code> propagiert auf alle enthaltenen Dateien. <code>neutralizeFields<\/code> ermöglicht Feld-Level-Maskierung bei DB-Queries.<\/td><\/tr><\/tbody><\/table>\n<p><strong>Auswertung:<\/strong> Irgendeine Quelle sagt <code>True<\/code> → neutralisieren. Keine Quelle kann eine andere aufheben. Es gibt kein <code>False<\/code>-Override, das ein <code>True<\/code> von woanders aushebelt.<\/p>\n<hr>\n<h2>3. Wo passiert die Neutralisierung?<\/h2>\n<p>Am <strong>Punkt der Content-Einspeisung<\/strong> — dort wo Rohdaten zu verarbeitbarem Content werden:<\/p>\n<table><thead><tr><th>Content-Einstieg<\/th><th>Was passiert<\/th><th>Wer prüft das Flag<\/th><\/tr><\/thead><tbody><tr><td><strong>Datei-Indexierung<\/strong> (RAG)<\/td><td>Text-Chunks werden über <code>processText<\/code> neutralisiert, bevor sie ins Embedding gehen. Medien: nur internes Modell oder nicht indexieren. Ergebnis: RAG enthält nur neutralisierten Content.<\/td><td><code>mainServiceKnowledge.indexFile<\/code> liest <code>FileItem.neutralize<\/code><\/td><\/tr><tr><td><strong>Content-Extraktion<\/strong> (Dokumente für KI-Verarbeitung)<\/td><td>Extrahierter Text/Tabellen werden neutralisiert. PDF, DOCX, XLSX, PPTX über <code>processFile<\/code> (Extract → neutralisieren → zurückschreiben).<\/td><td>Caller kennt die Quelle und deren Flag<\/td><\/tr><tr><td><strong>User-Prompt<\/strong> (Chat-Eingabe)<\/td><td>Prompt-Text wird durch <code>processText<\/code> neutralisiert, wenn Feature-Instanz oder Workflow es fordern.<\/td><td><code>mainServiceAi<\/code> prüft Context-Flag / Config<\/td><\/tr><tr><td><strong>DataSource-Download<\/strong><\/td><td>Flag wird auf erstellte <code>FileItem<\/code>s vererbt → bei Extraktion/Indexierung greift das File-Flag automatisch.<\/td><td><code>mainServiceAgent._resolveDataSource<\/code> / <code>_downloadFromDataSource<\/code><\/td><\/tr><tr><td><strong>FeatureDataSource-Abfrage (Tabelle)<\/strong><\/td><td>Wenn eine <code>FeatureDataSource.neutralize=True<\/code> hat → Content aus diesem Sub-Agent-Call wird neutralisiert.<\/td><td><code>mainServiceAgent._queryFeatureInstance<\/code> setzt <code>requireNeutralization=True<\/code><\/td><\/tr><tr><td><strong>FeatureDataSource-Abfrage (Feld/Typ, seit 2026-06)<\/strong><\/td><td>Typ- und vererbungsbewusst: <strong>Strings<\/strong> werden substring-neutralisiert sobald effektiv (explizit ODER geerbt, Feldname als Typ-Hint); <strong>Binary<\/strong> wird gedroppt; <strong>andere Skalare<\/strong> (number/date/bool) nur bei <strong>explizitem<\/strong> Feld-Flag als Ganzwert-Platzhalter <code>[NEUT.&lt;field&gt;.&lt;hash&gt;]<\/code>. Identifikatoren/System-Spalten ausgenommen, Engine-Ausfall = <code>[REDACTED]<\/code>. RAG-Bootstrap nutzt dieselbe Policy (Query- und Index-Pfad konsistent).<\/td><td><code>featureDataProvider.finalizeRowsAsync<\/code> / <code>_neutralizeAndSerializeRows<\/code>; Policy aus <code>coreTools/_featureSubAgentTools<\/code> via <code>resolveEffectiveForFds<\/code><\/td><\/tr><tr><td><strong>De-Neutralisierung für Download (seit 2026-06)<\/strong><\/td><td>Read-only Agent-Tool <code>revealDocument<\/code> löst Platzhalter <strong>nur<\/strong> über das lokale Mapping (<code>resolveText<\/code>, kein externes LLM) auf und liefert Klartext als transienten Einmal-Download (SSE <code>revealDownload<\/code>) — kein Save/Index/Historie.<\/td><td><code>coreTools/_mediaTools._revealDocument<\/code><\/td><\/tr><tr><td><strong>Ordner-Neutralisierung<\/strong><\/td><td><code>FileFolder.neutralize=True<\/code> propagiert auf alle enthaltenen Dateien (rekursiv). Neue/verschobene Dateien erben das Flag. Index-Purge + Re-Index wie bei einzelnen Dateien.<\/td><td><code>routeDataFiles.updateFolderNeutralize<\/code><\/td><\/tr><tr><td><strong>Workflow-Aktion <code>neutralizeData<\/code><\/strong><\/td><td>Expliziter Neutralisierungs-Schritt auf bereits extrahierten ContentParts.<\/td><td>Workflow-Config + <code>NeutralizationConfig.enabled<\/code><\/td><\/tr><\/tbody><\/table>\n<p><strong>Was NICHT nochmal neutralisiert werden muss:<\/strong><\/p>\n<ul><li>RAG-Chunks, die bereits neutralisiert indexiert sind — die sind schon sauber.<\/li><li>Web-Suchergebnisse — enthalten keine Mandantendaten, brauchen keine Neutralisierung.<\/li><\/ul>\n<p><strong>Flag-Änderung:<\/strong> Ändert sich <code>FileItem.neutralize<\/code> (Toggle) → Index löschen → Re-Indexierung triggern → neuer Index ist im richtigen Zustand.<\/p>\n<hr>\n<h2>4. Engine: <code>NeutralizationService<\/code><\/h2>\n<p>Eine Engine, drei Einstiege, aufgerufen an den Content-Einstiegspunkten aus Abschnitt 3.<\/p>\n<table><thead><tr><th>API<\/th><th>Eingabe<\/th><th>Status<\/th><\/tr><\/thead><tbody><tr><td><code>processText(text)<\/code><\/td><td>Rohtext (Prompt, Message, Text-ContentPart, Text-Chunk)<\/td><td><strong>Ist<\/strong><\/td><\/tr><tr><td><code>processFile(fileId)<\/code><\/td><td>Datei aus DB — wird nach MIME geroutet<\/td><td><strong>Ist<\/strong><\/td><\/tr><tr><td><code>processBinaryBytes<\/code> / <code>Async<\/code><\/td><td>Bytes + Dateiname + MIME<\/td><td><strong>Ist<\/strong><\/td><\/tr><tr><td><strong><code>processImage(imageBytes, fileName)<\/code><\/strong> / <code>processImageAsync<\/code><\/td><td>Bild-Datei oder Bild-ContentPart (image/png, image/jpeg, …)<\/td><td><strong>Ist<\/strong> (seit ~2026 Q1)<\/td><\/tr><\/tbody><\/table>\n<p><strong>Ist-Zustand Bilder (aktualisiert 2026-04-05):<\/strong> <code>processImageAsync<\/code> ist implementiert und nutzt <code>NEUTRALIZATION_IMAGE<\/code> (Private LLM Vision). <code>_processBinaryFile<\/code> verarbeitet jetzt Bild-Parts über <code>processImageAsync<\/code>. <strong>Einschränkung:<\/strong> Eigenständige Bild-Dateien (<code>image/*<\/code> MIME direkt an <code>processFile<\/code>) werden in <code>_isBinaryMimeType<\/code> weiterhin als Skip behandelt.<\/p>\n<p><strong>Ist (aktualisiert):<\/strong> <code>processImageAsync<\/code> existiert als Einstieg. Ruft internes Vision-Modell (<code>NEUTRALIZATION_IMAGE<\/code> → Private-LLM) auf, um sensible Inhalte in Bildern zu erkennen/entfernen. Kein externer Provider. Modell nicht verfügbar → Bild blockieren (nicht unbehandelt weiterreichen).<\/p>\n<p><strong>Ablauf nach MIME:<\/strong><\/p>\n<table><thead><tr><th>MIME<\/th><th>Pfad<\/th><\/tr><\/thead><tbody><tr><td>PDF, DOCX, XLSX, PPTX<\/td><td><code>runExtraction<\/code> → Text/Table-Parts durch <code>_neutralizeText<\/code>, Bild-Parts durch <code>processImage<\/code> → PDF in-place oder Office-Renderer<\/td><\/tr><tr><td>Text, JSON, CSV, XML<\/td><td><code>_neutralizeText<\/code> direkt (TextProcessor, ListProcessor, BinaryProcessor je nach Inhalt)<\/td><\/tr><tr><td>Bilder (image/*)<\/td><td><strong><code>processImage<\/code><\/strong> → internes Vision-Modell (<code>NEUTRALIZATION_IMAGE<\/code>). Nicht verfügbar → blockieren.<\/td><\/tr><tr><td>Video, Audio<\/td><td>Nur internes Modell oder blockieren (analog Bilder, aber niedrigere Priorität)<\/td><\/tr><tr><td>Anderes Binary<\/td><td>Skip (nicht unterstützt)<\/td><\/tr><\/tbody><\/table>\n<p><strong>Mapping:<\/strong> Platzhalter <code>[typ.uuid]<\/code> → Attribute in DB. <code>resolveText(text)<\/code> für Rückübersetzung.<\/p>\n<hr>\n<h2>5. Modellauswahl<\/h2>\n<table><thead><tr><th>Operation Type<\/th><th>Modelle<\/th><th>Zweck<\/th><\/tr><\/thead><tbody><tr><td><code>NEUTRALIZATION_TEXT<\/code><\/td><td><code>poweron-text-general<\/code> (Rating 9)<\/td><td>Falls Engine ein LLM für Text braucht<\/td><\/tr><tr><td><code>NEUTRALIZATION_IMAGE<\/code><\/td><td><code>poweron-vision-general<\/code> (9), <code>poweron-vision-deep<\/code> (9)<\/td><td>Medien bei Neutralisierungspflicht: nur intern<\/td><\/tr><\/tbody><\/table>\n<p>Registriert in <code>aicorePluginPrivateLlm.py<\/code>. Externe Provider haben keine <code>NEUTRALIZATION_*<\/code>-Ratings → werden nie für Neutralisierung gewählt.<\/p>\n<hr>\n<h2>6. Fail-safe<\/h2>\n<table><thead><tr><th>Situation<\/th><th>Verhalten<\/th><\/tr><\/thead><tbody><tr><td>Neutralisierung gefordert, Engine nicht verfügbar<\/td><td>Content <strong>nicht<\/strong> weiterverarbeiten (blockieren)<\/td><\/tr><tr><td>Neutralisierung eines Teils schlägt fehl<\/td><td>Teil entfernen, nicht im Rohzustand weiterleiten<\/td><\/tr><tr><td>Kein internes Modell für Medien verfügbar<\/td><td>Medien-Part entfernen<\/td><\/tr><\/tbody><\/table>\n<hr>\n<h2>7. Code-Karte<\/h2>\n<table><thead><tr><th>Bereich<\/th><th>Pfad<\/th><\/tr><\/thead><tbody><tr><td>Engine<\/td><td><code>features/neutralization/serviceNeutralization/mainServiceNeutralization.py<\/code> + <code>subProcess*.py<\/code><\/td><\/tr><tr><td>Config + Attribute DB<\/td><td><code>features/neutralization/datamodelFeatureNeutralizer.py<\/code>, <code>interfaceFeatureNeutralizer.py<\/code><\/td><\/tr><tr><td>Index (Data-at-rest)<\/td><td><code>serviceCenter/services/serviceKnowledge/mainServiceKnowledge.py<\/code><\/td><\/tr><tr><td>Prompt-Neutralisierung<\/td><td><code>serviceCenter/services/serviceAi/mainServiceAi.py<\/code> (<code>_shouldNeutralize<\/code>, <code>_neutralizeRequest<\/code>)<\/td><\/tr><tr><td>Agent / DataSource / Feature<\/td><td><code>serviceCenter/services/serviceAgent/mainServiceAgent.py<\/code><\/td><\/tr><tr><td>Workflow-Aktion<\/td><td><code>workflows/methods/methodContext/actions/neutralizeData.py<\/code><\/td><\/tr><tr><td>Modelle / Enums<\/td><td><code>datamodels/datamodelAi.py<\/code>, <code>aicore/aicorePluginPrivateLlm.py<\/code><\/td><\/tr><tr><td>Flags<\/td><td><code>datamodelFiles.py<\/code> (<code>FileItem.neutralize<\/code>), <code>datamodelDataSource.py<\/code>, <code>datamodelFeatureDataSource.py<\/code><\/td><\/tr><tr><td>Context<\/td><td><code>serviceCenter/context.py<\/code> (<code>ServiceCenterContext.requireNeutralization<\/code>)<\/td><\/tr><\/tbody><\/table>\n<hr>\n<h2>8. Umsetzungsplan<\/h2>\n<h3>Schritt 1: <code>processImage<\/code> in Engine bauen<\/h3>\n<p><strong>Datei:<\/strong> <code>mainServiceNeutralization.py<\/code> <strong>Was:<\/strong> Neue Methode <code>processImage(imageBytes: bytes, fileName: str, mimeType: str) -&gt; Dict<\/code> und <code>processImageAsync<\/code>. <strong>Wie:<\/strong> Internes Vision-Modell aufrufen (<code>NEUTRALIZATION_IMAGE<\/code> via Model Selector / <code>aiObjects<\/code>). Prompt: sensible Inhalte im Bild erkennen und beschreiben, damit Caller entscheiden kann ob Bild blockiert wird. Kein internes Modell verfügbar → <code>{'status': 'blocked'}<\/code> zurückgeben. <strong>Abhängigkeit:<\/strong> <code>OperationTypeEnum.NEUTRALIZATION_IMAGE<\/code> + Modell-Ratings in <code>aicorePluginPrivateLlm.py<\/code> — <strong>bereits erledigt<\/strong>.<\/p>\n<h3>Schritt 2: <code>_shouldNeutralize<\/code> vereinfachen<\/h3>\n<p><strong>Datei:<\/strong> <code>mainServiceAi.py<\/code> (Zeile ~560) <strong>Ist:<\/strong> Prüft <code>request.requireNeutralization<\/code> → <code>context.requireNeutralization<\/code> → <code>NeutralizationConfig.enabled<\/code> (Mandant-Level Config). <code>request.requireNeutralization=False<\/code> bricht sofort ab. <strong>Soll:<\/strong> Drei Quellen gemäss Abschnitt 2, kein <code>False<\/code>-Override:<\/p>\n<ol><li>Feature-Instanz: <code>NeutralizationConfig.enabled<\/code> (hat <code>featureInstanceId<\/code>)<\/li><li>Workflow/Session: <code>context.requireNeutralization<\/code><\/li><li>Request: <code>request.requireNeutralization<\/code><\/li><\/ol>\n<p>Irgendein <code>True<\/code> → neutralisieren. <code>False<\/code> in einer Quelle hebt <code>True<\/code> in einer anderen <strong>nicht<\/strong> auf. <strong>Änderung:<\/strong> <code>if request.requireNeutralization is False: return False<\/code> <strong>entfernen<\/strong>. Stattdessen OR-Verknüpfung aller drei Quellen.<\/p>\n<h3>Schritt 3: <code>_neutralizeRequest<\/code> auf Prompt/Messages beschränken<\/h3>\n<p><strong>Datei:<\/strong> <code>mainServiceAi.py<\/code> (Zeile ~592) <strong>Ist:<\/strong> Neutralisiert <code>prompt<\/code>, <code>context<\/code>, <code>messages<\/code> (String-Content). <strong>Soll:<\/strong> Zusätzlich Text in <code>contentParts<\/code> und Text-Teile in multimodalen Messages (content-Liste mit <code>type==text<\/code>). Bild-Teile in Messages: bei Neutralisierungspflicht über <code>processImage<\/code> prüfen oder entfernen. <strong>Wichtig:<\/strong> Hier geht es nur um Prompt-/Sessiondaten. File-Content aus RAG ist bereits neutralisiert (Schritt 5), muss hier nicht nochmal durch.<\/p>\n<h3>Schritt 4: <code>indexFile<\/code> — Bild-Chunks behandeln<\/h3>\n<p><strong>Datei:<\/strong> <code>mainServiceKnowledge.py<\/code> (Zeile ~146 ff.) <strong>Ist:<\/strong> Nur <code>textObjects<\/code> (contentType == \"text\") werden bei <code>_shouldNeutralize<\/code> durch <code>processText<\/code> geschickt. Bild-Chunks (<code>contentType == \"image\"<\/code>) werden unverändert indexiert. <strong>Soll:<\/strong> Bild-Chunks bei <code>_shouldNeutralize<\/code> über <code>processImage<\/code> (Schritt 1) prüfen. Ergebnis <code>blocked<\/code> → Bild-Chunk nicht indexieren. Ergebnis OK → Bild-Chunk indexieren (internes Modell hat es gesehen, kein externer Provider nötig). <strong>Abhängigkeit:<\/strong> Schritt 1.<\/p>\n<h3>Schritt 5: Agent-Tool <code>readFile<\/code> — Content bei Extraktion neutralisieren<\/h3>\n<p><strong>Datei:<\/strong> <code>mainServiceAgent.py<\/code>, Tool <code>_readFile<\/code> (Zeile ~540 ff.) <strong>Ist:<\/strong> Liest aus Knowledge Store (bereits indexiert) oder extrahiert on-demand. Kein Neutralisierungs-Check. <strong>Soll:<\/strong><\/p>\n<ul><li><strong>Knowledge Store Pfad (Zeile ~548):<\/strong> RAG-Chunks sind bereits neutralisiert wenn <code>FileItem.neutralize=True<\/code> war (Schritt 4) → nichts zu tun.<\/li><li><strong>On-Demand Extraktion (Zeile ~630 ff.):<\/strong> Nach <code>runExtraction<\/code> und vor Rückgabe der Text-Objekte: <code>FileItem.neutralize<\/code> laden. Wenn <code>True<\/code> → Text-Objekte durch <code>processText<\/code>, Bild-Objekte durch <code>processImage<\/code>.<\/li><\/ul>\n<h3>Schritt 6: Agent-Tool <code>summarizeContent<\/code> — File-Flag prüfen<\/h3>\n<p><strong>Datei:<\/strong> <code>mainServiceAgent.py<\/code>, Tool <code>_summarizeContent<\/code> (Zeile ~1921 ff.) <strong>Ist:<\/strong> Liest Content-Objects aus Knowledge Store, baut <code>combinedText<\/code> und ruft <code>callAi<\/code> auf. Kein Neutralisierungs-Check. <strong>Soll:<\/strong> Content aus Knowledge Store ist bereits neutralisiert (Schritt 4) → nichts zu tun, <strong>sofern<\/strong> File indexiert war. Wenn nicht indexiert: File-Flag prüfen, Text vor <code>callAi<\/code> durch <code>processText<\/code>. <strong>Hinweis:<\/strong> Durch Schritt 4 ist der Regelfall abgedeckt.<\/p>\n<h3>Schritt 7: Agent-Tool <code>describeImage<\/code> — File-Flag prüfen<\/h3>\n<p><strong>Datei:<\/strong> <code>mainServiceAgent.py<\/code>, Tool <code>_describeImage<\/code> (Zeile ~2015 ff.) <strong>Ist:<\/strong> Lädt Bild-Chunk oder Rohdaten, sendet per <code>callAi<\/code> mit <code>IMAGE_ANALYSE<\/code> an <strong>beliebigen<\/strong> Provider (inkl. extern). Kein Neutralisierungs-Check. <strong>Soll:<\/strong> <code>FileItem.neutralize<\/code> laden (fileId ist bekannt). Wenn <code>True<\/code>:<\/p>\n<ul><li><code>operationType<\/code> auf <code>NEUTRALIZATION_IMAGE<\/code> statt <code>IMAGE_ANALYSE<\/code> → Model Selector wählt nur internes Modell.<\/li><li>Kein internes Modell → Tool gibt Fehler zurück statt Bild an externen Provider zu senden.<\/li><\/ul>\n<h3>Schritt 8: <code>_processBinaryFile<\/code> — Bild-Parts nicht mehr überspringen<\/h3>\n<p><strong>Datei:<\/strong> <code>mainServiceNeutralization.py<\/code> (Zeile ~298) <strong>Ist:<\/strong> <code>if type_group in ('binary', 'image'): neutralized_parts.append(part); continue<\/code> — Bild-Parts werden übersprungen. <strong>Soll:<\/strong> <code>binary<\/code> weiterhin skip. <code>image<\/code> → durch <code>processImage<\/code> (Schritt 1). Ergebnis <code>blocked<\/code> → Part entfernen. Ergebnis OK → Part behalten. <strong>Abhängigkeit:<\/strong> Schritt 1.<\/p>\n<h3>Schritt 9: Workflow-Aktion <code>neutralizeData<\/code> — Bild-Parts<\/h3>\n<p><strong>Datei:<\/strong> <code>neutralizeData.py<\/code> (Zeile ~130 ff.) <strong>Ist:<\/strong> Iteriert über ContentParts, neutralisiert nur Parts mit <code>part.data<\/code> (Text). <code>typeGroup != text/table<\/code> → unverändert durchgereicht. <strong>Soll:<\/strong> Bild-Parts durch <code>processImage<\/code>. Ergebnis <code>blocked<\/code> → Part entfernen. <strong>Abhängigkeit:<\/strong> Schritt 1.<\/p>\n<h3>Schritt 10: Tests<\/h3>\n<table><thead><tr><th>Test<\/th><th>Was<\/th><\/tr><\/thead><tbody><tr><td>T1<\/td><td><code>FileItem.neutralize=True<\/code> → <code>indexFile<\/code> → Text-Chunks neutralisiert, Bild-Chunks geprüft/blockiert<\/td><\/tr><tr><td>T2<\/td><td><code>readFile<\/code> on-demand auf File mit <code>neutralize=True<\/code> → Text neutralisiert<\/td><\/tr><tr><td>T3<\/td><td><code>describeImage<\/code> auf File mit <code>neutralize=True<\/code> → nur internes Modell<\/td><\/tr><tr><td>T4<\/td><td>Feature-Instanz Config <code>enabled=True<\/code> → Prompt in <code>callAi<\/code> neutralisiert<\/td><\/tr><tr><td>T5<\/td><td>Workflow <code>requireNeutralization=True<\/code> → Prompt neutralisiert<\/td><\/tr><tr><td>T6<\/td><td><code>processFile<\/code> auf PDF mit Bildern → Text neutralisiert, Bild-Parts durch <code>processImage<\/code><\/td><\/tr><tr><td>T7<\/td><td>Flag-Toggle → Index gelöscht → Re-Index im richtigen Zustand<\/td><\/tr><\/tbody><\/table>\n<h3>Schritt 11: Logging<\/h3>\n<p><strong>Alle Stellen (Schritte 2–9):<\/strong> Bei Neutralisierung loggen: welche Quelle (Feature-Instanz / Workflow / File-Flag), welche <code>fileId<\/code> falls vorhanden, Ergebnis (OK / Part entfernt / blockiert). <strong>Kein Klartext<\/strong> in Logs.<\/p>", "text": "# neutralisierung **stand:** 2026-04-16 --- ## 1. grundidee neutralisierung passiert dort, wo **content entsteht oder ins system einfliesst** — nicht als nachgelagerter filter vor dem modell-call. wenn content einmal neutralisiert ist (z. b. im rag), bleibt er neutralisiert. kein doppeltes verarbeiten. --- ## 2. wer fordert neutralisierung? drei quellen, von breit nach spezifisch: | quelle | flag im code | bedeutung | |--------|-------------|-----------| | **feature-instanz** | `dataneutraliserconfig.enabled` (hat `featureinstanceid` + `mandateid`) | alle daten in dieser feature-instanz werden neutralisiert. betrifft jeden content-einstieg innerhalb dieser instanz. | | **chat-workflow / session** | `servicecentercontext.requireneutralization` (gesetzt z. b. vom ai-workspace oder automation) | dieser workflow/turn: jeder content, der hier verarbeitet wird, wird neutralisiert. | | **dokument oder quelle** | `fileitem.neutralize`, `filefolder.neutralize`, `datasource.neutralize`, `featuredatasource.neutralize`, `featuredatasource.neutralizefields` | dieses konkrete objekt: content daraus wird neutralisiert, egal ob die feature-instanz oder der workflow es sonst fordern würden. `filefolder.neutralize` propagiert auf alle enthaltenen dateien. `neutralizefields` ermöglicht feld-level-maskierung bei db-queries. | **auswertung:** irgendeine quelle sagt `true` → neutralisieren. keine quelle kann eine andere aufheben. es gibt kein `false`-override, das ein `true` von woanders aushebelt. --- ## 3. wo passiert die neutralisierung? am **punkt der content-einspeisung** — dort wo rohdaten zu verarbeitbarem content werden: | content-einstieg | was passiert | wer prüft das flag | |------------------|-------------|---------------------| | **datei-indexierung** (rag) | text-chunks werden über `processtext` neutralisiert, bevor sie ins embedding gehen. medien: nur internes modell oder nicht indexieren. ergebnis: rag enthält nur neutralisierten content. | `mainserviceknowledge.indexfile` liest `fileitem.neutralize` | | **content-extraktion** (dokumente für ki-verarbeitung) | extrahierter text/tabellen werden neutralisiert. pdf, docx, xlsx, pptx über `processfile` (extract → neutralisieren → zurückschreiben). | caller kennt die quelle und deren flag | | **user-prompt** (chat-eingabe) | prompt-text wird durch `processtext` neutralisiert, wenn feature-instanz oder workflow es fordern. | `mainserviceai` prüft context-flag / config | | **datasource-download** | flag wird auf erstellte `fileitem`s vererbt → bei extraktion/indexierung greift das file-flag automatisch. | `mainserviceagent._resolvedatasource` / `_downloadfromdatasource` | | **featuredatasource-abfrage (tabelle)** | wenn eine `featuredatasource.neutralize=true` hat → content aus diesem sub-agent-call wird neutralisiert. | `mainserviceagent._queryfeatureinstance` setzt `requireneutralization=true` | | **featuredatasource-abfrage (feld/typ, seit 2026-06)** | typ- und vererbungsbewusst: **strings** werden substring-neutralisiert sobald effektiv (explizit oder geerbt, feldname als typ-hint); **binary** wird gedroppt; **andere skalare** (number/date/bool) nur bei **explizitem** feld-flag als ganzwert-platzhalter `[neut.<field>.<hash>]`. identifikatoren/system-spalten ausgenommen, engine-ausfall = `[redacted]`. rag-bootstrap nutzt dieselbe policy (query- und index-pfad konsistent). | `featuredataprovider.finalizerowsasync` / `_neutralizeandserializerows`; policy aus `coretools/_featuresubagenttools` via `resolveeffectiveforfds` | | **de-neutralisierung für download (seit 2026-06)** | read-only agent-tool `revealdocument` löst platzhalter **nur** über das lokale mapping (`resolvetext`, kein externes llm) auf und liefert klartext als transienten einmal-download (sse `revealdownload`) — kein save/index/historie. | `coretools/_mediatools._revealdocument` | | **ordner-neutralisierung** | `filefolder.neutralize=true` propagiert auf alle enthaltenen dateien (rekursiv). neue/verschobene dateien erben das flag. index-purge + re-index wie bei einzelnen dateien. | `routedatafiles.updatefolderneutralize` | | **workflow-aktion `neutralizedata`** | expliziter neutralisierungs-schritt auf bereits extrahierten contentparts. | workflow-config + `neutralizationconfig.enabled` | **was nicht nochmal neutralisiert werden muss:** - rag-chunks, die bereits neutralisiert indexiert sind — die sind schon sauber. - web-suchergebnisse — enthalten keine mandantendaten, brauchen keine neutralisierung. **flag-änderung:** ändert sich `fileitem.neutralize` (toggle) → index löschen → re-indexierung triggern → neuer index ist im richtigen zustand. --- ## 4. engine: `neutralizationservice` eine engine, drei einstiege, aufgerufen an den content-einstiegspunkten aus abschnitt 3. | api | eingabe | status | |-----|---------|--------| | `processtext(text)` | rohtext (prompt, message, text-contentpart, text-chunk) | **ist** | | `processfile(fileid)` | datei aus db — wird nach mime geroutet | **ist** | | `processbinarybytes` / `async` | bytes + dateiname + mime | **ist** | | **`processimage(imagebytes, filename)`** / `processimageasync` | bild-datei oder bild-contentpart (image/png, image/jpeg, …) | **ist** (seit ~2026 q1) | **ist-zustand bilder (aktualisiert 2026-04-05):** `processimageasync` ist implementiert und nutzt `neutralization_image` (private llm vision). `_processbinaryfile` verarbeitet jetzt bild-parts über `processimageasync`. **einschränkung:** eigenständige bild-dateien (`image/*` mime direkt an `processfile`) werden in `_isbinarymimetype` weiterhin als skip behandelt. **ist (aktualisiert):** `processimageasync` existiert als einstieg. ruft internes vision-modell (`neutralization_image` → private-llm) auf, um sensible inhalte in bildern zu erkennen/entfernen. kein externer provider. modell nicht verfügbar → bild blockieren (nicht unbehandelt weiterreichen). **ablauf nach mime:** | mime | pfad | |------|------| | pdf, docx, xlsx, pptx | `runextraction` → text/table-parts durch `_neutralizetext`, bild-parts durch `processimage` → pdf in-place oder office-renderer | | text, json, csv, xml | `_neutralizetext` direkt (textprocessor, listprocessor, binaryprocessor je nach inhalt) | | bilder (image/*) | **`processimage`** → internes vision-modell (`neutralization_image`). nicht verfügbar → blockieren. | | video, audio | nur internes modell oder blockieren (analog bilder, aber niedrigere priorität) | | anderes binary | skip (nicht unterstützt) | **mapping:** platzhalter `[typ.uuid]` → attribute in db. `resolvetext(text)` für rückübersetzung. --- ## 5. modellauswahl | operation type | modelle | zweck | |----------------|---------|-------| | `neutralization_text` | `poweron-text-general` (rating 9) | falls engine ein llm für text braucht | | `neutralization_image` | `poweron-vision-general` (9), `poweron-vision-deep` (9) | medien bei neutralisierungspflicht: nur intern | registriert in `aicorepluginprivatellm.py`. externe provider haben keine `neutralization_*`-ratings → werden nie für neutralisierung gewählt. --- ## 6. fail-safe | situation | verhalten | |-----------|-----------| | neutralisierung gefordert, engine nicht verfügbar | content **nicht** weiterverarbeiten (blockieren) | | neutralisierung eines teils schlägt fehl | teil entfernen, nicht im rohzustand weiterleiten | | kein internes modell für medien verfügbar | medien-part entfernen | --- ## 7. code-karte | bereich | pfad | |---------|------| | engine | `features/neutralization/serviceneutralization/mainserviceneutralization.py` + `subprocess*.py` | | config + attribute db | `features/neutralization/datamodelfeatureneutralizer.py`, `interfacefeatureneutralizer.py` | | index (data-at-rest) | `servicecenter/services/serviceknowledge/mainserviceknowledge.py` | | prompt-neutralisierung | `servicecenter/services/serviceai/mainserviceai.py` (`_shouldneutralize`, `_neutralizerequest`) | | agent / datasource / feature | `servicecenter/services/serviceagent/mainserviceagent.py` | | workflow-aktion | `workflows/methods/methodcontext/actions/neutralizedata.py` | | modelle / enums | `datamodels/datamodelai.py`, `aicore/aicorepluginprivatellm.py` | | flags | `datamodelfiles.py` (`fileitem.neutralize`), `datamodeldatasource.py`, `datamodelfeaturedatasource.py` | | context | `servicecenter/context.py` (`servicecentercontext.requireneutralization`) | --- ## 8. umsetzungsplan ### schritt 1: `processimage` in engine bauen **datei:** `mainserviceneutralization.py` **was:** neue methode `processimage(imagebytes: bytes, filename: str, mimetype: str) -> dict` und `processimageasync`. **wie:** internes vision-modell aufrufen (`neutralization_image` via model selector / `aiobjects`). prompt: sensible inhalte im bild erkennen und beschreiben, damit caller entscheiden kann ob bild blockiert wird. kein internes modell verfügbar → `{'status': 'blocked'}` zurückgeben. **abhängigkeit:** `operationtypeenum.neutralization_image` + modell-ratings in `aicorepluginprivatellm.py` — **bereits erledigt**. ### schritt 2: `_shouldneutralize` vereinfachen **datei:** `mainserviceai.py` (zeile ~560) **ist:** prüft `request.requireneutralization` → `context.requireneutralization` → `neutralizationconfig.enabled` (mandant-level config). `request.requireneutralization=false` bricht sofort ab. **soll:** drei quellen gemäss abschnitt 2, kein `false`-override: 1. feature-instanz: `neutralizationconfig.enabled` (hat `featureinstanceid`) 2. workflow/session: `context.requireneutralization` 3. request: `request.requireneutralization` irgendein `true` → neutralisieren. `false` in einer quelle hebt `true` in einer anderen **nicht** auf. **änderung:** `if request.requireneutralization is false: return false` **entfernen**. stattdessen or-verknüpfung aller drei quellen. ### schritt 3: `_neutralizerequest` auf prompt/messages beschränken **datei:** `mainserviceai.py` (zeile ~592) **ist:** neutralisiert `prompt`, `context`, `messages` (string-content). **soll:** zusätzlich text in `contentparts` und text-teile in multimodalen messages (content-liste mit `type==text`). bild-teile in messages: bei neutralisierungspflicht über `processimage` prüfen oder entfernen. **wichtig:** hier geht es nur um prompt-/sessiondaten. file-content aus rag ist bereits neutralisiert (schritt 5), muss hier nicht nochmal durch. ### schritt 4: `indexfile` — bild-chunks behandeln **datei:** `mainserviceknowledge.py` (zeile ~146 ff.) **ist:** nur `textobjects` (contenttype == \"text\") werden bei `_shouldneutralize` durch `processtext` geschickt. bild-chunks (`contenttype == \"image\"`) werden unverändert indexiert. **soll:** bild-chunks bei `_shouldneutralize` über `processimage` (schritt 1) prüfen. ergebnis `blocked` → bild-chunk nicht indexieren. ergebnis ok → bild-chunk indexieren (internes modell hat es gesehen, kein externer provider nötig). **abhängigkeit:** schritt 1. ### schritt 5: agent-tool `readfile` — content bei extraktion neutralisieren **datei:** `mainserviceagent.py`, tool `_readfile` (zeile ~540 ff.) **ist:** liest aus knowledge store (bereits indexiert) oder extrahiert on-demand. kein neutralisierungs-check. **soll:** - **knowledge store pfad (zeile ~548):** rag-chunks sind bereits neutralisiert wenn `fileitem.neutralize=true` war (schritt 4) → nichts zu tun. - **on-demand extraktion (zeile ~630 ff.):** nach `runextraction` und vor rückgabe der text-objekte: `fileitem.neutralize` laden. wenn `true` → text-objekte durch `processtext`, bild-objekte durch `processimage`. ### schritt 6: agent-tool `summarizecontent` — file-flag prüfen **datei:** `mainserviceagent.py`, tool `_summarizecontent` (zeile ~1921 ff.) **ist:** liest content-objects aus knowledge store, baut `combinedtext` und ruft `callai` auf. kein neutralisierungs-check. **soll:** content aus knowledge store ist bereits neutralisiert (schritt 4) → nichts zu tun, **sofern** file indexiert war. wenn nicht indexiert: file-flag prüfen, text vor `callai` durch `processtext`. **hinweis:** durch schritt 4 ist der regelfall abgedeckt. ### schritt 7: agent-tool `describeimage` — file-flag prüfen **datei:** `mainserviceagent.py`, tool `_describeimage` (zeile ~2015 ff.) **ist:** lädt bild-chunk oder rohdaten, sendet per `callai` mit `image_analyse` an **beliebigen** provider (inkl. extern). kein neutralisierungs-check. **soll:** `fileitem.neutralize` laden (fileid ist bekannt). wenn `true`: - `operationtype` auf `neutralization_image` statt `image_analyse` → model selector wählt nur internes modell. - kein internes modell → tool gibt fehler zurück statt bild an externen provider zu senden. ### schritt 8: `_processbinaryfile` — bild-parts nicht mehr überspringen **datei:** `mainserviceneutralization.py` (zeile ~298) **ist:** `if type_group in ('binary', 'image'): neutralized_parts.append(part); continue` — bild-parts werden übersprungen. **soll:** `binary` weiterhin skip. `image` → durch `processimage` (schritt 1). ergebnis `blocked` → part entfernen. ergebnis ok → part behalten. **abhängigkeit:** schritt 1. ### schritt 9: workflow-aktion `neutralizedata` — bild-parts **datei:** `neutralizedata.py` (zeile ~130 ff.) **ist:** iteriert über contentparts, neutralisiert nur parts mit `part.data` (text). `typegroup != text/table` → unverändert durchgereicht. **soll:** bild-parts durch `processimage`. ergebnis `blocked` → part entfernen. **abhängigkeit:** schritt 1. ### schritt 10: tests | test | was | |------|-----| | t1 | `fileitem.neutralize=true` → `indexfile` → text-chunks neutralisiert, bild-chunks geprüft/blockiert | | t2 | `readfile` on-demand auf file mit `neutralize=true` → text neutralisiert | | t3 | `describeimage` auf file mit `neutralize=true` → nur internes modell | | t4 | feature-instanz config `enabled=true` → prompt in `callai` neutralisiert | | t5 | workflow `requireneutralization=true` → prompt neutralisiert | | t6 | `processfile` auf pdf mit bildern → text neutralisiert, bild-parts durch `processimage` | | t7 | flag-toggle → index gelöscht → re-index im richtigen zustand | ### schritt 11: logging **alle stellen (schritte 2–9):** bei neutralisierung loggen: welche quelle (feature-instanz / workflow / file-flag), welche `fileid` falls vorhanden, ergebnis (ok / part entfernt / blockiert). **kein klartext** in logs. ", "nextReview": "", "overdueReview": false, "zuPruefen": []}, {"id": "05_betrieb/security-overview.md", "path": "05_betrieb/security-overview.md", "chapter": "05_betrieb", "title": "PowerOn Plattform -- Sicherheit und Compliance", "filename": "security-overview.md", "meta": {}, "html": "<h1>PowerOn Plattform -- Sicherheit und Compliance<\/h1>\n<p><strong>Stand:<\/strong> Februar 2026 <strong>Zielgruppe:<\/strong> Entscheidungsträger, Einkauf, Rechtsabteilung, Datenschutzbeauftragte <strong>Klassifizierung:<\/strong> Kundeninformation<\/p>\n<hr>\n<h2>1. Management Summary<\/h2>\n<p>PowerOn ist eine <strong>Multi-Mandanten-KI-Plattform für Unternehmen<\/strong>, die es Organisationen ermöglicht, KI-gestützte Geschäftsprozesse sicher, datenschutzkonform und mandantengetrennt zu betreiben. Die Plattform richtet sich an mittlere bis grosse Unternehmen in datenschutzsensiblen Branchen wie Finanzwesen, Treuhand, Immobilien und Beratung.<\/p>\n<p>Dieses Dokument beschreibt die in PowerOn implementierten Sicherheits- und Datenschutzmassnahmen, ordnet diese gängigen Standards zu und benennt transparent bestehende Einschränkungen.<\/p>\n<p><strong>Kernaussagen:<\/strong><\/p>\n<ul><li><strong>DSGVO-Betroffenenrechte<\/strong> (Auskunft, Löschung, Datenübertragbarkeit, Berichtigung) sind als Self-Service-Funktionen direkt in der Plattform implementiert.<\/li><li><strong>Vollständige Mandantentrennung:<\/strong> Daten eines Mandanten sind unter keinen Umständen für andere Mandanten einsehbar oder zugänglich.<\/li><li><strong>Rollenbasierte Zugriffskontrolle (RBAC):<\/strong> Jeder Datenzugriff wird gegen ein mehrstufiges Berechtigungssystem geprüft -- konfigurierbar pro Mandant und Funktionsmodul.<\/li><li><strong>Verschlüsselung:<\/strong> Sensible Konfigurationsdaten sind nach Industriestandard verschlüsselt, sämtliche Kommunikation erfolgt über verschlüsselte Verbindungen.<\/li><li><strong>Audit-Trail:<\/strong> Alle sicherheitsrelevanten Aktionen werden lückenlos protokolliert und stehen für Compliance-Nachweise zur Verfügung.<\/li><li><strong>Transparenz bei KI-Nutzung:<\/strong> Die Plattform dokumentiert offen, welche Daten an KI-Dienste übermittelt werden, und bietet Konfigurationsoptionen für höchste Datenschutzanforderungen.<\/li><\/ul>\n<hr>\n<h2>2. DSGVO-Konformität<\/h2>\n<p>PowerOn implementiert die zentralen Betroffenenrechte der Datenschutz-Grundverordnung (DSGVO/GDPR) direkt als Plattformfunktionen. Im Folgenden wird für jeden relevanten Artikel beschrieben, was implementiert ist und wo Einschränkungen bestehen.<\/p>\n<h3>2.1 Auskunftsrecht (Art. 15 DSGVO)<\/h3>\n<p>Nutzer können über eine Self-Service-Funktion sämtliche über sie gespeicherten Daten exportieren:<\/p>\n<ul><li>Persönliche Profildaten (Name, E-Mail, Spracheinstellungen)<\/li><li>Mandatszugehörigkeiten und zugewiesene Rollen<\/li><li>Zugriffsrechte auf Funktionsmodule<\/li><li>Erstellte und eingelöste Einladungen<\/li><li>Zeitpunkte der Kontörstellung und letzten Anmeldung<\/li><\/ul>\n<p>Der Export umfasst alle auf Plattformebene gespeicherten Daten. Feature-spezifische Daten (z.B. Chat-Verläufe, Treuhandpositionen) können über die jeweiligen Funktionsmodule eingesehen werden.<\/p>\n<p><strong>Status: Implementiert.<\/strong><\/p>\n<h3>2.2 Recht auf Löschung (Art. 17 DSGVO)<\/h3>\n<p>Nutzer können ihr Konto und alle zugehörigen Daten eigenständig und unwiderruflich löschen. Dabei gilt:<\/p>\n<ul><li>Das System durchsucht automatisch alle Datenbanken (Plattform, Verwaltung, Chat, alle Funktionsmodule) nach Einträgen, die dem Nutzer zugeordnet sind.<\/li><li>Nutzerbezogene Daten werden vollständig gelöscht.<\/li><li>Audit-Logs werden anonymisiert statt gelöscht -- dies gewährleistet die Einhaltung gesetzlicher Aufbewahrungspflichten bei gleichzeitiger Wahrung der Betroffenenrechte.<\/li><li>Die Löschung erfordert eine explizite Bestätigung durch den Nutzer.<\/li><li>Systemadministratoren sind von der Selbstlöschung ausgenommen (Vier-Augen-Prinzip).<\/li><\/ul>\n<p><strong>Status: Implementiert.<\/strong><\/p>\n<h3>2.3 Recht auf Datenübertragbarkeit (Art. 20 DSGVO)<\/h3>\n<p>Nutzerdaten können in einem maschinenlesbaren, standardisierten Format (JSON-LD nach schema.org) exportiert werden. Dieses Format ermöglicht die Übertragung der Daten an einen anderen Dienstleister.<\/p>\n<p><strong>Status: Implementiert.<\/strong><\/p>\n<h3>2.4 Berichtigungsrecht (Art. 16 DSGVO)<\/h3>\n<p>Nutzer können ihre Profildaten (Name, E-Mail, Spracheinstellungen) jederzeit selbst korrigieren.<\/p>\n<p><strong>Status: Implementiert.<\/strong><\/p>\n<h3>2.5 Transparenz und Informationspflicht<\/h3>\n<p>Die Plattform stellt Nutzern aktiv Informationen über die Datenverarbeitung bereit:<\/p>\n<ul><li>Welche Daten erhoben werden<\/li><li>Zu welchem Zweck die Verarbeitung erfolgt<\/li><li>Auf welcher Rechtsgrundlage die Verarbeitung basiert<\/li><li>Welche Aufbewahrungsfristen gelten<\/li><li>Welche Betroffenenrechte bestehen und wie sie ausgeübt werden können<\/li><\/ul>\n<p><strong>Status: Implementiert.<\/strong><\/p>\n<h3>2.6 Bekannte Einschränkungen<\/h3>\n<p>Die folgenden Punkte sind transparent zu benennen:<\/p>\n<ul><li><strong>Consent-Management:<\/strong> Die Plattform verfügt derzeit über kein granulares Einwilligungsmanagement mit individuellen Zustimmungs-Toggles. Die Einwilligung zur Datenverarbeitung erfolgt über die Nutzungsbedingungen und, bei Drittanbieter-Authentifizierung (Microsoft, Google), über die jeweiligen OAuth-Einwilligungsflüsse.<\/li><li><strong>Datenschutz-Kontaktadresse:<\/strong> Die Kontaktadresse für Datenschutzanfragen ist pro Deployment konfigurierbar und muss vom jeweiligen Betreiber hinterlegt werden.<\/li><\/ul>\n<hr>\n<h2>3. Mandantenmodell und Datenisolation<\/h2>\n<h3>3.1 Grundprinzip<\/h3>\n<p>PowerOn ist als Multi-Mandanten-Plattform konzipiert. Jede Organisation, Abteilung oder jeder Kunde wird als eigenständiger <strong>Mandant<\/strong> abgebildet. Das zentrale Sicherheitsversprechen:<\/p>\n<blockquote><strong>Daten eines Mandanten sind unter keinen Umständen für Nutzer anderer Mandanten sichtbar oder zugänglich.<\/strong><\/blockquote>\n<h3>3.2 Wie die Trennung funktioniert<\/h3>\n<ul><li><strong>Zugehörigkeitsprüfung bei jedem Zugriff:<\/strong> Bevor ein Nutzer auf Mandantendaten zugreifen kann, prüft die Plattform, ob eine aktive Mitgliedschaft des Nutzers in diesem Mandanten besteht. Ohne nachgewiesene Mitgliedschaft wird der Zugriff verweigert.<\/li><li><strong>Kein mandantenübergreifender Datenfluss:<\/strong> Datenbankabfragen werden automatisch auf den Mandantenkontext gefiltert. Es gibt keinen Mechanismus, der Daten mandantenübergreifend zusammenführt oder exponiert.<\/li><li><strong>Feature-Isolation:<\/strong> Innerhalb eines Mandanten werden Funktionsmodule (z.B. CommCoach, Treuhand, Immobilien) zusätzlich isoliert. Nutzer benötigen für jedes Funktionsmodul eine explizite Zugriffsberechtigung.<\/li><\/ul>\n<h3>3.3 Mehrfachmandanten<\/h3>\n<p>Nutzer können gleichzeitig in mehreren Mandanten arbeiten -- ein häufiges Szenario bei Beratern, Treuhändern oder Dienstleistern mit mehreren Kunden. Die Plattform stellt sicher:<\/p>\n<ul><li>Der Mandantenkontext wird pro Anfrage bestimmt, nicht pro Sitzung. Ein Wechsel zwischen Mandanten ist jederzeit möglich, ohne dass Daten vermischt werden.<\/li><li>Es findet keine Übertragung von Daten, Berechtigungen oder Einstellungen zwischen Mandanten statt.<\/li><\/ul>\n<h3>3.4 Schutz vor Manipulation<\/h3>\n<p>Auch bei technischem Wissen über die Plattformarchitektur ist ein unbefugter Zugriff auf fremde Mandantendaten nicht möglich: Die Zugehörigkeitsprüfung erfolgt serverseitig und kann nicht durch Manipulation von Anfrageparametern umgangen werden.<\/p>\n<hr>\n<h2>4. Rollenbasierte Zugriffskontrolle (RBAC)<\/h2>\n<h3>4.1 Berechtigungsmodell<\/h3>\n<p>PowerOn verfügt über ein feingliedriges, rollenbasiertes Berechtigungssystem. Für jede Aktion (Lesen, Erstellen, Bearbeiten, Löschen) können individuelle Berechtigungsstufen vergeben werden:<\/p>\n<table><thead><tr><th>Berechtigungsstufe<\/th><th>Beschreibung<\/th><\/tr><\/thead><tbody><tr><td>Kein Zugriff<\/td><td>Funktion ist nicht verfügbar<\/td><\/tr><tr><td>Eigene Daten<\/td><td>Zugriff nur auf selbst erstellte Einträge<\/td><\/tr><tr><td>Mandantendaten<\/td><td>Zugriff auf alle Daten innerhalb des eigenen Mandanten<\/td><\/tr><tr><td>Alle Daten<\/td><td>Vollzugriff (typischerweise für Administratoren)<\/td><\/tr><\/tbody><\/table>\n<h3>4.2 Konfigurierbarkeit<\/h3>\n<ul><li>Rollen können <strong>pro Mandant<\/strong> und <strong>pro Funktionsmodul<\/strong> definiert und zugewiesen werden.<\/li><li>Es gibt keine fest verdrahteten Berechtigungen -- jede Organisation kann das Rollenmodell an ihre Bedürfnisse anpassen.<\/li><li>Berechtigungsänderungen werden im Audit-Trail protokolliert.<\/li><\/ul>\n<h3>4.3 Administratoren<\/h3>\n<p>Systemadministratoren verfügen über erweiterte Rechte, unterliegen jedoch ebenfalls dem RBAC-System. Alle Administratoraktionen werden gesondert im Audit-Log festgehalten. Es gibt kein unkontrolliertes \"Superuser\"-Konto ohne Nachvollziehbarkeit.<\/p>\n<hr>\n<h2>5. Verschlüsselung und Datensicherheit<\/h2>\n<h3>5.1 Verschlüsselung ruhender Daten<\/h3>\n<p>Alle sensiblen Konfigurationsdaten werden verschlüsselt gespeichert:<\/p>\n<ul><li><strong>Verschlüsselungsverfahren:<\/strong> AES-Verschlüsselung (Fernet)<\/li><li><strong>Schlüsselableitung:<\/strong> PBKDF2-HMAC-SHA256 nach aktuellem Industriestandard<\/li><li><strong>Umfang:<\/strong> Datenbankpasswörter, API-Schlüssel für KI-Dienste, OAuth-Geheimnisse, JWT-Schlüssel und alle weiteren als \"SECRET\" gekennzeichneten Konfigurationswerte<\/li><\/ul>\n<p>Sensible Konfigurationsdaten liegen zu keinem Zeitpunkt im Klartext in der Konfiguration oder im Quellcode vor.<\/p>\n<h3>5.2 Verschlüsselung in Übertragung<\/h3>\n<ul><li>Sämtliche Kommunikation zwischen Client und Server erfolgt über HTTPS/TLS.<\/li><li>Verbindungen zu Drittdiensten (KI-Anbieter, Authentifizierungsdienste, E-Mail-Dienste) nutzen ebenfalls ausschliesslich verschlüsselte Verbindungen.<\/li><li>Die TLS-Konfiguration erfolgt auf Infrastruktur-Ebene (Azure / Reverse Proxy) -- dies entspricht dem Branchenstandard bei Cloud-Deployments und ermöglicht zentrale Verwaltung und Aktualisierung der Zertifikate.<\/li><\/ul>\n<h3>5.3 Zugriffskontrolle auf Verschlüsselungsschlüssel<\/h3>\n<ul><li>Der Zugriff auf Verschlüsselungsschlüssel ist auf das Minimum beschränkt.<\/li><li>Jeder Zugriff auf Verschlüsselungsfunktionen (Entschlüsselung, Neuverschlüsselung) wird im Audit-Trail protokolliert.<\/li><li>Eine Ratenbegrenzung schützt vor automatisierten Entschlüsselungsversuchen.<\/li><\/ul>\n<hr>\n<h2>6. Schutzmassnahmen gegen Angriffe<\/h2>\n<p>PowerOn implementiert Schutzmassnahmen gegen die gängigsten Angriffsvektoren für Webanwendungen:<\/p>\n<h3>6.1 Cross-Site Request Forgery (CSRF)<\/h3>\n<p>Alle datenverändernden Operationen (POST, PUT, DELETE, PATCH) erfordern einen <code>X-CSRF-Token<\/code> Header. Die aktuelle Implementierung validiert das Tokenformat (16-64 Zeichen Hex-String); es gibt kein serverseitiges Session-Binding (kein klassisches Double-Submit oder Synchronizer Token). In Kombination mit <code>SameSite=Strict<\/code> Cookies und CORS bietet dies Basisschutz gegen CSRF.<\/p>\n<h3>6.2 Ratenbegrenzung (Rate Limiting)<\/h3>\n<p>Jede API-Funktion ist mit individuellen Zugriffslimits versehen, die automatisierte Angriffe und Missbrauch unterbinden:<\/p>\n<table><thead><tr><th>Funktion<\/th><th>Limit<\/th><\/tr><\/thead><tbody><tr><td>Anmeldung<\/td><td>30 Versuche pro Minute<\/td><\/tr><tr><td>Datenexport (DSGVO)<\/td><td>5 Anfragen pro Minute<\/td><\/tr><tr><td>Kontolöschung<\/td><td>1 Anfrage pro Stunde<\/td><\/tr><tr><td>KI-Anfragen<\/td><td>120 Anfragen pro Minute<\/td><\/tr><tr><td>Datei-Upload<\/td><td>10 Uploads pro Minute<\/td><\/tr><\/tbody><\/table>\n<h3>6.3 Eingabebereinigung<\/h3>\n<p>Nutzereingaben werden bereinigt und validiert, bevor sie an KI-Modelle oder Datenbanken weitergeleitet werden. Dies schützt vor Prompt-Injection-Angriffen und anderen Manipulationsversuchen.<\/p>\n<h3>6.4 SQL-Injection-Schutz<\/h3>\n<ul><li>Alle Datenbankabfragen der Plattform verwenden parametrisierte Abfragen -- der Industriestandard zur Vermeidung von SQL-Injection.<\/li><li>Der KI-gestützte Datenbankzugriff ist zusätzlich auf reine Leseabfragen (SELECT) beschränkt. Schreibende, ändernde oder löschende Operationen sind auf Systemebene blockiert.<\/li><\/ul>\n<h3>6.5 Cross-Origin Resource Sharing (CORS)<\/h3>\n<p>Nur definierte und verifizierte Quelldomains erhalten Zugriff auf die Plattform-API. Anfragen von nicht autorisierten Quellen werden automatisch abgelehnt.<\/p>\n<hr>\n<h2>7. KI-Dienste und Datenverarbeitung<\/h2>\n<p>Transparenz im Umgang mit KI-Diensten ist für datenschutzbewusste Organisationen entscheidend. PowerOn legt offen, wie Daten im Kontext der KI-Nutzung verarbeitet werden.<\/p>\n<h3>7.1 Welche Daten werden verarbeitet<\/h3>\n<p>Im Rahmen der KI-gestützten Funktionen (KI-Assistent, Workflow-Verarbeitung, Dokumentenanalyse) können folgende Daten an KI-Dienste übermittelt werden:<\/p>\n<ul><li>Nutzeranfragen und -eingaben<\/li><li>Dokumentinhalte (bei Dokumentenanalyse)<\/li><li>Gesprächsverläufe (bei Chat-Funktionen)<\/li><\/ul>\n<h3>7.2 Welche KI-Anbieter werden genutzt<\/h3>\n<p>PowerOn unterstützt mehrere KI-Anbieter, die je nach Bedarf und Konfiguration eingesetzt werden:<\/p>\n<ul><li><strong>OpenAI<\/strong> (GPT-4o und weitere Modelle)<\/li><li><strong>Anthropic<\/strong> (Claude-Modelle)<\/li><li><strong>Tavily<\/strong> (Websuche)<\/li><li><strong>Private LLM<\/strong> (lokale/eigene Modelle -- kein externer Datenabfluss)<\/li><\/ul>\n<p>Die Auswahl des Anbieters ist konfigurierbar und kann an die Datenschutzanforderungen des Kunden angepasst werden.<\/p>\n<h3>7.3 Mandantentrennung bei KI-Anfragen<\/h3>\n<p>Jede KI-Anfrage erfolgt im Kontext des jeweiligen Mandanten. Es findet keine Vermischung von Daten verschiedener Mandanten in KI-Anfragen statt.<\/p>\n<h3>7.4 Kein Training mit Kundendaten<\/h3>\n<p>Bei Nutzung der Enterprise-API-Vereinbarungen der KI-Anbieter (OpenAI Enterprise API, Anthropic API) werden Kundendaten nicht für das Training der KI-Modelle verwendet. Dies ist vertraglich durch die Auftragsverarbeitungsvereinbarungen (AV-V / DPA) mit den jeweiligen Anbietern abgesichert.<\/p>\n<h3>7.5 Optionen für höchste Datenschutzanforderungen<\/h3>\n<p>Für Organisationen mit besonders hohen Datenschutzanforderungen bietet PowerOn:<\/p>\n<ul><li><strong>Datenschutz-Neutralisierer:<\/strong> Optionales Modul, das personenbezogene Daten vor der Übermittlung an externe KI-Dienste entfernt oder pseudonymisiert.<\/li><li><strong>Private-LLM-Anbindung:<\/strong> Möglichkeit, ein eigenes, lokal betriebenes Sprachmodell zu nutzen. In diesem Fall verlassen keine Daten die eigene Infrastruktur.<\/li><\/ul>\n<h3>7.6 Bekannte Einschränkung<\/h3>\n<p>Die automatische Erkennung und Filterung personenbezogener Daten (PII) vor dem Versand an externe KI-Dienste ist <strong>nicht standardmässig aktiviert<\/strong>. Organisationen, die mit besonders sensiblen personenbezogenen Daten arbeiten, sollten den Datenschutz-Neutralisierer nutzen oder den Private-LLM-Connector einsetzen.<\/p>\n<hr>\n<h2>8. Audit-Trail und Nachvollziehbarkeit<\/h2>\n<h3>8.1 Was wird protokolliert<\/h3>\n<p>Sämtliche sicherheitsrelevanten Aktionen werden automatisch und lückenlos in einem Audit-Log erfasst:<\/p>\n<table><thead><tr><th>Kategorie<\/th><th>Beispiele<\/th><\/tr><\/thead><tbody><tr><td>Zugriff<\/td><td>Anmeldungen, fehlgeschlagene Anmeldeversuche, Abmeldungen<\/td><\/tr><tr><td>Sicherheit<\/td><td>Administratoraktionen, SysAdmin-Zugriffe, Sicherheitsereignisse<\/td><\/tr><tr><td>Datenschutz (DSGVO)<\/td><td>Datenexporte, Kontolöschungen, Portabilitätsanfragen<\/td><\/tr><tr><td>Berechtigungen<\/td><td>Rollenzuweisungen, Berechtigungsänderungen<\/td><\/tr><tr><td>Verschlüsselung<\/td><td>Zugriffe auf Verschlüsselungsfunktionen<\/td><\/tr><tr><td>Datenoperationen<\/td><td>Zugriffe auf sensible Geschäftsdaten<\/td><\/tr><\/tbody><\/table>\n<h3>8.2 Aufbewahrung und Bereinigung<\/h3>\n<ul><li><strong>Standard-Aufbewahrungsdauer:<\/strong> 365 Tage (konfigurierbar)<\/li><li><strong>Automatische Bereinigung:<\/strong> Veraltete Einträge werden durch einen täglichen Prozess entfernt -- dies stellt sicher, dass Audit-Daten nicht unbefristet aufbewahrt werden (DSGVO-Konformität).<\/li><li><strong>Anonymisierung:<\/strong> Bei der Löschung eines Nutzerkontos werden zugehörige Audit-Einträge anonymisiert statt gelöscht. Die Nachvollziehbarkeit sicherheitsrelevanter Ereignisse bleibt gewahrt, ohne dass Rückschlüsse auf die gelöschte Person möglich sind.<\/li><\/ul>\n<h3>8.3 Nutzung für Compliance-Nachweise<\/h3>\n<p>Die Audit-Daten können als Nachweis für interne und externe Audits herangezogen werden. Sie dokumentieren, wer wann welche sicherheitsrelevante Aktion durchgeführt hat, und unterstützen damit die Anforderungen an die Rechenschaftspflicht nach Art. 5 Abs. 2 DSGVO.<\/p>\n<hr>\n<h2>9. Einordnung in gängige Standards<\/h2>\n<p>PowerOn orientiert sich an anerkannten Standards und Rahmenwerken. Die folgende Einordnung beschreibt transparent, welche Anforderungen die Plattform bereits abdeckt und wo Ergänzungen erforderlich sind.<\/p>\n<h3>9.1 DSGVO / GDPR<\/h3>\n<table><thead><tr><th>Anforderung<\/th><th>Status<\/th><th>Bemerkung<\/th><\/tr><\/thead><tbody><tr><td>Betroffenenrechte (Art. 15--17, 20)<\/td><td>Implementiert<\/td><td>Auskunft, Löschung, Portabilität, Berichtigung als Self-Service<\/td><\/tr><tr><td>Rechenschaftspflicht (Art. 5 Abs. 2)<\/td><td>Implementiert<\/td><td>Lückenloser Audit-Trail<\/td><\/tr><tr><td>Verzeichnis der Verarbeitungstätigkeiten (Art. 30)<\/td><td>Unterstützt<\/td><td>Audit-Log liefert die Datenbasis; das formale Verzeichnis muss vom Betreiber geführt werden<\/td><\/tr><tr><td>Technische und organisatorische Massnahmen (Art. 32)<\/td><td>Implementiert<\/td><td>Verschlüsselung, Zugriffskontrolle, Mandantentrennung, Eingabevalidierung<\/td><\/tr><tr><td>Einwilligungsmanagement (Art. 7)<\/td><td>Teilweise<\/td><td>Über Nutzungsbedingungen und OAuth; kein granulares Consent-Tool<\/td><\/tr><\/tbody><\/table>\n<h3>9.2 Schweizer Datenschutzgesetz (nDSG / revDSG)<\/h3>\n<p>Die Anforderungen des revidierten Schweizer Datenschutzgesetzes sind mit den DSGVO-Massnahmen kompatibel. Insbesondere:<\/p>\n<ul><li>Informationspflicht bei Datenerhebung: Transparenzfunktion implementiert<\/li><li>Recht auf Datenherausgabe und -löschung: Self-Service-Funktionen vorhanden<\/li><li>Pflicht zu angemessenen technischen Massnahmen: Verschlüsselung, RBAC, Mandantentrennung<\/li><\/ul>\n<h3>9.3 OWASP Top 10<\/h3>\n<p>Die Plattform adressiert die häufigsten Web-Sicherheitsrisiken gemäss OWASP:<\/p>\n<table><thead><tr><th>OWASP-Risiko<\/th><th>Massnahme in PowerOn<\/th><\/tr><\/thead><tbody><tr><td>Broken Access Control<\/td><td>Rollenbasierte Zugriffskontrolle, Mandantenprüfung bei jedem Zugriff<\/td><\/tr><tr><td>Cryptographic Failures<\/td><td>AES-Verschlüsselung, PBKDF2-Schlüsselableitung, HTTPS/TLS<\/td><\/tr><tr><td>Injection<\/td><td>Parametrisierte Datenbankabfragen, Eingabebereinigung, SQL-Leseeinschränkung<\/td><\/tr><tr><td>Security Misconfiguration<\/td><td>CORS-Einschränkungen, Rate Limiting, CSRF-Schutz<\/td><\/tr><tr><td>Identification and Authentication Failures<\/td><td>JWT-basierte Authentifizierung, Token-Widerruf, Ratenbegrenzung bei Anmeldung<\/td><\/tr><\/tbody><\/table>\n<p>Es besteht <strong>keine formale OWASP-Zertifizierung<\/strong>. Die Massnahmen basieren auf den OWASP-Empfehlungen und sind als präventive Sicherheitsmassnahmen implementiert.<\/p>\n<h3>9.4 ISO 27001 / BSI IT-Grundschutz<\/h3>\n<p>Die implementierten technischen und organisatorischen Massnahmen (Zugriffskontrolle, Verschlüsselung, Audit-Logging, Eingabevalidierung, Mandantentrennung) bilden eine <strong>solide Grundlage<\/strong> für ein Informationssicherheits-Managementsystem (ISMS) nach ISO 27001 oder BSI IT-Grundschutz.<\/p>\n<p>Es besteht <strong>keine formale Zertifizierung<\/strong>. Die vorhandene Infrastruktur ermöglicht es jedoch, eine Zertifizierung auf dieser Basis gezielt anzustreben.<\/p>\n<hr>\n<h2>10. Authentifizierung und Identitätsmanagement<\/h2>\n<h3>10.1 Anmeldemethoden<\/h3>\n<p>PowerOn unterstützt mehrere Authentifizierungsverfahren:<\/p>\n<ul><li><strong>Lokale Anmeldung:<\/strong> Benutzername und Passwort mit JWT-basierter Sitzungsverwaltung<\/li><li><strong>Microsoft-Anmeldung (Azure AD / Entra ID):<\/strong> Single Sign-On über bestehende Microsoft-Konten<\/li><li><strong>Google-Anmeldung:<\/strong> Single Sign-On über Google Workspace<\/li><\/ul>\n<h3>10.2 Sitzungssicherheit<\/h3>\n<ul><li>Authentifizierungstoken werden in sicheren, HTTP-only Cookies gespeichert (nicht im Browser-Speicher zugänglich)<\/li><li>Tokens haben eine konfigurierbare Gültigkeitsdauer<\/li><li>Token-Widerruf ist jederzeit möglich (z.B. bei Verdacht auf Kompromittierung)<\/li><li>Bei lokaler Anmeldung wird die Gültigkeit des Tokens zusätzlich gegen die Datenbank geprüft<\/li><\/ul>\n<h3>10.3 Automatische Token-Erneuerung<\/h3>\n<p>Authentifizierungstoken werden automatisch erneuert, bevor sie ablaufen. Dies gewährleistet eine unterbrechungsfreie Nutzung bei gleichzeitiger Begrenzung der Token-Gültigkeitsdauer.<\/p>\n<hr>\n<h2>11. Offene Punkte und Empfehlungen<\/h2>\n<p>Transparenz schafft Vertrauen. Die folgenden Punkte sind offen benannt, damit Kunden und Betreiber informierte Entscheidungen treffen können.<\/p>\n<table><thead><tr><th>Thema<\/th><th>Status<\/th><th>Empfehlung<\/th><\/tr><\/thead><tbody><tr><td>Granulares Consent-Management<\/td><td>Nicht vorhanden<\/td><td>Falls regulatorisch erforderlich, als separates Modul ergänzen<\/td><\/tr><tr><td>PII-Filterung vor KI-Versand<\/td><td>Nicht standardmässig aktiv<\/td><td>Datenschutz-Neutralisierer aktivieren oder Private LLM einsetzen<\/td><\/tr><tr><td>Security-Header (CSP, HSTS)<\/td><td>Auf Infrastruktur-Ebene<\/td><td>Konfiguration auf Reverse-Proxy-Ebene dokumentieren und prüfen<\/td><\/tr><tr><td>Datenschutz-Kontaktadresse<\/td><td>Platzhalter<\/td><td>Pro Deployment mit tatsächlicher DSB-Kontaktadresse konfigurieren<\/td><\/tr><tr><td>Formale Zertifizierungen<\/td><td>Keine vorhanden<\/td><td>ISO 27001 / BSI auf Basis der vorhandenen Massnahmen anstrebbar<\/td><\/tr><\/tbody><\/table>\n<hr>\n<h2>12. Zusammenfassung<\/h2>\n<p>PowerOn vereint Enterprise-KI-Funktionalität mit einem umfassenden Sicherheits- und Datenschutzkonzept. Die Plattform bietet:<\/p>\n<ul><li><strong>DSGVO-konforme Betroffenenrechte<\/strong> als Self-Service-Funktionen<\/li><li><strong>Vollständige Mandantentrennung<\/strong> mit serverseitiger Zugehörigkeitsprüfung<\/li><li><strong>Feingliedriges Berechtigungssystem<\/strong> mit individuell konfigurierbaren Rollen<\/li><li><strong>Verschlüsselung nach Industriestandard<\/strong> für ruhende und übertragene Daten<\/li><li><strong>Lückenlosen Audit-Trail<\/strong> für Compliance-Nachweise<\/li><li><strong>Transparente KI-Datenverarbeitung<\/strong> mit Optionen für höchste Datenschutzanforderungen<\/li><\/ul>\n<p>Gleichzeitig werden bestehende Einschränkungen offen kommuniziert und Empfehlungen für ergänzende Massnahmen gegeben. Diese Kombination aus implementierter Sicherheit und transparenter Kommunikation bildet die Grundlage für eine vertrauensvolle Zusammenarbeit.<\/p>\n<hr>\n<p><em>Dieses Dokument basiert auf einer Analyse der PowerOn-Plattform (Stand Februar 2026). Alle beschriebenen Massnahmen sind in der Plattform implementiert und wurden anhand der Codebasis verifiziert. Angaben ohne Gewähr -- für verbindliche Zusicherungen gelten die jeweiligen Vertragsvereinbarungen.<\/em><\/p>", "text": "# poweron plattform -- sicherheit und compliance **stand:** februar 2026 **zielgruppe:** entscheidungsträger, einkauf, rechtsabteilung, datenschutzbeauftragte **klassifizierung:** kundeninformation --- ## 1. management summary poweron ist eine **multi-mandanten-ki-plattform für unternehmen**, die es organisationen ermöglicht, ki-gestützte geschäftsprozesse sicher, datenschutzkonform und mandantengetrennt zu betreiben. die plattform richtet sich an mittlere bis grosse unternehmen in datenschutzsensiblen branchen wie finanzwesen, treuhand, immobilien und beratung. dieses dokument beschreibt die in poweron implementierten sicherheits- und datenschutzmassnahmen, ordnet diese gängigen standards zu und benennt transparent bestehende einschränkungen. **kernaussagen:** - **dsgvo-betroffenenrechte** (auskunft, löschung, datenübertragbarkeit, berichtigung) sind als self-service-funktionen direkt in der plattform implementiert. - **vollständige mandantentrennung:** daten eines mandanten sind unter keinen umständen für andere mandanten einsehbar oder zugänglich. - **rollenbasierte zugriffskontrolle (rbac):** jeder datenzugriff wird gegen ein mehrstufiges berechtigungssystem geprüft -- konfigurierbar pro mandant und funktionsmodul. - **verschlüsselung:** sensible konfigurationsdaten sind nach industriestandard verschlüsselt, sämtliche kommunikation erfolgt über verschlüsselte verbindungen. - **audit-trail:** alle sicherheitsrelevanten aktionen werden lückenlos protokolliert und stehen für compliance-nachweise zur verfügung. - **transparenz bei ki-nutzung:** die plattform dokumentiert offen, welche daten an ki-dienste übermittelt werden, und bietet konfigurationsoptionen für höchste datenschutzanforderungen. --- ## 2. dsgvo-konformität poweron implementiert die zentralen betroffenenrechte der datenschutz-grundverordnung (dsgvo/gdpr) direkt als plattformfunktionen. im folgenden wird für jeden relevanten artikel beschrieben, was implementiert ist und wo einschränkungen bestehen. ### 2.1 auskunftsrecht (art. 15 dsgvo) nutzer können über eine self-service-funktion sämtliche über sie gespeicherten daten exportieren: - persönliche profildaten (name, e-mail, spracheinstellungen) - mandatszugehörigkeiten und zugewiesene rollen - zugriffsrechte auf funktionsmodule - erstellte und eingelöste einladungen - zeitpunkte der kontörstellung und letzten anmeldung der export umfasst alle auf plattformebene gespeicherten daten. feature-spezifische daten (z.b. chat-verläufe, treuhandpositionen) können über die jeweiligen funktionsmodule eingesehen werden. **status: implementiert.** ### 2.2 recht auf löschung (art. 17 dsgvo) nutzer können ihr konto und alle zugehörigen daten eigenständig und unwiderruflich löschen. dabei gilt: - das system durchsucht automatisch alle datenbanken (plattform, verwaltung, chat, alle funktionsmodule) nach einträgen, die dem nutzer zugeordnet sind. - nutzerbezogene daten werden vollständig gelöscht. - audit-logs werden anonymisiert statt gelöscht -- dies gewährleistet die einhaltung gesetzlicher aufbewahrungspflichten bei gleichzeitiger wahrung der betroffenenrechte. - die löschung erfordert eine explizite bestätigung durch den nutzer. - systemadministratoren sind von der selbstlöschung ausgenommen (vier-augen-prinzip). **status: implementiert.** ### 2.3 recht auf datenübertragbarkeit (art. 20 dsgvo) nutzerdaten können in einem maschinenlesbaren, standardisierten format (json-ld nach schema.org) exportiert werden. dieses format ermöglicht die übertragung der daten an einen anderen dienstleister. **status: implementiert.** ### 2.4 berichtigungsrecht (art. 16 dsgvo) nutzer können ihre profildaten (name, e-mail, spracheinstellungen) jederzeit selbst korrigieren. **status: implementiert.** ### 2.5 transparenz und informationspflicht die plattform stellt nutzern aktiv informationen über die datenverarbeitung bereit: - welche daten erhoben werden - zu welchem zweck die verarbeitung erfolgt - auf welcher rechtsgrundlage die verarbeitung basiert - welche aufbewahrungsfristen gelten - welche betroffenenrechte bestehen und wie sie ausgeübt werden können **status: implementiert.** ### 2.6 bekannte einschränkungen die folgenden punkte sind transparent zu benennen: - **consent-management:** die plattform verfügt derzeit über kein granulares einwilligungsmanagement mit individuellen zustimmungs-toggles. die einwilligung zur datenverarbeitung erfolgt über die nutzungsbedingungen und, bei drittanbieter-authentifizierung (microsoft, google), über die jeweiligen oauth-einwilligungsflüsse. - **datenschutz-kontaktadresse:** die kontaktadresse für datenschutzanfragen ist pro deployment konfigurierbar und muss vom jeweiligen betreiber hinterlegt werden. --- ## 3. mandantenmodell und datenisolation ### 3.1 grundprinzip poweron ist als multi-mandanten-plattform konzipiert. jede organisation, abteilung oder jeder kunde wird als eigenständiger **mandant** abgebildet. das zentrale sicherheitsversprechen: > **daten eines mandanten sind unter keinen umständen für nutzer anderer mandanten sichtbar oder zugänglich.** ### 3.2 wie die trennung funktioniert - **zugehörigkeitsprüfung bei jedem zugriff:** bevor ein nutzer auf mandantendaten zugreifen kann, prüft die plattform, ob eine aktive mitgliedschaft des nutzers in diesem mandanten besteht. ohne nachgewiesene mitgliedschaft wird der zugriff verweigert. - **kein mandantenübergreifender datenfluss:** datenbankabfragen werden automatisch auf den mandantenkontext gefiltert. es gibt keinen mechanismus, der daten mandantenübergreifend zusammenführt oder exponiert. - **feature-isolation:** innerhalb eines mandanten werden funktionsmodule (z.b. commcoach, treuhand, immobilien) zusätzlich isoliert. nutzer benötigen für jedes funktionsmodul eine explizite zugriffsberechtigung. ### 3.3 mehrfachmandanten nutzer können gleichzeitig in mehreren mandanten arbeiten -- ein häufiges szenario bei beratern, treuhändern oder dienstleistern mit mehreren kunden. die plattform stellt sicher: - der mandantenkontext wird pro anfrage bestimmt, nicht pro sitzung. ein wechsel zwischen mandanten ist jederzeit möglich, ohne dass daten vermischt werden. - es findet keine übertragung von daten, berechtigungen oder einstellungen zwischen mandanten statt. ### 3.4 schutz vor manipulation auch bei technischem wissen über die plattformarchitektur ist ein unbefugter zugriff auf fremde mandantendaten nicht möglich: die zugehörigkeitsprüfung erfolgt serverseitig und kann nicht durch manipulation von anfrageparametern umgangen werden. --- ## 4. rollenbasierte zugriffskontrolle (rbac) ### 4.1 berechtigungsmodell poweron verfügt über ein feingliedriges, rollenbasiertes berechtigungssystem. für jede aktion (lesen, erstellen, bearbeiten, löschen) können individuelle berechtigungsstufen vergeben werden: | berechtigungsstufe | beschreibung | |---|---| | kein zugriff | funktion ist nicht verfügbar | | eigene daten | zugriff nur auf selbst erstellte einträge | | mandantendaten | zugriff auf alle daten innerhalb des eigenen mandanten | | alle daten | vollzugriff (typischerweise für administratoren) | ### 4.2 konfigurierbarkeit - rollen können **pro mandant** und **pro funktionsmodul** definiert und zugewiesen werden. - es gibt keine fest verdrahteten berechtigungen -- jede organisation kann das rollenmodell an ihre bedürfnisse anpassen. - berechtigungsänderungen werden im audit-trail protokolliert. ### 4.3 administratoren systemadministratoren verfügen über erweiterte rechte, unterliegen jedoch ebenfalls dem rbac-system. alle administratoraktionen werden gesondert im audit-log festgehalten. es gibt kein unkontrolliertes \"superuser\"-konto ohne nachvollziehbarkeit. --- ## 5. verschlüsselung und datensicherheit ### 5.1 verschlüsselung ruhender daten alle sensiblen konfigurationsdaten werden verschlüsselt gespeichert: - **verschlüsselungsverfahren:** aes-verschlüsselung (fernet) - **schlüsselableitung:** pbkdf2-hmac-sha256 nach aktuellem industriestandard - **umfang:** datenbankpasswörter, api-schlüssel für ki-dienste, oauth-geheimnisse, jwt-schlüssel und alle weiteren als \"secret\" gekennzeichneten konfigurationswerte sensible konfigurationsdaten liegen zu keinem zeitpunkt im klartext in der konfiguration oder im quellcode vor. ### 5.2 verschlüsselung in übertragung - sämtliche kommunikation zwischen client und server erfolgt über https/tls. - verbindungen zu drittdiensten (ki-anbieter, authentifizierungsdienste, e-mail-dienste) nutzen ebenfalls ausschliesslich verschlüsselte verbindungen. - die tls-konfiguration erfolgt auf infrastruktur-ebene (azure / reverse proxy) -- dies entspricht dem branchenstandard bei cloud-deployments und ermöglicht zentrale verwaltung und aktualisierung der zertifikate. ### 5.3 zugriffskontrolle auf verschlüsselungsschlüssel - der zugriff auf verschlüsselungsschlüssel ist auf das minimum beschränkt. - jeder zugriff auf verschlüsselungsfunktionen (entschlüsselung, neuverschlüsselung) wird im audit-trail protokolliert. - eine ratenbegrenzung schützt vor automatisierten entschlüsselungsversuchen. --- ## 6. schutzmassnahmen gegen angriffe poweron implementiert schutzmassnahmen gegen die gängigsten angriffsvektoren für webanwendungen: ### 6.1 cross-site request forgery (csrf) alle datenverändernden operationen (post, put, delete, patch) erfordern einen `x-csrf-token` header. die aktuelle implementierung validiert das tokenformat (16-64 zeichen hex-string); es gibt kein serverseitiges session-binding (kein klassisches double-submit oder synchronizer token). in kombination mit `samesite=strict` cookies und cors bietet dies basisschutz gegen csrf. ### 6.2 ratenbegrenzung (rate limiting) jede api-funktion ist mit individuellen zugriffslimits versehen, die automatisierte angriffe und missbrauch unterbinden: | funktion | limit | |---|---| | anmeldung | 30 versuche pro minute | | datenexport (dsgvo) | 5 anfragen pro minute | | kontolöschung | 1 anfrage pro stunde | | ki-anfragen | 120 anfragen pro minute | | datei-upload | 10 uploads pro minute | ### 6.3 eingabebereinigung nutzereingaben werden bereinigt und validiert, bevor sie an ki-modelle oder datenbanken weitergeleitet werden. dies schützt vor prompt-injection-angriffen und anderen manipulationsversuchen. ### 6.4 sql-injection-schutz - alle datenbankabfragen der plattform verwenden parametrisierte abfragen -- der industriestandard zur vermeidung von sql-injection. - der ki-gestützte datenbankzugriff ist zusätzlich auf reine leseabfragen (select) beschränkt. schreibende, ändernde oder löschende operationen sind auf systemebene blockiert. ### 6.5 cross-origin resource sharing (cors) nur definierte und verifizierte quelldomains erhalten zugriff auf die plattform-api. anfragen von nicht autorisierten quellen werden automatisch abgelehnt. --- ## 7. ki-dienste und datenverarbeitung transparenz im umgang mit ki-diensten ist für datenschutzbewusste organisationen entscheidend. poweron legt offen, wie daten im kontext der ki-nutzung verarbeitet werden. ### 7.1 welche daten werden verarbeitet im rahmen der ki-gestützten funktionen (ki-assistent, workflow-verarbeitung, dokumentenanalyse) können folgende daten an ki-dienste übermittelt werden: - nutzeranfragen und -eingaben - dokumentinhalte (bei dokumentenanalyse) - gesprächsverläufe (bei chat-funktionen) ### 7.2 welche ki-anbieter werden genutzt poweron unterstützt mehrere ki-anbieter, die je nach bedarf und konfiguration eingesetzt werden: - **openai** (gpt-4o und weitere modelle) - **anthropic** (claude-modelle) - **tavily** (websuche) - **private llm** (lokale/eigene modelle -- kein externer datenabfluss) die auswahl des anbieters ist konfigurierbar und kann an die datenschutzanforderungen des kunden angepasst werden. ### 7.3 mandantentrennung bei ki-anfragen jede ki-anfrage erfolgt im kontext des jeweiligen mandanten. es findet keine vermischung von daten verschiedener mandanten in ki-anfragen statt. ### 7.4 kein training mit kundendaten bei nutzung der enterprise-api-vereinbarungen der ki-anbieter (openai enterprise api, anthropic api) werden kundendaten nicht für das training der ki-modelle verwendet. dies ist vertraglich durch die auftragsverarbeitungsvereinbarungen (av-v / dpa) mit den jeweiligen anbietern abgesichert. ### 7.5 optionen für höchste datenschutzanforderungen für organisationen mit besonders hohen datenschutzanforderungen bietet poweron: - **datenschutz-neutralisierer:** optionales modul, das personenbezogene daten vor der übermittlung an externe ki-dienste entfernt oder pseudonymisiert. - **private-llm-anbindung:** möglichkeit, ein eigenes, lokal betriebenes sprachmodell zu nutzen. in diesem fall verlassen keine daten die eigene infrastruktur. ### 7.6 bekannte einschränkung die automatische erkennung und filterung personenbezogener daten (pii) vor dem versand an externe ki-dienste ist **nicht standardmässig aktiviert**. organisationen, die mit besonders sensiblen personenbezogenen daten arbeiten, sollten den datenschutz-neutralisierer nutzen oder den private-llm-connector einsetzen. --- ## 8. audit-trail und nachvollziehbarkeit ### 8.1 was wird protokolliert sämtliche sicherheitsrelevanten aktionen werden automatisch und lückenlos in einem audit-log erfasst: | kategorie | beispiele | |---|---| | zugriff | anmeldungen, fehlgeschlagene anmeldeversuche, abmeldungen | | sicherheit | administratoraktionen, sysadmin-zugriffe, sicherheitsereignisse | | datenschutz (dsgvo) | datenexporte, kontolöschungen, portabilitätsanfragen | | berechtigungen | rollenzuweisungen, berechtigungsänderungen | | verschlüsselung | zugriffe auf verschlüsselungsfunktionen | | datenoperationen | zugriffe auf sensible geschäftsdaten | ### 8.2 aufbewahrung und bereinigung - **standard-aufbewahrungsdauer:** 365 tage (konfigurierbar) - **automatische bereinigung:** veraltete einträge werden durch einen täglichen prozess entfernt -- dies stellt sicher, dass audit-daten nicht unbefristet aufbewahrt werden (dsgvo-konformität). - **anonymisierung:** bei der löschung eines nutzerkontos werden zugehörige audit-einträge anonymisiert statt gelöscht. die nachvollziehbarkeit sicherheitsrelevanter ereignisse bleibt gewahrt, ohne dass rückschlüsse auf die gelöschte person möglich sind. ### 8.3 nutzung für compliance-nachweise die audit-daten können als nachweis für interne und externe audits herangezogen werden. sie dokumentieren, wer wann welche sicherheitsrelevante aktion durchgeführt hat, und unterstützen damit die anforderungen an die rechenschaftspflicht nach art. 5 abs. 2 dsgvo. --- ## 9. einordnung in gängige standards poweron orientiert sich an anerkannten standards und rahmenwerken. die folgende einordnung beschreibt transparent, welche anforderungen die plattform bereits abdeckt und wo ergänzungen erforderlich sind. ### 9.1 dsgvo / gdpr | anforderung | status | bemerkung | |---|---|---| | betroffenenrechte (art. 15--17, 20) | implementiert | auskunft, löschung, portabilität, berichtigung als self-service | | rechenschaftspflicht (art. 5 abs. 2) | implementiert | lückenloser audit-trail | | verzeichnis der verarbeitungstätigkeiten (art. 30) | unterstützt | audit-log liefert die datenbasis; das formale verzeichnis muss vom betreiber geführt werden | | technische und organisatorische massnahmen (art. 32) | implementiert | verschlüsselung, zugriffskontrolle, mandantentrennung, eingabevalidierung | | einwilligungsmanagement (art. 7) | teilweise | über nutzungsbedingungen und oauth; kein granulares consent-tool | ### 9.2 schweizer datenschutzgesetz (ndsg / revdsg) die anforderungen des revidierten schweizer datenschutzgesetzes sind mit den dsgvo-massnahmen kompatibel. insbesondere: - informationspflicht bei datenerhebung: transparenzfunktion implementiert - recht auf datenherausgabe und -löschung: self-service-funktionen vorhanden - pflicht zu angemessenen technischen massnahmen: verschlüsselung, rbac, mandantentrennung ### 9.3 owasp top 10 die plattform adressiert die häufigsten web-sicherheitsrisiken gemäss owasp: | owasp-risiko | massnahme in poweron | |---|---| | broken access control | rollenbasierte zugriffskontrolle, mandantenprüfung bei jedem zugriff | | cryptographic failures | aes-verschlüsselung, pbkdf2-schlüsselableitung, https/tls | | injection | parametrisierte datenbankabfragen, eingabebereinigung, sql-leseeinschränkung | | security misconfiguration | cors-einschränkungen, rate limiting, csrf-schutz | | identification and authentication failures | jwt-basierte authentifizierung, token-widerruf, ratenbegrenzung bei anmeldung | es besteht **keine formale owasp-zertifizierung**. die massnahmen basieren auf den owasp-empfehlungen und sind als präventive sicherheitsmassnahmen implementiert. ### 9.4 iso 27001 / bsi it-grundschutz die implementierten technischen und organisatorischen massnahmen (zugriffskontrolle, verschlüsselung, audit-logging, eingabevalidierung, mandantentrennung) bilden eine **solide grundlage** für ein informationssicherheits-managementsystem (isms) nach iso 27001 oder bsi it-grundschutz. es besteht **keine formale zertifizierung**. die vorhandene infrastruktur ermöglicht es jedoch, eine zertifizierung auf dieser basis gezielt anzustreben. --- ## 10. authentifizierung und identitätsmanagement ### 10.1 anmeldemethoden poweron unterstützt mehrere authentifizierungsverfahren: - **lokale anmeldung:** benutzername und passwort mit jwt-basierter sitzungsverwaltung - **microsoft-anmeldung (azure ad / entra id):** single sign-on über bestehende microsoft-konten - **google-anmeldung:** single sign-on über google workspace ### 10.2 sitzungssicherheit - authentifizierungstoken werden in sicheren, http-only cookies gespeichert (nicht im browser-speicher zugänglich) - tokens haben eine konfigurierbare gültigkeitsdauer - token-widerruf ist jederzeit möglich (z.b. bei verdacht auf kompromittierung) - bei lokaler anmeldung wird die gültigkeit des tokens zusätzlich gegen die datenbank geprüft ### 10.3 automatische token-erneuerung authentifizierungstoken werden automatisch erneuert, bevor sie ablaufen. dies gewährleistet eine unterbrechungsfreie nutzung bei gleichzeitiger begrenzung der token-gültigkeitsdauer. --- ## 11. offene punkte und empfehlungen transparenz schafft vertrauen. die folgenden punkte sind offen benannt, damit kunden und betreiber informierte entscheidungen treffen können. | thema | status | empfehlung | |---|---|---| | granulares consent-management | nicht vorhanden | falls regulatorisch erforderlich, als separates modul ergänzen | | pii-filterung vor ki-versand | nicht standardmässig aktiv | datenschutz-neutralisierer aktivieren oder private llm einsetzen | | security-header (csp, hsts) | auf infrastruktur-ebene | konfiguration auf reverse-proxy-ebene dokumentieren und prüfen | | datenschutz-kontaktadresse | platzhalter | pro deployment mit tatsächlicher dsb-kontaktadresse konfigurieren | | formale zertifizierungen | keine vorhanden | iso 27001 / bsi auf basis der vorhandenen massnahmen anstrebbar | --- ## 12. zusammenfassung poweron vereint enterprise-ki-funktionalität mit einem umfassenden sicherheits- und datenschutzkonzept. die plattform bietet: - **dsgvo-konforme betroffenenrechte** als self-service-funktionen - **vollständige mandantentrennung** mit serverseitiger zugehörigkeitsprüfung - **feingliedriges berechtigungssystem** mit individuell konfigurierbaren rollen - **verschlüsselung nach industriestandard** für ruhende und übertragene daten - **lückenlosen audit-trail** für compliance-nachweise - **transparente ki-datenverarbeitung** mit optionen für höchste datenschutzanforderungen gleichzeitig werden bestehende einschränkungen offen kommuniziert und empfehlungen für ergänzende massnahmen gegeben. diese kombination aus implementierter sicherheit und transparenter kommunikation bildet die grundlage für eine vertrauensvolle zusammenarbeit. --- *dieses dokument basiert auf einer analyse der poweron-plattform (stand februar 2026). alle beschriebenen massnahmen sind in der plattform implementiert und wurden anhand der codebasis verifiziert. angaben ohne gewähr -- für verbindliche zusicherungen gelten die jeweiligen vertragsvereinbarungen.* ", "nextReview": "", "overdueReview": false, "zuPruefen": []}, {"id": "06_bewertung/internes-audit.md", "path": "06_bewertung/internes-audit.md", "chapter": "06_bewertung", "title": "Internes Audit", "filename": "internes-audit.md", "meta": {"docId": "IMS-09-01", "status": "entwurf", "version": "0.1", "owner": "Patrick Motsch", "approver": "Geschäftsführung PowerOn AG", "approvedDate": "", "nextReview": "2027-06-03", "classification": "intern", "isoRefs": "9001:9.2; 27001:9.2"}, "html": "<h1>Internes Audit<\/h1>\n<p><strong>Dokumenttyp:<\/strong> Verfahren (Pflicht ISO 9001/27001 Kap. 9.2)<\/p>\n<h2>1. Zweck<\/h2>\n<p>Das interne Audit prüft regelmässig, ob das IMS den Normanforderungen (ISO 9001, ISO 27001) und den eigenen Vorgaben entspricht und wirksam umgesetzt ist.<\/p>\n<h2>2. Unabhängigkeit<\/h2>\n<p>Auditoren dürfen ihre eigene Arbeit nicht prüfen. Aufgrund der Teamgrösse wird das interne Audit <strong>an eine externe, unabhängige Person/Stelle vergeben<\/strong>. Die Auswahl wird dokumentiert.<\/p>\n<h2>3. Auditprogramm<\/h2>\n<table><thead><tr><th>Element<\/th><th>Vorgabe<\/th><\/tr><\/thead><tbody><tr><td>Turnus<\/td><td>Mindestens 1x jährlich, gesamtes IMS über max. 1 Zyklus<\/td><\/tr><tr><td>Umfang<\/td><td>Kap. 4-10 beider Normen + Annex-A-Controls (risikoorientiert priorisiert)<\/td><\/tr><tr><td>Erstes Audit<\/td><td>2026 Q3 (Voraussetzung für Audit-Reife)<\/td><\/tr><tr><td>Kriterien<\/td><td>Normtext, IMS-Dokumente, SoA, gesetzliche/vertragliche Anforderungen<\/td><\/tr><\/tbody><\/table>\n<h2>4. Ablauf<\/h2>\n<pre class=\"mermaid\">flowchart LR\n    plan[\"Auditplan (Umfang, Termin, Kriterien)\"] --&gt; exec[\"Durchführung (Interviews, Nachweise, Stichproben)\"]\n    exec --&gt; report[\"Auditbericht (Feststellungen, Abweichungen)\"]\n    report --&gt; capa[\"Korrekturmassnahmen ins Massnahmenregister\"]\n    capa --&gt; followup[\"Nachverfolgung &amp; Wirksamkeitsprüfung\"]<\/pre>\n<h2>5. Feststellungsklassen<\/h2>\n<table><thead><tr><th>Klasse<\/th><th>Bedeutung<\/th><th>Folge<\/th><\/tr><\/thead><tbody><tr><td>Hauptabweichung (major)<\/td><td>Norm-/Systemanforderung nicht erfüllt<\/td><td>sofortige Korrekturmassnahme<\/td><\/tr><tr><td>Nebenabweichung (minor)<\/td><td>punktuelle Schwäche<\/td><td>terminierte Korrekturmassnahme<\/td><\/tr><tr><td>Hinweis / Verbesserungspotenzial<\/td><td>Empfehlung<\/td><td>KVP-Prüfung<\/td><\/tr><\/tbody><\/table>\n<h2>6. Nachweise / Records<\/h2>\n<p>Auditplan, Auditbericht und Massnahmen werden als Records abgelegt; Abweichungen werden im <a href=\"../07_verbesserung/massnahmen-register.md\">Massnahmenregister<\/a> (Quelle: Audit) geführt. Ergebnisse sind Input für das <a href=\"management-review.md\">Management-Review<\/a>.<\/p>", "text": "<!-- docid: ims-09-01 --> <!-- status: entwurf --> <!-- version: 0.1 --> <!-- owner: patrick motsch --> <!-- approver: geschäftsführung poweron ag --> <!-- approveddate: --> <!-- nextreview: 2027-06-03 --> <!-- classification: intern --> <!-- isorefs: 9001:9.2; 27001:9.2 --> # internes audit **dokumenttyp:** verfahren (pflicht iso 9001/27001 kap. 9.2) ## 1. zweck das interne audit prüft regelmässig, ob das ims den normanforderungen (iso 9001, iso 27001) und den eigenen vorgaben entspricht und wirksam umgesetzt ist. ## 2. unabhängigkeit auditoren dürfen ihre eigene arbeit nicht prüfen. aufgrund der teamgrösse wird das interne audit **an eine externe, unabhängige person/stelle vergeben**. die auswahl wird dokumentiert. ## 3. auditprogramm | element | vorgabe | |---|---| | turnus | mindestens 1x jährlich, gesamtes ims über max. 1 zyklus | | umfang | kap. 4-10 beider normen + annex-a-controls (risikoorientiert priorisiert) | | erstes audit | 2026 q3 (voraussetzung für audit-reife) | | kriterien | normtext, ims-dokumente, soa, gesetzliche/vertragliche anforderungen | ## 4. ablauf ```mermaid flowchart lr plan[\"auditplan (umfang, termin, kriterien)\"] --> exec[\"durchführung (interviews, nachweise, stichproben)\"] exec --> report[\"auditbericht (feststellungen, abweichungen)\"] report --> capa[\"korrekturmassnahmen ins massnahmenregister\"] capa --> followup[\"nachverfolgung & wirksamkeitsprüfung\"] ``` ## 5. feststellungsklassen | klasse | bedeutung | folge | |---|---|---| | hauptabweichung (major) | norm-/systemanforderung nicht erfüllt | sofortige korrekturmassnahme | | nebenabweichung (minor) | punktuelle schwäche | terminierte korrekturmassnahme | | hinweis / verbesserungspotenzial | empfehlung | kvp-prüfung | ## 6. nachweise / records auditplan, auditbericht und massnahmen werden als records abgelegt; abweichungen werden im [massnahmenregister](../07_verbesserung/massnahmen-register.md) (quelle: audit) geführt. ergebnisse sind input für das [management-review](management-review.md). ", "nextReview": "2027-06-03", "overdueReview": false, "zuPruefen": []}, {"id": "06_bewertung/management-review.md", "path": "06_bewertung/management-review.md", "chapter": "06_bewertung", "title": "Management-Review", "filename": "management-review.md", "meta": {"docId": "IMS-09-02", "status": "entwurf", "version": "0.1", "owner": "Geschäftsführung PowerOn AG", "approver": "Geschäftsführung PowerOn AG", "approvedDate": "", "nextReview": "2027-06-03", "classification": "intern", "isoRefs": "9001:9.3; 27001:9.3"}, "html": "<h1>Management-Review<\/h1>\n<p><strong>Dokumenttyp:<\/strong> Verfahren + Protokollvorlage (Pflicht ISO 9001/27001 Kap. 9.3)<\/p>\n<h2>1. Zweck und Turnus<\/h2>\n<p>Die oberste Leitung bewertet das IMS mindestens <strong>jährlich<\/strong> sowie anlassbezogen auf Eignung, Angemessenheit und Wirksamkeit und entscheidet über Verbesserungen und Ressourcen.<\/p>\n<h2>2. Eingaben (Inputs)<\/h2>\n<ul><li>Status Massnahmen aus vorherigen Reviews<\/li><li>Änderungen interner/externer Themen (<a href=\"../01_kontext/kontext-und-interessierte-parteien.md\">Kontext<\/a>)<\/li><li>Erfüllung der <a href=\"../03_planung/ziele-und-kennzahlen.md\">Ziele &amp; Kennzahlen<\/a><\/li><li>Ergebnisse <a href=\"internes-audit.md\">interner Audits<\/a><\/li><li>Risikolage / <a href=\"../03_planung/risikoregister.md\">Risikoregister<\/a> + SoA-Status<\/li><li>Incidents, Abweichungen, Reklamationen<\/li><li>Rückmeldungen interessierter Parteien (Kunden, Lieferanten)<\/li><li>Stand offener Pendenzen (<a href=\"../07_verbesserung/massnahmen-register.md\">Massnahmenregister<\/a>)<\/li><\/ul>\n<h2>3. Ergebnisse (Outputs)<\/h2>\n<ul><li>Bewertung der IMS-Wirksamkeit<\/li><li>Entscheidungen zu Verbesserungen, Zielen, Ressourcen<\/li><li>neue/aktualisierte Massnahmen mit Owner und Termin<\/li><li>ggf. Anpassung von Politiken, Scope, SoA<\/li><\/ul>\n<h2>4. Protokollvorlage<\/h2>\n<pre class=\"code\"><code># Management-Review-Protokoll\n\nDatum:\nTeilnehmende:\nBerichtsperiode:\n\n## Inputs (Zusammenfassung)\n- Zielerreichung: ...\n- Audit-Ergebnisse: ...\n- Risiken/SoA: ...\n- Incidents/Abweichungen: ...\n- Rückmeldungen: ...\n\n## Bewertung\n- Eignung/Angemessenheit/Wirksamkeit: ...\n\n## Entscheidungen &amp; Massnahmen\n| Massnahme | Owner | Termin |\n|---|---|---|\n| | | |\n\n## Nächstes Review:\nFreigabe (Geschäftsführung):<\/code><\/pre>\n<h2>5. Records<\/h2>\n<p>Jedes Protokoll wird als Record abgelegt. Das erste Management-Review (2026 Q3) ist Voraussetzung für die Audit-Reife.<\/p>", "text": "<!-- docid: ims-09-02 --> <!-- status: entwurf --> <!-- version: 0.1 --> <!-- owner: geschäftsführung poweron ag --> <!-- approver: geschäftsführung poweron ag --> <!-- approveddate: --> <!-- nextreview: 2027-06-03 --> <!-- classification: intern --> <!-- isorefs: 9001:9.3; 27001:9.3 --> # management-review **dokumenttyp:** verfahren + protokollvorlage (pflicht iso 9001/27001 kap. 9.3) ## 1. zweck und turnus die oberste leitung bewertet das ims mindestens **jährlich** sowie anlassbezogen auf eignung, angemessenheit und wirksamkeit und entscheidet über verbesserungen und ressourcen. ## 2. eingaben (inputs) - status massnahmen aus vorherigen reviews - änderungen interner/externer themen ([kontext](../01_kontext/kontext-und-interessierte-parteien.md)) - erfüllung der [ziele & kennzahlen](../03_planung/ziele-und-kennzahlen.md) - ergebnisse [interner audits](internes-audit.md) - risikolage / [risikoregister](../03_planung/risikoregister.md) + soa-status - incidents, abweichungen, reklamationen - rückmeldungen interessierter parteien (kunden, lieferanten) - stand offener pendenzen ([massnahmenregister](../07_verbesserung/massnahmen-register.md)) ## 3. ergebnisse (outputs) - bewertung der ims-wirksamkeit - entscheidungen zu verbesserungen, zielen, ressourcen - neue/aktualisierte massnahmen mit owner und termin - ggf. anpassung von politiken, scope, soa ## 4. protokollvorlage ```markdown # management-review-protokoll datum: teilnehmende: berichtsperiode: ## inputs (zusammenfassung) - zielerreichung: ... - audit-ergebnisse: ... - risiken/soa: ... - incidents/abweichungen: ... - rückmeldungen: ... ## bewertung - eignung/angemessenheit/wirksamkeit: ... ## entscheidungen & massnahmen | massnahme | owner | termin | |---|---|---| | | | | ## nächstes review: freigabe (geschäftsführung): ``` ## 5. records jedes protokoll wird als record abgelegt. das erste management-review (2026 q3) ist voraussetzung für die audit-reife. ", "nextReview": "2027-06-03", "overdueReview": false, "zuPruefen": []}, {"id": "06_bewertung/monitoring-messung.md", "path": "06_bewertung/monitoring-messung.md", "chapter": "06_bewertung", "title": "Monitoring, Messung, Analyse und Bewertung", "filename": "monitoring-messung.md", "meta": {"docId": "IMS-09-03", "status": "entwurf", "version": "0.1", "owner": "Patrick Motsch", "approver": "Geschäftsführung PowerOn AG", "approvedDate": "", "nextReview": "2027-06-03", "classification": "intern", "isoRefs": "9001:9.1; 27001:9.1"}, "html": "<h1>Monitoring, Messung, Analyse und Bewertung<\/h1>\n<p><strong>Dokumenttyp:<\/strong> Verfahren (Pflicht ISO 9001/27001 Kap. 9.1)<\/p>\n<h2>1. Was wird gemessen<\/h2>\n<table><thead><tr><th>Gegenstand<\/th><th>Kennzahl<\/th><th>Quelle<\/th><th>Frequenz<\/th><th>Owner<\/th><\/tr><\/thead><tbody><tr><td>Qualitätsziele Q-1..Q-4<\/td><td>siehe <a href=\"../03_planung/ziele-und-kennzahlen.md\">Ziele<\/a><\/td><td>Tickets, Releases, CHANGELOG<\/td><td>quartalsweise<\/td><td>Patrick Motsch<\/td><\/tr><tr><td>Sicherheitsziele S-1..S-6<\/td><td>siehe <a href=\"../03_planung/ziele-und-kennzahlen.md\">Ziele<\/a><\/td><td>Risikoregister, Patch-/Incident-Logs<\/td><td>quartalsweise<\/td><td>Patrick Motsch<\/td><\/tr><tr><td>Verfügbarkeit Plattform<\/td><td>Uptime %<\/td><td>Monitoring/Statusseite<\/td><td>laufend<\/td><td>Patrick Motsch<\/td><\/tr><tr><td>Vorfälle<\/td><td>Anzahl, Schweregrad, Reaktionszeit<\/td><td><a href=\"../05_betrieb/07_Incident_Response_und_Meldewesen.md\">Incident Response<\/a><\/td><td>je Vorfall<\/td><td>Patrick Motsch<\/td><\/tr><tr><td>Dokumentenpflege<\/td><td>überfällige Reviews<\/td><td><a href=\"../cockpit/\">Cockpit<\/a><\/td><td>laufend<\/td><td>Patrick Motsch<\/td><\/tr><tr><td>Schwachstellen<\/td><td>offen/behoben, SLA-Treue<\/td><td><a href=\"../05_betrieb/10_Schwachstellenmanagement.md\">Schwachstellen<\/a><\/td><td>laufend<\/td><td>Patrick Motsch<\/td><\/tr><\/tbody><\/table>\n<h2>2. Analyse und Bewertung<\/h2>\n<p>Die Kennzahlen werden quartalsweise zusammengefasst und im <a href=\"management-review.md\">Management-Review<\/a> bewertet. Zielverfehlungen lösen Einträge im <a href=\"../07_verbesserung/massnahmen-register.md\">Massnahmenregister<\/a> aus.<\/p>\n<h2>3. Werkzeuge<\/h2>\n<p>Das <a href=\"../cockpit/\">Management-Cockpit<\/a> liefert die laufende Sicht auf Dokumentenstatus, fällige Reviews und offene Pendenzen. Betriebskennzahlen stammen aus Monitoring, Forgejo und den Betriebs-Records.<\/p>", "text": "<!-- docid: ims-09-03 --> <!-- status: entwurf --> <!-- version: 0.1 --> <!-- owner: patrick motsch --> <!-- approver: geschäftsführung poweron ag --> <!-- approveddate: --> <!-- nextreview: 2027-06-03 --> <!-- classification: intern --> <!-- isorefs: 9001:9.1; 27001:9.1 --> # monitoring, messung, analyse und bewertung **dokumenttyp:** verfahren (pflicht iso 9001/27001 kap. 9.1) ## 1. was wird gemessen | gegenstand | kennzahl | quelle | frequenz | owner | |---|---|---|---|---| | qualitätsziele q-1..q-4 | siehe [ziele](../03_planung/ziele-und-kennzahlen.md) | tickets, releases, changelog | quartalsweise | patrick motsch | | sicherheitsziele s-1..s-6 | siehe [ziele](../03_planung/ziele-und-kennzahlen.md) | risikoregister, patch-/incident-logs | quartalsweise | patrick motsch | | verfügbarkeit plattform | uptime % | monitoring/statusseite | laufend | patrick motsch | | vorfälle | anzahl, schweregrad, reaktionszeit | [incident response](../05_betrieb/07_incident_response_und_meldewesen.md) | je vorfall | patrick motsch | | dokumentenpflege | überfällige reviews | [cockpit](../cockpit/) | laufend | patrick motsch | | schwachstellen | offen/behoben, sla-treue | [schwachstellen](../05_betrieb/10_schwachstellenmanagement.md) | laufend | patrick motsch | ## 2. analyse und bewertung die kennzahlen werden quartalsweise zusammengefasst und im [management-review](management-review.md) bewertet. zielverfehlungen lösen einträge im [massnahmenregister](../07_verbesserung/massnahmen-register.md) aus. ## 3. werkzeuge das [management-cockpit](../cockpit/) liefert die laufende sicht auf dokumentenstatus, fällige reviews und offene pendenzen. betriebskennzahlen stammen aus monitoring, forgejo und den betriebs-records. ", "nextReview": "2027-06-03", "overdueReview": false, "zuPruefen": []}, {"id": "07_verbesserung/korrekturmassnahmen-und-kvp.md", "path": "07_verbesserung/korrekturmassnahmen-und-kvp.md", "chapter": "07_verbesserung", "title": "Korrekturmassnahmen & kontinuierliche Verbesserung (KVP)", "filename": "korrekturmassnahmen-und-kvp.md", "meta": {"docId": "IMS-10-01", "status": "entwurf", "version": "0.1", "owner": "Patrick Motsch", "approver": "Geschäftsführung PowerOn AG", "approvedDate": "", "nextReview": "2027-06-03", "classification": "intern", "isoRefs": "9001:10; 27001:10"}, "html": "<h1>Korrekturmassnahmen &amp; kontinuierliche Verbesserung (KVP)<\/h1>\n<p><strong>Dokumenttyp:<\/strong> Verfahren (Pflicht ISO 9001/27001 Kap. 10)<\/p>\n<h2>1. Zweck<\/h2>\n<p>Abweichungen (Nichtkonformitäten), Vorfälle, Reklamationen und Verbesserungsideen werden systematisch erfasst, behandelt und auf Wirksamkeit geprüft. Ziel ist die kontinuierliche Verbesserung des IMS.<\/p>\n<h2>2. Ablauf der Korrekturmassnahme<\/h2>\n<pre class=\"mermaid\">flowchart LR\n    erfassen[\"1 Abweichung erfassen (Massnahmenregister)\"] --&gt; sofort[\"2 Sofortmassnahme / Eindämmung\"]\n    sofort --&gt; ursache[\"3 Ursachenanalyse (Root Cause)\"]\n    ursache --&gt; massnahme[\"4 Korrekturmassnahme definieren (Owner, Termin)\"]\n    massnahme --&gt; umsetzen[\"5 Umsetzen\"]\n    umsetzen --&gt; wirksam[\"6 Wirksamkeit prüfen\"]\n    wirksam --&gt; schliessen[\"7 Schliessen + dokumentieren\"]<\/pre>\n<h2>3. Quellen von Abweichungen/Pendenzen<\/h2>\n<ul><li>Interne Audits (<a href=\"../06_bewertung/internes-audit.md\">internes-audit.md<\/a>)<\/li><li>Sicherheitsvorfälle (<a href=\"../05_betrieb/07_Incident_Response_und_Meldewesen.md\">Incident Response<\/a>)<\/li><li>Risikobehandlung (<a href=\"../03_planung/risikoregister.md\">Risikoregister<\/a>)<\/li><li>Zielverfehlungen (<a href=\"../06_bewertung/monitoring-messung.md\">Monitoring<\/a>)<\/li><li>Kundenreklamationen, Lieferantenprobleme<\/li><li>Überfällige Dokumenten-Reviews<\/li><li>Verbesserungsvorschläge<\/li><\/ul>\n<h2>4. Führung im Massnahmenregister<\/h2>\n<p>Alle Korrektur- und Verbesserungsmassnahmen werden zentral im <a href=\"massnahmen-register.md\">Massnahmenregister<\/a> geführt (Single Source of Truth). Das <a href=\"../cockpit/\">Cockpit<\/a> aggregiert daraus zusammen mit überfälligen Reviews und <code>[ZU PRÜFEN]<\/code>-Markern eine Gesamtsicht der Pendenzen.<\/p>\n<h2>5. Kontinuierliche Verbesserung<\/h2>\n<p>Trends (wiederkehrende Abweichungen, Incident-Muster) werden im <a href=\"../06_bewertung/management-review.md\">Management-Review<\/a> bewertet und führen zu präventiven Verbesserungen an Prozessen, Controls oder Dokumenten.<\/p>", "text": "<!-- docid: ims-10-01 --> <!-- status: entwurf --> <!-- version: 0.1 --> <!-- owner: patrick motsch --> <!-- approver: geschäftsführung poweron ag --> <!-- approveddate: --> <!-- nextreview: 2027-06-03 --> <!-- classification: intern --> <!-- isorefs: 9001:10; 27001:10 --> # korrekturmassnahmen & kontinuierliche verbesserung (kvp) **dokumenttyp:** verfahren (pflicht iso 9001/27001 kap. 10) ## 1. zweck abweichungen (nichtkonformitäten), vorfälle, reklamationen und verbesserungsideen werden systematisch erfasst, behandelt und auf wirksamkeit geprüft. ziel ist die kontinuierliche verbesserung des ims. ## 2. ablauf der korrekturmassnahme ```mermaid flowchart lr erfassen[\"1 abweichung erfassen (massnahmenregister)\"] --> sofort[\"2 sofortmassnahme / eindämmung\"] sofort --> ursache[\"3 ursachenanalyse (root cause)\"] ursache --> massnahme[\"4 korrekturmassnahme definieren (owner, termin)\"] massnahme --> umsetzen[\"5 umsetzen\"] umsetzen --> wirksam[\"6 wirksamkeit prüfen\"] wirksam --> schliessen[\"7 schliessen + dokumentieren\"] ``` ## 3. quellen von abweichungen/pendenzen - interne audits ([internes-audit.md](../06_bewertung/internes-audit.md)) - sicherheitsvorfälle ([incident response](../05_betrieb/07_incident_response_und_meldewesen.md)) - risikobehandlung ([risikoregister](../03_planung/risikoregister.md)) - zielverfehlungen ([monitoring](../06_bewertung/monitoring-messung.md)) - kundenreklamationen, lieferantenprobleme - überfällige dokumenten-reviews - verbesserungsvorschläge ## 4. führung im massnahmenregister alle korrektur- und verbesserungsmassnahmen werden zentral im [massnahmenregister](massnahmen-register.md) geführt (single source of truth). das [cockpit](../cockpit/) aggregiert daraus zusammen mit überfälligen reviews und `[zu prüfen]`-markern eine gesamtsicht der pendenzen. ## 5. kontinuierliche verbesserung trends (wiederkehrende abweichungen, incident-muster) werden im [management-review](../06_bewertung/management-review.md) bewertet und führen zu präventiven verbesserungen an prozessen, controls oder dokumenten. ", "nextReview": "2027-06-03", "overdueReview": false, "zuPruefen": []}, {"id": "07_verbesserung/massnahmen-register.md", "path": "07_verbesserung/massnahmen-register.md", "chapter": "07_verbesserung", "title": "Massnahmenregister (Pendenzen)", "filename": "massnahmen-register.md", "meta": {"docId": "IMS-10-02", "status": "entwurf", "version": "0.1", "owner": "Patrick Motsch", "approver": "Geschäftsführung PowerOn AG", "approvedDate": "", "nextReview": "2026-09-03", "classification": "intern", "isoRefs": "9001:10.2; 27001:10.1"}, "html": "<h1>Massnahmenregister (Pendenzen)<\/h1>\n<p><strong>Dokumenttyp:<\/strong> Record (zentrale Pendenzenliste -- Single Source of Truth)<\/p>\n<p>Zentrale Liste aller Korrektur- und Verbesserungsmassnahmen. Das <a href=\"../cockpit/\">Management-Cockpit<\/a> liest diese Tabelle und führt sie auf der Pendenzen-Seite mit überfälligen Reviews und <code>[ZU PRÜFEN]<\/code>-Markern zusammen.<\/p>\n<p><strong>Spalten-Schema (bitte exakt einhalten):<\/strong> <code>ID | Titel | Owner | Quelle | Erstellt | Faellig | Status<\/code> <strong>Status-Werte:<\/strong> <code>offen<\/code>, <code>in Arbeit<\/code>, <code>erledigt<\/code>. <strong>Quelle-Werte:<\/strong> <code>Audit<\/code>, <code>Review<\/code>, <code>Risiko<\/code>, <code>Incident<\/code>, <code>Doku<\/code>, <code>Sonstiges<\/code>.<\/p>\n<table><thead><tr><th>ID<\/th><th>Titel<\/th><th>Owner<\/th><th>Quelle<\/th><th>Erstellt<\/th><th>Fällig<\/th><th>Status<\/th><\/tr><\/thead><tbody><tr><td>M-01<\/td><td>MFA auf Admin-/Server-Zugängen bestätigen/erzwingen<\/td><td>Patrick Motsch<\/td><td>Risiko<\/td><td>2026-06-03<\/td><td>2026-07-15<\/td><td>erledigt<\/td><\/tr><tr><td>M-02<\/td><td>Restore-Test durchführen und protokollieren<\/td><td>Patrick Motsch<\/td><td>Risiko<\/td><td>2026-06-03<\/td><td>2026-06-30<\/td><td>offen<\/td><\/tr><tr><td>M-03<\/td><td>AVV/Zero-Retention mit OpenAI und weiteren LLM-Providern ablegen<\/td><td>Patrick Motsch<\/td><td>Risiko<\/td><td>2026-06-03<\/td><td>2026-07-31<\/td><td>offen<\/td><\/tr><tr><td>M-04<\/td><td>Log-Aufbewahrungsdauer und Manipulationsschutz festlegen<\/td><td>Patrick Motsch<\/td><td>Risiko<\/td><td>2026-06-03<\/td><td>2026-07-31<\/td><td>offen<\/td><\/tr><tr><td>M-05<\/td><td>Verschlüsselung at-rest der Infomaniak-DB bestätigen<\/td><td>Patrick Motsch<\/td><td>Risiko<\/td><td>2026-06-03<\/td><td>2026-06-30<\/td><td>offen<\/td><\/tr><tr><td>M-06<\/td><td>Entscheidung zu Produktivdaten in Testumgebung treffen<\/td><td>Patrick Motsch<\/td><td>Doku<\/td><td>2026-06-03<\/td><td>2026-07-15<\/td><td>offen<\/td><\/tr><tr><td>M-07<\/td><td>Hintergrundprüfungen bei Einstellung klären<\/td><td>Patrick Motsch<\/td><td>Risiko<\/td><td>2026-06-03<\/td><td>2026-08-15<\/td><td>offen<\/td><\/tr><tr><td>M-08<\/td><td>Externen internen Auditor benennen und beauftragen<\/td><td>Patrick Motsch<\/td><td>Audit<\/td><td>2026-06-03<\/td><td>2026-07-15<\/td><td>offen<\/td><\/tr><tr><td>M-09<\/td><td>Erstes internes Audit durchführen<\/td><td>Patrick Motsch<\/td><td>Audit<\/td><td>2026-06-03<\/td><td>2026-09-30<\/td><td>offen<\/td><\/tr><tr><td>M-10<\/td><td>Erstes Management-Review durchführen<\/td><td>Patrick Motsch<\/td><td>Review<\/td><td>2026-06-03<\/td><td>2026-09-30<\/td><td>offen<\/td><\/tr><tr><td>M-11<\/td><td>Risikoworkshop zur Validierung des Risikoregisters<\/td><td>Patrick Motsch<\/td><td>Risiko<\/td><td>2026-06-03<\/td><td>2026-06-30<\/td><td>offen<\/td><\/tr><tr><td>M-12<\/td><td>Asset-Inventar erstellen (A.5.9)<\/td><td>Patrick Motsch<\/td><td>Doku<\/td><td>2026-06-03<\/td><td>2026-08-31<\/td><td>offen<\/td><\/tr><tr><td>M-13<\/td><td>Politiken formal freigeben (Status entwurf -&gt; freigegeben)<\/td><td>Patrick Motsch<\/td><td>Doku<\/td><td>2026-06-03<\/td><td>2026-07-31<\/td><td>offen<\/td><\/tr><tr><td>M-14<\/td><td>Organisationsreglement und Meetingstruktur im POL bestätigen<\/td><td>Patrick Motsch<\/td><td>Review<\/td><td>2026-06-11<\/td><td>2026-06-30<\/td><td>in Arbeit<\/td><\/tr><\/tbody><\/table>\n<h2>Pflegehinweis<\/h2>\n<p>Neue Pendenzen mit fortlaufender ID ergänzen. Bei Abschluss <code>Status = erledigt<\/code> setzen (Zeile bleibt für Nachweis erhalten). Überfällige Einträge (Fällig &lt; heute, Status != erledigt) hebt das Cockpit rot hervor.<\/p>", "text": "<!-- docid: ims-10-02 --> <!-- status: entwurf --> <!-- version: 0.1 --> <!-- owner: patrick motsch --> <!-- approver: geschäftsführung poweron ag --> <!-- approveddate: --> <!-- nextreview: 2026-09-03 --> <!-- classification: intern --> <!-- isorefs: 9001:10.2; 27001:10.1 --> # massnahmenregister (pendenzen) **dokumenttyp:** record (zentrale pendenzenliste -- single source of truth) zentrale liste aller korrektur- und verbesserungsmassnahmen. das [management-cockpit](../cockpit/) liest diese tabelle und führt sie auf der pendenzen-seite mit überfälligen reviews und `[zu prüfen]`-markern zusammen. **spalten-schema (bitte exakt einhalten):** `id | titel | owner | quelle | erstellt | faellig | status` **status-werte:** `offen`, `in arbeit`, `erledigt`. **quelle-werte:** `audit`, `review`, `risiko`, `incident`, `doku`, `sonstiges`. | id | titel | owner | quelle | erstellt | fällig | status | |---|---|---|---|---|---|---| | m-01 | mfa auf admin-/server-zugängen bestätigen/erzwingen | patrick motsch | risiko | 2026-06-03 | 2026-07-15 | erledigt | | m-02 | restore-test durchführen und protokollieren | patrick motsch | risiko | 2026-06-03 | 2026-06-30 | offen | | m-03 | avv/zero-retention mit openai und weiteren llm-providern ablegen | patrick motsch | risiko | 2026-06-03 | 2026-07-31 | offen | | m-04 | log-aufbewahrungsdauer und manipulationsschutz festlegen | patrick motsch | risiko | 2026-06-03 | 2026-07-31 | offen | | m-05 | verschlüsselung at-rest der infomaniak-db bestätigen | patrick motsch | risiko | 2026-06-03 | 2026-06-30 | offen | | m-06 | entscheidung zu produktivdaten in testumgebung treffen | patrick motsch | doku | 2026-06-03 | 2026-07-15 | offen | | m-07 | hintergrundprüfungen bei einstellung klären | patrick motsch | risiko | 2026-06-03 | 2026-08-15 | offen | | m-08 | externen internen auditor benennen und beauftragen | patrick motsch | audit | 2026-06-03 | 2026-07-15 | offen | | m-09 | erstes internes audit durchführen | patrick motsch | audit | 2026-06-03 | 2026-09-30 | offen | | m-10 | erstes management-review durchführen | patrick motsch | review | 2026-06-03 | 2026-09-30 | offen | | m-11 | risikoworkshop zur validierung des risikoregisters | patrick motsch | risiko | 2026-06-03 | 2026-06-30 | offen | | m-12 | asset-inventar erstellen (a.5.9) | patrick motsch | doku | 2026-06-03 | 2026-08-31 | offen | | m-13 | politiken formal freigeben (status entwurf -> freigegeben) | patrick motsch | doku | 2026-06-03 | 2026-07-31 | offen | | m-14 | organisationsreglement und meetingstruktur im pol bestätigen | patrick motsch | review | 2026-06-11 | 2026-06-30 | in arbeit | ## pflegehinweis neue pendenzen mit fortlaufender id ergänzen. bei abschluss `status = erledigt` setzen (zeile bleibt für nachweis erhalten). überfällige einträge (fällig < heute, status != erledigt) hebt das cockpit rot hervor. ", "nextReview": "2026-09-03", "overdueReview": false, "zuPruefen": []}, {"id": "mappings/cacc-iso-crosswalk.md", "path": "mappings/cacc-iso-crosswalk.md", "chapter": "mappings", "title": "CACC / FINMA <-> ISO-Crosswalk", "filename": "cacc-iso-crosswalk.md", "meta": {"docId": "IMS-MAP-CACC", "status": "entwurf", "version": "1.1", "owner": "Patrick Motsch", "approver": "Geschäftsführung PowerOn AG", "approvedDate": "", "nextReview": "2027-06-03", "classification": "intern", "isoRefs": "27001:AnnexA; 9001:8"}, "html": "<h1>CACC / FINMA &lt;-&gt; ISO-Crosswalk<\/h1>\n<p><strong>Zweck:<\/strong> Verknüpft die bestehenden Prozessdokumente (ursprünglich für <strong>GLKB Cloud Assessment Criteria Catalogue (CACC)<\/strong> und FINMA-Rundschreiben 2018/3 &amp; 2023/1 erstellt) mit ihren neuen Speicherorten im IMS sowie den abgedeckten CACC-Punkten. Das Annex-A-Mapping für ISO 27001 ist das <a href=\"../03_planung/statement-of-applicability-soa.md\">SoA<\/a>.<\/p>\n<p><strong>Stand:<\/strong> 2026-06-03 <strong>Hinweis:<\/strong> <code>[ZU PRÜFEN]<\/code> markiert Stellen, die vor einer Einreichung verifiziert werden müssen.<\/p>\n<h2>Rahmenbedingungen<\/h2>\n<ul><li><strong>Hosting:<\/strong> Infomaniak Public Cloud, Schweiz (<code>api.poweron.swiss<\/code>, <code>db.poweron.swiss<\/code>).<\/li><li><strong>KI-Verarbeitung:<\/strong> Inhaltsdaten gehen an externe LLM-Provider (Primär OpenAI/USA); abgesichert via AVV/DPA + EU-SCC + Neutralisierung.<\/li><li><strong>Team:<\/strong> 2-5 Personen; wo Katalogpunkte grössere Organisationen voraussetzen, greifen kompensierende Massnahmen.<\/li><\/ul>\n<h2>Dokumentenkarte -&gt; neuer Ort + CACC-Punkte<\/h2>\n<table><thead><tr><th>Dokument (neuer Ort in <code>ims/<\/code>)<\/th><th>CACC-Punkte<\/th><\/tr><\/thead><tbody><tr><td><code>02_fuehrung/informationssicherheitspolitik.md<\/code><\/td><td>49, 52, 56<\/td><\/tr><tr><td><code>05_betrieb/02_Zugriffsmanagement_IAM_PAM.md<\/code><\/td><td>25, 36, 37, 66, 67, 68, 69<\/td><\/tr><tr><td><code>05_betrieb/03_Mitarbeitersicherheit_und_Screening.md<\/code><\/td><td>23, 35, 37<\/td><\/tr><tr><td><code>05_betrieb/04_Verschluesselung_und_Schluesselmanagement.md<\/code><\/td><td>43, 44, 45, 46, 70, 71, 72<\/td><\/tr><tr><td><code>05_betrieb/05_Backup_und_Wiederherstellung.md<\/code><\/td><td>75, 87<\/td><\/tr><tr><td><code>05_betrieb/06_Business_Continuity_und_Disaster_Recovery.md<\/code><\/td><td>3, 79, 87<\/td><\/tr><tr><td><code>05_betrieb/07_Incident_Response_und_Meldewesen.md<\/code><\/td><td>19, 20, 27, 86<\/td><\/tr><tr><td><code>05_betrieb/08_Change_Management.md<\/code><\/td><td>81, 82, 83<\/td><\/tr><tr><td><code>05_betrieb/09_Patch_Management.md<\/code><\/td><td>78<\/td><\/tr><tr><td><code>05_betrieb/10_Schwachstellenmanagement.md<\/code><\/td><td>54, 59, 63, 84<\/td><\/tr><tr><td><code>05_betrieb/11_Logging_und_Monitoring.md<\/code><\/td><td>88, 89, 90, 91, 92, 93, 94<\/td><\/tr><tr><td><code>05_betrieb/12_Netzwerk_und_Infrastruktursicherheit.md<\/code><\/td><td>95, 96, 97, 98, 99<\/td><\/tr><tr><td><code>05_betrieb/13_Datenaufbewahrung_Loeschung_LegalHold.md<\/code><\/td><td>1, 2, 38, 72<\/td><\/tr><tr><td><code>05_betrieb/14_Exit_und_Transition.md<\/code><\/td><td>4, 5, 6, 22<\/td><\/tr><tr><td><code>05_betrieb/15_Sichere_Softwareentwicklung_SDLC.md<\/code><\/td><td>100, 101, 102<\/td><\/tr><tr><td><code>05_betrieb/16_Kapazitaetsmanagement.md<\/code><\/td><td>80<\/td><\/tr><tr><td><code>05_betrieb/17_Subunternehmer_Management.md<\/code><\/td><td>16, 31, 48, 53<\/td><\/tr><tr><td><code>05_betrieb/18_Analyse_Recht_und_BestPractice.md<\/code><\/td><td>Befundbericht (intern)<\/td><\/tr><tr><td><code>05_betrieb/20260528_drittanbieter-inventar.md<\/code><\/td><td>48, 53, 61<\/td><\/tr><tr><td><code>05_betrieb/20260528_datenbank-handling.md<\/code><\/td><td>2, 38, 75 (teilw.)<\/td><\/tr><tr><td><code>05_betrieb/20260528_bcm_runbook.md<\/code><\/td><td>3, 87 (technisch)<\/td><\/tr><tr><td><code>05_betrieb/20260528_feature_release_bugfix.md<\/code><\/td><td>81, 100, 101 (teilw.)<\/td><\/tr><\/tbody><\/table>\n<h2>Offene Punkte (in Massnahmenregister überführt)<\/h2>\n<p>Die frühere Sammelliste offener Punkte wird jetzt zentral im <a href=\"../07_verbesserung/massnahmen-register.md\">Massnahmenregister<\/a> geführt (M-01 bis M-07 u. a.: at-rest-Verschlüsselung, MFA, Hintergrundprüfungen, Log-Retention, Restore-Test, AVVs, Testdaten).<\/p>", "text": "<!-- docid: ims-map-cacc --> <!-- status: entwurf --> <!-- version: 1.1 --> <!-- owner: patrick motsch --> <!-- approver: geschäftsführung poweron ag --> <!-- approveddate: --> <!-- nextreview: 2027-06-03 --> <!-- classification: intern --> <!-- isorefs: 27001:annexa; 9001:8 --> # cacc / finma <-> iso-crosswalk **zweck:** verknüpft die bestehenden prozessdokumente (ursprünglich für **glkb cloud assessment criteria catalogue (cacc)** und finma-rundschreiben 2018/3 & 2023/1 erstellt) mit ihren neuen speicherorten im ims sowie den abgedeckten cacc-punkten. das annex-a-mapping für iso 27001 ist das [soa](../03_planung/statement-of-applicability-soa.md). **stand:** 2026-06-03 **hinweis:** `[zu prüfen]` markiert stellen, die vor einer einreichung verifiziert werden müssen. ## rahmenbedingungen - **hosting:** infomaniak public cloud, schweiz (`api.poweron.swiss`, `db.poweron.swiss`). - **ki-verarbeitung:** inhaltsdaten gehen an externe llm-provider (primär openai/usa); abgesichert via avv/dpa + eu-scc + neutralisierung. - **team:** 2-5 personen; wo katalogpunkte grössere organisationen voraussetzen, greifen kompensierende massnahmen. ## dokumentenkarte -> neuer ort + cacc-punkte | dokument (neuer ort in `ims/`) | cacc-punkte | |---|---| | `02_fuehrung/informationssicherheitspolitik.md` | 49, 52, 56 | | `05_betrieb/02_zugriffsmanagement_iam_pam.md` | 25, 36, 37, 66, 67, 68, 69 | | `05_betrieb/03_mitarbeitersicherheit_und_screening.md` | 23, 35, 37 | | `05_betrieb/04_verschluesselung_und_schluesselmanagement.md` | 43, 44, 45, 46, 70, 71, 72 | | `05_betrieb/05_backup_und_wiederherstellung.md` | 75, 87 | | `05_betrieb/06_business_continuity_und_disaster_recovery.md` | 3, 79, 87 | | `05_betrieb/07_incident_response_und_meldewesen.md` | 19, 20, 27, 86 | | `05_betrieb/08_change_management.md` | 81, 82, 83 | | `05_betrieb/09_patch_management.md` | 78 | | `05_betrieb/10_schwachstellenmanagement.md` | 54, 59, 63, 84 | | `05_betrieb/11_logging_und_monitoring.md` | 88, 89, 90, 91, 92, 93, 94 | | `05_betrieb/12_netzwerk_und_infrastruktursicherheit.md` | 95, 96, 97, 98, 99 | | `05_betrieb/13_datenaufbewahrung_loeschung_legalhold.md` | 1, 2, 38, 72 | | `05_betrieb/14_exit_und_transition.md` | 4, 5, 6, 22 | | `05_betrieb/15_sichere_softwareentwicklung_sdlc.md` | 100, 101, 102 | | `05_betrieb/16_kapazitaetsmanagement.md` | 80 | | `05_betrieb/17_subunternehmer_management.md` | 16, 31, 48, 53 | | `05_betrieb/18_analyse_recht_und_bestpractice.md` | befundbericht (intern) | | `05_betrieb/20260528_drittanbieter-inventar.md` | 48, 53, 61 | | `05_betrieb/20260528_datenbank-handling.md` | 2, 38, 75 (teilw.) | | `05_betrieb/20260528_bcm_runbook.md` | 3, 87 (technisch) | | `05_betrieb/20260528_feature_release_bugfix.md` | 81, 100, 101 (teilw.) | ## offene punkte (in massnahmenregister überführt) die frühere sammelliste offener punkte wird jetzt zentral im [massnahmenregister](../07_verbesserung/massnahmen-register.md) geführt (m-01 bis m-07 u. a.: at-rest-verschlüsselung, mfa, hintergrundprüfungen, log-retention, restore-test, avvs, testdaten). ", "nextReview": "2027-06-03", "overdueReview": false, "zuPruefen": []}, {"id": "mappings/iso27001-annexA-soa-mapping.md", "path": "mappings/iso27001-annexA-soa-mapping.md", "chapter": "mappings", "title": "Mapping ISO/IEC 27001:2022 Annex A", "filename": "iso27001-annexA-soa-mapping.md", "meta": {"docId": "IMS-MAP-27001", "status": "entwurf", "version": "0.1", "owner": "Patrick Motsch", "approver": "Geschäftsführung PowerOn AG", "approvedDate": "", "nextReview": "2027-06-03", "classification": "intern", "isoRefs": "27001:AnnexA"}, "html": "<h1>Mapping ISO/IEC 27001:2022 Annex A<\/h1>\n<p>Das massgebliche Mapping aller 93 Annex-A-Controls (Anwendbarkeit, Status, umsetzendes Dokument) ist das <strong>Statement of Applicability<\/strong>:<\/p>\n<p>-&gt; <a href=\"../03_planung/statement-of-applicability-soa.md\">Statement of Applicability (SoA)<\/a><\/p>\n<p>Die ISO-27001-Hauptklauseln 4-10 werden durch das Managementsystem-Geruest abgedeckt; siehe <a href=\"iso9001-klausel-mapping.md\">iso9001-klausel-mapping.md<\/a> (strukturgleich, Annex SL) sowie die <code>isoRefs<\/code>-Header der einzelnen Dokumente.<\/p>", "text": "<!-- docid: ims-map-27001 --> <!-- status: entwurf --> <!-- version: 0.1 --> <!-- owner: patrick motsch --> <!-- approver: geschäftsführung poweron ag --> <!-- approveddate: --> <!-- nextreview: 2027-06-03 --> <!-- classification: intern --> <!-- isorefs: 27001:annexa --> # mapping iso/iec 27001:2022 annex a das massgebliche mapping aller 93 annex-a-controls (anwendbarkeit, status, umsetzendes dokument) ist das **statement of applicability**: -> [statement of applicability (soa)](../03_planung/statement-of-applicability-soa.md) die iso-27001-hauptklauseln 4-10 werden durch das managementsystem-geruest abgedeckt; siehe [iso9001-klausel-mapping.md](iso9001-klausel-mapping.md) (strukturgleich, annex sl) sowie die `isorefs`-header der einzelnen dokumente. ", "nextReview": "2027-06-03", "overdueReview": false, "zuPruefen": []}, {"id": "mappings/iso9001-klausel-mapping.md", "path": "mappings/iso9001-klausel-mapping.md", "chapter": "mappings", "title": "Mapping ISO 9001:2015 -- Klauseln zu IMS-Dokumenten", "filename": "iso9001-klausel-mapping.md", "meta": {"docId": "IMS-MAP-9001", "status": "entwurf", "version": "0.1", "owner": "Patrick Motsch", "approver": "Geschäftsführung PowerOn AG", "approvedDate": "", "nextReview": "2027-06-03", "classification": "intern", "isoRefs": "9001:4-10"}, "html": "<h1>Mapping ISO 9001:2015 -- Klauseln zu IMS-Dokumenten<\/h1>\n<p>Nachweis, welches Dokument welche ISO-9001-Anforderung abdeckt.<\/p>\n<table><thead><tr><th>Klausel<\/th><th>Anforderung<\/th><th>Dokument<\/th><\/tr><\/thead><tbody><tr><td>4.1/4.2<\/td><td>Kontext, interessierte Parteien<\/td><td><a href=\"../01_kontext/kontext-und-interessierte-parteien.md\">kontext-und-interessierte-parteien.md<\/a><\/td><\/tr><tr><td>4.3/4.4<\/td><td>Geltungsbereich, QMS &amp; Prozesse<\/td><td><a href=\"../01_kontext/geltungsbereich-scope.md\">geltungsbereich-scope.md<\/a><\/td><\/tr><tr><td>5.1/5.2<\/td><td>Führung, Qualitätspolitik<\/td><td><a href=\"../02_fuehrung/qm-politik.md\">qm-politik.md<\/a>, <a href=\"../00_IMS-Handbuch.md\">00_IMS-Handbuch.md<\/a><\/td><\/tr><tr><td>5.3<\/td><td>Rollen &amp; Verantwortlichkeiten<\/td><td><a href=\"../02_fuehrung/rollen-verantwortlichkeiten.md\">rollen-verantwortlichkeiten.md<\/a><\/td><\/tr><tr><td>6.1<\/td><td>Risiken &amp; Chancen<\/td><td><a href=\"../03_planung/risikomanagement-methodik.md\">risikomanagement-methodik.md<\/a>, <a href=\"../03_planung/risikoregister.md\">risikoregister.md<\/a><\/td><\/tr><tr><td>6.2<\/td><td>Qualitätsziele<\/td><td><a href=\"../03_planung/ziele-und-kennzahlen.md\">ziele-und-kennzahlen.md<\/a><\/td><\/tr><tr><td>7.1-7.3<\/td><td>Ressourcen, Kompetenz, Awareness<\/td><td><a href=\"../04_unterstuetzung/ressourcen-kompetenz-schulung.md\">ressourcen-kompetenz-schulung.md<\/a><\/td><\/tr><tr><td>7.4<\/td><td>Kommunikation<\/td><td><a href=\"../04_unterstuetzung/kommunikation.md\">kommunikation.md<\/a><\/td><\/tr><tr><td>7.5<\/td><td>Dokumentierte Information<\/td><td><a href=\"../04_unterstuetzung/dokumentenlenkung.md\">dokumentenlenkung.md<\/a>, <a href=\"../04_unterstuetzung/dokumentenregister.md\">dokumentenregister.md<\/a><\/td><\/tr><tr><td>8.1-8.6<\/td><td>Betrieb, Anforderungen, Entwicklung, Realisierung<\/td><td><a href=\"../05_betrieb/20260528_feature_release_bugfix.md\">feature_release_bugfix.md<\/a>, <a href=\"../05_betrieb/15_Sichere_Softwareentwicklung_SDLC.md\">SDLC<\/a>, <a href=\"../05_betrieb/08_Change_Management.md\">Change<\/a><\/td><\/tr><tr><td>9.1<\/td><td>Monitoring, Messung, Analyse<\/td><td><a href=\"../06_bewertung/monitoring-messung.md\">monitoring-messung.md<\/a><\/td><\/tr><tr><td>9.2<\/td><td>Internes Audit<\/td><td><a href=\"../06_bewertung/internes-audit.md\">internes-audit.md<\/a><\/td><\/tr><tr><td>9.3<\/td><td>Management-Review<\/td><td><a href=\"../06_bewertung/management-review.md\">management-review.md<\/a><\/td><\/tr><tr><td>10.1-10.3<\/td><td>Verbesserung, Nichtkonformität, KVP<\/td><td><a href=\"../07_verbesserung/korrekturmassnahmen-und-kvp.md\">korrekturmassnahmen-und-kvp.md<\/a>, <a href=\"../07_verbesserung/massnahmen-register.md\">massnahmen-register.md<\/a><\/td><\/tr><\/tbody><\/table>\n<h2>ISO/IEC 27001 Annex A<\/h2>\n<p>Das Mapping der ISO-27001-Annex-A-Controls ist das <a href=\"../03_planung/statement-of-applicability-soa.md\">Statement of Applicability (SoA)<\/a>. Die ISO-27001-Klauseln 4-10 sind strukturgleich zu ISO 9001 (Annex SL) und werden durch dieselben oben gelisteten Dokumente abgedeckt (vgl. <code>isoRefs<\/code>-Header je Dokument).<\/p>", "text": "<!-- docid: ims-map-9001 --> <!-- status: entwurf --> <!-- version: 0.1 --> <!-- owner: patrick motsch --> <!-- approver: geschäftsführung poweron ag --> <!-- approveddate: --> <!-- nextreview: 2027-06-03 --> <!-- classification: intern --> <!-- isorefs: 9001:4-10 --> # mapping iso 9001:2015 -- klauseln zu ims-dokumenten nachweis, welches dokument welche iso-9001-anforderung abdeckt. | klausel | anforderung | dokument | |---|---|---| | 4.1/4.2 | kontext, interessierte parteien | [kontext-und-interessierte-parteien.md](../01_kontext/kontext-und-interessierte-parteien.md) | | 4.3/4.4 | geltungsbereich, qms & prozesse | [geltungsbereich-scope.md](../01_kontext/geltungsbereich-scope.md) | | 5.1/5.2 | führung, qualitätspolitik | [qm-politik.md](../02_fuehrung/qm-politik.md), [00_ims-handbuch.md](../00_ims-handbuch.md) | | 5.3 | rollen & verantwortlichkeiten | [rollen-verantwortlichkeiten.md](../02_fuehrung/rollen-verantwortlichkeiten.md) | | 6.1 | risiken & chancen | [risikomanagement-methodik.md](../03_planung/risikomanagement-methodik.md), [risikoregister.md](../03_planung/risikoregister.md) | | 6.2 | qualitätsziele | [ziele-und-kennzahlen.md](../03_planung/ziele-und-kennzahlen.md) | | 7.1-7.3 | ressourcen, kompetenz, awareness | [ressourcen-kompetenz-schulung.md](../04_unterstuetzung/ressourcen-kompetenz-schulung.md) | | 7.4 | kommunikation | [kommunikation.md](../04_unterstuetzung/kommunikation.md) | | 7.5 | dokumentierte information | [dokumentenlenkung.md](../04_unterstuetzung/dokumentenlenkung.md), [dokumentenregister.md](../04_unterstuetzung/dokumentenregister.md) | | 8.1-8.6 | betrieb, anforderungen, entwicklung, realisierung | [feature_release_bugfix.md](../05_betrieb/20260528_feature_release_bugfix.md), [sdlc](../05_betrieb/15_sichere_softwareentwicklung_sdlc.md), [change](../05_betrieb/08_change_management.md) | | 9.1 | monitoring, messung, analyse | [monitoring-messung.md](../06_bewertung/monitoring-messung.md) | | 9.2 | internes audit | [internes-audit.md](../06_bewertung/internes-audit.md) | | 9.3 | management-review | [management-review.md](../06_bewertung/management-review.md) | | 10.1-10.3 | verbesserung, nichtkonformität, kvp | [korrekturmassnahmen-und-kvp.md](../07_verbesserung/korrekturmassnahmen-und-kvp.md), [massnahmen-register.md](../07_verbesserung/massnahmen-register.md) | ## iso/iec 27001 annex a das mapping der iso-27001-annex-a-controls ist das [statement of applicability (soa)](../03_planung/statement-of-applicability-soa.md). die iso-27001-klauseln 4-10 sind strukturgleich zu iso 9001 (annex sl) und werden durch dieselben oben gelisteten dokumente abgedeckt (vgl. `isorefs`-header je dokument). ", "nextReview": "2027-06-03", "overdueReview": false, "zuPruefen": []}], "chapters": [{"key": "00", "label": "Handbuch"}, {"key": "01_kontext", "label": "4 - Kontext"}, {"key": "02_fuehrung", "label": "5 - Führung"}, {"key": "03_planung", "label": "6 - Planung"}, {"key": "04_unterstuetzung", "label": "7 - Unterstützung"}, {"key": "05_betrieb", "label": "8 - Betrieb / Annex A"}, {"key": "06_bewertung", "label": "9 - Bewertung"}, {"key": "07_verbesserung", "label": "10 - Verbesserung"}, {"key": "mappings", "label": "Mappings"}], "pendenzenReg": [{"id": "M-01", "titel": "MFA auf Admin-/Server-Zugängen bestätigen/erzwingen", "owner": "Patrick Motsch", "quelle": "Risiko", "faellig": "2026-07-15", "status": "erledigt"}, {"id": "M-02", "titel": "Restore-Test durchführen und protokollieren", "owner": "Patrick Motsch", "quelle": "Risiko", "faellig": "2026-06-30", "status": "offen"}, {"id": "M-03", "titel": "AVV/Zero-Retention mit OpenAI und weiteren LLM-Providern ablegen", "owner": "Patrick Motsch", "quelle": "Risiko", "faellig": "2026-07-31", "status": "offen"}, {"id": "M-04", "titel": "Log-Aufbewahrungsdauer und Manipulationsschutz festlegen", "owner": "Patrick Motsch", "quelle": "Risiko", "faellig": "2026-07-31", "status": "offen"}, {"id": "M-05", "titel": "Verschlüsselung at-rest der Infomaniak-DB bestätigen", "owner": "Patrick Motsch", "quelle": "Risiko", "faellig": "2026-06-30", "status": "offen"}, {"id": "M-06", "titel": "Entscheidung zu Produktivdaten in Testumgebung treffen", "owner": "Patrick Motsch", "quelle": "Doku", "faellig": "2026-07-15", "status": "offen"}, {"id": "M-07", "titel": "Hintergrundprüfungen bei Einstellung klären", "owner": "Patrick Motsch", "quelle": "Risiko", "faellig": "2026-08-15", "status": "offen"}, {"id": "M-08", "titel": "Externen internen Auditor benennen und beauftragen", "owner": "Patrick Motsch", "quelle": "Audit", "faellig": "2026-07-15", "status": "offen"}, {"id": "M-09", "titel": "Erstes internes Audit durchführen", "owner": "Patrick Motsch", "quelle": "Audit", "faellig": "2026-09-30", "status": "offen"}, {"id": "M-10", "titel": "Erstes Management-Review durchführen", "owner": "Patrick Motsch", "quelle": "Review", "faellig": "2026-09-30", "status": "offen"}, {"id": "M-11", "titel": "Risikoworkshop zur Validierung des Risikoregisters", "owner": "Patrick Motsch", "quelle": "Risiko", "faellig": "2026-06-30", "status": "offen"}, {"id": "M-12", "titel": "Asset-Inventar erstellen (A.5.9)", "owner": "Patrick Motsch", "quelle": "Doku", "faellig": "2026-08-31", "status": "offen"}, {"id": "M-13", "titel": "Politiken formal freigeben (Status entwurf -> freigegeben)", "owner": "Patrick Motsch", "quelle": "Doku", "faellig": "2026-07-31", "status": "offen"}, {"id": "M-14", "titel": "Organisationsreglement und Meetingstruktur im POL bestätigen", "owner": "Patrick Motsch", "quelle": "Review", "faellig": "2026-06-30", "status": "in Arbeit"}], "overdueReviews": [], "zuPruefen": [{"id": "02_fuehrung/informationssicherheitspolitik.md", "title": "Informationssicherheitsrichtlinie (ISMS-Dachdokument)", "section": "8. Stand der Umsetzung / Lücken"}, {"id": "02_fuehrung/informationssicherheitspolitik.md", "title": "Informationssicherheitsrichtlinie (ISMS-Dachdokument)", "section": "8. Stand der Umsetzung / Lücken"}, {"id": "05_betrieb/02_Zugriffsmanagement_IAM_PAM.md", "title": "Zugriffsmanagement (IAM / PAM)", "section": "2. Zugriffsebenen der Plattform"}, {"id": "05_betrieb/02_Zugriffsmanagement_IAM_PAM.md", "title": "Zugriffsmanagement (IAM / PAM)", "section": "4. Authentifizierung (#68)"}, {"id": "05_betrieb/02_Zugriffsmanagement_IAM_PAM.md", "title": "Zugriffsmanagement (IAM / PAM)", "section": "4. Authentifizierung (#68)"}, {"id": "05_betrieb/02_Zugriffsmanagement_IAM_PAM.md", "title": "Zugriffsmanagement (IAM / PAM)", "section": "7. Zugangsbeschränkung auf IP/Domain (#69)"}, {"id": "05_betrieb/03_Mitarbeitersicherheit_und_Screening.md", "title": "Mitarbeitersicherheit und Screening", "section": "1. Vertraulichkeitsverpflichtung (#23)"}, {"id": "05_betrieb/03_Mitarbeitersicherheit_und_Screening.md", "title": "Mitarbeitersicherheit und Screening", "section": "2. Sorgfältige Auswahl und Hintergrundprüfung (#35)"}, {"id": "05_betrieb/03_Mitarbeitersicherheit_und_Screening.md", "title": "Mitarbeitersicherheit und Screening", "section": "2. Sorgfältige Auswahl und Hintergrundprüfung (#35)"}, {"id": "05_betrieb/03_Mitarbeitersicherheit_und_Screening.md", "title": "Mitarbeitersicherheit und Screening", "section": "2. Sorgfältige Auswahl und Hintergrundprüfung (#35)"}, {"id": "05_betrieb/03_Mitarbeitersicherheit_und_Screening.md", "title": "Mitarbeitersicherheit und Screening", "section": "3. Schulung und Awareness"}, {"id": "05_betrieb/03_Mitarbeitersicherheit_und_Screening.md", "title": "Mitarbeitersicherheit und Screening", "section": "5. Stand der Umsetzung / Lücken"}, {"id": "05_betrieb/03_Mitarbeitersicherheit_und_Screening.md", "title": "Mitarbeitersicherheit und Screening", "section": "5. Stand der Umsetzung / Lücken"}, {"id": "05_betrieb/03_Mitarbeitersicherheit_und_Screening.md", "title": "Mitarbeitersicherheit und Screening", "section": "5. Stand der Umsetzung / Lücken"}, {"id": "05_betrieb/04_Verschluesselung_und_Schluesselmanagement.md", "title": "Verschlüsselung und Schlüsselmanagement", "section": "1. Verschlüsselung bei der Übertragung (in transit) (#70)"}, {"id": "05_betrieb/04_Verschluesselung_und_Schluesselmanagement.md", "title": "Verschlüsselung und Schlüsselmanagement", "section": "1. Verschlüsselung bei der Übertragung (in transit) (#70)"}, {"id": "05_betrieb/04_Verschluesselung_und_Schluesselmanagement.md", "title": "Verschlüsselung und Schlüsselmanagement", "section": "2. Verschlüsselung im Ruhezustand (at rest) (#70)"}, {"id": "05_betrieb/04_Verschluesselung_und_Schluesselmanagement.md", "title": "Verschlüsselung und Schlüsselmanagement", "section": "2. Verschlüsselung im Ruhezustand (at rest) (#70)"}, {"id": "05_betrieb/04_Verschluesselung_und_Schluesselmanagement.md", "title": "Verschlüsselung und Schlüsselmanagement", "section": "3. Verarbeitung bei LLM-Providern (in use)"}, {"id": "05_betrieb/04_Verschluesselung_und_Schluesselmanagement.md", "title": "Verschlüsselung und Schlüsselmanagement", "section": "3. Verarbeitung bei LLM-Providern (in use)"}, {"id": "05_betrieb/04_Verschluesselung_und_Schluesselmanagement.md", "title": "Verschlüsselung und Schlüsselmanagement", "section": "4. Schlüsselmanagement-Modelle (#43–46, #71)"}, {"id": "05_betrieb/04_Verschluesselung_und_Schluesselmanagement.md", "title": "Verschlüsselung und Schlüsselmanagement", "section": "4. Schlüsselmanagement-Modelle (#43–46, #71)"}, {"id": "05_betrieb/04_Verschluesselung_und_Schluesselmanagement.md", "title": "Verschlüsselung und Schlüsselmanagement", "section": "4. Schlüsselmanagement-Modelle (#43–46, #71)"}, {"id": "05_betrieb/04_Verschluesselung_und_Schluesselmanagement.md", "title": "Verschlüsselung und Schlüsselmanagement", "section": "4. Schlüsselmanagement-Modelle (#43–46, #71)"}, {"id": "05_betrieb/04_Verschluesselung_und_Schluesselmanagement.md", "title": "Verschlüsselung und Schlüsselmanagement", "section": "5. Schlüssellebenszyklus (#72)"}, {"id": "05_betrieb/04_Verschluesselung_und_Schluesselmanagement.md", "title": "Verschlüsselung und Schlüsselmanagement", "section": "5. Schlüssellebenszyklus (#72)"}, {"id": "05_betrieb/04_Verschluesselung_und_Schluesselmanagement.md", "title": "Verschlüsselung und Schlüsselmanagement", "section": "5. Schlüssellebenszyklus (#72)"}, {"id": "05_betrieb/04_Verschluesselung_und_Schluesselmanagement.md", "title": "Verschlüsselung und Schlüsselmanagement", "section": "6. Stand der Umsetzung / Lücken"}, {"id": "05_betrieb/04_Verschluesselung_und_Schluesselmanagement.md", "title": "Verschlüsselung und Schlüsselmanagement", "section": "6. Stand der Umsetzung / Lücken"}, {"id": "05_betrieb/05_Backup_und_Wiederherstellung.md", "title": "Backup und Wiederherstellung", "section": "2.2 Überwachung der Datensicherung"}, {"id": "05_betrieb/05_Backup_und_Wiederherstellung.md", "title": "Backup und Wiederherstellung", "section": "3. Backup-Frequenz und Aufbewahrung"}, {"id": "05_betrieb/05_Backup_und_Wiederherstellung.md", "title": "Backup und Wiederherstellung", "section": "3. Backup-Frequenz und Aufbewahrung"}, {"id": "05_betrieb/05_Backup_und_Wiederherstellung.md", "title": "Backup und Wiederherstellung", "section": "4. Wiederherstellungsziele (RTO/RPO)"}, {"id": "05_betrieb/05_Backup_und_Wiederherstellung.md", "title": "Backup und Wiederherstellung", "section": "4. Wiederherstellungsziele (RTO/RPO)"}, {"id": "05_betrieb/05_Backup_und_Wiederherstellung.md", "title": "Backup und Wiederherstellung", "section": "6. Stand der Umsetzung / Lücken"}, {"id": "05_betrieb/06_Business_Continuity_und_Disaster_Recovery.md", "title": "Business Continuity (BCP) und Disaster Recovery (DRP)", "section": "3. Szenarien und Reaktion"}, {"id": "05_betrieb/06_Business_Continuity_und_Disaster_Recovery.md", "title": "Business Continuity (BCP) und Disaster Recovery (DRP)", "section": "4. Verfügbarkeitsüberwachung (#79)"}, {"id": "05_betrieb/06_Business_Continuity_und_Disaster_Recovery.md", "title": "Business Continuity (BCP) und Disaster Recovery (DRP)", "section": "5. Wiederherstellungsziele"}, {"id": "05_betrieb/06_Business_Continuity_und_Disaster_Recovery.md", "title": "Business Continuity (BCP) und Disaster Recovery (DRP)", "section": "5. Wiederherstellungsziele"}, {"id": "05_betrieb/06_Business_Continuity_und_Disaster_Recovery.md", "title": "Business Continuity (BCP) und Disaster Recovery (DRP)", "section": "6. Geografische Trennung / Backup-Standort"}, {"id": "05_betrieb/06_Business_Continuity_und_Disaster_Recovery.md", "title": "Business Continuity (BCP) und Disaster Recovery (DRP)", "section": "7. Tests und Überprüfung"}, {"id": "05_betrieb/06_Business_Continuity_und_Disaster_Recovery.md", "title": "Business Continuity (BCP) und Disaster Recovery (DRP)", "section": "7. Tests und Überprüfung"}, {"id": "05_betrieb/06_Business_Continuity_und_Disaster_Recovery.md", "title": "Business Continuity (BCP) und Disaster Recovery (DRP)", "section": "9. Stand der Umsetzung / Lücken"}, {"id": "05_betrieb/06_Business_Continuity_und_Disaster_Recovery.md", "title": "Business Continuity (BCP) und Disaster Recovery (DRP)", "section": "9. Stand der Umsetzung / Lücken"}, {"id": "05_betrieb/07_Incident_Response_und_Meldewesen.md", "title": "Incident Response und Meldewesen", "section": "8. Kleines Team — kompensierende Massnahmen"}, {"id": "05_betrieb/07_Incident_Response_und_Meldewesen.md", "title": "Incident Response und Meldewesen", "section": "9. Stand der Umsetzung / Lücken"}, {"id": "05_betrieb/08_Change_Management.md", "title": "Change Management", "section": "3. Frozen Zones und Maintenance Windows (#82)"}, {"id": "05_betrieb/08_Change_Management.md", "title": "Change Management", "section": "4. Standardisierte und sichere Konfiguration (#83)"}, {"id": "05_betrieb/08_Change_Management.md", "title": "Change Management", "section": "4. Standardisierte und sichere Konfiguration (#83)"}, {"id": "05_betrieb/08_Change_Management.md", "title": "Change Management", "section": "6. Stand der Umsetzung / Lücken"}, {"id": "05_betrieb/08_Change_Management.md", "title": "Change Management", "section": "6. Stand der Umsetzung / Lücken"}, {"id": "05_betrieb/09_Patch_Management.md", "title": "Patch Management", "section": "3. Ablauf"}, {"id": "05_betrieb/09_Patch_Management.md", "title": "Patch Management", "section": "5. Stand der Umsetzung / Lücken"}, {"id": "05_betrieb/09_Patch_Management.md", "title": "Patch Management", "section": "5. Stand der Umsetzung / Lücken"}, {"id": "05_betrieb/10_Schwachstellenmanagement.md", "title": "Schwachstellenmanagement", "section": "2. Identifizierungsmethoden (#63)"}, {"id": "05_betrieb/10_Schwachstellenmanagement.md", "title": "Schwachstellenmanagement", "section": "2. Identifizierungsmethoden (#63)"}, {"id": "05_betrieb/10_Schwachstellenmanagement.md", "title": "Schwachstellenmanagement", "section": "2. Identifizierungsmethoden (#63)"}, {"id": "05_betrieb/10_Schwachstellenmanagement.md", "title": "Schwachstellenmanagement", "section": "4. Unabhängige Audits (#54, #59)"}, {"id": "05_betrieb/10_Schwachstellenmanagement.md", "title": "Schwachstellenmanagement", "section": "6. Stand der Umsetzung / Lücken"}, {"id": "05_betrieb/10_Schwachstellenmanagement.md", "title": "Schwachstellenmanagement", "section": "6. Stand der Umsetzung / Lücken"}, {"id": "05_betrieb/11_Logging_und_Monitoring.md", "title": "Logging und Monitoring (Sicherheitsprotokollierung)", "section": "2. Protokollierung des Zugriffs auf Kundendaten (#88, #94)"}, {"id": "05_betrieb/11_Logging_und_Monitoring.md", "title": "Logging und Monitoring (Sicherheitsprotokollierung)", "section": "3. Kundenzugang zu Protokollen (#88)"}, {"id": "05_betrieb/11_Logging_und_Monitoring.md", "title": "Logging und Monitoring (Sicherheitsprotokollierung)", "section": "4. Automatische Analyse und Ereigniserkennung (#89, #90)"}, {"id": "05_betrieb/11_Logging_und_Monitoring.md", "title": "Logging und Monitoring (Sicherheitsprotokollierung)", "section": "4. Automatische Analyse und Ereigniserkennung (#89, #90)"}, {"id": "05_betrieb/11_Logging_und_Monitoring.md", "title": "Logging und Monitoring (Sicherheitsprotokollierung)", "section": "4. Automatische Analyse und Ereigniserkennung (#89, #90)"}, {"id": "05_betrieb/11_Logging_und_Monitoring.md", "title": "Logging und Monitoring (Sicherheitsprotokollierung)", "section": "5. Schutz der Protokolldaten (#91)"}, {"id": "05_betrieb/11_Logging_und_Monitoring.md", "title": "Logging und Monitoring (Sicherheitsprotokollierung)", "section": "6. 7×24-Analyse (#92) und SOC-Schnittstellen (#93)"}, {"id": "05_betrieb/11_Logging_und_Monitoring.md", "title": "Logging und Monitoring (Sicherheitsprotokollierung)", "section": "7. Stand der Umsetzung / Lücken"}, {"id": "05_betrieb/12_Netzwerk_und_Infrastruktursicherheit.md", "title": "Netzwerk- und Infrastruktursicherheit", "section": "1. Härtung und Basiskonfiguration (#95)"}, {"id": "05_betrieb/12_Netzwerk_und_Infrastruktursicherheit.md", "title": "Netzwerk- und Infrastruktursicherheit", "section": "1. Härtung und Basiskonfiguration (#95)"}, {"id": "05_betrieb/12_Netzwerk_und_Infrastruktursicherheit.md", "title": "Netzwerk- und Infrastruktursicherheit", "section": "1. Härtung und Basiskonfiguration (#95)"}, {"id": "05_betrieb/12_Netzwerk_und_Infrastruktursicherheit.md", "title": "Netzwerk- und Infrastruktursicherheit", "section": "2. Netzwerksegmentierung und Mandantentrennung (#96)"}, {"id": "05_betrieb/12_Netzwerk_und_Infrastruktursicherheit.md", "title": "Netzwerk- und Infrastruktursicherheit", "section": "3. Netzwerkschutzmassnahmen (#97)"}, {"id": "05_betrieb/12_Netzwerk_und_Infrastruktursicherheit.md", "title": "Netzwerk- und Infrastruktursicherheit", "section": "3. Netzwerkschutzmassnahmen (#97)"}, {"id": "05_betrieb/12_Netzwerk_und_Infrastruktursicherheit.md", "title": "Netzwerk- und Infrastruktursicherheit", "section": "3. Netzwerkschutzmassnahmen (#97)"}, {"id": "05_betrieb/12_Netzwerk_und_Infrastruktursicherheit.md", "title": "Netzwerk- und Infrastruktursicherheit", "section": "3. Netzwerkschutzmassnahmen (#97)"}, {"id": "05_betrieb/12_Netzwerk_und_Infrastruktursicherheit.md", "title": "Netzwerk- und Infrastruktursicherheit", "section": "4. Schutz vor netzwerkbasierten Angriffen / DDoS (#98)"}, {"id": "05_betrieb/12_Netzwerk_und_Infrastruktursicherheit.md", "title": "Netzwerk- und Infrastruktursicherheit", "section": "4. Schutz vor netzwerkbasierten Angriffen / DDoS (#98)"}, {"id": "05_betrieb/12_Netzwerk_und_Infrastruktursicherheit.md", "title": "Netzwerk- und Infrastruktursicherheit", "section": "5. Physische Sicherheit und Versorgung (#99)"}, {"id": "05_betrieb/12_Netzwerk_und_Infrastruktursicherheit.md", "title": "Netzwerk- und Infrastruktursicherheit", "section": "6. Stand der Umsetzung / Lücken"}, {"id": "05_betrieb/12_Netzwerk_und_Infrastruktursicherheit.md", "title": "Netzwerk- und Infrastruktursicherheit", "section": "6. Stand der Umsetzung / Lücken"}, {"id": "05_betrieb/12_Netzwerk_und_Infrastruktursicherheit.md", "title": "Netzwerk- und Infrastruktursicherheit", "section": "6. Stand der Umsetzung / Lücken"}, {"id": "05_betrieb/13_Datenaufbewahrung_Loeschung_LegalHold.md", "title": "Datenaufbewahrung, Löschung und Legal Hold", "section": "1. Legal Hold (#1)"}, {"id": "05_betrieb/13_Datenaufbewahrung_Loeschung_LegalHold.md", "title": "Datenaufbewahrung, Löschung und Legal Hold", "section": "2. Aufbewahrung und Löschung pro Datenkategorie (#2)"}, {"id": "05_betrieb/13_Datenaufbewahrung_Loeschung_LegalHold.md", "title": "Datenaufbewahrung, Löschung und Legal Hold", "section": "2. Aufbewahrung und Löschung pro Datenkategorie (#2)"}, {"id": "05_betrieb/13_Datenaufbewahrung_Loeschung_LegalHold.md", "title": "Datenaufbewahrung, Löschung und Legal Hold", "section": "2. Aufbewahrung und Löschung pro Datenkategorie (#2)"}, {"id": "05_betrieb/13_Datenaufbewahrung_Loeschung_LegalHold.md", "title": "Datenaufbewahrung, Löschung und Legal Hold", "section": "3. Löschung bei Vertragsende (#38)"}, {"id": "05_betrieb/13_Datenaufbewahrung_Loeschung_LegalHold.md", "title": "Datenaufbewahrung, Löschung und Legal Hold", "section": "3. Löschung bei Vertragsende (#38)"}, {"id": "05_betrieb/13_Datenaufbewahrung_Loeschung_LegalHold.md", "title": "Datenaufbewahrung, Löschung und Legal Hold", "section": "3. Löschung bei Vertragsende (#38)"}, {"id": "05_betrieb/13_Datenaufbewahrung_Loeschung_LegalHold.md", "title": "Datenaufbewahrung, Löschung und Legal Hold", "section": "6. Stand der Umsetzung / Lücken"}, {"id": "05_betrieb/14_Exit_und_Transition.md", "title": "Exit- und Transitionsmanagement (Repatriierung)", "section": "3. Datenexport (#5)"}, {"id": "05_betrieb/14_Exit_und_Transition.md", "title": "Exit- und Transitionsmanagement (Repatriierung)", "section": "7. Stand der Umsetzung / Lücken"}, {"id": "05_betrieb/15_Sichere_Softwareentwicklung_SDLC.md", "title": "Sichere Softwareentwicklung (Secure SDLC)", "section": "2. Sicherheit über den Entwicklungszyklus (#100)"}, {"id": "05_betrieb/15_Sichere_Softwareentwicklung_SDLC.md", "title": "Sichere Softwareentwicklung (Secure SDLC)", "section": "2. Sicherheit über den Entwicklungszyklus (#100)"}, {"id": "05_betrieb/15_Sichere_Softwareentwicklung_SDLC.md", "title": "Sichere Softwareentwicklung (Secure SDLC)", "section": "3. Standards und Frameworks (#101)"}, {"id": "05_betrieb/15_Sichere_Softwareentwicklung_SDLC.md", "title": "Sichere Softwareentwicklung (Secure SDLC)", "section": "3. Standards und Frameworks (#101)"}, {"id": "05_betrieb/15_Sichere_Softwareentwicklung_SDLC.md", "title": "Sichere Softwareentwicklung (Secure SDLC)", "section": "5. Stand der Umsetzung / Lücken"}, {"id": "05_betrieb/15_Sichere_Softwareentwicklung_SDLC.md", "title": "Sichere Softwareentwicklung (Secure SDLC)", "section": "5. Stand der Umsetzung / Lücken"}, {"id": "05_betrieb/16_Kapazitaetsmanagement.md", "title": "Kapazitätsmanagement", "section": "2. IT-Ressourcen-Kapazität"}, {"id": "05_betrieb/16_Kapazitaetsmanagement.md", "title": "Kapazitätsmanagement", "section": "2. IT-Ressourcen-Kapazität"}, {"id": "05_betrieb/16_Kapazitaetsmanagement.md", "title": "Kapazitätsmanagement", "section": "2. IT-Ressourcen-Kapazität"}, {"id": "05_betrieb/16_Kapazitaetsmanagement.md", "title": "Kapazitätsmanagement", "section": "2. IT-Ressourcen-Kapazität"}, {"id": "05_betrieb/16_Kapazitaetsmanagement.md", "title": "Kapazitätsmanagement", "section": "3. Personal-Kapazität (kleines Team)"}, {"id": "05_betrieb/16_Kapazitaetsmanagement.md", "title": "Kapazitätsmanagement", "section": "5. Stand der Umsetzung / Lücken"}, {"id": "05_betrieb/16_Kapazitaetsmanagement.md", "title": "Kapazitätsmanagement", "section": "5. Stand der Umsetzung / Lücken"}, {"id": "05_betrieb/17_Subunternehmer_Management.md", "title": "Subunternehmer- und Unterauftragsverarbeiter-Management", "section": "2. Compliance-Ergänzung zum Inventar (#48, #31)"}, {"id": "05_betrieb/17_Subunternehmer_Management.md", "title": "Subunternehmer- und Unterauftragsverarbeiter-Management", "section": "2. Compliance-Ergänzung zum Inventar (#48, #31)"}, {"id": "05_betrieb/17_Subunternehmer_Management.md", "title": "Subunternehmer- und Unterauftragsverarbeiter-Management", "section": "2. Compliance-Ergänzung zum Inventar (#48, #31)"}, {"id": "05_betrieb/17_Subunternehmer_Management.md", "title": "Subunternehmer- und Unterauftragsverarbeiter-Management", "section": "2. Compliance-Ergänzung zum Inventar (#48, #31)"}, {"id": "05_betrieb/17_Subunternehmer_Management.md", "title": "Subunternehmer- und Unterauftragsverarbeiter-Management", "section": "2. Compliance-Ergänzung zum Inventar (#48, #31)"}, {"id": "05_betrieb/17_Subunternehmer_Management.md", "title": "Subunternehmer- und Unterauftragsverarbeiter-Management", "section": "2. Compliance-Ergänzung zum Inventar (#48, #31)"}, {"id": "05_betrieb/17_Subunternehmer_Management.md", "title": "Subunternehmer- und Unterauftragsverarbeiter-Management", "section": "2. Compliance-Ergänzung zum Inventar (#48, #31)"}, {"id": "05_betrieb/17_Subunternehmer_Management.md", "title": "Subunternehmer- und Unterauftragsverarbeiter-Management", "section": "2. Compliance-Ergänzung zum Inventar (#48, #31)"}, {"id": "05_betrieb/17_Subunternehmer_Management.md", "title": "Subunternehmer- und Unterauftragsverarbeiter-Management", "section": "2. Compliance-Ergänzung zum Inventar (#48, #31)"}, {"id": "05_betrieb/17_Subunternehmer_Management.md", "title": "Subunternehmer- und Unterauftragsverarbeiter-Management", "section": "2. Compliance-Ergänzung zum Inventar (#48, #31)"}, {"id": "05_betrieb/17_Subunternehmer_Management.md", "title": "Subunternehmer- und Unterauftragsverarbeiter-Management", "section": "4. Weitergabe der Pflichten (#53)"}, {"id": "05_betrieb/17_Subunternehmer_Management.md", "title": "Subunternehmer- und Unterauftragsverarbeiter-Management", "section": "5. Sanktionsprüfung"}, {"id": "05_betrieb/17_Subunternehmer_Management.md", "title": "Subunternehmer- und Unterauftragsverarbeiter-Management", "section": "7. Stand der Umsetzung / Lücken"}, {"id": "05_betrieb/17_Subunternehmer_Management.md", "title": "Subunternehmer- und Unterauftragsverarbeiter-Management", "section": "7. Stand der Umsetzung / Lücken"}], "stats": {"docs": 46, "statusCounts": {"entwurf": 23, "unbekannt": 23}, "overdueReviews": 0, "openPendenzen": 13, "overduePendenzen": 0, "generated": "2026-06-11"}, "today": "2026-06-11"};</script>
+<script>window.IMS_DATA = {"docs": [{"id": "00_IMS-Handbuch.md", "path": "00_IMS-Handbuch.md", "chapter": "00", "title": "IMS-Handbuch -- Integriertes Managementsystem PowerOn AG", "filename": "00_IMS-Handbuch.md", "meta": {"docId": "IMS-00", "status": "entwurf", "version": "0.1", "owner": "Patrick Motsch", "approver": "Geschäftsführung PowerOn AG", "approvedDate": "", "nextReview": "2027-06-03", "classification": "intern", "isoRefs": "9001:4-10; 27001:4-10"}, "html": "<h1>IMS-Handbuch -- Integriertes Managementsystem PowerOn AG<\/h1>\n<p>Dachdokument des integrierten Managementsystems (IMS) der PowerOn AG. Das IMS deckt <strong>ISO 9001 (Qualität)<\/strong> und <strong>ISO/IEC 27001 (Informationssicherheit)<\/strong> gemeinsam ab. Beide Normen teilen die High-Level-Structure (Annex SL, Kapitel 4-10); dieses Handbuch und die referenzierten Dokumente bilden ein einziges, doppelt verwendetes Dokumentenset.<\/p>\n<h2>1. Zweck<\/h2>\n<p>Das IMS stellt sicher, dass PowerOn<\/p>\n<ul><li>Produkte und Dienstleistungen in gleichbleibender Qualität liefert (ISO 9001),<\/li><li>Informationen und Kundendaten vertraulich, integer und verfügbar hält (ISO 27001),<\/li><li>gesetzliche, vertragliche und regulatorische Anforderungen erfüllt,<\/li><li>sich kontinuierlich verbessert (KVP) und auditierbar bleibt.<\/li><\/ul>\n<h2>2. Geltungsbereich (Kurzfassung)<\/h2>\n<p>Gesamte PowerOn AG inkl. Entwicklung, Betrieb und Produktmanagement der <strong>PORTA Enterprise KI-Plattform<\/strong> (<code>api.poweron.swiss<\/code>). Vollständige Fassung: <a href=\"01_kontext/geltungsbereich-scope.md\">01_kontext/geltungsbereich-scope.md<\/a>.<\/p>\n<h2>3. Aufbau des IMS (Navigationskarte)<\/h2>\n<table><thead><tr><th>Kapitel (ISO)<\/th><th>Ordner<\/th><th>Inhalt<\/th><\/tr><\/thead><tbody><tr><td>4 Kontext<\/td><td><code>01_kontext/<\/code><\/td><td>Kontext &amp; interessierte Parteien, Geltungsbereich<\/td><\/tr><tr><td>5 Führung<\/td><td><code>02_fuehrung/<\/code><\/td><td>QM-Politik, IS-Politik, Rollen, Organisationsreglement, Personen-Mapping<\/td><\/tr><tr><td>6 Planung<\/td><td><code>03_planung/<\/code><\/td><td>Risikomethodik, Risikoregister, SoA, Ziele/KPI<\/td><\/tr><tr><td>7 Unterstützung<\/td><td><code>04_unterstuetzung/<\/code><\/td><td>Kompetenz/Schulung, Kommunikation, Dokumentenlenkung, Register<\/td><\/tr><tr><td>8 Betrieb + Annex A<\/td><td><code>05_betrieb/<\/code><\/td><td>Operative Prozesse &amp; Sicherheits-Controls<\/td><\/tr><tr><td>9 Bewertung<\/td><td><code>06_bewertung/<\/code><\/td><td>Internes Audit, Management-Review, Monitoring<\/td><\/tr><tr><td>10 Verbesserung<\/td><td><code>07_verbesserung/<\/code><\/td><td>Korrekturmassnahmen/KVP, Massnahmenregister<\/td><\/tr><tr><td>Mappings<\/td><td><code>mappings/<\/code><\/td><td>SoA/Annex-A-, ISO-9001-Klausel-, CACC-Crosswalk<\/td><\/tr><tr><td>Cockpit<\/td><td><code>cockpit/<\/code><\/td><td>HTML-Management-Cockpit (Generator + generierte Datei)<\/td><\/tr><\/tbody><\/table>\n<h2>4. Dokumentenpyramide<\/h2>\n<ol><li><strong>Ebene 1 -- Politiken / Handbuch:<\/strong> dieses Handbuch, QM-Politik, IS-Politik, Geltungsbereich, Ziele.<\/li><li><strong>Ebene 2 -- Verfahren / Prozesse:<\/strong> Risiko, Change, Incident, internes Audit, Management-Review, KVP.<\/li><li><strong>Ebene 3 -- Arbeitsanweisungen / Runbooks:<\/strong> BCM-Runbook, Datenbank-Handling, Deployment.<\/li><li><strong>Ebene 4 -- Records / Nachweise:<\/strong> Risikoregister, Audit-Berichte, Schulungsnachweise, Logs, Massnahmenregister.<\/li><\/ol>\n<h2>5. Verantwortung der obersten Leitung<\/h2>\n<p>Die Geschäftsführung verpflichtet sich zum Aufbau, Betrieb und zur kontinuierlichen Verbesserung des IMS, stellt die erforderlichen Ressourcen bereit, gibt die Politiken frei und führt das Management-Review durch (Details: <a href=\"02_fuehrung/\">Führung<\/a>, <a href=\"06_bewertung/management-review.md\">Management-Review<\/a>).<\/p>\n<h2>6. Dokumentenlenkung<\/h2>\n<p>Alle gelenkten Dokumente tragen einen einheitlichen Metadaten-Header und werden über Git/Forgejo versioniert und per Pull-Request-Review freigegeben. Verfahren: <a href=\"04_unterstuetzung/dokumentenlenkung.md\">04_unterstützung/dokumentenlenkung.md<\/a>. Zentrale Übersicht: <a href=\"04_unterstuetzung/dokumentenregister.md\">04_unterstützung/dokumentenregister.md<\/a>.<\/p>\n<h2>7. Status des IMS<\/h2>\n<p>Aufbauphase (Fast-Track). Ziel: ein gelebtes, audit-reifes IMS; Auswahl der Zertifizierungsstelle ist bewusst nachgelagert. Offene Punkte werden im <a href=\"07_verbesserung/massnahmen-register.md\">Massnahmenregister<\/a> geführt.<\/p>", "text": "<!-- docid: ims-00 --> <!-- status: entwurf --> <!-- version: 0.1 --> <!-- owner: patrick motsch --> <!-- approver: geschäftsführung poweron ag --> <!-- approveddate: --> <!-- nextreview: 2027-06-03 --> <!-- classification: intern --> <!-- isorefs: 9001:4-10; 27001:4-10 --> # ims-handbuch -- integriertes managementsystem poweron ag dachdokument des integrierten managementsystems (ims) der poweron ag. das ims deckt **iso 9001 (qualität)** und **iso/iec 27001 (informationssicherheit)** gemeinsam ab. beide normen teilen die high-level-structure (annex sl, kapitel 4-10); dieses handbuch und die referenzierten dokumente bilden ein einziges, doppelt verwendetes dokumentenset. ## 1. zweck das ims stellt sicher, dass poweron - produkte und dienstleistungen in gleichbleibender qualität liefert (iso 9001), - informationen und kundendaten vertraulich, integer und verfügbar hält (iso 27001), - gesetzliche, vertragliche und regulatorische anforderungen erfüllt, - sich kontinuierlich verbessert (kvp) und auditierbar bleibt. ## 2. geltungsbereich (kurzfassung) gesamte poweron ag inkl. entwicklung, betrieb und produktmanagement der **porta enterprise ki-plattform** (`api.poweron.swiss`). vollständige fassung: [01_kontext/geltungsbereich-scope.md](01_kontext/geltungsbereich-scope.md). ## 3. aufbau des ims (navigationskarte) | kapitel (iso) | ordner | inhalt | |---|---|---| | 4 kontext | `01_kontext/` | kontext & interessierte parteien, geltungsbereich | | 5 führung | `02_fuehrung/` | qm-politik, is-politik, rollen, organisationsreglement, personen-mapping | | 6 planung | `03_planung/` | risikomethodik, risikoregister, soa, ziele/kpi | | 7 unterstützung | `04_unterstuetzung/` | kompetenz/schulung, kommunikation, dokumentenlenkung, register | | 8 betrieb + annex a | `05_betrieb/` | operative prozesse & sicherheits-controls | | 9 bewertung | `06_bewertung/` | internes audit, management-review, monitoring | | 10 verbesserung | `07_verbesserung/` | korrekturmassnahmen/kvp, massnahmenregister | | mappings | `mappings/` | soa/annex-a-, iso-9001-klausel-, cacc-crosswalk | | cockpit | `cockpit/` | html-management-cockpit (generator + generierte datei) | ## 4. dokumentenpyramide 1. **ebene 1 -- politiken / handbuch:** dieses handbuch, qm-politik, is-politik, geltungsbereich, ziele. 2. **ebene 2 -- verfahren / prozesse:** risiko, change, incident, internes audit, management-review, kvp. 3. **ebene 3 -- arbeitsanweisungen / runbooks:** bcm-runbook, datenbank-handling, deployment. 4. **ebene 4 -- records / nachweise:** risikoregister, audit-berichte, schulungsnachweise, logs, massnahmenregister. ## 5. verantwortung der obersten leitung die geschäftsführung verpflichtet sich zum aufbau, betrieb und zur kontinuierlichen verbesserung des ims, stellt die erforderlichen ressourcen bereit, gibt die politiken frei und führt das management-review durch (details: [führung](02_fuehrung/), [management-review](06_bewertung/management-review.md)). ## 6. dokumentenlenkung alle gelenkten dokumente tragen einen einheitlichen metadaten-header und werden über git/forgejo versioniert und per pull-request-review freigegeben. verfahren: [04_unterstützung/dokumentenlenkung.md](04_unterstuetzung/dokumentenlenkung.md). zentrale übersicht: [04_unterstützung/dokumentenregister.md](04_unterstuetzung/dokumentenregister.md). ## 7. status des ims aufbauphase (fast-track). ziel: ein gelebtes, audit-reifes ims; auswahl der zertifizierungsstelle ist bewusst nachgelagert. offene punkte werden im [massnahmenregister](07_verbesserung/massnahmen-register.md) geführt. ", "nextReview": "2027-06-03", "overdueReview": false, "zuPruefen": []}, {"id": "01_kontext/geltungsbereich-scope.md", "path": "01_kontext/geltungsbereich-scope.md", "chapter": "01_kontext", "title": "Geltungsbereich (Scope) des IMS", "filename": "geltungsbereich-scope.md", "meta": {"docId": "IMS-04-02", "status": "entwurf", "version": "0.1", "owner": "Patrick Motsch", "approver": "Geschäftsführung PowerOn AG", "approvedDate": "", "nextReview": "2027-06-03", "classification": "intern", "isoRefs": "9001:4.3-4.4; 27001:4.3"}, "html": "<h1>Geltungsbereich (Scope) des IMS<\/h1>\n<p><strong>Dokumenttyp:<\/strong> Grundlagendokument (Pflichtdokument ISO 9001 4.3 / ISO 27001 4.3)<\/p>\n<h2>1. Scope-Statement<\/h2>\n<blockquote>Das integrierte Managementsystem der PowerOn AG umfasst die <strong>Entwicklung, den Betrieb, das Produktmanagement und den Support der PORTA Enterprise KI-Plattform<\/strong> (Multi-Tenant-SaaS, <code>api.poweron.swiss<\/code>) sowie die zugehörigen unterstützenden Prozesse der gesamten PowerOn AG.  Es deckt <strong>ISO 9001:2015<\/strong> (Qualitätsmanagement) und <strong>ISO/IEC 27001:2022<\/strong> (Informationssicherheit) ab.<\/blockquote>\n<h2>2. Eingeschlossen<\/h2>\n<ul><li>Software-Entwicklung (SDLC), Release- und Change-Management.<\/li><li>Betrieb der Plattform auf Infomaniak Public Cloud (Schweiz): <code>api.poweron.swiss<\/code>, <code>db.poweron.swiss<\/code>.<\/li><li>Entwicklungs-/Deployment-System (Forgejo, CI/CD).<\/li><li>Produktmanagement, Anforderungsmanagement, Kundensupport.<\/li><li>Verwaltung von Drittdiensten/Subunternehmern (inkl. externe LLM-Provider).<\/li><li>Unterstützungsprozesse: Personal/Kompetenz, Beschaffung, IT-Sicherheit, Dokumentenlenkung.<\/li><\/ul>\n<h2>3. Standorte und Mittel<\/h2>\n<ul><li>Cloud-Infrastruktur: Infomaniak (Schweiz).<\/li><li>Verteiltes Klein-Team; Arbeitsmittel und Remote-Zugriff gemäss <a href=\"../05_betrieb/02_Zugriffsmanagement_IAM_PAM.md\">Zugriffsmanagement<\/a>.<\/li><\/ul>\n<h2>4. Schnittstellen und Abhängigkeiten<\/h2>\n<ul><li>Externe LLM-Provider (Primär OpenAI/USA) -- Inhaltsdaten verlassen zur KI-Verarbeitung die Schweiz; abgesichert über AVV/DPA + EU-SCC und Neutralisierung. Siehe <a href=\"../05_betrieb/20260528_drittanbieter-inventar.md\">Drittanbieter-Inventar<\/a>.<\/li><li>Authentifizierungs-Dienste (Microsoft Entra, Google), E-Mail-Dienste.<\/li><\/ul>\n<h2>5. Ausschlüsse / Nichtanwendbarkeit<\/h2>\n<ul><li>ISO 9001 Kap. 8.3 (Entwicklung) ist <strong>anwendbar<\/strong> (PowerOn entwickelt eigenes Produkt) -- kein Ausschluss.<\/li><li>Annex-A-Controls von ISO 27001 werden nicht pauschal ausgeschlossen; Nichtanwendbarkeit wird einzeln im <a href=\"../03_planung/statement-of-applicability-soa.md\">SoA<\/a> begründet (z. B. rein physische Rechenzentrums-Controls, die beim Cloud-Provider liegen).<\/li><\/ul>\n<h2>6. Begründung kompensierender Massnahmen<\/h2>\n<p>Aufgrund der kleinen Teamgrösse ist eine vollständige Funktionstrennung nicht überall möglich. Wo Controls eine grössere Organisation voraussetzen, greifen kompensierende Massnahmen (Vier-Augen-Prinzip bei Releases, Protokollierung privilegierter Zugriffe, externe Vergabe des internen Audits). Diese sind in den jeweiligen Betriebsdokumenten und im SoA dokumentiert.<\/p>", "text": "<!-- docid: ims-04-02 --> <!-- status: entwurf --> <!-- version: 0.1 --> <!-- owner: patrick motsch --> <!-- approver: geschäftsführung poweron ag --> <!-- approveddate: --> <!-- nextreview: 2027-06-03 --> <!-- classification: intern --> <!-- isorefs: 9001:4.3-4.4; 27001:4.3 --> # geltungsbereich (scope) des ims **dokumenttyp:** grundlagendokument (pflichtdokument iso 9001 4.3 / iso 27001 4.3) ## 1. scope-statement > das integrierte managementsystem der poweron ag umfasst die **entwicklung, den betrieb, das produktmanagement und den support der porta enterprise ki-plattform** (multi-tenant-saas, `api.poweron.swiss`) sowie die zugehörigen unterstützenden prozesse der gesamten poweron ag. > > es deckt **iso 9001:2015** (qualitätsmanagement) und **iso/iec 27001:2022** (informationssicherheit) ab. ## 2. eingeschlossen - software-entwicklung (sdlc), release- und change-management. - betrieb der plattform auf infomaniak public cloud (schweiz): `api.poweron.swiss`, `db.poweron.swiss`. - entwicklungs-/deployment-system (forgejo, ci/cd). - produktmanagement, anforderungsmanagement, kundensupport. - verwaltung von drittdiensten/subunternehmern (inkl. externe llm-provider). - unterstützungsprozesse: personal/kompetenz, beschaffung, it-sicherheit, dokumentenlenkung. ## 3. standorte und mittel - cloud-infrastruktur: infomaniak (schweiz). - verteiltes klein-team; arbeitsmittel und remote-zugriff gemäss [zugriffsmanagement](../05_betrieb/02_zugriffsmanagement_iam_pam.md). ## 4. schnittstellen und abhängigkeiten - externe llm-provider (primär openai/usa) -- inhaltsdaten verlassen zur ki-verarbeitung die schweiz; abgesichert über avv/dpa + eu-scc und neutralisierung. siehe [drittanbieter-inventar](../05_betrieb/20260528_drittanbieter-inventar.md). - authentifizierungs-dienste (microsoft entra, google), e-mail-dienste. ## 5. ausschlüsse / nichtanwendbarkeit - iso 9001 kap. 8.3 (entwicklung) ist **anwendbar** (poweron entwickelt eigenes produkt) -- kein ausschluss. - annex-a-controls von iso 27001 werden nicht pauschal ausgeschlossen; nichtanwendbarkeit wird einzeln im [soa](../03_planung/statement-of-applicability-soa.md) begründet (z. b. rein physische rechenzentrums-controls, die beim cloud-provider liegen). ## 6. begründung kompensierender massnahmen aufgrund der kleinen teamgrösse ist eine vollständige funktionstrennung nicht überall möglich. wo controls eine grössere organisation voraussetzen, greifen kompensierende massnahmen (vier-augen-prinzip bei releases, protokollierung privilegierter zugriffe, externe vergabe des internen audits). diese sind in den jeweiligen betriebsdokumenten und im soa dokumentiert. ", "nextReview": "2027-06-03", "overdueReview": false, "zuPruefen": []}, {"id": "01_kontext/kontext-und-interessierte-parteien.md", "path": "01_kontext/kontext-und-interessierte-parteien.md", "chapter": "01_kontext", "title": "Kontext der Organisation & interessierte Parteien", "filename": "kontext-und-interessierte-parteien.md", "meta": {"docId": "IMS-04-01", "status": "entwurf", "version": "0.1", "owner": "Patrick Motsch", "approver": "Geschäftsführung PowerOn AG", "approvedDate": "", "nextReview": "2027-06-03", "classification": "intern", "isoRefs": "9001:4.1-4.2; 27001:4.1-4.2"}, "html": "<h1>Kontext der Organisation &amp; interessierte Parteien<\/h1>\n<p><strong>Dokumenttyp:<\/strong> Grundlagendokument ISO 9001 / 27001 Kap. 4.1-4.2: Bestimmung des organisatorischen Kontexts und der relevanten interessierten Parteien samt deren Anforderungen.<\/p>\n<h2>1. Organisation<\/h2>\n<p>PowerOn AG ist ein Schweizer Software-Unternehmen und betreibt die <strong>PORTA Enterprise KI-Plattform<\/strong> -- eine Multi-Tenant-SaaS-Lösung mit Feature-Store-Modell, AI-Agent-Workspace und mandantenweiter Datenneutralisierung. Zielkunden sind mittlere bis grosse Unternehmen in datenschutzsensiblen Branchen (Finanzwesen, Treuhand, Immobilien, Beratung). Sehr kleines Team (2-5 Personen).<\/p>\n<h2>2. Externe Themen (Kontext)<\/h2>\n<ul><li>Regulatorik: CH nDSG/revDSG, EU-DSGVO, für Bankkunden FINMA-Rundschreiben 2018/3 &amp; 2023/1, GLKB Cloud Assessment (CACC).<\/li><li>Markt: hohe Erwartung an Datensouveränität (CH-Hosting), KI-Transparenz, Nachweisbarkeit (ISO 27001/9001 als Einkaufskriterium).<\/li><li>Technologie: Abhängigkeit von externen LLM-Providern (OpenAI USA u. a.), Cloud-Hosting Infomaniak (CH).<\/li><li>Bedrohungslage: Web-/Cloud-Angriffe, Lieferkettenrisiken, KI-spezifische Risiken (Prompt-Injection, Datenabfluss).<\/li><\/ul>\n<h2>3. Interne Themen (Kontext)<\/h2>\n<ul><li>Kleines Team -&gt; Rollenbuendelung, eingeschränkte Funktionstrennung (kompensierende Massnahmen).<\/li><li>Hoher Automatisierungsgrad (Forgejo CI/CD, Infrastruktur, Wiki-basierte Doku).<\/li><li>Wissenskonzentration auf wenige Personen (Schlüsselpersonenrisiko).<\/li><\/ul>\n<h2>4. Interessierte Parteien und Anforderungen<\/h2>\n<table><thead><tr><th>Interessierte Partei<\/th><th>Wesentliche Anforderungen<\/th><\/tr><\/thead><tbody><tr><td>Kunden (inkl. Banken/Treuhänder)<\/td><td>Datenschutz, Vertraulichkeit, Verfügbarkeit (SLA), Nachweise/Zertifikate, Auditierbarkeit<\/td><\/tr><tr><td>Endnutzer<\/td><td>Funktionierende, sichere, performante Plattform; Datenschutzrechte<\/td><\/tr><tr><td>Geschäftsführung/Eigner<\/td><td>Wirtschaftlichkeit, Reputation, Compliance, beherrschbares Risiko<\/td><\/tr><tr><td>Mitarbeitende<\/td><td>Klare Prozesse, sichere Arbeitsmittel, Kompetenzentwicklung<\/td><\/tr><tr><td>Aufsicht/Regulatoren<\/td><td>Einhaltung Datenschutz- und Finanzmarktvorgaben<\/td><\/tr><tr><td>Lieferanten/Subunternehmer<\/td><td>Klare Verträge, AVVs, Sicherheitsanforderungen<\/td><\/tr><tr><td>Zertifizierungsstelle<\/td><td>Normkonformes, gelebtes, nachweisbares Managementsystem<\/td><\/tr><\/tbody><\/table>\n<h2>5. Geltungsbereich des IMS<\/h2>\n<p>Festlegung in <a href=\"geltungsbereich-scope.md\">geltungsbereich-scope.md<\/a>.<\/p>\n<h2>6. Wesentliche Prozesse (Prozesslandkarte)<\/h2>\n<pre class=\"mermaid\">flowchart LR\n    subgraph fuehrung [Führungsprozesse]\n        F1[\"Strategie &amp; Management-Review\"]\n        F2[\"Risiko- &amp; Compliance-Management\"]\n    end\n    subgraph kern [Kernprozesse]\n        K1[\"Produktmanagement &amp; Anforderungen\"]\n        K2[\"Software-Entwicklung (SDLC)\"]\n        K3[\"Release &amp; Change Management\"]\n        K4[\"Betrieb &amp; Support der PORTA-Plattform\"]\n    end\n    subgraph support [Unterstützungsprozesse]\n        S1[\"Beschaffung &amp; Lieferanten\"]\n        S2[\"Personal &amp; Kompetenz\"]\n        S3[\"IT-Sicherheit &amp; Infrastruktur\"]\n        S4[\"Dokumentenlenkung\"]\n    end\n    F1 --&gt; K1 --&gt; K2 --&gt; K3 --&gt; K4\n    F2 --&gt; K2\n    support --&gt; kern<\/pre>", "text": "<!-- docid: ims-04-01 --> <!-- status: entwurf --> <!-- version: 0.1 --> <!-- owner: patrick motsch --> <!-- approver: geschäftsführung poweron ag --> <!-- approveddate: --> <!-- nextreview: 2027-06-03 --> <!-- classification: intern --> <!-- isorefs: 9001:4.1-4.2; 27001:4.1-4.2 --> # kontext der organisation & interessierte parteien **dokumenttyp:** grundlagendokument iso 9001 / 27001 kap. 4.1-4.2: bestimmung des organisatorischen kontexts und der relevanten interessierten parteien samt deren anforderungen. ## 1. organisation poweron ag ist ein schweizer software-unternehmen und betreibt die **porta enterprise ki-plattform** -- eine multi-tenant-saas-lösung mit feature-store-modell, ai-agent-workspace und mandantenweiter datenneutralisierung. zielkunden sind mittlere bis grosse unternehmen in datenschutzsensiblen branchen (finanzwesen, treuhand, immobilien, beratung). sehr kleines team (2-5 personen). ## 2. externe themen (kontext) - regulatorik: ch ndsg/revdsg, eu-dsgvo, für bankkunden finma-rundschreiben 2018/3 & 2023/1, glkb cloud assessment (cacc). - markt: hohe erwartung an datensouveränität (ch-hosting), ki-transparenz, nachweisbarkeit (iso 27001/9001 als einkaufskriterium). - technologie: abhängigkeit von externen llm-providern (openai usa u. a.), cloud-hosting infomaniak (ch). - bedrohungslage: web-/cloud-angriffe, lieferkettenrisiken, ki-spezifische risiken (prompt-injection, datenabfluss). ## 3. interne themen (kontext) - kleines team -> rollenbuendelung, eingeschränkte funktionstrennung (kompensierende massnahmen). - hoher automatisierungsgrad (forgejo ci/cd, infrastruktur, wiki-basierte doku). - wissenskonzentration auf wenige personen (schlüsselpersonenrisiko). ## 4. interessierte parteien und anforderungen | interessierte partei | wesentliche anforderungen | |---|---| | kunden (inkl. banken/treuhänder) | datenschutz, vertraulichkeit, verfügbarkeit (sla), nachweise/zertifikate, auditierbarkeit | | endnutzer | funktionierende, sichere, performante plattform; datenschutzrechte | | geschäftsführung/eigner | wirtschaftlichkeit, reputation, compliance, beherrschbares risiko | | mitarbeitende | klare prozesse, sichere arbeitsmittel, kompetenzentwicklung | | aufsicht/regulatoren | einhaltung datenschutz- und finanzmarktvorgaben | | lieferanten/subunternehmer | klare verträge, avvs, sicherheitsanforderungen | | zertifizierungsstelle | normkonformes, gelebtes, nachweisbares managementsystem | ## 5. geltungsbereich des ims festlegung in [geltungsbereich-scope.md](geltungsbereich-scope.md). ## 6. wesentliche prozesse (prozesslandkarte) ```mermaid flowchart lr subgraph fuehrung [führungsprozesse] f1[\"strategie & management-review\"] f2[\"risiko- & compliance-management\"] end subgraph kern [kernprozesse] k1[\"produktmanagement & anforderungen\"] k2[\"software-entwicklung (sdlc)\"] k3[\"release & change management\"] k4[\"betrieb & support der porta-plattform\"] end subgraph support [unterstützungsprozesse] s1[\"beschaffung & lieferanten\"] s2[\"personal & kompetenz\"] s3[\"it-sicherheit & infrastruktur\"] s4[\"dokumentenlenkung\"] end f1 --> k1 --> k2 --> k3 --> k4 f2 --> k2 support --> kern ``` ", "nextReview": "2027-06-03", "overdueReview": false, "zuPruefen": []}, {"id": "02_fuehrung/informationssicherheitspolitik.md", "path": "02_fuehrung/informationssicherheitspolitik.md", "chapter": "02_fuehrung", "title": "Informationssicherheitsrichtlinie (ISMS-Dachdokument)", "filename": "informationssicherheitspolitik.md", "meta": {"docId": "IMS-05-02", "status": "entwurf", "version": "1.0", "owner": "Patrick Motsch", "approver": "Geschäftsführung PowerOn AG", "approvedDate": "", "nextReview": "2027-06-03", "classification": "intern", "isoRefs": "27001:5.2,5.1; 9001:5.2"}, "html": "<h1>Informationssicherheitsrichtlinie (ISMS-Dachdokument)<\/h1>\n<p><strong>Dokumenttyp:<\/strong> Richtlinie <strong>Geltungsbereich:<\/strong> PORTA Enterprise KI-Plattform, gesamte PowerOn AG <strong>Version:<\/strong> 1.0 <strong>Status:<\/strong> Entwurf zur internen Freigabe <strong>Owner:<\/strong> Geschäftsführung PowerOn AG <strong>Letzte Aktualisierung:<\/strong> 02.06.2026 <strong>Deckt ab (CACC):<\/strong> 49, 52, 56<\/p>\n<hr>\n<h2>1. Zweck und Geltungsbereich<\/h2>\n<p>Diese Richtlinie definiert die grundlegenden Vorgaben, Prinzipien und Verantwortlichkeiten für die Informationssicherheit bei PowerOn. Sie ist das Dachdokument des Informationssicherheits-Managementsystems (ISMS) und verweist auf die detaillierten Einzelprozesse.<\/p>\n<p>Der Geltungsbereich umfasst alle Systeme, Daten, Mitarbeitenden und Dienstleister, die an der Bereitstellung der PORTA-Plattform beteiligt sind — insbesondere die Infrastruktur bei Infomaniak (<code>api.poweron.swiss<\/code>, <code>db.poweron.swiss<\/code>), das Forgejo-basierte Entwicklungs- und Deployment-System sowie alle im Drittanbieter-Inventar gelisteten externen Dienste.<\/p>\n<h2>2. Sicherheitsziele<\/h2>\n<p>PowerOn verfolgt die klassischen Schutzziele der Informationssicherheit:<\/p>\n<ul><li><strong>Vertraulichkeit:<\/strong> Kundendaten (Inhaltsdaten, insbesondere Berufsgeheimnisdaten) sind nur autorisierten Personen und Prozessen zugänglich.<\/li><li><strong>Integrität:<\/strong> Daten und Systeme sind vor unbefugter oder unbeabsichtigter Veränderung geschützt.<\/li><li><strong>Verfügbarkeit:<\/strong> Die Plattform und die Kundendaten stehen im Rahmen der vereinbarten Service Levels zur Verfügung.<\/li><li><strong>Nachvollziehbarkeit:<\/strong> Zugriffe und Änderungen an kritischen Systemen sind protokolliert und auditierbar.<\/li><\/ul>\n<h2>3. Organisation und Verantwortlichkeiten<\/h2>\n<p>Aufgrund der kleinen Teamgrösse (2–5 Personen) werden Rollen gebündelt. Eine vollständige Funktionstrennung ist nicht in allen Bereichen möglich; wo sie fehlt, greifen kompensierende Massnahmen (Vier-Augen-Prinzip bei Releases, Protokollierung privilegierter Zugriffe).<\/p>\n<table><thead><tr><th>Rolle<\/th><th>Verantwortung<\/th><th>Träger<\/th><\/tr><\/thead><tbody><tr><td>Informationssicherheits-Verantwortlicher (ISO/CISO-Funktion)<\/td><td>Pflege des ISMS, Risikobeurteilung, Richtlinienfreigabe<\/td><td>Patrick Motsch (p.motsch@poweron.swiss)<\/td><\/tr><tr><td>Datenschutzverantwortlicher<\/td><td>Einhaltung DSG/DSGVO, AVV-Management<\/td><td>Patrick Motsch (p.motsch@poweron.swiss)<\/td><\/tr><tr><td>Drittdienst-Verantwortlicher<\/td><td>Verwaltung externer Dienste, Subunternehmer<\/td><td>Patrick Motsch (p.motsch@poweron.swiss)<\/td><\/tr><tr><td>Betrieb / DevOps<\/td><td>Server, Deployment, Backups, Incident-Handling<\/td><td>Patrick Motsch (p.motsch@poweron.swiss)<\/td><\/tr><tr><td>Geschäftsführung<\/td><td>Gesamtverantwortung, Freigabe Richtlinien<\/td><td>Patrick Motsch (p.motsch@poweron.swiss)<\/td><\/tr><\/tbody><\/table>\n<h2>4. Grundsätze<\/h2>\n<ol><li><strong>Need-to-Know &amp; Least Privilege:<\/strong> Zugriff nur im erforderlichen Umfang (Details: <code>02_Zugriffsmanagement_IAM_PAM.md<\/code>).<\/li><li><strong>Sichere Standardkonfiguration:<\/strong> Systeme werden nach anerkannten Standards gehärtet (Details: <code>12_Netzwerk_und_Infrastruktursicherheit.md<\/code>).<\/li><li><strong>Verschlüsselung:<\/strong> Daten werden bei Übertragung und Speicherung verschlüsselt (Details: <code>04_Verschluesselung_und_Schluesselmanagement.md<\/code>).<\/li><li><strong>Nachvollziehbare Änderungen:<\/strong> Alle Produktivänderungen durchlaufen den Change-Prozess (Details: <code>08_Change_Management.md<\/code>).<\/li><li><strong>Vorfallreaktion:<\/strong> Sicherheitsvorfälle werden klassifiziert, behoben und gemeldet (Details: <code>07_Incident_Response_und_Meldewesen.md<\/code>).<\/li><\/ol>\n<h2>5. Risikomanagement<\/h2>\n<p>PowerOn führt mindestens jährlich sowie anlassbezogen (z. B. bei wesentlichen Architekturänderungen) eine Risikobeurteilung der für Kunden relevanten Systeme durch. Identifizierte Risiken werden bewertet (Eintrittswahrscheinlichkeit × Auswirkung), behandelt (vermeiden / vermindern / übertragen / akzeptieren) und dokumentiert. Ergebnisse werden auf Anfrage berechtigten Kunden und Prüfern offengelegt.<\/p>\n<h2>6. Verbindlichkeit und Schulung<\/h2>\n<p>Diese Richtlinie ist für alle Mitarbeitenden und Hilfspersonen verbindlich. Neue Mitarbeitende werden im Onboarding auf die Richtlinie verpflichtet; eine Auffrischung erfolgt jährlich (siehe <code>03_Mitarbeitersicherheit_und_Screening.md<\/code>).<\/p>\n<h2>7. Überprüfung<\/h2>\n<p>Die Richtlinie wird mindestens jährlich sowie bei wesentlichen Änderungen überprüft und durch die Geschäftsführung freigegeben.<\/p>\n<h2>8. Stand der Umsetzung / Lücken<\/h2>\n<table><thead><tr><th>Thema<\/th><th>Status<\/th><th>Geplante Massnahme<\/th><\/tr><\/thead><tbody><tr><td>ISMS nach ISO/IEC 27001 zertifiziert<\/td><td>Nicht vorhanden<\/td><td>[ZU PRÜFEN: Zertifizierung geplant? Zeithorizont?]<\/td><\/tr><tr><td>Dokumentierte Rollenzuteilung<\/td><td>In Arbeit (dieses Dokument)<\/td><td>Namentliche Zuordnung ergänzen<\/td><\/tr><tr><td>Jährliche Risikobeurteilung<\/td><td>[ZU PRÜFEN]<\/td><td>Erstdurchführung terminieren<\/td><\/tr><\/tbody><\/table>", "text": "<!-- docid: ims-05-02 --> <!-- status: entwurf --> <!-- version: 1.0 --> <!-- owner: patrick motsch --> <!-- approver: geschäftsführung poweron ag --> <!-- approveddate: --> <!-- nextreview: 2027-06-03 --> <!-- classification: intern --> <!-- isorefs: 27001:5.2,5.1; 9001:5.2 --> # informationssicherheitsrichtlinie (isms-dachdokument) **dokumenttyp:** richtlinie **geltungsbereich:** porta enterprise ki-plattform, gesamte poweron ag **version:** 1.0 **status:** entwurf zur internen freigabe **owner:** geschäftsführung poweron ag **letzte aktualisierung:** 02.06.2026 **deckt ab (cacc):** 49, 52, 56 --- ## 1. zweck und geltungsbereich diese richtlinie definiert die grundlegenden vorgaben, prinzipien und verantwortlichkeiten für die informationssicherheit bei poweron. sie ist das dachdokument des informationssicherheits-managementsystems (isms) und verweist auf die detaillierten einzelprozesse. der geltungsbereich umfasst alle systeme, daten, mitarbeitenden und dienstleister, die an der bereitstellung der porta-plattform beteiligt sind — insbesondere die infrastruktur bei infomaniak (`api.poweron.swiss`, `db.poweron.swiss`), das forgejo-basierte entwicklungs- und deployment-system sowie alle im drittanbieter-inventar gelisteten externen dienste. ## 2. sicherheitsziele poweron verfolgt die klassischen schutzziele der informationssicherheit: - **vertraulichkeit:** kundendaten (inhaltsdaten, insbesondere berufsgeheimnisdaten) sind nur autorisierten personen und prozessen zugänglich. - **integrität:** daten und systeme sind vor unbefugter oder unbeabsichtigter veränderung geschützt. - **verfügbarkeit:** die plattform und die kundendaten stehen im rahmen der vereinbarten service levels zur verfügung. - **nachvollziehbarkeit:** zugriffe und änderungen an kritischen systemen sind protokolliert und auditierbar. ## 3. organisation und verantwortlichkeiten aufgrund der kleinen teamgrösse (2–5 personen) werden rollen gebündelt. eine vollständige funktionstrennung ist nicht in allen bereichen möglich; wo sie fehlt, greifen kompensierende massnahmen (vier-augen-prinzip bei releases, protokollierung privilegierter zugriffe). | rolle | verantwortung | träger | |---|---|---| | informationssicherheits-verantwortlicher (iso/ciso-funktion) | pflege des isms, risikobeurteilung, richtlinienfreigabe | patrick motsch (p.motsch@poweron.swiss) | | datenschutzverantwortlicher | einhaltung dsg/dsgvo, avv-management | patrick motsch (p.motsch@poweron.swiss) | | drittdienst-verantwortlicher | verwaltung externer dienste, subunternehmer | patrick motsch (p.motsch@poweron.swiss) | | betrieb / devops | server, deployment, backups, incident-handling | patrick motsch (p.motsch@poweron.swiss) | | geschäftsführung | gesamtverantwortung, freigabe richtlinien | patrick motsch (p.motsch@poweron.swiss) | ## 4. grundsätze 1. **need-to-know & least privilege:** zugriff nur im erforderlichen umfang (details: `02_zugriffsmanagement_iam_pam.md`). 2. **sichere standardkonfiguration:** systeme werden nach anerkannten standards gehärtet (details: `12_netzwerk_und_infrastruktursicherheit.md`). 3. **verschlüsselung:** daten werden bei übertragung und speicherung verschlüsselt (details: `04_verschluesselung_und_schluesselmanagement.md`). 4. **nachvollziehbare änderungen:** alle produktivänderungen durchlaufen den change-prozess (details: `08_change_management.md`). 5. **vorfallreaktion:** sicherheitsvorfälle werden klassifiziert, behoben und gemeldet (details: `07_incident_response_und_meldewesen.md`). ## 5. risikomanagement poweron führt mindestens jährlich sowie anlassbezogen (z. b. bei wesentlichen architekturänderungen) eine risikobeurteilung der für kunden relevanten systeme durch. identifizierte risiken werden bewertet (eintrittswahrscheinlichkeit × auswirkung), behandelt (vermeiden / vermindern / übertragen / akzeptieren) und dokumentiert. ergebnisse werden auf anfrage berechtigten kunden und prüfern offengelegt. ## 6. verbindlichkeit und schulung diese richtlinie ist für alle mitarbeitenden und hilfspersonen verbindlich. neue mitarbeitende werden im onboarding auf die richtlinie verpflichtet; eine auffrischung erfolgt jährlich (siehe `03_mitarbeitersicherheit_und_screening.md`). ## 7. überprüfung die richtlinie wird mindestens jährlich sowie bei wesentlichen änderungen überprüft und durch die geschäftsführung freigegeben. ## 8. stand der umsetzung / lücken | thema | status | geplante massnahme | |---|---|---| | isms nach iso/iec 27001 zertifiziert | nicht vorhanden | [zu prüfen: zertifizierung geplant? zeithorizont?] | | dokumentierte rollenzuteilung | in arbeit (dieses dokument) | namentliche zuordnung ergänzen | | jährliche risikobeurteilung | [zu prüfen] | erstdurchführung terminieren | ", "nextReview": "2027-06-03", "overdueReview": false, "zuPruefen": ["8. Stand der Umsetzung / Lücken", "8. Stand der Umsetzung / Lücken"]}, {"id": "02_fuehrung/organisationsreglement.md", "path": "02_fuehrung/organisationsreglement.md", "chapter": "02_fuehrung", "title": "Organisationsreglement", "filename": "organisationsreglement.md", "meta": {"docId": "IMS-05-04", "status": "entwurf", "version": "0.2", "owner": "Patrick Motsch", "approver": "Geschäftsführung PowerOn AG / Verwaltungsrat", "approvedDate": "", "nextReview": "2027-06-11", "classification": "intern", "isoRefs": "9001:5.1,5.3; 27001:5.1,5.3"}, "html": "<h1>Organisationsreglement<\/h1>\n<p><strong>Dokumenttyp:<\/strong> Grundlagendokument (Führung, operative Organisation)<\/p>\n<p>Regelt die <strong>operative Aufgabenverteilung<\/strong>, <strong>Meetingstruktur<\/strong> und <strong>Kommunikationswege<\/strong> der PowerOn AG. Ergänzt die IMS-Fachrollen in <a href=\"rollen-verantwortlichkeiten.md\">rollen-verantwortlichkeiten.md<\/a>. Personen und VR-Zugehörigkeit: <a href=\"personen-rollen-mapping.md\">Personen-Rollen-Mapping<\/a>.<\/p>\n<h2>1. Zweck<\/h2>\n<ul><li>Entlastung der zentralen Rollenträger (insb. Geschäftsführung und technische Schlüsselpersonen).<\/li><li>Klare Verantwortlichkeiten in Entwicklung, Betrieb, Vertrieb und Verwaltung.<\/li><li>Strukturierte Kommunikation zwischen Operations, Strategie und Verwaltungsrat.<\/li><\/ul>\n<h2>2. Ziele<\/h2>\n<table><thead><tr><th>Ziel<\/th><th>Beschreibung<\/th><\/tr><\/thead><tbody><tr><td>Entlastung Geschäftsführung<\/td><td>Fokus auf Roadmap Entwicklung, Personalplanung und operative Entscheidungsprozesse<\/td><\/tr><tr><td>Entlastung Leiter Strategie &amp; Kapital<\/td><td>Fokus auf Strategie, Growth und Investoren/Kapitalbeschaffung<\/td><\/tr><tr><td>Entlastung Leiter Vertrieb &amp; Support Operations<\/td><td>Fokus auf Network, Sales und Support Operations<\/td><\/tr><tr><td>Struktur &amp; Kommunikation<\/td><td>Regelmässige, thematisch getrennte Meetings mit klarer Moderation<\/td><\/tr><\/tbody><\/table>\n<h2>3. Aufgabenverteilung (operativ)<\/h2>\n<table><thead><tr><th>Rolle<\/th><th>Code<\/th><th>Amtsinhaber<\/th><th>VR<\/th><th>Schwerpunkt<\/th><\/tr><\/thead><tbody><tr><td><strong>Geschäftsführung<\/strong><\/td><td>GF<\/td><td>Patrick Motsch<\/td><td>ja<\/td><td>Roadmap Entwicklung, Personalplanung, operative Entscheidungsfindung; CEO, CTO; IMS-Fachrollen gebündelt<\/td><\/tr><tr><td><strong>Leiter Vertrieb &amp; Support Operations<\/strong><\/td><td>VSO<\/td><td>Dominic Largo<\/td><td>ja<\/td><td>Network, Sales, Unterstützung Business Development &amp; Support Operations<\/td><\/tr><tr><td><strong>Leiter Strategie &amp; Kapital<\/strong><\/td><td>SK<\/td><td>Philipp Graf<\/td><td>ja<\/td><td>Strategie, Support Growth Management, Lead Invest-Themen / Kapitalbeschaffung<\/td><\/tr><tr><td><strong>Finanzen und Treuhand<\/strong><\/td><td>FT<\/td><td>Silvan Winiger<\/td><td>ja<\/td><td>Treuhänderische &amp; buchhalterische Leistungen, Testing, Akquise<\/td><\/tr><tr><td><strong>Leiter operative Koordination und Produktmarketing<\/strong><\/td><td>OP<\/td><td>Chris Winiger<\/td><td>nein<\/td><td>Business Development, organisatorische Führung und Koordination, Produktmarketing; Bindeglied zwischen Operations, Entwicklung, Akquise und Kundenbetreuung; Entlastung der Geschäftsführung im Tagesgeschäft<\/td><\/tr><\/tbody><\/table>\n<h3>3.1 Weitere Mitarbeitende PowerOn AG<\/h3>\n<table><thead><tr><th>Name<\/th><th>Funktion<\/th><\/tr><\/thead><tbody><tr><td>Stephan Schellworth<\/td><td>Mitarbeitender<\/td><\/tr><tr><td>Ida Dittrich<\/td><td>Mitarbeitende<\/td><\/tr><\/tbody><\/table>\n<h2>4. Meetingstruktur<\/h2>\n<h3>4.1 Operations-Meeting (wöchentlich)<\/h3>\n<table><thead><tr><th>Feld<\/th><th>Inhalt<\/th><\/tr><\/thead><tbody><tr><td>Teilnehmende<\/td><td>Patrick Motsch (GF), Dominic Largo (VSO), Chris Winiger (OP); bei Bedarf Silvan Winiger (FT)<\/td><\/tr><tr><td>Inhalte<\/td><td>Daily Business, operative Entscheidungsfindungen, Zahlen<\/td><\/tr><tr><td>Moderation<\/td><td>Chris Winiger (OP) — Vertretung: Patrick Motsch (GF)<\/td><\/tr><tr><td>Eskalation<\/td><td>Bei Bedarf kurzes Sync Operations → Verwaltungsrat<\/td><\/tr><\/tbody><\/table>\n<h3>4.2 Verwaltungsrat<\/h3>\n<table><thead><tr><th>Feld<\/th><th>Regelung<\/th><\/tr><\/thead><tbody><tr><td>Mitglieder<\/td><td>Patrick Motsch, Dominic Largo, Philipp Graf, Silvan Winiger<\/td><\/tr><tr><td>Frequenz<\/td><td>Übergang: ab Juli 2026 zweiwöchentlich; ab Q4 2026 monatlich<\/td><\/tr><tr><td>Inhalte<\/td><td>Strategische Entscheidungen, relevante operative Themen, finanzielle Situation<\/td><\/tr><tr><td>Physisches Treffen<\/td><td>Quartalsweise (Abendessen / strategischer Austausch)<\/td><\/tr><\/tbody><\/table>\n<p>Details zur IMS-internen Kommunikation: <a href=\"../04_unterstuetzung/kommunikation.md\">kommunikation.md<\/a>.<\/p>\n<h2>5. Beziehung zum IMS<\/h2>\n<table><thead><tr><th>IMS-Bezug<\/th><th>Wirkung<\/th><\/tr><\/thead><tbody><tr><td>R-01 Schlüsselpersonenrisiko<\/td><td>Operative Entlastung und Rolle <strong>Leiter operative Koordination und Produktmarketing (OP)<\/strong> als kompensierende Massnahme — ersetzt keine technische Vertretung<\/td><\/tr><tr><td>Kap. 5.3 Rollen<\/td><td>Operative Rollen hier; IMS-Fachrollen in <a href=\"rollen-verantwortlichkeiten.md\">rollen-verantwortlichkeiten.md<\/a><\/td><\/tr><tr><td>Kap. 7.4 Kommunikation<\/td><td>Meetingrhythmus in <a href=\"../04_unterstuetzung/kommunikation.md\">kommunikation.md<\/a><\/td><\/tr><tr><td>Kap. 9.3 Management-Review<\/td><td>Verwaltungsrat als strategisches Review-Gremium; formales IMS-Management-Review zusätzlich gemäss <a href=\"../06_bewertung/management-review.md\">management-review.md<\/a><\/td><\/tr><\/tbody><\/table>\n<h2>6. Inkrafttreten<\/h2>\n<p>Gültig ab Freigabe durch den Verwaltungsrat. Anpassungen an Rolleninhalten in diesem Dokument; Personenwechsel im <a href=\"personen-rollen-mapping.md\">Personen-Rollen-Mapping<\/a>.<\/p>", "text": "<!-- docid: ims-05-04 --> <!-- status: entwurf --> <!-- version: 0.2 --> <!-- owner: patrick motsch --> <!-- approver: geschäftsführung poweron ag / verwaltungsrat --> <!-- approveddate: --> <!-- nextreview: 2027-06-11 --> <!-- classification: intern --> <!-- isorefs: 9001:5.1,5.3; 27001:5.1,5.3 --> # organisationsreglement **dokumenttyp:** grundlagendokument (führung, operative organisation) regelt die **operative aufgabenverteilung**, **meetingstruktur** und **kommunikationswege** der poweron ag. ergänzt die ims-fachrollen in [rollen-verantwortlichkeiten.md](rollen-verantwortlichkeiten.md). personen und vr-zugehörigkeit: [personen-rollen-mapping](personen-rollen-mapping.md). ## 1. zweck - entlastung der zentralen rollenträger (insb. geschäftsführung und technische schlüsselpersonen). - klare verantwortlichkeiten in entwicklung, betrieb, vertrieb und verwaltung. - strukturierte kommunikation zwischen operations, strategie und verwaltungsrat. ## 2. ziele | ziel | beschreibung | |---|---| | entlastung geschäftsführung | fokus auf roadmap entwicklung, personalplanung und operative entscheidungsprozesse | | entlastung leiter strategie & kapital | fokus auf strategie, growth und investoren/kapitalbeschaffung | | entlastung leiter vertrieb & support operations | fokus auf network, sales und support operations | | struktur & kommunikation | regelmässige, thematisch getrennte meetings mit klarer moderation | ## 3. aufgabenverteilung (operativ) | rolle | code | amtsinhaber | vr | schwerpunkt | |---|---|---|---|---| | **geschäftsführung** | gf | patrick motsch | ja | roadmap entwicklung, personalplanung, operative entscheidungsfindung; ceo, cto; ims-fachrollen gebündelt | | **leiter vertrieb & support operations** | vso | dominic largo | ja | network, sales, unterstützung business development & support operations | | **leiter strategie & kapital** | sk | philipp graf | ja | strategie, support growth management, lead invest-themen / kapitalbeschaffung | | **finanzen und treuhand** | ft | silvan winiger | ja | treuhänderische & buchhalterische leistungen, testing, akquise | | **leiter operative koordination und produktmarketing** | op | chris winiger | nein | business development, organisatorische führung und koordination, produktmarketing; bindeglied zwischen operations, entwicklung, akquise und kundenbetreuung; entlastung der geschäftsführung im tagesgeschäft | ### 3.1 weitere mitarbeitende poweron ag | name | funktion | |---|---| | stephan schellworth | mitarbeitender | | ida dittrich | mitarbeitende | ## 4. meetingstruktur ### 4.1 operations-meeting (wöchentlich) | feld | inhalt | |---|---| | teilnehmende | patrick motsch (gf), dominic largo (vso), chris winiger (op); bei bedarf silvan winiger (ft) | | inhalte | daily business, operative entscheidungsfindungen, zahlen | | moderation | chris winiger (op) — vertretung: patrick motsch (gf) | | eskalation | bei bedarf kurzes sync operations → verwaltungsrat | ### 4.2 verwaltungsrat | feld | regelung | |---|---| | mitglieder | patrick motsch, dominic largo, philipp graf, silvan winiger | | frequenz | übergang: ab juli 2026 zweiwöchentlich; ab q4 2026 monatlich | | inhalte | strategische entscheidungen, relevante operative themen, finanzielle situation | | physisches treffen | quartalsweise (abendessen / strategischer austausch) | details zur ims-internen kommunikation: [kommunikation.md](../04_unterstuetzung/kommunikation.md). ## 5. beziehung zum ims | ims-bezug | wirkung | |---|---| | r-01 schlüsselpersonenrisiko | operative entlastung und rolle **leiter operative koordination und produktmarketing (op)** als kompensierende massnahme — ersetzt keine technische vertretung | | kap. 5.3 rollen | operative rollen hier; ims-fachrollen in [rollen-verantwortlichkeiten.md](rollen-verantwortlichkeiten.md) | | kap. 7.4 kommunikation | meetingrhythmus in [kommunikation.md](../04_unterstuetzung/kommunikation.md) | | kap. 9.3 management-review | verwaltungsrat als strategisches review-gremium; formales ims-management-review zusätzlich gemäss [management-review.md](../06_bewertung/management-review.md) | ## 6. inkrafttreten gültig ab freigabe durch den verwaltungsrat. anpassungen an rolleninhalten in diesem dokument; personenwechsel im [personen-rollen-mapping](personen-rollen-mapping.md). ", "nextReview": "2027-06-11", "overdueReview": false, "zuPruefen": []}, {"id": "02_fuehrung/personen-rollen-mapping.md", "path": "02_fuehrung/personen-rollen-mapping.md", "chapter": "02_fuehrung", "title": "Personen-Rollen-Mapping", "filename": "personen-rollen-mapping.md", "meta": {"docId": "IMS-05-05", "status": "entwurf", "version": "0.2", "owner": "Patrick Motsch", "approver": "Geschäftsführung PowerOn AG / Verwaltungsrat", "approvedDate": "", "nextReview": "2027-06-11", "classification": "intern", "isoRefs": "9001:5.3; 27001:5.3"}, "html": "<h1>Personen-Rollen-Mapping<\/h1>\n<p><strong>Dokumenttyp:<\/strong> Record (Zuordnung Funktion → Person)<\/p>\n<p>Zentrale Zuordnung <strong>namentlicher Amtsinhaber<\/strong> zu den Rollen im IMS und Organisationsreglement. Bei Wechsel wird ausschliesslich diese Tabelle angepasst.<\/p>\n<p><strong>Stand:<\/strong> 2026-06-11<\/p>\n<h2>1. Verwaltungsrat und operative Führung<\/h2>\n<table><thead><tr><th>Rolle<\/th><th>Code<\/th><th>Name<\/th><th>VR<\/th><th>Bemerkung<\/th><\/tr><\/thead><tbody><tr><td>Geschäftsführung<\/td><td>GF<\/td><td><strong>Patrick Motsch<\/strong><\/td><td>ja<\/td><td>CEO, CTO<\/td><\/tr><tr><td>Leiter Vertrieb &amp; Support Operations<\/td><td>VSO<\/td><td><strong>Dominic Largo<\/strong><\/td><td>ja<\/td><td><\/td><\/tr><tr><td>Leiter Strategie &amp; Kapital<\/td><td>SK<\/td><td><strong>Philipp Graf<\/strong><\/td><td>ja<\/td><td><\/td><\/tr><tr><td>Finanzen und Treuhand<\/td><td>FT<\/td><td><strong>Silvan Winiger<\/strong><\/td><td>ja<\/td><td>Treuhänderische &amp; buchhalterische Leistungen (SoHa Treuhand AG)<\/td><\/tr><tr><td>Leiter operative Koordination und Produktmarketing<\/td><td>OP<\/td><td><strong>Chris Winiger<\/strong><\/td><td>nein<\/td><td>PowerOn AG<\/td><\/tr><\/tbody><\/table>\n<p>Rollenbeschreibungen und Aufgaben: <a href=\"organisationsreglement.md\">organisationsreglement.md<\/a>.<\/p>\n<h2>2. Weitere Mitarbeitende PowerOn AG<\/h2>\n<table><thead><tr><th>Name<\/th><th>Funktion<\/th><\/tr><\/thead><tbody><tr><td><strong>Stephan Schellworth<\/strong><\/td><td>Mitarbeitender<\/td><\/tr><tr><td><strong>Ida Dittrich<\/strong><\/td><td>Mitarbeitende<\/td><\/tr><\/tbody><\/table>\n<h2>3. IMS-Fachrollen<\/h2>\n<table><thead><tr><th>Rolle<\/th><th>Amtsinhaber<\/th><th>Kontakt<\/th><\/tr><\/thead><tbody><tr><td>Oberste Leitung (Geschäftsführung)<\/td><td>Patrick Motsch<\/td><td>p.motsch@poweron.swiss<\/td><\/tr><tr><td>Informationssicherheits-Beauftragter (ISB)<\/td><td>Patrick Motsch<\/td><td>p.motsch@poweron.swiss<\/td><\/tr><tr><td>Qualitätsmanagement-Beauftragter (QMB)<\/td><td>Patrick Motsch<\/td><td>p.motsch@poweron.swiss<\/td><\/tr><tr><td>Dokumentenlenkungs-Verantwortlicher<\/td><td>Patrick Motsch<\/td><td>p.motsch@poweron.swiss<\/td><\/tr><tr><td>Datenschutzverantwortlicher<\/td><td>Patrick Motsch<\/td><td>p.motsch@poweron.swiss<\/td><\/tr><tr><td>Betrieb / DevOps &amp; Incident-Verantwortlicher<\/td><td>Patrick Motsch<\/td><td>p.motsch@poweron.swiss<\/td><\/tr><tr><td>Drittdienst-/Lieferanten-Verantwortlicher<\/td><td>Patrick Motsch<\/td><td>p.motsch@poweron.swiss<\/td><\/tr><tr><td>Interner Auditor<\/td><td><em>noch zu benennen (extern)<\/em><\/td><td>—<\/td><\/tr><\/tbody><\/table>\n<p>Rollenbeschreibungen: <a href=\"rollen-verantwortlichkeiten.md\">rollen-verantwortlichkeiten.md<\/a>. Risiko-Eigner je Eintrag: <a href=\"../03_planung/risikoregister.md\">Risikoregister<\/a>.<\/p>\n<h2>4. Pflege<\/h2>\n<ul><li>Änderungen nur hier; kein Duplikat in Organisationsreglement oder Rollenmatrix.<\/li><li>Bei Wechsel: Zeile ersetzen, <code>Stand<\/code>-Datum im Header aktualisieren, betroffene Person informieren.<\/li><li>Freigabe durch Geschäftsführung; wesentliche Änderungen im nächsten Verwaltungsrat zur Kenntnis.<\/li><\/ul>", "text": "<!-- docid: ims-05-05 --> <!-- status: entwurf --> <!-- version: 0.2 --> <!-- owner: patrick motsch --> <!-- approver: geschäftsführung poweron ag / verwaltungsrat --> <!-- approveddate: --> <!-- nextreview: 2027-06-11 --> <!-- classification: intern --> <!-- isorefs: 9001:5.3; 27001:5.3 --> # personen-rollen-mapping **dokumenttyp:** record (zuordnung funktion → person) zentrale zuordnung **namentlicher amtsinhaber** zu den rollen im ims und organisationsreglement. bei wechsel wird ausschliesslich diese tabelle angepasst. **stand:** 2026-06-11 ## 1. verwaltungsrat und operative führung | rolle | code | name | vr | bemerkung | |---|---|---|---|---| | geschäftsführung | gf | **patrick motsch** | ja | ceo, cto | | leiter vertrieb & support operations | vso | **dominic largo** | ja | | | leiter strategie & kapital | sk | **philipp graf** | ja | | | finanzen und treuhand | ft | **silvan winiger** | ja | treuhänderische & buchhalterische leistungen (soha treuhand ag) | | leiter operative koordination und produktmarketing | op | **chris winiger** | nein | poweron ag | rollenbeschreibungen und aufgaben: [organisationsreglement.md](organisationsreglement.md). ## 2. weitere mitarbeitende poweron ag | name | funktion | |---|---| | **stephan schellworth** | mitarbeitender | | **ida dittrich** | mitarbeitende | ## 3. ims-fachrollen | rolle | amtsinhaber | kontakt | |---|---|---| | oberste leitung (geschäftsführung) | patrick motsch | p.motsch@poweron.swiss | | informationssicherheits-beauftragter (isb) | patrick motsch | p.motsch@poweron.swiss | | qualitätsmanagement-beauftragter (qmb) | patrick motsch | p.motsch@poweron.swiss | | dokumentenlenkungs-verantwortlicher | patrick motsch | p.motsch@poweron.swiss | | datenschutzverantwortlicher | patrick motsch | p.motsch@poweron.swiss | | betrieb / devops & incident-verantwortlicher | patrick motsch | p.motsch@poweron.swiss | | drittdienst-/lieferanten-verantwortlicher | patrick motsch | p.motsch@poweron.swiss | | interner auditor | *noch zu benennen (extern)* | — | rollenbeschreibungen: [rollen-verantwortlichkeiten.md](rollen-verantwortlichkeiten.md). risiko-eigner je eintrag: [risikoregister](../03_planung/risikoregister.md). ## 4. pflege - änderungen nur hier; kein duplikat in organisationsreglement oder rollenmatrix. - bei wechsel: zeile ersetzen, `stand`-datum im header aktualisieren, betroffene person informieren. - freigabe durch geschäftsführung; wesentliche änderungen im nächsten verwaltungsrat zur kenntnis. ", "nextReview": "2027-06-11", "overdueReview": false, "zuPruefen": []}, {"id": "02_fuehrung/qm-politik.md", "path": "02_fuehrung/qm-politik.md", "chapter": "02_fuehrung", "title": "Qualitätspolitik", "filename": "qm-politik.md", "meta": {"docId": "IMS-05-01", "status": "entwurf", "version": "0.1", "owner": "Patrick Motsch", "approver": "Geschäftsführung PowerOn AG", "approvedDate": "", "nextReview": "2027-06-03", "classification": "öffentlich", "isoRefs": "9001:5.2"}, "html": "<h1>Qualitätspolitik<\/h1>\n<p><strong>Dokumenttyp:<\/strong> Politik (Pflichtdokument ISO 9001 5.2) <strong>Geltungsbereich:<\/strong> Gesamte PowerOn AG<\/p>\n<h2>1. Unser Qualitätsverständnis<\/h2>\n<p>Die PowerOn AG entwickelt und betreibt mit der PORTA-Plattform sichere, zuverlässige und nutzbringende KI-Lösungen für datenschutzsensible Branchen. Qualität bedeutet für uns: zugesagte Funktionalität, Verfügbarkeit und Sicherheit verlässlich zu liefern und kontinuierlich zu verbessern.<\/p>\n<h2>2. Grundsätze<\/h2>\n<ol><li><strong>Kundenorientierung:<\/strong> Wir verstehen Kundenanforderungen und setzen sie nachvollziehbar in Produkt und Service um.<\/li><li><strong>Nachvollziehbare Prozesse:<\/strong> Entwicklung, Release und Support folgen dokumentierten, wiederholbaren Prozessen (siehe <a href=\"../05_betrieb/20260528_feature_release_bugfix.md\">Feature-/Release-/Bug-Prozess<\/a>).<\/li><li><strong>Qualität vor Tempo:<\/strong> Vier-Augen-Prinzip, Staging-Verifikation und Akzeptanzkriterien vor jedem Produktiv-Release.<\/li><li><strong>Datenschutz &amp; Sicherheit als Qualitätsmerkmal:<\/strong> Qualität und Informationssicherheit sind untrennbar (integriertes Managementsystem).<\/li><li><strong>Faktenbasierte Entscheidungen:<\/strong> Wir steuern über Kennzahlen (siehe <a href=\"../03_planung/ziele-und-kennzahlen.md\">Ziele &amp; Kennzahlen<\/a>).<\/li><li><strong>Kontinuierliche Verbesserung:<\/strong> Abweichungen werden als Chance verstanden und über den <a href=\"../07_verbesserung/korrekturmassnahmen-und-kvp.md\">KVP-Prozess<\/a> behandelt.<\/li><\/ol>\n<h2>3. Verpflichtung der Leitung<\/h2>\n<p>Die Geschäftsführung verpflichtet sich zur Erfüllung anwendbarer Anforderungen, zur Bereitstellung der nötigen Ressourcen und zur fortlaufenden Verbesserung des Qualitätsmanagementsystems. Qualitätsziele werden in <a href=\"../03_planung/ziele-und-kennzahlen.md\">Ziele &amp; Kennzahlen<\/a> festgelegt und im <a href=\"../06_bewertung/management-review.md\">Management-Review<\/a> bewertet.<\/p>\n<h2>4. Verbindlichkeit<\/h2>\n<p>Diese Politik ist für alle Mitarbeitenden verbindlich, wird kommuniziert (<a href=\"../04_unterstuetzung/kommunikation.md\">Kommunikation<\/a>) und mindestens jährlich auf Angemessenheit überprüft.<\/p>", "text": "<!-- docid: ims-05-01 --> <!-- status: entwurf --> <!-- version: 0.1 --> <!-- owner: patrick motsch --> <!-- approver: geschäftsführung poweron ag --> <!-- approveddate: --> <!-- nextreview: 2027-06-03 --> <!-- classification: öffentlich --> <!-- isorefs: 9001:5.2 --> # qualitätspolitik **dokumenttyp:** politik (pflichtdokument iso 9001 5.2) **geltungsbereich:** gesamte poweron ag ## 1. unser qualitätsverständnis die poweron ag entwickelt und betreibt mit der porta-plattform sichere, zuverlässige und nutzbringende ki-lösungen für datenschutzsensible branchen. qualität bedeutet für uns: zugesagte funktionalität, verfügbarkeit und sicherheit verlässlich zu liefern und kontinuierlich zu verbessern. ## 2. grundsätze 1. **kundenorientierung:** wir verstehen kundenanforderungen und setzen sie nachvollziehbar in produkt und service um. 2. **nachvollziehbare prozesse:** entwicklung, release und support folgen dokumentierten, wiederholbaren prozessen (siehe [feature-/release-/bug-prozess](../05_betrieb/20260528_feature_release_bugfix.md)). 3. **qualität vor tempo:** vier-augen-prinzip, staging-verifikation und akzeptanzkriterien vor jedem produktiv-release. 4. **datenschutz & sicherheit als qualitätsmerkmal:** qualität und informationssicherheit sind untrennbar (integriertes managementsystem). 5. **faktenbasierte entscheidungen:** wir steuern über kennzahlen (siehe [ziele & kennzahlen](../03_planung/ziele-und-kennzahlen.md)). 6. **kontinuierliche verbesserung:** abweichungen werden als chance verstanden und über den [kvp-prozess](../07_verbesserung/korrekturmassnahmen-und-kvp.md) behandelt. ## 3. verpflichtung der leitung die geschäftsführung verpflichtet sich zur erfüllung anwendbarer anforderungen, zur bereitstellung der nötigen ressourcen und zur fortlaufenden verbesserung des qualitätsmanagementsystems. qualitätsziele werden in [ziele & kennzahlen](../03_planung/ziele-und-kennzahlen.md) festgelegt und im [management-review](../06_bewertung/management-review.md) bewertet. ## 4. verbindlichkeit diese politik ist für alle mitarbeitenden verbindlich, wird kommuniziert ([kommunikation](../04_unterstuetzung/kommunikation.md)) und mindestens jährlich auf angemessenheit überprüft. ", "nextReview": "2027-06-03", "overdueReview": false, "zuPruefen": []}, {"id": "02_fuehrung/rollen-verantwortlichkeiten.md", "path": "02_fuehrung/rollen-verantwortlichkeiten.md", "chapter": "02_fuehrung", "title": "Rollen, Verantwortlichkeiten und Befugnisse", "filename": "rollen-verantwortlichkeiten.md", "meta": {"docId": "IMS-05-03", "status": "entwurf", "version": "0.1", "owner": "Patrick Motsch", "approver": "Geschäftsführung PowerOn AG", "approvedDate": "", "nextReview": "2027-06-03", "classification": "intern", "isoRefs": "9001:5.3; 27001:5.3"}, "html": "<h1>Rollen, Verantwortlichkeiten und Befugnisse<\/h1>\n<p><strong>Dokumenttyp:<\/strong> Grundlagendokument (ISO 9001 / 27001 Kap. 5.3)<\/p>\n<p>Aufgrund der kleinen Teamgrösse (2-5 Personen) werden Rollen gebuendelt. Bündelung ist zulässig; entscheidend ist die dokumentierte Zuweisung. <strong>Namentliche Träger<\/strong> stehen zentral im <a href=\"personen-rollen-mapping.md\">Personen-Rollen-Mapping<\/a> — diese Matrix enthält nur Funktionen.<\/p>\n<h2>1. Rollenmatrix<\/h2>\n<table><thead><tr><th>Rolle<\/th><th>Verantwortung / Befugnis<\/th><th>Träger<\/th><\/tr><\/thead><tbody><tr><td>Oberste Leitung (Geschäftsführung)<\/td><td>Gesamtverantwortung IMS, Freigabe Politiken, Ressourcen, Management-Review<\/td><td>→ Mapping<\/td><\/tr><tr><td>Informationssicherheits-Beauftragter (ISB / CISO-Funktion)<\/td><td>ISMS-Pflege, Risikobeurteilung, SoA, Steuerung Annex-A-Controls<\/td><td>→ Mapping<\/td><\/tr><tr><td>Qualitätsmanagement-Beauftragter (QMB)<\/td><td>QMS-Pflege, Prozesssteuerung, KVP, Audit-Koordination<\/td><td>→ Mapping<\/td><\/tr><tr><td>Dokumentenlenkungs-Verantwortlicher<\/td><td>Pflege Header-Standard, Dokumentenregister, Review-Zyklen<\/td><td>→ Mapping<\/td><\/tr><tr><td>Datenschutzverantwortlicher<\/td><td>DSG/DSGVO, AVV-Management<\/td><td>→ Mapping<\/td><\/tr><tr><td>Betrieb / DevOps &amp; Incident-Verantwortlicher<\/td><td>Server, Deployment, Backups, Vorfallbehandlung<\/td><td>→ Mapping<\/td><\/tr><tr><td>Drittdienst-/Lieferanten-Verantwortlicher<\/td><td>Drittanbieter-Inventar, AVVs, Subunternehmer<\/td><td>→ Mapping<\/td><\/tr><tr><td>Risiko-Eigner (Risk Owner)<\/td><td>Verantwortung je wesentlichem Risiko/Asset<\/td><td>gemäss <a href=\"../03_planung/risikoregister.md\">Risikoregister<\/a><\/td><\/tr><tr><td>Interner Auditor<\/td><td>Unabhängige Prüfung des IMS<\/td><td>→ Mapping (extern, Unabhängigkeit erforderlich)<\/td><\/tr><\/tbody><\/table>\n<p>Amtsinhaber: <a href=\"personen-rollen-mapping.md\">personen-rollen-mapping.md<\/a> Abschnitt 2.<\/p>\n<h2>2. Hinweis zur Funktionstrennung<\/h2>\n<p>Da derzeit zentrale Rollen bei einer Person liegen, sind folgende kompensierende Massnahmen verbindlich:<\/p>\n<ul><li><strong>Vier-Augen-Prinzip<\/strong> bei Code-Review und Produktiv-Releases (<a href=\"../05_betrieb/20260528_feature_release_bugfix.md\">feature_release_bugfix.md<\/a>).<\/li><li><strong>Protokollierung privilegierter Zugriffe<\/strong> (<a href=\"../05_betrieb/11_Logging_und_Monitoring.md\">Logging &amp; Monitoring<\/a>).<\/li><li><strong>Internes Audit wird extern vergeben<\/strong>, um Unabhängigkeit sicherzustellen (<a href=\"../06_bewertung/internes-audit.md\">Internes Audit<\/a>).<\/li><\/ul>\n<h2>3. Operative Organisation<\/h2>\n<p>Die geschäftliche Aufgabenverteilung, Meetingstruktur (Operations, Verwaltungsrat) und Koordinationsrollen sind im <a href=\"organisationsreglement.md\">Organisationsreglement<\/a> geregelt. Die operative Entlastungsstruktur adressiert das Schlüsselpersonenrisiko (R-01) als kompensierende Massnahme.<\/p>\n<h2>4. Pflege<\/h2>\n<p>Änderungen an Rolleninhalten in dieser Matrix bzw. im Organisationsreglement; <strong>Personenwechsel nur<\/strong> im <a href=\"personen-rollen-mapping.md\">Personen-Rollen-Mapping<\/a>. Wesentliche Änderungen im Management-Review bestätigen. Bei Teamwachstum Rollen entflechten (insb. interner Auditor, Release-Freigabe vs. Entwicklung).<\/p>", "text": "<!-- docid: ims-05-03 --> <!-- status: entwurf --> <!-- version: 0.1 --> <!-- owner: patrick motsch --> <!-- approver: geschäftsführung poweron ag --> <!-- approveddate: --> <!-- nextreview: 2027-06-03 --> <!-- classification: intern --> <!-- isorefs: 9001:5.3; 27001:5.3 --> # rollen, verantwortlichkeiten und befugnisse **dokumenttyp:** grundlagendokument (iso 9001 / 27001 kap. 5.3) aufgrund der kleinen teamgrösse (2-5 personen) werden rollen gebuendelt. bündelung ist zulässig; entscheidend ist die dokumentierte zuweisung. **namentliche träger** stehen zentral im [personen-rollen-mapping](personen-rollen-mapping.md) — diese matrix enthält nur funktionen. ## 1. rollenmatrix | rolle | verantwortung / befugnis | träger | |---|---|---| | oberste leitung (geschäftsführung) | gesamtverantwortung ims, freigabe politiken, ressourcen, management-review | → mapping | | informationssicherheits-beauftragter (isb / ciso-funktion) | isms-pflege, risikobeurteilung, soa, steuerung annex-a-controls | → mapping | | qualitätsmanagement-beauftragter (qmb) | qms-pflege, prozesssteuerung, kvp, audit-koordination | → mapping | | dokumentenlenkungs-verantwortlicher | pflege header-standard, dokumentenregister, review-zyklen | → mapping | | datenschutzverantwortlicher | dsg/dsgvo, avv-management | → mapping | | betrieb / devops & incident-verantwortlicher | server, deployment, backups, vorfallbehandlung | → mapping | | drittdienst-/lieferanten-verantwortlicher | drittanbieter-inventar, avvs, subunternehmer | → mapping | | risiko-eigner (risk owner) | verantwortung je wesentlichem risiko/asset | gemäss [risikoregister](../03_planung/risikoregister.md) | | interner auditor | unabhängige prüfung des ims | → mapping (extern, unabhängigkeit erforderlich) | amtsinhaber: [personen-rollen-mapping.md](personen-rollen-mapping.md) abschnitt 2. ## 2. hinweis zur funktionstrennung da derzeit zentrale rollen bei einer person liegen, sind folgende kompensierende massnahmen verbindlich: - **vier-augen-prinzip** bei code-review und produktiv-releases ([feature_release_bugfix.md](../05_betrieb/20260528_feature_release_bugfix.md)). - **protokollierung privilegierter zugriffe** ([logging & monitoring](../05_betrieb/11_logging_und_monitoring.md)). - **internes audit wird extern vergeben**, um unabhängigkeit sicherzustellen ([internes audit](../06_bewertung/internes-audit.md)). ## 3. operative organisation die geschäftliche aufgabenverteilung, meetingstruktur (operations, verwaltungsrat) und koordinationsrollen sind im [organisationsreglement](organisationsreglement.md) geregelt. die operative entlastungsstruktur adressiert das schlüsselpersonenrisiko (r-01) als kompensierende massnahme. ## 4. pflege änderungen an rolleninhalten in dieser matrix bzw. im organisationsreglement; **personenwechsel nur** im [personen-rollen-mapping](personen-rollen-mapping.md). wesentliche änderungen im management-review bestätigen. bei teamwachstum rollen entflechten (insb. interner auditor, release-freigabe vs. entwicklung). ", "nextReview": "2027-06-03", "overdueReview": false, "zuPruefen": []}, {"id": "03_planung/risikomanagement-methodik.md", "path": "03_planung/risikomanagement-methodik.md", "chapter": "03_planung", "title": "Risikomanagement-Methodik", "filename": "risikomanagement-methodik.md", "meta": {"docId": "IMS-06-01", "status": "entwurf", "version": "0.1", "owner": "Patrick Motsch", "approver": "Geschäftsführung PowerOn AG", "approvedDate": "", "nextReview": "2027-06-03", "classification": "intern", "isoRefs": "27001:6.1.2,6.1.3,8.2,8.3; 9001:6.1"}, "html": "<h1>Risikomanagement-Methodik<\/h1>\n<p><strong>Dokumenttyp:<\/strong> Verfahren (Pflichtdokument ISO 27001 6.1.2) <strong>Geltungsbereich:<\/strong> Informationssicherheits- und Qualitätsrisiken im IMS-Scope<\/p>\n<h2>1. Zweck<\/h2>\n<p>Dieses Verfahren legt fest, wie PowerOn Risiken und Chancen identifiziert, bewertet, behandelt und überwacht -- für ISO 27001 (Informationssicherheitsrisiken) und ISO 9001 (Risiken/Chancen für die Prozess- und Produktqualität).<\/p>\n<h2>2. Vorgehen<\/h2>\n<pre class=\"mermaid\">flowchart LR\n    id[\"1 Identifikation (Assets, Bedrohungen, Schwachstellen, Prozessrisiken)\"] --&gt; an[\"2 Analyse (Eintritt x Auswirkung)\"]\n    an --&gt; ev[\"3 Bewertung gegen Akzeptanzkriterien\"]\n    ev --&gt; tr[\"4 Behandlung (vermeiden/vermindern/übertragen/akzeptieren)\"]\n    tr --&gt; mo[\"5 Überwachung &amp; Review\"]\n    mo --&gt; id<\/pre>\n<h2>3. Bewertungsskala<\/h2>\n<p><strong>Eintrittswahrscheinlichkeit (W)<\/strong> und <strong>Auswirkung (A)<\/strong> je 1-4:<\/p>\n<table><thead><tr><th>Stufe<\/th><th>W (Wahrscheinlichkeit)<\/th><th>A (Auswirkung)<\/th><\/tr><\/thead><tbody><tr><td>1<\/td><td>selten (&lt; 1x/Jahr)<\/td><td>gering (kaum spuerbar)<\/td><\/tr><tr><td>2<\/td><td>möglich<\/td><td>spuerbar (begrenzt, intern)<\/td><\/tr><tr><td>3<\/td><td>wahrscheinlich<\/td><td>erheblich (Kunde/Daten betroffen)<\/td><\/tr><tr><td>4<\/td><td>sehr wahrscheinlich (laufend)<\/td><td>kritisch (Datenverlust, Ausfall, Rechtsbruch)<\/td><\/tr><\/tbody><\/table>\n<p><strong>Risikowert = W x A<\/strong> (1-16).<\/p>\n<table><thead><tr><th>Risikowert<\/th><th>Klasse<\/th><th>Vorgabe<\/th><\/tr><\/thead><tbody><tr><td>1-3<\/td><td>niedrig<\/td><td>akzeptieren, beobachten<\/td><\/tr><tr><td>4-8<\/td><td>mittel<\/td><td>Behandlung planen, terminiert<\/td><\/tr><tr><td>9-12<\/td><td>hoch<\/td><td>Behandlung priorisiert, zeitnah<\/td><\/tr><tr><td>13-16<\/td><td>sehr hoch<\/td><td>sofortige Massnahmen, Leitung informieren<\/td><\/tr><\/tbody><\/table>\n<h2>4. Risikoakzeptanzkriterium<\/h2>\n<p>Risiken der Klasse <strong>niedrig<\/strong> können ohne weitere Massnahme akzeptiert werden. Ab <strong>mittel<\/strong> ist eine dokumentierte Behandlung mit Owner und Termin erforderlich. Restrisiken ab <strong>hoch<\/strong> müssen von der obersten Leitung formal akzeptiert werden.<\/p>\n<h2>5. Behandlungsoptionen und Bezug zum SoA<\/h2>\n<p>Für Informationssicherheitsrisiken werden Massnahmen primär aus den <strong>ISO 27001 Annex-A-Controls<\/strong> abgeleitet; die Anwendbarkeit und Umsetzung wird im <a href=\"statement-of-applicability-soa.md\">Statement of Applicability<\/a> dokumentiert. Umsetzungsmassnahmen und Restrisiken werden im <a href=\"risikoregister.md\">Risikoregister<\/a> geführt; offene Massnahmen laufen ins <a href=\"../07_verbesserung/massnahmen-register.md\">Massnahmenregister<\/a>.<\/p>\n<h2>6. Turnus<\/h2>\n<p>Risikobeurteilung mindestens <strong>jährlich<\/strong> sowie <strong>anlassbezogen<\/strong> (wesentliche Architektur-/Prozessänderung, schwerer Incident, neuer wesentlicher Lieferant). Ergebnisse fliessen ins <a href=\"../06_bewertung/management-review.md\">Management-Review<\/a>.<\/p>", "text": "<!-- docid: ims-06-01 --> <!-- status: entwurf --> <!-- version: 0.1 --> <!-- owner: patrick motsch --> <!-- approver: geschäftsführung poweron ag --> <!-- approveddate: --> <!-- nextreview: 2027-06-03 --> <!-- classification: intern --> <!-- isorefs: 27001:6.1.2,6.1.3,8.2,8.3; 9001:6.1 --> # risikomanagement-methodik **dokumenttyp:** verfahren (pflichtdokument iso 27001 6.1.2) **geltungsbereich:** informationssicherheits- und qualitätsrisiken im ims-scope ## 1. zweck dieses verfahren legt fest, wie poweron risiken und chancen identifiziert, bewertet, behandelt und überwacht -- für iso 27001 (informationssicherheitsrisiken) und iso 9001 (risiken/chancen für die prozess- und produktqualität). ## 2. vorgehen ```mermaid flowchart lr id[\"1 identifikation (assets, bedrohungen, schwachstellen, prozessrisiken)\"] --> an[\"2 analyse (eintritt x auswirkung)\"] an --> ev[\"3 bewertung gegen akzeptanzkriterien\"] ev --> tr[\"4 behandlung (vermeiden/vermindern/übertragen/akzeptieren)\"] tr --> mo[\"5 überwachung & review\"] mo --> id ``` ## 3. bewertungsskala **eintrittswahrscheinlichkeit (w)** und **auswirkung (a)** je 1-4: | stufe | w (wahrscheinlichkeit) | a (auswirkung) | |---|---|---| | 1 | selten (< 1x/jahr) | gering (kaum spuerbar) | | 2 | möglich | spuerbar (begrenzt, intern) | | 3 | wahrscheinlich | erheblich (kunde/daten betroffen) | | 4 | sehr wahrscheinlich (laufend) | kritisch (datenverlust, ausfall, rechtsbruch) | **risikowert = w x a** (1-16). | risikowert | klasse | vorgabe | |---|---|---| | 1-3 | niedrig | akzeptieren, beobachten | | 4-8 | mittel | behandlung planen, terminiert | | 9-12 | hoch | behandlung priorisiert, zeitnah | | 13-16 | sehr hoch | sofortige massnahmen, leitung informieren | ## 4. risikoakzeptanzkriterium risiken der klasse **niedrig** können ohne weitere massnahme akzeptiert werden. ab **mittel** ist eine dokumentierte behandlung mit owner und termin erforderlich. restrisiken ab **hoch** müssen von der obersten leitung formal akzeptiert werden. ## 5. behandlungsoptionen und bezug zum soa für informationssicherheitsrisiken werden massnahmen primär aus den **iso 27001 annex-a-controls** abgeleitet; die anwendbarkeit und umsetzung wird im [statement of applicability](statement-of-applicability-soa.md) dokumentiert. umsetzungsmassnahmen und restrisiken werden im [risikoregister](risikoregister.md) geführt; offene massnahmen laufen ins [massnahmenregister](../07_verbesserung/massnahmen-register.md). ## 6. turnus risikobeurteilung mindestens **jährlich** sowie **anlassbezogen** (wesentliche architektur-/prozessänderung, schwerer incident, neuer wesentlicher lieferant). ergebnisse fliessen ins [management-review](../06_bewertung/management-review.md). ", "nextReview": "2027-06-03", "overdueReview": false, "zuPruefen": []}, {"id": "03_planung/risikoregister.md", "path": "03_planung/risikoregister.md", "chapter": "03_planung", "title": "Risikoregister", "filename": "risikoregister.md", "meta": {"docId": "IMS-06-02", "status": "entwurf", "version": "0.1", "owner": "Patrick Motsch", "approver": "Geschäftsführung PowerOn AG", "approvedDate": "", "nextReview": "2026-12-03", "classification": "vertraulich", "isoRefs": "27001:6.1.2,8.2; 9001:6.1"}, "html": "<h1>Risikoregister<\/h1>\n<p><strong>Dokumenttyp:<\/strong> Record (Ergebnis der Risikobeurteilung) Bewertung gemäss <a href=\"risikomanagement-methodik.md\">Risikomanagement-Methodik<\/a>. W = Wahrscheinlichkeit, A = Auswirkung, R = W x A. Behandlungsmassnahmen mit Owner/Termin laufen ins <a href=\"../07_verbesserung/massnahmen-register.md\">Massnahmenregister<\/a>.<\/p>\n<p><strong>Stand der Erstbeurteilung:<\/strong> 2026-06-03 (Entwurf -- in einer Erst-Risikoworkshop-Sitzung zu validieren).<\/p>\n<table><thead><tr><th>ID<\/th><th>Risiko<\/th><th>Kategorie<\/th><th>W<\/th><th>A<\/th><th>R<\/th><th>Klasse<\/th><th>Behandlung<\/th><th>Owner<\/th><th>Annex-A-Bezug<\/th><\/tr><\/thead><tbody><tr><td>R-01<\/td><td>Schlüsselpersonenrisiko (Wissen/Zugriffe auf eine Person konzentriert)<\/td><td>Organisation<\/td><td>3<\/td><td>4<\/td><td>12<\/td><td>hoch<\/td><td>Vertretung, Dokumentation, Break-Glass; operative Entlastung via <a href=\"../02_fuehrung/organisationsreglement.md\">Organisationsreglement<\/a> (Rolle OP)<\/td><td>Patrick Motsch (GF)<\/td><td>A.5.2, A.5.4<\/td><\/tr><tr><td>R-02<\/td><td>Abfluss sensibler Inhaltsdaten an externe LLM-Provider (OpenAI/USA)<\/td><td>Datenschutz<\/td><td>3<\/td><td>4<\/td><td>12<\/td><td>hoch<\/td><td>Neutralisierung, AVV/DPA + EU-SCC, Zero-Retention prüfen<\/td><td>Patrick Motsch<\/td><td>A.5.14, A.8.12<\/td><\/tr><tr><td>R-03<\/td><td>MFA auf Admin-/Server-Zugängen<\/td><td>Zugriff<\/td><td>1<\/td><td>2<\/td><td>2<\/td><td>niedrig<\/td><td>Umgesetzt (Juni 2026); periodische Rezertifizierung halbjährlich<\/td><td>Patrick Motsch<\/td><td>A.5.17, A.8.5<\/td><\/tr><tr><td>R-04<\/td><td>Backup nicht wiederherstellbar (Restore nie getestet)<\/td><td>Verfügbarkeit<\/td><td>2<\/td><td>4<\/td><td>8<\/td><td>mittel<\/td><td>Restore-Test durchführen &amp; protokollieren<\/td><td>Patrick Motsch<\/td><td>A.8.13<\/td><\/tr><tr><td>R-05<\/td><td>Ausfall Schlüssel-Lieferant (Infomaniak / LLM-Provider)<\/td><td>Lieferkette<\/td><td>2<\/td><td>3<\/td><td>6<\/td><td>mittel<\/td><td>BCM/DR-Plan, Exit-Strategie, Provider-Alternativen<\/td><td>Patrick Motsch<\/td><td>A.5.19, A.5.30<\/td><\/tr><tr><td>R-06<\/td><td>Sicherheitsluecke durch verspäteten Patch<\/td><td>Technik<\/td><td>2<\/td><td>3<\/td><td>6<\/td><td>mittel<\/td><td>Patch-/Schwachstellenprozess einhalten<\/td><td>Patrick Motsch<\/td><td>A.8.8<\/td><\/tr><tr><td>R-07<\/td><td>Unzureichende Log-Aufbewahrung/Manipulationsschutz<\/td><td>Nachweis<\/td><td>2<\/td><td>3<\/td><td>6<\/td><td>mittel<\/td><td>Retention &amp; Integritätsschutz festlegen<\/td><td>Patrick Motsch<\/td><td>A.8.15<\/td><\/tr><tr><td>R-08<\/td><td>Fehlerhafte Release führt zu Produktionsstörung<\/td><td>Qualität<\/td><td>2<\/td><td>3<\/td><td>6<\/td><td>mittel<\/td><td>Staging-Verifikation, Vier-Augen, Rollback<\/td><td>Patrick Motsch<\/td><td>A.8.31 (9001:8.5)<\/td><\/tr><tr><td>R-09<\/td><td>Prompt-Injection / Missbrauch KI-Funktionen<\/td><td>KI/Technik<\/td><td>3<\/td><td>2<\/td><td>6<\/td><td>mittel<\/td><td>Eingabebereinigung, Read-only DB-Zugriff, Rate-Limit<\/td><td>Patrick Motsch<\/td><td>A.8.28<\/td><\/tr><\/tbody><\/table>\n<h2>Pflegehinweis<\/h2>\n<p>Neue Risiken fortlaufend ergänzen, R bei Massnahmenwirkung neu bewerten (Restrisiko). Restrisiken der Klasse hoch+ erfordern formale Akzeptanz durch die oberste Leitung (Vermerk in Spalte Behandlung oder im Management-Review-Protokoll).<\/p>", "text": "<!-- docid: ims-06-02 --> <!-- status: entwurf --> <!-- version: 0.1 --> <!-- owner: patrick motsch --> <!-- approver: geschäftsführung poweron ag --> <!-- approveddate: --> <!-- nextreview: 2026-12-03 --> <!-- classification: vertraulich --> <!-- isorefs: 27001:6.1.2,8.2; 9001:6.1 --> # risikoregister **dokumenttyp:** record (ergebnis der risikobeurteilung) bewertung gemäss [risikomanagement-methodik](risikomanagement-methodik.md). w = wahrscheinlichkeit, a = auswirkung, r = w x a. behandlungsmassnahmen mit owner/termin laufen ins [massnahmenregister](../07_verbesserung/massnahmen-register.md). **stand der erstbeurteilung:** 2026-06-03 (entwurf -- in einer erst-risikoworkshop-sitzung zu validieren). | id | risiko | kategorie | w | a | r | klasse | behandlung | owner | annex-a-bezug | |---|---|---|---|---|---|---|---|---|---| | r-01 | schlüsselpersonenrisiko (wissen/zugriffe auf eine person konzentriert) | organisation | 3 | 4 | 12 | hoch | vertretung, dokumentation, break-glass; operative entlastung via [organisationsreglement](../02_fuehrung/organisationsreglement.md) (rolle op) | patrick motsch (gf) | a.5.2, a.5.4 | | r-02 | abfluss sensibler inhaltsdaten an externe llm-provider (openai/usa) | datenschutz | 3 | 4 | 12 | hoch | neutralisierung, avv/dpa + eu-scc, zero-retention prüfen | patrick motsch | a.5.14, a.8.12 | | r-03 | mfa auf admin-/server-zugängen | zugriff | 1 | 2 | 2 | niedrig | umgesetzt (juni 2026); periodische rezertifizierung halbjährlich | patrick motsch | a.5.17, a.8.5 | | r-04 | backup nicht wiederherstellbar (restore nie getestet) | verfügbarkeit | 2 | 4 | 8 | mittel | restore-test durchführen & protokollieren | patrick motsch | a.8.13 | | r-05 | ausfall schlüssel-lieferant (infomaniak / llm-provider) | lieferkette | 2 | 3 | 6 | mittel | bcm/dr-plan, exit-strategie, provider-alternativen | patrick motsch | a.5.19, a.5.30 | | r-06 | sicherheitsluecke durch verspäteten patch | technik | 2 | 3 | 6 | mittel | patch-/schwachstellenprozess einhalten | patrick motsch | a.8.8 | | r-07 | unzureichende log-aufbewahrung/manipulationsschutz | nachweis | 2 | 3 | 6 | mittel | retention & integritätsschutz festlegen | patrick motsch | a.8.15 | | r-08 | fehlerhafte release führt zu produktionsstörung | qualität | 2 | 3 | 6 | mittel | staging-verifikation, vier-augen, rollback | patrick motsch | a.8.31 (9001:8.5) | | r-09 | prompt-injection / missbrauch ki-funktionen | ki/technik | 3 | 2 | 6 | mittel | eingabebereinigung, read-only db-zugriff, rate-limit | patrick motsch | a.8.28 | ## pflegehinweis neue risiken fortlaufend ergänzen, r bei massnahmenwirkung neu bewerten (restrisiko). restrisiken der klasse hoch+ erfordern formale akzeptanz durch die oberste leitung (vermerk in spalte behandlung oder im management-review-protokoll). ", "nextReview": "2026-12-03", "overdueReview": false, "zuPruefen": []}, {"id": "03_planung/statement-of-applicability-soa.md", "path": "03_planung/statement-of-applicability-soa.md", "chapter": "03_planung", "title": "Statement of Applicability (SoA) -- ISO/IEC 27001:2022 Annex A", "filename": "statement-of-applicability-soa.md", "meta": {"docId": "IMS-06-03", "status": "entwurf", "version": "0.1", "owner": "Patrick Motsch", "approver": "Geschäftsführung PowerOn AG", "approvedDate": "", "nextReview": "2026-12-03", "classification": "vertraulich", "isoRefs": "27001:6.1.3,AnnexA"}, "html": "<h1>Statement of Applicability (SoA) -- ISO/IEC 27001:2022 Annex A<\/h1>\n<p><strong>Dokumenttyp:<\/strong> Pflichtdokument (ISO 27001 6.1.3 d) <strong>Stand:<\/strong> 2026-06-03 (Entwurf)<\/p>\n<p>Dieses SoA listet alle 93 Annex-A-Controls (2022) mit Anwendbarkeit, Begründung, Umsetzungsstatus und Verweis auf das umsetzende Dokument. Status: <strong>Umgesetzt / Teilweise / Geplant / N/A<\/strong>. Offene/teilweise Punkte sind im <a href=\"../07_verbesserung/massnahmen-register.md\">Massnahmenregister<\/a> geführt.<\/p>\n<p>Legende Anwendbarkeit: <strong>Ja<\/strong> = anwendbar; <strong>N/A<\/strong> = nicht anwendbar (mit Begründung). Cloud-Betrieb bei Infomaniak (CH): bestimmte physische Controls liegen beim Provider (Anwendbar, \"geerbt\").<\/p>\n<h2>A.5 Organisatorische Controls<\/h2>\n<table><thead><tr><th>Control<\/th><th>Titel<\/th><th>Anwend.<\/th><th>Status<\/th><th>Referenz / Begründung<\/th><\/tr><\/thead><tbody><tr><td>A.5.1<\/td><td>Informationssicherheits-Politiken<\/td><td>Ja<\/td><td>Umgesetzt<\/td><td><a href=\"../02_fuehrung/informationssicherheitspolitik.md\">informationssicherheitspolitik.md<\/a><\/td><\/tr><tr><td>A.5.2<\/td><td>Rollen &amp; Verantwortlichkeiten<\/td><td>Ja<\/td><td>Umgesetzt<\/td><td><a href=\"../02_fuehrung/rollen-verantwortlichkeiten.md\">rollen-verantwortlichkeiten.md<\/a><\/td><\/tr><tr><td>A.5.3<\/td><td>Aufgabentrennung<\/td><td>Ja<\/td><td>Teilweise<\/td><td>Klein-Team; kompensierend Vier-Augen-Prinzip, externes Audit<\/td><\/tr><tr><td>A.5.4<\/td><td>Verantwortung der Leitung<\/td><td>Ja<\/td><td>Umgesetzt<\/td><td><a href=\"../00_IMS-Handbuch.md\">00_IMS-Handbuch.md<\/a>, Management-Review<\/td><\/tr><tr><td>A.5.5<\/td><td>Kontakt zu Behörden<\/td><td>Ja<\/td><td>Geplant<\/td><td>Meldewege (EDOEB/FINMA) in <a href=\"../05_betrieb/07_Incident_Response_und_Meldewesen.md\">Incident Response<\/a> festhalten<\/td><\/tr><tr><td>A.5.6<\/td><td>Kontakt zu Interessengruppen<\/td><td>Ja<\/td><td>Teilweise<\/td><td>Security-Quellen/CERT-Feeds; formalisieren<\/td><\/tr><tr><td>A.5.7<\/td><td>Threat Intelligence<\/td><td>Ja<\/td><td>Teilweise<\/td><td><a href=\"../05_betrieb/10_Schwachstellenmanagement.md\">Schwachstellenmanagement<\/a><\/td><\/tr><tr><td>A.5.8<\/td><td>IS im Projektmanagement<\/td><td>Ja<\/td><td>Umgesetzt<\/td><td><a href=\"../05_betrieb/15_Sichere_Softwareentwicklung_SDLC.md\">SDLC<\/a>, Tech-Workshop<\/td><\/tr><tr><td>A.5.9<\/td><td>Inventar der Werte (Assets)<\/td><td>Ja<\/td><td>Teilweise<\/td><td><a href=\"../05_betrieb/20260528_drittanbieter-inventar.md\">Drittanbieter-Inventar<\/a>; Asset-Inventar ergänzen<\/td><\/tr><tr><td>A.5.10<\/td><td>Zulässige Nutzung von Werten<\/td><td>Ja<\/td><td>Geplant<\/td><td>Acceptable-Use in IS-Politik konkretisieren<\/td><\/tr><tr><td>A.5.11<\/td><td>Rückgabe von Werten<\/td><td>Ja<\/td><td>Geplant<\/td><td>Offboarding-Checkliste (<a href=\"../05_betrieb/03_Mitarbeitersicherheit_und_Screening.md\">Mitarbeitersicherheit<\/a>)<\/td><\/tr><tr><td>A.5.12<\/td><td>Klassifizierung von Information<\/td><td>Ja<\/td><td>Teilweise<\/td><td>Klassifizierungsschema (Header <code>classification<\/code>); ausweiten<\/td><\/tr><tr><td>A.5.13<\/td><td>Kennzeichnung von Information<\/td><td>Ja<\/td><td>Teilweise<\/td><td>Header-Klassifizierung; Daten-Labeling ergänzen<\/td><\/tr><tr><td>A.5.14<\/td><td>Informationsübertragung<\/td><td>Ja<\/td><td>Umgesetzt<\/td><td><a href=\"../05_betrieb/04_Verschluesselung_und_Schluesselmanagement.md\">Verschlüsselung<\/a>, TLS, <a href=\"../05_betrieb/neutralisierung-detail.md\">Neutralisierung<\/a><\/td><\/tr><tr><td>A.5.15<\/td><td>Zugangssteuerung<\/td><td>Ja<\/td><td>Umgesetzt<\/td><td><a href=\"../05_betrieb/02_Zugriffsmanagement_IAM_PAM.md\">Zugriffsmanagement<\/a>, RBAC<\/td><\/tr><tr><td>A.5.16<\/td><td>Identitätsmanagement<\/td><td>Ja<\/td><td>Umgesetzt<\/td><td><a href=\"../05_betrieb/02_Zugriffsmanagement_IAM_PAM.md\">Zugriffsmanagement<\/a><\/td><\/tr><tr><td>A.5.17<\/td><td>Authentisierungsinformation<\/td><td>Ja<\/td><td>Umgesetzt<\/td><td><a href=\"../05_betrieb/02_Zugriffsmanagement_IAM_PAM.md\">Zugriffsmanagement<\/a> — MFA Admin/Server (R-03, Juni 2026)<\/td><\/tr><tr><td>A.5.18<\/td><td>Zugangsrechte<\/td><td>Ja<\/td><td>Umgesetzt<\/td><td><a href=\"../05_betrieb/02_Zugriffsmanagement_IAM_PAM.md\">Zugriffsmanagement<\/a><\/td><\/tr><tr><td>A.5.19<\/td><td>IS in Lieferantenbeziehungen<\/td><td>Ja<\/td><td>Umgesetzt<\/td><td><a href=\"../05_betrieb/17_Subunternehmer_Management.md\">Subunternehmer<\/a><\/td><\/tr><tr><td>A.5.20<\/td><td>IS in Lieferantenvereinbarungen<\/td><td>Ja<\/td><td>Teilweise<\/td><td>AVVs vervollständigen (OpenAI Zero-Retention)<\/td><\/tr><tr><td>A.5.21<\/td><td>IS in der IKT-Lieferkette<\/td><td>Ja<\/td><td>Teilweise<\/td><td><a href=\"../05_betrieb/20260528_drittanbieter-inventar.md\">Drittanbieter-Inventar<\/a><\/td><\/tr><tr><td>A.5.22<\/td><td>Überwachung der Lieferantenleistung<\/td><td>Ja<\/td><td>Geplant<\/td><td>Review-Turnus Lieferanten festlegen<\/td><\/tr><tr><td>A.5.23<\/td><td>IS bei Nutzung von Cloud-Diensten<\/td><td>Ja<\/td><td>Umgesetzt<\/td><td>Infomaniak (CH); <a href=\"../05_betrieb/12_Netzwerk_und_Infrastruktursicherheit.md\">Netzwerk/Infra<\/a><\/td><\/tr><tr><td>A.5.24<\/td><td>Incident-Management Planung<\/td><td>Ja<\/td><td>Umgesetzt<\/td><td><a href=\"../05_betrieb/07_Incident_Response_und_Meldewesen.md\">Incident Response<\/a><\/td><\/tr><tr><td>A.5.25<\/td><td>Bewertung von IS-Ereignissen<\/td><td>Ja<\/td><td>Umgesetzt<\/td><td><a href=\"../05_betrieb/07_Incident_Response_und_Meldewesen.md\">Incident Response<\/a><\/td><\/tr><tr><td>A.5.26<\/td><td>Reaktion auf IS-Vorfälle<\/td><td>Ja<\/td><td>Umgesetzt<\/td><td><a href=\"../05_betrieb/07_Incident_Response_und_Meldewesen.md\">Incident Response<\/a><\/td><\/tr><tr><td>A.5.27<\/td><td>Lernen aus Vorfällen<\/td><td>Ja<\/td><td>Teilweise<\/td><td>Post-Incident-Review -&gt; <a href=\"../07_verbesserung/korrekturmassnahmen-und-kvp.md\">KVP<\/a><\/td><\/tr><tr><td>A.5.28<\/td><td>Sammlung von Beweismitteln<\/td><td>Ja<\/td><td>Teilweise<\/td><td>Logs/Forensik in <a href=\"../05_betrieb/11_Logging_und_Monitoring.md\">Logging<\/a><\/td><\/tr><tr><td>A.5.29<\/td><td>IS während Störung<\/td><td>Ja<\/td><td>Umgesetzt<\/td><td><a href=\"../05_betrieb/06_Business_Continuity_und_Disaster_Recovery.md\">BCM/DR<\/a><\/td><\/tr><tr><td>A.5.30<\/td><td>IKT-Bereitschaft für BC<\/td><td>Ja<\/td><td>Umgesetzt<\/td><td><a href=\"../05_betrieb/20260528_bcm_runbook.md\">BCM-Runbook<\/a><\/td><\/tr><tr><td>A.5.31<\/td><td>Gesetzliche &amp; vertragliche Anforderungen<\/td><td>Ja<\/td><td>Umgesetzt<\/td><td><a href=\"../05_betrieb/18_Analyse_Recht_und_BestPractice.md\">Recht/BestPractice<\/a>, AGB<\/td><\/tr><tr><td>A.5.32<\/td><td>Geistiges Eigentum<\/td><td>Ja<\/td><td>Teilweise<\/td><td>Lizenz-/OSS-Compliance dokumentieren<\/td><\/tr><tr><td>A.5.33<\/td><td>Schutz von Aufzeichnungen<\/td><td>Ja<\/td><td>Umgesetzt<\/td><td><a href=\"../05_betrieb/13_Datenaufbewahrung_Loeschung_LegalHold.md\">Datenaufbewahrung<\/a><\/td><\/tr><tr><td>A.5.34<\/td><td>Datenschutz &amp; PII-Schutz<\/td><td>Ja<\/td><td>Umgesetzt<\/td><td><a href=\"../05_betrieb/security-overview.md\">security-overview.md<\/a>, DSGVO-Funktionen<\/td><\/tr><tr><td>A.5.35<\/td><td>Unabhängige IS-Prüfung<\/td><td>Ja<\/td><td>Geplant<\/td><td>Externes <a href=\"../06_bewertung/internes-audit.md\">internes Audit<\/a><\/td><\/tr><tr><td>A.5.36<\/td><td>Konformität mit Politiken<\/td><td>Ja<\/td><td>Teilweise<\/td><td>Audit + Konformitätskontrolle<\/td><\/tr><tr><td>A.5.37<\/td><td>Dokumentierte Betriebsabläufe<\/td><td>Ja<\/td><td>Umgesetzt<\/td><td>Runbooks in <code>05_betrieb/<\/code><\/td><\/tr><\/tbody><\/table>\n<h2>A.6 Personenbezogene Controls<\/h2>\n<table><thead><tr><th>Control<\/th><th>Titel<\/th><th>Anwend.<\/th><th>Status<\/th><th>Referenz / Begründung<\/th><\/tr><\/thead><tbody><tr><td>A.6.1<\/td><td>Sicherheitsüberprüfung (Screening)<\/td><td>Ja<\/td><td>Teilweise<\/td><td><a href=\"../05_betrieb/03_Mitarbeitersicherheit_und_Screening.md\">Mitarbeitersicherheit<\/a>; Hintergrundprüfung klären<\/td><\/tr><tr><td>A.6.2<\/td><td>Arbeitsvertragsbedingungen<\/td><td>Ja<\/td><td>Teilweise<\/td><td>IS-Klauseln in Verträgen ergänzen<\/td><\/tr><tr><td>A.6.3<\/td><td>Awareness, Schulung &amp; Ausbildung<\/td><td>Ja<\/td><td>Geplant<\/td><td><a href=\"../04_unterstuetzung/ressourcen-kompetenz-schulung.md\">Kompetenz/Schulung<\/a><\/td><\/tr><tr><td>A.6.4<\/td><td>Disziplinarverfahren<\/td><td>Ja<\/td><td>Geplant<\/td><td>Verfahren in HR-Doku festhalten<\/td><\/tr><tr><td>A.6.5<\/td><td>Verantwortung nach Beendigung<\/td><td>Ja<\/td><td>Teilweise<\/td><td>Offboarding; NDA-Fortgeltung<\/td><\/tr><tr><td>A.6.6<\/td><td>Vertraulichkeits-/NDA-Vereinbarungen<\/td><td>Ja<\/td><td>Teilweise<\/td><td>NDA-Vorlage sicherstellen<\/td><\/tr><tr><td>A.6.7<\/td><td>Remote-Arbeit<\/td><td>Ja<\/td><td>Umgesetzt<\/td><td><a href=\"../05_betrieb/02_Zugriffsmanagement_IAM_PAM.md\">Zugriffsmanagement<\/a>, VPN/Geräte<\/td><\/tr><tr><td>A.6.8<\/td><td>Meldung von IS-Ereignissen<\/td><td>Ja<\/td><td>Umgesetzt<\/td><td><a href=\"../05_betrieb/07_Incident_Response_und_Meldewesen.md\">Incident Response<\/a><\/td><\/tr><\/tbody><\/table>\n<h2>A.7 Physische Controls<\/h2>\n<p>Eigene Büro-Infrastruktur minimal (Remote-Team); Rechenzentrums-Controls liegen beim Cloud-Provider Infomaniak (CH) und werden über dessen Zertifizierungen (ISO 27001) geerbt.<\/p>\n<table><thead><tr><th>Control<\/th><th>Titel<\/th><th>Anwend.<\/th><th>Status<\/th><th>Referenz / Begründung<\/th><\/tr><\/thead><tbody><tr><td>A.7.1<\/td><td>Physische Sicherheitsperimeter<\/td><td>Ja (geerbt)<\/td><td>Umgesetzt<\/td><td>Infomaniak RZ-Zertifizierung<\/td><\/tr><tr><td>A.7.2<\/td><td>Physischer Zutritt<\/td><td>Ja (geerbt)<\/td><td>Umgesetzt<\/td><td>Infomaniak<\/td><\/tr><tr><td>A.7.3<\/td><td>Sicherung von Büros/Räumen<\/td><td>Ja<\/td><td>Teilweise<\/td><td>Home-/Büro-Grundschutz<\/td><\/tr><tr><td>A.7.4<\/td><td>Physische Überwachung<\/td><td>Ja (geerbt)<\/td><td>Umgesetzt<\/td><td>Infomaniak<\/td><\/tr><tr><td>A.7.5<\/td><td>Schutz vor physischen/umweltbed. Bedrohungen<\/td><td>Ja (geerbt)<\/td><td>Umgesetzt<\/td><td>Infomaniak<\/td><\/tr><tr><td>A.7.6<\/td><td>Arbeiten in Sicherheitsbereichen<\/td><td>N/A<\/td><td>N/A<\/td><td>Keine eigenen Sicherheitsbereiche<\/td><\/tr><tr><td>A.7.7<\/td><td>Clear Desk / Clear Screen<\/td><td>Ja<\/td><td>Geplant<\/td><td>Regel in IS-Politik aufnehmen<\/td><\/tr><tr><td>A.7.8<\/td><td>Platzierung &amp; Schutz von Geräten<\/td><td>Ja<\/td><td>Teilweise<\/td><td>Endgeräte-Richtlinie<\/td><\/tr><tr><td>A.7.9<\/td><td>Schutz von Werten ausserhalb<\/td><td>Ja<\/td><td>Teilweise<\/td><td>Geräteverschlüsselung<\/td><\/tr><tr><td>A.7.10<\/td><td>Speichermedien<\/td><td>Ja<\/td><td>Teilweise<\/td><td>Verschlüsselung, sichere Löschung<\/td><\/tr><tr><td>A.7.11<\/td><td>Versorgungseinrichtungen<\/td><td>Ja (geerbt)<\/td><td>Umgesetzt<\/td><td>Infomaniak<\/td><\/tr><tr><td>A.7.12<\/td><td>Verkabelungssicherheit<\/td><td>Ja (geerbt)<\/td><td>Umgesetzt<\/td><td>Infomaniak<\/td><\/tr><tr><td>A.7.13<\/td><td>Instandhaltung von Geräten<\/td><td>Ja<\/td><td>Teilweise<\/td><td>Patch/Wartung Endgeräte<\/td><\/tr><tr><td>A.7.14<\/td><td>Sichere Entsorgung/Wiederverwendung<\/td><td>Ja<\/td><td>Geplant<\/td><td>Lösch-/Entsorgungsregel<\/td><\/tr><\/tbody><\/table>\n<h2>A.8 Technologische Controls<\/h2>\n<table><thead><tr><th>Control<\/th><th>Titel<\/th><th>Anwend.<\/th><th>Status<\/th><th>Referenz / Begründung<\/th><\/tr><\/thead><tbody><tr><td>A.8.1<\/td><td>Endgeräte der Nutzer<\/td><td>Ja<\/td><td>Teilweise<\/td><td>Endgeräte-Richtlinie, Verschlüsselung<\/td><\/tr><tr><td>A.8.2<\/td><td>Privilegierte Zugangsrechte<\/td><td>Ja<\/td><td>Umgesetzt<\/td><td><a href=\"../05_betrieb/02_Zugriffsmanagement_IAM_PAM.md\">Zugriffsmanagement<\/a><\/td><\/tr><tr><td>A.8.3<\/td><td>Informationszugriffsbeschränkung<\/td><td>Ja<\/td><td>Umgesetzt<\/td><td>RBAC, Mandantentrennung<\/td><\/tr><tr><td>A.8.4<\/td><td>Zugriff auf Quellcode<\/td><td>Ja<\/td><td>Umgesetzt<\/td><td>Forgejo-RBAC<\/td><\/tr><tr><td>A.8.5<\/td><td>Sichere Authentisierung<\/td><td>Ja<\/td><td>Umgesetzt<\/td><td><a href=\"../05_betrieb/02_Zugriffsmanagement_IAM_PAM.md\">Zugriffsmanagement<\/a> — MFA Admin/Server (R-03, Juni 2026)<\/td><\/tr><tr><td>A.8.6<\/td><td>Kapazitätsmanagement<\/td><td>Ja<\/td><td>Umgesetzt<\/td><td><a href=\"../05_betrieb/16_Kapazitaetsmanagement.md\">Kapazitätsmanagement<\/a><\/td><\/tr><tr><td>A.8.7<\/td><td>Schutz vor Schadsoftware<\/td><td>Ja<\/td><td>Teilweise<\/td><td>Endpoint-Schutz, Dependency-Scans<\/td><\/tr><tr><td>A.8.8<\/td><td>Management techn. Schwachstellen<\/td><td>Ja<\/td><td>Umgesetzt<\/td><td><a href=\"../05_betrieb/10_Schwachstellenmanagement.md\">Schwachstellen<\/a>, <a href=\"../05_betrieb/09_Patch_Management.md\">Patch<\/a><\/td><\/tr><tr><td>A.8.9<\/td><td>Konfigurationsmanagement<\/td><td>Ja<\/td><td>Teilweise<\/td><td>.env-Trennung; IaC/Konformität ausbauen<\/td><\/tr><tr><td>A.8.10<\/td><td>Löschung von Information<\/td><td>Ja<\/td><td>Umgesetzt<\/td><td><a href=\"../05_betrieb/13_Datenaufbewahrung_Loeschung_LegalHold.md\">Datenaufbewahrung<\/a>, DSGVO-Löschung<\/td><\/tr><tr><td>A.8.11<\/td><td>Datenmaskierung<\/td><td>Ja<\/td><td>Umgesetzt<\/td><td><a href=\"../05_betrieb/neutralisierung-detail.md\">Neutralisierung<\/a><\/td><\/tr><tr><td>A.8.12<\/td><td>Verhinderung von Datenabfluss<\/td><td>Ja<\/td><td>Teilweise<\/td><td>Neutralisierung, Read-only DB-Zugriff KI<\/td><\/tr><tr><td>A.8.13<\/td><td>Sicherung (Backup)<\/td><td>Ja<\/td><td>Teilweise<\/td><td><a href=\"../05_betrieb/05_Backup_und_Wiederherstellung.md\">Backup<\/a>; Restore-Test offen (R-04)<\/td><\/tr><tr><td>A.8.14<\/td><td>Redundanz von Verarbeitungseinrichtungen<\/td><td>Ja<\/td><td>Teilweise<\/td><td>Provider-Redundanz; dokumentieren<\/td><\/tr><tr><td>A.8.15<\/td><td>Protokollierung (Logging)<\/td><td>Ja<\/td><td>Umgesetzt<\/td><td><a href=\"../05_betrieb/11_Logging_und_Monitoring.md\">Logging &amp; Monitoring<\/a><\/td><\/tr><tr><td>A.8.16<\/td><td>Überwachung von Aktivitäten<\/td><td>Ja<\/td><td>Teilweise<\/td><td>Monitoring ausbauen<\/td><\/tr><tr><td>A.8.17<\/td><td>Uhrzeitsynchronisation<\/td><td>Ja<\/td><td>Umgesetzt<\/td><td>NTP (Infra)<\/td><\/tr><tr><td>A.8.18<\/td><td>Nutzung privilegierter Hilfsprogramme<\/td><td>Ja<\/td><td>Teilweise<\/td><td>Einschränkung/Protokollierung<\/td><\/tr><tr><td>A.8.19<\/td><td>Software-Installation auf Betriebssystemen<\/td><td>Ja<\/td><td>Teilweise<\/td><td>Deployment über CI/CD<\/td><\/tr><tr><td>A.8.20<\/td><td>Netzwerksicherheit<\/td><td>Ja<\/td><td>Umgesetzt<\/td><td><a href=\"../05_betrieb/12_Netzwerk_und_Infrastruktursicherheit.md\">Netzwerk/Infra<\/a><\/td><\/tr><tr><td>A.8.21<\/td><td>Sicherheit von Netzwerkdiensten<\/td><td>Ja<\/td><td>Umgesetzt<\/td><td>TLS, Reverse Proxy<\/td><\/tr><tr><td>A.8.22<\/td><td>Trennung von Netzwerken<\/td><td>Ja<\/td><td>Teilweise<\/td><td>Umgebungstrennung prod/int<\/td><\/tr><tr><td>A.8.23<\/td><td>Web-Filterung<\/td><td>Ja<\/td><td>Teilweise<\/td><td>CORS, Egress-Kontrolle<\/td><\/tr><tr><td>A.8.24<\/td><td>Nutzung von Kryptographie<\/td><td>Ja<\/td><td>Umgesetzt<\/td><td><a href=\"../05_betrieb/04_Verschluesselung_und_Schluesselmanagement.md\">Verschlüsselung &amp; Schlüsselmgmt<\/a><\/td><\/tr><tr><td>A.8.25<\/td><td>Sicherer Entwicklungslebenszyklus<\/td><td>Ja<\/td><td>Umgesetzt<\/td><td><a href=\"../05_betrieb/15_Sichere_Softwareentwicklung_SDLC.md\">SDLC<\/a><\/td><\/tr><tr><td>A.8.26<\/td><td>Anforderungen an Anwendungssicherheit<\/td><td>Ja<\/td><td>Umgesetzt<\/td><td><a href=\"../05_betrieb/15_Sichere_Softwareentwicklung_SDLC.md\">SDLC<\/a><\/td><\/tr><tr><td>A.8.27<\/td><td>Sichere Systemarchitektur &amp; Engineering<\/td><td>Ja<\/td><td>Teilweise<\/td><td>Architektur-Prinzipien dokumentieren<\/td><\/tr><tr><td>A.8.28<\/td><td>Sicheres Codieren<\/td><td>Ja<\/td><td>Umgesetzt<\/td><td><a href=\"../../../d-guides/coding-conventions.md\">Coding-Conventions<\/a>, Review<\/td><\/tr><tr><td>A.8.29<\/td><td>Sicherheitstests in Entw./Abnahme<\/td><td>Ja<\/td><td>Teilweise<\/td><td><a href=\"../../../d-guides/testing-strategy.md\">Testing-Strategie<\/a>, Staging-Verifikation<\/td><\/tr><tr><td>A.8.30<\/td><td>Ausgelagerte Entwicklung<\/td><td>N/A<\/td><td>N/A<\/td><td>Keine ausgelagerte Entwicklung<\/td><\/tr><tr><td>A.8.31<\/td><td>Trennung Entw./Test/Produktion<\/td><td>Ja<\/td><td>Umgesetzt<\/td><td>env-prod/env-int, Staging<\/td><\/tr><tr><td>A.8.32<\/td><td>Change Management<\/td><td>Ja<\/td><td>Umgesetzt<\/td><td><a href=\"../05_betrieb/08_Change_Management.md\">Change Management<\/a><\/td><\/tr><tr><td>A.8.33<\/td><td>Testinformation<\/td><td>Ja<\/td><td>Geplant<\/td><td>Umgang mit Produktivdaten in Test klären<\/td><\/tr><tr><td>A.8.34<\/td><td>Schutz von Systemen bei Audit-Tests<\/td><td>Ja<\/td><td>Teilweise<\/td><td>Auditzugriffe kontrolliert<\/td><\/tr><\/tbody><\/table>\n<h2>Pflege<\/h2>\n<p>Bei jeder wesentlichen Änderung von Controls/Risiken aktualisieren. Das SoA wird im <a href=\"../06_bewertung/management-review.md\">Management-Review<\/a> bestätigt. Teilweise/Geplant-Einträge spiegeln sich im <a href=\"../07_verbesserung/massnahmen-register.md\">Massnahmenregister<\/a>.<\/p>", "text": "<!-- docid: ims-06-03 --> <!-- status: entwurf --> <!-- version: 0.1 --> <!-- owner: patrick motsch --> <!-- approver: geschäftsführung poweron ag --> <!-- approveddate: --> <!-- nextreview: 2026-12-03 --> <!-- classification: vertraulich --> <!-- isorefs: 27001:6.1.3,annexa --> # statement of applicability (soa) -- iso/iec 27001:2022 annex a **dokumenttyp:** pflichtdokument (iso 27001 6.1.3 d) **stand:** 2026-06-03 (entwurf) dieses soa listet alle 93 annex-a-controls (2022) mit anwendbarkeit, begründung, umsetzungsstatus und verweis auf das umsetzende dokument. status: **umgesetzt / teilweise / geplant / n/a**. offene/teilweise punkte sind im [massnahmenregister](../07_verbesserung/massnahmen-register.md) geführt. legende anwendbarkeit: **ja** = anwendbar; **n/a** = nicht anwendbar (mit begründung). cloud-betrieb bei infomaniak (ch): bestimmte physische controls liegen beim provider (anwendbar, \"geerbt\"). ## a.5 organisatorische controls | control | titel | anwend. | status | referenz / begründung | |---|---|---|---|---| | a.5.1 | informationssicherheits-politiken | ja | umgesetzt | [informationssicherheitspolitik.md](../02_fuehrung/informationssicherheitspolitik.md) | | a.5.2 | rollen & verantwortlichkeiten | ja | umgesetzt | [rollen-verantwortlichkeiten.md](../02_fuehrung/rollen-verantwortlichkeiten.md) | | a.5.3 | aufgabentrennung | ja | teilweise | klein-team; kompensierend vier-augen-prinzip, externes audit | | a.5.4 | verantwortung der leitung | ja | umgesetzt | [00_ims-handbuch.md](../00_ims-handbuch.md), management-review | | a.5.5 | kontakt zu behörden | ja | geplant | meldewege (edoeb/finma) in [incident response](../05_betrieb/07_incident_response_und_meldewesen.md) festhalten | | a.5.6 | kontakt zu interessengruppen | ja | teilweise | security-quellen/cert-feeds; formalisieren | | a.5.7 | threat intelligence | ja | teilweise | [schwachstellenmanagement](../05_betrieb/10_schwachstellenmanagement.md) | | a.5.8 | is im projektmanagement | ja | umgesetzt | [sdlc](../05_betrieb/15_sichere_softwareentwicklung_sdlc.md), tech-workshop | | a.5.9 | inventar der werte (assets) | ja | teilweise | [drittanbieter-inventar](../05_betrieb/20260528_drittanbieter-inventar.md); asset-inventar ergänzen | | a.5.10 | zulässige nutzung von werten | ja | geplant | acceptable-use in is-politik konkretisieren | | a.5.11 | rückgabe von werten | ja | geplant | offboarding-checkliste ([mitarbeitersicherheit](../05_betrieb/03_mitarbeitersicherheit_und_screening.md)) | | a.5.12 | klassifizierung von information | ja | teilweise | klassifizierungsschema (header `classification`); ausweiten | | a.5.13 | kennzeichnung von information | ja | teilweise | header-klassifizierung; daten-labeling ergänzen | | a.5.14 | informationsübertragung | ja | umgesetzt | [verschlüsselung](../05_betrieb/04_verschluesselung_und_schluesselmanagement.md), tls, [neutralisierung](../05_betrieb/neutralisierung-detail.md) | | a.5.15 | zugangssteuerung | ja | umgesetzt | [zugriffsmanagement](../05_betrieb/02_zugriffsmanagement_iam_pam.md), rbac | | a.5.16 | identitätsmanagement | ja | umgesetzt | [zugriffsmanagement](../05_betrieb/02_zugriffsmanagement_iam_pam.md) | | a.5.17 | authentisierungsinformation | ja | umgesetzt | [zugriffsmanagement](../05_betrieb/02_zugriffsmanagement_iam_pam.md) — mfa admin/server (r-03, juni 2026) | | a.5.18 | zugangsrechte | ja | umgesetzt | [zugriffsmanagement](../05_betrieb/02_zugriffsmanagement_iam_pam.md) | | a.5.19 | is in lieferantenbeziehungen | ja | umgesetzt | [subunternehmer](../05_betrieb/17_subunternehmer_management.md) | | a.5.20 | is in lieferantenvereinbarungen | ja | teilweise | avvs vervollständigen (openai zero-retention) | | a.5.21 | is in der ikt-lieferkette | ja | teilweise | [drittanbieter-inventar](../05_betrieb/20260528_drittanbieter-inventar.md) | | a.5.22 | überwachung der lieferantenleistung | ja | geplant | review-turnus lieferanten festlegen | | a.5.23 | is bei nutzung von cloud-diensten | ja | umgesetzt | infomaniak (ch); [netzwerk/infra](../05_betrieb/12_netzwerk_und_infrastruktursicherheit.md) | | a.5.24 | incident-management planung | ja | umgesetzt | [incident response](../05_betrieb/07_incident_response_und_meldewesen.md) | | a.5.25 | bewertung von is-ereignissen | ja | umgesetzt | [incident response](../05_betrieb/07_incident_response_und_meldewesen.md) | | a.5.26 | reaktion auf is-vorfälle | ja | umgesetzt | [incident response](../05_betrieb/07_incident_response_und_meldewesen.md) | | a.5.27 | lernen aus vorfällen | ja | teilweise | post-incident-review -> [kvp](../07_verbesserung/korrekturmassnahmen-und-kvp.md) | | a.5.28 | sammlung von beweismitteln | ja | teilweise | logs/forensik in [logging](../05_betrieb/11_logging_und_monitoring.md) | | a.5.29 | is während störung | ja | umgesetzt | [bcm/dr](../05_betrieb/06_business_continuity_und_disaster_recovery.md) | | a.5.30 | ikt-bereitschaft für bc | ja | umgesetzt | [bcm-runbook](../05_betrieb/20260528_bcm_runbook.md) | | a.5.31 | gesetzliche & vertragliche anforderungen | ja | umgesetzt | [recht/bestpractice](../05_betrieb/18_analyse_recht_und_bestpractice.md), agb | | a.5.32 | geistiges eigentum | ja | teilweise | lizenz-/oss-compliance dokumentieren | | a.5.33 | schutz von aufzeichnungen | ja | umgesetzt | [datenaufbewahrung](../05_betrieb/13_datenaufbewahrung_loeschung_legalhold.md) | | a.5.34 | datenschutz & pii-schutz | ja | umgesetzt | [security-overview.md](../05_betrieb/security-overview.md), dsgvo-funktionen | | a.5.35 | unabhängige is-prüfung | ja | geplant | externes [internes audit](../06_bewertung/internes-audit.md) | | a.5.36 | konformität mit politiken | ja | teilweise | audit + konformitätskontrolle | | a.5.37 | dokumentierte betriebsabläufe | ja | umgesetzt | runbooks in `05_betrieb/` | ## a.6 personenbezogene controls | control | titel | anwend. | status | referenz / begründung | |---|---|---|---|---| | a.6.1 | sicherheitsüberprüfung (screening) | ja | teilweise | [mitarbeitersicherheit](../05_betrieb/03_mitarbeitersicherheit_und_screening.md); hintergrundprüfung klären | | a.6.2 | arbeitsvertragsbedingungen | ja | teilweise | is-klauseln in verträgen ergänzen | | a.6.3 | awareness, schulung & ausbildung | ja | geplant | [kompetenz/schulung](../04_unterstuetzung/ressourcen-kompetenz-schulung.md) | | a.6.4 | disziplinarverfahren | ja | geplant | verfahren in hr-doku festhalten | | a.6.5 | verantwortung nach beendigung | ja | teilweise | offboarding; nda-fortgeltung | | a.6.6 | vertraulichkeits-/nda-vereinbarungen | ja | teilweise | nda-vorlage sicherstellen | | a.6.7 | remote-arbeit | ja | umgesetzt | [zugriffsmanagement](../05_betrieb/02_zugriffsmanagement_iam_pam.md), vpn/geräte | | a.6.8 | meldung von is-ereignissen | ja | umgesetzt | [incident response](../05_betrieb/07_incident_response_und_meldewesen.md) | ## a.7 physische controls eigene büro-infrastruktur minimal (remote-team); rechenzentrums-controls liegen beim cloud-provider infomaniak (ch) und werden über dessen zertifizierungen (iso 27001) geerbt. | control | titel | anwend. | status | referenz / begründung | |---|---|---|---|---| | a.7.1 | physische sicherheitsperimeter | ja (geerbt) | umgesetzt | infomaniak rz-zertifizierung | | a.7.2 | physischer zutritt | ja (geerbt) | umgesetzt | infomaniak | | a.7.3 | sicherung von büros/räumen | ja | teilweise | home-/büro-grundschutz | | a.7.4 | physische überwachung | ja (geerbt) | umgesetzt | infomaniak | | a.7.5 | schutz vor physischen/umweltbed. bedrohungen | ja (geerbt) | umgesetzt | infomaniak | | a.7.6 | arbeiten in sicherheitsbereichen | n/a | n/a | keine eigenen sicherheitsbereiche | | a.7.7 | clear desk / clear screen | ja | geplant | regel in is-politik aufnehmen | | a.7.8 | platzierung & schutz von geräten | ja | teilweise | endgeräte-richtlinie | | a.7.9 | schutz von werten ausserhalb | ja | teilweise | geräteverschlüsselung | | a.7.10 | speichermedien | ja | teilweise | verschlüsselung, sichere löschung | | a.7.11 | versorgungseinrichtungen | ja (geerbt) | umgesetzt | infomaniak | | a.7.12 | verkabelungssicherheit | ja (geerbt) | umgesetzt | infomaniak | | a.7.13 | instandhaltung von geräten | ja | teilweise | patch/wartung endgeräte | | a.7.14 | sichere entsorgung/wiederverwendung | ja | geplant | lösch-/entsorgungsregel | ## a.8 technologische controls | control | titel | anwend. | status | referenz / begründung | |---|---|---|---|---| | a.8.1 | endgeräte der nutzer | ja | teilweise | endgeräte-richtlinie, verschlüsselung | | a.8.2 | privilegierte zugangsrechte | ja | umgesetzt | [zugriffsmanagement](../05_betrieb/02_zugriffsmanagement_iam_pam.md) | | a.8.3 | informationszugriffsbeschränkung | ja | umgesetzt | rbac, mandantentrennung | | a.8.4 | zugriff auf quellcode | ja | umgesetzt | forgejo-rbac | | a.8.5 | sichere authentisierung | ja | umgesetzt | [zugriffsmanagement](../05_betrieb/02_zugriffsmanagement_iam_pam.md) — mfa admin/server (r-03, juni 2026) | | a.8.6 | kapazitätsmanagement | ja | umgesetzt | [kapazitätsmanagement](../05_betrieb/16_kapazitaetsmanagement.md) | | a.8.7 | schutz vor schadsoftware | ja | teilweise | endpoint-schutz, dependency-scans | | a.8.8 | management techn. schwachstellen | ja | umgesetzt | [schwachstellen](../05_betrieb/10_schwachstellenmanagement.md), [patch](../05_betrieb/09_patch_management.md) | | a.8.9 | konfigurationsmanagement | ja | teilweise | .env-trennung; iac/konformität ausbauen | | a.8.10 | löschung von information | ja | umgesetzt | [datenaufbewahrung](../05_betrieb/13_datenaufbewahrung_loeschung_legalhold.md), dsgvo-löschung | | a.8.11 | datenmaskierung | ja | umgesetzt | [neutralisierung](../05_betrieb/neutralisierung-detail.md) | | a.8.12 | verhinderung von datenabfluss | ja | teilweise | neutralisierung, read-only db-zugriff ki | | a.8.13 | sicherung (backup) | ja | teilweise | [backup](../05_betrieb/05_backup_und_wiederherstellung.md); restore-test offen (r-04) | | a.8.14 | redundanz von verarbeitungseinrichtungen | ja | teilweise | provider-redundanz; dokumentieren | | a.8.15 | protokollierung (logging) | ja | umgesetzt | [logging & monitoring](../05_betrieb/11_logging_und_monitoring.md) | | a.8.16 | überwachung von aktivitäten | ja | teilweise | monitoring ausbauen | | a.8.17 | uhrzeitsynchronisation | ja | umgesetzt | ntp (infra) | | a.8.18 | nutzung privilegierter hilfsprogramme | ja | teilweise | einschränkung/protokollierung | | a.8.19 | software-installation auf betriebssystemen | ja | teilweise | deployment über ci/cd | | a.8.20 | netzwerksicherheit | ja | umgesetzt | [netzwerk/infra](../05_betrieb/12_netzwerk_und_infrastruktursicherheit.md) | | a.8.21 | sicherheit von netzwerkdiensten | ja | umgesetzt | tls, reverse proxy | | a.8.22 | trennung von netzwerken | ja | teilweise | umgebungstrennung prod/int | | a.8.23 | web-filterung | ja | teilweise | cors, egress-kontrolle | | a.8.24 | nutzung von kryptographie | ja | umgesetzt | [verschlüsselung & schlüsselmgmt](../05_betrieb/04_verschluesselung_und_schluesselmanagement.md) | | a.8.25 | sicherer entwicklungslebenszyklus | ja | umgesetzt | [sdlc](../05_betrieb/15_sichere_softwareentwicklung_sdlc.md) | | a.8.26 | anforderungen an anwendungssicherheit | ja | umgesetzt | [sdlc](../05_betrieb/15_sichere_softwareentwicklung_sdlc.md) | | a.8.27 | sichere systemarchitektur & engineering | ja | teilweise | architektur-prinzipien dokumentieren | | a.8.28 | sicheres codieren | ja | umgesetzt | [coding-conventions](../../../d-guides/coding-conventions.md), review | | a.8.29 | sicherheitstests in entw./abnahme | ja | teilweise | [testing-strategie](../../../d-guides/testing-strategy.md), staging-verifikation | | a.8.30 | ausgelagerte entwicklung | n/a | n/a | keine ausgelagerte entwicklung | | a.8.31 | trennung entw./test/produktion | ja | umgesetzt | env-prod/env-int, staging | | a.8.32 | change management | ja | umgesetzt | [change management](../05_betrieb/08_change_management.md) | | a.8.33 | testinformation | ja | geplant | umgang mit produktivdaten in test klären | | a.8.34 | schutz von systemen bei audit-tests | ja | teilweise | auditzugriffe kontrolliert | ## pflege bei jeder wesentlichen änderung von controls/risiken aktualisieren. das soa wird im [management-review](../06_bewertung/management-review.md) bestätigt. teilweise/geplant-einträge spiegeln sich im [massnahmenregister](../07_verbesserung/massnahmen-register.md). ", "nextReview": "2026-12-03", "overdueReview": false, "zuPruefen": []}, {"id": "03_planung/ziele-und-kennzahlen.md", "path": "03_planung/ziele-und-kennzahlen.md", "chapter": "03_planung", "title": "Ziele & Kennzahlen (Qualität und Informationssicherheit)", "filename": "ziele-und-kennzahlen.md", "meta": {"docId": "IMS-06-04", "status": "entwurf", "version": "0.1", "owner": "Patrick Motsch", "approver": "Geschäftsführung PowerOn AG", "approvedDate": "", "nextReview": "2027-06-03", "classification": "intern", "isoRefs": "9001:6.2; 27001:6.2,9.1"}, "html": "<h1>Ziele &amp; Kennzahlen (Qualität und Informationssicherheit)<\/h1>\n<p><strong>Dokumenttyp:<\/strong> Pflichtdokument (ISO 9001 6.2 / ISO 27001 6.2) <strong>Messperiode:<\/strong> Kalenderjahr 2026 (Erstfestlegung)<\/p>\n<p>Ziele sind messbar, terminiert und einem Owner zugeordnet. Die Messung erfolgt gemäss <a href=\"../06_bewertung/monitoring-messung.md\">Monitoring &amp; Messung<\/a>; Bewertung im <a href=\"../06_bewertung/management-review.md\">Management-Review<\/a>.<\/p>\n<h2>1. Qualitätsziele (ISO 9001)<\/h2>\n<table><thead><tr><th>ID<\/th><th>Ziel<\/th><th>Kennzahl (KPI)<\/th><th>Zielwert<\/th><th>Owner<\/th><\/tr><\/thead><tbody><tr><td>Q-1<\/td><td>Stabile Releases<\/td><td>Anteil Releases ohne Rollback/Hotfix &lt; 48h<\/td><td>&gt;= 95 %<\/td><td>Patrick Motsch<\/td><\/tr><tr><td>Q-2<\/td><td>Schnelle Fehlerbehebung<\/td><td>Einhaltung Bug-SLOs (kritisch 24h)<\/td><td>&gt;= 90 %<\/td><td>Patrick Motsch<\/td><\/tr><tr><td>Q-3<\/td><td>Nachvollziehbarkeit<\/td><td>Releases mit vollständigen Release Notes/CHANGELOG<\/td><td>100 %<\/td><td>Patrick Motsch<\/td><\/tr><tr><td>Q-4<\/td><td>Kundenzufriedenheit<\/td><td>Bearbeitete Support-Tickets in SLA<\/td><td>&gt;= 90 %<\/td><td>Patrick Motsch<\/td><\/tr><\/tbody><\/table>\n<h2>2. Informationssicherheitsziele (ISO 27001)<\/h2>\n<table><thead><tr><th>ID<\/th><th>Ziel<\/th><th>Kennzahl (KPI)<\/th><th>Zielwert<\/th><th>Owner<\/th><\/tr><\/thead><tbody><tr><td>S-1<\/td><td>Risiken unter Kontrolle<\/td><td>Offene Risiken Klasse hoch+<\/td><td>0 unbehandelt<\/td><td>Patrick Motsch<\/td><\/tr><tr><td>S-2<\/td><td>Aktuelle Systeme<\/td><td>Kritische Schwachstellen gepatcht innert SLA<\/td><td>100 %<\/td><td>Patrick Motsch<\/td><\/tr><tr><td>S-3<\/td><td>Wiederherstellbarkeit<\/td><td>Erfolgreiche Restore-Tests pro Jahr<\/td><td>&gt;= 2<\/td><td>Patrick Motsch<\/td><\/tr><tr><td>S-4<\/td><td>Zugriffssicherheit<\/td><td>Admin-/Server-Zugänge mit MFA<\/td><td>100 % (erreicht Juni 2026)<\/td><td>Patrick Motsch<\/td><\/tr><tr><td>S-5<\/td><td>Awareness<\/td><td>Mitarbeitende mit jährlicher IS-Schulung<\/td><td>100 %<\/td><td>Patrick Motsch<\/td><\/tr><tr><td>S-6<\/td><td>Vorfallreaktion<\/td><td>Incidents innerhalb Zielreaktionszeit behandelt<\/td><td>&gt;= 95 %<\/td><td>Patrick Motsch<\/td><\/tr><\/tbody><\/table>\n<h2>3. IMS-Aufbauziel (2026)<\/h2>\n<table><thead><tr><th>ID<\/th><th>Ziel<\/th><th>Kennzahl<\/th><th>Zielwert<\/th><th>Termin<\/th><\/tr><\/thead><tbody><tr><td>IMS-1<\/td><td>Gelebtes, audit-reifes IMS<\/td><td>1 internes Audit + 1 Management-Review durchgeführt<\/td><td>erfüllt<\/td><td>2026 Q3<\/td><\/tr><tr><td>IMS-2<\/td><td>Dokumentenpflege<\/td><td>Dokumente ohne überfälliges Review<\/td><td>100 %<\/td><td>laufend<\/td><\/tr><\/tbody><\/table>\n<h2>4. Pflege<\/h2>\n<p>Zielwerte werden jährlich im Management-Review überprüft und neu festgelegt. Abweichungen lösen Massnahmen im <a href=\"../07_verbesserung/massnahmen-register.md\">Massnahmenregister<\/a> aus.<\/p>", "text": "<!-- docid: ims-06-04 --> <!-- status: entwurf --> <!-- version: 0.1 --> <!-- owner: patrick motsch --> <!-- approver: geschäftsführung poweron ag --> <!-- approveddate: --> <!-- nextreview: 2027-06-03 --> <!-- classification: intern --> <!-- isorefs: 9001:6.2; 27001:6.2,9.1 --> # ziele & kennzahlen (qualität und informationssicherheit) **dokumenttyp:** pflichtdokument (iso 9001 6.2 / iso 27001 6.2) **messperiode:** kalenderjahr 2026 (erstfestlegung) ziele sind messbar, terminiert und einem owner zugeordnet. die messung erfolgt gemäss [monitoring & messung](../06_bewertung/monitoring-messung.md); bewertung im [management-review](../06_bewertung/management-review.md). ## 1. qualitätsziele (iso 9001) | id | ziel | kennzahl (kpi) | zielwert | owner | |---|---|---|---|---| | q-1 | stabile releases | anteil releases ohne rollback/hotfix < 48h | >= 95 % | patrick motsch | | q-2 | schnelle fehlerbehebung | einhaltung bug-slos (kritisch 24h) | >= 90 % | patrick motsch | | q-3 | nachvollziehbarkeit | releases mit vollständigen release notes/changelog | 100 % | patrick motsch | | q-4 | kundenzufriedenheit | bearbeitete support-tickets in sla | >= 90 % | patrick motsch | ## 2. informationssicherheitsziele (iso 27001) | id | ziel | kennzahl (kpi) | zielwert | owner | |---|---|---|---|---| | s-1 | risiken unter kontrolle | offene risiken klasse hoch+ | 0 unbehandelt | patrick motsch | | s-2 | aktuelle systeme | kritische schwachstellen gepatcht innert sla | 100 % | patrick motsch | | s-3 | wiederherstellbarkeit | erfolgreiche restore-tests pro jahr | >= 2 | patrick motsch | | s-4 | zugriffssicherheit | admin-/server-zugänge mit mfa | 100 % (erreicht juni 2026) | patrick motsch | | s-5 | awareness | mitarbeitende mit jährlicher is-schulung | 100 % | patrick motsch | | s-6 | vorfallreaktion | incidents innerhalb zielreaktionszeit behandelt | >= 95 % | patrick motsch | ## 3. ims-aufbauziel (2026) | id | ziel | kennzahl | zielwert | termin | |---|---|---|---|---| | ims-1 | gelebtes, audit-reifes ims | 1 internes audit + 1 management-review durchgeführt | erfüllt | 2026 q3 | | ims-2 | dokumentenpflege | dokumente ohne überfälliges review | 100 % | laufend | ## 4. pflege zielwerte werden jährlich im management-review überprüft und neu festgelegt. abweichungen lösen massnahmen im [massnahmenregister](../07_verbesserung/massnahmen-register.md) aus. ", "nextReview": "2027-06-03", "overdueReview": false, "zuPruefen": []}, {"id": "04_unterstuetzung/dokumentenlenkung.md", "path": "04_unterstuetzung/dokumentenlenkung.md", "chapter": "04_unterstuetzung", "title": "Lenkung dokumentierter Information", "filename": "dokumentenlenkung.md", "meta": {"docId": "IMS-07-03", "status": "entwurf", "version": "0.1", "owner": "Patrick Motsch", "approver": "Geschäftsführung PowerOn AG", "approvedDate": "", "nextReview": "2027-06-03", "classification": "intern", "isoRefs": "9001:7.5; 27001:7.5"}, "html": "<h1>Lenkung dokumentierter Information<\/h1>\n<p><strong>Dokumenttyp:<\/strong> Verfahren <strong>Geltungsbereich:<\/strong> Alle gelenkten Dokumente des IMS<\/p>\n<p>ISO 9001:2015 Kap. 7.5 und ISO/IEC 27001:2022 Kap. 7.5 verlangen, dass dokumentierte Information erstellt, freigegeben, aktuell gehalten, geschuetzt und gelenkt wird. Dieses Verfahren beschreibt, wie PowerOn das umsetzt -- bewusst schlank und werkzeuggestützt über Git/Forgejo.<\/p>\n<h2>1. Einheitlicher Metadaten-Header<\/h2>\n<p>Jedes gelenkte IMS-Dokument beginnt mit folgendem Header (HTML-Kommentar, im gerenderten Markdown unsichtbar, vom Cockpit ausgewertet):<\/p>\n<pre class=\"code\"><code>&lt;!-- docId: IMS-XX --&gt;\n&lt;!-- status: entwurf | freigegeben | abgelöst --&gt;\n&lt;!-- version: 0.1 --&gt;\n&lt;!-- owner: &lt;Name&gt; --&gt;\n&lt;!-- approver: &lt;Name/Gremium&gt; --&gt;\n&lt;!-- approvedDate: YYYY-MM-DD --&gt;\n&lt;!-- nextReview: YYYY-MM-DD --&gt;\n&lt;!-- classification: öffentlich | intern | vertraulich --&gt;\n&lt;!-- isoRefs: 9001:&lt;klausel&gt;; 27001:&lt;klausel/AnnexA&gt; --&gt;<\/code><\/pre>\n<table><thead><tr><th>Feld<\/th><th>Bedeutung<\/th><\/tr><\/thead><tbody><tr><td><code>docId<\/code><\/td><td>Eindeutige Dokument-ID (Schema: <code>IMS-&lt;Kapitel&gt;-&lt;Laufnr&gt;<\/code>)<\/td><\/tr><tr><td><code>status<\/code><\/td><td><code>entwurf<\/code> (in Arbeit), <code>freigegeben<\/code> (gültig), <code>abgelöst<\/code> (ersetzt/veraltet)<\/td><\/tr><tr><td><code>version<\/code><\/td><td>Semantisch: 0.x = Entwurf, ab 1.0 = freigegeben; Minor bei inhaltlichen Änderungen<\/td><\/tr><tr><td><code>owner<\/code><\/td><td>Fachlich verantwortliche Person (Pflege)<\/td><\/tr><tr><td><code>approver<\/code><\/td><td>Freigebende Person/Gremium<\/td><\/tr><tr><td><code>approvedDate<\/code><\/td><td>Datum der letzten Freigabe<\/td><\/tr><tr><td><code>nextReview<\/code><\/td><td>Spätestes nächstes Review (Standard: +12 Monate)<\/td><\/tr><tr><td><code>classification<\/code><\/td><td>Schutzbedarf gemäss IS-Politik<\/td><\/tr><tr><td><code>isoRefs<\/code><\/td><td>Abgedeckte Normklauseln/Annex-A-Controls<\/td><\/tr><\/tbody><\/table>\n<h2>2. Lebenszyklus<\/h2>\n<pre class=\"mermaid\">flowchart LR\n    draft[\"entwurf (0.x)\"] --&gt;|\"PR-Review + Freigabe\"| released[\"freigegeben (&gt;=1.0)\"]\n    released --&gt;|\"Änderung\"| draft\n    released --&gt;|\"ersetzt durch Nachfolger\"| retired[\"abgelöst\"]<\/pre>\n<ol><li><strong>Erstellen/Ändern:<\/strong> Auf Branch, Inhalt + Header pflegen.<\/li><li><strong>Freigabe:<\/strong> Pull Request mit Review durch zweite Person (Vier-Augen-Prinzip); Merge = Freigabe. <code>status<\/code> -&gt; <code>freigegeben<\/code>, <code>version<\/code> &gt;= 1.0, <code>approvedDate<\/code> + <code>nextReview<\/code> setzen.<\/li><li><strong>Versionierung &amp; Historie:<\/strong> Git/Forgejo ist die verbindliche Versions- und Änderungshistorie (Commit = Änderungsnachweis).<\/li><li><strong>Ablösung:<\/strong> Ersetzte Dokumente erhalten <code>status: abgelöst<\/code> und einen Vorwärts-Link zum Nachfolger; sie werden nicht gelöscht (Nachvollziehbarkeit).<\/li><\/ol>\n<h2>3. Review-Zyklus (\"gepflegt\")<\/h2>\n<ul><li>Jedes Dokument hat ein <code>nextReview<\/code>-Datum (Standard 12 Monate, anlassbezogen früher).<\/li><li>Das <a href=\"../cockpit/\">Management-Cockpit<\/a> listet überfällige und anstehende Reviews automatisch auf der Pendenzen-Seite.<\/li><li>Reviews werden im <a href=\"dokumentenregister.md\">Dokumentenregister<\/a> nachgeführt; fällige Reviews erzeugen bei Bedarf einen Eintrag im <a href=\"../07_verbesserung/massnahmen-register.md\">Massnahmenregister<\/a>.<\/li><\/ul>\n<h2>4. Schutz und Zugriff<\/h2>\n<ul><li>Vertrauliche Dokumente folgen der Klassifizierung der IS-Politik; das Repository ist zugriffsgeschuetzt (Forgejo-RBAC).<\/li><li>Externe Verteilung nur in freigegebenem Stand; das Cockpit kann als in sich geschlossene HTML zum Teilen erzeugt werden.<\/li><\/ul>\n<h2>5. Externe Dokumente<\/h2>\n<p>Extern vorgegebene Dokumente (Normtexte, Verträge, AVVs der Lieferanten) werden im <a href=\"../05_betrieb/20260528_drittanbieter-inventar.md\">Drittanbieter-Inventar<\/a> bzw. als Records referenziert und als solche gekennzeichnet.<\/p>", "text": "<!-- docid: ims-07-03 --> <!-- status: entwurf --> <!-- version: 0.1 --> <!-- owner: patrick motsch --> <!-- approver: geschäftsführung poweron ag --> <!-- approveddate: --> <!-- nextreview: 2027-06-03 --> <!-- classification: intern --> <!-- isorefs: 9001:7.5; 27001:7.5 --> # lenkung dokumentierter information **dokumenttyp:** verfahren **geltungsbereich:** alle gelenkten dokumente des ims iso 9001:2015 kap. 7.5 und iso/iec 27001:2022 kap. 7.5 verlangen, dass dokumentierte information erstellt, freigegeben, aktuell gehalten, geschuetzt und gelenkt wird. dieses verfahren beschreibt, wie poweron das umsetzt -- bewusst schlank und werkzeuggestützt über git/forgejo. ## 1. einheitlicher metadaten-header jedes gelenkte ims-dokument beginnt mit folgendem header (html-kommentar, im gerenderten markdown unsichtbar, vom cockpit ausgewertet): ``` <!-- docid: ims-xx --> <!-- status: entwurf | freigegeben | abgelöst --> <!-- version: 0.1 --> <!-- owner: <name> --> <!-- approver: <name/gremium> --> <!-- approveddate: yyyy-mm-dd --> <!-- nextreview: yyyy-mm-dd --> <!-- classification: öffentlich | intern | vertraulich --> <!-- isorefs: 9001:<klausel>; 27001:<klausel/annexa> --> ``` | feld | bedeutung | |---|---| | `docid` | eindeutige dokument-id (schema: `ims-<kapitel>-<laufnr>`) | | `status` | `entwurf` (in arbeit), `freigegeben` (gültig), `abgelöst` (ersetzt/veraltet) | | `version` | semantisch: 0.x = entwurf, ab 1.0 = freigegeben; minor bei inhaltlichen änderungen | | `owner` | fachlich verantwortliche person (pflege) | | `approver` | freigebende person/gremium | | `approveddate` | datum der letzten freigabe | | `nextreview` | spätestes nächstes review (standard: +12 monate) | | `classification` | schutzbedarf gemäss is-politik | | `isorefs` | abgedeckte normklauseln/annex-a-controls | ## 2. lebenszyklus ```mermaid flowchart lr draft[\"entwurf (0.x)\"] -->|\"pr-review + freigabe\"| released[\"freigegeben (>=1.0)\"] released -->|\"änderung\"| draft released -->|\"ersetzt durch nachfolger\"| retired[\"abgelöst\"] ``` 1. **erstellen/ändern:** auf branch, inhalt + header pflegen. 2. **freigabe:** pull request mit review durch zweite person (vier-augen-prinzip); merge = freigabe. `status` -> `freigegeben`, `version` >= 1.0, `approveddate` + `nextreview` setzen. 3. **versionierung & historie:** git/forgejo ist die verbindliche versions- und änderungshistorie (commit = änderungsnachweis). 4. **ablösung:** ersetzte dokumente erhalten `status: abgelöst` und einen vorwärts-link zum nachfolger; sie werden nicht gelöscht (nachvollziehbarkeit). ## 3. review-zyklus (\"gepflegt\") - jedes dokument hat ein `nextreview`-datum (standard 12 monate, anlassbezogen früher). - das [management-cockpit](../cockpit/) listet überfällige und anstehende reviews automatisch auf der pendenzen-seite. - reviews werden im [dokumentenregister](dokumentenregister.md) nachgeführt; fällige reviews erzeugen bei bedarf einen eintrag im [massnahmenregister](../07_verbesserung/massnahmen-register.md). ## 4. schutz und zugriff - vertrauliche dokumente folgen der klassifizierung der is-politik; das repository ist zugriffsgeschuetzt (forgejo-rbac). - externe verteilung nur in freigegebenem stand; das cockpit kann als in sich geschlossene html zum teilen erzeugt werden. ## 5. externe dokumente extern vorgegebene dokumente (normtexte, verträge, avvs der lieferanten) werden im [drittanbieter-inventar](../05_betrieb/20260528_drittanbieter-inventar.md) bzw. als records referenziert und als solche gekennzeichnet. ", "nextReview": "2027-06-03", "overdueReview": false, "zuPruefen": []}, {"id": "04_unterstuetzung/dokumentenregister.md", "path": "04_unterstuetzung/dokumentenregister.md", "chapter": "04_unterstuetzung", "title": "Dokumentenregister", "filename": "dokumentenregister.md", "meta": {"docId": "IMS-07-04", "status": "entwurf", "version": "0.1", "owner": "Patrick Motsch", "approver": "Geschäftsführung PowerOn AG", "approvedDate": "", "nextReview": "2027-06-03", "classification": "intern", "isoRefs": "9001:7.5; 27001:7.5"}, "html": "<h1>Dokumentenregister<\/h1>\n<p>Zentrales Verzeichnis aller gelenkten IMS-Dokumente. Massgeblich für Status, Owner und nächstes Review ist der Header im jeweiligen Dokument; das <a href=\"../cockpit/\">Management-Cockpit<\/a> wertet diese automatisch aus. Diese Tabelle dient der manuellen Gesamtübersicht.<\/p>\n<table><thead><tr><th>docId<\/th><th>Dokument<\/th><th>Pfad<\/th><th>Owner<\/th><th>Status<\/th><\/tr><\/thead><tbody><tr><td>IMS-00<\/td><td>IMS-Handbuch<\/td><td><code>00_IMS-Handbuch.md<\/code><\/td><td>Patrick Motsch<\/td><td>entwurf<\/td><\/tr><tr><td>IMS-04-01<\/td><td>Kontext &amp; interessierte Parteien<\/td><td><code>01_kontext/kontext-und-interessierte-parteien.md<\/code><\/td><td>Patrick Motsch<\/td><td>entwurf<\/td><\/tr><tr><td>IMS-04-02<\/td><td>Geltungsbereich / Scope<\/td><td><code>01_kontext/geltungsbereich-scope.md<\/code><\/td><td>Patrick Motsch<\/td><td>entwurf<\/td><\/tr><tr><td>IMS-05-01<\/td><td>Qualitätspolitik<\/td><td><code>02_fuehrung/qm-politik.md<\/code><\/td><td>Patrick Motsch<\/td><td>entwurf<\/td><\/tr><tr><td>IMS-05-02<\/td><td>Informationssicherheitspolitik<\/td><td><code>02_fuehrung/informationssicherheitspolitik.md<\/code><\/td><td>Patrick Motsch<\/td><td>entwurf<\/td><\/tr><tr><td>IMS-05-03<\/td><td>Rollen &amp; Verantwortlichkeiten<\/td><td><code>02_fuehrung/rollen-verantwortlichkeiten.md<\/code><\/td><td>Patrick Motsch<\/td><td>entwurf<\/td><\/tr><tr><td>IMS-05-04<\/td><td>Organisationsreglement<\/td><td><code>02_fuehrung/organisationsreglement.md<\/code><\/td><td>Patrick Motsch<\/td><td>entwurf<\/td><\/tr><tr><td>IMS-05-05<\/td><td>Personen-Rollen-Mapping<\/td><td><code>02_fuehrung/personen-rollen-mapping.md<\/code><\/td><td>Patrick Motsch<\/td><td>entwurf<\/td><\/tr><tr><td>IMS-06-01<\/td><td>Risikomanagement-Methodik<\/td><td><code>03_planung/risikomanagement-methodik.md<\/code><\/td><td>Patrick Motsch<\/td><td>entwurf<\/td><\/tr><tr><td>IMS-06-02<\/td><td>Risikoregister<\/td><td><code>03_planung/risikoregister.md<\/code><\/td><td>Patrick Motsch<\/td><td>entwurf<\/td><\/tr><tr><td>IMS-06-03<\/td><td>Statement of Applicability (SoA)<\/td><td><code>03_planung/statement-of-applicability-soa.md<\/code><\/td><td>Patrick Motsch<\/td><td>entwurf<\/td><\/tr><tr><td>IMS-06-04<\/td><td>Ziele &amp; Kennzahlen<\/td><td><code>03_planung/ziele-und-kennzahlen.md<\/code><\/td><td>Patrick Motsch<\/td><td>entwurf<\/td><\/tr><tr><td>IMS-07-01<\/td><td>Ressourcen, Kompetenz &amp; Schulung<\/td><td><code>04_unterstuetzung/ressourcen-kompetenz-schulung.md<\/code><\/td><td>Patrick Motsch<\/td><td>entwurf<\/td><\/tr><tr><td>IMS-07-02<\/td><td>Kommunikation<\/td><td><code>04_unterstuetzung/kommunikation.md<\/code><\/td><td>Patrick Motsch<\/td><td>entwurf<\/td><\/tr><tr><td>IMS-07-03<\/td><td>Lenkung dokumentierter Information<\/td><td><code>04_unterstuetzung/dokumentenlenkung.md<\/code><\/td><td>Patrick Motsch<\/td><td>entwurf<\/td><\/tr><tr><td>IMS-07-04<\/td><td>Dokumentenregister<\/td><td><code>04_unterstuetzung/dokumentenregister.md<\/code><\/td><td>Patrick Motsch<\/td><td>entwurf<\/td><\/tr><tr><td>IMS-09-01<\/td><td>Internes Audit<\/td><td><code>06_bewertung/internes-audit.md<\/code><\/td><td>Patrick Motsch<\/td><td>entwurf<\/td><\/tr><tr><td>IMS-09-02<\/td><td>Management-Review<\/td><td><code>06_bewertung/management-review.md<\/code><\/td><td>Patrick Motsch<\/td><td>entwurf<\/td><\/tr><tr><td>IMS-09-03<\/td><td>Monitoring &amp; Messung<\/td><td><code>06_bewertung/monitoring-messung.md<\/code><\/td><td>Patrick Motsch<\/td><td>entwurf<\/td><\/tr><tr><td>IMS-10-01<\/td><td>Korrekturmassnahmen &amp; KVP<\/td><td><code>07_verbesserung/korrekturmassnahmen-und-kvp.md<\/code><\/td><td>Patrick Motsch<\/td><td>entwurf<\/td><\/tr><tr><td>IMS-10-02<\/td><td>Massnahmenregister<\/td><td><code>07_verbesserung/massnahmen-register.md<\/code><\/td><td>Patrick Motsch<\/td><td>entwurf<\/td><\/tr><\/tbody><\/table>\n<h2>Betriebsdokumente (Kap. 8 / Annex A) -- <code>05_betrieb/<\/code><\/h2>\n<p>Die operativen Prozess- und Sicherheitsdokumente (Zugriffsmanagement, Verschlüsselung, Backup, BCM/DR, Incident, Change, Patch, Schwachstellen, Logging, Netzwerk, Datenaufbewahrung, Exit, SDLC, Kapazität, Subunternehmer, Mitarbeitersicherheit) liegen in <code>05_betrieb/<\/code>. Ihre Zuordnung zu ISO-27001-Annex-A-Controls und ISO-9001-Klauseln steht im <a href=\"../03_planung/statement-of-applicability-soa.md\">SoA<\/a> bzw. in den <a href=\"../mappings/\">Mappings<\/a>.<\/p>\n<h2>Hinweis zur Pflege<\/h2>\n<p>Header-Felder (<code>owner<\/code>, <code>status<\/code>, <code>nextReview<\/code>) werden direkt im Dokument gepflegt. Bei neuen Dokumenten hier eine Zeile ergänzen. Die verbindliche Review-Fälligkeit zeigt das Cockpit.<\/p>", "text": "<!-- docid: ims-07-04 --> <!-- status: entwurf --> <!-- version: 0.1 --> <!-- owner: patrick motsch --> <!-- approver: geschäftsführung poweron ag --> <!-- approveddate: --> <!-- nextreview: 2027-06-03 --> <!-- classification: intern --> <!-- isorefs: 9001:7.5; 27001:7.5 --> # dokumentenregister zentrales verzeichnis aller gelenkten ims-dokumente. massgeblich für status, owner und nächstes review ist der header im jeweiligen dokument; das [management-cockpit](../cockpit/) wertet diese automatisch aus. diese tabelle dient der manuellen gesamtübersicht. | docid | dokument | pfad | owner | status | |---|---|---|---|---| | ims-00 | ims-handbuch | `00_ims-handbuch.md` | patrick motsch | entwurf | | ims-04-01 | kontext & interessierte parteien | `01_kontext/kontext-und-interessierte-parteien.md` | patrick motsch | entwurf | | ims-04-02 | geltungsbereich / scope | `01_kontext/geltungsbereich-scope.md` | patrick motsch | entwurf | | ims-05-01 | qualitätspolitik | `02_fuehrung/qm-politik.md` | patrick motsch | entwurf | | ims-05-02 | informationssicherheitspolitik | `02_fuehrung/informationssicherheitspolitik.md` | patrick motsch | entwurf | | ims-05-03 | rollen & verantwortlichkeiten | `02_fuehrung/rollen-verantwortlichkeiten.md` | patrick motsch | entwurf | | ims-05-04 | organisationsreglement | `02_fuehrung/organisationsreglement.md` | patrick motsch | entwurf | | ims-05-05 | personen-rollen-mapping | `02_fuehrung/personen-rollen-mapping.md` | patrick motsch | entwurf | | ims-06-01 | risikomanagement-methodik | `03_planung/risikomanagement-methodik.md` | patrick motsch | entwurf | | ims-06-02 | risikoregister | `03_planung/risikoregister.md` | patrick motsch | entwurf | | ims-06-03 | statement of applicability (soa) | `03_planung/statement-of-applicability-soa.md` | patrick motsch | entwurf | | ims-06-04 | ziele & kennzahlen | `03_planung/ziele-und-kennzahlen.md` | patrick motsch | entwurf | | ims-07-01 | ressourcen, kompetenz & schulung | `04_unterstuetzung/ressourcen-kompetenz-schulung.md` | patrick motsch | entwurf | | ims-07-02 | kommunikation | `04_unterstuetzung/kommunikation.md` | patrick motsch | entwurf | | ims-07-03 | lenkung dokumentierter information | `04_unterstuetzung/dokumentenlenkung.md` | patrick motsch | entwurf | | ims-07-04 | dokumentenregister | `04_unterstuetzung/dokumentenregister.md` | patrick motsch | entwurf | | ims-09-01 | internes audit | `06_bewertung/internes-audit.md` | patrick motsch | entwurf | | ims-09-02 | management-review | `06_bewertung/management-review.md` | patrick motsch | entwurf | | ims-09-03 | monitoring & messung | `06_bewertung/monitoring-messung.md` | patrick motsch | entwurf | | ims-10-01 | korrekturmassnahmen & kvp | `07_verbesserung/korrekturmassnahmen-und-kvp.md` | patrick motsch | entwurf | | ims-10-02 | massnahmenregister | `07_verbesserung/massnahmen-register.md` | patrick motsch | entwurf | ## betriebsdokumente (kap. 8 / annex a) -- `05_betrieb/` die operativen prozess- und sicherheitsdokumente (zugriffsmanagement, verschlüsselung, backup, bcm/dr, incident, change, patch, schwachstellen, logging, netzwerk, datenaufbewahrung, exit, sdlc, kapazität, subunternehmer, mitarbeitersicherheit) liegen in `05_betrieb/`. ihre zuordnung zu iso-27001-annex-a-controls und iso-9001-klauseln steht im [soa](../03_planung/statement-of-applicability-soa.md) bzw. in den [mappings](../mappings/). ## hinweis zur pflege header-felder (`owner`, `status`, `nextreview`) werden direkt im dokument gepflegt. bei neuen dokumenten hier eine zeile ergänzen. die verbindliche review-fälligkeit zeigt das cockpit. ", "nextReview": "2027-06-03", "overdueReview": false, "zuPruefen": []}, {"id": "04_unterstuetzung/kommunikation.md", "path": "04_unterstuetzung/kommunikation.md", "chapter": "04_unterstuetzung", "title": "Kommunikation (intern und extern)", "filename": "kommunikation.md", "meta": {"docId": "IMS-07-02", "status": "entwurf", "version": "0.1", "owner": "Patrick Motsch", "approver": "Geschäftsführung PowerOn AG", "approvedDate": "", "nextReview": "2027-06-03", "classification": "intern", "isoRefs": "9001:7.4; 27001:7.4"}, "html": "<h1>Kommunikation (intern und extern)<\/h1>\n<p><strong>Dokumenttyp:<\/strong> Verfahren (ISO 9001/27001 Kap. 7.4)<\/p>\n<p>Regelt, <strong>was, wann, mit wem und wie<\/strong> im Kontext des IMS kommuniziert wird.<\/p>\n<h2>1. Interne Kommunikation<\/h2>\n<table><thead><tr><th>Was<\/th><th>Wann<\/th><th>Wer -&gt; Wem<\/th><th>Kanal<\/th><\/tr><\/thead><tbody><tr><td>Politiken, Ziele, IMS-Änderungen<\/td><td>Bei Änderung / jährlich<\/td><td>Leitung -&gt; Team<\/td><td>Wiki, Teammeeting<\/td><\/tr><tr><td>Risiken, offene Massnahmen<\/td><td>laufend<\/td><td>ISB/QMB -&gt; Team<\/td><td>Massnahmenregister, Cockpit<\/td><\/tr><tr><td>Incidents<\/td><td>sofort<\/td><td>Melder -&gt; Incident-Verantwortlicher<\/td><td>definierter Meldeweg<\/td><\/tr><tr><td>Release Notes / Changes<\/td><td>je Release<\/td><td>Release-Verantwortlicher -&gt; Team<\/td><td>CHANGELOG, Wiki<\/td><\/tr><tr><td>Management-Review-Ergebnisse<\/td><td>nach Review<\/td><td>Leitung -&gt; Team<\/td><td>Protokoll<\/td><\/tr><tr><td>Operations-Meeting<\/td><td>wöchentlich<\/td><td>GF, VSO, OP (+ ggf. FT)<\/td><td>Meeting — Moderation OP; Daily Business, operative Entscheide, Zahlen<\/td><\/tr><tr><td>Verwaltungsrat<\/td><td>ab Jul 2026 2-wöchentlich, ab Q4 2026 monatlich<\/td><td>VR<\/td><td>Strategie, Finanzen, Eskalation aus Operations<\/td><\/tr><tr><td>VR — physisches Treffen<\/td><td>quartalsweise<\/td><td>VR<\/td><td>Abendessen / strategischer Austausch<\/td><\/tr><\/tbody><\/table>\n<p>Rollencodes und Amtsinhaber: <a href=\"../02_fuehrung/personen-rollen-mapping.md\">Personen-Rollen-Mapping<\/a>. Details: <a href=\"../02_fuehrung/organisationsreglement.md\">Organisationsreglement<\/a>.<\/p>\n<h2>2. Externe Kommunikation<\/h2>\n<table><thead><tr><th>Was<\/th><th>Anlass<\/th><th>Wer -&gt; Wem<\/th><th>Kanal<\/th><\/tr><\/thead><tbody><tr><td>Datenschutzvorfall / Meldepflicht<\/td><td>gesetzliche Frist<\/td><td>Datenschutzverantw. -&gt; EDOEB/Betroffene/FINMA<\/td><td>gemäss <a href=\"../05_betrieb/07_Incident_Response_und_Meldewesen.md\">Incident Response<\/a><\/td><\/tr><tr><td>Sicherheits-/Compliance-Nachweise<\/td><td>auf Anfrage<\/td><td>Leitung -&gt; Kunde/Prüfer<\/td><td><a href=\"../05_betrieb/security-overview.md\">security-overview.md<\/a>, SoA-Auszug<\/td><\/tr><tr><td>Wartung / Maintenance Window<\/td><td>mind. 5 Werktage vorab<\/td><td>Betrieb -&gt; Kunden<\/td><td>E-Mail/Statusseite<\/td><\/tr><tr><td>Lieferantenanforderungen<\/td><td>bei Beauftragung<\/td><td>Lieferanten-Verantw. -&gt; Lieferant<\/td><td>Vertrag/AVV<\/td><\/tr><\/tbody><\/table>\n<h2>3. Grundsatz<\/h2>\n<p>Externe sicherheits-/datenschutzrelevante Kommunikation wird ausschliesslich über die benannten Rollen geführt und im freigegebenen Stand verteilt.<\/p>", "text": "<!-- docid: ims-07-02 --> <!-- status: entwurf --> <!-- version: 0.1 --> <!-- owner: patrick motsch --> <!-- approver: geschäftsführung poweron ag --> <!-- approveddate: --> <!-- nextreview: 2027-06-03 --> <!-- classification: intern --> <!-- isorefs: 9001:7.4; 27001:7.4 --> # kommunikation (intern und extern) **dokumenttyp:** verfahren (iso 9001/27001 kap. 7.4) regelt, **was, wann, mit wem und wie** im kontext des ims kommuniziert wird. ## 1. interne kommunikation | was | wann | wer -> wem | kanal | |---|---|---|---| | politiken, ziele, ims-änderungen | bei änderung / jährlich | leitung -> team | wiki, teammeeting | | risiken, offene massnahmen | laufend | isb/qmb -> team | massnahmenregister, cockpit | | incidents | sofort | melder -> incident-verantwortlicher | definierter meldeweg | | release notes / changes | je release | release-verantwortlicher -> team | changelog, wiki | | management-review-ergebnisse | nach review | leitung -> team | protokoll | | operations-meeting | wöchentlich | gf, vso, op (+ ggf. ft) | meeting — moderation op; daily business, operative entscheide, zahlen | | verwaltungsrat | ab jul 2026 2-wöchentlich, ab q4 2026 monatlich | vr | strategie, finanzen, eskalation aus operations | | vr — physisches treffen | quartalsweise | vr | abendessen / strategischer austausch | rollencodes und amtsinhaber: [personen-rollen-mapping](../02_fuehrung/personen-rollen-mapping.md). details: [organisationsreglement](../02_fuehrung/organisationsreglement.md). ## 2. externe kommunikation | was | anlass | wer -> wem | kanal | |---|---|---|---| | datenschutzvorfall / meldepflicht | gesetzliche frist | datenschutzverantw. -> edoeb/betroffene/finma | gemäss [incident response](../05_betrieb/07_incident_response_und_meldewesen.md) | | sicherheits-/compliance-nachweise | auf anfrage | leitung -> kunde/prüfer | [security-overview.md](../05_betrieb/security-overview.md), soa-auszug | | wartung / maintenance window | mind. 5 werktage vorab | betrieb -> kunden | e-mail/statusseite | | lieferantenanforderungen | bei beauftragung | lieferanten-verantw. -> lieferant | vertrag/avv | ## 3. grundsatz externe sicherheits-/datenschutzrelevante kommunikation wird ausschliesslich über die benannten rollen geführt und im freigegebenen stand verteilt. ", "nextReview": "2027-06-03", "overdueReview": false, "zuPruefen": []}, {"id": "04_unterstuetzung/ressourcen-kompetenz-schulung.md", "path": "04_unterstuetzung/ressourcen-kompetenz-schulung.md", "chapter": "04_unterstuetzung", "title": "Ressourcen, Kompetenz, Awareness & Schulung", "filename": "ressourcen-kompetenz-schulung.md", "meta": {"docId": "IMS-07-01", "status": "entwurf", "version": "0.1", "owner": "Patrick Motsch", "approver": "Geschäftsführung PowerOn AG", "approvedDate": "", "nextReview": "2027-06-03", "classification": "intern", "isoRefs": "9001:7.1-7.3; 27001:7.1-7.3,A.6.3"}, "html": "<h1>Ressourcen, Kompetenz, Awareness &amp; Schulung<\/h1>\n<p><strong>Dokumenttyp:<\/strong> Verfahren (ISO 9001/27001 Kap. 7.1-7.3, Annex A.6.3)<\/p>\n<h2>1. Ressourcen (7.1)<\/h2>\n<p>Die Geschäftsführung stellt die für Betrieb und Verbesserung des IMS erforderlichen Ressourcen bereit: Personal, Cloud-Infrastruktur (Infomaniak), Entwicklungs-/CI-Systeme (Forgejo), Tooling sowie Budget für externe Unterstützung (z. B. internes Audit, Penetrationstests).<\/p>\n<h2>2. Kompetenz (7.2)<\/h2>\n<table><thead><tr><th>Kompetenzbereich<\/th><th>Anforderung<\/th><th>Nachweis<\/th><\/tr><\/thead><tbody><tr><td>Sichere Softwareentwicklung<\/td><td>Kenntnis SDLC, Secure Coding, Review<\/td><td>Code-Reviews, Schulungsnachweis<\/td><\/tr><tr><td>Betrieb/DevOps<\/td><td>Deployment, Backup/Restore, Incident-Handling<\/td><td>Runbooks, durchgeführte Tests<\/td><\/tr><tr><td>Datenschutz/Compliance<\/td><td>DSG/DSGVO, AVV, ISO-Grundlagen<\/td><td>Schulungsnachweis<\/td><\/tr><tr><td>Informationssicherheit<\/td><td>Risiko, Annex-A-Controls<\/td><td>Schulungsnachweis<\/td><\/tr><\/tbody><\/table>\n<p>Kompetenzluecken werden im Management-Review identifiziert und über Schulung/externe Unterstützung geschlossen. Kompetenznachweise (Zertifikate, Kursteilnahmen) werden als Records abgelegt.<\/p>\n<h2>3. Awareness (7.3 / A.6.3)<\/h2>\n<ul><li>Alle Mitarbeitenden werden im Onboarding auf IS-Politik, QM-Politik und Meldewege verpflichtet.<\/li><li>Jährliche Auffrischung zu Informationssicherheit und Datenschutz (Ziel S-5: 100 %).<\/li><li>Anlassbezogene Sensibilisierung nach relevanten Incidents.<\/li><\/ul>\n<h2>4. Schulungsnachweis (Record-Vorlage)<\/h2>\n<table><thead><tr><th>Datum<\/th><th>Person<\/th><th>Thema<\/th><th>Form<\/th><th>Nachweis<\/th><\/tr><\/thead><tbody><tr><td><\/td><td><\/td><td><\/td><td><\/td><td><\/td><\/tr><\/tbody><\/table>\n<h2>5. Pflege<\/h2>\n<p>Schulungsplanung und -nachweise werden jährlich aktualisiert; offene Schulungen laufen ins <a href=\"../07_verbesserung/massnahmen-register.md\">Massnahmenregister<\/a>.<\/p>", "text": "<!-- docid: ims-07-01 --> <!-- status: entwurf --> <!-- version: 0.1 --> <!-- owner: patrick motsch --> <!-- approver: geschäftsführung poweron ag --> <!-- approveddate: --> <!-- nextreview: 2027-06-03 --> <!-- classification: intern --> <!-- isorefs: 9001:7.1-7.3; 27001:7.1-7.3,a.6.3 --> # ressourcen, kompetenz, awareness & schulung **dokumenttyp:** verfahren (iso 9001/27001 kap. 7.1-7.3, annex a.6.3) ## 1. ressourcen (7.1) die geschäftsführung stellt die für betrieb und verbesserung des ims erforderlichen ressourcen bereit: personal, cloud-infrastruktur (infomaniak), entwicklungs-/ci-systeme (forgejo), tooling sowie budget für externe unterstützung (z. b. internes audit, penetrationstests). ## 2. kompetenz (7.2) | kompetenzbereich | anforderung | nachweis | |---|---|---| | sichere softwareentwicklung | kenntnis sdlc, secure coding, review | code-reviews, schulungsnachweis | | betrieb/devops | deployment, backup/restore, incident-handling | runbooks, durchgeführte tests | | datenschutz/compliance | dsg/dsgvo, avv, iso-grundlagen | schulungsnachweis | | informationssicherheit | risiko, annex-a-controls | schulungsnachweis | kompetenzluecken werden im management-review identifiziert und über schulung/externe unterstützung geschlossen. kompetenznachweise (zertifikate, kursteilnahmen) werden als records abgelegt. ## 3. awareness (7.3 / a.6.3) - alle mitarbeitenden werden im onboarding auf is-politik, qm-politik und meldewege verpflichtet. - jährliche auffrischung zu informationssicherheit und datenschutz (ziel s-5: 100 %). - anlassbezogene sensibilisierung nach relevanten incidents. ## 4. schulungsnachweis (record-vorlage) | datum | person | thema | form | nachweis | |---|---|---|---|---| | | | | | | ## 5. pflege schulungsplanung und -nachweise werden jährlich aktualisiert; offene schulungen laufen ins [massnahmenregister](../07_verbesserung/massnahmen-register.md). ", "nextReview": "2027-06-03", "overdueReview": false, "zuPruefen": []}, {"id": "05_betrieb/02_Zugriffsmanagement_IAM_PAM.md", "path": "05_betrieb/02_Zugriffsmanagement_IAM_PAM.md", "chapter": "05_betrieb", "title": "Zugriffsmanagement (IAM / PAM)", "filename": "02_Zugriffsmanagement_IAM_PAM.md", "meta": {}, "html": "<h1>Zugriffsmanagement (IAM / PAM)<\/h1>\n<p><strong>Dokumenttyp:<\/strong> Richtlinie &amp; Prozess <strong>Geltungsbereich:<\/strong> Alle Zugänge zu PORTA-Systemen (Server, Datenbank, Admin-UI, Drittdienste) <strong>Version:<\/strong> 1.0 <strong>Status:<\/strong> Entwurf zur internen Freigabe <strong>Owner:<\/strong> Betrieb / DevOps <strong>Letzte Aktualisierung:<\/strong> 02.06.2026 <strong>Deckt ab (CACC):<\/strong> 25, 36, 37, 66, 67, 68, 69<\/p>\n<hr>\n<h2>1. Grundprinzipien<\/h2>\n<p>PowerOn gewährt Zugriffe ausschliesslich nach <strong>Need-to-Know<\/strong> und <strong>Least Privilege<\/strong>. Kein Mitarbeiter erhält mehr Rechte, als für seine Aufgabe erforderlich sind.<\/p>\n<h2>2. Zugriffsebenen der Plattform<\/h2>\n<table><thead><tr><th>Ebene<\/th><th>Beschreibung<\/th><th>Berechtigte<\/th><\/tr><\/thead><tbody><tr><td><strong>SysAdmin (Admin-UI)<\/strong><\/td><td>Höchste Stufe in der PORTA-Admin-UI: DB-Export/Import, Mandatsverwaltung, Feature-Steuerung<\/td><td>Patrick Motsch<\/td><\/tr><tr><td><strong>Server-Zugang (SSH)<\/strong><\/td><td><code>ubuntu@api.poweron.swiss<\/code> / <code>api-int<\/code> — Vollzugriff auf Anwendung und Konfiguration<\/td><td>Patrick Motsch<\/td><\/tr><tr><td><strong>Datenbank<\/strong><\/td><td>DB-User <code>poweron_dev<\/code> auf <code>db.poweron.swiss:5432<\/code><\/td><td>Patrick Motsch<\/td><\/tr><tr><td><strong>Mandats-Administrator (kundenseitig)<\/strong><\/td><td>Verwaltet Nutzer innerhalb des eigenen Tenants<\/td><td>Kunde selbst<\/td><\/tr><tr><td><strong>Endnutzer<\/strong><\/td><td>Nutzung der gebuchten Features<\/td><td>Kunde<\/td><\/tr><\/tbody><\/table>\n<blockquote><strong>Offener Punkt (kompensierende Massnahme nötig):<\/strong> Der SSH-Zugang erfolgt aktuell über den geteilten Benutzer <code>ubuntu<\/code>. Für Nachvollziehbarkeit auf Personenebene ist entweder (a) Umstellung auf personalisierte SSH-Accounts oder (b) lückenlose Protokollierung jeder SSH-Sitzung mit eindeutiger Personenzuordnung erforderlich. → siehe <code>11_Logging_und_Monitoring.md<\/code>. <strong>[ZU PRÜFEN / UMZUSETZEN]<\/strong><\/blockquote>\n<h2>3. Zugang zu Kundendaten im Klartext (#25, #66)<\/h2>\n<p>Mitarbeitende von PowerOn greifen auf Inhaltsdaten eines Kunden im Klartext <strong>nur<\/strong> zu, wenn:<\/p>\n<ol><li>der Kunde dies für einen konkreten Fall (z. B. Support-Ticket) freigegeben hat, <strong>oder<\/strong><\/li><li>eine rechtskräftige behördliche Anordnung dies zwingend verlangt, <strong>oder<\/strong><\/li><li>ein schwerer technischer Störfall den Zugriff temporär erfordert — mit unverzüglicher nachträglicher Information des Kunden.<\/li><\/ol>\n<p>Jeder solche Zugriff wird protokolliert (Datenbank-Export/Import wird serverseitig geloggt, siehe <code>datenbank-handling.md<\/code> Abschnitt 6).<\/p>\n<h2>4. Authentifizierung (#68)<\/h2>\n<table><thead><tr><th>System<\/th><th>Authentifizierungsmethode<\/th><th>MFA<\/th><\/tr><\/thead><tbody><tr><td>PORTA Endnutzer<\/td><td>Microsoft Azure AD OAuth / Google OAuth / lokales Login<\/td><td>[ZU PRÜFEN: MFA erzwungen?]<\/td><\/tr><tr><td>Admin-UI (SysAdmin)<\/td><td>Lokales Login / Session<\/td><td><strong>MFA erzwungen<\/strong> (umgesetzt Juni 2026)<\/td><\/tr><tr><td>SSH-Server<\/td><td>SSH-Key<\/td><td>[ZU PRÜFEN: Key + Passphrase? Bastion?]<\/td><\/tr><tr><td>Drittdienste (OpenAI etc.)<\/td><td>API-Keys in <code>.env<\/code><\/td><td>n/a<\/td><\/tr><\/tbody><\/table>\n<p><strong>Vorgabe:<\/strong> Für privilegierte Zugänge (SysAdmin, SSH, DB) ist Zwei-Faktor-Authentifizierung zu konfigurieren. SMS-/mobile TAN ist möglichst zu vermeiden; bevorzugt App- oder Hardware-Token.<\/p>\n<p><strong>Stand Juni 2026:<\/strong> MFA auf Admin-UI (SysAdmin) und Server-Zugängen umgesetzt. Endnutzer-MFA über IdP (Azure AD/Google) und SSH-Details siehe unten — offene Punkte bleiben markiert.<\/p>\n<h2>5. Berechtigungsvergabe, -änderung und -entzug (#67)<\/h2>\n<table><thead><tr><th>Ereignis<\/th><th>Massnahme<\/th><th>Frist<\/th><\/tr><\/thead><tbody><tr><td>Onboarding<\/td><td>Zugänge gemäss Rolle einrichten, Minimalprinzip<\/td><td>Bei Eintritt<\/td><\/tr><tr><td>Rollenwechsel<\/td><td>Berechtigungen anpassen, nicht mehr benötigte entziehen<\/td><td>Innert 5 Werktagen<\/td><\/tr><tr><td>Offboarding<\/td><td><strong>Alle<\/strong> Zugänge sofort sperren: SSH-Key entfernen, Admin-UI deaktivieren, API-Keys rotieren, DB-Zugang entziehen<\/td><td>Am letzten Arbeitstag<\/td><\/tr><tr><td>Rezertifizierung<\/td><td>Vollständige Überprüfung aller Zugänge und Berechtigungen<\/td><td>Mindestens halbjährlich<\/td><\/tr><\/tbody><\/table>\n<h2>6. Privilegierte Zugriffe (PAM) (#36, #37)<\/h2>\n<p>Privilegierter Zugriff (SSH, DB-Admin, SysAdmin) wird nur sorgfältig ausgewählten, geschulten Personen gewährt. Aufgrund der Teamgrösse ist die Anzahl privilegierter Personen sehr klein, was das Risiko begrenzt. Kompensierend zu fehlender vollständiger Funktionstrennung gilt:<\/p>\n<ul><li>Protokollierung privilegierter Aktionen (Export/Import, Deployments, DB-Zugriffe).<\/li><li>Vier-Augen-Prinzip bei produktiven Releases (siehe <code>feature_release_bugfix.md<\/code> / <code>08_Change_Management.md<\/code>).<\/li><li>Regelmässige Stichprobenprüfung der Protokolle.<\/li><\/ul>\n<h2>7. Zugangsbeschränkung auf IP/Domain (#69)<\/h2>\n<p>[ZU PRÜFEN: Ist der Admin-/Server-Zugang auf bestimmte IP-Adressen beschränkt? Falls ja, dokumentieren. Falls nein, als geplante Massnahme aufnehmen.]<\/p>\n<h2>8. Stand der Umsetzung / Lücken<\/h2>\n<table><thead><tr><th>Thema<\/th><th>Status<\/th><th>Massnahme<\/th><\/tr><\/thead><tbody><tr><td>Personalisierte SSH-Accounts<\/td><td>Offen<\/td><td>Umstellung oder vollständige Sitzungsprotokollierung<\/td><\/tr><tr><td>MFA auf privilegierten Zugängen<\/td><td><strong>Umgesetzt<\/strong> (Juni 2026)<\/td><td>Halbjährliche Rezertifizierung<\/td><\/tr><tr><td>Halbjährliche Rezertifizierung<\/td><td>Neu<\/td><td>Erstdurchführung terminieren<\/td><\/tr><\/tbody><\/table>", "text": "# zugriffsmanagement (iam / pam) **dokumenttyp:** richtlinie & prozess **geltungsbereich:** alle zugänge zu porta-systemen (server, datenbank, admin-ui, drittdienste) **version:** 1.0 **status:** entwurf zur internen freigabe **owner:** betrieb / devops **letzte aktualisierung:** 02.06.2026 **deckt ab (cacc):** 25, 36, 37, 66, 67, 68, 69 --- ## 1. grundprinzipien poweron gewährt zugriffe ausschliesslich nach **need-to-know** und **least privilege**. kein mitarbeiter erhält mehr rechte, als für seine aufgabe erforderlich sind. ## 2. zugriffsebenen der plattform | ebene | beschreibung | berechtigte | |---|---|---| | **sysadmin (admin-ui)** | höchste stufe in der porta-admin-ui: db-export/import, mandatsverwaltung, feature-steuerung | patrick motsch | | **server-zugang (ssh)** | `ubuntu@api.poweron.swiss` / `api-int` — vollzugriff auf anwendung und konfiguration | patrick motsch | | **datenbank** | db-user `poweron_dev` auf `db.poweron.swiss:5432` | patrick motsch | | **mandats-administrator (kundenseitig)** | verwaltet nutzer innerhalb des eigenen tenants | kunde selbst | | **endnutzer** | nutzung der gebuchten features | kunde | > **offener punkt (kompensierende massnahme nötig):** der ssh-zugang erfolgt aktuell über den geteilten benutzer `ubuntu`. für nachvollziehbarkeit auf personenebene ist entweder (a) umstellung auf personalisierte ssh-accounts oder (b) lückenlose protokollierung jeder ssh-sitzung mit eindeutiger personenzuordnung erforderlich. → siehe `11_logging_und_monitoring.md`. **[zu prüfen / umzusetzen]** ## 3. zugang zu kundendaten im klartext (#25, #66) mitarbeitende von poweron greifen auf inhaltsdaten eines kunden im klartext **nur** zu, wenn: 1. der kunde dies für einen konkreten fall (z. b. support-ticket) freigegeben hat, **oder** 2. eine rechtskräftige behördliche anordnung dies zwingend verlangt, **oder** 3. ein schwerer technischer störfall den zugriff temporär erfordert — mit unverzüglicher nachträglicher information des kunden. jeder solche zugriff wird protokolliert (datenbank-export/import wird serverseitig geloggt, siehe `datenbank-handling.md` abschnitt 6). ## 4. authentifizierung (#68) | system | authentifizierungsmethode | mfa | |---|---|---| | porta endnutzer | microsoft azure ad oauth / google oauth / lokales login | [zu prüfen: mfa erzwungen?] | | admin-ui (sysadmin) | lokales login / session | **mfa erzwungen** (umgesetzt juni 2026) | | ssh-server | ssh-key | [zu prüfen: key + passphrase? bastion?] | | drittdienste (openai etc.) | api-keys in `.env` | n/a | **vorgabe:** für privilegierte zugänge (sysadmin, ssh, db) ist zwei-faktor-authentifizierung zu konfigurieren. sms-/mobile tan ist möglichst zu vermeiden; bevorzugt app- oder hardware-token. **stand juni 2026:** mfa auf admin-ui (sysadmin) und server-zugängen umgesetzt. endnutzer-mfa über idp (azure ad/google) und ssh-details siehe unten — offene punkte bleiben markiert. ## 5. berechtigungsvergabe, -änderung und -entzug (#67) | ereignis | massnahme | frist | |---|---|---| | onboarding | zugänge gemäss rolle einrichten, minimalprinzip | bei eintritt | | rollenwechsel | berechtigungen anpassen, nicht mehr benötigte entziehen | innert 5 werktagen | | offboarding | **alle** zugänge sofort sperren: ssh-key entfernen, admin-ui deaktivieren, api-keys rotieren, db-zugang entziehen | am letzten arbeitstag | | rezertifizierung | vollständige überprüfung aller zugänge und berechtigungen | mindestens halbjährlich | ## 6. privilegierte zugriffe (pam) (#36, #37) privilegierter zugriff (ssh, db-admin, sysadmin) wird nur sorgfältig ausgewählten, geschulten personen gewährt. aufgrund der teamgrösse ist die anzahl privilegierter personen sehr klein, was das risiko begrenzt. kompensierend zu fehlender vollständiger funktionstrennung gilt: - protokollierung privilegierter aktionen (export/import, deployments, db-zugriffe). - vier-augen-prinzip bei produktiven releases (siehe `feature_release_bugfix.md` / `08_change_management.md`). - regelmässige stichprobenprüfung der protokolle. ## 7. zugangsbeschränkung auf ip/domain (#69) [zu prüfen: ist der admin-/server-zugang auf bestimmte ip-adressen beschränkt? falls ja, dokumentieren. falls nein, als geplante massnahme aufnehmen.] ## 8. stand der umsetzung / lücken | thema | status | massnahme | |---|---|---| | personalisierte ssh-accounts | offen | umstellung oder vollständige sitzungsprotokollierung | | mfa auf privilegierten zugängen | **umgesetzt** (juni 2026) | halbjährliche rezertifizierung | | halbjährliche rezertifizierung | neu | erstdurchführung terminieren | ", "nextReview": "", "overdueReview": false, "zuPruefen": ["2. Zugriffsebenen der Plattform", "4. Authentifizierung (#68)", "4. Authentifizierung (#68)", "7. Zugangsbeschränkung auf IP/Domain (#69)"]}, {"id": "05_betrieb/03_Mitarbeitersicherheit_und_Screening.md", "path": "05_betrieb/03_Mitarbeitersicherheit_und_Screening.md", "chapter": "05_betrieb", "title": "Mitarbeitersicherheit und Screening", "filename": "03_Mitarbeitersicherheit_und_Screening.md", "meta": {}, "html": "<h1>Mitarbeitersicherheit und Screening<\/h1>\n<p><strong>Dokumenttyp:<\/strong> Richtlinie &amp; Prozess <strong>Geltungsbereich:<\/strong> Alle Mitarbeitenden und Hilfspersonen mit Zugang zu Kundendaten <strong>Version:<\/strong> 1.0 <strong>Status:<\/strong> Entwurf zur internen Freigabe <strong>Owner:<\/strong> Geschäftsführung <strong>Letzte Aktualisierung:<\/strong> 02.06.2026 <strong>Deckt ab (CACC):<\/strong> 23, 35, 37<\/p>\n<hr>\n<h2>1. Vertraulichkeitsverpflichtung (#23)<\/h2>\n<p>Alle Mitarbeitenden und Hilfspersonen werden bei Eintritt schriftlich zur Geheimhaltung sämtlicher Inhaltsdaten der Kunden verpflichtet — insbesondere zur Wahrung des Bankkunden- und sonstigen Berufsgeheimnisses. Die Verpflichtung gilt <strong>zeitlich unbefristet<\/strong> und besteht auch nach Beendigung des Arbeitsverhältnisses fort.<\/p>\n<p><strong>Nachweis:<\/strong> Unterschriebene Geheimhaltungsvereinbarung (NDA) im Personaldossier. <strong>[ZU PRÜFEN: liegen NDAs für alle aktuellen Mitarbeitenden vor?]<\/strong><\/p>\n<h2>2. Sorgfältige Auswahl und Hintergrundprüfung (#35)<\/h2>\n<p>Vor Gewährung von Zugang zu Berufsgeheimnisdaten im Klartext werden Mitarbeitende sorgfältig ausgewählt und überprüft.<\/p>\n<table><thead><tr><th>Prüfschritt<\/th><th>Durchführung<\/th><\/tr><\/thead><tbody><tr><td>Identitätsprüfung<\/td><td>Bei Einstellung<\/td><\/tr><tr><td>Strafregisterauszug<\/td><td>[ZU PRÜFEN: wird verlangt?]<\/td><\/tr><tr><td>Referenzprüfung früherer Arbeitgeber<\/td><td>[ZU PRÜFEN]<\/td><\/tr><tr><td>Prüfung auf einschlägige Sanktionslisten<\/td><td>[ZU PRÜFEN]<\/td><\/tr><\/tbody><\/table>\n<blockquote><strong>Hinweis:<\/strong> Punkt #35 verlangt eine Überprüfung „entsprechend den Standards des Instituts für eigene Mitarbeiter\". Für FINMA-Kunden ist mindestens ein aktueller Strafregisterauszug üblich. Falls dies aktuell nicht erfolgt, als Massnahme aufnehmen.<\/blockquote>\n<h2>3. Schulung und Awareness<\/h2>\n<table><thead><tr><th>Massnahme<\/th><th>Häufigkeit<\/th><\/tr><\/thead><tbody><tr><td>Sicherheits- und Datenschutz-Onboarding<\/td><td>Bei Eintritt<\/td><\/tr><tr><td>Auffrischungsschulung (inkl. Phishing-/Social-Engineering-Awareness)<\/td><td>Jährlich<\/td><\/tr><tr><td>Schulung zu dieser Richtlinie und zur IS-Richtlinie<\/td><td>Bei Eintritt + bei Änderungen<\/td><\/tr><\/tbody><\/table>\n<p><strong>[ZU PRÜFEN: Findet eine strukturierte Schulung statt? Falls informell, formalisieren und dokumentieren.]<\/strong><\/p>\n<h2>4. Überwachung privilegierter Mitarbeitender (#37)<\/h2>\n<p>Mitarbeitende mit privilegiertem Zugriff auf kritische Klartextdaten werden:<\/p>\n<ul><li>sorgfältig ausgewählt und geschult,<\/li><li>durch Audit-Trails überwacht, die regelmässig (mindestens stichprobenweise) ausgewertet werden (siehe <code>11_Logging_und_Monitoring.md<\/code>),<\/li><li>bei Offboarding sofort entzogen (siehe <code>02_Zugriffsmanagement_IAM_PAM.md<\/code> Abschnitt 5).<\/li><\/ul>\n<h2>5. Stand der Umsetzung / Lücken<\/h2>\n<table><thead><tr><th>Thema<\/th><th>Status<\/th><th>Massnahme<\/th><\/tr><\/thead><tbody><tr><td>NDAs für alle Mitarbeitenden<\/td><td>[ZU PRÜFEN]<\/td><td>Vollständigkeit sicherstellen<\/td><\/tr><tr><td>Strafregisterauszug bei Einstellung<\/td><td>[ZU PRÜFEN]<\/td><td>Einführen falls nicht vorhanden<\/td><\/tr><tr><td>Dokumentierte jährliche Schulung<\/td><td>[ZU PRÜFEN]<\/td><td>Formalisieren<\/td><\/tr><\/tbody><\/table>", "text": "# mitarbeitersicherheit und screening **dokumenttyp:** richtlinie & prozess **geltungsbereich:** alle mitarbeitenden und hilfspersonen mit zugang zu kundendaten **version:** 1.0 **status:** entwurf zur internen freigabe **owner:** geschäftsführung **letzte aktualisierung:** 02.06.2026 **deckt ab (cacc):** 23, 35, 37 --- ## 1. vertraulichkeitsverpflichtung (#23) alle mitarbeitenden und hilfspersonen werden bei eintritt schriftlich zur geheimhaltung sämtlicher inhaltsdaten der kunden verpflichtet — insbesondere zur wahrung des bankkunden- und sonstigen berufsgeheimnisses. die verpflichtung gilt **zeitlich unbefristet** und besteht auch nach beendigung des arbeitsverhältnisses fort. **nachweis:** unterschriebene geheimhaltungsvereinbarung (nda) im personaldossier. **[zu prüfen: liegen ndas für alle aktuellen mitarbeitenden vor?]** ## 2. sorgfältige auswahl und hintergrundprüfung (#35) vor gewährung von zugang zu berufsgeheimnisdaten im klartext werden mitarbeitende sorgfältig ausgewählt und überprüft. | prüfschritt | durchführung | |---|---| | identitätsprüfung | bei einstellung | | strafregisterauszug | [zu prüfen: wird verlangt?] | | referenzprüfung früherer arbeitgeber | [zu prüfen] | | prüfung auf einschlägige sanktionslisten | [zu prüfen] | > **hinweis:** punkt #35 verlangt eine überprüfung „entsprechend den standards des instituts für eigene mitarbeiter\". für finma-kunden ist mindestens ein aktueller strafregisterauszug üblich. falls dies aktuell nicht erfolgt, als massnahme aufnehmen. ## 3. schulung und awareness | massnahme | häufigkeit | |---|---| | sicherheits- und datenschutz-onboarding | bei eintritt | | auffrischungsschulung (inkl. phishing-/social-engineering-awareness) | jährlich | | schulung zu dieser richtlinie und zur is-richtlinie | bei eintritt + bei änderungen | **[zu prüfen: findet eine strukturierte schulung statt? falls informell, formalisieren und dokumentieren.]** ## 4. überwachung privilegierter mitarbeitender (#37) mitarbeitende mit privilegiertem zugriff auf kritische klartextdaten werden: - sorgfältig ausgewählt und geschult, - durch audit-trails überwacht, die regelmässig (mindestens stichprobenweise) ausgewertet werden (siehe `11_logging_und_monitoring.md`), - bei offboarding sofort entzogen (siehe `02_zugriffsmanagement_iam_pam.md` abschnitt 5). ## 5. stand der umsetzung / lücken | thema | status | massnahme | |---|---|---| | ndas für alle mitarbeitenden | [zu prüfen] | vollständigkeit sicherstellen | | strafregisterauszug bei einstellung | [zu prüfen] | einführen falls nicht vorhanden | | dokumentierte jährliche schulung | [zu prüfen] | formalisieren | ", "nextReview": "", "overdueReview": false, "zuPruefen": ["1. Vertraulichkeitsverpflichtung (#23)", "2. Sorgfältige Auswahl und Hintergrundprüfung (#35)", "2. Sorgfältige Auswahl und Hintergrundprüfung (#35)", "2. Sorgfältige Auswahl und Hintergrundprüfung (#35)", "3. Schulung und Awareness", "5. Stand der Umsetzung / Lücken", "5. Stand der Umsetzung / Lücken", "5. Stand der Umsetzung / Lücken"]}, {"id": "05_betrieb/04_Verschluesselung_und_Schluesselmanagement.md", "path": "05_betrieb/04_Verschluesselung_und_Schluesselmanagement.md", "chapter": "05_betrieb", "title": "Verschlüsselung und Schlüsselmanagement", "filename": "04_Verschluesselung_und_Schluesselmanagement.md", "meta": {}, "html": "<h1>Verschlüsselung und Schlüsselmanagement<\/h1>\n<p><strong>Dokumenttyp:<\/strong> Konzept <strong>Geltungsbereich:<\/strong> Speicherung und Übertragung aller Kundendaten der PORTA-Plattform <strong>Version:<\/strong> 1.0 <strong>Status:<\/strong> Entwurf zur internen Freigabe <strong>Owner:<\/strong> Betrieb / DevOps <strong>Letzte Aktualisierung:<\/strong> 02.06.2026 <strong>Deckt ab (CACC):<\/strong> 43, 44, 45, 46, 70, 71, 72<\/p>\n<hr>\n<h2>1. Verschlüsselung bei der Übertragung (in transit) (#70)<\/h2>\n<table><thead><tr><th>Verbindung<\/th><th>Schutz<\/th><\/tr><\/thead><tbody><tr><td>Endnutzer → <code>api.poweron.swiss<\/code><\/td><td>HTTPS / TLS [ZU PRÜFEN: TLS 1.2 / 1.3? Ältere Versionen deaktiviert?]<\/td><\/tr><tr><td>Anwendung → Datenbank <code>db.poweron.swiss<\/code><\/td><td>[ZU PRÜFEN: TLS/SSL auf PostgreSQL-Verbindung aktiv?]<\/td><\/tr><tr><td>Anwendung → LLM-Provider (OpenAI etc.)<\/td><td>HTTPS / TLS (durch Provider-APIs)<\/td><\/tr><tr><td>System-E-Mail (Azure Communication Services)<\/td><td>TLS<\/td><\/tr><\/tbody><\/table>\n<p><strong>Vorgabe:<\/strong> Alle externen Verbindungen über TLS 1.2 oder höher; ältere Protokolle deaktiviert.<\/p>\n<h2>2. Verschlüsselung im Ruhezustand (at rest) (#70)<\/h2>\n<table><thead><tr><th>Datenort<\/th><th>Verschlüsselung<\/th><\/tr><\/thead><tbody><tr><td>PostgreSQL-Datenbank (Infomaniak Managed DB)<\/td><td>[ZU PRÜFEN: At-Rest-Verschlüsselung durch Infomaniak aktiviert? Standard bei Managed Databases bestätigen]<\/td><\/tr><tr><td>VM-Speicher (Infomaniak)<\/td><td>[ZU PRÜFEN: Volume-Verschlüsselung]<\/td><\/tr><tr><td>Backup-/Export-Dateien (JSON)<\/td><td><strong>Aktuell unverschlüsselt<\/strong> — siehe Hinweis unten<\/td><\/tr><\/tbody><\/table>\n<blockquote><strong>Wichtiger offener Punkt:<\/strong> Die JSON-Exporte aus <code>datenbank-handling.md<\/code> enthalten <em>alle<\/em> Kundendaten im Klartext und sind aktuell nicht verschlüsselt. <strong>Massnahme:<\/strong> Export-Dateien verschlüsselt ablegen (z. B. AES-256 / GPG) und Aufbewahrungsort absichern. → siehe <code>13_Datenaufbewahrung_Loeschung_LegalHold.md<\/code>.<\/blockquote>\n<h2>3. Verarbeitung bei LLM-Providern (in use)<\/h2>\n<p>Zur KI-Verarbeitung werden Inhaltsdaten an externe LLM-Provider übermittelt (Primär: OpenAI, USA). Während der Verarbeitung liegen die Daten beim Provider. Schutzmechanismen:<\/p>\n<ul><li>Übertragung ausschliesslich über TLS.<\/li><li>Vertragliche Absicherung über AVV/DPA und (für US-Provider) EU-Standardvertragsklauseln. <strong>[ZU PRÜFEN: Verträge abgeschlossen — siehe <code>17_Subunternehmer_Management.md<\/code>]<\/strong><\/li><li>Zero-Data-Retention-Vereinbarung (Daten werden nicht für Provider-Training genutzt). <strong>[ZU PRÜFEN: Enterprise-Tier / Opt-out aktiviert?]<\/strong><\/li><\/ul>\n<h2>4. Schlüsselmanagement-Modelle (#43–46, #71)<\/h2>\n<p>Der Katalog beschreibt vier Modelle. Aktueller Stand und Angebot von PowerOn:<\/p>\n<table><thead><tr><th>Modell<\/th><th>Beschreibung<\/th><th>PowerOn-Angebot<\/th><\/tr><\/thead><tbody><tr><td><strong>A — Kundenkontrolliert<\/strong><\/td><td>Schlüssel nur für vom Kunden zugelassene Nutzer/Prozesse<\/td><td>[ZU PRÜFEN: technisch möglich?]<\/td><\/tr><tr><td><strong>B — Anbieter verwaltet (Standard)<\/strong><\/td><td>Schlüssel im Speicher von PowerOn/Infomaniak, PowerOn verwaltet<\/td><td>Aktueller Stand: Infomaniak Managed Keys<\/td><\/tr><tr><td><strong>C — Anbieter-Speicher, Kunde verwaltet remote<\/strong><\/td><td>Schlüssel bei PowerOn, Verwaltung durch Kunde<\/td><td>[ZU PRÜFEN]<\/td><\/tr><tr><td><strong>D — Kunden-Schlüsselspeicher (BYOK)<\/strong><\/td><td>Schlüssel in kundenseitigem Key Store<\/td><td>[ZU PRÜFEN: BYOK angeboten?]<\/td><\/tr><\/tbody><\/table>\n<p><strong>Realistische Aussage für das Assessment:<\/strong> Aktuell wird Modell B (anbieterverwaltet über Infomaniak) genutzt. BYOK/kundenkontrollierte Schlüssel sind [ZU PRÜFEN: nicht / in Planung].<\/p>\n<h2>5. Schlüssellebenszyklus (#72)<\/h2>\n<p>Anforderungen für sichere Erzeugung, Speicherung, Archivierung, Abfrage, Verteilung, Sperrung und Löschung von Schlüsseln:<\/p>\n<table><thead><tr><th>Phase<\/th><th>Vorgabe<\/th><th>Status<\/th><\/tr><\/thead><tbody><tr><td>Erzeugung<\/td><td>Durch Infomaniak Managed DB / etablierte Bibliotheken<\/td><td>[ZU PRÜFEN]<\/td><\/tr><tr><td>Speicherung<\/td><td>Getrennt von verschlüsselten Daten<\/td><td>[ZU PRÜFEN]<\/td><\/tr><tr><td>API-Keys (OpenAI etc.)<\/td><td>In <code>.env<\/code> auf dem Server, nicht im Git<\/td><td>Umgesetzt (Konfiguration getrennt)<\/td><\/tr><tr><td>Rotation<\/td><td>API-Keys bei Offboarding/Verdacht rotieren<\/td><td>[ZU PRÜFEN: Rotationsintervall definieren]<\/td><\/tr><tr><td>Sperrung/Löschung<\/td><td>Bei Vertragsende Schlüssel vernichten (Krypto-Löschung)<\/td><td>siehe Dok 13<\/td><\/tr><\/tbody><\/table>\n<h2>6. Stand der Umsetzung / Lücken<\/h2>\n<table><thead><tr><th>Thema<\/th><th>Status<\/th><th>Massnahme<\/th><\/tr><\/thead><tbody><tr><td>At-Rest-Verschlüsselung DB bestätigen<\/td><td>[ZU PRÜFEN]<\/td><td>Bei Infomaniak verifizieren, dokumentieren<\/td><\/tr><tr><td>Export-Dateien verschlüsseln<\/td><td>Offen<\/td><td>AES-256/GPG einführen<\/td><\/tr><tr><td>BYOK-Angebot<\/td><td>[ZU PRÜFEN]<\/td><td>Entscheidung für regulierte Kunden<\/td><\/tr><tr><td>Schlüssel-Rotationsintervall<\/td><td>Offen<\/td><td>Festlegen<\/td><\/tr><\/tbody><\/table>", "text": "# verschlüsselung und schlüsselmanagement **dokumenttyp:** konzept **geltungsbereich:** speicherung und übertragung aller kundendaten der porta-plattform **version:** 1.0 **status:** entwurf zur internen freigabe **owner:** betrieb / devops **letzte aktualisierung:** 02.06.2026 **deckt ab (cacc):** 43, 44, 45, 46, 70, 71, 72 --- ## 1. verschlüsselung bei der übertragung (in transit) (#70) | verbindung | schutz | |---|---| | endnutzer → `api.poweron.swiss` | https / tls [zu prüfen: tls 1.2 / 1.3? ältere versionen deaktiviert?] | | anwendung → datenbank `db.poweron.swiss` | [zu prüfen: tls/ssl auf postgresql-verbindung aktiv?] | | anwendung → llm-provider (openai etc.) | https / tls (durch provider-apis) | | system-e-mail (azure communication services) | tls | **vorgabe:** alle externen verbindungen über tls 1.2 oder höher; ältere protokolle deaktiviert. ## 2. verschlüsselung im ruhezustand (at rest) (#70) | datenort | verschlüsselung | |---|---| | postgresql-datenbank (infomaniak managed db) | [zu prüfen: at-rest-verschlüsselung durch infomaniak aktiviert? standard bei managed databases bestätigen] | | vm-speicher (infomaniak) | [zu prüfen: volume-verschlüsselung] | | backup-/export-dateien (json) | **aktuell unverschlüsselt** — siehe hinweis unten | > **wichtiger offener punkt:** die json-exporte aus `datenbank-handling.md` enthalten *alle* kundendaten im klartext und sind aktuell nicht verschlüsselt. **massnahme:** export-dateien verschlüsselt ablegen (z. b. aes-256 / gpg) und aufbewahrungsort absichern. → siehe `13_datenaufbewahrung_loeschung_legalhold.md`. ## 3. verarbeitung bei llm-providern (in use) zur ki-verarbeitung werden inhaltsdaten an externe llm-provider übermittelt (primär: openai, usa). während der verarbeitung liegen die daten beim provider. schutzmechanismen: - übertragung ausschliesslich über tls. - vertragliche absicherung über avv/dpa und (für us-provider) eu-standardvertragsklauseln. **[zu prüfen: verträge abgeschlossen — siehe `17_subunternehmer_management.md`]** - zero-data-retention-vereinbarung (daten werden nicht für provider-training genutzt). **[zu prüfen: enterprise-tier / opt-out aktiviert?]** ## 4. schlüsselmanagement-modelle (#43–46, #71) der katalog beschreibt vier modelle. aktueller stand und angebot von poweron: | modell | beschreibung | poweron-angebot | |---|---|---| | **a — kundenkontrolliert** | schlüssel nur für vom kunden zugelassene nutzer/prozesse | [zu prüfen: technisch möglich?] | | **b — anbieter verwaltet (standard)** | schlüssel im speicher von poweron/infomaniak, poweron verwaltet | aktueller stand: infomaniak managed keys | | **c — anbieter-speicher, kunde verwaltet remote** | schlüssel bei poweron, verwaltung durch kunde | [zu prüfen] | | **d — kunden-schlüsselspeicher (byok)** | schlüssel in kundenseitigem key store | [zu prüfen: byok angeboten?] | **realistische aussage für das assessment:** aktuell wird modell b (anbieterverwaltet über infomaniak) genutzt. byok/kundenkontrollierte schlüssel sind [zu prüfen: nicht / in planung]. ## 5. schlüssellebenszyklus (#72) anforderungen für sichere erzeugung, speicherung, archivierung, abfrage, verteilung, sperrung und löschung von schlüsseln: | phase | vorgabe | status | |---|---|---| | erzeugung | durch infomaniak managed db / etablierte bibliotheken | [zu prüfen] | | speicherung | getrennt von verschlüsselten daten | [zu prüfen] | | api-keys (openai etc.) | in `.env` auf dem server, nicht im git | umgesetzt (konfiguration getrennt) | | rotation | api-keys bei offboarding/verdacht rotieren | [zu prüfen: rotationsintervall definieren] | | sperrung/löschung | bei vertragsende schlüssel vernichten (krypto-löschung) | siehe dok 13 | ## 6. stand der umsetzung / lücken | thema | status | massnahme | |---|---|---| | at-rest-verschlüsselung db bestätigen | [zu prüfen] | bei infomaniak verifizieren, dokumentieren | | export-dateien verschlüsseln | offen | aes-256/gpg einführen | | byok-angebot | [zu prüfen] | entscheidung für regulierte kunden | | schlüssel-rotationsintervall | offen | festlegen | ", "nextReview": "", "overdueReview": false, "zuPruefen": ["1. Verschlüsselung bei der Übertragung (in transit) (#70)", "1. Verschlüsselung bei der Übertragung (in transit) (#70)", "2. Verschlüsselung im Ruhezustand (at rest) (#70)", "2. Verschlüsselung im Ruhezustand (at rest) (#70)", "3. Verarbeitung bei LLM-Providern (in use)", "3. Verarbeitung bei LLM-Providern (in use)", "4. Schlüsselmanagement-Modelle (#43–46, #71)", "4. Schlüsselmanagement-Modelle (#43–46, #71)", "4. Schlüsselmanagement-Modelle (#43–46, #71)", "4. Schlüsselmanagement-Modelle (#43–46, #71)", "5. Schlüssellebenszyklus (#72)", "5. Schlüssellebenszyklus (#72)", "5. Schlüssellebenszyklus (#72)", "6. Stand der Umsetzung / Lücken", "6. Stand der Umsetzung / Lücken"]}, {"id": "05_betrieb/05_Backup_und_Wiederherstellung.md", "path": "05_betrieb/05_Backup_und_Wiederherstellung.md", "chapter": "05_betrieb", "title": "Backup und Wiederherstellung", "filename": "05_Backup_und_Wiederherstellung.md", "meta": {}, "html": "<h1>Backup und Wiederherstellung<\/h1>\n<p><strong>Dokumenttyp:<\/strong> Konzept &amp; Prozess <strong>Geltungsbereich:<\/strong> Alle Kundendaten auf <code>db.poweron.swiss<\/code> <strong>Version:<\/strong> 1.0 <strong>Status:<\/strong> Entwurf zur internen Freigabe <strong>Owner:<\/strong> Betrieb / DevOps <strong>Letzte Aktualisierung:<\/strong> 02.06.2026 <strong>Deckt ab (CACC):<\/strong> 75, 87 <strong>Verweist auf:<\/strong> <code>datenbank-handling.md<\/code>, <code>bcm_runbook.md<\/code><\/p>\n<hr>\n<h2>1. Backup-Strategie (mehrschichtig)<\/h2>\n<p>PowerOn sichert Daten auf zwei Ebenen (vgl. <code>datenbank-handling.md<\/code> Abschnitt 4):<\/p>\n<table><thead><tr><th>Ebene<\/th><th>Mechanismus<\/th><th>Verantwortung<\/th><\/tr><\/thead><tbody><tr><td><strong>Infrastruktur<\/strong><\/td><td>Snapshots der Infomaniak Managed PostgreSQL<\/td><td>Infomaniak / Betrieb<\/td><\/tr><tr><td><strong>Anwendung<\/strong><\/td><td>Vollständiger JSON-Export aller 13 Datenbanken via Admin-UI oder Script<\/td><td>Betrieb (SysAdmin)<\/td><\/tr><\/tbody><\/table>\n<p>Token- und AuthEvent-Tabellen sowie die Testdatenbank werden vom Export ausgeschlossen.<\/p>\n<h2>2. Anforderung #75 — die drei Pflichtelemente<\/h2>\n<p>Punkt #75 verlangt explizit drei Dinge. Stand und Massnahmen:<\/p>\n<h3>2.1 Angemessener Schutz der gesicherten Daten<\/h3>\n<ul><li>Backup-Dateien enthalten alle Kundendaten und sind als vertraulich klassifiziert.<\/li><li><strong>Offen:<\/strong> Export-Dateien aktuell unverschlüsselt → Verschlüsselung einführen (siehe Dok 04).<\/li><li>Ablage nur auf gesicherten Speichern, nicht auf persönlichen Geräten/Cloud (vgl. <code>datenbank-handling.md<\/code> Abschnitt 6).<\/li><\/ul>\n<h3>2.2 Überwachung der Datensicherung<\/h3>\n<ul><li><strong>Offen / [ZU PRÜFEN]:<\/strong> Werden Infomaniak-Snapshots automatisch überwacht (Erfolg/Fehler-Alerting)?<\/li><li><strong>Massnahme:<\/strong> Automatisiertes Alerting bei fehlgeschlagenem Backup einrichten; Backup-Status mindestens wöchentlich kontrollieren.<\/li><\/ul>\n<h3>2.3 Test der Wiederherstellungsverfahren<\/h3>\n<ul><li>Das technische Restore-Verfahren ist in <code>bcm_runbook.md<\/code> Abschnitt 2 vollständig dokumentiert (pg_dump/pg_restore + Migrations-Tool).<\/li><li><strong>Offen:<\/strong> Es fehlt ein dokumentierter, regelmässiger Restore-Test.<\/li><li><strong>Massnahme:<\/strong> Mindestens <strong>vierteljährlich<\/strong> einen Restore-Test auf der INT-Umgebung durchführen und protokollieren (Datum, getestete DB, Dauer, Ergebnis, Tester).<\/li><\/ul>\n<h2>3. Backup-Frequenz und Aufbewahrung<\/h2>\n<table><thead><tr><th>Anlass<\/th><th>Aktion<\/th><th>Aufbewahrung<\/th><\/tr><\/thead><tbody><tr><td>Vor jedem Deployment<\/td><td>Export via Admin-UI<\/td><td>bis zum nächsten erfolgreichen Deployment<\/td><\/tr><tr><td>Vor DB-Migrationen<\/td><td>Export + beschriftet archivieren<\/td><td>mind. 90 Tage<\/td><\/tr><tr><td>Wöchentlich<\/td><td>Archiv-Export<\/td><td>[ZU PRÜFEN: Aufbewahrungsdauer festlegen, z. B. 90 Tage]<\/td><\/tr><tr><td>Infrastruktur-Snapshot<\/td><td>automatisch (Infomaniak)<\/td><td>[ZU PRÜFEN: Intervall &amp; Retention bei Infomaniak]<\/td><\/tr><\/tbody><\/table>\n<h2>4. Wiederherstellungsziele (RTO/RPO)<\/h2>\n<table><thead><tr><th>Parameter<\/th><th>Zielwert<\/th><th>Bemerkung<\/th><\/tr><\/thead><tbody><tr><td>RTO (Recovery Time Objective)<\/td><td>[ZU PRÜFEN, Vorschlag: ≤ 4 h]<\/td><td>Restore dauert lt. Runbook „wenige Minuten bis 1 Stunde\"<\/td><\/tr><tr><td>RPO (Recovery Point Objective)<\/td><td>[ZU PRÜFEN, Vorschlag: ≤ 24 h]<\/td><td>Abhängig von Snapshot-/Export-Frequenz<\/td><\/tr><\/tbody><\/table>\n<blockquote>Hinweis: RTO/RPO müssen zu den im SLA gegenüber Kunden zugesagten Werten passen (AGB Anhang B). Aktuell im AGB-Entwurf RTO ≤ 4 h / RPO ≤ 1 h — das erfordert häufigere Sicherungen als die aktuelle wöchentliche Praxis. <strong>Abgleich nötig.<\/strong><\/blockquote>\n<h2>5. Restore-Test-Protokoll (Vorlage)<\/h2>\n<table><thead><tr><th>Datum<\/th><th>Getestete DB<\/th><th>Quelle (Backup)<\/th><th>Dauer<\/th><th>Ergebnis<\/th><th>Tester<\/th><\/tr><\/thead><tbody><tr><td><\/td><td><\/td><td><\/td><td><\/td><td><\/td><td><\/td><\/tr><\/tbody><\/table>\n<h2>6. Stand der Umsetzung / Lücken<\/h2>\n<table><thead><tr><th>Thema<\/th><th>Status<\/th><th>Massnahme<\/th><\/tr><\/thead><tbody><tr><td>Backup-Verschlüsselung<\/td><td>Offen<\/td><td>siehe Dok 04<\/td><\/tr><tr><td>Backup-Monitoring/Alerting<\/td><td>[ZU PRÜFEN]<\/td><td>Einrichten<\/td><\/tr><tr><td>Regelmässiger Restore-Test<\/td><td>Offen<\/td><td>Vierteljährlich + Protokoll<\/td><\/tr><tr><td>RTO/RPO mit SLA abgleichen<\/td><td>Offen<\/td><td>Werte festlegen &amp; Frequenz anpassen<\/td><\/tr><\/tbody><\/table>", "text": "# backup und wiederherstellung **dokumenttyp:** konzept & prozess **geltungsbereich:** alle kundendaten auf `db.poweron.swiss` **version:** 1.0 **status:** entwurf zur internen freigabe **owner:** betrieb / devops **letzte aktualisierung:** 02.06.2026 **deckt ab (cacc):** 75, 87 **verweist auf:** `datenbank-handling.md`, `bcm_runbook.md` --- ## 1. backup-strategie (mehrschichtig) poweron sichert daten auf zwei ebenen (vgl. `datenbank-handling.md` abschnitt 4): | ebene | mechanismus | verantwortung | |---|---|---| | **infrastruktur** | snapshots der infomaniak managed postgresql | infomaniak / betrieb | | **anwendung** | vollständiger json-export aller 13 datenbanken via admin-ui oder script | betrieb (sysadmin) | token- und authevent-tabellen sowie die testdatenbank werden vom export ausgeschlossen. ## 2. anforderung #75 — die drei pflichtelemente punkt #75 verlangt explizit drei dinge. stand und massnahmen: ### 2.1 angemessener schutz der gesicherten daten - backup-dateien enthalten alle kundendaten und sind als vertraulich klassifiziert. - **offen:** export-dateien aktuell unverschlüsselt → verschlüsselung einführen (siehe dok 04). - ablage nur auf gesicherten speichern, nicht auf persönlichen geräten/cloud (vgl. `datenbank-handling.md` abschnitt 6). ### 2.2 überwachung der datensicherung - **offen / [zu prüfen]:** werden infomaniak-snapshots automatisch überwacht (erfolg/fehler-alerting)? - **massnahme:** automatisiertes alerting bei fehlgeschlagenem backup einrichten; backup-status mindestens wöchentlich kontrollieren. ### 2.3 test der wiederherstellungsverfahren - das technische restore-verfahren ist in `bcm_runbook.md` abschnitt 2 vollständig dokumentiert (pg_dump/pg_restore + migrations-tool). - **offen:** es fehlt ein dokumentierter, regelmässiger restore-test. - **massnahme:** mindestens **vierteljährlich** einen restore-test auf der int-umgebung durchführen und protokollieren (datum, getestete db, dauer, ergebnis, tester). ## 3. backup-frequenz und aufbewahrung | anlass | aktion | aufbewahrung | |---|---|---| | vor jedem deployment | export via admin-ui | bis zum nächsten erfolgreichen deployment | | vor db-migrationen | export + beschriftet archivieren | mind. 90 tage | | wöchentlich | archiv-export | [zu prüfen: aufbewahrungsdauer festlegen, z. b. 90 tage] | | infrastruktur-snapshot | automatisch (infomaniak) | [zu prüfen: intervall & retention bei infomaniak] | ## 4. wiederherstellungsziele (rto/rpo) | parameter | zielwert | bemerkung | |---|---|---| | rto (recovery time objective) | [zu prüfen, vorschlag: ≤ 4 h] | restore dauert lt. runbook „wenige minuten bis 1 stunde\" | | rpo (recovery point objective) | [zu prüfen, vorschlag: ≤ 24 h] | abhängig von snapshot-/export-frequenz | > hinweis: rto/rpo müssen zu den im sla gegenüber kunden zugesagten werten passen (agb anhang b). aktuell im agb-entwurf rto ≤ 4 h / rpo ≤ 1 h — das erfordert häufigere sicherungen als die aktuelle wöchentliche praxis. **abgleich nötig.** ## 5. restore-test-protokoll (vorlage) | datum | getestete db | quelle (backup) | dauer | ergebnis | tester | |---|---|---|---|---|---| | | | | | | | ## 6. stand der umsetzung / lücken | thema | status | massnahme | |---|---|---| | backup-verschlüsselung | offen | siehe dok 04 | | backup-monitoring/alerting | [zu prüfen] | einrichten | | regelmässiger restore-test | offen | vierteljährlich + protokoll | | rto/rpo mit sla abgleichen | offen | werte festlegen & frequenz anpassen | ", "nextReview": "", "overdueReview": false, "zuPruefen": ["2.2 Überwachung der Datensicherung", "3. Backup-Frequenz und Aufbewahrung", "3. Backup-Frequenz und Aufbewahrung", "4. Wiederherstellungsziele (RTO/RPO)", "4. Wiederherstellungsziele (RTO/RPO)", "6. Stand der Umsetzung / Lücken"]}, {"id": "05_betrieb/06_Business_Continuity_und_Disaster_Recovery.md", "path": "05_betrieb/06_Business_Continuity_und_Disaster_Recovery.md", "chapter": "05_betrieb", "title": "Business Continuity (BCP) und Disaster Recovery (DRP)", "filename": "06_Business_Continuity_und_Disaster_Recovery.md", "meta": {}, "html": "<h1>Business Continuity (BCP) und Disaster Recovery (DRP)<\/h1>\n<p><strong>Dokumenttyp:<\/strong> Konzept &amp; Plan <strong>Geltungsbereich:<\/strong> PORTA-Plattform und zugehörige Infrastruktur <strong>Version:<\/strong> 1.0 <strong>Status:<\/strong> Entwurf zur internen Freigabe <strong>Owner:<\/strong> Geschäftsführung / Betrieb <strong>Letzte Aktualisierung:<\/strong> 02.06.2026 <strong>Deckt ab (CACC):<\/strong> 3, 79, 87 <strong>Verweist auf:<\/strong> <code>bcm_runbook.md<\/code>, <code>05_Backup_und_Wiederherstellung.md<\/code>, <code>drittanbieter-inventar.md<\/code><\/p>\n<hr>\n<h2>1. Zweck<\/h2>\n<p>Dieser Plan stellt die kontinuierliche Leistungserbringung und die Wiederherstellung der PORTA-Plattform im Katastrophen- und Störfall sicher. Die operativen Schritte sind im <code>bcm_runbook.md<\/code> dokumentiert; dieses Dokument liefert den organisatorischen Rahmen (Szenarien, Rollen, Ziele, Tests).<\/p>\n<h2>2. Kritische Komponenten und Abhängigkeiten<\/h2>\n<p>Aus dem Drittanbieter-Inventar ergeben sich die geschäftskritischen Abhängigkeiten:<\/p>\n<table><thead><tr><th>Komponente<\/th><th>Anbieter<\/th><th>Auswirkung bei Ausfall<\/th><\/tr><\/thead><tbody><tr><td>VM-Hosting &amp; DB<\/td><td>Infomaniak (CH)<\/td><td><strong>Totalausfall<\/strong> der Plattform<\/td><\/tr><tr><td>Primärer LLM-Provider<\/td><td>OpenAI (USA)<\/td><td>KI-Features (Chat, Agent, Automation) nicht verfügbar — Ausweichen auf Anthropic/Mistral möglich<\/td><\/tr><tr><td>Auth<\/td><td>Microsoft Azure AD / Google OAuth<\/td><td>Login für betroffene Nutzer nicht möglich<\/td><\/tr><tr><td>Zahlungen<\/td><td>Stripe<\/td><td>Neue Abos/Zahlungen schlagen fehl<\/td><\/tr><tr><td>System-E-Mail<\/td><td>Azure Communication Services (CH)<\/td><td>Einladungen/Benachrichtigungen werden nicht zugestellt<\/td><\/tr><\/tbody><\/table>\n<h2>3. Szenarien und Reaktion<\/h2>\n<table><thead><tr><th>#<\/th><th>Szenario<\/th><th>Reaktion<\/th><th>Referenz<\/th><\/tr><\/thead><tbody><tr><td>1<\/td><td>API antwortet nicht / Timeouts<\/td><td>Service-Neustart<\/td><td><code>bcm_runbook.md<\/code> §1<\/td><\/tr><tr><td>2<\/td><td>Datenverlust / fehlerhafte Migration<\/td><td>Backup-Restore<\/td><td><code>bcm_runbook.md<\/code> §2<\/td><\/tr><tr><td>3<\/td><td>Fehlerhaftes Release<\/td><td>Rollback (Git/Forgejo)<\/td><td><code>bcm_runbook.md<\/code> §3<\/td><\/tr><tr><td>4<\/td><td>Ausfall LLM-Primärprovider<\/td><td>Umschalten auf alternativen Provider (Anthropic/Mistral)<\/td><td>[ZU PRÜFEN: Failover-Konfiguration dokumentieren]<\/td><\/tr><tr><td>5<\/td><td>Totalausfall Infomaniak-Region<\/td><td>Wiederaufbau aus Export-Backup<\/td><td>siehe unten<\/td><\/tr><\/tbody><\/table>\n<h2>4. Verfügbarkeitsüberwachung (#79)<\/h2>\n<ul><li>Health-Check-Endpunkt: <code>GET /api/admin/health<\/code> (liefert 200 OK bei intaktem Betrieb).<\/li><li>[ZU PRÜFEN: Existiert ein automatisiertes Uptime-Monitoring, das den Health-Check periodisch prüft und bei Ausfall alarmiert? Falls nicht: einrichten (z. B. externer Monitor + Alert an Betrieb).]<\/li><\/ul>\n<h2>5. Wiederherstellungsziele<\/h2>\n<table><thead><tr><th>Parameter<\/th><th>Zielwert<\/th><th>Quelle<\/th><\/tr><\/thead><tbody><tr><td>RTO<\/td><td>[ZU PRÜFEN, Vorschlag ≤ 4 h]<\/td><td>mit SLA abgleichen<\/td><\/tr><tr><td>RPO<\/td><td>[ZU PRÜFEN, Vorschlag ≤ 24 h]<\/td><td>abhängig von Backup-Frequenz<\/td><\/tr><\/tbody><\/table>\n<h2>6. Geografische Trennung / Backup-Standort<\/h2>\n<blockquote><strong>Offener Punkt:<\/strong> Punkt #3 / FINMA verlangt angemessene Redundanz. Aktuell liegen Prod und Backup in der Infomaniak-Umgebung. <strong>[ZU PRÜFEN: Liegen Snapshots/Backups in einer getrennten Infomaniak-Region oder einem getrennten Rechenzentrum? Falls nicht, geografisch getrennte Backup-Ablage als Massnahme aufnehmen.]<\/strong><\/blockquote>\n<h2>7. Tests und Überprüfung<\/h2>\n<table><thead><tr><th>Test<\/th><th>Häufigkeit<\/th><th>Status<\/th><\/tr><\/thead><tbody><tr><td>Restore-Test (DB)<\/td><td>Vierteljährlich<\/td><td>siehe Dok 05 — neu einzuführen<\/td><\/tr><tr><td>Rollback-Übung<\/td><td>Halbjährlich<\/td><td>[ZU PRÜFEN]<\/td><\/tr><tr><td>LLM-Failover-Test<\/td><td>Halbjährlich<\/td><td>[ZU PRÜFEN]<\/td><\/tr><tr><td>BCP-Review (Aktualität)<\/td><td>Jährlich<\/td><td>neu<\/td><\/tr><\/tbody><\/table>\n<h2>8. Kommunikation im Notfall<\/h2>\n<table><thead><tr><th>Rolle<\/th><th>Kontakt<\/th><\/tr><\/thead><tbody><tr><td>Betrieb / DevOps (Server-Zugang)<\/td><td>Patrick Motsch — p.motsch@poweron.swiss<\/td><\/tr><tr><td>Drittdienste / Eskalation<\/td><td>Patrick Motsch — p.motsch@poweron.swiss<\/td><\/tr><tr><td>Kundeninformation (bei Vorfall)<\/td><td>siehe <code>07_Incident_Response_und_Meldewesen.md<\/code><\/td><\/tr><\/tbody><\/table>\n<h2>9. Stand der Umsetzung / Lücken<\/h2>\n<table><thead><tr><th>Thema<\/th><th>Status<\/th><th>Massnahme<\/th><\/tr><\/thead><tbody><tr><td>Automatisiertes Uptime-Monitoring<\/td><td>[ZU PRÜFEN]<\/td><td>Einrichten + Alerting<\/td><\/tr><tr><td>Geografisch getrenntes Backup<\/td><td>[ZU PRÜFEN]<\/td><td>Klären / umsetzen<\/td><\/tr><tr><td>Dokumentierte Tests<\/td><td>Offen<\/td><td>Testplan etablieren<\/td><\/tr><tr><td>LLM-Failover dokumentieren<\/td><td>Offen<\/td><td>Konfiguration festhalten<\/td><\/tr><\/tbody><\/table>", "text": "# business continuity (bcp) und disaster recovery (drp) **dokumenttyp:** konzept & plan **geltungsbereich:** porta-plattform und zugehörige infrastruktur **version:** 1.0 **status:** entwurf zur internen freigabe **owner:** geschäftsführung / betrieb **letzte aktualisierung:** 02.06.2026 **deckt ab (cacc):** 3, 79, 87 **verweist auf:** `bcm_runbook.md`, `05_backup_und_wiederherstellung.md`, `drittanbieter-inventar.md` --- ## 1. zweck dieser plan stellt die kontinuierliche leistungserbringung und die wiederherstellung der porta-plattform im katastrophen- und störfall sicher. die operativen schritte sind im `bcm_runbook.md` dokumentiert; dieses dokument liefert den organisatorischen rahmen (szenarien, rollen, ziele, tests). ## 2. kritische komponenten und abhängigkeiten aus dem drittanbieter-inventar ergeben sich die geschäftskritischen abhängigkeiten: | komponente | anbieter | auswirkung bei ausfall | |---|---|---| | vm-hosting & db | infomaniak (ch) | **totalausfall** der plattform | | primärer llm-provider | openai (usa) | ki-features (chat, agent, automation) nicht verfügbar — ausweichen auf anthropic/mistral möglich | | auth | microsoft azure ad / google oauth | login für betroffene nutzer nicht möglich | | zahlungen | stripe | neue abos/zahlungen schlagen fehl | | system-e-mail | azure communication services (ch) | einladungen/benachrichtigungen werden nicht zugestellt | ## 3. szenarien und reaktion | # | szenario | reaktion | referenz | |---|---|---|---| | 1 | api antwortet nicht / timeouts | service-neustart | `bcm_runbook.md` §1 | | 2 | datenverlust / fehlerhafte migration | backup-restore | `bcm_runbook.md` §2 | | 3 | fehlerhaftes release | rollback (git/forgejo) | `bcm_runbook.md` §3 | | 4 | ausfall llm-primärprovider | umschalten auf alternativen provider (anthropic/mistral) | [zu prüfen: failover-konfiguration dokumentieren] | | 5 | totalausfall infomaniak-region | wiederaufbau aus export-backup | siehe unten | ## 4. verfügbarkeitsüberwachung (#79) - health-check-endpunkt: `get /api/admin/health` (liefert 200 ok bei intaktem betrieb). - [zu prüfen: existiert ein automatisiertes uptime-monitoring, das den health-check periodisch prüft und bei ausfall alarmiert? falls nicht: einrichten (z. b. externer monitor + alert an betrieb).] ## 5. wiederherstellungsziele | parameter | zielwert | quelle | |---|---|---| | rto | [zu prüfen, vorschlag ≤ 4 h] | mit sla abgleichen | | rpo | [zu prüfen, vorschlag ≤ 24 h] | abhängig von backup-frequenz | ## 6. geografische trennung / backup-standort > **offener punkt:** punkt #3 / finma verlangt angemessene redundanz. aktuell liegen prod und backup in der infomaniak-umgebung. **[zu prüfen: liegen snapshots/backups in einer getrennten infomaniak-region oder einem getrennten rechenzentrum? falls nicht, geografisch getrennte backup-ablage als massnahme aufnehmen.]** ## 7. tests und überprüfung | test | häufigkeit | status | |---|---|---| | restore-test (db) | vierteljährlich | siehe dok 05 — neu einzuführen | | rollback-übung | halbjährlich | [zu prüfen] | | llm-failover-test | halbjährlich | [zu prüfen] | | bcp-review (aktualität) | jährlich | neu | ## 8. kommunikation im notfall | rolle | kontakt | |---|---| | betrieb / devops (server-zugang) | patrick motsch — p.motsch@poweron.swiss | | drittdienste / eskalation | patrick motsch — p.motsch@poweron.swiss | | kundeninformation (bei vorfall) | siehe `07_incident_response_und_meldewesen.md` | ## 9. stand der umsetzung / lücken | thema | status | massnahme | |---|---|---| | automatisiertes uptime-monitoring | [zu prüfen] | einrichten + alerting | | geografisch getrenntes backup | [zu prüfen] | klären / umsetzen | | dokumentierte tests | offen | testplan etablieren | | llm-failover dokumentieren | offen | konfiguration festhalten | ", "nextReview": "", "overdueReview": false, "zuPruefen": ["3. Szenarien und Reaktion", "4. Verfügbarkeitsüberwachung (#79)", "5. Wiederherstellungsziele", "5. Wiederherstellungsziele", "6. Geografische Trennung / Backup-Standort", "7. Tests und Überprüfung", "7. Tests und Überprüfung", "9. Stand der Umsetzung / Lücken", "9. Stand der Umsetzung / Lücken"]}, {"id": "05_betrieb/07_Incident_Response_und_Meldewesen.md", "path": "05_betrieb/07_Incident_Response_und_Meldewesen.md", "chapter": "05_betrieb", "title": "Incident Response und Meldewesen", "filename": "07_Incident_Response_und_Meldewesen.md", "meta": {}, "html": "<h1>Incident Response und Meldewesen<\/h1>\n<p><strong>Dokumenttyp:<\/strong> Prozess <strong>Geltungsbereich:<\/strong> Alle Sicherheits- und IT-Vorfälle der PORTA-Plattform <strong>Version:<\/strong> 1.0 <strong>Status:<\/strong> Entwurf zur internen Freigabe <strong>Owner:<\/strong> Betrieb / Geschäftsführung <strong>Letzte Aktualisierung:<\/strong> 02.06.2026 <strong>Deckt ab (CACC):<\/strong> 19, 20, 27, 86<\/p>\n<hr>\n<h2>1. Zweck<\/h2>\n<p>Dieser Prozess stellt eine schnelle, effektive und angemessene Reaktion auf Sicherheits- und IT-Vorfälle sicher und regelt die <strong>Meldepflichten gegenüber Kunden<\/strong> — insbesondere die für FINMA-Kunden kritische <strong>24-Stunden-Meldung<\/strong>.<\/p>\n<h2>2. Vorfallklassifizierung (#86)<\/h2>\n<table><thead><tr><th>Stufe<\/th><th>Definition<\/th><th>Beispiel<\/th><\/tr><\/thead><tbody><tr><td><strong>P1 — Kritisch<\/strong><\/td><td>Bestätigte Verletzung von Vertraulichkeit/Integrität/Verfügbarkeit kritischer Daten; erfolgreicher Cyberangriff<\/td><td>Datenabfluss, Ransomware, DB-Kompromittierung<\/td><\/tr><tr><td><strong>P2 — Hoch<\/strong><\/td><td>Teilweise erfolgreicher Angriff; wesentliche Störung ohne bestätigten Datenverlust<\/td><td>Eingedrungener, aber isolierter Angreifer; längerer Totalausfall<\/td><\/tr><tr><td><strong>P3 — Mittel<\/strong><\/td><td>Sicherheitsrelevantes Ereignis ohne unmittelbare Kundenauswirkung<\/td><td>Verdächtige Login-Versuche, einzelne Schwachstelle<\/td><\/tr><tr><td><strong>P4 — Niedrig<\/strong><\/td><td>Geringfügig, kein Kundenbezug<\/td><td>Fehlkonfiguration ohne Exposure<\/td><\/tr><\/tbody><\/table>\n<h2>3. Reaktionsablauf<\/h2>\n<pre class=\"mermaid\">flowchart TD\n    A[Vorfall erkannt] --&gt; B[Erfassen &amp; Klassifizieren P1-P4]\n    B --&gt; C{Kundendaten betroffen?}\n    C --&gt;|Ja| D[Sofortmassnahmen: Eindämmen, Beweise sichern]\n    C --&gt;|Nein| E[Beheben &amp; dokumentieren]\n    D --&gt; F[Kunde benachrichtigen - Frist 24h bei P1/P2]\n    F --&gt; G[Behebung &amp; Root-Cause-Analyse]\n    E --&gt; G\n    G --&gt; H[Abschlussbericht &amp; Lessons Learned]\n    H --&gt; I[Ticket schliessen, Massnahmen tracken]<\/pre>\n<h2>4. Meldepflichten gegenüber dem Kunden (#19, #20, #27)<\/h2>\n<table><thead><tr><th>Auslöser<\/th><th>Meldefrist<\/th><th>Empfänger<\/th><\/tr><\/thead><tbody><tr><td>Erfolgreicher/teilw. erfolgreicher Cyberangriff auf kritische Daten/Prozesse (#19)<\/td><td><strong>≤ 24 h<\/strong> nach Feststellung<\/td><td>Kunde (Sicherheitskontakt)<\/td><\/tr><tr><td>Wesentliche Verletzung Vertraulichkeit/Integrität/Verfügbarkeit (#19)<\/td><td><strong>≤ 24 h<\/strong><\/td><td>Kunde<\/td><\/tr><tr><td>Sonstige wesentliche nachteilige Entwicklungen (#20)<\/td><td>unverzüglich<\/td><td>Kunde<\/td><\/tr><tr><td>Verletzung des Berufsgeheimnisses (#27)<\/td><td>unverzüglich<\/td><td>Kunde<\/td><\/tr><\/tbody><\/table>\n<p><strong>Begründung der Frist:<\/strong> Der Kunde (FINMA-Institut) muss seinerseits die FINMA fristgerecht informieren (Art. 29 FINMAG). Die 24-h-Meldung von PowerOn ermöglicht das.<\/p>\n<h2>5. Meldeinhalt<\/h2>\n<p>Jede Meldung an den Kunden enthält, soweit bekannt: Art des Vorfalls, betroffene Datenkategorien/-mengen, betroffene Tenants/Personen, wahrscheinliche Folgen, bereits ergriffene und geplante Massnahmen, Ansprechpartner. Folgeberichte nach Vereinbarung; Abschlussbericht mit Root-Cause-Analyse innert <strong>72 h<\/strong>.<\/p>\n<h2>6. Meldewege und Kontakte<\/h2>\n<table><thead><tr><th>Funktion<\/th><th>Kontakt<\/th><\/tr><\/thead><tbody><tr><td>Interner Incident-Koordinator<\/td><td>Patrick Motsch — p.motsch@poweron.swiss<\/td><\/tr><tr><td>Kundenmeldung (Kanal)<\/td><td>Telefon + verschlüsselte E-Mail an den im Vertrag definierten Sicherheitskontakt<\/td><\/tr><tr><td>Eskalation Drittdienste<\/td><td>Patrick Motsch — p.motsch@poweron.swiss<\/td><\/tr><\/tbody><\/table>\n<h2>7. Beweissicherung (Forensik)<\/h2>\n<p>Bei P1/P2 werden vor der Bereinigung betroffener Systeme Beweise gesichert: relevante Logs exportieren (siehe <code>11_Logging_und_Monitoring.md<\/code>), Zeitstempel und handelnde Personen festhalten, Snapshots/Abbilder erstellen wo möglich.<\/p>\n<h2>8. Kleines Team — kompensierende Massnahmen<\/h2>\n<p>Eine 7×24-Besetzung ist nicht vorhanden. Kompensierend:<\/p>\n<ul><li>definierte Rufbereitschaft der Betriebsverantwortlichen,<\/li><li>automatisiertes Alerting (siehe Dok 11), das Vorfälle auch ausserhalb der Arbeitszeit meldet,<\/li><li>klare Eskalationskette.<\/li><\/ul>\n<p><strong>[ZU PRÜFEN: Rufbereitschaft und Erreichbarkeit konkret festlegen.]<\/strong><\/p>\n<h2>9. Stand der Umsetzung / Lücken<\/h2>\n<table><thead><tr><th>Thema<\/th><th>Status<\/th><th>Massnahme<\/th><\/tr><\/thead><tbody><tr><td>Dokumentierter Incident-Prozess<\/td><td>Neu (dieses Dokument)<\/td><td>Intern freigeben &amp; üben<\/td><\/tr><tr><td>Kundenmelde-Kontakte je Vertrag<\/td><td>Offen<\/td><td>Im Vertrag/AVV festhalten<\/td><\/tr><tr><td>Alerting für Out-of-hours<\/td><td>[ZU PRÜFEN]<\/td><td>siehe Dok 11<\/td><\/tr><tr><td>Incident-Log / Register<\/td><td>Neu<\/td><td>Anlegen<\/td><\/tr><\/tbody><\/table>", "text": "# incident response und meldewesen **dokumenttyp:** prozess **geltungsbereich:** alle sicherheits- und it-vorfälle der porta-plattform **version:** 1.0 **status:** entwurf zur internen freigabe **owner:** betrieb / geschäftsführung **letzte aktualisierung:** 02.06.2026 **deckt ab (cacc):** 19, 20, 27, 86 --- ## 1. zweck dieser prozess stellt eine schnelle, effektive und angemessene reaktion auf sicherheits- und it-vorfälle sicher und regelt die **meldepflichten gegenüber kunden** — insbesondere die für finma-kunden kritische **24-stunden-meldung**. ## 2. vorfallklassifizierung (#86) | stufe | definition | beispiel | |---|---|---| | **p1 — kritisch** | bestätigte verletzung von vertraulichkeit/integrität/verfügbarkeit kritischer daten; erfolgreicher cyberangriff | datenabfluss, ransomware, db-kompromittierung | | **p2 — hoch** | teilweise erfolgreicher angriff; wesentliche störung ohne bestätigten datenverlust | eingedrungener, aber isolierter angreifer; längerer totalausfall | | **p3 — mittel** | sicherheitsrelevantes ereignis ohne unmittelbare kundenauswirkung | verdächtige login-versuche, einzelne schwachstelle | | **p4 — niedrig** | geringfügig, kein kundenbezug | fehlkonfiguration ohne exposure | ## 3. reaktionsablauf ```mermaid flowchart td a[vorfall erkannt] --> b[erfassen & klassifizieren p1-p4] b --> c{kundendaten betroffen?} c -->|ja| d[sofortmassnahmen: eindämmen, beweise sichern] c -->|nein| e[beheben & dokumentieren] d --> f[kunde benachrichtigen - frist 24h bei p1/p2] f --> g[behebung & root-cause-analyse] e --> g g --> h[abschlussbericht & lessons learned] h --> i[ticket schliessen, massnahmen tracken] ``` ## 4. meldepflichten gegenüber dem kunden (#19, #20, #27) | auslöser | meldefrist | empfänger | |---|---|---| | erfolgreicher/teilw. erfolgreicher cyberangriff auf kritische daten/prozesse (#19) | **≤ 24 h** nach feststellung | kunde (sicherheitskontakt) | | wesentliche verletzung vertraulichkeit/integrität/verfügbarkeit (#19) | **≤ 24 h** | kunde | | sonstige wesentliche nachteilige entwicklungen (#20) | unverzüglich | kunde | | verletzung des berufsgeheimnisses (#27) | unverzüglich | kunde | **begründung der frist:** der kunde (finma-institut) muss seinerseits die finma fristgerecht informieren (art. 29 finmag). die 24-h-meldung von poweron ermöglicht das. ## 5. meldeinhalt jede meldung an den kunden enthält, soweit bekannt: art des vorfalls, betroffene datenkategorien/-mengen, betroffene tenants/personen, wahrscheinliche folgen, bereits ergriffene und geplante massnahmen, ansprechpartner. folgeberichte nach vereinbarung; abschlussbericht mit root-cause-analyse innert **72 h**. ## 6. meldewege und kontakte | funktion | kontakt | |---|---| | interner incident-koordinator | patrick motsch — p.motsch@poweron.swiss | | kundenmeldung (kanal) | telefon + verschlüsselte e-mail an den im vertrag definierten sicherheitskontakt | | eskalation drittdienste | patrick motsch — p.motsch@poweron.swiss | ## 7. beweissicherung (forensik) bei p1/p2 werden vor der bereinigung betroffener systeme beweise gesichert: relevante logs exportieren (siehe `11_logging_und_monitoring.md`), zeitstempel und handelnde personen festhalten, snapshots/abbilder erstellen wo möglich. ## 8. kleines team — kompensierende massnahmen eine 7×24-besetzung ist nicht vorhanden. kompensierend: - definierte rufbereitschaft der betriebsverantwortlichen, - automatisiertes alerting (siehe dok 11), das vorfälle auch ausserhalb der arbeitszeit meldet, - klare eskalationskette. **[zu prüfen: rufbereitschaft und erreichbarkeit konkret festlegen.]** ## 9. stand der umsetzung / lücken | thema | status | massnahme | |---|---|---| | dokumentierter incident-prozess | neu (dieses dokument) | intern freigeben & üben | | kundenmelde-kontakte je vertrag | offen | im vertrag/avv festhalten | | alerting für out-of-hours | [zu prüfen] | siehe dok 11 | | incident-log / register | neu | anlegen | ", "nextReview": "", "overdueReview": false, "zuPruefen": ["8. Kleines Team — kompensierende Massnahmen", "9. Stand der Umsetzung / Lücken"]}, {"id": "05_betrieb/08_Change_Management.md", "path": "05_betrieb/08_Change_Management.md", "chapter": "05_betrieb", "title": "Change Management", "filename": "08_Change_Management.md", "meta": {}, "html": "<h1>Change Management<\/h1>\n<p><strong>Dokumenttyp:<\/strong> Prozess <strong>Geltungsbereich:<\/strong> Alle Änderungen an Produktivsystemen der PORTA-Plattform <strong>Version:<\/strong> 1.0 <strong>Status:<\/strong> Entwurf zur internen Freigabe <strong>Owner:<\/strong> Entwicklung / Release-Verantwortlicher <strong>Letzte Aktualisierung:<\/strong> 02.06.2026 <strong>Deckt ab (CACC):<\/strong> 81, 82, 83 <strong>Verweist auf:<\/strong> <code>feature_release_bugfix.md<\/code><\/p>\n<hr>\n<h2>1. Bestehender Prozess (Basis)<\/h2>\n<p>Der Kern des Change-Managements ist bereits in <code>feature_release_bugfix.md<\/code> dokumentiert und auditkonform aufgebaut: zentrale Erfassung, Priorisierung, Tech-Workshop, Feature-/Bugfix-Branches, Code-Review (Vier-Augen-Prinzip), Staging-Verifikation gegen Akzeptanzkriterien, Release in Produktion, versionierte Release Notes und CHANGELOG. Deployment erfolgt automatisiert über Forgejo-CI/CD.<\/p>\n<p>Dieses Dokument ergänzt die für das CACC fehlenden Aspekte (#82 Frozen Zones, #83 Konfigurationskonformität) und fasst die Risikobewertung/Genehmigung formal zusammen (#81).<\/p>\n<h2>2. Change-Kategorien und Genehmigung (#81)<\/h2>\n<table><thead><tr><th>Kategorie<\/th><th>Beispiel<\/th><th>Risikobewertung<\/th><th>Genehmigung<\/th><\/tr><\/thead><tbody><tr><td><strong>Standard<\/strong><\/td><td>Routine-Bugfix, kleinere Anpassung<\/td><td>gering<\/td><td>Code-Review (2. Entwickler)<\/td><\/tr><tr><td><strong>Normal<\/strong><\/td><td>Neues Feature, API-Änderung<\/td><td>mittel<\/td><td>Tech-Workshop + Review + Staging-Verifikation<\/td><\/tr><tr><td><strong>Major<\/strong><\/td><td>Neue Version, DB-Migration, Architekturänderung<\/td><td>hoch<\/td><td>Tech-Workshop + Review + Staging + Backup vor Deployment + explizite Release-Freigabe<\/td><\/tr><tr><td><strong>Emergency<\/strong><\/td><td>Kritischer Hotfix / Sicherheitspatch<\/td><td>situativ<\/td><td>Verkürzt: Fix + Review + sofortiges Deployment, Nachdokumentation innert 24 h<\/td><\/tr><\/tbody><\/table>\n<p>Jede Major-Änderung erfordert vor dem Deployment einen Export-Backup (siehe <code>datenbank-handling.md<\/code> / Dok 05).<\/p>\n<h2>3. Frozen Zones und Maintenance Windows (#82)<\/h2>\n<p>PowerOn ermöglicht kundenseitig definierte <strong>Frozen Zones<\/strong> (Zeiträume ohne Änderungen, z. B. Jahresabschluss einer Bank) und <strong>Maintenance Windows<\/strong>.<\/p>\n<table><thead><tr><th>Element<\/th><th>Regelung<\/th><\/tr><\/thead><tbody><tr><td>Frozen Zone<\/td><td>Auf Kundenwunsch im Vertrag/SLA definiert; in diesen Zeiträumen keine nicht-kritischen Deployments<\/td><\/tr><tr><td>Maintenance Window<\/td><td>Geplante Wartung wird mind. 5 Werktage im Voraus angekündigt<\/td><\/tr><tr><td>Notfalländerung in Frozen Zone<\/td><td>Nur bei kritischen Sicherheitsvorfällen, mit Kundeninformation<\/td><\/tr><\/tbody><\/table>\n<p><strong>[ZU PRÜFEN: Werden Frozen Zones aktuell technisch/organisatorisch berücksichtigt? Falls neu, als Prozessvorgabe etablieren.]<\/strong><\/p>\n<h2>4. Standardisierte und sichere Konfiguration (#83)<\/h2>\n<table><thead><tr><th>Element<\/th><th>Regelung<\/th><th>Status<\/th><\/tr><\/thead><tbody><tr><td>Konfigurationsdateien<\/td><td><code>.env<\/code> pro Umgebung (<code>env-prod.env<\/code>, <code>env-int.env<\/code>), getrennt, nicht im Git<\/td><td>Umgesetzt<\/td><\/tr><tr><td>Infrastruktur als Code<\/td><td>[ZU PRÜFEN: Werden Server-Konfigurationen versioniert/reproduzierbar gehalten?]<\/td><td>[ZU PRÜFEN]<\/td><\/tr><tr><td>Konformitätskontrolle<\/td><td>Regelmässige Prüfung, dass Produktivkonfiguration dem Soll entspricht<\/td><td>[ZU PRÜFEN: etablieren]<\/td><\/tr><tr><td>Härtung<\/td><td>siehe <code>12_Netzwerk_und_Infrastruktursicherheit.md<\/code><\/td><td><\/td><\/tr><\/tbody><\/table>\n<h2>5. Nachvollziehbarkeit (Auditnachweis)<\/h2>\n<p>Jede Änderung ist nachvollziehbar über: Issue/Ticket, Feature-/Bugfix-Branch, Pull Request mit Review, CI/CD-Pipeline-Lauf in Forgejo, Commit-Historie, CHANGELOG-Eintrag. Rollbacks sind über Git/Forgejo dokumentiert (<code>bcm_runbook.md<\/code> §3).<\/p>\n<h2>6. Stand der Umsetzung / Lücken<\/h2>\n<table><thead><tr><th>Thema<\/th><th>Status<\/th><th>Massnahme<\/th><\/tr><\/thead><tbody><tr><td>Change-Kategorisierung formalisiert<\/td><td>Neu<\/td><td>Übernehmen<\/td><\/tr><tr><td>Frozen Zones<\/td><td>[ZU PRÜFEN]<\/td><td>Prozess verankern<\/td><\/tr><tr><td>Konfigurations-Konformitätsprüfung<\/td><td>[ZU PRÜFEN]<\/td><td>Etablieren<\/td><\/tr><\/tbody><\/table>", "text": "# change management **dokumenttyp:** prozess **geltungsbereich:** alle änderungen an produktivsystemen der porta-plattform **version:** 1.0 **status:** entwurf zur internen freigabe **owner:** entwicklung / release-verantwortlicher **letzte aktualisierung:** 02.06.2026 **deckt ab (cacc):** 81, 82, 83 **verweist auf:** `feature_release_bugfix.md` --- ## 1. bestehender prozess (basis) der kern des change-managements ist bereits in `feature_release_bugfix.md` dokumentiert und auditkonform aufgebaut: zentrale erfassung, priorisierung, tech-workshop, feature-/bugfix-branches, code-review (vier-augen-prinzip), staging-verifikation gegen akzeptanzkriterien, release in produktion, versionierte release notes und changelog. deployment erfolgt automatisiert über forgejo-ci/cd. dieses dokument ergänzt die für das cacc fehlenden aspekte (#82 frozen zones, #83 konfigurationskonformität) und fasst die risikobewertung/genehmigung formal zusammen (#81). ## 2. change-kategorien und genehmigung (#81) | kategorie | beispiel | risikobewertung | genehmigung | |---|---|---|---| | **standard** | routine-bugfix, kleinere anpassung | gering | code-review (2. entwickler) | | **normal** | neues feature, api-änderung | mittel | tech-workshop + review + staging-verifikation | | **major** | neue version, db-migration, architekturänderung | hoch | tech-workshop + review + staging + backup vor deployment + explizite release-freigabe | | **emergency** | kritischer hotfix / sicherheitspatch | situativ | verkürzt: fix + review + sofortiges deployment, nachdokumentation innert 24 h | jede major-änderung erfordert vor dem deployment einen export-backup (siehe `datenbank-handling.md` / dok 05). ## 3. frozen zones und maintenance windows (#82) poweron ermöglicht kundenseitig definierte **frozen zones** (zeiträume ohne änderungen, z. b. jahresabschluss einer bank) und **maintenance windows**. | element | regelung | |---|---| | frozen zone | auf kundenwunsch im vertrag/sla definiert; in diesen zeiträumen keine nicht-kritischen deployments | | maintenance window | geplante wartung wird mind. 5 werktage im voraus angekündigt | | notfalländerung in frozen zone | nur bei kritischen sicherheitsvorfällen, mit kundeninformation | **[zu prüfen: werden frozen zones aktuell technisch/organisatorisch berücksichtigt? falls neu, als prozessvorgabe etablieren.]** ## 4. standardisierte und sichere konfiguration (#83) | element | regelung | status | |---|---|---| | konfigurationsdateien | `.env` pro umgebung (`env-prod.env`, `env-int.env`), getrennt, nicht im git | umgesetzt | | infrastruktur als code | [zu prüfen: werden server-konfigurationen versioniert/reproduzierbar gehalten?] | [zu prüfen] | | konformitätskontrolle | regelmässige prüfung, dass produktivkonfiguration dem soll entspricht | [zu prüfen: etablieren] | | härtung | siehe `12_netzwerk_und_infrastruktursicherheit.md` | | ## 5. nachvollziehbarkeit (auditnachweis) jede änderung ist nachvollziehbar über: issue/ticket, feature-/bugfix-branch, pull request mit review, ci/cd-pipeline-lauf in forgejo, commit-historie, changelog-eintrag. rollbacks sind über git/forgejo dokumentiert (`bcm_runbook.md` §3). ## 6. stand der umsetzung / lücken | thema | status | massnahme | |---|---|---| | change-kategorisierung formalisiert | neu | übernehmen | | frozen zones | [zu prüfen] | prozess verankern | | konfigurations-konformitätsprüfung | [zu prüfen] | etablieren | ", "nextReview": "", "overdueReview": false, "zuPruefen": ["3. Frozen Zones und Maintenance Windows (#82)", "4. Standardisierte und sichere Konfiguration (#83)", "4. Standardisierte und sichere Konfiguration (#83)", "6. Stand der Umsetzung / Lücken", "6. Stand der Umsetzung / Lücken"]}, {"id": "05_betrieb/09_Patch_Management.md", "path": "05_betrieb/09_Patch_Management.md", "chapter": "05_betrieb", "title": "Patch Management", "filename": "09_Patch_Management.md", "meta": {}, "html": "<h1>Patch Management<\/h1>\n<p><strong>Dokumenttyp:<\/strong> Prozess <strong>Geltungsbereich:<\/strong> Betriebssystem, Laufzeitumgebung, Abhängigkeiten der PORTA-Plattform <strong>Version:<\/strong> 1.0 <strong>Status:<\/strong> Entwurf zur internen Freigabe <strong>Owner:<\/strong> Betrieb / DevOps <strong>Letzte Aktualisierung:<\/strong> 02.06.2026 <strong>Deckt ab (CACC):<\/strong> 78<\/p>\n<hr>\n<h2>1. Geltungsbereich<\/h2>\n<table><thead><tr><th>Ebene<\/th><th>Beispiel<\/th><th>Patch-Verantwortung<\/th><\/tr><\/thead><tbody><tr><td>Managed Infrastruktur<\/td><td>VM-Host, PostgreSQL (Infomaniak)<\/td><td>Infomaniak (Managed) + Betrieb<\/td><\/tr><tr><td>Betriebssystem (Ubuntu)<\/td><td>Sicherheitsupdates<\/td><td>Betrieb<\/td><\/tr><tr><td>Laufzeit / Python<\/td><td><code>requirements.txt<\/code>-Abhängigkeiten<\/td><td>Entwicklung/Betrieb<\/td><\/tr><tr><td>Anwendungsabhängigkeiten<\/td><td>Bibliotheken (z. B. LangChain, SDKs)<\/td><td>Entwicklung<\/td><\/tr><\/tbody><\/table>\n<h2>2. Maximale Fristen (#78)<\/h2>\n<p>Punkt #78 verlangt definierte Höchstdauern bis zum Einspielen von Patches:<\/p>\n<table><thead><tr><th>Kritikalität<\/th><th>Beschreibung<\/th><th>Maximale Frist<\/th><\/tr><\/thead><tbody><tr><td>Kritisch<\/td><td>Aktiv ausgenutzte / kritische Schwachstelle (CVSS ≥ 9)<\/td><td><strong>48 Stunden<\/strong><\/td><\/tr><tr><td>Hoch<\/td><td>CVSS 7,0–8,9<\/td><td>7 Tage<\/td><\/tr><tr><td>Mittel<\/td><td>CVSS 4,0–6,9<\/td><td>30 Tage<\/td><\/tr><tr><td>Niedrig<\/td><td>CVSS &lt; 4,0<\/td><td>nächstes Wartungsfenster<\/td><\/tr><\/tbody><\/table>\n<h2>3. Ablauf<\/h2>\n<ol><li><strong>Erkennung:<\/strong> Sicherheitsmeldungen verfolgen (Ubuntu Security, GitHub Dependabot/Advisories, Provider-Statusseiten). <strong>[ZU PRÜFEN: Wird Dependabot o. ä. in Forgejo/Repo genutzt?]<\/strong><\/li><li><strong>Bewertung:<\/strong> Kritikalität einstufen, betroffene Systeme bestimmen.<\/li><li><strong>Test:<\/strong> Patch auf INT-Umgebung (<code>api-int.poweron.swiss<\/code>) einspielen und verifizieren.<\/li><li><strong>Freigabe &amp; Deployment:<\/strong> Über regulären Change-Prozess (Dok 08); bei kritischen Patches als Emergency-Change.<\/li><li><strong>Dokumentation:<\/strong> Patch, Datum, Version im CHANGELOG/Ticket festhalten.<\/li><\/ol>\n<h2>4. OS- und Abhängigkeits-Updates (technisch)<\/h2>\n<p>Abhängigkeiten werden beim Deployment via <code>pip install -r requirements.txt<\/code> aktualisiert (siehe <code>bcm_runbook.md<\/code>). OS-Patches: <code>apt<\/code>-Updates auf den VMs via <code>unattended-upgrades<\/code> (aktiv auf allen VMs). Konfiguration: Sicherheitspatches werden automatisch installiert, aber Services werden <strong>nicht<\/strong> automatisch neugestartet (<code>needrestart = 'l'<\/code>). Der Restart erfolgt kontrolliert beim naechsten Deployment oder manuell bei kritischen Patches.<\/p>\n<h2>5. Stand der Umsetzung / Lücken<\/h2>\n<table><thead><tr><th>Thema<\/th><th>Status<\/th><th>Massnahme<\/th><\/tr><\/thead><tbody><tr><td>Definierte Patch-Fristen<\/td><td>Neu (dieses Dokument)<\/td><td>Übernehmen<\/td><\/tr><tr><td>Automatisches Vuln-Tracking (Dependabot)<\/td><td>[ZU PRÜFEN]<\/td><td>Aktivieren<\/td><\/tr><tr><td>Unattended-Upgrades OS<\/td><td>✅ Aktiv<\/td><td>Patches auto-installiert, Service-Restart manuell (<code>needrestart='l'<\/code>)<\/td><\/tr><tr><td>Patch-Protokollierung<\/td><td>[ZU PRÜFEN]<\/td><td>Im CHANGELOG mitführen<\/td><\/tr><\/tbody><\/table>", "text": "# patch management **dokumenttyp:** prozess **geltungsbereich:** betriebssystem, laufzeitumgebung, abhängigkeiten der porta-plattform **version:** 1.0 **status:** entwurf zur internen freigabe **owner:** betrieb / devops **letzte aktualisierung:** 02.06.2026 **deckt ab (cacc):** 78 --- ## 1. geltungsbereich | ebene | beispiel | patch-verantwortung | |---|---|---| | managed infrastruktur | vm-host, postgresql (infomaniak) | infomaniak (managed) + betrieb | | betriebssystem (ubuntu) | sicherheitsupdates | betrieb | | laufzeit / python | `requirements.txt`-abhängigkeiten | entwicklung/betrieb | | anwendungsabhängigkeiten | bibliotheken (z. b. langchain, sdks) | entwicklung | ## 2. maximale fristen (#78) punkt #78 verlangt definierte höchstdauern bis zum einspielen von patches: | kritikalität | beschreibung | maximale frist | |---|---|---| | kritisch | aktiv ausgenutzte / kritische schwachstelle (cvss ≥ 9) | **48 stunden** | | hoch | cvss 7,0–8,9 | 7 tage | | mittel | cvss 4,0–6,9 | 30 tage | | niedrig | cvss < 4,0 | nächstes wartungsfenster | ## 3. ablauf 1. **erkennung:** sicherheitsmeldungen verfolgen (ubuntu security, github dependabot/advisories, provider-statusseiten). **[zu prüfen: wird dependabot o. ä. in forgejo/repo genutzt?]** 2. **bewertung:** kritikalität einstufen, betroffene systeme bestimmen. 3. **test:** patch auf int-umgebung (`api-int.poweron.swiss`) einspielen und verifizieren. 4. **freigabe & deployment:** über regulären change-prozess (dok 08); bei kritischen patches als emergency-change. 5. **dokumentation:** patch, datum, version im changelog/ticket festhalten. ## 4. os- und abhängigkeits-updates (technisch) abhängigkeiten werden beim deployment via `pip install -r requirements.txt` aktualisiert (siehe `bcm_runbook.md`). os-patches: `apt`-updates auf den vms via `unattended-upgrades` (aktiv auf allen vms). konfiguration: sicherheitspatches werden automatisch installiert, aber services werden **nicht** automatisch neugestartet (`needrestart = 'l'`). der restart erfolgt kontrolliert beim naechsten deployment oder manuell bei kritischen patches. ## 5. stand der umsetzung / lücken | thema | status | massnahme | |---|---|---| | definierte patch-fristen | neu (dieses dokument) | übernehmen | | automatisches vuln-tracking (dependabot) | [zu prüfen] | aktivieren | | unattended-upgrades os | ✅ aktiv | patches auto-installiert, service-restart manuell (`needrestart='l'`) | | patch-protokollierung | [zu prüfen] | im changelog mitführen | ", "nextReview": "", "overdueReview": false, "zuPruefen": ["3. Ablauf", "5. Stand der Umsetzung / Lücken", "5. Stand der Umsetzung / Lücken"]}, {"id": "05_betrieb/10_Schwachstellenmanagement.md", "path": "05_betrieb/10_Schwachstellenmanagement.md", "chapter": "05_betrieb", "title": "Schwachstellenmanagement", "filename": "10_Schwachstellenmanagement.md", "meta": {}, "html": "<h1>Schwachstellenmanagement<\/h1>\n<p><strong>Dokumenttyp:<\/strong> Richtlinie &amp; Prozess <strong>Geltungsbereich:<\/strong> Alle für Kunden relevanten Systeme der PORTA-Plattform <strong>Version:<\/strong> 1.0 <strong>Status:<\/strong> Entwurf zur internen Freigabe <strong>Owner:<\/strong> Betrieb / Entwicklung <strong>Letzte Aktualisierung:<\/strong> 02.06.2026 <strong>Deckt ab (CACC):<\/strong> 54, 59, 63, 84<\/p>\n<hr>\n<h2>1. Zweck<\/h2>\n<p>Kontinuierliche Identifizierung, Bewertung, Behandlung und Nachverfolgung von Schwachstellen in den für Kunden relevanten Systemen.<\/p>\n<h2>2. Identifizierungsmethoden (#63)<\/h2>\n<table><thead><tr><th>Methode<\/th><th>Häufigkeit<\/th><th>Status<\/th><\/tr><\/thead><tbody><tr><td>Automatisiertes Dependency-Scanning (Bibliotheken)<\/td><td>kontinuierlich<\/td><td>[ZU PRÜFEN: Dependabot/Scanner aktiv?]<\/td><\/tr><tr><td>Schwachstellen-Scan der Server/Endpunkte<\/td><td>[ZU PRÜFEN, Vorschlag: quartalsweise]<\/td><td>[ZU PRÜFEN]<\/td><\/tr><tr><td>Penetrationstest durch unabhängige Dritte<\/td><td>jährlich<\/td><td><strong>[ZU PRÜFEN: bisher durchgeführt? Sonst erstmalig planen]<\/strong><\/td><\/tr><tr><td>Interne Code-Reviews<\/td><td>pro Change<\/td><td>Umgesetzt (siehe Dok 08)<\/td><\/tr><\/tbody><\/table>\n<h2>3. Bewertung und Behandlung (#84)<\/h2>\n<ol><li><strong>Dokumentation:<\/strong> Jede Schwachstelle wird mit Quelle, betroffenem System und CVSS-Score erfasst.<\/li><li><strong>Bewertung:<\/strong> Einstufung nach Kritikalität.<\/li><li><strong>Massnahme:<\/strong> Behebung über Patch- (Dok 09) bzw. Change-Prozess (Dok 08), nach den dort definierten Fristen.<\/li><li><strong>Nachverfolgung:<\/strong> Offene Schwachstellen werden bis zur Behebung in einem Register getrackt.<\/li><li><strong>Reporting:<\/strong> Status mindestens quartalsweise intern; auf Anfrage für berechtigte Kunden/Prüfer einsehbar.<\/li><\/ol>\n<h2>4. Unabhängige Audits (#54, #59)<\/h2>\n<p>Punkt #54/#59 verlangen regelmässige unabhängige Audits und die Bereitstellung <strong>vollständiger Auditberichte<\/strong> (nicht nur Zertifikate).<\/p>\n<ul><li><strong>Aktuell:<\/strong> [ZU PRÜFEN: Es liegen bisher keine externen Audit-/Pentest-Berichte vor.]<\/li><li><strong>Massnahme:<\/strong> Jährlichen externen Penetrationstest beauftragen; Bericht ablegen und berechtigten Kunden zugänglich machen. Behobene Schwachstellen dokumentieren.<\/li><\/ul>\n<h2>5. Schwachstellen-Register (Vorlage)<\/h2>\n<table><thead><tr><th>ID<\/th><th>Datum<\/th><th>System<\/th><th>Beschreibung<\/th><th>CVSS<\/th><th>Status<\/th><th>Behoben am<\/th><\/tr><\/thead><tbody><tr><td><\/td><td><\/td><td><\/td><td><\/td><td><\/td><td><\/td><td><\/td><\/tr><\/tbody><\/table>\n<h2>6. Stand der Umsetzung / Lücken<\/h2>\n<table><thead><tr><th>Thema<\/th><th>Status<\/th><th>Massnahme<\/th><\/tr><\/thead><tbody><tr><td>Externer Pentest<\/td><td>[ZU PRÜFEN / fehlt]<\/td><td>Jährlich beauftragen<\/td><\/tr><tr><td>Dependency-Scanning<\/td><td>[ZU PRÜFEN]<\/td><td>Aktivieren<\/td><\/tr><tr><td>Schwachstellen-Register<\/td><td>Neu<\/td><td>Anlegen<\/td><\/tr><\/tbody><\/table>", "text": "# schwachstellenmanagement **dokumenttyp:** richtlinie & prozess **geltungsbereich:** alle für kunden relevanten systeme der porta-plattform **version:** 1.0 **status:** entwurf zur internen freigabe **owner:** betrieb / entwicklung **letzte aktualisierung:** 02.06.2026 **deckt ab (cacc):** 54, 59, 63, 84 --- ## 1. zweck kontinuierliche identifizierung, bewertung, behandlung und nachverfolgung von schwachstellen in den für kunden relevanten systemen. ## 2. identifizierungsmethoden (#63) | methode | häufigkeit | status | |---|---|---| | automatisiertes dependency-scanning (bibliotheken) | kontinuierlich | [zu prüfen: dependabot/scanner aktiv?] | | schwachstellen-scan der server/endpunkte | [zu prüfen, vorschlag: quartalsweise] | [zu prüfen] | | penetrationstest durch unabhängige dritte | jährlich | **[zu prüfen: bisher durchgeführt? sonst erstmalig planen]** | | interne code-reviews | pro change | umgesetzt (siehe dok 08) | ## 3. bewertung und behandlung (#84) 1. **dokumentation:** jede schwachstelle wird mit quelle, betroffenem system und cvss-score erfasst. 2. **bewertung:** einstufung nach kritikalität. 3. **massnahme:** behebung über patch- (dok 09) bzw. change-prozess (dok 08), nach den dort definierten fristen. 4. **nachverfolgung:** offene schwachstellen werden bis zur behebung in einem register getrackt. 5. **reporting:** status mindestens quartalsweise intern; auf anfrage für berechtigte kunden/prüfer einsehbar. ## 4. unabhängige audits (#54, #59) punkt #54/#59 verlangen regelmässige unabhängige audits und die bereitstellung **vollständiger auditberichte** (nicht nur zertifikate). - **aktuell:** [zu prüfen: es liegen bisher keine externen audit-/pentest-berichte vor.] - **massnahme:** jährlichen externen penetrationstest beauftragen; bericht ablegen und berechtigten kunden zugänglich machen. behobene schwachstellen dokumentieren. ## 5. schwachstellen-register (vorlage) | id | datum | system | beschreibung | cvss | status | behoben am | |---|---|---|---|---|---|---| | | | | | | | | ## 6. stand der umsetzung / lücken | thema | status | massnahme | |---|---|---| | externer pentest | [zu prüfen / fehlt] | jährlich beauftragen | | dependency-scanning | [zu prüfen] | aktivieren | | schwachstellen-register | neu | anlegen | ", "nextReview": "", "overdueReview": false, "zuPruefen": ["2. Identifizierungsmethoden (#63)", "2. Identifizierungsmethoden (#63)", "2. Identifizierungsmethoden (#63)", "4. Unabhängige Audits (#54, #59)", "6. Stand der Umsetzung / Lücken", "6. Stand der Umsetzung / Lücken"]}, {"id": "05_betrieb/11_Logging_und_Monitoring.md", "path": "05_betrieb/11_Logging_und_Monitoring.md", "chapter": "05_betrieb", "title": "Logging und Monitoring (Sicherheitsprotokollierung)", "filename": "11_Logging_und_Monitoring.md", "meta": {}, "html": "<h1>Logging und Monitoring (Sicherheitsprotokollierung)<\/h1>\n<p><strong>Dokumenttyp:<\/strong> Konzept <strong>Geltungsbereich:<\/strong> Protokollierung und Überwachung der PORTA-Plattform <strong>Version:<\/strong> 1.0 <strong>Status:<\/strong> Entwurf zur internen Freigabe <strong>Owner:<\/strong> Betrieb / DevOps <strong>Letzte Aktualisierung:<\/strong> 02.06.2026 <strong>Deckt ab (CACC):<\/strong> 88, 89, 90, 91, 92, 93, 94<\/p>\n<hr>\n<h2>1. Vorhandene Protokolle<\/h2>\n<table><thead><tr><th>Protokoll<\/th><th>Inhalt<\/th><th>Ort<\/th><\/tr><\/thead><tbody><tr><td>Anwendungslog<\/td><td>App-Ereignisse<\/td><td><code>/srv/gateway/shared/logs/log_app_YYYYMMDD.log<\/code><\/td><\/tr><tr><td>Systemlog<\/td><td>Service <code>gateway<\/code><\/td><td><code>journalctl -u gateway<\/code><\/td><\/tr><tr><td>AuthEvent (DB)<\/td><td>Login-Protokoll<\/td><td>DB-Tabelle (vom Export ausgeschlossen)<\/td><\/tr><tr><td>Export/Import-Log<\/td><td>DB-Operationen durch SysAdmins<\/td><td>serverseitig (siehe <code>datenbank-handling.md<\/code> §6)<\/td><\/tr><tr><td>CI/CD<\/td><td>Deployments<\/td><td>Forgejo<\/td><\/tr><\/tbody><\/table>\n<h2>2. Protokollierung des Zugriffs auf Kundendaten (#88, #94)<\/h2>\n<ul><li>Zugriffe auf Kundendaten im Klartext (z. B. DB-Export/Import) werden serverseitig geloggt.<\/li><li><strong>Anforderung #94:<\/strong> Eindeutige Identifizierung von Benutzerzugriffen auf Tenant-Ebene für forensische Analyse.<\/li><li><strong>Offener Punkt:<\/strong> Da der SSH-Zugang über den geteilten <code>ubuntu<\/code>-User läuft, ist die Personenzuordnung auf Server-Ebene aktuell eingeschränkt. → personalisierte Zugänge oder Sitzungsprotokollierung erforderlich (siehe Dok 02). <strong>[ZU PRÜFEN/UMZUSETZEN]<\/strong><\/li><\/ul>\n<h2>3. Kundenzugang zu Protokollen (#88)<\/h2>\n<p>Punkt #88 verlangt, dass Protokolle dem Kunden jederzeit (ggf. in Echtzeit) zur Verfügung stehen.<\/p>\n<p><strong>[ZU PRÜFEN: Können Kunden ihre Tenant-bezogenen Logs einsehen/exportieren? Falls nicht vorhanden, als Massnahme aufnehmen — z. B. Log-Export pro Mandant oder API.]<\/strong><\/p>\n<h2>4. Automatische Analyse und Ereigniserkennung (#89, #90)<\/h2>\n<table><thead><tr><th>Element<\/th><th>Status<\/th><\/tr><\/thead><tbody><tr><td>Etablierter Logging-/Monitoring-Prozess<\/td><td>[ZU PRÜFEN]<\/td><\/tr><tr><td>Automatische, proaktive Loganalyse (SIEM/Alerting)<\/td><td><strong>Offen<\/strong> — kleines Team, kein SIEM<\/td><\/tr><tr><td>Anomalie-/Schwellwert-Alerting<\/td><td>[ZU PRÜFEN]<\/td><\/tr><\/tbody><\/table>\n<p><strong>Kompensierende Massnahme (kleines Team):<\/strong> Statt eines vollwertigen SIEM ein leichtgewichtiges, automatisiertes Alerting (z. B. Log-Monitor, der bei definierten Mustern — fehlgeschlagene Logins, Fehlerraten, Health-Check-Ausfall — eine Benachrichtigung an die Rufbereitschaft sendet). <strong>[ZU PRÜFEN/EINFÜHREN]<\/strong><\/p>\n<h2>5. Schutz der Protokolldaten (#91)<\/h2>\n<table><thead><tr><th>Anforderung<\/th><th>Status / Massnahme<\/th><\/tr><\/thead><tbody><tr><td>Schutz vor unbefugtem Zugriff<\/td><td>Logs auf Server, nur über privilegierten Zugang erreichbar<\/td><\/tr><tr><td>Schutz vor Veränderung/Löschung (Integrität)<\/td><td><strong>Offen<\/strong> — Logs aktuell auf demselben Server, kein Write-Once. <strong>Massnahme:<\/strong> Logs an einen getrennten, append-only/write-once Speicher weiterleiten<\/td><\/tr><tr><td>Aufbewahrungsdauer<\/td><td>[ZU PRÜFEN, Vorschlag: mind. 12 Monate, sicherheitsrelevante Zugriffslogs 3 Jahre]<\/td><\/tr><\/tbody><\/table>\n<h2>6. 7×24-Analyse (#92) und SOC-Schnittstellen (#93)<\/h2>\n<ul><li><strong>#92 (7×24-Analyse):<\/strong> Mit 2–5 Personen nicht als Vollbetrieb leistbar. Kompensierend: automatisiertes Alerting + Rufbereitschaft (siehe Dok 07).<\/li><li><strong>#93 (Schnittstellen zum Kunden-SOC):<\/strong> [ZU PRÜFEN: Kann Log-Streaming/Export an ein Kunden-SOC bereitgestellt werden (Syslog, API)? Falls nicht, als optionales Angebot dokumentieren.]<\/li><\/ul>\n<h2>7. Stand der Umsetzung / Lücken<\/h2>\n<table><thead><tr><th>Thema<\/th><th>Status<\/th><th>Massnahme<\/th><\/tr><\/thead><tbody><tr><td>Personenbezogene Nachvollziehbarkeit (Tenant-Ebene)<\/td><td>Teilweise<\/td><td>personalisierte Zugänge / Sitzungslog<\/td><\/tr><tr><td>Log-Integritätsschutz<\/td><td>Offen<\/td><td>append-only/getrennter Speicher<\/td><\/tr><tr><td>Automatisches Alerting<\/td><td>Offen<\/td><td>einführen<\/td><\/tr><tr><td>Aufbewahrungsdauer definiert<\/td><td>Offen<\/td><td>festlegen<\/td><\/tr><tr><td>Kundenzugang zu Logs<\/td><td>[ZU PRÜFEN]<\/td><td>klären<\/td><\/tr><\/tbody><\/table>", "text": "# logging und monitoring (sicherheitsprotokollierung) **dokumenttyp:** konzept **geltungsbereich:** protokollierung und überwachung der porta-plattform **version:** 1.0 **status:** entwurf zur internen freigabe **owner:** betrieb / devops **letzte aktualisierung:** 02.06.2026 **deckt ab (cacc):** 88, 89, 90, 91, 92, 93, 94 --- ## 1. vorhandene protokolle | protokoll | inhalt | ort | |---|---|---| | anwendungslog | app-ereignisse | `/srv/gateway/shared/logs/log_app_yyyymmdd.log` | | systemlog | service `gateway` | `journalctl -u gateway` | | authevent (db) | login-protokoll | db-tabelle (vom export ausgeschlossen) | | export/import-log | db-operationen durch sysadmins | serverseitig (siehe `datenbank-handling.md` §6) | | ci/cd | deployments | forgejo | ## 2. protokollierung des zugriffs auf kundendaten (#88, #94) - zugriffe auf kundendaten im klartext (z. b. db-export/import) werden serverseitig geloggt. - **anforderung #94:** eindeutige identifizierung von benutzerzugriffen auf tenant-ebene für forensische analyse. - **offener punkt:** da der ssh-zugang über den geteilten `ubuntu`-user läuft, ist die personenzuordnung auf server-ebene aktuell eingeschränkt. → personalisierte zugänge oder sitzungsprotokollierung erforderlich (siehe dok 02). **[zu prüfen/umzusetzen]** ## 3. kundenzugang zu protokollen (#88) punkt #88 verlangt, dass protokolle dem kunden jederzeit (ggf. in echtzeit) zur verfügung stehen. **[zu prüfen: können kunden ihre tenant-bezogenen logs einsehen/exportieren? falls nicht vorhanden, als massnahme aufnehmen — z. b. log-export pro mandant oder api.]** ## 4. automatische analyse und ereigniserkennung (#89, #90) | element | status | |---|---| | etablierter logging-/monitoring-prozess | [zu prüfen] | | automatische, proaktive loganalyse (siem/alerting) | **offen** — kleines team, kein siem | | anomalie-/schwellwert-alerting | [zu prüfen] | **kompensierende massnahme (kleines team):** statt eines vollwertigen siem ein leichtgewichtiges, automatisiertes alerting (z. b. log-monitor, der bei definierten mustern — fehlgeschlagene logins, fehlerraten, health-check-ausfall — eine benachrichtigung an die rufbereitschaft sendet). **[zu prüfen/einführen]** ## 5. schutz der protokolldaten (#91) | anforderung | status / massnahme | |---|---| | schutz vor unbefugtem zugriff | logs auf server, nur über privilegierten zugang erreichbar | | schutz vor veränderung/löschung (integrität) | **offen** — logs aktuell auf demselben server, kein write-once. **massnahme:** logs an einen getrennten, append-only/write-once speicher weiterleiten | | aufbewahrungsdauer | [zu prüfen, vorschlag: mind. 12 monate, sicherheitsrelevante zugriffslogs 3 jahre] | ## 6. 7×24-analyse (#92) und soc-schnittstellen (#93) - **#92 (7×24-analyse):** mit 2–5 personen nicht als vollbetrieb leistbar. kompensierend: automatisiertes alerting + rufbereitschaft (siehe dok 07). - **#93 (schnittstellen zum kunden-soc):** [zu prüfen: kann log-streaming/export an ein kunden-soc bereitgestellt werden (syslog, api)? falls nicht, als optionales angebot dokumentieren.] ## 7. stand der umsetzung / lücken | thema | status | massnahme | |---|---|---| | personenbezogene nachvollziehbarkeit (tenant-ebene) | teilweise | personalisierte zugänge / sitzungslog | | log-integritätsschutz | offen | append-only/getrennter speicher | | automatisches alerting | offen | einführen | | aufbewahrungsdauer definiert | offen | festlegen | | kundenzugang zu logs | [zu prüfen] | klären | ", "nextReview": "", "overdueReview": false, "zuPruefen": ["2. Protokollierung des Zugriffs auf Kundendaten (#88, #94)", "3. Kundenzugang zu Protokollen (#88)", "4. Automatische Analyse und Ereigniserkennung (#89, #90)", "4. Automatische Analyse und Ereigniserkennung (#89, #90)", "4. Automatische Analyse und Ereigniserkennung (#89, #90)", "5. Schutz der Protokolldaten (#91)", "6. 7×24-Analyse (#92) und SOC-Schnittstellen (#93)", "7. Stand der Umsetzung / Lücken"]}, {"id": "05_betrieb/12_Netzwerk_und_Infrastruktursicherheit.md", "path": "05_betrieb/12_Netzwerk_und_Infrastruktursicherheit.md", "chapter": "05_betrieb", "title": "Netzwerk- und Infrastruktursicherheit", "filename": "12_Netzwerk_und_Infrastruktursicherheit.md", "meta": {}, "html": "<h1>Netzwerk- und Infrastruktursicherheit<\/h1>\n<p><strong>Dokumenttyp:<\/strong> Konzept <strong>Geltungsbereich:<\/strong> Netzwerk, Server und Rechenzentrumsanbindung der PORTA-Plattform <strong>Version:<\/strong> 1.0 <strong>Status:<\/strong> Entwurf zur internen Freigabe <strong>Owner:<\/strong> Betrieb / DevOps <strong>Letzte Aktualisierung:<\/strong> 02.06.2026 <strong>Deckt ab (CACC):<\/strong> 95, 96, 97, 98, 99<\/p>\n<hr>\n<h2>1. Härtung und Basiskonfiguration (#95)<\/h2>\n<table><thead><tr><th>Element<\/th><th>Vorgabe<\/th><th>Status<\/th><\/tr><\/thead><tbody><tr><td>Server-Härtung (Ubuntu)<\/td><td>nach anerkanntem Standard (z. B. CIS Benchmark)<\/td><td>[ZU PRÜFEN: angewendet?]<\/td><\/tr><tr><td>Nicht benötigte Dienste/Ports deaktiviert<\/td><td>ja<\/td><td>[ZU PRÜFEN]<\/td><\/tr><tr><td>Regelmässige Validierung der Basiskonfiguration<\/td><td>mind. jährlich<\/td><td>[ZU PRÜFEN: etablieren]<\/td><\/tr><\/tbody><\/table>\n<h2>2. Netzwerksegmentierung und Mandantentrennung (#96)<\/h2>\n<table><thead><tr><th>Element<\/th><th>Beschreibung<\/th><th>Status<\/th><\/tr><\/thead><tbody><tr><td>Trennung App / DB<\/td><td>Anwendung (<code>api.poweron.swiss<\/code>) und Datenbank (<code>db.poweron.swiss<\/code>) auf getrennten Hosts<\/td><td>Umgesetzt<\/td><\/tr><tr><td>Trennung Prod / Int<\/td><td>Produktiv- und Integrationsumgebung getrennt<\/td><td>Umgesetzt<\/td><\/tr><tr><td>Mandantentrennung (Multi-Tenancy)<\/td><td>Logische Trennung der Kundendaten innerhalb der Anwendung über Mandate/Berechtigungen<\/td><td>Umgesetzt (logisch)<\/td><\/tr><tr><td>Netzwerksegmentierung (Firewall-Zonen)<\/td><td>[ZU PRÜFEN: wie ist der Netzverkehr segmentiert?]<\/td><td>[ZU PRÜFEN]<\/td><\/tr><\/tbody><\/table>\n<blockquote><strong>Hinweis für regulierte Kunden:<\/strong> Die Mandantentrennung erfolgt logisch (gemeinsame DB-Instanz, getrennte Mandate/Berechtigungen), nicht physisch pro Kunde. Das ist für SaaS üblich, sollte aber im Assessment transparent gemacht werden.<\/blockquote>\n<h2>3. Netzwerkschutzmassnahmen (#97)<\/h2>\n<table><thead><tr><th>Massnahme<\/th><th>Status<\/th><\/tr><\/thead><tbody><tr><td>Firewall<\/td><td>[ZU PRÜFEN: Infomaniak-Firewall / OS-Firewall (ufw/iptables) konfiguriert?]<\/td><\/tr><tr><td>Web Application Firewall (WAF)<\/td><td>[ZU PRÜFEN: vorhanden?]<\/td><\/tr><tr><td>IDS/IPS (Intrusion Detection/Prevention)<\/td><td>[ZU PRÜFEN: vorhanden?]<\/td><\/tr><tr><td>TLS-Terminierung / Reverse Proxy<\/td><td>[ZU PRÜFEN: nginx o. ä.?]<\/td><\/tr><\/tbody><\/table>\n<h2>4. Schutz vor netzwerkbasierten Angriffen / DDoS (#98)<\/h2>\n<table><thead><tr><th>Massnahme<\/th><th>Status<\/th><\/tr><\/thead><tbody><tr><td>DDoS-Schutz<\/td><td>[ZU PRÜFEN: durch Infomaniak bereitgestellt?]<\/td><\/tr><tr><td>Anomalie-Erkennung im Datenverkehr<\/td><td>[ZU PRÜFEN]<\/td><\/tr><tr><td>Rate-Limiting<\/td><td>Teilweise (z. B. Export max. 2/Min — siehe <code>datenbank-handling.md<\/code>)<\/td><\/tr><\/tbody><\/table>\n<h2>5. Physische Sicherheit und Versorgung (#99)<\/h2>\n<p>Die physische Sicherheit wird durch den Rechenzentrumsbetreiber <strong>Infomaniak<\/strong> (Schweiz) gewährleistet:<\/p>\n<table><thead><tr><th>Element<\/th><th>Zuständigkeit<\/th><th>Nachweis<\/th><\/tr><\/thead><tbody><tr><td>Physische Zutrittskontrolle<\/td><td>Infomaniak<\/td><td>[ZU PRÜFEN: Infomaniak-Zertifikate/RZ-Doku beilegen, z. B. ISO 27001]<\/td><\/tr><tr><td>Stromversorgung / USV / Notstrom<\/td><td>Infomaniak<\/td><td>Infomaniak-Rechenzentren (CH)<\/td><\/tr><tr><td>Kühlung / Brandschutz<\/td><td>Infomaniak<\/td><td>Infomaniak-Dokumentation<\/td><\/tr><\/tbody><\/table>\n<p><strong>Massnahme:<\/strong> Aktuelle Sicherheits-/Zertifizierungsnachweise von Infomaniak einholen und als Evidenz dem Assessment beilegen.<\/p>\n<h2>6. Stand der Umsetzung / Lücken<\/h2>\n<table><thead><tr><th>Thema<\/th><th>Status<\/th><th>Massnahme<\/th><\/tr><\/thead><tbody><tr><td>Server-Härtung nach CIS<\/td><td>[ZU PRÜFEN]<\/td><td>Anwenden &amp; dokumentieren<\/td><\/tr><tr><td>WAF / IDS / IPS<\/td><td>[ZU PRÜFEN]<\/td><td>Bedarf klären, ggf. einführen<\/td><\/tr><tr><td>Infomaniak-Zertifikate als Evidenz<\/td><td>Offen<\/td><td>Einholen<\/td><\/tr><tr><td>Firewall-Konfiguration dokumentieren<\/td><td>[ZU PRÜFEN]<\/td><td>Festhalten<\/td><\/tr><\/tbody><\/table>", "text": "# netzwerk- und infrastruktursicherheit **dokumenttyp:** konzept **geltungsbereich:** netzwerk, server und rechenzentrumsanbindung der porta-plattform **version:** 1.0 **status:** entwurf zur internen freigabe **owner:** betrieb / devops **letzte aktualisierung:** 02.06.2026 **deckt ab (cacc):** 95, 96, 97, 98, 99 --- ## 1. härtung und basiskonfiguration (#95) | element | vorgabe | status | |---|---|---| | server-härtung (ubuntu) | nach anerkanntem standard (z. b. cis benchmark) | [zu prüfen: angewendet?] | | nicht benötigte dienste/ports deaktiviert | ja | [zu prüfen] | | regelmässige validierung der basiskonfiguration | mind. jährlich | [zu prüfen: etablieren] | ## 2. netzwerksegmentierung und mandantentrennung (#96) | element | beschreibung | status | |---|---|---| | trennung app / db | anwendung (`api.poweron.swiss`) und datenbank (`db.poweron.swiss`) auf getrennten hosts | umgesetzt | | trennung prod / int | produktiv- und integrationsumgebung getrennt | umgesetzt | | mandantentrennung (multi-tenancy) | logische trennung der kundendaten innerhalb der anwendung über mandate/berechtigungen | umgesetzt (logisch) | | netzwerksegmentierung (firewall-zonen) | [zu prüfen: wie ist der netzverkehr segmentiert?] | [zu prüfen] | > **hinweis für regulierte kunden:** die mandantentrennung erfolgt logisch (gemeinsame db-instanz, getrennte mandate/berechtigungen), nicht physisch pro kunde. das ist für saas üblich, sollte aber im assessment transparent gemacht werden. ## 3. netzwerkschutzmassnahmen (#97) | massnahme | status | |---|---| | firewall | [zu prüfen: infomaniak-firewall / os-firewall (ufw/iptables) konfiguriert?] | | web application firewall (waf) | [zu prüfen: vorhanden?] | | ids/ips (intrusion detection/prevention) | [zu prüfen: vorhanden?] | | tls-terminierung / reverse proxy | [zu prüfen: nginx o. ä.?] | ## 4. schutz vor netzwerkbasierten angriffen / ddos (#98) | massnahme | status | |---|---| | ddos-schutz | [zu prüfen: durch infomaniak bereitgestellt?] | | anomalie-erkennung im datenverkehr | [zu prüfen] | | rate-limiting | teilweise (z. b. export max. 2/min — siehe `datenbank-handling.md`) | ## 5. physische sicherheit und versorgung (#99) die physische sicherheit wird durch den rechenzentrumsbetreiber **infomaniak** (schweiz) gewährleistet: | element | zuständigkeit | nachweis | |---|---|---| | physische zutrittskontrolle | infomaniak | [zu prüfen: infomaniak-zertifikate/rz-doku beilegen, z. b. iso 27001] | | stromversorgung / usv / notstrom | infomaniak | infomaniak-rechenzentren (ch) | | kühlung / brandschutz | infomaniak | infomaniak-dokumentation | **massnahme:** aktuelle sicherheits-/zertifizierungsnachweise von infomaniak einholen und als evidenz dem assessment beilegen. ## 6. stand der umsetzung / lücken | thema | status | massnahme | |---|---|---| | server-härtung nach cis | [zu prüfen] | anwenden & dokumentieren | | waf / ids / ips | [zu prüfen] | bedarf klären, ggf. einführen | | infomaniak-zertifikate als evidenz | offen | einholen | | firewall-konfiguration dokumentieren | [zu prüfen] | festhalten | ", "nextReview": "", "overdueReview": false, "zuPruefen": ["1. Härtung und Basiskonfiguration (#95)", "1. Härtung und Basiskonfiguration (#95)", "1. Härtung und Basiskonfiguration (#95)", "2. Netzwerksegmentierung und Mandantentrennung (#96)", "3. Netzwerkschutzmassnahmen (#97)", "3. Netzwerkschutzmassnahmen (#97)", "3. Netzwerkschutzmassnahmen (#97)", "3. Netzwerkschutzmassnahmen (#97)", "4. Schutz vor netzwerkbasierten Angriffen / DDoS (#98)", "4. Schutz vor netzwerkbasierten Angriffen / DDoS (#98)", "5. Physische Sicherheit und Versorgung (#99)", "6. Stand der Umsetzung / Lücken", "6. Stand der Umsetzung / Lücken", "6. Stand der Umsetzung / Lücken"]}, {"id": "05_betrieb/13_Datenaufbewahrung_Loeschung_LegalHold.md", "path": "05_betrieb/13_Datenaufbewahrung_Loeschung_LegalHold.md", "chapter": "05_betrieb", "title": "Datenaufbewahrung, Löschung und Legal Hold", "filename": "13_Datenaufbewahrung_Loeschung_LegalHold.md", "meta": {}, "html": "<h1>Datenaufbewahrung, Löschung und Legal Hold<\/h1>\n<p><strong>Dokumenttyp:<\/strong> Konzept <strong>Geltungsbereich:<\/strong> Alle Kundendaten (Inhaltsdaten, Metadaten) der PORTA-Plattform <strong>Version:<\/strong> 1.0 <strong>Status:<\/strong> Entwurf zur internen Freigabe <strong>Owner:<\/strong> Datenschutzverantwortlicher / Betrieb <strong>Letzte Aktualisierung:<\/strong> 02.06.2026 <strong>Deckt ab (CACC):<\/strong> 1, 2, 38, 72 <strong>Verweist auf:<\/strong> <code>datenbank-handling.md<\/code><\/p>\n<hr>\n<h2>1. Legal Hold (#1)<\/h2>\n<p>Punkt #1 verlangt, dass der Kunde Inhalte (inkl. Metadaten) für rechtliche Zwecke aufbewahren und exportieren kann.<\/p>\n<table><thead><tr><th>Funktion<\/th><th>Status<\/th><\/tr><\/thead><tbody><tr><td>Daten eines Mandats vollständig exportieren (JSON)<\/td><td>Umgesetzt (Admin-UI / Script, siehe <code>datenbank-handling.md<\/code>)<\/td><\/tr><tr><td>Gezieltes „Einfrieren\" einzelner Datensätze gegen Löschung (Legal Hold)<\/td><td><strong>[ZU PRÜFEN: technisch vorhanden? Sonst als Massnahme / manuelle Prozedur dokumentieren]<\/strong><\/td><\/tr><tr><td>Forensischer Export in lesbarem Format<\/td><td>Umgesetzt (JSON)<\/td><\/tr><\/tbody><\/table>\n<p><strong>Manuelle Legal-Hold-Prozedur (Übergang, falls keine Funktion vorhanden):<\/strong> Auf Kundenanfrage wird ein vollständiger Export des betroffenen Mandats erstellt und gesichert abgelegt; betroffene Daten werden von automatischen Löschroutinen ausgenommen.<\/p>\n<h2>2. Aufbewahrung und Löschung pro Datenkategorie (#2)<\/h2>\n<p>Punkt #2 verlangt konfigurierbare Aufbewahrungsfristen pro Datenkategorie mit sicherer Löschung/Anonymisierung und Ausnahmemöglichkeit.<\/p>\n<table><thead><tr><th>Datenkategorie (DB)<\/th><th>Aufbewahrung<\/th><th>Löschung<\/th><\/tr><\/thead><tbody><tr><td>Chat-Konversationen (<code>poweron_chat<\/code>)<\/td><td>[ZU PRÜFEN / festlegen]<\/td><td>[ZU PRÜFEN: automatisch?]<\/td><\/tr><tr><td>Chatbot-Logs (<code>poweron_chatbot<\/code>)<\/td><td>[ZU PRÜFEN]<\/td><td>[ZU PRÜFEN]<\/td><\/tr><tr><td>RAG-Wissensdaten (<code>poweron_knowledge<\/code>)<\/td><td>bis Kunde löscht<\/td><td>manuell<\/td><\/tr><tr><td>Abrechnungsdaten (<code>poweron_billing<\/code>)<\/td><td>gesetzliche Frist (CH: 10 Jahre Geschäftsbücher)<\/td><td>nach Frist<\/td><\/tr><tr><td>Auth-/Login-Protokoll (<code>AuthEvent<\/code>)<\/td><td>[ZU PRÜFEN, Vorschlag: 12 Monate]<\/td><td>[ZU PRÜFEN]<\/td><\/tr><\/tbody><\/table>\n<blockquote><strong>Offener Punkt:<\/strong> Aktuell besteht <strong>keine automatische, kategorienbasierte Löschroutine<\/strong>. Daten bleiben, bis ein Mandat/Datensatz manuell gelöscht wird. <strong>Massnahme:<\/strong> Aufbewahrungsfristen je Kategorie definieren und — soweit möglich — automatisierte Löschung/Anonymisierung implementieren, mit Ausnahmemechanismus (Legal Hold).<\/blockquote>\n<h2>3. Löschung bei Vertragsende (#38)<\/h2>\n<p>Nach Vertragsende und erfolgter Datenmigration darf PowerOn keine lesbare Kopie der Berufsgeheimnisdaten mehr besitzen.<\/p>\n<table><thead><tr><th>Schritt<\/th><th>Vorgehen<\/th><th>Status<\/th><\/tr><\/thead><tbody><tr><td>Datenexport an Kunden<\/td><td>vollständiger JSON-Export<\/td><td>Umgesetzt<\/td><\/tr><tr><td>Löschung aus Produktiv-DB<\/td><td>Mandat und zugehörige Daten löschen<\/td><td>[ZU PRÜFEN: vollständige Löschroutine pro Mandat?]<\/td><\/tr><tr><td>Löschung aus Backups/Exports<\/td><td>Krypto-Löschung (Schlüssel vernichten) bzw. Löschung der Export-Dateien<\/td><td>[ZU PRÜFEN]<\/td><\/tr><tr><td>Löschung bei Subprozessoren<\/td><td>LLM-Provider: keine Speicherung (Zero-Retention)<\/td><td>[ZU PRÜFEN: vertraglich]<\/td><\/tr><tr><td>Löschbestätigung<\/td><td>schriftliche Bestätigung an Kunden<\/td><td>Neu — Vorlage erstellen<\/td><\/tr><\/tbody><\/table>\n<h2>4. Schlüssellöschung (#72)<\/h2>\n<p>Sichere Löschung von Verschlüsselungsschlüsseln am Ende des Lebenszyklus — siehe <code>04_Verschluesselung_und_Schluesselmanagement.md<\/code>.<\/p>\n<h2>5. Datenschutz-Hinweise (aus bestehender Doku)<\/h2>\n<p>Aus <code>datenbank-handling.md<\/code> übernommen und verbindlich: Export-Dateien enthalten alle Kundendaten, dürfen nicht auf unsicheren Speichern abgelegt werden und sind nach Gebrauch zu löschen. Zugriff auf Export/Import nur für SysAdmins, serverseitig geloggt.<\/p>\n<h2>6. Stand der Umsetzung / Lücken<\/h2>\n<table><thead><tr><th>Thema<\/th><th>Status<\/th><th>Massnahme<\/th><\/tr><\/thead><tbody><tr><td>Kategorienbasierte Aufbewahrungsfristen<\/td><td>Offen<\/td><td>Definieren<\/td><\/tr><tr><td>Automatische Löschung/Anonymisierung<\/td><td>Offen<\/td><td>Implementieren<\/td><\/tr><tr><td>Legal-Hold-Funktion<\/td><td>[ZU PRÜFEN]<\/td><td>Funktion oder manuelle Prozedur<\/td><\/tr><tr><td>Löschbestätigung bei Vertragsende<\/td><td>Neu<\/td><td>Vorlage erstellen<\/td><\/tr><\/tbody><\/table>", "text": "# datenaufbewahrung, löschung und legal hold **dokumenttyp:** konzept **geltungsbereich:** alle kundendaten (inhaltsdaten, metadaten) der porta-plattform **version:** 1.0 **status:** entwurf zur internen freigabe **owner:** datenschutzverantwortlicher / betrieb **letzte aktualisierung:** 02.06.2026 **deckt ab (cacc):** 1, 2, 38, 72 **verweist auf:** `datenbank-handling.md` --- ## 1. legal hold (#1) punkt #1 verlangt, dass der kunde inhalte (inkl. metadaten) für rechtliche zwecke aufbewahren und exportieren kann. | funktion | status | |---|---| | daten eines mandats vollständig exportieren (json) | umgesetzt (admin-ui / script, siehe `datenbank-handling.md`) | | gezieltes „einfrieren\" einzelner datensätze gegen löschung (legal hold) | **[zu prüfen: technisch vorhanden? sonst als massnahme / manuelle prozedur dokumentieren]** | | forensischer export in lesbarem format | umgesetzt (json) | **manuelle legal-hold-prozedur (übergang, falls keine funktion vorhanden):** auf kundenanfrage wird ein vollständiger export des betroffenen mandats erstellt und gesichert abgelegt; betroffene daten werden von automatischen löschroutinen ausgenommen. ## 2. aufbewahrung und löschung pro datenkategorie (#2) punkt #2 verlangt konfigurierbare aufbewahrungsfristen pro datenkategorie mit sicherer löschung/anonymisierung und ausnahmemöglichkeit. | datenkategorie (db) | aufbewahrung | löschung | |---|---|---| | chat-konversationen (`poweron_chat`) | [zu prüfen / festlegen] | [zu prüfen: automatisch?] | | chatbot-logs (`poweron_chatbot`) | [zu prüfen] | [zu prüfen] | | rag-wissensdaten (`poweron_knowledge`) | bis kunde löscht | manuell | | abrechnungsdaten (`poweron_billing`) | gesetzliche frist (ch: 10 jahre geschäftsbücher) | nach frist | | auth-/login-protokoll (`authevent`) | [zu prüfen, vorschlag: 12 monate] | [zu prüfen] | > **offener punkt:** aktuell besteht **keine automatische, kategorienbasierte löschroutine**. daten bleiben, bis ein mandat/datensatz manuell gelöscht wird. **massnahme:** aufbewahrungsfristen je kategorie definieren und — soweit möglich — automatisierte löschung/anonymisierung implementieren, mit ausnahmemechanismus (legal hold). ## 3. löschung bei vertragsende (#38) nach vertragsende und erfolgter datenmigration darf poweron keine lesbare kopie der berufsgeheimnisdaten mehr besitzen. | schritt | vorgehen | status | |---|---|---| | datenexport an kunden | vollständiger json-export | umgesetzt | | löschung aus produktiv-db | mandat und zugehörige daten löschen | [zu prüfen: vollständige löschroutine pro mandat?] | | löschung aus backups/exports | krypto-löschung (schlüssel vernichten) bzw. löschung der export-dateien | [zu prüfen] | | löschung bei subprozessoren | llm-provider: keine speicherung (zero-retention) | [zu prüfen: vertraglich] | | löschbestätigung | schriftliche bestätigung an kunden | neu — vorlage erstellen | ## 4. schlüssellöschung (#72) sichere löschung von verschlüsselungsschlüsseln am ende des lebenszyklus — siehe `04_verschluesselung_und_schluesselmanagement.md`. ## 5. datenschutz-hinweise (aus bestehender doku) aus `datenbank-handling.md` übernommen und verbindlich: export-dateien enthalten alle kundendaten, dürfen nicht auf unsicheren speichern abgelegt werden und sind nach gebrauch zu löschen. zugriff auf export/import nur für sysadmins, serverseitig geloggt. ## 6. stand der umsetzung / lücken | thema | status | massnahme | |---|---|---| | kategorienbasierte aufbewahrungsfristen | offen | definieren | | automatische löschung/anonymisierung | offen | implementieren | | legal-hold-funktion | [zu prüfen] | funktion oder manuelle prozedur | | löschbestätigung bei vertragsende | neu | vorlage erstellen | ", "nextReview": "", "overdueReview": false, "zuPruefen": ["1. Legal Hold (#1)", "2. Aufbewahrung und Löschung pro Datenkategorie (#2)", "2. Aufbewahrung und Löschung pro Datenkategorie (#2)", "2. Aufbewahrung und Löschung pro Datenkategorie (#2)", "3. Löschung bei Vertragsende (#38)", "3. Löschung bei Vertragsende (#38)", "3. Löschung bei Vertragsende (#38)", "6. Stand der Umsetzung / Lücken"]}, {"id": "05_betrieb/14_Exit_und_Transition.md", "path": "05_betrieb/14_Exit_und_Transition.md", "chapter": "05_betrieb", "title": "Exit- und Transitionsmanagement (Repatriierung)", "filename": "14_Exit_und_Transition.md", "meta": {}, "html": "<h1>Exit- und Transitionsmanagement (Repatriierung)<\/h1>\n<p><strong>Dokumenttyp:<\/strong> Konzept &amp; Plan <strong>Geltungsbereich:<\/strong> Beendigung der Dienstleistung und Rückführung von Daten/Funktionen <strong>Version:<\/strong> 1.0 <strong>Status:<\/strong> Entwurf zur internen Freigabe <strong>Owner:<\/strong> Geschäftsführung / Betrieb <strong>Letzte Aktualisierung:<\/strong> 02.06.2026 <strong>Deckt ab (CACC):<\/strong> 4, 5, 6, 22<\/p>\n<hr>\n<h2>1. Zweck<\/h2>\n<p>Dieser Plan stellt sicher, dass ein Kunde die ausgelagerten Funktionen geordnet zu sich oder einem Drittanbieter zurückführen (repatriieren) kann, ohne dass kritische Daten verloren gehen oder der Betrieb des Kunden gefährdet wird.<\/p>\n<h2>2. Kündigungs- und Vorlauffristen (#4, #22)<\/h2>\n<table><thead><tr><th>Element<\/th><th>Regelung (gemäss AGB-Entwurf)<\/th><\/tr><\/thead><tbody><tr><td>Ordentliche Kündigung<\/td><td>3 Monate zum Vertragsmonatsende<\/td><\/tr><tr><td>Ankündigung neuer Subunternehmer<\/td><td>30 Tage im Voraus, Widerspruchsrecht<\/td><\/tr><tr><td>Vorlauf für geordneten Rücktransport bei Kündigung durch PowerOn<\/td><td>ausreichend für Migration (siehe Weiterführungspflicht)<\/td><\/tr><\/tbody><\/table>\n<blockquote>Hinweis: Punkt #4 nennt als Richtwert ~6 Monate Vorlauf. Prüfen, ob 3 Monate Kündigungsfrist + Exportfenster + Weiterführungspflicht in Summe ausreichend sind, oder ob die Frist für regulierte Kunden vertraglich verlängert wird.<\/blockquote>\n<h2>3. Datenexport (#5)<\/h2>\n<p>Der Kunde kann <strong>jederzeit<\/strong> alle relevanten Daten exportieren:<\/p>\n<table><thead><tr><th>Datenart<\/th><th>Export<\/th><\/tr><\/thead><tbody><tr><td>Inhaltsdaten (Mandate, Chats, Dokumente, Wissensdaten)<\/td><td>vollständiger JSON-Export (Admin-UI/Script)<\/td><\/tr><tr><td>Zugriffs-/Protokolldaten<\/td><td>[ZU PRÜFEN: AuthEvent/Logs separat exportierbar?]<\/td><\/tr><tr><td>Format<\/td><td>JSON (offen, maschinenlesbar, kein proprietäres Lock-in)<\/td><\/tr><\/tbody><\/table>\n<p>Der Export ist unabhängig von Zahlungsstreitigkeiten verfügbar (vgl. AGB §18.4).<\/p>\n<h2>4. Weiterführungspflicht bei gescheiterter Repatriierung (#6)<\/h2>\n<p>Sollte die Rückführung scheitern, führt PowerOn die Leistung für einen definierten Zeitraum weiter, damit der Kunde einen zweiten Versuch unternehmen kann.<\/p>\n<table><thead><tr><th>Element<\/th><th>Regelung<\/th><\/tr><\/thead><tbody><tr><td>Weiterführungsdauer<\/td><td>mind. 6 Monate (gemäss AGB §11.3)<\/td><\/tr><tr><td>Bedingungen<\/td><td>zu bisherigen Vertragsbedingungen<\/td><\/tr><\/tbody><\/table>\n<h2>5. Transition-Ablauf (Runbook)<\/h2>\n<pre class=\"mermaid\">flowchart TD\n    A[Kündigung / Exit-Entscheid] --&gt; B[Exit-Plan aktivieren, Ansprechpartner benennen]\n    B --&gt; C[Vollständiger Datenexport JSON]\n    C --&gt; D[Übergabe an Kunde/Drittanbieter, Formatklärung]\n    D --&gt; E[Verifikation: Daten vollständig &amp; lesbar beim Kunden]\n    E --&gt; F{Repatriierung erfolgreich?}\n    F --&gt;|Nein| G[Weiterführung bis zu 6 Monate, 2. Versuch]\n    F --&gt;|Ja| H[Löschung bei PowerOn inkl. Backups]\n    H --&gt; I[Schriftliche Löschbestätigung an Kunden]<\/pre>\n<h2>6. Löschung nach Exit<\/h2>\n<p>Siehe <code>13_Datenaufbewahrung_Loeschung_LegalHold.md<\/code> Abschnitt 3. Nach erfolgreicher Migration: vollständige Löschung inkl. Backups und Bestätigung an den Kunden.<\/p>\n<h2>7. Stand der Umsetzung / Lücken<\/h2>\n<table><thead><tr><th>Thema<\/th><th>Status<\/th><th>Massnahme<\/th><\/tr><\/thead><tbody><tr><td>Exportfunktion<\/td><td>Umgesetzt<\/td><td>—<\/td><\/tr><tr><td>Export von Logs/Zugriffsdaten<\/td><td>[ZU PRÜFEN]<\/td><td>sicherstellen<\/td><\/tr><tr><td>Exit-Plan je regulierten Kunden<\/td><td>Neu<\/td><td>im Vertrag konkretisieren<\/td><\/tr><tr><td>Löschbestätigungs-Vorlage<\/td><td>Neu<\/td><td>erstellen<\/td><\/tr><\/tbody><\/table>", "text": "# exit- und transitionsmanagement (repatriierung) **dokumenttyp:** konzept & plan **geltungsbereich:** beendigung der dienstleistung und rückführung von daten/funktionen **version:** 1.0 **status:** entwurf zur internen freigabe **owner:** geschäftsführung / betrieb **letzte aktualisierung:** 02.06.2026 **deckt ab (cacc):** 4, 5, 6, 22 --- ## 1. zweck dieser plan stellt sicher, dass ein kunde die ausgelagerten funktionen geordnet zu sich oder einem drittanbieter zurückführen (repatriieren) kann, ohne dass kritische daten verloren gehen oder der betrieb des kunden gefährdet wird. ## 2. kündigungs- und vorlauffristen (#4, #22) | element | regelung (gemäss agb-entwurf) | |---|---| | ordentliche kündigung | 3 monate zum vertragsmonatsende | | ankündigung neuer subunternehmer | 30 tage im voraus, widerspruchsrecht | | vorlauf für geordneten rücktransport bei kündigung durch poweron | ausreichend für migration (siehe weiterführungspflicht) | > hinweis: punkt #4 nennt als richtwert ~6 monate vorlauf. prüfen, ob 3 monate kündigungsfrist + exportfenster + weiterführungspflicht in summe ausreichend sind, oder ob die frist für regulierte kunden vertraglich verlängert wird. ## 3. datenexport (#5) der kunde kann **jederzeit** alle relevanten daten exportieren: | datenart | export | |---|---| | inhaltsdaten (mandate, chats, dokumente, wissensdaten) | vollständiger json-export (admin-ui/script) | | zugriffs-/protokolldaten | [zu prüfen: authevent/logs separat exportierbar?] | | format | json (offen, maschinenlesbar, kein proprietäres lock-in) | der export ist unabhängig von zahlungsstreitigkeiten verfügbar (vgl. agb §18.4). ## 4. weiterführungspflicht bei gescheiterter repatriierung (#6) sollte die rückführung scheitern, führt poweron die leistung für einen definierten zeitraum weiter, damit der kunde einen zweiten versuch unternehmen kann. | element | regelung | |---|---| | weiterführungsdauer | mind. 6 monate (gemäss agb §11.3) | | bedingungen | zu bisherigen vertragsbedingungen | ## 5. transition-ablauf (runbook) ```mermaid flowchart td a[kündigung / exit-entscheid] --> b[exit-plan aktivieren, ansprechpartner benennen] b --> c[vollständiger datenexport json] c --> d[übergabe an kunde/drittanbieter, formatklärung] d --> e[verifikation: daten vollständig & lesbar beim kunden] e --> f{repatriierung erfolgreich?} f -->|nein| g[weiterführung bis zu 6 monate, 2. versuch] f -->|ja| h[löschung bei poweron inkl. backups] h --> i[schriftliche löschbestätigung an kunden] ``` ## 6. löschung nach exit siehe `13_datenaufbewahrung_loeschung_legalhold.md` abschnitt 3. nach erfolgreicher migration: vollständige löschung inkl. backups und bestätigung an den kunden. ## 7. stand der umsetzung / lücken | thema | status | massnahme | |---|---|---| | exportfunktion | umgesetzt | — | | export von logs/zugriffsdaten | [zu prüfen] | sicherstellen | | exit-plan je regulierten kunden | neu | im vertrag konkretisieren | | löschbestätigungs-vorlage | neu | erstellen | ", "nextReview": "", "overdueReview": false, "zuPruefen": ["3. Datenexport (#5)", "7. Stand der Umsetzung / Lücken"]}, {"id": "05_betrieb/15_Sichere_Softwareentwicklung_SDLC.md", "path": "05_betrieb/15_Sichere_Softwareentwicklung_SDLC.md", "chapter": "05_betrieb", "title": "Sichere Softwareentwicklung (Secure SDLC)", "filename": "15_Sichere_Softwareentwicklung_SDLC.md", "meta": {}, "html": "<h1>Sichere Softwareentwicklung (Secure SDLC)<\/h1>\n<p><strong>Dokumenttyp:<\/strong> Richtlinie <strong>Geltungsbereich:<\/strong> Entwicklung der PORTA-Plattform <strong>Version:<\/strong> 1.0 <strong>Status:<\/strong> Entwurf zur internen Freigabe <strong>Owner:<\/strong> Entwicklung <strong>Letzte Aktualisierung:<\/strong> 02.06.2026 <strong>Deckt ab (CACC):<\/strong> 100, 101, 102 <strong>Verweist auf:<\/strong> <code>feature_release_bugfix.md<\/code><\/p>\n<hr>\n<h2>1. Basis<\/h2>\n<p>Der grundlegende Entwicklungs- und Release-Prozess (Anforderungen, Tech-Workshop mit Architektur-/Schnittstellenanalyse, Branches, Code-Review, Staging-Verifikation, Release Notes) ist in <code>feature_release_bugfix.md<\/code> dokumentiert. Dieses Dokument ergänzt die <strong>sicherheitsspezifischen<\/strong> Aspekte gemäss #100–#102.<\/p>\n<h2>2. Sicherheit über den Entwicklungszyklus (#100)<\/h2>\n<table><thead><tr><th>Phase<\/th><th>Sicherheitsmassnahme<\/th><th>Status<\/th><\/tr><\/thead><tbody><tr><td>Anforderungen<\/td><td>Sicherheits-/Datenschutzanforderungen je Feature im Tech-Workshop berücksichtigen<\/td><td>[ZU PRÜFEN: explizit Teil des Workshops?]<\/td><\/tr><tr><td>Design<\/td><td>Bedrohungsbetrachtung bei Architekturänderungen (betroffene Daten, Schnittstellen, Drittdienste)<\/td><td>Teilweise (Tech-Workshop prüft Abhängigkeiten zu Drittdiensten)<\/td><\/tr><tr><td>Implementierung<\/td><td>Sichere Coding-Praktiken, Secrets nicht im Code (<code>.env<\/code>-Trennung)<\/td><td>Umgesetzt<\/td><\/tr><tr><td>Tests &amp; Review<\/td><td>Code-Review (Vier-Augen), Staging-Verifikation<\/td><td>Umgesetzt<\/td><\/tr><tr><td>Security-Tests<\/td><td>SAST/DAST/Dependency-Scan in der CI/CD-Pipeline<\/td><td><strong>[ZU PRÜFEN: in Forgejo-Pipeline integriert?]<\/strong><\/td><\/tr><\/tbody><\/table>\n<h2>3. Standards und Frameworks (#101)<\/h2>\n<table><thead><tr><th>Standard<\/th><th>Anwendung<\/th><th>Status<\/th><\/tr><\/thead><tbody><tr><td>OWASP Top 10<\/td><td>Berücksichtigung gängiger Web-Schwachstellen in Reviews<\/td><td>[ZU PRÜFEN: als Review-Checkliste verankert?]<\/td><\/tr><tr><td>NIST / anerkannte Frameworks<\/td><td>Orientierung<\/td><td>[ZU PRÜFEN]<\/td><\/tr><\/tbody><\/table>\n<p><strong>Massnahme:<\/strong> OWASP-Top-10-Checkliste als fester Bestandteil des Code-Reviews aufnehmen; ggf. automatisiertes SAST-Tool (z. B. Bandit für Python) in die Pipeline integrieren.<\/p>\n<h2>4. Keine Produktivdaten in Entwicklung/Test (#102) — WICHTIG<\/h2>\n<blockquote><strong>Direkter Konflikt mit aktueller Praxis:<\/strong> <code>datenbank-handling.md<\/code> (Abschnitt 3) beschreibt das Übertragen von <strong>Produktionsdaten auf die Testumgebung<\/strong> als regulären Use-Case. Punkt #102 verlangt jedoch ausdrücklich, dass <strong>produktive, dem Berufsgeheimnis unterliegende Daten NICHT für Entwicklung und Test<\/strong> verwendet werden.<\/blockquote>\n<p><strong>Erforderliche Massnahme (Entscheidung nötig):<\/strong><\/p>\n<table><thead><tr><th>Option<\/th><th>Beschreibung<\/th><\/tr><\/thead><tbody><tr><td>A — Verbot + Anonymisierung<\/td><td>Prod→Int-Migration nur mit vollständiger Anonymisierung/Pseudonymisierung der Inhaltsdaten. Klartext-Berufsgeheimnisdaten nie auf Int.<\/td><\/tr><tr><td>B — Synthetische Testdaten<\/td><td>Entwicklung/Test ausschliesslich mit synthetischen Testdaten (<code>poweron_test<\/code> ist bereits vom Export ausgeschlossen).<\/td><\/tr><tr><td>C — Streng kontrollierte Ausnahme<\/td><td>Prod-Daten auf Int nur in eng begrenzten, protokollierten Ausnahmefällen mit Kundengenehmigung.<\/td><\/tr><\/tbody><\/table>\n<p><strong>Empfehlung für FINMA-Kontext:<\/strong> Option A oder B. Die aktuelle Beschreibung in <code>datenbank-handling.md<\/code> ist entsprechend anzupassen.<\/p>\n<h2>5. Stand der Umsetzung / Lücken<\/h2>\n<table><thead><tr><th>Thema<\/th><th>Status<\/th><th>Massnahme<\/th><\/tr><\/thead><tbody><tr><td>SAST/DAST in Pipeline<\/td><td>[ZU PRÜFEN]<\/td><td>Integrieren<\/td><\/tr><tr><td>OWASP-Review-Checkliste<\/td><td>[ZU PRÜFEN]<\/td><td>Verankern<\/td><\/tr><tr><td>Prod-Daten in Test (#102)<\/td><td><strong>Konflikt<\/strong><\/td><td>Praxis ändern (Anonymisierung/synthetische Daten) + Doku anpassen<\/td><\/tr><\/tbody><\/table>", "text": "# sichere softwareentwicklung (secure sdlc) **dokumenttyp:** richtlinie **geltungsbereich:** entwicklung der porta-plattform **version:** 1.0 **status:** entwurf zur internen freigabe **owner:** entwicklung **letzte aktualisierung:** 02.06.2026 **deckt ab (cacc):** 100, 101, 102 **verweist auf:** `feature_release_bugfix.md` --- ## 1. basis der grundlegende entwicklungs- und release-prozess (anforderungen, tech-workshop mit architektur-/schnittstellenanalyse, branches, code-review, staging-verifikation, release notes) ist in `feature_release_bugfix.md` dokumentiert. dieses dokument ergänzt die **sicherheitsspezifischen** aspekte gemäss #100–#102. ## 2. sicherheit über den entwicklungszyklus (#100) | phase | sicherheitsmassnahme | status | |---|---|---| | anforderungen | sicherheits-/datenschutzanforderungen je feature im tech-workshop berücksichtigen | [zu prüfen: explizit teil des workshops?] | | design | bedrohungsbetrachtung bei architekturänderungen (betroffene daten, schnittstellen, drittdienste) | teilweise (tech-workshop prüft abhängigkeiten zu drittdiensten) | | implementierung | sichere coding-praktiken, secrets nicht im code (`.env`-trennung) | umgesetzt | | tests & review | code-review (vier-augen), staging-verifikation | umgesetzt | | security-tests | sast/dast/dependency-scan in der ci/cd-pipeline | **[zu prüfen: in forgejo-pipeline integriert?]** | ## 3. standards und frameworks (#101) | standard | anwendung | status | |---|---|---| | owasp top 10 | berücksichtigung gängiger web-schwachstellen in reviews | [zu prüfen: als review-checkliste verankert?] | | nist / anerkannte frameworks | orientierung | [zu prüfen] | **massnahme:** owasp-top-10-checkliste als fester bestandteil des code-reviews aufnehmen; ggf. automatisiertes sast-tool (z. b. bandit für python) in die pipeline integrieren. ## 4. keine produktivdaten in entwicklung/test (#102) — wichtig > **direkter konflikt mit aktueller praxis:** `datenbank-handling.md` (abschnitt 3) beschreibt das übertragen von **produktionsdaten auf die testumgebung** als regulären use-case. punkt #102 verlangt jedoch ausdrücklich, dass **produktive, dem berufsgeheimnis unterliegende daten nicht für entwicklung und test** verwendet werden. **erforderliche massnahme (entscheidung nötig):** | option | beschreibung | |---|---| | a — verbot + anonymisierung | prod→int-migration nur mit vollständiger anonymisierung/pseudonymisierung der inhaltsdaten. klartext-berufsgeheimnisdaten nie auf int. | | b — synthetische testdaten | entwicklung/test ausschliesslich mit synthetischen testdaten (`poweron_test` ist bereits vom export ausgeschlossen). | | c — streng kontrollierte ausnahme | prod-daten auf int nur in eng begrenzten, protokollierten ausnahmefällen mit kundengenehmigung. | **empfehlung für finma-kontext:** option a oder b. die aktuelle beschreibung in `datenbank-handling.md` ist entsprechend anzupassen. ## 5. stand der umsetzung / lücken | thema | status | massnahme | |---|---|---| | sast/dast in pipeline | [zu prüfen] | integrieren | | owasp-review-checkliste | [zu prüfen] | verankern | | prod-daten in test (#102) | **konflikt** | praxis ändern (anonymisierung/synthetische daten) + doku anpassen | ", "nextReview": "", "overdueReview": false, "zuPruefen": ["2. Sicherheit über den Entwicklungszyklus (#100)", "2. Sicherheit über den Entwicklungszyklus (#100)", "3. Standards und Frameworks (#101)", "3. Standards und Frameworks (#101)", "5. Stand der Umsetzung / Lücken", "5. Stand der Umsetzung / Lücken"]}, {"id": "05_betrieb/16_Kapazitaetsmanagement.md", "path": "05_betrieb/16_Kapazitaetsmanagement.md", "chapter": "05_betrieb", "title": "Kapazitätsmanagement", "filename": "16_Kapazitaetsmanagement.md", "meta": {}, "html": "<h1>Kapazitätsmanagement<\/h1>\n<p><strong>Dokumenttyp:<\/strong> Prozess <strong>Geltungsbereich:<\/strong> Personal- und IT-Ressourcen der PORTA-Plattform <strong>Version:<\/strong> 1.0 <strong>Status:<\/strong> Entwurf zur internen Freigabe <strong>Owner:<\/strong> Geschäftsführung / Betrieb <strong>Letzte Aktualisierung:<\/strong> 02.06.2026 <strong>Deckt ab (CACC):<\/strong> 80<\/p>\n<hr>\n<h2>1. Zweck<\/h2>\n<p>Sicherstellung ausreichender Personal- und IT-Kapazitäten für eine kontinuierliche, vereinbarungsgemässe Leistungserbringung.<\/p>\n<h2>2. IT-Ressourcen-Kapazität<\/h2>\n<table><thead><tr><th>Ressource<\/th><th>Überwachung<\/th><th>Status<\/th><\/tr><\/thead><tbody><tr><td>Server-Auslastung (CPU/RAM/Disk)<\/td><td>[ZU PRÜFEN: Monitoring vorhanden?]<\/td><td>[ZU PRÜFEN]<\/td><\/tr><tr><td>Datenbank (Grösse, Verbindungen)<\/td><td>Infomaniak Managed DB Metriken<\/td><td>[ZU PRÜFEN]<\/td><\/tr><tr><td>LLM-Provider-Kontingente (Rate Limits, Token-Budget)<\/td><td>Provider-Dashboards<\/td><td>[ZU PRÜFEN]<\/td><\/tr><tr><td>Speicher (Backups/Exports)<\/td><td>manuell<\/td><td>[ZU PRÜFEN]<\/td><\/tr><\/tbody><\/table>\n<p><strong>Massnahme:<\/strong> Schwellwerte definieren (z. B. Disk &gt; 80 %, DB-Verbindungen &gt; 80 %) und Alerting einrichten (gemeinsam mit Dok 11).<\/p>\n<h2>3. Personal-Kapazität (kleines Team)<\/h2>\n<p>Bei 2–5 Personen ist die Personalkapazität ein erhöhtes Risiko (Schlüsselpersonen-Abhängigkeit).<\/p>\n<table><thead><tr><th>Risiko<\/th><th>Kompensierende Massnahme<\/th><\/tr><\/thead><tbody><tr><td>Ausfall einer Schlüsselperson<\/td><td>Dokumentation aller kritischen Prozesse (dieses Wiki), Zugangs-Notfallregelung<\/td><\/tr><tr><td>Wissenskonzentration<\/td><td>Vier-Augen-Prinzip, gemeinsame Reviews, dokumentierte Runbooks<\/td><\/tr><tr><td>Bei Wachstum<\/td><td>Kapazitätsplanung bei Neukunden-Onboarding<\/td><\/tr><\/tbody><\/table>\n<p><strong>[ZU PRÜFEN: Gibt es eine Vertretungs-/Notfallregelung für den alleinigen Server-Zugang?]<\/strong><\/p>\n<h2>4. Kapazitäts-Review<\/h2>\n<table><thead><tr><th>Aktivität<\/th><th>Häufigkeit<\/th><\/tr><\/thead><tbody><tr><td>Review IT-Auslastung<\/td><td>mind. quartalsweise<\/td><\/tr><tr><td>Review Personal-/Projektlast<\/td><td>laufend / bei Neukunden<\/td><\/tr><tr><td>Skalierungsentscheid Infrastruktur<\/td><td>bei Bedarf (Infomaniak skalierbar)<\/td><\/tr><\/tbody><\/table>\n<h2>5. Stand der Umsetzung / Lücken<\/h2>\n<table><thead><tr><th>Thema<\/th><th>Status<\/th><th>Massnahme<\/th><\/tr><\/thead><tbody><tr><td>Ressourcen-Monitoring mit Schwellwerten<\/td><td>[ZU PRÜFEN]<\/td><td>Einrichten<\/td><\/tr><tr><td>Schlüsselpersonen-Vertretung<\/td><td>[ZU PRÜFEN]<\/td><td>Notfallregelung dokumentieren<\/td><\/tr><tr><td>Quartals-Review<\/td><td>Neu<\/td><td>etablieren<\/td><\/tr><\/tbody><\/table>", "text": "# kapazitätsmanagement **dokumenttyp:** prozess **geltungsbereich:** personal- und it-ressourcen der porta-plattform **version:** 1.0 **status:** entwurf zur internen freigabe **owner:** geschäftsführung / betrieb **letzte aktualisierung:** 02.06.2026 **deckt ab (cacc):** 80 --- ## 1. zweck sicherstellung ausreichender personal- und it-kapazitäten für eine kontinuierliche, vereinbarungsgemässe leistungserbringung. ## 2. it-ressourcen-kapazität | ressource | überwachung | status | |---|---|---| | server-auslastung (cpu/ram/disk) | [zu prüfen: monitoring vorhanden?] | [zu prüfen] | | datenbank (grösse, verbindungen) | infomaniak managed db metriken | [zu prüfen] | | llm-provider-kontingente (rate limits, token-budget) | provider-dashboards | [zu prüfen] | | speicher (backups/exports) | manuell | [zu prüfen] | **massnahme:** schwellwerte definieren (z. b. disk > 80 %, db-verbindungen > 80 %) und alerting einrichten (gemeinsam mit dok 11). ## 3. personal-kapazität (kleines team) bei 2–5 personen ist die personalkapazität ein erhöhtes risiko (schlüsselpersonen-abhängigkeit). | risiko | kompensierende massnahme | |---|---| | ausfall einer schlüsselperson | dokumentation aller kritischen prozesse (dieses wiki), zugangs-notfallregelung | | wissenskonzentration | vier-augen-prinzip, gemeinsame reviews, dokumentierte runbooks | | bei wachstum | kapazitätsplanung bei neukunden-onboarding | **[zu prüfen: gibt es eine vertretungs-/notfallregelung für den alleinigen server-zugang?]** ## 4. kapazitäts-review | aktivität | häufigkeit | |---|---| | review it-auslastung | mind. quartalsweise | | review personal-/projektlast | laufend / bei neukunden | | skalierungsentscheid infrastruktur | bei bedarf (infomaniak skalierbar) | ## 5. stand der umsetzung / lücken | thema | status | massnahme | |---|---|---| | ressourcen-monitoring mit schwellwerten | [zu prüfen] | einrichten | | schlüsselpersonen-vertretung | [zu prüfen] | notfallregelung dokumentieren | | quartals-review | neu | etablieren | ", "nextReview": "", "overdueReview": false, "zuPruefen": ["2. IT-Ressourcen-Kapazität", "2. IT-Ressourcen-Kapazität", "2. IT-Ressourcen-Kapazität", "2. IT-Ressourcen-Kapazität", "3. Personal-Kapazität (kleines Team)", "5. Stand der Umsetzung / Lücken", "5. Stand der Umsetzung / Lücken"]}, {"id": "05_betrieb/17_Subunternehmer_Management.md", "path": "05_betrieb/17_Subunternehmer_Management.md", "chapter": "05_betrieb", "title": "Subunternehmer- und Unterauftragsverarbeiter-Management", "filename": "17_Subunternehmer_Management.md", "meta": {}, "html": "<h1>Subunternehmer- und Unterauftragsverarbeiter-Management<\/h1>\n<p><strong>Dokumenttyp:<\/strong> Prozess <strong>Geltungsbereich:<\/strong> Alle externen Dienste und Unterauftragsverarbeiter <strong>Version:<\/strong> 1.0 <strong>Status:<\/strong> Entwurf zur internen Freigabe <strong>Owner:<\/strong> Patrick Motsch (Drittdienst-Verantwortlicher) <strong>Letzte Aktualisierung:<\/strong> 02.06.2026 <strong>Deckt ab (CACC):<\/strong> 16, 31, 48, 53 <strong>Verweist auf:<\/strong> <code>drittanbieter-inventar.md<\/code><\/p>\n<hr>\n<h2>1. Basis<\/h2>\n<p>Das vollständige Inventar aller Drittdienste ist in <code>drittanbieter-inventar.md<\/code> dokumentiert (Verantwortlicher: Patrick Motsch). Dieses Dokument ergänzt die <strong>Compliance-Sicht<\/strong>: Datenschutz-Status, Datenstandort, Widerspruchsrecht und Sanktionsprüfung.<\/p>\n<h2>2. Compliance-Ergänzung zum Inventar (#48, #31)<\/h2>\n<p>Für jeden Unterauftragsverarbeiter, der Inhaltsdaten verarbeitet, sind folgende Angaben zu führen (Ergänzung zum bestehenden Inventar):<\/p>\n<table><thead><tr><th>Anbieter<\/th><th>Rolle<\/th><th>Datenstandort<\/th><th>AVV/DPA<\/th><th>EU-SCC (falls Drittland)<\/th><th>Zero-Retention<\/th><\/tr><\/thead><tbody><tr><td>OpenAI (USA)<\/td><td>LLM (primär)<\/td><td>USA<\/td><td>[ZU PRÜFEN]<\/td><td>[ZU PRÜFEN]<\/td><td>[ZU PRÜFEN: Enterprise/Opt-out]<\/td><\/tr><tr><td>Anthropic (USA)<\/td><td>LLM (alternativ)<\/td><td>USA<\/td><td>[ZU PRÜFEN]<\/td><td>[ZU PRÜFEN]<\/td><td>[ZU PRÜFEN]<\/td><\/tr><tr><td>Mistral (EU/FR)<\/td><td>LLM (alternativ)<\/td><td>EU<\/td><td>[ZU PRÜFEN]<\/td><td>n/a (EU)<\/td><td>[ZU PRÜFEN]<\/td><\/tr><tr><td>Perplexity (USA)<\/td><td>LLM + Websuche<\/td><td>USA<\/td><td>[ZU PRÜFEN]<\/td><td>[ZU PRÜFEN]<\/td><td>[ZU PRÜFEN]<\/td><\/tr><tr><td>Tavily (USA)<\/td><td>AI-Websuche<\/td><td>USA<\/td><td>[ZU PRÜFEN]<\/td><td>[ZU PRÜFEN]<\/td><td>n/a<\/td><\/tr><tr><td>Infomaniak (CH)<\/td><td>Hosting/DB<\/td><td>Schweiz<\/td><td>[ZU PRÜFEN]<\/td><td>n/a (CH)<\/td><td>n/a<\/td><\/tr><tr><td>Google Cloud (USA)<\/td><td>STT/TTS/Translate<\/td><td>USA<\/td><td>[ZU PRÜFEN]<\/td><td>[ZU PRÜFEN]<\/td><td>[ZU PRÜFEN]<\/td><\/tr><tr><td>Microsoft Azure (CH/EU)<\/td><td>Auth + E-Mail (CH-Region)<\/td><td>CH/EU<\/td><td>[ZU PRÜFEN]<\/td><td>[ZU PRÜFEN]<\/td><td>n/a<\/td><\/tr><tr><td>Stripe (USA/IE)<\/td><td>Payment<\/td><td>USA/EU<\/td><td>[ZU PRÜFEN]<\/td><td>[ZU PRÜFEN]<\/td><td>n/a<\/td><\/tr><tr><td>Twilio (USA)<\/td><td>SMS<\/td><td>USA<\/td><td>[ZU PRÜFEN]<\/td><td>[ZU PRÜFEN]<\/td><td>n/a<\/td><\/tr><\/tbody><\/table>\n<blockquote><strong>Wichtig für FINMA-Kunden:<\/strong> Inhaltsdaten gehen an den primären LLM-Provider OpenAI (USA). Für regulierte Kunden ist zu klären, ob (a) ausreichende vertragliche Absicherung (AVV + SCC + Zero-Retention) vorliegt und/oder (b) ein auf EU/CH-LLM beschränkter Betrieb angeboten wird (z. B. Mistral EU oder CH-gehostetes Modell).<\/blockquote>\n<h2>3. Widerspruchsrecht des Kunden (#16)<\/h2>\n<table><thead><tr><th>Element<\/th><th>Regelung<\/th><\/tr><\/thead><tbody><tr><td>Information über neuen wesentlichen Subunternehmer<\/td><td>30 Tage im Voraus (gemäss AGB §12.2)<\/td><\/tr><tr><td>Widerspruchsfrist Kunde<\/td><td>14 Tage, aus sachlichem Grund<\/td><\/tr><tr><td>Folge bei berechtigtem Widerspruch<\/td><td>ausserordentliches Kündigungsrecht des Kunden<\/td><\/tr><\/tbody><\/table>\n<h2>4. Weitergabe der Pflichten (#53)<\/h2>\n<p>Alle Subunternehmer werden vertraglich auf gleichwertige Sicherheits-, Datenschutz- und Vertraulichkeitspflichten verpflichtet. Kunden können diese bei Bedarf (mittelbar) auditieren.<\/p>\n<p><strong>[ZU PRÜFEN: Liegen die DPAs/AVVs der grossen Provider (OpenAI, Microsoft, Google, Stripe) abgelegt vor? Diese sind als Evidenz für das Assessment zentral.]<\/strong><\/p>\n<h2>5. Sanktionsprüfung<\/h2>\n<p>Subunternehmer werden vor Einsatz und periodisch gegen einschlägige Sanktionslisten geprüft. <strong>[ZU PRÜFEN: erfolgt das? Sonst einführen.]<\/strong><\/p>\n<h2>6. Pflege<\/h2>\n<p>Das Inventar wird bei jeder Änderung (neuer/entfallender Dienst) aktualisiert; Verantwortlich: Patrick Motsch. Review mindestens jährlich.<\/p>\n<h2>7. Stand der Umsetzung / Lücken<\/h2>\n<table><thead><tr><th>Thema<\/th><th>Status<\/th><th>Massnahme<\/th><\/tr><\/thead><tbody><tr><td>AVV/SCC/Zero-Retention je Provider<\/td><td>[ZU PRÜFEN]<\/td><td>Verträge prüfen &amp; ablegen<\/td><\/tr><tr><td>Compliance-Spalten im Inventar<\/td><td>Neu<\/td><td>ergänzen<\/td><\/tr><tr><td>Sanktionsprüfung<\/td><td>[ZU PRÜFEN]<\/td><td>einführen<\/td><\/tr><tr><td>EU/CH-only-LLM-Option für FINMA-Kunden<\/td><td>Offen<\/td><td>Entscheidung<\/td><\/tr><\/tbody><\/table>", "text": "# subunternehmer- und unterauftragsverarbeiter-management **dokumenttyp:** prozess **geltungsbereich:** alle externen dienste und unterauftragsverarbeiter **version:** 1.0 **status:** entwurf zur internen freigabe **owner:** patrick motsch (drittdienst-verantwortlicher) **letzte aktualisierung:** 02.06.2026 **deckt ab (cacc):** 16, 31, 48, 53 **verweist auf:** `drittanbieter-inventar.md` --- ## 1. basis das vollständige inventar aller drittdienste ist in `drittanbieter-inventar.md` dokumentiert (verantwortlicher: patrick motsch). dieses dokument ergänzt die **compliance-sicht**: datenschutz-status, datenstandort, widerspruchsrecht und sanktionsprüfung. ## 2. compliance-ergänzung zum inventar (#48, #31) für jeden unterauftragsverarbeiter, der inhaltsdaten verarbeitet, sind folgende angaben zu führen (ergänzung zum bestehenden inventar): | anbieter | rolle | datenstandort | avv/dpa | eu-scc (falls drittland) | zero-retention | |---|---|---|---|---|---| | openai (usa) | llm (primär) | usa | [zu prüfen] | [zu prüfen] | [zu prüfen: enterprise/opt-out] | | anthropic (usa) | llm (alternativ) | usa | [zu prüfen] | [zu prüfen] | [zu prüfen] | | mistral (eu/fr) | llm (alternativ) | eu | [zu prüfen] | n/a (eu) | [zu prüfen] | | perplexity (usa) | llm + websuche | usa | [zu prüfen] | [zu prüfen] | [zu prüfen] | | tavily (usa) | ai-websuche | usa | [zu prüfen] | [zu prüfen] | n/a | | infomaniak (ch) | hosting/db | schweiz | [zu prüfen] | n/a (ch) | n/a | | google cloud (usa) | stt/tts/translate | usa | [zu prüfen] | [zu prüfen] | [zu prüfen] | | microsoft azure (ch/eu) | auth + e-mail (ch-region) | ch/eu | [zu prüfen] | [zu prüfen] | n/a | | stripe (usa/ie) | payment | usa/eu | [zu prüfen] | [zu prüfen] | n/a | | twilio (usa) | sms | usa | [zu prüfen] | [zu prüfen] | n/a | > **wichtig für finma-kunden:** inhaltsdaten gehen an den primären llm-provider openai (usa). für regulierte kunden ist zu klären, ob (a) ausreichende vertragliche absicherung (avv + scc + zero-retention) vorliegt und/oder (b) ein auf eu/ch-llm beschränkter betrieb angeboten wird (z. b. mistral eu oder ch-gehostetes modell). ## 3. widerspruchsrecht des kunden (#16) | element | regelung | |---|---| | information über neuen wesentlichen subunternehmer | 30 tage im voraus (gemäss agb §12.2) | | widerspruchsfrist kunde | 14 tage, aus sachlichem grund | | folge bei berechtigtem widerspruch | ausserordentliches kündigungsrecht des kunden | ## 4. weitergabe der pflichten (#53) alle subunternehmer werden vertraglich auf gleichwertige sicherheits-, datenschutz- und vertraulichkeitspflichten verpflichtet. kunden können diese bei bedarf (mittelbar) auditieren. **[zu prüfen: liegen die dpas/avvs der grossen provider (openai, microsoft, google, stripe) abgelegt vor? diese sind als evidenz für das assessment zentral.]** ## 5. sanktionsprüfung subunternehmer werden vor einsatz und periodisch gegen einschlägige sanktionslisten geprüft. **[zu prüfen: erfolgt das? sonst einführen.]** ## 6. pflege das inventar wird bei jeder änderung (neuer/entfallender dienst) aktualisiert; verantwortlich: patrick motsch. review mindestens jährlich. ## 7. stand der umsetzung / lücken | thema | status | massnahme | |---|---|---| | avv/scc/zero-retention je provider | [zu prüfen] | verträge prüfen & ablegen | | compliance-spalten im inventar | neu | ergänzen | | sanktionsprüfung | [zu prüfen] | einführen | | eu/ch-only-llm-option für finma-kunden | offen | entscheidung | ", "nextReview": "", "overdueReview": false, "zuPruefen": ["2. Compliance-Ergänzung zum Inventar (#48, #31)", "2. Compliance-Ergänzung zum Inventar (#48, #31)", "2. Compliance-Ergänzung zum Inventar (#48, #31)", "2. Compliance-Ergänzung zum Inventar (#48, #31)", "2. Compliance-Ergänzung zum Inventar (#48, #31)", "2. Compliance-Ergänzung zum Inventar (#48, #31)", "2. Compliance-Ergänzung zum Inventar (#48, #31)", "2. Compliance-Ergänzung zum Inventar (#48, #31)", "2. Compliance-Ergänzung zum Inventar (#48, #31)", "2. Compliance-Ergänzung zum Inventar (#48, #31)", "4. Weitergabe der Pflichten (#53)", "5. Sanktionsprüfung", "7. Stand der Umsetzung / Lücken", "7. Stand der Umsetzung / Lücken"]}, {"id": "05_betrieb/18_Analyse_Recht_und_BestPractice.md", "path": "05_betrieb/18_Analyse_Recht_und_BestPractice.md", "chapter": "05_betrieb", "title": "Analyse: Rechtliche Aspekte und Best Practices", "filename": "18_Analyse_Recht_und_BestPractice.md", "meta": {}, "html": "<h1>Analyse: Rechtliche Aspekte und Best Practices<\/h1>\n<p><strong>Dokumenttyp:<\/strong> Befund- und Risikobericht (intern) <strong>Geltungsbereich:<\/strong> Gesamtes e-compliance-Wiki (PORTA-Plattform) <strong>Version:<\/strong> 1.0 <strong>Stand:<\/strong> 01.02.2026 <strong>Erstellt für:<\/strong> PowerOn AG, Birmensdorferstrasse 94, 8003 Zürich (CHE-491.960.195) <strong>Ansprechpartner:<\/strong> Patrick Motsch — p.motsch@poweron.swiss<\/p>\n<blockquote><strong>Hinweis:<\/strong> Dieser Bericht ersetzt keine anwaltliche Beratung. Er dokumentiert den Stand der Wiki-Dokumentation nach der Firmendaten-Anpassung und benennt Lücken sowie Widersprüche zwischen vertraglichen Zusicherungen (AGB) und beschriebenem Umsetzungsstand.<\/blockquote>\n<hr>\n<h2>1. Durchgeführte Anpassungen (01.02.2026)<\/h2>\n<table><thead><tr><th>Massnahme<\/th><th>Umfang<\/th><\/tr><\/thead><tbody><tr><td>Rechtsträger<\/td><td><code>PowerON GmbH<\/code> → <strong>PowerOn AG<\/strong> (CHE-491.960.195)<\/td><\/tr><tr><td>Markenschreibweise<\/td><td><code>PowerON<\/code> → <strong>PowerOn<\/strong> in AGB und allen <code>legal/<\/code>-Dokumenten<\/td><\/tr><tr><td>Stammdaten AGB §1.1<\/td><td>Birmensdorferstrasse 94, 8003 Zürich, p.motsch@poweron.swiss<\/td><\/tr><tr><td>Gerichtsstand AGB §23.2<\/td><td>Zürich, Schweiz<\/td><\/tr><tr><td>Datumsfelder AGB<\/td><td>Stand / Gilt ab / Anhänge: <strong>01.02.2026<\/strong>; nächste Überprüfung: <strong>01.02.2027<\/strong><\/td><\/tr><tr><td>Ansprechpartner/Rollen<\/td><td>Patrick Motsch in offenen Namens-/Kontaktfeldern (Dok. 01, 02, 06, 07)<\/td><\/tr><\/tbody><\/table>\n<p><strong>Nicht geändert (bewusst):<\/strong> Inhaltliche AGB-Zusicherungen; technische <code>[ZU PRÜFEN]<\/code>-Fakten (At-Rest, Pentest-Nachweis etc.). MFA auf Admin-/Server-Zugängen seit Juni 2026 umgesetzt.<\/p>\n<hr>\n<h2>2. Rechtlicher Rahmen<\/h2>\n<h3>2.1 Anwendbares Recht<\/h3>\n<table><thead><tr><th>Rechtsgebiet<\/th><th>Relevanz in der Dokumentation<\/th><\/tr><\/thead><tbody><tr><td><strong>Schweizer DSG<\/strong> (revDSG)<\/td><td>Primärrecht für Daten in der Schweiz; AGB §6.4, security-overview Kap. 9.2<\/td><\/tr><tr><td><strong>DSGVO<\/strong><\/td><td>Anwendbar bei EU-Betroffenen / grenzüberschreitender Verarbeitung; Betroffenenrechte in security-overview<\/td><\/tr><tr><td><strong>FINMA-Rundschreiben 2018/3, 2023/1<\/strong><\/td><td>Auslagerung an Cloud/IT-Dienstleister; CACC-Mapping in <code>00_README_Prozessuebersicht.md<\/code><\/td><\/tr><tr><td><strong>Bankgeheimnis (Art. 47 BankG)<\/strong><\/td><td>AGB §13.2; erhöhter Schutz für Berufsgeheimnisdaten<\/td><\/tr><tr><td><strong>Berufsgeheimnis StGB (Art. 321)<\/strong><\/td><td>Medizinische/sonstige Berufsgeheimnisse; gleiche Behandlung wie Bankdaten in AGB<\/td><\/tr><tr><td><strong>Schweizer Obligationenrecht / ZGB<\/strong><\/td><td>B2B-Verträge, AGB-Geltung, Gerichtsstand Zürich<\/td><\/tr><\/tbody><\/table>\n<h3>2.2 Vertragshierarchie (AGB §1.4)<\/h3>\n<ol><li>Individueller Dienstleistungsvertrag<\/li><li>AVV (Auftragsverarbeitungsvertrag)<\/li><li>SLA<\/li><li>AGB<\/li><li>Anhänge A, B, C<\/li><\/ol>\n<p><strong>Empfehlung:<\/strong> Für FINMA-regulierte Kunden immer individuellen Vertrag + AVV abschliessen; AGB allein genügt regulatorisch nicht.<\/p>\n<h3>2.3 Auftragsverarbeitung und Drittlandtransfers<\/h3>\n<ul><li><strong>Speicherung Inhaltsdaten:<\/strong> Schweiz (Infomaniak) — konsistent dokumentiert.<\/li><li><strong>LLM-Verarbeitung:<\/strong> Primär OpenAI (USA) — temporärer Datenabfluss; erfordert AVV/DPA, EU-SCC, TIA, Zero-Data-Retention (<code>17_Subunternehmer_Management.md<\/code>, AGB §7.2).<\/li><li><strong>Neutralisierung:<\/strong> Technisches Modul reduziert PII vor externem LLM-Call (<code>neutralisierung-detail.md<\/code>); nicht standardmässig für alle Tenants aktiv (<code>security-overview.md<\/code> Kap. 7.6).<\/li><\/ul>\n<h3>2.4 Melde- und Auditpflichten<\/h3>\n<table><thead><tr><th>Pflicht<\/th><th>AGB / CACC<\/th><th>Umsetzungsdokument<\/th><\/tr><\/thead><tbody><tr><td>24h-Meldung Cyberangriffe<\/td><td>AGB §14, CACC #19<\/td><td><code>07_Incident_Response_und_Meldewesen.md<\/code><\/td><\/tr><tr><td>FINMA-Drittbegünstigung<\/td><td>AGB §17.2<\/td><td>Prozess neu dokumentiert<\/td><\/tr><tr><td>Audit-Rechte (vollständige Berichte)<\/td><td>AGB §17.3<\/td><td><code>10_Schwachstellenmanagement.md<\/code> — Pentest fehlt<\/td><\/tr><\/tbody><\/table>\n<hr>\n<h2>3. Best-Practice-Einordnung<\/h2>\n<h3>3.1 Stärken (implementiert / dokumentiert)<\/h3>\n<table><thead><tr><th>Bereich<\/th><th>Status<\/th><th>Nachweis<\/th><\/tr><\/thead><tbody><tr><td>DSGVO-Betroffenenrechte (Self-Service)<\/td><td>Implementiert<\/td><td><code>security-overview.md<\/code> Kap. 2<\/td><\/tr><tr><td>Mandantentrennung (logisch)<\/td><td>Implementiert<\/td><td><code>security-overview.md<\/code> Kap. 3<\/td><\/tr><tr><td>RBAC<\/td><td>Implementiert<\/td><td><code>security-overview.md<\/code> Kap. 4<\/td><\/tr><tr><td>Parametrisierte DB-Queries, CSRF, Rate Limiting<\/td><td>Implementiert<\/td><td><code>security-overview.md<\/code> Kap. 6<\/td><\/tr><tr><td>Change Management / Vier-Augen<\/td><td>Dokumentiert<\/td><td><code>feature_release_bugfix.md<\/code>, <code>08_Change_Management.md<\/code><\/td><\/tr><tr><td>Fail-safe Neutralisierung<\/td><td>Konzept + Code-Karte<\/td><td><code>neutralisierung-detail.md<\/code><\/td><\/tr><tr><td>Drittanbieter-Inventar<\/td><td>Vollständig<\/td><td><code>drittanbieter-inventar.md<\/code><\/td><\/tr><tr><td>BCM-Runbook (operativ)<\/td><td>Vorhanden<\/td><td><code>bcm_runbook.md<\/code><\/td><\/tr><tr><td>JSON-Export / Exit<\/td><td>Vorhanden<\/td><td><code>datenbank-handling.md<\/code>, <code>14_Exit_und_Transition.md<\/code><\/td><\/tr><\/tbody><\/table>\n<h3>3.2 Lücken (transparent benannt)<\/h3>\n<table><thead><tr><th>Thema<\/th><th>Risiko<\/th><th>Quelle<\/th><\/tr><\/thead><tbody><tr><td>Keine ISO 27001-Zertifizierung<\/td><td>Mittel — AGB spricht von «Streben»<\/td><td>AGB §8.1, <code>01_Informationssicherheitsrichtlinie.md<\/code><\/td><\/tr><tr><td>Kein granulares Consent-Management<\/td><td>Mittel (Art. 7 DSGVO)<\/td><td><code>security-overview.md<\/code> Kap. 2.6<\/td><\/tr><tr><td>PII-Filter nicht Standard<\/td><td>Hoch bei sensiblen Daten<\/td><td><code>security-overview.md<\/code> Kap. 7.6<\/td><\/tr><tr><td>Kein SIEM / 7×24-SOC<\/td><td>Hoch für FINMA-Kunden<\/td><td><code>11_Logging_und_Monitoring.md<\/code><\/td><\/tr><tr><td>Geteilter SSH-User <code>ubuntu<\/code><\/td><td>Hoch — fehlende Personen-Nachvollziehbarkeit<\/td><td><code>02_Zugriffsmanagement_IAM_PAM.md<\/code><\/td><\/tr><tr><td>Log-Integrität (kein write-once)<\/td><td>Hoch<\/td><td><code>11_Logging_und_Monitoring.md<\/code><\/td><\/tr><tr><td>Kein externer Pentest-Nachweis<\/td><td>Hoch — widerspricht AGB<\/td><td><code>10_Schwachstellenmanagement.md<\/code><\/td><\/tr><tr><td>AVV/SCC bei LLM-Providern ungeklärt<\/td><td>Hoch<\/td><td><code>17_Subunternehmer_Management.md<\/code><\/td><\/tr><\/tbody><\/table>\n<h3>3.3 OWASP / ISO 27001<\/h3>\n<p>Die Plattform adressiert OWASP Top 10 präventiv (<code>security-overview.md<\/code> Kap. 9.3), ohne formale Zertifizierung. Die <code>legal/<\/code>-Prozesse bilden eine <strong>Grundlage für ISMS<\/strong> nach ISO 27001, sind aber grösstenteils im Status «Entwurf» mit vielen <code>[ZU PRÜFEN]<\/code>-Markierungen.<\/p>\n<hr>\n<h2>4. Widersprüche: AGB-Zusicherung vs. dokumentierter Umsetzungsstand<\/h2>\n<blockquote>Die AGB wurden inhaltlich <strong>nicht<\/strong> abgeschwächt. Die folgenden Punkte sind <strong>Compliance-Risiken<\/strong>, solange der Umsetzungsstand nicht angeglichen wird.<\/blockquote>\n<h3>4.1 Verschlüsselung at-rest (AGB §9.1, Anhang C)<\/h3>\n<table><thead><tr><th><\/th><th>AGB<\/th><th>Dokumentierter Stand<\/th><\/tr><\/thead><tbody><tr><td>Zusage<\/td><td>Alle Inhaltsdaten AES-256 at rest<\/td><td><code>[ZU PRÜFEN]<\/code> Infomaniak DB; JSON-Exporte <strong>unverschlüsselt<\/strong><\/td><\/tr><tr><td>Referenz<\/td><td><code>20260603_PowerON_AGB_v1.0_1.md<\/code> §9.1<\/td><td><code>04_Verschluesselung_und_Schluesselmanagement.md<\/code> §2; <code>security-overview.md<\/code> §5.1 (nur Secrets)<\/td><\/tr><\/tbody><\/table>\n<p><strong>Empfehlung:<\/strong> At-Rest bei Infomaniak verifizieren und dokumentieren; Export-Verschlüsselung (AES-256/GPG) einführen; ggf. AGB-Formulierung präzisieren («Inhaltsdaten in der Produktiv-DB» vs. «Backup-Exporte»).<\/p>\n<h3>4.2 Penetrationstests (AGB §8.4)<\/h3>\n<table><thead><tr><th><\/th><th>AGB<\/th><th>Dokumentierter Stand<\/th><\/tr><\/thead><tbody><tr><td>Zusage<\/td><td>Jährlich, unabhängig, volle Berichte auf Anfrage<\/td><td>«Bisher keine externen Pentest-Berichte»<\/td><\/tr><tr><td>Referenz<\/td><td>AGB §8.4<\/td><td><code>10_Schwachstellenmanagement.md<\/code> §4<\/td><\/tr><\/tbody><\/table>\n<p><strong>Empfehlung:<\/strong> Jährlichen Pentest beauftragen; Bericht archivieren; oder AGB-Frist erst nach erstem Test aktivieren.<\/p>\n<h3>4.3 RTO / RPO (AGB Anhang B)<\/h3>\n<table><thead><tr><th><\/th><th>AGB<\/th><th>Dokumentierter Stand<\/th><\/tr><\/thead><tbody><tr><td>Zusage<\/td><td>RTO ≤ 4 h, RPO ≤ 1 h<\/td><td>Wöchentliche Export-Praxis; RPO eher ≤ 24 h<\/td><\/tr><tr><td>Referenz<\/td><td>Anhang B<\/td><td><code>05_Backup_und_Wiederherstellung.md<\/code> §4<\/td><\/tr><\/tbody><\/table>\n<p><strong>Empfehlung:<\/strong> Backup-Frequenz erhöhen (täglich inkrementell) oder SLA/AGB-Werte an reale Kapazität anpassen.<\/p>\n<h3>4.4 Geografisch getrenntes Backup-RZ (AGB §11.2)<\/h3>\n<table><thead><tr><th><\/th><th>AGB<\/th><th>Dokumentierter Stand<\/th><\/tr><\/thead><tbody><tr><td>Zusage<\/td><td>Backup-RZ in der Schweiz, geografisch getrennt<\/td><td><code>[ZU PRÜFEN]<\/code> — nur Infomaniak-Umgebung<\/td><\/tr><tr><td>Referenz<\/td><td>AGB §11.2<\/td><td><code>06_Business_Continuity_und_Disaster_Recovery.md<\/code> §6<\/td><\/tr><\/tbody><\/table>\n<p><strong>Empfehlung:<\/strong> Infomaniak-Region/Snapshot-Standort klären; Evidenz beilegen.<\/p>\n<h3>4.5 MFA und Logging (AGB Anhang C)<\/h3>\n<table><thead><tr><th><\/th><th>AGB<\/th><th>Dokumentierter Stand<\/th><\/tr><\/thead><tbody><tr><td>Zusage<\/td><td>MFA verpflichtend; Logs 3 Jahre, write-once, Kundenzugang<\/td><td>MFA <strong>umgesetzt<\/strong> (Admin/Server, Juni 2026); kein write-once; SIEM offen<\/td><\/tr><tr><td>Referenz<\/td><td>Anhang C<\/td><td><code>02_Zugriffsmanagement_IAM_PAM.md<\/code>, <code>11_Logging_und_Monitoring.md<\/code><\/td><\/tr><\/tbody><\/table>\n<p><strong>Empfehlung:<\/strong> Log-Shipping auf append-only Storage; leichtgewichtiges Alerting. MFA Admin/Server erledigt (Juni 2026).<\/p>\n<h3>4.6 Produktivdaten in Testumgebung (CACC #102)<\/h3>\n<table><thead><tr><th><\/th><th>Anforderung<\/th><th>Dokumentierter Stand<\/th><\/tr><\/thead><tbody><tr><td>Verbot<\/td><td>Keine Berufsgeheimnisdaten in Dev/Test<\/td><td>Prod→Int-Migration als Regelfall beschrieben<\/td><\/tr><tr><td>Referenz<\/td><td><code>15_Sichere_Softwareentwicklung_SDLC.md<\/code> §4<\/td><td><code>datenbank-handling.md<\/code> §3<\/td><\/tr><\/tbody><\/table>\n<p><strong>Empfehlung:<\/strong> Option A (Anonymisierung) oder B (synthetische Daten); <code>datenbank-handling.md<\/code> anpassen — <strong>kritisch für FINMA-Assessment<\/strong>.<\/p>\n<h3>4.7 Anhang A: Rechenzentrumsbetreiber<\/h3>\n<table><thead><tr><th><\/th><th>AGB Anhang A<\/th><th>Übrige Dokumente<\/th><\/tr><\/thead><tbody><tr><td>Stand<\/td><td><code>[RZ-Anbieter primär]<\/code> Platzhalter<\/td><td><strong>Infomaniak<\/strong> (Schweiz) klar benannt<\/td><\/tr><tr><td>Referenz<\/td><td>AGB Anhang A §A.1<\/td><td><code>00_README<\/code>, <code>drittanbieter-inventar.md<\/code><\/td><\/tr><\/tbody><\/table>\n<p><strong>Empfehlung:<\/strong> Anhang A mit Infomaniak (primär + DR-Standort) füllen — keine inhaltliche AGB-Änderung der Zusagen, nur Vervollständigung.<\/p>\n<hr>\n<h2>5. Priorisierte Massnahmenliste<\/h2>\n<table><thead><tr><th>Prio<\/th><th>Massnahme<\/th><th>Aufwand<\/th><th>Rechtliches Risiko<\/th><\/tr><\/thead><tbody><tr><td>P1<\/td><td>AVV/DPA + SCC + Zero-Retention mit OpenAI (und weiteren LLM-Providern) abschliessen und ablegen<\/td><td>Mittel<\/td><td>Hoch<\/td><\/tr><tr><td>P1<\/td><td>Prod-Daten in Test: Prozess ändern (Anonymisierung/synthetisch)<\/td><td>Mittel<\/td><td>Hoch (FINMA)<\/td><\/tr><tr><td>P1<\/td><td>Backup-Exporte verschlüsseln<\/td><td>Gering<\/td><td>Hoch<\/td><\/tr><tr><td>P2<\/td><td>Externen Pentest beauftragen (jährlich)<\/td><td>Mittel<\/td><td>Hoch (AGB §8.4)<\/td><\/tr><tr><td>~~P2~~<\/td><td>~~MFA auf privilegierten Zugängen~~<\/td><td>—<\/td><td><strong>Erledigt<\/strong> (Juni 2026)<\/td><\/tr><tr><td>P2<\/td><td>RTO/RPO mit Backup-Frequenz abgleichen<\/td><td>Mittel<\/td><td>Mittel (Vertrag)<\/td><\/tr><tr><td>P2<\/td><td>Anhang A: Infomaniak eintragen<\/td><td>Gering<\/td><td>Gering<\/td><\/tr><tr><td>P3<\/td><td>Personalisierte SSH-Accounts oder Sitzungsprotokollierung<\/td><td>Mittel<\/td><td>Mittel<\/td><\/tr><tr><td>P3<\/td><td>Log-Integrität (append-only / separates Log-Storage)<\/td><td>Mittel<\/td><td>Mittel<\/td><\/tr><tr><td>P3<\/td><td>Automatisches Uptime-Monitoring + Alerting<\/td><td>Gering<\/td><td>Mittel<\/td><\/tr><tr><td>P3<\/td><td>Strafregisterauszug / NDAs für alle Mitarbeitenden verifizieren<\/td><td>Gering<\/td><td>Mittel<\/td><\/tr><tr><td>P3<\/td><td>ISO-27001-Zertifizierung planen oder AGB-Formulierung «strebt an» beibehalten<\/td><td>Hoch<\/td><td>Niedrig (wenn ehrlich kommuniziert)<\/td><\/tr><\/tbody><\/table>\n<hr>\n<h2>6. Offene Punkte zur Klärung (Rückfragen an PowerOn AG)<\/h2>\n<p>Die folgenden Punkte konnten aus den Dokumenten <strong>nicht<\/strong> verifiziert werden und sollten intern geklärt werden:<\/p>\n<ol><li><strong>Telefonnummer<\/strong> für Incident-Rufbereitschaft (aktuell nur E-Mail Patrick Motsch).<\/li><li><strong>Trennung Rollen:<\/strong> Patrick Motsch trägt alle Rollen (CISO, DPO, GF, DevOps) — für Audits ggf. formale Zuordnung oder externe DPO-Unterstützung erwägen.<\/li><li><strong>Infomaniak:<\/strong> At-Rest-Verschlüsselung, DR-Region, ISO-Zertifikate als PDF beilegen.<\/li><li><strong>OpenAI:<\/strong> Enterprise-Tier mit Training-Opt-out — Vertragsversion und Speicherort dokumentieren.<\/li><li><strong>Schweizer/EU-only LLM<\/strong> für FINMA-Kunden: Ist Mistral EU oder self-hosted Modell produktiv anbietbar?<\/li><li><strong>Legal Hold:<\/strong> Technische Funktion vorhanden oder nur manuelle Prozedur?<\/li><li><strong>Kundenzugang zu Logs:<\/strong> API/Export pro Mandant geplant?<\/li><li><strong>BYOK:<\/strong> Angebot gewünscht für regulierte Kunden?<\/li><li><strong>Rechtliche Prüfung AGB<\/strong> durch Fachanwalt vor Veröffentlichung gegenüber Bankkunden.<\/li><li><strong>Weitere Ansprechpartner<\/strong> bei Team-Wachstum (Vertretung Schlüsselperson).<\/li><\/ol>\n<hr>\n<h2>7. Dokumentenübersicht (Stand nach Anpassung)<\/h2>\n<table><thead><tr><th>Datei<\/th><th>Rolle<\/th><\/tr><\/thead><tbody><tr><td><code>20260603_PowerON_AGB_v1.0_1.md<\/code><\/td><td>Vertragsgrundlage B2B (Stammdaten aktualisiert)<\/td><\/tr><tr><td><code>security-overview.md<\/code><\/td><td>Kundeninformation Sicherheit/Datenschutz<\/td><\/tr><tr><td><code>neutralisierung-detail.md<\/code><\/td><td>Technisches Datenschutz-Modul<\/td><\/tr><tr><td><code>legal/00<\/code>–<code>17<\/code><\/td><td>CACC/FINMA-Prozessdokumentation<\/td><\/tr><tr><td><strong><code>legal/18_Analyse_Recht_und_BestPractice.md<\/code><\/strong><\/td><td>Dieser Befundbericht<\/td><\/tr><\/tbody><\/table>\n<hr>\n<p><em>Nächste planmässige Überprüfung dieses Berichts: 01.02.2027 oder nach wesentlicher Änderung an AGB, Infrastruktur oder regulatorischen Anforderungen.<\/em><\/p>", "text": "# analyse: rechtliche aspekte und best practices **dokumenttyp:** befund- und risikobericht (intern) **geltungsbereich:** gesamtes e-compliance-wiki (porta-plattform) **version:** 1.0 **stand:** 01.02.2026 **erstellt für:** poweron ag, birmensdorferstrasse 94, 8003 zürich (che-491.960.195) **ansprechpartner:** patrick motsch — p.motsch@poweron.swiss > **hinweis:** dieser bericht ersetzt keine anwaltliche beratung. er dokumentiert den stand der wiki-dokumentation nach der firmendaten-anpassung und benennt lücken sowie widersprüche zwischen vertraglichen zusicherungen (agb) und beschriebenem umsetzungsstand. --- ## 1. durchgeführte anpassungen (01.02.2026) | massnahme | umfang | |---|---| | rechtsträger | `poweron gmbh` → **poweron ag** (che-491.960.195) | | markenschreibweise | `poweron` → **poweron** in agb und allen `legal/`-dokumenten | | stammdaten agb §1.1 | birmensdorferstrasse 94, 8003 zürich, p.motsch@poweron.swiss | | gerichtsstand agb §23.2 | zürich, schweiz | | datumsfelder agb | stand / gilt ab / anhänge: **01.02.2026**; nächste überprüfung: **01.02.2027** | | ansprechpartner/rollen | patrick motsch in offenen namens-/kontaktfeldern (dok. 01, 02, 06, 07) | **nicht geändert (bewusst):** inhaltliche agb-zusicherungen; technische `[zu prüfen]`-fakten (at-rest, pentest-nachweis etc.). mfa auf admin-/server-zugängen seit juni 2026 umgesetzt. --- ## 2. rechtlicher rahmen ### 2.1 anwendbares recht | rechtsgebiet | relevanz in der dokumentation | |---|---| | **schweizer dsg** (revdsg) | primärrecht für daten in der schweiz; agb §6.4, security-overview kap. 9.2 | | **dsgvo** | anwendbar bei eu-betroffenen / grenzüberschreitender verarbeitung; betroffenenrechte in security-overview | | **finma-rundschreiben 2018/3, 2023/1** | auslagerung an cloud/it-dienstleister; cacc-mapping in `00_readme_prozessuebersicht.md` | | **bankgeheimnis (art. 47 bankg)** | agb §13.2; erhöhter schutz für berufsgeheimnisdaten | | **berufsgeheimnis stgb (art. 321)** | medizinische/sonstige berufsgeheimnisse; gleiche behandlung wie bankdaten in agb | | **schweizer obligationenrecht / zgb** | b2b-verträge, agb-geltung, gerichtsstand zürich | ### 2.2 vertragshierarchie (agb §1.4) 1. individueller dienstleistungsvertrag 2. avv (auftragsverarbeitungsvertrag) 3. sla 4. agb 5. anhänge a, b, c **empfehlung:** für finma-regulierte kunden immer individuellen vertrag + avv abschliessen; agb allein genügt regulatorisch nicht. ### 2.3 auftragsverarbeitung und drittlandtransfers - **speicherung inhaltsdaten:** schweiz (infomaniak) — konsistent dokumentiert. - **llm-verarbeitung:** primär openai (usa) — temporärer datenabfluss; erfordert avv/dpa, eu-scc, tia, zero-data-retention (`17_subunternehmer_management.md`, agb §7.2). - **neutralisierung:** technisches modul reduziert pii vor externem llm-call (`neutralisierung-detail.md`); nicht standardmässig für alle tenants aktiv (`security-overview.md` kap. 7.6). ### 2.4 melde- und auditpflichten | pflicht | agb / cacc | umsetzungsdokument | |---|---|---| | 24h-meldung cyberangriffe | agb §14, cacc #19 | `07_incident_response_und_meldewesen.md` | | finma-drittbegünstigung | agb §17.2 | prozess neu dokumentiert | | audit-rechte (vollständige berichte) | agb §17.3 | `10_schwachstellenmanagement.md` — pentest fehlt | --- ## 3. best-practice-einordnung ### 3.1 stärken (implementiert / dokumentiert) | bereich | status | nachweis | |---|---|---| | dsgvo-betroffenenrechte (self-service) | implementiert | `security-overview.md` kap. 2 | | mandantentrennung (logisch) | implementiert | `security-overview.md` kap. 3 | | rbac | implementiert | `security-overview.md` kap. 4 | | parametrisierte db-queries, csrf, rate limiting | implementiert | `security-overview.md` kap. 6 | | change management / vier-augen | dokumentiert | `feature_release_bugfix.md`, `08_change_management.md` | | fail-safe neutralisierung | konzept + code-karte | `neutralisierung-detail.md` | | drittanbieter-inventar | vollständig | `drittanbieter-inventar.md` | | bcm-runbook (operativ) | vorhanden | `bcm_runbook.md` | | json-export / exit | vorhanden | `datenbank-handling.md`, `14_exit_und_transition.md` | ### 3.2 lücken (transparent benannt) | thema | risiko | quelle | |---|---|---| | keine iso 27001-zertifizierung | mittel — agb spricht von «streben» | agb §8.1, `01_informationssicherheitsrichtlinie.md` | | kein granulares consent-management | mittel (art. 7 dsgvo) | `security-overview.md` kap. 2.6 | | pii-filter nicht standard | hoch bei sensiblen daten | `security-overview.md` kap. 7.6 | | kein siem / 7×24-soc | hoch für finma-kunden | `11_logging_und_monitoring.md` | | geteilter ssh-user `ubuntu` | hoch — fehlende personen-nachvollziehbarkeit | `02_zugriffsmanagement_iam_pam.md` | | log-integrität (kein write-once) | hoch | `11_logging_und_monitoring.md` | | kein externer pentest-nachweis | hoch — widerspricht agb | `10_schwachstellenmanagement.md` | | avv/scc bei llm-providern ungeklärt | hoch | `17_subunternehmer_management.md` | ### 3.3 owasp / iso 27001 die plattform adressiert owasp top 10 präventiv (`security-overview.md` kap. 9.3), ohne formale zertifizierung. die `legal/`-prozesse bilden eine **grundlage für isms** nach iso 27001, sind aber grösstenteils im status «entwurf» mit vielen `[zu prüfen]`-markierungen. --- ## 4. widersprüche: agb-zusicherung vs. dokumentierter umsetzungsstand > die agb wurden inhaltlich **nicht** abgeschwächt. die folgenden punkte sind **compliance-risiken**, solange der umsetzungsstand nicht angeglichen wird. ### 4.1 verschlüsselung at-rest (agb §9.1, anhang c) | | agb | dokumentierter stand | |---|---|---| | zusage | alle inhaltsdaten aes-256 at rest | `[zu prüfen]` infomaniak db; json-exporte **unverschlüsselt** | | referenz | `20260603_poweron_agb_v1.0_1.md` §9.1 | `04_verschluesselung_und_schluesselmanagement.md` §2; `security-overview.md` §5.1 (nur secrets) | **empfehlung:** at-rest bei infomaniak verifizieren und dokumentieren; export-verschlüsselung (aes-256/gpg) einführen; ggf. agb-formulierung präzisieren («inhaltsdaten in der produktiv-db» vs. «backup-exporte»). ### 4.2 penetrationstests (agb §8.4) | | agb | dokumentierter stand | |---|---|---| | zusage | jährlich, unabhängig, volle berichte auf anfrage | «bisher keine externen pentest-berichte» | | referenz | agb §8.4 | `10_schwachstellenmanagement.md` §4 | **empfehlung:** jährlichen pentest beauftragen; bericht archivieren; oder agb-frist erst nach erstem test aktivieren. ### 4.3 rto / rpo (agb anhang b) | | agb | dokumentierter stand | |---|---|---| | zusage | rto ≤ 4 h, rpo ≤ 1 h | wöchentliche export-praxis; rpo eher ≤ 24 h | | referenz | anhang b | `05_backup_und_wiederherstellung.md` §4 | **empfehlung:** backup-frequenz erhöhen (täglich inkrementell) oder sla/agb-werte an reale kapazität anpassen. ### 4.4 geografisch getrenntes backup-rz (agb §11.2) | | agb | dokumentierter stand | |---|---|---| | zusage | backup-rz in der schweiz, geografisch getrennt | `[zu prüfen]` — nur infomaniak-umgebung | | referenz | agb §11.2 | `06_business_continuity_und_disaster_recovery.md` §6 | **empfehlung:** infomaniak-region/snapshot-standort klären; evidenz beilegen. ### 4.5 mfa und logging (agb anhang c) | | agb | dokumentierter stand | |---|---|---| | zusage | mfa verpflichtend; logs 3 jahre, write-once, kundenzugang | mfa **umgesetzt** (admin/server, juni 2026); kein write-once; siem offen | | referenz | anhang c | `02_zugriffsmanagement_iam_pam.md`, `11_logging_und_monitoring.md` | **empfehlung:** log-shipping auf append-only storage; leichtgewichtiges alerting. mfa admin/server erledigt (juni 2026). ### 4.6 produktivdaten in testumgebung (cacc #102) | | anforderung | dokumentierter stand | |---|---|---| | verbot | keine berufsgeheimnisdaten in dev/test | prod→int-migration als regelfall beschrieben | | referenz | `15_sichere_softwareentwicklung_sdlc.md` §4 | `datenbank-handling.md` §3 | **empfehlung:** option a (anonymisierung) oder b (synthetische daten); `datenbank-handling.md` anpassen — **kritisch für finma-assessment**. ### 4.7 anhang a: rechenzentrumsbetreiber | | agb anhang a | übrige dokumente | |---|---|---| | stand | `[rz-anbieter primär]` platzhalter | **infomaniak** (schweiz) klar benannt | | referenz | agb anhang a §a.1 | `00_readme`, `drittanbieter-inventar.md` | **empfehlung:** anhang a mit infomaniak (primär + dr-standort) füllen — keine inhaltliche agb-änderung der zusagen, nur vervollständigung. --- ## 5. priorisierte massnahmenliste | prio | massnahme | aufwand | rechtliches risiko | |:---:|---|---|---| | p1 | avv/dpa + scc + zero-retention mit openai (und weiteren llm-providern) abschliessen und ablegen | mittel | hoch | | p1 | prod-daten in test: prozess ändern (anonymisierung/synthetisch) | mittel | hoch (finma) | | p1 | backup-exporte verschlüsseln | gering | hoch | | p2 | externen pentest beauftragen (jährlich) | mittel | hoch (agb §8.4) | | ~~p2~~ | ~~mfa auf privilegierten zugängen~~ | — | **erledigt** (juni 2026) | | p2 | rto/rpo mit backup-frequenz abgleichen | mittel | mittel (vertrag) | | p2 | anhang a: infomaniak eintragen | gering | gering | | p3 | personalisierte ssh-accounts oder sitzungsprotokollierung | mittel | mittel | | p3 | log-integrität (append-only / separates log-storage) | mittel | mittel | | p3 | automatisches uptime-monitoring + alerting | gering | mittel | | p3 | strafregisterauszug / ndas für alle mitarbeitenden verifizieren | gering | mittel | | p3 | iso-27001-zertifizierung planen oder agb-formulierung «strebt an» beibehalten | hoch | niedrig (wenn ehrlich kommuniziert) | --- ## 6. offene punkte zur klärung (rückfragen an poweron ag) die folgenden punkte konnten aus den dokumenten **nicht** verifiziert werden und sollten intern geklärt werden: 1. **telefonnummer** für incident-rufbereitschaft (aktuell nur e-mail patrick motsch). 2. **trennung rollen:** patrick motsch trägt alle rollen (ciso, dpo, gf, devops) — für audits ggf. formale zuordnung oder externe dpo-unterstützung erwägen. 3. **infomaniak:** at-rest-verschlüsselung, dr-region, iso-zertifikate als pdf beilegen. 4. **openai:** enterprise-tier mit training-opt-out — vertragsversion und speicherort dokumentieren. 5. **schweizer/eu-only llm** für finma-kunden: ist mistral eu oder self-hosted modell produktiv anbietbar? 6. **legal hold:** technische funktion vorhanden oder nur manuelle prozedur? 7. **kundenzugang zu logs:** api/export pro mandant geplant? 8. **byok:** angebot gewünscht für regulierte kunden? 9. **rechtliche prüfung agb** durch fachanwalt vor veröffentlichung gegenüber bankkunden. 10. **weitere ansprechpartner** bei team-wachstum (vertretung schlüsselperson). --- ## 7. dokumentenübersicht (stand nach anpassung) | datei | rolle | |---|---| | `20260603_poweron_agb_v1.0_1.md` | vertragsgrundlage b2b (stammdaten aktualisiert) | | `security-overview.md` | kundeninformation sicherheit/datenschutz | | `neutralisierung-detail.md` | technisches datenschutz-modul | | `legal/00`–`17` | cacc/finma-prozessdokumentation | | **`legal/18_analyse_recht_und_bestpractice.md`** | dieser befundbericht | --- *nächste planmässige überprüfung dieses berichts: 01.02.2027 oder nach wesentlicher änderung an agb, infrastruktur oder regulatorischen anforderungen.* ", "nextReview": "", "overdueReview": false, "zuPruefen": []}, {"id": "05_betrieb/20260528_bcm_runbook.md", "path": "05_betrieb/20260528_bcm_runbook.md", "chapter": "05_betrieb", "title": "Runbook: Plattform-Core (PowerOn Gateway)", "filename": "20260528_bcm_runbook.md", "meta": {}, "html": "<h1>Runbook: Plattform-Core (PowerOn Gateway)<\/h1>\n<p>Dieses Dokument beschreibt die drei häufigsten Betriebsszenarien für die PowerOn-Plattform. Es richtet sich an alle, die im Notfall handeln müssen — auch ohne tiefes technisches Vorwissen. Die konkreten Befehle sind für die Person gedacht, die den Server-Zugang hat (typisch: Entwickler oder DevOps).<\/p>\n<p><strong>Kurze Systemübersicht:<\/strong> Die Plattform läuft auf einem Server bei Infomaniak (<code>api.poweron.swiss<\/code>). Alle Kundendaten liegen in einer separaten PostgreSQL-Datenbank (<code>db.poweron.swiss<\/code>). Codeänderungen werden über das interne Git-System (Forgejo) automatisch deployed.<\/p>\n<table><thead><tr><th>Umgebung<\/th><th>Server<\/th><th>URL<\/th><\/tr><\/thead><tbody><tr><td>Produktion<\/td><td><code>ubuntu@api.poweron.swiss<\/code><\/td><td><code>https://api.poweron.swiss<\/code><\/td><\/tr><tr><td>Integration (Test)<\/td><td><code>ubuntu@api-int.poweron.swiss<\/code><\/td><td><code>https://api-int.poweron.swiss<\/code><\/td><\/tr><\/tbody><\/table>\n<hr>\n<h2>1. Produktivumgebung neu starten<\/h2>\n<p><strong>Wann nötig?<\/strong> Die API antwortet nicht mehr, Requests laufen in Timeouts, oder nach einem Konfigurationswechsel soll alles frisch gestartet werden.<\/p>\n<p><strong>Was passiert dabei?<\/strong> Der laufende Prozess wird gestoppt und neu gestartet. Die Datenbank und alle gespeicherten Daten bleiben dabei vollständig erhalten. Nutzer merken einen kurzen Unterbruch von typisch wenigen Sekunden.<\/p>\n<h3>Normalfall: Service neu starten<\/h3>\n<p>Auf dem Produktionsserver einloggen und den Service neu starten:<\/p>\n<pre class=\"code\"><code>ssh ubuntu@api.poweron.swiss\nsudo systemctl restart gateway<\/code><\/pre>\n<p>Danach prüfen, ob alles wieder läuft:<\/p>\n<pre class=\"code\"><code>sudo systemctl status gateway<\/code><\/pre>\n<p>Den Health-Check aufrufen — wenn er <code>200 OK<\/code> zurückgibt, ist alles gut:<\/p>\n<pre class=\"code\"><code>curl https://api.poweron.swiss/api/admin/health<\/code><\/pre>\n<h3>Kompletter Neustart (inkl. Abhängigkeiten neu laden)<\/h3>\n<p>Wenn sich seit dem letzten Deploy neue Bibliotheken geändert haben oder nach einem manuellen Eingriff am Server:<\/p>\n<pre class=\"code\"><code>ssh ubuntu@api.poweron.swiss\ncd /srv/gateway/current\nsource .venv/bin/activate\npip install -r requirements.txt --no-cache-dir\nsudo systemctl restart gateway<\/code><\/pre>\n<h3>Wenn der Service nicht startet<\/h3>\n<p>Wenn der Neustart nicht hilft oder der Service sofort wieder abbricht, hilft ein Blick in die Logs:<\/p>\n<pre class=\"code\"><code># Systemlogs der letzten 100 Zeilen\nsudo journalctl -u gateway -n 100 --no-pager\n\n# Anwendungslogs des heutigen Tages\ntail -100 /srv/gateway/shared/logs/log_app_$(date +%Y%m%d).log<\/code><\/pre>\n<p>Wenn der Fehler unklar ist, kann die App auch direkt im Vordergrund gestartet werden — dann erscheint die Fehlermeldung sofort im Terminal:<\/p>\n<pre class=\"code\"><code>cd /srv/gateway/current\nsource .venv/bin/activate\ngunicorn app:app --bind 0.0.0.0:8000 --timeout 600 \\\n  --worker-class uvicorn.workers.UvicornWorker --workers 1<\/code><\/pre>\n<hr>\n<h2>2. Backup einspielen (Datenbankwiederherstellung)<\/h2>\n<p><strong>Wann nötig?<\/strong> Nach einem Datenverlust, einer fehlerhaften Migration oder wenn ein früherer Datenbankstand wiederhergestellt werden muss.<\/p>\n<p><strong>Was passiert dabei?<\/strong> Die Anwendung wird kurz gestoppt, damit während dem Restore niemand inkonsistente Daten sieht. Die bestehenden Daten werden durch den Backup-Stand ersetzt. Danach wird die Anwendung wieder gestartet. Je nach Datenmenge dauert der Restore wenige Minuten bis zu einer Stunde.<\/p>\n<p><strong>Wichtig vor dem Start:<\/strong> Immer zuerst einen aktuellen Snapshot erstellen, bevor man ein älteres Backup einspielt — so kann man auch den Zustand kurz vor dem Restore noch wiederherstellen, falls etwas schiefläuft.<\/p>\n<h3>Schritt 1: Aktuellen Stand sichern (Sicherheitskopie)<\/h3>\n<pre class=\"code\"><code>ssh ubuntu@api.poweron.swiss\n# DB-Passwort aus der Konfiguration lesen:\ngrep DB_ /srv/gateway/current/.env\n\n# Alle Datenbanken sichern (Dateien landen in /tmp/)\nfor DB in poweron_app poweron_management poweron_billing poweron_chat \\\n           poweron_chatbot poweron_trustee poweron_realestate \\\n           poweron_knowledge poweron_workspace; do\n  pg_dump -h db.poweron.swiss -U poweron_dev -p 5432 \\\n    -Fc $DB &gt; /tmp/backup_${DB}_$(date +%Y%m%d_%H%M%S).dump\ndone<\/code><\/pre>\n<h3>Schritt 2: Anwendung stoppen und Backup einspielen<\/h3>\n<pre class=\"code\"><code>sudo systemctl stop gateway\n\n# Einzelne Datenbank wiederherstellen (Beispiel: poweron_app)\npg_restore -h db.poweron.swiss -U poweron_dev -p 5432 \\\n  -d poweron_app --clean --if-exists \\\n  /pfad/zum/backup_poweron_app_DATUM.dump\n\nsudo systemctl start gateway<\/code><\/pre>\n<h3>Backup einspielen über das Migrations-Tool (alle Datenbanken)<\/h3>\n<p>Wenn ein vollständiges JSON-Export aus dem projekteigenen Migrationstool vorliegt:<\/p>\n<pre class=\"code\"><code>ssh ubuntu@api.poweron.swiss\ncd /srv/gateway/current\nsource .venv/bin/activate\nsudo systemctl stop gateway\n\n# Hilfe zum Import-Script anzeigen:\npython scripts/script_db_export_migration.py --help\n\nsudo systemctl start gateway<\/code><\/pre>\n<h3>Schritt 3: Verifizieren<\/h3>\n<pre class=\"code\"><code>sudo systemctl status gateway\ncurl https://api.poweron.swiss/api/admin/health<\/code><\/pre>\n<hr>\n<h2>3. Rollback auf die vorherige Version<\/h2>\n<p><strong>Wann nötig?<\/strong> Ein frisch deploytes Update verursacht Fehler oder unerwünschtes Verhalten, das vorher nicht da war. Statt stundenlang zu debuggen, fährt man die Plattform einfach auf den letzten stabilen Stand zurück.<\/p>\n<p><strong>Was passiert dabei?<\/strong> Der Code auf dem Server wird auf einen früheren Git-Commit zurückgesetzt. Die Datenbank bleibt unverändert — nur der Anwendungscode wird ausgetauscht. Das dauert typisch unter 2 Minuten.<\/p>\n<p><strong>Hinweis zu Datenbank-Migrationen:<\/strong> Wenn das neue Update auch Datenbankänderungen enthielt, kann ein reiner Code-Rollback zu Inkompatibilitäten führen. In diesem Fall zusätzlich einen Datenbank-Restore (Szenario 2) in Betracht ziehen und vorher mit dem Entwicklungsteam absprechen.<\/p>\n<h3>Rollback über Git (empfohlen, schnellster Weg)<\/h3>\n<pre class=\"code\"><code>ssh ubuntu@api.poweron.swiss\ncd /srv/gateway/current\n\n# Die letzten 10 Deployments anzeigen — den gewünschten HASH notieren\ngit log --oneline -10\n\n# Auf den gewählten Stand zurücksetzen (HASH ersetzen, z.B. \"b04211be\")\ngit reset --hard &lt;COMMIT_HASH&gt;\n\n# Konfigurationsdatei neu setzen\ntest -f env-prod.env &amp;&amp; cp env-prod.env .env &amp;&amp; rm -f env-*.env\n\n# Abhängigkeiten prüfen\nsource .venv/bin/activate\npip install -r requirements.txt --no-cache-dir\n\n# Service neu starten und prüfen\nsudo systemctl restart gateway\nsudo systemctl status gateway\ncurl https://api.poweron.swiss/api/admin/health<\/code><\/pre>\n<h3>Rollback über Forgejo (sauberer, hinterlässt Protokoll)<\/h3>\n<p>Diese Variante ist etwas langsamer (Tests laufen durch), aber der Rollback wird im Git-Verlauf sichtbar und ist für alle nachvollziehbar.<\/p>\n<pre class=\"code\"><code># Lokal: einen Revert-Commit erstellen und pushen\ngit revert HEAD  # oder den spezifischen Commit angeben\ngit push origin main\n# → Forgejo startet automatisch Tests und deployed danach<\/code><\/pre>\n<h3>Rollback auf der INT-Umgebung<\/h3>\n<p>Gleiche Schritte wie oben, aber mit diesen Werten:<\/p>\n<ul><li>Server: <code>ubuntu@api-int.poweron.swiss<\/code><\/li><li>Branch: <code>int<\/code> statt <code>main<\/code><\/li><li>Env-Datei: <code>env-int.env<\/code><\/li><li>Health-Check: <code>https://api-int.poweron.swiss/api/admin/health<\/code><\/li><\/ul>\n<hr>\n<h2>Referenz<\/h2>\n<table><thead><tr><th>Was<\/th><th>Wo<\/th><\/tr><\/thead><tbody><tr><td>Prod-Server<\/td><td><code>ubuntu@api.poweron.swiss<\/code><\/td><\/tr><tr><td>Int-Server<\/td><td><code>ubuntu@api-int.poweron.swiss<\/code><\/td><\/tr><tr><td>App-Pfad auf Server<\/td><td><code>/srv/gateway/current<\/code><\/td><\/tr><tr><td>App-Logs<\/td><td><code>/srv/gateway/shared/logs/log_app_YYYYMMDD.log<\/code><\/td><\/tr><tr><td>System-Logs<\/td><td><code>journalctl -u gateway<\/code><\/td><\/tr><tr><td>Datenbank-Host<\/td><td><code>db.poweron.swiss:5432<\/code><\/td><\/tr><tr><td>Datenbank-User<\/td><td><code>poweron_dev<\/code><\/td><\/tr><tr><td>Health-Check Endpoint<\/td><td><code>GET /api/admin/health<\/code><\/td><\/tr><tr><td>CI/CD Pipeline<\/td><td><code>.forgejo/workflows/main_porta-main-platform-core.yml<\/code><\/td><\/tr><\/tbody><\/table>", "text": "# runbook: plattform-core (poweron gateway) dieses dokument beschreibt die drei häufigsten betriebsszenarien für die poweron-plattform. es richtet sich an alle, die im notfall handeln müssen — auch ohne tiefes technisches vorwissen. die konkreten befehle sind für die person gedacht, die den server-zugang hat (typisch: entwickler oder devops). **kurze systemübersicht:** die plattform läuft auf einem server bei infomaniak (`api.poweron.swiss`). alle kundendaten liegen in einer separaten postgresql-datenbank (`db.poweron.swiss`). codeänderungen werden über das interne git-system (forgejo) automatisch deployed. | umgebung | server | url | |---|---|---| | produktion | `ubuntu@api.poweron.swiss` | `https://api.poweron.swiss` | | integration (test) | `ubuntu@api-int.poweron.swiss` | `https://api-int.poweron.swiss` | --- ## 1. produktivumgebung neu starten **wann nötig?** die api antwortet nicht mehr, requests laufen in timeouts, oder nach einem konfigurationswechsel soll alles frisch gestartet werden. **was passiert dabei?** der laufende prozess wird gestoppt und neu gestartet. die datenbank und alle gespeicherten daten bleiben dabei vollständig erhalten. nutzer merken einen kurzen unterbruch von typisch wenigen sekunden. ### normalfall: service neu starten auf dem produktionsserver einloggen und den service neu starten: ```bash ssh ubuntu@api.poweron.swiss sudo systemctl restart gateway ``` danach prüfen, ob alles wieder läuft: ```bash sudo systemctl status gateway ``` den health-check aufrufen — wenn er `200 ok` zurückgibt, ist alles gut: ```bash curl https://api.poweron.swiss/api/admin/health ``` ### kompletter neustart (inkl. abhängigkeiten neu laden) wenn sich seit dem letzten deploy neue bibliotheken geändert haben oder nach einem manuellen eingriff am server: ```bash ssh ubuntu@api.poweron.swiss cd /srv/gateway/current source .venv/bin/activate pip install -r requirements.txt --no-cache-dir sudo systemctl restart gateway ``` ### wenn der service nicht startet wenn der neustart nicht hilft oder der service sofort wieder abbricht, hilft ein blick in die logs: ```bash # systemlogs der letzten 100 zeilen sudo journalctl -u gateway -n 100 --no-pager # anwendungslogs des heutigen tages tail -100 /srv/gateway/shared/logs/log_app_$(date +%y%m%d).log ``` wenn der fehler unklar ist, kann die app auch direkt im vordergrund gestartet werden — dann erscheint die fehlermeldung sofort im terminal: ```bash cd /srv/gateway/current source .venv/bin/activate gunicorn app:app --bind 0.0.0.0:8000 --timeout 600 \\ --worker-class uvicorn.workers.uvicornworker --workers 1 ``` --- ## 2. backup einspielen (datenbankwiederherstellung) **wann nötig?** nach einem datenverlust, einer fehlerhaften migration oder wenn ein früherer datenbankstand wiederhergestellt werden muss. **was passiert dabei?** die anwendung wird kurz gestoppt, damit während dem restore niemand inkonsistente daten sieht. die bestehenden daten werden durch den backup-stand ersetzt. danach wird die anwendung wieder gestartet. je nach datenmenge dauert der restore wenige minuten bis zu einer stunde. **wichtig vor dem start:** immer zuerst einen aktuellen snapshot erstellen, bevor man ein älteres backup einspielt — so kann man auch den zustand kurz vor dem restore noch wiederherstellen, falls etwas schiefläuft. ### schritt 1: aktuellen stand sichern (sicherheitskopie) ```bash ssh ubuntu@api.poweron.swiss # db-passwort aus der konfiguration lesen: grep db_ /srv/gateway/current/.env # alle datenbanken sichern (dateien landen in /tmp/) for db in poweron_app poweron_management poweron_billing poweron_chat \\ poweron_chatbot poweron_trustee poweron_realestate \\ poweron_knowledge poweron_workspace; do pg_dump -h db.poweron.swiss -u poweron_dev -p 5432 \\ -fc $db > /tmp/backup_${db}_$(date +%y%m%d_%h%m%s).dump done ``` ### schritt 2: anwendung stoppen und backup einspielen ```bash sudo systemctl stop gateway # einzelne datenbank wiederherstellen (beispiel: poweron_app) pg_restore -h db.poweron.swiss -u poweron_dev -p 5432 \\ -d poweron_app --clean --if-exists \\ /pfad/zum/backup_poweron_app_datum.dump sudo systemctl start gateway ``` ### backup einspielen über das migrations-tool (alle datenbanken) wenn ein vollständiges json-export aus dem projekteigenen migrationstool vorliegt: ```bash ssh ubuntu@api.poweron.swiss cd /srv/gateway/current source .venv/bin/activate sudo systemctl stop gateway # hilfe zum import-script anzeigen: python scripts/script_db_export_migration.py --help sudo systemctl start gateway ``` ### schritt 3: verifizieren ```bash sudo systemctl status gateway curl https://api.poweron.swiss/api/admin/health ``` --- ## 3. rollback auf die vorherige version **wann nötig?** ein frisch deploytes update verursacht fehler oder unerwünschtes verhalten, das vorher nicht da war. statt stundenlang zu debuggen, fährt man die plattform einfach auf den letzten stabilen stand zurück. **was passiert dabei?** der code auf dem server wird auf einen früheren git-commit zurückgesetzt. die datenbank bleibt unverändert — nur der anwendungscode wird ausgetauscht. das dauert typisch unter 2 minuten. **hinweis zu datenbank-migrationen:** wenn das neue update auch datenbankänderungen enthielt, kann ein reiner code-rollback zu inkompatibilitäten führen. in diesem fall zusätzlich einen datenbank-restore (szenario 2) in betracht ziehen und vorher mit dem entwicklungsteam absprechen. ### rollback über git (empfohlen, schnellster weg) ```bash ssh ubuntu@api.poweron.swiss cd /srv/gateway/current # die letzten 10 deployments anzeigen — den gewünschten hash notieren git log --oneline -10 # auf den gewählten stand zurücksetzen (hash ersetzen, z.b. \"b04211be\") git reset --hard <commit_hash> # konfigurationsdatei neu setzen test -f env-prod.env && cp env-prod.env .env && rm -f env-*.env # abhängigkeiten prüfen source .venv/bin/activate pip install -r requirements.txt --no-cache-dir # service neu starten und prüfen sudo systemctl restart gateway sudo systemctl status gateway curl https://api.poweron.swiss/api/admin/health ``` ### rollback über forgejo (sauberer, hinterlässt protokoll) diese variante ist etwas langsamer (tests laufen durch), aber der rollback wird im git-verlauf sichtbar und ist für alle nachvollziehbar. ```bash # lokal: einen revert-commit erstellen und pushen git revert head # oder den spezifischen commit angeben git push origin main # → forgejo startet automatisch tests und deployed danach ``` ### rollback auf der int-umgebung gleiche schritte wie oben, aber mit diesen werten: - server: `ubuntu@api-int.poweron.swiss` - branch: `int` statt `main` - env-datei: `env-int.env` - health-check: `https://api-int.poweron.swiss/api/admin/health` --- ## referenz | was | wo | |---|---| | prod-server | `ubuntu@api.poweron.swiss` | | int-server | `ubuntu@api-int.poweron.swiss` | | app-pfad auf server | `/srv/gateway/current` | | app-logs | `/srv/gateway/shared/logs/log_app_yyyymmdd.log` | | system-logs | `journalctl -u gateway` | | datenbank-host | `db.poweron.swiss:5432` | | datenbank-user | `poweron_dev` | | health-check endpoint | `get /api/admin/health` | | ci/cd pipeline | `.forgejo/workflows/main_porta-main-platform-core.yml` | ", "nextReview": "", "overdueReview": false, "zuPruefen": []}, {"id": "05_betrieb/20260528_datenbank-handling.md", "path": "05_betrieb/20260528_datenbank-handling.md", "chapter": "05_betrieb", "title": "Datenbank-Handling: Exports, Imports, Backups & Datensicherung", "filename": "20260528_datenbank-handling.md", "meta": {}, "html": "<h1>Datenbank-Handling: Exports, Imports, Backups &amp; Datensicherung<\/h1>\n<p>Dieses Dokument beschreibt, wie die PowerOn-Plattform ihre Datenbanken verwaltet — von der strukturierten Datensicherung über flexible Export- und Import-Werkzeuge bis hin zur sicheren Wiederherstellung.<\/p>\n<hr>\n<h2>1. Datenbankübersicht<\/h2>\n<p>Die Plattform betreibt <strong>13 separate Datenbanken<\/strong> auf dem Datenbankserver <code>db.poweron.swiss<\/code>. Jede Datenbank gehört einem fachlichen Bereich:<\/p>\n<table><thead><tr><th>Datenbank<\/th><th>Inhalt<\/th><\/tr><\/thead><tbody><tr><td><code>poweron_app<\/code><\/td><td>Benutzer, Mandate, Berechtigungen, Features — Kern der Plattform<\/td><\/tr><tr><td><code>poweron_management<\/code><\/td><td>Workflows, Prompts, Verbindungen (Connections)<\/td><\/tr><tr><td><code>poweron_billing<\/code><\/td><td>Abonnements, Rechnungen, Stripe-Daten<\/td><\/tr><tr><td><code>poweron_chat<\/code><\/td><td>Chat-Konversationen und Nachrichten<\/td><\/tr><tr><td><code>poweron_chatbot<\/code><\/td><td>Chatbot-Feature: Konversationen, Logs<\/td><\/tr><tr><td><code>poweron_knowledge<\/code><\/td><td>RAG-Wissensdatenbank, Dokumentenindizes<\/td><\/tr><tr><td><code>poweron_workspace<\/code><\/td><td>Workspace-Daten<\/td><\/tr><tr><td><code>poweron_trustee<\/code><\/td><td>Treuhand-spezifische Daten<\/td><\/tr><tr><td><code>poweron_realestate<\/code><\/td><td>Immobilien-Daten<\/td><\/tr><tr><td><code>poweron_commcoach<\/code><\/td><td>CommCoach-Feature<\/td><\/tr><tr><td><code>poweron_neutralization<\/code><\/td><td>Content-Neutralisierung<\/td><\/tr><tr><td><code>poweron_teamsbot<\/code><\/td><td>Microsoft Teams Bot<\/td><\/tr><tr><td><code>poweron_test<\/code><\/td><td>Testdaten (wird bei Exports ausgeschlossen)<\/td><\/tr><\/tbody><\/table>\n<hr>\n<h2>2. Export<\/h2>\n<p>Ein Export erstellt eine vollständige Kopie aller Daten in einem lesbaren JSON-Format. Er dient als Grundlage für Backups, Migrationen zwischen Umgebungen (z. B. Prod → Int) und als Sicherungspunkt vor grösseren Änderungen.<\/p>\n<h3>2.1 Export via Admin-UI (empfohlen)<\/h3>\n<p>Im SysAdmin-Bereich der Plattform gibt es einen integrierten Export-Button. Er erzeugt eine JSON-Datei, die direkt heruntergeladen wird.<\/p>\n<ul><li><strong>Zugriff:<\/strong> Nur für SysAdmins (höchste Berechtigungsstufe)<\/li><li><strong>Umfang:<\/strong> Alle Datenbanken oder einzelne auswählbar<\/li><li><strong>Dateiname:<\/strong> <code>migration_backup_YYYY-MM-DD_HH-MM.json<\/code><\/li><li><strong>Rate-Limit:<\/strong> Max. 2 Exports pro Minute (Schutzmassnahme gegen versehentliche Mehrfachausführung)<\/li><\/ul>\n<p>Auch sehr grosse Datenbanken werden sicher übertragen, ohne dass der Server dabei überlastet wird.<\/p>\n<h3>2.2 Export via Script (für Entwickler / Server-Zugriff)<\/h3>\n<p>Direkt auf dem Server kann das Export-Script ausgeführt werden:<\/p>\n<pre class=\"code\"><code>ssh ubuntu@api.poweron.swiss\ncd /srv/gateway/current\nsource .venv/bin/activate\n\n# Alle Datenbanken exportieren\npython scripts/script_db_export_migration.py --pretty\n\n# Nur bestimmte Datenbanken\npython scripts/script_db_export_migration.py --db poweron_app,poweron_management\n\n# Ohne Metadaten (kleiner, für Archivierung)\npython scripts/script_db_export_migration.py --exclude Token,AuthEvent\n\n# Mit Zusammenfassung (zeigt Tabellen- und Zeilenanzahl)\npython scripts/script_db_export_migration.py --summary<\/code><\/pre>\n<p>Das Script erstellt automatisch zwei Dateien:<\/p>\n<ul><li><code>migration_export_TIMESTAMP.json<\/code> — vollständige Daten<\/li><li><code>migration_export_TIMESTAMP_structure.json<\/code> — nur Tabellenstruktur, keine Daten<\/li><\/ul>\n<h3>2.3 Was wird beim Export ausgeschlossen?<\/h3>\n<p>Aus Sicherheits- und Datenschutzgründen werden folgende Tabellen <strong>nie<\/strong> exportiert:<\/p>\n<ul><li><code>Token<\/code> (aktive Login-Sessions)<\/li><li><code>AuthEvent<\/code> (Login-Protokoll)<\/li><li><code>poweron_test<\/code> (Testdatenbank)<\/li><\/ul>\n<hr>\n<h2>3. Import<\/h2>\n<p>Ein Import spielt einen zuvor erstellten Export wieder ein. Typische Anwendungsfälle:<\/p>\n<ul><li>Wiederherstellung eines früheren Datenstands<\/li><li>Migration zwischen Umgebungen (z. B. Produktionsdaten auf die Testumgebung übertragen)<\/li><li>Initialisierung einer neuen Instanz<\/li><\/ul>\n<h3>3.1 Zwei Import-Modi<\/h3>\n<p><strong>Replace (Ersetzen):<\/strong> Löscht alle bestehenden Daten (ausser geschützte System-Objekte, siehe unten) und schreibt den Backup-Stand vollständig neu. Verwenden bei vollständiger Wiederherstellung.<\/p>\n<p><strong>Merge (Zusammenführen):<\/strong> Fügt nur Datensätze ein, die noch nicht existieren (anhand ID). Bestehende Daten bleiben unverändert. Verwenden wenn nur fehlende Daten ergänzt werden sollen.<\/p>\n<h3>3.2 Import via Admin-UI<\/h3>\n<ol><li>JSON-Datei hochladen<\/li><li>Validation läuft automatisch (prüft Format-Version, Struktur, System-Objekte)<\/li><li>Import-Modus wählen: <code>replace<\/code> oder <code>merge<\/code><\/li><li>Import starten — Ergebnis zeigt Anzahl eingespielter Datensätze pro Tabelle<\/li><\/ol>\n<p>Auch sehr grosse Backup-Dateien können problemlos importiert werden, ohne den Server zu überlasten.<\/p>\n<h3>3.3 Geschützte System-Objekte<\/h3>\n<p>Beim Import werden drei kritische Objekte <strong>nie gelöscht oder überschrieben<\/strong>, unabhängig vom Import-Modus:<\/p>\n<ul><li>Root-Mandat<\/li><li>Admin-Benutzer<\/li><li>Event-Benutzer<\/li><\/ul>\n<p>Falls diese Objekte im Backup andere interne Kennungen hatten als in der Zielumgebung, passt das System alle betroffenen Verknüpfungen <strong>automatisch<\/strong> an. Das verhindert inkonsistente Daten nach dem Import.<\/p>\n<h3>3.4 Import via Script<\/h3>\n<pre class=\"code\"><code>ssh ubuntu@api.poweron.swiss\ncd /srv/gateway/current\nsource .venv/bin/activate\nsudo systemctl stop gateway\n\n# Import-Script (Pendant zum Export-Script)\n# Datei übergeben, Modus wählen\npython scripts/script_db_export_migration.py --help  # zeigt alle Optionen\n\nsudo systemctl start gateway<\/code><\/pre>\n<hr>\n<h2>4. Backups &amp; Datensicherung<\/h2>\n<h3>4.1 Backup-Strategie<\/h3>\n<p>Die Plattform verfügt über ein durchdachtes, mehrschichtiges Sicherungskonzept:<\/p>\n<p><strong>Infrastruktur-Ebene:<\/strong> Der Datenbankserver läuft auf der Infomaniak Public Cloud, die Snapshot-Funktionalitäten für Managed Databases bereitstellt.<\/p>\n<p><strong>Anwendungs-Ebene:<\/strong> Über die integrierte Admin-UI kann jederzeit ein vollständiger Export aller Datenbanken erstellt werden — on-demand, gezielt pro Datenbank oder als Gesamtexport. Die Backup-Dateien sind vollständig portabel und können auf jedem Speicher archiviert werden.<\/p>\n<h3>4.2 Empfohlene Backup-Praxis<\/h3>\n<table><thead><tr><th>Zeitpunkt<\/th><th>Aktion<\/th><\/tr><\/thead><tbody><tr><td>Vor jedem Deployment<\/td><td>Export via Admin-UI, Datei lokal speichern<\/td><\/tr><tr><td>Vor Datenbank-Migrationen<\/td><td>Export erstellen und beschriftet archivieren<\/td><\/tr><tr><td>Wöchentlich<\/td><td>Export als Archiv-Backup ablegen<\/td><\/tr><\/tbody><\/table>\n<hr>\n<h2>5. Datenbankmigrationen (Struktur-Änderungen)<\/h2>\n<p>Wenn sich das Datenmodell weiterentwickelt — z. B. durch neue Felder oder Tabellen — stellt die Plattform dedizierte Hilfsprogramme bereit, die Datenbankstruktur kontrolliert und sicher anzupassen:<\/p>\n<table><thead><tr><th>Programm<\/th><th>Zweck<\/th><\/tr><\/thead><tbody><tr><td><code>script_db_adapt_to_models.py<\/code><\/td><td>Passt die Datenbankstruktur automatisch an den aktuellen Code an (mit Vorschau-Modus ohne Änderungen)<\/td><\/tr><tr><td><code>script_db_audit_legacy_state.py<\/code><\/td><td>Analysiert den Datenbankzustand vor einem Bereinigungsschritt<\/td><\/tr><tr><td><code>script_db_migrate_*.py<\/code><\/td><td>Datenmigrations-Programme für spezifische Features<\/td><\/tr><tr><td><code>script_db_init_automation2.py<\/code><\/td><td>Erstellt die Datenbankstruktur für das Automation-Feature<\/td><\/tr><tr><td><code>script_db_init_chatbot.py<\/code><\/td><td>Erstellt die Datenbankstruktur für das Chatbot-Feature<\/td><\/tr><\/tbody><\/table>\n<p>Beim Start der Anwendung prüft die Plattform ausserdem automatisch, ob alle benötigten Tabellen vorhanden sind, und legt fehlende selbstständig an.<\/p>\n<hr>\n<h2>6. Datenschutz-Hinweise<\/h2>\n<ul><li>Export-Dateien enthalten <strong>alle Kundendaten<\/strong> (Mandate, Benutzer, Chats, Dokumente, etc.) und sind entsprechend zu behandeln<\/li><li>Dateien dürfen <strong>nicht auf unsicheren Speichern<\/strong> (persönliche Dropbox, E-Mail, etc.) abgelegt werden<\/li><li>Export-Dateien sollten nach Nutzung gelöscht werden wenn sie nicht mehr benötigt werden<\/li><li>Der Zugriff auf Export/Import ist auf SysAdmins beschränkt und wird serverseitig geloggt<\/li><\/ul>\n<hr>\n<h2>Zusammenfassung: Datenbankoperationen im Überblick<\/h2>\n<table><thead><tr><th>Aufgabe<\/th><th>Wie<\/th><\/tr><\/thead><tbody><tr><td>Fehlende Tabellen beim Start anlegen<\/td><td>Automatisch beim Plattform-Start<\/td><\/tr><tr><td>Datenbank-Export / Backup<\/td><td>Admin-UI (ein Klick) oder Entwickler-Script<\/td><\/tr><tr><td>Datenbank-Import / Wiederherstellung<\/td><td>Admin-UI mit geführtem Prozess oder Entwickler-Script<\/td><\/tr><tr><td>Infrastruktur-Snapshots<\/td><td>Infomaniak Cloud (Serverebene)<\/td><\/tr><tr><td>Struktur-Anpassungen bei Updates<\/td><td>Kontrolliert durch Entwickler-Hilfsprogramme<\/td><\/tr><tr><td>Datenbankpflege &amp; Bereinigung<\/td><td>Admin-UI<\/td><\/tr><\/tbody><\/table>", "text": "# datenbank-handling: exports, imports, backups & datensicherung dieses dokument beschreibt, wie die poweron-plattform ihre datenbanken verwaltet — von der strukturierten datensicherung über flexible export- und import-werkzeuge bis hin zur sicheren wiederherstellung. --- ## 1. datenbankübersicht die plattform betreibt **13 separate datenbanken** auf dem datenbankserver `db.poweron.swiss`. jede datenbank gehört einem fachlichen bereich: | datenbank | inhalt | |---|---| | `poweron_app` | benutzer, mandate, berechtigungen, features — kern der plattform | | `poweron_management` | workflows, prompts, verbindungen (connections) | | `poweron_billing` | abonnements, rechnungen, stripe-daten | | `poweron_chat` | chat-konversationen und nachrichten | | `poweron_chatbot` | chatbot-feature: konversationen, logs | | `poweron_knowledge` | rag-wissensdatenbank, dokumentenindizes | | `poweron_workspace` | workspace-daten | | `poweron_trustee` | treuhand-spezifische daten | | `poweron_realestate` | immobilien-daten | | `poweron_commcoach` | commcoach-feature | | `poweron_neutralization` | content-neutralisierung | | `poweron_teamsbot` | microsoft teams bot | | `poweron_test` | testdaten (wird bei exports ausgeschlossen) | --- ## 2. export ein export erstellt eine vollständige kopie aller daten in einem lesbaren json-format. er dient als grundlage für backups, migrationen zwischen umgebungen (z. b. prod → int) und als sicherungspunkt vor grösseren änderungen. ### 2.1 export via admin-ui (empfohlen) im sysadmin-bereich der plattform gibt es einen integrierten export-button. er erzeugt eine json-datei, die direkt heruntergeladen wird. - **zugriff:** nur für sysadmins (höchste berechtigungsstufe) - **umfang:** alle datenbanken oder einzelne auswählbar - **dateiname:** `migration_backup_yyyy-mm-dd_hh-mm.json` - **rate-limit:** max. 2 exports pro minute (schutzmassnahme gegen versehentliche mehrfachausführung) auch sehr grosse datenbanken werden sicher übertragen, ohne dass der server dabei überlastet wird. ### 2.2 export via script (für entwickler / server-zugriff) direkt auf dem server kann das export-script ausgeführt werden: ```bash ssh ubuntu@api.poweron.swiss cd /srv/gateway/current source .venv/bin/activate # alle datenbanken exportieren python scripts/script_db_export_migration.py --pretty # nur bestimmte datenbanken python scripts/script_db_export_migration.py --db poweron_app,poweron_management # ohne metadaten (kleiner, für archivierung) python scripts/script_db_export_migration.py --exclude token,authevent # mit zusammenfassung (zeigt tabellen- und zeilenanzahl) python scripts/script_db_export_migration.py --summary ``` das script erstellt automatisch zwei dateien: - `migration_export_timestamp.json` — vollständige daten - `migration_export_timestamp_structure.json` — nur tabellenstruktur, keine daten ### 2.3 was wird beim export ausgeschlossen? aus sicherheits- und datenschutzgründen werden folgende tabellen **nie** exportiert: - `token` (aktive login-sessions) - `authevent` (login-protokoll) - `poweron_test` (testdatenbank) --- ## 3. import ein import spielt einen zuvor erstellten export wieder ein. typische anwendungsfälle: - wiederherstellung eines früheren datenstands - migration zwischen umgebungen (z. b. produktionsdaten auf die testumgebung übertragen) - initialisierung einer neuen instanz ### 3.1 zwei import-modi **replace (ersetzen):** löscht alle bestehenden daten (ausser geschützte system-objekte, siehe unten) und schreibt den backup-stand vollständig neu. verwenden bei vollständiger wiederherstellung. **merge (zusammenführen):** fügt nur datensätze ein, die noch nicht existieren (anhand id). bestehende daten bleiben unverändert. verwenden wenn nur fehlende daten ergänzt werden sollen. ### 3.2 import via admin-ui 1. json-datei hochladen 2. validation läuft automatisch (prüft format-version, struktur, system-objekte) 3. import-modus wählen: `replace` oder `merge` 4. import starten — ergebnis zeigt anzahl eingespielter datensätze pro tabelle auch sehr grosse backup-dateien können problemlos importiert werden, ohne den server zu überlasten. ### 3.3 geschützte system-objekte beim import werden drei kritische objekte **nie gelöscht oder überschrieben**, unabhängig vom import-modus: - root-mandat - admin-benutzer - event-benutzer falls diese objekte im backup andere interne kennungen hatten als in der zielumgebung, passt das system alle betroffenen verknüpfungen **automatisch** an. das verhindert inkonsistente daten nach dem import. ### 3.4 import via script ```bash ssh ubuntu@api.poweron.swiss cd /srv/gateway/current source .venv/bin/activate sudo systemctl stop gateway # import-script (pendant zum export-script) # datei übergeben, modus wählen python scripts/script_db_export_migration.py --help # zeigt alle optionen sudo systemctl start gateway ``` --- ## 4. backups & datensicherung ### 4.1 backup-strategie die plattform verfügt über ein durchdachtes, mehrschichtiges sicherungskonzept: **infrastruktur-ebene:** der datenbankserver läuft auf der infomaniak public cloud, die snapshot-funktionalitäten für managed databases bereitstellt. **anwendungs-ebene:** über die integrierte admin-ui kann jederzeit ein vollständiger export aller datenbanken erstellt werden — on-demand, gezielt pro datenbank oder als gesamtexport. die backup-dateien sind vollständig portabel und können auf jedem speicher archiviert werden. ### 4.2 empfohlene backup-praxis | zeitpunkt | aktion | |---|---| | vor jedem deployment | export via admin-ui, datei lokal speichern | | vor datenbank-migrationen | export erstellen und beschriftet archivieren | | wöchentlich | export als archiv-backup ablegen | --- ## 5. datenbankmigrationen (struktur-änderungen) wenn sich das datenmodell weiterentwickelt — z. b. durch neue felder oder tabellen — stellt die plattform dedizierte hilfsprogramme bereit, die datenbankstruktur kontrolliert und sicher anzupassen: | programm | zweck | |---|---| | `script_db_adapt_to_models.py` | passt die datenbankstruktur automatisch an den aktuellen code an (mit vorschau-modus ohne änderungen) | | `script_db_audit_legacy_state.py` | analysiert den datenbankzustand vor einem bereinigungsschritt | | `script_db_migrate_*.py` | datenmigrations-programme für spezifische features | | `script_db_init_automation2.py` | erstellt die datenbankstruktur für das automation-feature | | `script_db_init_chatbot.py` | erstellt die datenbankstruktur für das chatbot-feature | beim start der anwendung prüft die plattform ausserdem automatisch, ob alle benötigten tabellen vorhanden sind, und legt fehlende selbstständig an. --- ## 6. datenschutz-hinweise - export-dateien enthalten **alle kundendaten** (mandate, benutzer, chats, dokumente, etc.) und sind entsprechend zu behandeln - dateien dürfen **nicht auf unsicheren speichern** (persönliche dropbox, e-mail, etc.) abgelegt werden - export-dateien sollten nach nutzung gelöscht werden wenn sie nicht mehr benötigt werden - der zugriff auf export/import ist auf sysadmins beschränkt und wird serverseitig geloggt --- ## zusammenfassung: datenbankoperationen im überblick | aufgabe | wie | |---|---| | fehlende tabellen beim start anlegen | automatisch beim plattform-start | | datenbank-export / backup | admin-ui (ein klick) oder entwickler-script | | datenbank-import / wiederherstellung | admin-ui mit geführtem prozess oder entwickler-script | | infrastruktur-snapshots | infomaniak cloud (serverebene) | | struktur-anpassungen bei updates | kontrolliert durch entwickler-hilfsprogramme | | datenbankpflege & bereinigung | admin-ui | ", "nextReview": "", "overdueReview": false, "zuPruefen": []}, {"id": "05_betrieb/20260528_drittanbieter-inventar.md", "path": "05_betrieb/20260528_drittanbieter-inventar.md", "chapter": "05_betrieb", "title": "Drittanbieter-Inventar: Plattform-Core", "filename": "20260528_drittanbieter-inventar.md", "meta": {}, "html": "<h1>Drittanbieter-Inventar: Plattform-Core<\/h1>\n<p>Dieses Dokument listet alle externen Dienste und Plattformen auf, mit denen die PowerOn-Plattform direkt integriert ist. Es basiert auf einer Auswertung des Quellcodes (Stand: Mai 2026).<\/p>\n<p><strong>Verantwortlicher für alle Drittdienste:<\/strong> Patrick Motsch — p.motsch@poweron.swiss<\/p>\n<hr>\n<h2>1. KI-Provider (LLM)<\/h2>\n<p>Diese Dienste liefern die KI-Intelligenz der Plattform. Fällt einer aus, sind die entsprechenden AI-Features nicht mehr verfügbar, je nach Konfiguration kann auf einen anderen Provider ausgewichen werden.<\/p>\n<h3>OpenAI<\/h3>\n<table><thead><tr><th>Feld<\/th><th>Wert<\/th><\/tr><\/thead><tbody><tr><td><strong>Kategorie<\/strong><\/td><td>LLM-Provider<\/td><\/tr><tr><td><strong>Verwendung<\/strong><\/td><td>Chat-Completions, Embeddings für RAG/Suche, Bildgenerierung (DALL·E). Primärer AI-Provider.<\/td><\/tr><tr><td><strong>Kritikalität<\/strong><\/td><td>Ja — Ausfall betrifft Chat, Agent, Automation-Features<\/td><\/tr><tr><td><strong>Ansprechpartner<\/strong><\/td><td>Patrick Motsch — p.motsch@poweron.swiss<\/td><\/tr><tr><td><strong>Statusseite<\/strong><\/td><td>https://status.openai.com<\/td><\/tr><tr><td><strong>Vertragslaufzeit / Kündigung<\/strong><\/td><td>unbefristet<\/td><\/tr><\/tbody><\/table>\n<h3>Anthropic (Claude)<\/h3>\n<table><thead><tr><th>Feld<\/th><th>Wert<\/th><\/tr><\/thead><tbody><tr><td><strong>Kategorie<\/strong><\/td><td>LLM-Provider<\/td><\/tr><tr><td><strong>Verwendung<\/strong><\/td><td>Chat-Completions, Agent-Workflows als Alternative zu OpenAI<\/td><\/tr><tr><td><strong>Kritikalität<\/strong><\/td><td>Nein — nur wenn als aktiver Provider konfiguriert<\/td><\/tr><tr><td><strong>Ansprechpartner<\/strong><\/td><td>Patrick Motsch — p.motsch@poweron.swiss<\/td><\/tr><tr><td><strong>Statusseite<\/strong><\/td><td>https://status.anthropic.com<\/td><\/tr><tr><td><strong>Vertragslaufzeit / Kündigung<\/strong><\/td><td>unbefristet<\/td><\/tr><\/tbody><\/table>\n<h3>Mistral AI<\/h3>\n<table><thead><tr><th>Feld<\/th><th>Wert<\/th><\/tr><\/thead><tbody><tr><td><strong>Kategorie<\/strong><\/td><td>LLM-Provider<\/td><\/tr><tr><td><strong>Verwendung<\/strong><\/td><td>Chat-Completions und Embeddings als Alternative zu OpenAI<\/td><\/tr><tr><td><strong>Kritikalität<\/strong><\/td><td>Nein — nur wenn als aktiver Provider konfiguriert<\/td><\/tr><tr><td><strong>Ansprechpartner<\/strong><\/td><td>Patrick Motsch — p.motsch@poweron.swiss<\/td><\/tr><tr><td><strong>Statusseite<\/strong><\/td><td>https://mistral.ai/status<\/td><\/tr><tr><td><strong>Vertragslaufzeit / Kündigung<\/strong><\/td><td>unbefristet<\/td><\/tr><\/tbody><\/table>\n<h3>Perplexity AI<\/h3>\n<table><thead><tr><th>Feld<\/th><th>Wert<\/th><\/tr><\/thead><tbody><tr><td><strong>Kategorie<\/strong><\/td><td>LLM-Provider (mit Web-Zugriff)<\/td><\/tr><tr><td><strong>Verwendung<\/strong><\/td><td>Chat-Completions mit integrierter Websuche<\/td><\/tr><tr><td><strong>Kritikalität<\/strong><\/td><td>Nein — optionaler Provider<\/td><\/tr><tr><td><strong>Ansprechpartner<\/strong><\/td><td>Patrick Motsch — p.motsch@poweron.swiss<\/td><\/tr><tr><td><strong>Statusseite<\/strong><\/td><td>https://status.perplexity.ai<\/td><\/tr><tr><td><strong>Vertragslaufzeit / Kündigung<\/strong><\/td><td>unbefristet<\/td><\/tr><\/tbody><\/table>\n<h3>Tavily<\/h3>\n<table><thead><tr><th>Feld<\/th><th>Wert<\/th><\/tr><\/thead><tbody><tr><td><strong>Kategorie<\/strong><\/td><td>AI-Websuche<\/td><\/tr><tr><td><strong>Verwendung<\/strong><\/td><td>Echtzeit-Websuche für AI-Agenten und LangChain-Workflows<\/td><\/tr><tr><td><strong>Kritikalität<\/strong><\/td><td>Nein — betrifft nur Research-/Agent-Features<\/td><\/tr><tr><td><strong>Ansprechpartner<\/strong><\/td><td>Patrick Motsch — p.motsch@poweron.swiss<\/td><\/tr><tr><td><strong>Statusseite<\/strong><\/td><td>https://status.tavily.com<\/td><\/tr><tr><td><strong>Vertragslaufzeit / Kündigung<\/strong><\/td><td>unbefristet<\/td><\/tr><\/tbody><\/table>\n<hr>\n<h2>2. Infrastruktur &amp; Hosting<\/h2>\n<h3>Infomaniak (Server &amp; Datenbank)<\/h3>\n<table><thead><tr><th>Feld<\/th><th>Wert<\/th><\/tr><\/thead><tbody><tr><td><strong>Kategorie<\/strong><\/td><td>Cloud Hosting / Managed Database<\/td><\/tr><tr><td><strong>Verwendung<\/strong><\/td><td>VM-Hosting für Prod- und Int-Server (<code>api.poweron.swiss<\/code>, <code>api-int.poweron.swiss<\/code>), PostgreSQL-Datenbank (<code>db.poweron.swiss<\/code>)<\/td><\/tr><tr><td><strong>Kritikalität<\/strong><\/td><td><strong>Ja<\/strong> — Totalausfall der Plattform bei Ausfall<\/td><\/tr><tr><td><strong>Ansprechpartner<\/strong><\/td><td>Patrick Motsch — p.motsch@poweron.swiss<\/td><\/tr><tr><td><strong>Statusseite<\/strong><\/td><td>https://status.infomaniak.com<\/td><\/tr><tr><td><strong>Vertragslaufzeit / Kündigung<\/strong><\/td><td>unbefristet<\/td><\/tr><\/tbody><\/table>\n<hr>\n<h2>3. Authentifizierung &amp; Login<\/h2>\n<h3>Microsoft Azure AD (OAuth)<\/h3>\n<table><thead><tr><th>Feld<\/th><th>Wert<\/th><\/tr><\/thead><tbody><tr><td><strong>Kategorie<\/strong><\/td><td>Auth / Identity Provider<\/td><\/tr><tr><td><strong>Verwendung<\/strong><\/td><td>Login via Microsoft-Konto (OAuth 2.0). Auch Basis für Microsoft 365 Datenzugriff.<\/td><\/tr><tr><td><strong>Kritikalität<\/strong><\/td><td>Ja — Login für Microsoft-Nutzer nicht möglich bei Ausfall<\/td><\/tr><tr><td><strong>Ansprechpartner<\/strong><\/td><td>Patrick Motsch — p.motsch@poweron.swiss<\/td><\/tr><tr><td><strong>Statusseite<\/strong><\/td><td>https://status.azure.com<\/td><\/tr><tr><td><strong>Vertragslaufzeit / Kündigung<\/strong><\/td><td>Kundenseitig<\/td><\/tr><\/tbody><\/table>\n<h3>Google OAuth<\/h3>\n<table><thead><tr><th>Feld<\/th><th>Wert<\/th><\/tr><\/thead><tbody><tr><td><strong>Kategorie<\/strong><\/td><td>Auth / Identity Provider<\/td><\/tr><tr><td><strong>Verwendung<\/strong><\/td><td>Login via Google-Konto. Auch Basis für Google Workspace Datenzugriff.<\/td><\/tr><tr><td><strong>Kritikalität<\/strong><\/td><td>Ja — Login für Google-Nutzer nicht möglich bei Ausfall<\/td><\/tr><tr><td><strong>Ansprechpartner<\/strong><\/td><td>Patrick Motsch — p.motsch@poweron.swiss<\/td><\/tr><tr><td><strong>Statusseite<\/strong><\/td><td>https://www.google.com/appsstatus<\/td><\/tr><tr><td><strong>Vertragslaufzeit / Kündigung<\/strong><\/td><td>Kundenseitig<\/td><\/tr><\/tbody><\/table>\n<hr>\n<h2>4. Daten-Konnektoren (Dateiablage, Kalender, Kontakte)<\/h2>\n<p>Diese Dienste sind optionale Verbindungen, die Endkunden in ihrer Mandanten-Konfiguration aktivieren können. Ein Ausfall betrifft die Kunden, die diesen Konnektor aktiv nutzen.<\/p>\n<h3>Microsoft 365 (SharePoint / OneDrive / Outlook / Calendar)<\/h3>\n<table><thead><tr><th>Feld<\/th><th>Wert<\/th><\/tr><\/thead><tbody><tr><td><strong>Kategorie<\/strong><\/td><td>Datei- &amp; Kommunikationsplattform (Konnektor)<\/td><\/tr><tr><td><strong>Verwendung<\/strong><\/td><td>Dateizugriff auf SharePoint/OneDrive, E-Mail-Lesen und -Senden via Outlook, Kalender-Integration via Microsoft Graph API<\/td><\/tr><tr><td><strong>Kritikalität<\/strong><\/td><td>Nein (nur für Kunden mit aktivem MS365-Konnektor)<\/td><\/tr><tr><td><strong>Ansprechpartner<\/strong><\/td><td>Patrick Motsch — p.motsch@poweron.swiss<\/td><\/tr><tr><td><strong>Statusseite<\/strong><\/td><td>https://status.office365.com<\/td><\/tr><tr><td><strong>Vertragslaufzeit / Kündigung<\/strong><\/td><td>Kundenseitig (eigenes Microsoft-Konto des Kunden)<\/td><\/tr><\/tbody><\/table>\n<h3>Google Workspace (Drive / Gmail / Calendar / Contacts)<\/h3>\n<table><thead><tr><th>Feld<\/th><th>Wert<\/th><\/tr><\/thead><tbody><tr><td><strong>Kategorie<\/strong><\/td><td>Datei- &amp; Kommunikationsplattform (Konnektor)<\/td><\/tr><tr><td><strong>Verwendung<\/strong><\/td><td>Dateizugriff auf Google Drive, Gmail lesen/senden, Google Calendar, Google Contacts via Google APIs<\/td><\/tr><tr><td><strong>Kritikalität<\/strong><\/td><td>Nein (nur für Kunden mit aktivem Google-Konnektor)<\/td><\/tr><tr><td><strong>Ansprechpartner<\/strong><\/td><td>Patrick Motsch — p.motsch@poweron.swiss<\/td><\/tr><tr><td><strong>Statusseite<\/strong><\/td><td>https://www.google.com/appsstatus<\/td><\/tr><tr><td><strong>Vertragslaufzeit / Kündigung<\/strong><\/td><td>Kundenseitig<\/td><\/tr><\/tbody><\/table>\n<h3>Infomaniak (kDrive / Kalender / Kontakte)<\/h3>\n<table><thead><tr><th>Feld<\/th><th>Wert<\/th><\/tr><\/thead><tbody><tr><td><strong>Kategorie<\/strong><\/td><td>Datei- &amp; Kommunikationsplattform (Konnektor)<\/td><\/tr><tr><td><strong>Verwendung<\/strong><\/td><td>Dateizugriff auf kDrive, Infomaniak Calendar, Infomaniak Contacts via Personal Access Token<\/td><\/tr><tr><td><strong>Kritikalität<\/strong><\/td><td>Nein (nur für Kunden mit aktivem Infomaniak-Konnektor)<\/td><\/tr><tr><td><strong>Ansprechpartner<\/strong><\/td><td>Patrick Motsch — p.motsch@poweron.swiss<\/td><\/tr><tr><td><strong>Statusseite<\/strong><\/td><td>https://status.infomaniak.com<\/td><\/tr><tr><td><strong>Vertragslaufzeit / Kündigung<\/strong><\/td><td>Kundenseitig<\/td><\/tr><\/tbody><\/table>\n<h3>FTP<\/h3>\n<table><thead><tr><th>Feld<\/th><th>Wert<\/th><\/tr><\/thead><tbody><tr><td><strong>Kategorie<\/strong><\/td><td>Dateikonnektor<\/td><\/tr><tr><td><strong>Verwendung<\/strong><\/td><td>Generischer FTP/SFTP-Zugriff für Kunden mit FTP-Verbindung<\/td><\/tr><tr><td><strong>Kritikalität<\/strong><\/td><td>Nein (nur für Kunden mit aktivem FTP-Konnektor)<\/td><\/tr><tr><td><strong>Ansprechpartner<\/strong><\/td><td>Patrick Motsch — p.motsch@poweron.swiss<\/td><\/tr><tr><td><strong>Statusseite<\/strong><\/td><td>Kundenseitig<\/td><\/tr><tr><td><strong>Vertragslaufzeit / Kündigung<\/strong><\/td><td>Kundenseitig<\/td><\/tr><\/tbody><\/table>\n<hr>\n<h2>5. Ticket-Systeme (Konnektoren)<\/h2>\n<h3>ClickUp<\/h3>\n<table><thead><tr><th>Feld<\/th><th>Wert<\/th><\/tr><\/thead><tbody><tr><td><strong>Kategorie<\/strong><\/td><td>Projektmanagement / Ticketing (Konnektor)<\/td><\/tr><tr><td><strong>Verwendung<\/strong><\/td><td>Aufgaben und Tickets lesen/erstellen/aktualisieren via ClickUp API v2 und OAuth<\/td><\/tr><tr><td><strong>Kritikalität<\/strong><\/td><td>Nein (nur für Kunden mit aktivem ClickUp-Konnektor)<\/td><\/tr><tr><td><strong>Ansprechpartner<\/strong><\/td><td>Patrick Motsch — p.motsch@poweron.swiss<\/td><\/tr><tr><td><strong>Statusseite<\/strong><\/td><td>https://clickupstatus.com<\/td><\/tr><tr><td><strong>Vertragslaufzeit / Kündigung<\/strong><\/td><td>Kundenseitig<\/td><\/tr><\/tbody><\/table>\n<h3>Jira<\/h3>\n<table><thead><tr><th>Feld<\/th><th>Wert<\/th><\/tr><\/thead><tbody><tr><td><strong>Kategorie<\/strong><\/td><td>Projektmanagement / Ticketing (Konnektor)<\/td><\/tr><tr><td><strong>Verwendung<\/strong><\/td><td>Tickets lesen/erstellen via Jira REST API<\/td><\/tr><tr><td><strong>Kritikalität<\/strong><\/td><td>Nein (nur für Kunden mit aktivem Jira-Konnektor)<\/td><\/tr><tr><td><strong>Ansprechpartner<\/strong><\/td><td>Patrick Motsch — p.motsch@poweron.swiss<\/td><\/tr><tr><td><strong>Statusseite<\/strong><\/td><td>https://jira-software.status.atlassian.com<\/td><\/tr><tr><td><strong>Vertragslaufzeit / Kündigung<\/strong><\/td><td>Kundenseitig<\/td><\/tr><\/tbody><\/table>\n<h3>Redmine<\/h3>\n<table><thead><tr><th>Feld<\/th><th>Wert<\/th><\/tr><\/thead><tbody><tr><td><strong>Kategorie<\/strong><\/td><td>Projektmanagement / Ticketing (Konnektor)<\/td><\/tr><tr><td><strong>Verwendung<\/strong><\/td><td>Tickets lesen/erstellen via Redmine REST API<\/td><\/tr><tr><td><strong>Kritikalität<\/strong><\/td><td>Nein (nur für Kunden mit aktivem Redmine-Konnektor)<\/td><\/tr><tr><td><strong>Ansprechpartner<\/strong><\/td><td>Patrick Motsch — p.motsch@poweron.swiss<\/td><\/tr><tr><td><strong>Statusseite<\/strong><\/td><td>Kundenseitig<\/td><\/tr><tr><td><strong>Vertragslaufzeit / Kündigung<\/strong><\/td><td>Kundenseitig<\/td><\/tr><\/tbody><\/table>\n<hr>\n<h2>6. Payment<\/h2>\n<h3>Stripe<\/h3>\n<table><thead><tr><th>Feld<\/th><th>Wert<\/th><\/tr><\/thead><tbody><tr><td><strong>Kategorie<\/strong><\/td><td>Payment Provider<\/td><\/tr><tr><td><strong>Verwendung<\/strong><\/td><td>Abonnement-Management, Zahlungsabwicklung, automatische Steuerberechnung (CH MwSt). API-Version <code>2026-01-28<\/code>.<\/td><\/tr><tr><td><strong>Kritikalität<\/strong><\/td><td><strong>Ja<\/strong> — Neue Abonnements und Zahlungen schlagen fehl bei Ausfall<\/td><\/tr><tr><td><strong>Ansprechpartner<\/strong><\/td><td>Patrick Motsch — p.motsch@poweron.swiss<\/td><\/tr><tr><td><strong>Statusseite<\/strong><\/td><td>https://status.stripe.com<\/td><\/tr><tr><td><strong>Vertragslaufzeit / Kündigung<\/strong><\/td><td>unbefristet<\/td><\/tr><\/tbody><\/table>\n<hr>\n<h2>7. Messaging &amp; Kommunikation<\/h2>\n<h3>Azure Communication Services (E-Mail)<\/h3>\n<table><thead><tr><th>Feld<\/th><th>Wert<\/th><\/tr><\/thead><tbody><tr><td><strong>Kategorie<\/strong><\/td><td>Transaktions-E-Mail<\/td><\/tr><tr><td><strong>Verwendung<\/strong><\/td><td>Systemmails (Einladungen, Passwort-Reset, Rechnungen) via <code>DoNotReply@poweron.swiss<\/code>. Endpunkt: <code>mailing-poweron-prod.switzerland.communication.azure.com<\/code><\/td><\/tr><tr><td><strong>Kritikalität<\/strong><\/td><td><strong>Ja<\/strong> — Einladungs- und Benachrichtigungs-E-Mails werden nicht zugestellt<\/td><\/tr><tr><td><strong>Ansprechpartner<\/strong><\/td><td>Patrick Motsch — p.motsch@poweron.swiss<\/td><\/tr><tr><td><strong>Statusseite<\/strong><\/td><td>https://status.azure.com<\/td><\/tr><tr><td><strong>Vertragslaufzeit / Kündigung<\/strong><\/td><td>unbefristet<\/td><\/tr><\/tbody><\/table>\n<h3>Twilio (SMS)<\/h3>\n<table><thead><tr><th>Feld<\/th><th>Wert<\/th><\/tr><\/thead><tbody><tr><td><strong>Kategorie<\/strong><\/td><td>SMS-Gateway<\/td><\/tr><tr><td><strong>Verwendung<\/strong><\/td><td>SMS-Versand (z. B. 2FA, Benachrichtigungen)<\/td><\/tr><tr><td><strong>Kritikalität<\/strong><\/td><td>Nein — nur wenn SMS-Feature aktiv genutzt wird<\/td><\/tr><tr><td><strong>Ansprechpartner<\/strong><\/td><td>Patrick Motsch — p.motsch@poweron.swiss<\/td><\/tr><tr><td><strong>Statusseite<\/strong><\/td><td>https://status.twilio.com<\/td><\/tr><tr><td><strong>Vertragslaufzeit / Kündigung<\/strong><\/td><td>unbefristet<\/td><\/tr><\/tbody><\/table>\n<hr>\n<h2>8. Google Cloud Services<\/h2>\n<h3>Google Cloud Speech-to-Text / Text-to-Speech<\/h3>\n<table><thead><tr><th>Feld<\/th><th>Wert<\/th><\/tr><\/thead><tbody><tr><td><strong>Kategorie<\/strong><\/td><td>Sprach-KI (STT/TTS)<\/td><\/tr><tr><td><strong>Verwendung<\/strong><\/td><td>Sprache-zu-Text-Transkription und Text-zu-Sprache-Synthese für Voice-Features<\/td><\/tr><tr><td><strong>Kritikalität<\/strong><\/td><td>Nein — betrifft nur Voice-Features<\/td><\/tr><tr><td><strong>Ansprechpartner<\/strong><\/td><td>Patrick Motsch — p.motsch@poweron.swiss<\/td><\/tr><tr><td><strong>Statusseite<\/strong><\/td><td>https://status.cloud.google.com<\/td><\/tr><tr><td><strong>Vertragslaufzeit / Kündigung<\/strong><\/td><td>unbefristet<\/td><\/tr><\/tbody><\/table>\n<h3>Google Cloud Translate<\/h3>\n<table><thead><tr><th>Feld<\/th><th>Wert<\/th><\/tr><\/thead><tbody><tr><td><strong>Kategorie<\/strong><\/td><td>Übersetzungsdienst<\/td><\/tr><tr><td><strong>Verwendung<\/strong><\/td><td>Automatische Übersetzung von Inhalten<\/td><\/tr><tr><td><strong>Kritikalität<\/strong><\/td><td>Nein — betrifft nur Übersetzungsfeatures<\/td><\/tr><tr><td><strong>Ansprechpartner<\/strong><\/td><td>Patrick Motsch — p.motsch@poweron.swiss<\/td><\/tr><tr><td><strong>Statusseite<\/strong><\/td><td>https://status.cloud.google.com<\/td><\/tr><tr><td><strong>Vertragslaufzeit / Kündigung<\/strong><\/td><td>unbefristet<\/td><\/tr><\/tbody><\/table>\n<hr>\n<h2>9. Schweizer Geodienste (öffentliche APIs)<\/h2>\n<p>Diese Dienste sind öffentlich zugängliche Schnittstellen des Bundes und der Kantone. Kein Login, kein Vertrag erforderlich — aber ein Ausfall beeinträchtigt Geo-Features.<\/p>\n<h3>swisstopo MapServer &amp; Geocoding<\/h3>\n<table><thead><tr><th>Feld<\/th><th>Wert<\/th><\/tr><\/thead><tbody><tr><td><strong>Kategorie<\/strong><\/td><td>Geodaten / Kartendienst<\/td><\/tr><tr><td><strong>Verwendung<\/strong><\/td><td>Adress-Geocoding, Karteninformationen, Parzellen-Identifikation via <code>api3.geo.admin.ch<\/code><\/td><\/tr><tr><td><strong>Kritikalität<\/strong><\/td><td>Nein — betrifft nur Immobilien-/Geo-Features<\/td><\/tr><tr><td><strong>Ansprechpartner<\/strong><\/td><td>Patrick Motsch — p.motsch@poweron.swiss<\/td><\/tr><tr><td><strong>Statusseite<\/strong><\/td><td>https://www.geo.admin.ch<\/td><\/tr><tr><td><strong>Vertragslaufzeit / Kündigung<\/strong><\/td><td>Kostenloser öffentlicher Dienst<\/td><\/tr><\/tbody><\/table>\n<h3>STAC API (swisstopo)<\/h3>\n<table><thead><tr><th>Feld<\/th><th>Wert<\/th><\/tr><\/thead><tbody><tr><td><strong>Kategorie<\/strong><\/td><td>Geodaten (Satellitenbilder / Rasterdaten)<\/td><\/tr><tr><td><strong>Verwendung<\/strong><\/td><td>Zugriff auf georäumliche Katalogdaten via <code>data.geo.admin.ch<\/code><\/td><\/tr><tr><td><strong>Kritikalität<\/strong><\/td><td>Nein — betrifft nur Geo-Features<\/td><\/tr><tr><td><strong>Ansprechpartner<\/strong><\/td><td>Patrick Motsch — p.motsch@poweron.swiss<\/td><\/tr><tr><td><strong>Statusseite<\/strong><\/td><td>https://www.geo.admin.ch<\/td><\/tr><tr><td><strong>Vertragslaufzeit / Kündigung<\/strong><\/td><td>Kostenloser öffentlicher Dienst<\/td><\/tr><\/tbody><\/table>\n<h3>ÖREB-Kataster WFS (Kanton Zürich)<\/h3>\n<table><thead><tr><th>Feld<\/th><th>Wert<\/th><\/tr><\/thead><tbody><tr><td><strong>Kategorie<\/strong><\/td><td>Geodaten / Rechtliche Grundlagen Grundstücke<\/td><\/tr><tr><td><strong>Verwendung<\/strong><\/td><td>Abruf öffentlich-rechtlicher Eigentumsbeschränkungen (ÖREB) für Parzellen via <code>maps.zh.ch<\/code><\/td><\/tr><tr><td><strong>Kritikalität<\/strong><\/td><td>Nein — betrifft nur Immobilien-Features (ZH)<\/td><\/tr><tr><td><strong>Ansprechpartner<\/strong><\/td><td>Patrick Motsch — p.motsch@poweron.swiss<\/td><\/tr><tr><td><strong>Statusseite<\/strong><\/td><td>https://www.zh.ch/de/direktion-der-justiz-und-des-innern/geoinformation.html<\/td><\/tr><tr><td><strong>Vertragslaufzeit / Kündigung<\/strong><\/td><td>Kostenloser öffentlicher Dienst<\/td><\/tr><\/tbody><\/table>\n<h3>Geodienste.ch (Amtliche Vermessung ZH)<\/h3>\n<table><thead><tr><th>Feld<\/th><th>Wert<\/th><\/tr><\/thead><tbody><tr><td><strong>Kategorie<\/strong><\/td><td>Geodaten / Amtliche Vermessung<\/td><\/tr><tr><td><strong>Verwendung<\/strong><\/td><td>WFS-Abfragen für Parzellensuche via <code>www.geodienste.ch<\/code><\/td><\/tr><tr><td><strong>Kritikalität<\/strong><\/td><td>Nein — betrifft nur Immobilien-Features<\/td><\/tr><tr><td><strong>Ansprechpartner<\/strong><\/td><td>Patrick Motsch — p.motsch@poweron.swiss<\/td><\/tr><tr><td><strong>Statusseite<\/strong><\/td><td>https://www.geodienste.ch<\/td><\/tr><tr><td><strong>Vertragslaufzeit / Kündigung<\/strong><\/td><td>Kostenloser öffentlicher Dienst<\/td><\/tr><\/tbody><\/table>", "text": "# drittanbieter-inventar: plattform-core dieses dokument listet alle externen dienste und plattformen auf, mit denen die poweron-plattform direkt integriert ist. es basiert auf einer auswertung des quellcodes (stand: mai 2026). **verantwortlicher für alle drittdienste:** patrick motsch — p.motsch@poweron.swiss --- ## 1. ki-provider (llm) diese dienste liefern die ki-intelligenz der plattform. fällt einer aus, sind die entsprechenden ai-features nicht mehr verfügbar, je nach konfiguration kann auf einen anderen provider ausgewichen werden. ### openai | feld | wert | |---|---| | **kategorie** | llm-provider | | **verwendung** | chat-completions, embeddings für rag/suche, bildgenerierung (dall·e). primärer ai-provider. | | **kritikalität** | ja — ausfall betrifft chat, agent, automation-features | | **ansprechpartner** | patrick motsch — p.motsch@poweron.swiss | | **statusseite** | https://status.openai.com | | **vertragslaufzeit / kündigung** | unbefristet | ### anthropic (claude) | feld | wert | |---|---| | **kategorie** | llm-provider | | **verwendung** | chat-completions, agent-workflows als alternative zu openai | | **kritikalität** | nein — nur wenn als aktiver provider konfiguriert | | **ansprechpartner** | patrick motsch — p.motsch@poweron.swiss | | **statusseite** | https://status.anthropic.com | | **vertragslaufzeit / kündigung** | unbefristet | ### mistral ai | feld | wert | |---|---| | **kategorie** | llm-provider | | **verwendung** | chat-completions und embeddings als alternative zu openai | | **kritikalität** | nein — nur wenn als aktiver provider konfiguriert | | **ansprechpartner** | patrick motsch — p.motsch@poweron.swiss | | **statusseite** | https://mistral.ai/status | | **vertragslaufzeit / kündigung** | unbefristet | ### perplexity ai | feld | wert | |---|---| | **kategorie** | llm-provider (mit web-zugriff) | | **verwendung** | chat-completions mit integrierter websuche | | **kritikalität** | nein — optionaler provider | | **ansprechpartner** | patrick motsch — p.motsch@poweron.swiss | | **statusseite** | https://status.perplexity.ai | | **vertragslaufzeit / kündigung** | unbefristet | ### tavily | feld | wert | |---|---| | **kategorie** | ai-websuche | | **verwendung** | echtzeit-websuche für ai-agenten und langchain-workflows | | **kritikalität** | nein — betrifft nur research-/agent-features | | **ansprechpartner** | patrick motsch — p.motsch@poweron.swiss | | **statusseite** | https://status.tavily.com | | **vertragslaufzeit / kündigung** | unbefristet | --- ## 2. infrastruktur & hosting ### infomaniak (server & datenbank) | feld | wert | |---|---| | **kategorie** | cloud hosting / managed database | | **verwendung** | vm-hosting für prod- und int-server (`api.poweron.swiss`, `api-int.poweron.swiss`), postgresql-datenbank (`db.poweron.swiss`) | | **kritikalität** | **ja** — totalausfall der plattform bei ausfall | | **ansprechpartner** | patrick motsch — p.motsch@poweron.swiss | | **statusseite** | https://status.infomaniak.com | | **vertragslaufzeit / kündigung** | unbefristet | --- ## 3. authentifizierung & login ### microsoft azure ad (oauth) | feld | wert | |---|---| | **kategorie** | auth / identity provider | | **verwendung** | login via microsoft-konto (oauth 2.0). auch basis für microsoft 365 datenzugriff. | | **kritikalität** | ja — login für microsoft-nutzer nicht möglich bei ausfall | | **ansprechpartner** | patrick motsch — p.motsch@poweron.swiss | | **statusseite** | https://status.azure.com | | **vertragslaufzeit / kündigung** | kundenseitig | ### google oauth | feld | wert | |---|---| | **kategorie** | auth / identity provider | | **verwendung** | login via google-konto. auch basis für google workspace datenzugriff. | | **kritikalität** | ja — login für google-nutzer nicht möglich bei ausfall | | **ansprechpartner** | patrick motsch — p.motsch@poweron.swiss | | **statusseite** | https://www.google.com/appsstatus | | **vertragslaufzeit / kündigung** | kundenseitig | --- ## 4. daten-konnektoren (dateiablage, kalender, kontakte) diese dienste sind optionale verbindungen, die endkunden in ihrer mandanten-konfiguration aktivieren können. ein ausfall betrifft die kunden, die diesen konnektor aktiv nutzen. ### microsoft 365 (sharepoint / onedrive / outlook / calendar) | feld | wert | |---|---| | **kategorie** | datei- & kommunikationsplattform (konnektor) | | **verwendung** | dateizugriff auf sharepoint/onedrive, e-mail-lesen und -senden via outlook, kalender-integration via microsoft graph api | | **kritikalität** | nein (nur für kunden mit aktivem ms365-konnektor) | | **ansprechpartner** | patrick motsch — p.motsch@poweron.swiss | | **statusseite** | https://status.office365.com | | **vertragslaufzeit / kündigung** | kundenseitig (eigenes microsoft-konto des kunden) | ### google workspace (drive / gmail / calendar / contacts) | feld | wert | |---|---| | **kategorie** | datei- & kommunikationsplattform (konnektor) | | **verwendung** | dateizugriff auf google drive, gmail lesen/senden, google calendar, google contacts via google apis | | **kritikalität** | nein (nur für kunden mit aktivem google-konnektor) | | **ansprechpartner** | patrick motsch — p.motsch@poweron.swiss | | **statusseite** | https://www.google.com/appsstatus | | **vertragslaufzeit / kündigung** | kundenseitig | ### infomaniak (kdrive / kalender / kontakte) | feld | wert | |---|---| | **kategorie** | datei- & kommunikationsplattform (konnektor) | | **verwendung** | dateizugriff auf kdrive, infomaniak calendar, infomaniak contacts via personal access token | | **kritikalität** | nein (nur für kunden mit aktivem infomaniak-konnektor) | | **ansprechpartner** | patrick motsch — p.motsch@poweron.swiss | | **statusseite** | https://status.infomaniak.com | | **vertragslaufzeit / kündigung** | kundenseitig | ### ftp | feld | wert | |---|---| | **kategorie** | dateikonnektor | | **verwendung** | generischer ftp/sftp-zugriff für kunden mit ftp-verbindung | | **kritikalität** | nein (nur für kunden mit aktivem ftp-konnektor) | | **ansprechpartner** | patrick motsch — p.motsch@poweron.swiss | | **statusseite** | kundenseitig | | **vertragslaufzeit / kündigung** | kundenseitig | --- ## 5. ticket-systeme (konnektoren) ### clickup | feld | wert | |---|---| | **kategorie** | projektmanagement / ticketing (konnektor) | | **verwendung** | aufgaben und tickets lesen/erstellen/aktualisieren via clickup api v2 und oauth | | **kritikalität** | nein (nur für kunden mit aktivem clickup-konnektor) | | **ansprechpartner** | patrick motsch — p.motsch@poweron.swiss | | **statusseite** | https://clickupstatus.com | | **vertragslaufzeit / kündigung** | kundenseitig | ### jira | feld | wert | |---|---| | **kategorie** | projektmanagement / ticketing (konnektor) | | **verwendung** | tickets lesen/erstellen via jira rest api | | **kritikalität** | nein (nur für kunden mit aktivem jira-konnektor) | | **ansprechpartner** | patrick motsch — p.motsch@poweron.swiss | | **statusseite** | https://jira-software.status.atlassian.com | | **vertragslaufzeit / kündigung** | kundenseitig | ### redmine | feld | wert | |---|---| | **kategorie** | projektmanagement / ticketing (konnektor) | | **verwendung** | tickets lesen/erstellen via redmine rest api | | **kritikalität** | nein (nur für kunden mit aktivem redmine-konnektor) | | **ansprechpartner** | patrick motsch — p.motsch@poweron.swiss | | **statusseite** | kundenseitig | | **vertragslaufzeit / kündigung** | kundenseitig | --- ## 6. payment ### stripe | feld | wert | |---|---| | **kategorie** | payment provider | | **verwendung** | abonnement-management, zahlungsabwicklung, automatische steuerberechnung (ch mwst). api-version `2026-01-28`. | | **kritikalität** | **ja** — neue abonnements und zahlungen schlagen fehl bei ausfall | | **ansprechpartner** | patrick motsch — p.motsch@poweron.swiss | | **statusseite** | https://status.stripe.com | | **vertragslaufzeit / kündigung** | unbefristet | --- ## 7. messaging & kommunikation ### azure communication services (e-mail) | feld | wert | |---|---| | **kategorie** | transaktions-e-mail | | **verwendung** | systemmails (einladungen, passwort-reset, rechnungen) via `donotreply@poweron.swiss`. endpunkt: `mailing-poweron-prod.switzerland.communication.azure.com` | | **kritikalität** | **ja** — einladungs- und benachrichtigungs-e-mails werden nicht zugestellt | | **ansprechpartner** | patrick motsch — p.motsch@poweron.swiss | | **statusseite** | https://status.azure.com | | **vertragslaufzeit / kündigung** | unbefristet | ### twilio (sms) | feld | wert | |---|---| | **kategorie** | sms-gateway | | **verwendung** | sms-versand (z. b. 2fa, benachrichtigungen) | | **kritikalität** | nein — nur wenn sms-feature aktiv genutzt wird | | **ansprechpartner** | patrick motsch — p.motsch@poweron.swiss | | **statusseite** | https://status.twilio.com | | **vertragslaufzeit / kündigung** | unbefristet | --- ## 8. google cloud services ### google cloud speech-to-text / text-to-speech | feld | wert | |---|---| | **kategorie** | sprach-ki (stt/tts) | | **verwendung** | sprache-zu-text-transkription und text-zu-sprache-synthese für voice-features | | **kritikalität** | nein — betrifft nur voice-features | | **ansprechpartner** | patrick motsch — p.motsch@poweron.swiss | | **statusseite** | https://status.cloud.google.com | | **vertragslaufzeit / kündigung** | unbefristet | ### google cloud translate | feld | wert | |---|---| | **kategorie** | übersetzungsdienst | | **verwendung** | automatische übersetzung von inhalten | | **kritikalität** | nein — betrifft nur übersetzungsfeatures | | **ansprechpartner** | patrick motsch — p.motsch@poweron.swiss | | **statusseite** | https://status.cloud.google.com | | **vertragslaufzeit / kündigung** | unbefristet | --- ## 9. schweizer geodienste (öffentliche apis) diese dienste sind öffentlich zugängliche schnittstellen des bundes und der kantone. kein login, kein vertrag erforderlich — aber ein ausfall beeinträchtigt geo-features. ### swisstopo mapserver & geocoding | feld | wert | |---|---| | **kategorie** | geodaten / kartendienst | | **verwendung** | adress-geocoding, karteninformationen, parzellen-identifikation via `api3.geo.admin.ch` | | **kritikalität** | nein — betrifft nur immobilien-/geo-features | | **ansprechpartner** | patrick motsch — p.motsch@poweron.swiss | | **statusseite** | https://www.geo.admin.ch | | **vertragslaufzeit / kündigung** | kostenloser öffentlicher dienst | ### stac api (swisstopo) | feld | wert | |---|---| | **kategorie** | geodaten (satellitenbilder / rasterdaten) | | **verwendung** | zugriff auf georäumliche katalogdaten via `data.geo.admin.ch` | | **kritikalität** | nein — betrifft nur geo-features | | **ansprechpartner** | patrick motsch — p.motsch@poweron.swiss | | **statusseite** | https://www.geo.admin.ch | | **vertragslaufzeit / kündigung** | kostenloser öffentlicher dienst | ### öreb-kataster wfs (kanton zürich) | feld | wert | |---|---| | **kategorie** | geodaten / rechtliche grundlagen grundstücke | | **verwendung** | abruf öffentlich-rechtlicher eigentumsbeschränkungen (öreb) für parzellen via `maps.zh.ch` | | **kritikalität** | nein — betrifft nur immobilien-features (zh) | | **ansprechpartner** | patrick motsch — p.motsch@poweron.swiss | | **statusseite** | https://www.zh.ch/de/direktion-der-justiz-und-des-innern/geoinformation.html | | **vertragslaufzeit / kündigung** | kostenloser öffentlicher dienst | ### geodienste.ch (amtliche vermessung zh) | feld | wert | |---|---| | **kategorie** | geodaten / amtliche vermessung | | **verwendung** | wfs-abfragen für parzellensuche via `www.geodienste.ch` | | **kritikalität** | nein — betrifft nur immobilien-features | | **ansprechpartner** | patrick motsch — p.motsch@poweron.swiss | | **statusseite** | https://www.geodienste.ch | | **vertragslaufzeit / kündigung** | kostenloser öffentlicher dienst | ", "nextReview": "", "overdueReview": false, "zuPruefen": []}, {"id": "05_betrieb/20260528_feature_release_bugfix.md", "path": "05_betrieb/20260528_feature_release_bugfix.md", "chapter": "05_betrieb", "title": "Auditkonformer Prozess: Feature-Entwicklung, Releases und Bug-Management", "filename": "20260528_feature_release_bugfix.md", "meta": {}, "html": "<h1>Auditkonformer Prozess: Feature-Entwicklung, Releases und Bug-Management<\/h1>\n<p><strong>Dokumenttyp:<\/strong> Prozessbeschreibung / SOP <strong>Geltungsbereich:<\/strong> Softwareentwicklung, Release Management, Bugfixing <strong>Version:<\/strong> 1.0 <strong>Status:<\/strong> Entwurf zur internen Freigabe <strong>Owner:<\/strong> Entwicklung / Produktverantwortung <strong>Letzte Aktualisierung:<\/strong> 28.05.2026<\/p>\n<hr>\n<h2>1. Zweck des Dokuments<\/h2>\n<p>Dieses Dokument beschreibt einen auditkonformen Prozess für:<\/p>\n<ul><li>die strukturierte Aufnahme, Bewertung und Umsetzung von Feature-Requests,<\/li><li>die Durchführung technischer Workshops vor Implementierungsbeginn,<\/li><li>die kontrollierte Entwicklung über Branches, Reviews und Staging-Verifikation,<\/li><li>die versionierte Erstellung von Release Notes,<\/li><li>die Erfassung, Priorisierung, Bearbeitung und Dokumentation von Bugs,<\/li><li>die Nachvollziehbarkeit von Entscheidungen, Änderungen, Verantwortlichkeiten und Freigaben.<\/li><\/ul>\n<p>Ziel ist es, einen nachvollziehbaren, wiederholbaren und prüfbaren Entwicklungs- und Release-Prozess sicherzustellen.<\/p>\n<hr>\n<h2>2. Prozessübersicht<\/h2>\n<p>Der Gesamtprozess besteht aus zwei Hauptsträngen:<\/p>\n<ol><li><strong>Feature-Entwicklung &amp; Releases<\/strong><\/li><li><strong>Bug-Management &amp; Bugfixing<\/strong><\/li><\/ol>\n<p>Beide Stränge folgen gemeinsamen Prinzipien:<\/p>\n<ul><li>zentrale Erfassung aller Anforderungen und Fehler,<\/li><li>dokumentierte Bewertung und Priorisierung,<\/li><li>nachvollziehbare technische Entscheidungen,<\/li><li>Vier-Augen-Prinzip vor produktivem Release,<\/li><li>dokumentierte Release Notes,<\/li><li>klare Verantwortlichkeiten,<\/li><li>prüfbare Nachweise in Tickets, Branches, Pull Requests und Changelogs.<\/li><\/ul>\n<hr>\n<h2>3. Prozessbild<\/h2>\n<pre class=\"mermaid\">flowchart TD\n\n    A[Feature Request oder Bug Report geht ein] --&gt; B{Art des Eingangs}\n\n    B --&gt;|Feature Request| F1[Zentrale Erfassung&lt;br/&gt;z. B. GitHub Issues, Linear, Notion]\n    F1 --&gt; F2[Priorisierung nach Kundenwert,&lt;br/&gt;strategischer Relevanz und Aufwand]\n    F2 --&gt; F3[Feature mit hoher Priorität&lt;br/&gt;für Tech Workshop vormerken]\n    F3 --&gt; F4[Tech Workshop mit beiden Entwicklern]\n    F4 --&gt; F5[Architektur-, API-, Datenmodell-&lt;br/&gt;und Schnittstellenanalyse]\n    F5 --&gt; F6[Aufwandsschätzung,&lt;br/&gt;Aufgabenverteilung und Akzeptanzkriterien]\n    F6 --&gt; F7[Dokumentation im Issue&lt;br/&gt;oder internen Ticket]\n    F7 --&gt; F8[Entwicklung auf Feature Branch&lt;br/&gt;feature/kurzbeschreibung]\n    F8 --&gt; F9[Commits mit aussagekräftigen Messages&lt;br/&gt;z. B. feat:, fix:, chore:]\n    F9 --&gt; F10[Code Review durch zweiten Entwickler]\n    F10 --&gt; F11{Review bestanden?}\n    F11 --&gt;|Nein| F12[Überarbeitung durch Entwickler]\n    F12 --&gt; F10\n    F11 --&gt;|Ja| F13[Merge in Main/Development Branch]\n    F13 --&gt; F14[Deployment in Staging]\n    F14 --&gt; F15[Finale Verifikation gegen Akzeptanzkriterien]\n    F15 --&gt; F16{Verifikation bestanden?}\n    F16 --&gt;|Nein| F12\n    F16 --&gt;|Ja| F17[Release / Push in Produktion]\n    F17 --&gt; F18[Release Notes erstellen und versionieren]\n    F18 --&gt; F19[CHANGELOG.md und /changelog aktualisieren]\n\n    B --&gt;|Bug Report| G1[Zentrale Erfassung&lt;br/&gt;z. B. ClickUp Formular]\n    G1 --&gt; G2[Initiale Antwort gemäß Schweregrad]\n    G2 --&gt; G3[Triage durch Mitarbeiter 1]\n    G3 --&gt; G4[Prüfung auf Vollständigkeit&lt;br/&gt;und Reproduzierbarkeit]\n    G4 --&gt; G5[Klassifizierung:&lt;br/&gt;Kritisch / Hoch / Mittel / Niedrig]\n    G5 --&gt; G6[Zuweisung an zuständigen Entwickler]\n    G6 --&gt; G7[Fix auf Bugfix Branch&lt;br/&gt;fix/kurzbeschreibung]\n    G7 --&gt; G8[Code Review durch Mitarbeiter 1]\n    G8 --&gt; G9{Review bestanden?}\n    G9 --&gt;|Nein| G10[Nachbesserung durch Entwickler]\n    G10 --&gt; G8\n    G9 --&gt;|Ja| G11[Merge analog Feature-Prozess]\n    G11 --&gt; G12[Staging-Verifikation]\n    G12 --&gt; G13{Fix verifiziert?}\n    G13 --&gt;|Nein| G10\n    G13 --&gt;|Ja| G14[Release in Produktion]\n    G14 --&gt; G15[Dokumentation in Release Notes / CHANGELOG]\n    G15 --&gt; G16[Melder informieren und Ticket schließen]<\/pre>\n<hr>\n<h2>4. Rollen und Verantwortlichkeiten<\/h2>\n<table><thead><tr><th>Rolle<\/th><th>Verantwortung<\/th><\/tr><\/thead><tbody><tr><td>Entwickler 1<\/td><td>Teilnahme am Tech Workshop, Entwicklung, Review, ggf. Triage<\/td><\/tr><tr><td>Entwickler 2<\/td><td>Teilnahme am Tech Workshop, Entwicklung, Review, Release-Durchführung<\/td><\/tr><tr><td>Mitarbeiter 1 / Triage-Rolle<\/td><td>Prüfung eingehender Bug Reports, Klassifizierung, Reproduzierbarkeit, Zuweisung, Review von Bugfixes<\/td><\/tr><tr><td>Mitarbeiter 2 / Entwicklungsrolle<\/td><td>Umsetzung von Bugfixes auf separatem Branch, Dokumentation technischer Änderungen<\/td><\/tr><tr><td>Release-Verantwortlicher<\/td><td>Durchführung des Releases, Pflege der Release Notes, Aktualisierung von CHANGELOG.md und /changelog<\/td><\/tr><tr><td>Produkt-/Business-Verantwortlicher<\/td><td>Bewertung von Kundenwert und strategischer Relevanz bei Feature Requests<\/td><\/tr><\/tbody><\/table>\n<hr>\n<h1>5. Feature-Entwicklung &amp; Releases<\/h1>\n<h2>5.1 Feature-Request-Prozess<\/h2>\n<p>Eingehende Feature-Requests werden zentral gesammelt. Mögliche Systeme sind:<\/p>\n<ul><li>GitHub Issues,<\/li><li>Linear,<\/li><li>Notion,<\/li><li>ein internes Produkt-Backlog.<\/li><\/ul>\n<p>Jeder Feature Request muss mindestens folgende Informationen enthalten:<\/p>\n<table><thead><tr><th>Pflichtfeld<\/th><th>Beschreibung<\/th><\/tr><\/thead><tbody><tr><td>Titel<\/td><td>Kurze, eindeutige Beschreibung des gewünschten Features<\/td><\/tr><tr><td>Beschreibung<\/td><td>Fachliche Beschreibung des Bedarfs<\/td><\/tr><tr><td>Nutzen<\/td><td>Erwarteter Mehrwert für Kunden, Nutzer oder internes Team<\/td><\/tr><tr><td>Quelle<\/td><td>Kunde, interner Stakeholder, Entwickler, Support oder Management<\/td><\/tr><tr><td>Prioritätsbewertung<\/td><td>Bewertung nach definierten Kriterien<\/td><\/tr><tr><td>Status<\/td><td>Neu, in Bewertung, geplant, in Umsetzung, umgesetzt, abgelehnt<\/td><\/tr><\/tbody><\/table>\n<h2>5.2 Priorisierung<\/h2>\n<p>Die Priorisierung erfolgt anhand folgender Kriterien:<\/p>\n<table><thead><tr><th>Kriterium<\/th><th>Beschreibung<\/th><th>Bewertung<\/th><\/tr><\/thead><tbody><tr><td>Kundenwert<\/td><td>Relevanz für Nutzer oder Kunden<\/td><td>1 = gering, 2 = mittel, 3 = hoch<\/td><\/tr><tr><td>Strategische Relevanz<\/td><td>Beitrag zur Produktstrategie<\/td><td>1 = gering, 2 = mittel, 3 = hoch<\/td><\/tr><tr><td>Implementierungsaufwand<\/td><td>Technischer und organisatorischer Aufwand<\/td><td>1 = gering, 2 = mittel, 3 = hoch<\/td><\/tr><\/tbody><\/table>\n<p>Alternativ kann eine MoSCoW-Kategorisierung verwendet werden:<\/p>\n<table><thead><tr><th>Kategorie<\/th><th>Bedeutung<\/th><\/tr><\/thead><tbody><tr><td>Must have<\/td><td>zwingend erforderlich<\/td><\/tr><tr><td>Should have<\/td><td>wichtig, aber nicht kritisch<\/td><\/tr><tr><td>Could have<\/td><td>optional, wenn Kapazität vorhanden<\/td><\/tr><tr><td>Won't have<\/td><td>bewusst zurückgestellt<\/td><\/tr><\/tbody><\/table>\n<p>Features mit höchster Priorität werden für den nächsten Tech Workshop vorgemerkt.<\/p>\n<hr>\n<h2>5.3 Tech Workshop vor Implementierungsbeginn<\/h2>\n<p>Vor der Implementierung priorisierter Features findet ein Tech Workshop statt.<\/p>\n<p><strong>Teilnehmer:<\/strong><\/p>\n<ul><li>beide Entwickler,<\/li><li>optional Produkt-/Business-Verantwortlicher bei fachlicher Klärung.<\/li><\/ul>\n<p><strong>Inhalte des Tech Workshops:<\/strong><\/p>\n<ul><li>Analyse architektonischer Auswirkungen,<\/li><li>Prüfung betroffener Systeme, Schnittstellen und Datenmodelle,<\/li><li>Definition möglicher API-Änderungen,<\/li><li>Definition neuer Endpunkte,<\/li><li>Prüfung von Abhängigkeiten zu Drittdiensten,<\/li><li>Aufwandsschätzung,<\/li><li>Aufgabenverteilung,<\/li><li>Definition von Akzeptanzkriterien,<\/li><li>Festlegung von technischen Risiken,<\/li><li>Dokumentation der Entscheidung.<\/li><\/ul>\n<p><strong>Auditnachweis:<\/strong><\/p>\n<p>Das Ergebnis des Tech Workshops wird dokumentiert, z. B. als:<\/p>\n<ul><li>Issue-Kommentar,<\/li><li>internes Ticket,<\/li><li>kurzer Workshop-Vermerk,<\/li><li>technische Entscheidungsnotiz.<\/li><\/ul>\n<hr>\n<h2>5.4 Entwicklungsprozess<\/h2>\n<p>Jedes Feature wird auf einem separaten Feature Branch entwickelt.<\/p>\n<p><strong>Branch-Konvention:<\/strong><\/p>\n<pre class=\"code\"><code>feature/kurzbeschreibung<\/code><\/pre>\n<p><strong>Beispiele:<\/strong><\/p>\n<pre class=\"code\"><code>feature/user-export\nfeature/payment-dashboard\nfeature/api-rate-limit<\/code><\/pre>\n<p><strong>Commit-Konvention:<\/strong><\/p>\n<p>Commits sollen aussagekräftige Messages enthalten, vorzugsweise nach dem Muster der Conventional Commits.<\/p>\n<p><strong>Beispiele:<\/strong><\/p>\n<pre class=\"code\"><code>feat: add user export endpoint\nfix: correct validation for release note dates\nchore: update dependency configuration<\/code><\/pre>\n<hr>\n<h2>5.5 Code Review<\/h2>\n<p>Vor jedem Merge ist ein Code Review durch den jeweils anderen Entwickler erforderlich.<\/p>\n<p><strong>Review-Fokus:<\/strong><\/p>\n<ul><li>Codequalität,<\/li><li>Sicherheit,<\/li><li>Konsistenz,<\/li><li>Architektur,<\/li><li>Einhaltung der Akzeptanzkriterien,<\/li><li>potenzielle Seiteneffekte,<\/li><li>Lesbarkeit und Wartbarkeit,<\/li><li>Auswirkungen auf Schnittstellen oder Datenmodelle.<\/li><\/ul>\n<p><strong>Auditkontrolle:<\/strong><\/p>\n<p>Ein Merge darf nur erfolgen, wenn das Review dokumentiert und freigegeben wurde.<\/p>\n<hr>\n<h2>5.6 Staging-Verifikation und Release<\/h2>\n<p>Nach bestandenem Review erfolgt:<\/p>\n<ol><li>Merge in den Main- oder Development-Branch,<\/li><li>Deployment in die Staging-Umgebung,<\/li><li>finale Verifikation gegen die Akzeptanzkriterien,<\/li><li>Release bzw. Push in Produktion,<\/li><li>Dokumentation im Release-Prozess.<\/li><\/ol>\n<p>Die produktive Veröffentlichung darf erst erfolgen, wenn die Staging-Verifikation erfolgreich abgeschlossen wurde.<\/p>\n<hr>\n<h1>6. Release Notes<\/h1>\n<h2>6.1 Grundsatz<\/h2>\n<p>Release Notes werden mit jedem Merge bzw. Release erstellt und versioniert.<\/p>\n<p>Es wird semantische Versionierung verwendet:<\/p>\n<pre class=\"code\"><code>MAJOR.MINOR.PATCH<\/code><\/pre>\n<p><strong>Beispiel:<\/strong><\/p>\n<pre class=\"code\"><code>1.4.2<\/code><\/pre>\n<h2>6.2 Inhalt einer Release Note<\/h2>\n<p>Jede Release Note enthält mindestens:<\/p>\n<table><thead><tr><th>Abschnitt<\/th><th>Inhalt<\/th><\/tr><\/thead><tbody><tr><td>Versionsnummer<\/td><td>z. B. 1.4.2<\/td><\/tr><tr><td>Datum<\/td><td>Datum des Releases<\/td><\/tr><tr><td>Neue Features<\/td><td>kurze Beschreibung, ggf. Nutzen für User<\/td><\/tr><tr><td>Behobene Bugs<\/td><td>Liste der korrigierten Fehler<\/td><\/tr><tr><td>Breaking Changes<\/td><td>prominent hervorgehobene inkompatible Änderungen<\/td><\/tr><tr><td>Technische Änderungen<\/td><td>interne Infrastruktur-, API- oder Architekturänderungen<\/td><\/tr><\/tbody><\/table>\n<h2>6.3 Ablageorte<\/h2>\n<table><thead><tr><th>Ablageort<\/th><th>Zielgruppe<\/th><th>Inhalt<\/th><\/tr><\/thead><tbody><tr><td><code>CHANGELOG.md<\/code> im Wiki-Repository<\/td><td>technische Zielgruppe<\/td><td>vollständige Release-Historie<\/td><\/tr><tr><td><code>/changelog<\/code><\/td><td>intern / technisch<\/td><td>ausführliche Details je Release<\/td><\/tr><tr><td>Produktbereich<\/td><td>Endnutzer<\/td><td>kurze, nicht-technische Zusammenfassung, derzeit optional<\/td><\/tr><\/tbody><\/table>\n<h2>6.4 Verantwortlichkeit<\/h2>\n<p>Verantwortlich für die Release Notes ist der Entwickler, der den Release durchführt.<\/p>\n<hr>\n<h1>7. Bug-Management &amp; Bugfixing<\/h1>\n<h2>7.1 Eingang und Erstreaktion<\/h2>\n<p>Bug Reports werden zentral erfasst, z. B. über ein ClickUp Formular.<\/p>\n<p>Jeder Bug Report soll mindestens enthalten:<\/p>\n<table><thead><tr><th>Pflichtfeld<\/th><th>Beschreibung<\/th><\/tr><\/thead><tbody><tr><td>Titel<\/td><td>Kurze Fehlerbeschreibung<\/td><\/tr><tr><td>Beschreibung<\/td><td>Was ist passiert?<\/td><\/tr><tr><td>Erwartetes Verhalten<\/td><td>Was hätte passieren sollen?<\/td><\/tr><tr><td>Tatsächliches Verhalten<\/td><td>Was ist tatsächlich passiert?<\/td><\/tr><tr><td>Reproduktionsschritte<\/td><td>Schritte zur Nachstellung des Fehlers<\/td><\/tr><tr><td>Schweregrad<\/td><td>Kritisch, Hoch, Mittel, Niedrig<\/td><\/tr><tr><td>Screenshots / Logs<\/td><td>falls vorhanden<\/td><\/tr><tr><td>Melder<\/td><td>Person oder Quelle des Reports<\/td><\/tr><\/tbody><\/table>\n<h2>7.2 Initiale Antwortzeiten<\/h2>\n<table><thead><tr><th>Schweregrad<\/th><th>Beschreibung<\/th><th>Initiale Antwort<\/th><\/tr><\/thead><tbody><tr><td>Kritisch<\/td><td>Produktionsausfall, Datenverlust<\/td><td>innerhalb von 2 Stunden<\/td><\/tr><tr><td>Hoch<\/td><td>wesentliche Funktion defekt<\/td><td>innerhalb von 1 Werktag<\/td><\/tr><tr><td>Mittel<\/td><td>eingeschränkte Funktion, Workaround möglich<\/td><td>innerhalb von 2 Werktagen<\/td><\/tr><tr><td>Niedrig<\/td><td>kosmetisch oder selten auftretend<\/td><td>innerhalb von 5 Werktagen<\/td><\/tr><\/tbody><\/table>\n<hr>\n<h2>7.3 Triage und Priorisierung<\/h2>\n<p>Die Triage wird durch Mitarbeiter 1 durchgeführt.<\/p>\n<p><strong>Aufgaben der Triage-Rolle:<\/strong><\/p>\n<ul><li>Prüfung auf Vollständigkeit,<\/li><li>Prüfung auf Reproduzierbarkeit,<\/li><li>Rückfrage bei unvollständigen Reports,<\/li><li>Klassifizierung nach Schweregrad,<\/li><li>Zuweisung an zuständigen Entwickler,<\/li><li>Dokumentation der Entscheidung im Ticket.<\/li><\/ul>\n<p><strong>Schweregrade:<\/strong><\/p>\n<table><thead><tr><th>Schweregrad<\/th><th>Definition<\/th><\/tr><\/thead><tbody><tr><td>Kritisch<\/td><td>Produktionsausfall, Datenverlust, sicherheitsrelevanter Vorfall oder vollständige Nichtnutzbarkeit<\/td><\/tr><tr><td>Hoch<\/td><td>zentrale Funktion defekt, erhebliche Nutzerbeeinträchtigung<\/td><\/tr><tr><td>Mittel<\/td><td>eingeschränkte Funktion, Workaround vorhanden<\/td><\/tr><tr><td>Niedrig<\/td><td>kosmetischer Fehler, seltenes Randverhalten, geringe Auswirkungen<\/td><\/tr><\/tbody><\/table>\n<hr>\n<h2>7.4 Ziellösungszeiten / SLOs<\/h2>\n<table><thead><tr><th>Priorität<\/th><th>Initiale Antwort<\/th><th>Angestrebte Lösung<\/th><\/tr><\/thead><tbody><tr><td>Kritisch<\/td><td>2 Stunden<\/td><td>24 Stunden<\/td><\/tr><tr><td>Hoch<\/td><td>1 Werktag<\/td><td>3 Werktage<\/td><\/tr><tr><td>Mittel<\/td><td>2 Werktage<\/td><td>2 Wochen<\/td><\/tr><tr><td>Niedrig<\/td><td>5 Werktage<\/td><td>nächster Release<\/td><\/tr><\/tbody><\/table>\n<p>Die SLOs sind Zielwerte. Abweichungen müssen im Ticket nachvollziehbar begründet werden.<\/p>\n<hr>\n<h2>7.5 Fixing und Release<\/h2>\n<p>Die Umsetzung erfolgt durch Mitarbeiter 2 bzw. den zuständigen Entwickler.<\/p>\n<p><strong>Branch-Konvention:<\/strong><\/p>\n<pre class=\"code\"><code>fix/kurzbeschreibung<\/code><\/pre>\n<p><strong>Beispiele:<\/strong><\/p>\n<pre class=\"code\"><code>fix/login-timeout\nfix/export-validation\nfix/payment-status-mapping<\/code><\/pre>\n<p><strong>Ablauf:<\/strong><\/p>\n<ol><li>Bugfix Branch erstellen,<\/li><li>Fehler reproduzieren,<\/li><li>Ursache analysieren,<\/li><li>Fix implementieren,<\/li><li>Tests bzw. Verifikation durchführen,<\/li><li>Code Review durch Mitarbeiter 1,<\/li><li>Merge analog Feature-Prozess,<\/li><li>Deployment in Staging,<\/li><li>finale Verifikation,<\/li><li>Release in Produktion,<\/li><li>Dokumentation in Release Notes / CHANGELOG,<\/li><li>Information an Melder,<\/li><li>Ticket schliessen.<\/li><\/ol>\n<hr>\n<h1>8. Kontrollpunkte und Auditnachweise<\/h1>\n<table><thead><tr><th>Kontrollpunkt<\/th><th>Beschreibung<\/th><th>Nachweis<\/th><\/tr><\/thead><tbody><tr><td>Zentrale Erfassung<\/td><td>Alle Requests und Bugs werden in definierten Systemen erfasst<\/td><td>Issue, Ticket, Formular<\/td><\/tr><tr><td>Priorisierung<\/td><td>Bewertung anhand definierter Kriterien<\/td><td>Prioritätsfeld, Score, Kommentar<\/td><\/tr><tr><td>Tech Workshop<\/td><td>technische Analyse vor Implementierung<\/td><td>Workshop-Kommentar, Ticketnotiz<\/td><\/tr><tr><td>Akzeptanzkriterien<\/td><td>fachliche und technische Erfolgskriterien<\/td><td>Ticketbeschreibung<\/td><\/tr><tr><td>Branching<\/td><td>getrennte Branches je Feature oder Bugfix<\/td><td>Git Branch<\/td><\/tr><tr><td>Commit-Konvention<\/td><td>nachvollziehbare Änderungshistorie<\/td><td>Git Commit History<\/td><\/tr><tr><td>Code Review<\/td><td>Vier-Augen-Prinzip vor Merge<\/td><td>Pull Request Review<\/td><\/tr><tr><td>Staging-Verifikation<\/td><td>Prüfung vor Produktion<\/td><td>Testkommentar, Checkliste<\/td><\/tr><tr><td>Release Notes<\/td><td>versionierte Dokumentation jeder Änderung<\/td><td>CHANGELOG.md, /changelog<\/td><\/tr><tr><td>Bug-Triage<\/td><td>Klassifizierung und Zuweisung<\/td><td>Bug Ticket<\/td><\/tr><tr><td>SLO-Überwachung<\/td><td>Prüfung von Antwort- und Lösungszeiten<\/td><td>Ticket-Zeitstempel<\/td><\/tr><tr><td>Ticketabschluss<\/td><td>Abschluss mit nachvollziehbarem Ergebnis<\/td><td>Status, Kommentar, Melderinfo<\/td><\/tr><\/tbody><\/table>\n<hr>\n<h1>9. Definition of Done<\/h1>\n<p>Ein Feature oder Bugfix gilt erst als abgeschlossen, wenn folgende Kriterien erfüllt sind:<\/p>\n<ul><li>Umsetzung auf separatem Branch erfolgt,<\/li><li>aussagekräftige Commits vorhanden,<\/li><li>Code Review durch zweite Person durchgeführt,<\/li><li>Review-Kommentare wurden bearbeitet,<\/li><li>Merge in Main/Development erfolgt,<\/li><li>Staging-Verifikation erfolgreich abgeschlossen,<\/li><li>Akzeptanzkriterien erfüllt,<\/li><li>Release Notes aktualisiert,<\/li><li>CHANGELOG.md bzw. /changelog aktualisiert,<\/li><li>bei Bugs: Melder informiert,<\/li><li>Ticket geschlossen oder auf erledigt gesetzt.<\/li><\/ul>\n<hr>\n<h1>10. Risiken und Kontrollen<\/h1>\n<table><thead><tr><th>Risiko<\/th><th>Auswirkung<\/th><th>Kontrolle<\/th><\/tr><\/thead><tbody><tr><td>Unklare Anforderungen<\/td><td>Fehlentwicklung, Rework<\/td><td>Akzeptanzkriterien und Tech Workshop<\/td><\/tr><tr><td>Fehlende Priorisierung<\/td><td>falsche Ressourcenallokation<\/td><td>Scoring oder MoSCoW<\/td><\/tr><tr><td>Direkter Merge ohne Review<\/td><td>Qualitäts- und Sicherheitsrisiken<\/td><td>verpflichtendes Vier-Augen-Prinzip<\/td><\/tr><tr><td>Unvollständige Release Notes<\/td><td>fehlende Nachvollziehbarkeit<\/td><td>Release-Checkliste<\/td><\/tr><tr><td>Bugs ohne Triage<\/td><td>falsche Dringlichkeit<\/td><td>definierte Triage-Rolle<\/td><\/tr><tr><td>SLO-Verletzungen ohne Begründung<\/td><td>fehlende Steuerbarkeit<\/td><td>Ticketkommentar bei Abweichung<\/td><\/tr><tr><td>Produktivfehler nach Release<\/td><td>Nutzerbeeinträchtigung<\/td><td>Staging-Verifikation vor Produktion<\/td><\/tr><\/tbody><\/table>\n<hr>\n<h1>11. Empfohlene Ticket-Templates<\/h1>\n<h2>11.1 Feature Request Template<\/h2>\n<pre class=\"code\"><code>## Feature Request\n\n### Titel\nKurzbeschreibung des Features\n\n### Beschreibung\nWas soll umgesetzt werden?\n\n### Nutzen\nWelchen Mehrwert liefert das Feature?\n\n### Quelle\nKunde / intern / Support / Management\n\n### Priorisierung\n- Kundenwert: 1 / 2 / 3\n- Strategische Relevanz: 1 / 2 / 3\n- Implementierungsaufwand: 1 / 2 / 3\n\n### Akzeptanzkriterien\n- [ ] Kriterium 1\n- [ ] Kriterium 2\n- [ ] Kriterium 3\n\n### Technische Hinweise\nBetroffene Systeme, APIs, Datenmodelle oder Schnittstellen\n\n### Entscheidung Tech Workshop\nKurzprotokoll / Ergebnis<\/code><\/pre>\n<hr>\n<h2>11.2 Bug Report Template<\/h2>\n<pre class=\"code\"><code>## Bug Report\n\n### Titel\nKurzbeschreibung des Fehlers\n\n### Beschreibung\nWas ist passiert?\n\n### Erwartetes Verhalten\nWas hätte passieren sollen?\n\n### Tatsächliches Verhalten\nWas ist tatsächlich passiert?\n\n### Reproduktionsschritte\n1. Schritt 1\n2. Schritt 2\n3. Schritt 3\n\n### Schweregrad\nKritisch / Hoch / Mittel / Niedrig\n\n### Auswirkungen\nWelche Nutzer, Systeme oder Daten sind betroffen?\n\n### Workaround\nJa / Nein / Beschreibung\n\n### Anhänge\nScreenshots, Logs, Videos\n\n### Triage-Ergebnis\n- Vollständig: Ja / Nein\n- Reproduzierbar: Ja / Nein\n- Zugewiesen an:\n- Zieltermin:<\/code><\/pre>\n<hr>\n<h2>11.3 Release Note Template<\/h2>\n<pre class=\"code\"><code># Release Notes\n\n## Version\nx.y.z\n\n## Datum\nTT.MM.JJJJ\n\n## Neue Features\n- Beschreibung des Features und Nutzen\n\n## Behobene Bugs\n- Beschreibung des behobenen Fehlers\n\n## Breaking Changes\n- Keine / Beschreibung der Änderung\n\n## Technische Änderungen\n- API, Infrastruktur, Datenmodell oder Abhängigkeiten\n\n## Verantwortlich\nName des Release-Verantwortlichen\n\n## Referenzen\n- Issue / Ticket / Pull Request<\/code><\/pre>\n<hr>\n<h1>12. Freigabe und Review des Prozesses<\/h1>\n<p>Dieser Prozess sollte regelmässig überprüft werden, mindestens jedoch:<\/p>\n<ul><li>bei wesentlichen Änderungen am Entwicklungsprozess,<\/li><li>bei Einführung neuer Tools,<\/li><li>nach grösseren Incidents,<\/li><li>vor externen Audits,<\/li><li>mindestens einmal jährlich.<\/li><\/ul>\n<table><thead><tr><th>Freigabefeld<\/th><th>Eintrag<\/th><\/tr><\/thead><tbody><tr><td>Prozessverantwortlicher<\/td><td><\/td><\/tr><tr><td>Fachliche Freigabe<\/td><td><\/td><\/tr><tr><td>Technische Freigabe<\/td><td><\/td><\/tr><tr><td>Datum der Freigabe<\/td><td><\/td><\/tr><tr><td>Nächste Überprüfung<\/td><td><\/td><\/tr><\/tbody><\/table>\n<hr>\n<h1>13. Kurzfazit<\/h1>\n<p>Der beschriebene Prozess stellt sicher, dass Feature-Entwicklung, Bugfixing und Releases kontrolliert, nachvollziehbar und auditfähig durchgeführt werden. Durch zentrale Erfassung, klare Rollen, dokumentierte Priorisierung, Tech Workshops, Branching-Konventionen, Code Reviews, Staging-Verifikation und versionierte Release Notes entsteht ein robuster Entwicklungsprozess mit belastbaren Nachweisen für interne und externe Prüfungen.<\/p>", "text": "# auditkonformer prozess: feature-entwicklung, releases und bug-management **dokumenttyp:** prozessbeschreibung / sop **geltungsbereich:** softwareentwicklung, release management, bugfixing **version:** 1.0 **status:** entwurf zur internen freigabe **owner:** entwicklung / produktverantwortung **letzte aktualisierung:** 28.05.2026 --- ## 1. zweck des dokuments dieses dokument beschreibt einen auditkonformen prozess für: - die strukturierte aufnahme, bewertung und umsetzung von feature-requests, - die durchführung technischer workshops vor implementierungsbeginn, - die kontrollierte entwicklung über branches, reviews und staging-verifikation, - die versionierte erstellung von release notes, - die erfassung, priorisierung, bearbeitung und dokumentation von bugs, - die nachvollziehbarkeit von entscheidungen, änderungen, verantwortlichkeiten und freigaben. ziel ist es, einen nachvollziehbaren, wiederholbaren und prüfbaren entwicklungs- und release-prozess sicherzustellen. --- ## 2. prozessübersicht der gesamtprozess besteht aus zwei hauptsträngen: 1. **feature-entwicklung & releases** 2. **bug-management & bugfixing** beide stränge folgen gemeinsamen prinzipien: - zentrale erfassung aller anforderungen und fehler, - dokumentierte bewertung und priorisierung, - nachvollziehbare technische entscheidungen, - vier-augen-prinzip vor produktivem release, - dokumentierte release notes, - klare verantwortlichkeiten, - prüfbare nachweise in tickets, branches, pull requests und changelogs. --- ## 3. prozessbild ```mermaid flowchart td a[feature request oder bug report geht ein] --> b{art des eingangs} b -->|feature request| f1[zentrale erfassung<br/>z. b. github issues, linear, notion] f1 --> f2[priorisierung nach kundenwert,<br/>strategischer relevanz und aufwand] f2 --> f3[feature mit hoher priorität<br/>für tech workshop vormerken] f3 --> f4[tech workshop mit beiden entwicklern] f4 --> f5[architektur-, api-, datenmodell-<br/>und schnittstellenanalyse] f5 --> f6[aufwandsschätzung,<br/>aufgabenverteilung und akzeptanzkriterien] f6 --> f7[dokumentation im issue<br/>oder internen ticket] f7 --> f8[entwicklung auf feature branch<br/>feature/kurzbeschreibung] f8 --> f9[commits mit aussagekräftigen messages<br/>z. b. feat:, fix:, chore:] f9 --> f10[code review durch zweiten entwickler] f10 --> f11{review bestanden?} f11 -->|nein| f12[überarbeitung durch entwickler] f12 --> f10 f11 -->|ja| f13[merge in main/development branch] f13 --> f14[deployment in staging] f14 --> f15[finale verifikation gegen akzeptanzkriterien] f15 --> f16{verifikation bestanden?} f16 -->|nein| f12 f16 -->|ja| f17[release / push in produktion] f17 --> f18[release notes erstellen und versionieren] f18 --> f19[changelog.md und /changelog aktualisieren] b -->|bug report| g1[zentrale erfassung<br/>z. b. clickup formular] g1 --> g2[initiale antwort gemäß schweregrad] g2 --> g3[triage durch mitarbeiter 1] g3 --> g4[prüfung auf vollständigkeit<br/>und reproduzierbarkeit] g4 --> g5[klassifizierung:<br/>kritisch / hoch / mittel / niedrig] g5 --> g6[zuweisung an zuständigen entwickler] g6 --> g7[fix auf bugfix branch<br/>fix/kurzbeschreibung] g7 --> g8[code review durch mitarbeiter 1] g8 --> g9{review bestanden?} g9 -->|nein| g10[nachbesserung durch entwickler] g10 --> g8 g9 -->|ja| g11[merge analog feature-prozess] g11 --> g12[staging-verifikation] g12 --> g13{fix verifiziert?} g13 -->|nein| g10 g13 -->|ja| g14[release in produktion] g14 --> g15[dokumentation in release notes / changelog] g15 --> g16[melder informieren und ticket schließen] ``` --- ## 4. rollen und verantwortlichkeiten | rolle | verantwortung | |---|---| | entwickler 1 | teilnahme am tech workshop, entwicklung, review, ggf. triage | | entwickler 2 | teilnahme am tech workshop, entwicklung, review, release-durchführung | | mitarbeiter 1 / triage-rolle | prüfung eingehender bug reports, klassifizierung, reproduzierbarkeit, zuweisung, review von bugfixes | | mitarbeiter 2 / entwicklungsrolle | umsetzung von bugfixes auf separatem branch, dokumentation technischer änderungen | | release-verantwortlicher | durchführung des releases, pflege der release notes, aktualisierung von changelog.md und /changelog | | produkt-/business-verantwortlicher | bewertung von kundenwert und strategischer relevanz bei feature requests | --- # 5. feature-entwicklung & releases ## 5.1 feature-request-prozess eingehende feature-requests werden zentral gesammelt. mögliche systeme sind: - github issues, - linear, - notion, - ein internes produkt-backlog. jeder feature request muss mindestens folgende informationen enthalten: | pflichtfeld | beschreibung | |---|---| | titel | kurze, eindeutige beschreibung des gewünschten features | | beschreibung | fachliche beschreibung des bedarfs | | nutzen | erwarteter mehrwert für kunden, nutzer oder internes team | | quelle | kunde, interner stakeholder, entwickler, support oder management | | prioritätsbewertung | bewertung nach definierten kriterien | | status | neu, in bewertung, geplant, in umsetzung, umgesetzt, abgelehnt | ## 5.2 priorisierung die priorisierung erfolgt anhand folgender kriterien: | kriterium | beschreibung | bewertung | |---|---|---| | kundenwert | relevanz für nutzer oder kunden | 1 = gering, 2 = mittel, 3 = hoch | | strategische relevanz | beitrag zur produktstrategie | 1 = gering, 2 = mittel, 3 = hoch | | implementierungsaufwand | technischer und organisatorischer aufwand | 1 = gering, 2 = mittel, 3 = hoch | alternativ kann eine moscow-kategorisierung verwendet werden: | kategorie | bedeutung | |---|---| | must have | zwingend erforderlich | | should have | wichtig, aber nicht kritisch | | could have | optional, wenn kapazität vorhanden | | won't have | bewusst zurückgestellt | features mit höchster priorität werden für den nächsten tech workshop vorgemerkt. --- ## 5.3 tech workshop vor implementierungsbeginn vor der implementierung priorisierter features findet ein tech workshop statt. **teilnehmer:** - beide entwickler, - optional produkt-/business-verantwortlicher bei fachlicher klärung. **inhalte des tech workshops:** - analyse architektonischer auswirkungen, - prüfung betroffener systeme, schnittstellen und datenmodelle, - definition möglicher api-änderungen, - definition neuer endpunkte, - prüfung von abhängigkeiten zu drittdiensten, - aufwandsschätzung, - aufgabenverteilung, - definition von akzeptanzkriterien, - festlegung von technischen risiken, - dokumentation der entscheidung. **auditnachweis:** das ergebnis des tech workshops wird dokumentiert, z. b. als: - issue-kommentar, - internes ticket, - kurzer workshop-vermerk, - technische entscheidungsnotiz. --- ## 5.4 entwicklungsprozess jedes feature wird auf einem separaten feature branch entwickelt. **branch-konvention:** ```text feature/kurzbeschreibung ``` **beispiele:** ```text feature/user-export feature/payment-dashboard feature/api-rate-limit ``` **commit-konvention:** commits sollen aussagekräftige messages enthalten, vorzugsweise nach dem muster der conventional commits. **beispiele:** ```text feat: add user export endpoint fix: correct validation for release note dates chore: update dependency configuration ``` --- ## 5.5 code review vor jedem merge ist ein code review durch den jeweils anderen entwickler erforderlich. **review-fokus:** - codequalität, - sicherheit, - konsistenz, - architektur, - einhaltung der akzeptanzkriterien, - potenzielle seiteneffekte, - lesbarkeit und wartbarkeit, - auswirkungen auf schnittstellen oder datenmodelle. **auditkontrolle:** ein merge darf nur erfolgen, wenn das review dokumentiert und freigegeben wurde. --- ## 5.6 staging-verifikation und release nach bestandenem review erfolgt: 1. merge in den main- oder development-branch, 2. deployment in die staging-umgebung, 3. finale verifikation gegen die akzeptanzkriterien, 4. release bzw. push in produktion, 5. dokumentation im release-prozess. die produktive veröffentlichung darf erst erfolgen, wenn die staging-verifikation erfolgreich abgeschlossen wurde. --- # 6. release notes ## 6.1 grundsatz release notes werden mit jedem merge bzw. release erstellt und versioniert. es wird semantische versionierung verwendet: ```text major.minor.patch ``` **beispiel:** ```text 1.4.2 ``` ## 6.2 inhalt einer release note jede release note enthält mindestens: | abschnitt | inhalt | |---|---| | versionsnummer | z. b. 1.4.2 | | datum | datum des releases | | neue features | kurze beschreibung, ggf. nutzen für user | | behobene bugs | liste der korrigierten fehler | | breaking changes | prominent hervorgehobene inkompatible änderungen | | technische änderungen | interne infrastruktur-, api- oder architekturänderungen | ## 6.3 ablageorte | ablageort | zielgruppe | inhalt | |---|---|---| | `changelog.md` im wiki-repository | technische zielgruppe | vollständige release-historie | | `/changelog` | intern / technisch | ausführliche details je release | | produktbereich | endnutzer | kurze, nicht-technische zusammenfassung, derzeit optional | ## 6.4 verantwortlichkeit verantwortlich für die release notes ist der entwickler, der den release durchführt. --- # 7. bug-management & bugfixing ## 7.1 eingang und erstreaktion bug reports werden zentral erfasst, z. b. über ein clickup formular. jeder bug report soll mindestens enthalten: | pflichtfeld | beschreibung | |---|---| | titel | kurze fehlerbeschreibung | | beschreibung | was ist passiert? | | erwartetes verhalten | was hätte passieren sollen? | | tatsächliches verhalten | was ist tatsächlich passiert? | | reproduktionsschritte | schritte zur nachstellung des fehlers | | schweregrad | kritisch, hoch, mittel, niedrig | | screenshots / logs | falls vorhanden | | melder | person oder quelle des reports | ## 7.2 initiale antwortzeiten | schweregrad | beschreibung | initiale antwort | |---|---|---| | kritisch | produktionsausfall, datenverlust | innerhalb von 2 stunden | | hoch | wesentliche funktion defekt | innerhalb von 1 werktag | | mittel | eingeschränkte funktion, workaround möglich | innerhalb von 2 werktagen | | niedrig | kosmetisch oder selten auftretend | innerhalb von 5 werktagen | --- ## 7.3 triage und priorisierung die triage wird durch mitarbeiter 1 durchgeführt. **aufgaben der triage-rolle:** - prüfung auf vollständigkeit, - prüfung auf reproduzierbarkeit, - rückfrage bei unvollständigen reports, - klassifizierung nach schweregrad, - zuweisung an zuständigen entwickler, - dokumentation der entscheidung im ticket. **schweregrade:** | schweregrad | definition | |---|---| | kritisch | produktionsausfall, datenverlust, sicherheitsrelevanter vorfall oder vollständige nichtnutzbarkeit | | hoch | zentrale funktion defekt, erhebliche nutzerbeeinträchtigung | | mittel | eingeschränkte funktion, workaround vorhanden | | niedrig | kosmetischer fehler, seltenes randverhalten, geringe auswirkungen | --- ## 7.4 ziellösungszeiten / slos | priorität | initiale antwort | angestrebte lösung | |---|---:|---:| | kritisch | 2 stunden | 24 stunden | | hoch | 1 werktag | 3 werktage | | mittel | 2 werktage | 2 wochen | | niedrig | 5 werktage | nächster release | die slos sind zielwerte. abweichungen müssen im ticket nachvollziehbar begründet werden. --- ## 7.5 fixing und release die umsetzung erfolgt durch mitarbeiter 2 bzw. den zuständigen entwickler. **branch-konvention:** ```text fix/kurzbeschreibung ``` **beispiele:** ```text fix/login-timeout fix/export-validation fix/payment-status-mapping ``` **ablauf:** 1. bugfix branch erstellen, 2. fehler reproduzieren, 3. ursache analysieren, 4. fix implementieren, 5. tests bzw. verifikation durchführen, 6. code review durch mitarbeiter 1, 7. merge analog feature-prozess, 8. deployment in staging, 9. finale verifikation, 10. release in produktion, 11. dokumentation in release notes / changelog, 12. information an melder, 13. ticket schliessen. --- # 8. kontrollpunkte und auditnachweise | kontrollpunkt | beschreibung | nachweis | |---|---|---| | zentrale erfassung | alle requests und bugs werden in definierten systemen erfasst | issue, ticket, formular | | priorisierung | bewertung anhand definierter kriterien | prioritätsfeld, score, kommentar | | tech workshop | technische analyse vor implementierung | workshop-kommentar, ticketnotiz | | akzeptanzkriterien | fachliche und technische erfolgskriterien | ticketbeschreibung | | branching | getrennte branches je feature oder bugfix | git branch | | commit-konvention | nachvollziehbare änderungshistorie | git commit history | | code review | vier-augen-prinzip vor merge | pull request review | | staging-verifikation | prüfung vor produktion | testkommentar, checkliste | | release notes | versionierte dokumentation jeder änderung | changelog.md, /changelog | | bug-triage | klassifizierung und zuweisung | bug ticket | | slo-überwachung | prüfung von antwort- und lösungszeiten | ticket-zeitstempel | | ticketabschluss | abschluss mit nachvollziehbarem ergebnis | status, kommentar, melderinfo | --- # 9. definition of done ein feature oder bugfix gilt erst als abgeschlossen, wenn folgende kriterien erfüllt sind: - umsetzung auf separatem branch erfolgt, - aussagekräftige commits vorhanden, - code review durch zweite person durchgeführt, - review-kommentare wurden bearbeitet, - merge in main/development erfolgt, - staging-verifikation erfolgreich abgeschlossen, - akzeptanzkriterien erfüllt, - release notes aktualisiert, - changelog.md bzw. /changelog aktualisiert, - bei bugs: melder informiert, - ticket geschlossen oder auf erledigt gesetzt. --- # 10. risiken und kontrollen | risiko | auswirkung | kontrolle | |---|---|---| | unklare anforderungen | fehlentwicklung, rework | akzeptanzkriterien und tech workshop | | fehlende priorisierung | falsche ressourcenallokation | scoring oder moscow | | direkter merge ohne review | qualitäts- und sicherheitsrisiken | verpflichtendes vier-augen-prinzip | | unvollständige release notes | fehlende nachvollziehbarkeit | release-checkliste | | bugs ohne triage | falsche dringlichkeit | definierte triage-rolle | | slo-verletzungen ohne begründung | fehlende steuerbarkeit | ticketkommentar bei abweichung | | produktivfehler nach release | nutzerbeeinträchtigung | staging-verifikation vor produktion | --- # 11. empfohlene ticket-templates ## 11.1 feature request template ```markdown ## feature request ### titel kurzbeschreibung des features ### beschreibung was soll umgesetzt werden? ### nutzen welchen mehrwert liefert das feature? ### quelle kunde / intern / support / management ### priorisierung - kundenwert: 1 / 2 / 3 - strategische relevanz: 1 / 2 / 3 - implementierungsaufwand: 1 / 2 / 3 ### akzeptanzkriterien - [ ] kriterium 1 - [ ] kriterium 2 - [ ] kriterium 3 ### technische hinweise betroffene systeme, apis, datenmodelle oder schnittstellen ### entscheidung tech workshop kurzprotokoll / ergebnis ``` --- ## 11.2 bug report template ```markdown ## bug report ### titel kurzbeschreibung des fehlers ### beschreibung was ist passiert? ### erwartetes verhalten was hätte passieren sollen? ### tatsächliches verhalten was ist tatsächlich passiert? ### reproduktionsschritte 1. schritt 1 2. schritt 2 3. schritt 3 ### schweregrad kritisch / hoch / mittel / niedrig ### auswirkungen welche nutzer, systeme oder daten sind betroffen? ### workaround ja / nein / beschreibung ### anhänge screenshots, logs, videos ### triage-ergebnis - vollständig: ja / nein - reproduzierbar: ja / nein - zugewiesen an: - zieltermin: ``` --- ## 11.3 release note template ```markdown # release notes ## version x.y.z ## datum tt.mm.jjjj ## neue features - beschreibung des features und nutzen ## behobene bugs - beschreibung des behobenen fehlers ## breaking changes - keine / beschreibung der änderung ## technische änderungen - api, infrastruktur, datenmodell oder abhängigkeiten ## verantwortlich name des release-verantwortlichen ## referenzen - issue / ticket / pull request ``` --- # 12. freigabe und review des prozesses dieser prozess sollte regelmässig überprüft werden, mindestens jedoch: - bei wesentlichen änderungen am entwicklungsprozess, - bei einführung neuer tools, - nach grösseren incidents, - vor externen audits, - mindestens einmal jährlich. | freigabefeld | eintrag | |---|---| | prozessverantwortlicher | | | fachliche freigabe | | | technische freigabe | | | datum der freigabe | | | nächste überprüfung | | --- # 13. kurzfazit der beschriebene prozess stellt sicher, dass feature-entwicklung, bugfixing und releases kontrolliert, nachvollziehbar und auditfähig durchgeführt werden. durch zentrale erfassung, klare rollen, dokumentierte priorisierung, tech workshops, branching-konventionen, code reviews, staging-verifikation und versionierte release notes entsteht ein robuster entwicklungsprozess mit belastbaren nachweisen für interne und externe prüfungen. ", "nextReview": "", "overdueReview": false, "zuPruefen": []}, {"id": "05_betrieb/neutralisierung-detail.md", "path": "05_betrieb/neutralisierung-detail.md", "chapter": "05_betrieb", "title": "neutralisierung-detail.md", "filename": "neutralisierung-detail.md", "meta": {}, "html": "<p># Neutralisierung<\/p>\n<p><strong>Stand:<\/strong> 2026-04-16<\/p>\n<hr>\n<h2>1. Grundidee<\/h2>\n<p>Neutralisierung passiert dort, wo <strong>Content entsteht oder ins System einfliesst<\/strong> — nicht als nachgelagerter Filter vor dem Modell-Call. Wenn Content einmal neutralisiert ist (z. B. im RAG), bleibt er neutralisiert. Kein doppeltes Verarbeiten.<\/p>\n<hr>\n<h2>2. Wer fordert Neutralisierung?<\/h2>\n<p>Drei Quellen, von breit nach spezifisch:<\/p>\n<table><thead><tr><th>Quelle<\/th><th>Flag im Code<\/th><th>Bedeutung<\/th><\/tr><\/thead><tbody><tr><td><strong>Feature-Instanz<\/strong><\/td><td><code>DataNeutraliserConfig.enabled<\/code> (hat <code>featureInstanceId<\/code> + <code>mandateId<\/code>)<\/td><td>Alle Daten in dieser Feature-Instanz werden neutralisiert. Betrifft jeden Content-Einstieg innerhalb dieser Instanz.<\/td><\/tr><tr><td><strong>Chat-Workflow / Session<\/strong><\/td><td><code>ServiceCenterContext.requireNeutralization<\/code> (gesetzt z. B. vom AI-Workspace oder Automation)<\/td><td>Dieser Workflow/Turn: jeder Content, der hier verarbeitet wird, wird neutralisiert.<\/td><\/tr><tr><td><strong>Dokument oder Quelle<\/strong><\/td><td><code>FileItem.neutralize<\/code>, <code>FileFolder.neutralize<\/code>, <code>DataSource.neutralize<\/code>, <code>FeatureDataSource.neutralize<\/code>, <code>FeatureDataSource.neutralizeFields<\/code><\/td><td>Dieses konkrete Objekt: Content daraus wird neutralisiert, egal ob die Feature-Instanz oder der Workflow es sonst fordern würden. <code>FileFolder.neutralize<\/code> propagiert auf alle enthaltenen Dateien. <code>neutralizeFields<\/code> ermöglicht Feld-Level-Maskierung bei DB-Queries.<\/td><\/tr><\/tbody><\/table>\n<p><strong>Auswertung:<\/strong> Irgendeine Quelle sagt <code>True<\/code> → neutralisieren. Keine Quelle kann eine andere aufheben. Es gibt kein <code>False<\/code>-Override, das ein <code>True<\/code> von woanders aushebelt.<\/p>\n<hr>\n<h2>3. Wo passiert die Neutralisierung?<\/h2>\n<p>Am <strong>Punkt der Content-Einspeisung<\/strong> — dort wo Rohdaten zu verarbeitbarem Content werden:<\/p>\n<table><thead><tr><th>Content-Einstieg<\/th><th>Was passiert<\/th><th>Wer prüft das Flag<\/th><\/tr><\/thead><tbody><tr><td><strong>Datei-Indexierung<\/strong> (RAG)<\/td><td>Text-Chunks werden über <code>processText<\/code> neutralisiert, bevor sie ins Embedding gehen. Medien: nur internes Modell oder nicht indexieren. Ergebnis: RAG enthält nur neutralisierten Content.<\/td><td><code>mainServiceKnowledge.indexFile<\/code> liest <code>FileItem.neutralize<\/code><\/td><\/tr><tr><td><strong>Content-Extraktion<\/strong> (Dokumente für KI-Verarbeitung)<\/td><td>Extrahierter Text/Tabellen werden neutralisiert. PDF, DOCX, XLSX, PPTX über <code>processFile<\/code> (Extract → neutralisieren → zurückschreiben).<\/td><td>Caller kennt die Quelle und deren Flag<\/td><\/tr><tr><td><strong>User-Prompt<\/strong> (Chat-Eingabe)<\/td><td>Prompt-Text wird durch <code>processText<\/code> neutralisiert, wenn Feature-Instanz oder Workflow es fordern.<\/td><td><code>mainServiceAi<\/code> prüft Context-Flag / Config<\/td><\/tr><tr><td><strong>DataSource-Download<\/strong><\/td><td>Flag wird auf erstellte <code>FileItem<\/code>s vererbt → bei Extraktion/Indexierung greift das File-Flag automatisch.<\/td><td><code>mainServiceAgent._resolveDataSource<\/code> / <code>_downloadFromDataSource<\/code><\/td><\/tr><tr><td><strong>FeatureDataSource-Abfrage (Tabelle)<\/strong><\/td><td>Wenn eine <code>FeatureDataSource.neutralize=True<\/code> hat → Content aus diesem Sub-Agent-Call wird neutralisiert.<\/td><td><code>mainServiceAgent._queryFeatureInstance<\/code> setzt <code>requireNeutralization=True<\/code><\/td><\/tr><tr><td><strong>FeatureDataSource-Abfrage (Feld/Typ, seit 2026-06)<\/strong><\/td><td>Typ- und vererbungsbewusst: <strong>Strings<\/strong> werden substring-neutralisiert sobald effektiv (explizit ODER geerbt, Feldname als Typ-Hint); <strong>Binary<\/strong> wird gedroppt; <strong>andere Skalare<\/strong> (number/date/bool) nur bei <strong>explizitem<\/strong> Feld-Flag als Ganzwert-Platzhalter <code>[NEUT.&lt;field&gt;.&lt;hash&gt;]<\/code>. Identifikatoren/System-Spalten ausgenommen, Engine-Ausfall = <code>[REDACTED]<\/code>. RAG-Bootstrap nutzt dieselbe Policy (Query- und Index-Pfad konsistent).<\/td><td><code>featureDataProvider.finalizeRowsAsync<\/code> / <code>_neutralizeAndSerializeRows<\/code>; Policy aus <code>coreTools/_featureSubAgentTools<\/code> via <code>resolveEffectiveForFds<\/code><\/td><\/tr><tr><td><strong>De-Neutralisierung für Download (seit 2026-06)<\/strong><\/td><td>Read-only Agent-Tool <code>revealDocument<\/code> löst Platzhalter <strong>nur<\/strong> über das lokale Mapping (<code>resolveText<\/code>, kein externes LLM) auf und liefert Klartext als transienten Einmal-Download (SSE <code>revealDownload<\/code>) — kein Save/Index/Historie.<\/td><td><code>coreTools/_mediaTools._revealDocument<\/code><\/td><\/tr><tr><td><strong>Ordner-Neutralisierung<\/strong><\/td><td><code>FileFolder.neutralize=True<\/code> propagiert auf alle enthaltenen Dateien (rekursiv). Neue/verschobene Dateien erben das Flag. Index-Purge + Re-Index wie bei einzelnen Dateien.<\/td><td><code>routeDataFiles.updateFolderNeutralize<\/code><\/td><\/tr><tr><td><strong>Workflow-Aktion <code>neutralizeData<\/code><\/strong><\/td><td>Expliziter Neutralisierungs-Schritt auf bereits extrahierten ContentParts.<\/td><td>Workflow-Config + <code>NeutralizationConfig.enabled<\/code><\/td><\/tr><\/tbody><\/table>\n<p><strong>Was NICHT nochmal neutralisiert werden muss:<\/strong><\/p>\n<ul><li>RAG-Chunks, die bereits neutralisiert indexiert sind — die sind schon sauber.<\/li><li>Web-Suchergebnisse — enthalten keine Mandantendaten, brauchen keine Neutralisierung.<\/li><\/ul>\n<p><strong>Flag-Änderung:<\/strong> Ändert sich <code>FileItem.neutralize<\/code> (Toggle) → Index löschen → Re-Indexierung triggern → neuer Index ist im richtigen Zustand.<\/p>\n<hr>\n<h2>4. Engine: <code>NeutralizationService<\/code><\/h2>\n<p>Eine Engine, drei Einstiege, aufgerufen an den Content-Einstiegspunkten aus Abschnitt 3.<\/p>\n<table><thead><tr><th>API<\/th><th>Eingabe<\/th><th>Status<\/th><\/tr><\/thead><tbody><tr><td><code>processText(text)<\/code><\/td><td>Rohtext (Prompt, Message, Text-ContentPart, Text-Chunk)<\/td><td><strong>Ist<\/strong><\/td><\/tr><tr><td><code>processFile(fileId)<\/code><\/td><td>Datei aus DB — wird nach MIME geroutet<\/td><td><strong>Ist<\/strong><\/td><\/tr><tr><td><code>processBinaryBytes<\/code> / <code>Async<\/code><\/td><td>Bytes + Dateiname + MIME<\/td><td><strong>Ist<\/strong><\/td><\/tr><tr><td><strong><code>processImage(imageBytes, fileName)<\/code><\/strong> / <code>processImageAsync<\/code><\/td><td>Bild-Datei oder Bild-ContentPart (image/png, image/jpeg, …)<\/td><td><strong>Ist<\/strong> (seit ~2026 Q1)<\/td><\/tr><\/tbody><\/table>\n<p><strong>Ist-Zustand Bilder (aktualisiert 2026-04-05):<\/strong> <code>processImageAsync<\/code> ist implementiert und nutzt <code>NEUTRALIZATION_IMAGE<\/code> (Private LLM Vision). <code>_processBinaryFile<\/code> verarbeitet jetzt Bild-Parts über <code>processImageAsync<\/code>. <strong>Einschränkung:<\/strong> Eigenständige Bild-Dateien (<code>image/*<\/code> MIME direkt an <code>processFile<\/code>) werden in <code>_isBinaryMimeType<\/code> weiterhin als Skip behandelt.<\/p>\n<p><strong>Ist (aktualisiert):<\/strong> <code>processImageAsync<\/code> existiert als Einstieg. Ruft internes Vision-Modell (<code>NEUTRALIZATION_IMAGE<\/code> → Private-LLM) auf, um sensible Inhalte in Bildern zu erkennen/entfernen. Kein externer Provider. Modell nicht verfügbar → Bild blockieren (nicht unbehandelt weiterreichen).<\/p>\n<p><strong>Ablauf nach MIME:<\/strong><\/p>\n<table><thead><tr><th>MIME<\/th><th>Pfad<\/th><\/tr><\/thead><tbody><tr><td>PDF, DOCX, XLSX, PPTX<\/td><td><code>runExtraction<\/code> → Text/Table-Parts durch <code>_neutralizeText<\/code>, Bild-Parts durch <code>processImage<\/code> → PDF in-place oder Office-Renderer<\/td><\/tr><tr><td>Text, JSON, CSV, XML<\/td><td><code>_neutralizeText<\/code> direkt (TextProcessor, ListProcessor, BinaryProcessor je nach Inhalt)<\/td><\/tr><tr><td>Bilder (image/*)<\/td><td><strong><code>processImage<\/code><\/strong> → internes Vision-Modell (<code>NEUTRALIZATION_IMAGE<\/code>). Nicht verfügbar → blockieren.<\/td><\/tr><tr><td>Video, Audio<\/td><td>Nur internes Modell oder blockieren (analog Bilder, aber niedrigere Priorität)<\/td><\/tr><tr><td>Anderes Binary<\/td><td>Skip (nicht unterstützt)<\/td><\/tr><\/tbody><\/table>\n<p><strong>Mapping:<\/strong> Platzhalter <code>[typ.uuid]<\/code> → Attribute in DB. <code>resolveText(text)<\/code> für Rückübersetzung.<\/p>\n<hr>\n<h2>5. Modellauswahl<\/h2>\n<table><thead><tr><th>Operation Type<\/th><th>Modelle<\/th><th>Zweck<\/th><\/tr><\/thead><tbody><tr><td><code>NEUTRALIZATION_TEXT<\/code><\/td><td><code>poweron-text-general<\/code> (Rating 9)<\/td><td>Falls Engine ein LLM für Text braucht<\/td><\/tr><tr><td><code>NEUTRALIZATION_IMAGE<\/code><\/td><td><code>poweron-vision-general<\/code> (9), <code>poweron-vision-deep<\/code> (9)<\/td><td>Medien bei Neutralisierungspflicht: nur intern<\/td><\/tr><\/tbody><\/table>\n<p>Registriert in <code>aicorePluginPrivateLlm.py<\/code>. Externe Provider haben keine <code>NEUTRALIZATION_*<\/code>-Ratings → werden nie für Neutralisierung gewählt.<\/p>\n<hr>\n<h2>6. Fail-safe<\/h2>\n<table><thead><tr><th>Situation<\/th><th>Verhalten<\/th><\/tr><\/thead><tbody><tr><td>Neutralisierung gefordert, Engine nicht verfügbar<\/td><td>Content <strong>nicht<\/strong> weiterverarbeiten (blockieren)<\/td><\/tr><tr><td>Neutralisierung eines Teils schlägt fehl<\/td><td>Teil entfernen, nicht im Rohzustand weiterleiten<\/td><\/tr><tr><td>Kein internes Modell für Medien verfügbar<\/td><td>Medien-Part entfernen<\/td><\/tr><\/tbody><\/table>\n<hr>\n<h2>7. Code-Karte<\/h2>\n<table><thead><tr><th>Bereich<\/th><th>Pfad<\/th><\/tr><\/thead><tbody><tr><td>Engine<\/td><td><code>features/neutralization/serviceNeutralization/mainServiceNeutralization.py<\/code> + <code>subProcess*.py<\/code><\/td><\/tr><tr><td>Config + Attribute DB<\/td><td><code>features/neutralization/datamodelFeatureNeutralizer.py<\/code>, <code>interfaceFeatureNeutralizer.py<\/code><\/td><\/tr><tr><td>Index (Data-at-rest)<\/td><td><code>serviceCenter/services/serviceKnowledge/mainServiceKnowledge.py<\/code><\/td><\/tr><tr><td>Prompt-Neutralisierung<\/td><td><code>serviceCenter/services/serviceAi/mainServiceAi.py<\/code> (<code>_shouldNeutralize<\/code>, <code>_neutralizeRequest<\/code>)<\/td><\/tr><tr><td>Agent / DataSource / Feature<\/td><td><code>serviceCenter/services/serviceAgent/mainServiceAgent.py<\/code><\/td><\/tr><tr><td>Workflow-Aktion<\/td><td><code>workflows/methods/methodContext/actions/neutralizeData.py<\/code><\/td><\/tr><tr><td>Modelle / Enums<\/td><td><code>datamodels/datamodelAi.py<\/code>, <code>aicore/aicorePluginPrivateLlm.py<\/code><\/td><\/tr><tr><td>Flags<\/td><td><code>datamodelFiles.py<\/code> (<code>FileItem.neutralize<\/code>), <code>datamodelDataSource.py<\/code>, <code>datamodelFeatureDataSource.py<\/code><\/td><\/tr><tr><td>Context<\/td><td><code>serviceCenter/context.py<\/code> (<code>ServiceCenterContext.requireNeutralization<\/code>)<\/td><\/tr><\/tbody><\/table>\n<hr>\n<h2>8. Umsetzungsplan<\/h2>\n<h3>Schritt 1: <code>processImage<\/code> in Engine bauen<\/h3>\n<p><strong>Datei:<\/strong> <code>mainServiceNeutralization.py<\/code> <strong>Was:<\/strong> Neue Methode <code>processImage(imageBytes: bytes, fileName: str, mimeType: str) -&gt; Dict<\/code> und <code>processImageAsync<\/code>. <strong>Wie:<\/strong> Internes Vision-Modell aufrufen (<code>NEUTRALIZATION_IMAGE<\/code> via Model Selector / <code>aiObjects<\/code>). Prompt: sensible Inhalte im Bild erkennen und beschreiben, damit Caller entscheiden kann ob Bild blockiert wird. Kein internes Modell verfügbar → <code>{'status': 'blocked'}<\/code> zurückgeben. <strong>Abhängigkeit:<\/strong> <code>OperationTypeEnum.NEUTRALIZATION_IMAGE<\/code> + Modell-Ratings in <code>aicorePluginPrivateLlm.py<\/code> — <strong>bereits erledigt<\/strong>.<\/p>\n<h3>Schritt 2: <code>_shouldNeutralize<\/code> vereinfachen<\/h3>\n<p><strong>Datei:<\/strong> <code>mainServiceAi.py<\/code> (Zeile ~560) <strong>Ist:<\/strong> Prüft <code>request.requireNeutralization<\/code> → <code>context.requireNeutralization<\/code> → <code>NeutralizationConfig.enabled<\/code> (Mandant-Level Config). <code>request.requireNeutralization=False<\/code> bricht sofort ab. <strong>Soll:<\/strong> Drei Quellen gemäss Abschnitt 2, kein <code>False<\/code>-Override:<\/p>\n<ol><li>Feature-Instanz: <code>NeutralizationConfig.enabled<\/code> (hat <code>featureInstanceId<\/code>)<\/li><li>Workflow/Session: <code>context.requireNeutralization<\/code><\/li><li>Request: <code>request.requireNeutralization<\/code><\/li><\/ol>\n<p>Irgendein <code>True<\/code> → neutralisieren. <code>False<\/code> in einer Quelle hebt <code>True<\/code> in einer anderen <strong>nicht<\/strong> auf. <strong>Änderung:<\/strong> <code>if request.requireNeutralization is False: return False<\/code> <strong>entfernen<\/strong>. Stattdessen OR-Verknüpfung aller drei Quellen.<\/p>\n<h3>Schritt 3: <code>_neutralizeRequest<\/code> auf Prompt/Messages beschränken<\/h3>\n<p><strong>Datei:<\/strong> <code>mainServiceAi.py<\/code> (Zeile ~592) <strong>Ist:<\/strong> Neutralisiert <code>prompt<\/code>, <code>context<\/code>, <code>messages<\/code> (String-Content). <strong>Soll:<\/strong> Zusätzlich Text in <code>contentParts<\/code> und Text-Teile in multimodalen Messages (content-Liste mit <code>type==text<\/code>). Bild-Teile in Messages: bei Neutralisierungspflicht über <code>processImage<\/code> prüfen oder entfernen. <strong>Wichtig:<\/strong> Hier geht es nur um Prompt-/Sessiondaten. File-Content aus RAG ist bereits neutralisiert (Schritt 5), muss hier nicht nochmal durch.<\/p>\n<h3>Schritt 4: <code>indexFile<\/code> — Bild-Chunks behandeln<\/h3>\n<p><strong>Datei:<\/strong> <code>mainServiceKnowledge.py<\/code> (Zeile ~146 ff.) <strong>Ist:<\/strong> Nur <code>textObjects<\/code> (contentType == \"text\") werden bei <code>_shouldNeutralize<\/code> durch <code>processText<\/code> geschickt. Bild-Chunks (<code>contentType == \"image\"<\/code>) werden unverändert indexiert. <strong>Soll:<\/strong> Bild-Chunks bei <code>_shouldNeutralize<\/code> über <code>processImage<\/code> (Schritt 1) prüfen. Ergebnis <code>blocked<\/code> → Bild-Chunk nicht indexieren. Ergebnis OK → Bild-Chunk indexieren (internes Modell hat es gesehen, kein externer Provider nötig). <strong>Abhängigkeit:<\/strong> Schritt 1.<\/p>\n<h3>Schritt 5: Agent-Tool <code>readFile<\/code> — Content bei Extraktion neutralisieren<\/h3>\n<p><strong>Datei:<\/strong> <code>mainServiceAgent.py<\/code>, Tool <code>_readFile<\/code> (Zeile ~540 ff.) <strong>Ist:<\/strong> Liest aus Knowledge Store (bereits indexiert) oder extrahiert on-demand. Kein Neutralisierungs-Check. <strong>Soll:<\/strong><\/p>\n<ul><li><strong>Knowledge Store Pfad (Zeile ~548):<\/strong> RAG-Chunks sind bereits neutralisiert wenn <code>FileItem.neutralize=True<\/code> war (Schritt 4) → nichts zu tun.<\/li><li><strong>On-Demand Extraktion (Zeile ~630 ff.):<\/strong> Nach <code>runExtraction<\/code> und vor Rückgabe der Text-Objekte: <code>FileItem.neutralize<\/code> laden. Wenn <code>True<\/code> → Text-Objekte durch <code>processText<\/code>, Bild-Objekte durch <code>processImage<\/code>.<\/li><\/ul>\n<h3>Schritt 6: Agent-Tool <code>summarizeContent<\/code> — File-Flag prüfen<\/h3>\n<p><strong>Datei:<\/strong> <code>mainServiceAgent.py<\/code>, Tool <code>_summarizeContent<\/code> (Zeile ~1921 ff.) <strong>Ist:<\/strong> Liest Content-Objects aus Knowledge Store, baut <code>combinedText<\/code> und ruft <code>callAi<\/code> auf. Kein Neutralisierungs-Check. <strong>Soll:<\/strong> Content aus Knowledge Store ist bereits neutralisiert (Schritt 4) → nichts zu tun, <strong>sofern<\/strong> File indexiert war. Wenn nicht indexiert: File-Flag prüfen, Text vor <code>callAi<\/code> durch <code>processText<\/code>. <strong>Hinweis:<\/strong> Durch Schritt 4 ist der Regelfall abgedeckt.<\/p>\n<h3>Schritt 7: Agent-Tool <code>describeImage<\/code> — File-Flag prüfen<\/h3>\n<p><strong>Datei:<\/strong> <code>mainServiceAgent.py<\/code>, Tool <code>_describeImage<\/code> (Zeile ~2015 ff.) <strong>Ist:<\/strong> Lädt Bild-Chunk oder Rohdaten, sendet per <code>callAi<\/code> mit <code>IMAGE_ANALYSE<\/code> an <strong>beliebigen<\/strong> Provider (inkl. extern). Kein Neutralisierungs-Check. <strong>Soll:<\/strong> <code>FileItem.neutralize<\/code> laden (fileId ist bekannt). Wenn <code>True<\/code>:<\/p>\n<ul><li><code>operationType<\/code> auf <code>NEUTRALIZATION_IMAGE<\/code> statt <code>IMAGE_ANALYSE<\/code> → Model Selector wählt nur internes Modell.<\/li><li>Kein internes Modell → Tool gibt Fehler zurück statt Bild an externen Provider zu senden.<\/li><\/ul>\n<h3>Schritt 8: <code>_processBinaryFile<\/code> — Bild-Parts nicht mehr überspringen<\/h3>\n<p><strong>Datei:<\/strong> <code>mainServiceNeutralization.py<\/code> (Zeile ~298) <strong>Ist:<\/strong> <code>if type_group in ('binary', 'image'): neutralized_parts.append(part); continue<\/code> — Bild-Parts werden übersprungen. <strong>Soll:<\/strong> <code>binary<\/code> weiterhin skip. <code>image<\/code> → durch <code>processImage<\/code> (Schritt 1). Ergebnis <code>blocked<\/code> → Part entfernen. Ergebnis OK → Part behalten. <strong>Abhängigkeit:<\/strong> Schritt 1.<\/p>\n<h3>Schritt 9: Workflow-Aktion <code>neutralizeData<\/code> — Bild-Parts<\/h3>\n<p><strong>Datei:<\/strong> <code>neutralizeData.py<\/code> (Zeile ~130 ff.) <strong>Ist:<\/strong> Iteriert über ContentParts, neutralisiert nur Parts mit <code>part.data<\/code> (Text). <code>typeGroup != text/table<\/code> → unverändert durchgereicht. <strong>Soll:<\/strong> Bild-Parts durch <code>processImage<\/code>. Ergebnis <code>blocked<\/code> → Part entfernen. <strong>Abhängigkeit:<\/strong> Schritt 1.<\/p>\n<h3>Schritt 10: Tests<\/h3>\n<table><thead><tr><th>Test<\/th><th>Was<\/th><\/tr><\/thead><tbody><tr><td>T1<\/td><td><code>FileItem.neutralize=True<\/code> → <code>indexFile<\/code> → Text-Chunks neutralisiert, Bild-Chunks geprüft/blockiert<\/td><\/tr><tr><td>T2<\/td><td><code>readFile<\/code> on-demand auf File mit <code>neutralize=True<\/code> → Text neutralisiert<\/td><\/tr><tr><td>T3<\/td><td><code>describeImage<\/code> auf File mit <code>neutralize=True<\/code> → nur internes Modell<\/td><\/tr><tr><td>T4<\/td><td>Feature-Instanz Config <code>enabled=True<\/code> → Prompt in <code>callAi<\/code> neutralisiert<\/td><\/tr><tr><td>T5<\/td><td>Workflow <code>requireNeutralization=True<\/code> → Prompt neutralisiert<\/td><\/tr><tr><td>T6<\/td><td><code>processFile<\/code> auf PDF mit Bildern → Text neutralisiert, Bild-Parts durch <code>processImage<\/code><\/td><\/tr><tr><td>T7<\/td><td>Flag-Toggle → Index gelöscht → Re-Index im richtigen Zustand<\/td><\/tr><\/tbody><\/table>\n<h3>Schritt 11: Logging<\/h3>\n<p><strong>Alle Stellen (Schritte 2–9):<\/strong> Bei Neutralisierung loggen: welche Quelle (Feature-Instanz / Workflow / File-Flag), welche <code>fileId<\/code> falls vorhanden, Ergebnis (OK / Part entfernt / blockiert). <strong>Kein Klartext<\/strong> in Logs.<\/p>", "text": "# neutralisierung **stand:** 2026-04-16 --- ## 1. grundidee neutralisierung passiert dort, wo **content entsteht oder ins system einfliesst** — nicht als nachgelagerter filter vor dem modell-call. wenn content einmal neutralisiert ist (z. b. im rag), bleibt er neutralisiert. kein doppeltes verarbeiten. --- ## 2. wer fordert neutralisierung? drei quellen, von breit nach spezifisch: | quelle | flag im code | bedeutung | |--------|-------------|-----------| | **feature-instanz** | `dataneutraliserconfig.enabled` (hat `featureinstanceid` + `mandateid`) | alle daten in dieser feature-instanz werden neutralisiert. betrifft jeden content-einstieg innerhalb dieser instanz. | | **chat-workflow / session** | `servicecentercontext.requireneutralization` (gesetzt z. b. vom ai-workspace oder automation) | dieser workflow/turn: jeder content, der hier verarbeitet wird, wird neutralisiert. | | **dokument oder quelle** | `fileitem.neutralize`, `filefolder.neutralize`, `datasource.neutralize`, `featuredatasource.neutralize`, `featuredatasource.neutralizefields` | dieses konkrete objekt: content daraus wird neutralisiert, egal ob die feature-instanz oder der workflow es sonst fordern würden. `filefolder.neutralize` propagiert auf alle enthaltenen dateien. `neutralizefields` ermöglicht feld-level-maskierung bei db-queries. | **auswertung:** irgendeine quelle sagt `true` → neutralisieren. keine quelle kann eine andere aufheben. es gibt kein `false`-override, das ein `true` von woanders aushebelt. --- ## 3. wo passiert die neutralisierung? am **punkt der content-einspeisung** — dort wo rohdaten zu verarbeitbarem content werden: | content-einstieg | was passiert | wer prüft das flag | |------------------|-------------|---------------------| | **datei-indexierung** (rag) | text-chunks werden über `processtext` neutralisiert, bevor sie ins embedding gehen. medien: nur internes modell oder nicht indexieren. ergebnis: rag enthält nur neutralisierten content. | `mainserviceknowledge.indexfile` liest `fileitem.neutralize` | | **content-extraktion** (dokumente für ki-verarbeitung) | extrahierter text/tabellen werden neutralisiert. pdf, docx, xlsx, pptx über `processfile` (extract → neutralisieren → zurückschreiben). | caller kennt die quelle und deren flag | | **user-prompt** (chat-eingabe) | prompt-text wird durch `processtext` neutralisiert, wenn feature-instanz oder workflow es fordern. | `mainserviceai` prüft context-flag / config | | **datasource-download** | flag wird auf erstellte `fileitem`s vererbt → bei extraktion/indexierung greift das file-flag automatisch. | `mainserviceagent._resolvedatasource` / `_downloadfromdatasource` | | **featuredatasource-abfrage (tabelle)** | wenn eine `featuredatasource.neutralize=true` hat → content aus diesem sub-agent-call wird neutralisiert. | `mainserviceagent._queryfeatureinstance` setzt `requireneutralization=true` | | **featuredatasource-abfrage (feld/typ, seit 2026-06)** | typ- und vererbungsbewusst: **strings** werden substring-neutralisiert sobald effektiv (explizit oder geerbt, feldname als typ-hint); **binary** wird gedroppt; **andere skalare** (number/date/bool) nur bei **explizitem** feld-flag als ganzwert-platzhalter `[neut.<field>.<hash>]`. identifikatoren/system-spalten ausgenommen, engine-ausfall = `[redacted]`. rag-bootstrap nutzt dieselbe policy (query- und index-pfad konsistent). | `featuredataprovider.finalizerowsasync` / `_neutralizeandserializerows`; policy aus `coretools/_featuresubagenttools` via `resolveeffectiveforfds` | | **de-neutralisierung für download (seit 2026-06)** | read-only agent-tool `revealdocument` löst platzhalter **nur** über das lokale mapping (`resolvetext`, kein externes llm) auf und liefert klartext als transienten einmal-download (sse `revealdownload`) — kein save/index/historie. | `coretools/_mediatools._revealdocument` | | **ordner-neutralisierung** | `filefolder.neutralize=true` propagiert auf alle enthaltenen dateien (rekursiv). neue/verschobene dateien erben das flag. index-purge + re-index wie bei einzelnen dateien. | `routedatafiles.updatefolderneutralize` | | **workflow-aktion `neutralizedata`** | expliziter neutralisierungs-schritt auf bereits extrahierten contentparts. | workflow-config + `neutralizationconfig.enabled` | **was nicht nochmal neutralisiert werden muss:** - rag-chunks, die bereits neutralisiert indexiert sind — die sind schon sauber. - web-suchergebnisse — enthalten keine mandantendaten, brauchen keine neutralisierung. **flag-änderung:** ändert sich `fileitem.neutralize` (toggle) → index löschen → re-indexierung triggern → neuer index ist im richtigen zustand. --- ## 4. engine: `neutralizationservice` eine engine, drei einstiege, aufgerufen an den content-einstiegspunkten aus abschnitt 3. | api | eingabe | status | |-----|---------|--------| | `processtext(text)` | rohtext (prompt, message, text-contentpart, text-chunk) | **ist** | | `processfile(fileid)` | datei aus db — wird nach mime geroutet | **ist** | | `processbinarybytes` / `async` | bytes + dateiname + mime | **ist** | | **`processimage(imagebytes, filename)`** / `processimageasync` | bild-datei oder bild-contentpart (image/png, image/jpeg, …) | **ist** (seit ~2026 q1) | **ist-zustand bilder (aktualisiert 2026-04-05):** `processimageasync` ist implementiert und nutzt `neutralization_image` (private llm vision). `_processbinaryfile` verarbeitet jetzt bild-parts über `processimageasync`. **einschränkung:** eigenständige bild-dateien (`image/*` mime direkt an `processfile`) werden in `_isbinarymimetype` weiterhin als skip behandelt. **ist (aktualisiert):** `processimageasync` existiert als einstieg. ruft internes vision-modell (`neutralization_image` → private-llm) auf, um sensible inhalte in bildern zu erkennen/entfernen. kein externer provider. modell nicht verfügbar → bild blockieren (nicht unbehandelt weiterreichen). **ablauf nach mime:** | mime | pfad | |------|------| | pdf, docx, xlsx, pptx | `runextraction` → text/table-parts durch `_neutralizetext`, bild-parts durch `processimage` → pdf in-place oder office-renderer | | text, json, csv, xml | `_neutralizetext` direkt (textprocessor, listprocessor, binaryprocessor je nach inhalt) | | bilder (image/*) | **`processimage`** → internes vision-modell (`neutralization_image`). nicht verfügbar → blockieren. | | video, audio | nur internes modell oder blockieren (analog bilder, aber niedrigere priorität) | | anderes binary | skip (nicht unterstützt) | **mapping:** platzhalter `[typ.uuid]` → attribute in db. `resolvetext(text)` für rückübersetzung. --- ## 5. modellauswahl | operation type | modelle | zweck | |----------------|---------|-------| | `neutralization_text` | `poweron-text-general` (rating 9) | falls engine ein llm für text braucht | | `neutralization_image` | `poweron-vision-general` (9), `poweron-vision-deep` (9) | medien bei neutralisierungspflicht: nur intern | registriert in `aicorepluginprivatellm.py`. externe provider haben keine `neutralization_*`-ratings → werden nie für neutralisierung gewählt. --- ## 6. fail-safe | situation | verhalten | |-----------|-----------| | neutralisierung gefordert, engine nicht verfügbar | content **nicht** weiterverarbeiten (blockieren) | | neutralisierung eines teils schlägt fehl | teil entfernen, nicht im rohzustand weiterleiten | | kein internes modell für medien verfügbar | medien-part entfernen | --- ## 7. code-karte | bereich | pfad | |---------|------| | engine | `features/neutralization/serviceneutralization/mainserviceneutralization.py` + `subprocess*.py` | | config + attribute db | `features/neutralization/datamodelfeatureneutralizer.py`, `interfacefeatureneutralizer.py` | | index (data-at-rest) | `servicecenter/services/serviceknowledge/mainserviceknowledge.py` | | prompt-neutralisierung | `servicecenter/services/serviceai/mainserviceai.py` (`_shouldneutralize`, `_neutralizerequest`) | | agent / datasource / feature | `servicecenter/services/serviceagent/mainserviceagent.py` | | workflow-aktion | `workflows/methods/methodcontext/actions/neutralizedata.py` | | modelle / enums | `datamodels/datamodelai.py`, `aicore/aicorepluginprivatellm.py` | | flags | `datamodelfiles.py` (`fileitem.neutralize`), `datamodeldatasource.py`, `datamodelfeaturedatasource.py` | | context | `servicecenter/context.py` (`servicecentercontext.requireneutralization`) | --- ## 8. umsetzungsplan ### schritt 1: `processimage` in engine bauen **datei:** `mainserviceneutralization.py` **was:** neue methode `processimage(imagebytes: bytes, filename: str, mimetype: str) -> dict` und `processimageasync`. **wie:** internes vision-modell aufrufen (`neutralization_image` via model selector / `aiobjects`). prompt: sensible inhalte im bild erkennen und beschreiben, damit caller entscheiden kann ob bild blockiert wird. kein internes modell verfügbar → `{'status': 'blocked'}` zurückgeben. **abhängigkeit:** `operationtypeenum.neutralization_image` + modell-ratings in `aicorepluginprivatellm.py` — **bereits erledigt**. ### schritt 2: `_shouldneutralize` vereinfachen **datei:** `mainserviceai.py` (zeile ~560) **ist:** prüft `request.requireneutralization` → `context.requireneutralization` → `neutralizationconfig.enabled` (mandant-level config). `request.requireneutralization=false` bricht sofort ab. **soll:** drei quellen gemäss abschnitt 2, kein `false`-override: 1. feature-instanz: `neutralizationconfig.enabled` (hat `featureinstanceid`) 2. workflow/session: `context.requireneutralization` 3. request: `request.requireneutralization` irgendein `true` → neutralisieren. `false` in einer quelle hebt `true` in einer anderen **nicht** auf. **änderung:** `if request.requireneutralization is false: return false` **entfernen**. stattdessen or-verknüpfung aller drei quellen. ### schritt 3: `_neutralizerequest` auf prompt/messages beschränken **datei:** `mainserviceai.py` (zeile ~592) **ist:** neutralisiert `prompt`, `context`, `messages` (string-content). **soll:** zusätzlich text in `contentparts` und text-teile in multimodalen messages (content-liste mit `type==text`). bild-teile in messages: bei neutralisierungspflicht über `processimage` prüfen oder entfernen. **wichtig:** hier geht es nur um prompt-/sessiondaten. file-content aus rag ist bereits neutralisiert (schritt 5), muss hier nicht nochmal durch. ### schritt 4: `indexfile` — bild-chunks behandeln **datei:** `mainserviceknowledge.py` (zeile ~146 ff.) **ist:** nur `textobjects` (contenttype == \"text\") werden bei `_shouldneutralize` durch `processtext` geschickt. bild-chunks (`contenttype == \"image\"`) werden unverändert indexiert. **soll:** bild-chunks bei `_shouldneutralize` über `processimage` (schritt 1) prüfen. ergebnis `blocked` → bild-chunk nicht indexieren. ergebnis ok → bild-chunk indexieren (internes modell hat es gesehen, kein externer provider nötig). **abhängigkeit:** schritt 1. ### schritt 5: agent-tool `readfile` — content bei extraktion neutralisieren **datei:** `mainserviceagent.py`, tool `_readfile` (zeile ~540 ff.) **ist:** liest aus knowledge store (bereits indexiert) oder extrahiert on-demand. kein neutralisierungs-check. **soll:** - **knowledge store pfad (zeile ~548):** rag-chunks sind bereits neutralisiert wenn `fileitem.neutralize=true` war (schritt 4) → nichts zu tun. - **on-demand extraktion (zeile ~630 ff.):** nach `runextraction` und vor rückgabe der text-objekte: `fileitem.neutralize` laden. wenn `true` → text-objekte durch `processtext`, bild-objekte durch `processimage`. ### schritt 6: agent-tool `summarizecontent` — file-flag prüfen **datei:** `mainserviceagent.py`, tool `_summarizecontent` (zeile ~1921 ff.) **ist:** liest content-objects aus knowledge store, baut `combinedtext` und ruft `callai` auf. kein neutralisierungs-check. **soll:** content aus knowledge store ist bereits neutralisiert (schritt 4) → nichts zu tun, **sofern** file indexiert war. wenn nicht indexiert: file-flag prüfen, text vor `callai` durch `processtext`. **hinweis:** durch schritt 4 ist der regelfall abgedeckt. ### schritt 7: agent-tool `describeimage` — file-flag prüfen **datei:** `mainserviceagent.py`, tool `_describeimage` (zeile ~2015 ff.) **ist:** lädt bild-chunk oder rohdaten, sendet per `callai` mit `image_analyse` an **beliebigen** provider (inkl. extern). kein neutralisierungs-check. **soll:** `fileitem.neutralize` laden (fileid ist bekannt). wenn `true`: - `operationtype` auf `neutralization_image` statt `image_analyse` → model selector wählt nur internes modell. - kein internes modell → tool gibt fehler zurück statt bild an externen provider zu senden. ### schritt 8: `_processbinaryfile` — bild-parts nicht mehr überspringen **datei:** `mainserviceneutralization.py` (zeile ~298) **ist:** `if type_group in ('binary', 'image'): neutralized_parts.append(part); continue` — bild-parts werden übersprungen. **soll:** `binary` weiterhin skip. `image` → durch `processimage` (schritt 1). ergebnis `blocked` → part entfernen. ergebnis ok → part behalten. **abhängigkeit:** schritt 1. ### schritt 9: workflow-aktion `neutralizedata` — bild-parts **datei:** `neutralizedata.py` (zeile ~130 ff.) **ist:** iteriert über contentparts, neutralisiert nur parts mit `part.data` (text). `typegroup != text/table` → unverändert durchgereicht. **soll:** bild-parts durch `processimage`. ergebnis `blocked` → part entfernen. **abhängigkeit:** schritt 1. ### schritt 10: tests | test | was | |------|-----| | t1 | `fileitem.neutralize=true` → `indexfile` → text-chunks neutralisiert, bild-chunks geprüft/blockiert | | t2 | `readfile` on-demand auf file mit `neutralize=true` → text neutralisiert | | t3 | `describeimage` auf file mit `neutralize=true` → nur internes modell | | t4 | feature-instanz config `enabled=true` → prompt in `callai` neutralisiert | | t5 | workflow `requireneutralization=true` → prompt neutralisiert | | t6 | `processfile` auf pdf mit bildern → text neutralisiert, bild-parts durch `processimage` | | t7 | flag-toggle → index gelöscht → re-index im richtigen zustand | ### schritt 11: logging **alle stellen (schritte 2–9):** bei neutralisierung loggen: welche quelle (feature-instanz / workflow / file-flag), welche `fileid` falls vorhanden, ergebnis (ok / part entfernt / blockiert). **kein klartext** in logs. ", "nextReview": "", "overdueReview": false, "zuPruefen": []}, {"id": "05_betrieb/security-overview.md", "path": "05_betrieb/security-overview.md", "chapter": "05_betrieb", "title": "PowerOn Plattform -- Sicherheit und Compliance", "filename": "security-overview.md", "meta": {}, "html": "<h1>PowerOn Plattform -- Sicherheit und Compliance<\/h1>\n<p><strong>Stand:<\/strong> Februar 2026 <strong>Zielgruppe:<\/strong> Entscheidungsträger, Einkauf, Rechtsabteilung, Datenschutzbeauftragte <strong>Klassifizierung:<\/strong> Kundeninformation<\/p>\n<hr>\n<h2>1. Management Summary<\/h2>\n<p>PowerOn ist eine <strong>Multi-Mandanten-KI-Plattform für Unternehmen<\/strong>, die es Organisationen ermöglicht, KI-gestützte Geschäftsprozesse sicher, datenschutzkonform und mandantengetrennt zu betreiben. Die Plattform richtet sich an mittlere bis grosse Unternehmen in datenschutzsensiblen Branchen wie Finanzwesen, Treuhand, Immobilien und Beratung.<\/p>\n<p>Dieses Dokument beschreibt die in PowerOn implementierten Sicherheits- und Datenschutzmassnahmen, ordnet diese gängigen Standards zu und benennt transparent bestehende Einschränkungen.<\/p>\n<p><strong>Kernaussagen:<\/strong><\/p>\n<ul><li><strong>DSGVO-Betroffenenrechte<\/strong> (Auskunft, Löschung, Datenübertragbarkeit, Berichtigung) sind als Self-Service-Funktionen direkt in der Plattform implementiert.<\/li><li><strong>Vollständige Mandantentrennung:<\/strong> Daten eines Mandanten sind unter keinen Umständen für andere Mandanten einsehbar oder zugänglich.<\/li><li><strong>Rollenbasierte Zugriffskontrolle (RBAC):<\/strong> Jeder Datenzugriff wird gegen ein mehrstufiges Berechtigungssystem geprüft -- konfigurierbar pro Mandant und Funktionsmodul.<\/li><li><strong>Verschlüsselung:<\/strong> Sensible Konfigurationsdaten sind nach Industriestandard verschlüsselt, sämtliche Kommunikation erfolgt über verschlüsselte Verbindungen.<\/li><li><strong>Audit-Trail:<\/strong> Alle sicherheitsrelevanten Aktionen werden lückenlos protokolliert und stehen für Compliance-Nachweise zur Verfügung.<\/li><li><strong>Transparenz bei KI-Nutzung:<\/strong> Die Plattform dokumentiert offen, welche Daten an KI-Dienste übermittelt werden, und bietet Konfigurationsoptionen für höchste Datenschutzanforderungen.<\/li><\/ul>\n<hr>\n<h2>2. DSGVO-Konformität<\/h2>\n<p>PowerOn implementiert die zentralen Betroffenenrechte der Datenschutz-Grundverordnung (DSGVO/GDPR) direkt als Plattformfunktionen. Im Folgenden wird für jeden relevanten Artikel beschrieben, was implementiert ist und wo Einschränkungen bestehen.<\/p>\n<h3>2.1 Auskunftsrecht (Art. 15 DSGVO)<\/h3>\n<p>Nutzer können über eine Self-Service-Funktion sämtliche über sie gespeicherten Daten exportieren:<\/p>\n<ul><li>Persönliche Profildaten (Name, E-Mail, Spracheinstellungen)<\/li><li>Mandatszugehörigkeiten und zugewiesene Rollen<\/li><li>Zugriffsrechte auf Funktionsmodule<\/li><li>Erstellte und eingelöste Einladungen<\/li><li>Zeitpunkte der Kontörstellung und letzten Anmeldung<\/li><\/ul>\n<p>Der Export umfasst alle auf Plattformebene gespeicherten Daten. Feature-spezifische Daten (z.B. Chat-Verläufe, Treuhandpositionen) können über die jeweiligen Funktionsmodule eingesehen werden.<\/p>\n<p><strong>Status: Implementiert.<\/strong><\/p>\n<h3>2.2 Recht auf Löschung (Art. 17 DSGVO)<\/h3>\n<p>Nutzer können ihr Konto und alle zugehörigen Daten eigenständig und unwiderruflich löschen. Dabei gilt:<\/p>\n<ul><li>Das System durchsucht automatisch alle Datenbanken (Plattform, Verwaltung, Chat, alle Funktionsmodule) nach Einträgen, die dem Nutzer zugeordnet sind.<\/li><li>Nutzerbezogene Daten werden vollständig gelöscht.<\/li><li>Audit-Logs werden anonymisiert statt gelöscht -- dies gewährleistet die Einhaltung gesetzlicher Aufbewahrungspflichten bei gleichzeitiger Wahrung der Betroffenenrechte.<\/li><li>Die Löschung erfordert eine explizite Bestätigung durch den Nutzer.<\/li><li>Systemadministratoren sind von der Selbstlöschung ausgenommen (Vier-Augen-Prinzip).<\/li><\/ul>\n<p><strong>Status: Implementiert.<\/strong><\/p>\n<h3>2.3 Recht auf Datenübertragbarkeit (Art. 20 DSGVO)<\/h3>\n<p>Nutzerdaten können in einem maschinenlesbaren, standardisierten Format (JSON-LD nach schema.org) exportiert werden. Dieses Format ermöglicht die Übertragung der Daten an einen anderen Dienstleister.<\/p>\n<p><strong>Status: Implementiert.<\/strong><\/p>\n<h3>2.4 Berichtigungsrecht (Art. 16 DSGVO)<\/h3>\n<p>Nutzer können ihre Profildaten (Name, E-Mail, Spracheinstellungen) jederzeit selbst korrigieren.<\/p>\n<p><strong>Status: Implementiert.<\/strong><\/p>\n<h3>2.5 Transparenz und Informationspflicht<\/h3>\n<p>Die Plattform stellt Nutzern aktiv Informationen über die Datenverarbeitung bereit:<\/p>\n<ul><li>Welche Daten erhoben werden<\/li><li>Zu welchem Zweck die Verarbeitung erfolgt<\/li><li>Auf welcher Rechtsgrundlage die Verarbeitung basiert<\/li><li>Welche Aufbewahrungsfristen gelten<\/li><li>Welche Betroffenenrechte bestehen und wie sie ausgeübt werden können<\/li><\/ul>\n<p><strong>Status: Implementiert.<\/strong><\/p>\n<h3>2.6 Bekannte Einschränkungen<\/h3>\n<p>Die folgenden Punkte sind transparent zu benennen:<\/p>\n<ul><li><strong>Consent-Management:<\/strong> Die Plattform verfügt derzeit über kein granulares Einwilligungsmanagement mit individuellen Zustimmungs-Toggles. Die Einwilligung zur Datenverarbeitung erfolgt über die Nutzungsbedingungen und, bei Drittanbieter-Authentifizierung (Microsoft, Google), über die jeweiligen OAuth-Einwilligungsflüsse.<\/li><li><strong>Datenschutz-Kontaktadresse:<\/strong> Die Kontaktadresse für Datenschutzanfragen ist pro Deployment konfigurierbar und muss vom jeweiligen Betreiber hinterlegt werden.<\/li><\/ul>\n<hr>\n<h2>3. Mandantenmodell und Datenisolation<\/h2>\n<h3>3.1 Grundprinzip<\/h3>\n<p>PowerOn ist als Multi-Mandanten-Plattform konzipiert. Jede Organisation, Abteilung oder jeder Kunde wird als eigenständiger <strong>Mandant<\/strong> abgebildet. Das zentrale Sicherheitsversprechen:<\/p>\n<blockquote><strong>Daten eines Mandanten sind unter keinen Umständen für Nutzer anderer Mandanten sichtbar oder zugänglich.<\/strong><\/blockquote>\n<h3>3.2 Wie die Trennung funktioniert<\/h3>\n<ul><li><strong>Zugehörigkeitsprüfung bei jedem Zugriff:<\/strong> Bevor ein Nutzer auf Mandantendaten zugreifen kann, prüft die Plattform, ob eine aktive Mitgliedschaft des Nutzers in diesem Mandanten besteht. Ohne nachgewiesene Mitgliedschaft wird der Zugriff verweigert.<\/li><li><strong>Kein mandantenübergreifender Datenfluss:<\/strong> Datenbankabfragen werden automatisch auf den Mandantenkontext gefiltert. Es gibt keinen Mechanismus, der Daten mandantenübergreifend zusammenführt oder exponiert.<\/li><li><strong>Feature-Isolation:<\/strong> Innerhalb eines Mandanten werden Funktionsmodule (z.B. CommCoach, Treuhand, Immobilien) zusätzlich isoliert. Nutzer benötigen für jedes Funktionsmodul eine explizite Zugriffsberechtigung.<\/li><\/ul>\n<h3>3.3 Mehrfachmandanten<\/h3>\n<p>Nutzer können gleichzeitig in mehreren Mandanten arbeiten -- ein häufiges Szenario bei Beratern, Treuhändern oder Dienstleistern mit mehreren Kunden. Die Plattform stellt sicher:<\/p>\n<ul><li>Der Mandantenkontext wird pro Anfrage bestimmt, nicht pro Sitzung. Ein Wechsel zwischen Mandanten ist jederzeit möglich, ohne dass Daten vermischt werden.<\/li><li>Es findet keine Übertragung von Daten, Berechtigungen oder Einstellungen zwischen Mandanten statt.<\/li><\/ul>\n<h3>3.4 Schutz vor Manipulation<\/h3>\n<p>Auch bei technischem Wissen über die Plattformarchitektur ist ein unbefugter Zugriff auf fremde Mandantendaten nicht möglich: Die Zugehörigkeitsprüfung erfolgt serverseitig und kann nicht durch Manipulation von Anfrageparametern umgangen werden.<\/p>\n<hr>\n<h2>4. Rollenbasierte Zugriffskontrolle (RBAC)<\/h2>\n<h3>4.1 Berechtigungsmodell<\/h3>\n<p>PowerOn verfügt über ein feingliedriges, rollenbasiertes Berechtigungssystem. Für jede Aktion (Lesen, Erstellen, Bearbeiten, Löschen) können individuelle Berechtigungsstufen vergeben werden:<\/p>\n<table><thead><tr><th>Berechtigungsstufe<\/th><th>Beschreibung<\/th><\/tr><\/thead><tbody><tr><td>Kein Zugriff<\/td><td>Funktion ist nicht verfügbar<\/td><\/tr><tr><td>Eigene Daten<\/td><td>Zugriff nur auf selbst erstellte Einträge<\/td><\/tr><tr><td>Mandantendaten<\/td><td>Zugriff auf alle Daten innerhalb des eigenen Mandanten<\/td><\/tr><tr><td>Alle Daten<\/td><td>Vollzugriff (typischerweise für Administratoren)<\/td><\/tr><\/tbody><\/table>\n<h3>4.2 Konfigurierbarkeit<\/h3>\n<ul><li>Rollen können <strong>pro Mandant<\/strong> und <strong>pro Funktionsmodul<\/strong> definiert und zugewiesen werden.<\/li><li>Es gibt keine fest verdrahteten Berechtigungen -- jede Organisation kann das Rollenmodell an ihre Bedürfnisse anpassen.<\/li><li>Berechtigungsänderungen werden im Audit-Trail protokolliert.<\/li><\/ul>\n<h3>4.3 Administratoren<\/h3>\n<p>Systemadministratoren verfügen über erweiterte Rechte, unterliegen jedoch ebenfalls dem RBAC-System. Alle Administratoraktionen werden gesondert im Audit-Log festgehalten. Es gibt kein unkontrolliertes \"Superuser\"-Konto ohne Nachvollziehbarkeit.<\/p>\n<hr>\n<h2>5. Verschlüsselung und Datensicherheit<\/h2>\n<h3>5.1 Verschlüsselung ruhender Daten<\/h3>\n<p>Alle sensiblen Konfigurationsdaten werden verschlüsselt gespeichert:<\/p>\n<ul><li><strong>Verschlüsselungsverfahren:<\/strong> AES-Verschlüsselung (Fernet)<\/li><li><strong>Schlüsselableitung:<\/strong> PBKDF2-HMAC-SHA256 nach aktuellem Industriestandard<\/li><li><strong>Umfang:<\/strong> Datenbankpasswörter, API-Schlüssel für KI-Dienste, OAuth-Geheimnisse, JWT-Schlüssel und alle weiteren als \"SECRET\" gekennzeichneten Konfigurationswerte<\/li><\/ul>\n<p>Sensible Konfigurationsdaten liegen zu keinem Zeitpunkt im Klartext in der Konfiguration oder im Quellcode vor.<\/p>\n<h3>5.2 Verschlüsselung in Übertragung<\/h3>\n<ul><li>Sämtliche Kommunikation zwischen Client und Server erfolgt über HTTPS/TLS.<\/li><li>Verbindungen zu Drittdiensten (KI-Anbieter, Authentifizierungsdienste, E-Mail-Dienste) nutzen ebenfalls ausschliesslich verschlüsselte Verbindungen.<\/li><li>Die TLS-Konfiguration erfolgt auf Infrastruktur-Ebene (Azure / Reverse Proxy) -- dies entspricht dem Branchenstandard bei Cloud-Deployments und ermöglicht zentrale Verwaltung und Aktualisierung der Zertifikate.<\/li><\/ul>\n<h3>5.3 Zugriffskontrolle auf Verschlüsselungsschlüssel<\/h3>\n<ul><li>Der Zugriff auf Verschlüsselungsschlüssel ist auf das Minimum beschränkt.<\/li><li>Jeder Zugriff auf Verschlüsselungsfunktionen (Entschlüsselung, Neuverschlüsselung) wird im Audit-Trail protokolliert.<\/li><li>Eine Ratenbegrenzung schützt vor automatisierten Entschlüsselungsversuchen.<\/li><\/ul>\n<hr>\n<h2>6. Schutzmassnahmen gegen Angriffe<\/h2>\n<p>PowerOn implementiert Schutzmassnahmen gegen die gängigsten Angriffsvektoren für Webanwendungen:<\/p>\n<h3>6.1 Cross-Site Request Forgery (CSRF)<\/h3>\n<p>Alle datenverändernden Operationen (POST, PUT, DELETE, PATCH) erfordern einen <code>X-CSRF-Token<\/code> Header. Die aktuelle Implementierung validiert das Tokenformat (16-64 Zeichen Hex-String); es gibt kein serverseitiges Session-Binding (kein klassisches Double-Submit oder Synchronizer Token). In Kombination mit <code>SameSite=Strict<\/code> Cookies und CORS bietet dies Basisschutz gegen CSRF.<\/p>\n<h3>6.2 Ratenbegrenzung (Rate Limiting)<\/h3>\n<p>Jede API-Funktion ist mit individuellen Zugriffslimits versehen, die automatisierte Angriffe und Missbrauch unterbinden:<\/p>\n<table><thead><tr><th>Funktion<\/th><th>Limit<\/th><\/tr><\/thead><tbody><tr><td>Anmeldung<\/td><td>30 Versuche pro Minute<\/td><\/tr><tr><td>Datenexport (DSGVO)<\/td><td>5 Anfragen pro Minute<\/td><\/tr><tr><td>Kontolöschung<\/td><td>1 Anfrage pro Stunde<\/td><\/tr><tr><td>KI-Anfragen<\/td><td>120 Anfragen pro Minute<\/td><\/tr><tr><td>Datei-Upload<\/td><td>10 Uploads pro Minute<\/td><\/tr><\/tbody><\/table>\n<h3>6.3 Eingabebereinigung<\/h3>\n<p>Nutzereingaben werden bereinigt und validiert, bevor sie an KI-Modelle oder Datenbanken weitergeleitet werden. Dies schützt vor Prompt-Injection-Angriffen und anderen Manipulationsversuchen.<\/p>\n<h3>6.4 SQL-Injection-Schutz<\/h3>\n<ul><li>Alle Datenbankabfragen der Plattform verwenden parametrisierte Abfragen -- der Industriestandard zur Vermeidung von SQL-Injection.<\/li><li>Der KI-gestützte Datenbankzugriff ist zusätzlich auf reine Leseabfragen (SELECT) beschränkt. Schreibende, ändernde oder löschende Operationen sind auf Systemebene blockiert.<\/li><\/ul>\n<h3>6.5 Cross-Origin Resource Sharing (CORS)<\/h3>\n<p>Nur definierte und verifizierte Quelldomains erhalten Zugriff auf die Plattform-API. Anfragen von nicht autorisierten Quellen werden automatisch abgelehnt.<\/p>\n<hr>\n<h2>7. KI-Dienste und Datenverarbeitung<\/h2>\n<p>Transparenz im Umgang mit KI-Diensten ist für datenschutzbewusste Organisationen entscheidend. PowerOn legt offen, wie Daten im Kontext der KI-Nutzung verarbeitet werden.<\/p>\n<h3>7.1 Welche Daten werden verarbeitet<\/h3>\n<p>Im Rahmen der KI-gestützten Funktionen (KI-Assistent, Workflow-Verarbeitung, Dokumentenanalyse) können folgende Daten an KI-Dienste übermittelt werden:<\/p>\n<ul><li>Nutzeranfragen und -eingaben<\/li><li>Dokumentinhalte (bei Dokumentenanalyse)<\/li><li>Gesprächsverläufe (bei Chat-Funktionen)<\/li><\/ul>\n<h3>7.2 Welche KI-Anbieter werden genutzt<\/h3>\n<p>PowerOn unterstützt mehrere KI-Anbieter, die je nach Bedarf und Konfiguration eingesetzt werden:<\/p>\n<ul><li><strong>OpenAI<\/strong> (GPT-4o und weitere Modelle)<\/li><li><strong>Anthropic<\/strong> (Claude-Modelle)<\/li><li><strong>Tavily<\/strong> (Websuche)<\/li><li><strong>Private LLM<\/strong> (lokale/eigene Modelle -- kein externer Datenabfluss)<\/li><\/ul>\n<p>Die Auswahl des Anbieters ist konfigurierbar und kann an die Datenschutzanforderungen des Kunden angepasst werden.<\/p>\n<h3>7.3 Mandantentrennung bei KI-Anfragen<\/h3>\n<p>Jede KI-Anfrage erfolgt im Kontext des jeweiligen Mandanten. Es findet keine Vermischung von Daten verschiedener Mandanten in KI-Anfragen statt.<\/p>\n<h3>7.4 Kein Training mit Kundendaten<\/h3>\n<p>Bei Nutzung der Enterprise-API-Vereinbarungen der KI-Anbieter (OpenAI Enterprise API, Anthropic API) werden Kundendaten nicht für das Training der KI-Modelle verwendet. Dies ist vertraglich durch die Auftragsverarbeitungsvereinbarungen (AV-V / DPA) mit den jeweiligen Anbietern abgesichert.<\/p>\n<h3>7.5 Optionen für höchste Datenschutzanforderungen<\/h3>\n<p>Für Organisationen mit besonders hohen Datenschutzanforderungen bietet PowerOn:<\/p>\n<ul><li><strong>Datenschutz-Neutralisierer:<\/strong> Optionales Modul, das personenbezogene Daten vor der Übermittlung an externe KI-Dienste entfernt oder pseudonymisiert.<\/li><li><strong>Private-LLM-Anbindung:<\/strong> Möglichkeit, ein eigenes, lokal betriebenes Sprachmodell zu nutzen. In diesem Fall verlassen keine Daten die eigene Infrastruktur.<\/li><\/ul>\n<h3>7.6 Bekannte Einschränkung<\/h3>\n<p>Die automatische Erkennung und Filterung personenbezogener Daten (PII) vor dem Versand an externe KI-Dienste ist <strong>nicht standardmässig aktiviert<\/strong>. Organisationen, die mit besonders sensiblen personenbezogenen Daten arbeiten, sollten den Datenschutz-Neutralisierer nutzen oder den Private-LLM-Connector einsetzen.<\/p>\n<hr>\n<h2>8. Audit-Trail und Nachvollziehbarkeit<\/h2>\n<h3>8.1 Was wird protokolliert<\/h3>\n<p>Sämtliche sicherheitsrelevanten Aktionen werden automatisch und lückenlos in einem Audit-Log erfasst:<\/p>\n<table><thead><tr><th>Kategorie<\/th><th>Beispiele<\/th><\/tr><\/thead><tbody><tr><td>Zugriff<\/td><td>Anmeldungen, fehlgeschlagene Anmeldeversuche, Abmeldungen<\/td><\/tr><tr><td>Sicherheit<\/td><td>Administratoraktionen, SysAdmin-Zugriffe, Sicherheitsereignisse<\/td><\/tr><tr><td>Datenschutz (DSGVO)<\/td><td>Datenexporte, Kontolöschungen, Portabilitätsanfragen<\/td><\/tr><tr><td>Berechtigungen<\/td><td>Rollenzuweisungen, Berechtigungsänderungen<\/td><\/tr><tr><td>Verschlüsselung<\/td><td>Zugriffe auf Verschlüsselungsfunktionen<\/td><\/tr><tr><td>Datenoperationen<\/td><td>Zugriffe auf sensible Geschäftsdaten<\/td><\/tr><\/tbody><\/table>\n<h3>8.2 Aufbewahrung und Bereinigung<\/h3>\n<ul><li><strong>Standard-Aufbewahrungsdauer:<\/strong> 365 Tage (konfigurierbar)<\/li><li><strong>Automatische Bereinigung:<\/strong> Veraltete Einträge werden durch einen täglichen Prozess entfernt -- dies stellt sicher, dass Audit-Daten nicht unbefristet aufbewahrt werden (DSGVO-Konformität).<\/li><li><strong>Anonymisierung:<\/strong> Bei der Löschung eines Nutzerkontos werden zugehörige Audit-Einträge anonymisiert statt gelöscht. Die Nachvollziehbarkeit sicherheitsrelevanter Ereignisse bleibt gewahrt, ohne dass Rückschlüsse auf die gelöschte Person möglich sind.<\/li><\/ul>\n<h3>8.3 Nutzung für Compliance-Nachweise<\/h3>\n<p>Die Audit-Daten können als Nachweis für interne und externe Audits herangezogen werden. Sie dokumentieren, wer wann welche sicherheitsrelevante Aktion durchgeführt hat, und unterstützen damit die Anforderungen an die Rechenschaftspflicht nach Art. 5 Abs. 2 DSGVO.<\/p>\n<hr>\n<h2>9. Einordnung in gängige Standards<\/h2>\n<p>PowerOn orientiert sich an anerkannten Standards und Rahmenwerken. Die folgende Einordnung beschreibt transparent, welche Anforderungen die Plattform bereits abdeckt und wo Ergänzungen erforderlich sind.<\/p>\n<h3>9.1 DSGVO / GDPR<\/h3>\n<table><thead><tr><th>Anforderung<\/th><th>Status<\/th><th>Bemerkung<\/th><\/tr><\/thead><tbody><tr><td>Betroffenenrechte (Art. 15--17, 20)<\/td><td>Implementiert<\/td><td>Auskunft, Löschung, Portabilität, Berichtigung als Self-Service<\/td><\/tr><tr><td>Rechenschaftspflicht (Art. 5 Abs. 2)<\/td><td>Implementiert<\/td><td>Lückenloser Audit-Trail<\/td><\/tr><tr><td>Verzeichnis der Verarbeitungstätigkeiten (Art. 30)<\/td><td>Unterstützt<\/td><td>Audit-Log liefert die Datenbasis; das formale Verzeichnis muss vom Betreiber geführt werden<\/td><\/tr><tr><td>Technische und organisatorische Massnahmen (Art. 32)<\/td><td>Implementiert<\/td><td>Verschlüsselung, Zugriffskontrolle, Mandantentrennung, Eingabevalidierung<\/td><\/tr><tr><td>Einwilligungsmanagement (Art. 7)<\/td><td>Teilweise<\/td><td>Über Nutzungsbedingungen und OAuth; kein granulares Consent-Tool<\/td><\/tr><\/tbody><\/table>\n<h3>9.2 Schweizer Datenschutzgesetz (nDSG / revDSG)<\/h3>\n<p>Die Anforderungen des revidierten Schweizer Datenschutzgesetzes sind mit den DSGVO-Massnahmen kompatibel. Insbesondere:<\/p>\n<ul><li>Informationspflicht bei Datenerhebung: Transparenzfunktion implementiert<\/li><li>Recht auf Datenherausgabe und -löschung: Self-Service-Funktionen vorhanden<\/li><li>Pflicht zu angemessenen technischen Massnahmen: Verschlüsselung, RBAC, Mandantentrennung<\/li><\/ul>\n<h3>9.3 OWASP Top 10<\/h3>\n<p>Die Plattform adressiert die häufigsten Web-Sicherheitsrisiken gemäss OWASP:<\/p>\n<table><thead><tr><th>OWASP-Risiko<\/th><th>Massnahme in PowerOn<\/th><\/tr><\/thead><tbody><tr><td>Broken Access Control<\/td><td>Rollenbasierte Zugriffskontrolle, Mandantenprüfung bei jedem Zugriff<\/td><\/tr><tr><td>Cryptographic Failures<\/td><td>AES-Verschlüsselung, PBKDF2-Schlüsselableitung, HTTPS/TLS<\/td><\/tr><tr><td>Injection<\/td><td>Parametrisierte Datenbankabfragen, Eingabebereinigung, SQL-Leseeinschränkung<\/td><\/tr><tr><td>Security Misconfiguration<\/td><td>CORS-Einschränkungen, Rate Limiting, CSRF-Schutz<\/td><\/tr><tr><td>Identification and Authentication Failures<\/td><td>JWT-basierte Authentifizierung, Token-Widerruf, Ratenbegrenzung bei Anmeldung<\/td><\/tr><\/tbody><\/table>\n<p>Es besteht <strong>keine formale OWASP-Zertifizierung<\/strong>. Die Massnahmen basieren auf den OWASP-Empfehlungen und sind als präventive Sicherheitsmassnahmen implementiert.<\/p>\n<h3>9.4 ISO 27001 / BSI IT-Grundschutz<\/h3>\n<p>Die implementierten technischen und organisatorischen Massnahmen (Zugriffskontrolle, Verschlüsselung, Audit-Logging, Eingabevalidierung, Mandantentrennung) bilden eine <strong>solide Grundlage<\/strong> für ein Informationssicherheits-Managementsystem (ISMS) nach ISO 27001 oder BSI IT-Grundschutz.<\/p>\n<p>Es besteht <strong>keine formale Zertifizierung<\/strong>. Die vorhandene Infrastruktur ermöglicht es jedoch, eine Zertifizierung auf dieser Basis gezielt anzustreben.<\/p>\n<hr>\n<h2>10. Authentifizierung und Identitätsmanagement<\/h2>\n<h3>10.1 Anmeldemethoden<\/h3>\n<p>PowerOn unterstützt mehrere Authentifizierungsverfahren:<\/p>\n<ul><li><strong>Lokale Anmeldung:<\/strong> Benutzername und Passwort mit JWT-basierter Sitzungsverwaltung<\/li><li><strong>Microsoft-Anmeldung (Azure AD / Entra ID):<\/strong> Single Sign-On über bestehende Microsoft-Konten<\/li><li><strong>Google-Anmeldung:<\/strong> Single Sign-On über Google Workspace<\/li><\/ul>\n<h3>10.2 Sitzungssicherheit<\/h3>\n<ul><li>Authentifizierungstoken werden in sicheren, HTTP-only Cookies gespeichert (nicht im Browser-Speicher zugänglich)<\/li><li>Tokens haben eine konfigurierbare Gültigkeitsdauer<\/li><li>Token-Widerruf ist jederzeit möglich (z.B. bei Verdacht auf Kompromittierung)<\/li><li>Bei lokaler Anmeldung wird die Gültigkeit des Tokens zusätzlich gegen die Datenbank geprüft<\/li><\/ul>\n<h3>10.3 Automatische Token-Erneuerung<\/h3>\n<p>Authentifizierungstoken werden automatisch erneuert, bevor sie ablaufen. Dies gewährleistet eine unterbrechungsfreie Nutzung bei gleichzeitiger Begrenzung der Token-Gültigkeitsdauer.<\/p>\n<hr>\n<h2>11. Offene Punkte und Empfehlungen<\/h2>\n<p>Transparenz schafft Vertrauen. Die folgenden Punkte sind offen benannt, damit Kunden und Betreiber informierte Entscheidungen treffen können.<\/p>\n<table><thead><tr><th>Thema<\/th><th>Status<\/th><th>Empfehlung<\/th><\/tr><\/thead><tbody><tr><td>Granulares Consent-Management<\/td><td>Nicht vorhanden<\/td><td>Falls regulatorisch erforderlich, als separates Modul ergänzen<\/td><\/tr><tr><td>PII-Filterung vor KI-Versand<\/td><td>Nicht standardmässig aktiv<\/td><td>Datenschutz-Neutralisierer aktivieren oder Private LLM einsetzen<\/td><\/tr><tr><td>Security-Header (CSP, HSTS)<\/td><td>Auf Infrastruktur-Ebene<\/td><td>Konfiguration auf Reverse-Proxy-Ebene dokumentieren und prüfen<\/td><\/tr><tr><td>Datenschutz-Kontaktadresse<\/td><td>Platzhalter<\/td><td>Pro Deployment mit tatsächlicher DSB-Kontaktadresse konfigurieren<\/td><\/tr><tr><td>Formale Zertifizierungen<\/td><td>Keine vorhanden<\/td><td>ISO 27001 / BSI auf Basis der vorhandenen Massnahmen anstrebbar<\/td><\/tr><\/tbody><\/table>\n<hr>\n<h2>12. Zusammenfassung<\/h2>\n<p>PowerOn vereint Enterprise-KI-Funktionalität mit einem umfassenden Sicherheits- und Datenschutzkonzept. Die Plattform bietet:<\/p>\n<ul><li><strong>DSGVO-konforme Betroffenenrechte<\/strong> als Self-Service-Funktionen<\/li><li><strong>Vollständige Mandantentrennung<\/strong> mit serverseitiger Zugehörigkeitsprüfung<\/li><li><strong>Feingliedriges Berechtigungssystem<\/strong> mit individuell konfigurierbaren Rollen<\/li><li><strong>Verschlüsselung nach Industriestandard<\/strong> für ruhende und übertragene Daten<\/li><li><strong>Lückenlosen Audit-Trail<\/strong> für Compliance-Nachweise<\/li><li><strong>Transparente KI-Datenverarbeitung<\/strong> mit Optionen für höchste Datenschutzanforderungen<\/li><\/ul>\n<p>Gleichzeitig werden bestehende Einschränkungen offen kommuniziert und Empfehlungen für ergänzende Massnahmen gegeben. Diese Kombination aus implementierter Sicherheit und transparenter Kommunikation bildet die Grundlage für eine vertrauensvolle Zusammenarbeit.<\/p>\n<hr>\n<p><em>Dieses Dokument basiert auf einer Analyse der PowerOn-Plattform (Stand Februar 2026). Alle beschriebenen Massnahmen sind in der Plattform implementiert und wurden anhand der Codebasis verifiziert. Angaben ohne Gewähr -- für verbindliche Zusicherungen gelten die jeweiligen Vertragsvereinbarungen.<\/em><\/p>", "text": "# poweron plattform -- sicherheit und compliance **stand:** februar 2026 **zielgruppe:** entscheidungsträger, einkauf, rechtsabteilung, datenschutzbeauftragte **klassifizierung:** kundeninformation --- ## 1. management summary poweron ist eine **multi-mandanten-ki-plattform für unternehmen**, die es organisationen ermöglicht, ki-gestützte geschäftsprozesse sicher, datenschutzkonform und mandantengetrennt zu betreiben. die plattform richtet sich an mittlere bis grosse unternehmen in datenschutzsensiblen branchen wie finanzwesen, treuhand, immobilien und beratung. dieses dokument beschreibt die in poweron implementierten sicherheits- und datenschutzmassnahmen, ordnet diese gängigen standards zu und benennt transparent bestehende einschränkungen. **kernaussagen:** - **dsgvo-betroffenenrechte** (auskunft, löschung, datenübertragbarkeit, berichtigung) sind als self-service-funktionen direkt in der plattform implementiert. - **vollständige mandantentrennung:** daten eines mandanten sind unter keinen umständen für andere mandanten einsehbar oder zugänglich. - **rollenbasierte zugriffskontrolle (rbac):** jeder datenzugriff wird gegen ein mehrstufiges berechtigungssystem geprüft -- konfigurierbar pro mandant und funktionsmodul. - **verschlüsselung:** sensible konfigurationsdaten sind nach industriestandard verschlüsselt, sämtliche kommunikation erfolgt über verschlüsselte verbindungen. - **audit-trail:** alle sicherheitsrelevanten aktionen werden lückenlos protokolliert und stehen für compliance-nachweise zur verfügung. - **transparenz bei ki-nutzung:** die plattform dokumentiert offen, welche daten an ki-dienste übermittelt werden, und bietet konfigurationsoptionen für höchste datenschutzanforderungen. --- ## 2. dsgvo-konformität poweron implementiert die zentralen betroffenenrechte der datenschutz-grundverordnung (dsgvo/gdpr) direkt als plattformfunktionen. im folgenden wird für jeden relevanten artikel beschrieben, was implementiert ist und wo einschränkungen bestehen. ### 2.1 auskunftsrecht (art. 15 dsgvo) nutzer können über eine self-service-funktion sämtliche über sie gespeicherten daten exportieren: - persönliche profildaten (name, e-mail, spracheinstellungen) - mandatszugehörigkeiten und zugewiesene rollen - zugriffsrechte auf funktionsmodule - erstellte und eingelöste einladungen - zeitpunkte der kontörstellung und letzten anmeldung der export umfasst alle auf plattformebene gespeicherten daten. feature-spezifische daten (z.b. chat-verläufe, treuhandpositionen) können über die jeweiligen funktionsmodule eingesehen werden. **status: implementiert.** ### 2.2 recht auf löschung (art. 17 dsgvo) nutzer können ihr konto und alle zugehörigen daten eigenständig und unwiderruflich löschen. dabei gilt: - das system durchsucht automatisch alle datenbanken (plattform, verwaltung, chat, alle funktionsmodule) nach einträgen, die dem nutzer zugeordnet sind. - nutzerbezogene daten werden vollständig gelöscht. - audit-logs werden anonymisiert statt gelöscht -- dies gewährleistet die einhaltung gesetzlicher aufbewahrungspflichten bei gleichzeitiger wahrung der betroffenenrechte. - die löschung erfordert eine explizite bestätigung durch den nutzer. - systemadministratoren sind von der selbstlöschung ausgenommen (vier-augen-prinzip). **status: implementiert.** ### 2.3 recht auf datenübertragbarkeit (art. 20 dsgvo) nutzerdaten können in einem maschinenlesbaren, standardisierten format (json-ld nach schema.org) exportiert werden. dieses format ermöglicht die übertragung der daten an einen anderen dienstleister. **status: implementiert.** ### 2.4 berichtigungsrecht (art. 16 dsgvo) nutzer können ihre profildaten (name, e-mail, spracheinstellungen) jederzeit selbst korrigieren. **status: implementiert.** ### 2.5 transparenz und informationspflicht die plattform stellt nutzern aktiv informationen über die datenverarbeitung bereit: - welche daten erhoben werden - zu welchem zweck die verarbeitung erfolgt - auf welcher rechtsgrundlage die verarbeitung basiert - welche aufbewahrungsfristen gelten - welche betroffenenrechte bestehen und wie sie ausgeübt werden können **status: implementiert.** ### 2.6 bekannte einschränkungen die folgenden punkte sind transparent zu benennen: - **consent-management:** die plattform verfügt derzeit über kein granulares einwilligungsmanagement mit individuellen zustimmungs-toggles. die einwilligung zur datenverarbeitung erfolgt über die nutzungsbedingungen und, bei drittanbieter-authentifizierung (microsoft, google), über die jeweiligen oauth-einwilligungsflüsse. - **datenschutz-kontaktadresse:** die kontaktadresse für datenschutzanfragen ist pro deployment konfigurierbar und muss vom jeweiligen betreiber hinterlegt werden. --- ## 3. mandantenmodell und datenisolation ### 3.1 grundprinzip poweron ist als multi-mandanten-plattform konzipiert. jede organisation, abteilung oder jeder kunde wird als eigenständiger **mandant** abgebildet. das zentrale sicherheitsversprechen: > **daten eines mandanten sind unter keinen umständen für nutzer anderer mandanten sichtbar oder zugänglich.** ### 3.2 wie die trennung funktioniert - **zugehörigkeitsprüfung bei jedem zugriff:** bevor ein nutzer auf mandantendaten zugreifen kann, prüft die plattform, ob eine aktive mitgliedschaft des nutzers in diesem mandanten besteht. ohne nachgewiesene mitgliedschaft wird der zugriff verweigert. - **kein mandantenübergreifender datenfluss:** datenbankabfragen werden automatisch auf den mandantenkontext gefiltert. es gibt keinen mechanismus, der daten mandantenübergreifend zusammenführt oder exponiert. - **feature-isolation:** innerhalb eines mandanten werden funktionsmodule (z.b. commcoach, treuhand, immobilien) zusätzlich isoliert. nutzer benötigen für jedes funktionsmodul eine explizite zugriffsberechtigung. ### 3.3 mehrfachmandanten nutzer können gleichzeitig in mehreren mandanten arbeiten -- ein häufiges szenario bei beratern, treuhändern oder dienstleistern mit mehreren kunden. die plattform stellt sicher: - der mandantenkontext wird pro anfrage bestimmt, nicht pro sitzung. ein wechsel zwischen mandanten ist jederzeit möglich, ohne dass daten vermischt werden. - es findet keine übertragung von daten, berechtigungen oder einstellungen zwischen mandanten statt. ### 3.4 schutz vor manipulation auch bei technischem wissen über die plattformarchitektur ist ein unbefugter zugriff auf fremde mandantendaten nicht möglich: die zugehörigkeitsprüfung erfolgt serverseitig und kann nicht durch manipulation von anfrageparametern umgangen werden. --- ## 4. rollenbasierte zugriffskontrolle (rbac) ### 4.1 berechtigungsmodell poweron verfügt über ein feingliedriges, rollenbasiertes berechtigungssystem. für jede aktion (lesen, erstellen, bearbeiten, löschen) können individuelle berechtigungsstufen vergeben werden: | berechtigungsstufe | beschreibung | |---|---| | kein zugriff | funktion ist nicht verfügbar | | eigene daten | zugriff nur auf selbst erstellte einträge | | mandantendaten | zugriff auf alle daten innerhalb des eigenen mandanten | | alle daten | vollzugriff (typischerweise für administratoren) | ### 4.2 konfigurierbarkeit - rollen können **pro mandant** und **pro funktionsmodul** definiert und zugewiesen werden. - es gibt keine fest verdrahteten berechtigungen -- jede organisation kann das rollenmodell an ihre bedürfnisse anpassen. - berechtigungsänderungen werden im audit-trail protokolliert. ### 4.3 administratoren systemadministratoren verfügen über erweiterte rechte, unterliegen jedoch ebenfalls dem rbac-system. alle administratoraktionen werden gesondert im audit-log festgehalten. es gibt kein unkontrolliertes \"superuser\"-konto ohne nachvollziehbarkeit. --- ## 5. verschlüsselung und datensicherheit ### 5.1 verschlüsselung ruhender daten alle sensiblen konfigurationsdaten werden verschlüsselt gespeichert: - **verschlüsselungsverfahren:** aes-verschlüsselung (fernet) - **schlüsselableitung:** pbkdf2-hmac-sha256 nach aktuellem industriestandard - **umfang:** datenbankpasswörter, api-schlüssel für ki-dienste, oauth-geheimnisse, jwt-schlüssel und alle weiteren als \"secret\" gekennzeichneten konfigurationswerte sensible konfigurationsdaten liegen zu keinem zeitpunkt im klartext in der konfiguration oder im quellcode vor. ### 5.2 verschlüsselung in übertragung - sämtliche kommunikation zwischen client und server erfolgt über https/tls. - verbindungen zu drittdiensten (ki-anbieter, authentifizierungsdienste, e-mail-dienste) nutzen ebenfalls ausschliesslich verschlüsselte verbindungen. - die tls-konfiguration erfolgt auf infrastruktur-ebene (azure / reverse proxy) -- dies entspricht dem branchenstandard bei cloud-deployments und ermöglicht zentrale verwaltung und aktualisierung der zertifikate. ### 5.3 zugriffskontrolle auf verschlüsselungsschlüssel - der zugriff auf verschlüsselungsschlüssel ist auf das minimum beschränkt. - jeder zugriff auf verschlüsselungsfunktionen (entschlüsselung, neuverschlüsselung) wird im audit-trail protokolliert. - eine ratenbegrenzung schützt vor automatisierten entschlüsselungsversuchen. --- ## 6. schutzmassnahmen gegen angriffe poweron implementiert schutzmassnahmen gegen die gängigsten angriffsvektoren für webanwendungen: ### 6.1 cross-site request forgery (csrf) alle datenverändernden operationen (post, put, delete, patch) erfordern einen `x-csrf-token` header. die aktuelle implementierung validiert das tokenformat (16-64 zeichen hex-string); es gibt kein serverseitiges session-binding (kein klassisches double-submit oder synchronizer token). in kombination mit `samesite=strict` cookies und cors bietet dies basisschutz gegen csrf. ### 6.2 ratenbegrenzung (rate limiting) jede api-funktion ist mit individuellen zugriffslimits versehen, die automatisierte angriffe und missbrauch unterbinden: | funktion | limit | |---|---| | anmeldung | 30 versuche pro minute | | datenexport (dsgvo) | 5 anfragen pro minute | | kontolöschung | 1 anfrage pro stunde | | ki-anfragen | 120 anfragen pro minute | | datei-upload | 10 uploads pro minute | ### 6.3 eingabebereinigung nutzereingaben werden bereinigt und validiert, bevor sie an ki-modelle oder datenbanken weitergeleitet werden. dies schützt vor prompt-injection-angriffen und anderen manipulationsversuchen. ### 6.4 sql-injection-schutz - alle datenbankabfragen der plattform verwenden parametrisierte abfragen -- der industriestandard zur vermeidung von sql-injection. - der ki-gestützte datenbankzugriff ist zusätzlich auf reine leseabfragen (select) beschränkt. schreibende, ändernde oder löschende operationen sind auf systemebene blockiert. ### 6.5 cross-origin resource sharing (cors) nur definierte und verifizierte quelldomains erhalten zugriff auf die plattform-api. anfragen von nicht autorisierten quellen werden automatisch abgelehnt. --- ## 7. ki-dienste und datenverarbeitung transparenz im umgang mit ki-diensten ist für datenschutzbewusste organisationen entscheidend. poweron legt offen, wie daten im kontext der ki-nutzung verarbeitet werden. ### 7.1 welche daten werden verarbeitet im rahmen der ki-gestützten funktionen (ki-assistent, workflow-verarbeitung, dokumentenanalyse) können folgende daten an ki-dienste übermittelt werden: - nutzeranfragen und -eingaben - dokumentinhalte (bei dokumentenanalyse) - gesprächsverläufe (bei chat-funktionen) ### 7.2 welche ki-anbieter werden genutzt poweron unterstützt mehrere ki-anbieter, die je nach bedarf und konfiguration eingesetzt werden: - **openai** (gpt-4o und weitere modelle) - **anthropic** (claude-modelle) - **tavily** (websuche) - **private llm** (lokale/eigene modelle -- kein externer datenabfluss) die auswahl des anbieters ist konfigurierbar und kann an die datenschutzanforderungen des kunden angepasst werden. ### 7.3 mandantentrennung bei ki-anfragen jede ki-anfrage erfolgt im kontext des jeweiligen mandanten. es findet keine vermischung von daten verschiedener mandanten in ki-anfragen statt. ### 7.4 kein training mit kundendaten bei nutzung der enterprise-api-vereinbarungen der ki-anbieter (openai enterprise api, anthropic api) werden kundendaten nicht für das training der ki-modelle verwendet. dies ist vertraglich durch die auftragsverarbeitungsvereinbarungen (av-v / dpa) mit den jeweiligen anbietern abgesichert. ### 7.5 optionen für höchste datenschutzanforderungen für organisationen mit besonders hohen datenschutzanforderungen bietet poweron: - **datenschutz-neutralisierer:** optionales modul, das personenbezogene daten vor der übermittlung an externe ki-dienste entfernt oder pseudonymisiert. - **private-llm-anbindung:** möglichkeit, ein eigenes, lokal betriebenes sprachmodell zu nutzen. in diesem fall verlassen keine daten die eigene infrastruktur. ### 7.6 bekannte einschränkung die automatische erkennung und filterung personenbezogener daten (pii) vor dem versand an externe ki-dienste ist **nicht standardmässig aktiviert**. organisationen, die mit besonders sensiblen personenbezogenen daten arbeiten, sollten den datenschutz-neutralisierer nutzen oder den private-llm-connector einsetzen. --- ## 8. audit-trail und nachvollziehbarkeit ### 8.1 was wird protokolliert sämtliche sicherheitsrelevanten aktionen werden automatisch und lückenlos in einem audit-log erfasst: | kategorie | beispiele | |---|---| | zugriff | anmeldungen, fehlgeschlagene anmeldeversuche, abmeldungen | | sicherheit | administratoraktionen, sysadmin-zugriffe, sicherheitsereignisse | | datenschutz (dsgvo) | datenexporte, kontolöschungen, portabilitätsanfragen | | berechtigungen | rollenzuweisungen, berechtigungsänderungen | | verschlüsselung | zugriffe auf verschlüsselungsfunktionen | | datenoperationen | zugriffe auf sensible geschäftsdaten | ### 8.2 aufbewahrung und bereinigung - **standard-aufbewahrungsdauer:** 365 tage (konfigurierbar) - **automatische bereinigung:** veraltete einträge werden durch einen täglichen prozess entfernt -- dies stellt sicher, dass audit-daten nicht unbefristet aufbewahrt werden (dsgvo-konformität). - **anonymisierung:** bei der löschung eines nutzerkontos werden zugehörige audit-einträge anonymisiert statt gelöscht. die nachvollziehbarkeit sicherheitsrelevanter ereignisse bleibt gewahrt, ohne dass rückschlüsse auf die gelöschte person möglich sind. ### 8.3 nutzung für compliance-nachweise die audit-daten können als nachweis für interne und externe audits herangezogen werden. sie dokumentieren, wer wann welche sicherheitsrelevante aktion durchgeführt hat, und unterstützen damit die anforderungen an die rechenschaftspflicht nach art. 5 abs. 2 dsgvo. --- ## 9. einordnung in gängige standards poweron orientiert sich an anerkannten standards und rahmenwerken. die folgende einordnung beschreibt transparent, welche anforderungen die plattform bereits abdeckt und wo ergänzungen erforderlich sind. ### 9.1 dsgvo / gdpr | anforderung | status | bemerkung | |---|---|---| | betroffenenrechte (art. 15--17, 20) | implementiert | auskunft, löschung, portabilität, berichtigung als self-service | | rechenschaftspflicht (art. 5 abs. 2) | implementiert | lückenloser audit-trail | | verzeichnis der verarbeitungstätigkeiten (art. 30) | unterstützt | audit-log liefert die datenbasis; das formale verzeichnis muss vom betreiber geführt werden | | technische und organisatorische massnahmen (art. 32) | implementiert | verschlüsselung, zugriffskontrolle, mandantentrennung, eingabevalidierung | | einwilligungsmanagement (art. 7) | teilweise | über nutzungsbedingungen und oauth; kein granulares consent-tool | ### 9.2 schweizer datenschutzgesetz (ndsg / revdsg) die anforderungen des revidierten schweizer datenschutzgesetzes sind mit den dsgvo-massnahmen kompatibel. insbesondere: - informationspflicht bei datenerhebung: transparenzfunktion implementiert - recht auf datenherausgabe und -löschung: self-service-funktionen vorhanden - pflicht zu angemessenen technischen massnahmen: verschlüsselung, rbac, mandantentrennung ### 9.3 owasp top 10 die plattform adressiert die häufigsten web-sicherheitsrisiken gemäss owasp: | owasp-risiko | massnahme in poweron | |---|---| | broken access control | rollenbasierte zugriffskontrolle, mandantenprüfung bei jedem zugriff | | cryptographic failures | aes-verschlüsselung, pbkdf2-schlüsselableitung, https/tls | | injection | parametrisierte datenbankabfragen, eingabebereinigung, sql-leseeinschränkung | | security misconfiguration | cors-einschränkungen, rate limiting, csrf-schutz | | identification and authentication failures | jwt-basierte authentifizierung, token-widerruf, ratenbegrenzung bei anmeldung | es besteht **keine formale owasp-zertifizierung**. die massnahmen basieren auf den owasp-empfehlungen und sind als präventive sicherheitsmassnahmen implementiert. ### 9.4 iso 27001 / bsi it-grundschutz die implementierten technischen und organisatorischen massnahmen (zugriffskontrolle, verschlüsselung, audit-logging, eingabevalidierung, mandantentrennung) bilden eine **solide grundlage** für ein informationssicherheits-managementsystem (isms) nach iso 27001 oder bsi it-grundschutz. es besteht **keine formale zertifizierung**. die vorhandene infrastruktur ermöglicht es jedoch, eine zertifizierung auf dieser basis gezielt anzustreben. --- ## 10. authentifizierung und identitätsmanagement ### 10.1 anmeldemethoden poweron unterstützt mehrere authentifizierungsverfahren: - **lokale anmeldung:** benutzername und passwort mit jwt-basierter sitzungsverwaltung - **microsoft-anmeldung (azure ad / entra id):** single sign-on über bestehende microsoft-konten - **google-anmeldung:** single sign-on über google workspace ### 10.2 sitzungssicherheit - authentifizierungstoken werden in sicheren, http-only cookies gespeichert (nicht im browser-speicher zugänglich) - tokens haben eine konfigurierbare gültigkeitsdauer - token-widerruf ist jederzeit möglich (z.b. bei verdacht auf kompromittierung) - bei lokaler anmeldung wird die gültigkeit des tokens zusätzlich gegen die datenbank geprüft ### 10.3 automatische token-erneuerung authentifizierungstoken werden automatisch erneuert, bevor sie ablaufen. dies gewährleistet eine unterbrechungsfreie nutzung bei gleichzeitiger begrenzung der token-gültigkeitsdauer. --- ## 11. offene punkte und empfehlungen transparenz schafft vertrauen. die folgenden punkte sind offen benannt, damit kunden und betreiber informierte entscheidungen treffen können. | thema | status | empfehlung | |---|---|---| | granulares consent-management | nicht vorhanden | falls regulatorisch erforderlich, als separates modul ergänzen | | pii-filterung vor ki-versand | nicht standardmässig aktiv | datenschutz-neutralisierer aktivieren oder private llm einsetzen | | security-header (csp, hsts) | auf infrastruktur-ebene | konfiguration auf reverse-proxy-ebene dokumentieren und prüfen | | datenschutz-kontaktadresse | platzhalter | pro deployment mit tatsächlicher dsb-kontaktadresse konfigurieren | | formale zertifizierungen | keine vorhanden | iso 27001 / bsi auf basis der vorhandenen massnahmen anstrebbar | --- ## 12. zusammenfassung poweron vereint enterprise-ki-funktionalität mit einem umfassenden sicherheits- und datenschutzkonzept. die plattform bietet: - **dsgvo-konforme betroffenenrechte** als self-service-funktionen - **vollständige mandantentrennung** mit serverseitiger zugehörigkeitsprüfung - **feingliedriges berechtigungssystem** mit individuell konfigurierbaren rollen - **verschlüsselung nach industriestandard** für ruhende und übertragene daten - **lückenlosen audit-trail** für compliance-nachweise - **transparente ki-datenverarbeitung** mit optionen für höchste datenschutzanforderungen gleichzeitig werden bestehende einschränkungen offen kommuniziert und empfehlungen für ergänzende massnahmen gegeben. diese kombination aus implementierter sicherheit und transparenter kommunikation bildet die grundlage für eine vertrauensvolle zusammenarbeit. --- *dieses dokument basiert auf einer analyse der poweron-plattform (stand februar 2026). alle beschriebenen massnahmen sind in der plattform implementiert und wurden anhand der codebasis verifiziert. angaben ohne gewähr -- für verbindliche zusicherungen gelten die jeweiligen vertragsvereinbarungen.* ", "nextReview": "", "overdueReview": false, "zuPruefen": []}, {"id": "06_bewertung/internes-audit.md", "path": "06_bewertung/internes-audit.md", "chapter": "06_bewertung", "title": "Internes Audit", "filename": "internes-audit.md", "meta": {"docId": "IMS-09-01", "status": "entwurf", "version": "0.1", "owner": "Patrick Motsch", "approver": "Geschäftsführung PowerOn AG", "approvedDate": "", "nextReview": "2027-06-03", "classification": "intern", "isoRefs": "9001:9.2; 27001:9.2"}, "html": "<h1>Internes Audit<\/h1>\n<p><strong>Dokumenttyp:<\/strong> Verfahren (Pflicht ISO 9001/27001 Kap. 9.2)<\/p>\n<h2>1. Zweck<\/h2>\n<p>Das interne Audit prüft regelmässig, ob das IMS den Normanforderungen (ISO 9001, ISO 27001) und den eigenen Vorgaben entspricht und wirksam umgesetzt ist.<\/p>\n<h2>2. Unabhängigkeit<\/h2>\n<p>Auditoren dürfen ihre eigene Arbeit nicht prüfen. Aufgrund der Teamgrösse wird das interne Audit <strong>an eine externe, unabhängige Person/Stelle vergeben<\/strong>. Die Auswahl wird dokumentiert.<\/p>\n<h2>3. Auditprogramm<\/h2>\n<table><thead><tr><th>Element<\/th><th>Vorgabe<\/th><\/tr><\/thead><tbody><tr><td>Turnus<\/td><td>Mindestens 1x jährlich, gesamtes IMS über max. 1 Zyklus<\/td><\/tr><tr><td>Umfang<\/td><td>Kap. 4-10 beider Normen + Annex-A-Controls (risikoorientiert priorisiert)<\/td><\/tr><tr><td>Erstes Audit<\/td><td>2026 Q3 (Voraussetzung für Audit-Reife)<\/td><\/tr><tr><td>Kriterien<\/td><td>Normtext, IMS-Dokumente, SoA, gesetzliche/vertragliche Anforderungen<\/td><\/tr><\/tbody><\/table>\n<h2>4. Ablauf<\/h2>\n<pre class=\"mermaid\">flowchart LR\n    plan[\"Auditplan (Umfang, Termin, Kriterien)\"] --&gt; exec[\"Durchführung (Interviews, Nachweise, Stichproben)\"]\n    exec --&gt; report[\"Auditbericht (Feststellungen, Abweichungen)\"]\n    report --&gt; capa[\"Korrekturmassnahmen ins Massnahmenregister\"]\n    capa --&gt; followup[\"Nachverfolgung &amp; Wirksamkeitsprüfung\"]<\/pre>\n<h2>5. Feststellungsklassen<\/h2>\n<table><thead><tr><th>Klasse<\/th><th>Bedeutung<\/th><th>Folge<\/th><\/tr><\/thead><tbody><tr><td>Hauptabweichung (major)<\/td><td>Norm-/Systemanforderung nicht erfüllt<\/td><td>sofortige Korrekturmassnahme<\/td><\/tr><tr><td>Nebenabweichung (minor)<\/td><td>punktuelle Schwäche<\/td><td>terminierte Korrekturmassnahme<\/td><\/tr><tr><td>Hinweis / Verbesserungspotenzial<\/td><td>Empfehlung<\/td><td>KVP-Prüfung<\/td><\/tr><\/tbody><\/table>\n<h2>6. Nachweise / Records<\/h2>\n<p>Auditplan, Auditbericht und Massnahmen werden als Records abgelegt; Abweichungen werden im <a href=\"../07_verbesserung/massnahmen-register.md\">Massnahmenregister<\/a> (Quelle: Audit) geführt. Ergebnisse sind Input für das <a href=\"management-review.md\">Management-Review<\/a>.<\/p>", "text": "<!-- docid: ims-09-01 --> <!-- status: entwurf --> <!-- version: 0.1 --> <!-- owner: patrick motsch --> <!-- approver: geschäftsführung poweron ag --> <!-- approveddate: --> <!-- nextreview: 2027-06-03 --> <!-- classification: intern --> <!-- isorefs: 9001:9.2; 27001:9.2 --> # internes audit **dokumenttyp:** verfahren (pflicht iso 9001/27001 kap. 9.2) ## 1. zweck das interne audit prüft regelmässig, ob das ims den normanforderungen (iso 9001, iso 27001) und den eigenen vorgaben entspricht und wirksam umgesetzt ist. ## 2. unabhängigkeit auditoren dürfen ihre eigene arbeit nicht prüfen. aufgrund der teamgrösse wird das interne audit **an eine externe, unabhängige person/stelle vergeben**. die auswahl wird dokumentiert. ## 3. auditprogramm | element | vorgabe | |---|---| | turnus | mindestens 1x jährlich, gesamtes ims über max. 1 zyklus | | umfang | kap. 4-10 beider normen + annex-a-controls (risikoorientiert priorisiert) | | erstes audit | 2026 q3 (voraussetzung für audit-reife) | | kriterien | normtext, ims-dokumente, soa, gesetzliche/vertragliche anforderungen | ## 4. ablauf ```mermaid flowchart lr plan[\"auditplan (umfang, termin, kriterien)\"] --> exec[\"durchführung (interviews, nachweise, stichproben)\"] exec --> report[\"auditbericht (feststellungen, abweichungen)\"] report --> capa[\"korrekturmassnahmen ins massnahmenregister\"] capa --> followup[\"nachverfolgung & wirksamkeitsprüfung\"] ``` ## 5. feststellungsklassen | klasse | bedeutung | folge | |---|---|---| | hauptabweichung (major) | norm-/systemanforderung nicht erfüllt | sofortige korrekturmassnahme | | nebenabweichung (minor) | punktuelle schwäche | terminierte korrekturmassnahme | | hinweis / verbesserungspotenzial | empfehlung | kvp-prüfung | ## 6. nachweise / records auditplan, auditbericht und massnahmen werden als records abgelegt; abweichungen werden im [massnahmenregister](../07_verbesserung/massnahmen-register.md) (quelle: audit) geführt. ergebnisse sind input für das [management-review](management-review.md). ", "nextReview": "2027-06-03", "overdueReview": false, "zuPruefen": []}, {"id": "06_bewertung/management-review.md", "path": "06_bewertung/management-review.md", "chapter": "06_bewertung", "title": "Management-Review", "filename": "management-review.md", "meta": {"docId": "IMS-09-02", "status": "entwurf", "version": "0.1", "owner": "Geschäftsführung PowerOn AG", "approver": "Geschäftsführung PowerOn AG", "approvedDate": "", "nextReview": "2027-06-03", "classification": "intern", "isoRefs": "9001:9.3; 27001:9.3"}, "html": "<h1>Management-Review<\/h1>\n<p><strong>Dokumenttyp:<\/strong> Verfahren + Protokollvorlage (Pflicht ISO 9001/27001 Kap. 9.3)<\/p>\n<h2>1. Zweck und Turnus<\/h2>\n<p>Die oberste Leitung bewertet das IMS mindestens <strong>jährlich<\/strong> sowie anlassbezogen auf Eignung, Angemessenheit und Wirksamkeit und entscheidet über Verbesserungen und Ressourcen.<\/p>\n<h2>2. Eingaben (Inputs)<\/h2>\n<ul><li>Status Massnahmen aus vorherigen Reviews<\/li><li>Änderungen interner/externer Themen (<a href=\"../01_kontext/kontext-und-interessierte-parteien.md\">Kontext<\/a>)<\/li><li>Erfüllung der <a href=\"../03_planung/ziele-und-kennzahlen.md\">Ziele &amp; Kennzahlen<\/a><\/li><li>Ergebnisse <a href=\"internes-audit.md\">interner Audits<\/a><\/li><li>Risikolage / <a href=\"../03_planung/risikoregister.md\">Risikoregister<\/a> + SoA-Status<\/li><li>Incidents, Abweichungen, Reklamationen<\/li><li>Rückmeldungen interessierter Parteien (Kunden, Lieferanten)<\/li><li>Stand offener Pendenzen (<a href=\"../07_verbesserung/massnahmen-register.md\">Massnahmenregister<\/a>)<\/li><\/ul>\n<h2>3. Ergebnisse (Outputs)<\/h2>\n<ul><li>Bewertung der IMS-Wirksamkeit<\/li><li>Entscheidungen zu Verbesserungen, Zielen, Ressourcen<\/li><li>neue/aktualisierte Massnahmen mit Owner und Termin<\/li><li>ggf. Anpassung von Politiken, Scope, SoA<\/li><\/ul>\n<h2>4. Protokollvorlage<\/h2>\n<pre class=\"code\"><code># Management-Review-Protokoll\n\nDatum:\nTeilnehmende:\nBerichtsperiode:\n\n## Inputs (Zusammenfassung)\n- Zielerreichung: ...\n- Audit-Ergebnisse: ...\n- Risiken/SoA: ...\n- Incidents/Abweichungen: ...\n- Rückmeldungen: ...\n\n## Bewertung\n- Eignung/Angemessenheit/Wirksamkeit: ...\n\n## Entscheidungen &amp; Massnahmen\n| Massnahme | Owner | Termin |\n|---|---|---|\n| | | |\n\n## Nächstes Review:\nFreigabe (Geschäftsführung):<\/code><\/pre>\n<h2>5. Records<\/h2>\n<p>Jedes Protokoll wird als Record abgelegt. Das erste Management-Review (2026 Q3) ist Voraussetzung für die Audit-Reife.<\/p>", "text": "<!-- docid: ims-09-02 --> <!-- status: entwurf --> <!-- version: 0.1 --> <!-- owner: geschäftsführung poweron ag --> <!-- approver: geschäftsführung poweron ag --> <!-- approveddate: --> <!-- nextreview: 2027-06-03 --> <!-- classification: intern --> <!-- isorefs: 9001:9.3; 27001:9.3 --> # management-review **dokumenttyp:** verfahren + protokollvorlage (pflicht iso 9001/27001 kap. 9.3) ## 1. zweck und turnus die oberste leitung bewertet das ims mindestens **jährlich** sowie anlassbezogen auf eignung, angemessenheit und wirksamkeit und entscheidet über verbesserungen und ressourcen. ## 2. eingaben (inputs) - status massnahmen aus vorherigen reviews - änderungen interner/externer themen ([kontext](../01_kontext/kontext-und-interessierte-parteien.md)) - erfüllung der [ziele & kennzahlen](../03_planung/ziele-und-kennzahlen.md) - ergebnisse [interner audits](internes-audit.md) - risikolage / [risikoregister](../03_planung/risikoregister.md) + soa-status - incidents, abweichungen, reklamationen - rückmeldungen interessierter parteien (kunden, lieferanten) - stand offener pendenzen ([massnahmenregister](../07_verbesserung/massnahmen-register.md)) ## 3. ergebnisse (outputs) - bewertung der ims-wirksamkeit - entscheidungen zu verbesserungen, zielen, ressourcen - neue/aktualisierte massnahmen mit owner und termin - ggf. anpassung von politiken, scope, soa ## 4. protokollvorlage ```markdown # management-review-protokoll datum: teilnehmende: berichtsperiode: ## inputs (zusammenfassung) - zielerreichung: ... - audit-ergebnisse: ... - risiken/soa: ... - incidents/abweichungen: ... - rückmeldungen: ... ## bewertung - eignung/angemessenheit/wirksamkeit: ... ## entscheidungen & massnahmen | massnahme | owner | termin | |---|---|---| | | | | ## nächstes review: freigabe (geschäftsführung): ``` ## 5. records jedes protokoll wird als record abgelegt. das erste management-review (2026 q3) ist voraussetzung für die audit-reife. ", "nextReview": "2027-06-03", "overdueReview": false, "zuPruefen": []}, {"id": "06_bewertung/monitoring-messung.md", "path": "06_bewertung/monitoring-messung.md", "chapter": "06_bewertung", "title": "Monitoring, Messung, Analyse und Bewertung", "filename": "monitoring-messung.md", "meta": {"docId": "IMS-09-03", "status": "entwurf", "version": "0.1", "owner": "Patrick Motsch", "approver": "Geschäftsführung PowerOn AG", "approvedDate": "", "nextReview": "2027-06-03", "classification": "intern", "isoRefs": "9001:9.1; 27001:9.1"}, "html": "<h1>Monitoring, Messung, Analyse und Bewertung<\/h1>\n<p><strong>Dokumenttyp:<\/strong> Verfahren (Pflicht ISO 9001/27001 Kap. 9.1)<\/p>\n<h2>1. Was wird gemessen<\/h2>\n<table><thead><tr><th>Gegenstand<\/th><th>Kennzahl<\/th><th>Quelle<\/th><th>Frequenz<\/th><th>Owner<\/th><\/tr><\/thead><tbody><tr><td>Qualitätsziele Q-1..Q-4<\/td><td>siehe <a href=\"../03_planung/ziele-und-kennzahlen.md\">Ziele<\/a><\/td><td>Tickets, Releases, CHANGELOG<\/td><td>quartalsweise<\/td><td>Patrick Motsch<\/td><\/tr><tr><td>Sicherheitsziele S-1..S-6<\/td><td>siehe <a href=\"../03_planung/ziele-und-kennzahlen.md\">Ziele<\/a><\/td><td>Risikoregister, Patch-/Incident-Logs<\/td><td>quartalsweise<\/td><td>Patrick Motsch<\/td><\/tr><tr><td>Verfügbarkeit Plattform<\/td><td>Uptime %<\/td><td>Monitoring/Statusseite<\/td><td>laufend<\/td><td>Patrick Motsch<\/td><\/tr><tr><td>Vorfälle<\/td><td>Anzahl, Schweregrad, Reaktionszeit<\/td><td><a href=\"../05_betrieb/07_Incident_Response_und_Meldewesen.md\">Incident Response<\/a><\/td><td>je Vorfall<\/td><td>Patrick Motsch<\/td><\/tr><tr><td>Dokumentenpflege<\/td><td>überfällige Reviews<\/td><td><a href=\"../cockpit/\">Cockpit<\/a><\/td><td>laufend<\/td><td>Patrick Motsch<\/td><\/tr><tr><td>Schwachstellen<\/td><td>offen/behoben, SLA-Treue<\/td><td><a href=\"../05_betrieb/10_Schwachstellenmanagement.md\">Schwachstellen<\/a><\/td><td>laufend<\/td><td>Patrick Motsch<\/td><\/tr><\/tbody><\/table>\n<h2>2. Analyse und Bewertung<\/h2>\n<p>Die Kennzahlen werden quartalsweise zusammengefasst und im <a href=\"management-review.md\">Management-Review<\/a> bewertet. Zielverfehlungen lösen Einträge im <a href=\"../07_verbesserung/massnahmen-register.md\">Massnahmenregister<\/a> aus.<\/p>\n<h2>3. Werkzeuge<\/h2>\n<p>Das <a href=\"../cockpit/\">Management-Cockpit<\/a> liefert die laufende Sicht auf Dokumentenstatus, fällige Reviews und offene Pendenzen. Betriebskennzahlen stammen aus Monitoring, Forgejo und den Betriebs-Records.<\/p>", "text": "<!-- docid: ims-09-03 --> <!-- status: entwurf --> <!-- version: 0.1 --> <!-- owner: patrick motsch --> <!-- approver: geschäftsführung poweron ag --> <!-- approveddate: --> <!-- nextreview: 2027-06-03 --> <!-- classification: intern --> <!-- isorefs: 9001:9.1; 27001:9.1 --> # monitoring, messung, analyse und bewertung **dokumenttyp:** verfahren (pflicht iso 9001/27001 kap. 9.1) ## 1. was wird gemessen | gegenstand | kennzahl | quelle | frequenz | owner | |---|---|---|---|---| | qualitätsziele q-1..q-4 | siehe [ziele](../03_planung/ziele-und-kennzahlen.md) | tickets, releases, changelog | quartalsweise | patrick motsch | | sicherheitsziele s-1..s-6 | siehe [ziele](../03_planung/ziele-und-kennzahlen.md) | risikoregister, patch-/incident-logs | quartalsweise | patrick motsch | | verfügbarkeit plattform | uptime % | monitoring/statusseite | laufend | patrick motsch | | vorfälle | anzahl, schweregrad, reaktionszeit | [incident response](../05_betrieb/07_incident_response_und_meldewesen.md) | je vorfall | patrick motsch | | dokumentenpflege | überfällige reviews | [cockpit](../cockpit/) | laufend | patrick motsch | | schwachstellen | offen/behoben, sla-treue | [schwachstellen](../05_betrieb/10_schwachstellenmanagement.md) | laufend | patrick motsch | ## 2. analyse und bewertung die kennzahlen werden quartalsweise zusammengefasst und im [management-review](management-review.md) bewertet. zielverfehlungen lösen einträge im [massnahmenregister](../07_verbesserung/massnahmen-register.md) aus. ## 3. werkzeuge das [management-cockpit](../cockpit/) liefert die laufende sicht auf dokumentenstatus, fällige reviews und offene pendenzen. betriebskennzahlen stammen aus monitoring, forgejo und den betriebs-records. ", "nextReview": "2027-06-03", "overdueReview": false, "zuPruefen": []}, {"id": "07_verbesserung/korrekturmassnahmen-und-kvp.md", "path": "07_verbesserung/korrekturmassnahmen-und-kvp.md", "chapter": "07_verbesserung", "title": "Korrekturmassnahmen & kontinuierliche Verbesserung (KVP)", "filename": "korrekturmassnahmen-und-kvp.md", "meta": {"docId": "IMS-10-01", "status": "entwurf", "version": "0.1", "owner": "Patrick Motsch", "approver": "Geschäftsführung PowerOn AG", "approvedDate": "", "nextReview": "2027-06-03", "classification": "intern", "isoRefs": "9001:10; 27001:10"}, "html": "<h1>Korrekturmassnahmen &amp; kontinuierliche Verbesserung (KVP)<\/h1>\n<p><strong>Dokumenttyp:<\/strong> Verfahren (Pflicht ISO 9001/27001 Kap. 10)<\/p>\n<h2>1. Zweck<\/h2>\n<p>Abweichungen (Nichtkonformitäten), Vorfälle, Reklamationen und Verbesserungsideen werden systematisch erfasst, behandelt und auf Wirksamkeit geprüft. Ziel ist die kontinuierliche Verbesserung des IMS.<\/p>\n<h2>2. Ablauf der Korrekturmassnahme<\/h2>\n<pre class=\"mermaid\">flowchart LR\n    erfassen[\"1 Abweichung erfassen (Massnahmenregister)\"] --&gt; sofort[\"2 Sofortmassnahme / Eindämmung\"]\n    sofort --&gt; ursache[\"3 Ursachenanalyse (Root Cause)\"]\n    ursache --&gt; massnahme[\"4 Korrekturmassnahme definieren (Owner, Termin)\"]\n    massnahme --&gt; umsetzen[\"5 Umsetzen\"]\n    umsetzen --&gt; wirksam[\"6 Wirksamkeit prüfen\"]\n    wirksam --&gt; schliessen[\"7 Schliessen + dokumentieren\"]<\/pre>\n<h2>3. Quellen von Abweichungen/Pendenzen<\/h2>\n<ul><li>Interne Audits (<a href=\"../06_bewertung/internes-audit.md\">internes-audit.md<\/a>)<\/li><li>Sicherheitsvorfälle (<a href=\"../05_betrieb/07_Incident_Response_und_Meldewesen.md\">Incident Response<\/a>)<\/li><li>Risikobehandlung (<a href=\"../03_planung/risikoregister.md\">Risikoregister<\/a>)<\/li><li>Zielverfehlungen (<a href=\"../06_bewertung/monitoring-messung.md\">Monitoring<\/a>)<\/li><li>Kundenreklamationen, Lieferantenprobleme<\/li><li>Überfällige Dokumenten-Reviews<\/li><li>Verbesserungsvorschläge<\/li><\/ul>\n<h2>4. Führung im Massnahmenregister<\/h2>\n<p>Alle Korrektur- und Verbesserungsmassnahmen werden zentral im <a href=\"massnahmen-register.md\">Massnahmenregister<\/a> geführt (Single Source of Truth). Das <a href=\"../cockpit/\">Cockpit<\/a> aggregiert daraus zusammen mit überfälligen Reviews und <code>[ZU PRÜFEN]<\/code>-Markern eine Gesamtsicht der Pendenzen.<\/p>\n<h2>5. Kontinuierliche Verbesserung<\/h2>\n<p>Trends (wiederkehrende Abweichungen, Incident-Muster) werden im <a href=\"../06_bewertung/management-review.md\">Management-Review<\/a> bewertet und führen zu präventiven Verbesserungen an Prozessen, Controls oder Dokumenten.<\/p>", "text": "<!-- docid: ims-10-01 --> <!-- status: entwurf --> <!-- version: 0.1 --> <!-- owner: patrick motsch --> <!-- approver: geschäftsführung poweron ag --> <!-- approveddate: --> <!-- nextreview: 2027-06-03 --> <!-- classification: intern --> <!-- isorefs: 9001:10; 27001:10 --> # korrekturmassnahmen & kontinuierliche verbesserung (kvp) **dokumenttyp:** verfahren (pflicht iso 9001/27001 kap. 10) ## 1. zweck abweichungen (nichtkonformitäten), vorfälle, reklamationen und verbesserungsideen werden systematisch erfasst, behandelt und auf wirksamkeit geprüft. ziel ist die kontinuierliche verbesserung des ims. ## 2. ablauf der korrekturmassnahme ```mermaid flowchart lr erfassen[\"1 abweichung erfassen (massnahmenregister)\"] --> sofort[\"2 sofortmassnahme / eindämmung\"] sofort --> ursache[\"3 ursachenanalyse (root cause)\"] ursache --> massnahme[\"4 korrekturmassnahme definieren (owner, termin)\"] massnahme --> umsetzen[\"5 umsetzen\"] umsetzen --> wirksam[\"6 wirksamkeit prüfen\"] wirksam --> schliessen[\"7 schliessen + dokumentieren\"] ``` ## 3. quellen von abweichungen/pendenzen - interne audits ([internes-audit.md](../06_bewertung/internes-audit.md)) - sicherheitsvorfälle ([incident response](../05_betrieb/07_incident_response_und_meldewesen.md)) - risikobehandlung ([risikoregister](../03_planung/risikoregister.md)) - zielverfehlungen ([monitoring](../06_bewertung/monitoring-messung.md)) - kundenreklamationen, lieferantenprobleme - überfällige dokumenten-reviews - verbesserungsvorschläge ## 4. führung im massnahmenregister alle korrektur- und verbesserungsmassnahmen werden zentral im [massnahmenregister](massnahmen-register.md) geführt (single source of truth). das [cockpit](../cockpit/) aggregiert daraus zusammen mit überfälligen reviews und `[zu prüfen]`-markern eine gesamtsicht der pendenzen. ## 5. kontinuierliche verbesserung trends (wiederkehrende abweichungen, incident-muster) werden im [management-review](../06_bewertung/management-review.md) bewertet und führen zu präventiven verbesserungen an prozessen, controls oder dokumenten. ", "nextReview": "2027-06-03", "overdueReview": false, "zuPruefen": []}, {"id": "07_verbesserung/massnahmen-register.md", "path": "07_verbesserung/massnahmen-register.md", "chapter": "07_verbesserung", "title": "Massnahmenregister (Pendenzen)", "filename": "massnahmen-register.md", "meta": {"docId": "IMS-10-02", "status": "entwurf", "version": "0.1", "owner": "Patrick Motsch", "approver": "Geschäftsführung PowerOn AG", "approvedDate": "", "nextReview": "2026-09-03", "classification": "intern", "isoRefs": "9001:10.2; 27001:10.1"}, "html": "<h1>Massnahmenregister (Pendenzen)<\/h1>\n<p><strong>Dokumenttyp:<\/strong> Record (zentrale Pendenzenliste -- Single Source of Truth)<\/p>\n<p>Zentrale Liste aller Korrektur- und Verbesserungsmassnahmen. Das <a href=\"../cockpit/\">Management-Cockpit<\/a> liest diese Tabelle und führt sie auf der Pendenzen-Seite mit überfälligen Reviews und <code>[ZU PRÜFEN]<\/code>-Markern zusammen.<\/p>\n<p><strong>Spalten-Schema (bitte exakt einhalten):<\/strong> <code>ID | Titel | Owner | Quelle | Erstellt | Faellig | Status<\/code> <strong>Status-Werte:<\/strong> <code>offen<\/code>, <code>in Arbeit<\/code>, <code>erledigt<\/code>. <strong>Quelle-Werte:<\/strong> <code>Audit<\/code>, <code>Review<\/code>, <code>Risiko<\/code>, <code>Incident<\/code>, <code>Doku<\/code>, <code>Sonstiges<\/code>.<\/p>\n<table><thead><tr><th>ID<\/th><th>Titel<\/th><th>Owner<\/th><th>Quelle<\/th><th>Erstellt<\/th><th>Fällig<\/th><th>Status<\/th><\/tr><\/thead><tbody><tr><td>M-01<\/td><td>MFA auf Admin-/Server-Zugängen bestätigen/erzwingen<\/td><td>Patrick Motsch<\/td><td>Risiko<\/td><td>2026-06-03<\/td><td>2026-07-15<\/td><td>erledigt<\/td><\/tr><tr><td>M-02<\/td><td>Restore-Test durchführen und protokollieren<\/td><td>Patrick Motsch<\/td><td>Risiko<\/td><td>2026-06-03<\/td><td>2026-06-30<\/td><td>offen<\/td><\/tr><tr><td>M-03<\/td><td>AVV/Zero-Retention mit OpenAI und weiteren LLM-Providern ablegen<\/td><td>Patrick Motsch<\/td><td>Risiko<\/td><td>2026-06-03<\/td><td>2026-07-31<\/td><td>offen<\/td><\/tr><tr><td>M-04<\/td><td>Log-Aufbewahrungsdauer und Manipulationsschutz festlegen<\/td><td>Patrick Motsch<\/td><td>Risiko<\/td><td>2026-06-03<\/td><td>2026-07-31<\/td><td>offen<\/td><\/tr><tr><td>M-05<\/td><td>Verschlüsselung at-rest der Infomaniak-DB bestätigen<\/td><td>Patrick Motsch<\/td><td>Risiko<\/td><td>2026-06-03<\/td><td>2026-06-30<\/td><td>offen<\/td><\/tr><tr><td>M-06<\/td><td>Entscheidung zu Produktivdaten in Testumgebung treffen<\/td><td>Patrick Motsch<\/td><td>Doku<\/td><td>2026-06-03<\/td><td>2026-07-15<\/td><td>offen<\/td><\/tr><tr><td>M-07<\/td><td>Hintergrundprüfungen bei Einstellung klären<\/td><td>Patrick Motsch<\/td><td>Risiko<\/td><td>2026-06-03<\/td><td>2026-08-15<\/td><td>offen<\/td><\/tr><tr><td>M-08<\/td><td>Externen internen Auditor benennen und beauftragen<\/td><td>Patrick Motsch<\/td><td>Audit<\/td><td>2026-06-03<\/td><td>2026-07-15<\/td><td>offen<\/td><\/tr><tr><td>M-09<\/td><td>Erstes internes Audit durchführen<\/td><td>Patrick Motsch<\/td><td>Audit<\/td><td>2026-06-03<\/td><td>2026-09-30<\/td><td>offen<\/td><\/tr><tr><td>M-10<\/td><td>Erstes Management-Review durchführen<\/td><td>Patrick Motsch<\/td><td>Review<\/td><td>2026-06-03<\/td><td>2026-09-30<\/td><td>offen<\/td><\/tr><tr><td>M-11<\/td><td>Risikoworkshop zur Validierung des Risikoregisters<\/td><td>Patrick Motsch<\/td><td>Risiko<\/td><td>2026-06-03<\/td><td>2026-06-30<\/td><td>offen<\/td><\/tr><tr><td>M-12<\/td><td>Asset-Inventar erstellen (A.5.9)<\/td><td>Patrick Motsch<\/td><td>Doku<\/td><td>2026-06-03<\/td><td>2026-08-31<\/td><td>offen<\/td><\/tr><tr><td>M-13<\/td><td>Politiken formal freigeben (Status entwurf -&gt; freigegeben)<\/td><td>Patrick Motsch<\/td><td>Doku<\/td><td>2026-06-03<\/td><td>2026-07-31<\/td><td>offen<\/td><\/tr><tr><td>M-14<\/td><td>Organisationsreglement administrativ durch Verwaltungsrat freigeben<\/td><td>Patrick Motsch<\/td><td>Review<\/td><td>2026-06-11<\/td><td>2026-06-12<\/td><td>in Arbeit<\/td><\/tr><\/tbody><\/table>\n<h2>Pflegehinweis<\/h2>\n<p>Neue Pendenzen mit fortlaufender ID ergänzen. Bei Abschluss <code>Status = erledigt<\/code> setzen (Zeile bleibt für Nachweis erhalten). Überfällige Einträge (Fällig &lt; heute, Status != erledigt) hebt das Cockpit rot hervor.<\/p>", "text": "<!-- docid: ims-10-02 --> <!-- status: entwurf --> <!-- version: 0.1 --> <!-- owner: patrick motsch --> <!-- approver: geschäftsführung poweron ag --> <!-- approveddate: --> <!-- nextreview: 2026-09-03 --> <!-- classification: intern --> <!-- isorefs: 9001:10.2; 27001:10.1 --> # massnahmenregister (pendenzen) **dokumenttyp:** record (zentrale pendenzenliste -- single source of truth) zentrale liste aller korrektur- und verbesserungsmassnahmen. das [management-cockpit](../cockpit/) liest diese tabelle und führt sie auf der pendenzen-seite mit überfälligen reviews und `[zu prüfen]`-markern zusammen. **spalten-schema (bitte exakt einhalten):** `id | titel | owner | quelle | erstellt | faellig | status` **status-werte:** `offen`, `in arbeit`, `erledigt`. **quelle-werte:** `audit`, `review`, `risiko`, `incident`, `doku`, `sonstiges`. | id | titel | owner | quelle | erstellt | fällig | status | |---|---|---|---|---|---|---| | m-01 | mfa auf admin-/server-zugängen bestätigen/erzwingen | patrick motsch | risiko | 2026-06-03 | 2026-07-15 | erledigt | | m-02 | restore-test durchführen und protokollieren | patrick motsch | risiko | 2026-06-03 | 2026-06-30 | offen | | m-03 | avv/zero-retention mit openai und weiteren llm-providern ablegen | patrick motsch | risiko | 2026-06-03 | 2026-07-31 | offen | | m-04 | log-aufbewahrungsdauer und manipulationsschutz festlegen | patrick motsch | risiko | 2026-06-03 | 2026-07-31 | offen | | m-05 | verschlüsselung at-rest der infomaniak-db bestätigen | patrick motsch | risiko | 2026-06-03 | 2026-06-30 | offen | | m-06 | entscheidung zu produktivdaten in testumgebung treffen | patrick motsch | doku | 2026-06-03 | 2026-07-15 | offen | | m-07 | hintergrundprüfungen bei einstellung klären | patrick motsch | risiko | 2026-06-03 | 2026-08-15 | offen | | m-08 | externen internen auditor benennen und beauftragen | patrick motsch | audit | 2026-06-03 | 2026-07-15 | offen | | m-09 | erstes internes audit durchführen | patrick motsch | audit | 2026-06-03 | 2026-09-30 | offen | | m-10 | erstes management-review durchführen | patrick motsch | review | 2026-06-03 | 2026-09-30 | offen | | m-11 | risikoworkshop zur validierung des risikoregisters | patrick motsch | risiko | 2026-06-03 | 2026-06-30 | offen | | m-12 | asset-inventar erstellen (a.5.9) | patrick motsch | doku | 2026-06-03 | 2026-08-31 | offen | | m-13 | politiken formal freigeben (status entwurf -> freigegeben) | patrick motsch | doku | 2026-06-03 | 2026-07-31 | offen | | m-14 | organisationsreglement administrativ durch verwaltungsrat freigeben | patrick motsch | review | 2026-06-11 | 2026-06-12 | in arbeit | ## pflegehinweis neue pendenzen mit fortlaufender id ergänzen. bei abschluss `status = erledigt` setzen (zeile bleibt für nachweis erhalten). überfällige einträge (fällig < heute, status != erledigt) hebt das cockpit rot hervor. ", "nextReview": "2026-09-03", "overdueReview": false, "zuPruefen": []}, {"id": "mappings/cacc-iso-crosswalk.md", "path": "mappings/cacc-iso-crosswalk.md", "chapter": "mappings", "title": "CACC / FINMA <-> ISO-Crosswalk", "filename": "cacc-iso-crosswalk.md", "meta": {"docId": "IMS-MAP-CACC", "status": "entwurf", "version": "1.1", "owner": "Patrick Motsch", "approver": "Geschäftsführung PowerOn AG", "approvedDate": "", "nextReview": "2027-06-03", "classification": "intern", "isoRefs": "27001:AnnexA; 9001:8"}, "html": "<h1>CACC / FINMA &lt;-&gt; ISO-Crosswalk<\/h1>\n<p><strong>Zweck:<\/strong> Verknüpft die bestehenden Prozessdokumente (ursprünglich für <strong>GLKB Cloud Assessment Criteria Catalogue (CACC)<\/strong> und FINMA-Rundschreiben 2018/3 &amp; 2023/1 erstellt) mit ihren neuen Speicherorten im IMS sowie den abgedeckten CACC-Punkten. Das Annex-A-Mapping für ISO 27001 ist das <a href=\"../03_planung/statement-of-applicability-soa.md\">SoA<\/a>.<\/p>\n<p><strong>Stand:<\/strong> 2026-06-03 <strong>Hinweis:<\/strong> <code>[ZU PRÜFEN]<\/code> markiert Stellen, die vor einer Einreichung verifiziert werden müssen.<\/p>\n<h2>Rahmenbedingungen<\/h2>\n<ul><li><strong>Hosting:<\/strong> Infomaniak Public Cloud, Schweiz (<code>api.poweron.swiss<\/code>, <code>db.poweron.swiss<\/code>).<\/li><li><strong>KI-Verarbeitung:<\/strong> Inhaltsdaten gehen an externe LLM-Provider (Primär OpenAI/USA); abgesichert via AVV/DPA + EU-SCC + Neutralisierung.<\/li><li><strong>Team:<\/strong> 2-5 Personen; wo Katalogpunkte grössere Organisationen voraussetzen, greifen kompensierende Massnahmen.<\/li><\/ul>\n<h2>Dokumentenkarte -&gt; neuer Ort + CACC-Punkte<\/h2>\n<table><thead><tr><th>Dokument (neuer Ort in <code>ims/<\/code>)<\/th><th>CACC-Punkte<\/th><\/tr><\/thead><tbody><tr><td><code>02_fuehrung/informationssicherheitspolitik.md<\/code><\/td><td>49, 52, 56<\/td><\/tr><tr><td><code>05_betrieb/02_Zugriffsmanagement_IAM_PAM.md<\/code><\/td><td>25, 36, 37, 66, 67, 68, 69<\/td><\/tr><tr><td><code>05_betrieb/03_Mitarbeitersicherheit_und_Screening.md<\/code><\/td><td>23, 35, 37<\/td><\/tr><tr><td><code>05_betrieb/04_Verschluesselung_und_Schluesselmanagement.md<\/code><\/td><td>43, 44, 45, 46, 70, 71, 72<\/td><\/tr><tr><td><code>05_betrieb/05_Backup_und_Wiederherstellung.md<\/code><\/td><td>75, 87<\/td><\/tr><tr><td><code>05_betrieb/06_Business_Continuity_und_Disaster_Recovery.md<\/code><\/td><td>3, 79, 87<\/td><\/tr><tr><td><code>05_betrieb/07_Incident_Response_und_Meldewesen.md<\/code><\/td><td>19, 20, 27, 86<\/td><\/tr><tr><td><code>05_betrieb/08_Change_Management.md<\/code><\/td><td>81, 82, 83<\/td><\/tr><tr><td><code>05_betrieb/09_Patch_Management.md<\/code><\/td><td>78<\/td><\/tr><tr><td><code>05_betrieb/10_Schwachstellenmanagement.md<\/code><\/td><td>54, 59, 63, 84<\/td><\/tr><tr><td><code>05_betrieb/11_Logging_und_Monitoring.md<\/code><\/td><td>88, 89, 90, 91, 92, 93, 94<\/td><\/tr><tr><td><code>05_betrieb/12_Netzwerk_und_Infrastruktursicherheit.md<\/code><\/td><td>95, 96, 97, 98, 99<\/td><\/tr><tr><td><code>05_betrieb/13_Datenaufbewahrung_Loeschung_LegalHold.md<\/code><\/td><td>1, 2, 38, 72<\/td><\/tr><tr><td><code>05_betrieb/14_Exit_und_Transition.md<\/code><\/td><td>4, 5, 6, 22<\/td><\/tr><tr><td><code>05_betrieb/15_Sichere_Softwareentwicklung_SDLC.md<\/code><\/td><td>100, 101, 102<\/td><\/tr><tr><td><code>05_betrieb/16_Kapazitaetsmanagement.md<\/code><\/td><td>80<\/td><\/tr><tr><td><code>05_betrieb/17_Subunternehmer_Management.md<\/code><\/td><td>16, 31, 48, 53<\/td><\/tr><tr><td><code>05_betrieb/18_Analyse_Recht_und_BestPractice.md<\/code><\/td><td>Befundbericht (intern)<\/td><\/tr><tr><td><code>05_betrieb/20260528_drittanbieter-inventar.md<\/code><\/td><td>48, 53, 61<\/td><\/tr><tr><td><code>05_betrieb/20260528_datenbank-handling.md<\/code><\/td><td>2, 38, 75 (teilw.)<\/td><\/tr><tr><td><code>05_betrieb/20260528_bcm_runbook.md<\/code><\/td><td>3, 87 (technisch)<\/td><\/tr><tr><td><code>05_betrieb/20260528_feature_release_bugfix.md<\/code><\/td><td>81, 100, 101 (teilw.)<\/td><\/tr><\/tbody><\/table>\n<h2>Offene Punkte (in Massnahmenregister überführt)<\/h2>\n<p>Die frühere Sammelliste offener Punkte wird jetzt zentral im <a href=\"../07_verbesserung/massnahmen-register.md\">Massnahmenregister<\/a> geführt (M-01 bis M-07 u. a.: at-rest-Verschlüsselung, MFA, Hintergrundprüfungen, Log-Retention, Restore-Test, AVVs, Testdaten).<\/p>", "text": "<!-- docid: ims-map-cacc --> <!-- status: entwurf --> <!-- version: 1.1 --> <!-- owner: patrick motsch --> <!-- approver: geschäftsführung poweron ag --> <!-- approveddate: --> <!-- nextreview: 2027-06-03 --> <!-- classification: intern --> <!-- isorefs: 27001:annexa; 9001:8 --> # cacc / finma <-> iso-crosswalk **zweck:** verknüpft die bestehenden prozessdokumente (ursprünglich für **glkb cloud assessment criteria catalogue (cacc)** und finma-rundschreiben 2018/3 & 2023/1 erstellt) mit ihren neuen speicherorten im ims sowie den abgedeckten cacc-punkten. das annex-a-mapping für iso 27001 ist das [soa](../03_planung/statement-of-applicability-soa.md). **stand:** 2026-06-03 **hinweis:** `[zu prüfen]` markiert stellen, die vor einer einreichung verifiziert werden müssen. ## rahmenbedingungen - **hosting:** infomaniak public cloud, schweiz (`api.poweron.swiss`, `db.poweron.swiss`). - **ki-verarbeitung:** inhaltsdaten gehen an externe llm-provider (primär openai/usa); abgesichert via avv/dpa + eu-scc + neutralisierung. - **team:** 2-5 personen; wo katalogpunkte grössere organisationen voraussetzen, greifen kompensierende massnahmen. ## dokumentenkarte -> neuer ort + cacc-punkte | dokument (neuer ort in `ims/`) | cacc-punkte | |---|---| | `02_fuehrung/informationssicherheitspolitik.md` | 49, 52, 56 | | `05_betrieb/02_zugriffsmanagement_iam_pam.md` | 25, 36, 37, 66, 67, 68, 69 | | `05_betrieb/03_mitarbeitersicherheit_und_screening.md` | 23, 35, 37 | | `05_betrieb/04_verschluesselung_und_schluesselmanagement.md` | 43, 44, 45, 46, 70, 71, 72 | | `05_betrieb/05_backup_und_wiederherstellung.md` | 75, 87 | | `05_betrieb/06_business_continuity_und_disaster_recovery.md` | 3, 79, 87 | | `05_betrieb/07_incident_response_und_meldewesen.md` | 19, 20, 27, 86 | | `05_betrieb/08_change_management.md` | 81, 82, 83 | | `05_betrieb/09_patch_management.md` | 78 | | `05_betrieb/10_schwachstellenmanagement.md` | 54, 59, 63, 84 | | `05_betrieb/11_logging_und_monitoring.md` | 88, 89, 90, 91, 92, 93, 94 | | `05_betrieb/12_netzwerk_und_infrastruktursicherheit.md` | 95, 96, 97, 98, 99 | | `05_betrieb/13_datenaufbewahrung_loeschung_legalhold.md` | 1, 2, 38, 72 | | `05_betrieb/14_exit_und_transition.md` | 4, 5, 6, 22 | | `05_betrieb/15_sichere_softwareentwicklung_sdlc.md` | 100, 101, 102 | | `05_betrieb/16_kapazitaetsmanagement.md` | 80 | | `05_betrieb/17_subunternehmer_management.md` | 16, 31, 48, 53 | | `05_betrieb/18_analyse_recht_und_bestpractice.md` | befundbericht (intern) | | `05_betrieb/20260528_drittanbieter-inventar.md` | 48, 53, 61 | | `05_betrieb/20260528_datenbank-handling.md` | 2, 38, 75 (teilw.) | | `05_betrieb/20260528_bcm_runbook.md` | 3, 87 (technisch) | | `05_betrieb/20260528_feature_release_bugfix.md` | 81, 100, 101 (teilw.) | ## offene punkte (in massnahmenregister überführt) die frühere sammelliste offener punkte wird jetzt zentral im [massnahmenregister](../07_verbesserung/massnahmen-register.md) geführt (m-01 bis m-07 u. a.: at-rest-verschlüsselung, mfa, hintergrundprüfungen, log-retention, restore-test, avvs, testdaten). ", "nextReview": "2027-06-03", "overdueReview": false, "zuPruefen": []}, {"id": "mappings/iso27001-annexA-soa-mapping.md", "path": "mappings/iso27001-annexA-soa-mapping.md", "chapter": "mappings", "title": "Mapping ISO/IEC 27001:2022 Annex A", "filename": "iso27001-annexA-soa-mapping.md", "meta": {"docId": "IMS-MAP-27001", "status": "entwurf", "version": "0.1", "owner": "Patrick Motsch", "approver": "Geschäftsführung PowerOn AG", "approvedDate": "", "nextReview": "2027-06-03", "classification": "intern", "isoRefs": "27001:AnnexA"}, "html": "<h1>Mapping ISO/IEC 27001:2022 Annex A<\/h1>\n<p>Das massgebliche Mapping aller 93 Annex-A-Controls (Anwendbarkeit, Status, umsetzendes Dokument) ist das <strong>Statement of Applicability<\/strong>:<\/p>\n<p>-&gt; <a href=\"../03_planung/statement-of-applicability-soa.md\">Statement of Applicability (SoA)<\/a><\/p>\n<p>Die ISO-27001-Hauptklauseln 4-10 werden durch das Managementsystem-Geruest abgedeckt; siehe <a href=\"iso9001-klausel-mapping.md\">iso9001-klausel-mapping.md<\/a> (strukturgleich, Annex SL) sowie die <code>isoRefs<\/code>-Header der einzelnen Dokumente.<\/p>", "text": "<!-- docid: ims-map-27001 --> <!-- status: entwurf --> <!-- version: 0.1 --> <!-- owner: patrick motsch --> <!-- approver: geschäftsführung poweron ag --> <!-- approveddate: --> <!-- nextreview: 2027-06-03 --> <!-- classification: intern --> <!-- isorefs: 27001:annexa --> # mapping iso/iec 27001:2022 annex a das massgebliche mapping aller 93 annex-a-controls (anwendbarkeit, status, umsetzendes dokument) ist das **statement of applicability**: -> [statement of applicability (soa)](../03_planung/statement-of-applicability-soa.md) die iso-27001-hauptklauseln 4-10 werden durch das managementsystem-geruest abgedeckt; siehe [iso9001-klausel-mapping.md](iso9001-klausel-mapping.md) (strukturgleich, annex sl) sowie die `isorefs`-header der einzelnen dokumente. ", "nextReview": "2027-06-03", "overdueReview": false, "zuPruefen": []}, {"id": "mappings/iso9001-klausel-mapping.md", "path": "mappings/iso9001-klausel-mapping.md", "chapter": "mappings", "title": "Mapping ISO 9001:2015 -- Klauseln zu IMS-Dokumenten", "filename": "iso9001-klausel-mapping.md", "meta": {"docId": "IMS-MAP-9001", "status": "entwurf", "version": "0.1", "owner": "Patrick Motsch", "approver": "Geschäftsführung PowerOn AG", "approvedDate": "", "nextReview": "2027-06-03", "classification": "intern", "isoRefs": "9001:4-10"}, "html": "<h1>Mapping ISO 9001:2015 -- Klauseln zu IMS-Dokumenten<\/h1>\n<p>Nachweis, welches Dokument welche ISO-9001-Anforderung abdeckt.<\/p>\n<table><thead><tr><th>Klausel<\/th><th>Anforderung<\/th><th>Dokument<\/th><\/tr><\/thead><tbody><tr><td>4.1/4.2<\/td><td>Kontext, interessierte Parteien<\/td><td><a href=\"../01_kontext/kontext-und-interessierte-parteien.md\">kontext-und-interessierte-parteien.md<\/a><\/td><\/tr><tr><td>4.3/4.4<\/td><td>Geltungsbereich, QMS &amp; Prozesse<\/td><td><a href=\"../01_kontext/geltungsbereich-scope.md\">geltungsbereich-scope.md<\/a><\/td><\/tr><tr><td>5.1/5.2<\/td><td>Führung, Qualitätspolitik<\/td><td><a href=\"../02_fuehrung/qm-politik.md\">qm-politik.md<\/a>, <a href=\"../00_IMS-Handbuch.md\">00_IMS-Handbuch.md<\/a><\/td><\/tr><tr><td>5.3<\/td><td>Rollen &amp; Verantwortlichkeiten<\/td><td><a href=\"../02_fuehrung/rollen-verantwortlichkeiten.md\">rollen-verantwortlichkeiten.md<\/a><\/td><\/tr><tr><td>6.1<\/td><td>Risiken &amp; Chancen<\/td><td><a href=\"../03_planung/risikomanagement-methodik.md\">risikomanagement-methodik.md<\/a>, <a href=\"../03_planung/risikoregister.md\">risikoregister.md<\/a><\/td><\/tr><tr><td>6.2<\/td><td>Qualitätsziele<\/td><td><a href=\"../03_planung/ziele-und-kennzahlen.md\">ziele-und-kennzahlen.md<\/a><\/td><\/tr><tr><td>7.1-7.3<\/td><td>Ressourcen, Kompetenz, Awareness<\/td><td><a href=\"../04_unterstuetzung/ressourcen-kompetenz-schulung.md\">ressourcen-kompetenz-schulung.md<\/a><\/td><\/tr><tr><td>7.4<\/td><td>Kommunikation<\/td><td><a href=\"../04_unterstuetzung/kommunikation.md\">kommunikation.md<\/a><\/td><\/tr><tr><td>7.5<\/td><td>Dokumentierte Information<\/td><td><a href=\"../04_unterstuetzung/dokumentenlenkung.md\">dokumentenlenkung.md<\/a>, <a href=\"../04_unterstuetzung/dokumentenregister.md\">dokumentenregister.md<\/a><\/td><\/tr><tr><td>8.1-8.6<\/td><td>Betrieb, Anforderungen, Entwicklung, Realisierung<\/td><td><a href=\"../05_betrieb/20260528_feature_release_bugfix.md\">feature_release_bugfix.md<\/a>, <a href=\"../05_betrieb/15_Sichere_Softwareentwicklung_SDLC.md\">SDLC<\/a>, <a href=\"../05_betrieb/08_Change_Management.md\">Change<\/a><\/td><\/tr><tr><td>9.1<\/td><td>Monitoring, Messung, Analyse<\/td><td><a href=\"../06_bewertung/monitoring-messung.md\">monitoring-messung.md<\/a><\/td><\/tr><tr><td>9.2<\/td><td>Internes Audit<\/td><td><a href=\"../06_bewertung/internes-audit.md\">internes-audit.md<\/a><\/td><\/tr><tr><td>9.3<\/td><td>Management-Review<\/td><td><a href=\"../06_bewertung/management-review.md\">management-review.md<\/a><\/td><\/tr><tr><td>10.1-10.3<\/td><td>Verbesserung, Nichtkonformität, KVP<\/td><td><a href=\"../07_verbesserung/korrekturmassnahmen-und-kvp.md\">korrekturmassnahmen-und-kvp.md<\/a>, <a href=\"../07_verbesserung/massnahmen-register.md\">massnahmen-register.md<\/a><\/td><\/tr><\/tbody><\/table>\n<h2>ISO/IEC 27001 Annex A<\/h2>\n<p>Das Mapping der ISO-27001-Annex-A-Controls ist das <a href=\"../03_planung/statement-of-applicability-soa.md\">Statement of Applicability (SoA)<\/a>. Die ISO-27001-Klauseln 4-10 sind strukturgleich zu ISO 9001 (Annex SL) und werden durch dieselben oben gelisteten Dokumente abgedeckt (vgl. <code>isoRefs<\/code>-Header je Dokument).<\/p>", "text": "<!-- docid: ims-map-9001 --> <!-- status: entwurf --> <!-- version: 0.1 --> <!-- owner: patrick motsch --> <!-- approver: geschäftsführung poweron ag --> <!-- approveddate: --> <!-- nextreview: 2027-06-03 --> <!-- classification: intern --> <!-- isorefs: 9001:4-10 --> # mapping iso 9001:2015 -- klauseln zu ims-dokumenten nachweis, welches dokument welche iso-9001-anforderung abdeckt. | klausel | anforderung | dokument | |---|---|---| | 4.1/4.2 | kontext, interessierte parteien | [kontext-und-interessierte-parteien.md](../01_kontext/kontext-und-interessierte-parteien.md) | | 4.3/4.4 | geltungsbereich, qms & prozesse | [geltungsbereich-scope.md](../01_kontext/geltungsbereich-scope.md) | | 5.1/5.2 | führung, qualitätspolitik | [qm-politik.md](../02_fuehrung/qm-politik.md), [00_ims-handbuch.md](../00_ims-handbuch.md) | | 5.3 | rollen & verantwortlichkeiten | [rollen-verantwortlichkeiten.md](../02_fuehrung/rollen-verantwortlichkeiten.md) | | 6.1 | risiken & chancen | [risikomanagement-methodik.md](../03_planung/risikomanagement-methodik.md), [risikoregister.md](../03_planung/risikoregister.md) | | 6.2 | qualitätsziele | [ziele-und-kennzahlen.md](../03_planung/ziele-und-kennzahlen.md) | | 7.1-7.3 | ressourcen, kompetenz, awareness | [ressourcen-kompetenz-schulung.md](../04_unterstuetzung/ressourcen-kompetenz-schulung.md) | | 7.4 | kommunikation | [kommunikation.md](../04_unterstuetzung/kommunikation.md) | | 7.5 | dokumentierte information | [dokumentenlenkung.md](../04_unterstuetzung/dokumentenlenkung.md), [dokumentenregister.md](../04_unterstuetzung/dokumentenregister.md) | | 8.1-8.6 | betrieb, anforderungen, entwicklung, realisierung | [feature_release_bugfix.md](../05_betrieb/20260528_feature_release_bugfix.md), [sdlc](../05_betrieb/15_sichere_softwareentwicklung_sdlc.md), [change](../05_betrieb/08_change_management.md) | | 9.1 | monitoring, messung, analyse | [monitoring-messung.md](../06_bewertung/monitoring-messung.md) | | 9.2 | internes audit | [internes-audit.md](../06_bewertung/internes-audit.md) | | 9.3 | management-review | [management-review.md](../06_bewertung/management-review.md) | | 10.1-10.3 | verbesserung, nichtkonformität, kvp | [korrekturmassnahmen-und-kvp.md](../07_verbesserung/korrekturmassnahmen-und-kvp.md), [massnahmen-register.md](../07_verbesserung/massnahmen-register.md) | ## iso/iec 27001 annex a das mapping der iso-27001-annex-a-controls ist das [statement of applicability (soa)](../03_planung/statement-of-applicability-soa.md). die iso-27001-klauseln 4-10 sind strukturgleich zu iso 9001 (annex sl) und werden durch dieselben oben gelisteten dokumente abgedeckt (vgl. `isorefs`-header je dokument). ", "nextReview": "2027-06-03", "overdueReview": false, "zuPruefen": []}], "chapters": [{"key": "00", "label": "Handbuch"}, {"key": "01_kontext", "label": "4 - Kontext"}, {"key": "02_fuehrung", "label": "5 - Führung"}, {"key": "03_planung", "label": "6 - Planung"}, {"key": "04_unterstuetzung", "label": "7 - Unterstützung"}, {"key": "05_betrieb", "label": "8 - Betrieb / Annex A"}, {"key": "06_bewertung", "label": "9 - Bewertung"}, {"key": "07_verbesserung", "label": "10 - Verbesserung"}, {"key": "mappings", "label": "Mappings"}], "pendenzenReg": [{"id": "M-01", "titel": "MFA auf Admin-/Server-Zugängen bestätigen/erzwingen", "owner": "Patrick Motsch", "quelle": "Risiko", "faellig": "2026-07-15", "status": "erledigt"}, {"id": "M-02", "titel": "Restore-Test durchführen und protokollieren", "owner": "Patrick Motsch", "quelle": "Risiko", "faellig": "2026-06-30", "status": "offen"}, {"id": "M-03", "titel": "AVV/Zero-Retention mit OpenAI und weiteren LLM-Providern ablegen", "owner": "Patrick Motsch", "quelle": "Risiko", "faellig": "2026-07-31", "status": "offen"}, {"id": "M-04", "titel": "Log-Aufbewahrungsdauer und Manipulationsschutz festlegen", "owner": "Patrick Motsch", "quelle": "Risiko", "faellig": "2026-07-31", "status": "offen"}, {"id": "M-05", "titel": "Verschlüsselung at-rest der Infomaniak-DB bestätigen", "owner": "Patrick Motsch", "quelle": "Risiko", "faellig": "2026-06-30", "status": "offen"}, {"id": "M-06", "titel": "Entscheidung zu Produktivdaten in Testumgebung treffen", "owner": "Patrick Motsch", "quelle": "Doku", "faellig": "2026-07-15", "status": "offen"}, {"id": "M-07", "titel": "Hintergrundprüfungen bei Einstellung klären", "owner": "Patrick Motsch", "quelle": "Risiko", "faellig": "2026-08-15", "status": "offen"}, {"id": "M-08", "titel": "Externen internen Auditor benennen und beauftragen", "owner": "Patrick Motsch", "quelle": "Audit", "faellig": "2026-07-15", "status": "offen"}, {"id": "M-09", "titel": "Erstes internes Audit durchführen", "owner": "Patrick Motsch", "quelle": "Audit", "faellig": "2026-09-30", "status": "offen"}, {"id": "M-10", "titel": "Erstes Management-Review durchführen", "owner": "Patrick Motsch", "quelle": "Review", "faellig": "2026-09-30", "status": "offen"}, {"id": "M-11", "titel": "Risikoworkshop zur Validierung des Risikoregisters", "owner": "Patrick Motsch", "quelle": "Risiko", "faellig": "2026-06-30", "status": "offen"}, {"id": "M-12", "titel": "Asset-Inventar erstellen (A.5.9)", "owner": "Patrick Motsch", "quelle": "Doku", "faellig": "2026-08-31", "status": "offen"}, {"id": "M-13", "titel": "Politiken formal freigeben (Status entwurf -> freigegeben)", "owner": "Patrick Motsch", "quelle": "Doku", "faellig": "2026-07-31", "status": "offen"}, {"id": "M-14", "titel": "Organisationsreglement administrativ durch Verwaltungsrat freigeben", "owner": "Patrick Motsch", "quelle": "Review", "faellig": "2026-06-12", "status": "in Arbeit"}], "overdueReviews": [], "zuPruefen": [{"id": "02_fuehrung/informationssicherheitspolitik.md", "title": "Informationssicherheitsrichtlinie (ISMS-Dachdokument)", "section": "8. Stand der Umsetzung / Lücken"}, {"id": "02_fuehrung/informationssicherheitspolitik.md", "title": "Informationssicherheitsrichtlinie (ISMS-Dachdokument)", "section": "8. Stand der Umsetzung / Lücken"}, {"id": "05_betrieb/02_Zugriffsmanagement_IAM_PAM.md", "title": "Zugriffsmanagement (IAM / PAM)", "section": "2. Zugriffsebenen der Plattform"}, {"id": "05_betrieb/02_Zugriffsmanagement_IAM_PAM.md", "title": "Zugriffsmanagement (IAM / PAM)", "section": "4. Authentifizierung (#68)"}, {"id": "05_betrieb/02_Zugriffsmanagement_IAM_PAM.md", "title": "Zugriffsmanagement (IAM / PAM)", "section": "4. Authentifizierung (#68)"}, {"id": "05_betrieb/02_Zugriffsmanagement_IAM_PAM.md", "title": "Zugriffsmanagement (IAM / PAM)", "section": "7. Zugangsbeschränkung auf IP/Domain (#69)"}, {"id": "05_betrieb/03_Mitarbeitersicherheit_und_Screening.md", "title": "Mitarbeitersicherheit und Screening", "section": "1. Vertraulichkeitsverpflichtung (#23)"}, {"id": "05_betrieb/03_Mitarbeitersicherheit_und_Screening.md", "title": "Mitarbeitersicherheit und Screening", "section": "2. Sorgfältige Auswahl und Hintergrundprüfung (#35)"}, {"id": "05_betrieb/03_Mitarbeitersicherheit_und_Screening.md", "title": "Mitarbeitersicherheit und Screening", "section": "2. Sorgfältige Auswahl und Hintergrundprüfung (#35)"}, {"id": "05_betrieb/03_Mitarbeitersicherheit_und_Screening.md", "title": "Mitarbeitersicherheit und Screening", "section": "2. Sorgfältige Auswahl und Hintergrundprüfung (#35)"}, {"id": "05_betrieb/03_Mitarbeitersicherheit_und_Screening.md", "title": "Mitarbeitersicherheit und Screening", "section": "3. Schulung und Awareness"}, {"id": "05_betrieb/03_Mitarbeitersicherheit_und_Screening.md", "title": "Mitarbeitersicherheit und Screening", "section": "5. Stand der Umsetzung / Lücken"}, {"id": "05_betrieb/03_Mitarbeitersicherheit_und_Screening.md", "title": "Mitarbeitersicherheit und Screening", "section": "5. Stand der Umsetzung / Lücken"}, {"id": "05_betrieb/03_Mitarbeitersicherheit_und_Screening.md", "title": "Mitarbeitersicherheit und Screening", "section": "5. Stand der Umsetzung / Lücken"}, {"id": "05_betrieb/04_Verschluesselung_und_Schluesselmanagement.md", "title": "Verschlüsselung und Schlüsselmanagement", "section": "1. Verschlüsselung bei der Übertragung (in transit) (#70)"}, {"id": "05_betrieb/04_Verschluesselung_und_Schluesselmanagement.md", "title": "Verschlüsselung und Schlüsselmanagement", "section": "1. Verschlüsselung bei der Übertragung (in transit) (#70)"}, {"id": "05_betrieb/04_Verschluesselung_und_Schluesselmanagement.md", "title": "Verschlüsselung und Schlüsselmanagement", "section": "2. Verschlüsselung im Ruhezustand (at rest) (#70)"}, {"id": "05_betrieb/04_Verschluesselung_und_Schluesselmanagement.md", "title": "Verschlüsselung und Schlüsselmanagement", "section": "2. Verschlüsselung im Ruhezustand (at rest) (#70)"}, {"id": "05_betrieb/04_Verschluesselung_und_Schluesselmanagement.md", "title": "Verschlüsselung und Schlüsselmanagement", "section": "3. Verarbeitung bei LLM-Providern (in use)"}, {"id": "05_betrieb/04_Verschluesselung_und_Schluesselmanagement.md", "title": "Verschlüsselung und Schlüsselmanagement", "section": "3. Verarbeitung bei LLM-Providern (in use)"}, {"id": "05_betrieb/04_Verschluesselung_und_Schluesselmanagement.md", "title": "Verschlüsselung und Schlüsselmanagement", "section": "4. Schlüsselmanagement-Modelle (#43–46, #71)"}, {"id": "05_betrieb/04_Verschluesselung_und_Schluesselmanagement.md", "title": "Verschlüsselung und Schlüsselmanagement", "section": "4. Schlüsselmanagement-Modelle (#43–46, #71)"}, {"id": "05_betrieb/04_Verschluesselung_und_Schluesselmanagement.md", "title": "Verschlüsselung und Schlüsselmanagement", "section": "4. Schlüsselmanagement-Modelle (#43–46, #71)"}, {"id": "05_betrieb/04_Verschluesselung_und_Schluesselmanagement.md", "title": "Verschlüsselung und Schlüsselmanagement", "section": "4. Schlüsselmanagement-Modelle (#43–46, #71)"}, {"id": "05_betrieb/04_Verschluesselung_und_Schluesselmanagement.md", "title": "Verschlüsselung und Schlüsselmanagement", "section": "5. Schlüssellebenszyklus (#72)"}, {"id": "05_betrieb/04_Verschluesselung_und_Schluesselmanagement.md", "title": "Verschlüsselung und Schlüsselmanagement", "section": "5. Schlüssellebenszyklus (#72)"}, {"id": "05_betrieb/04_Verschluesselung_und_Schluesselmanagement.md", "title": "Verschlüsselung und Schlüsselmanagement", "section": "5. Schlüssellebenszyklus (#72)"}, {"id": "05_betrieb/04_Verschluesselung_und_Schluesselmanagement.md", "title": "Verschlüsselung und Schlüsselmanagement", "section": "6. Stand der Umsetzung / Lücken"}, {"id": "05_betrieb/04_Verschluesselung_und_Schluesselmanagement.md", "title": "Verschlüsselung und Schlüsselmanagement", "section": "6. Stand der Umsetzung / Lücken"}, {"id": "05_betrieb/05_Backup_und_Wiederherstellung.md", "title": "Backup und Wiederherstellung", "section": "2.2 Überwachung der Datensicherung"}, {"id": "05_betrieb/05_Backup_und_Wiederherstellung.md", "title": "Backup und Wiederherstellung", "section": "3. Backup-Frequenz und Aufbewahrung"}, {"id": "05_betrieb/05_Backup_und_Wiederherstellung.md", "title": "Backup und Wiederherstellung", "section": "3. Backup-Frequenz und Aufbewahrung"}, {"id": "05_betrieb/05_Backup_und_Wiederherstellung.md", "title": "Backup und Wiederherstellung", "section": "4. Wiederherstellungsziele (RTO/RPO)"}, {"id": "05_betrieb/05_Backup_und_Wiederherstellung.md", "title": "Backup und Wiederherstellung", "section": "4. Wiederherstellungsziele (RTO/RPO)"}, {"id": "05_betrieb/05_Backup_und_Wiederherstellung.md", "title": "Backup und Wiederherstellung", "section": "6. Stand der Umsetzung / Lücken"}, {"id": "05_betrieb/06_Business_Continuity_und_Disaster_Recovery.md", "title": "Business Continuity (BCP) und Disaster Recovery (DRP)", "section": "3. Szenarien und Reaktion"}, {"id": "05_betrieb/06_Business_Continuity_und_Disaster_Recovery.md", "title": "Business Continuity (BCP) und Disaster Recovery (DRP)", "section": "4. Verfügbarkeitsüberwachung (#79)"}, {"id": "05_betrieb/06_Business_Continuity_und_Disaster_Recovery.md", "title": "Business Continuity (BCP) und Disaster Recovery (DRP)", "section": "5. Wiederherstellungsziele"}, {"id": "05_betrieb/06_Business_Continuity_und_Disaster_Recovery.md", "title": "Business Continuity (BCP) und Disaster Recovery (DRP)", "section": "5. Wiederherstellungsziele"}, {"id": "05_betrieb/06_Business_Continuity_und_Disaster_Recovery.md", "title": "Business Continuity (BCP) und Disaster Recovery (DRP)", "section": "6. Geografische Trennung / Backup-Standort"}, {"id": "05_betrieb/06_Business_Continuity_und_Disaster_Recovery.md", "title": "Business Continuity (BCP) und Disaster Recovery (DRP)", "section": "7. Tests und Überprüfung"}, {"id": "05_betrieb/06_Business_Continuity_und_Disaster_Recovery.md", "title": "Business Continuity (BCP) und Disaster Recovery (DRP)", "section": "7. Tests und Überprüfung"}, {"id": "05_betrieb/06_Business_Continuity_und_Disaster_Recovery.md", "title": "Business Continuity (BCP) und Disaster Recovery (DRP)", "section": "9. Stand der Umsetzung / Lücken"}, {"id": "05_betrieb/06_Business_Continuity_und_Disaster_Recovery.md", "title": "Business Continuity (BCP) und Disaster Recovery (DRP)", "section": "9. Stand der Umsetzung / Lücken"}, {"id": "05_betrieb/07_Incident_Response_und_Meldewesen.md", "title": "Incident Response und Meldewesen", "section": "8. Kleines Team — kompensierende Massnahmen"}, {"id": "05_betrieb/07_Incident_Response_und_Meldewesen.md", "title": "Incident Response und Meldewesen", "section": "9. Stand der Umsetzung / Lücken"}, {"id": "05_betrieb/08_Change_Management.md", "title": "Change Management", "section": "3. Frozen Zones und Maintenance Windows (#82)"}, {"id": "05_betrieb/08_Change_Management.md", "title": "Change Management", "section": "4. Standardisierte und sichere Konfiguration (#83)"}, {"id": "05_betrieb/08_Change_Management.md", "title": "Change Management", "section": "4. Standardisierte und sichere Konfiguration (#83)"}, {"id": "05_betrieb/08_Change_Management.md", "title": "Change Management", "section": "6. Stand der Umsetzung / Lücken"}, {"id": "05_betrieb/08_Change_Management.md", "title": "Change Management", "section": "6. Stand der Umsetzung / Lücken"}, {"id": "05_betrieb/09_Patch_Management.md", "title": "Patch Management", "section": "3. Ablauf"}, {"id": "05_betrieb/09_Patch_Management.md", "title": "Patch Management", "section": "5. Stand der Umsetzung / Lücken"}, {"id": "05_betrieb/09_Patch_Management.md", "title": "Patch Management", "section": "5. Stand der Umsetzung / Lücken"}, {"id": "05_betrieb/10_Schwachstellenmanagement.md", "title": "Schwachstellenmanagement", "section": "2. Identifizierungsmethoden (#63)"}, {"id": "05_betrieb/10_Schwachstellenmanagement.md", "title": "Schwachstellenmanagement", "section": "2. Identifizierungsmethoden (#63)"}, {"id": "05_betrieb/10_Schwachstellenmanagement.md", "title": "Schwachstellenmanagement", "section": "2. Identifizierungsmethoden (#63)"}, {"id": "05_betrieb/10_Schwachstellenmanagement.md", "title": "Schwachstellenmanagement", "section": "4. Unabhängige Audits (#54, #59)"}, {"id": "05_betrieb/10_Schwachstellenmanagement.md", "title": "Schwachstellenmanagement", "section": "6. Stand der Umsetzung / Lücken"}, {"id": "05_betrieb/10_Schwachstellenmanagement.md", "title": "Schwachstellenmanagement", "section": "6. Stand der Umsetzung / Lücken"}, {"id": "05_betrieb/11_Logging_und_Monitoring.md", "title": "Logging und Monitoring (Sicherheitsprotokollierung)", "section": "2. Protokollierung des Zugriffs auf Kundendaten (#88, #94)"}, {"id": "05_betrieb/11_Logging_und_Monitoring.md", "title": "Logging und Monitoring (Sicherheitsprotokollierung)", "section": "3. Kundenzugang zu Protokollen (#88)"}, {"id": "05_betrieb/11_Logging_und_Monitoring.md", "title": "Logging und Monitoring (Sicherheitsprotokollierung)", "section": "4. Automatische Analyse und Ereigniserkennung (#89, #90)"}, {"id": "05_betrieb/11_Logging_und_Monitoring.md", "title": "Logging und Monitoring (Sicherheitsprotokollierung)", "section": "4. Automatische Analyse und Ereigniserkennung (#89, #90)"}, {"id": "05_betrieb/11_Logging_und_Monitoring.md", "title": "Logging und Monitoring (Sicherheitsprotokollierung)", "section": "4. Automatische Analyse und Ereigniserkennung (#89, #90)"}, {"id": "05_betrieb/11_Logging_und_Monitoring.md", "title": "Logging und Monitoring (Sicherheitsprotokollierung)", "section": "5. Schutz der Protokolldaten (#91)"}, {"id": "05_betrieb/11_Logging_und_Monitoring.md", "title": "Logging und Monitoring (Sicherheitsprotokollierung)", "section": "6. 7×24-Analyse (#92) und SOC-Schnittstellen (#93)"}, {"id": "05_betrieb/11_Logging_und_Monitoring.md", "title": "Logging und Monitoring (Sicherheitsprotokollierung)", "section": "7. Stand der Umsetzung / Lücken"}, {"id": "05_betrieb/12_Netzwerk_und_Infrastruktursicherheit.md", "title": "Netzwerk- und Infrastruktursicherheit", "section": "1. Härtung und Basiskonfiguration (#95)"}, {"id": "05_betrieb/12_Netzwerk_und_Infrastruktursicherheit.md", "title": "Netzwerk- und Infrastruktursicherheit", "section": "1. Härtung und Basiskonfiguration (#95)"}, {"id": "05_betrieb/12_Netzwerk_und_Infrastruktursicherheit.md", "title": "Netzwerk- und Infrastruktursicherheit", "section": "1. Härtung und Basiskonfiguration (#95)"}, {"id": "05_betrieb/12_Netzwerk_und_Infrastruktursicherheit.md", "title": "Netzwerk- und Infrastruktursicherheit", "section": "2. Netzwerksegmentierung und Mandantentrennung (#96)"}, {"id": "05_betrieb/12_Netzwerk_und_Infrastruktursicherheit.md", "title": "Netzwerk- und Infrastruktursicherheit", "section": "3. Netzwerkschutzmassnahmen (#97)"}, {"id": "05_betrieb/12_Netzwerk_und_Infrastruktursicherheit.md", "title": "Netzwerk- und Infrastruktursicherheit", "section": "3. Netzwerkschutzmassnahmen (#97)"}, {"id": "05_betrieb/12_Netzwerk_und_Infrastruktursicherheit.md", "title": "Netzwerk- und Infrastruktursicherheit", "section": "3. Netzwerkschutzmassnahmen (#97)"}, {"id": "05_betrieb/12_Netzwerk_und_Infrastruktursicherheit.md", "title": "Netzwerk- und Infrastruktursicherheit", "section": "3. Netzwerkschutzmassnahmen (#97)"}, {"id": "05_betrieb/12_Netzwerk_und_Infrastruktursicherheit.md", "title": "Netzwerk- und Infrastruktursicherheit", "section": "4. Schutz vor netzwerkbasierten Angriffen / DDoS (#98)"}, {"id": "05_betrieb/12_Netzwerk_und_Infrastruktursicherheit.md", "title": "Netzwerk- und Infrastruktursicherheit", "section": "4. Schutz vor netzwerkbasierten Angriffen / DDoS (#98)"}, {"id": "05_betrieb/12_Netzwerk_und_Infrastruktursicherheit.md", "title": "Netzwerk- und Infrastruktursicherheit", "section": "5. Physische Sicherheit und Versorgung (#99)"}, {"id": "05_betrieb/12_Netzwerk_und_Infrastruktursicherheit.md", "title": "Netzwerk- und Infrastruktursicherheit", "section": "6. Stand der Umsetzung / Lücken"}, {"id": "05_betrieb/12_Netzwerk_und_Infrastruktursicherheit.md", "title": "Netzwerk- und Infrastruktursicherheit", "section": "6. Stand der Umsetzung / Lücken"}, {"id": "05_betrieb/12_Netzwerk_und_Infrastruktursicherheit.md", "title": "Netzwerk- und Infrastruktursicherheit", "section": "6. Stand der Umsetzung / Lücken"}, {"id": "05_betrieb/13_Datenaufbewahrung_Loeschung_LegalHold.md", "title": "Datenaufbewahrung, Löschung und Legal Hold", "section": "1. Legal Hold (#1)"}, {"id": "05_betrieb/13_Datenaufbewahrung_Loeschung_LegalHold.md", "title": "Datenaufbewahrung, Löschung und Legal Hold", "section": "2. Aufbewahrung und Löschung pro Datenkategorie (#2)"}, {"id": "05_betrieb/13_Datenaufbewahrung_Loeschung_LegalHold.md", "title": "Datenaufbewahrung, Löschung und Legal Hold", "section": "2. Aufbewahrung und Löschung pro Datenkategorie (#2)"}, {"id": "05_betrieb/13_Datenaufbewahrung_Loeschung_LegalHold.md", "title": "Datenaufbewahrung, Löschung und Legal Hold", "section": "2. Aufbewahrung und Löschung pro Datenkategorie (#2)"}, {"id": "05_betrieb/13_Datenaufbewahrung_Loeschung_LegalHold.md", "title": "Datenaufbewahrung, Löschung und Legal Hold", "section": "3. Löschung bei Vertragsende (#38)"}, {"id": "05_betrieb/13_Datenaufbewahrung_Loeschung_LegalHold.md", "title": "Datenaufbewahrung, Löschung und Legal Hold", "section": "3. Löschung bei Vertragsende (#38)"}, {"id": "05_betrieb/13_Datenaufbewahrung_Loeschung_LegalHold.md", "title": "Datenaufbewahrung, Löschung und Legal Hold", "section": "3. Löschung bei Vertragsende (#38)"}, {"id": "05_betrieb/13_Datenaufbewahrung_Loeschung_LegalHold.md", "title": "Datenaufbewahrung, Löschung und Legal Hold", "section": "6. Stand der Umsetzung / Lücken"}, {"id": "05_betrieb/14_Exit_und_Transition.md", "title": "Exit- und Transitionsmanagement (Repatriierung)", "section": "3. Datenexport (#5)"}, {"id": "05_betrieb/14_Exit_und_Transition.md", "title": "Exit- und Transitionsmanagement (Repatriierung)", "section": "7. Stand der Umsetzung / Lücken"}, {"id": "05_betrieb/15_Sichere_Softwareentwicklung_SDLC.md", "title": "Sichere Softwareentwicklung (Secure SDLC)", "section": "2. Sicherheit über den Entwicklungszyklus (#100)"}, {"id": "05_betrieb/15_Sichere_Softwareentwicklung_SDLC.md", "title": "Sichere Softwareentwicklung (Secure SDLC)", "section": "2. Sicherheit über den Entwicklungszyklus (#100)"}, {"id": "05_betrieb/15_Sichere_Softwareentwicklung_SDLC.md", "title": "Sichere Softwareentwicklung (Secure SDLC)", "section": "3. Standards und Frameworks (#101)"}, {"id": "05_betrieb/15_Sichere_Softwareentwicklung_SDLC.md", "title": "Sichere Softwareentwicklung (Secure SDLC)", "section": "3. Standards und Frameworks (#101)"}, {"id": "05_betrieb/15_Sichere_Softwareentwicklung_SDLC.md", "title": "Sichere Softwareentwicklung (Secure SDLC)", "section": "5. Stand der Umsetzung / Lücken"}, {"id": "05_betrieb/15_Sichere_Softwareentwicklung_SDLC.md", "title": "Sichere Softwareentwicklung (Secure SDLC)", "section": "5. Stand der Umsetzung / Lücken"}, {"id": "05_betrieb/16_Kapazitaetsmanagement.md", "title": "Kapazitätsmanagement", "section": "2. IT-Ressourcen-Kapazität"}, {"id": "05_betrieb/16_Kapazitaetsmanagement.md", "title": "Kapazitätsmanagement", "section": "2. IT-Ressourcen-Kapazität"}, {"id": "05_betrieb/16_Kapazitaetsmanagement.md", "title": "Kapazitätsmanagement", "section": "2. IT-Ressourcen-Kapazität"}, {"id": "05_betrieb/16_Kapazitaetsmanagement.md", "title": "Kapazitätsmanagement", "section": "2. IT-Ressourcen-Kapazität"}, {"id": "05_betrieb/16_Kapazitaetsmanagement.md", "title": "Kapazitätsmanagement", "section": "3. Personal-Kapazität (kleines Team)"}, {"id": "05_betrieb/16_Kapazitaetsmanagement.md", "title": "Kapazitätsmanagement", "section": "5. Stand der Umsetzung / Lücken"}, {"id": "05_betrieb/16_Kapazitaetsmanagement.md", "title": "Kapazitätsmanagement", "section": "5. Stand der Umsetzung / Lücken"}, {"id": "05_betrieb/17_Subunternehmer_Management.md", "title": "Subunternehmer- und Unterauftragsverarbeiter-Management", "section": "2. Compliance-Ergänzung zum Inventar (#48, #31)"}, {"id": "05_betrieb/17_Subunternehmer_Management.md", "title": "Subunternehmer- und Unterauftragsverarbeiter-Management", "section": "2. Compliance-Ergänzung zum Inventar (#48, #31)"}, {"id": "05_betrieb/17_Subunternehmer_Management.md", "title": "Subunternehmer- und Unterauftragsverarbeiter-Management", "section": "2. Compliance-Ergänzung zum Inventar (#48, #31)"}, {"id": "05_betrieb/17_Subunternehmer_Management.md", "title": "Subunternehmer- und Unterauftragsverarbeiter-Management", "section": "2. Compliance-Ergänzung zum Inventar (#48, #31)"}, {"id": "05_betrieb/17_Subunternehmer_Management.md", "title": "Subunternehmer- und Unterauftragsverarbeiter-Management", "section": "2. Compliance-Ergänzung zum Inventar (#48, #31)"}, {"id": "05_betrieb/17_Subunternehmer_Management.md", "title": "Subunternehmer- und Unterauftragsverarbeiter-Management", "section": "2. Compliance-Ergänzung zum Inventar (#48, #31)"}, {"id": "05_betrieb/17_Subunternehmer_Management.md", "title": "Subunternehmer- und Unterauftragsverarbeiter-Management", "section": "2. Compliance-Ergänzung zum Inventar (#48, #31)"}, {"id": "05_betrieb/17_Subunternehmer_Management.md", "title": "Subunternehmer- und Unterauftragsverarbeiter-Management", "section": "2. Compliance-Ergänzung zum Inventar (#48, #31)"}, {"id": "05_betrieb/17_Subunternehmer_Management.md", "title": "Subunternehmer- und Unterauftragsverarbeiter-Management", "section": "2. Compliance-Ergänzung zum Inventar (#48, #31)"}, {"id": "05_betrieb/17_Subunternehmer_Management.md", "title": "Subunternehmer- und Unterauftragsverarbeiter-Management", "section": "2. Compliance-Ergänzung zum Inventar (#48, #31)"}, {"id": "05_betrieb/17_Subunternehmer_Management.md", "title": "Subunternehmer- und Unterauftragsverarbeiter-Management", "section": "4. Weitergabe der Pflichten (#53)"}, {"id": "05_betrieb/17_Subunternehmer_Management.md", "title": "Subunternehmer- und Unterauftragsverarbeiter-Management", "section": "5. Sanktionsprüfung"}, {"id": "05_betrieb/17_Subunternehmer_Management.md", "title": "Subunternehmer- und Unterauftragsverarbeiter-Management", "section": "7. Stand der Umsetzung / Lücken"}, {"id": "05_betrieb/17_Subunternehmer_Management.md", "title": "Subunternehmer- und Unterauftragsverarbeiter-Management", "section": "7. Stand der Umsetzung / Lücken"}], "stats": {"docs": 47, "statusCounts": {"entwurf": 24, "unbekannt": 23}, "overdueReviews": 0, "openPendenzen": 13, "overduePendenzen": 0, "generated": "2026-06-11"}, "today": "2026-06-11"};</script>
 <script>
 const D = window.IMS_DATA;
 const byId = {}; D.docs.forEach(d => byId[d.id] = d);