Berechtigungskonzept Immobilien CRM: Matrix und Prüfprotokoll

Was gehört in ein Berechtigungskonzept Immobilien CRM?

Ein Berechtigungskonzept für ein Immobilien-CRM besteht aus drei Teilen: einer Matrix, die Rollen, Datenobjekte und Aktionen kreuzt, einem Prüfprotokoll, das jede Zelle vor der Freischaltung testet, und einer Änderungsregel, die festhält, wer Rechte beantragt, umsetzt und abnimmt. Fehlt einer der drei Teile, bleibt das Konzept eine Absichtserklärung.

Die Matrix beschreibt das Soll. Sie wird fachlich geschrieben, nicht technisch: nicht „Rolle X hat Recht contacts.read“, sondern „Berater lesen Kontakte, die ihnen als Betreuer zugeordnet sind“. Diese Formulierung lässt sich gegen jede Software prüfen, unabhängig davon, wie ein Anbieter seine Rechte intern benennt. Die technische Übersetzung gehört in eine zweite Spalte, die die Administration pflegt.

Das Prüfprotokoll beschreibt das Ist. Es dokumentiert, dass ein Testzugang eine erlaubte Aktion ausführen konnte und eine gesperrte nicht. Art. 32 Abs. 1 lit. d DSGVO verlangt ein Verfahren zur regelmäßigen Überprüfung, Bewertung und Evaluierung der Wirksamkeit technischer und organisatorischer Maßnahmen. Das Protokoll ist eine prüfbare Form, diese Überprüfung für Zugriffsrechte festzuhalten; ob es im Einzelfall genügt, klären Sie mit Ihrer Datenschutzberatung.

• Matrix: Rolle × Datenobjekt × Aktion, fachlich formuliert
• Reichweite je Zelle: eigene Datensätze, Team, freigegebene Projekte oder alle
• Prüfprotokoll: je Zelle ein positiver oder negativer Testfall mit Ergebnis, Datum und prüfender Person
• Änderungsregel: Antrag, Freigabe, Umsetzung, Nachtest
• Versionsstand: Datum und verantwortliche Person jeder Matrixfassung

Vier Rollen, fünf Datenobjekte, drei Aktionen

Für die Vorlage empfiehlt sich ein bewusst schmaler Zuschnitt. Vier Rollen bilden die Grundkonstellation im Projektvertrieb ab: fest eingebundene Berater, Teamleitungen mit Verantwortung für mehrere Berater, externe Vertriebspartner mit eigener Organisation und die Administration, die das System pflegt. Weitere Rollen wie Buchhaltung oder Käuferbetreuung ergänzen Sie nach demselben Muster als zusätzliche Spalte.

Die fünf Datenobjekte sind eigene Kontakte, fremde Kontakte, Projekte mit Einheiten, Finanzierungsunterlagen und Provisionen. Die Trennung zwischen eigenen und fremden Kontakten ist der Kern der Vorlage. „Eigen“ heißt: Der Kontakt ist dem Nutzer als Betreuer zugeordnet. „Fremd“ ist alles andere, also Kontakte von Kollegen, anderen Teams oder anderen Partnerunternehmen.

Die drei Aktionen sind Lesen, Ändern und Exportieren. Löschen fehlt absichtlich: Es empfiehlt sich, Löschungen aus den Vertriebsrollen herauszunehmen und über das Löschkonzept zu steuern, damit Aufbewahrungspflichten nicht durch einen Klick im Tagesgeschäft unterlaufen werden. Anlegen fällt in der Vorlage unter Ändern, weil beide Aktionen dieselbe Frage aufwerfen: Darf diese Rolle den Datenbestand verändern?

• Berater: arbeitet an zugeordneten Kontakten und sieht freigegebene Projekte
• Teamleitung: sieht und verteilt Kontakte des eigenen Teams, wertet Provisionen des Teams aus
• Externer Vertriebspartner: wie Berater, aber strikt auf die eigene Organisation und freigegebene Projekte begrenzt
• Administration: pflegt Projekte, Nutzer und Rollen, arbeitet nicht in Kundendaten

In der Software

Jeder Vorgang steht an seiner Stufe

Board, Tabelle und Zeitstrahl zeigen dieselben Deals — wer wo hängt, sieht man ohne Rückfrage.

Deal-Pipeline

Wie sieht eine kopierbare CRM Berechtigungsmatrix aus?

Eine kopierbare CRM Berechtigungsmatrix führt die Datenobjekte als Zeilen und die Rollen als Spalten. Jede Zelle nennt die erlaubten Aktionen als Kürzel mit Reichweite, etwa „L, Ä (eigene Kunden)“. Ein Strich bedeutet gesperrt. So passt die gesamte Soll-Regel auf eine Seite und lässt sich Zelle für Zelle testen.

Die folgende Tabelle ist ein Vorschlag, kein Standard. Sie folgt einer restriktiven Grundhaltung: Jede Rolle erhält nur, was sie für ihre Aufgabe braucht. Das entspricht dem Gedanken aus Art. 25 Abs. 2 Satz 2 DSGVO, wonach datenschutzfreundliche Voreinstellungen unter anderem die Zugänglichkeit personenbezogener Daten auf das Erforderliche begrenzen. Wo Ihr Vertrieb anders arbeitet, ändern Sie die Zelle und halten die Begründung fest.

Lesen Sie die Kürzel so: L steht für Lesen, Ä für Ändern einschließlich Anlegen, E für Exportieren einschließlich Download, Druck und Massenversand. Der Zusatz in Klammern beschreibt die Reichweite. Bei vier Rollen, fünf Datenobjekten und drei Aktionen enthält die Matrix 60 Einzelrechte, von denen in dieser Fassung 24 erlaubt und 36 gesperrt sind.

Eigene und fremde Kontakte: wo die Grenze technisch verläuft

Die Zeile „fremde Kontakte“ verlangt besondere Sorgfalt. Ein Hinweis auf eine bestehende Betreuung kann Doppelansprachen vermeiden, offenbart aber bereits Informationen über einen Interessenten. In dieser Vorlage erscheint deshalb höchstens „Bitte Zuordnung durch den Innendienst prüfen“, ohne fremdes Team, Kontaktdetails oder Gesprächsnotizen zu nennen. Prüfen Sie, ob selbst dieser Hinweis im konkreten Zweck erforderlich und zulässig ist; andernfalls bleibt auch die Existenz des Datensatzes verborgen.

Die Teamleitung braucht fremde Kontakte in engerer Form. In der Vorlage darf sie Kontakte des eigenen Teams lesen und ändern, damit sie Urlaubsvertretungen und Umverteilungen steuern kann. Kontakte anderer Teams bleiben gesperrt. Exportieren darf sie fremde Kontakte nicht, auch nicht aus dem eigenen Team; wer einen Teamexport braucht, beantragt ihn als Einzelfall über die Änderungsregel.

Bei externen Vertriebspartnern kommt eine zweite Grenze hinzu: die Organisation. Ein Partnerunternehmen mit mehreren Mitarbeitern sieht nur Kontakte, die ihm zugeordnet sind, nicht die Kontakte anderer Partner, die im selben Projekt verkaufen. Vertragliche Zuständigkeiten und die datenschutzrechtlich zulässigen Zwecke bestimmen gemeinsam, welcher Zugriff erforderlich ist. Ein Vertriebspartnervertrag allein ersetzt keine Rechtsgrundlage für die Verarbeitung.

Warum ist Exportieren eine eigene Berechtigung?

Exportieren ist eine eigene Berechtigung, weil Daten nach dem Export die Kontrolle des CRM verlassen. Leserechte lassen sich entziehen, ein heruntergeladener Datenbestand nicht. Wer lesen darf, darf deshalb nicht automatisch exportieren; beides wird in der Matrix getrennt vergeben und getrennt getestet. Eine Exportsperre begrenzt die vom System angebotenen Ausgabewege. Sie verhindert jedoch nicht zuverlässig, dass lesbare Inhalte abgeschrieben oder per Bildschirmaufnahme kopiert werden. Diese Grenze gehört ausdrücklich in die Abnahme.

Im Immobilienvertrieb ist das Risiko greifbar: Scheidet ein Berater oder ein Vertriebspartner aus, ist der Kundenstamm das Wertvollste, was er mitnehmen könnte. Die Vorlage vergibt Exportrechte deshalb nur an Teamleitung und Administration, jeweils für einen begrenzten Ausschnitt. Art. 5 Abs. 1 lit. f DSGVO verlangt eine Verarbeitung mit angemessener Sicherheit einschließlich Schutz vor unbefugter Verarbeitung; eine enge Exportregel ist ein prüfbarer Baustein dafür.

Entscheidend ist, was alles als Export zählt. Neben der offensichtlichen Exportfunktion bieten viele Systeme weitere Wege, Daten herauszuziehen. Die Matrix sollte diese Wege ausdrücklich unter E zusammenfassen, damit niemand argumentieren kann, ein PDF-Druck oder ein Massenversand sei kein Export.

• CSV- oder Excel-Download aus Listen und Berichten
• PDF-Druck von Kontaktdetails oder Kundenakten
• Massen-E-Mail an Listen mit sichtbaren Adressen
• Synchronisation in private Adressbücher oder Kalender
• API-Schlüssel und Integrationen, die ein Nutzer selbst anlegen kann
• Download von Dokumentenpaketen oder ganzen Ordnern

Finanzierungsunterlagen und Provisionen: die sensibelsten Zellen

Finanzierungsunterlagen enthalten Einkommensnachweise, Kontoauszüge und Selbstauskünfte. In der Vorlage dürfen Berater und Partner diese Unterlagen für eigene Kunden lesen und hochladen, aber nicht exportieren. Die Weitergabe an Finanzierungspartner läuft über einen dokumentierten Übergabeweg, etwa einen freigegebenen Datenraum, nicht über den Download auf ein privates Gerät.

Die Teamleitung liest Finanzierungsunterlagen ihres Teams, um die Vollständigkeit zu prüfen, ändert sie aber nicht. Die Administration hat in der Vorlage keinen Zugriff auf Inhalte, obwohl sie technisch Rechte vergibt. Diese Trennung ist Absicht: Wer Rollen verwaltet, sollte nicht zugleich Einblick in Einkommensdaten haben. Für echte Störungen empfiehlt sich ein protokollierter Notfallzugang mit Vier-Augen-Freigabe.

Provisionen sind aus einem anderen Grund heikel: Sie berühren das Vertrauen im Team. Berater und Partner sehen in der Vorlage nur eigene Provisionen, die Teamleitung sieht und exportiert die Werte ihres Teams für Auswertungen. Provisionssätze anderer Partner bleiben unsichtbar, auch wenn sie im selben Projekt verkaufen. Wer Abrechnungen freigibt, ist eine eigene Rolle außerhalb dieser Matrix.

Wie prüft man Zugriffsrechte vor der Freischaltung?

Zugriffsrechte prüft man vor der Freischaltung mit je einem Testzugang pro Rolle und einem Prüfprotokoll, das jede Zelle der Matrix als Testfall führt. Erlaubte Aktionen müssen gelingen, gesperrte müssen scheitern. Erst wenn alle Fälle das erwartete Ergebnis zeigen und dokumentiert sind, werden echte Nutzer freigeschaltet.

Für die Testzugänge empfiehlt sich eine eigene Testorganisation mit fiktiven Kontakten, etwa unter Adressen der Domain example.com, die die IANA für Dokumentations- und Beispielzwecke reserviert hat. So landen Testnachrichten nicht bei echten Empfängern. Jeder Testkontakt erhält einen eindeutigen Betreuer, damit eigene und fremde Datensätze klar unterscheidbar sind.

Negative Tests sind wichtiger als positive. Dass ein Berater seine eigenen Kontakte sieht, fällt im Alltag sofort auf. Dass er über eine veränderte Adresse einen fremden Kontakt öffnen kann, fällt niemandem auf, bis es passiert. Das Protokoll hält deshalb für jede gesperrte Zelle fest, auf welchen Wegen der Zugriff versucht wurde.

1. 1Testorganisation mit fiktiven Daten anlegen: je Rolle ein Testzugang, je Rolle mindestens ein eigener und ein fremder Testkontakt
2. 2Matrix in Testfälle übersetzen: jede Zelle wird eine Zeile mit Rolle, Datenobjekt, Aktion und erwartetem Ergebnis
3. 3Positive Fälle ausführen: Aktion durchführen, Ergebnis, Datum und prüfende Person eintragen
4. 4Negative Fälle über mehrere Wege versuchen: Menü, Suche, direkte Adresse mit fremder Datensatz-Kennung, mobile Ansicht, Bericht
5. 5Abweichungen erfassen, beheben lassen und die betroffene Rolle vollständig nachtesten
6. 6Abnahme zeichnen lassen: fachlich durch die Vertriebsleitung, technisch durch die Administration

Praxisbeispiel: Prüfaufwand für 60 Testfälle berechnen

Annahme: Ein Vertrieb übernimmt die Matrix unverändert, also vier Rollen, fünf Datenobjekte und drei Aktionen. Daraus ergeben sich 4 × 5 × 3 = 60 Testfälle, laut Tabelle 24 erlaubte und 36 gesperrte. Nehmen wir an, ein Testfall dauert einschließlich Dokumentation im Mittel 3 Minuten. Der Erstdurchlauf kostet dann 60 × 3 = 180 Minuten, also 3 Stunden.

Annahme: Im Erstdurchlauf fallen 4 Testfälle durch, verteilt auf zwei Rollen. Zum Beispiel öffnet der Testzugang des Vertriebspartners über die globale Suche einen fremden Kontakt, und die Teamleitung ruft einen Kontakt eines anderen Teams per direkter Adresse auf. Nach der Korrektur wird nicht nur der einzelne Fall, sondern die gesamte betroffene Rolle nachgetestet, weil eine Rechteänderung Nebenwirkungen haben kann.

Eine Rolle umfasst 5 × 3 = 15 Testfälle. Zwei betroffene Rollen ergeben 30 Nachtests, bei 3 Minuten je Fall also 90 Minuten. Der Gesamtaufwand liegt in diesem Beispiel bei 180 + 90 = 270 Minuten oder 4,5 Stunden. Rechnen Sie mit Ihren eigenen Annahmen nach: Jede zusätzliche Rolle erhöht den Erstdurchlauf um 15 Testfälle, jedes zusätzliche Datenobjekt um 4 × 3 = 12.

Die 60 Fälle bilden nur das Grundraster aus Rollen, Datenobjekten und Aktionen ab. Bei erlaubten Rechten mit begrenzter Reichweite kommen zusätzliche Negativfälle hinzu: etwa derselbe Leseversuch mit einem Kontakt außerhalb des eigenen Teams oder Partnerunternehmens. Auch mehrere Zugangswege und getrennte Prüfungen von Anlegen und Ändern erhöhen die tatsächliche Fallzahl. Erfassen Sie diese Varianten gesondert; die Beispielrechnung ist kein vollständiges Sicherheits-Testbudget.

Wer darf die Berechtigungsmatrix ändern?

Fachlich ändert die Vertriebsleitung als Eigentümerin die Berechtigungsmatrix, technisch setzt die Administration um, und eine dritte Person testet nach. Niemand sollte eine Rechteänderung allein beantragen, umsetzen und abnehmen. Jede Änderung erhält eine neue Versionsnummer und einen Eintrag im Änderungsprotokoll.

Im Tagesgeschäft kommen Rechteänderungen selten als Konzeptfrage, sondern als Einzelwunsch: Ein Partner soll ein weiteres Projekt sehen, eine Teamleitung übernimmt vorübergehend ein zweites Team. Solche Wünsche werden als befristete Ausnahme erfasst, mit Enddatum und Begründung. Unterstützt das System befristete Rechte, laufen sie automatisch aus; andernfalls sichert ein fester Wiedervorlagetermin den Entzug.

Art. 32 Abs. 4 DSGVO verlangt, dass unterstellte Personen mit Zugang zu personenbezogenen Daten diese nur auf Anweisung des Verantwortlichen verarbeiten, sofern keine gesetzliche Verarbeitungspflicht besteht. Ein Änderungsprotokoll, das Antrag, Freigabe und Umsetzung festhält, macht nachvollziehbar, auf wessen Anweisung ein Zugriff eingeräumt wurde, und unterstützt die Rechenschaftspflicht nach Art. 5 Abs. 2 DSGVO.

• Datum und Versionsnummer der Matrix
• Betroffene Rolle und Zelle
• Antragsteller und Begründung
• Freigabe durch die Vertriebsleitung
• Umsetzung durch die Administration
• Nachtest mit Ergebnis und prüfender Person
• Enddatum bei befristeten Ausnahmen

Welche Prüffälle gehören in die CRM-Demo?

In die CRM-Demo gehören die negativen Prüffälle der Matrix: fremden Kontakt per direkter Adresse öffnen, Export aus einer Liste ohne Exportrecht, Dokumentvorschau mit Download-Versuch, Suche nach Kontakten anderer Partner. Lassen Sie diese Fälle live mit einem Testzugang der jeweiligen Rolle vorführen, nicht mit einem Administratorzugang.

Eine Demo mit Administratorrechten zeigt, was ein System kann, aber nicht, was es verhindert. Deshalb empfiehlt es sich, dem Anbieter die Matrix vorab zu schicken und um eine Vorführung mit vorbereiteten Rollen zu bitten. Wo ein Probezugang möglich ist, führen Sie einen Teil des Prüfprotokolls selbst aus. Das Ergebnis fließt als eigenes Kriterium in Ihre Bewertung ein.

Achten Sie darauf, ob sich die Reichweiten der Vorlage überhaupt abbilden lassen. Manche Systeme unterscheiden nur Rollen, aber nicht nach Zuordnung oder Organisation; dann lässt sich „eigene Kontakte“ nicht von „alle Kontakte“ trennen. Für die Zusammenarbeit mit externen Vertriebspartnern ist diese Frage entscheidend und sollte vor Vertragsschluss geklärt sein.

• Lässt sich Sichtbarkeit nach Betreuer und nach Partnerorganisation getrennt einstellen?
• Ist Export getrennt von Lesen vergebbar, auch für Druck und Massenversand?
• Werden Rechteänderungen mit Person und Zeitpunkt protokolliert?
• Lassen sich Rechte befristen?
• Gibt es einen protokollierten Notfallzugang ohne dauerhaften Inhaltszugriff der Administration?