From 8491c7f173a394a342723c3fae868dcae6b8ac5b Mon Sep 17 00:00:00 2001 From: Martin Date: Mon, 14 Sep 2026 11:35:44 +0200 Subject: [PATCH] Fundament: ISMS-Module entfernt; Craftvia-Rollen, Module, Navigation, i18n-Split MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit - ISMS-Routen, Actions, Server-/Lib-Code, Komponenten, Prisma-Modelle, Seeds, Importer, Skripte und ISMS-Tests entfernt (Fundament bleibt: Auth, Identity, MFA/WebAuthn, RBAC, Audit, Mail, Storage, Backup/DSGVO, Plattform-Admin) - Schema auf Fundament-Modelle reduziert; TenantSettings generisch (+phone/email) - TENANT_MODELS (db.ts, backup/topology.ts) und PII-Felder ausgedünnt - RBAC: Rollen tenant-admin/backoffice/team-lead/technician + Craftvia-Permissions - Modul-Katalog (customers, sites, teams, work_orders, imports, field, reports, emergency, documents, notifications, lotse) + Navigation aus src/lib/nav.ts - Modul-Routen mit requireModule-Layout und Platzhalterseite - Message-Katalog je Namespace (messages//.json), fs-Loader - check-module-guards: Modul-Key aus src/server/actions// - Provisionierung, Admin-Konsole, Einstellungen, Files-Route, Mail entkoppelt - Seed minimal (demo/demo2, Nutzer je Rolle); Fundament-Tests auf Role/ NotificationPreference-Fixtures umgestellt Co-Authored-By: Claude Opus 5 --- .../Contracts-Checkliste-Kickoff.md | 168 - .../Paket-DevA-Wizard-Scoping.md | 82 - .../Paket-DevB-Engines-Richtlinien.md | 100 - .../Berater-Anweisung-Fachcontent.md | 68 - .../Onboarding-Wizard-Machbarkeitsanalyse.md | 120 - .../01_Planung/Wizard-Entwickler-Backlog.md | 133 - .../01_Planung/Wizard-Stories.md | 174 - .../C0_README-Fachcontent-Uebersicht.md | 35 - .../C1_Scoping-AL-Pruefziel.md | 444 -- .../C2_Fragenkatalog-Wirkung.md | 110 - .../C3_Vorlagen-Annotation.md | 49 - .../02_Fachcontent_C1-C9/C4_Risikokatalog.md | 169 - .../02_Fachcontent_C1-C9/C5_Reifegradlogik.md | 199 - .../C6_Umsetzungshinweise.md | 3778 ------------ .../C7_Rollen-Funktionstrennung.md | 61 - .../C8_Priorisierung-Gap.md | 37 - .../C9_Auswertung-Export.md | 49 - .../Onboarding_Wizard_Fahrplan_Detail.md | 233 - .../03_Referenz/STAND-dev-branch.HINWEIS.md | 9 - docs/wizard-uebergabe/README.md | 20 - messages/de.json | 1136 ---- messages/de/admin.json | 58 + messages/de/common.json | 23 + messages/de/dashboard.json | 8 + messages/de/login.json | 11 + messages/de/modules.json | 18 + messages/de/nav.json | 12 + messages/en.json | 1136 ---- messages/en/admin.json | 58 + messages/en/common.json | 23 + messages/en/dashboard.json | 8 + messages/en/login.json | 11 + messages/en/modules.json | 18 + messages/en/nav.json | 12 + next.config.ts | 33 +- prisma/import-hints.ts | 82 - prisma/import-managed.ts | 222 - prisma/import-policies.ts | 521 -- prisma/import-process-catalog.ts | 256 - prisma/import-risks.ts | 63 - prisma/schema.prisma | 2306 +------ prisma/seed-content.ts | 60 - prisma/seed.ts | 783 +-- prisma/template-store.ts | 205 - scripts/backfill-risk-5x5.ts | 61 - scripts/build-c1-scope.ts | 63 - scripts/build-c5-controls.ts | 67 - scripts/check-module-guards.ts | 185 +- scripts/import-c6-hints.ts | 15 - scripts/import-risk-catalog.ts | 15 - scripts/incident-inbound-worker.ts | 205 - .../snapshots/framework-assessment-tisax.json | 1233 ---- scripts/sync-policy-templates.ts | 58 - scripts/test-action-error.ts | 4 +- scripts/test-action-guard-authz.ts | 4 +- scripts/test-assessment-iso.ts | 60 - scripts/test-backup-dsgvo.ts | 12 +- scripts/test-backup-portal.ts | 4 +- scripts/test-doc-control.ts | 73 - scripts/test-framework-assessment.ts | 103 - scripts/test-framework-core.ts | 93 - scripts/test-framework-dryrun.ts | 118 - scripts/test-framework-provision.ts | 106 - scripts/test-framework-templates.ts | 62 - scripts/test-framework-toggle.ts | 150 - scripts/test-ft-rules.ts | 60 - scripts/test-gap-consolidation.ts | 91 - scripts/test-incident-deadlines.ts | 205 - scripts/test-incident-inbound.ts | 179 - scripts/test-incident-links.ts | 212 - scripts/test-incidents.ts | 153 - scripts/test-mail.ts | 2 +- scripts/test-maturity.ts | 98 - scripts/test-readiness.ts | 56 - scripts/test-reimport.ts | 88 - scripts/test-review.ts | 78 - scripts/test-rls-enforcement.ts | 154 +- scripts/test-rules.ts | 102 - scripts/test-scope-filter.ts | 72 - scripts/test-soa.ts | 67 - scripts/test-tenant-isolation.ts | 85 +- scripts/test-tenant-users-authz.ts | 24 +- scripts/test-vda-isa.ts | 44 - .../Nachweisregister_zentral.md | 47 - .../Statement-of-Applicability-ISO.md | 135 - .../Technische-Sicherheits-Baseline.md | 113 - .../isms-vorlagenpaket-v2-en/mapping-iso.json | 2219 ------- seed/isms-vorlagenpaket-v2-en/mapping.json | 5351 ----------------- .../richtlinien/D01_Datenschutz.md | 49 - .../L00_Informationssicherheitsleitlinie.md | 175 - .../richtlinien/P01_Prototypenschutz.md | 60 - .../R01_ISMS-Organisation-und-Rollen.md | 294 - ...02_Asset-und-Klassifizierungsrichtlinie.md | 259 - ...03_Risikomanagement-und-Auditrichtlinie.md | 289 - ...ent-Notfall-und-Kontinuitaetsrichtlinie.md | 383 -- .../R05_Personalsicherheit-und-Awareness.md | 221 - ...R06_Mobiles-Arbeiten-und-mobile-Geraete.md | 151 - .../richtlinien/R07_Physische-Sicherheit.md | 173 - .../R08_Identitaets-und-Zugriffsmanagement.md | 314 - ...ryptografie-und-Uebertragungsrichtlinie.md | 156 - .../richtlinien/R10_Betriebssicherheit.md | 598 -- ...chere-Systembeschaffung-und-Entwicklung.md | 219 - .../R12_Cloud-KI-und-externe-IT-Dienste.md | 117 - ..._Lieferanten-und-Dienstleistersteuerung.md | 250 - .../R14_Compliance-und-Datenschutz.md | 129 - .../variables.schema.json | 379 -- ...01_Incident-Response-und-Meldeverfahren.md | 71 - ...02_IT-Notfall-und-Wiederanlaufverfahren.md | 72 - .../verfahren/VA-03_Berechtigungsverfahren.md | 71 - ...4_Change-und-Patch-Management-Verfahren.md | 71 - .../VA-05_Backup-und-Restore-Verfahren.md | 69 - ...A-06_Schwachstellenmanagement-Verfahren.md | 69 - ..._Kryptokonzept-und-Schluesselverwaltung.md | 69 - ...-08_Asset-und-Klassifizierungsverfahren.md | 69 - .../VA-09_Risikomanagement-Verfahren.md | 69 - ...10_Lieferanten-Onboarding-und-Bewertung.md | 69 - .../VA-11_Cloud-und-KI-Freigabeverfahren.md | 69 - .../VA-12_Awareness-und-Schulungsverfahren.md | 69 - .../VA-13_Logging-und-Monitoring-Verfahren.md | 69 - ...-14_Personalsicherheit-Eignungspruefung.md | 71 - ...Interne-Audits-und-Compliancepruefungen.md | 72 - ...ere-Beschaffung-Entwicklung-und-Abnahme.md | 72 - .../VA-17_Zutritts-und-Besuchermanagement.md | 67 - ...VA-18_Datenschutz-und-Compliance-Pflege.md | 66 - ...-19_Informationssicherheit-in-Projekten.md | 70 - .../VA-20_Prototypen-Zutritt-und-Transport.md | 38 - ...tkonformitaeten-und-Korrekturmassnahmen.md | 78 - ...A-22_Managementbewertung-und-Kennzahlen.md | 77 - .../00_Integrationsleitfaden_Wizard.md | 148 - .../ISA-Mapping-Matrix.md | 379 -- .../Nachweisregister_zentral.md | 47 - .../Statement-of-Applicability-ISO.md | 135 - .../Technische-Sicherheits-Baseline.md | 113 - seed/isms-vorlagenpaket-v2/_enrich.py | 168 - seed/isms-vorlagenpaket-v2/_fix.py | 21 - seed/isms-vorlagenpaket-v2/_generate_iso.py | 525 -- seed/isms-vorlagenpaket-v2/_generate_v2.py | 553 -- seed/isms-vorlagenpaket-v2/_generate_v3.py | 173 - .../_generate_verfahren.py | 295 - seed/isms-vorlagenpaket-v2/_isa_de.py | 656 -- .../isms-vorlagenpaket-v2/_iso_crosswalk.json | 1735 ------ seed/isms-vorlagenpaket-v2/_iso_sections.json | 81 - .../_iso_sections_en.json | 81 - seed/isms-vorlagenpaket-v2/_iso_texts_en.json | 485 -- seed/isms-vorlagenpaket-v2/_matrix.py | 36 - seed/isms-vorlagenpaket-v2/_render_diff.py | 79 - seed/isms-vorlagenpaket-v2/_verify.py | 62 - seed/isms-vorlagenpaket-v2/_verify_iso.py | 138 - seed/isms-vorlagenpaket-v2/mapping-iso.json | 2219 ------- seed/isms-vorlagenpaket-v2/mapping.json | 5351 ----------------- .../richtlinien/D01_Datenschutz.md | 49 - .../L00_Informationssicherheitsleitlinie.md | 175 - .../richtlinien/P01_Prototypenschutz.md | 60 - .../R01_ISMS-Organisation-und-Rollen.md | 294 - ...02_Asset-und-Klassifizierungsrichtlinie.md | 259 - ...03_Risikomanagement-und-Auditrichtlinie.md | 289 - ...ent-Notfall-und-Kontinuitaetsrichtlinie.md | 383 -- .../R05_Personalsicherheit-und-Awareness.md | 221 - ...R06_Mobiles-Arbeiten-und-mobile-Geraete.md | 151 - .../richtlinien/R07_Physische-Sicherheit.md | 173 - .../R08_Identitaets-und-Zugriffsmanagement.md | 314 - ...ryptografie-und-Uebertragungsrichtlinie.md | 156 - .../richtlinien/R10_Betriebssicherheit.md | 598 -- ...chere-Systembeschaffung-und-Entwicklung.md | 219 - .../R12_Cloud-KI-und-externe-IT-Dienste.md | 117 - ..._Lieferanten-und-Dienstleistersteuerung.md | 250 - .../R14_Compliance-und-Datenschutz.md | 129 - .../variables.schema.json | 379 -- ...01_Incident-Response-und-Meldeverfahren.md | 71 - ...02_IT-Notfall-und-Wiederanlaufverfahren.md | 72 - .../verfahren/VA-03_Berechtigungsverfahren.md | 71 - ...4_Change-und-Patch-Management-Verfahren.md | 71 - .../VA-05_Backup-und-Restore-Verfahren.md | 69 - ...A-06_Schwachstellenmanagement-Verfahren.md | 69 - ..._Kryptokonzept-und-Schluesselverwaltung.md | 69 - ...-08_Asset-und-Klassifizierungsverfahren.md | 69 - .../VA-09_Risikomanagement-Verfahren.md | 69 - ...10_Lieferanten-Onboarding-und-Bewertung.md | 69 - .../VA-11_Cloud-und-KI-Freigabeverfahren.md | 69 - .../VA-12_Awareness-und-Schulungsverfahren.md | 69 - .../VA-13_Logging-und-Monitoring-Verfahren.md | 69 - ...-14_Personalsicherheit-Eignungspruefung.md | 71 - ...Interne-Audits-und-Compliancepruefungen.md | 72 - ...ere-Beschaffung-Entwicklung-und-Abnahme.md | 72 - .../VA-17_Zutritts-und-Besuchermanagement.md | 67 - ...VA-18_Datenschutz-und-Compliance-Pflege.md | 66 - ...-19_Informationssicherheit-in-Projekten.md | 70 - .../VA-20_Prototypen-Zutritt-und-Transport.md | 38 - ...tkonformitaeten-und-Korrekturmassnahmen.md | 78 - ...A-22_Managementbewertung-und-Kennzahlen.md | 77 - seed/scoping/c1-scope.json | 3710 ------------ seed/scoping/c5-controls.json | 564 -- src/app/(app)/assets/[id]/edit/page.tsx | 11 - src/app/(app)/assets/[id]/page.tsx | 11 - src/app/(app)/assets/layout.tsx | 7 - src/app/(app)/assets/new/page.tsx | 6 - src/app/(app)/assets/page.tsx | 454 -- .../[auditId]/controls/page.tsx | 217 - .../audit-readiness/[auditId]/export/page.tsx | 90 - .../audit-readiness/[auditId]/layout.tsx | 63 - .../[auditId]/nachweise/page.tsx | 206 - .../[auditId]/nachweise/reassign-select.tsx | 36 - .../(app)/audit-readiness/[auditId]/page.tsx | 12 - .../[auditId]/readiness/page.tsx | 68 - .../audit-readiness/[auditId]/wizard-tabs.tsx | 44 - .../(app)/audit-readiness/audit-dialog.tsx | 186 - src/app/(app)/audit-readiness/export/route.ts | 57 - src/app/(app)/audit-readiness/layout.tsx | 16 - src/app/(app)/audit-readiness/page.tsx | 181 - .../(app)/audit-readiness/steps/gap/step.tsx | 112 - .../audit-readiness/steps/readiness/step.tsx | 148 - .../(app)/audit-readiness/summary/page.tsx | 109 - src/app/(app)/customers/layout.tsx | 7 + src/app/(app)/customers/page.tsx | 5 + src/app/(app)/dashboard/page.tsx | 215 +- src/app/(app)/dependencies/layout.tsx | 7 - src/app/(app)/dependencies/page.tsx | 132 - src/app/(app)/documents/layout.tsx | 7 + src/app/(app)/documents/page.tsx | 5 + src/app/(app)/files/[...key]/route.ts | 33 +- src/app/(app)/imports/layout.tsx | 7 + src/app/(app)/imports/page.tsx | 5 + src/app/(app)/incidents/export/route.ts | 97 - src/app/(app)/incidents/layout.tsx | 7 - src/app/(app)/incidents/page.tsx | 284 - src/app/(app)/layout.tsx | 131 +- src/app/(app)/m/(field)/layout.tsx | 7 + src/app/(app)/m/(field)/page.tsx | 5 + src/app/(app)/m/emergency/layout.tsx | 7 + src/app/(app)/m/emergency/page.tsx | 5 + src/app/(app)/measures/layout.tsx | 7 - src/app/(app)/measures/page.tsx | 133 - src/app/(app)/notifications/layout.tsx | 7 + src/app/(app)/notifications/page.tsx | 5 + src/app/(app)/onboarding/layout.tsx | 7 - src/app/(app)/onboarding/page.tsx | 250 - .../(app)/onboarding/steps/assets/step.tsx | 143 - .../(app)/onboarding/steps/context/step.tsx | 92 - .../(app)/onboarding/steps/controls/step.tsx | 201 - .../onboarding/steps/criteria/actions.ts | 115 - .../steps/criteria/criteria-edit-dialog.tsx | 48 - .../steps/criteria/criteria-editor.tsx | 301 - .../(app)/onboarding/steps/criteria/step.tsx | 148 - .../information/information-combobox.tsx | 257 - .../onboarding/steps/information/step.tsx | 117 - .../(app)/onboarding/steps/placeholder.tsx | 18 - .../(app)/onboarding/steps/policies/step.tsx | 139 - .../(app)/onboarding/steps/processes/step.tsx | 287 - .../onboarding/steps/protection/step.tsx | 136 - src/app/(app)/onboarding/steps/risks/step.tsx | 130 - .../(app)/onboarding/steps/roles/popup.tsx | 93 - .../steps/roles/role-edit-dialog.tsx | 179 - src/app/(app)/onboarding/steps/roles/step.tsx | 179 - .../(app)/onboarding/steps/scoping/step.tsx | 107 - src/app/(app)/policies/[code]/edit/page.tsx | 220 - src/app/(app)/policies/[code]/page.tsx | 120 - src/app/(app)/policies/control/page.tsx | 127 - src/app/(app)/policies/hints/page.tsx | 107 - src/app/(app)/policies/layout.tsx | 7 - src/app/(app)/policies/page.tsx | 389 -- src/app/(app)/policies/updates/page.tsx | 123 - src/app/(app)/policies/upload/page.tsx | 56 - src/app/(app)/processes/[id]/edit/page.tsx | 11 - src/app/(app)/processes/[id]/page.tsx | 11 - src/app/(app)/processes/layout.tsx | 7 - src/app/(app)/processes/new/page.tsx | 6 - src/app/(app)/processes/page.tsx | 537 -- src/app/(app)/reports/layout.tsx | 7 + src/app/(app)/reports/page.tsx | 5 + src/app/(app)/review/page.tsx | 234 - src/app/(app)/risks/catalog/page.tsx | 101 - src/app/(app)/risks/layout.tsx | 7 - src/app/(app)/risks/page.tsx | 290 - .../(app)/settings/incident-intake/page.tsx | 117 - src/app/(app)/settings/page.tsx | 104 +- src/app/(app)/settings/risk-criteria/page.tsx | 72 - src/app/(app)/sites/layout.tsx | 7 + src/app/(app)/sites/page.tsx | 5 + src/app/(app)/soa/export/route.ts | 117 - src/app/(app)/soa/page.tsx | 155 - src/app/(app)/suppliers/layout.tsx | 7 - src/app/(app)/suppliers/page.tsx | 327 - src/app/(app)/tasks/layout.tsx | 7 - src/app/(app)/tasks/page.tsx | 350 -- src/app/(app)/teams/layout.tsx | 7 + src/app/(app)/teams/page.tsx | 5 + src/app/(app)/work-orders/layout.tsx | 7 + src/app/(app)/work-orders/page.tsx | 5 + src/app/(platform)/admin/[id]/page.tsx | 180 +- src/app/(platform)/admin/page.tsx | 121 +- src/app/(platform)/layout.tsx | 5 +- .../templates/[locale]/[code]/page.tsx | 73 - .../templates/[locale]/requirements/page.tsx | 106 - .../templates/[locale]/variables/page.tsx | 114 - src/app/(platform)/templates/page.tsx | 195 - src/components/asset-form.tsx | 129 - src/components/asset-modals.tsx | 333 - src/components/audit-trail.tsx | 24 +- src/components/bia-popup.tsx | 735 --- src/components/dependency-graph.tsx | 344 -- src/components/filter-tabs.tsx | 28 - src/components/generic-register.tsx | 88 - src/components/incident-deadlines.tsx | 114 - src/components/incident-modals.tsx | 765 --- src/components/kanban-board.tsx | 218 - src/components/measure-modals.tsx | 275 - src/components/module-placeholder.tsx | 25 + src/components/object-review.tsx | 114 - src/components/policy-domain-view.tsx | 235 - src/components/policy-expert-editor.tsx | 126 - src/components/policy-modals.tsx | 116 - src/components/policy-registers.tsx | 411 -- src/components/process-form.tsx | 142 - src/components/process-modals.tsx | 927 --- src/components/project-modals.tsx | 277 - src/components/risk-modals.tsx | 849 --- src/components/role-manager.tsx | 26 +- src/components/segmented-rating.tsx | 67 - src/components/service-modals.tsx | 373 -- src/components/software-modals.tsx | 280 - src/components/supplier-cockpit.tsx | 217 - src/components/supplier-modals.tsx | 447 -- src/components/task-modals.tsx | 364 -- src/i18n/request.ts | 46 +- src/lib/assessment.ts | 102 - src/lib/asset-labels.ts | 34 - src/lib/audit-readiness/activation.ts | 23 - src/lib/control-domain.ts | 128 - src/lib/control-specs-iso.ts | 147 - src/lib/control-titles-iso.ts | 133 - src/lib/control-titles.ts | 79 - src/lib/export/vda-isa.ts | 145 - src/lib/ft-rules.ts | 114 - src/lib/gap-consolidation.ts | 165 - src/lib/incident-deadlines.ts | 278 - src/lib/incident-export.ts | 270 - src/lib/incident-report-html.ts | 232 - src/lib/incident-severity.ts | 60 - src/lib/incident.ts | 116 - src/lib/isa-controls.ts | 22 - src/lib/isb-bestellung.ts | 46 - src/lib/iso-isa-crosswalk.ts | 108 - src/lib/levels.ts | 13 - src/lib/maturity.ts | 217 - src/lib/measure.ts | 15 - src/lib/modules.ts | 62 +- src/lib/nav.ts | 65 + src/lib/normalize-asset.ts | 86 - src/lib/object-review.ts | 45 - src/lib/onboarding/facts.ts | 63 - src/lib/onboarding/functions.ts | 115 - src/lib/onboarding/questions.ts | 91 - src/lib/onboarding/register-steps.ts | 62 - src/lib/onboarding/registry.ts | 91 - src/lib/onboarding/state.ts | 70 - src/lib/policy-render.ts | 260 - src/lib/policy-titles.ts | 64 - src/lib/policy-variables.ts | 15 - src/lib/readiness.ts | 118 - src/lib/review-cycle.ts | 37 - src/lib/risk.ts | 37 - src/lib/rules/dsl.ts | 69 - src/lib/rules/engine.ts | 62 - src/lib/rules/feature-rules.ts | 141 - src/lib/scope-filter.ts | 78 - src/lib/soa.ts | 78 - src/lib/supplier-include.ts | 45 - src/lib/supplier.ts | 193 - src/lib/task-triggers.ts | 131 - src/lib/tasks.ts | 95 - src/server/action-error.ts | 6 +- src/server/action-guard.ts | 6 +- src/server/actions/admin.ts | 183 +- src/server/actions/assets.ts | 163 - src/server/actions/audit-evidence.ts | 314 - src/server/actions/audits.ts | 157 - src/server/actions/control-descriptions.ts | 124 - src/server/actions/gap.ts | 73 - src/server/actions/hints.ts | 34 - src/server/actions/incident-intake-admin.ts | 105 - src/server/actions/incident-intake.ts | 70 - src/server/actions/incidents.ts | 872 --- src/server/actions/measures.ts | 253 - src/server/actions/onboarding-facts.ts | 62 - src/server/actions/onboarding-steps.ts | 63 - src/server/actions/onboarding-team.ts | 210 - src/server/actions/onboarding.ts | 211 - src/server/actions/policies.ts | 320 - src/server/actions/policy-control.ts | 75 - src/server/actions/policy-package.ts | 54 - src/server/actions/policy-templates.ts | 313 - src/server/actions/policy-upload.ts | 186 - src/server/actions/processes.ts | 553 -- src/server/actions/projects.ts | 92 - src/server/actions/register.ts | 69 - src/server/actions/review.ts | 234 - src/server/actions/risk-catalog.ts | 242 - src/server/actions/risks.ts | 368 -- src/server/actions/services.ts | 126 - src/server/actions/soa-entries.ts | 52 - src/server/actions/soa.ts | 185 - src/server/actions/software.ts | 96 - src/server/actions/structure.ts | 446 -- src/server/actions/suppliers.ts | 299 - src/server/actions/tasks.ts | 643 -- src/server/actions/tenant-settings.ts | 40 +- src/server/ai/draft-control-description.ts | 127 - src/server/assessment-level.ts | 30 - src/server/assessment.ts | 136 - src/server/backup/topology.ts | 51 +- src/server/control-descriptions-context.ts | 145 - src/server/control-domain.ts | 201 - src/server/db.ts | 101 +- src/server/dependency-graph.ts | 284 - src/server/dsgvo/pii-fields.ts | 25 +- src/server/export-context.ts | 69 - src/server/export/incident-xlsx.ts | 37 - src/server/export/soa-xlsx.ts | 30 - src/server/export/vda-isa-xlsx.ts | 57 - src/server/gap-context.ts | 122 - src/server/incident-export-context.ts | 206 - src/server/incident-inbound/parse.ts | 210 - src/server/incident-inbound/process.ts | 135 - src/server/incident-inbound/route.ts | 144 - src/server/incident-refno.ts | 35 - src/server/iso-hints.ts | 80 - src/server/mail/incident-notifications.ts | 294 - src/server/mail/job.ts | 2 +- src/server/mail/notifications.ts | 161 +- src/server/mail/service.ts | 2 +- src/server/mail/templates.ts | 38 +- src/server/mail/worker.ts | 9 +- src/server/object-review.ts | 100 - src/server/policies/derive-domains.ts | 40 - src/server/provision.ts | 118 +- src/server/rbac.ts | 222 +- src/server/risk-calc.ts | 43 - src/server/roles.ts | 98 - src/server/soa-context.ts | 174 - src/server/soa-statement.ts | 114 - src/server/task-sync.ts | 186 - src/server/task-visibility.ts | 56 - types/mailparser.d.ts | 5 - 443 files changed, 1325 insertions(+), 87773 deletions(-) delete mode 100644 docs/wizard-uebergabe/00_Entwicklerpakete/Contracts-Checkliste-Kickoff.md delete mode 100644 docs/wizard-uebergabe/00_Entwicklerpakete/Paket-DevA-Wizard-Scoping.md delete mode 100644 docs/wizard-uebergabe/00_Entwicklerpakete/Paket-DevB-Engines-Richtlinien.md delete mode 100644 docs/wizard-uebergabe/01_Planung/Berater-Anweisung-Fachcontent.md delete mode 100644 docs/wizard-uebergabe/01_Planung/Onboarding-Wizard-Machbarkeitsanalyse.md delete mode 100644 docs/wizard-uebergabe/01_Planung/Wizard-Entwickler-Backlog.md delete mode 100644 docs/wizard-uebergabe/01_Planung/Wizard-Stories.md delete mode 100644 docs/wizard-uebergabe/02_Fachcontent_C1-C9/C0_README-Fachcontent-Uebersicht.md delete mode 100644 docs/wizard-uebergabe/02_Fachcontent_C1-C9/C1_Scoping-AL-Pruefziel.md delete mode 100644 docs/wizard-uebergabe/02_Fachcontent_C1-C9/C2_Fragenkatalog-Wirkung.md delete mode 100644 docs/wizard-uebergabe/02_Fachcontent_C1-C9/C3_Vorlagen-Annotation.md delete mode 100644 docs/wizard-uebergabe/02_Fachcontent_C1-C9/C4_Risikokatalog.md delete mode 100644 docs/wizard-uebergabe/02_Fachcontent_C1-C9/C5_Reifegradlogik.md delete mode 100644 docs/wizard-uebergabe/02_Fachcontent_C1-C9/C6_Umsetzungshinweise.md delete mode 100644 docs/wizard-uebergabe/02_Fachcontent_C1-C9/C7_Rollen-Funktionstrennung.md delete mode 100644 docs/wizard-uebergabe/02_Fachcontent_C1-C9/C8_Priorisierung-Gap.md delete mode 100644 docs/wizard-uebergabe/02_Fachcontent_C1-C9/C9_Auswertung-Export.md delete mode 100644 docs/wizard-uebergabe/03_Referenz/Onboarding_Wizard_Fahrplan_Detail.md delete mode 100644 docs/wizard-uebergabe/03_Referenz/STAND-dev-branch.HINWEIS.md delete mode 100644 docs/wizard-uebergabe/README.md delete mode 100644 messages/de.json create mode 100644 messages/de/admin.json create mode 100644 messages/de/common.json create mode 100644 messages/de/dashboard.json create mode 100644 messages/de/login.json create mode 100644 messages/de/modules.json create mode 100644 messages/de/nav.json delete mode 100644 messages/en.json create mode 100644 messages/en/admin.json create mode 100644 messages/en/common.json create mode 100644 messages/en/dashboard.json create mode 100644 messages/en/login.json create mode 100644 messages/en/modules.json create mode 100644 messages/en/nav.json delete mode 100644 prisma/import-hints.ts delete mode 100644 prisma/import-managed.ts delete mode 100644 prisma/import-policies.ts delete mode 100644 prisma/import-process-catalog.ts delete mode 100644 prisma/import-risks.ts delete mode 100644 prisma/seed-content.ts delete mode 100644 prisma/template-store.ts delete mode 100644 scripts/backfill-risk-5x5.ts delete mode 100644 scripts/build-c1-scope.ts delete mode 100644 scripts/build-c5-controls.ts delete mode 100644 scripts/import-c6-hints.ts delete mode 100644 scripts/import-risk-catalog.ts delete mode 100644 scripts/incident-inbound-worker.ts delete mode 100644 scripts/snapshots/framework-assessment-tisax.json delete mode 100644 scripts/sync-policy-templates.ts delete mode 100644 scripts/test-assessment-iso.ts delete mode 100644 scripts/test-doc-control.ts delete mode 100644 scripts/test-framework-assessment.ts delete mode 100644 scripts/test-framework-core.ts delete mode 100644 scripts/test-framework-dryrun.ts delete mode 100644 scripts/test-framework-provision.ts delete mode 100644 scripts/test-framework-templates.ts delete mode 100644 scripts/test-framework-toggle.ts delete mode 100644 scripts/test-ft-rules.ts delete mode 100644 scripts/test-gap-consolidation.ts delete mode 100644 scripts/test-incident-deadlines.ts delete mode 100644 scripts/test-incident-inbound.ts delete mode 100644 scripts/test-incident-links.ts delete mode 100644 scripts/test-incidents.ts delete mode 100644 scripts/test-maturity.ts delete mode 100644 scripts/test-readiness.ts delete mode 100644 scripts/test-reimport.ts delete mode 100644 scripts/test-review.ts delete mode 100644 scripts/test-rules.ts delete mode 100644 scripts/test-scope-filter.ts delete mode 100644 scripts/test-soa.ts delete mode 100644 scripts/test-vda-isa.ts delete mode 100644 seed/isms-vorlagenpaket-v2-en/Nachweisregister_zentral.md delete mode 100644 seed/isms-vorlagenpaket-v2-en/Statement-of-Applicability-ISO.md delete mode 100644 seed/isms-vorlagenpaket-v2-en/Technische-Sicherheits-Baseline.md delete mode 100644 seed/isms-vorlagenpaket-v2-en/mapping-iso.json delete mode 100644 seed/isms-vorlagenpaket-v2-en/mapping.json delete mode 100644 seed/isms-vorlagenpaket-v2-en/richtlinien/D01_Datenschutz.md delete mode 100644 seed/isms-vorlagenpaket-v2-en/richtlinien/L00_Informationssicherheitsleitlinie.md delete mode 100644 seed/isms-vorlagenpaket-v2-en/richtlinien/P01_Prototypenschutz.md delete mode 100644 seed/isms-vorlagenpaket-v2-en/richtlinien/R01_ISMS-Organisation-und-Rollen.md delete mode 100644 seed/isms-vorlagenpaket-v2-en/richtlinien/R02_Asset-und-Klassifizierungsrichtlinie.md delete mode 100644 seed/isms-vorlagenpaket-v2-en/richtlinien/R03_Risikomanagement-und-Auditrichtlinie.md delete mode 100644 seed/isms-vorlagenpaket-v2-en/richtlinien/R04_Incident-Notfall-und-Kontinuitaetsrichtlinie.md delete mode 100644 seed/isms-vorlagenpaket-v2-en/richtlinien/R05_Personalsicherheit-und-Awareness.md delete mode 100644 seed/isms-vorlagenpaket-v2-en/richtlinien/R06_Mobiles-Arbeiten-und-mobile-Geraete.md delete mode 100644 seed/isms-vorlagenpaket-v2-en/richtlinien/R07_Physische-Sicherheit.md delete mode 100644 seed/isms-vorlagenpaket-v2-en/richtlinien/R08_Identitaets-und-Zugriffsmanagement.md delete mode 100644 seed/isms-vorlagenpaket-v2-en/richtlinien/R09_Kryptografie-und-Uebertragungsrichtlinie.md delete mode 100644 seed/isms-vorlagenpaket-v2-en/richtlinien/R10_Betriebssicherheit.md delete mode 100644 seed/isms-vorlagenpaket-v2-en/richtlinien/R11_Sichere-Systembeschaffung-und-Entwicklung.md delete mode 100644 seed/isms-vorlagenpaket-v2-en/richtlinien/R12_Cloud-KI-und-externe-IT-Dienste.md delete mode 100644 seed/isms-vorlagenpaket-v2-en/richtlinien/R13_Lieferanten-und-Dienstleistersteuerung.md delete mode 100644 seed/isms-vorlagenpaket-v2-en/richtlinien/R14_Compliance-und-Datenschutz.md delete mode 100644 seed/isms-vorlagenpaket-v2-en/variables.schema.json delete mode 100644 seed/isms-vorlagenpaket-v2-en/verfahren/VA-01_Incident-Response-und-Meldeverfahren.md delete mode 100644 seed/isms-vorlagenpaket-v2-en/verfahren/VA-02_IT-Notfall-und-Wiederanlaufverfahren.md delete mode 100644 seed/isms-vorlagenpaket-v2-en/verfahren/VA-03_Berechtigungsverfahren.md delete mode 100644 seed/isms-vorlagenpaket-v2-en/verfahren/VA-04_Change-und-Patch-Management-Verfahren.md delete mode 100644 seed/isms-vorlagenpaket-v2-en/verfahren/VA-05_Backup-und-Restore-Verfahren.md delete mode 100644 seed/isms-vorlagenpaket-v2-en/verfahren/VA-06_Schwachstellenmanagement-Verfahren.md delete mode 100644 seed/isms-vorlagenpaket-v2-en/verfahren/VA-07_Kryptokonzept-und-Schluesselverwaltung.md delete mode 100644 seed/isms-vorlagenpaket-v2-en/verfahren/VA-08_Asset-und-Klassifizierungsverfahren.md delete mode 100644 seed/isms-vorlagenpaket-v2-en/verfahren/VA-09_Risikomanagement-Verfahren.md delete mode 100644 seed/isms-vorlagenpaket-v2-en/verfahren/VA-10_Lieferanten-Onboarding-und-Bewertung.md delete mode 100644 seed/isms-vorlagenpaket-v2-en/verfahren/VA-11_Cloud-und-KI-Freigabeverfahren.md delete mode 100644 seed/isms-vorlagenpaket-v2-en/verfahren/VA-12_Awareness-und-Schulungsverfahren.md delete mode 100644 seed/isms-vorlagenpaket-v2-en/verfahren/VA-13_Logging-und-Monitoring-Verfahren.md delete mode 100644 seed/isms-vorlagenpaket-v2-en/verfahren/VA-14_Personalsicherheit-Eignungspruefung.md delete mode 100644 seed/isms-vorlagenpaket-v2-en/verfahren/VA-15_Interne-Audits-und-Compliancepruefungen.md delete mode 100644 seed/isms-vorlagenpaket-v2-en/verfahren/VA-16_Sichere-Beschaffung-Entwicklung-und-Abnahme.md delete mode 100644 seed/isms-vorlagenpaket-v2-en/verfahren/VA-17_Zutritts-und-Besuchermanagement.md delete mode 100644 seed/isms-vorlagenpaket-v2-en/verfahren/VA-18_Datenschutz-und-Compliance-Pflege.md delete mode 100644 seed/isms-vorlagenpaket-v2-en/verfahren/VA-19_Informationssicherheit-in-Projekten.md delete mode 100644 seed/isms-vorlagenpaket-v2-en/verfahren/VA-20_Prototypen-Zutritt-und-Transport.md delete mode 100644 seed/isms-vorlagenpaket-v2-en/verfahren/VA-21_Nichtkonformitaeten-und-Korrekturmassnahmen.md delete mode 100644 seed/isms-vorlagenpaket-v2-en/verfahren/VA-22_Managementbewertung-und-Kennzahlen.md delete mode 100644 seed/isms-vorlagenpaket-v2/00_Integrationsleitfaden_Wizard.md delete mode 100644 seed/isms-vorlagenpaket-v2/ISA-Mapping-Matrix.md delete mode 100644 seed/isms-vorlagenpaket-v2/Nachweisregister_zentral.md delete mode 100644 seed/isms-vorlagenpaket-v2/Statement-of-Applicability-ISO.md delete mode 100644 seed/isms-vorlagenpaket-v2/Technische-Sicherheits-Baseline.md delete mode 100644 seed/isms-vorlagenpaket-v2/_enrich.py delete mode 100644 seed/isms-vorlagenpaket-v2/_fix.py delete mode 100644 seed/isms-vorlagenpaket-v2/_generate_iso.py delete mode 100644 seed/isms-vorlagenpaket-v2/_generate_v2.py delete mode 100644 seed/isms-vorlagenpaket-v2/_generate_v3.py delete mode 100644 seed/isms-vorlagenpaket-v2/_generate_verfahren.py delete mode 100644 seed/isms-vorlagenpaket-v2/_isa_de.py delete mode 100644 seed/isms-vorlagenpaket-v2/_iso_crosswalk.json delete mode 100644 seed/isms-vorlagenpaket-v2/_iso_sections.json delete mode 100644 seed/isms-vorlagenpaket-v2/_iso_sections_en.json delete mode 100644 seed/isms-vorlagenpaket-v2/_iso_texts_en.json delete mode 100644 seed/isms-vorlagenpaket-v2/_matrix.py delete mode 100644 seed/isms-vorlagenpaket-v2/_render_diff.py delete mode 100644 seed/isms-vorlagenpaket-v2/_verify.py delete mode 100644 seed/isms-vorlagenpaket-v2/_verify_iso.py delete mode 100644 seed/isms-vorlagenpaket-v2/mapping-iso.json delete mode 100644 seed/isms-vorlagenpaket-v2/mapping.json delete mode 100644 seed/isms-vorlagenpaket-v2/richtlinien/D01_Datenschutz.md delete mode 100644 seed/isms-vorlagenpaket-v2/richtlinien/L00_Informationssicherheitsleitlinie.md delete mode 100644 seed/isms-vorlagenpaket-v2/richtlinien/P01_Prototypenschutz.md delete mode 100644 seed/isms-vorlagenpaket-v2/richtlinien/R01_ISMS-Organisation-und-Rollen.md delete mode 100644 seed/isms-vorlagenpaket-v2/richtlinien/R02_Asset-und-Klassifizierungsrichtlinie.md delete mode 100644 seed/isms-vorlagenpaket-v2/richtlinien/R03_Risikomanagement-und-Auditrichtlinie.md delete mode 100644 seed/isms-vorlagenpaket-v2/richtlinien/R04_Incident-Notfall-und-Kontinuitaetsrichtlinie.md delete mode 100644 seed/isms-vorlagenpaket-v2/richtlinien/R05_Personalsicherheit-und-Awareness.md delete mode 100644 seed/isms-vorlagenpaket-v2/richtlinien/R06_Mobiles-Arbeiten-und-mobile-Geraete.md delete mode 100644 seed/isms-vorlagenpaket-v2/richtlinien/R07_Physische-Sicherheit.md delete mode 100644 seed/isms-vorlagenpaket-v2/richtlinien/R08_Identitaets-und-Zugriffsmanagement.md delete mode 100644 seed/isms-vorlagenpaket-v2/richtlinien/R09_Kryptografie-und-Uebertragungsrichtlinie.md delete mode 100644 seed/isms-vorlagenpaket-v2/richtlinien/R10_Betriebssicherheit.md delete mode 100644 seed/isms-vorlagenpaket-v2/richtlinien/R11_Sichere-Systembeschaffung-und-Entwicklung.md delete mode 100644 seed/isms-vorlagenpaket-v2/richtlinien/R12_Cloud-KI-und-externe-IT-Dienste.md delete mode 100644 seed/isms-vorlagenpaket-v2/richtlinien/R13_Lieferanten-und-Dienstleistersteuerung.md delete mode 100644 seed/isms-vorlagenpaket-v2/richtlinien/R14_Compliance-und-Datenschutz.md delete mode 100644 seed/isms-vorlagenpaket-v2/variables.schema.json delete mode 100644 seed/isms-vorlagenpaket-v2/verfahren/VA-01_Incident-Response-und-Meldeverfahren.md delete mode 100644 seed/isms-vorlagenpaket-v2/verfahren/VA-02_IT-Notfall-und-Wiederanlaufverfahren.md delete mode 100644 seed/isms-vorlagenpaket-v2/verfahren/VA-03_Berechtigungsverfahren.md delete mode 100644 seed/isms-vorlagenpaket-v2/verfahren/VA-04_Change-und-Patch-Management-Verfahren.md delete mode 100644 seed/isms-vorlagenpaket-v2/verfahren/VA-05_Backup-und-Restore-Verfahren.md delete mode 100644 seed/isms-vorlagenpaket-v2/verfahren/VA-06_Schwachstellenmanagement-Verfahren.md delete mode 100644 seed/isms-vorlagenpaket-v2/verfahren/VA-07_Kryptokonzept-und-Schluesselverwaltung.md delete mode 100644 seed/isms-vorlagenpaket-v2/verfahren/VA-08_Asset-und-Klassifizierungsverfahren.md delete mode 100644 seed/isms-vorlagenpaket-v2/verfahren/VA-09_Risikomanagement-Verfahren.md delete mode 100644 seed/isms-vorlagenpaket-v2/verfahren/VA-10_Lieferanten-Onboarding-und-Bewertung.md delete mode 100644 seed/isms-vorlagenpaket-v2/verfahren/VA-11_Cloud-und-KI-Freigabeverfahren.md delete mode 100644 seed/isms-vorlagenpaket-v2/verfahren/VA-12_Awareness-und-Schulungsverfahren.md delete mode 100644 seed/isms-vorlagenpaket-v2/verfahren/VA-13_Logging-und-Monitoring-Verfahren.md delete mode 100644 seed/isms-vorlagenpaket-v2/verfahren/VA-14_Personalsicherheit-Eignungspruefung.md delete mode 100644 seed/isms-vorlagenpaket-v2/verfahren/VA-15_Interne-Audits-und-Compliancepruefungen.md delete mode 100644 seed/isms-vorlagenpaket-v2/verfahren/VA-16_Sichere-Beschaffung-Entwicklung-und-Abnahme.md delete mode 100644 seed/isms-vorlagenpaket-v2/verfahren/VA-17_Zutritts-und-Besuchermanagement.md delete mode 100644 seed/isms-vorlagenpaket-v2/verfahren/VA-18_Datenschutz-und-Compliance-Pflege.md delete mode 100644 seed/isms-vorlagenpaket-v2/verfahren/VA-19_Informationssicherheit-in-Projekten.md delete mode 100644 seed/isms-vorlagenpaket-v2/verfahren/VA-20_Prototypen-Zutritt-und-Transport.md delete mode 100644 seed/isms-vorlagenpaket-v2/verfahren/VA-21_Nichtkonformitaeten-und-Korrekturmassnahmen.md delete mode 100644 seed/isms-vorlagenpaket-v2/verfahren/VA-22_Managementbewertung-und-Kennzahlen.md delete mode 100644 seed/scoping/c1-scope.json delete mode 100644 seed/scoping/c5-controls.json delete mode 100644 src/app/(app)/assets/[id]/edit/page.tsx delete mode 100644 src/app/(app)/assets/[id]/page.tsx delete mode 100644 src/app/(app)/assets/layout.tsx delete mode 100644 src/app/(app)/assets/new/page.tsx delete mode 100644 src/app/(app)/assets/page.tsx delete mode 100644 src/app/(app)/audit-readiness/[auditId]/controls/page.tsx delete mode 100644 src/app/(app)/audit-readiness/[auditId]/export/page.tsx delete mode 100644 src/app/(app)/audit-readiness/[auditId]/layout.tsx delete mode 100644 src/app/(app)/audit-readiness/[auditId]/nachweise/page.tsx delete mode 100644 src/app/(app)/audit-readiness/[auditId]/nachweise/reassign-select.tsx delete mode 100644 src/app/(app)/audit-readiness/[auditId]/page.tsx delete mode 100644 src/app/(app)/audit-readiness/[auditId]/readiness/page.tsx delete mode 100644 src/app/(app)/audit-readiness/[auditId]/wizard-tabs.tsx delete mode 100644 src/app/(app)/audit-readiness/audit-dialog.tsx delete mode 100644 src/app/(app)/audit-readiness/export/route.ts delete mode 100644 src/app/(app)/audit-readiness/layout.tsx delete mode 100644 src/app/(app)/audit-readiness/page.tsx delete mode 100644 src/app/(app)/audit-readiness/steps/gap/step.tsx delete mode 100644 src/app/(app)/audit-readiness/steps/readiness/step.tsx delete mode 100644 src/app/(app)/audit-readiness/summary/page.tsx create mode 100644 src/app/(app)/customers/layout.tsx create mode 100644 src/app/(app)/customers/page.tsx delete mode 100644 src/app/(app)/dependencies/layout.tsx delete mode 100644 src/app/(app)/dependencies/page.tsx create mode 100644 src/app/(app)/documents/layout.tsx create mode 100644 src/app/(app)/documents/page.tsx create mode 100644 src/app/(app)/imports/layout.tsx create mode 100644 src/app/(app)/imports/page.tsx delete mode 100644 src/app/(app)/incidents/export/route.ts delete mode 100644 src/app/(app)/incidents/layout.tsx delete mode 100644 src/app/(app)/incidents/page.tsx create mode 100644 src/app/(app)/m/(field)/layout.tsx create mode 100644 src/app/(app)/m/(field)/page.tsx create mode 100644 src/app/(app)/m/emergency/layout.tsx create mode 100644 src/app/(app)/m/emergency/page.tsx delete mode 100644 src/app/(app)/measures/layout.tsx delete mode 100644 src/app/(app)/measures/page.tsx create mode 100644 src/app/(app)/notifications/layout.tsx create mode 100644 src/app/(app)/notifications/page.tsx delete mode 100644 src/app/(app)/onboarding/layout.tsx delete mode 100644 src/app/(app)/onboarding/page.tsx delete mode 100644 src/app/(app)/onboarding/steps/assets/step.tsx delete mode 100644 src/app/(app)/onboarding/steps/context/step.tsx delete mode 100644 src/app/(app)/onboarding/steps/controls/step.tsx delete mode 100644 src/app/(app)/onboarding/steps/criteria/actions.ts delete mode 100644 src/app/(app)/onboarding/steps/criteria/criteria-edit-dialog.tsx delete mode 100644 src/app/(app)/onboarding/steps/criteria/criteria-editor.tsx delete mode 100644 src/app/(app)/onboarding/steps/criteria/step.tsx delete mode 100644 src/app/(app)/onboarding/steps/information/information-combobox.tsx delete mode 100644 src/app/(app)/onboarding/steps/information/step.tsx delete mode 100644 src/app/(app)/onboarding/steps/placeholder.tsx delete mode 100644 src/app/(app)/onboarding/steps/policies/step.tsx delete mode 100644 src/app/(app)/onboarding/steps/processes/step.tsx delete mode 100644 src/app/(app)/onboarding/steps/protection/step.tsx delete mode 100644 src/app/(app)/onboarding/steps/risks/step.tsx delete mode 100644 src/app/(app)/onboarding/steps/roles/popup.tsx delete mode 100644 src/app/(app)/onboarding/steps/roles/role-edit-dialog.tsx delete mode 100644 src/app/(app)/onboarding/steps/roles/step.tsx delete mode 100644 src/app/(app)/onboarding/steps/scoping/step.tsx delete mode 100644 src/app/(app)/policies/[code]/edit/page.tsx delete mode 100644 src/app/(app)/policies/[code]/page.tsx delete mode 100644 src/app/(app)/policies/control/page.tsx delete mode 100644 src/app/(app)/policies/hints/page.tsx delete mode 100644 src/app/(app)/policies/layout.tsx delete mode 100644 src/app/(app)/policies/page.tsx delete mode 100644 src/app/(app)/policies/updates/page.tsx delete mode 100644 src/app/(app)/policies/upload/page.tsx delete mode 100644 src/app/(app)/processes/[id]/edit/page.tsx delete mode 100644 src/app/(app)/processes/[id]/page.tsx delete mode 100644 src/app/(app)/processes/layout.tsx delete mode 100644 src/app/(app)/processes/new/page.tsx delete mode 100644 src/app/(app)/processes/page.tsx create mode 100644 src/app/(app)/reports/layout.tsx create mode 100644 src/app/(app)/reports/page.tsx delete mode 100644 src/app/(app)/review/page.tsx delete mode 100644 src/app/(app)/risks/catalog/page.tsx delete mode 100644 src/app/(app)/risks/layout.tsx delete mode 100644 src/app/(app)/risks/page.tsx delete mode 100644 src/app/(app)/settings/incident-intake/page.tsx delete mode 100644 src/app/(app)/settings/risk-criteria/page.tsx create mode 100644 src/app/(app)/sites/layout.tsx create mode 100644 src/app/(app)/sites/page.tsx delete mode 100644 src/app/(app)/soa/export/route.ts delete mode 100644 src/app/(app)/soa/page.tsx delete mode 100644 src/app/(app)/suppliers/layout.tsx delete mode 100644 src/app/(app)/suppliers/page.tsx delete mode 100644 src/app/(app)/tasks/layout.tsx delete mode 100644 src/app/(app)/tasks/page.tsx create mode 100644 src/app/(app)/teams/layout.tsx create mode 100644 src/app/(app)/teams/page.tsx create mode 100644 src/app/(app)/work-orders/layout.tsx create mode 100644 src/app/(app)/work-orders/page.tsx delete mode 100644 src/app/(platform)/templates/[locale]/[code]/page.tsx delete mode 100644 src/app/(platform)/templates/[locale]/requirements/page.tsx delete mode 100644 src/app/(platform)/templates/[locale]/variables/page.tsx delete mode 100644 src/app/(platform)/templates/page.tsx delete mode 100644 src/components/asset-form.tsx delete mode 100644 src/components/asset-modals.tsx delete mode 100644 src/components/bia-popup.tsx delete mode 100644 src/components/dependency-graph.tsx delete mode 100644 src/components/filter-tabs.tsx delete mode 100644 src/components/generic-register.tsx delete mode 100644 src/components/incident-deadlines.tsx delete mode 100644 src/components/incident-modals.tsx delete mode 100644 src/components/kanban-board.tsx delete mode 100644 src/components/measure-modals.tsx create mode 100644 src/components/module-placeholder.tsx delete mode 100644 src/components/object-review.tsx delete mode 100644 src/components/policy-domain-view.tsx delete mode 100644 src/components/policy-expert-editor.tsx delete mode 100644 src/components/policy-modals.tsx delete mode 100644 src/components/policy-registers.tsx delete mode 100644 src/components/process-form.tsx delete mode 100644 src/components/process-modals.tsx delete mode 100644 src/components/project-modals.tsx delete mode 100644 src/components/risk-modals.tsx delete mode 100644 src/components/segmented-rating.tsx delete mode 100644 src/components/service-modals.tsx delete mode 100644 src/components/software-modals.tsx delete mode 100644 src/components/supplier-cockpit.tsx delete mode 100644 src/components/supplier-modals.tsx delete mode 100644 src/components/task-modals.tsx delete mode 100644 src/lib/assessment.ts delete mode 100644 src/lib/asset-labels.ts delete mode 100644 src/lib/audit-readiness/activation.ts delete mode 100644 src/lib/control-domain.ts delete mode 100644 src/lib/control-specs-iso.ts delete mode 100644 src/lib/control-titles-iso.ts delete mode 100644 src/lib/control-titles.ts delete mode 100644 src/lib/export/vda-isa.ts delete mode 100644 src/lib/ft-rules.ts delete mode 100644 src/lib/gap-consolidation.ts delete mode 100644 src/lib/incident-deadlines.ts delete mode 100644 src/lib/incident-export.ts delete mode 100644 src/lib/incident-report-html.ts delete mode 100644 src/lib/incident-severity.ts delete mode 100644 src/lib/incident.ts delete mode 100644 src/lib/isa-controls.ts delete mode 100644 src/lib/isb-bestellung.ts delete mode 100644 src/lib/iso-isa-crosswalk.ts delete mode 100644 src/lib/levels.ts delete mode 100644 src/lib/maturity.ts delete mode 100644 src/lib/measure.ts create mode 100644 src/lib/nav.ts delete mode 100644 src/lib/normalize-asset.ts delete mode 100644 src/lib/object-review.ts delete mode 100644 src/lib/onboarding/facts.ts delete mode 100644 src/lib/onboarding/functions.ts delete mode 100644 src/lib/onboarding/questions.ts delete mode 100644 src/lib/onboarding/register-steps.ts delete mode 100644 src/lib/onboarding/registry.ts delete mode 100644 src/lib/onboarding/state.ts delete mode 100644 src/lib/policy-render.ts delete mode 100644 src/lib/policy-titles.ts delete mode 100644 src/lib/policy-variables.ts delete mode 100644 src/lib/readiness.ts delete mode 100644 src/lib/review-cycle.ts delete mode 100644 src/lib/risk.ts delete mode 100644 src/lib/rules/dsl.ts delete mode 100644 src/lib/rules/engine.ts delete mode 100644 src/lib/rules/feature-rules.ts delete mode 100644 src/lib/scope-filter.ts delete mode 100644 src/lib/soa.ts delete mode 100644 src/lib/supplier-include.ts delete mode 100644 src/lib/supplier.ts delete mode 100644 src/lib/task-triggers.ts delete mode 100644 src/lib/tasks.ts delete mode 100644 src/server/actions/assets.ts delete mode 100644 src/server/actions/audit-evidence.ts delete mode 100644 src/server/actions/audits.ts delete mode 100644 src/server/actions/control-descriptions.ts delete mode 100644 src/server/actions/gap.ts delete mode 100644 src/server/actions/hints.ts delete mode 100644 src/server/actions/incident-intake-admin.ts delete mode 100644 src/server/actions/incident-intake.ts delete mode 100644 src/server/actions/incidents.ts delete mode 100644 src/server/actions/measures.ts delete mode 100644 src/server/actions/onboarding-facts.ts delete mode 100644 src/server/actions/onboarding-steps.ts delete mode 100644 src/server/actions/onboarding-team.ts delete mode 100644 src/server/actions/onboarding.ts delete mode 100644 src/server/actions/policies.ts delete mode 100644 src/server/actions/policy-control.ts delete mode 100644 src/server/actions/policy-package.ts delete mode 100644 src/server/actions/policy-templates.ts delete mode 100644 src/server/actions/policy-upload.ts delete mode 100644 src/server/actions/processes.ts delete mode 100644 src/server/actions/projects.ts delete mode 100644 src/server/actions/register.ts delete mode 100644 src/server/actions/review.ts delete mode 100644 src/server/actions/risk-catalog.ts delete mode 100644 src/server/actions/risks.ts delete mode 100644 src/server/actions/services.ts delete mode 100644 src/server/actions/soa-entries.ts delete mode 100644 src/server/actions/soa.ts delete mode 100644 src/server/actions/software.ts delete mode 100644 src/server/actions/structure.ts delete mode 100644 src/server/actions/suppliers.ts delete mode 100644 src/server/actions/tasks.ts delete mode 100644 src/server/ai/draft-control-description.ts delete mode 100644 src/server/assessment-level.ts delete mode 100644 src/server/assessment.ts delete mode 100644 src/server/control-descriptions-context.ts delete mode 100644 src/server/control-domain.ts delete mode 100644 src/server/dependency-graph.ts delete mode 100644 src/server/export-context.ts delete mode 100644 src/server/export/incident-xlsx.ts delete mode 100644 src/server/export/soa-xlsx.ts delete mode 100644 src/server/export/vda-isa-xlsx.ts delete mode 100644 src/server/gap-context.ts delete mode 100644 src/server/incident-export-context.ts delete mode 100644 src/server/incident-inbound/parse.ts delete mode 100644 src/server/incident-inbound/process.ts delete mode 100644 src/server/incident-inbound/route.ts delete mode 100644 src/server/incident-refno.ts delete mode 100644 src/server/iso-hints.ts delete mode 100644 src/server/mail/incident-notifications.ts delete mode 100644 src/server/object-review.ts delete mode 100644 src/server/policies/derive-domains.ts delete mode 100644 src/server/risk-calc.ts delete mode 100644 src/server/roles.ts delete mode 100644 src/server/soa-context.ts delete mode 100644 src/server/soa-statement.ts delete mode 100644 src/server/task-sync.ts delete mode 100644 src/server/task-visibility.ts delete mode 100644 types/mailparser.d.ts diff --git a/docs/wizard-uebergabe/00_Entwicklerpakete/Contracts-Checkliste-Kickoff.md b/docs/wizard-uebergabe/00_Entwicklerpakete/Contracts-Checkliste-Kickoff.md deleted file mode 100644 index a5de6ff..0000000 --- a/docs/wizard-uebergabe/00_Entwicklerpakete/Contracts-Checkliste-Kickoff.md +++ /dev/null @@ -1,168 +0,0 @@ -# Contracts-Checkliste — Kickoff Dev A × Dev B (15 Min.) - -> Zweck: Die Naht zwischen **Paket Dev A** (Wizard-Shell/Scoping/AL) und **Paket Dev B** -> (Engines/Fragebogen/Richtlinien) **einmal gemeinsam bestätigen**, bevor beide parallel starten. -> Grundlage: der identische *Contracts-Anhang* §1–§6 in beiden Entwicklerpaketen. -> Vorgehen: Punkt für Punkt durchgehen, abhaken, offene Entscheidungen unten eintragen, beide signieren. -> Danach laufen A und B konfliktarm parallel — einzige echte Nahtstellen sind -> `prisma/schema.prisma`, `scripts/check-module-guards.ts` und die Step-Registry. - -**Basis-Branch:** `dev` · **Feature-Branches:** `dev/a*-…` (A) bzw. `dev/b*-…` (B) · **PR-Ziel:** `dev` -Kein Push durch die Agenten; häufig auf `dev` rebasen; kleine PRs je Story. - ---- - -## §1 Task-Objekt — **Owner: Dev B** (A konsumiert) - -Dev B besitzt das Modell + `createTask`-Action; Dev A / Wizard-Gates rufen sie auf. - -- [ ] `type`: `document_create | evidence_provide | technical | organizational | validation | policy_approval` -- [ ] Felder: `owner`, `dueDate`, `priority: 'hoch'|'mittel'|'niedrig'`, `status` -- [ ] `resources` (JSON): `{ tool, budget, personnel, time }` -- [ ] `origin` (Herkunft/Trigger) vorhanden -- [ ] `links` (polymorph): `{ control?, risk?, document?, asset? }` -- [ ] Bestehender `policy_approval`-Flow bleibt unverändert lauffähig (Regression grün) -- [ ] **Signatur der `createTask`-Action steht fix**, bevor A ihre Gates verdrahtet - → Signatur hier notieren: `_____________________________________________` - -## §2 Validierungsstatus — **Owner: Dev A** (B konsumiert) - -- [ ] `enum ObjectReviewStatus { offen, in_bearbeitung, zur_validierung, validiert, zurueckgewiesen }` -- [ ] Zusatzfelder: `reviewComment`, `reviewerId` -- [ ] Regel bestätigt: **„Nur `validiert` zählt als bestätigt."** -- [ ] RBAC-Recht `validate_objects` + Rolle `external_validator` (klonbar) angelegt -- [ ] Feld-Konvention (an welchen Objekten der Status hängt) für Wizard-Gates fix - -## §3 Flags in `variables.schema.json` — **Owner: Dev B** (Namen fix, A entwickelt dagegen) - -- [ ] Namen unverändert übernommen (keine Umbenennung ohne beidseitige Abstimmung): - `FLAG_INCLUDE_SHOULD, FLAG_HIGH_PROTECTION, FLAG_VERY_HIGH_PROTECTION, - FLAG_ELEVATED_PROTECTION, FLAG_PERSONAL_DATA, FLAG_PROTOTYPE_PROTECTION, - FLAG_CLOUD_USED, FLAG_AI_USED, FLAG_OT_USED, FLAG_DEV_INHOUSE, FLAG_MOBILE_WORK, - FLAG_MOBILE_DEVICES, FLAG_CRYPTO_PKI, FLAG_EXTERNAL_IT, FLAG_CUSTOMER_SYSTEMS, - FLAG_ISB_EXTERNAL, FLAG_ISB_INTERNAL` -- [ ] `FLAG_ELEVATED_PROTECTION` bleibt **abgeleitet** (`applyProtection`) — nie manuell setzen -- [ ] Nach Schema-Änderung: `python3 seed/isms-vorlagenpaket-v2/_verify.py` → **OK** - -## §4 Prüfziele — beidseitig fix - -- [ ] Werte: `informationssicherheit | prototypenschutz | datenschutz` -- [ ] Wirkung bestätigt: Kapitel `8.x` nur bei Prototyp, `9.x` nur bei Datenschutz - -## §5 Step-Registry — **Owner: Dev A** (B konsumiert) - -- [ ] Signatur fix: `registerStep({ key, title, order, guard, component })` -- [ ] Schritt-Keys/Reihenfolge: - `1 scoping · 2 context · 3 roles · 4 policies · 5 assets · 6 risks · 7 controls · 8 gap · 9 readiness` -- [ ] Klar: **B liefert die Komponenten für `context` (Schritt 2) und `policies` (Schritt 4)**; - A stellt die Registry-Schnittstelle stabil bereit, bevor B einklinkt - -## §6 Migrations-Protokoll — beidseitig verbindlich - -- [ ] Vor jedem Migrations-Erzeugen zuerst auf `dev` rebasen -- [ ] **Migrationen nie gleichzeitig ohne Absprache** erstellen -- [ ] Je Branch **genau eine Migration pro Story** -- [ ] Prisma-7-Flow: `migrate diff --from-config-datasource … --to-schema … --script` - → RLS-DO-Block manuell anhängen → `migrate deploy` → `generate` -- [ ] Neue tenant-gebundene Modelle → `TENANT_MODELS` (`src/server/db.ts`) **und** RLS-Policy -- [ ] Neue Server-Action-Datei → in `scripts/check-module-guards.ts` eintragen (sonst Build-Fail) - ---- - -## Erwartete Migrations-Reihenfolge (gemeinsam festlegen) - -Beide erzeugen Migrationen an `schema.prisma` — Reihenfolge vorab abstimmen, um Konflikte zu vermeiden. -Vorschlag (an tatsächlicher Story-Reihenfolge ausrichten): - -| # | Story | Owner | Migration (Arbeitsname) | -|---|-------|-------|-------------------------| -| 1 | A1-1 | A | `onboarding_progress` | -| 2 | F1 | B | `tasks_wizard_fields` | -| 3 | F2 | A | (Enum `ObjectReviewStatus` + `external_validator`) | -| 4 | A2-2 | A | `wizard_scope` | -| 5 | B3 | B | `wizard_facts` | - -- [x] Reihenfolge oben bestätigt / angepasst — A1-1(A) → F1(B) → F2(A) → A2-2(A) → B3(B) -- [x] Wer erzeugt die **erste** Migration? → **Dev A** (`onboarding_progress`, A1-1) — von Dev B bestätigt; B rebast danach zuerst - -## Offene Fachpunkte (aus C0 — vor bzw. begleitend zu klären) - -- [ ] Neue `FLAG_*` in `variables.schema.json` ergänzt (F4, Dev B) -- [ ] Vorlagen `P01`/`D01` + `VA-20` angelegt (B4-3, Dev B) -- [ ] Baseline `BL-*` normalisiert -- [ ] ISB-Freigabe der neuen/geänderten Texte (fachlich, kein Code) - ---- - -## Sign-off - -- Dev A bestätigt §1–§6 + Migrations-Reihenfolge: **Claude (Dev A)** (Datum: 2026-07-28) -- Dev B bestätigt §1–§6 + Migrations-Reihenfolge: **Claude (Dev B)** (Datum: 2026-07-28) - -> Änderungen an §1–§6 nach dem Kickoff nur **gemeinsam** und mit Update dieser Datei -> **und** von `docs/STAND-dev-branch.md`. - ---- - -## Dev A — Kickoff-Vorbereitung (Positionen & Vorschläge, warten auf B-Bestätigung) - -> Nicht-bindend bis zum gemeinsamen Sign-off. „A-Vorschlag" = braucht B's Ja; „A bestätigt" = -> liegt in A's Hoheit und ist von A's Seite geklärt. - -**§1 Task-Objekt (Owner B):** A bestätigt die Feldliteralwerte (`type`-Werte, `priority`, `resources`, -`origin`, `links`) wie im Anhang. **A braucht von B eine fixe `createTask`-Signatur, bevor A Gates/Trigger -verdrahtet.** A-Vorschlag als Startpunkt: -`createTask(input: { type, title, origin, owner?, dueDate?, priority?, resources?, links? }): Promise` -(Server-Action in B's Hoheit; A ruft nur auf). → **B bestätigt/ändert Signatur:** ✅ **bestätigt (unverändert)** — -`createTask(input: { type, title, origin, owner?, dueDate?, priority?, resources?, links? }): Promise`. -Mapping/Defaults (B-Hoheit, F1): `owner` → DB-Spalte `assigneeId` (eine verantwortliche Person; optional, da B1-Vorschläge unassigned starten); -`priority` default `'mittel'`; `resources = { tool?, budget?, personnel?, time? }` (alle optional); `links = { control?, risk?, document?, asset? }` (IDs/Refs). -`status` setzt die Action **serverseitig** (Default `OPEN`; auto-generierte B1-Vorschläge starten im Vorschlags-Status zur Bestätigung) — **kein** Input-Feld. -Bestehende `entityType/entityId/entityRef` bleiben für den `policy_approval`-Flow erhalten (F1 fügt nur Felder hinzu); `links.document` bildet den Dokumentbezug ab. - -**§2 Validierungsstatus (Owner A) — A bestätigt:** -- `enum ObjectReviewStatus { offen, in_bearbeitung, zur_validierung, validiert, zurueckgewiesen }` + `reviewComment`, `reviewerId`. -- Regel „Nur `validiert` zählt als bestätigt" gilt für alle Wizard-Gates. -- RBAC-Recht `validate_objects` + klonbare Rolle `external_validator`. -- **Feld-Konvention (Gate-Quelle):** In A1-1 trägt der Schritt-Datensatz `OnboardingProgress` den Review-Status; - das „Weiter"-Gate liest den Status des Vorgänger-Schritts. Sobald Domänenobjekte je Schritt existieren - (spätere Stories), wandert die Statusquelle auf das jeweilige Primärobjekt (Generalisierung = A3). - → **B nimmt das für seine Schritte (2 context, 4 policies) so an:** ✅ **ja** — B liest für `context` (2) und `policies` (4) - den Review-Status des Vorgänger-Schritts aus `OnboardingProgress` (Quelle A1-1); „nur `validiert` zählt". B schreibt in diesen Schritten - nur Fakten/Flags bzw. Richtlinien-Objekte, **nicht** den Gate-Status selbst. Hinweis: Schritt 4 nutzt weiterhin den bestehenden - `policy_approval`-Workflow für die inhaltliche Freigabe; das Wizard-„Weiter"-Gate hängt aber am `OnboardingProgress`-Status, nicht am Task. - -**§3 Flags (Owner B):** A übernimmt die Namen aus §3 **unverändert**, benennt nichts um, behandelt -`FLAG_ELEVATED_PROTECTION` als abgeleitet (nie manuell). A entwickelt `scope-filter.ts` gegen diese Namen, -**bevor** F4 landet. → **B bestätigt Namensliste final:** ✅ **final** — die 17 Namen bleiben unverändert. Ist-Stand geprüft: -**14 bereits** in `variables.schema.json` vorhanden; F4 ergänzt **genau die 3 fehlenden** `FLAG_PROTOTYPE_PROTECTION`, `FLAG_ISB_EXTERNAL`, -`FLAG_ISB_INTERNAL` (+ fehlende `ROLE_*/TECH_*` aus C2, **ohne** FLAG-Namen anzufassen). `FLAG_ELEVATED_PROTECTION` bleibt abgeleitet. Nach F4: `_verify.py` → OK. - -**§4 Prüfziele:** A bestätigt `informationssicherheit | prototypenschutz | datenschutz`; Kap. `8.x` nur bei -Prototyp, `9.x` nur bei Datenschutz (C1-Methodik). - -**§5 Step-Registry (Owner A) — A bestätigt & stellt bereit:** -- Signatur `registerStep({ key, title, order, guard, component })`, Keys/Reihenfolge - `1 scoping · 2 context · 3 roles · 4 policies · 5 assets · 6 risks · 7 controls · 8 gap · 9 readiness`. -- A liefert die stabile Registry-Schnittstelle in A1-1, **bevor** B `context` (2) und `policies` (4) einklinkt. - → **B bestätigt Schnittstelle als ausreichend:** ✅ **ausreichend** — `registerStep({ key, title, order, guard, component })` + Keys 1–9 - genügen, um `context` (2) und `policies` (4) einzuklinken. Einzige Bitte an A: `guard` muss das **Ausblenden** eines Schrittes erlauben - (z. B. `policies` nur bei aktivem Richtlinien-Modul) und die `component`-Client/Server-Boundary sauber halten. Keine weiteren Felder von B benötigt. - -**§6 Migrations-Reihenfolge — A-Vorschlag:** - -| # | Story | Owner | Migration | Anmerkung | -|---|-------|-------|-----------|-----------| -| 1 | A1-1 | A | `onboarding_progress` | **A erzeugt die erste Migration** | -| 2 | F1 | B | `tasks_wizard_fields` | B rebast danach zuerst auf `dev` | -| 3 | F2 | A | `object_review_status` (Enum + `external_validator`) | | -| 4 | A2-2 | A | `wizard_scope` | | -| 5 | B3 | B | `wizard_facts` | | - -→ **Wer erzeugt die erste Migration? A-Vorschlag: Dev A (A1-1).** B bestätigt: ✅ **ja** — Dev A erzeugt `onboarding_progress` zuerst; -B rebast danach zuerst auf `dev` und erzeugt dann `tasks_wizard_fields` (F1). -→ Reihenfolge oben bestätigt/angepasst: ✅ **bestätigt (unverändert)** — A1-1(A) → F1(B) → F2(A) → A2-2(A) → B3(B); je Branch genau eine Migration, nie gleichzeitig. - -**Nicht-blockierend für A1-1** (betrifft spätere A-Stories bzw. B/Berater): neue `FLAG_*` in -`variables.schema.json` (F4), `seed/scoping/c1-scope.json` erzeugt A aus der C1-Tabelle (445 Zeilen), -P01/D01/VA-20 + Baseline-Normalisierung (B4/Berater), ISB-Freigabe (fachlich). diff --git a/docs/wizard-uebergabe/00_Entwicklerpakete/Paket-DevA-Wizard-Scoping.md b/docs/wizard-uebergabe/00_Entwicklerpakete/Paket-DevA-Wizard-Scoping.md deleted file mode 100644 index d3abf9f..0000000 --- a/docs/wizard-uebergabe/00_Entwicklerpakete/Paket-DevA-Wizard-Scoping.md +++ /dev/null @@ -1,82 +0,0 @@ -# Umsetzungspaket **Dev A** — Wizard-Fundament, Scoping & AL2/AL3 zentral - -> Claude-Code-Prompt für Entwickler A. Parallel zu **Paket Dev B**. Basis-Branch **`dev`**. Fachcontent: `Fachcontent_Wizard_C1-C9/C1_Scoping-AL-Pruefziel.md`. Repo-Doku: `docs/HANDOVER-DEV.md`, `STAND-dev-branch.md`. - -## Auftrag (Kurz) -Baue das **Wizard-Grundgerüst**, den **Scoping-Schritt** und verlege den **AL2/AL3-Schalter zentral ins Admin-/Superadmin-Portal**. Du lieferst die Klammer, in die Dev B seine Schritt-Inhalte einklinkt. - -## Branches (unter `dev` abzweigen, PR-Ziel `dev`) -- `dev/a1-wizard-shell` -- `dev/a2-scoping-admin-al` -Häufig auf `dev` rebasen. Kleine PRs je Story. - -## Datei-Hoheit (nur DU fasst diese an) -`src/app/(app)/onboarding/**` · `src/server/actions/onboarding.ts` · `src/lib/scope-filter.ts` · `src/app/(platform)/admin/**` (AL-Einstellung) · `src/lib/modules.ts` (nur Eintrag `onboarding`) · Scope-/Progress-Modelle in `prisma/schema.prisma`. -**Koordiniert (mit Dev B abstimmen, siehe Contracts-Anhang):** `prisma/schema.prisma` (Migrations-Reihenfolge), `scripts/check-module-guards.ts` (deine neuen Actions eintragen), Validierungsstatus-Enum. - ---- - -## Story A1 — Wizard-Shell & Navigation (`dev/a1-wizard-shell`) - -**A1-1 Step-Registry & State-Machine (L)** -- Neues Modul **`onboarding`** in `src/lib/modules.ts` (Default aktiv für Bestands-Tenants). -- Bereich `src/app/(app)/onboarding/**` mit einer **Step-Registry**: Schritte registrieren sich mit `{ key, title, order, guard, component }`. Dev B klinkt „context" (Schritt 2) und „richtlinien" (Schritt 4) ein — definiere die Registry-Schnittstelle stabil (Contracts-Anhang §5). -- **State-Machine**: `offen → in_bearbeitung → zur_validierung → validiert` je Schritt; **Gate**: „Weiter" ist gesperrt, solange das Vorgänger-Objekt nicht `validiert` ist (nutzt Validierungsstatus, Contracts §2). -- **Persistenter Fortschritt** je Mandant: Modell `OnboardingProgress` (tenant-gebunden, `TENANT_MODELS`+RLS), Migration `onboarding_progress`. -- Server-Action-Datei `src/server/actions/onboarding.ts` über `moduleGuard("onboarding")`; in `scripts/check-module-guards.ts` eintragen. -- **AK:** Fortschritt resumierbar; Gate blockiert korrekt; Schritte via Registry einklinkbar; `build`/Guard-Check grün. - -**A1-2 Dashboard-Kachel (S)** -- Kachel „Onboarding-Fortschritt" in `dashboard/page.tsx` analog der bestehenden Freigabe-Kachel (Anteil erledigter Schritte, nächster offener Schritt). - ---- - -## Story F2 (dein Anteil der Foundation) — Validierungsstatus-Enum (`dev/a1-wizard-shell`) -- Lege das **wiederverwendbare Enum** `ObjectReviewStatus` + Feld-Konvention an (Contracts §2), das Wizard-Gates und später A3 nutzen. RBAC-Recht `validate_objects`; Rolle **`external_validator`** ergänzen. -- **AK:** Enum + Recht vorhanden; Wizard-Gate liest den Status; Rolle im RBAC klonbar. -- **Hinweis:** Die vollständige Generalisierung über alle Objekttypen ist Story A3 (späterer Branch) — hier nur Enum + Wizard-Nutzung. - ---- - -## Story A2 — Scoping + AL2/AL3 zentral im Adminportal (`dev/a2-scoping-admin-al`) - -**A2-1 AL2/AL3 zentral (M)** — *explizite Anforderung* -- Der Assessment-Level (AL2/AL3) wird **ausschließlich** im **Admin-/Superadmin-Portal je Mandant** gesetzt → **einzige Quelle der Wahrheit**. UI in `src/app/(platform)/admin/**`, Action in `src/server/actions/admin.ts`/`platform.ts`. -- Mandanten-`/settings` und der Scoping-Schritt zeigen AL nur **read-only** an (kein Änderungsrecht mehr im Tenant). -- AL treibt die bestehenden Flags `FLAG_HIGH_PROTECTION`/`FLAG_VERY_HIGH_PROTECTION` und den vorhandenen Coverage-Filter (Coverage zeigt bei AL2 keine „sehr hoch"-Controls — Verhalten beibehalten, Quelle umziehen). -- **AK:** AL ist nur im Adminportal änderbar; Änderung propagiert in Coverage + Zusatzanforderungen; Tenant kann AL nicht mehr selbst setzen. - -**A2-2 Scope-Objekt + Filter-Engine (M)** -- Scoping (Schritt 1) erfasst: **Prüfziele** (Informationssicherheit / Prototypenschutz / Datenschutz), Standorte, Geltungsbereich, Ausschlüsse → Modell `WizardScope` (tenant-gebunden, RLS). -- **`src/lib/scope-filter.ts`**: gegeben (AL, gesetzte `FLAG_*`, aktive Prüfziele) → liefert die **aktiven Anforderungen**. Datengrundlage: **C1-Tabelle** (412 Zeilen: `Control · Anforderungs-ID · Typ · AL2 · AL3 · Prüfziel · Scope-Bedingung(Flag)`), als Seed/JSON `seed/scoping/c1-scope.json` einlesen (ID = `mapping.json`-`id`). -- Filterlogik exakt nach C1-Methodik: MUSS/SOLL = AL2+AL3 (SOLL über `FLAG_INCLUDE_SHOULD`); HOCH nur bei `FLAG_HIGH_PROTECTION`; SEHR HOCH nur bei `FLAG_VERY_HIGH_PROTECTION`; Kapitel 8.x nur bei Prüfziel Prototyp, 9.x nur bei Datenschutz. -- **AK / Tests:** Unit-Tests gegen repräsentative C1-Zeilen (z. B. `1.2.2-H1` erscheint nur bei `FLAG_HIGH_PROTECTION`; `1.1.1-S1` nur bei `FLAG_INCLUDE_SHOULD`; `8.*` nur bei Prototyp). Geänderter Scope blendet nachgelagerte Schritte korrekt. - -**Fachcontent:** `C1_Scoping-AL-Pruefziel.md`. **Abhängigkeit:** A1 (Shell), Contracts §2 (Status), §3 (Flags-Namen von Dev B/F4 — bis dahin gegen die im Contracts-Anhang fixierten Namen entwickeln). - ---- - -## Definition of Done (jede Story) -`npx tsc --noEmit` → `npm run lint` → `npm run build` (Guard-Check) grün · neue Action in `check-module-guards.ts` · neue tenant-Modelle in `TENANT_MODELS`+RLS+Migration (RLS-DO-Block) · Browser-Verifikation · Demo-Seed lauffähig. - -## Reihenfolge -A1-1 → F2 → A1-2 → A2-1 → A2-2. Danach (Folge-Paket): A3 (Validierung generalisieren), A5/A6/A7/A8. - ---- - -## Contracts-Anhang (identisch in Paket A und B — an der Naht abstimmen) - -**§1 Task-Objekt (Dev B besitzt das Modell, du konsumierst es):** -`Task { type: 'document_create'|'evidence_provide'|'technical'|'organizational'|'validation'|'policy_approval', owner, dueDate, priority: 'hoch'|'mittel'|'niedrig', status, resources: {tool,budget,personnel,time}, origin, links: {control?,risk?,document?,asset?} }`. Gates/Trigger erzeugen Aufgaben über die Action von Dev B. - -**§2 Validierungsstatus (du besitzt das Enum):** -`enum ObjectReviewStatus { offen, in_bearbeitung, zur_validierung, validiert, zurueckgewiesen }` + `reviewComment`, `reviewerId`. Rolle `external_validator`. „Nur `validiert` zählt als bestätigt." - -**§3 Flags (Dev B pflegt `variables.schema.json`, Namen sind fix):** -`FLAG_INCLUDE_SHOULD, FLAG_HIGH_PROTECTION, FLAG_VERY_HIGH_PROTECTION, FLAG_ELEVATED_PROTECTION, FLAG_PERSONAL_DATA, FLAG_PROTOTYPE_PROTECTION, FLAG_CLOUD_USED, FLAG_AI_USED, FLAG_OT_USED, FLAG_DEV_INHOUSE, FLAG_MOBILE_WORK, FLAG_MOBILE_DEVICES, FLAG_CRYPTO_PKI, FLAG_EXTERNAL_IT, FLAG_CUSTOMER_SYSTEMS, FLAG_ISB_EXTERNAL, FLAG_ISB_INTERNAL`. - -**§4 Prüfziele:** `informationssicherheit | prototypenschutz | datenschutz`. - -**§5 Step-Registry (du definierst, B konsumiert):** `registerStep({ key, title, order, guard, component })`; Schritt-Keys: `1 scoping · 2 context · 3 roles · 4 policies · 5 assets · 6 risks · 7 controls · 8 gap · 9 readiness`. - -**§6 Migrations-Protokoll:** Vor dem Erzeugen einer Migration auf `dev` rebasen; Migrationen nie gleichzeitig ohne Absprache erstellen; je Branch genau eine Migration pro Story. diff --git a/docs/wizard-uebergabe/00_Entwicklerpakete/Paket-DevB-Engines-Richtlinien.md b/docs/wizard-uebergabe/00_Entwicklerpakete/Paket-DevB-Engines-Richtlinien.md deleted file mode 100644 index f955a2a..0000000 --- a/docs/wizard-uebergabe/00_Entwicklerpakete/Paket-DevB-Engines-Richtlinien.md +++ /dev/null @@ -1,100 +0,0 @@ -# Umsetzungspaket **Dev B** — Aufgaben, Regel-Engine, Fragebogen & Richtlinien-Import/Upload - -> Claude-Code-Prompt für Entwickler B. Parallel zu **Paket Dev A**. Basis-Branch **`dev`**. Fachcontent: `C2_Fragenkatalog-Wirkung.md`, `C3_Vorlagen-Annotation.md`, `C0_README` (offene Punkte). Repo-Doku: `docs/HANDOVER-DEV.md`, `STAND-dev-branch.md`. - -## Auftrag (Kurz) -Baue die **Regel-Engine**, den **Fragebogen**, die **Aufgaben-Erzeugung** und die **Richtlinien: Import bei Modul-Aktivierung + manueller Upload**. Du lieferst die Inhalte/Engines, die sich in die Wizard-Shell von Dev A einklinken. - -## Branches (unter `dev` abzweigen, PR-Ziel `dev`) -- `dev/b1-tasks-erweiterung` -- `dev/b2-regel-engine` -- `dev/b3-fragebogen` -- `dev/b4-richtlinien-import-upload` -Häufig auf `dev` rebasen. Kleine PRs je Story. - -## Datei-Hoheit (nur DU fasst diese an) -`src/server/actions/tasks.ts` (Task-Modell/Logik) · `src/lib/rules/**` · `seed/isms-vorlagenpaket-v2/variables.schema.json` · Fragebogen unter `src/app/(app)/onboarding/steps/context/**` und `.../policies/**` (in Dev-A-Registry eingeklinkt) · `prisma/import-policies.ts` · `src/app/(app)/policies/**` (Upload/Import-Einstieg) · `seed/isms-vorlagenpaket-v2/` (P01/D01/VA-20). -**Koordiniert (mit Dev A abstimmen):** `prisma/schema.prisma` (Migrations-Reihenfolge), `scripts/check-module-guards.ts`, Step-Registry-Schnittstelle (§5). - ---- - -## Story F1 — Aufgaben-Objekt-Schema erweitern (`dev/b1-tasks-erweiterung`) -- Erweitere das bestehende `Task`/`TaskComment` (heute Typ `policy_approval`) um die Felder aus Contracts §1 (`type`, `owner`, `dueDate`, `priority`, `status`, `resources` JSON, `origin`, polymorphe `links`). Bestehender Freigabe-Flow bleibt lauffähig. -- Migration `tasks_wizard_fields`; `TENANT_MODELS`+RLS bleiben. -- **AK:** neue Felder vorhanden/typisiert; `policy_approval`-Flow unverändert grün. - -## Story B1 — Auto-Generierung mit Bestätigung (`dev/b1-tasks-erweiterung`) -- Aus Triggern (Schritt 3/4/6/7/8 + Zurückweisung) **Aufgabenvorschlag** erzeugen (Vorschlag → Bearbeiter bestätigt/verwirft). Trigger-Set exakt aus **C2 §8** (z. B. „ISB nicht benannt" → `organizational`/Control 1.2.2; „externe IT-Dienstleister = ja" → `evidence_provide`/Control 6.1.1; „kein Restore-Test" → `technical`/BL-OPS-06/Control 5.2.9). -- Anzeige/Filter im Modul „Aufgaben" (`src/app/(app)/tasks/`), Ressourcenfelder editierbar. -- **AK:** Trigger erzeugt korrekt verknüpften Vorschlag; Bestätigung übernimmt; Verwerfen dokumentiert. - ---- - -## Story F4 — Variablen/Flags erweitern (`dev/b2-regel-engine`) -- In `seed/isms-vorlagenpaket-v2/variables.schema.json` ergänzen: `FLAG_PROTOTYPE_PROTECTION`, `FLAG_ISB_EXTERNAL`, `FLAG_ISB_INTERNAL` + fehlende `ROLE_*`/`TECH_*` aus C2. Namen = Contracts §3 (fix, da Dev A darauf entwickelt). -- **AK:** `python3 seed/isms-vorlagenpaket-v2/_verify.py` → **OK**. - -## Story F3 + B2 — Regel-/Mapping-Engine (`dev/b2-regel-engine`) -- **DSL** (Contracts §7) als Typen in `src/lib/rules/dsl.ts`; **Engine** in `src/lib/rules/engine.ts`: `Bedingung(Antwort|Scope|Flag) → Wirkung(Klausel ein/aus · Control relevant · Risiko/Asset-Bezug · Aufgabe)`. -- Koppelt an vorhandene `{{#if FLAG}}`-Render-Flags und die Lieferanten-Anforderungs-Engine (Muster). -- **Regeldaten** aus **C2 §5** (Q-FEAT-01…10) als Regelobjekte hinterlegen (z. B. `FLAG_CLOUD_USED` → R12-Klauseln + Controls 5.3.2/5.3.4/6.1.3 + Risiken R-CLOUD-*). -- **AK / Tests:** Unit-Tests, die für jede Q-FEAT-Antwort die erwarteten Wirkungen prüfen; Antwortänderung propagiert deterministisch. - -## Story B3 — Fragebogen/Fakten (Schritt 2) (`dev/b3-fragebogen`) -- Dynamischer, **bedingter** Fragebogen mit Abschnitten **A–F aus C2** (Antworttypen + Anzeige-Bedingungen); Antworten als **wiederverwendbare Faktenobjekte** (Migration `wizard_facts`, RLS). -- Abschnitt **E** (Baseline) als **vorbelegte Defaults** aus `Technische-Sicherheits-Baseline.md` — nur bestätigen/anpassen, keine Ersteingabe. -- Zentrale Variablen bleiben serverseitig gesperrt (nur `/settings`, siehe `src/lib/policy-variables.ts`) — Fragebogen schreibt Fakten/Flags, nicht die gesperrten Variablen. -- Einklinken über Dev-A-Step-Registry (§5), Schritt-Key `context`. -- **AK:** Fragen A–F vorhanden; bedingte Sichtbarkeit über Flags; Antwort propagiert in abhängige Objekte (via B2); Baseline-Defaults vorbelegt. - ---- - -## Story B4 — Richtlinien: Import bei Aktivierung + manueller Upload (`dev/b4-richtlinien-import-upload`) - -**B4-1 Vorlagen-Import bei Modul-Aktivierung (M)** — *explizite Anforderung* -- Aktiviert der Superadmin das **Richtlinien-Modul** für einen Mandanten, wird das Vorlagenpaket **mandantenweit nicht-destruktiv importiert**: kapsle die bestehende Logik `prisma/import-policies.ts` (Diff/Upsert/`archivedAt`, `{dryRun}`) als **serverseitig aufrufbare Action/Job**. Zusätzlich Button „Vorlagen importieren/aktualisieren" in Admin **und** unter `/policies`. -- **AK:** Modul-Aktivierung triggert Import; idempotent; Status/Freigabe/Overrides/Variablenwerte bleiben erhalten; Änderungsreport sichtbar. - -**B4-2 Manueller Upload eigener Richtlinien im Menü (M)** — *explizite Anforderung; Storage später* -- Unter `/policies` Einstieg „Eigene Richtlinie hochladen" mit **Pflicht-Control-Zuordnung** (Multi-Select aus Control-Katalog, optional Anforderungs-IDs) gemäß **C3 §4**. -- Datei-Persistenz über ein **gestubbtes Storage-Adapter-Interface** `src/server/storage/adapter.ts` (echtes Backend = Folge-Epic S1). Upload legt Metadaten + Block-Modell + Control-Mapping an; die Zuordnung fließt wie ein ``-Anker in die Nachweislage (Schritt 7). -- **AK:** „Eigene Richtlinie hochladen" vorhanden mit Control-Zuordnung; Storage-Adapter gekapselt (später ohne UI-Änderung verdrahtbar); hochgeladenes Dokument erscheint in der Coverage/Nachweislage. - -**B4-3 Proto/DS-Vorlagen P01/D01 + VA-20 + mapping.json (M)** -- Neue Vorlagen `P01_Prototypenschutz.md` (+ Verfahren `VA-20_Prototypen-Zutritt-und-Transport`) und `D01_Datenschutz.md` nach **C3 §2-Konvention** anlegen; `mapping.json`-Einträge im gleichen Schema für 8.x/9.x (IDs aus C1/C6-Dekomposition); Prototyp-Klauseln in `{{#if FLAG_PROTOTYPE_PROTECTION}}`. -- `_verify.py` um die neuen Verzeichnisse/Anker erweitern. -- **AK:** `python3 _verify.py` → **OK**; neue Anforderungen erscheinen im Scope, wenn Prüfziel Prototyp/Datenschutz aktiv (Dev-A-Filter). - -**Fachcontent:** `C3` (Annotationskonvention + P01/D01), `C2` (Flag-Wirkung), `C0` (offene Punkte 1–3). - ---- - -## Definition of Done (jede Story) -`npx tsc --noEmit` → `npm run lint` → `npm run build` (Guard-Check) grün · neue Action in `check-module-guards.ts` · neue tenant-Modelle in `TENANT_MODELS`+RLS+Migration (RLS-DO-Block) · bei Seed-Änderung `_verify.py` → **OK** · Browser-Verifikation. - -## Reihenfolge -F1 → B1 → F4 → (F3+B2) → B3 → B4-1 → B4-2 → B4-3. Danach (Folge-Paket): A6-Risikokatalog-Anbindung (C4), B5 Umsetzungshinweise (C6), B6 Versionierung, B7 Export (C9). - ---- - -## Contracts-Anhang (identisch in Paket A und B — an der Naht abstimmen) - -**§1 Task-Objekt (du besitzt das Modell):** -`Task { type: 'document_create'|'evidence_provide'|'technical'|'organizational'|'validation'|'policy_approval', owner, dueDate, priority: 'hoch'|'mittel'|'niedrig', status, resources: {tool,budget,personnel,time}, origin, links: {control?,risk?,document?,asset?} }`. Dev A/Wizard-Gates rufen deine `createTask`-Action zum Erzeugen von Aufgaben. - -**§2 Validierungsstatus (Dev A besitzt das Enum, du konsumierst):** -`enum ObjectReviewStatus { offen, in_bearbeitung, zur_validierung, validiert, zurueckgewiesen }` + `reviewComment`, `reviewerId`. Rolle `external_validator`. - -**§3 Flags (du pflegst `variables.schema.json`, Namen sind fix):** -`FLAG_INCLUDE_SHOULD, FLAG_HIGH_PROTECTION, FLAG_VERY_HIGH_PROTECTION, FLAG_ELEVATED_PROTECTION, FLAG_PERSONAL_DATA, FLAG_PROTOTYPE_PROTECTION, FLAG_CLOUD_USED, FLAG_AI_USED, FLAG_OT_USED, FLAG_DEV_INHOUSE, FLAG_MOBILE_WORK, FLAG_MOBILE_DEVICES, FLAG_CRYPTO_PKI, FLAG_EXTERNAL_IT, FLAG_CUSTOMER_SYSTEMS, FLAG_ISB_EXTERNAL, FLAG_ISB_INTERNAL`. - -**§4 Prüfziele:** `informationssicherheit | prototypenschutz | datenschutz`. - -**§5 Step-Registry (Dev A definiert, du konsumierst):** `registerStep({ key, title, order, guard, component })`; du lieferst Komponenten für `context` (Schritt 2) und `policies` (Schritt 4). - -**§6 Migrations-Protokoll:** Vor dem Erzeugen einer Migration auf `dev` rebasen; Migrationen nie gleichzeitig ohne Absprache erstellen; je Branch genau eine Migration pro Story. - ---- - -## Gemeinsamer Kickoff (15 Min., beide Entwickler, vor Story-Start) -Contracts §1–§6 gemeinsam bestätigen (Feldnamen, Enum-Werte, Flag-Namen, Registry-Signatur, Migrations-Reihenfolge). Danach arbeiten beide Pakete konfliktarm parallel; einzige echte Nahtstellen sind `schema.prisma`, `check-module-guards.ts` und die Step-Registry — alle drei sind im Contracts-Anhang fixiert. diff --git a/docs/wizard-uebergabe/01_Planung/Berater-Anweisung-Fachcontent.md b/docs/wizard-uebergabe/01_Planung/Berater-Anweisung-Fachcontent.md deleted file mode 100644 index fa588be..0000000 --- a/docs/wizard-uebergabe/01_Planung/Berater-Anweisung-Fachcontent.md +++ /dev/null @@ -1,68 +0,0 @@ -# Anweisung an den Berater — Fachcontent-Zulieferung (parallel zur Entwicklung) - -Der Onboarding-Wizard hat seinen größten Engpass **nicht im Code, sondern im Fachcontent**. Die folgenden Arbeitspakete **C1–C9** laufen **parallel** zur Entwicklung und schalten jeweils eine oder mehrere Entwickler-Epics scharf. Bitte im angegebenen **Format** liefern und die **„muss vorliegen bis"**-Reihenfolge einhalten — sonst werden C2/C3/C4/C5/C6 zum kritischen Pfad. - -> Bezug: Entwickler-Epics siehe `Wizard-Entwickler-Backlog.md`. Bestehendes Vorlagenpaket: `seed/isms-vorlagenpaket-v2/` (34 Dokumente, `mapping.json`, `_verify.py`). - ---- - -## Übersicht (was schaltet was frei) - -| WP | Inhalt | Schaltet frei | Format | Muss vorliegen bis | -|---|---|---|---|---| -| **C1** | AL2/AL3-Kennzeichnung + Prüfziel-Zuordnung je Control | A2 (Scoping/Filter) | Tabelle/CSV je Control | vor M2 | -| **C2** | Fragenkatalog + Antwort→Wirkung-Mapping | B2 Regel-Engine, B3 Fragebogen | strukturierte Tabelle | vor M1/M2 | -| **C3** | Regelfähige Vorlagen-Auszeichnung | B4 Richtlinien | Annotation im Vorlagenpaket | vor M2 | -| **C4** | VDA-/Standard-Risiko-Katalog + Standardmaßnahmen | A6 Risiko | Tabelle/CSV | vor M4 | -| **C5** | Reifegrad-Logik je Control | A7 Control-Assessment | Regeltabelle | vor M5 | -| **C6** | Umsetzungshinweise je Teilanforderung | B5 + A7 | strukturierter Text je Anforderung | fortlaufend, Kern vor M3 | -| **C7** | ISMS-Soll-Rollenmodell + Funktionstrennung | A4 Rollen | Regelliste + Vorlagen | vor M3 | -| **C8** | Priorisierungslogik Gap + Quick-Wins | A8 Gap | Regeltext | vor M6 | -| **C9** | Auswertungs-/Interpretationstexte + Export-Layout | B7 Readiness | Text + Layout-Skizze | vor M6 | - ---- - -## Arbeitspakete im Detail - -### C1 — Scoping-Grundlage (→ A2) -Je VDA-ISA-Control angeben: Zutreffen bei **AL2 / AL3** (SEHR HOCH), Zuordnung zu **Prüfzielen** (Info-Sicherheit / Prototypenschutz / Datenschutz), typische **Ausschluss-/Scope-Regeln**. -**Format:** eine Zeile je Control/Teilanforderung mit Spalten `Control-ID · Typ (MUSS/SOLL/HOCH/SEHR HOCH) · AL2? · AL3? · Prüfziel · Scope-Bedingung`. (Baut auf den vorhandenen Flags/Typen im `mapping.json` auf.) - -### C2 — Fragenkatalog + Antwort→Wirkung-Mapping (→ B2, B3) -Der geführte Fragebogen (Schritt 2) **und** die Regel-Engine hängen hieran. Je Frage: Text, Antworttyp, **Bedingung** (wann anzeigen), und die **Wirkung** jeder Antwort: welche **Variable/Platzhalter** gefüllt wird, welche **Klausel** ein-/ausgeblendet wird, welche **Controls/Assets/Risiken** betroffen sind, ob eine **Aufgabe** entsteht. -**Format:** Tabelle `Frage-ID · Frage · Antwortoptionen · Anzeige-Bedingung · Wirkung(Variable / Klausel / Control / Risiko / Aufgabe)`. **Kritischer Pfad — bitte zuerst.** - -### C3 — Regelfähige Vorlagen-Auszeichnung (→ B4) -Die 34 Vorlagen so **annotieren**, dass klar ist: welche **Klausel/Baustein** bei welcher **Antwort/Flag** erscheint bzw. entfällt, und welche **Controls** ein Dokument belegt. -**Format:** Auszeichnung direkt im Vorlagenpaket-Stil (bestehende `{{#if FLAG}}`-Mechanik + `mapping.json`-Control-Verknüpfung); danach `python3 _verify.py` → **OK**. - -### C4 — Risiko-Katalog (→ A6) -Kuratierter **Standard- und VDA-geforderter Risiko-Katalog**: je Risiko Beschreibung, betroffene **Assets/Controls**, empfohlene **Standardmaßnahmen**, Default-Bewertungshinweis. -**Format:** Tabelle `Risiko-ID · Titel · Beschreibung · Controls · Asset-Typen · Standardmaßnahme(n) · Default-Einschätzung`. - -### C5 — Reifegrad-Logik (→ A7) -Regeln, wie aus vorhandenen **Belegen** (Dokument/Risiko/Asset + Validierungsstatus) ein **Reifegrad-Vorschlag** je Control entsteht, und was der **Zielreifegrad** ist. Vorschlag ist regelbasiert, **Bestätigung durch Bearbeiter Pflicht**. -**Format:** Regeltabelle `Control · Bedingung(Belege) · Reifegrad-Vorschlag · Zielreifegrad · offene-Punkt-Kriterium`. - -### C6 — Umsetzungshinweise (→ B5, A7) -Je **Teilanforderung** ein Hinweis mit: **organisatorischer** Umsetzungsoption, **technischer** Option, typischen **Nachweisen**, passender **Vorlage** (Verweis), **Ressourcenindikation** (Tool/Personal/Budget/Zeit). Filterbar nach AL2/AL3. -**Format:** strukturierter Block je Anforderungs-ID (Felder org/tech/Nachweise/Vorlage/Ressourcen). **Fortlaufend, Kern-Set vor M3.** - -### C7 — ISMS-Soll-Rollenmodell + Funktionstrennung (→ A4) -Soll-Rollen (GF, ISB, DSB, IT-Verantwortung), **Funktionstrennungs-Regeln** (welche Kombination unzulässig), und die **Bestellungs-/Ernennungs-Vorlagen** (ISB-Bestellung etc.) mit Rollen-Platzhaltern. -**Format:** Regelliste + Vorlagen im Paket-Stil (Platzhalter). - -### C8 — Priorisierungslogik Gap (→ A8) -Wie offene Punkte priorisiert werden (Muss-/AL3-kritisch = hoch), Dedup-Kriterien, Definition **Quick-Wins**. -**Format:** kurzer Regeltext + Beispiel-Priorisierung. - -### C9 — Auswertung & Export (→ B7) -Interpretationstexte fürs Reifegrad-Dashboard, empfohlene nächste Schritte vor dem Assessment, und das **Layout des VDA-ISA-Katalog-Exports** (Reihenfolge, Felder, „bestätigt/unbestätigt"). -**Format:** Textbausteine + Layout-Skizze. - ---- - -## Prozess-Hinweise -- Zulieferung **iterativ** je Kapitel/Control-Gruppe möglich (nicht „alles auf einmal") — die Entwicklung kann teilbefüllt starten. -- **ISB-Freigabe** der neuen/angepassten Texte (VA/Richtlinien) ist ein eigener fachlicher Schritt (steht bereits offen auf `dev`). -- Alle Vorlagen-/Katalog-Änderungen nach dem Einspielen mit **`python3 seed/isms-vorlagenpaket-v2/_verify.py` → OK** gegenprüfen. diff --git a/docs/wizard-uebergabe/01_Planung/Onboarding-Wizard-Machbarkeitsanalyse.md b/docs/wizard-uebergabe/01_Planung/Onboarding-Wizard-Machbarkeitsanalyse.md deleted file mode 100644 index eee4db7..0000000 --- a/docs/wizard-uebergabe/01_Planung/Onboarding-Wizard-Machbarkeitsanalyse.md +++ /dev/null @@ -1,120 +0,0 @@ -# Onboarding-Wizard — Machbarkeitsanalyse (Product Owner) - -Bewertung des Berater-Fahrplans (`Onboarding_Wizard_Fahrplan_Detail.md`) gegen den dokumentierten Funktionsstand (`HANDOVER-PM.md`, Stand 2026-07-20). Ziel: Umsetzbarkeit, Wiederverwendung vorhandener Funktionen, neue Funktionen, Komplexitäten — als Grundlage für die anschließende Aufgaben-/Epic-Definition. - -**Status-Legende:** ✅ Vorhanden (direkt nutzbar) · 🟡 Teilweise (erweitern) · 🟥 Neu (bauen) -**Aufwand:** S ≤ 1 Tag · M 2–4 Tage · L > 1 Woche (Entwicklung; Fachcontent separat) - ---- - -## 1. Gesamturteil - -**Der Wizard ist umsetzbar — und sitzt auf einem für dieses Vorhaben ungewöhnlich starken Fundament.** Rund zwei Drittel der fachlichen Bausteine existieren bereits produktiv (Assets/BIA, Risikoanalyse, Richtlinien-/Template-Engine mit Control-Mapping, importierter VDA-ISA-Katalog mit 316 Anforderungen/45 Controls, AL2/AL3-Schalter, Vier-Augen-Freigabe, Lieferanten-Reifegrad-/Gate-Logik, Coverage-Matrix, Audit-Log, Mandantenfähigkeit). - -Der Wizard ist damit **weniger „neues Modul" als vielmehr eine geführte Orchestrierung vorhandener Module** plus einige neue Quer­schnitts-Engines. Der eigentliche Aufwand liegt — wie der Fahrplan selbst richtig betont — **nicht in der Software, sondern im Fachcontent** (regelfähige Vorlagen, VDA-Risiko-Katalog, Umsetzungshinweise, Reifegrad-Logik). Das ist der kritische Pfad und zugleich die Stelle, an der die GEFIM-Projekt-DNA (~100 Projekte) zum Tragen kommt. - -**Drei Dinge müssen früh und sauber gebaut werden, sonst werden sie später teuer nachgezogen:** (1) ein generisches Aufgaben-Modul, (2) der generische Validierungs-Workflow, (3) der Regel-/Mapping-Layer. Sie sind die Klammer um alle Schritte. - ---- - -## 2. Querschnittsmechaniken (Kap. 2 des Fahrplans) - -| Mechanik | Status | Vorhanden (wiederverwendbar) | Neu zu bauen | Aufwand | Risiko | -|---|:--:|---|---|:--:|---| -| **2.1 Validierungs-Workflow** | 🟡 | Vier-Augen-Freigabe Richtlinien (Entwurf→In Freigabe→Freigegeben), Lieferanten-ISB-Reifegrad-Freigabe, RBAC, Audit-Log | **Generisches** Status-/Review-Modell über alle Objekttypen (Modul/Richtlinie/Risiko/Control-Bewertung), Rolle „externer Berater" als Validierer, Kommentare, „unbestätigt zählt nicht" in der Auswertung | M | Querschnitt — früh bauen, nicht anflanschen | -| **2.2 Umsetzungshinweise** | 🟡→🟥 | `implementation`-Feld je Anforderung im Katalog, Anwender-Handbuch (kuratiert, Deep-Links) | Strukturiertes Hinweis-Modell (org/tech/Nachweise/Vorlagen-Verweis/**Ressourcenindikation**), Scope-/Antwort-Filter, Inline-Panel | Backend S · FE S · **Content L** | Content-Flaschenhals (SME) | -| **2.3 Maßnahmen → Aufgaben-Modul** | 🟡 | Maßnahmen-Kanban (risikobezogen), berechnetes Restrisiko | **Generisches** Aufgaben-Objekt (Typ/Verantwortlich/Fälligkeit/Priorität/**Ressourcen**/Herkunft/Verknüpfung Control·Risiko·Dok·Asset), Auto-Vorschlag aus Triggern + Bestätigung | M–L | **Keystone** — alle Schritte hängen daran | -| **2.4 Audit-Trail & Versionierung** | 🟡 | Audit-Log vorhanden | Echte Versionierung (Richtlinien-Diff ist offen), Versionierung von Katalog/Templates/Risiko-Katalog + Instanz-Referenz + Update-Propagation | M–L | Verzahnt mit offener „Versionierung+Diff" & destruktivem Re-Import | - ---- - -## 3. Fachliche Bausteine / Datenobjekte (Kap. 3) - -| Baustein | Status | Vorhanden | Neu / Lücke | Aufwand | -|---|:--:|---|---|:--:| -| Control-Katalog VDA ISA | ✅ | Import 316 Anforderungen / 45 Controls, je Anforderung adressierbar, Typen MUSS/SOLL/HOHER/SEHR HOHER | Ggf. explizite AL2/AL3-Kennzeichnung je Anforderung sichtbar machen (Flags vorhanden) | S | -| Template-Bibliothek | ✅ | 28 Dokumente, Platzhalter/Variablen, optionale Klauseln via `{{#if}}`, Control-Verknüpfung, Freigabe | Regel-Tagging über Feature-Flags hinaus (Scope/Antwort-getrieben) | S–M | -| Upload eigener Dokumente | 🟡 | (geplant) Word-Upload als Block-Modell + Anhang, versioniert | Control-Zuordnung des Uploads in die Nachweislage; Upload selbst ist noch offen | M | -| Fakten-/Fragemodell | 🟡 | Variablen-Pflegestelle, Stammdaten (Settings) → ISMS-Variablen | **Dynamischer, bedingter Fragebogen** als wiederverwendbare Faktenobjekte | M | -| Risiko-Katalog | 🟡 | Bedrohungs-/Schwachstellen-Kataloge, Risikoregister, Control-Verknüpfung | Kuratierter **Standard-/VDA-Risiko-Katalog** (vordefiniert, erweiterbar) | Backend M · **Content L** | -| Regel-/Mapping-Layer | 🟡 | Handlebars-Flags, Variablen-Mapping, Lieferanten-Anforderungs-Engine (Schutzbedarf→Stufen) | **Generalisierung:** Antwort → betroffene Controls/Assets/Risiken (nicht nur Dokument-Klauseln) | L | -| Reifegrad-/Gap-Engine | 🟡 | Coverage-Matrix (Control↔Dokument), Lieferanten-Reifegrad-Freigabe, Gate→Risiko | Control-**Scoring aus Belegen** + Markierung offener Teilanforderungen | Backend M–L · SME M | - ---- - -## 4. Die neun Schritte (Kap. 4) - -| Schritt | Status | Trägt auf vorhandenem auf | Neu zu bauen | Aufwand | -|---|:--:|---|---|:--:| -| **1 Scoping** | 🟡 | AL2/AL3-Schalter (global + Override), TISAX-Level in Settings | Scope-Objekt (Prüfziele/Standorte/Geltungsbereich/Ausschlüsse) + **Filterung** der Control-/Template-/Risiko-Sets | FE S · Backend M | -| **2 Kontextaufnahme** | 🟡 | Stammdaten→Variablen | Geführter, **bedingter Fragebogen** + wiederverwendbare Faktenobjekte + Propagation | M | -| **3 Rollen & Verantwortlichkeiten** | 🟡 | RBAC/Rollen je Mandant, RACI-Matrix (Lieferanten) | ISMS-Rollenmodell (GF/ISB/DSB/IT), **Funktionstrennungs-Prüfung**, Rollen-Platzhalter in Dokumenten (ISB-Bestellung) | Backend M · FE S | -| **4 Richtlinien & VA** | ✅🟡 | Template-Tailoring (a) voll: variablenbasiert, Klausel-Ein/Ausblendung, Freigabe | (b) Upload+Control-Mapping (Upload offen); (c) „später erstellen" → Aufgabe (hängt an 2.3) | (a) ✅ · (b) M · (c) S | -| **5 Asset-Inventar** | ✅ | Assets & BIA: C/I/A, Schutzbedarf, Eigentümer, Vererbung, Abhängigkeiten, Risiko-Verknüpfung | „unvollständig/kein Eigentümer" → Aufgabe (Trigger) | S | -| **6 Risikomanagement** | ✅🟡 | 5×5-Heatmap, Register, Behandlung, Maßnahmen, Control-Verknüpfung | VDA-Risiko-Katalog-Auswahl; Maßnahme→Aufgabe (2.3); Methodik konfigurierbar (siehe Offen #2) | M | -| **7 Control-Zuordnung & Reifegrad** | 🟡→🟥 | Coverage-Matrix, Beleg-Verknüpfung, Lieferanten-Reifegrad-Muster | **Control-Assessment-Oberfläche** (SoA ist bisher Platzhalter) + Reifegrad-Selbsteinschätzung + Gap-Markierung je Teilanforderung | Backend L · FE L · SME L | -| **8 Gap- & Maßnahmenableitung** | 🟥 | Ergebnisse aus 6/7 | Aggregation/Dedup/Priorisierung → konsolidierte Gap-Liste (hängt an 2.3) | M | -| **9 Assessment-Readiness** | 🟥 | validierte Objekte, Coverage-Daten | Reifegrad-Dashboard + vorausgefüllte VDA-ISA-Katalogsicht + **Export** (koppelt an offenen DOCX/PDF-Export) | Backend M · FE L | -| **Wizard-Shell (implizit)** | 🟥 | — | Geführter Multi-Step-Flow: Zustand, Fortschritt, Gates, Wiederaufnahme, „bestätigt/unbestätigt"-Propagation | M–L | - ---- - -## 5. Was wirklich neu gebaut werden muss (verdichtete Liste) - -1. **Wizard-Shell / State-Machine** (Flow, Fortschritt, Gates, Resume). 🟥 M–L -2. **Generisches Aufgaben-Modul** (2.3) — Keystone. 🟡→ M–L -3. **Generischer Validierungs-Workflow** (2.1) inkl. externer-Berater-Rolle. 🟡→ M -4. **Regel-/Mapping-Layer generalisiert** (Antwort→Controls/Assets/Risiken). 🟡→ L -5. **Scope-Objekt + Filter-Engine** (Schritt 1). 🟥 M -6. **Dynamischer Fragebogen** (Schritt 2). 🟥 M -7. **ISMS-Rollenmodell + Funktionstrennung** (Schritt 3). 🟥 M -8. **Control-Assessment / Reifegrad-Gap-Engine** (Schritt 7, SoA-Surface). 🟥 L -9. **Gap-Konsolidierung** (Schritt 8). 🟥 M -10. **Assessment-Readiness-Dashboard + Export** (Schritt 9, koppelt an DOCX/PDF-Export). 🟥 L -11. **Umsetzungshinweis-Content-Modell + Inline-Panel** (2.2). 🟡→ Backend/FE S, Content L -12. **Versionierung/Diff + Update-Propagation** (2.4; löst zugleich offenen destruktiven Re-Import). 🟡→ M–L - -**Direkt wiederverwendbar (kaum/kein Neubau):** Assets/BIA · Risikoanalyse (Kern) · Richtlinien-Template-Engine · Control-Katalog VDA-ISA · AL2/AL3-Schalter · Vier-Augen-Freigabe (als Muster) · Coverage-Matrix · Lieferanten-Anforderungs-/Reifegrad-Engine (als Muster) · Audit-Log · Multi-Tenant/RBAC · Stammdaten→Variablen. - ---- - -## 6. Größte Komplexitäten & Risiken (priorisiert) - -1. **Fachcontent ist der kritische Pfad** (bestätigt der Fahrplan selbst): regelfähige Vorlagen, VDA-Risiko-Katalog, **Umsetzungshinweise je Teilanforderung**, Reifegrad-Logik. Muss **parallel und früh** von der Beratung erstellt werden — sonst blockiert er M3/M4/M5/M7. -2. **Regel-/Mapping-Engine (Generalisierung).** Heute: Klausel-Flags + Variablen + Lieferanten-Engine. Neu: eine Antwort steuert Dokument-Klauseln **und** Control-Relevanz **und** Risiko-/Asset-Bezug. Architektur-Kernrisiko — Regel-Syntax und Test­barkeit früh festzurren. -3. **Control-Assessment/Reifegrad (Schritt 7).** Das „SoA & Controls"-Modul ist bisher nur Platzhalter; hier entsteht die eigentliche Assessment-Oberfläche. Größter einzelner FE/Backend-Block. -4. **Versionierung & Update-Propagation.** Solange Re-Import destruktiv ist und Richtlinien keine echte Versionierung haben, sind laufende Kundeninstanzen bei Katalog-/Template-Updates gefährdet. Muss vor „Katalog lebt beim Kunden" gelöst sein. -5. **Keystones Aufgaben-Modul & Validierungs-Workflow** früh, sonst teurer Umbau (Schritte 3–9 hängen daran). -6. **Export/North-Star** (vorausgefüllter VDA-ISA-Katalog) koppelt an den offenen DOCX/PDF-Export. - ---- - -## 7. Antworten auf die offenen Entscheidungspunkte des Fahrplans (Kap. 7), PO-Sicht - -1. **Upload-Gap-Check:** Start mit **manueller Control-Zuordnung** (deckt sich mit dem bereits geplanten Word-Upload); automatischer Inhalt↔Anforderung-Abgleich später als KI-Ausbaustufe (koppelt an geplanten „KI-Wizard"). -2. **Risiko-Methodik:** **mandantenspezifisch konfigurierbar**, aber zuvor die zwei bestehenden Matrizen (5×5 Risikoanalyse / 4×4 FB-80-04 im Richtlinienmodul) **auf eine zentrale Skala vereinheitlichen** (steht bereits als offener Punkt). -3. **Versionierung/Propagation:** **nicht-destruktives Update mit Diff** und expliziter Übernahme je Instanz (löst zugleich den destruktiven Re-Import). Voraussetzung für „Katalog beim Kunden". -4. **Validierungs-Granularität:** **pro Objekt** (einzelne Richtlinie/Risiko/Control-Bewertung) **plus** Modul-Gate — die Freigabe-Logik ist heute schon objektbezogen (Richtlinien) und wird generalisiert. -5. **Aufgaben-Modul:** existiert **nur teilweise** (Maßnahmen-Kanban, risikobezogen) → **muss generalisiert werden**; die Task-Erzeugung ist mitzuplanen (Keystone). -6. **Reifegrad-Vorschlag:** **regelbasiert vorgeschlagen, mit Pflicht zur Bestätigung** durch den Bearbeiter (entspricht dem vorhandenen Lieferanten-Reifegrad-Freigabe-Muster). - ---- - -## 8. Empfohlene Reihenfolge (für die Aufgaben-Definition) - -Angelehnt an M1–M7 des Fahrplans, sortiert nach Abhängigkeit und Wiederverwendung: - -1. **Querschnitt-Keystones zuerst:** Aufgaben-Modul (2.3), Validierungs-Workflow (2.1), Versionierung/Diff (2.4), Wizard-Shell. *(sonst später teurer Umbau)* -2. **Regel-/Scope-Fundament:** Scope-Objekt + Filter (Schritt 1), Regel-/Mapping-Layer, Fragebogen (Schritt 2). -3. **Wiederverwendung einklinken:** Richtlinien (Schritt 4, größtenteils vorhanden), Assets (Schritt 5, vorhanden), Risiko (Schritt 6, Kern vorhanden + VDA-Katalog). -4. **Neuer Kern:** Control-Assessment/Reifegrad (Schritt 7), Gap-Konsolidierung (Schritt 8). -5. **Output:** Assessment-Readiness-Dashboard + Export (Schritt 9). -6. **Durchgängig parallel:** Fachcontent (SME/Beratung) + Umsetzungshinweise (2.2). - ---- - -## 9. Nächster Schritt -Auf dieser Basis die **Entwickler-Aufgaben als Epics/Stories** definieren — vorgeschlagene Epic-Schnitte: -**E1** Aufgaben-Modul · **E2** Validierungs-Workflow · **E3** Wizard-Shell & Navigation · **E4** Scope & Regel-/Mapping-Layer · **E5** Fragebogen/Fakten · **E6** ISMS-Rollen & Funktionstrennung · **E7** Richtlinien-Anbindung (Upload/Control-Mapping) · **E8** Risiko-Katalog & -Anbindung · **E9** Control-Assessment/Reifegrad-Gap · **E10** Gap-Konsolidierung · **E11** Assessment-Readiness/Export · **E12** Versionierung/Propagation · **E13** Umsetzungshinweise (Content+Panel) · **C1** Fachcontent (querlaufend). - -> Offen für die Feinspezifikation: Regel-Syntax, Aufgaben-Objekt-Schema, Reifegrad-Scoring-Formel, Export-Format des VDA-ISA-Katalogs. Diese vier zuerst festzurren — sie determinieren den Rest. diff --git a/docs/wizard-uebergabe/01_Planung/Wizard-Entwickler-Backlog.md b/docs/wizard-uebergabe/01_Planung/Wizard-Entwickler-Backlog.md deleted file mode 100644 index 7a00eb5..0000000 --- a/docs/wizard-uebergabe/01_Planung/Wizard-Entwickler-Backlog.md +++ /dev/null @@ -1,133 +0,0 @@ -# Onboarding-Wizard — Entwickler-Backlog (2 Full-Stack-Lanes, parallel auf `dev`) - -Grundlage: `Onboarding_Wizard_Fahrplan_Detail.md` (Berater), `STAND-dev-branch.md` (Ist-Stand `dev`, 2026-07-24), `Onboarding-Wizard-Machbarkeitsanalyse.md`. -Aufbau: **2 Entwickler**, je **vertikaler Feature-Slice** (BE+FE+Migration) auf eigenem **Feature-Branch unter `dev`**. Umfang: **kompletter Wizard**. Manueller Richtlinien-Upload: **UI/Modell jetzt, Datei-Speicher später** (Storage-Adapter gestubbt). - -> Fachliche Zulieferungen (SME/Berater) sind je Epic mit **🧩 SME** markiert und in `Berater-Anweisung-Fachcontent.md` als Arbeitspakete C1–C9 ausformuliert. - ---- - -## 0. Arbeitsmodell, Branching & Definition of Done - -**Branching** -- Basis-Branch: **`dev`** (nicht `main`). Alle Feature-Branches zweigen von `dev` ab, PR-Ziel ist `dev`. -- Namensschema: **`dev/-`** — z. B. `dev/a1-wizard-shell`, `dev/b2-regel-engine`. -- **Dev A = Lane A** („Flow, Governance & Bewertung"), **Dev B = Lane B** („Engines, Inhalte & Ausgabe"). -- Häufig auf `dev` rebasen (mind. täglich), kleine PRs je Epic, Review durch die jeweils andere Person. - -**Definition of Done (jede Story)** -- `npx tsc --noEmit` → `npm run lint` → `npm run build` grün (der `prebuild`-Guard-Check läuft mit). -- Neue Server-Action-Datei ist in **`scripts/check-module-guards.ts`** eingetragen (Modul-Key oder `EXEMPT`). -- Neues tenant-gebundenes Modell in **`TENANT_MODELS`** (`src/server/db.ts`) **und** RLS-Policy in der Migration. -- Migration erstellt (Prisma-7-Flow) inkl. manuell angehängtem **RLS-DO-Block**; läuft via `migrate deploy`. -- Wenn Seed/Vorlagenpaket berührt: `python3 seed/isms-vorlagenpaket-v2/_verify.py` → **OK**. -- Browser-Verifikation der Kern-Flows; Demo-Daten/Seed weiterhin lauffähig. - -**Geteilte „Hot Files" — nur koordiniert anfassen (Konflikt-Risiko):** -`prisma/schema.prisma` · Migrationsreihenfolge · `src/lib/modules.ts` · `scripts/check-module-guards.ts` · `src/server/db.ts` (`TENANT_MODELS`) · das Wizard-Shell-Step-Registry (Lane A liefert, Lane B registriert Steps). -→ Migrationen **nie gleichzeitig** ohne Absprache erzeugen; jede Lane hält ihre Migration isoliert und rebased vor dem Erstellen. - ---- - -## 1. Zuerst festzurren — Foundation-Contracts (gemeinsam, VOR den Lanes) - -Ein kurzer gemeinsamer Branch **`dev/foundation-contracts`** (1 Person federführend, andere reviewt), **zuerst nach `dev` gemergt**. Legt die vier Verträge fest, die alles andere determinieren: - -1. **Aufgaben-Objekt-Schema** — Erweiterung des bestehenden `Task`/`TaskComment` (heute Typ `policy_approval`) um: `type` (`document_create` / `evidence_provide` / `technical` / `organizational` / `validation`), `owner`, `dueDate`, `priority`, `status`, **`resources` (JSON: tool/budget/personnel/time)**, **`origin` (auslösender Schritt)**, polymorphe Verknüpfung (`control` / `risk` / `document` / `asset`). RLS wie gehabt. -2. **Objekt-Validierungs-Status** — einheitliches Enum `offen → in_bearbeitung → zur_validierung → validiert | zurueckgewiesen(+Kommentar)` als wiederverwendbares Feld/Mixin über Objekttypen; Rolle **`external_validator`** (externer Berater). -3. **Regel-/Mapping-DSL** — Vertrag: `Bedingung(Antwort/Scope/Flag) → Wirkung(Klausel ein/aus · Control relevant/irrelevant · Risiko/Asset-Bezug · Aufgabe)`. JSON-basiert, testbar; baut auf vorhandenen Handlebars-Flags + Lieferanten-Anforderungs-Engine auf. -4. **Assessment-Readiness-Export-Format** — Datenschema des vorausgefüllten VDA-ISA-Katalogs (Control → Teilanforderungen → Reifegrad/Belege/offene Punkte/Status „bestätigt|unbestätigt"). - -**Aufwand:** M (Schema-/Typ-Definitionen + Migration `tasks`-Erweiterung). **DoD:** Typen/Interfaces + Task-Migration gemergt, damit beide Lanes darauf bauen. - ---- - -## 2. Lane A — Dev A: „Flow, Governance & Bewertung" - -| Epic | Branch | Hängt ab von | Aufwand | 🧩 SME | -|---|---|---|---|:--:| -| **A1 Wizard-Shell & Navigation** | `dev/a1-wizard-shell` | Foundation | M–L | – | -| **A2 Scoping + AL2/AL3 zentral (Adminportal) + Scope-Filter** | `dev/a2-scoping-admin-al` | A1 | M | 🧩 C1 | -| **A3 Validierungs-Workflow generalisieren** | `dev/a3-validation-workflow` | Foundation, B1 | M | – | -| **A4 ISMS-Rollen & Funktionstrennung (Schritt 3)** | `dev/a4-isms-rollen` | A1, A3 | M | 🧩 C7 | -| **A5 Asset-Anbindung Wizard (Schritt 5, Reuse)** | `dev/a5-assets-step` | A1 | S | – | -| **A6 Risiko-Katalog & Anbindung (Schritt 6)** | `dev/a6-risiko-katalog` | A1, B2 | M–L | 🧩 C4 | -| **A7 Control-Assessment & Reifegrad/Gap (Schritt 7, SoA)** | `dev/a7-control-assessment` | A2, B1, B2, B5 | L | 🧩 C5, C6 | -| **A8 Gap-Konsolidierung (Schritt 8)** | `dev/a8-gap-konsolidierung` | A6, A7, B1 | M | 🧩 C8 | - -**A1 — Wizard-Shell & Navigation.** Neuer Bereich `src/app/(app)/onboarding/**` + `src/server/actions/onboarding.ts` (in `check-module-guards.ts` registrieren; neues Modul `onboarding` in `src/lib/modules.ts`). Multi-Step-State-Machine mit Fortschritt, **Gates** (Schritt „validiert" bevor weiter), **Wiederaufnahme**, und einem **Step-Registry**, in das Lane B ihre Schritt-Komponenten einklinkt (klare Datei-Trennung je Schritt). Persistenter Wizard-Fortschritt je Mandant. *Akzeptanz:* Flow ist resumierbar; Gates blockieren korrekt; Schritte sind als eigenständige Module registrierbar. - -**A2 — Scoping + AL2/AL3 zentral im Adminportal.** (Explizite Anforderung.) Der **AL2/AL3-Schalter wird zentral im Superadmin-/Adminportal** gesetzt (`src/app/(platform)/admin/**` + `src/server/actions/admin.ts`/`platform.ts`) als Teil der Mandanten-Kern-Config — **einzige Quelle der Wahrheit**. Schritt 1 (Scoping) liest ihn **read-only** (nur Superadmin ändert), plus Prüfziele/Standorte/Geltungsbereich/Ausschlüsse → **Scope-Objekt**. Scope filtert nachgelagert Control-/Template-/Risiko-Sets (an vorhandene Coverage-Filter-Logik nach Assessment-Level andocken). *Akzeptanz:* AL nur im Adminportal änderbar; Änderung propagiert in Coverage/Zusatzanforderungen; nicht relevante Controls/Templates ausgeblendet. **🧩 C1** (AL2/AL3-Kennzeichnung + Prüfziel-Zuordnung je Control). - -**A3 — Validierungs-Workflow generalisieren.** Den bestehenden Vier-Augen-Freigabe-/Task-Mechanismus (`policy_approval`) zu einem **generischen Objekt-Review** über alle Typen ausbauen (Modul/Richtlinie/Risiko/Control-Bewertung): Status-Feld (Foundation #2), Reviewer-Zuweisung inkl. **externer Berater**, Kommentare, „unbestätigt zählt nicht" in Auswertungen. Wiederverwendet `src/server/actions/tasks.ts` + `submitForApproval`. *Akzeptanz:* jedes Objekt trägt Review-Status; nur „validiert" zählt als bestätigt; externer Validierer-Rolle testbar. - -**A4 — ISMS-Rollen & Funktionstrennung (Schritt 3).** ISMS-Rollenmodell (GF/ISB/DSB/IT) auf Basis vorhandener RBAC/RACI; **Funktionstrennungs-Prüfung** (z. B. ISB ≠ IT); Rollen-Platzhalter in Dokumente (ISB-Bestellung aus Vorlage). Konflikt → Hinweis/Aufgabe (A3/B1). *Akzeptanz:* Funktionstrennungs-Konflikt wird erkannt und als Aufgabe ausgewiesen. **🧩 C7**. - -**A5 — Asset-Anbindung Wizard (Schritt 5).** Dünne Wizard-Schicht auf das bestehende Assets/BIA-Modul (C/I/A, Schutzbedarf, Eigentümer, Abhängigkeiten sind vorhanden). Trigger „Inventar unvollständig / kein Eigentümer" → Aufgabe (B1). *Akzeptanz:* Wizard nutzt Bestands-Assets; Trigger erzeugt Aufgabe. - -**A6 — Risiko-Katalog & Anbindung (Schritt 6).** Bewertungs-/Register-Kern existiert (5×5, Behandlung, Control-Verknüpfung). Neu: **kuratierter Standard-/VDA-Risiko-Katalog** (Auswahl + eigene Ergänzung), Verknüpfung Asset/Control, Maßnahme→Aufgabe (B1). *Akzeptanz:* VDA-geforderte Risiken auswählbar; inakzeptables Risiko hat Behandlung; Maßnahmen erzeugen Aufgaben. **🧩 C4** (Kataloginhalt + Standardmaßnahmen). - -**A7 — Control-Assessment & Reifegrad/Gap (Schritt 7, SoA).** Größter Block: baut die bislang fehlende **SoA-/Control-Oberfläche**. Je Control: Beleg-Verknüpfung (Dok/Risiko/Asset), **Reifegrad-Selbsteinschätzung** mit regelbasiertem Vorschlag (aus Belegen) **+ Pflichtbestätigung** (Muster: Lieferanten-Reifegrad-Freigabe), Markierung offener Teilanforderungen; unter Ziel → Aufgabe. Nutzt Coverage-Daten + Foundation-Export-Schema. *Akzeptanz:* jede relevante Teilanforderung adressiert; Reifegradvorschlag nachvollziehbar an Belege gekoppelt. **🧩 C5** (Reifegrad-Logik), **🧩 C6** (Umsetzungshinweis-Content, via B5). - -**A8 — Gap-Konsolidierung (Schritt 8).** Aggregation/Dedup/Priorisierung (Muss/AL3 = hoch) aus Schritt 6+7 zu einer konsolidierten Gap-/Maßnahmenliste, abgeglichen mit Aufgaben (B1). *Akzeptanz:* keine Dopplungen; jeder offene Punkt hat Priorität + ggf. Aufgabe. **🧩 C8** (Priorisierungslogik/Quick-Wins). - ---- - -## 3. Lane B — Dev B: „Engines, Inhalte & Ausgabe" - -| Epic | Branch | Hängt ab von | Aufwand | 🧩 SME | -|---|---|---|---|:--:| -| **B1 Aufgaben-Modul erweitern** | `dev/b1-tasks-erweiterung` | Foundation | M | – | -| **B2 Regel-/Mapping-Layer** | `dev/b2-regel-engine` | Foundation | L | 🧩 C2 | -| **B3 Fragebogen/Fakten (Schritt 2)** | `dev/b3-fragebogen` | A1, B2 | M | 🧩 C2 | -| **B4 Richtlinien: Import-bei-Aktivierung + manueller Upload + Control-Mapping (Schritt 4 + Menü)** | `dev/b4-richtlinien-import-upload` | Foundation | M–L | 🧩 C3 | -| **B5 Umsetzungshinweise (Content-Modell + Inline-Panel)** | `dev/b5-umsetzungshinweise` | A1 | S (Code) | 🧩 C6 | -| **B6 Versionierung/Propagation** | `dev/b6-versionierung` | B4 | M–L | – | -| **B7 Assessment-Readiness & Export (Schritt 9)** | `dev/b7-readiness-export` | A7, A8 | L | 🧩 C9 | - -**B1 — Aufgaben-Modul erweitern.** Das generische `Task`-Modell (heute `policy_approval`) um die Foundation-Felder erweitern; **Auto-Generierung** aus Triggern (Schritt 3/4/6/7/8, Zurückweisung) als **Vorschlag mit Bestätigung**; Ressourcenfelder editierbar; Verknüpfungen Control/Risiko/Dok/Asset; Anzeige/Filter im bestehenden Modul „Aufgaben" (`src/app/(app)/tasks/`). *Akzeptanz:* Trigger erzeugt Aufgabenvorschlag mit korrekten Verknüpfungen/Ressourcen; Bestätigung übernimmt. - -**B2 — Regel-/Mapping-Layer.** Umsetzung der DSL (Foundation #3) als testbare Engine `src/lib/rules/**`: Antwort/Scope/Flag → Klausel-Ein/Ausblendung (Handlebars-Flags erweitern), betroffene Controls/Assets/Risiken, Aufgaben-Trigger. Isoliert + unit-getestet. *Akzeptanz:* Regelauswertung deterministisch, mit Testfällen belegt; Änderung einer Antwort propagiert sichtbar. **🧩 C2** (Antwort→Wirkung-Mapping). - -**B3 — Fragebogen/Fakten (Schritt 2).** Dynamischer, **bedingter Fragebogen**; Antworten als **wiederverwendbare Faktenobjekte** (an vorhandene zentrale Variablen/Stammdaten andocken, ohne die Sperre der zentralen Variablen zu verletzen). Bedingte Sichtbarkeit über B2. *Akzeptanz:* Antworten wiederverwendbar; Änderung propagiert in abhängige Objekte/Platzhalter. **🧩 C2** (Fragenkatalog). - -**B4 — Richtlinien: Import-bei-Aktivierung + manueller Upload + Control-Mapping.** (Explizite Anforderung.) Zwei Wege: -- **(a) Vorlagen-Import bei Modul-Aktivierung:** Wird das **Richtlinien-Modul im Superadmin/Adminportal aktiviert**, wird das Vorlagenpaket **mandantenweit importiert** — die vorhandene **nicht-destruktive** Logik (`prisma/import-policies.ts`, Diff/Upsert/`archivedAt`) als **serverseitig auslösbare Aktion/Job** kapseln (statt nur CLI/Seed). Zusätzlich Button „Vorlagen importieren/aktualisieren" (Admin bzw. `/policies`). Idempotent, Änderungsreport. -- **(b) Manueller Upload eigener Richtlinien direkt im Menü `/policies`:** Einstiegspunkt + Metadaten-/Block-Modell + **Control-Zuordnung** jetzt bauen; **Datei-Persistenz über einen Storage-Adapter-Interface stubben** (echtes Storage-Backend = Folge-Epic **S1**, außerhalb dieses Batches). Upload erfasst Datei-Referenz/Platzhalter + Control-Mapping in die Nachweislage. *Akzeptanz:* Modul-Aktivierung importiert Vorlagen nicht-destruktiv; unter `/policies` existiert „Eigene Richtlinie hochladen" mit Control-Zuordnung; Storage-Adapter ist gekapselt und später ohne UI-Änderung verdrahtbar. **🧩 C3** (regelfähige Vorlagen-Auszeichnung). - -**B5 — Umsetzungshinweise (Content-Modell + Inline-Panel).** Strukturiertes Hinweis-Modell (org/tech/Nachweise/Vorlagen-Verweis/**Ressourcenindikation**), Scope-/Antwort-Filter (B2), kontextsensitives Inline-Panel an Teilanforderungen/Risiken/Templates. Code klein — **Inhalt ist der Aufwand**. *Akzeptanz:* passende Hinweise werden nach Scope/Antworten gefiltert eingeblendet; führen bei Maßnahme zu Aufgabe (B1). **🧩 C6**. - -**B6 — Versionierung/Propagation.** Versionierung von Katalog/Templates/Risiko-Katalog + **Instanz-Referenz auf genutzte Version** + **Diff & gesteuerte Übernahme** bei Updates (löst zugleich den heute noch offenen Richtlinien-Diff und flankiert den nicht-destruktiven Re-Import). *Akzeptanz:* laufende Kundeninstanz bekommt bei Update einen Diff und übernimmt kontrolliert; nichts wird still überschrieben. - -**B7 — Assessment-Readiness & Export (Schritt 9).** Reifegrad-Dashboard je Kapitel/gesamt, vorausgefüllte **VDA-ISA-Katalogsicht**, Maßnahmenplan; „bestätigt vs. unbestätigt" nach Validierungsstatus (A3); **Export** (koppelt an den offenen DOCX/PDF-Export). *Akzeptanz:* Kennzahlen stimmen mit Einzelbewertungen; Export vollständig/nachvollziehbar. **🧩 C9** (Auswertungs-/Interpretationstexte, Export-Layout). - ---- - -## 4. Sequenz / Meilensteine (2 Lanes im Takt) - -| Takt | Dev A (Lane A) | Dev B (Lane B) | Gate | -|---|---|---|---| -| **M0** | Foundation-Contracts (gemeinsam) | Foundation-Contracts (gemeinsam) | Contracts + `tasks`-Migration auf `dev` | -| **M1** | A1 Wizard-Shell | B1 Tasks-Erweiterung · B2 Regel-Engine (Kern) | Shell + Task-API stehen | -| **M2** | A2 Scoping/Admin-AL | B4 Richtlinien-Import/Upload · B3 Fragebogen | AL zentral · Import läuft | -| **M3** | A3 Validierung · A4 Rollen | B5 Umsetzungshinweise | Review generisch | -| **M4** | A5 Assets · A6 Risiko-Katalog | B6 Versionierung | Katalog/Risiko nutzbar | -| **M5** | A7 Control-Assessment (SoA) | (Puffer/Review A7) · Start B7 | Kern-Bewertung steht | -| **M6** | A8 Gap-Konsolidierung | B7 Readiness & Export | North-Star: Readiness-Export | - -**Kürzester Pfad zur Assessment-Readiness:** M0→M1→M2→…→M6. Governance (A3/B1/B5/B6) läuft bewusst mit, nicht am Ende. - ---- - -## 5. Explizite Anforderungen (Kurz-Referenz) -- **AL2/AL3 zentral im Adminportal:** → **A2** (einzige Quelle im Superadmin/Admin; Scoping liest read-only; treibt Coverage/AL3-Zusatzanforderungen). -- **Richtlinien-Vorlagen-Import bei Modul-Aktivierung + manueller Upload im Menü:** → **B4** (Import nicht-destruktiv on-enable; manueller Upload jetzt als UI/Modell/Control-Mapping, Datei-Speicher via Storage-Adapter später = Folge-Epic **S1**). - -## 6. Außerhalb dieses Batches (Folge-Epics) -- **S1 Storage-Backend** (Coolify-Volume/MinIO) — schaltet echten Datei-Upload (B4b, Netzplan REG-NET, Nachweis-Upload) scharf. -- **Paket 4** (SMTP/Einladung), **NIS2-Modul**, **Admin Phase 2** (Impersonation/Plan-Limits) — unverändert im Backlog. - ---- - -## 7. Nächster Schritt -Foundation-Contracts (Abschnitt 1) gemeinsam finalisieren und mergen → dann Lanes starten. Fachliche Zulieferung C1–C9 parallel anstoßen (siehe `Berater-Anweisung-Fachcontent.md`), sonst werden C2/C3/C4/C5/C6 zum kritischen Pfad für A2/A6/A7 und B2/B3/B4/B5. diff --git a/docs/wizard-uebergabe/01_Planung/Wizard-Stories.md b/docs/wizard-uebergabe/01_Planung/Wizard-Stories.md deleted file mode 100644 index db16b44..0000000 --- a/docs/wizard-uebergabe/01_Planung/Wizard-Stories.md +++ /dev/null @@ -1,174 +0,0 @@ -# Onboarding-Wizard — Story-Backlog (umsetzungsreif, mit Fachcontent C1–C9) - -Basis: `Wizard-Entwickler-Backlog.md` (2 Lanes) + Fachcontent `Fachcontent_Wizard_C1-C9` + Dev-Stand `dev` (2026-07-24). -Jede Story: **ID · Titel · (Lane/Branch) · User Story · Akzeptanzkriterien · Technik/Dateien · Fachcontent · Abhängigkeit**. - -**Konventionen (für alle Stories):** DoD wie im Backlog (§0: `tsc`+`lint`+`build`/Guard-Check, `TENANT_MODELS`+RLS, Migration+RLS-DO-Block, `_verify.py`→OK bei Seed-Änderung, Browser-Verifikation). Story-Größe: S/M/L. -**Fachcontent-Referenzen:** C1 = Scoping/AL-Tabelle (412 Anf.), C2 = Fragenkatalog+Wirkung, C3 = Vorlagen-Annotation, C4 = Risikokatalog (39 Risiken), C5 = Reifegrad R0–R3, C6 = Umsetzungshinweise (~397 Blöcke), C7 = Rollen/FT-01…06, C8 = Priorisierung/Dedup, C9 = Auswertung/Export. - ---- - -## F — Foundation-Contracts (`dev/foundation-contracts`, gemeinsam, zuerst mergen) - -### F1 — Aufgaben-Objekt-Schema erweitern (M) -**Als** Entwickler **möchte ich** das bestehende `Task`/`TaskComment`-Modell um Wizard-Felder erweitern, **damit** alle Schritte Aufgaben einheitlich erzeugen. -- **AK:** `Task` besitzt `type` (`document_create|evidence_provide|technical|organizational|validation`), `owner`, `dueDate`, `priority`, `status`, `resources` (JSON: tool/budget/personnel/time), `origin` (Schritt), polymorphe Verknüpfung `control|risk|document|asset`. Bestehender Typ `policy_approval` bleibt lauffähig. -- **Technik:** `prisma/schema.prisma` (`Task`), Migration `tasks_wizard_fields`, `TENANT_MODELS`+RLS, `src/server/actions/tasks.ts` erweitern (in `check-module-guards.ts` registriert). -- **Fachcontent:** C2 §8 (Task-Trigger), C8 (Priorität/Dedup als Feldsemantik). - -### F2 — Einheitlicher Objekt-Validierungsstatus + externe-Validierer-Rolle (M) -**Als** ISB/Berater **möchte ich** jedes bewertbare Objekt gleich validieren. -- **AK:** wiederverwendbares Status-Feld `offen|in_bearbeitung|zur_validierung|validiert|zurueckgewiesen(+Kommentar)`; Rolle `external_validator` in RBAC; „unbestätigt zählt nicht" ist als Query-Helfer verfügbar. -- **Technik:** Mixin/Enum in `schema.prisma`; RBAC-Recht; baut auf `submitForApproval`/`tasks.ts`. -- **Fachcontent:** C5 (Validierungsstatus je Beleg), C9 (bestätigt/unbestätigt). - -### F3 — Regel-/Mapping-DSL-Vertrag (M) -**Als** Entwickler **möchte ich** einen testbaren Regel-Vertrag, **damit** Antworten/Scope/Flags Wirkungen auslösen. -- **AK:** JSON-Schema `Bedingung(Antwort|Scope|Flag) → Wirkung(Klausel|Control|Risiko|Asset|Aufgabe)`; Referenz-Testfälle aus C2 §5 (Q-FEAT-01…10) grün. -- **Technik:** `src/lib/rules/dsl.ts` (Typen) + Unit-Test-Harness. Noch keine UI. -- **Fachcontent:** C2 (Wirkungsmatrix), C1 (Scope-Bedingung-Spalte). - -### F4 — Wizard-Variablen/Flags erweitern (`variables.schema.json`) (S) -**Als** Content-Owner **möchte ich** neue Flags/Variablen registriert haben, **damit** `_verify.py` sie kennt. -- **AK:** `FLAG_PROTOTYPE_PROTECTION`, `FLAG_ISB_EXTERNAL`, `FLAG_ISB_INTERNAL` + fehlende `ROLE_*`/`TECH_*` aus C2 ergänzt; `python3 _verify.py` → **OK**. -- **Technik:** `seed/isms-vorlagenpaket-v2/variables.schema.json`. -- **Fachcontent:** C0 (offene Punkte 2), C2 §3–6, C7 §3. **Abh.:** vor B2/B3/B4/A4. - ---- - -## Lane A — Dev A - -### A1 — Wizard-Shell & Navigation (`dev/a1-wizard-shell`) -**A1-1 Step-Registry & State-Machine (L).** Multi-Step-Flow mit Fortschritt, Gates, Wiederaufnahme; Schritte als registrierbare Module. -- **AK:** Fortschritt je Mandant persistent; ein Gate blockiert „weiter", bis das Vorgänger-Objekt `validiert` ist (F2); Steps sind per Registry einklinkbar (Lane B liefert Step-Inhalte). -- **Technik:** `src/app/(app)/onboarding/**`, `src/server/actions/onboarding.ts`, neues Modul `onboarding` in `src/lib/modules.ts`; Migration `onboarding_progress`. -**A1-2 Fortschritts-/Status-Dashboard-Kachel (S).** Kachel „Onboarding-Fortschritt" analog vorhandener Dashboard-Kachel. - -### A2 — Scoping + AL2/AL3 zentral im Adminportal (`dev/a2-scoping-admin-al`) -**A2-1 AL2/AL3 zentral im Admin/Superadmin (M).** *(Explizite Anforderung.)* -- **AK:** Der Assessment-Level (AL2/AL3) wird **ausschließlich** im Admin-/Superadmin-Portal je Mandant gesetzt (einzige Quelle); im Scoping read-only; treibt bestehende Coverage-Filter + `FLAG_HIGH/VERY_HIGH_PROTECTION`. -- **Technik:** `src/app/(platform)/admin/**`, `src/server/actions/admin.ts`/`platform.ts`; Mandanten-`/settings` verliert die Änderungs-Kompetenz (nur Anzeige). -**A2-2 Scope-Objekt + Filter-Engine (M).** -- **AK:** Scoping erfasst Prüfziele (IS/Prototyp/Datenschutz), Standorte, Geltungsbereich, Ausschlüsse → Scope-Objekt; Filter blendet Anforderungen nach **AL + Flag + Prüfziel** exakt gemäß C1 aus (z. B. `HOCH` nur bei `FLAG_HIGH_PROTECTION`; 8.x nur bei Prototyp). -- **Technik:** Scope-Modell + `src/lib/scope-filter.ts`; Import der C1-Tabelle als Datenquelle je Anforderung. -- **Fachcontent:** **C1** (AL2/AL3 + Prüfziel + Scope-Bedingung je Anforderung, 412 Zeilen). **Abh.:** F3, A1. - -### A3 — Validierungs-Workflow generalisieren (`dev/a3-validation-workflow`) -**A3-1 Generisches Objekt-Review (M).** -- **AK:** Richtlinie/Risiko/Control-Bewertung/Modul tragen Review-Status (F2); Reviewer-Zuweisung inkl. `external_validator`; Kommentare; Auswertung zählt nur `validiert`. -- **Technik:** Ausbau `src/server/actions/tasks.ts` + `submitForApproval`; generische Review-Komponente. -- **Fachcontent:** C9 §1 (bestätigt/unbestätigt). **Abh.:** F1, F2. - -### A4 — ISMS-Rollen & Funktionstrennung (`dev/a4-isms-rollen`) -**A4-1 Rollenmodell + Platzhalter (M).** -- **AK:** Rollen `ROLE_MANAGEMENT/ISB/IT_LEAD/HR_LEAD/DPO` erfassbar (aus C2 Abschnitt B), befüllen Vorlagen-Platzhalter; ISB-Bestellung aus Vorlage generierbar. -- **Technik:** Rollen-Modell; Anbindung zentrale Variablen (`src/lib/policy-variables.ts`). -**A4-2 Funktionstrennungs-Prüfung FT-01…06 (M).** -- **AK:** Regeln **FT-01…FT-06** aus C7 implementiert; Konflikt/Lücke → Hinweis + Aufgabe (F1); Option „Trennung herstellen" **oder** „kompensierende Kontrolle dokumentieren". -- **Fachcontent:** **C7** (Rollen, FT-Regeln, `VA-00_ISB-Bestellung.md`, Flags `FLAG_ISB_EXTERNAL/INTERNAL`). **Abh.:** F4, A3. - -### A5 — Asset-Anbindung Wizard (`dev/a5-assets-step`) -**A5-1 Asset-Schritt auf Bestandsmodul (S).** -- **AK:** Schritt 5 nutzt vorhandenes Assets/BIA (C/I/A, Schutzbedarf, Eigentümer); Trigger „unvollständig/kein Eigentümer" → Aufgabe (F1). Keine Doppel-Datenhaltung. - -### A6 — Risiko-Katalog & Anbindung (`dev/a6-risiko-katalog`) -**A6-1 Risiko-Katalog-Datenmodell + Import (M).** -- **AK:** 39 Katalog-Risiken (11 Kategorien) importiert mit ID `R--`, Controls, Asset-Typen, Standardmaßnahmen, Default `E/S`; erweiterbar; „nicht anwendbar"-Begründung möglich. -- **Technik:** Risiko-Katalog-Seed + Auswahl-UI im vorhandenen Risikomodul; 5×5 wie C4. -**A6-2 Maßnahme → Aufgabe + Restrisiko (M).** -- **AK:** ausgewähltes Risiko → Bewertung (5×5) → Behandlung → Standardmaßnahme erzeugt Aufgabe (F1), verknüpft Risiko+Control; Restrisiko > Akzeptanz erfordert dokumentierte Akzeptanz (VA-09). -- **Fachcontent:** **C4** (Katalog + Bewertungslogik + Standardmaßnahmen). **Abh.:** F1, B2. - -### A7 — Control-Assessment & Reifegrad/Gap (`dev/a7-control-assessment`, SoA) -**A7-1 Control-/SoA-Oberfläche (L).** -- **AK:** je relevantem Control: Belege verknüpfen (Dok/Risiko/Asset), Teilanforderungen sichtbar (aus C1/`mapping.json`), offene Teilanforderungen markiert; Inline-Umsetzungshinweise (B5/C6). -**A7-2 Reifegrad-Engine R0–R3 + Pflichtbestätigung (L).** -- **AK:** Reifegrad-Vorschlag exakt nach **C5**-Regeln (R0/R1a-c/R2/R3, Sonderfälle, Aktualitätsregel ≤12 Mon., Deckelung bei Widerspruch); Vorschlag ist **an Belege gekoppelt und nachvollziehbar**; Bearbeiter-Bestätigung Pflicht; Zielreifegrad nach C5 §3 (AL2→2, AL3→3, HOCH/SEHR HOCH→3). -- **AK:** Reifegrad < Ziel / offene Teilanforderung → Aufgabe (F1). -- **Technik:** `src/app/(app)/soa/**` (bislang Platzhalter) + `src/server/actions/soa.ts`; Reifegrad-Berechnung `src/lib/maturity.ts` (unit-getestet gegen C5-Beispiele). -- **Fachcontent:** **C5** (Reifegradlogik), **C6** (Umsetzungshinweise). **Abh.:** A2, B1, B2, B5. - -### A8 — Gap-Konsolidierung (`dev/a8-gap-konsolidierung`) -**A8-1 Aggregation + Dedup + Priorisierung (M).** -- **AK:** offene Punkte aus Schritt 6/7 zusammengeführt; **Dedup-Schlüssel** (Control+Teilanforderung / verknüpfte Aufgabe) nach C8 §2; Priorität **Hoch/Mittel/Niedrig** nach C8 §1 mit Zusatzsortierung (betroffene Controls, Risikohöhe, Aufwand); keine Dopplungen; jeder Punkt hat Priorität + ggf. Aufgabe. -**A8-2 Quick-Win-Kennzeichnung (S).** -- **AK:** Quick-Win-Kriterien aus C8 §3; im Maßnahmenplan hervorgehoben („erst Quick-Wins"). -- **Fachcontent:** **C8**. **Abh.:** A6, A7, B1. - ---- - -## Lane B — Dev B - -### B1 — Aufgaben-Modul erweitern (`dev/b1-tasks-erweiterung`) -**B1-1 Auto-Generierung mit Bestätigung (M).** -- **AK:** Trigger aus Schritt 3/4/6/7/8 + Zurückweisung erzeugen **Aufgabenvorschlag** (Typ/Verknüpfung/Ressourcen aus F1); Bearbeiter bestätigt/verwirft; Anzeige/Filter im Modul „Aufgaben" (`src/app/(app)/tasks/`). -- **Fachcontent:** C2 §8 (konkrete Trigger). **Abh.:** F1. - -### B2 — Regel-/Mapping-Engine (`dev/b2-regel-engine`) -**B2-1 Engine-Kern + Klausel-Flags (L).** -- **AK:** DSL (F3) ausgewertet: Antwort/Scope/Flag → Klausel ein/aus (Handlebars-Flags), Control-Relevanz, Risiko-/Asset-Bezug, Aufgabe; deterministisch, unit-getestet gegen **C2** Q-FEAT-01…10. -- **Technik:** `src/lib/rules/**`; koppelt an vorhandene `{{#if FLAG}}`-Renderer + Lieferanten-Anforderungs-Engine. -**B2-2 Propagation bei Antwortänderung (M).** -- **AK:** Änderung einer Antwort propagiert sichtbar in abhängige Objekte/Platzhalter/Controls. -- **Fachcontent:** **C2** (Wirkungsmatrix), C1 (Scope-Bedingungen). **Abh.:** F3, F4. - -### B3 — Fragebogen/Fakten (`dev/b3-fragebogen`) -**B3-1 Dynamischer, bedingter Fragebogen (M).** -- **AK:** Abschnitte A–F aus C2 mit Antworttypen + Anzeige-Bedingungen; Antworten als wiederverwendbare Faktenobjekte; Baseline-Fragen (E) als vorbelegte Defaults aus `Technische-Sicherheits-Baseline.md` (nur bestätigen). -- **AK:** zentrale Variablen bleiben serverseitig gesperrt (nur `/settings`), Fragebogen respektiert das. -- **Technik:** `src/app/(app)/onboarding/steps/context/**` (im A1-Registry); Faktenmodell + Migration. -- **Fachcontent:** **C2** (Fragen A–F, Baseline-Defaults). **Abh.:** A1, B2, F4. - -### B4 — Richtlinien: Import-bei-Aktivierung + manueller Upload + Control-Mapping (`dev/b4-richtlinien-import-upload`) -**B4-1 Vorlagen-Import bei Modul-Aktivierung (M).** *(Explizite Anforderung.)* -- **AK:** Aktiviert der Superadmin das Richtlinien-Modul, wird das Paket mandantenweit **nicht-destruktiv** importiert (bestehende Logik `prisma/import-policies.ts` als Server-Action/Job gekapselt); Button „Vorlagen importieren/aktualisieren" in Admin und `/policies`; idempotent, Änderungsreport. -**B4-2 Manueller Upload eigener Richtlinien im Menü (M).** *(Explizite Anforderung; Storage später.)* -- **AK:** unter `/policies` „Eigene Richtlinie hochladen" mit **Pflicht-Control-Zuordnung** (Multi-Select Control-Katalog, optional Anforderungs-IDs, siehe C3 §4); Metadaten/Block-Modell angelegt; Datei-Persistenz über gestubbtes **Storage-Adapter-Interface** (echtes Backend = Folge-Epic S1); Zuordnung fließt als ``-Äquivalent in die Nachweislage (Schritt 7). -**B4-3 Proto/DS-Vorlagen P01/D01 + mapping.json (M).** -- **AK:** neue Vorlagen `P01_Prototypenschutz.md` (+ `VA-20`) und `D01_Datenschutz.md` nach C3-Konvention angelegt; `mapping.json`-Einträge im gleichen Schema (8.x/9.x); `FLAG_PROTOTYPE_PROTECTION` genutzt; `_verify.py` (um neue Anker erweitert) → **OK**. -- **Fachcontent:** **C3** (Annotationskonvention + P01/D01), C1/C6 (Dekomposition 8.x/9.x). **Abh.:** F4. - -### B5 — Umsetzungshinweise (`dev/b5-umsetzungshinweise`) -**B5-1 Hinweis-Datenmodell + Import (S Code).** -- **AK:** Hinweis-Objekt je Teilanforderung mit Feldern **organisatorisch/technisch/Nachweise/Vorlage/Ressourcen/AL-Filter**; Import der ~397 C6-Blöcke; Baseline-Referenzen (`BL-*`) statt harter Werte. -**B5-2 Kontextsensitives Inline-Panel (S).** -- **AK:** Panel an Teilanforderung/Risiko/Template; gefiltert nach Scope/Antworten (B2) und AL; Ressourcen-Hinweis mit Beschaffungsbedarf → Aufgabe (F1). -- **Fachcontent:** **C6** (Hinweise), C0 offener Punkt 3 (Baseline-Codes vor Verdrahtung gegen `Technische-Sicherheits-Baseline.md` normalisieren). **Abh.:** A1. - -### B6 — Versionierung/Propagation (`dev/b6-versionierung`) -**B6-1 Versionierung Katalog/Templates/Risiko + Instanz-Referenz (M).** -- **AK:** Kundeninstanz referenziert genutzte Template-/Katalog-Version; Änderungen erzeugen Diff. -**B6-2 Gesteuerte Übernahme (Diff) (M).** -- **AK:** bei Update erhält die Instanz einen Diff mit kontrollierter Übernahme; nichts wird still überschrieben (ergänzt nicht-destruktiven Re-Import + löst offenen Richtlinien-Diff). **Abh.:** B4. - -### B7 — Assessment-Readiness & Export (`dev/b7-readiness-export`) -**B7-1 Reifegrad-Dashboard + Interpretationstexte (M).** -- **AK:** Aggregation je Kapitel/gesamt (Ø, „unbestätigt zählt nicht"); Textbänder nach C9 §1; Kennzahlen (Anteil bestätigt, offene Punkte je Priorität, Abdeckung je Prüfziel); dynamische „nächste Schritte" (C9 §2). -**B7-2 VDA-ISA-Katalog-Export (L).** -- **AK:** Export-Layout exakt nach **C9 §3** (Felder Control-ID/Frage/Reifegrad/Status/Umsetzungsbeschreibung MUSS→SOLL→HOCH→SEHR HOCH/Belege/offene Punkte); Reihenfolge IS→Proto→DS; „unbestätigt" markiert; **XLSX** (Katalog+Kennzahlen) + DOCX/PDF-Management-Summary (koppelt an bestehenden Export); Zusatzartefakte (Maßnahmenplan, Nachweisregister) nach C9 §4. -- **Fachcontent:** **C9**. **Abh.:** A7, A8. - ---- - -## Content-Integration & offene Fachpunkte (aus C0) - -| ID | Story | Owner | Abh. | -|---|---|---|---| -| **X1** | Neue `FLAG_*`/Variablen in `variables.schema.json` (siehe F4) | B (mit SME) | vor B2/B3/B4/A4 | -| **X2** | P01/D01 + `VA-20` Vorlagen + `mapping.json`-Einträge (B4-3) | B (mit SME) | C3 | -| **X3** | Baseline-`BL-*`-Codes aus C6 gegen `Technische-Sicherheits-Baseline.md` normalisieren | B5 (mit SME) | vor B5-Verdrahtung | -| **X4** | ISB-Freigabe aller neuen/angepassten Fachtexte (VA/Richtlinien/P01/D01) | ISB (fachlich, kein Code) | vor Produktivsetzung | - ---- - -## Sprint-Vorschlag (2 Lanes) - -- **Sprint 0:** F1–F4 (gemeinsam) → mergen. -- **Sprint 1:** A1 · B1 + B2-1. -- **Sprint 2:** A2 (+C1) · B4 (+C3) + B3 (+C2). -- **Sprint 3:** A3 · A4 (+C7) · B5 (+C6). -- **Sprint 4:** A5 · A6 (+C4) · B6. -- **Sprint 5:** A7 (+C5/C6). -- **Sprint 6:** A8 (+C8) · B7 (+C9). - -> „Definition of Ready" je Story: zugehöriges C-Paket eingespielt und (wo Seed) `_verify.py` → **OK**. Fehlt der Fachcontent, bleibt die Story blockiert (kritischer Pfad: C2 → C1/C3 → C5/C6). diff --git a/docs/wizard-uebergabe/02_Fachcontent_C1-C9/C0_README-Fachcontent-Uebersicht.md b/docs/wizard-uebergabe/02_Fachcontent_C1-C9/C0_README-Fachcontent-Uebersicht.md deleted file mode 100644 index 9ef5d44..0000000 --- a/docs/wizard-uebergabe/02_Fachcontent_C1-C9/C0_README-Fachcontent-Uebersicht.md +++ /dev/null @@ -1,35 +0,0 @@ -# Fachcontent-Zulieferung C1–C9 — Übersicht - -Fachliche Zulieferung (SME/Berater) für den Onboarding-Wizard, gemäß `BeraterAnweisungFachcontent.md` und `WizardEntwicklerBacklog.md`. Alle Pakete sind ID-konsistent zum bestehenden Vorlagenpaket `isms-vorlagenpaket-v2` (`mapping.json`, `variables.schema.json`, Baseline `BL-*`). Prüfziele: Informationssicherheit (Paketbasis), Prototypenschutz (8.x) und Datenschutz (9.x) als Erweiterung. - -## Lieferpakete - -| WP | Datei | Schaltet frei (Backlog) | Inhalt | -|---|---|---|---| -| **C1** | `C1_Scoping-AL-Pruefziel.md` | A2 | AL2/AL3-Kennzeichnung + Prüfziel + Scope-Bedingung je Anforderung — **412 Anforderungen** (316 IS + 72 Proto + 24 DS) | -| **C2** | `C2_Fragenkatalog-Wirkung.md` | B2, B3 | Fragenkatalog (A–F) + Antwort→Wirkung (Variable/Flag/Control/Risiko/Aufgabe), gekoppelt an `variables.schema.json` | -| **C3** | `C3_Vorlagen-Annotation.md` | B4 | Annotationskonvention (REQ/IMPL-Anker, `{{#if FLAG}}`, Baseline-Variablen), Ist-Bestätigung (`_verify.py → OK`), Erweiterung P01/D01 | -| **C4** | `C4_Risikokatalog.md` | A6 | Standard-/VDA-Risiko-Katalog (**39 Risiken, 11 Kategorien**) mit Controls, Assets, Standardmaßnahmen, Default-5×5-Einschätzung | -| **C5** | `C5_Reifegradlogik.md` | A7 | Generische Beleg→Reifegrad-Regel + control-spezifische Tabelle (alle 45 IS-Controls + Proto/DS-Gruppen), Zielreifegrad, Offene-Punkt-Kriterium | -| **C6** | `C6_Umsetzungshinweise.md` | B5, A7 | Umsetzungshinweise je Teilanforderung (**~397 Blöcke über 79 Controls**): org/tech, Nachweise, Vorlage, Ressourcen, AL-Filter | -| **C7** | `C7_Rollen-Funktionstrennung.md` | A4 | Soll-Rollenmodell, Funktionstrennungs-Regeln (FT-01…06), ISB-Bestellungs-Vorlage im Paket-Stil | -| **C8** | `C8_Priorisierung-Gap.md` | A8 | Prioritätsregeln (Hoch/Mittel/Niedrig), Dedup-Kriterien, Quick-Win-Definition | -| **C9** | `C9_Auswertung-Export.md` | B7 | Reifegrad-Interpretationstexte, nächste Schritte, VDA-ISA-Export-Layout (bestätigt/unbestätigt) | - -## Konsistenz-Anker - -- **Anforderungs-IDs** = `mapping.json`-IDs (z. B. `4.1.2-H1`); Proto/DS neu im gleichen Schema (`8.1.1-M1`, `9.1.1-M1`). -- **Flags/Variablen** = `variables.schema.json` (Single Source of Truth). Neue Flags (`FLAG_PROTOTYPE_PROTECTION`, `FLAG_ISB_EXTERNAL/INTERNAL`) sind in C3/C7 vermerkt und dort zuerst zu ergänzen. -- **Technische Werte** = Baseline `BL-*` (C6 referenziert, nie hart kodiert). -- **Vorlagenpaket** unverändert; `python3 seed/isms-vorlagenpaket-v2/_verify.py` → **OK**. - -## Offene Punkte / Abhängigkeiten für die Umsetzung - -1. **Proto/DS-Vorlagen** (`P01`, `D01`) und zugehörige `mapping.json`-Einträge sind noch anzulegen (C3 Abschnitt 3) — die Anforderungsdekomposition + Hinweise (C1/C5/C6) liegen bereits vor. -2. **Neue `FLAG_*`** vor Nutzung in `variables.schema.json` ergänzen, damit `_verify.py` sie kennt. -3. **Baseline-IDs in C6**: Agenten haben teils sprechende `BL-*`-Codes ergänzt, die über den dokumentierten Satz (BL-IAM/CRY/OPS/NET/EP/PHY/HR/SUP/DEL/GOV/PROJ) hinausgehen — vor Verdrahtung gegen `Technische-Sicherheits-Baseline.md` normalisieren. -4. **ISB-Freigabe** der neuen/angepassten Fachtexte ist der abschließende fachliche Schritt (steht im Backlog offen auf `dev`). - -## Reihenfolge (kritischer Pfad) - -C2 → C1/C3 (schalten B2/B3 und A2/B4 frei) → C4/C5/C6 (A6/A7/B5) → C7/C8/C9. Entspricht der Meilenstein-Sequenz M0–M6 des Backlogs. diff --git a/docs/wizard-uebergabe/02_Fachcontent_C1-C9/C1_Scoping-AL-Pruefziel.md b/docs/wizard-uebergabe/02_Fachcontent_C1-C9/C1_Scoping-AL-Pruefziel.md deleted file mode 100644 index 85b94a4..0000000 --- a/docs/wizard-uebergabe/02_Fachcontent_C1-C9/C1_Scoping-AL-Pruefziel.md +++ /dev/null @@ -1,444 +0,0 @@ -# C1 — Scoping-Grundlage: AL2/AL3-Kennzeichnung + Prüfziel-Zuordnung je Anforderung - -> **Schaltet frei:** A2 (Scoping / Admin-AL / Scope-Filter). **Grundlage:** `mapping.json` (Informationssicherheit, 316 Anforderungen) + Prototypenschutz/Datenschutz-Dekomposition (Erweiterung). - -## Methodik (Zuordnungslogik) - -Der Assessment-Level (AL) wird **zentral im Adminportal** gesetzt (Backlog A2) und ist read-only im Scoping. Die Zuordnung folgt der VDA-ISA-/TISAX-Systematik: - -- **MUSS / SOLL** → Bestandteil von **AL2 und AL3** (Grundabsicherung; SOLL über `FLAG_INCLUDE_SHOULD` für Ziel-Reifegrad 3). -- **HOCH** (Zusatz hoher Schutzbedarf) → relevant bei **hohem Schutzbedarf** (typisch AL3), Flag `FLAG_HIGH_PROTECTION`. -- **SEHR HOCH** (Zusatz sehr hoher Schutzbedarf) → relevant bei **sehr hohem Schutzbedarf** (AL3), Flag `FLAG_VERY_HIGH_PROTECTION`. -- **Prüfziel** steuert, ob ein ganzes Kapitel überhaupt im Scope ist (Informationssicherheit / Prototypenschutz / Datenschutz). -- **Scope-Bedingung** = das Feature-Flag bzw. die Bedingung aus `mapping.json` (`condition`); ist keine gesetzt, gilt „immer im Scope" (sobald das Prüfziel aktiv ist). - -Der Scope-Filter (A2) blendet je nach AL + Flags + Prüfziel die nicht relevanten Anforderungen aus. Spalte „Scope-Bedingung" ist maschinenlesbar an die `FLAG_*` aus `variables.schema.json` gekoppelt. - -## Prüfziel Informationssicherheit (316 Anforderungen) - -| Control | Anforderungs-ID | Typ | AL2 | AL3 | Prüfziel | Scope-Bedingung (Flag) | -|---|---|---|:--:|:--:|---|---| -| 1.1.1 | 1.1.1-M1 | MUSS | Ja | Ja | Informationssicherheit | immer im Scope | -| 1.1.1 | 1.1.1-M2 | MUSS | Ja | Ja | Informationssicherheit | immer im Scope | -| 1.1.1 | 1.1.1-M3 | MUSS | Ja | Ja | Informationssicherheit | immer im Scope | -| 1.1.1 | 1.1.1-M4 | MUSS | Ja | Ja | Informationssicherheit | immer im Scope | -| 1.1.1 | 1.1.1-M5 | MUSS | Ja | Ja | Informationssicherheit | immer im Scope | -| 1.1.1 | 1.1.1-S1 | SOLL | Ja | Ja | Informationssicherheit | `FLAG_INCLUDE_SHOULD` | -| 1.1.1 | 1.1.1-S2 | SOLL | Ja | Ja | Informationssicherheit | `FLAG_INCLUDE_SHOULD` | -| 1.1.1 | 1.1.1-S3 | SOLL | Ja | Ja | Informationssicherheit | `FLAG_INCLUDE_SHOULD` | -| 1.1.1 | 1.1.1-S4 | SOLL | Ja | Ja | Informationssicherheit | `FLAG_INCLUDE_SHOULD` | -| 1.2.1 | 1.2.1-M1 | MUSS | Ja | Ja | Informationssicherheit | immer im Scope | -| 1.2.1 | 1.2.1-M2 | MUSS | Ja | Ja | Informationssicherheit | immer im Scope | -| 1.2.1 | 1.2.1-M3 | MUSS | Ja | Ja | Informationssicherheit | immer im Scope | -| 1.2.1 | 1.2.1-M4 | MUSS | Ja | Ja | Informationssicherheit | immer im Scope | -| 1.2.1 | 1.2.1-M5 | MUSS | Ja | Ja | Informationssicherheit | immer im Scope | -| 1.2.1 | 1.2.1-M6 | MUSS | Ja | Ja | Informationssicherheit | immer im Scope | -| 1.2.2 | 1.2.2-M1 | MUSS | Ja | Ja | Informationssicherheit | immer im Scope | -| 1.2.2 | 1.2.2-M2 | MUSS | Ja | Ja | Informationssicherheit | immer im Scope | -| 1.2.2 | 1.2.2-M3 | MUSS | Ja | Ja | Informationssicherheit | immer im Scope | -| 1.2.2 | 1.2.2-M4 | MUSS | Ja | Ja | Informationssicherheit | immer im Scope | -| 1.2.2 | 1.2.2-S1 | SOLL | Ja | Ja | Informationssicherheit | `FLAG_INCLUDE_SHOULD` | -| 1.2.2 | 1.2.2-S2 | SOLL | Ja | Ja | Informationssicherheit | `FLAG_INCLUDE_SHOULD` | -| 1.2.2 | 1.2.2-H1 | HOCH | – | Ja | Informationssicherheit | `FLAG_HIGH_PROTECTION` | -| 1.2.3 | 1.2.3-M1 | MUSS | Ja | Ja | Informationssicherheit | immer im Scope | -| 1.2.3 | 1.2.3-S1 | SOLL | Ja | Ja | Informationssicherheit | `FLAG_INCLUDE_SHOULD` | -| 1.2.3 | 1.2.3-S2 | SOLL | Ja | Ja | Informationssicherheit | `FLAG_INCLUDE_SHOULD` | -| 1.2.3 | 1.2.3-S3 | SOLL | Ja | Ja | Informationssicherheit | `FLAG_INCLUDE_SHOULD` | -| 1.2.3 | 1.2.3-H1 | HOCH | – | Ja | Informationssicherheit | `FLAG_HIGH_PROTECTION` | -| 1.3.1 | 1.3.1-M1 | MUSS | Ja | Ja | Informationssicherheit | immer im Scope | -| 1.3.1 | 1.3.1-M2 | MUSS | Ja | Ja | Informationssicherheit | immer im Scope | -| 1.3.1 | 1.3.1-S1 | SOLL | Ja | Ja | Informationssicherheit | `FLAG_INCLUDE_SHOULD` | -| 1.3.2 | 1.3.2-M1 | MUSS | Ja | Ja | Informationssicherheit | immer im Scope | -| 1.3.2 | 1.3.2-M2 | MUSS | Ja | Ja | Informationssicherheit | immer im Scope | -| 1.3.2 | 1.3.2-M3 | MUSS | Ja | Ja | Informationssicherheit | immer im Scope | -| 1.3.2 | 1.3.2-S1 | SOLL | Ja | Ja | Informationssicherheit | `FLAG_INCLUDE_SHOULD` | -| 1.3.3 | 1.3.3-M1 | MUSS | Ja | Ja | Informationssicherheit | immer im Scope | -| 1.3.3 | 1.3.3-M2 | MUSS | Ja | Ja | Informationssicherheit | immer im Scope | -| 1.3.3 | 1.3.3-S1 | SOLL | Ja | Ja | Informationssicherheit | `FLAG_INCLUDE_SHOULD` | -| 1.3.3 | 1.3.3-S2 | SOLL | Ja | Ja | Informationssicherheit | `FLAG_INCLUDE_SHOULD` | -| 1.3.3 | 1.3.3-S3 | SOLL | Ja | Ja | Informationssicherheit | `FLAG_INCLUDE_SHOULD` | -| 1.3.3 | 1.3.3-S4 | SOLL | Ja | Ja | Informationssicherheit | `FLAG_INCLUDE_SHOULD` | -| 1.3.4 | 1.3.4-M1 | MUSS | Ja | Ja | Informationssicherheit | immer im Scope | -| 1.3.4 | 1.3.4-M2 | MUSS | Ja | Ja | Informationssicherheit | immer im Scope | -| 1.3.4 | 1.3.4-S1 | SOLL | Ja | Ja | Informationssicherheit | `FLAG_INCLUDE_SHOULD` | -| 1.3.4 | 1.3.4-S2 | SOLL | Ja | Ja | Informationssicherheit | `FLAG_INCLUDE_SHOULD` | -| 1.3.4 | 1.3.4-S3 | SOLL | Ja | Ja | Informationssicherheit | `FLAG_INCLUDE_SHOULD` | -| 1.3.4 | 1.3.4-S4 | SOLL | Ja | Ja | Informationssicherheit | `FLAG_INCLUDE_SHOULD` | -| 1.3.4 | 1.3.4-S5 | SOLL | Ja | Ja | Informationssicherheit | `FLAG_INCLUDE_SHOULD` | -| 1.3.4 | 1.3.4-V1 | SEHR HOCH | – | Ja | Informationssicherheit | `FLAG_VERY_HIGH_PROTECTION` | -| 1.4.1 | 1.4.1-M1 | MUSS | Ja | Ja | Informationssicherheit | immer im Scope | -| 1.4.1 | 1.4.1-M2 | MUSS | Ja | Ja | Informationssicherheit | immer im Scope | -| 1.4.1 | 1.4.1-M3 | MUSS | Ja | Ja | Informationssicherheit | immer im Scope | -| 1.4.1 | 1.4.1-M4 | MUSS | Ja | Ja | Informationssicherheit | immer im Scope | -| 1.4.1 | 1.4.1-S1 | SOLL | Ja | Ja | Informationssicherheit | `FLAG_INCLUDE_SHOULD` | -| 1.4.1 | 1.4.1-S2 | SOLL | Ja | Ja | Informationssicherheit | `FLAG_INCLUDE_SHOULD` | -| 1.4.1 | 1.4.1-S3 | SOLL | Ja | Ja | Informationssicherheit | `FLAG_INCLUDE_SHOULD` | -| 1.4.1 | 1.4.1-S4 | SOLL | Ja | Ja | Informationssicherheit | `FLAG_INCLUDE_SHOULD` | -| 1.5.1 | 1.5.1-M1 | MUSS | Ja | Ja | Informationssicherheit | immer im Scope | -| 1.5.1 | 1.5.1-M2 | MUSS | Ja | Ja | Informationssicherheit | immer im Scope | -| 1.5.1 | 1.5.1-M3 | MUSS | Ja | Ja | Informationssicherheit | immer im Scope | -| 1.5.1 | 1.5.1-M4 | MUSS | Ja | Ja | Informationssicherheit | immer im Scope | -| 1.5.1 | 1.5.1-M5 | MUSS | Ja | Ja | Informationssicherheit | immer im Scope | -| 1.5.1 | 1.5.1-S1 | SOLL | Ja | Ja | Informationssicherheit | `FLAG_INCLUDE_SHOULD` | -| 1.5.2 | 1.5.2-M1 | MUSS | Ja | Ja | Informationssicherheit | immer im Scope | -| 1.5.2 | 1.5.2-M2 | MUSS | Ja | Ja | Informationssicherheit | immer im Scope | -| 1.5.2 | 1.5.2-S1 | SOLL | Ja | Ja | Informationssicherheit | `FLAG_INCLUDE_SHOULD` | -| 1.6.1 | 1.6.1-M1 | MUSS | Ja | Ja | Informationssicherheit | immer im Scope | -| 1.6.1 | 1.6.1-M2 | MUSS | Ja | Ja | Informationssicherheit | immer im Scope | -| 1.6.1 | 1.6.1-M3 | MUSS | Ja | Ja | Informationssicherheit | immer im Scope | -| 1.6.1 | 1.6.1-S1 | SOLL | Ja | Ja | Informationssicherheit | `FLAG_INCLUDE_SHOULD` | -| 1.6.1 | 1.6.1-S2 | SOLL | Ja | Ja | Informationssicherheit | `FLAG_INCLUDE_SHOULD` | -| 1.6.1 | 1.6.1-S3 | SOLL | Ja | Ja | Informationssicherheit | `FLAG_INCLUDE_SHOULD` | -| 1.6.1 | 1.6.1-S4 | SOLL | Ja | Ja | Informationssicherheit | `FLAG_INCLUDE_SHOULD` | -| 1.6.1 | 1.6.1-S5 | SOLL | Ja | Ja | Informationssicherheit | `FLAG_INCLUDE_SHOULD` | -| 1.6.1 | 1.6.1-S6 | SOLL | Ja | Ja | Informationssicherheit | `FLAG_INCLUDE_SHOULD` | -| 1.6.1 | 1.6.1-V1 | SEHR HOCH | – | Ja | Informationssicherheit | `FLAG_VERY_HIGH_PROTECTION` | -| 1.6.2 | 1.6.2-M1 | MUSS | Ja | Ja | Informationssicherheit | immer im Scope | -| 1.6.2 | 1.6.2-M2 | MUSS | Ja | Ja | Informationssicherheit | immer im Scope | -| 1.6.2 | 1.6.2-M3 | MUSS | Ja | Ja | Informationssicherheit | immer im Scope | -| 1.6.2 | 1.6.2-S1 | SOLL | Ja | Ja | Informationssicherheit | `FLAG_INCLUDE_SHOULD` | -| 1.6.2 | 1.6.2-S2 | SOLL | Ja | Ja | Informationssicherheit | `FLAG_INCLUDE_SHOULD` | -| 1.6.2 | 1.6.2-S3 | SOLL | Ja | Ja | Informationssicherheit | `FLAG_INCLUDE_SHOULD` | -| 1.6.2 | 1.6.2-H1 | HOCH | – | Ja | Informationssicherheit | `FLAG_HIGH_PROTECTION` | -| 1.6.2 | 1.6.2-H2 | HOCH | – | Ja | Informationssicherheit | `FLAG_HIGH_PROTECTION` | -| 1.6.2 | 1.6.2-H3 | HOCH | – | Ja | Informationssicherheit | `FLAG_HIGH_PROTECTION` | -| 1.6.2 | 1.6.2-H4 | HOCH | – | Ja | Informationssicherheit | `FLAG_HIGH_PROTECTION` | -| 1.6.2 | 1.6.2-H5 | HOCH | – | Ja | Informationssicherheit | `FLAG_HIGH_PROTECTION` | -| 1.6.2 | 1.6.2-V1 | SEHR HOCH | – | Ja | Informationssicherheit | `FLAG_VERY_HIGH_PROTECTION` | -| 1.6.3 | 1.6.3-M1 | MUSS | Ja | Ja | Informationssicherheit | immer im Scope | -| 1.6.3 | 1.6.3-M2 | MUSS | Ja | Ja | Informationssicherheit | immer im Scope | -| 1.6.3 | 1.6.3-M3 | MUSS | Ja | Ja | Informationssicherheit | immer im Scope | -| 1.6.3 | 1.6.3-S1 | SOLL | Ja | Ja | Informationssicherheit | `FLAG_INCLUDE_SHOULD` | -| 1.6.3 | 1.6.3-S2 | SOLL | Ja | Ja | Informationssicherheit | `FLAG_INCLUDE_SHOULD` | -| 1.6.3 | 1.6.3-S3 | SOLL | Ja | Ja | Informationssicherheit | `FLAG_INCLUDE_SHOULD` | -| 1.6.3 | 1.6.3-S4 | SOLL | Ja | Ja | Informationssicherheit | `FLAG_INCLUDE_SHOULD` | -| 1.6.3 | 1.6.3-S5 | SOLL | Ja | Ja | Informationssicherheit | `FLAG_INCLUDE_SHOULD` | -| 1.6.3 | 1.6.3-S6 | SOLL | Ja | Ja | Informationssicherheit | `FLAG_INCLUDE_SHOULD` | -| 1.6.3 | 1.6.3-H1 | HOCH | – | Ja | Informationssicherheit | `FLAG_HIGH_PROTECTION` | -| 1.6.3 | 1.6.3-H2 | HOCH | – | Ja | Informationssicherheit | `FLAG_HIGH_PROTECTION` | -| 1.6.3 | 1.6.3-H3 | HOCH | – | Ja | Informationssicherheit | `FLAG_HIGH_PROTECTION` | -| 1.6.3 | 1.6.3-H4 | HOCH | – | Ja | Informationssicherheit | `FLAG_HIGH_PROTECTION` | -| 1.6.3 | 1.6.3-H5 | HOCH | – | Ja | Informationssicherheit | `FLAG_HIGH_PROTECTION` | -| 1.6.3 | 1.6.3-V1 | SEHR HOCH | – | Ja | Informationssicherheit | `FLAG_VERY_HIGH_PROTECTION` | -| 2.1.1 | 2.1.1-M1 | MUSS | Ja | Ja | Informationssicherheit | immer im Scope | -| 2.1.1 | 2.1.1-M2 | MUSS | Ja | Ja | Informationssicherheit | immer im Scope | -| 2.1.1 | 2.1.1-M3 | MUSS | Ja | Ja | Informationssicherheit | immer im Scope | -| 2.1.1 | 2.1.1-S1 | SOLL | Ja | Ja | Informationssicherheit | `FLAG_INCLUDE_SHOULD` | -| 2.1.1 | 2.1.1-S2 | SOLL | Ja | Ja | Informationssicherheit | `FLAG_INCLUDE_SHOULD` | -| 2.1.2 | 2.1.2-M1 | MUSS | Ja | Ja | Informationssicherheit | immer im Scope | -| 2.1.2 | 2.1.2-M2 | MUSS | Ja | Ja | Informationssicherheit | immer im Scope | -| 2.1.2 | 2.1.2-S1 | SOLL | Ja | Ja | Informationssicherheit | `FLAG_INCLUDE_SHOULD` | -| 2.1.2 | 2.1.2-S2 | SOLL | Ja | Ja | Informationssicherheit | `FLAG_INCLUDE_SHOULD` | -| 2.1.2 | 2.1.2-S3 | SOLL | Ja | Ja | Informationssicherheit | `FLAG_INCLUDE_SHOULD` | -| 2.1.3 | 2.1.3-M1 | MUSS | Ja | Ja | Informationssicherheit | immer im Scope | -| 2.1.3 | 2.1.3-S1 | SOLL | Ja | Ja | Informationssicherheit | `FLAG_INCLUDE_SHOULD` | -| 2.1.3 | 2.1.3-S2 | SOLL | Ja | Ja | Informationssicherheit | `FLAG_INCLUDE_SHOULD` | -| 2.1.3 | 2.1.3-S3 | SOLL | Ja | Ja | Informationssicherheit | `FLAG_INCLUDE_SHOULD` | -| 2.1.3 | 2.1.3-S4 | SOLL | Ja | Ja | Informationssicherheit | `FLAG_INCLUDE_SHOULD` | -| 2.1.3 | 2.1.3-S5 | SOLL | Ja | Ja | Informationssicherheit | `FLAG_INCLUDE_SHOULD` | -| 2.1.3 | 2.1.3-S6 | SOLL | Ja | Ja | Informationssicherheit | `FLAG_INCLUDE_SHOULD` | -| 2.1.4 | 2.1.4-M1 | MUSS | Ja | Ja | Informationssicherheit | immer im Scope | -| 2.1.4 | 2.1.4-S1 | SOLL | Ja | Ja | Informationssicherheit | `FLAG_INCLUDE_SHOULD` | -| 2.1.4 | 2.1.4-S2 | SOLL | Ja | Ja | Informationssicherheit | `FLAG_INCLUDE_SHOULD` | -| 2.1.4 | 2.1.4-H1 | HOCH | – | Ja | Informationssicherheit | `FLAG_HIGH_PROTECTION` | -| 3.1.1 | 3.1.1-M1 | MUSS | Ja | Ja | Informationssicherheit | immer im Scope | -| 3.1.1 | 3.1.1-M2 | MUSS | Ja | Ja | Informationssicherheit | immer im Scope | -| 3.1.1 | 3.1.1-M3 | MUSS | Ja | Ja | Informationssicherheit | immer im Scope | -| 3.1.1 | 3.1.1-S1 | SOLL | Ja | Ja | Informationssicherheit | `FLAG_INCLUDE_SHOULD` | -| 3.1.1 | 3.1.1-S2 | SOLL | Ja | Ja | Informationssicherheit | `FLAG_INCLUDE_SHOULD` | -| 3.1.1 | 3.1.1-S3 | SOLL | Ja | Ja | Informationssicherheit | `FLAG_INCLUDE_SHOULD` | -| 3.1.1 | 3.1.1-S4 | SOLL | Ja | Ja | Informationssicherheit | `FLAG_INCLUDE_SHOULD` | -| 3.1.1 | 3.1.1-S5 | SOLL | Ja | Ja | Informationssicherheit | `FLAG_INCLUDE_SHOULD` | -| 3.1.1 | 3.1.1-H1 | HOCH | – | Ja | Informationssicherheit | `FLAG_HIGH_PROTECTION` | -| 3.1.4 | 3.1.4-M1 | MUSS | Ja | Ja | Informationssicherheit | immer im Scope | -| 3.1.4 | 3.1.4-S1 | SOLL | Ja | Ja | Informationssicherheit | `FLAG_INCLUDE_SHOULD` | -| 3.1.4 | 3.1.4-H1 | HOCH | – | Ja | Informationssicherheit | `FLAG_HIGH_PROTECTION` | -| 4.1.1 | 4.1.1-M1 | MUSS | Ja | Ja | Informationssicherheit | immer im Scope | -| 4.1.1 | 4.1.1-S1 | SOLL | Ja | Ja | Informationssicherheit | `FLAG_INCLUDE_SHOULD` | -| 4.1.1 | 4.1.1-H1 | HOCH | – | Ja | Informationssicherheit | `FLAG_HIGH_PROTECTION` | -| 4.1.2 | 4.1.2-M1 | MUSS | Ja | Ja | Informationssicherheit | immer im Scope | -| 4.1.2 | 4.1.2-M2 | MUSS | Ja | Ja | Informationssicherheit | immer im Scope | -| 4.1.2 | 4.1.2-S1 | SOLL | Ja | Ja | Informationssicherheit | `FLAG_INCLUDE_SHOULD` | -| 4.1.2 | 4.1.2-S2 | SOLL | Ja | Ja | Informationssicherheit | `FLAG_INCLUDE_SHOULD` | -| 4.1.2 | 4.1.2-S3 | SOLL | Ja | Ja | Informationssicherheit | `FLAG_INCLUDE_SHOULD` | -| 4.1.2 | 4.1.2-H1 | HOCH | – | Ja | Informationssicherheit | `FLAG_HIGH_PROTECTION` | -| 4.1.2 | 4.1.2-V1 | SEHR HOCH | – | Ja | Informationssicherheit | `FLAG_VERY_HIGH_PROTECTION` | -| 4.1.3 | 4.1.3-M1 | MUSS | Ja | Ja | Informationssicherheit | immer im Scope | -| 4.1.3 | 4.1.3-M2 | MUSS | Ja | Ja | Informationssicherheit | immer im Scope | -| 4.1.3 | 4.1.3-M3 | MUSS | Ja | Ja | Informationssicherheit | immer im Scope | -| 4.1.3 | 4.1.3-M4 | MUSS | Ja | Ja | Informationssicherheit | immer im Scope | -| 4.1.3 | 4.1.3-M5 | MUSS | Ja | Ja | Informationssicherheit | immer im Scope | -| 4.1.3 | 4.1.3-M6 | MUSS | Ja | Ja | Informationssicherheit | immer im Scope | -| 4.1.3 | 4.1.3-M7 | MUSS | Ja | Ja | Informationssicherheit | immer im Scope | -| 4.1.3 | 4.1.3-S1 | SOLL | Ja | Ja | Informationssicherheit | `FLAG_INCLUDE_SHOULD` | -| 4.1.3 | 4.1.3-S10 | SOLL | Ja | Ja | Informationssicherheit | `FLAG_INCLUDE_SHOULD` | -| 4.1.3 | 4.1.3-S2 | SOLL | Ja | Ja | Informationssicherheit | `FLAG_INCLUDE_SHOULD` | -| 4.1.3 | 4.1.3-S3 | SOLL | Ja | Ja | Informationssicherheit | `FLAG_INCLUDE_SHOULD` | -| 4.1.3 | 4.1.3-S4 | SOLL | Ja | Ja | Informationssicherheit | `FLAG_INCLUDE_SHOULD` | -| 4.1.3 | 4.1.3-S5 | SOLL | Ja | Ja | Informationssicherheit | `FLAG_INCLUDE_SHOULD` | -| 4.1.3 | 4.1.3-S6 | SOLL | Ja | Ja | Informationssicherheit | `FLAG_INCLUDE_SHOULD` | -| 4.1.3 | 4.1.3-S7 | SOLL | Ja | Ja | Informationssicherheit | `FLAG_INCLUDE_SHOULD` | -| 4.1.3 | 4.1.3-S8 | SOLL | Ja | Ja | Informationssicherheit | `FLAG_INCLUDE_SHOULD` | -| 4.1.3 | 4.1.3-S9 | SOLL | Ja | Ja | Informationssicherheit | `FLAG_INCLUDE_SHOULD` | -| 4.2.1 | 4.2.1-M1 | MUSS | Ja | Ja | Informationssicherheit | immer im Scope | -| 4.2.1 | 4.2.1-M2 | MUSS | Ja | Ja | Informationssicherheit | immer im Scope | -| 4.2.1 | 4.2.1-S1 | SOLL | Ja | Ja | Informationssicherheit | `FLAG_INCLUDE_SHOULD` | -| 4.2.1 | 4.2.1-S2 | SOLL | Ja | Ja | Informationssicherheit | `FLAG_INCLUDE_SHOULD` | -| 4.2.1 | 4.2.1-S3 | SOLL | Ja | Ja | Informationssicherheit | `FLAG_INCLUDE_SHOULD` | -| 4.2.1 | 4.2.1-S4 | SOLL | Ja | Ja | Informationssicherheit | `FLAG_INCLUDE_SHOULD` | -| 4.2.1 | 4.2.1-S5 | SOLL | Ja | Ja | Informationssicherheit | `FLAG_INCLUDE_SHOULD` | -| 4.2.1 | 4.2.1-H1 | HOCH | – | Ja | Informationssicherheit | `FLAG_HIGH_PROTECTION` | -| 4.2.1 | 4.2.1-V1 | SEHR HOCH | – | Ja | Informationssicherheit | `FLAG_VERY_HIGH_PROTECTION` | -| 4.2.1 | 4.2.1-V2 | SEHR HOCH | – | Ja | Informationssicherheit | `FLAG_VERY_HIGH_PROTECTION` | -| 5.1.1 | 5.1.1-M1 | MUSS | Ja | Ja | Informationssicherheit | immer im Scope | -| 5.1.1 | 5.1.1-S1 | SOLL | Ja | Ja | Informationssicherheit | `FLAG_INCLUDE_SHOULD` | -| 5.1.1 | 5.1.1-H1 | HOCH | – | Ja | Informationssicherheit | `FLAG_HIGH_PROTECTION` | -| 5.1.2 | 5.1.2-M1 | MUSS | Ja | Ja | Informationssicherheit | immer im Scope | -| 5.1.2 | 5.1.2-M2 | MUSS | Ja | Ja | Informationssicherheit | immer im Scope | -| 5.1.2 | 5.1.2-M3 | MUSS | Ja | Ja | Informationssicherheit | immer im Scope | -| 5.1.2 | 5.1.2-S1 | SOLL | Ja | Ja | Informationssicherheit | `FLAG_INCLUDE_SHOULD` | -| 5.1.2 | 5.1.2-S2 | SOLL | Ja | Ja | Informationssicherheit | `FLAG_INCLUDE_SHOULD` | -| 5.1.2 | 5.1.2-S3 | SOLL | Ja | Ja | Informationssicherheit | `FLAG_INCLUDE_SHOULD` | -| 5.1.2 | 5.1.2-H1 | HOCH | – | Ja | Informationssicherheit | `FLAG_HIGH_PROTECTION` | -| 5.1.2 | 5.1.2-V1 | SEHR HOCH | – | Ja | Informationssicherheit | `FLAG_VERY_HIGH_PROTECTION` | -| 5.2.1 | 5.2.1-M1 | MUSS | Ja | Ja | Informationssicherheit | immer im Scope | -| 5.2.1 | 5.2.1-S1 | SOLL | Ja | Ja | Informationssicherheit | `FLAG_INCLUDE_SHOULD` | -| 5.2.1 | 5.2.1-S2 | SOLL | Ja | Ja | Informationssicherheit | `FLAG_INCLUDE_SHOULD` | -| 5.2.1 | 5.2.1-S3 | SOLL | Ja | Ja | Informationssicherheit | `FLAG_INCLUDE_SHOULD` | -| 5.2.1 | 5.2.1-S4 | SOLL | Ja | Ja | Informationssicherheit | `FLAG_INCLUDE_SHOULD` | -| 5.2.1 | 5.2.1-H1 | HOCH | – | Ja | Informationssicherheit | `FLAG_HIGH_PROTECTION` | -| 5.2.2 | 5.2.2-M1 | MUSS | Ja | Ja | Informationssicherheit | immer im Scope | -| 5.2.2 | 5.2.2-M2 | MUSS | Ja | Ja | Informationssicherheit | immer im Scope | -| 5.2.2 | 5.2.2-S1 | SOLL | Ja | Ja | Informationssicherheit | `FLAG_INCLUDE_SHOULD` | -| 5.2.3 | 5.2.3-M1 | MUSS | Ja | Ja | Informationssicherheit | immer im Scope | -| 5.2.3 | 5.2.3-M2 | MUSS | Ja | Ja | Informationssicherheit | immer im Scope | -| 5.2.3 | 5.2.3-S1 | SOLL | Ja | Ja | Informationssicherheit | `FLAG_INCLUDE_SHOULD` | -| 5.2.3 | 5.2.3-S2 | SOLL | Ja | Ja | Informationssicherheit | `FLAG_INCLUDE_SHOULD` | -| 5.2.3 | 5.2.3-S3 | SOLL | Ja | Ja | Informationssicherheit | `FLAG_INCLUDE_SHOULD` | -| 5.2.3 | 5.2.3-S4 | SOLL | Ja | Ja | Informationssicherheit | `FLAG_INCLUDE_SHOULD` | -| 5.2.3 | 5.2.3-S5 | SOLL | Ja | Ja | Informationssicherheit | `FLAG_INCLUDE_SHOULD` | -| 5.2.3 | 5.2.3-S6 | SOLL | Ja | Ja | Informationssicherheit | `FLAG_INCLUDE_SHOULD` | -| 5.2.3 | 5.2.3-S7 | SOLL | Ja | Ja | Informationssicherheit | `FLAG_INCLUDE_SHOULD` | -| 5.2.3 | 5.2.3-S8 | SOLL | Ja | Ja | Informationssicherheit | `FLAG_INCLUDE_SHOULD` | -| 5.2.4 | 5.2.4-M1 | MUSS | Ja | Ja | Informationssicherheit | immer im Scope | -| 5.2.4 | 5.2.4-M2 | MUSS | Ja | Ja | Informationssicherheit | immer im Scope | -| 5.2.4 | 5.2.4-M3 | MUSS | Ja | Ja | Informationssicherheit | immer im Scope | -| 5.2.4 | 5.2.4-M4 | MUSS | Ja | Ja | Informationssicherheit | immer im Scope | -| 5.2.4 | 5.2.4-M5 | MUSS | Ja | Ja | Informationssicherheit | immer im Scope | -| 5.2.4 | 5.2.4-S1 | SOLL | Ja | Ja | Informationssicherheit | `FLAG_INCLUDE_SHOULD` | -| 5.2.4 | 5.2.4-S2 | SOLL | Ja | Ja | Informationssicherheit | `FLAG_INCLUDE_SHOULD` | -| 5.2.4 | 5.2.4-S3 | SOLL | Ja | Ja | Informationssicherheit | `FLAG_INCLUDE_SHOULD` | -| 5.2.4 | 5.2.4-H1 | HOCH | – | Ja | Informationssicherheit | `FLAG_HIGH_PROTECTION` | -| 5.2.4 | 5.2.4-H2 | HOCH | – | Ja | Informationssicherheit | `FLAG_HIGH_PROTECTION` | -| 5.2.4 | 5.2.4-V1 | SEHR HOCH | – | Ja | Informationssicherheit | `FLAG_VERY_HIGH_PROTECTION` | -| 5.2.5 | 5.2.5-M1 | MUSS | Ja | Ja | Informationssicherheit | immer im Scope | -| 5.2.5 | 5.2.5-M2 | MUSS | Ja | Ja | Informationssicherheit | immer im Scope | -| 5.2.5 | 5.2.5-M3 | MUSS | Ja | Ja | Informationssicherheit | immer im Scope | -| 5.2.5 | 5.2.5-S1 | SOLL | Ja | Ja | Informationssicherheit | `FLAG_INCLUDE_SHOULD` | -| 5.2.5 | 5.2.5-S2 | SOLL | Ja | Ja | Informationssicherheit | `FLAG_INCLUDE_SHOULD` | -| 5.2.5 | 5.2.5-S3 | SOLL | Ja | Ja | Informationssicherheit | `FLAG_INCLUDE_SHOULD` | -| 5.2.6 | 5.2.6-M1 | MUSS | Ja | Ja | Informationssicherheit | immer im Scope | -| 5.2.6 | 5.2.6-M2 | MUSS | Ja | Ja | Informationssicherheit | immer im Scope | -| 5.2.6 | 5.2.6-M3 | MUSS | Ja | Ja | Informationssicherheit | immer im Scope | -| 5.2.6 | 5.2.6-M4 | MUSS | Ja | Ja | Informationssicherheit | immer im Scope | -| 5.2.6 | 5.2.6-M5 | MUSS | Ja | Ja | Informationssicherheit | immer im Scope | -| 5.2.6 | 5.2.6-S1 | SOLL | Ja | Ja | Informationssicherheit | `FLAG_INCLUDE_SHOULD` | -| 5.2.6 | 5.2.6-S2 | SOLL | Ja | Ja | Informationssicherheit | `FLAG_INCLUDE_SHOULD` | -| 5.2.6 | 5.2.6-S3 | SOLL | Ja | Ja | Informationssicherheit | `FLAG_INCLUDE_SHOULD` | -| 5.2.6 | 5.2.6-H1 | HOCH | – | Ja | Informationssicherheit | `FLAG_HIGH_PROTECTION` | -| 5.2.6 | 5.2.6-V1 | SEHR HOCH | – | Ja | Informationssicherheit | `FLAG_VERY_HIGH_PROTECTION` | -| 5.2.7 | 5.2.7-M1 | MUSS | Ja | Ja | Informationssicherheit | immer im Scope | -| 5.2.7 | 5.2.7-M2 | MUSS | Ja | Ja | Informationssicherheit | immer im Scope | -| 5.2.7 | 5.2.7-S1 | SOLL | Ja | Ja | Informationssicherheit | `FLAG_INCLUDE_SHOULD` | -| 5.2.7 | 5.2.7-S2 | SOLL | Ja | Ja | Informationssicherheit | `FLAG_INCLUDE_SHOULD` | -| 5.2.7 | 5.2.7-H1 | HOCH | – | Ja | Informationssicherheit | `FLAG_HIGH_PROTECTION` | -| 5.2.8 | 5.2.8-M1 | MUSS | Ja | Ja | Informationssicherheit | immer im Scope | -| 5.2.8 | 5.2.8-M2 | MUSS | Ja | Ja | Informationssicherheit | immer im Scope | -| 5.2.8 | 5.2.8-S1 | SOLL | Ja | Ja | Informationssicherheit | `FLAG_INCLUDE_SHOULD` | -| 5.2.8 | 5.2.8-S2 | SOLL | Ja | Ja | Informationssicherheit | `FLAG_INCLUDE_SHOULD` | -| 5.2.8 | 5.2.8-S3 | SOLL | Ja | Ja | Informationssicherheit | `FLAG_INCLUDE_SHOULD` | -| 5.2.8 | 5.2.8-H1 | HOCH | – | Ja | Informationssicherheit | `FLAG_HIGH_PROTECTION` | -| 5.2.8 | 5.2.8-H2 | HOCH | – | Ja | Informationssicherheit | `FLAG_HIGH_PROTECTION` | -| 5.2.8 | 5.2.8-H3 | HOCH | – | Ja | Informationssicherheit | `FLAG_HIGH_PROTECTION` | -| 5.2.8 | 5.2.8-H4 | HOCH | – | Ja | Informationssicherheit | `FLAG_HIGH_PROTECTION` | -| 5.2.8 | 5.2.8-H5 | HOCH | – | Ja | Informationssicherheit | `FLAG_HIGH_PROTECTION` | -| 5.2.8 | 5.2.8-H6 | HOCH | – | Ja | Informationssicherheit | `FLAG_HIGH_PROTECTION` | -| 5.2.8 | 5.2.8-H7 | HOCH | – | Ja | Informationssicherheit | `FLAG_HIGH_PROTECTION` | -| 5.2.8 | 5.2.8-V1 | SEHR HOCH | – | Ja | Informationssicherheit | `FLAG_VERY_HIGH_PROTECTION` | -| 5.2.8 | 5.2.8-V2 | SEHR HOCH | – | Ja | Informationssicherheit | `FLAG_VERY_HIGH_PROTECTION` | -| 5.2.8 | 5.2.8-V3 | SEHR HOCH | – | Ja | Informationssicherheit | `FLAG_VERY_HIGH_PROTECTION` | -| 5.2.9 | 5.2.9-M1 | MUSS | Ja | Ja | Informationssicherheit | immer im Scope | -| 5.2.9 | 5.2.9-M2 | MUSS | Ja | Ja | Informationssicherheit | immer im Scope | -| 5.2.9 | 5.2.9-S1 | SOLL | Ja | Ja | Informationssicherheit | `FLAG_INCLUDE_SHOULD` | -| 5.2.9 | 5.2.9-H1 | HOCH | – | Ja | Informationssicherheit | `FLAG_HIGH_PROTECTION` | -| 5.2.9 | 5.2.9-H2 | HOCH | – | Ja | Informationssicherheit | `FLAG_HIGH_PROTECTION` | -| 5.2.9 | 5.2.9-V1 | SEHR HOCH | – | Ja | Informationssicherheit | `FLAG_VERY_HIGH_PROTECTION` | -| 5.2.9 | 5.2.9-V2 | SEHR HOCH | – | Ja | Informationssicherheit | `FLAG_VERY_HIGH_PROTECTION` | -| 5.2.9 | 5.2.9-V3 | SEHR HOCH | – | Ja | Informationssicherheit | `FLAG_VERY_HIGH_PROTECTION` | -| 5.3.1 | 5.3.1-M1 | MUSS | Ja | Ja | Informationssicherheit | immer im Scope | -| 5.3.1 | 5.3.1-M2 | MUSS | Ja | Ja | Informationssicherheit | immer im Scope | -| 5.3.1 | 5.3.1-M3 | MUSS | Ja | Ja | Informationssicherheit | immer im Scope | -| 5.3.1 | 5.3.1-M4 | MUSS | Ja | Ja | Informationssicherheit | immer im Scope | -| 5.3.1 | 5.3.1-S1 | SOLL | Ja | Ja | Informationssicherheit | `FLAG_INCLUDE_SHOULD` | -| 5.3.1 | 5.3.1-S2 | SOLL | Ja | Ja | Informationssicherheit | `FLAG_INCLUDE_SHOULD` | -| 5.3.1 | 5.3.1-S3 | SOLL | Ja | Ja | Informationssicherheit | `FLAG_INCLUDE_SHOULD` | -| 5.3.1 | 5.3.1-S4 | SOLL | Ja | Ja | Informationssicherheit | `FLAG_INCLUDE_SHOULD` | -| 5.3.1 | 5.3.1-S5 | SOLL | Ja | Ja | Informationssicherheit | `FLAG_INCLUDE_SHOULD` | -| 5.3.1 | 5.3.1-V1 | SEHR HOCH | – | Ja | Informationssicherheit | `FLAG_VERY_HIGH_PROTECTION` | -| 5.3.2 | 5.3.2-M1 | MUSS | Ja | Ja | Informationssicherheit | immer im Scope | -| 5.3.2 | 5.3.2-S1 | SOLL | Ja | Ja | Informationssicherheit | `FLAG_INCLUDE_SHOULD` | -| 5.3.2 | 5.3.2-S2 | SOLL | Ja | Ja | Informationssicherheit | `FLAG_INCLUDE_SHOULD` | -| 5.3.2 | 5.3.2-S3 | SOLL | Ja | Ja | Informationssicherheit | `FLAG_INCLUDE_SHOULD` | -| 5.3.2 | 5.3.2-H1 | HOCH | – | Ja | Informationssicherheit | `FLAG_HIGH_PROTECTION` | -| 5.3.3 | 5.3.3-S1 | SOLL | Ja | Ja | Informationssicherheit | `FLAG_INCLUDE_SHOULD` | -| 5.3.4 | 5.3.4-M1 | MUSS | Ja | Ja | Informationssicherheit | immer im Scope | -| 5.3.4 | 5.3.4-S1 | SOLL | Ja | Ja | Informationssicherheit | `FLAG_INCLUDE_SHOULD` | -| 5.3.4-KI | 5.3.4-KI-M1 | MUSS | Ja | Ja | Informationssicherheit | immer im Scope | -| 5.3.4-KI | 5.3.4-KI-M2 | MUSS | Ja | Ja | Informationssicherheit | immer im Scope | -| 5.3.4-KI | 5.3.4-KI-M3 | MUSS | Ja | Ja | Informationssicherheit | immer im Scope | -| 5.3.4-KI | 5.3.4-KI-S1 | SOLL | Ja | Ja | Informationssicherheit | `FLAG_INCLUDE_SHOULD` | -| 6.1.1 | 6.1.1-M1 | MUSS | Ja | Ja | Informationssicherheit | immer im Scope | -| 6.1.1 | 6.1.1-M2 | MUSS | Ja | Ja | Informationssicherheit | immer im Scope | -| 6.1.1 | 6.1.1-M3 | MUSS | Ja | Ja | Informationssicherheit | immer im Scope | -| 6.1.1 | 6.1.1-S1 | SOLL | Ja | Ja | Informationssicherheit | `FLAG_INCLUDE_SHOULD` | -| 6.1.1 | 6.1.1-S2 | SOLL | Ja | Ja | Informationssicherheit | `FLAG_INCLUDE_SHOULD` | -| 6.1.1 | 6.1.1-H1 | HOCH | – | Ja | Informationssicherheit | `FLAG_HIGH_PROTECTION` | -| 6.1.1 | 6.1.1-H2 | HOCH | – | Ja | Informationssicherheit | `FLAG_HIGH_PROTECTION` | -| 6.1.1 | 6.1.1-H3 | HOCH | – | Ja | Informationssicherheit | `FLAG_HIGH_PROTECTION` | -| 6.1.1 | 6.1.1-V1 | SEHR HOCH | – | Ja | Informationssicherheit | `FLAG_VERY_HIGH_PROTECTION` | -| 6.1.1 | 6.1.1-V2 | SEHR HOCH | – | Ja | Informationssicherheit | `FLAG_VERY_HIGH_PROTECTION` | -| 6.1.2 | 6.1.2-M1 | MUSS | Ja | Ja | Informationssicherheit | immer im Scope | -| 6.1.2 | 6.1.2-M2 | MUSS | Ja | Ja | Informationssicherheit | immer im Scope | -| 6.1.2 | 6.1.2-M3 | MUSS | Ja | Ja | Informationssicherheit | immer im Scope | -| 6.1.2 | 6.1.2-M4 | MUSS | Ja | Ja | Informationssicherheit | immer im Scope | -| 6.1.2 | 6.1.2-S1 | SOLL | Ja | Ja | Informationssicherheit | `FLAG_INCLUDE_SHOULD` | -| 6.1.2 | 6.1.2-S2 | SOLL | Ja | Ja | Informationssicherheit | `FLAG_INCLUDE_SHOULD` | -| 6.1.2 | 6.1.2-S3 | SOLL | Ja | Ja | Informationssicherheit | `FLAG_INCLUDE_SHOULD` | -| 6.1.2 | 6.1.2-S4 | SOLL | Ja | Ja | Informationssicherheit | `FLAG_INCLUDE_SHOULD` | -| 6.1.2 | 6.1.2-S5 | SOLL | Ja | Ja | Informationssicherheit | `FLAG_INCLUDE_SHOULD` | -| 6.1.3 | 6.1.3-M1 | MUSS | Ja | Ja | Informationssicherheit | immer im Scope | -| 6.1.3 | 6.1.3-M2 | MUSS | Ja | Ja | Informationssicherheit | immer im Scope | -| 6.1.3 | 6.1.3-M3 | MUSS | Ja | Ja | Informationssicherheit | immer im Scope | -| 6.1.3 | 6.1.3-M4 | MUSS | Ja | Ja | Informationssicherheit | immer im Scope | -| 6.1.3 | 6.1.3-M5 | MUSS | Ja | Ja | Informationssicherheit | immer im Scope | -| 6.1.3 | 6.1.3-S1 | SOLL | Ja | Ja | Informationssicherheit | `FLAG_INCLUDE_SHOULD` | -| 6.1.3 | 6.1.3-S2 | SOLL | Ja | Ja | Informationssicherheit | `FLAG_INCLUDE_SHOULD` | -| 6.1.3 | 6.1.3-H1 | HOCH | – | Ja | Informationssicherheit | `FLAG_HIGH_PROTECTION` | -| 6.1.3 | 6.1.3-H2 | HOCH | – | Ja | Informationssicherheit | `FLAG_HIGH_PROTECTION` | -| 6.1.3 | 6.1.3-H3 | HOCH | – | Ja | Informationssicherheit | `FLAG_HIGH_PROTECTION` | -| 6.1.3 | 6.1.3-H4 | HOCH | – | Ja | Informationssicherheit | `FLAG_HIGH_PROTECTION` | -| 6.1.3 | 6.1.3-H5 | HOCH | – | Ja | Informationssicherheit | `FLAG_HIGH_PROTECTION` | -| 7.1.1 | 7.1.1-M1 | MUSS | Ja | Ja | Informationssicherheit | immer im Scope | -| 7.1.1 | 7.1.1-M2 | MUSS | Ja | Ja | Informationssicherheit | immer im Scope | -| 7.1.1 | 7.1.1-S1 | SOLL | Ja | Ja | Informationssicherheit | `FLAG_INCLUDE_SHOULD` | -| 7.1.2 | 7.1.2-M1 | MUSS | Ja | Ja | Informationssicherheit | immer im Scope | -| 7.1.2 | 7.1.2-M2 | MUSS | Ja | Ja | Informationssicherheit | immer im Scope | -| 7.1.2 | 7.1.2-M3 | MUSS | Ja | Ja | Informationssicherheit | immer im Scope | - -## Prüfziel Prototypenschutz (72 Anforderungen) — Erweiterung - -| Control | Anforderungs-ID | Typ | AL2 | AL3 | Prüfziel | Scope-Bedingung (Flag) | -|---|---|---|:--:|:--:|---|---| -| 8.1.1 | 8.1.1-M1 | MUSS | Ja | Ja | Prototypenschutz | Prüfziel Prototypenschutz aktiv | -| 8.1.1 | 8.1.1-S1 | SOLL | Ja | Ja | Prototypenschutz | `FLAG_INCLUDE_SHOULD` | -| 8.1.2 | 8.1.2-M1 | MUSS | Ja | Ja | Prototypenschutz | Prüfziel Prototypenschutz aktiv | -| 8.1.2 | 8.1.2-S1 | SOLL | Ja | Ja | Prototypenschutz | `FLAG_INCLUDE_SHOULD` | -| 8.1.3 | 8.1.3-M1 | MUSS | Ja | Ja | Prototypenschutz | Prüfziel Prototypenschutz aktiv | -| 8.1.3 | 8.1.3-S1 | SOLL | Ja | Ja | Prototypenschutz | `FLAG_INCLUDE_SHOULD` | -| 8.1.3 | 8.1.3-S2 | SOLL | Ja | Ja | Prototypenschutz | `FLAG_INCLUDE_SHOULD` | -| 8.1.4 | 8.1.4-M1 | MUSS | Ja | Ja | Prototypenschutz | Prüfziel Prototypenschutz aktiv | -| 8.1.4 | 8.1.4-S1 | SOLL | Ja | Ja | Prototypenschutz | `FLAG_INCLUDE_SHOULD` | -| 8.1.4 | 8.1.4-S2 | SOLL | Ja | Ja | Prototypenschutz | `FLAG_INCLUDE_SHOULD` | -| 8.1.4 | 8.1.4-H1 | HOCH | – | Ja | Prototypenschutz | `FLAG_HIGH_PROTECTION` | -| 8.1.5 | 8.1.5-M1 | MUSS | Ja | Ja | Prototypenschutz | Prüfziel Prototypenschutz aktiv | -| 8.1.5 | 8.1.5-H1 | HOCH | – | Ja | Prototypenschutz | `FLAG_HIGH_PROTECTION` | -| 8.1.6 | 8.1.6-M1 | MUSS | Ja | Ja | Prototypenschutz | Prüfziel Prototypenschutz aktiv | -| 8.1.6 | 8.1.6-M2 | MUSS | Ja | Ja | Prototypenschutz | Prüfziel Prototypenschutz aktiv | -| 8.1.6 | 8.1.6-M3 | MUSS | Ja | Ja | Prototypenschutz | Prüfziel Prototypenschutz aktiv | -| 8.1.7 | 8.1.7-M1 | MUSS | Ja | Ja | Prototypenschutz | Prüfziel Prototypenschutz aktiv | -| 8.1.7 | 8.1.7-M2 | MUSS | Ja | Ja | Prototypenschutz | Prüfziel Prototypenschutz aktiv | -| 8.1.7 | 8.1.7-M3 | MUSS | Ja | Ja | Prototypenschutz | Prüfziel Prototypenschutz aktiv | -| 8.1.7 | 8.1.7-M4 | MUSS | Ja | Ja | Prototypenschutz | Prüfziel Prototypenschutz aktiv | -| 8.1.8 | 8.1.8-M1 | MUSS | Ja | Ja | Prototypenschutz | Prüfziel Prototypenschutz aktiv | -| 8.1.8 | 8.1.8-H1 | HOCH | – | Ja | Prototypenschutz | `FLAG_HIGH_PROTECTION` | -| 8.2.1 | 8.2.1-M1 | MUSS | Ja | Ja | Prototypenschutz | Prüfziel Prototypenschutz aktiv | -| 8.2.1 | 8.2.1-M2 | MUSS | Ja | Ja | Prototypenschutz | Prüfziel Prototypenschutz aktiv | -| 8.2.1 | 8.2.1-M3 | MUSS | Ja | Ja | Prototypenschutz | Prüfziel Prototypenschutz aktiv | -| 8.2.1 | 8.2.1-M4 | MUSS | Ja | Ja | Prototypenschutz | Prüfziel Prototypenschutz aktiv | -| 8.2.2 | 8.2.2-M1 | MUSS | Ja | Ja | Prototypenschutz | Prüfziel Prototypenschutz aktiv | -| 8.2.2 | 8.2.2-M2 | MUSS | Ja | Ja | Prototypenschutz | Prüfziel Prototypenschutz aktiv | -| 8.2.2 | 8.2.2-M3 | MUSS | Ja | Ja | Prototypenschutz | Prüfziel Prototypenschutz aktiv | -| 8.2.2 | 8.2.2-M4 | MUSS | Ja | Ja | Prototypenschutz | Prüfziel Prototypenschutz aktiv | -| 8.2.2 | 8.2.2-M5 | MUSS | Ja | Ja | Prototypenschutz | Prüfziel Prototypenschutz aktiv | -| 8.2.2 | 8.2.2-M6 | MUSS | Ja | Ja | Prototypenschutz | Prüfziel Prototypenschutz aktiv | -| 8.2.3 | 8.2.3-M1 | MUSS | Ja | Ja | Prototypenschutz | Prüfziel Prototypenschutz aktiv | -| 8.2.3 | 8.2.3-M2 | MUSS | Ja | Ja | Prototypenschutz | Prüfziel Prototypenschutz aktiv | -| 8.2.3 | 8.2.3-M3 | MUSS | Ja | Ja | Prototypenschutz | Prüfziel Prototypenschutz aktiv | -| 8.2.3 | 8.2.3-M4 | MUSS | Ja | Ja | Prototypenschutz | Prüfziel Prototypenschutz aktiv | -| 8.2.3 | 8.2.3-M5 | MUSS | Ja | Ja | Prototypenschutz | Prüfziel Prototypenschutz aktiv | -| 8.2.3 | 8.2.3-M6 | MUSS | Ja | Ja | Prototypenschutz | Prüfziel Prototypenschutz aktiv | -| 8.2.3 | 8.2.3-M7 | MUSS | Ja | Ja | Prototypenschutz | Prüfziel Prototypenschutz aktiv | -| 8.2.4 | 8.2.4-M1 | MUSS | Ja | Ja | Prototypenschutz | Prüfziel Prototypenschutz aktiv | -| 8.2.4 | 8.2.4-M2 | MUSS | Ja | Ja | Prototypenschutz | Prüfziel Prototypenschutz aktiv | -| 8.2.4 | 8.2.4-M3 | MUSS | Ja | Ja | Prototypenschutz | Prüfziel Prototypenschutz aktiv | -| 8.2.5 | 8.2.5-M1 | MUSS | Ja | Ja | Prototypenschutz | Prüfziel Prototypenschutz aktiv | -| 8.2.5 | 8.2.5-M2 | MUSS | Ja | Ja | Prototypenschutz | Prüfziel Prototypenschutz aktiv | -| 8.2.5 | 8.2.5-M3 | MUSS | Ja | Ja | Prototypenschutz | Prüfziel Prototypenschutz aktiv | -| 8.2.6 | 8.2.6-M1 | MUSS | Ja | Ja | Prototypenschutz | Prüfziel Prototypenschutz aktiv | -| 8.2.6 | 8.2.6-M2 | MUSS | Ja | Ja | Prototypenschutz | Prüfziel Prototypenschutz aktiv | -| 8.2.6 | 8.2.6-M3 | MUSS | Ja | Ja | Prototypenschutz | Prüfziel Prototypenschutz aktiv | -| 8.2.6 | 8.2.6-M4 | MUSS | Ja | Ja | Prototypenschutz | Prüfziel Prototypenschutz aktiv | -| 8.2.6 | 8.2.6-M5 | MUSS | Ja | Ja | Prototypenschutz | Prüfziel Prototypenschutz aktiv | -| 8.2.7 | 8.2.7-M1 | MUSS | Ja | Ja | Prototypenschutz | Prüfziel Prototypenschutz aktiv | -| 8.2.7 | 8.2.7-M2 | MUSS | Ja | Ja | Prototypenschutz | Prüfziel Prototypenschutz aktiv | -| 8.3.1 | 8.3.1-M1 | MUSS | Ja | Ja | Prototypenschutz | Prüfziel Prototypenschutz aktiv | -| 8.3.1 | 8.3.1-M2 | MUSS | Ja | Ja | Prototypenschutz | Prüfziel Prototypenschutz aktiv | -| 8.3.1 | 8.3.1-M3 | MUSS | Ja | Ja | Prototypenschutz | Prüfziel Prototypenschutz aktiv | -| 8.3.1 | 8.3.1-M4 | MUSS | Ja | Ja | Prototypenschutz | Prüfziel Prototypenschutz aktiv | -| 8.3.2 | 8.3.2-M1 | MUSS | Ja | Ja | Prototypenschutz | Prüfziel Prototypenschutz aktiv | -| 8.4.1 | 8.4.1-M1 | MUSS | Ja | Ja | Prototypenschutz | Prüfziel Prototypenschutz aktiv | -| 8.4.1 | 8.4.1-M2 | MUSS | Ja | Ja | Prototypenschutz | Prüfziel Prototypenschutz aktiv | -| 8.4.1 | 8.4.1-M3 | MUSS | Ja | Ja | Prototypenschutz | Prüfziel Prototypenschutz aktiv | -| 8.4.2 | 8.4.2-M1 | MUSS | Ja | Ja | Prototypenschutz | Prüfziel Prototypenschutz aktiv | -| 8.4.2 | 8.4.2-M2 | MUSS | Ja | Ja | Prototypenschutz | Prüfziel Prototypenschutz aktiv | -| 8.4.3 | 8.4.3-M1 | MUSS | Ja | Ja | Prototypenschutz | Prüfziel Prototypenschutz aktiv | -| 8.4.3 | 8.4.3-M2 | MUSS | Ja | Ja | Prototypenschutz | Prüfziel Prototypenschutz aktiv | -| 8.4.3 | 8.4.3-M3 | MUSS | Ja | Ja | Prototypenschutz | Prüfziel Prototypenschutz aktiv | -| 8.5.1 | 8.5.1-M1 | MUSS | Ja | Ja | Prototypenschutz | Prüfziel Prototypenschutz aktiv | -| 8.5.1 | 8.5.1-M2 | MUSS | Ja | Ja | Prototypenschutz | Prüfziel Prototypenschutz aktiv | -| 8.5.1 | 8.5.1-M3 | MUSS | Ja | Ja | Prototypenschutz | Prüfziel Prototypenschutz aktiv | -| 8.5.2 | 8.5.2-M1 | MUSS | Ja | Ja | Prototypenschutz | Prüfziel Prototypenschutz aktiv | -| 8.5.2 | 8.5.2-M2 | MUSS | Ja | Ja | Prototypenschutz | Prüfziel Prototypenschutz aktiv | -| 8.5.2 | 8.5.2-M3 | MUSS | Ja | Ja | Prototypenschutz | Prüfziel Prototypenschutz aktiv | -| 8.5.2 | 8.5.2-M4 | MUSS | Ja | Ja | Prototypenschutz | Prüfziel Prototypenschutz aktiv | - -> Hinweis Scope Prototypenschutz: Prüfziel bezieht sich in der aktuellen Konfiguration auf **Prototypenteile/-komponenten**; Controls 8.4.x (Test-/Erprobung) und 8.5.x (Ausstellungen/Film) sind per Scope-Regel `n.a.` und werden ausgeblendet. - -## Prüfziel Datenschutz (24 Anforderungen) — Erweiterung - -| Control | Anforderungs-ID | Typ | AL2 | AL3 | Prüfziel | Scope-Bedingung (Flag) | -|---|---|---|:--:|:--:|---|---| -| 9.1.1 | 9.1.1-M1 | MUSS | Ja | Ja | Datenschutz | Prüfziel Datenschutz aktiv (`FLAG_PERSONAL_DATA`) | -| 9.2.1 | 9.2.1-M1 | MUSS | Ja | Ja | Datenschutz | Prüfziel Datenschutz aktiv (`FLAG_PERSONAL_DATA`) | -| 9.2.1 | 9.2.1-M2 | MUSS | Ja | Ja | Datenschutz | Prüfziel Datenschutz aktiv (`FLAG_PERSONAL_DATA`) | -| 9.2.1 | 9.2.1-M3 | MUSS | Ja | Ja | Datenschutz | Prüfziel Datenschutz aktiv (`FLAG_PERSONAL_DATA`) | -| 9.2.1 | 9.2.1-M4 | MUSS | Ja | Ja | Datenschutz | Prüfziel Datenschutz aktiv (`FLAG_PERSONAL_DATA`) | -| 9.2.1 | 9.2.1-M5 | MUSS | Ja | Ja | Datenschutz | Prüfziel Datenschutz aktiv (`FLAG_PERSONAL_DATA`) | -| 9.2.1 | 9.2.1-M6 | MUSS | Ja | Ja | Datenschutz | Prüfziel Datenschutz aktiv (`FLAG_PERSONAL_DATA`) | -| 9.3.1 | 9.3.1-M1 | MUSS | Ja | Ja | Datenschutz | Prüfziel Datenschutz aktiv (`FLAG_PERSONAL_DATA`) | -| 9.4.1 | 9.4.1-M1 | MUSS | Ja | Ja | Datenschutz | Prüfziel Datenschutz aktiv (`FLAG_PERSONAL_DATA`) | -| 9.4.1 | 9.4.1-M2 | MUSS | Ja | Ja | Datenschutz | Prüfziel Datenschutz aktiv (`FLAG_PERSONAL_DATA`) | -| 9.5.1 | 9.5.1-M1 | MUSS | Ja | Ja | Datenschutz | Prüfziel Datenschutz aktiv (`FLAG_PERSONAL_DATA`) | -| 9.5.2 | 9.5.2-M1 | MUSS | Ja | Ja | Datenschutz | Prüfziel Datenschutz aktiv (`FLAG_PERSONAL_DATA`) | -| 9.5.2 | 9.5.2-M2 | MUSS | Ja | Ja | Datenschutz | Prüfziel Datenschutz aktiv (`FLAG_PERSONAL_DATA`) | -| 9.5.3 | 9.5.3-M1 | MUSS | Ja | Ja | Datenschutz | Prüfziel Datenschutz aktiv (`FLAG_PERSONAL_DATA`) | -| 9.5.3 | 9.5.3-M2 | MUSS | Ja | Ja | Datenschutz | Prüfziel Datenschutz aktiv (`FLAG_PERSONAL_DATA`) | -| 9.5.3 | 9.5.3-M3 | MUSS | Ja | Ja | Datenschutz | Prüfziel Datenschutz aktiv (`FLAG_PERSONAL_DATA`) | -| 9.6.1 | 9.6.1-M1 | MUSS | Ja | Ja | Datenschutz | Prüfziel Datenschutz aktiv (`FLAG_PERSONAL_DATA`) | -| 9.6.2 | 9.6.2-M1 | MUSS | Ja | Ja | Datenschutz | Prüfziel Datenschutz aktiv (`FLAG_PERSONAL_DATA`) | -| 9.6.2 | 9.6.2-M2 | MUSS | Ja | Ja | Datenschutz | Prüfziel Datenschutz aktiv (`FLAG_PERSONAL_DATA`) | -| 9.6.2 | 9.6.2-M3 | MUSS | Ja | Ja | Datenschutz | Prüfziel Datenschutz aktiv (`FLAG_PERSONAL_DATA`) | -| 9.7.1 | 9.7.1-M1 | MUSS | Ja | Ja | Datenschutz | Prüfziel Datenschutz aktiv (`FLAG_PERSONAL_DATA`) | -| 9.7.2 | 9.7.2-M1 | MUSS | Ja | Ja | Datenschutz | Prüfziel Datenschutz aktiv (`FLAG_PERSONAL_DATA`) | -| 9.8.1 | 9.8.1-M1 | MUSS | Ja | Ja | Datenschutz | Prüfziel Datenschutz aktiv (`FLAG_PERSONAL_DATA`) | -| 9.8.1 | 9.8.1-M2 | MUSS | Ja | Ja | Datenschutz | Prüfziel Datenschutz aktiv (`FLAG_PERSONAL_DATA`) | diff --git a/docs/wizard-uebergabe/02_Fachcontent_C1-C9/C2_Fragenkatalog-Wirkung.md b/docs/wizard-uebergabe/02_Fachcontent_C1-C9/C2_Fragenkatalog-Wirkung.md deleted file mode 100644 index e97b77c..0000000 --- a/docs/wizard-uebergabe/02_Fachcontent_C1-C9/C2_Fragenkatalog-Wirkung.md +++ /dev/null @@ -1,110 +0,0 @@ -# C2 — Fragenkatalog + Antwort→Wirkung-Mapping - -> **Schaltet frei:** B2 (Regel-/Mapping-Engine) und B3 (Fragebogen, Schritt 2). **Kritischer Pfad.** -> **Grundlage:** `variables.schema.json` (Single Source of Truth der Wizard-Variablen und `FLAG_*`), `mapping.json` (`condition`-Flags je Anforderung), `Technische-Sicherheits-Baseline.md` (`BL-*`-Parameter). - -## 1. Prinzip - -Jede Frage erzeugt eine **Wirkung** auf genau vier Kanäle (DSL-Vertrag aus dem Backlog, Foundation #3): - -1. **Variable/Platzhalter** — füllt einen `{{NAME}}`-Wert (z. B. `ORG_NAME`, `MFA_SCOPE`). -2. **Feature-Flag** — setzt ein `FLAG_*` true/false, das `{{#if FLAG_X}}`-Blöcke in Vorlagen und die Control-Relevanz steuert. -3. **Control/Risiko-Bezug** — schaltet Controls in den Scope und schlägt Katalog-Risiken (C4) vor. -4. **Aufgabe** — erzeugt bei bestimmten Antworten einen Aufgabenvorschlag (Aufgaben-Modul). - -Antworttypen: `text`, `single-select`, `multi-select`, `boolean`, `number/duration`. Baseline-Parameter (Abschnitt E) sind **vorbelegte Defaults** aus der Baseline; die Frage dient nur der Bestätigung/Anpassung, nicht der Ersteingabe. - -Anzeige-Bedingungen referenzieren zuvor gesetzte Flags (bedingter Fragebogen). - ---- - -## 2. Abschnitt A — Organisation & Geltungsbereich - -| Frage-ID | Frage | Antworttyp | Anzeige-Bedingung | Wirkung | -|---|---|---|---|---| -| Q-ORG-01 | Vollständiger Name der Organisation? | text | immer | Variable `ORG_NAME` | -| Q-ORG-02 | Kurzname/Abkürzung? | text | immer | Variable `ORG_SHORT` | -| Q-ORG-03 | Geltungsbereich – Kurzlabel? | text | immer | Variable `ISMS_SCOPE` | -| Q-ORG-04 | Geltungsbereich – Beschreibung (Standorte, Bereiche, Systeme, Ausschlüsse)? | text (lang) | immer | Variable `ISMS_SCOPE_DESCRIPTION`; speist Scope-Objekt (Schritt 1) | -| Q-ORG-05 | Verarbeitet die Organisation personenbezogene Daten? | boolean | immer | Flag `FLAG_PERSONAL_DATA`; schaltet Prüfziel Datenschutz (9.x) + Controls 7.1.2 · Risiken R-DSGVO-* | -| Q-ORG-06 | Werden Prototypen/schutzbedürftige Entwicklungsobjekte verarbeitet? | boolean | immer | schaltet Prüfziel Prototypenschutz (8.x); bei „nein" 8.x ausgeblendet | - -## 3. Abschnitt B — Rollen (→ Schritt 3, Paket C7) - -| Frage-ID | Frage | Antworttyp | Anzeige-Bedingung | Wirkung | -|---|---|---|---|---| -| Q-ROLE-01 | Oberste Leitung (Name/Funktion)? | text | immer | Variable `ROLE_MANAGEMENT` | -| Q-ROLE-02 | Informationssicherheitsbeauftragte(r)/CISO? intern/extern? | text + single-select | immer | Variable `ROLE_ISB`; Funktionstrennungsprüfung (C7); bei fehlend → Aufgabe „ISB bestellen" | -| Q-ROLE-03 | IT-Leitung / IT-Verantwortung (intern/extern)? | text | immer | Variable `ROLE_IT_LEAD`; Input Funktionstrennung ISB≠IT (C7) | -| Q-ROLE-04 | Personalleitung? | text | immer | Variable `ROLE_HR_LEAD` | -| Q-ROLE-05 | Datenschutzbeauftragte(r)? | text | `FLAG_PERSONAL_DATA` | Variable `ROLE_DPO` | - -## 4. Abschnitt C — Governance & Betriebsrahmen - -| Frage-ID | Frage | Antworttyp | Anzeige-Bedingung | Wirkung | -|---|---|---|---|---| -| Q-GOV-01 | Name des eingesetzten ISMS-Tools? | text | immer | Variable `TOOL_NAME` | -| Q-GOV-02 | Ticket-/Workflow-System (Dokumentationsort)? | text | immer | Variable `TOOL_TICKET` (BL-IAM-07, BL-OPS-02/09) | -| Q-GOV-03 | Verzeichnis-/IAM-System? | text | immer | Variable `TOOL_IAM` (BL-IAM-06/07) | -| Q-GOV-04 | Revisions-/Prüfzyklus? | single-select (jährlich/…) | immer | Variable `REVIEW_CYCLE` (BL-HR-01, BL-GOV-01) | -| Q-GOV-05 | Ziel-Reifegrad – SOLL-Anforderungen einbeziehen? | boolean (Default ja) | immer | Flag `FLAG_INCLUDE_SHOULD`; blendet alle `[SOLL]`-Blöcke ein/aus | - -## 5. Abschnitt D — Feature-Fragen (steuern `FLAG_*`, Klauseln, Controls, Risiken) - -Diese Fragen sind der Kern der Regel-Engine: jede Antwort blendet Vorlagenklauseln ein/aus, schaltet Controls in den Scope und schlägt Risiken vor. - -| Frage-ID | Frage | Antworttyp | Anzeige-Bedingung | Wirkung (Flag · Klausel/Control · Risiko/Aufgabe) | -|---|---|---|---|---| -| Q-FEAT-01 | Schutzbedarf im Scope – höchste Stufe? (normal / hoch / sehr hoch) | single-select | immer | `FLAG_HIGH_PROTECTION` (hoch|sehr hoch), `FLAG_VERY_HIGH_PROTECTION` (sehr hoch), abgeleitet `FLAG_ELEVATED_PROTECTION`; blendet `[HOCH]`/`[SEHR HOCH]`-Anforderungen + `-elev`-Umsetzungstexte ein | -| Q-FEAT-02 | Werden Cloud-Dienste genutzt? | boolean | immer | `FLAG_CLOUD_USED`; R12-Klauseln + Controls 5.3.2/5.3.4/6.1.3; Risiken R-CLOUD-* | -| Q-FEAT-03 | Werden KI-/GenAI-Dienste genutzt? | boolean | immer | `FLAG_AI_USED`; R12-KI-Klauseln + Control 5.3.4-KI · VA-11; Risiko R-AI-* | -| Q-FEAT-04 | Produktions-/OT-Umgebung vorhanden? | boolean | immer | `FLAG_OT_USED`; BL-NET-01 OT-Segmentierung; Risiken R-OT-* | -| Q-FEAT-05 | Eigene Software-Entwicklung? | boolean | immer | `FLAG_DEV_INHOUSE`; R11-Klauseln + Controls 5.3.1 · VA-16; Risiko R-DEV-* | -| Q-FEAT-06 | Mobiles Arbeiten / Homeoffice zugelassen? | boolean | immer | `FLAG_MOBILE_WORK`; R06-Klauseln + Control 2.1.4 | -| Q-FEAT-07 | Mobile Endgeräte / Datenträger im Einsatz? | boolean | immer | `FLAG_MOBILE_DEVICES`; R06/BL-EP-*; Control 3.1.4; Risiko R-PHY-mobile | -| Q-FEAT-08 | Eigene PKI / Zertifikatsverwaltung? | boolean | immer | `FLAG_CRYPTO_PKI`; BL-CRY-05 PKI-Klausel; Control 5.1.1 | -| Q-FEAT-09 | Externe IT-Dienstleister genutzt? | boolean | immer | `FLAG_EXTERNAL_IT`; R13-Klauseln + Controls 6.1.1/6.1.3 · VA-10; Risiko R-SUP-*; bei „ja" → Aufgabe „Dienstleister-Selbstauskunft einholen" | -| Q-FEAT-10 | Zugriff auf Kundensysteme (z. B. OEM)? | boolean | immer | `FLAG_CUSTOMER_SYSTEMS`; Klauseln „Konten in Kundensystemen" in R08/R13 (Controls 4.1.3/4.2.1/6.1.x) | - -## 6. Abschnitt E — Technische Baseline (Defaults bestätigen/anpassen) - -Vorbelegt aus `Technische-Sicherheits-Baseline.md`. Je Frage wird der Default angezeigt; Änderung schreibt die zugehörige Variable. Anzeige gruppiert; nur relevante bei gesetztem Flag. - -| Frage-ID | Frage (Parameter) | Variable / Baseline-ID | Anzeige-Bedingung | -|---|---|---|---| -| Q-BL-01 | Passwort-Mindestlänge / Komplexität / Rotation | `PW_MIN_LENGTH`,`PW_COMPLEXITY`,`PW_ROTATION` (BL-IAM-01) | immer | -| Q-BL-02 | MFA-Geltungsbereich | `MFA_SCOPE` (BL-IAM-02) | immer | -| Q-BL-03 | Sitzungs-Timeout | `SESSION_TIMEOUT` (BL-IAM-03) | immer | -| Q-BL-04 | Kontosperrung | `ACCOUNT_LOCKOUT` (BL-IAM-04) | immer | -| Q-BL-05 | Rezertifizierungs-Frequenz | `RECERT_FREQ` (BL-IAM-05) | immer | -| Q-BL-06 | Mindest-TLS / zulässige Algorithmen | `TLS_MIN`,`CRYPTO_ALGO` (BL-CRY-01/02) | immer | -| Q-BL-07 | Patch-SLAs (kritisch/hoch/standard) | `PATCH_SLA_CRIT/HIGH/STD` (BL-OPS-01) | immer | -| Q-BL-08 | Schwachstellenscan-Frequenz | `VULN_SCAN_FREQ` (BL-OPS-02) | immer | -| Q-BL-09 | Malware-Update-Frequenz | `MALWARE_UPDATE` (BL-OPS-03) | immer | -| Q-BL-10 | Log-Aufbewahrung | `LOG_RETENTION` (BL-OPS-04) | immer | -| Q-BL-11 | Backup-Schema / Aufbewahrung / Testfrequenz | `BACKUP_SCHEME/RETENTION/TEST_FREQ` (BL-OPS-05/06) | immer | -| Q-BL-12 | Penetrationstest-Frequenz | `PENTEST_FREQ` (BL-OPS-08) | `FLAG_ELEVATED_PROTECTION` | -| Q-BL-13 | Eingesetzte Lösungen: MFA/Malware/Backup/SIEM/MDM/VPN | `TECH_MFA/MALWARE/BACKUP/SIEM/MDM/VPN` | jeweils bei zugehörigem Flag | -| Q-BL-14 | Krypto-Standardvorgabe | `TECH_CRYPTO` (BL-CRY-02) | immer | - -## 7. Abschnitt F — Dokument-Metadaten - -| Frage-ID | Frage | Variable | -|---|---|---| -| Q-DOC-01 | Dokument-Version (Default 1.0) | `DOC_VERSION` | -| Q-DOC-02 | Dokument-Datum | `DOC_DATE` | -| Q-DOC-03 | Dokument-Status (Entwurf/In Freigabe/Freigegeben) | `DOC_STATUS` | - ---- - -## 8. Aufgaben-Trigger aus Antworten (Auszug) - -| Auslösende Antwort | Aufgabe (Typ) | -|---|---| -| Q-ROLE-02 „ISB nicht benannt" | `organizational` – ISB bestellen (verknüpft Control 1.2.2) | -| Q-ROLE-02/03 ISB = IT-Verantwortung | `organizational` – Funktionstrennung herstellen/kompensieren (C7) | -| Q-FEAT-09 „externe IT-Dienstleister = ja" | `evidence_provide` – Selbstauskunft/TISAX-Nachweis einholen (Control 6.1.1) | -| Q-FEAT-02/03 Cloud/KI = ja, ohne Freigabeverfahren | `document_create` – Cloud-/KI-Freigabeverfahren aktivieren (VA-11) | -| Q-BL-11 „kein Wiederherstellungstest" | `technical` – Restore-Test etablieren (BL-OPS-06, Control 5.2.9) | - -> Hinweis: Die vollständige Antwort→Wirkung-Matrix wird maschinenlesbar als Regelobjekte (B2-DSL) hinterlegt; diese Tabelle ist die fachliche Spezifikation dafür. Neue `FLAG_*` bitte zuerst in `variables.schema.json` ergänzen (Single Source of Truth), dann Frage + Wirkung hier. diff --git a/docs/wizard-uebergabe/02_Fachcontent_C1-C9/C3_Vorlagen-Annotation.md b/docs/wizard-uebergabe/02_Fachcontent_C1-C9/C3_Vorlagen-Annotation.md deleted file mode 100644 index b660fd8..0000000 --- a/docs/wizard-uebergabe/02_Fachcontent_C1-C9/C3_Vorlagen-Annotation.md +++ /dev/null @@ -1,49 +0,0 @@ -# C3 — Regelfähige Vorlagen-Auszeichnung (Annotationskonvention + Verify + Erweiterung) - -> **Schaltet frei:** B4 (Richtlinien – Import + Upload + Control-Mapping). **Grundlage:** `isms-vorlagenpaket-v2/` (34 Vorlagen, `mapping.json`, `variables.schema.json`, `_verify.py`). - -## 1. Ist-Zustand (Informationssicherheit) — vollständig annotiert - -Das Vorlagenpaket ist für die **Informationssicherheit** bereits regelfähig ausgezeichnet und konsistent: - -- **34 Vorlagen** – Leitlinie `L00`, Richtlinien `R01–R14`, Verfahren `VA-01 … VA-19`, plus `Technische-Sicherheits-Baseline.md`, `Nachweisregister_zentral.md`, `ISA-Mapping-Matrix.md`. -- **316 Anforderungen** in `mapping.json` (312 ISA + 4 kundenspezifisch KI), je mit stabiler ID, `type`, `level`, `policy`, `condition`-Flag, `req_anchor`/`impl_anchor`, `verfahren`. -- **`python3 _verify.py` → OK** (Render ohne offene Platzhalter für `FLAG_INCLUDE_SHOULD` an/aus, keine verwaisten Anker, keine Handlebars-Reste). **Dieser Lauf ist die Abnahmebedingung jeder Änderung.** - -Für Informationssicherheit ist C3 damit als „bestätigt/konsistent" zu betrachten; die SME-Aufgabe ist Pflege + die Erweiterung um Prototypenschutz/Datenschutz (Abschnitt 3). - -## 2. Annotationskonvention (verbindlich für alle Vorlagen) - -| Konstrukt | Bedeutung | Beispiel | -|---|---|---| -| `{{VARIABLE}}` | Variable aus `variables.schema.json` | `{{ORG_NAME}}`, `{{MFA_SCOPE}}` | -| `{{#if FLAG_X}} … {{/if}}` | Bedingter Block (Feature-Flag/Reifegrad/Schutzbedarf) | `{{#if FLAG_HIGH_PROTECTION}} … {{/if}}` | -| `[MUSS]`/`[SOLL]`/`[HOCH]`/`[SEHR HOCH]` | Sichtbare Kennzeichnung der Anforderungsstufe | `- **[SOLL]** …` | -| `` | Hidden-Anker vor einer Einzelanforderung | `` | -| `` | Hidden-Anker vor dem Umsetzungstext (Control-gebündelt) | `` | -| `` | Umsetzungsvariante für erhöhten Schutzbedarf | `` | -| `{{LINK:ZIEL}}` | Laufzeit-Link (Dokument/Nachweisregister) | `{{LINK:R08#4.1.2}}` | -| Verfahrensanker `` | VA erfüllt Anforderungen | in `VA-*` | - -**Regeln für eine regelfähige Auszeichnung** - -1. Jede Einzelanforderung erhält genau einen ``-Anker, dessen ID exakt der `mapping.json`-`id` entspricht. -2. `[SOLL]` immer in `{{#if FLAG_INCLUDE_SHOULD}}`, `[HOCH]` in `{{#if FLAG_HIGH_PROTECTION}}`, `[SEHR HOCH]` in `{{#if FLAG_VERY_HIGH_PROTECTION}}`. Der `condition`-Wert in `mapping.json` und der `{{#if}}` im Dokument müssen übereinstimmen. -3. Feature-abhängige Klauseln (Cloud/KI/OT/Dev/Mobil/PKI/Extern/Kundensysteme) in den passenden `{{#if FLAG_*}}`-Block. -4. Konkrete Zahlenwerte nie hart schreiben, sondern über Baseline-Variable (`{{PW_MIN_LENGTH}}` …) referenzieren. -5. ``-Anker im Dokument belassen (im Lesemodus unsichtbar); nur der PDF-/Druckexport entfernt sie. -6. Nach jeder Änderung `python3 _verify.py` → **OK**. - -## 3. Erweiterung: Prototypenschutz (P01) + Datenschutz (D01) - -Das Paket ist „VDA ISA 2027 (Information Security)". Für die Prüfziele **Prototypenschutz (8.x)** und **Datenschutz (9.x)** sind Vorlagen + `mapping.json`-Einträge neu anzulegen — nach identischer Konvention. Vorschlag: - -- **Neue Vorlage `P01_Prototypenschutz.md`** (Richtlinie Prototypenschutz) + Verfahren `VA-20_Prototypen-Zutritt-und-Transport`. Deckt 8.1.x (physische Sicherheit/Perimeter/Zonen/Zutritt/Einbruch/Besucher/Mandantentrennung), 8.2.x (Geheimhaltung/Unterauftragnehmer/Schulung/Klassifizierung/Bildaufzeichnung), 8.3.x (Transport/Lagerung). 8.4.x/8.5.x nur bei erweitertem Prüfziel. -- **Neue Vorlage `D01_Datenschutz.md`** (Richtlinie Datenschutz) — kann `R14 Compliance & Datenschutz` erweitern/aufteilen; Verfahren `VA-18 Datenschutz-und-Compliance-Pflege` ist vorhanden. Deckt 9.1.x–9.8.x. -- Je neuer Anforderung ein `mapping.json`-Eintrag im gleichen Schema (`id`,`policy`=P01/D01,`control`,`level`,`type`,`is_isa`=true,`req_anchor`,`impl_anchor`,`condition`,`requirement`,`verfahren`). Anforderungs-IDs siehe C1/C6-Dekomposition (`8.1.1-M1` …, `9.1.1-M1` …). -- Neue `FLAG_*` bei Bedarf zuerst in `variables.schema.json` (z. B. `FLAG_PROTOTYPE_PROTECTION`), damit `_verify.py` sie kennt; Prototypenschutz-Klauseln in `{{#if FLAG_PROTOTYPE_PROTECTION}}`. -- `_verify.py` um die neuen Verzeichnisse/Anker erweitern, dann → **OK**. - -## 4. Control-Zuordnung beim manuellen Upload (B4b) - -Für hochgeladene **eigene** Richtlinien (kein Template): Pflichtfeld „belegt Controls" (Multi-Select aus dem Control-Katalog). Optional je Control die abgedeckten Anforderungs-IDs. Diese Zuordnung fließt wie ein ``-Anker in die Nachweislage (Schritt 7) — ohne Tailoring, aber mit voller Reifegrad-/Gap-Wirkung. Ein späterer Gap-Check (Dokumentinhalt ↔ Anforderungstext) ist als Option vorgesehen (offener Entscheidungspunkt). diff --git a/docs/wizard-uebergabe/02_Fachcontent_C1-C9/C4_Risikokatalog.md b/docs/wizard-uebergabe/02_Fachcontent_C1-C9/C4_Risikokatalog.md deleted file mode 100644 index e6a1272..0000000 --- a/docs/wizard-uebergabe/02_Fachcontent_C1-C9/C4_Risikokatalog.md +++ /dev/null @@ -1,169 +0,0 @@ -# C4 — Standard-Risikokatalog (VDA ISA / TISAX) - -**Paket:** C4 — Kuratierter Risiko-Katalog für den Onboarding-Wizard -**Modul:** Risikomanagement -**Referenzen:** R03 Risikomanagement · VA-09 Risikomanagement-Verfahren · VDA ISA (IS 1.x–7.x, Prototypenschutz 8.x, Datenschutz 9.x) · Baseline-Parameter BL-* - ---- - -## 1. Nutzung im Wizard-Schritt „Risikomanagement" - -Dieser Katalog wird dem Kunden im Onboarding-Wizard als kuratierte Vorauswahl typischer Informationssicherheits- und TISAX-Risiken angeboten. Der Ablauf: - -1. **Auswahl** — Der Kunde markiert die für seinen Scope zutreffenden Risiken. Nicht zutreffende Risiken (z. B. Prototypenschutz ohne physische Musterteile, Entwicklung ohne eigene Softwareentwicklung) werden abgewählt oder als „nicht anwendbar" begründet. -2. **Ergänzung** — Der Kunde ergänzt eigene, organisationsspezifische Risiken. -3. **Bewertung** — Jedes ausgewählte Risiko wird nach der 5×5-Matrix bewertet (Eintrittswahrscheinlichkeit × Schadenshöhe). Die im Katalog hinterlegte **Default-Einschätzung** ist ein Startwert und vom Kunden anzupassen. -4. **Maßnahmenableitung** — Aus dem bewerteten Risiko werden Maßnahmen abgeleitet (Standardmaßnahmen sind vorbelegt). Maßnahmen erzeugen im System **Aufgaben** mit Verantwortlichen und Fristen. -5. **Restrisiko** — Nach Maßnahmenumsetzung erfolgt eine erneute Bewertung (Netto-/Restrisiko). Restrisiken oberhalb der Akzeptanzschwelle erfordern eine dokumentierte Risikoakzeptanz durch die Leitung (siehe VA-09). - -### Bewertungslogik (5×5) - -| Achse | Stufen | Kurzdefinition | -|-------|--------|----------------| -| **Eintrittswahrscheinlichkeit (E)** | 1 sehr gering · 2 gering · 3 mittel · 4 hoch · 5 sehr hoch | Erwartete Häufigkeit im Betrachtungszeitraum (i. d. R. 12 Monate) | -| **Schadenshöhe (S)** | 1 vernachlässigbar · 2 gering · 3 spürbar · 4 hoch · 5 existenzbedrohend | Auswirkung auf Vertraulichkeit/Integrität/Verfügbarkeit, Vertrag, Reputation, Recht | - -**Risikowert = E × S** (1–25). Klassifizierung gemäß VA-09: - -- **1–4 gering** (grün) — beobachten, ggf. akzeptieren -- **5–9 mittel** (gelb) — Maßnahmen empfohlen -- **10–15 hoch** (orange) — Maßnahmen verbindlich, Termin gesetzt -- **16–25 sehr hoch** (rot) — Sofortmaßnahmen, Eskalation an Leitung - -Die Default-Einschätzung je Risiko ist als **E/S** angegeben (z. B. „E3/S4"). Sie geht von einem typischen KMU-Zuliefererbetrieb ohne bereits umgesetzte Maßnahmen aus (Brutto-/Ausgangsrisiko). - -### ID-Schema - -`R--` — Kategorien: ORG (Organisation/Governance), HR (Personal), PHY (Physisch), IAM (Identitäts-/Zugriffsmanagement), CRY (Kryptografie), OPS (Betrieb/IT), NET (Netzwerk), SUP (Lieferanten/Cloud), DEV (Entwicklung), PROTO (Prototypenschutz), DSGVO (Datenschutz). - ---- - -## 2. Organisation / Governance - -| Risiko-ID | Titel | Beschreibung | Betroffene Controls (VDA ISA) | Asset-Typen | Standardmaßnahme(n) | Default (E/S) | -|-----------|-------|--------------|-------------------------------|-------------|---------------------|---------------| -| R-ORG-01 | Fehlende/veraltete IS-Leitlinie & Verantwortlichkeiten | Es existiert keine von der Leitung verabschiedete Informationssicherheitsleitlinie oder Rollen (ISB/CISO) sind nicht benannt, sodass Steuerung und Verbindlichkeit fehlen. | 1.1.1, 1.2.1, 1.3.1 | Richtlinien, Organisation | IS-Leitlinie nach R03 erstellen/aktualisieren, ISB benennen, jährliches Management-Review etablieren | E3/S4 — ohne Governance keine wirksame Steuerung; Schaden trifft gesamtes ISMS | -| R-ORG-02 | Kein funktionierendes Risikomanagement | Risiken werden nicht systematisch erfasst, bewertet oder behandelt; TISAX-Anforderung an Risikoprozess ist nicht erfüllt. | 1.4.1 | Prozesse, Dokumentation | Risikomanagement-Verfahren VA-09 einführen, Risiko-Register führen, Reviews terminieren | E3/S4 — Kernanforderung TISAX; Assessment-Abweichung wahrscheinlich | -| R-ORG-03 | Fehlendes Asset- und Informationsklassifizierungsschema | Werte (Informationen, Systeme) sind nicht inventarisiert oder klassifiziert, sodass Schutzbedarf und Maßnahmen nicht zielgerichtet zugeordnet werden können. | 1.3.2, 1.3.3, 5.2.x | Informationswerte, Inventar | Asset-Inventar aufbauen, Klassifizierungsschema (intern/vertraulich/streng vertraulich) einführen und kennzeichnen | E3/S3 — Grundlage vieler Controls; ohne Klassifizierung Fehlschutz | -| R-ORG-04 | Unzureichende IS-Vorgabendokumentation / veraltete Verfahren | Verfahrensanweisungen und Richtlinien sind nicht vorhanden, veraltet oder werden nicht gelebt, was zu inkonsistentem Handeln führt. | 1.2.x, 1.5.1 | Dokumentation | Dokumentenlenkung nach R03 etablieren, Review-Zyklus (jährlich), Freigabe- und Versionskontrolle | E3/S3 — Nachweisführung im Assessment gefährdet | -| R-ORG-05 | Fehlendes Vorfalls- / Incident-Management | Sicherheitsvorfälle werden nicht erkannt, gemeldet, dokumentiert oder ausgewertet, wodurch Schäden eskalieren und Lernen ausbleibt. | 1.6.1 | Prozesse | Incident-Response-Prozess einführen, Meldewege und Eskalation definieren, Vorfallregister führen | E3/S4 — verzögerte Reaktion vergrößert Schaden erheblich | -| R-ORG-06 | Fehlendes Business Continuity / Notfallmanagement | Für Ausfälle kritischer Prozesse/IT existieren keine Notfall- und Wiederanlaufpläne, sodass Betriebsunterbrechungen unkontrolliert verlaufen. | 1.6.x, 7.x | Prozesse, IT-Systeme | BCM-Konzept und Wiederanlaufpläne erstellen, Notfallübungen jährlich, Bezug zu BL-OPS-05 (Backup) | E2/S4 — selten, aber hoher Schaden bei Eintritt | - ---- - -## 3. Personal - -| Risiko-ID | Titel | Beschreibung | Betroffene Controls (VDA ISA) | Asset-Typen | Standardmaßnahme(n) | Default (E/S) | -|-----------|-------|--------------|-------------------------------|-------------|---------------------|---------------| -| R-HR-01 | Mangelndes Sicherheitsbewusstsein der Mitarbeitenden | Beschäftigte sind nicht regelmäßig geschult und fallen auf Phishing/Social Engineering herein oder handeln fahrlässig. | 2.1.2, 2.1.3 | Personal, Informationen | Awareness-Programm und jährliche Schulungen einführen, Phishing-Simulationen, Schulungsnachweise dokumentieren | E4/S3 — Mensch häufigster Angriffsvektor | -| R-HR-02 | Fehlende Vertraulichkeits-/Geheimhaltungsvereinbarungen | Mit Mitarbeitenden, Zeitarbeit oder Externen sind keine NDAs abgeschlossen, sodass der Schutz vertraulicher Informationen rechtlich nicht abgesichert ist. | 2.1.1 | Verträge, Personal | NDA/Verpflichtung auf Vertraulichkeit in Onboarding-Prozess verankern, Bestand nachpflegen | E3/S3 — häufige Lücke bei Externen/Zeitarbeit | -| R-HR-03 | Unsicheres On-/Offboarding (Berechtigungen bei Austritt) | Bei Eintritt, Wechsel oder Austritt werden Zugänge und Assets nicht zeitnah vergeben/entzogen, sodass verwaiste Konten und Datenmitnahme entstehen. | 2.1.x, 3.1.1 | Konten, Endgeräte | On-/Offboarding-Checkliste mit HR/IT, Fristen für Kontoentzug und Asset-Rückgabe, regelmäßiger Abgleich | E3/S3 — verwaiste Konten sind typischer Auditfund | -| R-HR-04 | Innentäter / Datenmitnahme durch Mitarbeitende | Berechtigte Personen entwenden oder missbrauchen vorsätzlich Informationen (z. B. Konstruktionsdaten) zum eigenen Vorteil oder für Wettbewerber. | 2.1.x, 5.2.x, 3.1.x | Informationen, geistiges Eigentum | Need-to-know umsetzen, Protokollierung sensibler Zugriffe, DLP-Ansätze, arbeitsrechtliche Regelungen | E2/S4 — selten, aber sehr hoher Schaden für IP | - ---- - -## 4. Physische Sicherheit - -| Risiko-ID | Titel | Beschreibung | Betroffene Controls (VDA ISA) | Asset-Typen | Standardmaßnahme(n) | Default (E/S) | -|-----------|-------|--------------|-------------------------------|-------------|---------------------|---------------| -| R-PHY-01 | Unberechtigter Zutritt zu Betriebs-/Sicherheitsbereichen | Fehlende Zutrittskontrolle ermöglicht Unbefugten Zugang zu Büros, Serverräumen oder Fertigung, mit Diebstahl- und Manipulationsrisiko. | 4.1.1, 4.1.2 | Gebäude, IT-Systeme | Zonenkonzept, Zutrittskontrollsystem/Schließplan, Besucherregelung mit Begleitung und Protokoll | E3/S3 — Grundschutzanforderung, oft lückenhaft | -| R-PHY-02 | Unzureichender Schutz von Server-/Technikräumen | Serverräume sind nicht ausreichend gegen Zutritt, Brand, Wasser, Strom-/Klimaausfall geschützt, was zu Ausfall oder Datenverlust führt. | 4.1.x, 7.x | IT-Infrastruktur | Technikraum absichern (Zutritt, USV, Klima, Brand-/Wasserschutz), Umgebungsüberwachung | E2/S4 — geringe Häufigkeit, hoher Ausfallschaden | -| R-PHY-03 | Diebstahl/Verlust von Datenträgern und Dokumenten | Papierunterlagen, USB-Medien oder Datenträger mit vertraulichen Informationen gehen verloren oder werden entwendet. | 4.1.x, 5.2.x | Datenträger, Dokumente | Clean-Desk-Policy, verschließbare Schränke, sichere Entsorgung (Schredder/zertifiziert), Medienverschlüsselung | E3/S3 — alltägliches Restrisiko | - ---- - -## 5. Identitäts- und Zugriffsmanagement (IAM) - -| Risiko-ID | Titel | Beschreibung | Betroffene Controls (VDA ISA) | Asset-Typen | Standardmaßnahme(n) | Default (E/S) | -|-----------|-------|--------------|-------------------------------|-------------|---------------------|---------------| -| R-IAM-01 | Fehlberechtigungen / überzogene Zugriffsrechte | Zugriffsrechte folgen nicht dem Need-to-know- und Least-Privilege-Prinzip; Sammelrechte und Rechteakkumulation entstehen. | 3.1.1, 3.1.2, 3.1.3 | Konten, Anwendungen, Daten | Rollen-/Rechtekonzept (RBAC), regelmäßige Rezertifizierung der Berechtigungen, Trennung von Funktionen | E4/S3 — häufigster Auditfund im IAM | -| R-IAM-02 | Schwache Authentisierung / fehlende MFA | Zugänge (insb. remote, Admin, Cloud) sind nur durch schwache Passwörter geschützt, wodurch Kontoübernahmen leicht möglich sind. | 3.1.4, 3.1.5 | Konten, Zugänge | Passwortrichtlinie (BL-IAM-*), MFA für Remote-/Admin-/Cloud-Zugänge verpflichtend, SSO | E4/S4 — Credential-Angriffe sehr häufig und wirksam | -| R-IAM-03 | Ungesicherte / geteilte privilegierte Konten | Administrative und Sammelkonten werden geteilt genutzt und nicht überwacht, sodass Handlungen nicht zurechenbar sind. | 3.1.x | Admin-Konten | Privileged-Access-Management, personalisierte Admin-Konten, Protokollierung, getrennte Admin-Arbeitsplätze | E3/S4 — Missbrauch privilegierter Rechte hochwirksam | - ---- - -## 6. Kryptografie - -| Risiko-ID | Titel | Beschreibung | Betroffene Controls (VDA ISA) | Asset-Typen | Standardmaßnahme(n) | Default (E/S) | -|-----------|-------|--------------|-------------------------------|-------------|---------------------|---------------| -| R-CRY-01 | Fehlende Verschlüsselung mobiler Geräte / Datenträger | Notebooks, Smartphones und Wechselmedien sind nicht verschlüsselt, sodass bei Verlust/Diebstahl Daten unmittelbar lesbar sind. | 5.1.1, 5.1.2 | Endgeräte, Datenträger | Full-Disk-Encryption (BitLocker/FileVault) verpflichtend, MDM-erzwungene Verschlüsselung, Medienrichtlinie | E3/S4 — Verlustfall führt sonst direkt zu Datenabfluss | -| R-CRY-02 | Unsichere Datenübertragung (fehlende Transportverschlüsselung) | Vertrauliche Daten werden unverschlüsselt (E-Mail, FTP, HTTP) übertragen und können abgefangen werden. | 5.1.1 | Kommunikation, Daten | TLS erzwingen, sichere Austauschwege/Portale, E-Mail-Verschlüsselung für vertrauliche Inhalte | E3/S3 — Abfangrisiko bei Zulieferaustausch | -| R-CRY-03 | Unzureichendes Schlüssel-/Zertifikatsmanagement | Kryptografische Schlüssel und Zertifikate werden nicht sicher verwaltet oder laufen unbemerkt ab, was zu Ausfällen oder Kompromittierung führt. | 5.1.x | Schlüssel, Zertifikate | Krypto-Richtlinie, zentrale Schlüssel-/Zertifikatsverwaltung, Ablaufüberwachung, sichere Aufbewahrung | E2/S3 — schleichender, aber wirkungsvoller Ausfall | - ---- - -## 7. Betrieb / IT - -| Risiko-ID | Titel | Beschreibung | Betroffene Controls (VDA ISA) | Asset-Typen | Standardmaßnahme(n) | Default (E/S) | -|-----------|-------|--------------|-------------------------------|-------------|---------------------|---------------| -| R-OPS-01 | Fehlendes/mangelhaftes Patch- und Schwachstellenmanagement | Betriebssysteme und Anwendungen werden nicht zeitnah aktualisiert, sodass bekannte Schwachstellen ausnutzbar bleiben. | 5.2.4, 5.2.5 | IT-Systeme, Software | Patchmanagement-Prozess mit Fristen nach Kritikalität, Schwachstellenscans, Vulnerability-Tracking | E4/S4 — meistgenutztes Einfallstor, hohe Angriffsfläche | -| R-OPS-02 | Schadsoftware / Ransomware-Befall | Malware gelangt über E-Mail, Wechselmedien oder Web ins Netz und verschlüsselt oder exfiltriert Daten. | 5.2.3 | IT-Systeme, Daten | Endpoint-Protection/EDR flächendeckend, E-Mail-/Web-Filter, Makro-Restriktionen, Awareness (R-HR-01) | E4/S5 — hohe Häufigkeit, potenziell existenzbedrohend | -| R-OPS-03 | Backup-/Wiederanlauf-Versagen | Datensicherungen fehlen, sind unvollständig, nicht getestet oder mitverschlüsselbar, sodass eine Wiederherstellung im Ernstfall scheitert. | 7.x | Daten, IT-Systeme | Backup-Konzept nach BL-OPS-05 (3-2-1, Offline-/Immutable-Kopie), regelmäßige Restore-Tests, RTO/RPO definieren | E3/S5 — im Ransomware-Fall entscheidend für Überleben | -| R-OPS-04 | Fehlende Protokollierung und Überwachung (Logging/Monitoring) | Sicherheitsrelevante Ereignisse werden nicht protokolliert oder ausgewertet, sodass Angriffe unentdeckt bleiben. | 5.2.6 | IT-Systeme, Logs | Zentrales Logging, Log-Auswertung/SIEM-Ansatz, Aufbewahrungsfristen, Alarmierung bei Auffälligkeiten | E3/S3 — verlängert Entdeckungszeit erheblich | -| R-OPS-05 | Schatten-IT / nicht genehmigte Software & Dienste | Mitarbeitende nutzen nicht freigegebene Cloud-Dienste oder Software, wodurch Daten unkontrolliert abfließen und Schwachstellen entstehen. | 5.2.x, 6.1.x | Anwendungen, Daten | Freigabeprozess für Software/Dienste, Anwendungsinventar, technische Restriktionen, Awareness | E3/S3 — verbreitet, schwer sichtbar | -| R-OPS-06 | Fehlkonfiguration / fehlendes Change-Management | Systeme werden ohne kontrollierte Änderungsprozesse betrieben, sodass Fehlkonfigurationen Sicherheitslücken und Ausfälle verursachen. | 5.2.1, 5.2.2 | IT-Systeme, Konfiguration | Härtungs-/Konfigurationsvorgaben (Baselines), Change-Management-Prozess, Test vor Produktivsetzung | E3/S3 — Fehlkonfiguration häufige Ausfall-/Angriffsursache | -| R-OPS-07 | Verlust/Diebstahl mobiler Endgeräte | Notebooks, Smartphones oder Tablets gehen unterwegs verloren oder werden gestohlen und ermöglichen Zugriff auf Daten und Systeme. | 5.2.x, 5.1.1 | Endgeräte, Daten | MDM mit Remote-Wipe, Geräteverschlüsselung (R-CRY-01), Bildschirmsperre, Verlustmeldeprozess | E3/S3 — mobiles Arbeiten erhöht Häufigkeit | -| R-OPS-08 | Fehlende sichere Entsorgung / Wiederverwendung von IT | Ausgemusterte Geräte und Datenträger werden ohne sichere Löschung entsorgt oder weitergegeben, sodass Restdaten abfließen. | 5.2.x, 4.1.x | Datenträger, Endgeräte | Prozess zur sicheren Löschung/Vernichtung, zertifizierte Entsorgung, Nachweisführung | E2/S3 — selten, aber unbemerkter Datenabfluss | - ---- - -## 8. Netzwerk - -| Risiko-ID | Titel | Beschreibung | Betroffene Controls (VDA ISA) | Asset-Typen | Standardmaßnahme(n) | Default (E/S) | -|-----------|-------|--------------|-------------------------------|-------------|---------------------|---------------| -| R-NET-01 | Unsichere Netzsegmentierung / flaches Netz | Fehlende Trennung zwischen Office-, Produktions-/OT- und Gastnetzen ermöglicht laterale Ausbreitung von Angriffen. | 5.2.x | Netzwerk, IT-Systeme | Netzsegmentierung (VLAN/Zonen), Firewall-Regelwerk, Trennung OT/IT und Gast-WLAN | E3/S4 — begünstigt großflächige Kompromittierung | -| R-NET-02 | Unsicherer Remote-/VPN-Zugang | Fernzugriffe sind nicht ausreichend abgesichert (kein MFA, offene Ports, veraltete VPN-Gateways) und werden angegriffen. | 5.2.x, 3.1.4 | Zugänge, Netzwerk | Gehärtetes VPN mit MFA, Zugriff nach Least-Privilege, Patching der Gateways, Zugriffprotokollierung | E3/S4 — Remote-Zugänge sind bevorzugtes Angriffsziel | -| R-NET-03 | Unzureichender Perimeter-/Firewall-Schutz | Fehlende oder falsch konfigurierte Firewalls und exponierte Dienste erlauben direkte Angriffe aus dem Internet. | 5.2.x | Netzwerk, IT-Systeme | Firewall mit restriktivem Regelwerk, regelmäßige Regel-Reviews, Minimierung exponierter Dienste, externe Scans | E3/S4 — exponierte Dienste werden automatisiert angegriffen | - ---- - -## 9. Lieferanten / Cloud - -| Risiko-ID | Titel | Beschreibung | Betroffene Controls (VDA ISA) | Asset-Typen | Standardmaßnahme(n) | Default (E/S) | -|-----------|-------|--------------|-------------------------------|-------------|---------------------|---------------| -| R-SUP-01 | Lieferanten/Dienstleister ohne IS-Nachweis | Externe Partner mit Zugriff auf Informationen/Systeme verfügen über kein nachgewiesenes IS-Niveau (z. B. TISAX/ISO 27001), was Risiken in die Lieferkette trägt. | 6.1.1, 6.1.2 | Verträge, Lieferanten | Lieferantenbewertung, IS-Anforderungen und Nachweise vertraglich fordern, TISAX-Label bei sensiblen Daten | E3/S4 — Kettenrisiko, TISAX-relevant für Weitergabe | -| R-SUP-02 | Unzureichende vertragliche IS-Regelungen mit Dienstleistern | Verträge enthalten keine Vorgaben zu Vertraulichkeit, Rückgabe/Löschung, Audit- und Meldepflichten. | 6.1.x | Verträge | Standard-IS-Vertragsklauseln/Anlage, Regelungen zu Löschung, Subunternehmern, Meldung von Vorfällen | E3/S3 — Nachweislücke bei Audit | -| R-SUP-03 | Abhängigkeit von Cloud-Diensten / Datenabfluss in die Cloud | Vertrauliche Daten liegen bei Cloud-Anbietern ohne ausreichende Kontrolle über Standort, Zugriff und Ausfallabsicherung. | 6.1.x, 9.x | Cloud-Dienste, Daten | Cloud-Nutzungsrichtlinie, Anbieterprüfung (Zertifikate, Standort), Verschlüsselung, AVV bei Personenbezug | E3/S4 — Kontrollverlust und Lock-in | -| R-SUP-04 | Kompromittierung über die Software-Lieferkette | Manipulierte Updates, Bibliotheken oder Fernwartungszugänge von Dienstleistern führen zu Kompromittierungen. | 6.1.x, 5.2.x | Software, Zugänge | Bezugsquellen prüfen, Signaturen verifizieren, Fernwartungszugänge kontrollieren und protokollieren | E2/S4 — selten, aber weitreichende Wirkung | - ---- - -## 10. Entwicklung - -| Risiko-ID | Titel | Beschreibung | Betroffene Controls (VDA ISA) | Asset-Typen | Standardmaßnahme(n) | Default (E/S) | -|-----------|-------|--------------|-------------------------------|-------------|---------------------|---------------| -| R-DEV-01 | Abfluss von Entwicklungs-/Konstruktionsdaten | Vertrauliche Entwicklungsdaten (CAD, Spezifikationen, Quellcode) gelangen unkontrolliert nach außen (Cloud, Mail, private Geräte). | 5.2.x, 8.x, 6.1.x | Entwicklungsdaten, IP | Klassifizierung und Zugriffsbeschränkung (Need-to-know), sichere Austauschwege, DLP, Repository-Absicherung | E3/S5 — Kernwert des Zulieferers, hoher IP-Schaden | -| R-DEV-02 | Unsichere Software-Entwicklung (fehlender Secure SDLC) | Sicherheitsanforderungen werden in Entwicklung und Tests nicht berücksichtigt, sodass verwundbare Produkte/Software entstehen. | 5.2.x | Quellcode, Anwendungen | Secure-Coding-Vorgaben, Code-Reviews/SAST, Sicherheitstests, Trennung Entwicklungs-/Produktivumgebung | E3/S3 — je nach Entwicklungsanteil relevant | -| R-DEV-03 | Testdaten mit Echt-/Produktivdaten | In Entwicklungs- und Testumgebungen werden ungeschützte Produktiv- oder Personendaten verwendet und exponiert. | 5.2.x, 9.x | Testdaten, Personendaten | Anonymisierung/Pseudonymisierung von Testdaten, Zugriffsbeschränkung Testumgebung, Löschkonzept | E3/S3 — verbreitete Praxis, auch datenschutzrelevant | - ---- - -## 11. Prototypenschutz - -| Risiko-ID | Titel | Beschreibung | Betroffene Controls (VDA ISA) | Asset-Typen | Standardmaßnahme(n) | Default (E/S) | -|-----------|-------|--------------|-------------------------------|-------------|---------------------|---------------| -| R-PROTO-01 | Unberechtigter Zutritt zu Prototypen-/Musterbereichen | Unbefugte erlangen Zugang zu Bereichen mit Prototypen, Musterteilen oder Vorserien und können diese einsehen, fotografieren oder entwenden. | 8.1.x, 8.2.x | Prototypen, Räumlichkeiten | Sicherheitszonen mit Zutrittskontrolle, Begleitpflicht, Kamera-/Fotografierverbot, Besucherregelung | E3/S4 — TISAX-Prototypenschutz Kernrisiko | -| R-PROTO-02 | Unzureichender Schutz bei Erprobung/Transport von Prototypen | Bei Fahrzeugerprobung, Foto/Film oder Transport werden Prototypen unzureichend getarnt/gesichert und Dritten zugänglich. | 8.3.x, 8.4.x | Prototypen, Fahrzeuge | Tarnung/Abdeckung, gesicherte Transporte, Regelungen für Erprobung und Foto/Film, Geheimhaltungszonen | E2/S4 — seltener, aber öffentlichkeitswirksamer Schaden | -| R-PROTO-03 | Informationsabfluss zu geschützten Produkten/Projekten | Informationen zu geheimhaltungsbedürftigen Fahrzeugprojekten (Bilder, Daten, Termine) gelangen an Unbefugte oder in soziale Medien. | 8.1.x, 8.2.x | Projektinformationen | Verschärfte Klassifizierung/Kennzeichnung, Need-to-know, Schulung Prototypenschutz, Mobilgeräte-Restriktionen | E3/S4 — Reputations- und Vertragsschaden beim OEM | - ---- - -## 12. Datenschutz - -| Risiko-ID | Titel | Beschreibung | Betroffene Controls (VDA ISA) | Asset-Typen | Standardmaßnahme(n) | Default (E/S) | -|-----------|-------|--------------|-------------------------------|-------------|---------------------|---------------| -| R-DSGVO-01 | Datenschutzverstoß / meldepflichtige Datenpanne | Personenbezogene Daten werden unrechtmäßig offengelegt, verloren oder verarbeitet, was zu Meldepflicht (Art. 33/34), Bußgeld und Reputationsschaden führt. | 9.x | Personendaten | Datenschutz-Managementprozess, Datenpannen-Meldeprozess (72 h), technische/organisatorische Maßnahmen (TOM) | E3/S4 — hohe Bußgeld- und Meldepflichtrelevanz | -| R-DSGVO-02 | Fehlende Auftragsverarbeitungsverträge (AVV) | Für Dienstleister, die personenbezogene Daten verarbeiten, fehlen AVV nach Art. 28 DSGVO, sodass Verarbeitung unrechtmäßig ist. | 9.x, 6.1.x | Verträge, Personendaten | AVV-Prozess etablieren, Bestand prüfen und nachholen, Dienstleister mit Personenbezug erfassen | E3/S3 — häufige Lücke, aufsichtsrelevant | -| R-DSGVO-03 | Fehlendes Verarbeitungsverzeichnis / keine Rechtsgrundlagen | Verarbeitungstätigkeiten sind nicht dokumentiert (Art. 30) oder ohne Rechtsgrundlage, sodass Nachweispflichten verletzt werden. | 9.x | Dokumentation, Personendaten | Verzeichnis von Verarbeitungstätigkeiten führen, Rechtsgrundlagen prüfen, Löschkonzept/Fristen definieren | E3/S3 — Rechenschaftspflicht, Auditfund | -| R-DSGVO-04 | Unzulässige Übermittlung in Drittländer | Personenbezogene Daten werden ohne geeignete Garantien in Drittländer (z. B. über Cloud-Dienste) übermittelt. | 9.x, 6.1.x | Personendaten, Cloud-Dienste | Datenflüsse prüfen, Standardvertragsklauseln/Transfer-Impact-Assessment, EU-Verarbeitung bevorzugen | E2/S4 — komplex, hohe aufsichtsrechtliche Relevanz | - ---- - -## 13. Hinweise zur Pflege des Katalogs - -- Der Katalog ist eine **Startvorlage**; jede Organisation passt Auswahl, Beschreibung, Controls-Zuordnung und Bewertung an ihren Scope an. -- Controls-Angaben referenzieren die **Struktur** der VDA ISA (Kapitel 1–9). Die genauen Unter-Control-Nummern sind bei Nutzung gegen die aktuell gültige VDA-ISA-Version zu verifizieren. -- Standardmaßnahmen verweisen, wo möglich, auf vorhandene Vorlagen/Verfahren (R03, VA-09) und Baseline-Parameter (z. B. **BL-OPS-05** Backup). Weitere BL-* sind bei Umsetzung zu ergänzen. -- Jede aus einem Risiko abgeleitete Maßnahme sollte eine **Aufgabe** mit Verantwortlichem, Termin und Statusverfolgung erzeugen (VA-09). - -_Ende Paket C4 — Standard-Risikokatalog._ diff --git a/docs/wizard-uebergabe/02_Fachcontent_C1-C9/C5_Reifegradlogik.md b/docs/wizard-uebergabe/02_Fachcontent_C1-C9/C5_Reifegradlogik.md deleted file mode 100644 index 7781d2f..0000000 --- a/docs/wizard-uebergabe/02_Fachcontent_C1-C9/C5_Reifegradlogik.md +++ /dev/null @@ -1,199 +0,0 @@ -# Paket C5 — Reifegrad-Logik je Control (Onboarding-Wizard, Schritt 7 „Control-Assessment") - -**Zweck:** Regelbasierte, nachvollziehbare Herleitung eines **Reifegrad-Vorschlags (0–3)** je Control aus den im Wizard vorhandenen Belegen (verknüpfte Dokumente, Risiken, Assets) und deren Validierungsstatus. Der Vorschlag ist **nicht bindend** — die Bestätigung/Überschreibung durch den Bearbeiter ist Pflicht (Vier-Augen-Logik über die Rolle des ISB/Assessors). - -**Grundlage:** VDA-ISA-Reifegradmodell 0–3 -- **0 — unvollständig:** Anforderung nicht oder nur zufällig erfüllt, keine belastbaren Belege. -- **1 — durchgeführt/informell:** Ergebnis wird erreicht, aber ohne festgelegte, dokumentierte Vorgehensweise. -- **2 — gesteuert/dokumentiert:** Vorgehen ist definiert, dokumentiert (Richtlinie **und** Verfahren) und mit Nachweisen belegt. -- **3 — etabliert/integriert:** Vorgehen ist in die Organisation integriert und seine **Wirksamkeit wird über die Zeit nachgewiesen** (wiederkehrende Reviews/Protokolle/Tests). - ---- - -## 1. Belegtypen und Validierungsstatus (Datenmodell-Bezug) - -Der Wizard kennt je Control folgende verknüpfbare Belegklassen: - -| Belegklasse | Herkunft im Fachcontent | Beispiel | -|---|---|---| -| **Zuständige Richtlinie (P)** | Feld `policy` (L00, R01–R14) | Leitlinie, Richtlinie | -| **Zugehöriges Verfahren (V)** | Feld `verfahren` (VA-01 … VA-19) | Verfahrensanweisung / Prozess | -| **Operativer Nachweis (N)** | control-spezifisch (Protokoll, Report, Register, Ticket, Testnachweis) | Review-Protokoll, Auditbericht | -| **Asset-Verknüpfung (A)** | Asset-Inventar | zugeordnete Informationswerte/Systeme | -| **Risiko-Verknüpfung (R)** | Risikoregister | zugeordnete Risiken + Risk Owner | - -**Validierungsstatus je Beleg:** `fehlt` → `verknüpft (unvalidiert)` → `validiert` (durch Bearbeiter bestätigt, vorhanden, aktuell). Ein Beleg zählt für Reifegrad-Sprünge nach ≥2 nur, wenn er **`validiert`** ist. - -**Aktualitätsregel (für N):** Ein operativer Nachweis gilt als „aktuell", wenn er innerhalb des für das Control definierten Review-Zyklus liegt (Standard: ≤ 12 Monate; anlassbezogene Verfahren: letzter relevanter Vorfall/Change abgedeckt). Veraltete Nachweise zählen wie `verknüpft (unvalidiert)`. - ---- - -## 2. Allgemeine Regeltabelle „Belegkonstellation → Reifegrad-Vorschlag" (generisch, für alle Controls) - -| # | Belegkonstellation | Vorschlag | Begründung | -|---|---|---|---| -| R0 | Keine Belege verknüpft **oder** nur unvalidierte Fragmente ohne zuständige Richtlinie | **0** | Kein belastbarer Nachweis einer geregelten Vorgehensweise. | -| R1a | Zuständige Richtlinie (P) verknüpft, aber **nicht validiert** | **1** | Regelungsabsicht erkennbar, aber nicht bestätigt/gelebt (informell). | -| R1b | Richtlinie (P) validiert, **aber** ein für das Control **gefordertes Verfahren (V) fehlt** oder ist unvalidiert | **1** | Richtlinie allein steuert die operative Umsetzung noch nicht. | -| R1c | Nur operativer Nachweis (N) vorhanden, **ohne** validierte Richtlinie | **1** | Tätigkeit wird durchgeführt, aber nicht dokumentiert gesteuert. | -| R2 | Richtlinie (P) **validiert** **UND** alle geforderten Verfahren (V) **validiert** **UND** (falls einschlägig) Asset-/Risiko-Verknüpfung vorhanden | **2** | Vorgehen ist dokumentiert und gesteuert, Nachweise liegen strukturell vor. | -| R3 | Zusätzlich zu R2: mindestens **ein operativer Wirksamkeitsnachweis (N) validiert und aktuell** (Review-/Audit-/Test-/Schulungs-/Rezertifizierungsprotokoll) | **3** | Wirksamkeit wird über die Zeit belegt, Vorgehen ist integriert. | - -**Sonderfälle:** -- Controls **ohne** zugeordnetes Verfahren im Fachcontent (`verfahren` = leer): Die operative Steuerung ist in der Richtlinie selbst verankert. Für Grad 2 tritt an die Stelle von (V) eine **validierte, dokumentierte Umsetzungsregelung/Konfiguration (N-basisch)**; Grad 3 erfordert weiterhin einen **wiederkehrenden Wirksamkeitsnachweis**. -- Controls, die nur `SOLL` enthalten (z. B. 5.3.3): MUSS-Ebene ist definitionsgemäß erfüllt; Bewertung startet effektiv bei 1 und folgt ansonsten der Tabelle. -- **Nachweis widerspricht Richtlinie / offene Findings im Nachweis:** Vorschlag wird um einen Grad gedeckelt (max. 1) und ein offener Punkt erzeugt. - ---- - -## 3. Zielreifegrad-Regel - -| Assessment-Scope (Kundenkonfiguration) | Standard-Zielreifegrad | -|---|---| -| **AL 3** / normaler Schutzbedarf (MUSS + SOLL im Scope) | **3** | -| **AL 2** / reiner **MUSS-Scope** | **2** | -| Control mit HOCH/SEHR-HOCH-Anforderungen im Scope (hoher/sehr hoher Schutzbedarf) | **3** (Grad 3 wird zur Pflicht, keine Absenkung) | - -- Der Zielreifegrad wird **einmal je Assessment** aus dem Scope (AL2/AL3, Schutzbedarf-Flags `FLAG_INCLUDE_SHOULD`, `FLAG_HIGH_PROTECTION`, `FLAG_VERY_HIGH_PROTECTION`) abgeleitet und je Control angezeigt. -- In der Control-Tabelle (Abschnitt 5) ist der **Standard-Zielreifegrad = 3** ausgewiesen; er sinkt automatisch auf **2**, sobald der Kunde im Onboarding einen reinen MUSS-/AL2-Scope wählt. - ---- - -## 4. „Offener-Punkt"-Kriterium (Gap/Aufgabe entsteht, wenn …) - -Ein **offener Punkt (Gap → Aufgabe)** wird automatisch erzeugt, wenn **eine** der folgenden Bedingungen zutrifft: - -1. **Vorschlag < Zielreifegrad** (Reifegradlücke). → Aufgabe: „Belege/Umsetzung bis Zielgrad X anheben". -2. **Pflichtbeleg fehlt:** zuständige Richtlinie (P) oder ein gefordertes Verfahren (V) ist `fehlt`/unvalidiert. → Aufgabe: Dokument erstellen/verknüpfen/validieren. -3. **Operativer Nachweis fehlt oder ist veraltet**, obwohl Zielgrad 3. → Aufgabe: Review/Audit/Test durchführen und dokumentieren. -4. **Asset-/Risiko-Verknüpfung fehlt** bei Controls, die auf Inventar/Risikoregister aufsetzen (z. B. 1.3.x, 1.4.1, 5.2.8). → Aufgabe: Verknüpfung herstellen. -5. **Nachweis mit Findings/Widerspruch** (Deckelung nach Abschnitt 2). → Aufgabe: Abweichung beheben. -6. **Bearbeiter überschreibt Vorschlag nach unten** oder markiert „nicht bestätigt". → Aufgabe mit Begründungspflicht. - -Jeder offene Punkt trägt: Control-ID, fehlende Belegklasse, Ist-Grad, Zielgrad, empfohlene Maßnahme, Verantwortlichen (Default: ISB). - ---- - -## 5. Control-spezifische Tabelle — IS-Controls (alle 45) - -**Legende Richtlinien (`policy`):** L00 = Informationssicherheits-Leitlinie · R01 = ISMS-Organisation/Rollen · R02 = Umgang mit Informationswerten (Asset-Mgmt) · R03 = Risikomanagement & Wirksamkeitsprüfung · R04 = Incident-/Notfall-/Kontinuitätsmanagement · R05 = Personalsicherheit · R06 = Mobiles Arbeiten/Mobile Geräte · R07 = Physische Sicherheit/Zonenkonzept · R08 = Zugriffssteuerung (IAM) · R09 = Kryptografie/Kommunikationssicherheit · R10 = IT-Betriebssicherheit · R11 = Systementwicklung/Beschaffung · R12 = Cloud/externe IT-Dienste & KI · R13 = Lieferantenmanagement · R14 = Compliance/Recht & Datenschutz. - -**Legende Verfahren (`verfahren`, abgeleitete Bezeichnungen):** VA-01 Ereignisbehandlung · VA-02 Notfall-/Kontinuitätsmgmt · VA-03 Benutzer-/Berechtigungsverwaltung · VA-04 Change-Management · VA-05 Backup & Wiederherstellung · VA-06 Schwachstellen-/Patch-/Audit-Mgmt · VA-07 Kryptografie/sichere Übertragung · VA-08 Asset-Inventarisierung & Klassifizierung · VA-09 Risikomanagement · VA-10 Lieferantensteuerung · VA-11 Cloud-/KI-Freigabe · VA-12 Schulung & Sensibilisierung · VA-13 Protokollierung/Monitoring · VA-14 Personalprozess · VA-15 Interne Audits/Compliance-Prüfung · VA-17 Zutrittsmanagement · VA-16 Sichere Entwicklung/Beschaffung · VA-18 Rechts-/Datenschutzkataster · VA-19 Projektklassifizierung. - -Format: **Reifegrad-2-Bedingung** = Vorgehen dokumentiert & gesteuert · **Reifegrad-3-Bedingung** = zusätzlich validierter, aktueller Wirksamkeitsnachweis. - -| Control | Erwartete Belege (Richtlinie / Verfahren / operativer Nachweis) | Reifegrad-2-Bedingung | Reifegrad-3-Bedingung | Ziel | -|---|---|---|---|---| -| **1.1.1** IS-Leitlinie | L00 / — / Managementfreigabe + Veröffentlichungsnachweis (Intranet), Änderungskommunikation | L00 validiert, Freigabe u. Bereitstellung dokumentiert | Wiederkehrender Leitlinien-Review (≤12 M.) + Nachweis Änderungskommunikation | 3 | -| **1.2.1** ISMS/Geltungsbereich | R01 / — / Anwendbarkeitserklärung (SoA)/ISA-Katalog, Management-Review-Protokoll | R01 validiert, Scope + SoA dokumentiert | Regelmäßige Managementbewertung mit Wirksamkeitsaussage | 3 | -| **1.2.2** Rollen & Verantwortlichkeiten | R01 / — / Rollen-/Verantwortungsmatrix, ISB-Ernennung, Qualifikationsnachweis | R01 validiert, Rollen zugewiesen u. dokumentiert | Periodische Überprüfung der Rollenbesetzung/Qualifikation | 3 | -| **1.2.3** Projektklassifizierung | R01 / VA-19 / ausgefüllte Projektklassifizierung + Projekt-Risikobewertung | R01 + VA-19 validiert | Nachweis wiederholter Klassifizierung/Neubewertung über Projekte | 3 | -| **1.3.1** Identifizierung Informationswerte | R02 / VA-08 / aktuelles Asset-/Informationswert-Inventar (**A**) | R02 + VA-08 validiert, Inventar (A) verknüpft | Nachweis regelmäßiger Inventarpflege/-abgleich | 3 | -| **1.3.2** Klassifizierung Informationswerte | R02 / VA-08 / Klassifizierungsschema + klassifizierte Assets (**A**) | R02 + VA-08 validiert, Schema angewandt | Regelmäßige Überprüfung/Neubewertung der Klassifizierung | 3 | -| **1.3.3** Externe IT-Dienste | R02 / — / Freigabe-/Bestandsliste externer Dienste, Freigabeverfahren | R02 validiert + dokumentierte Freigabeliste u. -regelung | Regelmäßige Prüfung, dass nur freigegebene Dienste genutzt werden | 3 | -| **1.3.4** Software-Freigabe | R02 / — / Softwarefreigabeliste/Whitelist, Versions-/Patchstand | R02 validiert + dokumentierte Freigabeliste | Regelmäßige Überprüfung der Softwarefreigaben | 3 | -| **1.4.1** Risikomanagement | R03 / VA-09 / Risikoregister mit Risk Ownern (**R**), Maßnahmenplan | R03 + VA-09 validiert, Risikoregister (R) verknüpft | Regelmäßige/anlassbezogene Neubewertung + Maßnahmen-Tracking | 3 | -| **1.5.1** Compliance-/Richtlinienprüfung | R03 / VA-15 / Prüfplan + Prüfaufzeichnungen/Ergebnisse | R03 + VA-15 validiert, Prüfplan vorhanden | Durchgeführte Prüfungen dokumentiert + Korrekturmaßnahmen verfolgt | 3 | -| **1.5.2** Unabhängige Überprüfung | R03 / VA-15 / Bericht unabhängiger/kompetenter Stelle, Managementbericht | R03 + VA-15 validiert | Durchgeführte unabhängige Prüfung + Maßnahmenverfolgung nachgewiesen | 3 | -| **1.6.1** Meldung Sicherheitsereignisse | R04 / VA-01 / dokumentierte Meldewege/-kanäle, Meldeformular/Ticketsystem | R04 + VA-01 validiert, Meldewege bekannt | Nachweis genutzter Meldewege (Tickets) + ggf. Test der Meldung | 3 | -| **1.6.2** Behandlung Sicherheitsereignisse | R04 / VA-01 / Incident-Log/Tickethistorie mit Lessons Learned | R04 + VA-01 validiert | Bearbeitete Vorfälle + Lessons-Learned-Rückfluss nachgewiesen | 3 | -| **1.6.3** Krisen-/Notfallmanagement | R04 / VA-02 / Krisen-/Notfallplan, Krisenstab, Übungs-/Testprotokoll | R04 + VA-02 validiert, Plan u. Rollen dokumentiert | Durchgeführte Krisenübung/Test + Aktualisierung der Planung | 3 | -| **2.1.1** Personalprüfung (Eignung/Identität) | R05 / VA-14 / Einstellungsprozess, dokumentierte Identitätsprüfung | R05 + VA-14 validiert | Nachweis gelebter Prüfung über Einstellungen (Stichprobe) | 3 | -| **2.1.2** Verpflichtungen (NDA/Richtlinien) | R05 / VA-14 / unterzeichnete Vertraulichkeits-/Richtlinienverpflichtungen | R05 + VA-14 validiert, Verpflichtungen vorhanden | Nachweis flächendeckender, aktueller Verpflichtungen | 3 | -| **2.1.3** Schulung & Sensibilisierung | R05 / VA-12 / Schulungskonzept + Teilnahmenachweise | R05 + VA-12 validiert, Konzept genehmigt | Regelmäßig durchgeführte Schulungen + Teilnahmedokumentation | 3 | -| **2.1.4** Mobiles Arbeiten | R06 / — / kommunizierte Regelung, Sensibilisierungsnachweis | R06 validiert + dokumentierte Anforderungen | Nachweis Sensibilisierung + Überprüfung der Umsetzung | 3 | -| **3.1.1** Sicherheitszonenkonzept | R07 / VA-17 / Zonenkonzept + Umsetzungsnachweis, Zutritts-/Besucherverfahren | R07 + VA-17 validiert, Zonenkonzept umgesetzt | Regelmäßige Überprüfung von Zonen/Zutritt/Besuchermgmt | 3 | -| **3.1.4** Mobile Geräte/Datenträger | R06 / — / Regelung + Geräteregistrierung/MDM-Nachweis | R06 validiert + dokumentierte Anforderungen/Registrierung | Nachweis Umsetzung (MDM/Verschlüsselung) + Überprüfung | 3 | -| **4.1.1** Identifikationsmittel (Lebenszyklus) | R08 / VA-03 / Ausgabe-/Rückgabe-/Sperrprozess, Nachweis kontrollierte Erstellung | R08 + VA-03 validiert | Nachweis gelebter Sperr-/Rückgabeprozesse (z. B. Verlustfall) | 3 | -| **4.1.2** Benutzerauthentifizierung | R08 / — / Authentifizierungskonzept, techn. Umsetzung (Passwortpolicy/MFA) | R08 validiert + dokumentiertes Auth-Konzept | Nachweis wirksamer Umsetzung (MFA-/Policy-Report) + Review | 3 | -| **4.1.3** Verwaltung Benutzerkonten | R08 / VA-03 / Kontenverwaltungsprozess, Konten-Rezertifizierung | R08 + VA-03 validiert | Regelmäßige Konten-Überprüfung/Rezertifizierung nachgewiesen | 3 | -| **4.2.1** Verwaltung Zugriffsrechte | R08 / VA-03 / Berechtigungskonzept, Rechte-Review/Rezertifizierung | R08 + VA-03 validiert | Regelmäßige Rechte-Rezertifizierung nachgewiesen | 3 | -| **5.1.1** Kryptografie | R09 / VA-07 / Kryptokonzept, Nachweis eingesetzter Verfahren | R09 + VA-07 validiert, Konzept umgesetzt | Regelmäßige Überprüfung der Krypto-Verfahren/Stand der Technik | 3 | -| **5.1.2** Netzdienste/sichere Übertragung | R09 / VA-07 / Netzdienst-Inventar, Verschlüsselungsnachweis | R09 + VA-07 validiert, Dienste dokumentiert | Nachweis wirksamer (Transport-)Verschlüsselung + Überprüfung | 3 | -| **5.2.1** Change-Management | R10 / VA-04 / Change-Prozess, Change-Tickets/CAB-Protokolle | R10 + VA-04 validiert | Nachweis gelebter Changes inkl. IS-Bewertung + Verifikation | 3 | -| **5.2.2** Trennung Entw./Test/Prod | R10 / — / Risikobewertung + Segmentierungsnachweis | R10 validiert + dokumentierte Segmentierung | Überprüfung der Trennung/Segmentierung im Betrieb | 3 | -| **5.2.3** Schutz vor Schadsoftware | R10 / — / AV-Konzept, AV-Konsole/Status-Report | R10 validiert + dokumentierte Schutzmaßnahmen | Aktueller AV-Statusreport + regelmäßige Überprüfung | 3 | -| **5.2.4** Protokollierung/Logging | R10 / VA-13 / Logging-Konzept, Log-Review-Nachweis | R10 + VA-13 validiert | Nachweis regelmäßiger Log-Auswertung/Eskalation | 3 | -| **5.2.5** Umgang mit Schwachstellen | R10 / VA-04, VA-06 / Schwachstellen-/Patchprozess, Scan-/Patchreports | R10 + VA-04 + VA-06 validiert | Aktuelle Scan-/Patchreports + Risikobehandlung nachgewiesen | 3 | -| **5.2.6** Prüfung von IT-Systemen (Audit) | R10 / VA-06 / Prüfanforderungen, Audit-/Pentestberichte | R10 + VA-06 validiert | Durchgeführte System-/Dienstprüfungen + Maßnahmen nachgewiesen | 3 | -| **5.2.7** Netzwerkmanagement | R10 / — / Netzkonzept/Segmentierung, Umsetzungsnachweis | R10 validiert + dokumentiertes Netzkonzept | Überprüfung von Netzmgmt/Segmentierung im Betrieb | 3 | -| **5.2.8** Kontinuität IT-Dienste (BCM) | R04 / VA-02 / kritische Dienste identifiziert (**A**), Kontinuitätsplan, Testprotokoll | R04 + VA-02 validiert, kritische Dienste (A) erfasst | Durchgeführter Kontinuitäts-/Wiederherstellungstest nachgewiesen | 3 | -| **5.2.9** Backup & Wiederherstellung | R10 / VA-05 / Backup-/Restore-Konzept, Restore-Testprotokoll | R10 + VA-05 validiert, Konzepte vorhanden | Durchgeführter Restore-Test (regelmäßig) nachgewiesen | 3 | -| **5.3.1** Sichere Systementwicklung/Beschaffung | R11 / VA-16 / IS-Anforderungen, Abnahme-/Testnachweise | R11 + VA-16 validiert | Nachweis durchgeführter Abnahmetests/Security-Tests | 3 | -| **5.3.2** Sicherheit Netzdienste | R11 / VA-16 / SLA/Absicherungsverfahren, Überwachungsnachweis | R11 + VA-16 validiert | Nachweis Überwachung/Qualitätssicherung der Netzdienste | 3 | -| **5.3.3** Beendigung IT-Dienste (nur SOLL) | R11 / — / vertraglich geregelter Beendigungsprozess, Nachweis Rückgabe/Löschung | R11 validiert + dokumentierter Beendigungsprozess | Nachweis gelebter Beendigung (Datenrückgabe/-löschung) | 3 | -| **5.3.4** Mandantentrennung (Cloud) | R12 / VA-11 / Trennungskonzept des Anbieters, Nachweis | R12 + VA-11 validiert | Regelmäßige Überprüfung/Anpassung des Trennungskonzepts | 3 | -| **5.3.4-KI** KI-/GenAI-Nutzung | R12 / VA-11 / KI-Nutzungsregelung + Freigabeliste, vertragl. Trainings-Ausschluss | R12 + VA-11 validiert, Freigabeliste + Datenklassen | Human-in-the-Loop-/Dokumentationsnachweis + Überprüfung | 3 | -| **6.1.1** Lieferantenmanagement | R13 / VA-10 / Lieferantenbewertung, Verträge + Nachweise/Zertifikate | R13 + VA-10 validiert, Bewertung + Verträge | Regelmäßige Überprüfung Nachweise/Vertragserfüllung (Monitoring) | 3 | -| **6.1.2** Vertraulichkeitsvereinbarungen | R13 / VA-10 / NDA-Vorlagen + abgeschlossene NDAs, Gültigkeitsüberwachung | R13 + VA-10 validiert, Vorlagen + NDAs | Regelmäßige Überprüfung/Verlängerung + gelebte NDA-Nutzung | 3 | -| **6.1.3** Geteilte Verantwortlichkeiten (Shared Resp.) | R13 / VA-10 / Verantwortungsmatrix, Nachweis Erfüllung durch Dienstleister | R13 + VA-10 validiert, Matrix dokumentiert | Nachweis, dass Dienstleister Verantwortung erfüllen (Prüfung) | 3 | -| **7.1.1** Rechtliche/vertragliche Vorgaben | R14 / VA-18 / Rechts-/Compliance-Kataster, Aktualisierungsnachweis | R14 + VA-18 validiert, Kataster vorhanden | Regelmäßige Aktualisierung des Katasters + Umsetzungsnachweis | 3 | -| **7.1.2** Datenschutz-relevante IS-Anforderungen | R14 / VA-18 / dokumentierte DS-Anforderungen, Umsetzungsnachweis im ISMS | R14 + VA-18 validiert, Anforderungen bestimmt | Nachweis Umsetzung/Überprüfung im ISMS-Kontext | 3 (MUSS-only¹) | - -¹ 7.1.2 enthält nur MUSS-Anforderungen: In reinem AL2-/MUSS-Scope Zielreifegrad **2**; ansonsten 3. - ---- - -## 6. Proto (8.x) und Datenschutz (9.x) — kompakte Gruppenlogik - -Für Prototypenschutz und Datenschutz sind im Fachcontent **keine Verfahren (VA)** hinterlegt; die Anforderungen sind überwiegend **MUSS** und stark auftraggeber-/rechtsgetrieben. Die Reifegradlogik wird daher vereinfacht: Für Grad 2 tritt an die Stelle des Verfahrens die **dokumentierte, umgesetzte Regelung** (Konzept/Prozess/Vereinbarung); Grad 3 erfordert einen **wiederkehrenden Wirksamkeits-/Umsetzungsnachweis**. - -**Generische Regel Proto/DS:** -- **0** — keine Regelung/kein Konzept belegt. -- **1** — Konzept/Vereinbarung vorhanden, aber unvalidiert oder nur informell umgesetzt. -- **2** — Konzept/Prozess/Vereinbarung **validiert und umgesetzt** (physische Maßnahme, Vertrag, dokumentierter Prozess). -- **3** — zusätzlich **validierter, aktueller Nachweis der gelebten Umsetzung** (Auditbericht, Alarmverfolgung, Schulungsnachweis, Besucherprotokoll, DSFA-Register, VVT-Pflege, Auftragskontrollen). - -**Zielreifegrad Proto/DS:** überwiegend **2** (reine MUSS-Anforderungen); für Gruppen mit SOLL/HOCH-Anteil bzw. hohem Schutzbedarf **3**. - -### 6.1 Prototypenschutz (8.x) - -| Gruppe | Controls | Erwartete Belege (Richtlinie/Regelung / operativer Nachweis) | Grad-2-Bedingung | Grad-3-Bedingung | Ziel | -|---|---|---|---|---|---| -| **8.1 Physische Sicherheit** | 8.1.1–8.1.8 | Sicherheitskonzept Prototypenschutz (Außenhaut, Zutritt, Einblickschutz, EMA/Alarmverfolgung, Besuchermgmt, Mandantentrennung) / Umsetzungs- u. Alarmverfolgungsnachweise, Besucherprotokolle | Sicherheitskonzept validiert + Schutzmaßnahmen umgesetzt | Wiederkehrende Überprüfung der phys. Maßnahmen + Alarmverfolgung/Besuchermgmt nachgewiesen | 2–3² | -| **8.2 Organisation/Vertrag/Personal** | 8.2.1–8.2.7 | NDAs (Firma + Personen), Zutrittsvergabeprozess, Schulungskonzept Prototypen, Bild-/Geräteregelungen / unterzeichnete NDAs, Schulungsnachweise, Zutrittslogs | Vereinbarungen/Prozesse validiert u. dokumentiert | Nachweis gelebter Umsetzung (Schulungen, Zutritts-Reviews, Nachweise Unterauftragnehmer) | 2 | -| **8.3 Transport/Lagerung** | 8.3.1–8.3.2 | Prozess Einholung Auftraggebervorgaben, freigegebene Logistiker / Nachweis Einhaltung/Meldeprozess | Prozesse validiert u. implementiert | Nachweis gelebter Transport-/Lagerkontrollen u. Ereignismeldung | 2 | -| **8.4 Tarnung/Erprobung** | 8.4.1–8.4.3 | Tarnungs-/Erprobungsregeln, Meldeprozess Beschädigungen / Nachweis Bekanntgabe u. Einhaltung | Regeln/Prozesse validiert u. bekannt | Nachweis gelebter Einhaltung + Meldungen bei Vorfällen | 2 | -| **8.5 Ausstellungen/Foto-Film** | 8.5.1–8.5.2 | Prozess Auftraggebervorgaben, freigegebene Sicherheitskonzepte / Freigabenachweise, Verhaltensregeln | Prozesse + freigegebene Konzepte validiert | Nachweis gelebter Umsetzung je Veranstaltung/Shooting | 2 | - -² 8.1.4/8.1.5/8.1.8 mit HOCH-Anteil (schutzbedürftige Fahrzeuge): Zielreifegrad 3. - -### 6.2 Datenschutz (9.x) - -| Gruppe | Controls | Erwartete Belege (Richtlinie/Regelung / operativer Nachweis) | Grad-2-Bedingung | Grad-3-Bedingung | Ziel | -|---|---|---|---|---|---| -| **9.1 Richtlinie DS** | 9.1.1 | DS-Richtlinie (freigegeben) / Aktualisierungs-/Freigabenachweis | DS-Richtlinie validiert u. freigegeben | Regelmäßige Aktualisierung/Review nachgewiesen | 2 | -| **9.2 Verantwortlichkeiten DS** | 9.2.1 | DSB-Bestellung/DS-Funktion, Kontaktveröffentlichung, Ressourcen / Kontroll- u. Berichtsdokumentation | Bestellung/Funktion + Eingliederung validiert | Nachweis ausgeübter Kontrollpflichten + Managementbericht | 2 | -| **9.3 Verarbeitungsverzeichnis** | 9.3.1 | VVT (Art. 30), Prozessbeschreibung/Zuständigkeiten / VVT-Pflegenachweis | VVT + Prozess validiert | Regelmäßige VVT-Pflege/Aktualität nachgewiesen | 2 | -| **9.4 DSFA** | 9.4.1 | Kriterien/Liste DSFA-pflichtiger Verarbeitungen, DSFA-Verfahren / durchgeführte DSFA | DSFA-Verfahren + Zuständigkeiten validiert | Durchgeführte DSFA + Maßnahmen nachgewiesen | 2 | -| **9.5 Datenübermittlung/AV** | 9.5.1–9.5.3 | AV-Verträge (Art. 28), Transferinstrumente, Drittland-Garantien / Nachweis Verträge/Prüfungen | Prozesse + Verträge validiert | Nachweis Überprüfung Einhaltung + Drittland-Erfassung (TIA) | 2 | -| **9.6 Betroffenenrechte/Vorfälle** | 9.6.1–9.6.2 | Verfahren Betroffenenanfragen, DS-Vorfall-/Notfallplan, Schulung / Bearbeitungs-/Meldenachweise | Verfahren validiert u. dokumentiert | Nachweis fristgerechter Bearbeitung + Meldeprozesse gelebt | 2 | -| **9.7 Personal DS** | 9.7.1–9.7.2 | Vertraulichkeitsverpflichtungen, DS-Schulungskonzept / Verpflichtungs- u. Schulungsnachweise | Verpflichtung + Schulungskonzept validiert | Regelmäßige DS-Schulungen + Verpflichtungen nachgewiesen | 2 | -| **9.8 Weisungen AV** | 9.8.1 | Verfahren Weisungsumgang, Datentrennung nach Auftrag / Dokumentation Weisungen | Verfahren + Maßnahmen validiert | Nachweis dokumentierter/umgesetzter Weisungen + Trennung | 2 | - ---- - -## 7. Umsetzungshinweis Wizard (Pseudologik) - -``` -ziel = ableiteZiel(scope) // AL3 -> 3, AL2/MUSS -> 2, HOCH/V-HOCH -> 3 -p = statusRichtlinie(control.policy) -v = min(statusAllerVerfahren(control.verfahren)) // leer -> „n/a" (durch N-basisch ersetzt) -n = statusOperativerNachweis(control) // inkl. Aktualitätsprüfung -a = statusAssetVerknuepfung(control) // nur falls einschlägig -r = statusRisikoVerknuepfung(control) // nur falls einschlägig - -if p != validiert: vorschlag = (p == verknuepft) ? 1 : 0 -elif verfahrenGefordert && v != validiert: vorschlag = 1 -elif einschlaegigA && a != verknuepft: vorschlag = 1 -else: vorschlag = 2 -if vorschlag == 2 && n == validiert_aktuell: vorschlag = 3 -if nachweisMitFindings: vorschlag = min(vorschlag, 1) - -if vorschlag < ziel || pflichtbelegFehlt || (ziel==3 && n!=validiert_aktuell): - erzeugeOffenenPunkt(control, ist=vorschlag, ziel, fehlendeBelege) - -// Pflicht: Bearbeiter bestätigt oder überschreibt vorschlag (mit Begründung) -``` - -**Kernprinzip:** Der Wizard schlägt vor, der Bearbeiter entscheidet. Jeder Vorschlag ist über die verknüpften, validierten Belege vollständig nachvollziehbar; jede Lücke zwischen Vorschlag und Zielreifegrad wird automatisch in einen offenen Punkt (Aufgabe) überführt. diff --git a/docs/wizard-uebergabe/02_Fachcontent_C1-C9/C6_Umsetzungshinweise.md b/docs/wizard-uebergabe/02_Fachcontent_C1-C9/C6_Umsetzungshinweise.md deleted file mode 100644 index 4100ccb..0000000 --- a/docs/wizard-uebergabe/02_Fachcontent_C1-C9/C6_Umsetzungshinweise.md +++ /dev/null @@ -1,3778 +0,0 @@ -# C6 — Umsetzungshinweise je Teilanforderung - -> **Schaltet frei:** B5 (Umsetzungshinweise-Panel) + A7 (Control-Assessment). **Grundlage:** `mapping.json` (Anforderungs-IDs) + Proto/DS-Dekomposition. -> Je Anforderung: organisatorische & technische Umsetzungsoption, typische Nachweise, Vorlagen-Verweis, Ressourcenindikation, AL-Filter. Ressourcen-Hinweise mit Beschaffungs-/Umsetzungsbedarf führen im Wizard zu einer Aufgabe. - - ---- - -# Kapitel 1 — Governance & Organisation - -# C6 — Umsetzungshinweise Kapitel 1 (Informationssicherheitspolitik & Organisation) - -## Control 1.1.1 — Inwieweit werden Informationssicherheitsrichtlinien erstellt und kommuniziert? - -### 1.1.1-M1 — [MUSS] -**Anforderung:** Anforderungen der Informationssicherheit sind bestimmt, dokumentiert und an den Organisationszielen ausgerichtet. -- **Organisatorisch:** Sicherheitsanforderungen aus Geschäftszielen, Kunden-/Vertrags- und Gesetzeslage ableiten und in der Leitlinie verankern; Ableitung dokumentieren und von der Leitung bestätigen lassen. -- **Technisch:** Leitliniendokument versioniert im Dokumentenmanagement/DMS ablegen; Freigabe- und Änderungshistorie technisch nachvollziehbar führen. -- **Typische Nachweise:** genehmigte Leitlinie mit Zielbezug; Übersicht abgeleiteter Anforderungen; Freigabevermerk der Leitung. -- **Vorlage:** L00 -- **Ressourcen:** ISB/CISO; ca. 1–2 PT für Erstellung/Abstimmung; kein Toolbudget (vorhandenes DMS). -- **AL-Filter:** AL2 + AL3 - -### 1.1.1-M2 — [MUSS] -**Anforderung:** Eine durch die Leitung genehmigte Leitlinie existiert. -- **Organisatorisch:** Formalen Genehmigungsakt durch die oberste Leitung durchführen (Managementbeschluss, Unterschrift); Genehmigung datieren. -- **Technisch:** Signierte/freigegebene Version zentral und unveränderbar (read-only) bereitstellen. -- **Typische Nachweise:** unterschriebene/freigegebene Leitlinie; Protokoll- oder Beschlussvermerk der Leitung. -- **Vorlage:** L00 -- **Ressourcen:** Leitung + ISB; gering (Termin/Freigabe). -- **AL-Filter:** AL2 + AL3 - -### 1.1.1-M3 — [MUSS] -**Anforderung:** Die Leitlinie benennt Ziele und Bedeutung der Informationssicherheit. -- **Organisatorisch:** Abschnitt „Ziele und Stellenwert der Informationssicherheit" in die Leitlinie aufnehmen; Bezug zu Schutzzielen (C/I/A) herstellen. -- **Technisch:** Keine spezifische technische Maßnahme; Inhalt im Leitliniendokument. -- **Typische Nachweise:** Leitlinie mit Ziel- und Bedeutungskapitel. -- **Vorlage:** L00 -- **Ressourcen:** ISB; gering. -- **AL-Filter:** AL2 + AL3 - -### 1.1.1-M4 — [MUSS] -**Anforderung:** Leitlinien werden den Beschäftigten in geeigneter Form bereitgestellt (z. B. Intranet). -- **Organisatorisch:** Verbindlichen Veröffentlichungsweg festlegen; Bereitstellung in Onboarding-Prozess aufnehmen. -- **Technisch:** Veröffentlichung im Intranet/Mitarbeiterportal mit Lesebestätigung; Zugriff für alle Beschäftigten sicherstellen. -- **Typische Nachweise:** Intranet-Link/Screenshot; Verteil- oder Lesebestätigungen. -- **Vorlage:** L00 -- **Ressourcen:** IT/Kommunikation; gering. -- **AL-Filter:** AL2 + AL3 - -### 1.1.1-M5 — [MUSS] -**Anforderung:** Beschäftigte und externe Geschäftspartner werden über relevante Änderungen informiert. -- **Organisatorisch:** Kommunikationsprozess für Richtlinienänderungen definieren (Zielgruppen, Kanäle, Auslöser); externe Partner über definierte Ansprechstellen einbinden. -- **Technisch:** Automatisierte Change-Benachrichtigung (Intranet-News, Verteiler) beim Publizieren neuer Versionen. -- **Typische Nachweise:** Änderungsmitteilungen; Verteilernachweise; Kommunikationsprotokoll. -- **Vorlage:** L00 -- **Ressourcen:** ISB/Kommunikation; gering, laufend. -- **AL-Filter:** AL2 + AL3 - -### 1.1.1-S1 — [SOLL] -**Anforderung:** Anforderungen basieren auf der Organisationsstrategie; Gesetze und Verträge werden berücksichtigt. -- **Organisatorisch:** Strategie-, Rechts- und Vertragsanforderungen systematisch erheben (Legal/Compliance einbeziehen) und Bezug in der Leitlinie herstellen. -- **Technisch:** Verweis-/Anforderungsregister (Legal-Register) pflegen und mit der Leitlinie verknüpfen. -- **Typische Nachweise:** Anforderungs-/Rechtsregister; Leitlinie mit Strategie- und Rechtsbezug. -- **Vorlage:** L00 -- **Ressourcen:** ISB + Legal; ca. 1 PT. -- **AL-Filter:** AL2 + AL3 - -### 1.1.1-S2 — [SOLL] -**Anforderung:** Die Leitlinie benennt Konsequenzen bei Nichteinhaltung. -- **Organisatorisch:** Sanktions-/Konsequenzenklausel abstimmen (HR, Betriebsrat) und in die Leitlinie aufnehmen. -- **Technisch:** Keine; Inhalt im Dokument. -- **Typische Nachweise:** Leitlinienabschnitt zu Konsequenzen; Betriebsrats-/HR-Abstimmung. -- **Vorlage:** L00 -- **Ressourcen:** ISB + HR; gering. -- **AL-Filter:** AL2 + AL3 - -### 1.1.1-S3 — [SOLL] -**Anforderung:** Weitere relevante Sicherheitsrichtlinien sind etabliert. -- **Organisatorisch:** Richtlinienlandkarte aufbauen; themenspezifische Richtlinien (Zugriff, Kryptografie, mobiles Arbeiten etc.) aus dem Vorlagensatz ableiten und freigeben. -- **Technisch:** Richtliniensammlung strukturiert im DMS mit Gültigkeits-/Reviewständen. -- **Typische Nachweise:** Richtlinienübersicht; freigegebene Einzelrichtlinien. -- **Vorlage:** L00; R01–R14 -- **Ressourcen:** ISB; mehrere PT je nach Umfang. -- **AL-Filter:** AL2 + AL3 - -### 1.1.1-S4 — [SOLL] -**Anforderung:** Regelmäßige Überprüfung und ggf. Überarbeitung der Richtlinien ist etabliert. -- **Organisatorisch:** Review-Zyklus (z. B. jährlich) und anlassbezogene Prüfung festlegen; Verantwortliche und Termine definieren. -- **Technisch:** Wiedervorlage-/Review-Erinnerungen im DMS oder GRC-Tool setzen. -- **Typische Nachweise:** Review-Plan; Änderungshistorie mit Prüfdatum. -- **Vorlage:** L00; VA-15 -- **Ressourcen:** ISB; gering, laufend. -- **AL-Filter:** AL2 + AL3 - -## Control 1.2.1 — Inwieweit wird Informationssicherheit in der Organisation gemanagt (ISMS)? - -### 1.2.1-M1 — [MUSS] -**Anforderung:** Der Geltungsbereich des ISMS ist definiert. -- **Organisatorisch:** Scope nach Standorten, Organisationseinheiten, Prozessen und Dienstleistungen abgrenzen und begründen; Schnittstellen/Ausschlüsse dokumentieren. -- **Technisch:** Scope-Dokument im ISMS/GRC-Tool hinterlegen und mit Asset-/Standortlisten verknüpfen. -- **Typische Nachweise:** Scope-Dokument; Standort-/Bereichsübersicht. -- **Vorlage:** R01 -- **Ressourcen:** ISB; ca. 1–2 PT. -- **AL-Filter:** AL2 + AL3 - -### 1.2.1-M2 — [MUSS] -**Anforderung:** Die Anforderungen der Organisation an das ISMS sind bestimmt. -- **Organisatorisch:** Interessierte Parteien und deren Anforderungen (Kunden, Regulatorik, intern) erheben und dokumentieren. -- **Technisch:** Anforderungsregister im GRC-Tool führen. -- **Typische Nachweise:** Kontext-/Stakeholder-Analyse; Anforderungsliste. -- **Vorlage:** R01 -- **Ressourcen:** ISB; ca. 1 PT. -- **AL-Filter:** AL2 + AL3 - -### 1.2.1-M3 — [MUSS] -**Anforderung:** Die Organisationsleitung hat das ISMS beauftragt und genehmigt. -- **Organisatorisch:** Formalen Auftrag/Mandat der Leitung für das ISMS und den ISB erteilen und dokumentieren. -- **Technisch:** Keine; Beschlussdokument. -- **Typische Nachweise:** ISMS-Auftrag/Mandat; Leitungsbeschluss. -- **Vorlage:** R01 -- **Ressourcen:** Leitung + ISB; gering. -- **AL-Filter:** AL2 + AL3 - -### 1.2.1-M4 — [MUSS] -**Anforderung:** Das ISMS stellt der Leitung Mittel zur Überwachung und Steuerung bereit (z. B. Managementbewertung). -- **Organisatorisch:** Managementbewertung (Management-Review) mit Turnus, Input (Kennzahlen, Audits, Vorfälle, Risiken) und Output (Maßnahmen) etablieren. -- **Technisch:** ISMS-Kennzahlen/Dashboard im GRC-Tool bereitstellen. -- **Typische Nachweise:** Management-Review-Protokoll; ISMS-Kennzahlenbericht. -- **Vorlage:** R01; VA-15 -- **Ressourcen:** ISB + Leitung; gering, periodisch. -- **AL-Filter:** AL2 + AL3 - -### 1.2.1-M5 — [MUSS] -**Anforderung:** Die anwendbaren Controls sind bestimmt (z. B. Anwendbarkeitserklärung/ausgefüllter ISA-Katalog). -- **Organisatorisch:** Anwendbarkeit je Control festlegen und begründen (SoA/ISA); Verantwortliche zuordnen. -- **Technisch:** SoA/ISA-Katalog im GRC-Tool pflegen und mit Maßnahmen verknüpfen. -- **Typische Nachweise:** Statement of Applicability / ausgefüllter ISA-Katalog. -- **Vorlage:** R01 -- **Ressourcen:** ISB; ca. 2–3 PT. -- **AL-Filter:** AL2 + AL3 - -### 1.2.1-M6 — [MUSS] -**Anforderung:** Die Wirksamkeit des ISMS wird regelmäßig durch die Leitung überprüft. -- **Organisatorisch:** Wirksamkeitsprüfung als festen Bestandteil des Management-Reviews mit Bewertungskriterien verankern. -- **Technisch:** Trend-/Kennzahlenauswertung (Vorfälle, Audits, Maßnahmenumsetzung) automatisiert bereitstellen. -- **Typische Nachweise:** Management-Review mit Wirksamkeitsbewertung; abgeleitete Verbesserungsmaßnahmen. -- **Vorlage:** R01; VA-15 -- **Ressourcen:** ISB + Leitung; gering, periodisch. -- **AL-Filter:** AL2 + AL3 - -## Control 1.2.2 — Inwieweit werden Verantwortlichkeiten für Informationssicherheit organisiert? - -### 1.2.2-M1 — [MUSS] -**Anforderung:** Verantwortlichkeiten für Informationssicherheit sind definiert, dokumentiert und zugewiesen. -- **Organisatorisch:** Rollen (ISB, Risk Owner, Asset Owner) und Verantwortlichkeiten festlegen und namentlich zuweisen; RACI erstellen. -- **Technisch:** Rollen-/Verantwortlichkeitsmatrix im DMS/GRC-Tool pflegen. -- **Typische Nachweise:** Rollenbeschreibungen; RACI-Matrix; Bestellungsschreiben ISB. -- **Vorlage:** R01 -- **Ressourcen:** ISB + HR; ca. 1–2 PT. -- **AL-Filter:** AL2 + AL3 - -### 1.2.2-M2 — [MUSS] -**Anforderung:** Die verantwortlichen Beschäftigten sind definiert, qualifiziert und befähigt. -- **Organisatorisch:** Qualifikationsanforderungen je Rolle definieren; Schulungen/Zertifizierungen sicherstellen. -- **Technisch:** Qualifikations-/Schulungsnachweise im Schulungssystem dokumentieren. -- **Typische Nachweise:** Qualifikations-/Zertifikatsnachweise; Schulungsdokumentation. -- **Vorlage:** R01; VA-12 -- **Ressourcen:** HR + ISB; Schulungsbudget je Rolle. -- **AL-Filter:** AL2 + AL3 - -### 1.2.2-M3 — [MUSS] -**Anforderung:** Die erforderlichen Ressourcen stehen zur Verfügung. -- **Organisatorisch:** Personal- und Budgetbedarf des ISMS ermitteln und durch die Leitung bereitstellen lassen; im Management-Review nachhalten. -- **Technisch:** Keine; Ressourcenplanung. -- **Typische Nachweise:** Budget-/Ressourcenfreigabe; Stellen-/Kapazitätsplan. -- **Vorlage:** R01 -- **Ressourcen:** Leitung; Budget-/Personalzuweisung erforderlich. -- **AL-Filter:** AL2 + AL3 - -### 1.2.2-M4 — [MUSS] -**Anforderung:** Ansprechpartner sind innerhalb der Organisation und bei relevanten Geschäftspartnern bekannt. -- **Organisatorisch:** Ansprechpartner der Informationssicherheit intern und gegenüber Partnern kommunizieren; Aktualisierung sicherstellen. -- **Technisch:** Kontaktverzeichnis im Intranet/Portal bereitstellen. -- **Typische Nachweise:** Intranet-Kontaktseite; Kommunikation an Partner. -- **Vorlage:** R01 -- **Ressourcen:** ISB; gering. -- **AL-Filter:** AL2 + AL3 - -### 1.2.2-S1 — [SOLL] -**Anforderung:** Eine angemessene Informationssicherheitsstruktur ist definiert und dokumentiert. -- **Organisatorisch:** Aufbau-/Ablauforganisation der Informationssicherheit (Gremien, Berichtswege, Eskalation) beschreiben. -- **Technisch:** Organigramm/Strukturdokument im DMS. -- **Typische Nachweise:** IS-Organigramm; Gremien-/Berichtsstruktur. -- **Vorlage:** R01 -- **Ressourcen:** ISB; ca. 1 PT. -- **AL-Filter:** AL2 + AL3 - -### 1.2.2-S2 — [SOLL] -**Anforderung:** Sicherheitsrelevante Rollen außerhalb des ISMS werden berücksichtigt. -- **Organisatorisch:** Schnittstellenrollen (Datenschutz, Werkschutz, IT-Betrieb, Notfallmanagement) identifizieren und in die IS-Struktur einbinden. -- **Technisch:** Erweiterte Rollenmatrix mit Schnittstellen dokumentieren. -- **Typische Nachweise:** Rollenübersicht inkl. Schnittstellenrollen. -- **Vorlage:** R01 -- **Ressourcen:** ISB; gering. -- **AL-Filter:** AL2 + AL3 - -### 1.2.2-H1 — [HOCH] -**Anforderung:** Angemessene organisatorische Trennung von Verantwortlichkeiten (Funktionstrennung) zur Vermeidung von Interessenkonflikten. (C, I, A) -- **Organisatorisch:** Funktionstrennung (SoD) definieren; kritische Kombinationen identifizieren und trennen; kompensierende Kontrollen bei Kleinstteams festlegen. -- **Technisch:** SoD-Regeln in Berechtigungskonzepten und IAM-Rollen abbilden und prüfen. -- **Typische Nachweise:** SoD-Matrix; Berechtigungskonzept mit Trennungsregeln; Ausnahmedoku. -- **Vorlage:** R01; VA-03 -- **Ressourcen:** ISB + IT; ca. 1–2 PT; ggf. IAM-Konfiguration. -- **AL-Filter:** AL3 (hoher Schutzbedarf) - -## Control 1.2.3 — Inwieweit werden Informationssicherheitsanforderungen in Projekten berücksichtigt? - -### 1.2.3-M1 — [MUSS] -**Anforderung:** Projekte werden unter Berücksichtigung der Informationssicherheitsanforderungen klassifiziert. -- **Organisatorisch:** IS-Klassifizierung als verpflichtenden Schritt im Projekt-Gate/-Freigabeprozess verankern. -- **Technisch:** Klassifizierungsfeld/Checkliste im Projekt-/PM-Tool hinterlegen. -- **Typische Nachweise:** klassifizierte Projektliste; Projektfreigaben mit IS-Einstufung. -- **Vorlage:** R01; VA-19 -- **Ressourcen:** PMO + ISB; gering, laufend. -- **AL-Filter:** AL2 + AL3 - -### 1.2.3-S1 — [SOLL] -**Anforderung:** Verfahren und Kriterien für die Projektklassifizierung sind dokumentiert. -- **Organisatorisch:** Klassifizierungskriterien (Datenschutzbedarf, Kundenbezug, Kritikalität) und Verfahren beschreiben und freigeben. -- **Technisch:** Kriterienkatalog im PM-Tool/DMS verfügbar machen. -- **Typische Nachweise:** dokumentiertes Klassifizierungsverfahren; Kriterienkatalog. -- **Vorlage:** R01; VA-19 -- **Ressourcen:** ISB + PMO; ca. 1 PT. -- **AL-Filter:** AL2 + AL3 - -### 1.2.3-S2 — [SOLL] -**Anforderung:** In früher Projektphase erfolgt eine Risikobewertung nach definiertem Verfahren; Wiederholung bei Änderungen. -- **Organisatorisch:** Risikobewertung als Pflicht-Deliverable früher Projektphasen und bei wesentlichen Änderungen festlegen. -- **Technisch:** Risikobewertungsvorlage mit Projekt-Workflow verknüpfen. -- **Typische Nachweise:** Projekt-Risikobewertungen; Änderungs-Trigger-Doku. -- **Vorlage:** R01; VA-19; VA-09 -- **Ressourcen:** Projektleitung + ISB; je Projekt. -- **AL-Filter:** AL2 + AL3 - -### 1.2.3-S3 — [SOLL] -**Anforderung:** Für identifizierte Risiken werden Maßnahmen abgeleitet und im Projekt berücksichtigt. -- **Organisatorisch:** Maßnahmen aus der Risikobewertung in Projektplan/-backlog überführen und nachverfolgen. -- **Technisch:** Maßnahmen als Tasks im PM-Tool mit Verantwortlichen/Terminen führen. -- **Typische Nachweise:** Maßnahmenliste je Projekt; Statusnachverfolgung. -- **Vorlage:** R01; VA-19 -- **Ressourcen:** Projektteam; je Projekt. -- **AL-Filter:** AL2 + AL3 - -### 1.2.3-H1 — [HOCH] -**Anforderung:** Abgeleitete Maßnahmen werden im Projektverlauf regelmäßig überprüft und bei geänderten Bewertungskriterien neu bewertet. (C, I, A) -- **Organisatorisch:** Periodische Reviews der Projektmaßnahmen in Projektsteuerung/Gates verankern; Trigger für Neubewertung definieren. -- **Technisch:** Review-Termine/Reminder und Statusfelder im PM-Tool automatisieren. -- **Typische Nachweise:** Review-Protokolle; aktualisierte Risiko-/Maßnahmenstände. -- **Vorlage:** R01; VA-19; VA-09 -- **Ressourcen:** Projektleitung + ISB; laufend. -- **AL-Filter:** AL3 (hoher Schutzbedarf) - -## Control 1.3.1 — Inwieweit sind Informationswerte identifiziert und erfasst? - -### 1.3.1-M1 — [MUSS] -**Anforderung:** Informationswerte und weitere sicherheitsrelevante Assets sind identifiziert und erfasst. -- **Organisatorisch:** Erhebungsverfahren und Verantwortliche (Asset Owner) festlegen; Informationswerte je Bereich erheben. -- **Technisch:** Asset-Inventar/CMDB aufbauen und pflegen; Eindeutige IDs vergeben. -- **Typische Nachweise:** Asset-/Informationswert-Inventar; Owner-Zuordnung. -- **Vorlage:** R02; VA-08 -- **Ressourcen:** ISB + Fachbereiche; ggf. Inventar-/CMDB-Tool (Beschaffung möglich). -- **AL-Filter:** AL2 + AL3 - -### 1.3.1-M2 — [MUSS] -**Anforderung:** Die unterstützenden Assets, die Informationswerte verarbeiten, sind identifiziert und erfasst. -- **Organisatorisch:** Abhängigkeiten zwischen Informationswerten und unterstützenden Assets (Systeme, Anwendungen, Standorte, Dienstleister) erheben. -- **Technisch:** Verknüpfung Informationswert ↔ unterstützendes Asset in der CMDB abbilden. -- **Typische Nachweise:** Inventar unterstützender Assets; Abhängigkeits-/Mapping-Übersicht. -- **Vorlage:** R02; VA-08 -- **Ressourcen:** IT + Fachbereiche; laufend. -- **AL-Filter:** AL2 + AL3 - -### 1.3.1-S1 — [SOLL] -**Anforderung:** Ein Katalog relevanter Informationswerte existiert; einschlägige Aspekte werden berücksichtigt. -- **Organisatorisch:** Strukturierten Katalog mit Attributen (Owner, Klassifizierung, Speicherort, Aufbewahrung) etablieren und pflegen. -- **Technisch:** Katalog in Inventar-Tool mit Pflichtfeldern und Aktualisierungsroutine. -- **Typische Nachweise:** Informationswert-Katalog mit Attributen. -- **Vorlage:** R02; VA-08 -- **Ressourcen:** ISB; laufend. -- **AL-Filter:** AL2 + AL3 - -## Control 1.3.2 — Inwieweit werden Informationswerte klassifiziert und geschützt? - -### 1.3.2-M1 — [MUSS] -**Anforderung:** Ein konsistentes Schema zur Klassifizierung hinsichtlich Vertraulichkeit ist vorhanden. -- **Organisatorisch:** Vertraulichkeitsstufen (z. B. öffentlich/intern/vertraulich/streng vertraulich) mit Kriterien definieren und freigeben. -- **Technisch:** Klassifizierungsschema in Vorlagen/Labels (z. B. Klassifizierungstool) verankern. -- **Typische Nachweise:** freigegebenes Klassifizierungsschema mit Stufen/Kriterien. -- **Vorlage:** R02; VA-08 -- **Ressourcen:** ISB; ca. 1 PT. -- **AL-Filter:** AL2 + AL3 - -### 1.3.2-M2 — [MUSS] -**Anforderung:** Informationswerte werden nach definierten Kriterien bewertet und dem Schema zugeordnet. -- **Organisatorisch:** Asset Owner klassifizieren ihre Informationswerte; Vollständigkeit prüfen. -- **Technisch:** Klassifizierungsattribut im Inventar/CMDB pflegen; ggf. Labeling in Dokumenten. -- **Typische Nachweise:** klassifiziertes Inventar; Stichprobe klassifizierter Werte. -- **Vorlage:** R02; VA-08 -- **Ressourcen:** Fachbereiche + ISB; laufend. -- **AL-Filter:** AL2 + AL3 - -### 1.3.2-M3 — [MUSS] -**Anforderung:** Vorgaben zur Handhabung unterstützender Assets abhängig von der Klassifizierung sind vorhanden und umgesetzt (Kennzeichnung, Nutzung, Transport, Speicherung, Rückgabe, Löschung/Vernichtung). -- **Organisatorisch:** Handhabungsmatrix je Klassifizierungsstufe (inkl. Löschung/Vernichtung) definieren und schulen. -- **Technisch:** Technische Kontrollen umsetzen (Verschlüsselung, Zugriffsrechte, sichere Löschung/Datenträgervernichtung) passend zur Stufe. -- **Typische Nachweise:** Handhabungsrichtlinie/-matrix; Lösch-/Vernichtungsnachweise. -- **Vorlage:** R02 -- **Ressourcen:** ISB + IT; ggf. Beschaffung Vernichtungs-/Verschlüsselungslösung. -- **AL-Filter:** AL2 + AL3 - -### 1.3.2-S1 — [SOLL] -**Anforderung:** Die Schutzziele Integrität und Verfügbarkeit werden berücksichtigt. -- **Organisatorisch:** Klassifizierung um Integritäts- und Verfügbarkeitsstufen erweitern; Kriterien definieren. -- **Technisch:** I-/A-Attribute im Inventar; abgeleitete Schutzmaßnahmen (z. B. Backup nach BL-OPS-05) zuordnen. -- **Typische Nachweise:** erweitertes Schema C/I/A; klassifizierte Werte inkl. I/A. -- **Vorlage:** R02; VA-08; BL-OPS-05 -- **Ressourcen:** ISB; ca. 1 PT. -- **AL-Filter:** AL2 + AL3 - -## Control 1.3.3 — Inwieweit ist sichergestellt, dass nur bewertete und freigegebene externe IT-Dienste genutzt werden? - -### 1.3.3-M1 — [MUSS] -**Anforderung:** Externe IT-Dienste werden nicht ohne ausdrückliche Bewertung und Umsetzung der IS-Anforderungen genutzt; einschlägige Aspekte werden berücksichtigt. -- **Organisatorisch:** Verpflichtende IS-Bewertung vor Nutzung externer IT-Dienste (Cloud/SaaS) im Beschaffungs-/Freigabeprozess verankern. -- **Technisch:** Cloud-/SaaS-Register führen; Nutzung nicht freigegebener Dienste durch Netzwerk-/Proxy-Kontrollen einschränken (Shadow-IT-Erkennung). -- **Typische Nachweise:** Bewertungsdokumente je Dienst; Freigabeliste; Register. -- **Vorlage:** R02 -- **Ressourcen:** ISB + Einkauf/IT; laufend; ggf. CASB/Proxy. -- **AL-Filter:** AL2 + AL3 - -### 1.3.3-M2 — [MUSS] -**Anforderung:** Externe IT-Dienste sind mit dem Schutzbedarf der verarbeiteten Informationswerte abgestimmt. -- **Organisatorisch:** Schutzbedarf der zu verarbeitenden Daten dem Dienst gegenüberstellen; Eignung dokumentieren. -- **Technisch:** Schutzbedarf/Klassifizierung im Dienstregister mit zulässigen Datenkategorien verknüpfen. -- **Typische Nachweise:** Schutzbedarfs-/Eignungsbewertung je Dienst. -- **Vorlage:** R02 -- **Ressourcen:** ISB + Fachbereich; je Dienst. -- **AL-Filter:** AL2 + AL3 - -### 1.3.3-S1 — [SOLL] -**Anforderung:** Anforderungen an Beschaffung, Inbetriebnahme und Freigabe externer IT-Dienste sind bestimmt und erfüllt. -- **Organisatorisch:** IS-Anforderungen in Beschaffungs-/Onboarding-Checklisten für externe Dienste aufnehmen. -- **Technisch:** Konfigurations-/Sicherheitsvorgaben (z. B. SSO, Verschlüsselung) bei Inbetriebnahme prüfen. -- **Typische Nachweise:** Beschaffungs-/Freigabecheckliste; Inbetriebnahme-Doku. -- **Vorlage:** R02 -- **Ressourcen:** Einkauf + IT + ISB; je Dienst. -- **AL-Filter:** AL2 + AL3 - -### 1.3.3-S2 — [SOLL] -**Anforderung:** Ein Verfahren zur Freigabe unter Berücksichtigung des Schutzbedarfs ist etabliert. -- **Organisatorisch:** Formalen Freigabe-Workflow mit Rollen und Entscheidungskriterien definieren. -- **Technisch:** Freigabe-Workflow im Ticket-/Service-Management abbilden. -- **Typische Nachweise:** dokumentiertes Freigabeverfahren; Freigabetickets. -- **Vorlage:** R02 -- **Ressourcen:** ISB + IT; ca. 1 PT. -- **AL-Filter:** AL2 + AL3 - -### 1.3.3-S3 — [SOLL] -**Anforderung:** Externe IT-Dienste und ihre Freigabe sind dokumentiert. -- **Organisatorisch:** Zentrales, aktuelles Register freigegebener Dienste mit Freigabestatus führen. -- **Technisch:** Register im GRC-/Service-Tool mit Freigabehistorie. -- **Typische Nachweise:** Dienstregister mit Freigabestatus. -- **Vorlage:** R02 -- **Ressourcen:** ISB; laufend. -- **AL-Filter:** AL2 + AL3 - -### 1.3.3-S4 — [SOLL] -**Anforderung:** Es wird regelmäßig überprüft, dass nur freigegebene externe IT-Dienste genutzt werden. -- **Organisatorisch:** Periodische Reviews/Abgleich der tatsächlichen Nutzung gegen die Freigabeliste durchführen. -- **Technisch:** Shadow-IT-/CASB-Reports oder Proxy-Logauswertung nutzen. -- **Typische Nachweise:** Review-Protokolle; Shadow-IT-Reports. -- **Vorlage:** R02; VA-15 -- **Ressourcen:** IT + ISB; periodisch. -- **AL-Filter:** AL2 + AL3 - -## Control 1.3.4 — Inwieweit ist sichergestellt, dass nur bewertete und freigegebene Software genutzt wird? - -### 1.3.4-M1 — [MUSS] -**Anforderung:** Software wird vor Installation/Nutzung freigegeben; einschlägige Aspekte werden berücksichtigt. -- **Organisatorisch:** Softwarefreigabeprozess (Bewertung Herkunft, Lizenz, Sicherheit) definieren und verpflichtend machen. -- **Technisch:** Application-Whitelisting/Allowlisting und Softwareverteilung über zentrales Endpoint-/Client-Management. -- **Typische Nachweise:** Freigabeliste zugelassener Software; Whitelisting-Konfiguration. -- **Vorlage:** R02 -- **Ressourcen:** IT + ISB; ggf. Endpoint-Management/Whitelisting-Tool. -- **AL-Filter:** AL2 + AL3 - -### 1.3.4-M2 — [MUSS] -**Anforderung:** Die Softwarefreigabe gilt auch für Spezialsoftware wie Wartungswerkzeuge. -- **Organisatorisch:** Wartungs-/Diagnose- und Spezialwerkzeuge explizit in den Freigabeprozess einbeziehen. -- **Technisch:** Kontrollierte Bereitstellung von Wartungssoftware (dedizierte Konten/Systeme, Freigabe je Einsatz). -- **Typische Nachweise:** Freigabeliste inkl. Spezialsoftware; Einsatz-/Freigabedoku. -- **Vorlage:** R02 -- **Ressourcen:** IT + ISB; laufend. -- **AL-Filter:** AL2 + AL3 - -### 1.3.4-S1 — [SOLL] -**Anforderung:** Die zu verwaltenden Softwarearten (Firmware, Betriebssysteme, Anwendungen, Bibliotheken, Gerätetreiber) sind bestimmt. -- **Organisatorisch:** Geltungsbereich des Software-Managements je Softwareart festlegen. -- **Technisch:** Kategorisierung im Software-Inventar/CMDB abbilden. -- **Typische Nachweise:** Übersicht verwalteter Softwarearten. -- **Vorlage:** R02 -- **Ressourcen:** IT; gering. -- **AL-Filter:** AL2 + AL3 - -### 1.3.4-S2 — [SOLL] -**Anforderung:** Repositorys der verwalteten Software existieren. -- **Organisatorisch:** Verbindliche zentrale Software-Quellen definieren. -- **Technisch:** Zentrales Software-Repository/Paketquelle (Distributionspunkt) bereitstellen. -- **Typische Nachweise:** Repository-Übersicht; Verweis auf Distributionspunkt. -- **Vorlage:** R02 -- **Ressourcen:** IT; ggf. Repository-Tool. -- **AL-Filter:** AL2 + AL3 - -### 1.3.4-S3 — [SOLL] -**Anforderung:** Die Software-Repositorys sind gegen unbefugte Manipulation geschützt. -- **Organisatorisch:** Zugriff auf Repositorys nach Least-Privilege regeln; Änderungen protokollieren. -- **Technisch:** Zugriffsschutz, Integritätsprüfung (Signaturen/Hashes), Protokollierung. -- **Typische Nachweise:** Berechtigungskonzept Repository; Integritäts-/Signaturnachweise. -- **Vorlage:** R02; BL-IAM-05 -- **Ressourcen:** IT; ca. 1 PT. -- **AL-Filter:** AL2 + AL3 - -### 1.3.4-S4 — [SOLL] -**Anforderung:** Die Freigabe von Software wird regelmäßig überprüft. -- **Organisatorisch:** Periodisches Review der Freigabeliste (weiterhin benötigt/sicher) durchführen. -- **Technisch:** Report aus Software-Inventar/Whitelisting als Reviewgrundlage. -- **Typische Nachweise:** Review-Protokolle der Softwarefreigaben. -- **Vorlage:** R02; VA-15 -- **Ressourcen:** IT + ISB; periodisch. -- **AL-Filter:** AL2 + AL3 - -### 1.3.4-S5 — [SOLL] -**Anforderung:** Softwareversionen und Patch-Stände sind bekannt. -- **Organisatorisch:** Verantwortlichkeit für Versions-/Patchstand-Überblick festlegen. -- **Technisch:** Inventarisierung von Version/Patch via Endpoint-Management/Discovery. -- **Typische Nachweise:** Versions-/Patchstand-Report aus dem Inventar. -- **Vorlage:** R02 -- **Ressourcen:** IT; laufend; ggf. Discovery-Tool. -- **AL-Filter:** AL2 + AL3 - -### 1.3.4-V1 — [SEHR HOCH] -**Anforderung:** Zusätzliche Anforderungen an die Softwarenutzung (z. B. Kontroll-/Überwachungsbedarf) sind, sofern vorhanden, bestimmt. (C, I, A) -- **Organisatorisch:** Für Software mit sehr hohem Schutzbedarf zusätzliche Nutzungs-/Überwachungsauflagen definieren. -- **Technisch:** Erweiterte Protokollierung/Monitoring der Softwarenutzung (z. B. Nutzungslogs, Integritätsüberwachung) umsetzen. -- **Typische Nachweise:** dokumentierte Zusatzanforderungen; Monitoring-/Nutzungsprotokolle. -- **Vorlage:** R02 -- **Ressourcen:** IT + ISB; ggf. Monitoring-Erweiterung. -- **AL-Filter:** AL3 (sehr hoher Schutzbedarf) - -## Control 1.4.1 — Inwieweit werden Informationssicherheitsrisiken gemanagt? - -### 1.4.1-M1 — [MUSS] -**Anforderung:** Risikobewertungen werden regelmäßig und anlassbezogen durchgeführt. -- **Organisatorisch:** Turnus (z. B. jährlich) und Anlässe (Änderungen, Vorfälle) für Risikobewertungen festlegen. -- **Technisch:** Risikoregister/GRC-Tool mit Terminierung und Wiedervorlagen. -- **Typische Nachweise:** Risikobewertungsberichte; Zeitplan. -- **Vorlage:** R03; VA-09 -- **Ressourcen:** ISB + Risk Owner; periodisch. -- **AL-Filter:** AL2 + AL3 - -### 1.4.1-M2 — [MUSS] -**Anforderung:** Risiken werden angemessen bewertet (z. B. Eintrittswahrscheinlichkeit und Schadensausmaß). -- **Organisatorisch:** Bewertungsmethodik (Skalen für Wahrscheinlichkeit/Auswirkung) definieren und anwenden. -- **Technisch:** Methodik im GRC-Tool als Bewertungsschema hinterlegen. -- **Typische Nachweise:** bewertete Risiken mit Wahrscheinlichkeit/Auswirkung; Methodenbeschreibung. -- **Vorlage:** R03; VA-09 -- **Ressourcen:** ISB; laufend. -- **AL-Filter:** AL2 + AL3 - -### 1.4.1-M3 — [MUSS] -**Anforderung:** Informationssicherheitsrisiken werden dokumentiert. -- **Organisatorisch:** Vollständige, aktuelle Risikodokumentation sicherstellen. -- **Technisch:** Zentrales Risikoregister im GRC-Tool. -- **Typische Nachweise:** Risikoregister. -- **Vorlage:** R03; VA-09 -- **Ressourcen:** ISB; laufend. -- **AL-Filter:** AL2 + AL3 - -### 1.4.1-M4 — [MUSS] -**Anforderung:** Jedem Risiko ist ein Risk Owner zugeordnet, der für Bewertung und Behandlung verantwortlich ist. -- **Organisatorisch:** Risk Owner je Risiko benennen und Verantwortung kommunizieren. -- **Technisch:** Owner-Feld im Risikoregister pflegen (Pflichtfeld). -- **Typische Nachweise:** Risikoregister mit Owner-Zuordnung. -- **Vorlage:** R03 -- **Ressourcen:** ISB + Fachbereiche; gering. -- **AL-Filter:** AL2 + AL3 - -### 1.4.1-S1 — [SOLL] -**Anforderung:** Ein Verfahren zur Identifikation, Bewertung und Behandlung von Sicherheitsrisiken ist vorhanden. -- **Organisatorisch:** Risikomanagement-Verfahren dokumentieren und freigeben. -- **Technisch:** Verfahren im GRC-Tool/DMS verankern. -- **Typische Nachweise:** freigegebenes Risikomanagement-Verfahren. -- **Vorlage:** R03; VA-09 -- **Ressourcen:** ISB; ca. 1–2 PT. -- **AL-Filter:** AL2 + AL3 - -### 1.4.1-S2 — [SOLL] -**Anforderung:** Kriterien für Bewertung und Behandlung von Sicherheitsrisiken existieren. -- **Organisatorisch:** Akzeptanzkriterien/Risikoappetit und Behandlungskriterien festlegen und freigeben. -- **Technisch:** Kriterien/Schwellenwerte im GRC-Tool hinterlegen. -- **Typische Nachweise:** Kriterienkatalog; Risikoakzeptanzkriterien. -- **Vorlage:** R03 -- **Ressourcen:** ISB + Leitung; gering. -- **AL-Filter:** AL2 + AL3 - -### 1.4.1-S3 — [SOLL] -**Anforderung:** Behandlungsmaßnahmen und Verantwortliche sind festgelegt und dokumentiert; ein Maßnahmenplan wird nachverfolgt. -- **Organisatorisch:** Risikobehandlungsplan mit Maßnahmen, Verantwortlichen und Terminen führen. -- **Technisch:** Maßnahmen-Tracking im GRC-Tool mit Statusverfolgung. -- **Typische Nachweise:** Risikobehandlungsplan; Maßnahmenstatus. -- **Vorlage:** R03 -- **Ressourcen:** ISB + Risk Owner; laufend. -- **AL-Filter:** AL2 + AL3 - -### 1.4.1-S4 — [SOLL] -**Anforderung:** Bei Umfeldänderungen (Organisationsstruktur, Standort, Regularien) erfolgt zeitnah eine Neubewertung. -- **Organisatorisch:** Trigger für anlassbezogene Neubewertung definieren und in Change-Prozesse einbinden. -- **Technisch:** Change-/Ereignis-gekoppelte Erinnerung zur Risiko-Neubewertung. -- **Typische Nachweise:** dokumentierte anlassbezogene Neubewertungen. -- **Vorlage:** R03; VA-09 -- **Ressourcen:** ISB; laufend. -- **AL-Filter:** AL2 + AL3 - -## Control 1.5.1 — Inwieweit wird die Einhaltung von Informationssicherheit überprüft (interne Compliance)? - -### 1.5.1-M1 — [MUSS] -**Anforderung:** Die Einhaltung der Richtlinien wird organisationsweit überprüft. -- **Organisatorisch:** Regelmäßige Compliance-Prüfungen/interne Audits über alle Bereiche planen und durchführen. -- **Technisch:** Prüfergebnisse im GRC-Tool erfassen. -- **Typische Nachweise:** Auditplan; Prüf-/Auditberichte. -- **Vorlage:** R03; VA-15 -- **Ressourcen:** ISB/Interne Revision; periodisch. -- **AL-Filter:** AL2 + AL3 - -### 1.5.1-M2 — [MUSS] -**Anforderung:** Richtlinien und Verfahren werden regelmäßig überprüft. -- **Organisatorisch:** Review-Zyklen je Dokument festlegen und nachhalten. -- **Technisch:** Wiedervorlage/Review-Reminder im DMS/GRC. -- **Typische Nachweise:** Review-Historie der Dokumente. -- **Vorlage:** R03; VA-15 -- **Ressourcen:** ISB; laufend. -- **AL-Filter:** AL2 + AL3 - -### 1.5.1-M3 — [MUSS] -**Anforderung:** Maßnahmen zur Korrektur möglicher Abweichungen werden eingeleitet und verfolgt. -- **Organisatorisch:** Abweichungs-/Maßnahmenmanagement (CAPA) mit Verantwortlichen und Fristen etablieren. -- **Technisch:** Findings/Maßnahmen im GRC-Tool nachverfolgen. -- **Typische Nachweise:** Maßnahmenliste zu Findings; Statusnachverfolgung. -- **Vorlage:** R03; VA-15 -- **Ressourcen:** ISB + Fachbereiche; laufend. -- **AL-Filter:** AL2 + AL3 - -### 1.5.1-M4 — [MUSS] -**Anforderung:** Die Einhaltung von IS-Anforderungen (z. B. technische Vorgaben) wird regelmäßig überprüft. -- **Organisatorisch:** Technische Compliance-Prüfungen (Konfiguration/Baseline-Konformität) planen. -- **Technisch:** Automatisierte Compliance-/Konfigurations-Scans gegen Baseline-Vorgaben (BL-*). -- **Typische Nachweise:** Scan-/Konformitätsberichte; Abweichungslisten. -- **Vorlage:** R03; VA-15 -- **Ressourcen:** IT + ISB; ggf. Compliance-Scan-Tool. -- **AL-Filter:** AL2 + AL3 - -### 1.5.1-M5 — [MUSS] -**Anforderung:** Ergebnisse der Überprüfungen werden aufgezeichnet und aufbewahrt. -- **Organisatorisch:** Aufbewahrungsfristen für Prüfergebnisse festlegen. -- **Technisch:** Revisionssichere Ablage der Berichte im DMS/GRC. -- **Typische Nachweise:** archivierte Prüfberichte; Ablage-/Aufbewahrungsnachweis. -- **Vorlage:** R03; VA-15 -- **Ressourcen:** ISB; gering. -- **AL-Filter:** AL2 + AL3 - -### 1.5.1-S1 — [SOLL] -**Anforderung:** Ein Plan für Inhalt und Rahmenbedingungen (Zeitplan, Umfang, Controls) der Überprüfungen liegt vor. -- **Organisatorisch:** Mehrjahres-/Jahresauditplan mit Scope und Terminen erstellen und freigeben. -- **Technisch:** Auditplan im GRC-Tool mit Terminplanung. -- **Typische Nachweise:** freigegebener Prüf-/Auditplan. -- **Vorlage:** R03; VA-15 -- **Ressourcen:** ISB; ca. 1 PT. -- **AL-Filter:** AL2 + AL3 - -## Control 1.5.2 — Inwieweit wird die Informationssicherheit durch unabhängige Stellen überprüft? - -### 1.5.2-M1 — [MUSS] -**Anforderung:** IS-Überprüfungen werden durch eine unabhängige und kompetente Stelle regelmäßig und nach grundlegenden Änderungen durchgeführt. -- **Organisatorisch:** Unabhängige Prüfinstanz (interne Revision oder externer Prüfer) beauftragen; Unabhängigkeit sicherstellen; Turnus/Anlässe festlegen. -- **Technisch:** Prüfergebnisse zentral im GRC-Tool dokumentieren. -- **Typische Nachweise:** unabhängige Prüf-/Auditberichte; Beauftragung/Unabhängigkeitsnachweis. -- **Vorlage:** R03; VA-15 -- **Ressourcen:** ISB + interne Revision/externer Auditor; Prüfbudget möglich. -- **AL-Filter:** AL2 + AL3 - -### 1.5.2-M2 — [MUSS] -**Anforderung:** Maßnahmen zur Korrektur möglicher Abweichungen werden eingeleitet und verfolgt. -- **Organisatorisch:** Findings der unabhängigen Prüfung in das Maßnahmenmanagement überführen und nachhalten. -- **Technisch:** Maßnahmen-Tracking im GRC-Tool. -- **Typische Nachweise:** Maßnahmenliste zu Prüf-Findings; Statusnachverfolgung. -- **Vorlage:** R03; VA-15 -- **Ressourcen:** ISB + Fachbereiche; laufend. -- **AL-Filter:** AL2 + AL3 - -### 1.5.2-S1 — [SOLL] -**Anforderung:** Ergebnisse der Überprüfungen werden dokumentiert und der Organisationsleitung berichtet. -- **Organisatorisch:** Berichtsweg an die Leitung (z. B. im Management-Review) etablieren. -- **Technisch:** Berichte/Reportings im GRC-Tool bereitstellen. -- **Typische Nachweise:** Prüfbericht mit Leitungsvorlage; Management-Review-Protokoll. -- **Vorlage:** R03; VA-15 -- **Ressourcen:** ISB; gering, periodisch. -- **AL-Filter:** AL2 + AL3 - -## Control 1.6.1 — Inwieweit werden Sicherheitsereignisse gemeldet? - -### 1.6.1-M1 — [MUSS] -**Anforderung:** Eine Definition für ein meldepflichtiges Sicherheitsereignis/eine Beobachtung existiert und ist bekannt. -- **Organisatorisch:** Definition und Beispiele meldepflichtiger Ereignisse festlegen und kommunizieren. -- **Technisch:** Definition im Intranet/Meldeportal verfügbar machen. -- **Typische Nachweise:** dokumentierte Definition; Kommunikations-/Schulungsnachweis. -- **Vorlage:** R04; VA-01 -- **Ressourcen:** ISB; gering. -- **AL-Filter:** AL2 + AL3 - -### 1.6.1-M2 — [MUSS] -**Anforderung:** Angemessene, risikoorientierte Meldemechanismen sind definiert, umgesetzt und bekannt. -- **Organisatorisch:** Meldeprozess und -wege definieren und einführen; Bekanntmachung sicherstellen. -- **Technisch:** Meldekanäle bereitstellen (Ticketsystem, Meldeportal, Hotline/E-Mail). -- **Typische Nachweise:** beschriebener Meldeprozess; eingerichtete Meldekanäle; Kommunikation. -- **Vorlage:** R04; VA-01 -- **Ressourcen:** ISB + IT; ggf. Ticket-/Meldetool. -- **AL-Filter:** AL2 + AL3 - -### 1.6.1-M3 — [MUSS] -**Anforderung:** Angemessene Kanäle zur Kommunikation mit Meldenden existieren. -- **Organisatorisch:** Rückkanäle für Rückfragen/Statusinformation an Meldende festlegen. -- **Technisch:** Kommunikationsfunktion im Ticketsystem (Rückmeldungen, Status). -- **Typische Nachweise:** Kommunikationsverlauf im Ticketsystem; Kanalbeschreibung. -- **Vorlage:** R04 -- **Ressourcen:** IT + ISB; gering. -- **AL-Filter:** AL2 + AL3 - -### 1.6.1-S1 — [SOLL] -**Anforderung:** Eine gemeinsame Anlaufstelle für die Ereignismeldung existiert. -- **Organisatorisch:** Single Point of Contact (z. B. Security-Postfach/Service Desk) benennen. -- **Technisch:** Zentrale Meldeadresse/-portal einrichten. -- **Typische Nachweise:** SPoC-Beschreibung; zentrale Meldeadresse. -- **Vorlage:** R04 -- **Ressourcen:** ISB + IT; gering. -- **AL-Filter:** AL2 + AL3 - -### 1.6.1-S2 — [SOLL] -**Anforderung:** Verschiedene Meldekanäle je nach Schwere (Echtzeit für Notfälle, asynchron via Ticket/E-Mail) sind verfügbar. -- **Organisatorisch:** Kanäle nach Schweregrad differenzieren (Hotline vs. Ticket) und kommunizieren. -- **Technisch:** Hotline/Notfallnummer plus asynchrone Kanäle (Ticket, E-Mail) bereitstellen. -- **Typische Nachweise:** Kanalübersicht nach Schweregrad. -- **Vorlage:** R04 -- **Ressourcen:** IT + ISB; gering. -- **AL-Filter:** AL2 + AL3 - -### 1.6.1-S3 — [SOLL] -**Anforderung:** Beschäftigte sind verpflichtet und geschult, relevante Ereignisse zu melden. -- **Organisatorisch:** Meldepflicht in Richtlinien/Verpflichtung verankern; Schulung/Sensibilisierung durchführen. -- **Technisch:** Schulungsnachweise im Schulungssystem dokumentieren. -- **Typische Nachweise:** Verpflichtung; Schulungs-/Awareness-Nachweise. -- **Vorlage:** R04; VA-12 -- **Ressourcen:** ISB + HR; laufend. -- **AL-Filter:** AL2 + AL3 - -### 1.6.1-S4 — [SOLL] -**Anforderung:** Sicherheitsereignisse können auch durch Externe gemeldet werden; einschlägige Aspekte werden berücksichtigt. -- **Organisatorisch:** Externen Meldeweg definieren und kommunizieren (Lieferanten, Kunden, Öffentlichkeit). -- **Technisch:** Öffentlich erreichbare Meldeadresse/-formular (ggf. security.txt/Kontaktseite). -- **Typische Nachweise:** externe Kontakt-/Meldemöglichkeit; Prozessbeschreibung. -- **Vorlage:** R04 -- **Ressourcen:** ISB + IT; gering. -- **AL-Filter:** AL2 + AL3 - -### 1.6.1-S5 — [SOLL] -**Anforderung:** Mechanismus und Information zur Meldung sind für alle relevanten Meldenden zugänglich. -- **Organisatorisch:** Zugänglichkeit der Meldeinformation für alle Zielgruppen sicherstellen. -- **Technisch:** Meldeinformationen an zentralen, jederzeit erreichbaren Stellen (Intranet, Portal) veröffentlichen. -- **Typische Nachweise:** veröffentlichte Meldeanleitung; Zugriffsnachweis. -- **Vorlage:** R04 -- **Ressourcen:** ISB; gering. -- **AL-Filter:** AL2 + AL3 - -### 1.6.1-S6 — [SOLL] -**Anforderung:** Ein Rückmeldeverfahren an die Meldenden ist etabliert. -- **Organisatorisch:** Feedback-/Statusrückmeldung an Meldende verbindlich festlegen. -- **Technisch:** Automatische Eingangs-/Statusbenachrichtigung im Ticketsystem. -- **Typische Nachweise:** Rückmeldungen/Benachrichtigungen; Prozessbeschreibung. -- **Vorlage:** R04 -- **Ressourcen:** IT + ISB; gering. -- **AL-Filter:** AL2 + AL3 - -### 1.6.1-V1 — [SEHR HOCH] -**Anforderung:** Tests und Übungen der Ereignis- und Beobachtungsmeldung werden regelmäßig durchgeführt. (C, I, A) -- **Organisatorisch:** Regelmäßige Meldeübungen (z. B. Phishing-Simulation, Testmeldungen) planen und auswerten. -- **Technisch:** Simulations-/Testmeldungen über die Meldekanäle auslösen und Ergebnisse auswerten. -- **Typische Nachweise:** Übungsplan; Übungs-/Auswertungsberichte. -- **Vorlage:** R04; VA-01 -- **Ressourcen:** ISB; periodisch; ggf. Awareness-/Simulationstool. -- **AL-Filter:** AL3 (sehr hoher Schutzbedarf) - -## Control 1.6.2 — Inwieweit werden gemeldete Sicherheitsereignisse gemanagt? - -### 1.6.2-M1 — [MUSS] -**Anforderung:** Gemeldete Ereignisse werden ohne unangemessene Verzögerung bearbeitet. -- **Organisatorisch:** Bearbeitungsprozess mit Erstreaktion und Verantwortlichen definieren. -- **Technisch:** Ticket-/Incident-Workflow mit Eingangs- und Bearbeitungsstatus. -- **Typische Nachweise:** Incident-Tickets mit Zeitstempeln; Prozessbeschreibung. -- **Vorlage:** R04; VA-01 -- **Ressourcen:** ISB/Incident-Team; laufend. -- **AL-Filter:** AL2 + AL3 - -### 1.6.2-M2 — [MUSS] -**Anforderung:** Eine angemessene Reaktion auf gemeldete Sicherheitsereignisse ist sichergestellt. -- **Organisatorisch:** Reaktions-/Behandlungsverfahren (Analyse, Eindämmung, Behebung) festlegen. -- **Technisch:** Incident-Response-Workflow und ggf. Playbooks im Tool hinterlegen. -- **Typische Nachweise:** dokumentierte Vorfallbehandlung; Abschluss-/Behebungsnachweis. -- **Vorlage:** R04; VA-01 -- **Ressourcen:** Incident-Team; laufend. -- **AL-Filter:** AL2 + AL3 - -### 1.6.2-M3 — [MUSS] -**Anforderung:** Lessons Learned fließen in die kontinuierliche Verbesserung ein. -- **Organisatorisch:** Nachbereitung (Post-Incident-Review) mit Ableitung von Verbesserungen durchführen. -- **Technisch:** Verbesserungsmaßnahmen im GRC-/Maßnahmentool nachverfolgen. -- **Typische Nachweise:** Lessons-Learned-/Post-Incident-Protokolle; abgeleitete Maßnahmen. -- **Vorlage:** R04 -- **Ressourcen:** ISB + Incident-Team; je Vorfall. -- **AL-Filter:** AL2 + AL3 - -### 1.6.2-S1 — [SOLL] -**Anforderung:** Gemeldete Ereignisse werden kategorisiert, qualifiziert und priorisiert. -- **Organisatorisch:** Kategorien, Qualifizierungen und Prioritätsstufen definieren und anwenden. -- **Technisch:** Klassifizierungsfelder/Priorisierung im Ticket-/Incident-System. -- **Typische Nachweise:** kategorisierte/priorisierte Tickets; Klassifizierungsschema. -- **Vorlage:** R04; VA-01 -- **Ressourcen:** Incident-Team; laufend. -- **AL-Filter:** AL2 + AL3 - -### 1.6.2-S2 — [SOLL] -**Anforderung:** Verantwortlichkeiten für die Behandlung je Kategorie sind definiert und zugewiesen. -- **Organisatorisch:** Zuständigkeiten je Ereigniskategorie festlegen (RACI/Eskalationsmatrix). -- **Technisch:** Zuweisungsregeln im Ticketsystem (Routing/Queues). -- **Typische Nachweise:** Zuständigkeitsmatrix; Ticket-Routing-Konfiguration. -- **Vorlage:** R04; VA-01 -- **Ressourcen:** ISB; gering. -- **AL-Filter:** AL2 + AL3 - -### 1.6.2-S3 — [SOLL] -**Anforderung:** Eine Strategie zur Meldung potenziell strafrechtlich relevanter Aspekte an Behörden existiert. (C, I, A) -- **Organisatorisch:** Vorgehen und Zuständigkeit für Behördenmeldungen (Legal/Datenschutz einbinden) festlegen. -- **Technisch:** Kontaktinformationen/Vorlagen im Incident-Prozess hinterlegen. -- **Typische Nachweise:** dokumentierte Meldestrategie; Behördenkontaktliste. -- **Vorlage:** R04 -- **Ressourcen:** ISB + Legal; gering. -- **AL-Filter:** AL2 + AL3 - -### 1.6.2-H1 — [HOCH] -**Anforderung:** Maximale Reaktionszeiten je Klasse, Kategorie und Schwere sind definiert. (C, I, A) -- **Organisatorisch:** SLA/Reaktionszeiten je Priorität/Kategorie festlegen und freigeben. -- **Technisch:** SLA-Zeiten und Timer/Eskalation im Ticketsystem konfigurieren. -- **Typische Nachweise:** SLA-Matrix; SLA-Konfiguration im Tool. -- **Vorlage:** R04 -- **Ressourcen:** ISB + IT; ca. 1 PT. -- **AL-Filter:** AL3 (hoher Schutzbedarf) - -### 1.6.2-H2 — [HOCH] -**Anforderung:** Nicht prioritätsgerecht bearbeitete Ereignisse werden eskaliert; einschlägige Aspekte werden berücksichtigt. (C, I, A) -- **Organisatorisch:** Eskalationswege und -stufen definieren. -- **Technisch:** Automatische SLA-Eskalation bei Fristüberschreitung im Ticketsystem. -- **Typische Nachweise:** Eskalationskonzept; dokumentierte Eskalationen. -- **Vorlage:** R04 -- **Ressourcen:** IT + ISB; ca. 1 PT. -- **AL-Filter:** AL3 (hoher Schutzbedarf) - -### 1.6.2-H3 — [HOCH] -**Anforderung:** Gesetzliche, regulatorische und vertragliche Meldepflichten sowie Kontaktinformationen sind bekannt. (C, I, A) -- **Organisatorisch:** Meldepflichten (z. B. Datenschutz, Kundenverträge) mit Fristen und Kontakten zusammenstellen. -- **Technisch:** Melderegister/Kontaktliste im Incident-Prozess bereitstellen. -- **Typische Nachweise:** Melderegister; Kontaktliste; Vertrags-/Rechtsbezug. -- **Vorlage:** R04 -- **Ressourcen:** ISB + Legal; ca. 1 PT. -- **AL-Filter:** AL3 (hoher Schutzbedarf) - -### 1.6.2-H4 — [HOCH] -**Anforderung:** Eine Kommunikationsstrategie für sicherheitsrelevante Ereignisse existiert; einschlägige Aspekte werden berücksichtigt. (C, I, A) -- **Organisatorisch:** Interne/externe Kommunikationsstrategie (Sprecher, Zielgruppen, Freigaben) definieren. -- **Technisch:** Kommunikationsvorlagen/Verteiler hinterlegen. -- **Typische Nachweise:** Kommunikationsstrategie/-plan; Vorlagen. -- **Vorlage:** R04 -- **Ressourcen:** ISB + Kommunikation; ca. 1 PT. -- **AL-Filter:** AL3 (hoher Schutzbedarf) - -### 1.6.2-H5 — [HOCH] -**Anforderung:** Verfahren zur Reaktion auf Sicherheitsvorfälle bei Lieferanten sind etabliert; einschlägige Aspekte werden berücksichtigt. (C, I, A) -- **Organisatorisch:** Meldepflichten und Reaktionsprozesse mit Lieferanten vertraglich vereinbaren und im Incident-Prozess berücksichtigen. -- **Technisch:** Lieferanten-Kontakte/Schnittstellen im Incident-Tool erfassen. -- **Typische Nachweise:** Lieferanten-Vorfallverfahren; vertragliche Meldeklauseln. -- **Vorlage:** R04; VA-01 -- **Ressourcen:** ISB + Einkauf; ca. 1 PT. -- **AL-Filter:** AL3 (hoher Schutzbedarf) - -### 1.6.2-V1 — [SEHR HOCH] -**Anforderung:** Die Behandlung von Ereignissen unterschiedlicher Kategorien und Prioritäten wird regelmäßig getestet; einschlägige Aspekte werden berücksichtigt. (A) -- **Organisatorisch:** Regelmäßige Incident-Response-Übungen über verschiedene Kategorien/Prioritäten planen und auswerten. -- **Technisch:** Testszenarien über den Incident-Workflow durchspielen; Ergebnisse dokumentieren. -- **Typische Nachweise:** Übungsplan; Übungs-/Testberichte. -- **Vorlage:** R04; VA-01 -- **Ressourcen:** ISB + Incident-Team; periodisch. -- **AL-Filter:** AL3 (sehr hoher Schutzbedarf) - -## Control 1.6.3 — Inwieweit werden Krisen gemanagt? - -### 1.6.3-M1 — [MUSS] -**Anforderung:** Ein angemessener Plan zur Reaktion auf und Bewältigung von Krisensituationen existiert; erforderliche Ressourcen sind verfügbar. -- **Organisatorisch:** Krisenmanagementplan mit Rollen, Abläufen und Ressourcen erstellen und freigeben. -- **Technisch:** Plan und Kontaktdaten redundant/offline verfügbar halten. -- **Typische Nachweise:** freigegebener Krisenmanagementplan; Ressourcenübersicht. -- **Vorlage:** R04; VA-02 -- **Ressourcen:** ISB + Leitung; ca. 2–3 PT. -- **AL-Filter:** AL2 + AL3 - -### 1.6.3-M2 — [MUSS] -**Anforderung:** Verantwortlichkeiten und Befugnisse für das Krisenmanagement sind definiert, dokumentiert und zugewiesen. -- **Organisatorisch:** Krisenrollen und Entscheidungsbefugnisse festlegen und namentlich zuweisen. -- **Technisch:** Rollen-/Kontaktverzeichnis im Krisenplan hinterlegen. -- **Typische Nachweise:** Rollen-/Befugnismatrix; Krisenorganigramm. -- **Vorlage:** R04 -- **Ressourcen:** Leitung + ISB; gering. -- **AL-Filter:** AL2 + AL3 - -### 1.6.3-M3 — [MUSS] -**Anforderung:** Die verantwortlichen Beschäftigten sind definiert und für ihre Aufgabe qualifiziert. -- **Organisatorisch:** Qualifikation der Krisenverantwortlichen sicherstellen (Schulung/Training). -- **Technisch:** Qualifikations-/Trainingsnachweise dokumentieren. -- **Typische Nachweise:** Benennungen; Schulungs-/Trainingsnachweise. -- **Vorlage:** R04; VA-12 -- **Ressourcen:** HR + ISB; Schulungsbudget. -- **AL-Filter:** AL2 + AL3 - -### 1.6.3-S1 — [SOLL] -**Anforderung:** Methoden zur Erkennung von Krisensituationen sind etabliert; Anzeichen und vorhersehbare Krisen sind identifiziert. -- **Organisatorisch:** Frühwarnindikatoren und Erkennungskriterien definieren. -- **Technisch:** Monitoring/Meldeschwellen zur Krisenerkennung einbinden. -- **Typische Nachweise:** Indikatoren-/Erkennungskatalog. -- **Vorlage:** R04; VA-02 -- **Ressourcen:** ISB; ca. 1 PT. -- **AL-Filter:** AL2 + AL3 - -### 1.6.3-S2 — [SOLL] -**Anforderung:** Ein Verfahren zur Auslösung und/oder Eskalation des Krisenmanagements ist vorhanden. -- **Organisatorisch:** Alarmierungs-/Eskalationsverfahren mit Auslösekriterien festlegen. -- **Technisch:** Alarmierungsweg/-tool (Notfallbenachrichtigung) bereitstellen. -- **Typische Nachweise:** Alarmierungs-/Eskalationsverfahren. -- **Vorlage:** R04 -- **Ressourcen:** ISB; ggf. Alarmierungstool. -- **AL-Filter:** AL2 + AL3 - -### 1.6.3-S3 — [SOLL] -**Anforderung:** Strategische Ziele und ihre Priorität in Krisensituationen sind definiert und bekannt. -- **Organisatorisch:** Krisenziele und Prioritäten (z. B. Schutz von Leben, Kernprozessen) festlegen und kommunizieren. -- **Technisch:** Ziele im Krisenplan dokumentieren. -- **Typische Nachweise:** dokumentierte Krisenziele/Prioritäten. -- **Vorlage:** R04 -- **Ressourcen:** Leitung + ISB; gering. -- **AL-Filter:** AL2 + AL3 - -### 1.6.3-S4 — [SOLL] -**Anforderung:** Ein Krisenstab ist definiert und genehmigt. -- **Organisatorisch:** Zusammensetzung, Aufgaben und Stellvertretung des Krisenstabs festlegen und genehmigen. -- **Technisch:** Krisenstab-Kontaktliste redundant vorhalten. -- **Typische Nachweise:** genehmigte Krisenstab-Definition; Besetzungsliste. -- **Vorlage:** R04 -- **Ressourcen:** Leitung + ISB; gering. -- **AL-Filter:** AL2 + AL3 - -### 1.6.3-S5 — [SOLL] -**Anforderung:** Krisenrichtlinien und -verfahren sind definiert und genehmigt. -- **Organisatorisch:** Krisenrichtlinien/-verfahren dokumentieren und freigeben. -- **Technisch:** Verfahren im DMS und offline verfügbar halten. -- **Typische Nachweise:** freigegebene Krisenrichtlinien/-verfahren. -- **Vorlage:** R04; VA-02 -- **Ressourcen:** ISB; ca. 1 PT. -- **AL-Filter:** AL2 + AL3 - -### 1.6.3-S6 — [SOLL] -**Anforderung:** Die Krisenplanung wird regelmäßig überprüft und aktualisiert. -- **Organisatorisch:** Review-Zyklus für die Krisenplanung festlegen. -- **Technisch:** Wiedervorlage/Review-Reminder im DMS. -- **Typische Nachweise:** Review-Historie der Krisenplanung. -- **Vorlage:** R04; VA-15 -- **Ressourcen:** ISB; gering, periodisch. -- **AL-Filter:** AL2 + AL3 - -### 1.6.3-H1 — [HOCH] -**Anforderung:** Relevante unterschiedliche potenzielle Krisenszenarien sind identifiziert. -- **Organisatorisch:** Szenarienkatalog (z. B. Ausfall, Cyberangriff, Standortverlust) erstellen. -- **Technisch:** Szenarien im Krisenplan/BCM-Tool dokumentieren. -- **Typische Nachweise:** Krisenszenarien-Katalog. -- **Vorlage:** R04; VA-02 -- **Ressourcen:** ISB; ca. 1 PT. -- **AL-Filter:** AL3 (hoher Schutzbedarf) - -### 1.6.3-H2 — [HOCH] -**Anforderung:** Notwendige Ressourcen und Informationen zur Krisenbewältigung sind identifiziert; Maßnahmen zur Sicherstellung der Verfügbarkeit/Ausfallplanung sind vorhanden. (A) -- **Organisatorisch:** Kritische Ressourcen (Kommunikation, Kontakt-/Risikoinfos) bestimmen und Ausfallplanung erstellen. -- **Technisch:** Redundante Kommunikationsinfrastruktur; Offline-Verfügbarkeit von Kontakt-/Risikoinformationen; Backup (BL-OPS-05). -- **Typische Nachweise:** Ressourcenliste; Ausfall-/Redundanzkonzept. -- **Vorlage:** R04; BL-OPS-05 -- **Ressourcen:** ISB + IT; ggf. Beschaffung Redundanz. -- **AL-Filter:** AL3 (hoher Schutzbedarf) - -### 1.6.3-H3 — [HOCH] -**Anforderung:** Eine Kommunikationsstrategie für Krisensituationen existiert. (A) -- **Organisatorisch:** Krisenkommunikationsstrategie (interne/externe Zielgruppen, Sprecher, Freigaben) definieren. -- **Technisch:** Kommunikationskanäle/-vorlagen und redundante Erreichbarkeit bereitstellen. -- **Typische Nachweise:** Krisenkommunikationsplan; Vorlagen/Verteiler. -- **Vorlage:** R04 -- **Ressourcen:** ISB + Kommunikation; ca. 1 PT. -- **AL-Filter:** AL3 (hoher Schutzbedarf) - -### 1.6.3-H4 — [HOCH] -**Anforderung:** Effizienz, Durchführbarkeit und Angemessenheit der Krisenplanung werden regelmäßig bewertet. (A) -- **Organisatorisch:** Bewertungskriterien und Turnus zur Beurteilung der Krisenplanung festlegen. -- **Technisch:** Bewertungsergebnisse dokumentieren und Maßnahmen ableiten. -- **Typische Nachweise:** Bewertungsberichte der Krisenplanung. -- **Vorlage:** R04; VA-15 -- **Ressourcen:** ISB; periodisch. -- **AL-Filter:** AL3 (hoher Schutzbedarf) - -### 1.6.3-H5 — [HOCH] -**Anforderung:** Stichprobenbasierte Tests der Krisenplanung werden durchgeführt (z. B. Simulation, Tabletop-Übungen mit Schlüsselpersonal). (A) -- **Organisatorisch:** Tabletop-/Simulationsübungen mit Schlüsselpersonal planen und auswerten. -- **Technisch:** Übungsszenarien vorbereiten; Ergebnisse dokumentieren. -- **Typische Nachweise:** Übungsplan; Übungs-/Auswertungsberichte. -- **Vorlage:** R04; VA-02 -- **Ressourcen:** ISB + Krisenstab; periodisch. -- **AL-Filter:** AL3 (hoher Schutzbedarf) - -### 1.6.3-V1 — [SEHR HOCH] -**Anforderung:** Krisenübungen und Simulationen unter Einbindung aller relevanten Personen einschließlich Entscheidungsträger werden regelmäßig durchgeführt. (A) -- **Organisatorisch:** Umfassende Krisenübungen mit Leitung/Entscheidungsträgern regelmäßig durchführen und nachbereiten. -- **Technisch:** Realitätsnahe Simulationsumgebung/-szenarien inkl. Kommunikationsinfrastruktur einsetzen. -- **Typische Nachweise:** Übungskonzept; Teilnahmenachweise (inkl. Leitung); Auswertungs-/Verbesserungsberichte. -- **Vorlage:** R04; VA-02 -- **Ressourcen:** ISB + Leitung + Krisenstab; periodisch; ggf. externe Übungsbegleitung. -- **AL-Filter:** AL3 (sehr hoher Schutzbedarf) - - ---- - -# Kapitel 2–4 — Personal, Physisch, IAM - -## Control 2.1.1 — Qualifikation und Eignung des Personals - -### 2.1.1-M1 — [MUSS] -**Anforderung:** Sensible Arbeitsbereiche und Tätigkeiten sind bestimmt. -- **Organisatorisch:** Sensible Bereiche/Tätigkeiten (z. B. Administration, Zugang zu Kundennetzen, Fertigung mit Prototypenbezug) in einer Übersicht definieren und den Stellenprofilen zuordnen; Kriterien mit HR und Fachbereichen abstimmen. -- **Technisch:** Zuordnung in der HR-/Berechtigungssystematik hinterlegen, sodass sensible Rollen an erhöhte Prüf- und Berechtigungsanforderungen gekoppelt sind (BL-IAM-04 Rollenmodell). -- **Typische Nachweise:** Liste sensibler Arbeitsbereiche/Tätigkeiten, Stellenprofile mit Sensibilitätskennzeichnung, Freigabevermerk HR/ISB. -- **Vorlage:** R05; VA-14 -- **Ressourcen:** HR + ISB, gering; einmalige Erhebung, danach Pflege im Onboarding. -- **AL-Filter:** AL2, AL3 - -### 2.1.1-M2 — [MUSS] -**Anforderung:** Die Anforderungen an Beschäftigte hinsichtlich ihrer Stellenprofile sind bestimmt und erfüllt. -- **Organisatorisch:** Je Stellenprofil erforderliche Qualifikationen, Sicherheitsanforderungen und Nachweispflichten definieren und im Einstellungsprozess prüfen. -- **Technisch:** Anforderungsprofile im HR-System/Recruiting-Tool als strukturierte Felder pflegen; Abgleich bei Besetzung dokumentieren. -- **Typische Nachweise:** Stellenbeschreibungen mit Sicherheitsanforderungen, Nachweis der Anforderungsprüfung im Einstellungsakt. -- **Vorlage:** R05; VA-14 -- **Ressourcen:** HR, gering–mittel; laufend im Recruiting. -- **AL-Filter:** AL2, AL3 - -### 2.1.1-M3 — [MUSS] -**Anforderung:** Die Identität potenzieller Beschäftigter wird verifiziert (z. B. Prüfung von Ausweisdokumenten). -- **Organisatorisch:** Verbindliche Identitätsprüfung (amtliches Ausweisdokument) als Pflichtschritt im Onboarding festlegen; Ergebnis revisionssicher vermerken (ohne unzulässige Kopien). -- **Technisch:** Prüfvermerk im HR-System dokumentieren; ggf. Identverfahren des Dienstleisters nutzen. -- **Typische Nachweise:** Onboarding-Checkliste mit Feld „Identität geprüft", Prüfvermerk, Prozessbeschreibung. -- **Vorlage:** R05; VA-14 -- **Ressourcen:** HR, gering; je Einstellung. -- **AL-Filter:** AL2, AL3 - -### 2.1.1-S1 — [SOLL] -**Anforderung:** Die persönliche Eignung potenzieller Beschäftigter wird mit einfachen Methoden überprüft (z. B. Vorstellungsgespräch). -- **Organisatorisch:** Strukturiertes Vorstellungsgespräch mit Eignungsbewertung als Standardschritt etablieren; Bewertungsraster verwenden. -- **Technisch:** Bewertung im Recruiting-Tool dokumentieren. -- **Typische Nachweise:** Interviewleitfaden, dokumentierte Eignungsbewertung. -- **Vorlage:** R05; VA-14 -- **Ressourcen:** HR/Fachbereich, gering. -- **AL-Filter:** AL2, AL3 - -### 2.1.1-S2 — [SOLL] -**Anforderung:** Eine erweiterte Eignungsprüfung abhängig vom Arbeitsbereich wird durchgeführt (z. B. Referenzen, Zeugnisse, Führungszeugnis). -- **Organisatorisch:** Für sensible Tätigkeiten (aus M1) erweiterte Prüfschritte festlegen (Referenz-/Zeugnisprüfung, Führungszeugnis) unter Beachtung arbeits- und datenschutzrechtlicher Grenzen. -- **Technisch:** Prüfumfang je Sensibilitätsstufe im HR-System hinterlegen; Nachweise fristgerecht und datensparsam ablegen. -- **Typische Nachweise:** Prüfkonzept nach Sensibilitätsstufe, dokumentierte Referenz-/Zeugnisprüfung, Vermerk Führungszeugnis. -- **Vorlage:** R05; VA-14 -- **Ressourcen:** HR + Datenschutz, mittel; nur für sensible Rollen. -- **AL-Filter:** AL2, AL3 - -## Control 2.1.2 — Verpflichtung der Beschäftigten - -### 2.1.2-M1 — [MUSS] -**Anforderung:** Eine Vertraulichkeitsverpflichtung ist in Kraft. -- **Organisatorisch:** Vertraulichkeitsverpflichtung (NDA/Verschwiegenheit) verpflichtend bei Eintritt unterzeichnen lassen; Nachhalten der Unterschriften. -- **Technisch:** Signierte Verpflichtungen im Personalakten-/DMS-System ablegen; Status je Beschäftigtem nachvollziehbar. -- **Typische Nachweise:** Unterzeichnete Vertraulichkeitsverpflichtungen, Vollständigkeitsübersicht. -- **Vorlage:** R05; VA-14 -- **Ressourcen:** HR, gering; je Eintritt. -- **AL-Filter:** AL2, AL3 - -### 2.1.2-M2 — [MUSS] -**Anforderung:** Eine Verpflichtung zur Einhaltung der Informationssicherheitsrichtlinien ist in Kraft. -- **Organisatorisch:** Verpflichtung zur Einhaltung der IS-Richtlinien in Arbeitsvertrag oder gesonderte Erklärung aufnehmen; bei Richtlinienänderung erneut bestätigen lassen. -- **Technisch:** Bestätigung über HR-Portal/LMS mit Zeitstempel erfassen. -- **Typische Nachweise:** Unterzeichnete Verpflichtungserklärung, Zustimmungsprotokoll im Portal. -- **Vorlage:** R05; VA-14 -- **Ressourcen:** HR, gering. -- **AL-Filter:** AL2, AL3 - -### 2.1.2-S1 — [SOLL] -**Anforderung:** Eine über den Arbeitsvertrag hinausgehende Vertraulichkeitsverpflichtung ist in Kraft. -- **Organisatorisch:** Für Rollen mit Zugang zu hoch klassifizierten oder Kundeninformationen ergänzende NDAs (auch nachvertraglich) vorsehen. -- **Technisch:** Zuordnung erweiterter NDAs zu sensiblen Rollen im HR-System. -- **Typische Nachweise:** Ergänzende NDA-Vorlage, unterzeichnete Zusatzvereinbarungen. -- **Vorlage:** R05; VA-14 -- **Ressourcen:** HR + Recht, gering. -- **AL-Filter:** AL2, AL3 - -### 2.1.2-S2 — [SOLL] -**Anforderung:** Informationssicherheitsaspekte werden in den Arbeitsverträgen der Beschäftigten berücksichtigt. -- **Organisatorisch:** Standard-IS-Klauseln (Geheimhaltung, Richtlinientreue, Rückgabepflichten, Konsequenzen) mit HR/Recht in Vertragsmuster verankern. -- **Technisch:** Zentrale Vertragsvorlagen im DMS versionieren. -- **Typische Nachweise:** Vertragsmuster mit IS-Klauseln, Freigabe Recht. -- **Vorlage:** R05; VA-14 -- **Ressourcen:** HR + Recht, gering; einmalig. -- **AL-Filter:** AL2, AL3 - -### 2.1.2-S3 — [SOLL] -**Anforderung:** Ein Verfahren zum Umgang mit Verstößen gegen diese Verpflichtungen ist beschrieben. -- **Organisatorisch:** Eskalations- und Sanktionsprozess (Disziplinarmaßnahmen) mit HR, Betriebsrat und Recht definieren und kommunizieren. -- **Technisch:** Fälle im HR-/Vorfallsystem nachvollziehbar dokumentieren. -- **Typische Nachweise:** Verfahrensbeschreibung Verstöße, Sanktionskatalog, ggf. dokumentierte Fälle. -- **Vorlage:** R05; VA-14 -- **Ressourcen:** HR + Recht, gering; einmalig, danach anlassbezogen. -- **AL-Filter:** AL2, AL3 - -## Control 2.1.3 — Sensibilisierung und Schulung - -### 2.1.3-M1 — [MUSS] -**Anforderung:** Beschäftigte werden geschult und sensibilisiert. -- **Organisatorisch:** Verpflichtende IS-Awareness-Schulung bei Eintritt und mindestens jährlich; Teilnahme nachhalten und mahnen. -- **Technisch:** Schulungsdurchführung und -nachweis über LMS/Awareness-Plattform, inkl. Erinnerungen. -- **Typische Nachweise:** Schulungsnachweise/Teilnahmequote, Schulungsinhalte, Einladungs-/Mahnprotokolle. -- **Vorlage:** R05; VA-12 -- **Ressourcen:** ISB + HR, mittel; Plattform ggf. zu beschaffen (Awareness-Tool) — führt zu Aufgabe. -- **AL-Filter:** AL2, AL3 - -### 2.1.3-S1 — [SOLL] -**Anforderung:** Ein Konzept für Sensibilisierung und Schulung der Beschäftigten ist erstellt. -- **Organisatorisch:** Awareness-Konzept mit Zielen, Inhalten, Turnus, Formaten und Erfolgskontrolle dokumentieren. -- **Technisch:** Konzept im DMS versionieren; Kennzahlen aus dem LMS ableiten. -- **Typische Nachweise:** Awareness-/Schulungskonzept, Jahresplan. -- **Vorlage:** R05; VA-12 -- **Ressourcen:** ISB, gering–mittel; einmalig, jährliche Fortschreibung. -- **AL-Filter:** AL2, AL3 - -### 2.1.3-S2 — [SOLL] -**Anforderung:** Zielgruppen für Schulungs- und Sensibilisierungsmaßnahmen sind identifiziert und im Konzept berücksichtigt. -- **Organisatorisch:** Zielgruppen (Führungskräfte, Administratoren, Beschäftigte mit Kundennetzzugang, Fertigung) mit spezifischen Inhalten definieren. -- **Technisch:** Zielgruppen-Zuordnung und differenzierte Lernpfade im LMS abbilden. -- **Typische Nachweise:** Zielgruppenmatrix, rollenspezifische Curricula. -- **Vorlage:** R05; VA-12 -- **Ressourcen:** ISB, gering. -- **AL-Filter:** AL2, AL3 - -### 2.1.3-S3 — [SOLL] -**Anforderung:** Das Konzept ist durch die verantwortliche Leitung genehmigt. -- **Organisatorisch:** Formale Freigabe des Awareness-Konzepts durch die Leitung einholen und dokumentieren. -- **Technisch:** Freigabevermerk/Signatur im DMS. -- **Typische Nachweise:** Freigabeprotokoll/Managementunterschrift. -- **Vorlage:** R05; VA-12 -- **Ressourcen:** Leitung + ISB, gering. -- **AL-Filter:** AL2, AL3 - -### 2.1.3-S4 — [SOLL] -**Anforderung:** Schulungs- und Sensibilisierungsmaßnahmen werden regelmäßig und anlassbezogen durchgeführt. -- **Organisatorisch:** Jahresturnus plus anlassbezogene Maßnahmen (z. B. nach Vorfällen, neuen Bedrohungen) festlegen. -- **Technisch:** Kampagnen (z. B. Phishing-Simulation) und Turnusschulungen über die Awareness-Plattform steuern. -- **Typische Nachweise:** Durchführungsnachweise, Kampagnenauswertungen. -- **Vorlage:** R05; VA-12 -- **Ressourcen:** ISB, mittel; laufend. -- **AL-Filter:** AL2, AL3 - -### 2.1.3-S5 — [SOLL] -**Anforderung:** Die Teilnahme an Schulungs- und Sensibilisierungsmaßnahmen wird dokumentiert. -- **Organisatorisch:** Teilnahmepflicht und Nachverfolgung nicht abgeschlossener Schulungen regeln. -- **Technisch:** Automatische Teilnahme-/Abschlussdokumentation im LMS mit Reporting. -- **Typische Nachweise:** Teilnahmelisten/Abschlussberichte, Quotenauswertung. -- **Vorlage:** R05; VA-12 -- **Ressourcen:** ISB/HR, gering. -- **AL-Filter:** AL2, AL3 - -### 2.1.3-S6 — [SOLL] -**Anforderung:** Ansprechpartner für Informationssicherheit sind den Beschäftigten bekannt. -- **Organisatorisch:** ISB/Kontaktwege in Onboarding, Intranet und Schulungen kommunizieren. -- **Technisch:** Kontaktseite/Meldekanal im Intranet prominent verlinken. -- **Typische Nachweise:** Intranet-Seite, Onboarding-Unterlagen mit Ansprechpartnern. -- **Vorlage:** R05; VA-12 -- **Ressourcen:** ISB, gering. -- **AL-Filter:** AL2, AL3 - -## Control 2.1.4 — Mobiles Arbeiten - -### 2.1.4-M1 — [MUSS] -**Anforderung:** Die Anforderungen an mobiles Arbeiten sind bestimmt und erfüllt; dabei werden die einschlägigen Aspekte berücksichtigt. -- **Organisatorisch:** Richtlinie mobiles Arbeiten/Homeoffice mit Regeln zu Umgebung, Umgang mit Informationen, VPN-Pflicht und Meldewegen erstellen und verbindlich machen. -- **Technisch:** Sichere Fernzugriffe (VPN/ZTNA), verschlüsselte Endgeräte und MDM-gestützte Richtliniendurchsetzung (BL-EUC-01 Endgeräteschutz). -- **Typische Nachweise:** Richtlinie mobiles Arbeiten, VPN-/MDM-Konfiguration, Kenntnisnahmen. -- **Vorlage:** R06 -- **Ressourcen:** ISB + IT, mittel; VPN/MDM ggf. auszubauen — führt zu Aufgabe. -- **AL-Filter:** AL2, AL3 - -### 2.1.4-S1 — [SOLL] -**Anforderung:** Die einschlägigen Aspekte des mobilen Arbeitens werden berücksichtigt. -- **Organisatorisch:** Aspekte wie Clean Desk unterwegs, Nutzung öffentlicher Netze, Umgang mit vertraulichen Gesprächen und Papierdokumenten in der Richtlinie konkretisieren. -- **Technisch:** Automatische Bildschirmsperre, Festplattenverschlüsselung und Netzwerkabsicherung technisch erzwingen (BL-EUC-01). -- **Typische Nachweise:** Richtlinienabschnitt mit Aspektliste, technische Konfigurationsnachweise. -- **Vorlage:** R06 -- **Ressourcen:** ISB + IT, gering. -- **AL-Filter:** AL2, AL3 - -### 2.1.4-S2 — [SOLL] -**Anforderung:** Sensibilisierung der Beschäftigten. -- **Organisatorisch:** Spezifisches Awareness-Modul zu Risiken des mobilen Arbeitens einbinden. -- **Technisch:** Modul im LMS bereitstellen und Teilnahme nachhalten. -- **Typische Nachweise:** Schulungsinhalt „Mobiles Arbeiten", Teilnahmenachweise. -- **Vorlage:** R06; VA-12 -- **Ressourcen:** ISB, gering. -- **AL-Filter:** AL2, AL3 - -### 2.1.4-H1 — [HOCH] -**Anforderung:** Schutzmaßnahmen gegen Abhören und Einsehen sind umgesetzt. (C) -- **Organisatorisch:** Vorgaben für vertrauliche Umgebungen (keine Bearbeitung sensibler Daten in öffentlichen Bereichen, diskrete Gesprächsführung) verbindlich regeln. -- **Technisch:** Blickschutzfilter, automatische Sperre bei Inaktivität, Verzicht auf ungesicherte WLANs; verschlüsselte Kommunikation (BL-EUC-02 Sichtschutz/Session-Lock). -- **Typische Nachweise:** Ausgabe/Nachweis Blickschutzfilter, Richtlinienregelung, Konfiguration Bildschirmsperre. -- **Vorlage:** R06 -- **Ressourcen:** IT, gering; Beschaffung Blickschutzfilter — führt zu Aufgabe. -- **AL-Filter:** AL3 (hoher Schutzbedarf) - -## Control 3.1.1 — Sicherheitszonen und Zutrittsschutz - -### 3.1.1-M1 — [MUSS] -**Anforderung:** Ein Sicherheitszonenkonzept einschließlich zugehöriger Schutzmaßnahmen auf Basis der Anforderungen an die Handhabung von Informationswerten ist vorhanden. -- **Organisatorisch:** Zonenmodell (z. B. öffentlich, intern, geschützt, hochsicher) mit Schutzanforderungen je Zone definieren und Standorte/Räume zuordnen. -- **Technisch:** Zutrittskontrollsystem, Zonenpläne und bauliche/technische Maßnahmen (Türen, Schließanlage, Einbruchmeldeanlage) je Zone abbilden (BL-PHY-01 Zonenmodell). -- **Typische Nachweise:** Sicherheitszonenkonzept, Zonen-/Raumplan, Maßnahmenzuordnung je Zone. -- **Vorlage:** R07 -- **Ressourcen:** ISB + Facility, mittel; bauliche Maßnahmen ggf. investiv — führt zu Aufgabe. -- **AL-Filter:** AL2, AL3 - -### 3.1.1-M2 — [MUSS] -**Anforderung:** Die definierten Schutzmaßnahmen sind umgesetzt. -- **Organisatorisch:** Umsetzungsstand je Zone/Standort prüfen und Restmaßnahmen nachverfolgen. -- **Technisch:** Zutrittskontrolle, Schließanlage, EMA/Videoüberwachung gemäß Konzept in Betrieb; Wirksamkeit prüfen. -- **Typische Nachweise:** Umsetzungsnachweise (Fotos, Abnahmen), Konfiguration Zutrittskontrolle, Begehungsprotokoll. -- **Vorlage:** R07 -- **Ressourcen:** Facility + IT, mittel. -- **AL-Filter:** AL2, AL3 - -### 3.1.1-M3 — [MUSS] -**Anforderung:** Der Verhaltenskodex für Sicherheitszonen ist allen beteiligten Personen bekannt. -- **Organisatorisch:** Verhaltensregeln je Zone (Zutritt, Begleitung, Foto-/Geräteverbot) dokumentieren und kommunizieren; Aushänge an Zonenübergängen. -- **Technisch:** Kodex im Intranet bereitstellen; Kenntnisnahme über Portal erfassen. -- **Typische Nachweise:** Verhaltenskodex, Aushänge, Kenntnisnahmen. -- **Vorlage:** R07 -- **Ressourcen:** ISB + Facility, gering. -- **AL-Filter:** AL2, AL3 - -### 3.1.1-S1 — [SOLL] -**Anforderung:** Verfahren für die Vergabe und den Entzug von Zutrittsrechten sind etabliert. -- **Organisatorisch:** Antrags-, Genehmigungs- und Entzugsprozess für Zutrittsrechte (inkl. Deprovisionierung bei Austritt) definieren. -- **Technisch:** Zutrittsrechte im Zutrittskontrollsystem rollenbasiert vergeben; Entzug an HR-Austrittsprozess koppeln (BL-PHY-02 Zutrittsberechtigungen). -- **Typische Nachweise:** Verfahrensbeschreibung, Zutrittsrechteanträge, Berechtigungsliste. -- **Vorlage:** R07; VA-17 -- **Ressourcen:** Facility + HR, gering–mittel. -- **AL-Filter:** AL2, AL3 - -### 3.1.1-S2 — [SOLL] -**Anforderung:** Richtlinien für das Besuchermanagement (Registrierung, Begleitung) sind definiert. -- **Organisatorisch:** Besucherrichtlinie mit Anmeldung, Ausweispflicht, Begleitung und Belehrung festlegen. -- **Technisch:** Besuchermanagement-System/Besucherbuch mit Ein-/Ausgangserfassung und Badge-Vergabe. -- **Typische Nachweise:** Besucherrichtlinie, Besucherprotokolle, Besucherausweise. -- **Vorlage:** R07; VA-17 -- **Ressourcen:** Empfang/Facility, gering. -- **AL-Filter:** AL2, AL3 - -### 3.1.1-S3 — [SOLL] -**Anforderung:** Richtlinien für das Mitführen und Nutzen mobiler IT-Geräte und Datenträger sind definiert und umgesetzt. -- **Organisatorisch:** Regeln zu Registrierung, Kennzeichnung und Nutzung mitgeführter Geräte/Datenträger in sensiblen Zonen festlegen. -- **Technisch:** Kennzeichnungs-/Registrierungssystem; ggf. technische Sperren (Portkontrolle) in Hochsicherheitszonen. -- **Typische Nachweise:** Richtlinie, Geräteregister, Kennzeichnungsnachweise. -- **Vorlage:** R07; VA-17 -- **Ressourcen:** ISB + Facility, gering. -- **AL-Filter:** AL2, AL3 - -### 3.1.1-S4 — [SOLL] -**Anforderung:** Netzwerk-/Infrastrukturkomponenten (eigene oder Kundennetze) sind gegen unbefugten Zugriff geschützt. -- **Organisatorisch:** Verantwortlichkeiten und Zutrittsregeln für Technik-/Verteilerräume festlegen. -- **Technisch:** Verschließbare Verteiler/Serverräume, Zutrittsprotokollierung, physische Sicherung von Netzkomponenten (BL-PHY-03 Technikräume). -- **Typische Nachweise:** Zutrittsprotokolle Technikräume, Fotonachweis Absicherung, Schließplan. -- **Vorlage:** R07; VA-17 -- **Ressourcen:** Facility + IT, gering–mittel. -- **AL-Filter:** AL2, AL3 - -### 3.1.1-S5 — [SOLL] -**Anforderung:** Externe Liegenschaften zur Speicherung/Verarbeitung von Informationswerten sind im Zonenkonzept berücksichtigt. -- **Organisatorisch:** Externe Standorte (Lager, Werkstätten, Teststrecken, RZ) erfassen und ins Zonenkonzept einordnen; vertragliche Sicherheitsanforderungen prüfen. -- **Technisch:** Zonen-/Schutzanforderungen auf externe Liegenschaften übertragen und deren Umsetzung nachweisen. -- **Typische Nachweise:** Liste externer Liegenschaften, Zonen-Zuordnung, Nachweise externer Schutzmaßnahmen. -- **Vorlage:** R07; VA-17 -- **Ressourcen:** ISB + Facility, gering. -- **AL-Filter:** AL2, AL3 - -### 3.1.1-H1 — [HOCH] -**Anforderung:** Schutzmaßnahmen gegen einfaches Abhören und Einsehen sind umgesetzt. (C) -- **Organisatorisch:** Sensible Besprechungs-/Arbeitsräume ausweisen und Nutzungsregeln (kein Einsehen von außen, keine unbefugten Aufzeichnungen) festlegen. -- **Technisch:** Sichtschutz (Folien/Jalousien), Schallschutz, ggf. Abschirmung; kontrollierter Zutritt zu sensiblen Räumen (BL-PHY-04 Abhör-/Sichtschutz). -- **Typische Nachweise:** Raumkonzept sensibler Räume, Nachweis Sicht-/Schallschutzmaßnahmen. -- **Vorlage:** R07 -- **Ressourcen:** Facility, mittel; bauliche Maßnahmen ggf. investiv — führt zu Aufgabe. -- **AL-Filter:** AL3 (hoher Schutzbedarf) - -## Control 3.1.4 — Mobile IT-Geräte und Datenträger - -### 3.1.4-M1 — [MUSS] -**Anforderung:** Die Anforderungen an mobile IT-Geräte und mobile Datenträger sind bestimmt und erfüllt; dabei werden die einschlägigen Aspekte berücksichtigt. -- **Organisatorisch:** Richtlinie zu mobilen Geräten/Datenträgern (zugelassene Geräte, Nutzung, Aufbewahrung, Verlust-Meldung, Rückgabe) festlegen. -- **Technisch:** Zentrale Verwaltung über MDM/UEM mit erzwungenen Sicherheitsprofilen; Kontrolle des Wechseldatenträgereinsatzes (BL-EUC-01 Endgeräteschutz). -- **Typische Nachweise:** Richtlinie mobile Geräte/Datenträger, MDM-Richtlinien, Kenntnisnahmen. -- **Vorlage:** R06 -- **Ressourcen:** IT + ISB, mittel; MDM/UEM ggf. zu beschaffen/ausbauen — führt zu Aufgabe. -- **AL-Filter:** AL2, AL3 - -### 3.1.4-S1 — [SOLL] -**Anforderung:** Registrierung der IT-Geräte. -- **Organisatorisch:** Verbindliche Registrierung mobiler Geräte im Bestand (Zuordnung Nutzer/Gerät) vor Ausgabe. -- **Technisch:** Inventarisierung über MDM/CMDB mit eindeutiger Geräte-ID und Statuspflege. -- **Typische Nachweise:** Geräteinventar/CMDB-Auszug, Übergabeprotokolle. -- **Vorlage:** R06 -- **Ressourcen:** IT, gering. -- **AL-Filter:** AL2, AL3 - -### 3.1.4-H1 — [HOCH] -**Anforderung:** Generelle Verschlüsselung mobiler Datenträger bzw. der gespeicherten Informationswerte; wo technisch nicht machbar, gleichwertige Maßnahmen. (C, I) -- **Organisatorisch:** Verschlüsselungspflicht für mobile Geräte/Datenträger verbindlich festlegen; Ausnahmen mit gleichwertigen Ersatzmaßnahmen dokumentieren. -- **Technisch:** Full-Disk-Encryption (z. B. BitLocker/FileVault) und Verschlüsselung von Wechseldatenträgern per MDM erzwingen; zentrales Schlüssel-/Recovery-Management (BL-CRY-02 Datenträgerverschlüsselung). -- **Typische Nachweise:** Verschlüsselungsrichtlinie, MDM-Compliance-Report (Encryption-Status), Ausnahmedokumentation. -- **Vorlage:** R06 -- **Ressourcen:** IT, gering–mittel; über MDM steuerbar. -- **AL-Filter:** AL3 (hoher Schutzbedarf) - -## Control 4.1.1 — Identifikationsmittel - -### 4.1.1-M1 — [MUSS] -**Anforderung:** Die Anforderungen an den Umgang mit Identifikationsmitteln über den gesamten Lebenszyklus sind bestimmt und erfüllt; dabei werden die einschlägigen Aspekte berücksichtigt. -- **Organisatorisch:** Lebenszyklus von Identifikationsmitteln (Ausweise, Token, Schlüssel, Zertifikate) von Ausgabe über Nutzung bis Rückgabe/Sperrung regeln; Verantwortlichkeiten festlegen. -- **Technisch:** Zentrale Verwaltung von Ausweisen/Token/Zertifikaten mit Statusführung; Kopplung an Zutritts-/IAM-System (BL-IAM-06 Identifikationsmittel). -- **Typische Nachweise:** Richtlinie/Verfahren Identifikationsmittel, Ausgabe-/Rückgabeprotokolle, Bestandsführung. -- **Vorlage:** R08 -- **Ressourcen:** IT + Facility, mittel. -- **AL-Filter:** AL2, AL3 - -### 4.1.1-S1 — [SOLL] -**Anforderung:** Identifikationsmittel können nur unter kontrollierten Bedingungen erstellt werden. -- **Organisatorisch:** Erstellung von Ausweisen/Token an autorisierte Stellen und dokumentierte Freigaben binden (Vier-Augen-Prinzip bei sensiblen Mitteln). -- **Technisch:** Zugriff auf Ausweisdrucker/Token-Personalisierung und Zertifikats-CA beschränken und protokollieren (BL-IAM-06). -- **Typische Nachweise:** Berechtigungsnachweis Erstellungssysteme, Erstellungsprotokolle, Freigaben. -- **Vorlage:** R08; VA-03 -- **Ressourcen:** IT, gering. -- **AL-Filter:** AL2, AL3 - -### 4.1.1-H1 — [HOCH] -**Anforderung:** Eine Strategie zur Sperrung oder Ungültigmachung von Identifikationsmitteln im Verlustfall ist vorbereitet und soweit möglich umgesetzt. (C, I, A) -- **Organisatorisch:** Verlust-/Sperrprozess mit definierten Meldewegen und Reaktionszeiten festlegen; Verantwortliche und Erreichbarkeit (auch außerhalb Geschäftszeiten) benennen. -- **Technisch:** Sofortige Sperrung von Ausweisen/Token im Zutritts-/IAM-System, Zertifikatssperrung (CRL/OCSP); Remote-Wipe für Geräte-gebundene Mittel (BL-IAM-06). -- **Typische Nachweise:** Sperrprozess-Beschreibung, dokumentierte Sperrvorgänge, CRL-/Sperrnachweise. -- **Vorlage:** R08 -- **Ressourcen:** IT, gering–mittel. -- **AL-Filter:** AL3 (hoher Schutzbedarf) - -## Control 4.1.2 — Benutzerauthentifizierung - -### 4.1.2-M1 — [MUSS] -**Anforderung:** Die Verfahren zur Benutzerauthentifizierung sind auf Basis einer Risikobewertung ausgewählt; mögliche Angriffsszenarien wurden berücksichtigt. -- **Organisatorisch:** Authentifizierungsverfahren je System risikobasiert festlegen (Internet-Exponiertheit, Schutzbedarf); Auswahl dokumentieren. -- **Technisch:** Risikoabhängige Zuordnung von Verfahren (Passwort, MFA, zertifikatsbasiert) in der IAM-Architektur; besonders für extern erreichbare Dienste MFA vorsehen (BL-IAM-02 MFA). -- **Typische Nachweise:** Risikobewertung Authentifizierung, Zuordnung Verfahren je System. -- **Vorlage:** R08; VA-09 -- **Ressourcen:** ISB + IT, mittel. -- **AL-Filter:** AL2, AL3 - -### 4.1.2-M2 — [MUSS] -**Anforderung:** Verfahren zur Benutzerauthentifizierung nach dem Stand der Technik werden angewandt. -- **Organisatorisch:** Mindeststandards für Authentifizierung (starke Passwörter, MFA für kritische/exponierte Zugänge) verbindlich vorgeben. -- **Technisch:** Zentrale Authentifizierung (IdP/SSO) mit MFA; Passwortrichtlinie technisch erzwingen (BL-IAM-01 Passwort, BL-IAM-02 MFA). -- **Typische Nachweise:** IdP-/MFA-Konfiguration, Passwortrichtlinien-Konfiguration, Systemübersicht mit Verfahren. -- **Vorlage:** R08 -- **Ressourcen:** IT, mittel; MFA-Ausbau ggf. — führt zu Aufgabe. -- **AL-Filter:** AL2, AL3 - -### 4.1.2-S1 — [SOLL] -**Anforderung:** Die Authentifizierungsverfahren sind auf Basis der geschäftlichen und sicherheitsrelevanten Anforderungen definiert und umgesetzt. -- **Organisatorisch:** Anforderungen aus Fachbereichen und Sicherheit je Anwendung abstimmen und Zielverfahren festlegen. -- **Technisch:** Verfahren im IdP/Anwendungsstack konfigurieren und rollout-seitig durchsetzen. -- **Typische Nachweise:** Konzept Authentifizierungsverfahren, Konfigurationsnachweise. -- **Vorlage:** R08 -- **Ressourcen:** IT, gering–mittel. -- **AL-Filter:** AL2, AL3 - -### 4.1.2-S2 — [SOLL] -**Anforderung:** Benutzer werden mindestens durch starke Passwörter nach bewährten und anerkannten Praktiken authentifiziert. -- **Organisatorisch:** Passwortrichtlinie (Länge, Komplexität/Passphrasen, Sperrung kompromittierter Passwörter) gemäß anerkannter Praxis festlegen. -- **Technisch:** Richtlinie zentral erzwingen (Directory/IdP), Sperrlisten für kompromittierte Passwörter, keine erzwungenen periodischen Wechsel ohne Anlass (BL-IAM-01 Passwort). -- **Typische Nachweise:** Passwortrichtlinie, Directory-/IdP-Konfiguration. -- **Vorlage:** R08 -- **Ressourcen:** IT, gering. -- **AL-Filter:** AL2, AL3 - -### 4.1.2-S3 — [SOLL] -**Anforderung:** Für privilegierte Benutzerkonten werden höherwertige Verfahren genutzt (z. B. PAM, Zwei-Faktor-Authentifizierung). -- **Organisatorisch:** MFA-Pflicht und PAM-Nutzung für administrative/privilegierte Konten festlegen. -- **Technisch:** Privileged-Access-Management mit Session-Kontrolle und obligatorischer MFA für Admin-Zugänge (BL-IAM-05 Privileged Access). -- **Typische Nachweise:** PAM-Konfiguration, MFA-Nachweis Admin-Konten, Liste privilegierter Konten. -- **Vorlage:** R08 -- **Ressourcen:** IT, mittel; PAM ggf. zu beschaffen — führt zu Aufgabe. -- **AL-Filter:** AL2, AL3 - -### 4.1.2-H1 — [HOCH] -**Anforderung:** Authentifizierung und Zugangskontrolle sind durch ergänzende Maßnahmen verstärkt (z. B. Zugriffsüberwachung, starke Authentifizierung, automatische Abmeldung, Sperre bei Inaktivität, Brute-Force-Prävention). (C, I, A) -- **Organisatorisch:** Risikobasiert ergänzende Schutzmaßnahmen je System festlegen und deren Wirksamkeit prüfen. -- **Technisch:** Account-Lockout/Brute-Force-Schutz, Session-Timeout und automatische Abmeldung, kontinuierliches Zugriffs-/Anomaliemonitoring (SIEM) (BL-IAM-02, BL-IAM-05). -- **Typische Nachweise:** Konfiguration Lockout/Session-Timeout, Monitoring-/SIEM-Nachweise. -- **Vorlage:** R08 -- **Ressourcen:** IT, mittel. -- **AL-Filter:** AL3 (hoher Schutzbedarf) - -### 4.1.2-V1 — [SEHR HOCH] -**Anforderung:** Vor dem Zugriff auf Daten mit sehr hohem Schutzbedarf werden Benutzer mittels starker Authentifizierung (z. B. Zwei-Faktor) nach dem Stand der Technik authentifiziert. (C, I) -- **Organisatorisch:** Für Zugriffe auf sehr hoch schutzbedürftige Daten verbindliche Starke-Authentifizierung-Pflicht festlegen. -- **Technisch:** Phishing-resistente MFA (z. B. FIDO2/Zertifikate) für den Zugang zu sehr hoch klassifizierten Daten erzwingen (BL-IAM-02 MFA). -- **Typische Nachweise:** MFA-Enforcement-Konfiguration für Zielsysteme, Zugriffsprotokolle. -- **Vorlage:** R08 -- **Ressourcen:** IT, mittel. -- **AL-Filter:** AL3 (sehr hoher Schutzbedarf) - -## Control 4.1.3 — Benutzerkonten - -### 4.1.3-M1 — [MUSS] -**Anforderung:** Das Erstellen, Ändern und Löschen von Benutzerkonten wird durchgeführt. -- **Organisatorisch:** Joiner-Mover-Leaver-Prozess mit Verantwortlichkeiten und Auslösern (HR-Events) definieren. -- **Technisch:** Kontenlebenszyklus über IAM/Provisioning möglichst automatisiert an HR-System koppeln (BL-IAM-03 Kontenlebenszyklus). -- **Typische Nachweise:** Prozessbeschreibung JML, Provisioning-Logs, Beispiel-Tickets. -- **Vorlage:** R08; VA-03 -- **Ressourcen:** IT + HR, mittel. -- **AL-Filter:** AL2, AL3 - -### 4.1.3-M2 — [MUSS] -**Anforderung:** Eindeutige und personalisierte Benutzerkonten werden verwendet. -- **Organisatorisch:** Grundsatz personalisierter Konten festlegen; Ausnahmen (Sammelkonten) nur geregelt zulassen. -- **Technisch:** Eindeutige Namenskonvention und ID-Vergabe im Directory; keine geteilten personenbezogenen Logins. -- **Typische Nachweise:** Namenskonvention, Kontenauswertung Directory. -- **Vorlage:** R08 -- **Ressourcen:** IT, gering. -- **AL-Filter:** AL2, AL3 - -### 4.1.3-M3 — [MUSS] -**Anforderung:** Die Nutzung von Sammelkonten ist geregelt (z. B. beschränkt auf Fälle, in denen Nachvollziehbarkeit verzichtbar ist). -- **Organisatorisch:** Zulässige Anwendungsfälle, Genehmigung und Verantwortliche für Sammelkonten dokumentieren. -- **Technisch:** Sammelkonten inventarisieren, Zugriff einschränken und, wo möglich, ergänzend protokollieren. -- **Typische Nachweise:** Regelung Sammelkonten, Liste genehmigter Sammelkonten. -- **Vorlage:** R08 -- **Ressourcen:** IT + ISB, gering. -- **AL-Filter:** AL2, AL3 - -### 4.1.3-M4 — [MUSS] -**Anforderung:** Benutzerkonten werden unmittelbar nach dem Ausscheiden des Nutzers deaktiviert (z. B. bei Vertragsende). -- **Organisatorisch:** Austrittsprozess mit sofortiger Kontensperrung und definierter Frist verbindlich festlegen. -- **Technisch:** Automatische Deaktivierung durch HR-getriggertes Deprovisioning im IAM (BL-IAM-03 Kontenlebenszyklus). -- **Typische Nachweise:** Deaktivierungsnachweise, Austritts-/Deprovisioning-Logs, Fristdefinition. -- **Vorlage:** R08 -- **Ressourcen:** IT + HR, gering–mittel. -- **AL-Filter:** AL2, AL3 - -### 4.1.3-M5 — [MUSS] -**Anforderung:** Benutzerkonten werden regelmäßig überprüft. -- **Organisatorisch:** Turnus für Kontenreviews (Rezertifizierung) mit Verantwortlichen festlegen. -- **Technisch:** Reports über aktive/inaktive/verwaiste Konten aus IAM/Directory; ggf. Recertification-Workflow (BL-IAM-03). -- **Typische Nachweise:** Review-Protokolle, Reports verwaister Konten, Rezertifizierungsnachweise. -- **Vorlage:** R08 -- **Ressourcen:** IT + Fachbereiche, gering–mittel; wiederkehrend. -- **AL-Filter:** AL2, AL3 - -### 4.1.3-M6 — [MUSS] -**Anforderung:** Die Anmeldeinformationen werden dem Nutzer auf sichere Weise bereitgestellt. -- **Organisatorisch:** Sicheren Übergabeprozess für Erstzugangsdaten definieren (getrennte Kanäle, erzwungener Wechsel bei Erstanmeldung). -- **Technisch:** Initialpasswörter über sichere Kanäle, Einmalpasswörter/Aktivierungslinks, erzwungener Passwortwechsel bei Erstanmeldung (BL-IAM-01 Passwort). -- **Typische Nachweise:** Prozessbeschreibung Erstzugang, Konfiguration erzwungener Wechsel. -- **Vorlage:** R08 -- **Ressourcen:** IT, gering. -- **AL-Filter:** AL2, AL3 - -### 4.1.3-M7 — [MUSS] -**Anforderung:** Eine Richtlinie zum Umgang mit Anmeldeinformationen ist definiert und umgesetzt; dabei werden die einschlägigen Aspekte berücksichtigt. -- **Organisatorisch:** Richtlinie zum Umgang mit Credentials (Geheimhaltung, keine Weitergabe, Umgang bei Verdacht auf Kompromittierung) erstellen und kommunizieren. -- **Technisch:** Bereitstellung eines Passwort-Managers, Vorgaben zu Speicherung/Nutzung technisch unterstützen (BL-IAM-01). -- **Typische Nachweise:** Credential-Richtlinie, Kenntnisnahmen, Bereitstellung Passwort-Manager. -- **Vorlage:** R08 -- **Ressourcen:** ISB + IT, gering. -- **AL-Filter:** AL2, AL3 - -### 4.1.3-S1 — [SOLL] -**Anforderung:** Ein Basiskonto mit minimalen Zugriffsrechten und Funktionalitäten existiert und wird genutzt. -- **Organisatorisch:** Standard-/Basisprofil mit Minimalrechten als Ausgangsbasis für neue Konten festlegen. -- **Technisch:** Standardrolle mit minimalen Rechten im IAM als Default zuweisen (Least Privilege, BL-IAM-04 Rollenmodell). -- **Typische Nachweise:** Definition Basiskonto/-rolle, Rollenzuordnung im IAM. -- **Vorlage:** R08 -- **Ressourcen:** IT, gering. -- **AL-Filter:** AL2, AL3 - -### 4.1.3-S2 — [SOLL] -**Anforderung:** Vom Hersteller vorkonfigurierte Standardkonten und -passwörter sind deaktiviert (z. B. Sperren oder Passwortänderung). -- **Organisatorisch:** Hardening-Vorgabe zum Umgang mit Default-Konten bei Inbetriebnahme festlegen. -- **Technisch:** Default-Accounts deaktivieren/umbenennen und Default-Passwörter ändern; über Hardening-Baseline prüfen (BL-OPS-01 Hardening). -- **Typische Nachweise:** Hardening-Checkliste, Nachweis deaktivierter Default-Konten. -- **Vorlage:** R08 -- **Ressourcen:** IT, gering. -- **AL-Filter:** AL2, AL3 - -### 4.1.3-S3 — [SOLL] -**Anforderung:** Benutzerkonten werden durch die verantwortliche Stelle erstellt oder autorisiert. -- **Organisatorisch:** Zuständige Stelle für Kontenerstellung/-autorisierung benennen. -- **Technisch:** Kontenerstellung an autorisierte Rollen im IAM binden und protokollieren. -- **Typische Nachweise:** Rollen-/Verantwortlichkeitsdefinition, Erstellungsprotokolle. -- **Vorlage:** R08 -- **Ressourcen:** IT, gering. -- **AL-Filter:** AL2, AL3 - -### 4.1.3-S4 — [SOLL] -**Anforderung:** Das Erstellen von Benutzerkonten unterliegt einem Genehmigungsprozess (Vier-Augen-Prinzip). -- **Organisatorisch:** Genehmigungspflicht mit Vier-Augen-Prinzip für Kontenerstellung festlegen. -- **Technisch:** Approval-Workflow im IAM/ITSM mit dokumentierter Freigabe. -- **Typische Nachweise:** Workflow-Konfiguration, Genehmigungsnachweise/Tickets. -- **Vorlage:** R08 -- **Ressourcen:** IT, gering. -- **AL-Filter:** AL2, AL3 - -### 4.1.3-S5 — [SOLL] -**Anforderung:** Benutzerkonten von Dienstleistern werden nach Abschluss ihrer Aufgabe deaktiviert. -- **Organisatorisch:** Befristung und Verantwortliche für Dienstleisterkonten festlegen; Ende an Auftrags-/Vertragsende koppeln. -- **Technisch:** Ablaufdatum (Account-Expiry) für externe Konten im IAM setzen und überwachen (BL-IAM-03). -- **Typische Nachweise:** Liste Dienstleisterkonten mit Ablaufdatum, Deaktivierungsnachweise. -- **Vorlage:** R08 -- **Ressourcen:** IT, gering. -- **AL-Filter:** AL2, AL3 - -### 4.1.3-S6 — [SOLL] -**Anforderung:** Fristen für das Deaktivieren und Löschen von Benutzerkonten sind definiert. -- **Organisatorisch:** Fristen für Deaktivierung und endgültige Löschung (unter Beachtung von Aufbewahrungspflichten) definieren. -- **Technisch:** Fristen im IAM/Prozess automatisiert überwachen und umsetzen. -- **Typische Nachweise:** Fristenregelung, Nachweis fristgerechter Löschungen. -- **Vorlage:** R08 -- **Ressourcen:** IT + ISB, gering. -- **AL-Filter:** AL2, AL3 - -### 4.1.3-S7 — [SOLL] -**Anforderung:** Die Verwendung von Standardpasswörtern wird technisch verhindert. -- **Organisatorisch:** Vorgabe, dass Default-/triviale Passwörter unzulässig sind. -- **Technisch:** Erzwungener Wechsel bei Erstanmeldung, Sperrlisten trivialer Passwörter im IdP (BL-IAM-01). -- **Typische Nachweise:** IdP-Konfiguration (Sperrliste, Erstwechsel). -- **Vorlage:** R08 -- **Ressourcen:** IT, gering. -- **AL-Filter:** AL2, AL3 - -### 4.1.3-S8 — [SOLL] -**Anforderung:** Bei starker Authentifizierung ist die Nutzung des Mediums (z. B. Besitzfaktor) sicher. -- **Organisatorisch:** Regeln zur Ausgabe, Nutzung und Rückgabe von Token/Besitzfaktoren festlegen. -- **Technisch:** Sichere Token (Hardware-/FIDO2), PIN-Schutz und sichere Registrierung/Sperrung (BL-IAM-02 MFA). -- **Typische Nachweise:** Token-Ausgaberegelung, Konfiguration MFA-Registrierung/Sperrung. -- **Vorlage:** R08 -- **Ressourcen:** IT, gering–mittel. -- **AL-Filter:** AL2, AL3 - -### 4.1.3-S9 — [SOLL] -**Anforderung:** Benutzerkonten werden regelmäßig überprüft; dies umfasst auch Konten in IT-Systemen von Kunden. -- **Organisatorisch:** Kontenreviews auf Kundensysteme ausdehnen; Verantwortliche und Turnus je Kundenkontext festlegen. -- **Technisch:** Kontenlisten aus Kundensystemen periodisch abgleichen und rezertifizieren. -- **Typische Nachweise:** Review-Protokolle inkl. Kundensysteme, Rezertifizierungsnachweise. -- **Vorlage:** R08 -- **Ressourcen:** IT + Fachbereiche, mittel; wiederkehrend. -- **AL-Filter:** AL2, AL3 - -### 4.1.3-S10 — [SOLL] -**Anforderung:** Interaktive Anmeldung für Dienstkonten (technische Konten) wird technisch verhindert. -- **Organisatorisch:** Grundsatz „keine interaktive Anmeldung für Servicekonten" festlegen und Servicekonten inventarisieren. -- **Technisch:** Interaktive Logins per Richtlinie (z. B. Deny-Logon-Policy) unterbinden; Servicekonten mit minimalen Rechten und Managed/gMSA nutzen (BL-IAM-04). -- **Typische Nachweise:** Servicekonten-Inventar, Richtlinienkonfiguration (Deny interactive logon). -- **Vorlage:** R08 -- **Ressourcen:** IT, gering. -- **AL-Filter:** AL2, AL3 - -## Control 4.2.1 — Verwaltung von Zugriffsrechten - -### 4.2.1-M1 — [MUSS] -**Anforderung:** Die Anforderungen an die Verwaltung von Zugriffsrechten (Autorisierung) sind bestimmt und erfüllt; dabei werden die einschlägigen Aspekte berücksichtigt. -- **Organisatorisch:** Berechtigungskonzept mit Antrags-, Genehmigungs-, Änderungs- und Entzugsprozess sowie Least-Privilege-Grundsatz definieren. -- **Technisch:** Zentrale Rechteverwaltung über IAM; rollenbasierte Vergabe und Nachverfolgbarkeit (BL-IAM-04 Rollenmodell). -- **Typische Nachweise:** Berechtigungskonzept, Antrags-/Genehmigungsnachweise, Rechteübersicht. -- **Vorlage:** R08; VA-03 -- **Ressourcen:** ISB + IT, mittel. -- **AL-Filter:** AL2, AL3 - -### 4.2.1-M2 — [MUSS] -**Anforderung:** Die für normale, privilegierte und technische Konten vergebenen Zugriffsrechte werden regelmäßig überprüft, auch in IT-Systemen von Kunden. -- **Organisatorisch:** Rezertifizierung der Zugriffsrechte in festem Turnus mit Fachverantwortlichen; Kundensysteme einschließen. -- **Technisch:** Access-Recertification-Workflow im IAM mit Reports je Kontotyp (BL-IAM-04, BL-IAM-05 Privileged Access). -- **Typische Nachweise:** Rezertifizierungsprotokolle, Rechte-Reports (inkl. privilegiert/technisch/Kunde). -- **Vorlage:** R08; VA-03 -- **Ressourcen:** IT + Fachbereiche, mittel; wiederkehrend. -- **AL-Filter:** AL2, AL3 - -### 4.2.1-S1 — [SOLL] -**Anforderung:** Strategien zur Autorisierung von Zugriffen auf Informationen sind vorbereitet. -- **Organisatorisch:** Autorisierungsstrategie (z. B. RBAC, Need-to-know, Datenklassifizierung als Grundlage) dokumentieren. -- **Technisch:** Strategie in IAM-Rollen-/Policy-Modell überführen. -- **Typische Nachweise:** Autorisierungsstrategie/-konzept. -- **Vorlage:** R08; VA-03 -- **Ressourcen:** ISB + IT, gering. -- **AL-Filter:** AL2, AL3 - -### 4.2.1-S2 — [SOLL] -**Anforderung:** Autorisierungsrollen werden verwendet. -- **Organisatorisch:** Rollenmodell mit definierten Berechtigungsbündeln je Funktion etablieren und pflegen. -- **Technisch:** RBAC im IAM abbilden; Rollen zentral verwalten und zuweisen (BL-IAM-04). -- **Typische Nachweise:** Rollenkatalog, Rollen-Rechte-Matrix. -- **Vorlage:** R08 -- **Ressourcen:** IT, mittel. -- **AL-Filter:** AL2, AL3 - -### 4.2.1-S3 — [SOLL] -**Anforderung:** Rechte werden nach dem Need-to-use-Prinzip und gemäß Rolle und/oder Verantwortungsbereich vergeben. -- **Organisatorisch:** Vergabe strikt am tatsächlichen Bedarf und an der Rolle ausrichten; Sammelberechtigungen vermeiden. -- **Technisch:** Least-Privilege-Rollen im IAM; regelmäßige Bereinigung überschüssiger Rechte. -- **Typische Nachweise:** Rechtevergabe-Nachweise, Bereinigungsprotokolle. -- **Vorlage:** R08 -- **Ressourcen:** IT, gering–mittel. -- **AL-Filter:** AL2, AL3 - -### 4.2.1-S4 — [SOLL] -**Anforderung:** Normale Benutzerkonten erhalten keine privilegierten Zugriffsrechte. -- **Organisatorisch:** Trennung von Standard- und Administrationskonten verbindlich vorschreiben. -- **Technisch:** Getrennte Admin-Konten, Entzug lokaler Adminrechte auf Endgeräten, Just-in-Time-Admin über PAM (BL-IAM-05). -- **Typische Nachweise:** Nachweis getrennter Admin-Konten, Auswertung lokaler Adminrechte. -- **Vorlage:** R08 -- **Ressourcen:** IT, mittel. -- **AL-Filter:** AL2, AL3 - -### 4.2.1-S5 — [SOLL] -**Anforderung:** Die Zugriffsrechte des Nutzers werden nach Änderung seiner Verantwortlichkeiten aktualisiert. -- **Organisatorisch:** Mover-Prozess mit Neubewertung und Entzug nicht mehr benötigter Rechte bei Rollenwechsel definieren. -- **Technisch:** HR-getriggerte Rechteanpassung im IAM; Entzug alter Rollen (BL-IAM-03, BL-IAM-04). -- **Typische Nachweise:** Mover-Prozessbeschreibung, Änderungsnachweise Rechte. -- **Vorlage:** R08 -- **Ressourcen:** IT + HR, gering–mittel. -- **AL-Filter:** AL2, AL3 - -### 4.2.1-H1 — [HOCH] -**Anforderung:** Die Zugriffsrechte werden durch den verantwortlichen internen Information Officer genehmigt. (C, I, A) -- **Organisatorisch:** Genehmigung sensibler Zugriffsrechte durch den zuständigen Informationsverantwortlichen (Dateneigentümer) verbindlich festlegen. -- **Technisch:** Approval-Workflow mit Owner-Freigabe im IAM/ITSM; Genehmigungen revisionssicher protokollieren. -- **Typische Nachweise:** Freigabe-Workflow-Konfiguration, dokumentierte Owner-Genehmigungen. -- **Vorlage:** R08 -- **Ressourcen:** IT + Fachbereiche, gering–mittel. -- **AL-Filter:** AL3 (hoher Schutzbedarf) - -### 4.2.1-V1 — [SEHR HOCH] -**Anforderung:** Informationen werden auf Inhaltsebene (z. B. Dateiebene) verschlüsselt gespeichert, um unbefugten Zugriff (auch privilegierter Nutzer) zu verhindern; wo nicht machbar, gleichwertige Maßnahmen. (C) -- **Organisatorisch:** Für sehr hoch schutzbedürftige Daten Inhalts-/Dateiverschlüsselung mit strikter Schlüsseltrennung von Administratoren vorschreiben; Ausnahmen mit Ersatzmaßnahmen dokumentieren. -- **Technisch:** Datei-/Feldverschlüsselung mit nutzer-/gruppenbezogenem Schlüsselmanagement, sodass privilegierte Nutzer ohne Schlüssel keinen Klartextzugriff haben (BL-CRY-01 Inhaltsverschlüsselung). -- **Typische Nachweise:** Verschlüsselungskonzept, Nachweis Datei-/Inhaltsverschlüsselung, Schlüsselmanagement-Dokumentation. -- **Vorlage:** R08 -- **Ressourcen:** IT + ISB, hoch; Verschlüsselungslösung/Key-Management ggf. zu beschaffen — führt zu Aufgabe. -- **AL-Filter:** AL3 (sehr hoher Schutzbedarf) - -### 4.2.1-V2 — [SEHR HOCH] -**Anforderung:** Bestehende Zugriffsrechte werden in kürzeren Abständen (z. B. quartalsweise) überprüft. (C) -- **Organisatorisch:** Verkürzten Rezertifizierungsturnus (z. B. quartalsweise) für sehr hoch schutzbedürftige Bereiche festlegen. -- **Technisch:** Häufigere, automatisierte Recertification-Kampagnen im IAM mit Reporting (BL-IAM-04). -- **Typische Nachweise:** Quartalsweise Rezertifizierungsprotokolle, IAM-Kampagnenauswertung. -- **Vorlage:** R08 -- **Ressourcen:** IT + Fachbereiche, mittel; wiederkehrend. -- **AL-Filter:** AL3 (sehr hoher Schutzbedarf) - - ---- - -# Kapitel 5 — Kryptographie & Betriebssicherheit - -# C6 – Umsetzungshinweise Kapitel 5 (Betriebssicherheit, Kommunikation, Systementwicklung) - -## Control 5.1.1 — Einsatz von Kryptografie - -### 5.1.1-M1 — [MUSS] -**Anforderung:** Alle eingesetzten kryptografischen Verfahren bieten die im Anwendungsfeld erforderliche Sicherheit nach anerkanntem Industriestandard. -- **Organisatorisch:** Bestand der genutzten Krypto-Verfahren (Verschlüsselung, Signatur, Hash, Protokolle) je Anwendungsfall erheben und gegen aktuelle Empfehlungen (z. B. BSI TR-02102, NIST) abgleichen; veraltete Verfahren (z. B. TLS < 1.2, SHA-1, MD5) außer Betrieb nehmen. -- **Technisch:** Freigegebene Algorithmen und Mindestschlüssellängen zentral als Baseline vorgeben und in Systemkonfigurationen erzwingen (z. B. TLS-Policies, Cipher-Suites, Disk-Encryption). Referenz: BL-CRY-01 (zugelassene Algorithmen/Schlüssellängen), BL-CRY-02 (TLS-Mindeststandard). -- **Typische Nachweise:** Krypto-Katalog/Algorithmenliste mit Freigabestatus, Konfigurationsauszüge (z. B. TLS-Scan), Nachweis Ablösung veralteter Verfahren. -- **Vorlage:** R09; VA-07; BL-CRY-01; BL-CRY-02 -- **Ressourcen:** ISB/IT-Betrieb; ggf. TLS-/Config-Scanner (Beschaffung möglich); gering–mittel. -- **AL-Filter:** AL2 + AL3 - -### 5.1.1-S1 — [SOLL] -**Anforderung:** Ein Konzept für den Einsatz von Kryptografie ist definiert und umgesetzt. -- **Organisatorisch:** Kryptokonzept erstellen (Einsatzzwecke, zugelassene Verfahren, Schlüssellängen, Gültigkeitsdauern, Verantwortlichkeiten, Ausnahmeverfahren) und durch die Leitung freigeben lassen. -- **Technisch:** Konzeptvorgaben in Gerätehärtung, PKI-/Zertifikatsmanagement und Verschlüsselungsprofilen technisch verankern. Referenz: BL-CRY-01, BL-CRY-02. -- **Typische Nachweise:** Freigegebenes Kryptokonzept, Zuordnung Verfahren↔Anwendungsfall, Review-Vermerk. -- **Vorlage:** R09; VA-07; BL-CRY-01 -- **Ressourcen:** ISB + IT-Betrieb; gering. -- **AL-Filter:** AL2 + AL3 - -### 5.1.1-H1 — [HOCH] -**Anforderung:** Anforderungen an die Schlüsselhoheit (insbesondere bei externer Verarbeitung) sind bestimmt und erfüllt. (C, I) -- **Organisatorisch:** Für Daten mit hohem Schutzbedarf festlegen, dass Schlüssel unter eigener Kontrolle verbleiben (kein Zugriff des Dienstleisters); Schlüsselverwaltungsverantwortung und Rückgabe-/Löschprozesse vertraglich regeln. -- **Technisch:** Bring-Your-Own-Key/Hold-Your-Own-Key bzw. dedizierte Key-Management-Lösung oder HSM einsetzen; Schlüsseltrennung von Cloud-Anbieter-Schlüsseln. Referenz: BL-CRY-03 (Schlüsselhoheit/Key-Management). -- **Typische Nachweise:** KMS-/HSM-Konfiguration, Vertragsklausel Schlüsselhoheit, Nachweis getrennter Schlüsselverwaltung. -- **Vorlage:** R09; BL-CRY-03 -- **Ressourcen:** KMS/HSM oder BYOK-Funktion (Beschaffung/Lizenz möglich); mittel. -- **AL-Filter:** AL3 (hoher Schutzbedarf) - -## Control 5.1.2 — Sicherheit bei der Informationsübertragung / Netzdienste - -### 5.1.2-M1 — [MUSS] -**Anforderung:** Die zur Informationsübertragung genutzten Netzdienste sind identifiziert und dokumentiert. -- **Organisatorisch:** Übersicht der Übertragungswege/Netzdienste (E-Mail, VPN, Fileshare, EDI, Webportale, Fernzugriff) erstellen und Verantwortliche zuweisen. -- **Technisch:** Netzdienste-Inventar mit Protokoll, Endpunkten und Schutzbedarf führen; regelmäßig aus Netz-/Firewall-Dokumentation aktualisieren. Referenz: BL-NET-01 (Netzdienste-/Übertragungsinventar). -- **Typische Nachweise:** Netzdienste-Verzeichnis, Datenfluss-/Übertragungsübersicht. -- **Vorlage:** R09; VA-07; BL-NET-01 -- **Ressourcen:** IT-Betrieb; gering. -- **AL-Filter:** AL2 + AL3 - -### 5.1.2-M2 — [MUSS] -**Anforderung:** Richtlinien und Verfahren entsprechend den Klassifizierungsanforderungen für die Nutzung von Netzdiensten sind definiert und umgesetzt. -- **Organisatorisch:** Nutzungsvorgaben je Klassifizierungsstufe festlegen (welcher Dienst/Verschlüsselung für welche Informationsklasse zulässig ist) und kommunizieren. -- **Technisch:** Vorgaben durch Mail-Gateway-Regeln, erzwungene Transportverschlüsselung und Freigabelisten technisch durchsetzen. Referenz: BL-NET-01, BL-CRY-02. -- **Typische Nachweise:** Richtlinie Informationsübertragung, Gateway-/Mailflow-Regeln, Klassifizierungs-Mapping. -- **Vorlage:** R09; VA-07; BL-CRY-02 -- **Ressourcen:** ISB + IT-Betrieb; gering–mittel. -- **AL-Filter:** AL2 + AL3 - -### 5.1.2-M3 — [MUSS] -**Anforderung:** Maßnahmen zum Schutz übertragener Inhalte gegen unbefugten Zugriff sind umgesetzt. -- **Organisatorisch:** Vorgeben, dass schützenswerte Inhalte nur verschlüsselt übertragen werden; Ausnahmen dokumentieren. -- **Technisch:** Transport-/Inhaltsverschlüsselung (TLS, S/MIME, PGP, verschlüsselte Container/Portale) einsetzen; unverschlüsselte Legacy-Protokolle sperren. Referenz: BL-CRY-02, BL-NET-03 (Fernzugriff/VPN). -- **Typische Nachweise:** TLS-/Verschlüsselungsnachweis, verschlüsselter Austauschkanal, Konfigurationsauszug. -- **Vorlage:** R09; BL-CRY-02 -- **Ressourcen:** IT-Betrieb; gering–mittel. -- **AL-Filter:** AL2 + AL3 - -### 5.1.2-S1 — [SOLL] -**Anforderung:** Maßnahmen zur Sicherstellung korrekter Adressierung und korrekter Informationsübertragung sind umgesetzt. -- **Organisatorisch:** Prozesse gegen Fehlversand definieren (4-Augen bei sensiblen Verteilern, Pflege von Verteilerlisten, Sensibilisierung). -- **Technisch:** Maßnahmen wie Autovervollständigungs-Warnungen, Anti-Misdelivery-/DLP-Regeln, Empfängerbestätigung aktivieren. Referenz: BL-NET-01. -- **Typische Nachweise:** DLP-/Mailregeln, Schulungsnachweis, Verteilerpflege-Prozess. -- **Vorlage:** R09; VA-07 -- **Ressourcen:** IT-Betrieb; ggf. DLP-Funktion (Beschaffung möglich); gering. -- **AL-Filter:** AL2 + AL3 - -### 5.1.2-S2 — [SOLL] -**Anforderung:** Elektronischer Datenaustausch erfolgt mittels Inhalts- oder Transportverschlüsselung entsprechend der Klassifizierung. -- **Organisatorisch:** Je Klassifizierungsstufe festlegen, ob Transport- oder Inhaltsverschlüsselung erforderlich ist. -- **Technisch:** TLS-erzwungene Kanäle für interne/Standardübertragung, Inhaltsverschlüsselung (S/MIME, verschlüsselte Archive) für höhere Stufen. Referenz: BL-CRY-01, BL-CRY-02. -- **Typische Nachweise:** Verschlüsselungsmatrix je Klasse, Konfigurationsnachweis. -- **Vorlage:** R09; BL-CRY-02 -- **Ressourcen:** IT-Betrieb; gering. -- **AL-Filter:** AL2 + AL3 - -### 5.1.2-S3 — [SOLL] -**Anforderung:** Fernzugriffsverbindungen zum Netzwerk der Organisation verfügen über angemessene Sicherheitsmerkmale. -- **Organisatorisch:** Fernzugriffsrichtlinie mit Genehmigung, Mehr-Faktor-Pflicht und Nutzungsbedingungen definieren. -- **Technisch:** VPN nach Stand der Technik mit MFA, starker Verschlüsselung, Endpoint-Prüfung und Sitzungsbegrenzung. Referenz: BL-NET-03 (Fernzugriff/VPN), BL-IAM-02 (MFA). -- **Typische Nachweise:** VPN-Konfiguration, MFA-Nachweis, Fernzugriffsrichtlinie. -- **Vorlage:** R09; BL-NET-03; BL-IAM-02 -- **Ressourcen:** IT-Betrieb; gering–mittel. -- **AL-Filter:** AL2 + AL3 - -### 5.1.2-H1 — [HOCH] -**Anforderung:** Informationen werden verschlüsselt übertragen (mindestens Transportverschlüsselung) oder gleichwertig geschützt. (C) -- **Organisatorisch:** Verbindliche Verschlüsselungspflicht für Informationen mit hohem Schutzbedarf festschreiben; unverschlüsselte Ausnahmen nur mit dokumentierter Ersatzmaßnahme. -- **Technisch:** Transportverschlüsselung durchgängig erzwingen (TLS-Enforcement, verschlüsselte Tunnel); Fallback auf Klartext technisch verhindern. Referenz: BL-CRY-02. -- **Typische Nachweise:** TLS-Enforcement-Policy, Scan-Ergebnis ohne Klartextdienste. -- **Vorlage:** R09; BL-CRY-02 -- **Ressourcen:** IT-Betrieb; gering. -- **AL-Filter:** AL3 (hoher Schutzbedarf) - -### 5.1.2-V1 — [SEHR HOCH] -**Anforderung:** Informationen werden inhaltsverschlüsselt übertragen. (C) -- **Organisatorisch:** Für sehr hohen Schutzbedarf Ende-zu-Ende-/Inhaltsverschlüsselung verpflichtend vorschreiben, unabhängig vom Transportweg. -- **Technisch:** Inhaltsverschlüsselung (S/MIME, PGP, verschlüsselte Container mit eigener Schlüsselhoheit) einsetzen; Schlüssel getrennt vom Transportkanal verwalten. Referenz: BL-CRY-01, BL-CRY-03. -- **Typische Nachweise:** Nachweis Ende-zu-Ende-Verschlüsselung, Schlüsselmanagement-Dokumentation. -- **Vorlage:** R09; BL-CRY-03 -- **Ressourcen:** IT-Betrieb; mittel. -- **AL-Filter:** AL3 (sehr hoher Schutzbedarf) - -## Control 5.2.1 — Änderungsmanagement (Change Management) - -### 5.2.1-M1 — [MUSS] -**Anforderung:** Informationssicherheitsanforderungen für Änderungen an Organisation, Geschäftsprozessen und IT-Systemen sind bestimmt und erfüllt. -- **Organisatorisch:** Change-Management-Prozess etablieren, der Sicherheitsbewertung, Freigabe und Dokumentation jeder relevanten Änderung vorsieht. -- **Technisch:** Änderungen über Ticket-/Change-System mit Sicherheitsprüfung und Genehmigungs-Workflow abwickeln. Referenz: BL-OPS-01 (Change-Management). -- **Typische Nachweise:** Change-Records mit Sicherheitsbewertung, Change-Richtlinie, Freigaben. -- **Vorlage:** R10; VA-04; BL-OPS-01 -- **Ressourcen:** IT-Betrieb; ggf. Ticket-/Change-Tool (Beschaffung möglich); gering–mittel. -- **AL-Filter:** AL2 + AL3 - -### 5.2.1-S1 — [SOLL] -**Anforderung:** Ein formales Genehmigungsverfahren ist etabliert. -- **Organisatorisch:** Rollen (Antragsteller, Bewerter, Genehmiger) und Freigabekriterien definieren; ggf. Change Advisory Board. -- **Technisch:** Genehmigungs-Workflow im Change-Tool mit Pflichtfeldern und Freigabestufen abbilden. Referenz: BL-OPS-01. -- **Typische Nachweise:** Genehmigte Changes, Rollen-/Gremienbeschreibung. -- **Vorlage:** R10; VA-04; BL-OPS-01 -- **Ressourcen:** IT-Betrieb; gering. -- **AL-Filter:** AL2 + AL3 - -### 5.2.1-S2 — [SOLL] -**Anforderung:** Die möglichen Auswirkungen von Änderungen auf die Informationssicherheit werden bewertet. -- **Organisatorisch:** Impact-/Risikoanalyse als Pflichtschritt im Change vorsehen (betroffene Assets, Schutzziele). -- **Technisch:** Bewertungsfelder/Checkliste im Change-Record, Verknüpfung mit Asset- und Risikoregister. Referenz: BL-OPS-01. -- **Typische Nachweise:** Impact-Analysen in Change-Records, Bewertungscheckliste. -- **Vorlage:** R10; VA-04 -- **Ressourcen:** IT-Betrieb; gering. -- **AL-Filter:** AL2 + AL3 - -### 5.2.1-S3 — [SOLL] -**Anforderung:** Änderungen mit Auswirkung auf die Informationssicherheit werden geplant und getestet. -- **Organisatorisch:** Planungs- und Testschritte vor Produktivsetzung verbindlich vorschreiben. -- **Technisch:** Tests in getrennter Test-/Staging-Umgebung durchführen und dokumentieren. Referenz: BL-OPS-01, BL-OPS-02 (Umgebungstrennung). -- **Typische Nachweise:** Testprotokolle, Rollout-Plan. -- **Vorlage:** R10; VA-04; BL-OPS-02 -- **Ressourcen:** IT-Betrieb; gering–mittel. -- **AL-Filter:** AL2 + AL3 - -### 5.2.1-S4 — [SOLL] -**Anforderung:** Verfahren zum Rückfall (Fallback) in Fehlerfällen werden berücksichtigt. -- **Organisatorisch:** Für jede relevante Änderung Rollback-/Fallback-Plan fordern. -- **Technisch:** Backups/Snapshots vor Change, dokumentierte Rücksetzschritte. Referenz: BL-OPS-01, BL-OPS-05 (Backup). -- **Typische Nachweise:** Rollback-Plan im Change, Snapshot-/Backup-Nachweis. -- **Vorlage:** R10; VA-04; BL-OPS-05 -- **Ressourcen:** IT-Betrieb; gering. -- **AL-Filter:** AL2 + AL3 - -### 5.2.1-H1 — [HOCH] -**Anforderung:** Die Einhaltung der Informationssicherheitsanforderungen wird während und nach den Änderungen überprüft. (C, I, A) -- **Organisatorisch:** Post-Implementation-Review mit Sicherheitsprüfung verbindlich etablieren. -- **Technisch:** Konfigurations-/Compliance-Checks nach dem Change (z. B. Baseline-Scan, Hardening-Verifikation) durchführen. Referenz: BL-OPS-01. -- **Typische Nachweise:** PIR-Protokolle, Post-Change-Scan-Ergebnisse. -- **Vorlage:** R10; VA-04 -- **Ressourcen:** IT-Betrieb; gering–mittel. -- **AL-Filter:** AL3 (hoher Schutzbedarf) - -## Control 5.2.2 — Trennung von Entwicklungs-, Test- und Produktivumgebungen - -### 5.2.2-M1 — [MUSS] -**Anforderung:** Die IT-Systeme wurden einer Risikobewertung zur Notwendigkeit der Trennung in Entwicklungs-, Test- und Produktivsysteme unterzogen. -- **Organisatorisch:** Systeme identifizieren, bei denen Entwicklung/Test/Produktion getrennt werden muss, und Ergebnis dokumentieren. -- **Technisch:** Zuordnung der Systeme zu Umgebungen im Inventar; Risikobewertung mit Verfahren VA-09 verknüpfen. Referenz: BL-OPS-02 (Umgebungstrennung). -- **Typische Nachweise:** Risikobewertung Umgebungstrennung, System-/Umgebungszuordnung. -- **Vorlage:** R10; BL-OPS-02 -- **Ressourcen:** IT-Betrieb + ISB; gering. -- **AL-Filter:** AL2 + AL3 - -### 5.2.2-M2 — [MUSS] -**Anforderung:** Eine Segmentierung ist auf Basis der Ergebnisse der Risikoanalyse umgesetzt. -- **Organisatorisch:** Trennung organisatorisch absichern (getrennte Berechtigungen, kein Produktivzugriff aus Testkontext). -- **Technisch:** Umgebungen netz-/systemseitig trennen (getrennte Netzsegmente, Instanzen, Zugriffsrechte). Referenz: BL-OPS-02, BL-NET-01 (Segmentierung). -- **Typische Nachweise:** Netz-/Systemtrennungsnachweis, Berechtigungskonzept je Umgebung. -- **Vorlage:** R10; BL-OPS-02; BL-NET-01 -- **Ressourcen:** IT-Betrieb; mittel. -- **AL-Filter:** AL2 + AL3 - -### 5.2.2-S1 — [SOLL] -**Anforderung:** Die Anforderungen an Entwicklungs- und Testumgebungen sind bestimmt und erfüllt. -- **Organisatorisch:** Vorgaben für Dev-/Test-Umgebungen festlegen (Datenherkunft, Zugriff, Löschung, keine Produktivgeheimnisse). -- **Technisch:** Härtung der Testsysteme, anonymisierte Testdaten, getrennte Zugangsdaten. Referenz: BL-OPS-02. -- **Typische Nachweise:** Vorgaben Dev/Test, Nachweis Testdaten-Anonymisierung. -- **Vorlage:** R10; BL-OPS-02 -- **Ressourcen:** IT-Betrieb/Entwicklung; gering–mittel. -- **AL-Filter:** AL2 + AL3 - -## Control 5.2.3 — Schutz vor Schadsoftware - -### 5.2.3-M1 — [MUSS] -**Anforderung:** Anforderungen zum Schutz vor Schadsoftware sind bestimmt. -- **Organisatorisch:** Richtlinie/Vorgaben zum Malware-Schutz für alle Systemtypen (Client, Server, mobile Geräte, OT) festlegen. -- **Technisch:** Schutzbedarf je Systemklasse bestimmen und Schutzmechanismen zuordnen. Referenz: BL-OPS-03 (Malware-Schutz). -- **Typische Nachweise:** Malware-Schutz-Vorgabe, Systemklassen-Zuordnung. -- **Vorlage:** R10; BL-OPS-03 -- **Ressourcen:** ISB + IT-Betrieb; gering. -- **AL-Filter:** AL2 + AL3 - -### 5.2.3-M2 — [MUSS] -**Anforderung:** Technische und organisatorische Maßnahmen zum Schutz vor Schadsoftware sind definiert und umgesetzt. -- **Organisatorisch:** Kombination aus Nutzerverhalten (keine unbekannte Software, Umgang mit Anhängen) und technischen Kontrollen festlegen. -- **Technisch:** Endpoint-Protection/EDR flächendeckend, zentrale Verwaltung, Application-Control. Referenz: BL-OPS-03. -- **Typische Nachweise:** AV/EDR-Deployment-Report, Richtlinie, Konfiguration. -- **Vorlage:** R10; BL-OPS-03 -- **Ressourcen:** Endpoint-Protection/EDR (Beschaffung/Lizenz möglich); mittel. -- **AL-Filter:** AL2 + AL3 - -### 5.2.3-S1 — [SOLL] -**Anforderung:** Unnötige Netzwerkdienste sind deaktiviert. -- **Organisatorisch:** Vorgabe zur Minimierung von Diensten (Härtung) je Systemrolle. -- **Technisch:** Systemhärtung nach Baseline, nicht benötigte Dienste/Ports schließen. Referenz: BL-OPS-03, BL-NET-02 (Dienst-/Portfreigaben). -- **Typische Nachweise:** Härtungsbaseline, Port-/Dienste-Scan. -- **Vorlage:** R10; BL-NET-02 -- **Ressourcen:** IT-Betrieb; gering. -- **AL-Filter:** AL2 + AL3 - -### 5.2.3-S2 — [SOLL] -**Anforderung:** Der Zugriff auf Netzwerkdienste ist durch geeignete Schutzmaßnahmen auf das Notwendige beschränkt. -- **Organisatorisch:** Least-Privilege für Netzdienste vorgeben. -- **Technisch:** Firewall-/ACL-Regeln, Host-Firewalls, Segmentierung. Referenz: BL-NET-02, BL-NET-01. -- **Typische Nachweise:** Firewall-Regelwerk, ACL-Auszug. -- **Vorlage:** R10; BL-NET-02 -- **Ressourcen:** IT-Betrieb; gering–mittel. -- **AL-Filter:** AL2 + AL3 - -### 5.2.3-S3 — [SOLL] -**Anforderung:** Schutzsoftware gegen Schadsoftware ist installiert und wird regelmäßig automatisch aktualisiert. -- **Organisatorisch:** Aktualitäts-/Abdeckungsvorgabe für Schutzsoftware festlegen. -- **Technisch:** Automatische Signatur-/Engine-Updates, zentrales Reporting über Abdeckung und Update-Stand. Referenz: BL-OPS-03. -- **Typische Nachweise:** Update-/Abdeckungsreport, Konfiguration Auto-Update. -- **Vorlage:** R10; BL-OPS-03 -- **Ressourcen:** IT-Betrieb; gering. -- **AL-Filter:** AL2 + AL3 - -### 5.2.3-S4 — [SOLL] -**Anforderung:** Empfangene Dateien und Software werden vor Ausführung automatisch geprüft (On-Access-Scan). -- **Organisatorisch:** On-Access-Scan verbindlich vorgeben. -- **Technisch:** Echtzeitschutz/On-Access-Scanning aktivieren und gegen Deaktivierung schützen. Referenz: BL-OPS-03. -- **Typische Nachweise:** Konfigurationsnachweis Echtzeitschutz. -- **Vorlage:** R10; BL-OPS-03 -- **Ressourcen:** IT-Betrieb; gering. -- **AL-Filter:** AL2 + AL3 - -### 5.2.3-S5 — [SOLL] -**Anforderung:** Der gesamte Datenbestand aller Systeme wird regelmäßig auf Schadsoftware geprüft. -- **Organisatorisch:** Turnus für vollständige Scans festlegen. -- **Technisch:** Geplante Full-Scans zentral steuern und auswerten. Referenz: BL-OPS-03. -- **Typische Nachweise:** Scan-Zeitpläne, Scan-Berichte. -- **Vorlage:** R10; BL-OPS-03 -- **Ressourcen:** IT-Betrieb; gering. -- **AL-Filter:** AL2 + AL3 - -### 5.2.3-S6 — [SOLL] -**Anforderung:** Über zentrale Gateways übertragene Daten werden automatisch durch Schutzsoftware geprüft. -- **Organisatorisch:** Prüfung an E-Mail-/Web-/Übergabe-Gateways verpflichtend festlegen. -- **Technisch:** Gateway-Scanning (Mail-Security, Web-Proxy/Sandbox) einsetzen. Referenz: BL-OPS-03, BL-NET-02. -- **Typische Nachweise:** Gateway-Konfiguration, Scan-Statistik. -- **Vorlage:** R10; BL-OPS-03 -- **Ressourcen:** Mail-/Web-Security-Gateway (Beschaffung möglich); mittel. -- **AL-Filter:** AL2 + AL3 - -### 5.2.3-S7 — [SOLL] -**Anforderung:** Maßnahmen, die verhindern, dass Schutzsoftware durch Nutzer deaktiviert oder verändert wird, sind umgesetzt. -- **Organisatorisch:** Verbot der Deaktivierung in der Richtlinie verankern. -- **Technisch:** Tamper-Protection, Entzug lokaler Admin-Rechte, zentrale Richtlinienbindung. Referenz: BL-OPS-03, BL-IAM-05 (Privilegien). -- **Typische Nachweise:** Tamper-Protection-Konfiguration, Rechtekonzept. -- **Vorlage:** R10; BL-OPS-03; BL-IAM-05 -- **Ressourcen:** IT-Betrieb; gering. -- **AL-Filter:** AL2 + AL3 - -### 5.2.3-S8 — [SOLL] -**Anforderung:** Für IT-Systeme ohne Schutzsoftware sind alternative Maßnahmen umgesetzt. -- **Organisatorisch:** Systeme ohne AV (z. B. OT, Appliances) identifizieren und Ersatzmaßnahmen festlegen. -- **Technisch:** Netzisolation, Application-Whitelisting, minimale Dienste, erhöhte Resilienz. Referenz: BL-OPS-03, BL-NET-01. -- **Typische Nachweise:** Liste betroffener Systeme mit kompensierenden Maßnahmen. -- **Vorlage:** R10; BL-NET-01 -- **Ressourcen:** IT-Betrieb; mittel. -- **AL-Filter:** AL2 + AL3 - -## Control 5.2.4 — Ereignisprotokollierung (Logging & Monitoring) - -### 5.2.4-M1 — [MUSS] -**Anforderung:** Informationssicherheitsanforderungen an den Umgang mit Ereignisprotokollen sind bestimmt und erfüllt. -- **Organisatorisch:** Logging-Konzept mit Umfang, Aufbewahrungsfristen, Zugriff, Datenschutz-/Mitbestimmungsvorgaben definieren. -- **Technisch:** Zentrale Protokollierung (SIEM/Log-Management), definierte Log-Quellen und Retention. Referenz: BL-OPS-04 (Logging/Retention). -- **Typische Nachweise:** Logging-Konzept, Aufbewahrungsvorgabe, Log-Quellenliste. -- **Vorlage:** R10; VA-13; BL-OPS-04 -- **Ressourcen:** IT-Betrieb; ggf. SIEM/Log-Management (Beschaffung möglich); mittel. -- **AL-Filter:** AL2 + AL3 - -### 5.2.4-M2 — [MUSS] -**Anforderung:** Sicherheitsrelevante Anforderungen an die Protokollierung von Administrator- und Nutzeraktivitäten sind bestimmt und erfüllt. -- **Organisatorisch:** Festlegen, welche Admin-/Nutzeraktionen (Logins, Rechteänderungen, privilegierte Aktionen) protokolliert werden; Mitbestimmung/Datenschutz einbinden. -- **Technisch:** Audit-Logging auf Systemen und für privilegierte Zugriffe (PAM) aktivieren. Referenz: BL-OPS-04, BL-IAM-05. -- **Typische Nachweise:** Log-Auszüge Admin-Aktivitäten, Audit-Policy-Konfiguration. -- **Vorlage:** R10; VA-13; BL-OPS-04 -- **Ressourcen:** IT-Betrieb; gering–mittel. -- **AL-Filter:** AL2 + AL3 - -### 5.2.4-M3 — [MUSS] -**Anforderung:** Die eingesetzten IT-Systeme werden hinsichtlich der Notwendigkeit der Protokollierung bewertet. -- **Organisatorisch:** Bewertungskriterien festlegen, welche Systeme protokolliert werden müssen. -- **Technisch:** Logging-Abdeckung je System dokumentieren und aus dem Asset-Inventar ableiten. Referenz: BL-OPS-04. -- **Typische Nachweise:** Bewertungsübersicht Protokollierungsbedarf. -- **Vorlage:** R10; VA-13 -- **Ressourcen:** IT-Betrieb; gering. -- **AL-Filter:** AL2 + AL3 - -### 5.2.4-M4 — [MUSS] -**Anforderung:** Bei Nutzung externer IT-Dienste werden Informationen zu den Überwachungsmöglichkeiten eingeholt und berücksichtigt. -- **Organisatorisch:** Bei Cloud-/Dienstauswahl Logging-/Audit-Fähigkeiten abfragen und vertraglich sichern. -- **Technisch:** Verfügbare Anbieter-Logs (Audit-Logs, Access-Logs) anbinden/exportieren. Referenz: BL-OPS-04. -- **Typische Nachweise:** Anbieterauskunft Monitoring, angebundene Cloud-Logs. -- **Vorlage:** R10; VA-13 -- **Ressourcen:** IT-Betrieb/Einkauf; gering. -- **AL-Filter:** AL2 + AL3 - -### 5.2.4-M5 — [MUSS] -**Anforderung:** Ereignisprotokolle werden regelmäßig auf Richtlinienverstöße und auffällige Probleme geprüft. -- **Organisatorisch:** Auswerteturnus und Verantwortliche festlegen; rechtliche/organisatorische Vorgaben (Datenschutz, Mitbestimmung) einhalten. -- **Technisch:** Regelbasierte Auswertung/Alerting im SIEM, Use-Cases für auffällige Ereignisse. Referenz: BL-OPS-04. -- **Typische Nachweise:** Auswerteprotokolle, SIEM-Alert-Regeln, Reports. -- **Vorlage:** R10; VA-13 -- **Ressourcen:** IT-Betrieb/Security-Analyse; mittel. -- **AL-Filter:** AL2 + AL3 - -### 5.2.4-S1 — [SOLL] -**Anforderung:** Ein Verfahren zur Eskalation relevanter Ereignisse an die verantwortliche Stelle ist definiert und etabliert. -- **Organisatorisch:** Eskalationswege und Reaktionszuständigkeiten festlegen (Anbindung an Incident-Prozess R04). -- **Technisch:** Automatisierte Alerts an definierte Empfänger/Ticketsystem. Referenz: BL-OPS-04. -- **Typische Nachweise:** Eskalationsverfahren, Alert-Routing, Ticket-Nachweise. -- **Vorlage:** R10; VA-13; VA-01 -- **Ressourcen:** IT-Betrieb; gering. -- **AL-Filter:** AL2 + AL3 - -### 5.2.4-S2 — [SOLL] -**Anforderung:** Ereignisprotokolle sind gegen Veränderung geschützt. -- **Organisatorisch:** Vorgabe zur Integrität und Zugriffsbeschränkung der Logs. -- **Technisch:** Zentrale, schreibgeschützte/WORM-Logablage, getrennte Log-Umgebung, Zugriffskontrolle. Referenz: BL-OPS-04. -- **Typische Nachweise:** Konfiguration Log-Integritätsschutz, Zugriffskonzept Log-System. -- **Vorlage:** R10; BL-OPS-04 -- **Ressourcen:** IT-Betrieb; gering–mittel. -- **AL-Filter:** AL2 + AL3 - -### 5.2.4-S3 — [SOLL] -**Anforderung:** Eine angemessene Überwachung und Aufzeichnung aller informationssicherheitsrelevanten Aktionen im Netzwerk ist etabliert. -- **Organisatorisch:** Umfang der Netzüberwachung festlegen. -- **Technisch:** Netzwerk-Monitoring/IDS/NDR, zentrale Aufzeichnung sicherheitsrelevanter Netzereignisse. Referenz: BL-NET-01, BL-OPS-04. -- **Typische Nachweise:** IDS/NDR-Konfiguration, Monitoring-Reports. -- **Vorlage:** R10; BL-NET-01 -- **Ressourcen:** IDS/NDR-Lösung (Beschaffung möglich); mittel. -- **AL-Filter:** AL2 + AL3 - -### 5.2.4-H1 — [HOCH] -**Anforderung:** Sicherheitsrelevante Anforderungen an den Umgang mit Ereignisprotokollen (z. B. vertragliche) sind bestimmt und umgesetzt. (C, I, A) -- **Organisatorisch:** Kunden-/vertragliche Log-Anforderungen erheben und umsetzen (z. B. Aufbewahrung, Bereitstellung). -- **Technisch:** Erweiterte Retention, kundenspezifische Log-Trennung/-Bereitstellung. Referenz: BL-OPS-04. -- **Typische Nachweise:** Mapping vertragliche Anforderungen↔Umsetzung, Retention-Konfiguration. -- **Vorlage:** R10; BL-OPS-04 -- **Ressourcen:** IT-Betrieb; gering–mittel. -- **AL-Filter:** AL3 (hoher Schutzbedarf) - -### 5.2.4-H2 — [HOCH] -**Anforderung:** Ereignisse zu Auf- und Abbau von Fernzugriffssitzungen werden protokolliert. (C, I, A) -- **Organisatorisch:** Protokollierungspflicht für Fernwartung/Fernzugriff festlegen. -- **Technisch:** Session-Logging in VPN/PAM/Fernwartungslösung, inkl. Start-/Endzeit und Nutzer. Referenz: BL-NET-03, BL-OPS-04. -- **Typische Nachweise:** Fernzugriffs-Session-Logs, PAM-Aufzeichnungen. -- **Vorlage:** R10; BL-NET-03 -- **Ressourcen:** IT-Betrieb; gering. -- **AL-Filter:** AL3 (hoher Schutzbedarf) - -### 5.2.4-V1 — [SEHR HOCH] -**Anforderung:** Protokollierung jedes Zugriffs auf Daten mit sehr hohem Schutzbedarf, soweit technisch/rechtlich zulässig. (C, I) -- **Organisatorisch:** Zugriffsprotokollierung für sehr hohe Schutzklasse verbindlich festlegen; Datenschutz-/Mitbestimmung klären. -- **Technisch:** Objekt-/Datenzugriffs-Auditing (File-/DB-Access-Logs) für die betreffenden Datenbestände aktivieren. Referenz: BL-OPS-04. -- **Typische Nachweise:** Data-Access-Logs, Konfiguration Objekt-Auditing. -- **Vorlage:** R10; BL-OPS-04 -- **Ressourcen:** IT-Betrieb; mittel. -- **AL-Filter:** AL3 (sehr hoher Schutzbedarf) - -## Control 5.2.5 — Umgang mit technischen Schwachstellen (Vulnerability & Patch Management) - -### 5.2.5-M1 — [MUSS] -**Anforderung:** Informationen über technische Schwachstellen der eingesetzten IT-Systeme werden erhoben. -- **Organisatorisch:** Quellen definieren (Herstellermeldungen, CVE/CERT-Feeds, Audits) und Verantwortliche für die Auswertung benennen. -- **Technisch:** Abgleich von Schwachstelleninfos mit Asset-Inventar; automatisierte Vulnerability-Feeds/Scanner. Referenz: BL-OPS-06 (Patch-/Schwachstellenmanagement). -- **Typische Nachweise:** Abonnierte Feeds/CERT-Meldungen, Schwachstellenliste, Scan-Reports. -- **Vorlage:** R10; VA-04; VA-06; BL-OPS-06 -- **Ressourcen:** IT-Betrieb; ggf. Vulnerability-Scanner (Beschaffung möglich); mittel. -- **AL-Filter:** AL2 + AL3 - -### 5.2.5-M2 — [MUSS] -**Anforderung:** Potenziell betroffene IT-Systeme/Software werden identifiziert und das Risiko bewertet. -- **Organisatorisch:** Bewertungsprozess (Kritikalität, CVSS, Betroffenheit) mit Fristen etablieren. -- **Technisch:** Verknüpfung Schwachstelle↔Asset, Priorisierung nach Schweregrad/Exponiertheit. Referenz: BL-OPS-06. -- **Typische Nachweise:** Risikobewertungen je Schwachstelle, Priorisierungsliste. -- **Vorlage:** R10; VA-06; BL-OPS-06 -- **Ressourcen:** IT-Betrieb; gering–mittel. -- **AL-Filter:** AL2 + AL3 - -### 5.2.5-M3 — [MUSS] -**Anforderung:** Risiken aus Schwachstellen werden behandelt. -- **Organisatorisch:** Behandlungsentscheidung (Patch, Mitigation, Akzeptanz) dokumentieren und nachverfolgen. -- **Technisch:** Umsetzung von Patches/Workarounds, Nachkontrolle. Referenz: BL-OPS-06. -- **Typische Nachweise:** Maßnahmen-/Behandlungsnachweise, Ticket-Historie. -- **Vorlage:** R10; VA-06; BL-OPS-06 -- **Ressourcen:** IT-Betrieb; mittel. -- **AL-Filter:** AL2 + AL3 - -### 5.2.5-S1 — [SOLL] -**Anforderung:** Ein angemessenes Patch-Management ist definiert und umgesetzt. -- **Organisatorisch:** Patch-Prozess mit Test-, Freigabe- und Fristenregelung (nach Kritikalität) festlegen. -- **Technisch:** Patch-Management-Werkzeug mit Verteilung, Test-Ring und Reporting. Referenz: BL-OPS-06. -- **Typische Nachweise:** Patch-Richtlinie, Patch-Reports/Compliance-Grad. -- **Vorlage:** R10; VA-06; BL-OPS-06 -- **Ressourcen:** Patch-Management-Tool (Beschaffung möglich); mittel. -- **AL-Filter:** AL2 + AL3 - -### 5.2.5-S2 — [SOLL] -**Anforderung:** Risikominimierende Maßnahmen werden bei Bedarf umgesetzt. -- **Organisatorisch:** Für nicht sofort patchbare Schwachstellen kompensierende Maßnahmen festlegen. -- **Technisch:** Virtual Patching (IPS/WAF), Isolation, Dienstabschaltung. Referenz: BL-OPS-06, BL-NET-02. -- **Typische Nachweise:** Dokumentierte Mitigationsmaßnahmen. -- **Vorlage:** R10; BL-OPS-06 -- **Ressourcen:** IT-Betrieb; gering–mittel. -- **AL-Filter:** AL2 + AL3 - -### 5.2.5-S3 — [SOLL] -**Anforderung:** Die erfolgreiche Installation von Patches wird verifiziert. -- **Organisatorisch:** Verifikationsschritt im Patch-Prozess vorsehen. -- **Technisch:** Compliance-Reports/Re-Scan zur Bestätigung des Patch-Stands. Referenz: BL-OPS-06. -- **Typische Nachweise:** Patch-Compliance-Report, Verifikations-Scan. -- **Vorlage:** R10; BL-OPS-06 -- **Ressourcen:** IT-Betrieb; gering. -- **AL-Filter:** AL2 + AL3 - -## Control 5.2.6 — Prüfung (Audit) von IT-Systemen und -Diensten - -### 5.2.6-M1 — [MUSS] -**Anforderung:** Anforderungen an die Prüfung (Audit) von IT-Systemen oder -Diensten sind bestimmt. -- **Organisatorisch:** Prüfumfang, -kriterien und -verantwortliche festlegen (technische Systemprüfungen/Security-Tests). -- **Technisch:** Prüfmethoden je Systemklasse definieren (Konfigurationsprüfung, Schwachstellenscan). Referenz: BL-OPS-07 (Systemprüfung/Scanning). -- **Typische Nachweise:** Prüfkonzept/-vorgaben, Prüfkriterien. -- **Vorlage:** R10; VA-06; BL-OPS-07 -- **Ressourcen:** IT-Betrieb/ISB; gering. -- **AL-Filter:** AL2 + AL3 - -### 5.2.6-M2 — [MUSS] -**Anforderung:** Der Umfang der Systemprüfung wird rechtzeitig festgelegt. -- **Organisatorisch:** Scope und Zeitpunkt vorab abstimmen und dokumentieren. -- **Technisch:** Zieldefinition (Systeme, Tiefe, Werkzeuge) vor Prüfbeginn. Referenz: BL-OPS-07. -- **Typische Nachweise:** Scope-Dokument, Prüfplan. -- **Vorlage:** R10; VA-06 -- **Ressourcen:** IT-Betrieb; gering. -- **AL-Filter:** AL2 + AL3 - -### 5.2.6-M3 — [MUSS] -**Anforderung:** System-/Dienstprüfungen werden mit Betreiber und Nutzern abgestimmt. -- **Organisatorisch:** Abstimmungs-/Genehmigungsprozess vor Prüfungen (Vermeidung von Betriebsstörungen) etablieren. -- **Technisch:** Prüffenster/Wartungsfenster planen. Referenz: BL-OPS-07. -- **Typische Nachweise:** Abstimmungsnachweis, Freigabe der Prüfung. -- **Vorlage:** R10; VA-06 -- **Ressourcen:** IT-Betrieb; gering. -- **AL-Filter:** AL2 + AL3 - -### 5.2.6-M4 — [MUSS] -**Anforderung:** Die Ergebnisse werden nachvollziehbar gespeichert und der Leitung berichtet. -- **Organisatorisch:** Berichts- und Ablagepflicht festlegen. -- **Technisch:** Zentrale, zugriffsgeschützte Ablage der Prüfberichte. Referenz: BL-OPS-07. -- **Typische Nachweise:** Prüfberichte, Berichtsvermerk an Leitung. -- **Vorlage:** R10; VA-06 -- **Ressourcen:** IT-Betrieb; gering. -- **AL-Filter:** AL2 + AL3 - -### 5.2.6-M5 — [MUSS] -**Anforderung:** Aus den Ergebnissen werden Maßnahmen abgeleitet und fristgerecht umgesetzt. -- **Organisatorisch:** Maßnahmenverfolgung mit Fristen und Verantwortlichen etablieren. -- **Technisch:** Findings in Maßnahmen-/Ticketsystem überführen und nachhalten. Referenz: BL-OPS-06, BL-OPS-07. -- **Typische Nachweise:** Maßnahmenplan, Umsetzungsnachweise. -- **Vorlage:** R10; VA-06 -- **Ressourcen:** IT-Betrieb; mittel. -- **AL-Filter:** AL2 + AL3 - -### 5.2.6-S1 — [SOLL] -**Anforderung:** Prüfungen werden unter Berücksichtigung möglicher Sicherheitsrisiken geplant. -- **Organisatorisch:** Risiken der Prüfung selbst (Störungen, Datenzugriff) vorab bewerten. -- **Technisch:** Schonende Testmodi, Testumgebung bei kritischen Systemen. Referenz: BL-OPS-07. -- **Typische Nachweise:** Prüfplanung mit Risikobetrachtung. -- **Vorlage:** R10; VA-06 -- **Ressourcen:** IT-Betrieb; gering. -- **AL-Filter:** AL2 + AL3 - -### 5.2.6-S2 — [SOLL] -**Anforderung:** Regelmäßige System-/Dienstprüfungen werden durchgeführt. -- **Organisatorisch:** Prüfturnus festlegen. -- **Technisch:** Wiederkehrende Scans/Audits automatisieren. Referenz: BL-OPS-07. -- **Typische Nachweise:** Prüfkalender, wiederkehrende Prüfberichte. -- **Vorlage:** R10; VA-06 -- **Ressourcen:** IT-Betrieb; gering–mittel. -- **AL-Filter:** AL2 + AL3 - -### 5.2.6-S3 — [SOLL] -**Anforderung:** Innerhalb angemessener Frist wird ein Prüfbericht erstellt. -- **Organisatorisch:** Berichtsfrist festlegen. -- **Technisch:** Standardisierte Berichtsvorlage/Report-Export. Referenz: BL-OPS-07. -- **Typische Nachweise:** Datierte Prüfberichte. -- **Vorlage:** R10; VA-06 -- **Ressourcen:** IT-Betrieb; gering. -- **AL-Filter:** AL2 + AL3 - -### 5.2.6-H1 — [HOCH] -**Anforderung:** Für kritische IT-Systeme/-Dienste sind zusätzliche Prüfanforderungen identifiziert und werden erfüllt. (A) -- **Organisatorisch:** Kritische Systeme bestimmen und erweiterte Prüftiefe/-intervalle festlegen. -- **Technisch:** Dienstspezifische Tests und/oder manuelle Penetrationstests, risikobasierte Intervalle. Referenz: BL-OPS-07. -- **Typische Nachweise:** Pentest-/Prüfberichte kritischer Systeme, Intervallfestlegung. -- **Vorlage:** R10; VA-06; BL-OPS-07 -- **Ressourcen:** ggf. externer Pentest-Dienstleister (Budget); mittel–hoch. -- **AL-Filter:** AL3 (hoher Schutzbedarf) - -### 5.2.6-V1 — [SEHR HOCH] -**Anforderung:** IT-Systeme/-Dienste werden regelmäßig auf Schwachstellen gescannt; nicht scanbare Systeme erhalten Schutzmaßnahmen. (C, I, A) -- **Organisatorisch:** Verbindlichen Scan-Turnus und Umgang mit nicht scanbaren Systemen festlegen. -- **Technisch:** Regelmäßige authentifizierte Vulnerability-Scans; für nicht scanbare Systeme Isolation/kompensierende Maßnahmen. Referenz: BL-OPS-07, BL-OPS-06. -- **Typische Nachweise:** Scan-Reports, Liste nicht scanbarer Systeme mit Ersatzmaßnahmen. -- **Vorlage:** R10; VA-06; BL-OPS-07 -- **Ressourcen:** Vulnerability-Scanner (Beschaffung möglich); mittel. -- **AL-Filter:** AL3 (sehr hoher Schutzbedarf) - -## Control 5.2.7 — Netzwerkmanagement und -segmentierung - -### 5.2.7-M1 — [MUSS] -**Anforderung:** Anforderungen an das Management und die Steuerung von Netzwerken sind bestimmt und erfüllt. -- **Organisatorisch:** Netzwerkbetriebsvorgaben (Verantwortliche, Konfigurations-/Änderungsregeln, Dokumentationspflicht) festlegen. -- **Technisch:** Zentrale Verwaltung der Netzkomponenten, gehärtete Konfigurationen, Netzdokumentation. Referenz: BL-NET-01 (Netzwerkmanagement/Segmentierung). -- **Typische Nachweise:** Netzbetriebsrichtlinie, Netzplan, Konfigurationsstandards. -- **Vorlage:** R10; BL-NET-01 -- **Ressourcen:** IT-Betrieb/Netzwerk; gering–mittel. -- **AL-Filter:** AL2 + AL3 - -### 5.2.7-M2 — [MUSS] -**Anforderung:** Anforderungen an die Netzsegmentierung sind bestimmt und erfüllt. -- **Organisatorisch:** Segmentierungsvorgaben je Schutzbedarf/Zone festlegen (z. B. Client, Server, OT, DMZ, Gäste). -- **Technisch:** VLANs/Subnetze mit Firewall-/ACL-Kontrolle zwischen Segmenten. Referenz: BL-NET-01, BL-NET-02. -- **Typische Nachweise:** Segmentierungskonzept, Firewall-Regeln zwischen Zonen. -- **Vorlage:** R10; BL-NET-01; BL-NET-02 -- **Ressourcen:** IT-Betrieb/Netzwerk; mittel. -- **AL-Filter:** AL2 + AL3 - -### 5.2.7-S1 — [SOLL] -**Anforderung:** Verfahren für das Management und die Steuerung von Netzwerken sind definiert. -- **Organisatorisch:** Betriebs-/Änderungsverfahren für das Netzwerk dokumentieren. -- **Technisch:** Change-gebundene Netzkonfiguration, Konfigurations-Backups/Versionierung. Referenz: BL-NET-01, BL-OPS-01. -- **Typische Nachweise:** Netzbetriebsverfahren, Konfigurations-Backups. -- **Vorlage:** R10; BL-NET-01 -- **Ressourcen:** IT-Betrieb; gering. -- **AL-Filter:** AL2 + AL3 - -### 5.2.7-S2 — [SOLL] -**Anforderung:** Für eine risikobasierte Netzsegmentierung werden die einschlägigen Aspekte berücksichtigt. -- **Organisatorisch:** Segmentierung anhand Risiko/Schutzbedarf und Datenflüssen begründen. -- **Technisch:** Feinere Segmentierung/Mikrosegmentierung für schützenswerte Bereiche. Referenz: BL-NET-01. -- **Typische Nachweise:** Risikobasierte Segmentierungsbegründung, Datenflussanalyse. -- **Vorlage:** R10; BL-NET-01 -- **Ressourcen:** IT-Betrieb/Netzwerk; mittel. -- **AL-Filter:** AL2 + AL3 - -### 5.2.7-H1 — [HOCH] -**Anforderung:** Erweiterte Anforderungen an das Management und die Steuerung von Netzwerken sind bestimmt und umgesetzt. (C, I, A) -- **Organisatorisch:** Erhöhte Kontrollen für kritische Netzbereiche festlegen (z. B. dediziertes Admin-Netz, strengere Änderungsfreigaben). -- **Technisch:** Out-of-Band-Management, NAC/Portsicherheit, verschlüsseltes Management, Monitoring. Referenz: BL-NET-01, BL-NET-02. -- **Typische Nachweise:** NAC-/Admin-Netz-Konfiguration, Management-Härtung. -- **Vorlage:** R10; BL-NET-01 -- **Ressourcen:** IT-Betrieb/Netzwerk; mittel–hoch. -- **AL-Filter:** AL3 (hoher Schutzbedarf) - -## Control 5.2.8 — Kontinuität kritischer IT-Dienste (IT-Notfall-/BCM) - -### 5.2.8-M1 — [MUSS] -**Anforderung:** Kritische IT-Dienste sind identifiziert und die Geschäftsauswirkung wird berücksichtigt. -- **Organisatorisch:** Business-Impact-Analyse durchführen, kritische IT-Dienste und Abhängigkeiten bestimmen. -- **Technisch:** Kritikalitätsattribute im Service-/Asset-Inventar pflegen. Referenz: BL-OPS-08 (Kontinuität/BCM). -- **Typische Nachweise:** BIA, Liste kritischer IT-Dienste. -- **Vorlage:** R04; VA-02; BL-OPS-08 -- **Ressourcen:** ISB/IT-Betrieb; gering–mittel. -- **AL-Filter:** AL2 + AL3 - -### 5.2.8-M2 — [MUSS] -**Anforderung:** Anforderungen und Verantwortlichkeiten für Kontinuität und Wiederherstellung sind bekannt und erfüllt. -- **Organisatorisch:** Verantwortliche und Kontinuitätsanforderungen (Zielzustände, Zuständigkeiten) festlegen und kommunizieren. -- **Technisch:** Wiederherstellungsverfahren je kritischem Dienst dokumentieren. Referenz: BL-OPS-08, BL-OPS-05. -- **Typische Nachweise:** Rollen-/Verantwortungsmatrix, Kontinuitätsanforderungen je Dienst. -- **Vorlage:** R04; VA-02; BL-OPS-08 -- **Ressourcen:** IT-Betrieb; gering. -- **AL-Filter:** AL2 + AL3 - -### 5.2.8-S1 — [SOLL] -**Anforderung:** Kritische IT-Systeme sind identifiziert. -- **Organisatorisch:** Neben Diensten auch die unterstützenden kritischen Systeme/Komponenten bestimmen. -- **Technisch:** Abhängigkeitskarte Dienst↔System pflegen. Referenz: BL-OPS-08. -- **Typische Nachweise:** Liste kritischer Systeme, Abhängigkeitsdiagramm. -- **Vorlage:** R04; VA-02 -- **Ressourcen:** IT-Betrieb; gering. -- **AL-Filter:** AL2 + AL3 - -### 5.2.8-S2 — [SOLL] -**Anforderung:** Eine Kontinuitätsplanung existiert und wird regelmäßig überprüft und aktualisiert. -- **Organisatorisch:** IT-Notfallplan/BCP erstellen und Review-Turnus festlegen. -- **Technisch:** Wiederanlaufpläne, Notfallkonfigurationen dokumentieren und pflegen. Referenz: BL-OPS-08. -- **Typische Nachweise:** IT-Notfallplan, Review-Historie. -- **Vorlage:** R04; VA-02; BL-OPS-08 -- **Ressourcen:** ISB/IT-Betrieb; mittel. -- **AL-Filter:** AL2 + AL3 - -### 5.2.8-S3 — [SOLL] -**Anforderung:** Die Kontinuitätsplanung umfasst mindestens (D)DoS, Ransomware/Sabotage, Systemausfall und Naturkatastrophen. -- **Organisatorisch:** Szenariokatalog festlegen und Maßnahmen je Szenario planen. -- **Technisch:** Szenariospezifische Vorkehrungen (DDoS-Schutz, Ransomware-Wiederanlauf aus sauberem Backup, Redundanz). Referenz: BL-OPS-08, BL-OPS-05. -- **Typische Nachweise:** Szenarienübersicht mit Maßnahmen. -- **Vorlage:** R04; VA-02 -- **Ressourcen:** IT-Betrieb; mittel. -- **AL-Filter:** AL2 + AL3 - -### 5.2.8-H1 — [HOCH] -**Anforderung:** Die Kontinuitätsplanung enthält vordefinierte Zeitrahmen (RTO) für den Wiederanlauf. (A) -- **Organisatorisch:** RTO (und ergänzend RPO) je kritischem Dienst festlegen und freigeben. -- **Technisch:** Wiederherstellungsverfahren auf RTO auslegen (Ressourcen, Automatisierung). Referenz: BL-OPS-08, BL-OPS-05. -- **Typische Nachweise:** RTO/RPO-Festlegung, Abgleich mit Wiederanlaufverfahren. -- **Vorlage:** R04; VA-02; BL-OPS-08 -- **Ressourcen:** IT-Betrieb; mittel. -- **AL-Filter:** AL3 (hoher Schutzbedarf) - -### 5.2.8-H2 — [HOCH] -**Anforderung:** Angemessene SLAs mit externen Dienstleistern entsprechend der Kontinuitätsplanung bestehen. (A) -- **Organisatorisch:** Kontinuitäts-/Wiederherstellungszusagen vertraglich (SLA) mit Providern vereinbaren. -- **Technisch:** SLA-Parameter (Verfügbarkeit, Reaktions-/Wiederherstellzeit) mit eigenen RTO abgleichen. Referenz: BL-OPS-08. -- **Typische Nachweise:** SLA-Verträge, Abgleich SLA↔RTO. -- **Vorlage:** R04; VA-02 -- **Ressourcen:** Einkauf/IT; gering. -- **AL-Filter:** AL3 (hoher Schutzbedarf) - -### 5.2.8-H3 — [HOCH] -**Anforderung:** Die Kontinuitätspläne umfassen die Koordination vertraglich vereinbarter Kommunikation mit Geschäftspartnern. (A) -- **Organisatorisch:** Kommunikations-/Meldepflichten gegenüber Kunden/Partnern im Notfall festlegen. -- **Technisch:** Kontaktlisten und Kommunikationskanäle notfallfest bereithalten. Referenz: BL-OPS-08. -- **Typische Nachweise:** Kommunikationsplan, Kontaktverzeichnis. -- **Vorlage:** R04; VA-02 -- **Ressourcen:** ISB/IT; gering. -- **AL-Filter:** AL3 (hoher Schutzbedarf) - -### 5.2.8-H4 — [HOCH] -**Anforderung:** Die Kontinuitätsplanung wird regelmäßig getestet (inkl. vollständiger Wiederherstellung und Zielzeiten). (A) -- **Organisatorisch:** Testturnus und Testszenarien festlegen, Ergebnisse auswerten. -- **Technisch:** Wiederherstellungstests bis in bekannten Zustand, RTO-Messung. Referenz: BL-OPS-08, BL-OPS-05. -- **Typische Nachweise:** Testprotokolle mit Zielzeiterreichung, Lessons Learned. -- **Vorlage:** R04; VA-02 -- **Ressourcen:** IT-Betrieb; mittel. -- **AL-Filter:** AL3 (hoher Schutzbedarf) - -### 5.2.8-H5 — [HOCH] -**Anforderung:** Eine Backup- und Wiederherstellungsstrategie für kritische IT-Dienste ist definiert und umgesetzt. (C, I, A) -- **Organisatorisch:** Backup-Strategie (Umfang, Frequenz, Aufbewahrung, Schutzziele) für kritische Dienste festlegen. -- **Technisch:** Regelmäßige, überwachte Backups mit Verschlüsselung und getrennter Ablage. Referenz: BL-OPS-05 (Backup). -- **Typische Nachweise:** Backup-Konzept, Backup-Reports. -- **Vorlage:** R04; VA-02; BL-OPS-05 -- **Ressourcen:** IT-Betrieb; mittel. -- **AL-Filter:** AL3 (hoher Schutzbedarf) - -### 5.2.8-H6 — [HOCH] -**Anforderung:** Backups kritischer IT-Dienste sind gegen unbefugte Veränderung/Löschung durch Schadsoftware geschützt. (I, A) -- **Organisatorisch:** Schutzanforderung gegen Ransomware-Zugriff auf Backups festschreiben. -- **Technisch:** Immutable/WORM-Backups, Offline-/Air-Gap-Kopie, getrennte Backup-Credentials. Referenz: BL-OPS-05. -- **Typische Nachweise:** Immutable-/Offline-Backup-Konfiguration. -- **Vorlage:** R04; BL-OPS-05 -- **Ressourcen:** IT-Betrieb; mittel. -- **AL-Filter:** AL3 (hoher Schutzbedarf) - -### 5.2.8-H7 — [HOCH] -**Anforderung:** Backups kritischer IT-Dienste sind gegen unbefugten Zugriff durch Schadsoftware oder Betreiber geschützt. (C, I) -- **Organisatorisch:** Vertraulichkeitsschutz für Backups (auch bei externem Betrieb) festlegen. -- **Technisch:** Verschlüsselung der Backups mit eigener Schlüsselhoheit, strikte Zugriffstrennung. Referenz: BL-OPS-05, BL-CRY-03. -- **Typische Nachweise:** Backup-Verschlüsselung, Zugriffskonzept. -- **Vorlage:** R04; BL-OPS-05; BL-CRY-03 -- **Ressourcen:** IT-Betrieb; gering–mittel. -- **AL-Filter:** AL3 (hoher Schutzbedarf) - -### 5.2.8-V1 — [SEHR HOCH] -**Anforderung:** Die Kontinuitätsplanung ist mit den Kontinuitätsplänen relevanter externer Dienstleister abgestimmt. (A) -- **Organisatorisch:** Gemeinsame Abstimmung/Verzahnung der BCM-Pläne mit kritischen Providern. -- **Technisch:** End-to-End-Wiederanlaufketten über Provider hinweg dokumentieren. Referenz: BL-OPS-08. -- **Typische Nachweise:** Abgestimmte BCM-Pläne, Provider-Bestätigungen. -- **Vorlage:** R04; VA-02 -- **Ressourcen:** ISB/Einkauf; mittel. -- **AL-Filter:** AL3 (sehr hoher Schutzbedarf) - -### 5.2.8-V2 — [SEHR HOCH] -**Anforderung:** Fortführung wesentlicher Kern-/Geschäftsfunktionen mit minimalem Verlust an Betriebskontinuität ist möglich. -- **Organisatorisch:** Notbetriebskonzepte für Kernfunktionen definieren. -- **Technisch:** Hochverfügbarkeit/Redundanz und Failover für Kernfunktionen. Referenz: BL-OPS-08. -- **Typische Nachweise:** Notbetriebs-/HA-Konzept, Failover-Nachweis. -- **Vorlage:** R04; VA-02 -- **Ressourcen:** IT-Betrieb; hoch. -- **AL-Filter:** AL3 (sehr hoher Schutzbedarf) - -### 5.2.8-V3 — [SEHR HOCH] -**Anforderung:** Die Kontinuitätsplanung wird regelmäßig getestet; Szenarien, Ergebnisse und Lessons Learned werden aufgezeichnet. (I, A) -- **Organisatorisch:** Umfassendes Testprogramm mit Dokumentationspflicht etablieren. -- **Technisch:** Realitätsnahe Failover-/Wiederherstellungstests, Auswertung und Nachsteuerung. Referenz: BL-OPS-08. -- **Typische Nachweise:** Testberichte mit Szenarien und Lessons Learned. -- **Vorlage:** R04; VA-02 -- **Ressourcen:** IT-Betrieb; mittel–hoch. -- **AL-Filter:** AL3 (sehr hoher Schutzbedarf) - -## Control 5.2.9 — Datensicherung und Wiederherstellung (Backup) - -### 5.2.9-M1 — [MUSS] -**Anforderung:** Backup-Konzepte existieren für relevante IT-Systeme; Schutzmaßnahmen für C/I/A der Sicherungen werden berücksichtigt. -- **Organisatorisch:** Backup-Konzept je System/Datenbestand (Umfang, Frequenz, Aufbewahrung, Verantwortliche) erstellen. -- **Technisch:** Automatisierte Backups mit Verschlüsselung (C), Integritätsprüfung (I) und redundanter Ablage (A). Referenz: BL-OPS-05 (Backup). -- **Typische Nachweise:** Backup-Konzept, Backup-Job-Reports. -- **Vorlage:** R10; VA-05; BL-OPS-05 -- **Ressourcen:** IT-Betrieb; mittel. -- **AL-Filter:** AL2 + AL3 - -### 5.2.9-M2 — [MUSS] -**Anforderung:** Wiederherstellungskonzepte existieren für relevante IT-Dienste. -- **Organisatorisch:** Wiederherstellungsverfahren je Dienst dokumentieren (Schritte, Zuständige, Voraussetzungen). -- **Technisch:** Restore-Prozeduren mit Reihenfolge und Abhängigkeiten hinterlegen. Referenz: BL-OPS-05. -- **Typische Nachweise:** Wiederherstellungskonzept, Restore-Anleitung. -- **Vorlage:** R10; VA-05; BL-OPS-05 -- **Ressourcen:** IT-Betrieb; gering–mittel. -- **AL-Filter:** AL2 + AL3 - -### 5.2.9-S1 — [SOLL] -**Anforderung:** Für jeden relevanten IT-Dienst existiert ein Backup-/Wiederherstellungskonzept inkl. Abhängigkeiten und Reihenfolge. -- **Organisatorisch:** Konzepte diensteweise vervollständigen und Wiederanlaufreihenfolge festlegen. -- **Technisch:** Abhängigkeits-/Reihenfolgeplan in Restore-Runbooks abbilden. Referenz: BL-OPS-05, BL-OPS-08. -- **Typische Nachweise:** Restore-Runbooks mit Abhängigkeitsreihenfolge. -- **Vorlage:** R10; VA-05; BL-OPS-05 -- **Ressourcen:** IT-Betrieb; gering–mittel. -- **AL-Filter:** AL2 + AL3 - -### 5.2.9-H1 — [HOCH] -**Anforderung:** Backup-/Wiederherstellungskonzepte werden methodisch in regelmäßigen Abständen überprüft. (A) -- **Organisatorisch:** Review-Turnus für die Konzepte festlegen. -- **Technisch:** Abgleich Konzept↔tatsächliche Systemlandschaft/Backup-Jobs. Referenz: BL-OPS-05. -- **Typische Nachweise:** Review-Protokolle der Backup-Konzepte. -- **Vorlage:** R10; VA-05; BL-OPS-05 -- **Ressourcen:** IT-Betrieb; gering. -- **AL-Filter:** AL3 (hoher Schutzbedarf) - -### 5.2.9-H2 — [HOCH] -**Anforderung:** Die grundsätzliche Wiederherstellbarkeit wird berücksichtigt und getestet. (I, A) -- **Organisatorisch:** Restore-Tests einplanen (Stichproben/Testsysteme). -- **Technisch:** Regelmäßige Test-Restores auf Testsystem, Integritätsprüfung der Rücksicherung. Referenz: BL-OPS-05. -- **Typische Nachweise:** Restore-Testprotokolle. -- **Vorlage:** R10; VA-05; BL-OPS-05 -- **Ressourcen:** IT-Betrieb; gering–mittel. -- **AL-Filter:** AL3 (hoher Schutzbedarf) - -### 5.2.9-V1 — [SEHR HOCH] -**Anforderung:** (Zusätzliche) Backups über Offline-Verfahren, immutable Backups oder isolierte IAM-Lösung. (I, A) -- **Organisatorisch:** Ransomware-resistente Backup-Linie für sehr hohen Schutzbedarf festlegen. -- **Technisch:** Air-Gap/Offline-Kopien, Immutable-Storage, getrennte/isolierte Backup-Identitäten. Referenz: BL-OPS-05. -- **Typische Nachweise:** Konfiguration Offline-/Immutable-Backup, getrennte IAM-Nachweise. -- **Vorlage:** R10; VA-05; BL-OPS-05 -- **Ressourcen:** IT-Betrieb; mittel–hoch. -- **AL-Filter:** AL3 (sehr hoher Schutzbedarf) - -### 5.2.9-V2 — [SEHR HOCH] -**Anforderung:** Wiederherstellungsverfahren werden methodisch in regelmäßigen Abständen technisch getestet. (I, A) -- **Organisatorisch:** Verbindliches Restore-Testprogramm mit Auswertung etablieren. -- **Technisch:** Vollständige technische Restore-Tests inkl. Funktionsprüfung des wiederhergestellten Dienstes. Referenz: BL-OPS-05. -- **Typische Nachweise:** Technische Restore-Testberichte. -- **Vorlage:** R10; VA-05; BL-OPS-05 -- **Ressourcen:** IT-Betrieb; mittel. -- **AL-Filter:** AL3 (sehr hoher Schutzbedarf) - -### 5.2.9-V3 — [SEHR HOCH] -**Anforderung:** Geografische Redundanz wird in Backup-/Wiederherstellungskonzepten berücksichtigt. (A) -- **Organisatorisch:** Vorgabe zur räumlich getrennten Aufbewahrung von Sicherungen. -- **Technisch:** Backup-Replikation an zweiten Standort/Region, georedundante Ablage. Referenz: BL-OPS-05. -- **Typische Nachweise:** Nachweis georedundanter Backup-Ablage. -- **Vorlage:** R10; VA-05; BL-OPS-05 -- **Ressourcen:** IT-Betrieb; mittel–hoch. -- **AL-Filter:** AL3 (sehr hoher Schutzbedarf) - -## Control 5.3.1 — Sichere Entwicklung und Beschaffung von IT-Diensten - -### 5.3.1-M1 — [MUSS] -**Anforderung:** Die mit Design und Entwicklung eines IT-Dienstes verbundenen Informationssicherheitsanforderungen sind bestimmt und berücksichtigt. -- **Organisatorisch:** Security-by-Design im Entwicklungsprozess verankern (Sicherheitsanforderungen früh definieren, Freigaben). -- **Technisch:** Sichere Entwicklungsstandards, Threat Modeling, Code-/Konfigurationsvorgaben. Referenz: BL-OPS-02 (Umgebungstrennung), BL-CRY-01. -- **Typische Nachweise:** Sicherheitsanforderungen im Design, Secure-Development-Vorgaben. -- **Vorlage:** R11; VA-16; BL-OPS-02 -- **Ressourcen:** Entwicklung/ISB; mittel. -- **AL-Filter:** AL2 + AL3 - -### 5.3.1-M2 — [MUSS] -**Anforderung:** Die mit Beschaffung/Erweiterung von IT-Diensten und -Komponenten verbundenen Sicherheitsanforderungen sind bestimmt und berücksichtigt. -- **Organisatorisch:** Sicherheitsanforderungen in Beschaffungs-/Ausschreibungsprozess integrieren (Kriterien, Freigabe). -- **Technisch:** Anforderungskataloge/Sicherheitschecklisten für Beschaffung, Prüfung vor Inbetriebnahme. Referenz: BL-OPS-01. -- **Typische Nachweise:** Beschaffungsanforderungen mit Sicherheitskriterien, Freigabedokumente. -- **Vorlage:** R11; VA-16 -- **Ressourcen:** Einkauf/IT/ISB; gering–mittel. -- **AL-Filter:** AL2 + AL3 - -### 5.3.1-M3 — [MUSS] -**Anforderung:** Informationssicherheitsanforderungen bei Änderungen an entwickelten IT-Diensten werden berücksichtigt. -- **Organisatorisch:** Änderungen an Eigenentwicklungen an den Change-/Secure-Development-Prozess binden. -- **Technisch:** Sicherheitsprüfung/-tests bei Änderungen (SAST/DAST, Review). Referenz: BL-OPS-01, BL-OPS-02. -- **Typische Nachweise:** Change-Records mit Sicherheitsprüfung, Testresultate. -- **Vorlage:** R11; VA-16 -- **Ressourcen:** Entwicklung; mittel. -- **AL-Filter:** AL2 + AL3 - -### 5.3.1-M4 — [MUSS] -**Anforderung:** Systemabnahmetests werden unter Berücksichtigung der Informationssicherheitsanforderungen durchgeführt. -- **Organisatorisch:** Sicherheitskriterien als Abnahmebedingung festlegen. -- **Technisch:** Security-Testfälle in Abnahmetests, Nachweis vor Go-Live. Referenz: BL-OPS-02. -- **Typische Nachweise:** Abnahmetestprotokolle mit Sicherheitskriterien, Freigabe. -- **Vorlage:** R11; VA-16 -- **Ressourcen:** Entwicklung/QA; mittel. -- **AL-Filter:** AL2 + AL3 - -### 5.3.1-S1 — [SOLL] -**Anforderung:** Anforderungsspezifikationen werden erstellt. -- **Organisatorisch:** Verbindliche Spezifikation inkl. Sicherheitsanforderungen fordern. -- **Technisch:** Strukturierte Anforderungsdokumentation mit Sicherheitsabschnitt. Referenz: BL-OPS-02. -- **Typische Nachweise:** Anforderungsspezifikationen. -- **Vorlage:** R11; VA-16 -- **Ressourcen:** Entwicklung; gering. -- **AL-Filter:** AL2 + AL3 - -### 5.3.1-S2 — [SOLL] -**Anforderung:** Anforderungsspezifikationen werden gegen die Informationssicherheitsanforderungen geprüft. -- **Organisatorisch:** Review der Spezifikation gegen Sicherheitsvorgaben etablieren. -- **Technisch:** Security-Review/Checkliste in der Spezifikationsphase. Referenz: BL-OPS-02. -- **Typische Nachweise:** Review-Vermerk, Prüfcheckliste. -- **Vorlage:** R11; VA-16 -- **Ressourcen:** ISB/Entwicklung; gering. -- **AL-Filter:** AL2 + AL3 - -### 5.3.1-S3 — [SOLL] -**Anforderung:** Der IT-Dienst wird vor Produktivnutzung auf Einhaltung der Spezifikationen geprüft. -- **Organisatorisch:** Freigabe vor Produktivsetzung an Spezifikationskonformität binden. -- **Technisch:** Abnahme-/Konformitätstests gegen Spezifikation. Referenz: BL-OPS-02. -- **Typische Nachweise:** Konformitäts-/Abnahmeberichte. -- **Vorlage:** R11; VA-16 -- **Ressourcen:** QA/Entwicklung; gering–mittel. -- **AL-Filter:** AL2 + AL3 - -### 5.3.1-S4 — [SOLL] -**Anforderung:** Die Nutzung von Produktivdaten zu Testzwecken wird soweit möglich vermieden. -- **Organisatorisch:** Vorgabe zur Vermeidung von Produktivdaten in Tests; Ausnahmen genehmigungspflichtig. -- **Technisch:** Anonymisierung/Pseudonymisierung oder synthetische Testdaten. Referenz: BL-OPS-02. -- **Typische Nachweise:** Testdatenkonzept, Anonymisierungsnachweis. -- **Vorlage:** R11; VA-16 -- **Ressourcen:** Entwicklung; gering–mittel. -- **AL-Filter:** AL2 + AL3 - -### 5.3.1-S5 — [SOLL] -**Anforderung:** Testsysteme erhalten Schutzmaßnahmen vergleichbar zur Produktivumgebung, wenn Produktivdaten genutzt werden. -- **Organisatorisch:** Bei Produktivdaten im Test gleichwertigen Schutz vorschreiben. -- **Technisch:** Härtung, Zugriffskontrolle und Verschlüsselung der Testumgebung analog Produktion. Referenz: BL-OPS-02. -- **Typische Nachweise:** Schutzmaßnahmen-Nachweis Testumgebung. -- **Vorlage:** R11; VA-16 -- **Ressourcen:** IT-Betrieb/Entwicklung; mittel. -- **AL-Filter:** AL2 + AL3 - -### 5.3.1-V1 — [SEHR HOCH] -**Anforderung:** Die Sicherheit zweckgebauter/wesentlich angepasster Software wird bei Inbetriebnahme, wesentlichen Änderungen oder regelmäßig getestet. (C, I, A) -- **Organisatorisch:** Verbindliche Security-Tests (inkl. Pentest) an definierten Zeitpunkten festlegen. -- **Technisch:** Penetrationstests, SAST/DAST, Dependency-/Supply-Chain-Prüfung. Referenz: BL-OPS-07. -- **Typische Nachweise:** Pentest-/Security-Testberichte, Behebungsnachweise. -- **Vorlage:** R11; VA-16; BL-OPS-07 -- **Ressourcen:** ggf. externer Pentest (Budget); mittel–hoch. -- **AL-Filter:** AL3 (sehr hoher Schutzbedarf) - -## Control 5.3.2 — Sicherheit von Netzdiensten (Bereitstellung) - -### 5.3.2-M1 — [MUSS] -**Anforderung:** Anforderungen an die Informationssicherheit von Netzdiensten sind bestimmt und erfüllt. -- **Organisatorisch:** Sicherheitsanforderungen je bereitgestelltem Netzdienst festlegen (Verschlüsselung, Auth, Verfügbarkeit). -- **Technisch:** Sichere Konfiguration der Netzdienste, Zugriffskontrolle, Verschlüsselung. Referenz: BL-NET-01, BL-CRY-02. -- **Typische Nachweise:** Sicherheitsanforderungen Netzdienste, Konfigurationsnachweise. -- **Vorlage:** R11; VA-16; BL-NET-01 -- **Ressourcen:** IT-Betrieb/Netzwerk; gering–mittel. -- **AL-Filter:** AL2 + AL3 - -### 5.3.2-S1 — [SOLL] -**Anforderung:** Ein Verfahren zur Absicherung und Nutzung von Netzdiensten ist definiert und umgesetzt. -- **Organisatorisch:** Betriebs-/Nutzungsverfahren für Netzdienste dokumentieren. -- **Technisch:** Standardhärtung, Monitoring und Freigabeprozess für Netzdienste. Referenz: BL-NET-01, BL-NET-02. -- **Typische Nachweise:** Netzdienst-Verfahren, Härtungsstandard. -- **Vorlage:** R11; VA-16; BL-NET-02 -- **Ressourcen:** IT-Betrieb; gering. -- **AL-Filter:** AL2 + AL3 - -### 5.3.2-S2 — [SOLL] -**Anforderung:** Die Anforderungen werden in Form von SLAs vereinbart. -- **Organisatorisch:** Sicherheits-/Verfügbarkeitsanforderungen als SLA (intern/mit Provider) festhalten. -- **Technisch:** SLA-Parameter überwachen. Referenz: BL-NET-01. -- **Typische Nachweise:** SLA-Dokumente, SLA-Monitoring. -- **Vorlage:** R11; VA-16 -- **Ressourcen:** IT/Einkauf; gering. -- **AL-Filter:** AL2 + AL3 - -### 5.3.2-S3 — [SOLL] -**Anforderung:** Angemessene Redundanzlösungen sind umgesetzt. -- **Organisatorisch:** Redundanzbedarf je Netzdienst festlegen. -- **Technisch:** Redundante Anbindungen/Komponenten, Failover. Referenz: BL-NET-01. -- **Typische Nachweise:** Redundanzkonzept, Failover-Nachweis. -- **Vorlage:** R11; VA-16 -- **Ressourcen:** IT-Betrieb/Netzwerk; mittel. -- **AL-Filter:** AL2 + AL3 - -### 5.3.2-H1 — [HOCH] -**Anforderung:** Verfahren zur Überwachung der Qualität des Netzverkehrs sind definiert und werden durchgeführt. (A) -- **Organisatorisch:** Überwachungsvorgaben (Verfügbarkeit, Qualität) festlegen. -- **Technisch:** Traffic-Flow-Analysen, Verfügbarkeits-/Latenzmessung, Alerting. Referenz: BL-NET-01. -- **Typische Nachweise:** Monitoring-Konfiguration, Qualitäts-/Verfügbarkeitsreports. -- **Vorlage:** R11; VA-16; BL-NET-01 -- **Ressourcen:** Netz-Monitoring-Tool (Beschaffung möglich); mittel. -- **AL-Filter:** AL3 (hoher Schutzbedarf) - -## Control 5.3.3 — Beendigung von IT-Dienstleistungsverhältnissen - -### 5.3.3-S1 — [SOLL] -**Anforderung:** Eine Beschreibung des Beendigungsprozesses ist vorhanden, an Änderungen angepasst und vertraglich geregelt. -- **Organisatorisch:** Exit-/Offboarding-Prozess für IT-Dienste definieren (Datenrückgabe, sichere Löschung, Rechteentzug) und vertraglich verankern. -- **Technisch:** Nachweisbare Datenrückgabe/-löschung, Widerruf von Zugängen und Schnittstellen. Referenz: BL-OPS-01, BL-IAM-05. -- **Typische Nachweise:** Exit-/Beendigungskonzept, Vertragsklausel, Lösch-/Rückgabenachweis. -- **Vorlage:** R11; BL-OPS-01 -- **Ressourcen:** IT/Einkauf/ISB; gering–mittel. -- **AL-Filter:** AL2 + AL3 - -## Control 5.3.4 — Mandantentrennung bei IT-Diensten - -### 5.3.4-M1 — [MUSS] -**Anforderung:** Eine wirksame Trennung (z. B. Mandantentrennung) verhindert den Zugriff unbefugter Nutzer anderer Organisationen auf eigene Informationen. -- **Organisatorisch:** Trennungsanforderung bei geteilt genutzten (Cloud-)Diensten festlegen und beim Anbieter einfordern. -- **Technisch:** Logische/physische Mandantentrennung, getrennte Berechtigungen und ggf. Verschlüsselung mit eigener Schlüsselhoheit. Referenz: BL-NET-01, BL-CRY-03. -- **Typische Nachweise:** Nachweis Mandantentrennung (Anbieter), Berechtigungs-/Trennungskonzept. -- **Vorlage:** R12; VA-11; BL-NET-01 -- **Ressourcen:** IT/ISB; gering–mittel. -- **AL-Filter:** AL2 + AL3 - -### 5.3.4-S1 — [SOLL] -**Anforderung:** Das Trennungskonzept des Anbieters ist dokumentiert und an Änderungen angepasst. -- **Organisatorisch:** Trennungskonzept des Providers einholen, bewerten und bei Änderungen aktualisieren. -- **Technisch:** Abgleich des Anbieterkonzepts mit eigenen Schutzanforderungen (Isolationsmechanismen, Datenhaltung). Referenz: BL-NET-01. -- **Typische Nachweise:** Dokumentiertes Anbieter-Trennungskonzept, Bewertung/Review. -- **Vorlage:** R12; VA-11 -- **Ressourcen:** ISB; gering. -- **AL-Filter:** AL2 + AL3 - -## Control 5.3.4-KI — Nutzung von KI-/GenAI-Diensten - -### 5.3.4-KI-M1 — [MUSS] -**Anforderung:** Der Einsatz von KI-/GenAI-Diensten ist geregelt; es werden nur freigegebene Dienste genutzt. -- **Organisatorisch:** KI-Nutzungsrichtlinie mit Freigabeprozess und Positivliste zugelassener Dienste etablieren. -- **Technisch:** Nutzung nicht freigegebener KI-Dienste über Web-Proxy/CASB einschränken; Freigabeliste technisch durchsetzen. Referenz: BL-NET-02 (Web-/Dienstfreigaben). -- **Typische Nachweise:** KI-Richtlinie, Liste freigegebener Dienste, Proxy-/CASB-Regeln. -- **Vorlage:** R12; VA-11; BL-NET-02 -- **Ressourcen:** ISB/IT-Betrieb; gering–mittel. -- **AL-Filter:** AL2 + AL3 - -### 5.3.4-KI-M2 — [MUSS] -**Anforderung:** Die Eingabe vertraulicher/personenbezogener Informationen in nicht freigegebene KI-Dienste ist untersagt; zulässige Datenklassen je Dienst sind definiert. -- **Organisatorisch:** Zulässige Datenklassen je freigegebenem Dienst festlegen und Verbot für nicht freigegebene Dienste kommunizieren. -- **Technisch:** DLP-Regeln zur Erkennung/Blockierung sensibler Eingaben an KI-Endpunkte. Referenz: BL-NET-02. -- **Typische Nachweise:** Datenklassen-Mapping je Dienst, DLP-Regeln, Sensibilisierungsnachweis. -- **Vorlage:** R12; VA-11 -- **Ressourcen:** ISB/IT-Betrieb; ggf. DLP (Beschaffung möglich); gering–mittel. -- **AL-Filter:** AL2 + AL3 - -### 5.3.4-KI-M3 — [MUSS] -**Anforderung:** Bei freigegebenen KI-Diensten ist vertraglich sichergestellt, dass Eingaben nicht zum Training genutzt oder weitergegeben werden. -- **Organisatorisch:** Vertrags-/AVV-Prüfung auf No-Training- und Weitergabeklauseln; nur Dienste mit passenden Zusicherungen freigeben. -- **Technisch:** Enterprise-/Business-Tarife mit deaktiviertem Training und Datenresidenz nutzen. Referenz: BL-CRY-03 (Datenhoheit). -- **Typische Nachweise:** Vertrag/AVV mit No-Training-Klausel, Konfigurationsnachweis (Training deaktiviert). -- **Vorlage:** R12; VA-11 -- **Ressourcen:** Einkauf/ISB/Datenschutz; gering. -- **AL-Filter:** AL2 + AL3 - -### 5.3.4-KI-S1 — [SOLL] -**Anforderung:** Ergebnisse von KI-Diensten werden vor geschäftskritischer Verwendung geprüft (Human-in-the-Loop); der Einsatz wird dokumentiert und regulatorische Anforderungen (z. B. EU AI Act) berücksichtigt. -- **Organisatorisch:** Human-in-the-Loop-Vorgabe für kritische Ergebnisse, KI-Einsatzregister und Abgleich mit regulatorischen Pflichten (Risikoklassifizierung nach EU AI Act). -- **Technisch:** Kennzeichnung/Protokollierung von KI-generierten Inhalten, Freigabe-Workflows vor produktiver Nutzung. Referenz: BL-OPS-04 (Protokollierung). -- **Typische Nachweise:** KI-Einsatzregister, Prüf-/Freigabevermerke, AI-Act-Einordnung. -- **Vorlage:** R12; VA-11 -- **Ressourcen:** ISB/Fachbereich/Datenschutz; gering–mittel. -- **AL-Filter:** AL2 + AL3 - - ---- - -# Kapitel 6–7 — Lieferanten & Compliance/Datenschutz - -## Control 6.1.1 — Sicherheit bei Auftragnehmern/Lieferanten (Risikobewertung & Verträge) - -### 6.1.1-M1 — [MUSS] -**Anforderung:** Auftragnehmer und Partner werden einer Sicherheitsrisikobewertung unterzogen. -- **Organisatorisch:** Lieferantenverzeichnis führen und jeden sicherheitsrelevanten Auftragnehmer vor Beauftragung sowie regelmäßig anhand eines standardisierten Risikofragebogens (Kritikalität, verarbeitete Informationswerte, Zugriffsart) bewerten; Verantwortlichkeit im Einkauf/ISB verankern. -- **Technisch:** Bewertungen in einem GRC-/Lieferantenmanagement-Tool oder strukturiert im Ticket-/Vertragssystem erfassen, mit Wiedervorlage/Reassessment-Fristen. -- **Typische Nachweise:** Ausgefüllte Risikobewertungen je Lieferant, Lieferantenverzeichnis mit Kritikalitätseinstufung, Nachweis der Wiedervorlage. -- **Vorlage:** R13; VA-10 -- **Ressourcen:** ISB/Einkauf, moderater Aufwand; GRC-/Lieferantentool optional (Beschaffung möglich). -- **AL-Filter:** AL2 + AL3 - -### 6.1.1-M2 — [MUSS] -**Anforderung:** Ein angemessenes Informationssicherheitsniveau wird durch vertragliche Vereinbarungen mit Auftragnehmern und Partnern sichergestellt. -- **Organisatorisch:** Standardklauseln zur Informationssicherheit (Schutzniveau, Meldepflichten, Auditrechte, Unterauftragnehmer) in Verträge/AGB aufnehmen; Freigabe durch Recht/ISB vor Vertragsschluss. -- **Technisch:** Vertragsvorlagen mit IS-Klauselkatalog im Vertragsmanagement hinterlegen; Versionsverwaltung der Klauseln. -- **Typische Nachweise:** Unterzeichnete Verträge mit IS-Klauseln, Klauselkatalog/Vertragsmuster, Freigabevermerk. -- **Vorlage:** R13; VA-10 -- **Ressourcen:** Recht/Einkauf/ISB, initial erhöht (Klauselerstellung), danach gering. -- **AL-Filter:** AL2 + AL3 - -### 6.1.1-M3 — [MUSS] -**Anforderung:** Sofern zutreffend, werden vertragliche Vereinbarungen mit Auftraggebern/Kunden an Auftragnehmer und Partner weitergegeben. -- **Organisatorisch:** Kundenspezifische Sicherheitsanforderungen (Flow-down) identifizieren und verpflichtend in die Unterverträge übernehmen; Zuordnung Kundenanforderung → Lieferantenvertrag dokumentieren. -- **Technisch:** Anforderungsmatrix/Mapping-Tabelle im Vertrags- oder Anforderungsmanagement pflegen. -- **Typische Nachweise:** Flow-down-Klauseln in Unterverträgen, Mapping Kunden-/Lieferantenanforderungen. -- **Vorlage:** R13 -- **Ressourcen:** Recht/Einkauf, geringer bis moderater Aufwand. -- **AL-Filter:** AL2 + AL3 - -### 6.1.1-S1 — [SOLL] -**Anforderung:** Auftragnehmer und Partner sind vertraglich verpflichtet, Anforderungen an ein angemessenes Informationssicherheitsniveau an ihre Unterauftragnehmer weiterzugeben. -- **Organisatorisch:** Verpflichtung zur Weitergabe der IS-Anforderungen an Unterauftragnehmer als Standardklausel festlegen; Genehmigungspflicht für Unterbeauftragung vereinbaren. -- **Technisch:** Klausel im Vertragsmuster hinterlegen; Register der zugelassenen Unterauftragnehmer. -- **Typische Nachweise:** Vertragsklausel zur Weitergabe, Liste/Freigaben von Unterauftragnehmern. -- **Vorlage:** R13; VA-10 -- **Ressourcen:** Recht/Einkauf, geringer Aufwand. -- **AL-Filter:** AL2 + AL3 - -### 6.1.1-S2 — [SOLL] -**Anforderung:** Leistungsberichte und Dokumente von Auftragnehmern und Partnern werden geprüft. -- **Organisatorisch:** Regelmäßige Auswertung von Leistungs-/Service-Berichten (SLA-Erfüllung, Sicherheitsnachweise) durch die verantwortliche Fachstelle; Abweichungen nachverfolgen. -- **Technisch:** Berichtseingang und Prüfung im Lieferantenmanagement-/Ticketsystem dokumentieren, mit Fristen. -- **Typische Nachweise:** Geprüfte Leistungsberichte, Prüfvermerke, Maßnahmen-/Eskalationsnachweise. -- **Vorlage:** R13 -- **Ressourcen:** Fachbereich/Einkauf, laufender geringer Aufwand. -- **AL-Filter:** AL2 + AL3 - -### 6.1.1-H1 — [HOCH] -**Anforderung:** Es wird nachgewiesen, dass das Informationssicherheitsniveau des Lieferanten dem Schutzbedarf angemessen ist (z. B. geprüfter Fragebogen/Selbstauskunft, Attestierung, Zertifikat, Lieferantenaudit). -- **Organisatorisch:** Für Lieferanten mit hohem Schutzbedarf verbindlichen Nachweistyp festlegen (Selbstauskunft mit Plausibilitätsprüfung, ISO-27001-/TISAX-Nachweis oder Audit) und einholen/bewerten. -- **Technisch:** Nachweise (Zertifikate, ausgefüllte Fragebögen) revisionssicher im GRC-/Lieferantentool ablegen, mit Gültigkeitsüberwachung. -- **Typische Nachweise:** Geprüfte Selbstauskunft, Zertifikat/Attestierung, Auditbericht, Bewertungsvermerk. -- **Vorlage:** R13 -- **Ressourcen:** ISB, erhöhter Aufwand; ggf. Auditkosten (Budget). -- **AL-Filter:** AL3 (hoher Schutzbedarf) - -### 6.1.1-H2 — [HOCH] -**Anforderung:** Der Grad der Erfüllung geforderter Nachweise durch den Lieferanten wird dokumentiert, regelmäßig und bei Änderungen überprüft und überwacht. -- **Organisatorisch:** Erfüllungsgrad je geforderten Nachweis dokumentieren und in einem Reassessment-Zyklus sowie anlassbezogen (Vertrags-/Leistungsänderung) neu bewerten. -- **Technisch:** Statusübersicht (offen/erfüllt/abgelaufen) im GRC-Tool mit automatischen Erinnerungen. -- **Typische Nachweise:** Nachweis-Statusübersicht, Reassessment-Protokolle, Änderungshistorie. -- **Vorlage:** R13 -- **Ressourcen:** ISB, laufender moderater Aufwand. -- **AL-Filter:** AL3 (hoher Schutzbedarf) - -### 6.1.1-H3 — [HOCH] -**Anforderung:** Die Einhaltung vertraglicher Vereinbarungen durch den Lieferanten wird geprüft, dokumentiert, regelmäßig und bei Änderungen überprüft und überwacht. -- **Organisatorisch:** Vertragskonformität (IS-Klauseln, SLAs, Meldepflichten) regelmäßig prüfen; Feststellungen mit Maßnahmen und Eskalation verfolgen. -- **Technisch:** Prüf- und Maßnahmenverfolgung im Lieferanten-/GRC-Tool; Verknüpfung Vertrag ↔ Prüfergebnis. -- **Typische Nachweise:** Prüfprotokolle Vertragskonformität, Maßnahmenliste, Eskalationsnachweise. -- **Vorlage:** R13 -- **Ressourcen:** ISB/Einkauf, laufender moderater Aufwand. -- **AL-Filter:** AL3 (hoher Schutzbedarf) - -### 6.1.1-V1 — [SEHR HOCH] -**Anforderung:** Das angemessene Informationssicherheitsniveau sollte durch ein Drittparteien-Audit (angemessenes TISAX-Label o. Ä.) oder ein angemessenes Lieferantenaudit nachgewiesen werden. Ohne Audit muss die Leitung eine risikobasierte Entscheidung zur Fortführung treffen; ein Nachweis dieser Entscheidung existiert. -- **Organisatorisch:** Für Lieferanten mit sehr hohem Schutzbedarf ein passendes TISAX-Label bzw. Lieferantenaudit einfordern; liegt keines vor, dokumentierte, risikobasierte Leitungsentscheidung (Risk Acceptance) herbeiführen. -- **Technisch:** Label-/Auditnachweise und Leitungsentscheid revisionssicher im GRC-Tool ablegen, mit Gültigkeits- und Wiedervorlagesteuerung. -- **Typische Nachweise:** TISAX-Label/Auditbericht, dokumentierte Leitungsentscheidung mit Risikobegründung. -- **Vorlage:** R13 -- **Ressourcen:** Leitung/ISB, hoher Aufwand; Auditkosten (Budget). -- **AL-Filter:** AL3 (sehr hoher Schutzbedarf) - -### 6.1.1-V2 — [SEHR HOCH] -**Anforderung:** Vertragliche Verpflichtungen gegenüber Kunden zur Transparenz von Lieferkettenrisiken werden erfüllt. -- **Organisatorisch:** Kundenanforderungen zur Lieferketten-Transparenz identifizieren und ein Verfahren zur Offenlegung relevanter Lieferkettenrisiken (inkl. Unterauftragnehmer) etablieren. -- **Technisch:** Lieferketten-/Risikoregister mit Zuordnung zu Kundenverträgen; Reporting-Auszüge für Kunden generierbar. -- **Typische Nachweise:** Lieferkettenübersicht, an Kunden erbrachte Transparenznachweise, Vertragsbezug. -- **Vorlage:** R13 -- **Ressourcen:** ISB/Einkauf, erhöhter Aufwand. -- **AL-Filter:** AL3 (sehr hoher Schutzbedarf) - -## Control 6.1.2 — Vertraulichkeitsvereinbarungen (NDA) bei Informationsweitergabe - -### 6.1.2-M1 — [MUSS] -**Anforderung:** Die Vertraulichkeitsanforderungen sind bestimmt und erfüllt. -- **Organisatorisch:** Anlässe und Umfang von Vertraulichkeitsverpflichtungen (welche Informationsklassen, welche Empfänger) bestimmen und in einer Regelung festhalten; Umsetzung sicherstellen. -- **Technisch:** Verknüpfung mit dem Klassifizierungsschema; NDA-Pflicht als Attribut in Vertrags-/Partnerstammdaten. -- **Typische Nachweise:** Dokumentierte Vertraulichkeitsanforderungen, Bezug zum Klassifizierungsschema. -- **Vorlage:** R13; VA-10 -- **Ressourcen:** ISB/Recht, geringer bis moderater Aufwand. -- **AL-Filter:** AL2 + AL3 - -### 6.1.2-M2 — [MUSS] -**Anforderung:** Anforderungen und Verfahren zur Anwendung von Vertraulichkeitsvereinbarungen sind allen Personen bekannt, die schutzbedürftige Informationen weitergeben. -- **Organisatorisch:** Verfahren zur NDA-Anwendung kommunizieren (Onboarding, Richtlinie, Schulung); Ansprechpartner für den NDA-Abschluss benennen. -- **Technisch:** Richtlinie und NDA-Vorlagen im Intranet/Dokumentenmanagement zugänglich machen. -- **Typische Nachweise:** Veröffentlichte Richtlinie/Arbeitsanweisung, Schulungs-/Kenntnisnahmenachweise. -- **Vorlage:** R13 -- **Ressourcen:** ISB, geringer Aufwand. -- **AL-Filter:** AL2 + AL3 - -### 6.1.2-M3 — [MUSS] -**Anforderung:** Gültige Vertraulichkeitsvereinbarungen werden vor der Weitergabe schutzbedürftiger Informationen abgeschlossen. -- **Organisatorisch:** Verbindliche Regel „kein Informationsaustausch ohne gültiges NDA"; NDA-Abschluss als Voraussetzung im Freigabe-/Beschaffungsprozess verankern. -- **Technisch:** NDA-Status als Gate im Workflow (Vertrags-/Ticketsystem) prüfen, bevor Zugriff/Weitergabe erfolgt. -- **Typische Nachweise:** Abgeschlossene, gültige NDAs vor Austauschbeginn, Freigabe-Workflow mit NDA-Prüfung. -- **Vorlage:** R13 -- **Ressourcen:** Recht/Fachbereich, laufender geringer Aufwand. -- **AL-Filter:** AL2 + AL3 - -### 6.1.2-M4 — [MUSS] -**Anforderung:** Die Anforderungen und Verfahren zur Nutzung von Vertraulichkeitsvereinbarungen und zum Umgang mit schutzbedürftigen Informationen werden regelmäßig überprüft. -- **Organisatorisch:** NDA-Verfahren und -Vorlagen in einem festen Turnus sowie bei Rechtsänderungen überprüfen und aktualisieren; Review dokumentieren. -- **Technisch:** Review-Termine/Versionsstände im Dokumentenmanagement mit Wiedervorlage steuern. -- **Typische Nachweise:** Review-Protokolle, Versionshistorie der NDA-Vorlagen/-Richtlinie. -- **Vorlage:** R13 -- **Ressourcen:** ISB/Recht, geringer wiederkehrender Aufwand. -- **AL-Filter:** AL2 + AL3 - -### 6.1.2-S1 — [SOLL] -**Anforderung:** Vorlagen für Vertraulichkeitsvereinbarungen sind vorhanden und auf rechtliche Anwendbarkeit geprüft. -- **Organisatorisch:** Standard-NDA-Vorlagen (ein-/beidseitig) bereitstellen und durch die Rechtsfunktion auf Anwendbarkeit (Jurisdiktion, Durchsetzbarkeit) prüfen lassen. -- **Technisch:** Freigegebene Vorlagen zentral im Dokumentenmanagement, mit Kennzeichnung der geprüften Version. -- **Typische Nachweise:** Freigegebene NDA-Vorlagen, rechtlicher Prüfvermerk. -- **Vorlage:** R13; VA-10 -- **Ressourcen:** Recht, initial moderat. -- **AL-Filter:** AL2 + AL3 - -### 6.1.2-S2 — [SOLL] -**Anforderung:** Vertraulichkeitsvereinbarungen umfassen beteiligte Personen/Organisationen, Art der Informationen, Gegenstand, Gültigkeitsdauer und Verantwortlichkeiten der verpflichteten Partei. -- **Organisatorisch:** Mindestinhalte für NDAs verbindlich festlegen und in die Vorlage aufnehmen (Parteien, Informationsarten, Zweck, Laufzeit, Pflichten). -- **Technisch:** Vorlagen-Checkliste/Formularfelder zur Vollständigkeitsprüfung. -- **Typische Nachweise:** NDA-Vorlage mit Pflichtinhalten, Beispielverträge. -- **Vorlage:** R13 -- **Ressourcen:** Recht/ISB, geringer Aufwand. -- **AL-Filter:** AL2 + AL3 - -### 6.1.2-S3 — [SOLL] -**Anforderung:** Vertraulichkeitsvereinbarungen enthalten Regelungen zum Umgang mit schutzbedürftigen Informationen über die Vertragsbeziehung hinaus. -- **Organisatorisch:** Nachvertragliche Pflichten (Rückgabe/Löschung, Fortdauer der Geheimhaltung) verbindlich in NDAs regeln. -- **Technisch:** Entsprechende Standardklausel in der Vorlage hinterlegen. -- **Typische Nachweise:** NDA-Klausel zu nachvertraglichen Pflichten. -- **Vorlage:** R13 -- **Ressourcen:** Recht, geringer Aufwand. -- **AL-Filter:** AL2 + AL3 - -### 6.1.2-S4 — [SOLL] -**Anforderung:** Möglichkeiten zum Nachweis der Einhaltung (z. B. Prüfung durch unabhängige Dritte oder Auditrechte) sind definiert. -- **Organisatorisch:** Prüf-/Auditrechte oder Nachweispflichten zur NDA-Einhaltung in der Vereinbarung verankern. -- **Technisch:** Klausel in Vorlage; Nachverfolgung ausgeübter Prüfrechte im Vertragsmanagement. -- **Typische Nachweise:** Auditrechtsklausel, ggf. durchgeführte Prüfungen/Nachweise. -- **Vorlage:** R13 -- **Ressourcen:** Recht/ISB, geringer Aufwand. -- **AL-Filter:** AL2 + AL3 - -### 6.1.2-S5 — [SOLL] -**Anforderung:** Ein Prozess zur Überwachung der Gültigkeitsdauer temporärer Vertraulichkeitsvereinbarungen und zur rechtzeitigen Verlängerung ist definiert und umgesetzt. -- **Organisatorisch:** Fristenmanagement für befristete NDAs mit definierter Verantwortlichkeit und Verlängerungs-/Nachfassprozess etablieren. -- **Technisch:** Ablaufüberwachung mit automatischen Erinnerungen im Vertragsmanagement/Kalender. -- **Typische Nachweise:** Fristenübersicht mit Ablaufdaten, Erinnerungs-/Verlängerungsnachweise. -- **Vorlage:** R13 -- **Ressourcen:** Einkauf/Recht, geringer laufender Aufwand. -- **AL-Filter:** AL2 + AL3 - -## Control 6.1.3 — Sicherheit externer IT-Dienste & geteilte Verantwortlichkeiten - -### 6.1.3-M1 — [MUSS] -**Anforderung:** Die betroffenen IT-Dienste sind identifiziert. -- **Organisatorisch:** Alle genutzten externen IT-Dienste (Cloud/SaaS/Managed Services) erfassen und einem Verantwortlichen zuordnen; Bezug zu verarbeiteten Informationswerten herstellen. -- **Technisch:** Dienstinventar im Asset-/CMDB- oder GRC-Tool führen, verknüpft mit dem Asset-Register. -- **Typische Nachweise:** Inventar externer IT-Dienste, Zuordnung zu Assets/Verantwortlichen. -- **Vorlage:** R13; VA-10 -- **Ressourcen:** IT/ISB, moderater Aufwand. -- **AL-Filter:** AL2 + AL3 - -### 6.1.3-M2 — [MUSS] -**Anforderung:** Die für den IT-Dienst relevanten Sicherheitsanforderungen sind bestimmt. -- **Organisatorisch:** Je Dienst die Sicherheitsanforderungen aus Schutzbedarf und Klassifizierung ableiten und dokumentieren (Vertraulichkeit, Integrität, Verfügbarkeit, Standort/Rechtsraum). -- **Technisch:** Anforderungskatalog je Dienst hinterlegen; Abgleich mit Konfigurations-Baselines des Dienstes. -- **Typische Nachweise:** Dokumentierte Sicherheitsanforderungen je Dienst, Schutzbedarfsableitung. -- **Vorlage:** R13 -- **Ressourcen:** ISB/Fachbereich, moderater Aufwand. -- **AL-Filter:** AL2 + AL3 - -### 6.1.3-M3 — [MUSS] -**Anforderung:** Die für die Umsetzung der Anforderung verantwortliche Organisation ist definiert und sich ihrer Verantwortung bewusst. -- **Organisatorisch:** Für jede Anforderung festlegen, ob Anbieter oder eigene Organisation zuständig ist, und die Zuständigkeit gegenüber der verantwortlichen Stelle bestätigen. -- **Technisch:** Verantwortungszuordnung im Dienstinventar/Responsibility-Matrix dokumentieren. -- **Typische Nachweise:** Verantwortlichkeitszuordnung je Dienst/Anforderung, Bestätigung der zuständigen Stelle. -- **Vorlage:** R13 -- **Ressourcen:** ISB, geringer Aufwand. -- **AL-Filter:** AL2 + AL3 - -### 6.1.3-M4 — [MUSS] -**Anforderung:** Mechanismen für geteilte Verantwortlichkeiten sind spezifiziert und umgesetzt. -- **Organisatorisch:** Shared-Responsibility-Modell je Dienst festlegen (wer verantwortet welche Kontrolle) und die eigenen Pflichtanteile umsetzen. -- **Technisch:** Verantwortungsmatrix (Anbieter/Kunde) je Kontrollbereich; kundenseitige Konfigurationen (z. B. Zugriffsschutz, Verschlüsselung) gemäß Baseline umsetzen (BL-IAM-01 Passwort/Authentifizierung). -- **Typische Nachweise:** Responsibility-Matrix, umgesetzte kundenseitige Kontrollen, Konfigurationsnachweise. -- **Vorlage:** R13; BL-IAM-01 -- **Ressourcen:** IT/ISB, moderater Aufwand. -- **AL-Filter:** AL2 + AL3 - -### 6.1.3-M5 — [MUSS] -**Anforderung:** Die verantwortliche Organisation erfüllt ihre jeweiligen Verantwortlichkeiten. -- **Organisatorisch:** Erfüllung der eigenen und (per Nachweis) der anbieterseitigen Pflichten sicherstellen und regelmäßig kontrollieren. -- **Technisch:** Kontrollnachweise (eigene Konfigurationen, Anbieter-Reports/Zertifikate) sammeln und auswerten. -- **Typische Nachweise:** Nachweise erfüllter Pflichten (eigene und Anbieter), Kontrollberichte. -- **Vorlage:** R13 -- **Ressourcen:** IT/ISB, laufender Aufwand. -- **AL-Filter:** AL2 + AL3 - -### 6.1.3-S1 — [SOLL] -**Anforderung:** Bei IT-Diensten ist die Konfiguration auf Basis der notwendigen Sicherheitsanforderungen konzipiert, umgesetzt und dokumentiert. -- **Organisatorisch:** Sichere Sollkonfiguration je Dienst festlegen, freigeben und dokumentieren; Abweichungen begründen. -- **Technisch:** Konfigurations-Baseline/Hardening-Vorgaben anwenden; Ist-Konfiguration dokumentieren und gegen Soll prüfen (BL-OPS-Härtung). -- **Typische Nachweise:** Konfigurationskonzept/-dokumentation je Dienst, Soll-/Ist-Abgleich. -- **Vorlage:** R13; BL-OPS-01 -- **Ressourcen:** IT, moderater Aufwand. -- **AL-Filter:** AL2 + AL3 - -### 6.1.3-S2 — [SOLL] -**Anforderung:** Das verantwortliche Personal ist angemessen geschult. -- **Organisatorisch:** Für die Dienstverwaltung zuständiges Personal gezielt zu Konfiguration/Sicherheit der jeweiligen Dienste schulen. -- **Technisch:** Schulungs-/Zertifizierungsnachweise im Schulungsmanagement erfassen. -- **Typische Nachweise:** Schulungsnachweise, Qualifikationsnachweise des Personals. -- **Vorlage:** R13; VA-12 -- **Ressourcen:** Personal/Budget für Schulungen. -- **AL-Filter:** AL2 + AL3 - -### 6.1.3-H1 — [HOCH] -**Anforderung:** Eine Liste der betroffenen IT-Dienste und der jeweils verantwortlichen IT-Dienstleister existiert. -- **Organisatorisch:** Vollständige, gepflegte Liste der Dienste inkl. verantwortlichem Dienstleister und Kontaktinformationen führen. -- **Technisch:** Dienst-/Dienstleisterregister im CMDB-/GRC-Tool mit Aktualisierungsroutine. -- **Typische Nachweise:** Aktuelle Dienst-/Dienstleisterliste, Pflegehistorie. -- **Vorlage:** R13 -- **Ressourcen:** IT/ISB, geringer laufender Aufwand. -- **AL-Filter:** AL3 (hoher Schutzbedarf) - -### 6.1.3-H2 — [HOCH] -**Anforderung:** Die Anwendbarkeit der ISA-Controls wurde bewertet und dokumentiert. -- **Organisatorisch:** Je Dienst die anwendbaren ISA-Controls bestimmen und die Bewertung dokumentieren (Applicability-Statement je Dienst). -- **Technisch:** Control-Mapping je Dienst im GRC-Tool hinterlegen. -- **Typische Nachweise:** Dokumentierte ISA-Anwendbarkeitsbewertung je Dienst. -- **Vorlage:** R13 -- **Ressourcen:** ISB, moderater Aufwand. -- **AL-Filter:** AL3 (hoher Schutzbedarf) - -### 6.1.3-H3 — [HOCH] -**Anforderung:** Die Dienstkonfiguration ist in die regelmäßigen Sicherheitsbewertungen einbezogen. -- **Organisatorisch:** Dienstkonfigurationen in den Turnus der internen Sicherheitsüberprüfungen/Audits aufnehmen. -- **Technisch:** Wiederkehrende Konfigurations-Reviews/Compliance-Scans der Dienste; Ergebnisse dokumentieren (BL-OPS-Monitoring). -- **Typische Nachweise:** Prüfpläne mit Diensten, Review-/Scan-Ergebnisse. -- **Vorlage:** R13; VA-15 -- **Ressourcen:** IT/ISB, laufender Aufwand. -- **AL-Filter:** AL3 (hoher Schutzbedarf) - -### 6.1.3-H4 — [HOCH] -**Anforderung:** Es wird nachgewiesen, dass die IT-Dienstleister ihre Verantwortung erfüllen. -- **Organisatorisch:** Von Dienstleistern regelmäßig Nachweise (Zertifikate, SOC-/Prüfberichte, SLA-Reports) einfordern und bewerten. -- **Technisch:** Nachweiseingang und -bewertung im Lieferanten-/GRC-Tool mit Gültigkeitsüberwachung. -- **Typische Nachweise:** Anbieterzertifikate/Prüfberichte, Bewertungsvermerke. -- **Vorlage:** R13 -- **Ressourcen:** ISB, laufender moderater Aufwand. -- **AL-Filter:** AL3 (hoher Schutzbedarf) - -### 6.1.3-H5 — [HOCH] -**Anforderung:** Die Integration in lokale Schutzmaßnahmen (z. B. sichere Authentifizierungsmechanismen) ist etabliert und dokumentiert. -- **Organisatorisch:** Anbindung der Dienste an die eigenen Schutzmaßnahmen (zentrale Identität, Zugriffskontrolle, Protokollierung) verbindlich festlegen und dokumentieren. -- **Technisch:** SSO/Federation, MFA und Log-Anbindung an SIEM konfigurieren (BL-IAM-01 Authentifizierung, BL-IAM-02 MFA). -- **Typische Nachweise:** Integrationsdokumentation, SSO-/MFA-Konfiguration, Log-Anbindungsnachweis. -- **Vorlage:** R13; BL-IAM-01; BL-IAM-02 -- **Ressourcen:** IT, erhöhter Aufwand; ggf. Tooling (Beschaffung). -- **AL-Filter:** AL3 (hoher Schutzbedarf) - -## Control 7.1.1 — Einhaltung rechtlicher, regulatorischer & vertraglicher Vorgaben - -### 7.1.1-M1 — [MUSS] -**Anforderung:** Rechtliche, regulatorische und vertragliche Vorgaben mit Relevanz für die Informationssicherheit werden regelmäßig bestimmt. -- **Organisatorisch:** Ein Compliance-/Rechtskataster mit IS-relevanten Vorgaben (Gesetze, Normen, Verträge) führen und regelmäßig sowie anlassbezogen aktualisieren; Verantwortlichkeit benennen. -- **Technisch:** Anforderungsregister/GRC-Tool mit Quellen, Fristen und Verantwortlichen; Wiedervorlage für Updates. -- **Typische Nachweise:** Aktuelles Compliance-Register, Aktualisierungshistorie, Verantwortlichkeitszuordnung. -- **Vorlage:** R14; VA-18 -- **Ressourcen:** ISB/Recht, moderater laufender Aufwand. -- **AL-Filter:** AL2 + AL3 - -### 7.1.1-M2 — [MUSS] -**Anforderung:** Richtlinien zur Einhaltung der Vorgaben sind definiert, umgesetzt und den verantwortlichen Personen kommuniziert. -- **Organisatorisch:** Zu den identifizierten Vorgaben konkrete Umsetzungsrichtlinien/-vorgaben ableiten, umsetzen und den Verantwortlichen bekannt machen. -- **Technisch:** Richtlinien im Dokumentenmanagement/Intranet bereitstellen; Mapping Vorgabe → Richtlinie → Maßnahme. -- **Typische Nachweise:** Veröffentlichte Compliance-Richtlinien, Mapping Vorgabe/Maßnahme, Kommunikations-/Kenntnisnahmenachweise. -- **Vorlage:** R14; VA-18 -- **Ressourcen:** ISB/Recht, moderater Aufwand. -- **AL-Filter:** AL2 + AL3 - -### 7.1.1-S1 — [SOLL] -**Anforderung:** Die Integrität von Aufzeichnungen entsprechend rechtlichen, regulatorischen und vertraglichen Vorgaben sowie Geschäftsanforderungen wird berücksichtigt. -- **Organisatorisch:** Aufbewahrungs- und Integritätsanforderungen für nachweispflichtige Aufzeichnungen bestimmen und in Handhabungsvorgaben festlegen. -- **Technisch:** Manipulationssichere/revisionssichere Ablage (WORM, Zugriffsschutz, Protokollierung), ggf. mit definierter Aufbewahrungsdauer (BL-OPS-05 Backup/Aufbewahrung). -- **Typische Nachweise:** Aufbewahrungs-/Integritätsvorgaben, Nachweis revisionssicherer Speicherung. -- **Vorlage:** R14; BL-OPS-05 -- **Ressourcen:** IT/ISB, moderater Aufwand; ggf. Archivierungslösung (Beschaffung). -- **AL-Filter:** AL2 + AL3 - -## Control 7.1.2 — Schutz personenbezogener Daten (Datenschutz) - -### 7.1.2-M1 — [MUSS] -**Anforderung:** Rechtliche und vertragliche Informationssicherheitsanforderungen an Verfahren und Prozesse bei der Verarbeitung personenbezogener Daten sind bestimmt. -- **Organisatorisch:** Verarbeitungen personenbezogener Daten erfassen (Verzeichnis von Verarbeitungstätigkeiten) und die daraus folgenden rechtlichen/vertraglichen IS-Anforderungen (z. B. DSGVO) bestimmen; DSB einbinden. -- **Technisch:** VVT und Anforderungszuordnung im GRC-/Datenschutz-Tool pflegen. -- **Typische Nachweise:** Verzeichnis der Verarbeitungstätigkeiten, dokumentierte Datenschutz-/IS-Anforderungen. -- **Vorlage:** R14; VA-18 -- **Ressourcen:** DSB/ISB, moderater Aufwand. -- **AL-Filter:** AL2 + AL3 - -### 7.1.2-M2 — [MUSS] -**Anforderung:** Regelungen zur Einhaltung rechtlicher und vertraglicher Anforderungen an den Schutz personenbezogener Daten sind definiert und den beteiligten Personen bekannt. -- **Organisatorisch:** Datenschutzrichtlinie/-vorgaben (inkl. Betroffenenrechte, Meldepflichten, AVV) definieren und den beteiligten Personen kommunizieren/schulen. -- **Technisch:** Richtlinien und AVV-Vorlagen im Dokumentenmanagement bereitstellen; technische Schutzmaßnahmen (Zugriffsschutz, Verschlüsselung) gemäß Baseline. -- **Typische Nachweise:** Datenschutzrichtlinie, Schulungs-/Kenntnisnahmenachweise, AVV-Vorlagen. -- **Vorlage:** R14; VA-18; BL-IAM-01 -- **Ressourcen:** DSB/ISB, moderater Aufwand. -- **AL-Filter:** AL2 + AL3 - -### 7.1.2-M3 — [MUSS] -**Anforderung:** Prozesse und Verfahren zum Schutz personenbezogener Daten sind im Informationssicherheits-Managementsystem berücksichtigt. -- **Organisatorisch:** Datenschutzprozesse (z. B. Betroffenenanfragen, Datenpannen, DSFA) mit dem ISMS verzahnen (gemeinsame Risiko-, Vorfall- und Überprüfungsprozesse). -- **Technisch:** Verknüpfung von Datenschutz- und ISMS-Prozessen in GRC-/Incident-Tools (z. B. gemeinsamer Meldeworkflow für Datenpannen). -- **Typische Nachweise:** Integrierte Prozessdokumentation, Verweise Datenschutz ↔ ISMS (Risiko/Incident), DSFA-Beispiele. -- **Vorlage:** R14; VA-18; VA-09 -- **Ressourcen:** DSB/ISB, moderater Aufwand. -- **AL-Filter:** AL2 + AL3 - - ---- - -# Prototypenschutz (8.x) & Datenschutz (9.x) - -# Prototypenschutz (8.x) - -## Control 8.1.1 — Sicherheitskonzept physische/umgebungsbezogene Sicherheit - -### 8.1.1-M1 — [MUSS] -**Anforderung:** Sicherheitskonzept mit Außenhaut, Sicht-/Einblickschutz, Zutrittsschutz/-kontrolle, Einbruch-Überwachung, dokumentiertem Besuchermanagement und Mandantentrennung. -- **Organisatorisch:** Ein objektbezogenes Sicherheitskonzept je Liegenschaft/Sicherheitsbereich erstellen, das alle sechs Aspekte behandelt, Verantwortlichen (Betreiber/Objektsicherheit) benennen und durch die Leitung freigeben lassen; regelmäßige Review-Zyklen (mind. jährlich) festlegen. -- **Technisch:** Bestandteile technisch belegen (Schließplan, EMA/Videokonzept, Zonenplan mit Sicherheitsbereichen); Schutzbereiche in einem Liegenschaftsplan/Zonenmodell dokumentieren. -- **Typische Nachweise:** Freigegebenes Sicherheitskonzept, Zonen-/Liegenschaftsplan, Review-Protokoll, Zuständigkeitsmatrix. -- **Vorlage:** Richtlinie Prototypenschutz (P01, neu anzulegen); R07 physische Sicherheit; VA-17 Zutritt/Besucher. -- **Ressourcen:** Objektsicherheit/Werkschutz; Erstaufwand für Konzepterstellung (ggf. externe Beratung), danach jährliche Pflege. -- **AL-Filter:** AL2 | AL3 - -### 8.1.1-S1 — [SOLL] -**Anforderung:** Perimetersicherung. -- **Organisatorisch:** Perimeterschutz als eigenen Baustein im Sicherheitskonzept beschreiben (Geltungsbereich Grundstücksgrenze). -- **Technisch:** Umzäunung/Mauer, Toranlagen, ggf. Außenhautdetektion und Beleuchtung; Zufahrtskontrolle festlegen. -- **Typische Nachweise:** Perimeterkonzept, Fotodokumentation, Wartungsnachweise Zaun/Tore. -- **Vorlage:** P01; R07 physische Sicherheit. -- **Ressourcen:** Investitionsbedarf für bauliche Maßnahmen (Beschaffung/Bau) — führt zu Umsetzungsaufgabe. -- **AL-Filter:** AL2 | AL3 - -## Control 8.1.2 — Perimeterschutz gegen unberechtigten Zutritt - -### 8.1.2-M1 — [MUSS] -**Anforderung:** Der unberechtigte Zutritt zu Liegenschaften ist nicht möglich. -- **Organisatorisch:** Zutrittspunkte inventarisieren, Zufahrts-/Zugangsregelung definieren, Verantwortlichkeit für Perimeter festlegen. -- **Technisch:** Durchgängige Umschließung (Zaun/Mauer/Gebäudefront), gesicherte Tore/Schranken, ggf. Detektion; keine ungesicherten Nebenzugänge. -- **Typische Nachweise:** Perimeterplan, Begehungsprotokoll, Prüfung offener Zugänge. -- **Vorlage:** P01; R07 physische Sicherheit. -- **Ressourcen:** Bauliche Maßnahmen (Beschaffung/Bau), Werkschutz. -- **AL-Filter:** AL2 | AL3 - -### 8.1.2-S1 — [SOLL] -**Anforderung:** Geeignete künstliche, technische und natürliche Barrieren. -- **Organisatorisch:** Barrierenkonzept mit Kombination aus künstlichen (Zaun/Mauer), technischen (Detektion) und natürlichen (Bewuchs) Barrieren dokumentieren. -- **Technisch:** Zaunsysteme, Detektionstechnik, Geländegestaltung/Bewuchs so anordnen, dass Überwindung erschwert und detektiert wird. -- **Typische Nachweise:** Barrierenkonzept, Lageplan, Fotodokumentation. -- **Vorlage:** P01; R07 physische Sicherheit. -- **Ressourcen:** Investition bauliche/gärtnerische Maßnahmen. -- **AL-Filter:** AL2 | AL3 - -## Control 8.1.3 — Außenhaut Gebäude/Sicherheitsbereiche - -### 8.1.3-M1 — [MUSS] -**Anforderung:** Der unberechtigte Zutritt in Gebäude/Sicherheitsbereiche ist nicht möglich. -- **Organisatorisch:** Sicherheitsbereiche definieren und abgrenzen; Anforderungen an Außenhaut (Wände, Türen, Fenster, Dach) festlegen. -- **Technisch:** Einbruchhemmende Ausführung der Außenhautkomponenten; keine mit handelsüblichem Werkzeug zu öffnenden Elemente. -- **Typische Nachweise:** Bauunterlagen/Zertifikate der Bauteile, Begehungsprotokoll, Mängelliste. -- **Vorlage:** P01; R07 physische Sicherheit. -- **Ressourcen:** Bauliche Ertüchtigung (Beschaffung/Bau). -- **AL-Filter:** AL2 | AL3 - -### 8.1.3-S1 — [SOLL] -**Anforderung:** Massive Bauweise (Mauerwerk, Beton, Stahl-/Spannbeton). -- **Organisatorisch:** Bei Neubau/Anmietung massive Bauweise als Anforderung berücksichtigen. -- **Technisch:** Massive Wandkonstruktionen; bei Leichtbau ergänzende Verstärkungen/Detektion vorsehen. -- **Typische Nachweise:** Baubeschreibung, Statik-/Bauunterlagen, Fotodokumentation. -- **Vorlage:** P01; R07 physische Sicherheit. -- **Ressourcen:** Baulicher Investitionsbedarf. -- **AL-Filter:** AL2 | AL3 - -### 8.1.3-S2 — [SOLL] -**Anforderung:** Fenster und Türen in der Außenhaut in RC2 oder höher. -- **Organisatorisch:** RC-Klasse als Beschaffungsvorgabe für Fenster/Türen setzen; Bestand bewerten. -- **Technisch:** Einbruchhemmende Fenster/Türen nach DIN EN 1627 (RC2+), inkl. Verglasung und Beschlägen. -- **Typische Nachweise:** RC-Zertifikate/Herstellernachweise, Einbaudokumentation. -- **Vorlage:** P01; R07 physische Sicherheit. -- **Ressourcen:** Beschaffung einbruchhemmender Elemente. -- **AL-Filter:** AL2 | AL3 - -## Control 8.1.4 — Sicht- und Einblickschutz - -### 8.1.4-M1 — [MUSS] -**Anforderung:** Unberechtigter Einblick auf Neuentwicklungen mit hohem/sehr hohem Schutzbedarf ist nicht möglich. -- **Organisatorisch:** Sicht-/Einblickschutz für Sicherheitsbereiche festlegen; Verhaltensregeln (Türen/Tore geschlossen halten) definieren. -- **Technisch:** Sichtschutz an Fenstern/Glasflächen, blickdichte Tore/Vorhänge, bauliche Sichtbarrieren; Positionierung schutzbedürftiger Objekte außerhalb einsehbarer Zonen. -- **Typische Nachweise:** Einblickschutzkonzept, Begehungsprotokoll (Einsehbarkeit), Fotodokumentation. -- **Vorlage:** P01; R07 physische Sicherheit. -- **Ressourcen:** Beschaffung Sichtschutzmaßnahmen. -- **AL-Filter:** AL2 | AL3 - -### 8.1.4-S1 — [SOLL] -**Anforderung:** Schutz vor Einblick durch relevante Glasflächen. -- **Organisatorisch:** Relevante Glasflächen identifizieren und Sichtschutzmaßnahme je Fläche festlegen. -- **Technisch:** Folierung/Milchglas, Jalousien/Rollos, blickdichte Verglasung. -- **Typische Nachweise:** Liste Glasflächen mit Maßnahme, Fotodokumentation. -- **Vorlage:** P01; R07 physische Sicherheit. -- **Ressourcen:** Beschaffung/Installation Sichtschutz. -- **AL-Filter:** AL2 | AL3 - -### 8.1.4-S2 — [SOLL] -**Anforderung:** Einsicht in Sicherheitsbereiche durch offene Türen/Tore/Fenster wird verhindert. -- **Organisatorisch:** Verhaltensregel "Tore/Türen geschlossen" verankern, Kontrollen durchführen. -- **Technisch:** Selbstschließende Tore, Schleusen/Sichtschutzvorhänge an Zufahrten, Anordnung so, dass keine direkte Sichtachse besteht. -- **Typische Nachweise:** Verhaltensregeln, Begehungsprotokoll, Fotodokumentation. -- **Vorlage:** P01; R07 physische Sicherheit; VA-17 Zutritt/Besucher. -- **Ressourcen:** Organisatorisch gering; ggf. Nachrüstung Torautomatik. -- **AL-Filter:** AL2 | AL3 - -### 8.1.4-H1 — [HOCH] -**Anforderung:** Räumliche Situation auch geeignet, schutzbedürftig klassifizierte Fahrzeuge vor Einblick zu schützen. -- **Organisatorisch:** Für Fahrzeug-Schutzbedarf erweiterte Einblickschutzanforderungen festlegen (größere Objekte, Rangierflächen). -- **Technisch:** Geschlossene Hallen/Boxen, blickdichte Umhausung, Sichtschutz auch bei Rangier-/Zufahrtswegen. -- **Typische Nachweise:** Einblickschutzkonzept Fahrzeuge, Fotodokumentation, Begehung. -- **Vorlage:** P01; R07 physische Sicherheit. -- **Ressourcen:** Bauliche Maßnahmen bei hohem Schutzbedarf. -- **AL-Filter:** AL3 (hoher/sehr hoher Schutzbedarf) - -## Control 8.1.5 — Zugangskontrolle Sicherheitsbereiche - -### 8.1.5-M1 — [MUSS] -**Anforderung:** Mindestens eine von drei Maßnahmen: mechanische Schlösser mit dokumentierter Schlüsselvergabe, elektronische Zugangssysteme mit dokumentierter Berechtigungsvergabe oder Personen-Zutrittskontrolle inkl. Dokumentation. -- **Organisatorisch:** Zutrittskontrollverfahren mit dokumentierter Vergabe/Entzug festlegen; Berechtigungen nach Need-to-know. -- **Technisch:** Elektronisches Zutrittskontrollsystem (Ausweis/PIN) mit Protokollierung oder Schließanlage mit Schließplan; alternativ Personenkontrolle mit Zutrittsbuch. -- **Typische Nachweise:** Schließplan/Berechtigungsliste, Zutrittsprotokolle, Vergabe-/Entzugsnachweise. -- **Vorlage:** P01; VA-17 Zutritt/Besucher; R07 physische Sicherheit. -- **Ressourcen:** ZKS-Beschaffung/-Betrieb oder Schließanlage; Werkschutz. -- **AL-Filter:** AL2 | AL3 - -### 8.1.5-H1 — [HOCH] -**Anforderung:** Räumliche Situation auch geeignet, schutzbedürftig klassifizierte Fahrzeuge vor unberechtigtem Zugriff zu schützen. -- **Organisatorisch:** Zutrittsregelung auf Fahrzeug-Abstellbereiche ausdehnen, verschärfte Berechtigung. -- **Technisch:** Separat gesicherte, zutrittsbeschränkte Fahrzeughallen/Boxen mit protokolliertem Zugang. -- **Typische Nachweise:** Berechtigungskonzept Fahrzeugbereiche, Zutrittsprotokolle. -- **Vorlage:** P01; VA-17 Zutritt/Besucher. -- **Ressourcen:** Ggf. bauliche/technische Nachrüstung. -- **AL-Filter:** AL3 (hoher/sehr hoher Schutzbedarf) - -## Control 8.1.6 — Einbruch-Überwachung - -### 8.1.6-M1 — [MUSS] -**Anforderung:** Einbruchmeldeanlage nach DIN EN 50131/VdS mit Alarmverfolgung auf zertifizierten Sicherheitsdienst/Leitstelle — oder 24/7-Bewachung durch zertifizierten Sicherheitsdienst. -- **Organisatorisch:** Überwachungsvariante festlegen (EMA vs. Bewachung), Dienstleister vertraglich binden (zertifiziert). -- **Technisch:** EMA nach DIN EN 50131/VdS mit Aufschaltung auf Leitstelle (DIN 77200/VdS 3138); alternativ Wachdienst rund um die Uhr. -- **Typische Nachweise:** EMA-Attest/VdS-Nachweis, Aufschaltvertrag, Zertifikat Sicherheitsdienst, Wartungsnachweis. -- **Vorlage:** P01; R07 physische Sicherheit; R13 Lieferanten (Wachdienst); VA-10 Lieferanten. -- **Ressourcen:** EMA-Investition + laufende Aufschaltkosten oder Wachdienstvertrag. -- **AL-Filter:** AL2 | AL3 - -### 8.1.6-M2 — [MUSS] -**Anforderung:** Alarmierungspläne sind verfügbar. -- **Organisatorisch:** Alarmierungs-/Interventionsplan mit Eskalation, Verantwortlichen und Kontaktketten erstellen und aktuell halten. -- **Technisch:** Hinterlegung in Leitstelle/EMA; definierte Interventionskräfte. -- **Typische Nachweise:** Alarmierungsplan, Interventionsvereinbarung, Aktualisierungsnachweis. -- **Vorlage:** P01; R07 physische Sicherheit. -- **Ressourcen:** Organisatorisch; Abstimmung mit Dienstleister. -- **AL-Filter:** AL2 | AL3 - -### 8.1.6-M3 — [MUSS] -**Anforderung:** Eine zeitnahe Alarmverfolgung ist sichergestellt. -- **Organisatorisch:** Reaktions-/Interventionszeiten vertraglich vereinbaren und überprüfen. -- **Technisch:** Aufschaltung auf 24/7-Leitstelle mit definierter Interventionszeit; Funktionstests. -- **Typische Nachweise:** SLA/Interventionsvereinbarung, Alarm-/Interventionsprotokolle, Testberichte. -- **Vorlage:** P01; R13 Lieferanten; VA-10 Lieferanten. -- **Ressourcen:** Laufende Dienstleisterkosten. -- **AL-Filter:** AL2 | AL3 - -## Control 8.1.7 — Dokumentiertes Besuchermanagement - -### 8.1.7-M1 — [MUSS] -**Anforderung:** Anmeldepflicht für alle Besucher. -- **Organisatorisch:** Besucherprozess mit Voranmeldung, Registrierung, Begleitung und Abmeldung definieren. -- **Technisch:** Besuchermanagementsystem oder Besucherbuch mit Ausweisvergabe; Protokollierung Kommen/Gehen. -- **Typische Nachweise:** Besucherprozess, Besucherprotokolle/-liste, Besucherausweise. -- **Vorlage:** P01; VA-17 Zutritt/Besucher. -- **Ressourcen:** Empfang/Werkschutz; ggf. Besuchersystem. -- **AL-Filter:** AL2 | AL3 - -### 8.1.7-M2 — [MUSS] -**Anforderung:** Dokumentierte Verpflichtung zur Geheimhaltung vor dem Zutritt. -- **Organisatorisch:** Besucher vor Zutritt auf Geheimhaltung verpflichten (NDA/Besuchererklärung), Aufbewahrung regeln. -- **Technisch:** Digitale Erfassung/Signatur im Besuchersystem oder unterschriebene Formulare. -- **Typische Nachweise:** Unterzeichnete Geheimhaltungserklärungen, Archiv der Erklärungen. -- **Vorlage:** P01; VA-17 Zutritt/Besucher; R13 Lieferanten (bei Fremdfirmen). -- **Ressourcen:** Organisatorisch gering. -- **AL-Filter:** AL2 | AL3 - -### 8.1.7-M3 — [MUSS] -**Anforderung:** Veröffentlichung von Sicherheits- und Besucherregelungen. -- **Organisatorisch:** Besucher-/Sicherheitsregeln am Empfang und im Sicherheitsbereich aushängen/aushändigen. -- **Technisch:** Aushänge, Merkblätter, Anzeige im Besuchersystem. -- **Typische Nachweise:** Aushang/Merkblatt, Fotodokumentation, Aushändigungsnachweis. -- **Vorlage:** P01; VA-17 Zutritt/Besucher. -- **Ressourcen:** Organisatorisch gering. -- **AL-Filter:** AL2 | AL3 - -### 8.1.7-M4 — [MUSS] -**Anforderung:** Länderspezifische gesetzliche Datenschutzbestimmungen einhalten. -- **Organisatorisch:** Besucherdatenverarbeitung datenschutzkonform gestalten (Rechtsgrundlage, Löschfristen, Information); mit DS-Funktion abstimmen. -- **Technisch:** Zugriffsbeschränkung und automatisierte Löschung der Besucherdaten. -- **Typische Nachweise:** Löschkonzept Besucherdaten, Datenschutzinformation, Eintrag im Verarbeitungsverzeichnis. -- **Vorlage:** P01; VA-17 Zutritt/Besucher; Richtlinie Datenschutz (D01) / R14 Compliance & Datenschutz. -- **Ressourcen:** Abstimmung DS-Funktion. -- **AL-Filter:** AL2 | AL3 - -## Control 8.1.8 — Mandantentrennung vor Ort - -### 8.1.8-M1 — [MUSS] -**Anforderung:** Räumliche Trennung durch personelle/technische Maßnahmen nach Kunden/Projekten; ohne Trennung explizite Kundenfreigabe. -- **Organisatorisch:** Trennungskonzept je Kunde/Projekt definieren; bei fehlender Trennung Freigabe der betroffenen Kunden einholen und dokumentieren. -- **Technisch:** Bauliche Abtrennung (Boxen/Bereiche), zutrittsgetrennte Zonen, projektbezogene Berechtigungen. -- **Typische Nachweise:** Trennungskonzept, Zonen-/Berechtigungsplan, ggf. Kundenfreigaben. -- **Vorlage:** P01; R07 physische Sicherheit; R13 Lieferanten. -- **Ressourcen:** Ggf. bauliche Trennung. -- **AL-Filter:** AL2 | AL3 - -### 8.1.8-H1 — [HOCH] -**Anforderung:** Räumliche Situation auch geeignet für Mandantentrennung bei schutzbedürftig klassifizierten Fahrzeugen. -- **Organisatorisch:** Trennungskonzept auf Fahrzeugbereiche ausdehnen. -- **Technisch:** Separate, blickdichte und zutrittsgetrennte Fahrzeughallen/Boxen je Mandant. -- **Typische Nachweise:** Trennungskonzept Fahrzeuge, Belegungsplan, Fotodokumentation. -- **Vorlage:** P01; R07 physische Sicherheit. -- **Ressourcen:** Bauliche Maßnahmen bei hohem Schutzbedarf. -- **AL-Filter:** AL3 (hoher/sehr hoher Schutzbedarf) - -## Control 8.2.1 — Geheimhaltungsvereinbarungen - -### 8.2.1-M1 — [MUSS] -**Anforderung:** Eine Geheimhaltungsvereinbarung. -- **Organisatorisch:** NDA-Vorlage bereitstellen und Prozess festlegen, dass schutzbedürftige Informationen nur mit gültiger NDA weitergegeben werden. -- **Technisch:** Vertragsmanagement mit Ablage/Statusverfolgung der NDAs. -- **Typische Nachweise:** NDA-Vorlage, abgeschlossene NDAs, Vertragsregister. -- **Vorlage:** P01; R13 Lieferanten; VA-10 Lieferanten. -- **Ressourcen:** Recht/Einkauf; organisatorisch. -- **AL-Filter:** AL2 | AL3 - -### 8.2.1-M2 — [MUSS] -**Anforderung:** NDA zwischen Auftragnehmer und Auftraggeber (Firmen-Ebene). -- **Organisatorisch:** Firmen-NDA vor Projektbeginn abschließen; Gültigkeit prüfen. -- **Technisch:** Ablage im Vertragsregister mit Laufzeitüberwachung. -- **Typische Nachweise:** Unterzeichnetes Firmen-NDA, Vertragsregister. -- **Vorlage:** P01; R13 Lieferanten; VA-10 Lieferanten. -- **Ressourcen:** Recht/Einkauf. -- **AL-Filter:** AL2 | AL3 - -### 8.2.1-M3 — [MUSS] -**Anforderung:** Persönliche Verpflichtung aller Mitarbeiter und Projektbeteiligten. -- **Organisatorisch:** Alle Projektbeteiligten persönlich zur Geheimhaltung verpflichten (Onboarding/Projekteinstieg). -- **Technisch:** HR-/Projektsystem mit Erfassung und Nachverfolgung der Verpflichtungen. -- **Typische Nachweise:** Unterzeichnete Einzelverpflichtungen, Projektbeteiligtenliste mit Status. -- **Vorlage:** P01; R13 Lieferanten. -- **Ressourcen:** HR/Projektleitung. -- **AL-Filter:** AL2 | AL3 - -### 8.2.1-M4 — [MUSS] -**Anforderung:** Länderspezifische gesetzliche Datenschutzbestimmungen einhalten. -- **Organisatorisch:** Verpflichtungserklärungen datenschutzkonform gestalten und mit DS-Funktion abstimmen. -- **Technisch:** Zugriffsbeschränkte Ablage personenbezogener Verpflichtungsnachweise. -- **Typische Nachweise:** Datenschutzkonforme Formulare, Ablage-/Löschkonzept. -- **Vorlage:** P01; Richtlinie Datenschutz (D01) / R14 Compliance & Datenschutz. -- **Ressourcen:** Abstimmung DS-Funktion. -- **AL-Filter:** AL2 | AL3 - -## Control 8.2.2 — Beauftragung von Unterauftragnehmern - -### 8.2.2-M1 — [MUSS] -**Anforderung:** Freigabe durch den ursprünglichen Auftraggeber. -- **Organisatorisch:** Prozess zur Einholung der Auftraggeber-Freigabe vor Beauftragung von Unterauftragnehmern etablieren. -- **Technisch:** Dokumentierte Freigaben im Vertrags-/Lieferantenmanagement. -- **Typische Nachweise:** Freigabedokument des Auftraggebers, Prozessbeschreibung. -- **Vorlage:** P01; R13 Lieferanten; VA-10 Lieferanten. -- **Ressourcen:** Einkauf/Projektleitung. -- **AL-Filter:** AL2 | AL3 - -### 8.2.2-M2 — [MUSS] -**Anforderung:** Vertragsrechtlich gültige Geheimhaltungsvereinbarung vorhanden. -- **Organisatorisch:** NDA mit Unterauftragnehmer vor Weitergabe abschließen. -- **Technisch:** Vertragsregister mit Gültigkeitsprüfung. -- **Typische Nachweise:** Unterzeichnetes NDA, Vertragsregister. -- **Vorlage:** P01; R13 Lieferanten; VA-10 Lieferanten. -- **Ressourcen:** Recht/Einkauf. -- **AL-Filter:** AL2 | AL3 - -### 8.2.2-M3 — [MUSS] -**Anforderung:** NDA zwischen Auftragnehmer und Unterauftragnehmer (Firmen-Ebene). -- **Organisatorisch:** Firmen-NDA mit Unterauftragnehmer sicherstellen. -- **Technisch:** Ablage/Statusverfolgung im Vertragsregister. -- **Typische Nachweise:** Firmen-NDA Unterauftragnehmer. -- **Vorlage:** P01; R13 Lieferanten; VA-10 Lieferanten. -- **Ressourcen:** Recht/Einkauf. -- **AL-Filter:** AL2 | AL3 - -### 8.2.2-M4 — [MUSS] -**Anforderung:** Persönliche Verpflichtung aller Mitarbeiter/Projektbeteiligten des Unterauftragnehmers. -- **Organisatorisch:** Nachweis der persönlichen Verpflichtungen der Beschäftigten des Unterauftragnehmers einfordern. -- **Technisch:** Erfassung im Lieferantenmanagement. -- **Typische Nachweise:** Bestätigung/Liste der Einzelverpflichtungen des Unterauftragnehmers. -- **Vorlage:** P01; R13 Lieferanten. -- **Ressourcen:** Einkauf/Lieferantenmanagement. -- **AL-Filter:** AL2 | AL3 - -### 8.2.2-M5 — [MUSS] -**Anforderung:** Sicherstellung der Einhaltung der Sicherheitsvorgaben des eigentlichen Kunden (Nachweis eingeholt). -- **Organisatorisch:** Kundenvorgaben vertraglich an Unterauftragnehmer weitergeben und Nachweise einholen. -- **Technisch:** Back-to-back-Verträge, Nachweisablage. -- **Typische Nachweise:** Vertragliche Weitergabe, eingeholte Nachweise/Bestätigungen. -- **Vorlage:** P01; R13 Lieferanten; VA-10 Lieferanten. -- **Ressourcen:** Einkauf/Recht. -- **AL-Filter:** AL2 | AL3 - -### 8.2.2-M6 — [MUSS] -**Anforderung:** Nachweis der Einhaltung der Mindestanforderungen Prototypenschutz des Unterauftragnehmers (z. B. Zertifikat). -- **Organisatorisch:** Nachweis (TISAX-Label Prototypenschutz/Bescheinigung) vor Beauftragung einholen und Gültigkeit prüfen. -- **Technisch:** Lieferantenregister mit Label-/Zertifikatsstatus und Ablaufüberwachung. -- **Typische Nachweise:** TISAX-Label/Zertifikat/Bescheinigung, Lieferantenbewertung. -- **Vorlage:** P01; R13 Lieferanten; VA-10 Lieferanten. -- **Ressourcen:** Einkauf/Lieferantenmanagement. -- **AL-Filter:** AL2 | AL3 - -## Control 8.2.3 — Schulung/Sensibilisierung Umgang mit Prototypen - -### 8.2.3-M1 — [MUSS] -**Anforderung:** Sicherstellung der Durchführung von Schulungen/Sensibilisierung durch die Leitung. -- **Organisatorisch:** Leitung verpflichtet sich zu Schulungsprogramm Prototypenschutz und stellt Ressourcen bereit. -- **Technisch:** Learning-Management/Schulungstracking zur Steuerung. -- **Typische Nachweise:** Managementbeschluss/Leitlinie, Schulungsplan. -- **Vorlage:** P01. -- **Ressourcen:** Leitung; Schulungsbudget. -- **AL-Filter:** AL2 | AL3 - -### 8.2.3-M2 — [MUSS] -**Anforderung:** Schulung bei Projekteinstieg. -- **Organisatorisch:** Erstschulung als Pflichtbestandteil des Projekt-Onboardings festlegen. -- **Technisch:** Onboarding-/LMS-Workflow mit Zutritts-/Freischaltvoraussetzung. -- **Typische Nachweise:** Onboarding-Schulungsnachweise, Teilnehmerlisten. -- **Vorlage:** P01. -- **Ressourcen:** Projektleitung/HR. -- **AL-Filter:** AL2 | AL3 - -### 8.2.3-M3 — [MUSS] -**Anforderung:** Regelmäßige (mind. jährliche) Schulung. -- **Organisatorisch:** Jährliche Wiederholungsschulung planen und einladen. -- **Technisch:** LMS mit Fälligkeits-/Erinnerungssteuerung. -- **Typische Nachweise:** Jahresschulungsplan, Teilnahmenachweise. -- **Vorlage:** P01. -- **Ressourcen:** Schulungsbudget/Zeit. -- **AL-Filter:** AL2 | AL3 - -### 8.2.3-M4 — [MUSS] -**Anforderung:** Sicherstellung der Kenntnisse zu Schutzbedarf und resultierenden Maßnahmen. -- **Organisatorisch:** Schulungsinhalte auf Schutzbedarfsklassen und konkrete Maßnahmen ausrichten; Verständnis prüfen. -- **Technisch:** Lernerfolgskontrolle/Quiz im LMS. -- **Typische Nachweise:** Schulungsunterlagen, Testergebnisse. -- **Vorlage:** P01. -- **Ressourcen:** Fachliche Contenterstellung. -- **AL-Filter:** AL2 | AL3 - -### 8.2.3-M5 — [MUSS] -**Anforderung:** Verpflichtende Teilnahme jedes Mitarbeiters/Projektbeteiligten. -- **Organisatorisch:** Teilnahmepflicht verankern und Eskalation bei Nichtteilnahme regeln. -- **Technisch:** LMS-Pflichtzuweisung mit Statusüberwachung. -- **Typische Nachweise:** Vollständigkeitsreport Teilnahme, Eskalationsnachweise. -- **Vorlage:** P01. -- **Ressourcen:** HR/Projektleitung. -- **AL-Filter:** AL2 | AL3 - -### 8.2.3-M6 — [MUSS] -**Anforderung:** Dokumentation der Durchführungen. -- **Organisatorisch:** Schulungsnachweise revisionssicher aufbewahren. -- **Technisch:** LMS-Reporting/Nachweisarchiv. -- **Typische Nachweise:** Teilnahmeprotokolle, Zertifikate, Schulungsregister. -- **Vorlage:** P01. -- **Ressourcen:** Organisatorisch gering. -- **AL-Filter:** AL2 | AL3 - -### 8.2.3-M7 — [MUSS] -**Anforderung:** Schulungskonzept Prototypenschutz ist Teil des allgemeinen Schulungskonzepts (vgl. IS 2.1.3). -- **Organisatorisch:** Prototypenschutz-Modul in das ISMS-Awareness-Konzept integrieren. -- **Technisch:** Gemeinsames LMS-Curriculum mit Prototypen-Modul. -- **Typische Nachweise:** Übergreifendes Schulungskonzept mit Prototypenmodul. -- **Vorlage:** P01. -- **Ressourcen:** Abstimmung ISB/HR. -- **AL-Filter:** AL2 | AL3 - -## Control 8.2.4 — Sicherheitseinstufung des Projekts bekannt - -### 8.2.4-M1 — [MUSS] -**Anforderung:** Jedem Projektbeteiligten sind Sicherheitseinstufung und -vorgaben je Projektfortschritt bekannt. -- **Organisatorisch:** Sicherheitseinstufung und Vorgaben je Projektphase kommunizieren und aktualisieren. -- **Technisch:** Projektinfomappe/Portal mit stufenbezogenen Vorgaben. -- **Typische Nachweise:** Kommunikationsnachweise, Kenntnisnahmebestätigungen, Projektakte. -- **Vorlage:** P01. -- **Ressourcen:** Projektleitung. -- **AL-Filter:** AL2 | AL3 - -### 8.2.4-M2 — [MUSS] -**Anforderung:** Berücksichtigung von Stufenplänen, Geheimhaltung/Tarnung, Entwicklungsrichtlinien. -- **Organisatorisch:** Stufenplan und Tarn-/Entwicklungsvorgaben des Auftraggebers in Projektvorgaben aufnehmen. -- **Technisch:** Ablage der Stufenpläne im Projektsystem. -- **Typische Nachweise:** Stufenplan, Tarnvorgaben, Entwicklungsrichtlinien im Projekt. -- **Vorlage:** P01. -- **Ressourcen:** Projektleitung. -- **AL-Filter:** AL2 | AL3 - -### 8.2.4-M3 — [MUSS] -**Anforderung:** Berücksichtigung als IS-Anforderung des Projekts (vgl. IS 1.2.3 und 7.1.1). -- **Organisatorisch:** Prototypenanforderungen in die Projekt-IS-Anforderungen/-Risikobetrachtung überführen. -- **Technisch:** Verknüpfung mit ISMS-Projektrisikomanagement. -- **Typische Nachweise:** IS-Anforderungsliste/Risikoregister des Projekts. -- **Vorlage:** P01. -- **Ressourcen:** Abstimmung ISB/Projekt. -- **AL-Filter:** AL2 | AL3 - -## Control 8.2.5 — Prozess Zutrittsvergabe Sicherheitsbereiche - -### 8.2.5-M1 — [MUSS] -**Anforderung:** Verantwortlichkeiten für die Zutrittsvergabe eindeutig geregelt und dokumentiert. -- **Organisatorisch:** Rollen für Beantragung, Genehmigung und Vergabe festlegen und dokumentieren. -- **Technisch:** Rollen-/Rechtematrix im Zutrittssystem. -- **Typische Nachweise:** Zuständigkeits-/Rollenmatrix, Prozessbeschreibung. -- **Vorlage:** P01; VA-17 Zutritt/Besucher. -- **Ressourcen:** Objektsicherheit. -- **AL-Filter:** AL2 | AL3 - -### 8.2.5-M2 — [MUSS] -**Anforderung:** Prozess bei Neuvergabe, Änderung und Löschung von Zutrittsberechtigungen. -- **Organisatorisch:** Lebenszyklusprozess (Antrag/Genehmigung/Änderung/Entzug, inkl. Austritt) definieren; regelmäßige Rezertifizierung. -- **Technisch:** Workflow im Zutrittssystem, automatischer Entzug bei Austritt. -- **Typische Nachweise:** Prozessbeschreibung, Vergabe-/Entzugsprotokolle, Rezertifizierungsnachweise. -- **Vorlage:** P01; VA-17 Zutritt/Besucher. -- **Ressourcen:** Objektsicherheit/HR-Schnittstelle. -- **AL-Filter:** AL2 | AL3 - -### 8.2.5-M3 — [MUSS] -**Anforderung:** Verhaltensregeln bei Verlust/Diebstahl von Schließmitteln. -- **Organisatorisch:** Meldeweg und Sofortmaßnahmen (Sperrung/Umstellung) festlegen. -- **Technisch:** Sofortsperrung elektronischer Medien; bei mechanischen Schlössern Schließzylindertausch. -- **Typische Nachweise:** Verfahrensanweisung, Verlustmeldungen, Sperr-/Tauschnachweise. -- **Vorlage:** P01; VA-17 Zutritt/Besucher. -- **Ressourcen:** Objektsicherheit; ggf. Zylindertausch-Budget. -- **AL-Filter:** AL2 | AL3 - -## Control 8.2.6 — Regelungen Bildaufzeichnung/Bildmaterial - -### 8.2.6-M1 — [MUSS] -**Anforderung:** Genehmigungsverfahren zur Bildaufzeichnung. -- **Organisatorisch:** Genehmigungsprozess mit Verantwortlichen und Freigabekriterien definieren. -- **Technisch:** Antrags-/Freigabeworkflow, dokumentierte Freigaben. -- **Typische Nachweise:** Verfahrensbeschreibung, Freigabedokumente. -- **Vorlage:** P01. -- **Ressourcen:** Projektleitung/Objektsicherheit. -- **AL-Filter:** AL2 | AL3 - -### 8.2.6-M2 — [MUSS] -**Anforderung:** Klassifizierung/Einstufung von Bildmaterial festlegen. -- **Organisatorisch:** Einstufungsschema für Bildmaterial an Informationsklassifizierung anlehnen. -- **Technisch:** Kennzeichnung/Metadaten, Ablage nach Klassifizierung. -- **Typische Nachweise:** Klassifizierungsschema, klassifiziertes Bildmaterial. -- **Vorlage:** P01. -- **Ressourcen:** Organisatorisch. -- **AL-Filter:** AL2 | AL3 - -### 8.2.6-M3 — [MUSS] -**Anforderung:** Sichere Lagerung/Speicherung von Bildmaterial. -- **Organisatorisch:** Ablageorte und Zugriffsberechtigungen nach Need-to-know festlegen. -- **Technisch:** Verschlüsselte/zugriffsbeschränkte Speicherung, Berechtigungssteuerung. -- **Typische Nachweise:** Ablage-/Berechtigungskonzept, Zugriffsnachweise. -- **Vorlage:** P01. -- **Ressourcen:** IT/Objektsicherheit. -- **AL-Filter:** AL2 | AL3 - -### 8.2.6-M4 — [MUSS] -**Anforderung:** Sichere Löschung/Entsorgung nicht mehr benötigten Bildmaterials. -- **Organisatorisch:** Löschfristen und Löschprozess definieren. -- **Technisch:** Sichere Löschverfahren/Datenträgervernichtung mit Protokoll. -- **Typische Nachweise:** Löschkonzept, Lösch-/Vernichtungsprotokolle. -- **Vorlage:** P01. -- **Ressourcen:** IT/Objektsicherheit. -- **AL-Filter:** AL2 | AL3 - -### 8.2.6-M5 — [MUSS] -**Anforderung:** Abgesicherte Weitergabe/Versand nur an Empfangsberechtigte. -- **Organisatorisch:** Empfängerkreis und Freigabe für Versand definieren. -- **Technisch:** Verschlüsselter Transfer/gesicherte Freigabeplattform, Empfängerprüfung. -- **Typische Nachweise:** Versandregelung, Übermittlungsnachweise, Empfängerfreigaben. -- **Vorlage:** P01. -- **Ressourcen:** IT. -- **AL-Filter:** AL2 | AL3 - -## Control 8.2.7 — Mitführen/Nutzung mobiler Video-/Fotogeräte - -### 8.2.7-M1 — [MUSS] -**Anforderung:** Festlegung für das Mitführen (z. B. mit/ohne Versiegelung). -- **Organisatorisch:** Regeln zum Mitführen mobiler Geräte in Sicherheitsbereichen festlegen (Versiegelung/Abgabe). -- **Technisch:** Kamera-Versiegelung, Verwahrung am Eingang, Kennzeichnung. -- **Typische Nachweise:** Regelung Mitführen, Versiegelungs-/Verwahrnachweise, Aushang. -- **Vorlage:** P01; VA-17 Zutritt/Besucher. -- **Ressourcen:** Objektsicherheit; Versiegelungsmaterial. -- **AL-Filter:** AL2 | AL3 - -### 8.2.7-M2 — [MUSS] -**Anforderung:** Festlegung für die Nutzung (z. B. Telefonieren, Fotografieren). -- **Organisatorisch:** Nutzungsregeln (Foto-/Aufnahmeverbot, Telefonie) je Bereich festlegen und kommunizieren. -- **Technisch:** Beschilderung/Kennzeichnung, Kontrollen durch Werkschutz. -- **Typische Nachweise:** Nutzungsregelung, Beschilderung, Kontrollprotokolle. -- **Vorlage:** P01; VA-17 Zutritt/Besucher. -- **Ressourcen:** Objektsicherheit. -- **AL-Filter:** AL2 | AL3 - -## Control 8.3.1 — Transporte nach Auftraggebervorgaben - -### 8.3.1-M1 — [MUSS] -**Anforderung:** Prozess zur Einholung auftraggeberspezifischer Transportanforderungen beschrieben und implementiert. -- **Organisatorisch:** Prozess definieren, der vor Transport die Kundenvorgaben einholt und in Transportaufträge überführt. -- **Technisch:** Ablage der Vorgaben und Verknüpfung mit Transportaufträgen. -- **Typische Nachweise:** Prozessbeschreibung, eingeholte Kundenvorgaben. -- **Vorlage:** P01; R13 Lieferanten; VA-10 Lieferanten. -- **Ressourcen:** Logistik/Projektleitung. -- **AL-Filter:** AL2 | AL3 - -### 8.3.1-M2 — [MUSS] -**Anforderung:** Vom Auftraggeber definierte Sicherheitsvorgaben sind bekannt und werden eingehalten. -- **Organisatorisch:** Vorgaben an ausführende Stellen/Dienstleister kommunizieren und Einhaltung überwachen. -- **Technisch:** Transportbegleitpapiere mit Sicherheitsanforderungen, Tracking. -- **Typische Nachweise:** Kommunikationsnachweis, Transportdokumentation, Kontrollen. -- **Vorlage:** P01; R13 Lieferanten; VA-10 Lieferanten. -- **Ressourcen:** Logistik. -- **AL-Filter:** AL2 | AL3 - -### 8.3.1-M3 — [MUSS] -**Anforderung:** Nur vom Auftraggeber freigegebene Logistik-/Transportunternehmen verwenden. -- **Organisatorisch:** Freigegebene Dienstleister listen und ausschließlich diese beauftragen. -- **Technisch:** Lieferantenregister mit Freigabestatus, Sperrung nicht freigegebener. -- **Typische Nachweise:** Freigabeliste, Beauftragungsnachweise. -- **Vorlage:** P01; R13 Lieferanten; VA-10 Lieferanten. -- **Ressourcen:** Einkauf/Logistik. -- **AL-Filter:** AL2 | AL3 - -### 8.3.1-M4 — [MUSS] -**Anforderung:** Prozess zur Meldung aller sicherheitsrelevanten Ereignisse an den Auftraggeber. -- **Organisatorisch:** Meldeprozess mit Fristen und Kontaktketten zum Auftraggeber definieren. -- **Technisch:** Vorfall-/Meldeworkflow mit Dokumentation. -- **Typische Nachweise:** Meldeprozess, Vorfallsmeldungen/-protokolle. -- **Vorlage:** P01; R13 Lieferanten. -- **Ressourcen:** Logistik/Projektleitung. -- **AL-Filter:** AL2 | AL3 - -## Control 8.3.2 — Abstellen/Lagern nach Auftraggebervorgaben - -### 8.3.2-M1 — [MUSS] -**Anforderung:** Auftraggebervorgaben zum Abstellen/Lagern sind nachweislich bekannt und werden eingehalten. -- **Organisatorisch:** Kundenvorgaben zu Lager-/Abstellbedingungen einholen, kommunizieren und Einhaltung prüfen. -- **Technisch:** Gesicherte, zutritts-/einblickgeschützte Abstell-/Lagerbereiche gemäß Vorgaben. -- **Typische Nachweise:** Vorgabendokument, Kenntnisnahmenachweise, Begehungs-/Kontrollprotokolle. -- **Vorlage:** P01; R07 physische Sicherheit; R13 Lieferanten. -- **Ressourcen:** Logistik/Objektsicherheit. -- **AL-Filter:** AL2 | AL3 - -## Control 8.4.1 — Tarnung von Versuchsfahrzeugen - -> Im aktuellen Prüfziel (Prototypenteile/-komponenten) n.a. — nur relevant bei Prüfziel Fahrzeuge/Erprobung/Veranstaltungen. - -## Control 8.4.2 — Test-/Erprobungsgelände - -> Im aktuellen Prüfziel (Prototypenteile/-komponenten) n.a. — nur relevant bei Prüfziel Fahrzeuge/Erprobung/Veranstaltungen. - -## Control 8.4.3 — Erprobungsfahrten öffentliche Straßen - -> Im aktuellen Prüfziel (Prototypenteile/-komponenten) n.a. — nur relevant bei Prüfziel Fahrzeuge/Erprobung/Veranstaltungen. - -## Control 8.5.1 — Ausstellungen und Veranstaltungen - -> Im aktuellen Prüfziel (Prototypenteile/-komponenten) n.a. — nur relevant bei Prüfziel Fahrzeuge/Erprobung/Veranstaltungen. - -## Control 8.5.2 — Film- und Fotoshootings - -> Im aktuellen Prüfziel (Prototypenteile/-komponenten) n.a. — nur relevant bei Prüfziel Fahrzeuge/Erprobung/Veranstaltungen. - -# Datenschutz (9.x) - -## Control 9.1.1 — Richtlinien zum Datenschutz - -### 9.1.1-M1 — [MUSS] -**Anforderung:** Richtlinie ist erstellt, wird regelmäßig aktualisiert und von der Leitung freigegeben. -- **Organisatorisch:** Datenschutzrichtlinie erstellen, durch Leitung freigeben, Review-Zyklus (mind. jährlich) und Verantwortliche festlegen; an Beschäftigte kommunizieren. -- **Technisch:** Versionierte Ablage im Dokumentenmanagement mit Freigabe-Workflow und Wiedervorlage. -- **Typische Nachweise:** Freigegebene Datenschutzrichtlinie, Freigabevermerk, Versions-/Reviewhistorie. -- **Vorlage:** Richtlinie Datenschutz (D01) / R14 Compliance & Datenschutz; VA-18. -- **Ressourcen:** DS-Funktion/Leitung; jährliche Pflege. -- **AL-Filter:** AL2 | AL3 - -## Control 9.2.1 — Verantwortlichkeiten für Datenschutz - -### 9.2.1-M1 — [MUSS] -**Anforderung:** Bestellung eines DSB (sofern gesetzlich erforderlich, Art. 37 DSGVO) bzw. Festlegung einer Datenschutzfunktion. -- **Organisatorisch:** Prüfen, ob DSB-Pflicht besteht; DSB förmlich bestellen oder Datenschutzfunktion benennen; Aufgaben festlegen. -- **Technisch:** Ablage der Bestellurkunde/Funktionsbeschreibung im DMS. -- **Typische Nachweise:** Bestellurkunde/Benennung, Aufgabenbeschreibung, Meldung an Aufsichtsbehörde (falls DSB). -- **Vorlage:** Richtlinie Datenschutz (D01) / R14 Compliance & Datenschutz; VA-18. -- **Ressourcen:** Leitung; ggf. externer DSB (Budget). -- **AL-Filter:** AL2 | AL3 - -### 9.2.1-M2 — [MUSS] -**Anforderung:** Veröffentlichung der Kontaktdaten (z. B. im Internet). -- **Organisatorisch:** Kontaktdaten der DS-Funktion/DSB veröffentlichen und aktuell halten. -- **Technisch:** Angabe in Datenschutzerklärung/Website, ggf. Meldung an Aufsichtsbehörde. -- **Typische Nachweise:** Website-/Impressumseintrag, Datenschutzerklärung, Behördenmeldung. -- **Vorlage:** Richtlinie Datenschutz (D01) / R14 Compliance & Datenschutz; VA-18. -- **Ressourcen:** Organisatorisch gering. -- **AL-Filter:** AL2 | AL3 - -### 9.2.1-M3 — [MUSS] -**Anforderung:** Eingliederung in die Unternehmensstruktur. -- **Organisatorisch:** Stellung der DS-Funktion (Weisungsfreiheit, direkte Berichtslinie an Leitung, Unabhängigkeit) im Organigramm verankern. -- **Technisch:** Dokumentation in Organigramm/Funktionsbeschreibung. -- **Typische Nachweise:** Organigramm, Rollen-/Funktionsbeschreibung. -- **Vorlage:** Richtlinie Datenschutz (D01) / R14 Compliance & Datenschutz; VA-18. -- **Ressourcen:** Organisatorisch. -- **AL-Filter:** AL2 | AL3 - -### 9.2.1-M4 — [MUSS] -**Anforderung:** Ausübung der Kontrollpflichten aus Art. 39 Abs. 1 lit. b) DSGVO und Dokumentation. -- **Organisatorisch:** Kontroll-/Überwachungsplan der DS-Funktion festlegen und durchführen. -- **Technisch:** Dokumentierte Audits/Kontrollen im DMS/Auditsystem. -- **Typische Nachweise:** Kontroll-/Auditplan, Prüfberichte, Maßnahmennachverfolgung. -- **Vorlage:** Richtlinie Datenschutz (D01) / R14 Compliance & Datenschutz; VA-18. -- **Ressourcen:** DS-Funktion; Zeitaufwand. -- **AL-Filter:** AL2 | AL3 - -### 9.2.1-M5 — [MUSS] -**Anforderung:** Dokumentation des datenschutzrechtlichen Status und Bericht an die höchste Managementebene. -- **Organisatorisch:** Regelmäßige Datenschutzberichte an die Leitung etablieren. -- **Technisch:** Berichts-/Reportingablage. -- **Typische Nachweise:** Datenschutzberichte, Protokolle der Managementberichterstattung. -- **Vorlage:** Richtlinie Datenschutz (D01) / R14 Compliance & Datenschutz; VA-18. -- **Ressourcen:** DS-Funktion/Leitung. -- **AL-Filter:** AL2 | AL3 - -### 9.2.1-M6 — [MUSS] -**Anforderung:** Ausstattung mit ausreichenden Kapazitäten/Ressourcen (Qualifikation, Fortbildung, Fachliteratur, Koordinatoren). -- **Organisatorisch:** Ressourcen, Qualifikation, Fortbildungen und ggf. Datenschutzkoordinatoren je Bereich sicherstellen. -- **Technisch:** Zugang zu Fachliteratur/DS-Tools, Schulungssystem. -- **Typische Nachweise:** Fortbildungsnachweise, Ressourcen-/Budgetzuweisung, Koordinatorenbenennung. -- **Vorlage:** Richtlinie Datenschutz (D01) / R14 Compliance & Datenschutz; VA-18. -- **Ressourcen:** Budget Fortbildung/Personal. -- **AL-Filter:** AL2 | AL3 - -## Control 9.3.1 — Verzeichnis von Verarbeitungstätigkeiten - -### 9.3.1-M1 — [MUSS] -**Anforderung:** Verzeichnis von Verarbeitungstätigkeiten (Art. 30 Abs. 1/2 DSGVO) mit Prozessbeschreibung und Zuständigkeiten. -- **Organisatorisch:** VVT erstellen und pflegen; bei Auftragsverarbeitung nur auftragsgegenständliche Angaben; Prozess mit Zuständigkeiten und Aktualisierung definieren. -- **Technisch:** VVT-Tool/Vorlage mit Änderungshistorie; Verknüpfung zu TOM (aus IS-Fragebogen). -- **Typische Nachweise:** Gepflegtes VVT, Prozessbeschreibung, Aktualisierungsnachweise. -- **Vorlage:** Richtlinie Datenschutz (D01) / R14 Compliance & Datenschutz; VA-18. -- **Ressourcen:** DS-Funktion; ggf. VVT-Tool. -- **AL-Filter:** AL2 | AL3 - -## Control 9.4.1 — Datenschutzfolgenabschätzung - -### 9.4.1-M1 — [MUSS] -**Anforderung:** Verarbeitungen, die eine DSFA benötigen, sind bekannt. -- **Organisatorisch:** Schwellwertanalyse/Kriterien zur DSFA-Pflicht festlegen und Verarbeitungen bewerten. -- **Technisch:** DSFA-Kennzeichnung im VVT/DS-Tool. -- **Typische Nachweise:** Schwellwertanalyse, Liste DSFA-pflichtiger Verarbeitungen. -- **Vorlage:** Richtlinie Datenschutz (D01) / R14 Compliance & Datenschutz; VA-18. -- **Ressourcen:** DS-Funktion. -- **AL-Filter:** AL2 | AL3 - -### 9.4.1-M2 — [MUSS] -**Anforderung:** DSFA werden durchgeführt; Verantwortlichkeiten/Unterstützung festgelegt und bekannt. -- **Organisatorisch:** DSFA-Prozess mit Rollen, Unterstützung und Freigabe definieren; DSFA durchführen. -- **Technisch:** DSFA-Methodik/Vorlage, Dokumentation im DS-Tool. -- **Typische Nachweise:** Durchgeführte DSFA, Prozessbeschreibung, Maßnahmenkatalog. -- **Vorlage:** Richtlinie Datenschutz (D01) / R14 Compliance & Datenschutz; VA-18. -- **Ressourcen:** DS-Funktion/Fachbereiche. -- **AL-Filter:** AL2 | AL3 - -## Control 9.5.1 — Management der Datenübermittlung - -### 9.5.1-M1 — [MUSS] -**Anforderung:** Prozesse/Arbeitsabläufe für Übermittlung (u. a. AV-Verträge Art. 28, Transferinstrumente, Zustimmung/Widerspruch bei Unterbeauftragung). -- **Organisatorisch:** Übermittlungsprozess mit Prüfung der Rechtsgrundlage, AV-Verträgen und Transferinstrumenten etablieren. -- **Technisch:** Vertrags-/Nachweismanagement mit Statusverfolgung. -- **Typische Nachweise:** AV-Verträge (Art. 28), SCC/TIA, Prozessbeschreibung, Zustimmungsnachweise. -- **Vorlage:** Richtlinie Datenschutz (D01) / R14 Compliance & Datenschutz; VA-18. -- **Ressourcen:** DS-Funktion/Recht. -- **AL-Filter:** AL2 | AL3 - -## Control 9.5.2 — Weitergabe vertraglicher Vereinbarungen an Unterauftragnehmer - -### 9.5.2-M1 — [MUSS] -**Anforderung:** Mit Auftraggebern vereinbarte vertragliche Vereinbarungen werden an Unterauftragsverarbeiter weitergegeben. -- **Organisatorisch:** Back-to-back-Weitergabe der Auftraggebervorgaben an Unterauftragnehmer sicherstellen. -- **Technisch:** Vertragsregister mit Verknüpfung Haupt-/Unterauftrag. -- **Typische Nachweise:** Unterauftrags-AV-Verträge, Vertragsregister. -- **Vorlage:** Richtlinie Datenschutz (D01) / R14 Compliance & Datenschutz; VA-18. -- **Ressourcen:** DS-Funktion/Einkauf. -- **AL-Filter:** AL2 | AL3 - -### 9.5.2-M2 — [MUSS] -**Anforderung:** Überprüfung der Einhaltung vertraglicher Vereinbarungen; aktuelle Ansprechpartner-Kontaktdaten verfügbar. -- **Organisatorisch:** Regelmäßige Kontrolle der Unterauftragnehmer und Pflege der Ansprechpartner-Kontaktdaten. -- **Technisch:** Lieferantenregister mit Kontrollstatus und Kontaktdaten. -- **Typische Nachweise:** Kontroll-/Auditnachweise, aktuelle Kontaktliste. -- **Vorlage:** Richtlinie Datenschutz (D01) / R14 Compliance & Datenschutz; R13 Lieferanten; VA-18. -- **Ressourcen:** DS-Funktion/Lieferantenmanagement. -- **AL-Filter:** AL2 | AL3 - -## Control 9.5.3 — Datenübermittlung in Drittländer - -### 9.5.3-M1 — [MUSS] -**Anforderung:** Drittlandübermittlungen sind bekannt und werden systematisch erfasst. -- **Organisatorisch:** Drittlandtransfers identifizieren und im VVT/Transferregister dokumentieren. -- **Technisch:** Kennzeichnung Drittlandtransfers im DS-Tool. -- **Typische Nachweise:** Transferübersicht, VVT-Einträge. -- **Vorlage:** Richtlinie Datenschutz (D01) / R14 Compliance & Datenschutz; VA-18. -- **Ressourcen:** DS-Funktion. -- **AL-Filter:** AL2 | AL3 - -### 9.5.3-M2 — [MUSS] -**Anforderung:** Geeignete Garantien (Kapitel V DSGVO, EuGH-Rechtsprechung, ggf. TIA) liegen vor. -- **Organisatorisch:** Transferinstrumente je Drittlandtransfer festlegen und TIA bei Relevanz durchführen. -- **Technisch:** Ablage SCC/Angemessenheitsbeschluss/TIA im Vertrags-/DS-Tool. -- **Typische Nachweise:** SCC/Garantien, TIA, Angemessenheitsnachweise. -- **Vorlage:** Richtlinie Datenschutz (D01) / R14 Compliance & Datenschutz; VA-18. -- **Ressourcen:** DS-Funktion/Recht. -- **AL-Filter:** AL2 | AL3 - -### 9.5.3-M3 — [MUSS] -**Anforderung:** Prüfung, ob Zustimmung des Verantwortlichen zu jeder Drittlandübermittlung einzuholen ist. -- **Organisatorisch:** Zustimmungsprüfung als Prozessschritt vor Drittlandtransfer verankern. -- **Technisch:** Freigabe-/Zustimmungsworkflow mit Dokumentation. -- **Typische Nachweise:** Zustimmungsnachweise, Prozessbeschreibung. -- **Vorlage:** Richtlinie Datenschutz (D01) / R14 Compliance & Datenschutz; VA-18. -- **Ressourcen:** DS-Funktion. -- **AL-Filter:** AL2 | AL3 - -## Control 9.6.1 — Betroffenenanfragen - -### 9.6.1-M1 — [MUSS] -**Anforderung:** Betroffenenanfragen werden fristgerecht bearbeitet; Verfahren zur Unterstützung des Verantwortlichen; Mitarbeiterschulung zur Weiterleitung. -- **Organisatorisch:** Prozess zur Erkennung, Weiterleitung und fristgerechten Bearbeitung von Betroffenenanfragen etablieren; Mitarbeiter schulen, unverzüglich den Verantwortlichen zu kontaktieren. -- **Technisch:** Ticket-/Fallmanagement mit Fristenüberwachung. -- **Typische Nachweise:** Prozessbeschreibung, Fallakten mit Fristen, Schulungsnachweise. -- **Vorlage:** Richtlinie Datenschutz (D01) / R14 Compliance & Datenschutz; VA-18. -- **Ressourcen:** DS-Funktion; ggf. Fallmanagement-Tool. -- **AL-Filter:** AL2 | AL3 - -## Control 9.6.2 — Datenschutzvorfälle - -### 9.6.2-M1 — [MUSS] -**Anforderung:** Datenschutzvorfälle werden fristgerecht bearbeitet. -- **Organisatorisch:** Meldeprozess mit Fristen (u. a. 72-Stunden-Betrachtung) und Zuständigkeiten festlegen. -- **Technisch:** Vorfallmanagement mit Fristen-/Eskalationssteuerung. -- **Typische Nachweise:** Vorfallprozess, Vorfalldokumentation mit Fristen. -- **Vorlage:** Richtlinie Datenschutz (D01) / R14 Compliance & Datenschutz; VA-18. -- **Ressourcen:** DS-Funktion. -- **AL-Filter:** AL2 | AL3 - -### 9.6.2-M2 — [MUSS] -**Anforderung:** Maßnahmen aus IS 1.6.1 berücksichtigen auch Datenschutzvorfälle, alternativ eigener Notfallplan. -- **Organisatorisch:** Datenschutzvorfälle in das ISMS-Incident-Management integrieren oder eigenen DS-Notfallplan erstellen. -- **Technisch:** Gemeinsames/verknüpftes Incident-Tool. -- **Typische Nachweise:** Incident-Prozess mit DS-Bezug bzw. DS-Notfallplan. -- **Vorlage:** Richtlinie Datenschutz (D01) / R14 Compliance & Datenschutz; VA-18. -- **Ressourcen:** DS-Funktion/ISB. -- **AL-Filter:** AL2 | AL3 - -### 9.6.2-M3 — [MUSS] -**Anforderung:** Etablierte/dokumentierte Verfahren: unverzügliche Meldung an Verantwortlichen, Prozessdokumentation, Mitarbeiterschulung, Unterstützung des Verantwortlichen. -- **Organisatorisch:** Meldeweg zum Verantwortlichen, Dokumentationspflichten und Mitarbeiterschulung festlegen. -- **Technisch:** Meldeworkflow mit Benachrichtigung des Verantwortlichen. -- **Typische Nachweise:** Verfahrensbeschreibung, Meldenachweise, Schulungsnachweise. -- **Vorlage:** Richtlinie Datenschutz (D01) / R14 Compliance & Datenschutz; VA-18. -- **Ressourcen:** DS-Funktion. -- **AL-Filter:** AL2 | AL3 - -## Control 9.7.1 — Verpflichtung der Mitarbeiter auf Vertraulichkeit - -### 9.7.1-M1 — [MUSS] -**Anforderung:** Mitarbeiter mit Bezug zu personenbezogenen Daten werden dokumentiert zur Vertraulichkeit (auch über das Arbeitsverhältnis hinaus) und Datenschutz verpflichtet. -- **Organisatorisch:** Vertraulichkeits-/Datenschutzverpflichtung in Onboarding aufnehmen und dokumentieren. -- **Technisch:** HR-System mit Erfassung/Nachverfolgung der Verpflichtungen. -- **Typische Nachweise:** Unterzeichnete Verpflichtungserklärungen, Vollständigkeitsübersicht. -- **Vorlage:** Richtlinie Datenschutz (D01) / R14 Compliance & Datenschutz; VA-18. -- **Ressourcen:** HR/DS-Funktion. -- **AL-Filter:** AL2 | AL3 - -## Control 9.7.2 — Schulung der Mitarbeiter zum Datenschutz - -### 9.7.2-M1 — [MUSS] -**Anforderung:** Mitarbeiter sind geschult/sensibilisiert; Abstufung nach Schutzbedarf; spezifische Unterweisung kritischer Bereiche (z. B. IT-Admins). -- **Organisatorisch:** Datenschutz-Schulungskonzept mit Abstufung nach Schutzbedarf und rollenspezifischen Inhalten festlegen. -- **Technisch:** LMS mit Pflichtzuweisung, rollenspezifischen Modulen und Fälligkeitssteuerung. -- **Typische Nachweise:** Schulungskonzept, Teilnahmenachweise, rollenspezifische Unterweisungen. -- **Vorlage:** Richtlinie Datenschutz (D01) / R14 Compliance & Datenschutz; VA-18. -- **Ressourcen:** DS-Funktion/HR; Schulungsbudget. -- **AL-Filter:** AL2 | AL3 - -## Control 9.8.1 — Umgang mit Weisungen in Auftragsverarbeitungsverhältnissen - -### 9.8.1-M1 — [MUSS] -**Anforderung:** Umgang mit Weisungen zur auftragsgegenständlichen Verarbeitung ist gewährleistet. -- **Organisatorisch:** Weisungsprozess mit definierten weisungsberechtigten/-empfangenden Stellen festlegen. -- **Technisch:** Dokumentierte Weisungsablage mit Nachverfolgung. -- **Typische Nachweise:** Weisungsprozess, dokumentierte Weisungen. -- **Vorlage:** Richtlinie Datenschutz (D01) / R14 Compliance & Datenschutz; VA-18. -- **Ressourcen:** DS-Funktion. -- **AL-Filter:** AL2 | AL3 - -### 9.8.1-M2 — [MUSS] -**Anforderung:** Verfahren stellen sicher: Weisungen dokumentiert, umsetzbar (Berichtigen/Löschen), Daten nach Auftraggeber/Auftrag getrennt. -- **Organisatorisch:** Verfahren für Dokumentation, Umsetzung (Berichtigung/Löschung) und Mandantentrennung der Daten festlegen. -- **Technisch:** Mandantengetrennte Datenhaltung, Lösch-/Berichtigungsfunktionen, Protokollierung. -- **Typische Nachweise:** Verfahrensbeschreibung, Nachweis Datentrennung, Lösch-/Berichtigungsprotokolle. -- **Vorlage:** Richtlinie Datenschutz (D01) / R14 Compliance & Datenschutz; VA-18. -- **Ressourcen:** DS-Funktion/IT. -- **AL-Filter:** AL2 | AL3 diff --git a/docs/wizard-uebergabe/02_Fachcontent_C1-C9/C7_Rollen-Funktionstrennung.md b/docs/wizard-uebergabe/02_Fachcontent_C1-C9/C7_Rollen-Funktionstrennung.md deleted file mode 100644 index 3a6b286..0000000 --- a/docs/wizard-uebergabe/02_Fachcontent_C1-C9/C7_Rollen-Funktionstrennung.md +++ /dev/null @@ -1,61 +0,0 @@ -# C7 — ISMS-Soll-Rollenmodell + Funktionstrennung (+ Bestellungs-Vorlage) - -> **Schaltet frei:** A4 (ISMS-Rollen & Funktionstrennung, Schritt 3). **Grundlage:** `variables.schema.json` (`ROLE_*`), Richtlinie `R01_ISMS-Organisation-und-Rollen`. - -## 1. Soll-Rollenmodell - -| Rolle | Variable | Kernverantwortung | Besetzung | -|---|---|---|---| -| Oberste Leitung | `ROLE_MANAGEMENT` | Gesamtverantwortung ISMS, Ressourcen, Freigabe von Leitlinie/Richtlinien, Managementbewertung | intern (GF) | -| Informationssicherheitsbeauftragte(r) | `ROLE_ISB` | Aufbau/Pflege/Weiterentwicklung ISMS, Beratung der Leitung, Risikomanagement, Audits, Meldeweg; berichtet direkt an die Leitung | intern **oder** extern | -| IT-Leitung / IT-Verantwortung | `ROLE_IT_LEAD` | Betrieb, technische Umsetzung der Maßnahmen | intern oder extern (Dienstleister) | -| Personalleitung | `ROLE_HR_LEAD` | Personalsicherheit, On-/Offboarding, Awareness | intern | -| Datenschutzbeauftragte(r) | `ROLE_DPO` | Datenschutz-Compliance (bei Verarbeitung personenbezogener Daten) | intern oder extern | - -Bezug: Controls 1.2.1/1.2.2 (Organisation der IS), 2.1.x (Personal), 7.1.2 (Datenschutz). Rollen-Variablen befüllen Platzhalter in allen Vorlagen (Verantwortlich/Freigabe). - -## 2. Funktionstrennungs-Regeln (Prüfung im Wizard) - -| Regel-ID | Bedingung | Ergebnis | Begründung | -|---|---|---|---| -| FT-01 | `ROLE_ISB` = `ROLE_IT_LEAD` (dieselbe Person, beide intern) | **Konflikt** → Hinweis + Aufgabe | ISB muss die IT unabhängig überwachen können; Selbstkontrolle unzulässig | -| FT-02 | `ROLE_ISB` intern **und** direkt der IT-Leitung unterstellt | **Konflikt (schwach)** → Hinweis | Weisungsunabhängigkeit/Berichtsweg an Leitung gefährdet | -| FT-03 | `ROLE_ISB` = `ROLE_MANAGEMENT` | **Konflikt** → Hinweis + Aufgabe | Leitung kann eigene ISMS-Verantwortung nicht selbst überwachen | -| FT-04 | `ROLE_ISB` nicht benannt | **Lücke** → Aufgabe „ISB bestellen" (Control 1.2.2) | ISB ist Muss-Anforderung | -| FT-05 | `ROLE_DPO` fehlt trotz `FLAG_PERSONAL_DATA` | **Lücke** → Aufgabe „DSB benennen/prüfen" | Datenschutz-Organisation erforderlich | -| FT-06 | Antragsteller = Genehmiger von Zugriffsrechten (aus IAM-Daten) | **Konflikt** → Hinweis | Vier-Augen bei Berechtigungsvergabe (Control 4.2.1) | - -**Kompensierende Kontrollen** (wenn Trennung z. B. bei Kleinorganisation nicht möglich): externer ISB (GEFIM-Modell), Vier-Augen mit der Leitung, dokumentierte Ausnahmegenehmigung + verstärkte Protokollierung. Der Wizard bietet bei Konflikt „Trennung herstellen" **oder** „kompensierende Kontrolle dokumentieren" (→ Aufgabe bzw. Nachweis). - -## 3. Bestellungs-/Ernennungs-Vorlage (Paket-Stil) - -Neue Vorlage `VA-00_ISB-Bestellung.md` bzw. Textbaustein in `R01`, mit Platzhaltern und Ankern: - -```markdown -# Bestellung Informationssicherheitsbeauftragte(r) - -| Feld | Wert | -|------|------| -| Organisation | {{ORG_NAME}} | -| Bestellte Person / Funktion | {{ROLE_ISB}} | -| Bestellt durch | {{ROLE_MANAGEMENT}} | -| Besetzung | {{#if FLAG_ISB_EXTERNAL}}extern (Dienstleistervertrag){{/if}}{{#if FLAG_ISB_INTERNAL}}intern{{/if}} | -| Version / Datum / Status | {{DOC_VERSION}} / {{DOC_DATE}} / {{DOC_STATUS}} | - - -Die Organisation {{ORG_NAME}} bestellt {{ROLE_ISB}} mit Wirkung zum {{DOC_DATE}} zum/zur Informationssicherheitsbeauftragten. - -## Aufgaben und Befugnisse -- Aufbau, Pflege und Weiterentwicklung des ISMS gemäß VDA ISA. -- Beratung der Leitung; jährliche Überprüfung von Richtlinien und Wirksamkeit. -- Koordination von Risikomanagement, Schulungen, Audits, Maßnahmen. -- Melde-/Eskalationsrecht direkt an {{ROLE_MANAGEMENT}}; Zugang zu relevanten Informationen/Systemen. - -## Freigabe -| Rolle | Name | Datum, Unterschrift | -|-------|------|---------------------| -| Leitung | {{ROLE_MANAGEMENT}} | | -| ISB | {{ROLE_ISB}} | | -``` - -Neue Flags bei Bedarf in `variables.schema.json`: `FLAG_ISB_EXTERNAL` / `FLAG_ISB_INTERNAL` (aus Q-ROLE-02). Nach Anlage `_verify.py` → **OK**. diff --git a/docs/wizard-uebergabe/02_Fachcontent_C1-C9/C8_Priorisierung-Gap.md b/docs/wizard-uebergabe/02_Fachcontent_C1-C9/C8_Priorisierung-Gap.md deleted file mode 100644 index 741f424..0000000 --- a/docs/wizard-uebergabe/02_Fachcontent_C1-C9/C8_Priorisierung-Gap.md +++ /dev/null @@ -1,37 +0,0 @@ -# C8 — Priorisierungslogik Gap + Quick-Wins - -> **Schaltet frei:** A8 (Gap-Konsolidierung, Schritt 8). **Grundlage:** Ergebnisse aus Schritt 6 (Risiko) und 7 (Control-Assessment), Aufgaben-Modul. - -## 1. Prioritätsregeln (deterministisch) - -Priorität eines offenen Punkts = höchste zutreffende Regel: - -| Priorität | Bedingung | -|---|---| -| **Hoch** | Offene **MUSS**-Anforderung (Reifegrad < 2) · **oder** offene AL3-Zusatzanforderung (`HOCH`/`SEHR HOCH`) bei entsprechendem Schutzbedarf · **oder** Behandlungsmaßnahme zu einem Risiko oberhalb der Akzeptanzlinie · **oder** fehlende Muss-Rolle/Funktionstrennungs-Konflikt (C7 FT-01/03/04) | -| **Mittel** | Offene **SOLL**-Anforderung · Reifegrad = 2 aber unter Zielreifegrad 3 · Nachweis vorhanden aber nicht validiert · Dokument im Entwurf/nur als Vorlage | -| **Niedrig** | Redaktioneller/formaler Punkt · Optimierung ohne Reifegrad-Wirkung · Nachweis nur zu aktualisieren | - -Zusatzgewichtung (Sortierung innerhalb gleicher Priorität): (1) Anzahl betroffener Controls, (2) Risikohöhe des verknüpften Risikos, (3) Aufwand aufsteigend (Quick-Wins zuerst). - -## 2. Deduplizierung - -Offene Punkte aus Schritt 6 und 7 werden zusammengeführt. Dedup-Schlüssel = (Control + Teilanforderungs-ID) bzw. (verknüpfte Maßnahme/Aufgabe). Regeln: - -- Gleiche Teilanforderung aus mehreren Quellen → **ein** Punkt, höchste Priorität gewinnt, Quellen werden verknüpft. -- Ein offener Punkt, für den bereits eine Aufgabe existiert → keine neue Aufgabe, bestehende verknüpfen. -- Risiko-Maßnahme und Control-Gap, die dieselbe Maßnahme adressieren (z. B. „Patchmanagement einführen" für Risiko R-OPS-03 und Controls 5.2.3/5.2.5) → zusammenführen, alle Bezüge an die eine Aufgabe hängen. - -## 3. Quick-Wins - -Ein offener Punkt ist **Quick-Win**, wenn: geringer Aufwand (organisatorisch/redaktionell, kein Tool-/Budgetbedarf) **und** Reifegrad-Wirkung ≥ +1 auf mindestens ein Control **und** keine Abhängigkeit von anderer offener Maßnahme. Typische Quick-Wins: Freigabe/Validierung eines bereits erstellten Dokuments, Befüllen einer vorhandenen Vorlage (Konten-Review, Rezertifizierung), Rollen-/Funktionstrennungs-Dokumentation, Redaktionslücken schließen. Der Wizard hebt Quick-Wins im Maßnahmenplan gesondert hervor (Reihenfolge-Empfehlung „erst Quick-Wins, dann Hoch-Aufwand"). - -## 4. Beispiel-Priorisierung - -| Offener Punkt | Regel | Priorität | Quick-Win? | -|---|---|---|---| -| Kein Patchmanagement (Controls 5.2.3/5.2.5, Risiko R-OPS-03) | MUSS < 2 + Risiko | Hoch | nein (Tool) | -| Restore-Test nicht durchgeführt (5.2.9, BL-OPS-06) | MUSS-Nachweis fehlt | Hoch | ja (organisatorisch) | -| ISB = IT-Verantwortung (FT-01) | Funktionstrennungs-Konflikt | Hoch | teils (extern/kompensieren) | -| SOLL Berechtigungs-Review nur als Vorlage (4.2.1) | SOLL, nicht validiert | Mittel | ja | -| Zonenbezeichnung inkonsistent (3.1.1) | redaktionell | Niedrig | ja | diff --git a/docs/wizard-uebergabe/02_Fachcontent_C1-C9/C9_Auswertung-Export.md b/docs/wizard-uebergabe/02_Fachcontent_C1-C9/C9_Auswertung-Export.md deleted file mode 100644 index 4ba029c..0000000 --- a/docs/wizard-uebergabe/02_Fachcontent_C1-C9/C9_Auswertung-Export.md +++ /dev/null @@ -1,49 +0,0 @@ -# C9 — Auswertungs-/Interpretationstexte + Export-Layout - -> **Schaltet frei:** B7 (Assessment-Readiness & Export, Schritt 9). **Grundlage:** validierte Control-Bewertungen (Schritt 7), Gap-/Maßnahmenliste (Schritt 8), Validierungsstatus (A3). - -## 1. Reifegrad-Dashboard — Interpretationstexte - -Aggregation je Kapitel und gesamt (Durchschnitt der Control-Reifegrade, „unbestätigt" zählt nicht als erfüllt). Textbänder nach Gesamtreifegrad: - -| Reifegrad (Ø) | Band | Interpretationstext | -|---|---|---| -| < 1,5 | Aufbau | „Das ISMS befindet sich im Aufbau. Wesentliche Richtlinien/Verfahren sind noch zu erstellen oder freizugeben. Fokus: Muss-Anforderungen und Grundstruktur." | -| 1,5 – < 2,5 | Etabliert im Aufbau | „Grundlegende Prozesse sind vorhanden und teils dokumentiert. Für Assessment-Reife fehlen v. a. Nachweise der gelebten Anwendung und Validierungen." | -| 2,5 – < 3,0 | Assessment-nah | „Das ISMS ist überwiegend etabliert. Wenige offene Punkte und Nachweise trennen von der Assessment-Reife (AL-Ziel). Fokus: Hoch-Punkte schließen, Wirksamkeitsnachweise ergänzen." | -| = 3,0 | Assessment-reif | „Die bewerteten Controls erfüllen den Zielreifegrad. Empfehlung: Stichprobenvalidierung und Aktualität der Nachweise vor dem Assessment sicherstellen." | - -Zusätzliche Kennzahlen: Anteil bestätigter (validierter) Controls, Anzahl offener Punkte je Priorität, Abdeckung je Prüfziel, „höchstes erreichbares Ergebnis" = Zielreifegrad. - -## 2. Empfohlene nächste Schritte (dynamisch) - -Regelbasiert eingeblendet: - -- Offene **Hoch**-Punkte vorhanden → „Vor dem Assessment zwingend: die N Hoch-Punkte im Maßnahmenplan abarbeiten (siehe Aufgaben)." -- Unvalidierte Objekte vorhanden → „X Objekte warten auf Validierung durch ISB/Berater — bis dahin als ‚unbestätigt' gewertet." -- Prüfziel Prototypenschutz aktiv & 8.x < Ziel → „Prototypenspezifische Nachweise ergänzen (physische Schutzmaßnahmen, Zutritt, Transport)." -- Nachweis-Upload-Iteration noch offen → „Operative Nachweise (Screenshots/Protokolle) in der Folgeiteration hochladen." - -## 3. VDA-ISA-Katalog-Export — Layout - -**Struktur (je Prüfziel ein Tabellenblatt/Abschnitt, Reihenfolge Informationssicherheit → Prototypenschutz → Datenschutz):** - -| Feld | Inhalt | Quelle | -|---|---|---| -| Control-ID | z. B. 4.1.2 | Katalog | -| Kontrollfrage / Ziel | aus Katalog | Katalog | -| Reifegrad | 0–3 (bestätigt) bzw. „na" | Schritt 7 | -| Status | bestätigt / unbestätigt | A3-Validierung | -| Umsetzungsbeschreibung | je Teilanforderung: **Anforderung (fett)** + Umsetzung (normal), Reihenfolge MUSS→SOLL→HOCH→SEHR HOCH | Schritt 7 + Vorlagen-IMPL | -| Belege | verknüpfte Dokumente/Verfahren/Risiken/Assets | Schritt 4–7 | -| Offene Punkte | je Control aus Gap-Liste | Schritt 8 | - -**Darstellungsregeln:** Anforderungstext im Originalwortlaut, **fett**; Umsetzung normal darunter mit Quellenangabe (Dokument, Version/Stand, Kapitel) — konsistent zur bisherigen Ausarbeitung. „Unbestätigt" sichtbar markieren (z. B. Kennzeichnung/Farbe). Ergänzungshinweise/offene Punkte **nicht** im Katalog, sondern in der separaten Maßnahmen-/Schwachstellenliste. - -**Exportformate:** XLSX (VDA-ISA-Katalogsicht + Ergebnisblatt mit Reifegrad-Kennzahlen), zusätzlich DOCX/PDF für Management-Zusammenfassung. Der Export koppelt an den bestehenden DOCX/PDF-Export der App. - -## 4. Zusatzartefakte im Export - -- **Maßnahmenplan** (aus C8): priorisierte offene Punkte + verknüpfte Aufgaben, Quick-Wins hervorgehoben. -- **Nachweisregister** (aus `Nachweisregister_zentral.md`): je Anforderung der zugeordnete Nachweis/Status. -- **Management-Zusammenfassung**: Stärken, Reifegrad-Überblick, Hoch-Punkte, empfohlene Schritte vor dem Assessment. diff --git a/docs/wizard-uebergabe/03_Referenz/Onboarding_Wizard_Fahrplan_Detail.md b/docs/wizard-uebergabe/03_Referenz/Onboarding_Wizard_Fahrplan_Detail.md deleted file mode 100644 index 3e282c3..0000000 --- a/docs/wizard-uebergabe/03_Referenz/Onboarding_Wizard_Fahrplan_Detail.md +++ /dev/null @@ -1,233 +0,0 @@ -# Onboarding-Wizard ISMS – Detaillierter Fahrplan & Entwickler-Handlungsanweisung - -**Produkt:** ISMS-Applikation – Onboarding-Wizard -**Fokus der ersten Ausbaustufe:** TISAX / VDA ISA -**Ziel (North Star):** Assessment-Readiness – am Ende des Wizards liegt ein vorausgefüllter VDA-ISA-Katalog inkl. Reifegrad-Ersteinschätzung und Maßnahmenplan vor. -**Modus:** Kunde bearbeitet eigenständig; ISB oder externer Berater (falls gebucht) validiert an definierten Gates. -**Tailoring:** Template- und regelbasiert; eigene Richtlinien optional hochladbar; die mitgelieferten Vorlagen sind optional. -**Status:** Detailausarbeitung zur Verifizierung vor der technischen Umsetzung. - ---- - -## 1. Lesehinweis & Konventionen - -Dieses Dokument beschreibt je Wizard-Schritt: Zweck, Ein-/Ausgaben, Verarbeitungslogik, erzeugte Objekte, kontextsensitive Umsetzungshinweise, Aufgaben-Trigger, Validierung, benötigte Entwicklungs-Ressourcen und Akzeptanzkriterien. Es ist eine fachliche Handlungsanweisung, keine technische Spezifikation – Technologiewahl, konkrete Schemata und UI-Design folgen in der Umsetzung. - -**Aufwands-/Ressourcengröße (T-Shirt):** S = klein, M = mittel, L = groß. Bezieht sich auf den Entwicklungsaufwand des jeweiligen Bausteins, nicht auf die Kundenlaufzeit. - -**Rollen im Wizard** - -| Rolle | Aufgabe | -|---|---| -| Bearbeiter (Kunde) | Durchläuft die Schritte, gibt Fakten ein, wählt/erstellt Dokumente, bewertet Controls und Risiken | -| Validierer (ISB intern oder externer Berater) | Prüft und gibt Module/Objekte frei; ohne Freigabe fließt Inhalt als „unbestätigt" in die Auswertung | -| Systemadministrator (Vorbedingung) | Richtet Mandant, Nutzer und Rollen ein – **außerhalb** des Wizards | - ---- - -## 2. Querschnittsmechaniken (gelten in allen Schritten) - -Diese vier Mechaniken sind kein eigener Schritt, sondern durchziehen den gesamten Wizard und sollten früh als wiederverwendbare Bausteine gebaut werden. - -### 2.1 Validierungs-Workflow - -Jedes bearbeitbare Objekt (Modul, Richtlinie, Risiko, Control-Bewertung) trägt einen Status: `offen → in Bearbeitung → zur Validierung → validiert` (bzw. `zurückgewiesen` mit Kommentar). Nur validierte Inhalte zählen in der Assessment-Readiness-Auswertung als „bestätigt". Der Validierer erhält je Objekt Kontext, Kommentar- und Freigabefunktion. Ist kein externer Berater gebucht, übernimmt der interne ISB die Validierung. -**Ressourcen:** Backend (Statusmodell, Rechte) M · Frontend (Review-Ansicht, Kommentare) M. - -### 2.2 Umsetzungshinweise („So setzen Sie diese Anforderung um") - -An jeder VDA-ISA-Teilanforderung (und optional an Risiken/Templates) hängt redaktioneller Hinweis-Content, der bei der Bearbeitung kontextsensitiv eingeblendet wird. Ein Hinweis umfasst typischerweise: organisatorische Umsetzungsoption, technische Umsetzungsoption, typische Nachweise, geeignete Vorlage (Verweis) und eine **Ressourcenindikation** (Tool/Personal/Budget/Zeit). Die Einblendung wird über Scope und Antworten gefiltert (z. B. nur AL3-relevante Hinweise). Hinweise sind Wissensinhalt, keine trackbare Aufgabe – führt ein Hinweis zu einer umzusetzenden Maßnahme, entsteht daraus eine Aufgabe (siehe 2.3). -**Ressourcen:** Fachredaktion/ISMS-SME (Content-Pflege) L · Backend (Hinweis-Datenmodell, Filter) S · Frontend (Inline-Panel) S. - -### 2.3 Maßnahmen → Aufgaben-Modul - -Ergibt sich bei der Bearbeitung eine umzusetzende Maßnahme (z. B. „Patchmanagement-Tool einführen", „Berechtigungs-Review etablieren", „Notfallübung durchführen"), wird daraus eine **Aufgabe im Aufgaben-Modul** erzeugt – automatisch vorgeschlagen und vom Bearbeiter bestätigt. Trigger-Punkte: Richtlinie „später erstellen" (Schritt 4), Risikobehandlung (Schritt 6), Control-Lücke/Reifegrad < Ziel (Schritt 7), Gap-Liste (Schritt 8), Zurückweisung durch Validierer. - -**Aufgaben-Objekt (Felder):** Titel, Beschreibung, Typ (`Dokument erstellen` / `Nachweis liefern` / `technische Maßnahme` / `organisatorische Maßnahme`), Verantwortlicher, Fälligkeit, Priorität, Status, Verknüpfung (Control / Risiko / Dokument / Asset), **benötigte Ressourcen** (Tool, Budget, Personal, Zeit), Herkunft (auslösender Schritt). Die Ressourcenindikation stammt aus dem Umsetzungshinweis und ist editierbar. - -*Beispiel:* Control 5.2.3/5.2.5 unzureichend → Hinweis „technische Umsetzung: zentrales Patchmanagement" → Aufgabe „Patchmanagement-Tool auswählen und einführen", Typ `technische Maßnahme`, verknüpft mit 5.2.3 und 5.2.5, Ressourcen: Tool-Lizenz + IT-Personal ca. X PT, Priorität Hoch. -**Ressourcen:** Backend (Task-Generierung, Verknüpfungen, API zum Aufgaben-Modul) M · Frontend (Vorschlag/Bestätigung, Ressourcenfelder) M. Voraussetzung: Aufgaben-Modul der App existiert bzw. bietet eine Schnittstelle. - -### 2.4 Audit-Trail & Versionierung - -Jede Eingabe, Statusänderung und Freigabe wird protokolliert (wer/wann/was). Templates, Katalog und Risikokatalog sind versioniert; Kundendokumente referenzieren die genutzte Template-Version. -**Ressourcen:** Backend (Event-Log, Versionierung) M. - ---- - -## 3. Fachliche Bausteine / Datenobjekte (Fundament) - -| Baustein | Inhalt | Ressourcen | -|---|---|---| -| Control-Katalog VDA ISA | Prüfziele, Assessment-Level, je Control die Muss-/Soll-/Zusatzanforderungen als einzeln adressierbare Teilanforderungen | SME (Datenpflege) M · Backend (Import/Modell) S | -| Template-Bibliothek (optional) | Richtlinien-/VA-Vorlagen mit Platzhaltern, optionalen Bausteinen und Control-Verknüpfung | SME/Content L · Backend S | -| Upload-Pfad eigene Dokumente | Upload + Zuordnung „welche Controls belegt dieses Dokument" | Backend S · Frontend S | -| Fakten-/Fragemodell | Antwortobjekte zu Organisation, IT, Dienstleistern, Prozessen; wiederverwendbar | SME (Fragebogen) M · Backend M | -| Risiko-Katalog | Standard- und VDA-geforderte Risiken, vordefiniert und erweiterbar; Verknüpfung zu Controls/Assets | SME L · Backend M | -| Regel-/Mapping-Layer | Antwort → Platzhalter, Klausel-Ein/Ausblendung, betroffene Controls/Assets/Risiken | Backend (Regel-Engine) L | -| Reifegrad-/Gap-Engine | Reifegrad-Ersteinschätzung + offene Punkte je Control | Backend M · SME (Logik) M | - ---- - -## 4. Die Schritte im Detail - -> Vorbedingung (außerhalb des Wizards): technisches Onboarding – Mandant, Nutzer, Rollen eingerichtet. - -### Schritt 1 – Scoping - -- **Zweck:** Prüfziele, Assessment-Level (AL2/AL3), Standorte und Geltungsbereich festlegen. Dies steuert, welche Controls, Templates und Risiken im weiteren Verlauf überhaupt relevant sind. -- **Eingaben:** Prüfziele (Info-Sicherheit, Prototypenschutz, Datenschutz), Assessment-Level, Standort(e), organisatorischer/technischer Geltungsbereich, Ausschlüsse. -- **Verarbeitung & Regeln:** Aktiviert/deaktiviert Control-Set und Template-Set; z. B. Prototypenschutz nur bei entsprechendem Prüfziel, AL3 schaltet Zusatzanforderungen „sehr hoher Schutzbedarf" frei. -- **Erzeugte Objekte:** Scope-Objekt; gefiltertes Control-Set als Arbeitsgrundlage. -- **Umsetzungshinweise:** Erläuterung der Prüfziele und Level (Entscheidungshilfe AL2 vs. AL3), typische Scope-Formulierungen. -- **Aufgaben-Trigger:** i. d. R. keine. -- **Validierung:** Scope wird durch ISB/Berater bestätigt (Fundament für alles Weitere). -- **Ressourcen (Entwicklung):** Frontend (Scoping-UI) S · Backend (Scope-Filterlogik) M · SME (Scope-Regeln) S. -- **Akzeptanzkriterien:** Geänderter Scope filtert nachgelagerte Schritte korrekt; nicht relevante Controls/Templates sind ausgeblendet. - -### Schritt 2 – Kontextaufnahme (Gegebenheiten) - -- **Zweck:** Die tatsächlichen Gegebenheiten der Organisation als Faktenbasis erheben, die Platzhalter befüllt und Regeln aktiviert. -- **Eingaben:** Geführter Fragebogen – Unternehmensdaten, Organisationsstruktur, IT-Landschaft (Systeme, Cloud, Netzwerke), eingesetzte Dienstleister, relevante Prozesse, grundlegender Schutzbedarf. -- **Verarbeitung & Regeln:** Antworten werden als wiederverwendbare Faktenobjekte gespeichert und mit Platzhaltern, Klauselregeln, Controls, Assets und Risiken verknüpft. Bedingte Fragen (nur anzeigen, wenn relevant). -- **Erzeugte Objekte:** Faktenprofil der Organisation. -- **Umsetzungshinweise:** Erläuterung, warum eine Angabe gebraucht wird und wie sie sich auf Dokumente/Bewertung auswirkt. -- **Aufgaben-Trigger:** Fehlende Grundvoraussetzung erkennbar (z. B. „kein Inventar vorhanden") → optionale Aufgabe. -- **Validierung:** Plausibilitätsprüfung durch ISB/Berater. -- **Ressourcen (Entwicklung):** Frontend (dynamischer Fragebogen) M · Backend (Faktenmodell, bedingte Logik) M · SME (Fragenkatalog) M. -- **Akzeptanzkriterien:** Antworten sind wiederverwendbar; eine Änderung propagiert sichtbar in abhängige Objekte. - -### Schritt 3 – Rollen & Verantwortlichkeiten - -- **Zweck:** ISMS-Rollen festlegen (Geschäftsführung, ISB/DSB, IT-Verantwortung), inkl. Funktionstrennung. -- **Eingaben:** Personen/Funktionen je Rolle; intern/extern; Weisungs-/Berichtswege. -- **Verarbeitung & Regeln:** Prüft auf Funktionstrennung (z. B. ISB ≠ IT-Verantwortung); befüllt Rollen-Platzhalter in Dokumenten (Bestellungen/Ernennungen). -- **Erzeugte Objekte:** Rollenmodell; Dokumente wie ISB-Bestellung (aus Vorlage, optional). -- **Umsetzungshinweise:** Anforderungen an ISB-Qualifikation, externe vs. interne Besetzung, typische Nachweise. -- **Aufgaben-Trigger:** Fehlende ISB-Bestellung / fehlende Funktionstrennung → Aufgabe (organisatorische Maßnahme). -- **Validierung:** Freigabe des Rollenmodells. -- **Ressourcen (Entwicklung):** Frontend S · Backend (Rollenmodell, Regelprüfung) M · SME S. -- **Akzeptanzkriterien:** Funktionstrennungs-Konflikt wird erkannt und als Hinweis/Aufgabe ausgewiesen. - -### Schritt 4 – Richtlinien & Verfahrensanweisungen - -- **Zweck:** Für jeden relevanten Themenbereich die belegenden Dokumente bereitstellen – flexibel in der Quelle. -- **Eingaben:** Je Themenbereich Auswahl einer von drei Optionen: - (a) mitgelieferte Vorlage tailoren (Platzhalter aus Fakten befüllt, nicht zutreffende Klauseln ausgeblendet), - (b) eigene Richtlinie hochladen und den abgedeckten Controls zuordnen, - (c) als offen markieren / später erstellen. -- **Verarbeitung & Regeln:** (a) Template-Engine erzeugt kundenspezifisches Dokument aus Faktenprofil + Regeln; (b) Upload wird gespeichert und über Control-Mapping in die Nachweislage aufgenommen; (c) erzeugt Aufgabe. -- **Erzeugte Objekte:** Dokumenten-Set (generiert oder hochgeladen) mit Control-Verknüpfung und Versionsbezug. -- **Umsetzungshinweise:** Was die jeweilige Richtlinie mindestens enthalten muss (VDA-ISA-Bezug); Formulierungsbausteine. -- **Aufgaben-Trigger:** Option (c) „später erstellen" → Aufgabe `Dokument erstellen`; hochgeladenes Dokument ohne vollständige Control-Abdeckung → Hinweis/Aufgabe. -- **Validierung:** Freigabe je Dokument (Objekt-Ebene). -- **Ressourcen (Entwicklung):** Backend (Template-Engine, Platzhalter/Regeln, Rendering) L · Frontend (Auswahl, Editor/Vorschau, Upload) L · SME/Content (Vorlagen mit Regeln auszeichnen) L. -- **Akzeptanzkriterien:** Generiertes Dokument enthält keine unaufgelösten Platzhalter und keine nicht zutreffenden Klauseln; hochgeladenes Dokument ist Controls zugeordnet. - -### Schritt 5 – Werte-/Assetinventar (Grundstock) - -- **Zweck:** Die für Scope und Schutzbedarf nötigen Informationswerte/Assets erfassen. -- **Eingaben:** Assets (Kategorie, Eigentümer, Schutzziele C/I/A, Schutzbedarf, Standort/Verknüpfung). -- **Verarbeitung & Regeln:** Assets werden Risiken (Schritt 6) und Controls zugeordnet; Schutzbedarf steuert die AL3-Relevanz von Zusatzanforderungen. -- **Erzeugte Objekte:** Assetinventar (Grundstock). -- **Umsetzungshinweise:** Wie man Werte identifiziert und Schutzbedarf herleitet; Beispielkategorien. -- **Aufgaben-Trigger:** Unvollständiges Inventar / fehlender Eigentümer → Aufgabe. -- **Validierung:** Freigabe des Inventars. -- **Ressourcen (Entwicklung):** Frontend (Inventar-CRUD, Import) M · Backend (Assetmodell, Verknüpfungen) M · SME S. -- **Akzeptanzkriterien:** Jedes Asset hat Eigentümer und Schutzbedarf; Verknüpfung zu Risiken/Controls möglich. - -### Schritt 6 – Risikomanagement - -- **Zweck:** Risiken systematisch erfassen, bewerten und behandeln – auf Basis eines Katalogs mit Standard- und VDA-geforderten Risiken. -- **Eingaben:** Auswahl aus Risiko-Katalog (Standard/VDA) + eigene Ergänzungen; Bewertung (Eintrittswahrscheinlichkeit/Schadensausmaß); Behandlungsentscheidung. -- **Verarbeitung & Regeln:** Risiken werden mit Assets und Controls verknüpft; Bewertungsmethodik (Skalen, Akzeptanzlinie) wird angewendet; Behandlungsoptionen (reduzieren/übertragen/vermeiden/akzeptieren) mit Maßnahmenableitung. -- **Erzeugte Objekte:** Risikoregister; Behandlungsmaßnahmen. -- **Umsetzungshinweise:** Vorschlag typischer Maßnahmen je Risiko; Erläuterung der Bewertungsmethodik. -- **Aufgaben-Trigger:** Jede Behandlungsmaßnahme, die Umsetzung erfordert → Aufgabe (technisch/organisatorisch), verknüpft mit Risiko und Control (z. B. Risiko „Schadsoftware" → Aufgabe „Endpoint-/Patchmanagement einführen"). -- **Validierung:** Freigabe des Risikoregisters bzw. je Risiko. -- **Ressourcen (Entwicklung):** Backend (Risikomodell, Bewertungslogik, Katalog) L · Frontend (Register, Matrix, Bewertung) L · SME (Risiko-Katalog + Standardmaßnahmen) L. -- **Akzeptanzkriterien:** VDA-geforderte Risiken sind auswählbar; jedes inakzeptable Risiko hat eine Behandlung; Maßnahmen erzeugen Aufgaben. - -### Schritt 7 – Control-Zuordnung & Reifegrad - -- **Zweck:** Je relevantem VDA-ISA-Control die Umsetzung bewerten und Reifegrad einschätzen. -- **Eingaben:** Je Control: Verknüpfung der belegenden Dokumente/Risiken/Assets; geführte Reifegrad-Selbsteinschätzung; ggf. Kurzbeschreibung. -- **Verarbeitung & Regeln:** Reifegrad-/Gap-Engine schlägt auf Basis vorhandener Belege einen Reifegrad vor; offene Teilanforderungen werden markiert. -- **Erzeugte Objekte:** Control-Bewertung (Reifegrad, Belege, offene Punkte) – die Rohdaten des späteren VDA-ISA-Katalogs. -- **Umsetzungshinweise:** Pro Teilanforderung „So setzen Sie das um" (organisatorisch/technisch, Nachweise, passende Vorlage, Ressourcenbedarf). -- **Aufgaben-Trigger:** Reifegrad unter Ziel / offene Teilanforderung → Aufgabe (Dokument, Nachweis, technische oder organisatorische Maßnahme). -- **Validierung:** Freigabe der Control-Bewertung durch ISB/Berater. -- **Ressourcen (Entwicklung):** Backend (Scoring/Gap-Logik, Verknüpfungen) L · Frontend (Control-Ansicht, Belege, Reifegrad) L · SME (Reifegrad-Logik, Hinweis-Content) L. -- **Akzeptanzkriterien:** Jede relevante Teilanforderung ist adressiert; Reifegradvorschlag ist nachvollziehbar an Belege gekoppelt. - -### Schritt 8 – Gap- & Maßnahmenableitung - -- **Zweck:** Offene Punkte aus Controls und Risikobehandlung zu einer priorisierten Maßnahmenliste zusammenführen. -- **Eingaben:** Ergebnisse aus Schritt 6 und 7; bestehende Aufgaben. -- **Verarbeitung & Regeln:** Deduplizierung, Priorisierung (Muss-/AL3-kritisch = hoch), Konsolidierung zu einer Gesamtsicht; Abgleich mit dem Aufgaben-Modul. -- **Erzeugte Objekte:** Konsolidierte Maßnahmen-/Gap-Liste (verknüpft mit Aufgaben). -- **Umsetzungshinweise:** Priorisierungslogik erläutert; Quick-Wins hervorgehoben. -- **Aufgaben-Trigger:** Jeder offene Punkt ohne bestehende Aufgabe → Aufgabe. -- **Validierung:** Freigabe der Maßnahmenliste. -- **Ressourcen (Entwicklung):** Backend (Aggregation/Dedup/Priorisierung) M · Frontend (Listenansicht, Filter) M. -- **Akzeptanzkriterien:** Keine Dopplungen; jeder offene Punkt hat Priorität und – wo Umsetzung nötig – eine Aufgabe. - -### Schritt 9 – Assessment-Readiness-Auswertung - -- **Zweck:** Das Gesamtergebnis darstellen: vorausgefüllter VDA-ISA-Katalog, Reifegrad-Dashboard, Maßnahmenplan. -- **Eingaben:** Alle validierten Objekte. -- **Verarbeitung & Regeln:** Aggregation der Reifegrade je Kapitel/gesamt; „bestätigt vs. unbestätigt" nach Validierungsstatus; Export. -- **Erzeugte Objekte:** VDA-ISA-Katalog-Sicht/Export; Reifegrad-Dashboard; Maßnahmenplan. -- **Umsetzungshinweise:** Interpretation der Auswertung; empfohlene nächste Schritte vor dem Assessment. -- **Aufgaben-Trigger:** Aus offenen Hoch-Punkten ableitbar (bereits in Schritt 8 erzeugt). -- **Validierung:** Gesamtfreigabe/Abschluss durch ISB/Berater. -- **Ressourcen (Entwicklung):** Backend (Aggregation, Export) M · Frontend (Dashboard, Katalogansicht) L · SME (Auswertungslogik) M. -- **Akzeptanzkriterien:** Kennzahlen stimmen mit den Einzelbewertungen überein; Export ist vollständig und nachvollziehbar. - ---- - -## 5. Entwicklungs-Fahrplan (Meilensteine mit Ressourcen) - -| Meilenstein | Inhalt | Schritte | Kern-Ressourcen | Größe | -|---|---|---|---|---| -| M1 Fundament | Datenmodell + Import Control-Katalog VDA ISA | – | Backend, SME | M | -| M2 Frage-Engine | Scoping + Kontext + Rollen | 1–3 | Backend, Frontend, SME | L | -| M3 Richtlinien-Modul | Template-Engine + Upload/Control-Mapping | 4 | Backend, Frontend, Content-SME | L | -| M4 Asset- & Risiko-Modul | Assetinventar + Risiko-Katalog + Bewertung | 5–6 | Backend, Frontend, SME | L | -| M5 Bewertungs-Engine | Control-Mapping, Reifegrad/Gap, Maßnahmen-Konsolidierung | 7–8 | Backend, SME, Frontend | L | -| M6 Ergebnis/Output | Assessment-Readiness-Auswertung + Export | 9 | Backend, Frontend | M | -| M7 Governance (querlaufend) | Validierungs-Workflow, Aufgaben-Integration, Audit-Trail, Versionierung, Umsetzungshinweise | alle | Backend, Frontend, SME | L | - -**Kürzester Pfad zur Assessment-Readiness:** M1 → M2 → M3 → M4 → M5 → M6. M7 wird parallel eingezogen (Validierung, Aufgaben und Hinweise sollten nicht nachträglich „angeflanscht" werden). Nachweis-Upload ist bewusst spätere Iteration. - ---- - -## 6. Ressourcen-Gesamtübersicht (Rollen im Entwicklungsprojekt) - -| Rolle | Beitrag | Auslastung (grob) | -|---|---|---| -| ISMS/TISAX-SME (Fachredaktion) | Control-Katalog, Templates mit Regeln, Risiko-Katalog, Umsetzungshinweise, Reifegrad-/Bewertungslogik | hoch, durchgehend – der inhaltliche Flaschenhals | -| Backend-Entwicklung | Datenmodell, Regel-/Mapping-Engine, Scoring, Task-Integration, API, Audit-Trail | hoch | -| Frontend-Entwicklung | Wizard-Flow, dynamische Formulare, Editor/Vorschau, Dashboards | hoch | -| Content-/Template-Engineering | Vorlagen mit Platzhaltern und Regel-Tags auszeichnen | mittel, in M3 konzentriert | -| UX/Design | geführter Flow, Statusführung, Hinweis-Panels | mittel | -| QA/Test | Regel-/Scoring-Korrektheit, Dokumentgenerierung, Freigabelogik | mittel–hoch | - -**Wichtig:** Der größte, oft unterschätzte Aufwand liegt nicht in der Software, sondern im **Fachcontent** (Control-Daten, regelfähige Vorlagen, Risiko-Katalog, Umsetzungshinweise). Dieser sollte parallel und früh durch die Beratung erstellt werden, sonst wird er zum kritischen Pfad. - ---- - -## 7. Offene Entscheidungspunkte (vor der technischen Spezifikation zu klären) - -1. **Upload eigener Richtlinien:** nur Control-Zuordnung, oder zusätzlich ein automatischer Abgleich Dokumentinhalt ↔ Anforderungen (Gap-Check)? -2. **Risiko-Bewertungsmethodik:** fest vorgegeben oder mandantenspezifisch konfigurierbar (Skalen, Akzeptanzlinie)? -3. **Versionierung von Katalog/Templates/Risiken:** wie werden laufende Kundeninstanzen bei Updates nachgezogen (automatisch, mit Diff, manuell)? -4. **Validierungsgranularität:** pro Modul, zusätzlich pro Einzelobjekt (einzelne Richtlinie/Risiko/Control)? -5. **Aufgaben-Modul:** existiert bereits mit passender Schnittstelle, oder muss die Task-Erzeugung mitgeplant werden? -6. **Reifegrad-Vorschlag:** rein regelbasiert aus Belegen, oder als Empfehlung mit Pflicht zur Bestätigung durch den Bearbeiter? - ---- - -## 8. Nächster Schritt - -Nach Verifizierung dieses Fahrplans: technische Feinspezifikation je Modul (Datenschemata, Regel-Syntax, API-Verträge, UI-Wireframes, Akzeptanztests) – vorgeschlagene Reihenfolge entlang der Meilensteine M1–M7. diff --git a/docs/wizard-uebergabe/03_Referenz/STAND-dev-branch.HINWEIS.md b/docs/wizard-uebergabe/03_Referenz/STAND-dev-branch.HINWEIS.md deleted file mode 100644 index 680ce3f..0000000 --- a/docs/wizard-uebergabe/03_Referenz/STAND-dev-branch.HINWEIS.md +++ /dev/null @@ -1,9 +0,0 @@ -# Hinweis: STAND-dev-branch.md liegt zentral - -Die im Original-Übergabepaket enthaltene Kopie von `STAND-dev-branch.md` (Stand 2026-07-24) -wurde **bewusst nicht** hier abgelegt, um keinen zweiten, veralteten Stand zu führen. - -**Maßgeblich ist die zentrale Datei im Repo:** [`docs/STAND-dev-branch.md`](../../STAND-dev-branch.md) -(wird nach jeder abgeschlossenen Arbeit gepflegt — Single Source of Truth). - -Weitere Basis-Doku: `docs/HANDOVER-DEV.md`, `docs/HANDOVER-PM.md`, `docs/SPEC.md`. diff --git a/docs/wizard-uebergabe/README.md b/docs/wizard-uebergabe/README.md deleted file mode 100644 index 06661fa..0000000 --- a/docs/wizard-uebergabe/README.md +++ /dev/null @@ -1,20 +0,0 @@ -# Onboarding-Wizard — Übergabepaket (Entwicklung) - -Alles, was die beiden Entwickler und der Berater für die parallele Umsetzung brauchen. - -## Reihenfolge / Einstieg -1. **00_Entwicklerpakete/** — je ein fertiger Umsetzungs-Prompt: - - `Paket-DevA-Wizard-Scoping.md` — Wizard-Shell, Scoping, **AL2/AL3 zentral im Adminportal**. - - `Paket-DevB-Engines-Richtlinien.md` — Aufgaben/Regel-Engine, Fragebogen, **Richtlinien-Import bei Modul-Aktivierung + manueller Upload**. - - Beide enthalten einen **identischen Contracts-Anhang** (Naht) + Datei-Hoheit → konfliktarm parallel. Vorab: 15-Min-Kickoff. -2. **01_Planung/** — Kontext & Gesamtbild: - - `Wizard-Stories.md` (kompletter Story-Backlog F/A/B), `Wizard-Entwickler-Backlog.md` (2-Lane-Plan), - `Onboarding-Wizard-Machbarkeitsanalyse.md` (Ist-Abgleich), `Berater-Anweisung-Fachcontent.md`. -3. **02_Fachcontent_C1-C9/** — Zuarbeit des Fachberaters (ID-konsistent zu `isms-vorlagenpaket-v2`). Start: `C0_README-...`. -4. **03_Referenz/** — Berater-Fahrplan + Dev-Stand `dev`. - -## Wichtig -- Basis-Branch **`dev`**; Feature-Branches `dev/a*-…` bzw. `dev/b*-…`; PR-Ziel `dev`. -- **Definition of Ready** je Story: zugehöriges C-Paket eingespielt, bei Seed-Änderung `python3 seed/isms-vorlagenpaket-v2/_verify.py` → **OK**. -- Kritischer Pfad Fachcontent: C2 → C1/C3 → C5/C6. -- Offene Fachpunkte (C0): neue `FLAG_*` in `variables.schema.json`, P01/D01+VA-20 anlegen, Baseline-`BL-*` normalisieren, ISB-Freigabe. diff --git a/messages/de.json b/messages/de.json deleted file mode 100644 index 214b9cc..0000000 --- a/messages/de.json +++ /dev/null @@ -1,1136 +0,0 @@ -{ - "common": { - "appName": "Certvia", - "appTagline": "Informationssicherheit. Endlich einfach.", - "appByline": "Ein Produkt von GEFIM", - "language": "Sprache", - "logout": "Abmelden", - "create": "Anlegen", - "save": "Speichern", - "cancel": "Abbrechen", - "edit": "Bearbeiten", - "delete": "Löschen", - "back": "Zurück", - "close": "Schließen", - "search": "Suchen…", - "actions": "Aktionen", - "add": "Hinzufügen", - "remove": "Entfernen", - "none": "—", - "comingSoon": "Bald verfügbar", - "confirmDelete": "Wirklich löschen?", - "yes": "Ja", - "no": "Nein", - "readOnly": "Nur-Lese-Zugriff." - }, - "nav": { - "dashboard": "Dashboard", - "assetsBia": "Assets & BIA", - "risks": "Risikoanalyse", - "soa": "SoA & Controls", - "measures": "Maßnahmen", - "tasks": "Aufgaben", - "incidents": "Vorfälle", - "policies": "Richtlinien", - "chat": "ISMS-Chat", - "dependencies": "Abhängigkeiten", - "evidence": "Nachweise", - "suppliers": "Lieferanten", - "review": "Management-Review", - "assets": "Asset-Inventar", - "bia": "Business Impact Analyse", - "settings": "Einstellungen", - "admin": "Admin-Konsole", - "onboarding": "Onboarding", - "auditReadiness": "Audit vorbereiten" - }, - "login": { - "title": "Anmelden", - "tagline": "Informationssicherheit. Endlich einfach.", - "subtitle": "Melde dich mit deinem Firmenkonto an.", - "email": "E-Mail-Adresse", - "password": "Passwort", - "mfaOptional": "MFA-Code (falls eingerichtet)", - "submit": "Anmelden", - "forgotPassword": "Passwort vergessen?", - "error": "Anmeldung fehlgeschlagen. Bitte prüfe E-Mail und Passwort." - }, - "dashboard": { - "title": "Dashboard", - "welcome": "Willkommen, {name}", - "tenant": "Mandant", - "roles": "Rollen", - "placeholder": "Die Modul-Dashboards (Risiken, Aufgaben, SoA-Erfüllungsgrad) folgen in den nächsten Iterationen.", - "subtitle": "Willkommen zurück, {name} — Status des ISMS für {tenant}.", - "kpiAssets": "Assets im Inventar", - "kpiProcesses": "Prozesse (BIA)", - "kpiCritical": "Kritische Prozesse", - "kpiCriticalHint": "Kritikalität hoch oder sehr hoch", - "kpiRisks": "Offene Risiken", - "kpiRisksHint": "folgt mit dem Risiko-Modul", - "activity": "Letzte Aktivitäten", - "activitySub": "Audit-Log", - "activityEmpty": "Noch keine Aktivitäten.", - "onboardingTile": "Onboarding-Fortschritt · {percent}%", - "onboardingTileSub": "{done} von {total} Schritten validiert · nächster Schritt: {step}", - "onboardingTileCta": "Zum Wizard →", - "incidentTile": "Vorfälle · Meldefristen", - "incidentTileSub": "{open} offene Meldefrist(en){overdue, plural, =0 {} other {, davon # überfällig}}", - "incidentTileCta": "Zu den Vorfällen →" - }, - "assets": { - "title": "Assets & BIA", - "tabAssets": "Assets", - "tabProcesses": "Prozesse & BIA", - "newAsset": "Neues Asset", - "name": "Name", - "description": "Beschreibung", - "type": "Typ", - "status": "Status", - "owner": "Owner", - "location": "Standort", - "tags": "Tags (kommagetrennt)", - "protection": "Schutzbedarf", - "confidentiality": "Vertraulichkeit", - "integrity": "Integrität", - "availability": "Verfügbarkeit", - "allTypes": "Alle Typen", - "allStatus": "Alle Status", - "empty": "Keine Assets gefunden.", - "detailTitle": "Asset-Details", - "relations": "Abhängigkeiten", - "relationHint": "Dieses Asset hängt ab von:", - "relationReverseHint": "Von diesem Asset hängen ab:", - "addRelation": "Abhängigkeit hinzufügen", - "processes": "Zugeordnete Prozesse", - "linkedRisks": "Zugeordnete Risiken", - "linkedRisksPlaceholder": "Risiken werden mit dem Risiko-Modul (Iteration 3) verknüpft und erscheinen dann hier.", - "editTitle": "Asset bearbeiten", - "createTitle": "Asset anlegen", - "deleted": "Asset gelöscht", - "inheritedNote": "Vererbter Schutzbedarf aus Prozessen (Max-Prinzip) wird bei der BIA berücksichtigt.", - "crumb": "Fachdaten", - "invTitle": "Asset-Inventar", - "invSub": "{count} Werte · Schutzbedarf nach C/I/A · verknüpft mit BIA und Risiko", - "excelImport": "Excel-Import", - "export": "Export", - "kpiTotal": "Assets gesamt", - "kpiTotalTrend": "{count} Typen", - "kpiHigh": "Hoher Schutzbedarf", - "kpiHighTrend": "C/I/A ≥ 3", - "kpiNoOwner": "Ohne Owner", - "kpiNoOwnerTrend": "Zuweisung nötig", - "kpiSuppliers": "Lieferanten", - "kpiSuppliersTrend": "extern", - "all": "Alle", - "filter": "Filtern …", - "noOwner": "kein Owner", - "dependencies": "Abhängigkeiten", - "detailSub": "Stammdaten, Abhängigkeiten & Risiken", - "masterPill": "■ Stammdaten", - "masterNote": "Klassifizierung & Verantwortung", - "depPill": "◆ Abhängigkeiten", - "depNote": "Verknüpfte Assets", - "riskCount": "{count} Risiken", - "criticalTitle": "Kritische IT-Dienste", - "criticalSub": "Automatisch aus Assetinventar und BIA abgeleitet – schreibgeschützt.", - "criticalService": "Kritischer IT-Dienst", - "biaCriticality": "BIA-Kritikalität", - "supportedProcesses": "Gestützte Prozesse", - "criticalEmpty": "Keine kritischen IT-Dienste ermittelt (hohe Verfügbarkeit oder BIA-kritischer Prozess).", - "criticalNote": "Diese Sicht wird laufend aus dem Assetinventar und der Business-Impact-Analyse abgeleitet. RTO/RPO stammen aus den verknüpften Prozessen (strengster Wert). Pflege erfolgt am jeweiligen Asset bzw. Prozess.", - "backToInventory": "Zum Assetinventar" - }, - "assetType": { - "INFORMATION": "Information", - "SYSTEM": "System", - "APPLICATION": "Anwendung", - "LOCATION": "Standort", - "SUPPLIER": "Lieferant", - "PERSON": "Person/Rolle", - "DATA": "Datenkategorie", - "IT_SERVICE": "IT-Service", - "SOFTWARE": "Software", - "PROJECT": "Projekt" - }, - "assetStatus": { - "ACTIVE": "Aktiv", - "PLANNED": "Geplant", - "RETIRED": "Ausgemustert" - }, - "processes": { - "newProcess": "Neuer Prozess", - "name": "Name", - "description": "Beschreibung", - "owner": "Owner", - "criticality": "Kritikalität", - "assets": "Zugeordnete Assets", - "empty": "Keine Prozesse gefunden.", - "detailTitle": "Prozess-Details", - "createTitle": "Prozess anlegen", - "editTitle": "Prozess bearbeiten", - "primaryAssets": "Primäre Assets", - "primaryHint": "Das im Prozess erzeugte/verantwortete Ergebnis-Asset.", - "secondaryAssets": "Sekundäre Assets", - "secondaryHint": "Unterstützende Assets (Systeme, Anwendungen, Personen, Lieferanten).", - "assignAsset": "Asset zuordnen", - "role": "Rolle", - "linkedRisks": "Zugeordnete Risiken", - "linkedRisksPlaceholder": "Risiken werden mit dem Risiko-Modul (Iteration 3) verknüpft und erscheinen dann hier.", - "bia": "Business Impact Analyse", - "rto": "RTO (Stunden)", - "rpo": "RPO (Stunden)", - "mtd": "MTD/MTPD (Stunden)", - "rtoLong": "Recovery Time Objective — max. Zeit bis zur Wiederherstellung", - "rpoLong": "Recovery Point Objective — max. tolerierbarer Datenverlust", - "mtdLong": "Maximum Tolerable Downtime — max. tolerierbarer Ausfall", - "impact": "Schadenshöhe je Schutzziel (1–4)", - "notes": "Anmerkungen / Schadensszenarien", - "biaSaved": "BIA gespeichert", - "noBia": "Noch keine BIA erfasst.", - "biaTitle": "Business Impact Analyse", - "biaSub": "Kritikalität der Geschäftsprozesse · RTO / RPO / MTD", - "biaReport": "BIA-Report (PDF)", - "viewHouse": "Prozesshaus", - "viewTable": "Tabelle", - "kpiTotal": "Prozesse gesamt", - "kpiInScope": "Im Scope", - "kpiBiaDone": "BIA vollständig", - "kpiCritical": "Hohe Kritikalität", - "mainProcs": "{count} Hauptprozesse", - "subProcs": "{count} Teilprozesse", - "subHeading": "Teilprozesse", - "biaOpen": "BIA erfassen", - "biaStatusLegend": "BIA-Status", - "rollupHint": "Werte aus den Teilprozessen zusammengefasst (Kritikalität = Maximum, RTO/RPO/MTD = schärfster Wert).", - "laneEmpty": "Keine Prozesse in dieser Kategorie.", - "depsSection": "Abhängigkeiten", - "depsRequires": "benötigt", - "depsRequiredBy": "wird benötigt von", - "depsAdd": "Abhängigkeit hinzufügen", - "depsSelect": "Prozess wählen …", - "depsNotePlaceholder": "Notiz (optional, z. B. „ERP“)", - "depsNone": "keine", - "depsRequiresHint": "Prozesse, die dieser Prozess benötigt — fällt einer aus, ist dieser Prozess betroffen.", - "depsRequiredByN": "{count} Prozess(e) hängen hiervon ab", - "depsGraphLink": "Abhängigkeits-Graph", - "critTable": "Kritikalität der Prozesse", - "process": "Geschäftsprozess", - "detailHeading": "{name}", - "detailSub": "Zugeordnete Assets nach Rolle", - "critLabel": "Kritikalität: {label}", - "primaryPill": "★ Primäres Asset", - "primaryNote": "Ergebnis, das im Prozess erzeugt wird", - "secondaryPill": "◆ Sekundäre Assets", - "secondaryNote": "Werden zur Bearbeitung benötigt", - "inherits": "vererbt Schutzbedarf an sekundäre Assets", - "showDependencies": "Abhängigkeiten anzeigen →", - "impactShort": "Schadenshöhe (C/I/A)", - "close": "Schließen", - "noAssets": "Noch keine Assets zugeordnet.", - "category": "Prozesskategorie", - "secMaster": "Grunddaten", - "secAssets": "Zugeordnete Assets", - "deleteProcess": "Prozess löschen", - "purpose": "Zweck / Ziel", - "parent": "Hauptprozess", - "noParent": "— kein Hauptprozess (eigenständig)", - "deputyOwner": "Stellvertreter", - "noDeputy": "unbesetzt", - "legalBasis": "Rechtsgrundlage", - "interfaces": "Schnittstellen / Datenflüsse", - "dataProtectionRelevant": "Datenschutzrelevant", - "prototypeRelevant": "Prototypenrelevant", - "catalogCode": "Katalog-Code", - "businessInfo": "Fachliche Informationen" - }, - "processRole": { - "PRIMARY": "Primär", - "SECONDARY": "Sekundär" - }, - "criticality": { - "1": "Niedrig", - "2": "Mittel", - "3": "Hoch", - "4": "Sehr hoch" - }, - "protectionLevel": { - "1": "Normal", - "2": "Erhöht", - "3": "Hoch", - "4": "Sehr hoch" - }, - "processCategory": { - "CORE": "Kernprozess", - "MANAGEMENT": "Managementprozess", - "SUPPORT": "Unterstützender Prozess" - }, - "risks": { - "title": "Risikoanalyse", - "sub": "5×5-Matrix · Eintrittswahrscheinlichkeit × Auswirkung", - "export": "Risikoregister exportieren", - "newRisk": "Risiko", - "heatmap": "Risiko-Heatmap", - "heatmapSub": "Auswirkung (Y) × Eintrittswahrscheinlichkeit (X)", - "register": "Risikoregister", - "registerSub": "Risiken nach Bewertung", - "id": "ID", - "risk": "Risiko", - "rating": "Bewertung", - "treatment": "Behandlung", - "status": "Status", - "owner": "Owner", - "empty": "Noch keine Risiken erfasst.", - "detailHeading": "{ref} · {name}", - "detailSub": "Bewertung, betroffene Assets & Behandlung", - "editTitle": "Risiko bearbeiten", - "createTitle": "Risiko anlegen", - "titleField": "Titel", - "description": "Beschreibung", - "threat": "Bedrohung", - "vulnerability": "Schwachstelle", - "likelihood": "Eintrittswahrscheinlichkeit (1–5)", - "impact": "Auswirkung (1–5)", - "gross": "Brutto-Risiko", - "residual": "Rest-Risiko", - "residualHint": "Nach Umsetzung der Maßnahmen", - "noResidual": "Noch nicht bewertet", - "process": "Geschäftsprozess", - "affectedAssets": "Betroffene Assets", - "affectedNote": "Assets, auf die dieses Risiko wirkt", - "addAsset": "Asset verknüpfen", - "noAssets": "Keine Assets verknüpft.", - "measures": "Notwendige Maßnahmen", - "measuresPlaceholder": "Maßnahmen werden mit dem Maßnahmen-Modul (Iteration 4) verknüpft und erscheinen dann hier.", - "close": "Schließen", - "scoreLabel": "{score} · {level}", - "legendLow": "Gering", - "legendMedium": "Mittel", - "legendElevated": "Erhöht", - "legendHigh": "Hoch", - "legendCritical": "Kritisch", - "axisX": "Eintrittswahrscheinlichkeit →", - "axisY": "Auswirkung ↑", - "likelihoodShort": "Eintrittswahrscheinlichkeit", - "damageShort": "Schaden", - "scoreShort": "Risikowert", - "residualAuto": "Ergibt sich automatisch aus den verknüpften Maßnahmen.", - "noMeasures": "Noch keine Maßnahmen verknüpft — das Rest-Risiko entspricht dem Brutto-Risiko.", - "linkMeasure": "Maßnahme verknüpfen", - "newMeasure": "Neue Maßnahme anlegen & verknüpfen", - "measureTitle": "Titel der Maßnahme", - "reductionL": "Minderung Wahrscheinlichkeit (0,00–4,00)", - "reductionI": "Minderung Schaden (0,00–4,00)", - "reduction": "Minderung", - "createFromAsset": "Risiko erstellen", - "catalogHint": "Aus Katalog wählen oder frei eingeben …", - "addExistingBtn": "Maßnahme hinzufügen", - "createNewBtn": "Neue Maßnahme erstellen", - "measureCol": "Maßnahme", - "statusCol": "Status" - }, - "riskTreatment": { - "AVOID": "Vermeiden", - "MITIGATE": "Vermindern", - "TRANSFER": "Übertragen", - "ACCEPT": "Akzeptieren" - }, - "riskStatus": { - "OPEN": "Offen", - "IN_TREATMENT": "In Behandlung", - "ACCEPTED": "Akzeptiert", - "CLOSED": "Geschlossen" - }, - "riskLevel": { - "low": "Gering", - "medium": "Mittel", - "elevated": "Erhöht", - "high": "Hoch", - "critical": "Kritisch" - }, - "incidents": { - "title": "Vorfälle", - "sub": "Sicherheitsvorfälle erfassen, bewerten, bearbeiten und abschließen", - "crumb": "Betrieb", - "newIncident": "Vorfall melden", - "register": "Vorfallregister", - "registerSub": "Alle Vorfälle des Mandanten (neueste zuerst)", - "empty": "Keine Vorfälle erfasst.", - "id": "Kennung", - "incident": "Vorfall", - "category": "Kategorie", - "severity": "Schweregrad", - "status": "Status", - "owner": "Verantwortlich (Incident-Manager)", - "assignee": "Bearbeiter", - "filter": "Filter", - "filterAll": "Alle", - "createTitle": "Vorfall melden", - "createSub": "Titel, Beschreibung, Kategorie und Betroffenheit erfassen", - "editTitle": "Vorfall bearbeiten", - "detailSub": "Bewertung, Steuerung, Verknüpfungen, Verlauf", - "close": "Schließen", - "titleField": "Titel", - "description": "Beschreibung", - "source": "Kanal / Quelle", - "source_manual": "Intern (manuell)", - "source_email": "E-Mail", - "reporter": "Melder", - "reporterName": "Melder (Name)", - "reporterContact": "Melder (Kontakt)", - "occurredAt": "Eingetreten am", - "detectedAt": "Entdeckt am", - "impactHead": "Auswirkung & Dringlichkeit", - "impactHint": "Schutzziel-Verletzung C/I/A und Dringlichkeit (0–4) — bestimmen den Schweregrad.", - "impactC": "Vertraulichkeit (C)", - "impactI": "Integrität (I)", - "impactA": "Verfügbarkeit (A)", - "impactCia": "Auswirkung C/I/A", - "urgency": "Dringlichkeit", - "priority": "Priorität", - "dataCategories": "Betroffene Datenkategorien", - "dataCategoriesHint": "Kommagetrennt, z. B. Kundendaten, Zugangsdaten", - "personalData": "Personenbezug (→ DSGVO)", - "prototypeData": "Prototyp-/Kundendaten (→ TISAX)", - "nis2Relevant": "NIS2-relevant", - "flags": "Merkmale", - "severityAutoHint": "Der Schweregrad wird automatisch aus Auswirkung × Dringlichkeit abgeleitet (Standard-Matrix) und kann von der Steuerung überschrieben werden.", - "statusChange": "Statuswechsel", - "noTransitions": "Kein weiterer Statuswechsel möglich.", - "applyStatus": "Status setzen", - "steering": "Steuerung", - "restricted": "Vertraulich", - "restrictedToggle": "Vertraulich (nur Verantwortliche + Rollen mit Bearbeiten/Abschließen)", - "rootCause": "Ursache (Root Cause)", - "resolution": "Lösung / Behebung", - "closingNote": "Abschlussnotiz", - "lessonsLearned": "Lessons Learned", - "assets": "Betroffene Assets", - "processes": "Betroffene Prozesse", - "risks": "Verknüpfte Risiken", - "controls": "Betroffene Controls", - "controlsHint": "Welche Controls versagten/betroffen sind (Katalog-Referenz).", - "measures": "Verknüpfte Maßnahmen", - "addAsset": "Asset verknüpfen", - "addProcess": "Prozess verknüpfen", - "addRisk": "Risiko verknüpfen", - "addMeasure": "Maßnahme verknüpfen", - "deleteHint": "Vorfälle werden nicht gelöscht — für die Nachvollziehbarkeit abschließen.", - "comments": "Kommentare", - "noComments": "Noch keine Kommentare.", - "commentPlaceholder": "Kommentar schreiben …", - "addComment": "Kommentieren", - "internal": "Intern", - "timeline": "Verlauf (Audit)", - "noTimeline": "Noch keine Verlaufseinträge.", - "reportingHead": "Meldepflicht & Fristen", - "nis2CategoryLabel": "NIS2-Betroffenheit des Mandanten", - "nis2_keine": "keine", - "nis2_wichtig": "wichtige Einrichtung", - "nis2_wesentlich": "wesentliche Einrichtung", - "reportStatus_none": "keine Meldepflicht", - "reportStatus_pruefung": "Meldepflicht geprüft", - "reportStatus_erstmeldung": "Erstmeldung", - "reportStatus_folgemeldung": "Folgemeldung", - "reportStatus_abschluss": "Abschlussbericht", - "deadlineKind_erstmeldung": "NIS2 Erstmeldung (24 h)", - "deadlineKind_folgemeldung": "NIS2 Folgemeldung (72 h)", - "deadlineKind_abschluss": "NIS2 Abschlussbericht (1 Monat)", - "deadlineKind_dsgvo": "DSGVO-Meldung (Art. 33, 72 h)", - "deadlineKind_reaction": "Interne Reaktionsfrist (SLA)", - "deadlineKind_resolution": "Interne Behebungsfrist (SLA)", - "setReportability": "Meldepflicht setzen/prüfen", - "applyReportability": "Übernehmen", - "reportabilityHint": "Setzt die Meldefristen ab dem Kenntniszeitpunkt. NIS2-Timer nur bei NIS2-Betroffenheit des Mandanten.", - "advanceTo": "Weiter zu:", - "manualSubmitHint": "Die Übermittlung an die Behörde erfolgt manuell (Vorlage/Export). Hier nur Status und Timer.", - "noReportObligation": "Für diesen Vorfall besteht derzeit keine Meldepflicht.", - "dl_meldungHead": "Meldefristen", - "dl_slaHead": "Interne SLA (je Severity)", - "dl_remaining": "noch", - "dl_overdue": "überfällig", - "dl_submitted": "eingereicht", - "dl_none": "Keine Fristen gesetzt.", - "evidence": "Verknüpfte Nachweise", - "reviewHead": "Post-Incident-Review & Wirksamkeit", - "reviewHint": "Kurzbericht speist das Management-Review; die Wirksamkeit der (CAPA-)Maßnahmen dokumentieren (§8).", - "measuresEffectiveness": "Wirksamkeit der Maßnahmen", - "postIncidentReview": "Post-Incident-Review (Kurzbericht)", - "exportHead": "Export & Nachweise", - "exportReport": "Vorfallbericht (Druck/PDF)", - "exportNis2": "NIS2-Meldevorlage", - "exportDsgvo": "DSGVO-Meldevorlage", - "exportHint": "Vorlagen sind vorbefüllt; die Übermittlung an die Behörde erfolgt manuell.", - "exportRegisterCsv": "Register (CSV)", - "exportRegisterXlsx": "Register (XLSX)", - "newRiskFromIncident": "Neues Risiko aus dem Vorfall erzeugen", - "riskTitlePlaceholder": "Risikotitel", - "likelihood": "Eintritt (E)", - "impact": "Auswirkung (S)", - "createRisk": "Risiko anlegen & verknüpfen", - "newMeasureFromIncident": "Maßnahme direkt aus dem Vorfall anlegen", - "measureTitlePlaceholder": "Maßnahmentitel", - "measureOwnerNone": "Verantwortlich (optional)", - "createMeasure": "Maßnahme anlegen & verknüpfen", - "priorityLow": "niedrig", - "priorityMedium": "mittel", - "priorityHigh": "hoch", - "newEvidence": "Nachweis (Referenz/Text) anlegen", - "evidenceTitlePlaceholder": "Titel des Nachweises", - "evidenceRefPlaceholder": "Referenz/Link (optional)", - "createEvidence": "Nachweis anlegen & verknüpfen" - }, - "incidentCategory": { - "malware": "Schadsoftware", - "phishing": "Phishing / Social Engineering", - "unauthorized_access": "Unbefugter Zugriff", - "data_loss": "Datenabfluss / -verlust", - "outage": "Systemausfall / Verfügbarkeit", - "physical": "Physisch (Zutritt / Diebstahl)", - "misconfiguration": "Fehlbedienung / Konfiguration", - "supplier": "Lieferant / Drittpartei", - "prototype_customer_data": "Prototyp / Kundendaten", - "other": "Sonstiges" - }, - "incidentStatus": { - "neu": "Neu", - "triage": "Triage", - "in_bearbeitung": "In Bearbeitung", - "eingedaemmt": "Eingedämmt", - "behoben": "Behoben", - "abgeschlossen": "Abgeschlossen", - "wiedereroeffnet": "Wiedereröffnet" - }, - "incidentSeverity": { - "niedrig": "Niedrig", - "mittel": "Mittel", - "hoch": "Hoch", - "kritisch": "Kritisch" - }, - "measures": { - "title": "Aufgaben & Maßnahmen", - "sub": "Kanban-Board · Maßnahmen aus Risiken, Audits und Vorfällen", - "crumb": "Betrieb", - "newMeasure": "Maßnahme", - "board": "Maßnahmen-Board", - "empty": "Keine Maßnahmen.", - "detailHeading": "{ref} · {name}", - "detailSub": "Status, Verantwortung & verknüpfte Risiken", - "editTitle": "Maßnahme bearbeiten", - "createTitle": "Maßnahme anlegen", - "titleField": "Titel", - "description": "Beschreibung", - "status": "Status", - "priority": "Priorität", - "owner": "Verantwortlich", - "dueDate": "Fällig am", - "linkedRisks": "Verknüpfte Risiken", - "linkedRisksNote": "Diese Maßnahme mindert folgende Risiken", - "noRisks": "Keine Risiken verknüpft.", - "close": "Schließen", - "overdue": "überfällig", - "dragHint": "Karten per Drag-and-Drop zwischen den Spalten verschieben." - }, - "measureStatus": { - "OPEN": "Offen", - "IN_PROGRESS": "In Umsetzung", - "DONE": "Erledigt" - }, - "measurePriority": { - "LOW": "Niedrig", - "MEDIUM": "Mittel", - "HIGH": "Hoch" - }, - "dependencies": { - "title": "Abhängigkeiten & kritische Pfade", - "sub": "Verkettung von Prozessen und Assets · kritische Pfade & Single Points of Failure", - "crumb": "Fachdaten", - "search": "Suchen …", - "criticalToggle": "Kritische Pfade", - "onlyProcesses": "Nur Prozesse", - "fit": "Zentrieren", - "graphView": "Netzwerkgraph", - "analysis": "Analyse", - "spofTitle": "Single Points of Failure", - "spofNone": "Keine SPOF erkannt.", - "spofHint": "{count} kritische Prozesse hängen davon ab", - "critPathTitle": "Kritischster Pfad", - "critPathNone": "Kein kritischer Pfad.", - "critProcesses": "Kritische Prozesse", - "critEdges": "Kritische Kanten", - "legend": "Legende", - "legCritical": "Kritischer Pfad", - "legStandard": "Standard-Abhängigkeit", - "legSpof": "Single Point of Failure", - "legCrit": "Kritisch (K≥3)", - "empty": "Noch keine Prozesse/Assets für einen Graphen vorhanden.", - "openGraph": "Im Abhängigkeitsgraph anzeigen" - }, - "suppliers": { - "title": "Lieferanten & Dienstleister", - "sub": "VDA-ISA 2027 Kap. 6 · NIS2 Lieferkette (Art. 21(2)(d))", - "crumb": "Fachdaten", - "new": "Lieferant", - "newSupplier": "Neuer Lieferant", - "ref": "ID", - "kpiTotal": "Lieferanten", - "kpiNis2": "NIS2-relevant", - "kpiExpiring": "Ablaufend (90 T.)", - "kpiReviews": "Reviews fällig", - "name": "Name", - "sector": "Sektor", - "services": "Leistung / IT-Services", - "criticality": "Kritikalität", - "dataCategories": "Datenkategorien (kommagetrennt)", - "protection": "Schutzbedarf", - "nis2": "NIS2-relevant (Lieferkette)", - "status": "Status", - "contact": "Kontakt", - "nextReview": "Nächstes Review", - "notes": "Anmerkungen", - "empty": "Keine Lieferanten erfasst.", - "detailSub": "Bewertung, Verträge, Nachweise & Verantwortung", - "createTitle": "Lieferant anlegen", - "editTitle": "Lieferant bearbeiten", - "masterPill": "■ Stammdaten", - "catalog": "VDA-ISA 2027 · Kap. 6 Supplier Relationships", - "catalogNote": "Reifegrad je Prüfziel (Ziel 3)", - "target": "Ziel", - "maturity": "Reifegrad", - "references": "Referenzen", - "objective": "Zielbild", - "must": "Muss", - "should": "Soll", - "high": "Hoher Schutzbedarf", - "veryHigh": "Sehr hoher Schutzbedarf", - "sga": "Simplified Group Assessment", - "assessments": "Sicherheitsbewertungen", - "addAssessment": "Bewertung hinzufügen", - "score": "Score", - "result": "Ergebnis", - "type": "Typ", - "date": "Datum", - "contracts": "Verträge", - "addContract": "Vertrag hinzufügen", - "avDpa": "AV/DPA (Art. 28)", - "securityClauses": "Sicherheitsklauseln", - "flowdown": "Flow-down (Subunternehmer)", - "customerTransparency": "Kunden-Transparenz", - "validFrom": "Gültig ab", - "validTo": "Gültig bis", - "reference": "Referenz", - "ndas": "NDA / Geheimhaltung", - "addNda": "NDA hinzufügen", - "parties": "Parteien", - "infoScope": "Informationsart", - "subject": "Gegenstand", - "obligations": "Pflichten", - "extensionStatus": "Verlängerung", - "evidence": "Nachweise & Assurance", - "addEvidence": "Nachweis hinzufügen", - "kind": "Art", - "protectsCia": "Deckt (C/I/A)", - "adequacy": "Angemessenheit geprüft", - "expires": "läuft ab", - "raci": "Verantwortung (Shared Responsibility)", - "addRaci": "Zuordnung hinzufügen", - "itService": "IT-Service", - "requirement": "Anforderung", - "responsible": "Verantwortlich", - "isaApplicability": "ISA-Anwendbarkeit", - "localControls": "Lokale Schutzmaßnahmen", - "subcontractors": "Subunternehmer (4th Party)", - "addSub": "Subunternehmer hinzufügen", - "flowdownObl": "Flow-down-Pflicht", - "decision": "Risikobasierte Managemententscheidung", - "addDecision": "Entscheidung protokollieren", - "reasonNoAudit": "Grund (kein Audit/Label)", - "decisionText": "Entscheidung", - "decidedBy": "Entschieden von", - "recordRef": "Aktenzeichen", - "decisionNeeded": "Kein Third-Party-Audit/TISAX-Label mit geprüfter Angemessenheit vorhanden — eine dokumentierte risikobasierte Managemententscheidung ist erforderlich.", - "assets": "Betroffene Assets", - "close": "Schließen", - "none": "—", - "add": "Hinzufügen", - "risks": "Risiken", - "isbApproval": "ISB-Freigabe Reifegrad", - "isbValue": "ISB-Wert", - "justification": "Begründung (bei Abweichung Pflicht)", - "approve": "Freigeben", - "approvalNote": "Abweichung vom berechneten Wert wird mit Begründung im Audit-Log erfasst.", - "customerReq": "Kundenanforderungen weitergegeben", - "linkedAssets": "Verknüpfte Assets", - "derivedLevel": "Abgeleitete Stufe", - "conformity": "Konformität" - }, - "assessmentType": { - "QUESTIONNAIRE": "Fragebogen", - "SELF_ASSESSMENT": "Self-Assessment", - "AUDIT": "Audit" - }, - "assessmentStatus": { - "SENT": "Versendet", - "RECEIVED": "Eingegangen", - "EVALUATED": "Bewertet", - "OVERDUE": "Überfällig" - }, - "evidenceKind": { - "CERTIFICATE": "Zertifikat", - "TISAX_LABEL": "TISAX-Label", - "ATTESTATION": "Attestierung", - "AUDIT_REPORT": "Auditbericht", - "SELF_ASSESSMENT": "Self-Assessment" - }, - "responsibleParty": { - "CLIENT": "Kunde", - "SUPPLIER": "Lieferant", - "SHARED": "Geteilt" - }, - "supplierStatus": { - "ACTIVE": "Aktiv", - "ONBOARDING": "Onboarding", - "UNDER_REVIEW": "In Prüfung", - "OFFBOARDED": "Beendet" - }, - "services": { - "tabSuppliers": "Lieferanten", - "tabServices": "IT-Services", - "title": "IT-Services", - "newService": "IT-Service", - "ref": "ID", - "name": "Name", - "provider": "Provider (Lieferant)", - "internal": "Intern betrieben", - "criticality": "Kritikalität", - "protection": "Schutzbedarf", - "raciCoverage": "RACI dokumentiert", - "empty": "Keine IT-Services erfasst.", - "createTitle": "IT-Service anlegen", - "editTitle": "IT-Service bearbeiten", - "detailSub": "Asset-artig · Verantwortung (RACI) · Risiken", - "notes": "Anmerkungen", - "linkedAssets": "Verknüpfte Assets", - "linkedProcesses": "Prozesse", - "risks": "Risiken", - "noProvider": "kein Provider", - "raci": "Verantwortungsmatrix (Shared Responsibility)", - "raciNote": "Anwendbarkeit der ISA-Controls je Service — erfüllt 6.1.3", - "addControl": "Control hinzufügen", - "control": "Control", - "controlTitle": "Titel", - "applicable": "Anwendbar", - "responsibility": "Verantwortung", - "evidence": "Nachweis", - "raciEmpty": "Noch keine Controls zugeordnet.", - "close": "Schließen", - "none": "—", - "tabSoftware": "Software" - }, - "raciParty": { - "PROVIDER": "Provider", - "US": "Wir", - "SHARED": "Geteilt" - }, - "policies": { - "crumb": "ISMS-Dokumentation", - "title": "Richtlinien & Verfahren", - "sub": "VDA-ISA 2027 — Leitlinie, Richtlinien, Verfahrensanweisungen und Register", - "library": "Bibliothek", - "coverage": "Coverage-Matrix", - "byDomain": "Nach Fachbereich", - "domainResponsible": "Zuständig", - "domainUnassigned": "Nicht besetzt", - "domainNone": "Ohne Fachbereich", - "domainSet": "Fachbereich zuordnen", - "deriveDomains": "Fachbereiche ableiten", - "deriveDomainsDone": "{n} Fachbereiche aus dem primären Control abgeleitet.", - "deriveDomainsNone": "Alle Dokumente haben bereits einen Fachbereich.", - "actions": "Aktionen", - "submitReview": "Zur Prüfung geben", - "all": "Alle", - "code": "Kürzel", - "docTitle": "Titel", - "type": "Typ", - "version": "Version", - "status": "Status", - "coverageCol": "Abdeckung", - "controlsN": "{n} Controls", - "empty": "Keine Dokumente gefunden.", - "close": "Schließen", - "docInfo": "Dokumenteninformationen", - "operationalizes": "Operationalisiert Richtlinie", - "procedures": "Verfahren", - "control": "ISA-Control", - "policy": "Richtlinie", - "reqIds": "Anforderungs-IDs", - "coverageHint": "{controls} Controls · {reqs} Anforderungen (MUSS/SOLL) über Richtlinien und operationalisierende Verfahren.", - "kpiDocs": "Dokumente", - "kpiDocsTrend": "Leitlinie · Richtlinien · Verfahren · Register", - "kpiControls": "Abgedeckte Controls", - "kpiControlsTrend": "VDA-ISA 2027", - "kpiMust": "MUSS-Anforderungen", - "kpiShould": "SOLL-Anforderungen", - "openFullTable": "Vollständige Tabelle öffnen", - "backToLibrary": "Zurück zur Bibliothek", - "backToDoc": "Zurück zum Dokument", - "editableInline": "direkt in der Ansicht bearbeitbar", - "edit": "Bearbeiten", - "editTitle": "Dokument bearbeiten", - "editHint": "Änderungen werden direkt gespeichert. Der Vier-Augen-Freigabe-Workflow mit Versionierung folgt. Variablenwerte gelten zentral für alle Dokumente.", - "template": "Vorlage (Markdown)", - "docVariables": "Dokument-Variablen", - "docVariablesHint": "Nur die in diesem Dokument vorkommenden Variablen. Änderungen wirken in allen Dokumenten (eine Pflegestelle).", - "flagOn": "aktiv (ja)", - "flagOff": "inaktiv (nein)", - "preview": "Vorschau (Lesemodus)", - "approval": "Freigabe", - "submitForApproval": "Zur Freigabe einreichen", - "submittedBy": "Eingereicht von", - "approve": "Genehmigen (ISB)", - "reject": "Ablehnen", - "rejectReason": "Begründung der Ablehnung", - "fourEyesSelf": "Vier-Augen-Prinzip: Die Freigabe muss durch eine andere Person als den Einreichenden erfolgen.", - "fourEyesNoRight": "Freigabe erfordert die Rolle mit Freigaberecht (z. B. ISB).", - "approvedBy": "Freigegeben von", - "resubmit": "Erneut zur Freigabe einreichen", - "approvalNote": "Vier-Augen: Freigebender ≠ Autor. Versionierung/Diff folgt.", - "saveVariables": "Variablen speichern", - "modeStandard": "Standard (Variablen)", - "modeExpert": "Experten-Modus", - "expertHint": "Voller Vorlagen-Editor: Text, Formatierung, Variablen, Deep-Links & Referenzen. Neue Variablen werden beim Speichern angelegt und sind danach im Standard-Modus pflegbar.", - "byControl": "nach Control", - "byDocument": "nach Dokument", - "assessmentExport": "Assessment-Export", - "requirements": "Anforderung(en)", - "requirement": "Anforderung", - "implementation": "Umsetzung", - "comingSoon": "Bald verfügbar", - "kpiRequirements": "Anforderungen", - "protectionLevel": "Schutzbedarf / TISAX-Level", - "effectiveLevel": "Effektiv", - "globalLevel": "Global", - "levelGlobal": "Global übernehmen", - "levelAl2": "MUSS·SOLL·HOCH", - "levelAl3": "+ SEHR HOCH" - }, - "software": { - "title": "Software-Freigaben", - "tabTitle": "Software", - "newSoftware": "Software erfassen", - "ref": "Kürzel", - "name": "Software", - "provider": "Anbieter/Lieferant", - "noProvider": "kein Anbieter", - "version": "Version/Patch-Stand", - "approvalStatus": "Freigabestatus", - "approvedBy": "Freigeber", - "criticality": "Kritikalität", - "protection": "Schutzbedarf", - "nextReview": "Nächstes Review", - "review": "Review", - "notes": "Notizen", - "createTitle": "Software erfassen", - "editTitle": "Software bearbeiten", - "detailSub": "Freigegebene Software (Whitelist) mit Anbieter und Review", - "masterPill": "Stammdaten", - "linkedRisks": "Zugeordnete Risiken", - "empty": "Noch keine Software erfasst.", - "close": "Schließen", - "none": "—" - }, - "softwareStatus": { - "BEANTRAGT": "Beantragt", - "FREIGEGEBEN": "Freigegeben", - "GESPERRT": "Gesperrt" - }, - "projects": { - "title": "Projekte", - "newProject": "Projekt anlegen", - "ref": "Kürzel", - "name": "Projektname", - "owner": "Projektleitung", - "classification": "IS-Klassifizierung", - "status": "Status", - "isbInvolved": "ISB eingebunden", - "criticality": "Kritikalität", - "protection": "Schutzbedarf", - "notes": "Notizen", - "createTitle": "Projekt anlegen", - "editTitle": "Projekt bearbeiten", - "detailSub": "Informationssicherheit in Projekten (R01 / VA-19)", - "masterPill": "Stammdaten", - "linkedRisks": "Zugeordnete Risiken", - "empty": "Noch keine Projekte erfasst.", - "close": "Schließen", - "none": "—" - }, - "projectStatus": { - "GEPLANT": "Geplant", - "LAUFEND": "Laufend", - "ABGESCHLOSSEN": "Abgeschlossen", - "ABGEBROCHEN": "Abgebrochen" - }, - "onboarding": { - "crumb": "Einrichtung", - "title": "Onboarding-Wizard", - "progress": "{done} von {total} Schritten validiert · {percent}%", - "stepTitle": { - "context": "Kontext & Fakten", - "scope": "Geltungsbereich", - "policy": "Leitlinie & Richtlinien", - "roles": "Team & Rollen", - "criteria": "Kriterien & Skala", - "processes": "Prozesse", - "information": "Information", - "assets": "Assets", - "protection": "Schutzbedarf", - "risks": "Risiken", - "controls": "Controls", - "gap": "GAP-Analyse", - "readiness": "Audit-Readiness" - }, - "status": { - "offen": "Offen", - "in_bearbeitung": "In Bearbeitung", - "zur_validierung": "Zur Validierung", - "validiert": "Validiert", - "zurueckgewiesen": "Zurückgewiesen" - }, - "actions": { - "start": "Bearbeitung starten", - "submit": "Zur Validierung geben", - "validate": "Validieren", - "reset": "Zurücksetzen", - "back": "Zurück", - "next": "Weiter", - "rework": "Nacharbeiten", - "reject": "Zurückweisen" - }, - "placeholderNote": "Dieser Schritt wird in einer folgenden Story mit Inhalt gefüllt. Navigation, Status und Gate sind bereits aktiv.", - "locked": "Gesperrt – vorherige Schritte zuerst validieren.", - "gateHint": "Dieser Schritt ist noch nicht freigegeben — Sie können dennoch fortfahren; die Freigabe kann parallel erfolgen.", - "allDone": "Alle Schritte abgeschlossen", - "rejectCommentPlaceholder": "Begründung der Rückweisung (optional)", - "rejectedTitle": "Zurückgewiesen – bitte nacharbeiten", - "rejectedNoComment": "Keine Begründung hinterlegt.", - "awaitingValidation": "Wartet auf Validierung durch eine berechtigte Rolle." - }, - "auditReadiness": { - "crumb": "Audit vorbereiten", - "title": "Audit-Wizard", - "progress": "{done} von {total} Schritten validiert · {percent}%", - "stepTitle": { - "internal_audit": "Internes Audit", - "audit_gap": "GAP-Konsolidierung", - "audit_evidence": "Nachweis-Check", - "audit_readiness": "Readiness & Management-Review" - }, - "status": { - "offen": "Offen", - "in_bearbeitung": "In Bearbeitung", - "zur_validierung": "Zur Validierung", - "validiert": "Validiert", - "zurueckgewiesen": "Zurückgewiesen" - }, - "actions": { - "start": "Bearbeitung starten", - "submit": "Zur Validierung geben", - "validate": "Validieren", - "reset": "Zurücksetzen", - "back": "Zurück", - "next": "Weiter", - "rework": "Nacharbeiten", - "reject": "Zurückweisen" - }, - "gateHint": "Dieser Schritt ist noch nicht freigegeben — Sie können dennoch fortfahren; die Freigabe kann parallel erfolgen.", - "allDone": "Alle Schritte abgeschlossen", - "rejectCommentPlaceholder": "Begründung der Rückweisung (optional)", - "rejectedTitle": "Zurückgewiesen – bitte nacharbeiten", - "rejectedNoComment": "Keine Begründung hinterlegt.", - "awaitingValidation": "Wartet auf Validierung durch eine berechtigte Rolle." - }, - "processHouse": { - "title": "Prozesshaus", - "intro": "Aktiviere die relevanten Prozesse (Schalter) und arbeite dich je Kachel durch das geführte BIA-Popup. Die Farbe der Kachel zeigt den BIA-Stand.", - "newProcess": "Prozess anlegen", - "toModule": "Zum Prozess-Modul", - "kpiTotal": "Prozesse", - "kpiInScope": "im Scope (aktiv)", - "kpiDone": "BIA komplett", - "legend": "Legende", - "empty": "Noch keine Prozesse. Lege eigene an oder übernimm welche aus dem Standard-Katalog.", - "laneEmpty": "Keine Prozesse in dieser Bahn.", - "unassigned": "unbesetzt", - "deputy": "Stellvertreter", - "openBia": "BIA öffnen", - "details": "Details", - "activate": "Aktivieren", - "deactivate": "Deaktivieren", - "subProcesses": "{count} Teilprozess(e)", - "dotInfo": "Info", - "dotCarrier": "Träger", - "dotCia": "C/I/A", - "dotRisk": "Risiken", - "catalogTitle": "Aus Standard-Katalog übernehmen", - "catalogHint": "Kuratierte Kern-, Management- und Unterstützungsprozesse. „Übernehmen“ legt den Prozess im Register an (Zuordnung über Katalog-Code).", - "adopt": "Übernehmen", - "adopted": "übernommen", - "inclSub": "inkl. {count} Teilprozesse", - "delete": "Löschen", - "deleteConfirm": "Diesen Prozess wirklich entfernen? BIA-Eintrag und Träger-Zuordnungen werden gelöscht, Teilprozesse auf die oberste Ebene gehoben und Risiko-Verknüpfungen gelöst.", - "deleteConfirmBtn": "Endgültig löschen", - "detailSub": "Fachliche Übersicht & BIA (nur Ansicht)", - "children": "Teilprozesse", - "noChildren": "keine", - "status": { - "offen": "offen", - "teilweise": "teilweise", - "komplett": "komplett" - } - }, - "bia": { - "heading": "BIA · {name}", - "stepOf": "Schritt {n} von {total}", - "status": { - "offen": "BIA offen", - "teilweise": "BIA teilweise", - "komplett": "BIA komplett" - }, - "back": "Zurück", - "next": "Weiter", - "open": "offen", - "captured": "erfasst", - "s1Short": "Informationswert", - "s2Short": "Träger", - "s3Short": "Schutzbedarf", - "s4Short": "Risiken", - "s5Short": "Abschluss", - "s1Title": "Informationswert erfassen", - "s1Hint": "Ein Informationswert ist ein primäres Asset (Information/Daten). Katalog-Vorschlag nutzen, per Dedup-Suche erfassen oder mit der vollen Asset-Maske anlegen.", - "catalogLabels": "Katalog-Vorschlag (Klassifizierung)", - "currentPrimaries": "Erfasste Informationswerte", - "noPrimaries": "Noch kein Informationswert erfasst.", - "quickAdd": "Schnell erfassen (mit Dedup + Autovervollständigung)", - "manualToggle": "Manuell mit voller Asset-Inventar-Maske erfassen", - "manualHint": "Legt ein primäres Asset (Typ Information) an und verknüpft es mit diesem Prozess.", - "s2Title": "Sekundäre Assets / Träger", - "s2Hint": "Träger (Systeme, Anwendungen, Standorte, Dienstleister …), auf denen die Informationswerte liegen.", - "suggestedCarriers": "Träger-Vorschläge (Typen)", - "currentCarriers": "Zugeordnete Träger", - "noCarriers": "Noch keine Träger zugeordnet.", - "assignCarrier": "Träger zuordnen", - "noAvailable": "Keine weiteren Assets verfügbar — im Asset-Modul anlegen.", - "newCarrier": "Neues Träger-Asset anlegen", - "newCarrierHint": "Legt ein neues Träger-Asset über die volle Asset-Inventar-Maske an und verknüpft es als Träger (sekundär) mit diesem Prozess.", - "s3Title": "Schutzbedarf C/I/A", - "s3Hint": "Der Schutzbedarf liegt am primären Informationswert. Träger erben per Maximumprinzip.", - "noPrimaryForCia": "Zuerst in Schritt 1 einen Informationswert erfassen.", - "inheritedMax": "Geerbtes Maximum (Träger)", - "inheritedHint": "Träger sollten mindestens dieses Maximum ihrer getragenen primären Werte erfüllen.", - "s4Title": "Risiken je Prozess", - "s4Hint": "Passende Katalog-Risiken übernehmen und im selben Schritt bewerten (Eintritt × Auswirkung = Wert).", - "suggestedRisks": "Empfohlene Risiken (Katalog)", - "adopt": "Übernehmen", - "adopted": "übernommen", - "currentRisks": "Bewertung der Risiken", - "noRisks": "Noch keine Risiken mit diesem Prozess verknüpft.", - "likelihood": "Eintritt (1–5)", - "impact": "Auswirkung (1–5)", - "treatment": "Behandlung", - "statusField": "Status", - "rate": "Bewerten", - "openInRiskModule": "Im Risiko-Modul öffnen", - "linkRisk": "Risiko zuordnen", - "newRisk": "Neues Risiko anlegen", - "riskTitle": "Titel", - "riskDescription": "Beschreibung", - "s5Title": "Abschluss-Übersicht", - "s5Hint": "Kompletter Review aller erfassten Werte. Bei Abschluss wird der BIA-Stand gesetzt (Prozesshaus-Farbe).", - "clInfo": "Informationswert", - "clCarrier": "Träger", - "clCia": "Schutzbedarf", - "clRisk": "Risiken", - "reviewInfo": "Informationswerte & Schutzbedarf", - "reviewCarriers": "Träger", - "reviewRisks": "Risiken", - "finishTitle": "BIA abschließen", - "finishHint": "{done} von {total} Bereichen erfasst.", - "markComplete": "Als komplett markieren", - "markPartial": "Als teilweise markieren", - "criticality": "Kritikalität" - }, - "admin": { - "backToOverview": "Zurück zur Übersicht", - "crumb": "Mandant", - "sub": "Kürzel {slug}{sector} · TISAX {level}", - "statusActive": "Aktiv", - "statusSuspended": "Gesperrt", - "statusArchived": "Archiviert", - "masterDataTitle": "Stammdaten", - "masterDataHint": "Zentrale Quelle der ISMS-Variablen (Mandanten-Einstellungen).", - "orgName": "Unternehmensname", - "orgShort": "Kurzname", - "slug": "Kürzel", - "address": "Adresse", - "sector": "Sektor", - "duns": "D-U-N-S", - "ismsScope": "ISMS-Geltungsbereich", - "tisaxLevel": "TISAX-Level", - "status": "Status", - "notSet": "—", - "mainContactTitle": "Hauptkontakt", - "mainContactHint": "Abgeleitet aus dem/den Mandanten-Administrator(en).", - "mainContactNone": "Kein aktiver Mandanten-Administrator hinterlegt.", - "manageTitle": "Verwaltung", - "manageHint": "Module und Benutzer dieses Mandanten in einem Popup verwalten.", - "manageModules": "Module verwalten", - "manageUsers": "Benutzer verwalten", - "usersCount": "{count} Nutzer", - "modulesTitle": "Module", - "modulesHint": "Deaktivierte Module sind für den Kunden ausgeblendet und serverseitig gesperrt.", - "moduleActive": "Aktiv", - "moduleInactive": "Inaktiv", - "moduleActivate": "Aktivieren", - "moduleDeactivate": "Deaktivieren", - "importTemplates": "Vorlagen importieren", - "importTemplatesTitle": "Vorlagenpaket nicht-destruktiv importieren/aktualisieren", - "modulesModalSub": "Module für {name} aktivieren/deaktivieren", - "usersModalSub": "Benutzer von {name} — anlegen, Rollen, deaktivieren, Passwort zurücksetzen", - "lifecycleTitle": "Lebenszyklus", - "lifecycleActivate": "Aktivieren", - "lifecycleSuspend": "Sperren (Login blockiert)", - "lifecycleArchive": "Archivieren", - "lifecycleNote": "Löschung/Datenexport (DSGVO) und Retention folgen in Phase 2.", - "assessmentTitle": "Assessment-Level (Schutzbedarf)", - "assessmentHint": "Einzige Quelle des Schutzbedarfs — steuert die Schutzbedarf-Flags des Richtlinienmoduls, den Coverage-Filter und den Onboarding-Wizard (dort read-only). Aktuell: {level}.", - "assessmentAl2": "AL2 — MUSS · SOLL · HOCH", - "assessmentAl3": "AL3 — zusätzlich SEHR HOCH", - "mfaTitle": "MFA-Pflicht", - "mfaHint": "Bei Aktivierung müssen alle Nutzer dieses Mandanten beim nächsten Login eine Zwei-Faktor-Authentifizierung einrichten. Aktuell: {state}.", - "mfaStateOn": "aktiv", - "mfaStateOff": "aus", - "mfaActivate": "MFA-Pflicht aktivieren", - "mfaDeactivate": "MFA-Pflicht deaktivieren", - "policyLangTitle": "Sprache der Richtlinien", - "policyLangHint": "Bestimmt, in welcher Sprache das Vorlagenpaket importiert/aktualisiert wird. Wirkt auf künftige Importe; bereits importierte Richtlinien bleiben unverändert, bis der Mandant unter Paket-Updates übernimmt. Aktuell: {lang}.", - "policyLangDe": "Deutsch", - "policyLangEn": "English", - "auditTitle": "Audit-Trail", - "auditHint": "Nachvollziehbare Aktivitäten dieses Mandanten — wer hat wann was geändert.", - "auditView": "Audit-Trail einsehen", - "auditSub": "Aktivitäten von {name} (neueste zuerst, letzte 200)", - "userCreate": "Benutzer anlegen", - "userCreateSub": "Neuer Nutzer für {name}", - "userEdit": "Benutzer bearbeiten — {name}", - "close": "Schließen", - "frameworksTitle": "Normen / Rahmenwerke", - "frameworksHint": "Aktiv: {list}. Steuert Anforderungssicht, SoA und Auswertung. Mindestens eine Norm muss aktiv bleiben.", - "frameworksTisax": "TISAX / VDA ISA", - "frameworksIso": "ISO/IEC 27001", - "frameworksActivate": "Aktivieren", - "frameworksDeactivate": "Deaktivieren", - "frameworksActive": "Aktiv", - "frameworksNote": "Beim Aktivieren wird das Vorlagenpaket der Norm importiert. Beim Deaktivieren bleiben die Bewertungen erhalten und werden nur stillgelegt." - } -} diff --git a/messages/de/admin.json b/messages/de/admin.json new file mode 100644 index 0000000..bd337e6 --- /dev/null +++ b/messages/de/admin.json @@ -0,0 +1,58 @@ +{ + "backToOverview": "Zurück zur Übersicht", + "crumb": "Mandant", + "sub": "Kürzel {slug}{sector}", + "statusActive": "Aktiv", + "statusSuspended": "Gesperrt", + "statusArchived": "Archiviert", + "masterDataTitle": "Stammdaten", + "masterDataHint": "Unternehmensdaten aus den Mandanten-Einstellungen.", + "orgName": "Unternehmensname", + "orgShort": "Kurzname", + "slug": "Kürzel", + "address": "Adresse", + "sector": "Sektor", + "status": "Status", + "notSet": "—", + "mainContactTitle": "Hauptkontakt", + "mainContactHint": "Abgeleitet aus dem/den Mandanten-Administrator(en).", + "mainContactNone": "Kein aktiver Mandanten-Administrator hinterlegt.", + "manageTitle": "Verwaltung", + "manageHint": "Module und Benutzer dieses Mandanten in einem Popup verwalten.", + "manageModules": "Module verwalten", + "manageUsers": "Benutzer verwalten", + "usersCount": "{count} Nutzer", + "modulesTitle": "Module", + "modulesHint": "Deaktivierte Module sind für den Kunden ausgeblendet und serverseitig gesperrt.", + "moduleActive": "Aktiv", + "moduleInactive": "Inaktiv", + "moduleActivate": "Aktivieren", + "moduleDeactivate": "Deaktivieren", + "modulesModalSub": "Module für {name} aktivieren/deaktivieren", + "usersModalSub": "Benutzer von {name} — anlegen, Rollen, deaktivieren, Passwort zurücksetzen", + "lifecycleTitle": "Lebenszyklus", + "lifecycleActivate": "Aktivieren", + "lifecycleSuspend": "Sperren (Login blockiert)", + "lifecycleArchive": "Archivieren", + "lifecycleNote": "Gesperrte Mandanten können sich nicht anmelden; Archivierung blendet sie aus.", + "mfaTitle": "MFA-Pflicht", + "mfaHint": "Bei Aktivierung müssen alle Nutzer dieses Mandanten beim nächsten Login eine Zwei-Faktor-Authentifizierung einrichten. Aktuell: {state}.", + "mfaStateOn": "aktiv", + "mfaStateOff": "aus", + "mfaActivate": "MFA-Pflicht aktivieren", + "mfaDeactivate": "MFA-Pflicht deaktivieren", + "auditTitle": "Audit-Trail", + "auditHint": "Nachvollziehbare Aktivitäten dieses Mandanten — wer hat wann was geändert.", + "auditView": "Audit-Trail einsehen", + "auditSub": "Aktivitäten von {name} (neueste zuerst, letzte 200)", + "userCreate": "Benutzer anlegen", + "userCreateSub": "Neuer Nutzer für {name}", + "userEdit": "Benutzer bearbeiten — {name}", + "close": "Schließen", + "phone": "Telefon", + "email": "E-Mail", + "localeTitle": "Mandantensprache", + "localeHint": "Standardsprache für Benachrichtigungen und Dokumente dieses Mandanten (Nutzer wählen ihre UI-Sprache selbst). Aktuell: {lang}.", + "localeDe": "Deutsch", + "localeEn": "English" +} diff --git a/messages/de/common.json b/messages/de/common.json new file mode 100644 index 0000000..dbc6606 --- /dev/null +++ b/messages/de/common.json @@ -0,0 +1,23 @@ +{ + "appName": "Craftvia", + "appTagline": "Handwerk. Digital auf Kurs.", + "language": "Sprache", + "logout": "Abmelden", + "create": "Anlegen", + "save": "Speichern", + "cancel": "Abbrechen", + "edit": "Bearbeiten", + "delete": "Löschen", + "back": "Zurück", + "close": "Schließen", + "search": "Suchen…", + "actions": "Aktionen", + "add": "Hinzufügen", + "remove": "Entfernen", + "none": "—", + "comingSoon": "Bald verfügbar", + "confirmDelete": "Wirklich löschen?", + "yes": "Ja", + "no": "Nein", + "readOnly": "Nur-Lese-Zugriff." +} diff --git a/messages/de/dashboard.json b/messages/de/dashboard.json new file mode 100644 index 0000000..6d8db7b --- /dev/null +++ b/messages/de/dashboard.json @@ -0,0 +1,8 @@ +{ + "title": "Dashboard", + "crumb": "Übersicht", + "subtitle": "Willkommen, {name} — {tenant}", + "placeholderTitle": "Dashboard in Umsetzung", + "placeholder": "Hier erscheinen künftig offene Aufträge, heutige Einsätze, freizugebende Berichte und Notdienst-Meldungen.", + "moduleDisabled": "Das angeforderte Modul ist für Ihren Betrieb nicht freigeschaltet." +} diff --git a/messages/de/login.json b/messages/de/login.json new file mode 100644 index 0000000..bee6d7a --- /dev/null +++ b/messages/de/login.json @@ -0,0 +1,11 @@ +{ + "title": "Anmelden", + "tagline": "Handwerk. Digital auf Kurs.", + "subtitle": "Melde dich mit deinem Firmenkonto an.", + "email": "E-Mail-Adresse", + "password": "Passwort", + "mfaOptional": "MFA-Code (falls eingerichtet)", + "submit": "Anmelden", + "forgotPassword": "Passwort vergessen?", + "error": "Anmeldung fehlgeschlagen. Bitte prüfe E-Mail und Passwort." +} diff --git a/messages/de/modules.json b/messages/de/modules.json new file mode 100644 index 0000000..b1a1757 --- /dev/null +++ b/messages/de/modules.json @@ -0,0 +1,18 @@ +{ + "customers": "Kunden", + "sites": "Objekte", + "teams": "Teams", + "workOrders": "Aufträge", + "imports": "Auftragsimport", + "field": "Einsätze", + "reports": "Berichte", + "emergency": "Notdienst", + "documents": "Dokumente", + "notifications": "Benachrichtigungen", + "lotse": "Lotse (KI-Assistent)", + "placeholder": { + "crumb": "Modul", + "status": "Modul in Umsetzung", + "hint": "Dieser Bereich wird gerade gebaut. Navigation, Modul-Freischaltung und Berechtigungen sind bereits aktiv." + } +} diff --git a/messages/de/nav.json b/messages/de/nav.json new file mode 100644 index 0000000..a3ecd70 --- /dev/null +++ b/messages/de/nav.json @@ -0,0 +1,12 @@ +{ + "dashboard": "Dashboard", + "workOrders": "Aufträge", + "imports": "Import", + "customers": "Kunden", + "sites": "Objekte", + "teams": "Teams", + "reports": "Berichte", + "documents": "Dokumente", + "settings": "Einstellungen", + "admin": "Admin-Konsole" +} diff --git a/messages/en.json b/messages/en.json deleted file mode 100644 index aa5a69d..0000000 --- a/messages/en.json +++ /dev/null @@ -1,1136 +0,0 @@ -{ - "common": { - "appName": "Certvia", - "appTagline": "Information security. Finally simple.", - "appByline": "A GEFIM product", - "language": "Language", - "logout": "Sign out", - "create": "Create", - "save": "Save", - "cancel": "Cancel", - "edit": "Edit", - "delete": "Delete", - "back": "Back", - "close": "Close", - "search": "Search…", - "actions": "Actions", - "add": "Add", - "remove": "Remove", - "none": "—", - "comingSoon": "Coming soon", - "confirmDelete": "Really delete?", - "yes": "Yes", - "no": "No", - "readOnly": "Read-only access." - }, - "nav": { - "dashboard": "Dashboard", - "assetsBia": "Assets & BIA", - "risks": "Risk analysis", - "soa": "SoA & controls", - "measures": "Measures", - "tasks": "Tasks", - "incidents": "Incidents", - "policies": "Policies", - "chat": "ISMS chat", - "dependencies": "Dependencies", - "evidence": "Evidence", - "suppliers": "Suppliers", - "review": "Management review", - "assets": "Asset inventory", - "bia": "Business impact analysis", - "settings": "Settings", - "admin": "Admin console", - "onboarding": "Onboarding", - "auditReadiness": "Prepare audit" - }, - "login": { - "title": "Sign in", - "tagline": "Information security. Finally simple.", - "subtitle": "Sign in with your company account.", - "email": "E-mail address", - "password": "Password", - "mfaOptional": "MFA code (if enabled)", - "submit": "Sign in", - "forgotPassword": "Forgot password?", - "error": "Sign-in failed. Please check e-mail and password." - }, - "dashboard": { - "title": "Dashboard", - "welcome": "Welcome, {name}", - "tenant": "Tenant", - "roles": "Roles", - "placeholder": "Module dashboards (risks, tasks, SoA coverage) follow in upcoming iterations.", - "subtitle": "Welcome back, {name} — ISMS status for {tenant}.", - "kpiAssets": "Assets in inventory", - "kpiProcesses": "Processes (BIA)", - "kpiCritical": "Critical processes", - "kpiCriticalHint": "criticality high or very high", - "kpiRisks": "Open risks", - "kpiRisksHint": "coming with the risk module", - "activity": "Recent activity", - "activitySub": "Audit log", - "activityEmpty": "No activity yet.", - "onboardingTile": "Onboarding progress · {percent}%", - "onboardingTileSub": "{done} of {total} steps validated · next step: {step}", - "onboardingTileCta": "Open wizard →", - "incidentTile": "Incidents · reporting deadlines", - "incidentTileSub": "{open} open reporting deadline(s){overdue, plural, =0 {} other {, # overdue}}", - "incidentTileCta": "Go to incidents →" - }, - "assets": { - "title": "Assets & BIA", - "tabAssets": "Assets", - "tabProcesses": "Processes & BIA", - "newAsset": "New asset", - "name": "Name", - "description": "Description", - "type": "Type", - "status": "Status", - "owner": "Owner", - "location": "Location", - "tags": "Tags (comma-separated)", - "protection": "Protection needs", - "confidentiality": "Confidentiality", - "integrity": "Integrity", - "availability": "Availability", - "allTypes": "All types", - "allStatus": "All statuses", - "empty": "No assets found.", - "detailTitle": "Asset details", - "relations": "Dependencies", - "relationHint": "This asset depends on:", - "relationReverseHint": "Depending on this asset:", - "addRelation": "Add dependency", - "processes": "Assigned processes", - "linkedRisks": "Assigned risks", - "linkedRisksPlaceholder": "Risks will be linked with the risk module (iteration 3) and appear here.", - "editTitle": "Edit asset", - "createTitle": "Create asset", - "deleted": "Asset deleted", - "inheritedNote": "Inherited protection needs from processes (max principle) are considered in the BIA.", - "crumb": "Core data", - "invTitle": "Asset inventory", - "invSub": "{count} assets · protection needs by C/I/A · linked to BIA and risk", - "excelImport": "Excel import", - "export": "Export", - "kpiTotal": "Total assets", - "kpiTotalTrend": "{count} types", - "kpiHigh": "High protection needs", - "kpiHighTrend": "C/I/A ≥ 3", - "kpiNoOwner": "Without owner", - "kpiNoOwnerTrend": "assignment needed", - "kpiSuppliers": "Suppliers", - "kpiSuppliersTrend": "external", - "all": "All", - "filter": "Filter …", - "noOwner": "no owner", - "dependencies": "Dependencies", - "detailSub": "Master data, dependencies & risks", - "masterPill": "■ Master data", - "masterNote": "Classification & responsibility", - "depPill": "◆ Dependencies", - "depNote": "Linked assets", - "riskCount": "{count} risks", - "criticalTitle": "Critical IT services", - "criticalSub": "Automatically derived from asset inventory and BIA – read-only.", - "criticalService": "Critical IT service", - "biaCriticality": "BIA criticality", - "supportedProcesses": "Supported processes", - "criticalEmpty": "No critical IT services identified (high availability or BIA-critical process).", - "criticalNote": "This view is derived continuously from the asset inventory and the business impact analysis. RTO/RPO come from the linked processes (strictest value). Maintain data on the respective asset or process.", - "backToInventory": "Back to inventory" - }, - "assetType": { - "INFORMATION": "Information", - "SYSTEM": "System", - "APPLICATION": "Application", - "LOCATION": "Location", - "SUPPLIER": "Supplier", - "PERSON": "Person/role", - "DATA": "Data category", - "IT_SERVICE": "IT service", - "SOFTWARE": "Software", - "PROJECT": "Project" - }, - "assetStatus": { - "ACTIVE": "Active", - "PLANNED": "Planned", - "RETIRED": "Retired" - }, - "processes": { - "newProcess": "New process", - "name": "Name", - "description": "Description", - "owner": "Owner", - "criticality": "Criticality", - "assets": "Assigned assets", - "empty": "No processes found.", - "detailTitle": "Process details", - "createTitle": "Create process", - "editTitle": "Edit process", - "primaryAssets": "Primary assets", - "primaryHint": "The result asset produced/owned by this process.", - "secondaryAssets": "Secondary assets", - "secondaryHint": "Supporting assets (systems, applications, people, suppliers).", - "assignAsset": "Assign asset", - "role": "Role", - "linkedRisks": "Assigned risks", - "linkedRisksPlaceholder": "Risks will be linked with the risk module (iteration 3) and appear here.", - "bia": "Business impact analysis", - "rto": "RTO (hours)", - "rpo": "RPO (hours)", - "mtd": "MTD/MTPD (hours)", - "rtoLong": "Recovery Time Objective — max. time to recovery", - "rpoLong": "Recovery Point Objective — max. tolerable data loss", - "mtdLong": "Maximum Tolerable Downtime — max. tolerable outage", - "impact": "Damage level per protection goal (1–4)", - "notes": "Notes / damage scenarios", - "biaSaved": "BIA saved", - "noBia": "No BIA recorded yet.", - "biaTitle": "Business impact analysis", - "biaSub": "Criticality of business processes · RTO / RPO / MTD", - "biaReport": "BIA report (PDF)", - "viewHouse": "Process house", - "viewTable": "Table", - "kpiTotal": "Processes total", - "kpiInScope": "In scope", - "kpiBiaDone": "BIA complete", - "kpiCritical": "High criticality", - "mainProcs": "{count} main processes", - "subProcs": "{count} sub-processes", - "subHeading": "Sub-processes", - "biaOpen": "Record BIA", - "biaStatusLegend": "BIA status", - "rollupHint": "Aggregated from sub-processes (criticality = maximum, RTO/RPO/MTD = tightest value).", - "laneEmpty": "No processes in this category.", - "depsSection": "Dependencies", - "depsRequires": "requires", - "depsRequiredBy": "required by", - "depsAdd": "Add dependency", - "depsSelect": "Choose process …", - "depsNotePlaceholder": "Note (optional, e.g. \"ERP\")", - "depsNone": "none", - "depsRequiresHint": "Processes this one requires — if one fails, this process is affected.", - "depsRequiredByN": "{count} process(es) depend on this", - "depsGraphLink": "Dependency graph", - "critTable": "Process criticality", - "process": "Business process", - "detailHeading": "{name}", - "detailSub": "Assigned assets by role", - "critLabel": "Criticality: {label}", - "primaryPill": "★ Primary asset", - "primaryNote": "Result produced by the process", - "secondaryPill": "◆ Secondary assets", - "secondaryNote": "Required for processing", - "inherits": "inherits protection needs to secondary assets", - "showDependencies": "Show dependencies →", - "impactShort": "Damage level (C/I/A)", - "close": "Close", - "noAssets": "No assets assigned yet.", - "category": "Process category", - "secMaster": "Basic data", - "secAssets": "Assigned assets", - "deleteProcess": "Delete process", - "purpose": "Purpose / objective", - "parent": "Parent process", - "noParent": "— no parent (standalone)", - "deputyOwner": "Deputy", - "noDeputy": "unassigned", - "legalBasis": "Legal basis", - "interfaces": "Interfaces / data flows", - "dataProtectionRelevant": "Data-protection relevant", - "prototypeRelevant": "Prototype relevant", - "catalogCode": "Catalog code", - "businessInfo": "Business information" - }, - "processRole": { - "PRIMARY": "Primary", - "SECONDARY": "Secondary" - }, - "criticality": { - "1": "Low", - "2": "Medium", - "3": "High", - "4": "Very high" - }, - "protectionLevel": { - "1": "Normal", - "2": "Elevated", - "3": "High", - "4": "Very high" - }, - "processCategory": { - "CORE": "Core process", - "MANAGEMENT": "Management process", - "SUPPORT": "Supporting process" - }, - "risks": { - "title": "Risk analysis", - "sub": "5×5 matrix · likelihood × impact", - "export": "Export risk register", - "newRisk": "Risk", - "heatmap": "Risk heatmap", - "heatmapSub": "Impact (Y) × likelihood (X)", - "register": "Risk register", - "registerSub": "Risks by rating", - "id": "ID", - "risk": "Risk", - "rating": "Rating", - "treatment": "Treatment", - "status": "Status", - "owner": "Owner", - "empty": "No risks recorded yet.", - "detailHeading": "{ref} · {name}", - "detailSub": "Rating, affected assets & treatment", - "editTitle": "Edit risk", - "createTitle": "Create risk", - "titleField": "Title", - "description": "Description", - "threat": "Threat", - "vulnerability": "Vulnerability", - "likelihood": "Likelihood (1–5)", - "impact": "Impact (1–5)", - "gross": "Gross risk", - "residual": "Residual risk", - "residualHint": "After implementing measures", - "noResidual": "Not yet rated", - "process": "Business process", - "affectedAssets": "Affected assets", - "affectedNote": "Assets this risk applies to", - "addAsset": "Link asset", - "noAssets": "No assets linked.", - "measures": "Required measures", - "measuresPlaceholder": "Measures will be linked with the measures module (iteration 4) and appear here.", - "close": "Close", - "scoreLabel": "{score} · {level}", - "legendLow": "Low", - "legendMedium": "Medium", - "legendElevated": "Elevated", - "legendHigh": "High", - "legendCritical": "Critical", - "axisX": "Likelihood →", - "axisY": "Impact ↑", - "likelihoodShort": "Likelihood", - "damageShort": "Damage", - "scoreShort": "Risk score", - "residualAuto": "Derived automatically from the linked measures.", - "noMeasures": "No measures linked yet — the residual risk equals the gross risk.", - "linkMeasure": "Link measure", - "newMeasure": "Create & link new measure", - "measureTitle": "Measure title", - "reductionL": "Reduction likelihood (0.00–4.00)", - "reductionI": "Reduction damage (0.00–4.00)", - "reduction": "Reduction", - "createFromAsset": "Create risk", - "catalogHint": "Pick from catalog or type freely …", - "addExistingBtn": "Add measure", - "createNewBtn": "Create new measure", - "measureCol": "Measure", - "statusCol": "Status" - }, - "riskTreatment": { - "AVOID": "Avoid", - "MITIGATE": "Mitigate", - "TRANSFER": "Transfer", - "ACCEPT": "Accept" - }, - "riskStatus": { - "OPEN": "Open", - "IN_TREATMENT": "In treatment", - "ACCEPTED": "Accepted", - "CLOSED": "Closed" - }, - "riskLevel": { - "low": "Low", - "medium": "Medium", - "elevated": "Elevated", - "high": "High", - "critical": "Critical" - }, - "incidents": { - "title": "Incidents", - "sub": "Capture, assess, handle and close security incidents", - "crumb": "Operations", - "newIncident": "Report incident", - "register": "Incident register", - "registerSub": "All incidents of the tenant (newest first)", - "empty": "No incidents recorded.", - "id": "Reference", - "incident": "Incident", - "category": "Category", - "severity": "Severity", - "status": "Status", - "owner": "Owner (incident manager)", - "assignee": "Assignee", - "filter": "Filter", - "filterAll": "All", - "createTitle": "Report incident", - "createSub": "Capture title, description, category and impact", - "editTitle": "Edit incident", - "detailSub": "Assessment, steering, links, history", - "close": "Close", - "titleField": "Title", - "description": "Description", - "source": "Channel / source", - "source_manual": "Internal (manual)", - "source_email": "Email", - "reporter": "Reporter", - "reporterName": "Reporter (name)", - "reporterContact": "Reporter (contact)", - "occurredAt": "Occurred at", - "detectedAt": "Detected at", - "impactHead": "Impact & urgency", - "impactHint": "Protection-goal breach C/I/A and urgency (0–4) — determine the severity.", - "impactC": "Confidentiality (C)", - "impactI": "Integrity (I)", - "impactA": "Availability (A)", - "impactCia": "Impact C/I/A", - "urgency": "Urgency", - "priority": "Priority", - "dataCategories": "Affected data categories", - "dataCategoriesHint": "Comma-separated, e.g. customer data, credentials", - "personalData": "Personal data (→ GDPR)", - "prototypeData": "Prototype/customer data (→ TISAX)", - "nis2Relevant": "NIS2 relevant", - "flags": "Attributes", - "severityAutoHint": "Severity is derived automatically from impact × urgency (default matrix) and can be overridden by steering.", - "statusChange": "Status change", - "noTransitions": "No further status change possible.", - "applyStatus": "Set status", - "steering": "Steering", - "restricted": "Restricted", - "restrictedToggle": "Restricted (owner + roles with manage/close only)", - "rootCause": "Root cause", - "resolution": "Resolution", - "closingNote": "Closing note", - "lessonsLearned": "Lessons learned", - "assets": "Affected assets", - "processes": "Affected processes", - "risks": "Linked risks", - "controls": "Affected controls", - "controlsHint": "Which controls failed/were affected (catalog reference).", - "measures": "Linked measures", - "addAsset": "Link asset", - "addProcess": "Link process", - "addRisk": "Link risk", - "addMeasure": "Link measure", - "deleteHint": "Incidents are not deleted — close them for traceability.", - "comments": "Comments", - "noComments": "No comments yet.", - "commentPlaceholder": "Write a comment …", - "addComment": "Comment", - "internal": "Internal", - "timeline": "History (audit)", - "noTimeline": "No history entries yet.", - "reportingHead": "Reporting obligation & deadlines", - "nis2CategoryLabel": "Tenant NIS2 classification", - "nis2_keine": "none", - "nis2_wichtig": "important entity", - "nis2_wesentlich": "essential entity", - "reportStatus_none": "no reporting obligation", - "reportStatus_pruefung": "obligation reviewed", - "reportStatus_erstmeldung": "initial report", - "reportStatus_folgemeldung": "follow-up report", - "reportStatus_abschluss": "final report", - "deadlineKind_erstmeldung": "NIS2 initial report (24 h)", - "deadlineKind_folgemeldung": "NIS2 follow-up report (72 h)", - "deadlineKind_abschluss": "NIS2 final report (1 month)", - "deadlineKind_dsgvo": "GDPR notification (Art. 33, 72 h)", - "deadlineKind_reaction": "Internal reaction SLA", - "deadlineKind_resolution": "Internal resolution SLA", - "setReportability": "Set/review reporting obligation", - "applyReportability": "Apply", - "reportabilityHint": "Sets the reporting deadlines from the time of knowledge. NIS2 timers only if the tenant is in NIS2 scope.", - "advanceTo": "Advance to:", - "manualSubmitHint": "Submission to the authority is manual (template/export). This only tracks status and timers.", - "noReportObligation": "This incident currently has no reporting obligation.", - "dl_meldungHead": "Reporting deadlines", - "dl_slaHead": "Internal SLA (by severity)", - "dl_remaining": "in", - "dl_overdue": "overdue by", - "dl_submitted": "submitted", - "dl_none": "No deadlines set.", - "evidence": "Linked evidence", - "reviewHead": "Post-incident review & effectiveness", - "reviewHint": "The short report feeds the management review; document the effectiveness of the (CAPA) measures (§8).", - "measuresEffectiveness": "Effectiveness of measures", - "postIncidentReview": "Post-incident review (short report)", - "exportHead": "Export & evidence", - "exportReport": "Incident report (print/PDF)", - "exportNis2": "NIS2 notification template", - "exportDsgvo": "GDPR notification template", - "exportHint": "Templates are pre-filled; submission to the authority is manual.", - "exportRegisterCsv": "Register (CSV)", - "exportRegisterXlsx": "Register (XLSX)", - "newRiskFromIncident": "Create a new risk from the incident", - "riskTitlePlaceholder": "Risk title", - "likelihood": "Likelihood (L)", - "impact": "Impact (I)", - "createRisk": "Create & link risk", - "newMeasureFromIncident": "Create a measure directly from the incident", - "measureTitlePlaceholder": "Measure title", - "measureOwnerNone": "Owner (optional)", - "createMeasure": "Create & link measure", - "priorityLow": "low", - "priorityMedium": "medium", - "priorityHigh": "high", - "newEvidence": "Create evidence (reference/text)", - "evidenceTitlePlaceholder": "Evidence title", - "evidenceRefPlaceholder": "Reference/link (optional)", - "createEvidence": "Create & link evidence" - }, - "incidentCategory": { - "malware": "Malware", - "phishing": "Phishing / social engineering", - "unauthorized_access": "Unauthorized access", - "data_loss": "Data breach / loss", - "outage": "System outage / availability", - "physical": "Physical (access / theft)", - "misconfiguration": "Misoperation / configuration", - "supplier": "Supplier / third party", - "prototype_customer_data": "Prototype / customer data", - "other": "Other" - }, - "incidentStatus": { - "neu": "New", - "triage": "Triage", - "in_bearbeitung": "In progress", - "eingedaemmt": "Contained", - "behoben": "Resolved", - "abgeschlossen": "Closed", - "wiedereroeffnet": "Reopened" - }, - "incidentSeverity": { - "niedrig": "Low", - "mittel": "Medium", - "hoch": "High", - "kritisch": "Critical" - }, - "measures": { - "title": "Tasks & measures", - "sub": "Kanban board · measures from risks, audits and incidents", - "crumb": "Operations", - "newMeasure": "Measure", - "board": "Measures board", - "empty": "No measures.", - "detailHeading": "{ref} · {name}", - "detailSub": "Status, responsibility & linked risks", - "editTitle": "Edit measure", - "createTitle": "Create measure", - "titleField": "Title", - "description": "Description", - "status": "Status", - "priority": "Priority", - "owner": "Responsible", - "dueDate": "Due date", - "linkedRisks": "Linked risks", - "linkedRisksNote": "This measure reduces the following risks", - "noRisks": "No risks linked.", - "close": "Close", - "overdue": "overdue", - "dragHint": "Drag cards between columns to change status." - }, - "measureStatus": { - "OPEN": "Open", - "IN_PROGRESS": "In progress", - "DONE": "Done" - }, - "measurePriority": { - "LOW": "Low", - "MEDIUM": "Medium", - "HIGH": "High" - }, - "dependencies": { - "title": "Dependencies & critical paths", - "sub": "Process/asset chains · critical paths & single points of failure", - "crumb": "Core data", - "search": "Search …", - "criticalToggle": "Critical paths", - "onlyProcesses": "Processes only", - "fit": "Fit view", - "graphView": "Network graph", - "analysis": "Analysis", - "spofTitle": "Single points of failure", - "spofNone": "No SPOF detected.", - "spofHint": "{count} critical processes depend on it", - "critPathTitle": "Most critical path", - "critPathNone": "No critical path.", - "critProcesses": "Critical processes", - "critEdges": "Critical edges", - "legend": "Legend", - "legCritical": "Critical path", - "legStandard": "Standard dependency", - "legSpof": "Single point of failure", - "legCrit": "Critical (K≥3)", - "empty": "No processes/assets available for a graph yet.", - "openGraph": "Show in dependency graph" - }, - "suppliers": { - "title": "Suppliers & service providers", - "sub": "VDA-ISA 2027 ch. 6 · NIS2 supply chain (Art. 21(2)(d))", - "crumb": "Core data", - "new": "Supplier", - "newSupplier": "New supplier", - "ref": "ID", - "kpiTotal": "Suppliers", - "kpiNis2": "NIS2-relevant", - "kpiExpiring": "Expiring (90 d)", - "kpiReviews": "Reviews due", - "name": "Name", - "sector": "Sector", - "services": "Service / IT services", - "criticality": "Criticality", - "dataCategories": "Data categories (comma-separated)", - "protection": "Protection needs", - "nis2": "NIS2-relevant (supply chain)", - "status": "Status", - "contact": "Contact", - "nextReview": "Next review", - "notes": "Notes", - "empty": "No suppliers recorded.", - "detailSub": "Assessment, contracts, evidence & responsibility", - "createTitle": "Create supplier", - "editTitle": "Edit supplier", - "masterPill": "■ Master data", - "catalog": "VDA-ISA 2027 · ch. 6 Supplier Relationships", - "catalogNote": "Maturity per objective (target 3)", - "target": "Target", - "maturity": "Maturity", - "references": "References", - "objective": "Objective", - "must": "Must", - "should": "Should", - "high": "High protection", - "veryHigh": "Very high protection", - "sga": "Simplified Group Assessment", - "assessments": "Security assessments", - "addAssessment": "Add assessment", - "score": "Score", - "result": "Result", - "type": "Type", - "date": "Date", - "contracts": "Contracts", - "addContract": "Add contract", - "avDpa": "DPA (Art. 28)", - "securityClauses": "Security clauses", - "flowdown": "Flow-down (subcontractors)", - "customerTransparency": "Customer transparency", - "validFrom": "Valid from", - "validTo": "Valid to", - "reference": "Reference", - "ndas": "NDA / non-disclosure", - "addNda": "Add NDA", - "parties": "Parties", - "infoScope": "Information type", - "subject": "Subject", - "obligations": "Obligations", - "extensionStatus": "Extension", - "evidence": "Evidence & assurance", - "addEvidence": "Add evidence", - "kind": "Kind", - "protectsCia": "Covers (C/I/A)", - "adequacy": "Adequacy checked", - "expires": "expires", - "raci": "Responsibility (shared responsibility)", - "addRaci": "Add assignment", - "itService": "IT service", - "requirement": "Requirement", - "responsible": "Responsible", - "isaApplicability": "ISA applicability", - "localControls": "Local controls", - "subcontractors": "Subcontractors (4th party)", - "addSub": "Add subcontractor", - "flowdownObl": "Flow-down obligation", - "decision": "Risk-based management decision", - "addDecision": "Record decision", - "reasonNoAudit": "Reason (no audit/label)", - "decisionText": "Decision", - "decidedBy": "Decided by", - "recordRef": "Record ref", - "decisionNeeded": "No third-party audit/TISAX label with checked adequacy present — a documented risk-based management decision is required.", - "assets": "Affected assets", - "close": "Close", - "none": "—", - "add": "Add", - "risks": "Risks", - "isbApproval": "ISB maturity approval", - "isbValue": "ISB value", - "justification": "Justification (required on deviation)", - "approve": "Approve", - "approvalNote": "Deviation from the computed value is recorded with justification in the audit log.", - "customerReq": "Customer requirements passed", - "linkedAssets": "Linked assets", - "derivedLevel": "Derived level", - "conformity": "Conformity" - }, - "assessmentType": { - "QUESTIONNAIRE": "Questionnaire", - "SELF_ASSESSMENT": "Self-assessment", - "AUDIT": "Audit" - }, - "assessmentStatus": { - "SENT": "Sent", - "RECEIVED": "Received", - "EVALUATED": "Evaluated", - "OVERDUE": "Overdue" - }, - "evidenceKind": { - "CERTIFICATE": "Certificate", - "TISAX_LABEL": "TISAX label", - "ATTESTATION": "Attestation", - "AUDIT_REPORT": "Audit report", - "SELF_ASSESSMENT": "Self-assessment" - }, - "responsibleParty": { - "CLIENT": "Client", - "SUPPLIER": "Supplier", - "SHARED": "Shared" - }, - "supplierStatus": { - "ACTIVE": "Active", - "ONBOARDING": "Onboarding", - "UNDER_REVIEW": "Under review", - "OFFBOARDED": "Offboarded" - }, - "services": { - "tabSuppliers": "Suppliers", - "tabServices": "IT services", - "title": "IT services", - "newService": "IT service", - "ref": "ID", - "name": "Name", - "provider": "Provider (supplier)", - "internal": "Operated internally", - "criticality": "Criticality", - "protection": "Protection needs", - "raciCoverage": "RACI documented", - "empty": "No IT services recorded.", - "createTitle": "Create IT service", - "editTitle": "Edit IT service", - "detailSub": "Asset-like · responsibility (RACI) · risks", - "notes": "Notes", - "linkedAssets": "Linked assets", - "linkedProcesses": "Processes", - "risks": "Risks", - "noProvider": "no provider", - "raci": "Responsibility matrix (shared responsibility)", - "raciNote": "Applicability of ISA controls per service — fulfils 6.1.3", - "addControl": "Add control", - "control": "Control", - "controlTitle": "Title", - "applicable": "Applicable", - "responsibility": "Responsibility", - "evidence": "Evidence", - "raciEmpty": "No controls assigned yet.", - "close": "Close", - "none": "—", - "tabSoftware": "Software" - }, - "raciParty": { - "PROVIDER": "Provider", - "US": "Us", - "SHARED": "Shared" - }, - "policies": { - "crumb": "ISMS documentation", - "title": "Policies & Procedures", - "sub": "VDA-ISA 2027 — policy, policies, procedures and registers", - "library": "Library", - "coverage": "Coverage matrix", - "byDomain": "By domain", - "domainResponsible": "Responsible", - "domainUnassigned": "Unassigned", - "domainNone": "No domain", - "domainSet": "Assign domain", - "deriveDomains": "Derive domains", - "deriveDomainsDone": "{n} domains derived from the primary control.", - "deriveDomainsNone": "All documents already have a domain.", - "actions": "Actions", - "submitReview": "Submit for review", - "all": "All", - "code": "Code", - "docTitle": "Title", - "type": "Type", - "version": "Version", - "status": "Status", - "coverageCol": "Coverage", - "controlsN": "{n} controls", - "empty": "No documents found.", - "close": "Close", - "docInfo": "Document information", - "operationalizes": "Operationalizes policy", - "procedures": "Procedures", - "control": "ISA control", - "policy": "Policy", - "reqIds": "Requirement IDs", - "coverageHint": "{controls} controls · {reqs} requirements (MUST/SHOULD) across policies and operationalizing procedures.", - "kpiDocs": "Documents", - "kpiDocsTrend": "Policy · policies · procedures · registers", - "kpiControls": "Covered controls", - "kpiControlsTrend": "VDA-ISA 2027", - "kpiMust": "MUST requirements", - "kpiShould": "SHOULD requirements", - "openFullTable": "Open full table", - "backToLibrary": "Back to library", - "backToDoc": "Back to document", - "editableInline": "editable inline in the view", - "edit": "Edit", - "editTitle": "Edit document", - "editHint": "Changes are saved directly. The four-eyes approval workflow with versioning follows. Variable values apply centrally to all documents.", - "template": "Template (Markdown)", - "docVariables": "Document variables", - "docVariablesHint": "Only the variables used in this document. Changes apply across all documents (single source).", - "flagOn": "active (yes)", - "flagOff": "inactive (no)", - "preview": "Preview (read mode)", - "approval": "Approval", - "submitForApproval": "Submit for approval", - "submittedBy": "Submitted by", - "approve": "Approve (ISO)", - "reject": "Reject", - "rejectReason": "Reason for rejection", - "fourEyesSelf": "Four-eyes principle: approval must be done by someone other than the submitter.", - "fourEyesNoRight": "Approval requires the approver role (e.g. ISO).", - "approvedBy": "Approved by", - "resubmit": "Resubmit for approval", - "approvalNote": "Four-eyes: approver ≠ author. Versioning/diff to follow.", - "saveVariables": "Save variables", - "modeStandard": "Standard (variables)", - "modeExpert": "Expert mode", - "expertHint": "Full template editor: text, formatting, variables, deep links & references. New variables are created on save and can then be maintained in standard mode.", - "byControl": "by control", - "byDocument": "by document", - "assessmentExport": "Assessment export", - "requirements": "Requirement(s)", - "requirement": "Requirement", - "implementation": "Implementation", - "comingSoon": "Coming soon", - "kpiRequirements": "Requirements", - "protectionLevel": "Protection level / TISAX", - "effectiveLevel": "Effective", - "globalLevel": "Global", - "levelGlobal": "Inherit global", - "levelAl2": "MUST·SHOULD·HIGH", - "levelAl3": "+ VERY HIGH" - }, - "software": { - "title": "Software approvals", - "tabTitle": "Software", - "newSoftware": "Add software", - "ref": "Ref", - "name": "Software", - "provider": "Provider/Supplier", - "noProvider": "no provider", - "version": "Version/patch level", - "approvalStatus": "Approval status", - "approvedBy": "Approved by", - "criticality": "Criticality", - "protection": "Protection need", - "nextReview": "Next review", - "review": "Review", - "notes": "Notes", - "createTitle": "Add software", - "editTitle": "Edit software", - "detailSub": "Approved software (whitelist) with provider and review", - "masterPill": "Master data", - "linkedRisks": "Linked risks", - "empty": "No software recorded yet.", - "close": "Close", - "none": "—" - }, - "softwareStatus": { - "BEANTRAGT": "Requested", - "FREIGEGEBEN": "Approved", - "GESPERRT": "Blocked" - }, - "projects": { - "title": "Projects", - "newProject": "Add project", - "ref": "Ref", - "name": "Project name", - "owner": "Project lead", - "classification": "IS classification", - "status": "Status", - "isbInvolved": "ISB involved", - "criticality": "Criticality", - "protection": "Protection need", - "notes": "Notes", - "createTitle": "Add project", - "editTitle": "Edit project", - "detailSub": "Information security in projects (R01 / VA-19)", - "masterPill": "Master data", - "linkedRisks": "Linked risks", - "empty": "No projects recorded yet.", - "close": "Close", - "none": "—" - }, - "projectStatus": { - "GEPLANT": "Planned", - "LAUFEND": "Running", - "ABGESCHLOSSEN": "Completed", - "ABGEBROCHEN": "Cancelled" - }, - "onboarding": { - "crumb": "Setup", - "title": "Onboarding wizard", - "progress": "{done} of {total} steps validated · {percent}%", - "stepTitle": { - "context": "Context & facts", - "scope": "Scope", - "policy": "Policy & guidelines", - "roles": "Team & roles", - "criteria": "Criteria & scale", - "processes": "Processes", - "information": "Information", - "assets": "Assets", - "protection": "Protection needs", - "risks": "Risks", - "controls": "Controls", - "gap": "GAP analysis", - "readiness": "Audit readiness" - }, - "status": { - "offen": "Open", - "in_bearbeitung": "In progress", - "zur_validierung": "For validation", - "validiert": "Validated", - "zurueckgewiesen": "Rejected" - }, - "actions": { - "start": "Start", - "submit": "Submit for validation", - "validate": "Validate", - "reset": "Reset", - "back": "Back", - "next": "Next", - "rework": "Rework", - "reject": "Reject" - }, - "placeholderNote": "This step will be filled with content in a later story. Navigation, status and gating are already active.", - "locked": "Locked – validate previous steps first.", - "gateHint": "This step isn't approved yet — you can still continue; approval can happen in parallel.", - "allDone": "All steps completed", - "rejectCommentPlaceholder": "Reason for rejection (optional)", - "rejectedTitle": "Rejected – please rework", - "rejectedNoComment": "No reason provided.", - "awaitingValidation": "Awaiting validation by an authorized role." - }, - "auditReadiness": { - "crumb": "Prepare audit", - "title": "Audit wizard", - "progress": "{done} of {total} steps validated · {percent}%", - "stepTitle": { - "internal_audit": "Internal audit", - "audit_gap": "GAP consolidation", - "audit_evidence": "Evidence check", - "audit_readiness": "Readiness & management review" - }, - "status": { - "offen": "Open", - "in_bearbeitung": "In progress", - "zur_validierung": "For validation", - "validiert": "Validated", - "zurueckgewiesen": "Rejected" - }, - "actions": { - "start": "Start", - "submit": "Submit for validation", - "validate": "Validate", - "reset": "Reset", - "back": "Back", - "next": "Next", - "rework": "Rework", - "reject": "Reject" - }, - "gateHint": "This step isn't approved yet — you can still continue; approval can happen in parallel.", - "allDone": "All steps completed", - "rejectCommentPlaceholder": "Reason for rejection (optional)", - "rejectedTitle": "Rejected – please rework", - "rejectedNoComment": "No reason provided.", - "awaitingValidation": "Awaiting validation by an authorized role." - }, - "processHouse": { - "title": "Process house", - "intro": "Activate the relevant processes (toggle) and work through the guided BIA popup per tile. The tile colour reflects the BIA status.", - "newProcess": "New process", - "toModule": "To process module", - "kpiTotal": "Processes", - "kpiInScope": "in scope (active)", - "kpiDone": "BIA complete", - "legend": "Legend", - "empty": "No processes yet. Create your own or adopt from the standard catalog.", - "laneEmpty": "No processes in this lane.", - "unassigned": "unassigned", - "deputy": "Deputy", - "openBia": "Open BIA", - "details": "Details", - "activate": "Activate", - "deactivate": "Deactivate", - "subProcesses": "{count} sub-process(es)", - "dotInfo": "Info", - "dotCarrier": "Carrier", - "dotCia": "C/I/A", - "dotRisk": "Risks", - "catalogTitle": "Adopt from standard catalog", - "catalogHint": "Curated core, management and support processes. “Adopt” creates the process in the register (mapped via catalog code).", - "adopt": "Adopt", - "adopted": "adopted", - "inclSub": "incl. {count} sub-processes", - "delete": "Delete", - "deleteConfirm": "Really remove this process? Its BIA entry and asset links are deleted, sub-processes are moved to the top level and risk links are detached.", - "deleteConfirmBtn": "Delete permanently", - "detailSub": "Business overview & BIA (read-only)", - "children": "Sub-processes", - "noChildren": "none", - "status": { - "offen": "open", - "teilweise": "partial", - "komplett": "complete" - } - }, - "bia": { - "heading": "BIA · {name}", - "stepOf": "Step {n} of {total}", - "status": { - "offen": "BIA open", - "teilweise": "BIA partial", - "komplett": "BIA complete" - }, - "back": "Back", - "next": "Next", - "open": "open", - "captured": "captured", - "s1Short": "Information value", - "s2Short": "Carriers", - "s3Short": "Protection", - "s4Short": "Risks", - "s5Short": "Summary", - "s1Title": "Capture the information value", - "s1Hint": "An information value is a primary asset (information/data). Use a catalog suggestion, the dedup search, or the full asset mask.", - "catalogLabels": "Catalog suggestion (classification)", - "currentPrimaries": "Captured information values", - "noPrimaries": "No information value captured yet.", - "quickAdd": "Quick capture (with dedup + autocomplete)", - "manualToggle": "Capture manually with the full asset inventory mask", - "manualHint": "Creates a primary asset (type Information) and links it to this process.", - "s2Title": "Secondary assets / carriers", - "s2Hint": "Carriers (systems, applications, locations, suppliers …) that hold the information values.", - "suggestedCarriers": "Carrier suggestions (types)", - "currentCarriers": "Assigned carriers", - "noCarriers": "No carriers assigned yet.", - "assignCarrier": "Assign carrier", - "noAvailable": "No further assets available — create one in the asset module.", - "newCarrier": "Create new carrier asset", - "newCarrierHint": "Creates a new carrier asset via the full asset inventory mask and links it as a carrier (secondary) to this process.", - "s3Title": "Protection needs C/I/A", - "s3Hint": "Protection needs sit on the primary information value. Carriers inherit by the maximum principle.", - "noPrimaryForCia": "First capture an information value in step 1.", - "inheritedMax": "Inherited maximum (carriers)", - "inheritedHint": "Carriers should meet at least this maximum of the primary values they carry.", - "s4Title": "Risks per process", - "s4Hint": "Adopt matching catalog risks and rate them in the same step (likelihood × impact = score).", - "suggestedRisks": "Recommended risks (catalog)", - "adopt": "Adopt", - "adopted": "adopted", - "currentRisks": "Risk rating", - "noRisks": "No risks linked to this process yet.", - "likelihood": "Likelihood (1–5)", - "impact": "Impact (1–5)", - "treatment": "Treatment", - "statusField": "Status", - "rate": "Rate", - "openInRiskModule": "Open in risk module", - "linkRisk": "Link risk", - "newRisk": "Create new risk", - "riskTitle": "Title", - "riskDescription": "Description", - "s5Title": "Summary", - "s5Hint": "Full review of all captured values. On completion the BIA status is set (process-house colour).", - "clInfo": "Information value", - "clCarrier": "Carriers", - "clCia": "Protection", - "clRisk": "Risks", - "reviewInfo": "Information values & protection", - "reviewCarriers": "Carriers", - "reviewRisks": "Risks", - "finishTitle": "Complete BIA", - "finishHint": "{done} of {total} areas captured.", - "markComplete": "Mark as complete", - "markPartial": "Mark as partial", - "criticality": "Criticality" - }, - "admin": { - "backToOverview": "Back to overview", - "crumb": "Tenant", - "sub": "Slug {slug}{sector} · TISAX {level}", - "statusActive": "Active", - "statusSuspended": "Suspended", - "statusArchived": "Archived", - "masterDataTitle": "Master data", - "masterDataHint": "Single source of the ISMS variables (tenant settings).", - "orgName": "Company name", - "orgShort": "Short name", - "slug": "Slug", - "address": "Address", - "sector": "Sector", - "duns": "D-U-N-S", - "ismsScope": "ISMS scope", - "tisaxLevel": "TISAX level", - "status": "Status", - "notSet": "—", - "mainContactTitle": "Main contact", - "mainContactHint": "Derived from the tenant administrator(s).", - "mainContactNone": "No active tenant administrator on record.", - "manageTitle": "Management", - "manageHint": "Manage this tenant's modules and users in a popup.", - "manageModules": "Manage modules", - "manageUsers": "Manage users", - "usersCount": "{count} users", - "modulesTitle": "Modules", - "modulesHint": "Disabled modules are hidden from the customer and blocked server-side.", - "moduleActive": "Active", - "moduleInactive": "Inactive", - "moduleActivate": "Activate", - "moduleDeactivate": "Deactivate", - "importTemplates": "Import templates", - "importTemplatesTitle": "Import/update the template package non-destructively", - "modulesModalSub": "Enable/disable modules for {name}", - "usersModalSub": "Users of {name} — create, roles, deactivate, reset password", - "lifecycleTitle": "Lifecycle", - "lifecycleActivate": "Activate", - "lifecycleSuspend": "Suspend (login blocked)", - "lifecycleArchive": "Archive", - "lifecycleNote": "Deletion/data export (GDPR) and retention follow in phase 2.", - "assessmentTitle": "Assessment level (protection needs)", - "assessmentHint": "Single source of the protection needs — drives the policy module's protection flags, the coverage filter and the onboarding wizard (read-only there). Currently: {level}.", - "assessmentAl2": "AL2 — MUST · SHOULD · HIGH", - "assessmentAl3": "AL3 — additionally VERY HIGH", - "mfaTitle": "MFA requirement", - "mfaHint": "When enabled, every user of this tenant must set up two-factor authentication at their next login. Currently: {state}.", - "mfaStateOn": "on", - "mfaStateOff": "off", - "mfaActivate": "Enable MFA requirement", - "mfaDeactivate": "Disable MFA requirement", - "policyLangTitle": "Policy language", - "policyLangHint": "Determines the language in which the template package is imported/updated. Applies to future imports; already imported policies stay unchanged until the tenant adopts them under package updates. Currently: {lang}.", - "policyLangDe": "German", - "policyLangEn": "English", - "auditTitle": "Audit trail", - "auditHint": "Traceable activity of this tenant — who changed what and when.", - "auditView": "View audit trail", - "auditSub": "Activity of {name} (newest first, last 200)", - "userCreate": "Create user", - "userCreateSub": "New user for {name}", - "userEdit": "Edit user — {name}", - "close": "Close", - "frameworksTitle": "Standards / frameworks", - "frameworksHint": "Active: {list}. Controls the requirement view, SoA and evaluation. At least one standard must remain active.", - "frameworksTisax": "TISAX / VDA ISA", - "frameworksIso": "ISO/IEC 27001", - "frameworksActivate": "Activate", - "frameworksDeactivate": "Deactivate", - "frameworksActive": "Active", - "frameworksNote": "Activating imports the standard's template package. Deactivating keeps the assessments and only puts them dormant." - } -} diff --git a/messages/en/admin.json b/messages/en/admin.json new file mode 100644 index 0000000..1afcadf --- /dev/null +++ b/messages/en/admin.json @@ -0,0 +1,58 @@ +{ + "backToOverview": "Back to overview", + "crumb": "Tenant", + "sub": "Slug {slug}{sector}", + "statusActive": "Active", + "statusSuspended": "Suspended", + "statusArchived": "Archived", + "masterDataTitle": "Master data", + "masterDataHint": "Company data from the tenant settings.", + "orgName": "Company name", + "orgShort": "Short name", + "slug": "Slug", + "address": "Address", + "sector": "Sector", + "status": "Status", + "notSet": "—", + "mainContactTitle": "Main contact", + "mainContactHint": "Derived from the tenant administrator(s).", + "mainContactNone": "No active tenant administrator on record.", + "manageTitle": "Management", + "manageHint": "Manage this tenant's modules and users in a popup.", + "manageModules": "Manage modules", + "manageUsers": "Manage users", + "usersCount": "{count} users", + "modulesTitle": "Modules", + "modulesHint": "Disabled modules are hidden from the customer and blocked server-side.", + "moduleActive": "Active", + "moduleInactive": "Inactive", + "moduleActivate": "Activate", + "moduleDeactivate": "Deactivate", + "modulesModalSub": "Enable/disable modules for {name}", + "usersModalSub": "Users of {name} — create, roles, deactivate, reset password", + "lifecycleTitle": "Lifecycle", + "lifecycleActivate": "Activate", + "lifecycleSuspend": "Suspend (login blocked)", + "lifecycleArchive": "Archive", + "lifecycleNote": "Suspended tenants cannot sign in; archiving hides them.", + "mfaTitle": "MFA requirement", + "mfaHint": "When enabled, every user of this tenant must set up two-factor authentication at their next login. Currently: {state}.", + "mfaStateOn": "on", + "mfaStateOff": "off", + "mfaActivate": "Enable MFA requirement", + "mfaDeactivate": "Disable MFA requirement", + "auditTitle": "Audit trail", + "auditHint": "Traceable activity of this tenant — who changed what and when.", + "auditView": "View audit trail", + "auditSub": "Activity of {name} (newest first, last 200)", + "userCreate": "Create user", + "userCreateSub": "New user for {name}", + "userEdit": "Edit user — {name}", + "close": "Close", + "phone": "Phone", + "email": "E-mail", + "localeTitle": "Tenant language", + "localeHint": "Default language for notifications and documents of this tenant (users choose their own UI language). Currently: {lang}.", + "localeDe": "German", + "localeEn": "English" +} diff --git a/messages/en/common.json b/messages/en/common.json new file mode 100644 index 0000000..586e773 --- /dev/null +++ b/messages/en/common.json @@ -0,0 +1,23 @@ +{ + "appName": "Craftvia", + "appTagline": "Trades. Digitally on course.", + "language": "Language", + "logout": "Sign out", + "create": "Create", + "save": "Save", + "cancel": "Cancel", + "edit": "Edit", + "delete": "Delete", + "back": "Back", + "close": "Close", + "search": "Search…", + "actions": "Actions", + "add": "Add", + "remove": "Remove", + "none": "—", + "comingSoon": "Coming soon", + "confirmDelete": "Really delete?", + "yes": "Yes", + "no": "No", + "readOnly": "Read-only access." +} diff --git a/messages/en/dashboard.json b/messages/en/dashboard.json new file mode 100644 index 0000000..01f1e6c --- /dev/null +++ b/messages/en/dashboard.json @@ -0,0 +1,8 @@ +{ + "title": "Dashboard", + "crumb": "Overview", + "subtitle": "Welcome, {name} — {tenant}", + "placeholderTitle": "Dashboard under construction", + "placeholder": "Open work orders, today's jobs, reports awaiting approval and emergency calls will appear here.", + "moduleDisabled": "The requested module is not enabled for your company." +} diff --git a/messages/en/login.json b/messages/en/login.json new file mode 100644 index 0000000..fda6730 --- /dev/null +++ b/messages/en/login.json @@ -0,0 +1,11 @@ +{ + "title": "Sign in", + "tagline": "Trades. Digitally on course.", + "subtitle": "Sign in with your company account.", + "email": "E-mail address", + "password": "Password", + "mfaOptional": "MFA code (if enabled)", + "submit": "Sign in", + "forgotPassword": "Forgot password?", + "error": "Sign-in failed. Please check e-mail and password." +} diff --git a/messages/en/modules.json b/messages/en/modules.json new file mode 100644 index 0000000..02e47ae --- /dev/null +++ b/messages/en/modules.json @@ -0,0 +1,18 @@ +{ + "customers": "Customers", + "sites": "Sites", + "teams": "Teams", + "workOrders": "Work orders", + "imports": "Order import", + "field": "Field jobs", + "reports": "Reports", + "emergency": "Emergency service", + "documents": "Documents", + "notifications": "Notifications", + "lotse": "Lotse (AI assistant)", + "placeholder": { + "crumb": "Module", + "status": "Module under construction", + "hint": "This area is currently being built. Navigation, module activation and permissions are already in place." + } +} diff --git a/messages/en/nav.json b/messages/en/nav.json new file mode 100644 index 0000000..8a208a6 --- /dev/null +++ b/messages/en/nav.json @@ -0,0 +1,12 @@ +{ + "dashboard": "Dashboard", + "workOrders": "Work orders", + "imports": "Import", + "customers": "Customers", + "sites": "Sites", + "teams": "Teams", + "reports": "Reports", + "documents": "Documents", + "settings": "Settings", + "admin": "Admin console" +} diff --git a/next.config.ts b/next.config.ts index 4bcc68b..5be4174 100644 --- a/next.config.ts +++ b/next.config.ts @@ -5,28 +5,26 @@ import createNextIntlPlugin from "next-intl/plugin"; // zum Dev-Server. Diese Lockerungen gelten NUR in der Entwicklung, nie im Build. const isDev = process.env.NODE_ENV !== "production"; -// Content-Security-Policy (F-07) — zweite Verteidigungslinie hinter dem -// HTML-Sanitizing (F-03). +// Content-Security-Policy (F-07). // -// Hinweis Skripte: 'unsafe-inline' ist ein bewusster Zwischenstand. Next.js -// liefert seinen Hydration-Bootstrap als Inline-Skript aus; eine Nonce-basierte -// CSP (Nonce in proxy.ts erzeugen und an