Authentifizierung
Personen und technische Aufrufer eindeutig zuordnen. Zugang und aktuelle Sitzung müssen den vereinbarten Regeln entsprechen.
Wie wird das geprüft?
Berechtigten und abgewiesenen Login einschließlich gesperrtem Zugang testen.

Erfahren Sie, wie Zugriff, Daten, Betrieb und Prüfprozesse getrennt und dokumentiert werden.
Ein Loyalty-Programm verarbeitet Profile, Kaufnachweise und wertrelevante Vorgänge. Ein belastbares Schutzmodell verbindet dafür Identität, Datenbereich, Aktion und Betrieb.
Maßnahme · Geltungsbereich · Nachweis
Eine gültige Anmeldung ist die Voraussetzung. Der zulässige Datenbereich und die erlaubte Aktion werden danach separat geprüft.
Für passende Adminzugänge kann Microsoft Entra ID mit Conditional Access und rollen- oder risikobasierter MFA vereinbart werden. SSO über SAML 2.0 oder OIDC verbindet den Benutzerzugang; bestätigte SCIM-Prozesse können die Provisionierung ergänzen. Technische Integrationen benötigen ihre eigenen OAuth-Scopes und keine pauschalen Administratorrechte.
Eine Rolle erhält die für ihre Aufgabe erforderlichen Rechte. Lesen, Exportieren, Beantragen, Genehmigen und Ausführen werden bewusst getrennt. Zeitlich begrenzte Unterstützung und der Entzug ausgeschiedener Benutzer gehören zum Lebenszyklus des Zugangs.
Ein Konto aus Mandant A darf nicht auf die Daten von Mandant B zugreifen, auch wenn eine bekannte Referenz in einem direkten Aufruf verwendet wird. Die Prüfung umfasst Suche, Detailansicht, Export und kritische Aktionen. Ein ausgeblendeter Menüpunkt allein belegt keine wirksame Trennung.

| Beispielrolle | Zulässiger Bereich | Kontrollpunkt |
|---|---|---|
| Administration | Bestätigte Konfiguration innerhalb der zugeordneten Mandanten und Programme. | Kritische Änderungen mit eigener Freigabe und nachvollziehbarem Akteur. |
| Support | Relevante Mitglieds- und Falldaten des zugewiesenen Bereichs. | Keine automatische Auszahlung oder unbeschränkte Kontokorrektur. |
| Partner | Eigene Angebote, freigegebene Fälle oder definierte Partnerdaten. | Keine Einsicht in fremde Partner- oder Teilnehmerbestände. |
| Integration | Benannte Datenobjekte und Aktionen über bestätigte Systemzugänge. | Scopes, Mandantenbezug und Entzug des technischen Zugangs testen. |
Die Matrix ist ein Konfigurationsbeispiel. Die konkrete Rechtevergabe wird mit den zuständigen Verantwortlichen vereinbart.
Zweck, Rollen, erforderliche Daten und erlaubte Verarbeitung bestimmen.
Teilnahme und freiwillige Kommunikationswahl verständlich trennen. Datenumfang auf den Zweck begrenzen.
Zugriff, Verschlüsselung und Secret-Verwaltung am konkreten Datenfluss umsetzen.
Export und Betroffenenprozesse mit Identitätsprüfung, Berechtigung und nachvollziehbarer Übergabe verbinden.
Aufbewahrung, Löschung oder notwendige Pseudonymisierung nach einem abgestimmten Konzept durchführen.
Ein fachlich passendes Angebot ersetzt keine erforderliche Kontakterlaubnis. Der zuständige Prozess hält die aktuelle Wahl fest und berücksichtigt Abmeldung oder Sperren auch bei angebundenen Sendesystemen. Version, Zweck und Nachweis werden passend zum konkreten Einwilligungsprozess dokumentiert.
Neben Primärdaten werden Backups, Dateien, Logs und Replikate betrachtet. Subprozessoren und Supportzugriffe erhalten einen dokumentierten Bereich. Eine allgemeine Länderangabe für das Hosting beantwortet diese Fragen noch nicht.
Die beteiligten Rollen und eine gegebenenfalls erforderliche AVV werden vor dem Betrieb abgestimmt. Export, Auskunft und Löschweg müssen zu den führenden Systemen passen. Technische Unterstützung für solche Prozesse ist von einer pauschalen Aussage zur Rechtmäßigkeit jedes Programms zu unterscheiden.
Personen und technische Aufrufer eindeutig zuordnen. Zugang und aktuelle Sitzung müssen den vereinbarten Regeln entsprechen.
Berechtigten und abgewiesenen Login einschließlich gesperrtem Zugang testen.
Zusätzliche Faktoren für definierte Rollen oder Risiken einsetzen. Einrichtung und Wiederherstellung erhalten einen geregelten Weg.
Geforderte zweite Prüfung und unzulässigen Zugriff ohne sie nachstellen.
Den bestätigten Identitätsanbieter mit der Anwendung verbinden. Anmelden, Abmelden und Entzug des Zugangs gehören zusammen.
SAML-/OIDC-Konfiguration und Verhalten eines entzogenen Kontos prüfen.
Transport, gespeicherte Daten und Schlüsselzugriffe getrennt spezifizieren. TLS 1.2+ und AES-256 sind zu bestätigende Vorgaben.
Konfiguration, Schlüsselzugriff und Rotation anhand freigegebener Nachweise prüfen.
Änderungen und kritische Zugriffe mit Akteur, Zeitpunkt, Grund und Referenz nachvollziehbar machen.
Eine freigegebene Korrektur bis zum ursprünglichen Geschäftsvorfall verfolgen.
Datenumfang, Aufbewahrung und verschlüsselte Sicherungskopien festlegen.
Eine Stichprobe tatsächlich wiederherstellen und Vollständigkeit vergleichen.
Wiederanlaufreihenfolge, Verantwortliche und Datenabgleich auf das Ausfallszenario ausrichten.
Dokumentierte Übung mit gemessener Dauer und fachlichem Abgleich bewerten.
Relevante Nutzungspfade, Fehler und Rückstände überwachen. Alarme führen zu einer benannten zuständigen Stelle.
Testalarm auslösen und Routing, Einordnung und Rückmeldung nachvollziehen.
Ein Schutzkonzept braucht einen gepflegten Betrieb: Sicherheitsbefunde werden eingeordnet, Maßnahmen zugeordnet und die Wirksamkeit der Wiederherstellung überprüft.
Monitoring, Alerts und Incident-Prozess werden für den vereinbarten Umfang beschrieben. Eine mögliche 24/7-Überwachung ist von personeller Bereitschaft zu unterscheiden. Ein eigener SOC oder eine bestimmte Reaktionszeit wird nur mit tatsächlich bestätigter Leistung zugesagt.
Verantwortliche, Priorisierung und Änderungsweg werden pro betroffener Komponente festgelegt. Eine durchgeführte Änderung erhält einen nachvollziehbaren Stand. Fachliche Auswirkungen und erforderliche Tests werden mit dem Betrieb abgestimmt.
Regeln, Budgets und wertrelevante Korrekturen können eigene Freigaben benötigen. Antrag, Prüfung und Genehmigung bleiben getrennt. Die Historie zeigt den Grund des Eingriffs und verweist auf den ursprünglichen Vorgang.
Der Kommunikationsweg nennt zuständige Ansprechpartner, bestätigte Auswirkungen und nächsten Informationsschritt. Ein vermuteter Zustand bleibt als vorläufig erkennbar. Vertragliche und weitere erforderliche Meldewege werden passend zum konkreten Betrieb geregelt.

Für eine Prüfung zählt nicht nur der Dokumenttitel. Benötigt werden der aktuelle Stand, die verantwortliche Stelle und der konkrete Geltungsbereich.
| Unterlage | Benötigter Nachweis | Zugangsweg |
|---|---|---|
| Technische und organisatorische Maßnahmen | Version, Datum und betroffene Verarbeitung | Projektbezogen anfragen und prüfen |
| AVV / Subprozessoren / Regionen | Rollen, Dienstleister und Datenarten einschließlich Kopien | Projektbezogen abstimmen |
| Security-Kontakt / Incident-Verfahren | Meldeweg, Zuständigkeit und vertraglicher Umfang | Im Betriebspaket bestätigen |
| Penetrationstest-Zusammenfassung | Zeitpunkt, geprüfter Bereich und Behandlung relevanter Befunde | Verfügbarkeit und freigegebenen Umfang anfragen |
| Zertifikat / Auditumfang | Gültigkeit, Organisation und tatsächlicher Scope | Nur nach konkretem Nachweis verwenden |
| Wiederherstellungsbericht | Szenario, Datum, Ergebnis und offene Maßnahmen | Für den vereinbarten Betrieb prüfen |
Ein Organisationszertifikat bezieht sich auf den darin benannten Geltungsbereich. Eine Zertifizierung von Azure geht nicht automatisch auf ProLoyalty oder ein individuelles Kundenprogramm über. ISO-27001-Aussagen werden nur anhand gültigem Zertifikat und passendem Scope veröffentlicht. Ebenso benötigt eine Zero-Trust- oder Compliance-Aussage einen konkret belegten Umfang.

Besprechen wir Ihre Zielgruppe, Ihre Datenquellen und den Ablauf, den Sie verbessern möchten. Daraus entsteht eine Demo, die zu Ihrem Programm passt.
Ein normaler Vorgang. Ein Sonderfall. Die beteiligten Systeme. Wir zeigen, wie Regeln, Kanäle und Kontrolle zusammenspielen.