Plattform & Sicherheit

Eine Plattform, die Zahlungen freigibt, muss eine Kontrollplattform sein.

Identität, Isolation, Nachvollziehbarkeit — detailliert genug, um geprüft zu werden.

Diese Seite ist für die Menschen, die freigeben müssen: CIO, Sicherheitsverantwortung, Interne Revision und die Finance-Verantwortung, die persönlich für eine Zahlungsfreigabe haftet. Sie beschreibt, wie Kontrolle gebaut ist, statt zu behaupten, die Plattform sei sicher — und sagt offen, wo eine Aussage Ihre eigene Prüfung braucht.

Technisches Review anfragen Plattformarchitektur →
Identität und Zugriff

Zugriff ist eine Rolle, gehalten von einer Person.

Finance-Systeme scheitern am Zugriff, lange bevor sie an der Architektur scheitern. Geteilte Zugänge, mitgewachsene Rechte und ein allmächtiger Administrator sind die üblichen Feststellungen — deshalb ist keines davon vorgesehen.

Zentrale IdentitätDie Anmeldung läuft über Microsoft Entra ID. Das Produkt speichert keine Passwörter.
Rollenbasierter ZugriffRechte hängen an Rollen und Rollen an Personen. Es gibt keine geteilten Konten und keine persönlichen Ausnahmen.
GesellschaftsbezugEine Rolle gilt für definierte Gesellschaften. Sichtbarkeit und Handlungsrechte folgen der Organisationsstruktur.
FunktionstrennungVorbereitung, Prüfung und Freigabe sind getrennte Rechte. Selbstfreigabe blockiert die serverseitige Regel, nicht die Gewohnheit.
MinimalprinzipDie Voreinstellung ist kein Zugriff. Rechte werden bewusst erteilt und nicht mit der Dienstzeit vererbt.
Geschützte SchnittstelleJede Aktion wird dort geprüft, wo sie ausgeführt wird, nicht nur dort, wo sie angezeigt wird.
Isolation und Trennung

Ihre Daten sind getrennt, und unsere Umgebungen auch.

Mandantentrennung

Die Daten jedes Mandanten sind auf der Datenebene getrennt und nicht durch einen Filter in der Anwendung. Eine Abfrage ohne Mandantenkontext liefert nichts.

  • Row-Level Security auf mandantenbezogenen Daten
  • Isolation auf der Datenebene geprüft, nicht in der Oberfläche
  • Kein mandantenübergreifender Auswertungsweg

Umgebungstrennung

Entwicklung, Staging, Verifikation und Produktion sind getrennte Umgebungen mit getrennten Daten und getrennten Zugriffen.

  • Kein Entwicklungszugriff auf Produktionsdaten
  • Testdaten sind keine Kundendaten
  • Zugriff je Umgebung ist ein eigenes Recht

Wo die Plattform läuft

FinanceOS läuft auf Microsoft Azure. Die betriebenen Umgebungen liegen in einer europäischen Region, und die für Ihren Mandanten geltende Region ist Vertragsbestandteil und keine Marketingaussage.

  • Europäische Hosting-Region
  • Region je Mandant benannt
  • Unterauftragsverarbeiter auf Anfrage benannt

Daten in Übertragung und Ablage

Die Übertragung ist verschlüsselt, gespeicherte Daten werden von den eingesetzten Plattformdiensten verschlüsselt abgelegt. Die Einzelheiten beschreiben wir im technischen Review, statt sie zu einem Siegel zusammenzufassen.

  • Verschlüsselte Übertragung
  • Verschlüsselung in der Ablage
  • Details für Ihren Sicherheitsfragebogen
Prüfbarkeit und Nachvollziehbarkeit

Was passiert ist, ist festgehalten.

Prüfbarkeit ist keine Reporting-Funktion. Sie ist der Grund, warum ein Finance-Betrieb überhaupt außerhalb des ERP laufen darf.

Nur anhängende EinträgeEinträge auf Finanzobjekten werden ergänzt, nicht überschrieben. Historie lässt sich nicht still umschreiben.
Wer, was, wann, warumJede Änderung, Freigabe, Ablehnung und Ausnahme trägt Person, Zeitpunkt und Grundlage.
FreigabenachweisEine Zahlungsfreigabe behält die geltende Regel, das geprüfte Limit und die beteiligten Personen.
FallhistorieAusnahmen und Fälle behalten ihre Dokumente und Entscheidungen. Eine Frage im nächsten Jahr braucht keine Rekonstruktion.
Rückverfolgung zur QuelleEine Zahl lässt sich auf System und Datensatz zurückführen, aus dem sie kommt — eine Projektion ist nie anonym.
Administrative AktionenKonfigurations- und Rechteänderungen werden wie fachliche Aktionen protokolliert, weil dort das eigentliche Risiko liegt.
Datenqualität

Unknown is not zero.

Das ist die Entwurfsregel, nach der am häufigsten gefragt wird — und die eine Finance-Plattform am deutlichsten von einem Dashboard trennt.

Fehlende Daten werden als fehlend ausgewiesen. Eine Cash-Position, die eine Quelle nicht erreicht hat, ist eine unvollständige Cash-Position und wird so gekennzeichnet. Wo ein Wert nicht ehrlich abgeleitet werden kann — eine Umrechnung ohne Referenzkurs, eine Kennzahl ohne belastbaren Nenner — erzeugt die Plattform keine Zahl statt einer plausiblen. Ein leerer Zustand ist eine richtige Antwort; eine selbstsichere falsche Zahl ist es nicht.

Fail closedFehlt eine Eingangsgröße, hält die Plattform das Ergebnis zurück, statt einen Standardwert einzusetzen.
Quelle an der ZahlJeder Wert kann benennen, woher er kommt und mit welchem Stand.
Ehrliche LeerzuständeEine Sicht ohne Daten sagt das — und sagt, was fehlt.
Lücken sind sichtbarEine unvollständige Projektion wird dort gekennzeichnet, wo sie genutzt wird, nicht nur im Protokoll.
Änderungs- und Release-Governance

Änderungen erreichen Ihre Umgebung über einen kontrollierten Weg.

Eine Plattform, die Geld bewegt, darf nicht beiläufig geändert werden. Der Weg von einer Änderung in Ihre Umgebung ist selbst kontrolliert und protokolliert.

Von der Änderung in Ihre Umgebung
  1. 1
    Änderung
  2. 2
    Review
  3. 3
    Automatisierte Prüfung
  4. 4
    Staging
  5. 5
    Abnahme
  6. 6
    Kontrolliertes Release
  7. 7
    Rückweg

Ein Release ist erst vollständig, wenn auch der Rückweg belegt ist. Rollback und Wiederherstellung sind Teil des Verfahrens und keine Improvisation im Notfall.

Zertifizierungen und Prüfungen

Was wir behaupten und was nicht.

Wir behaupten keine Zertifizierungen, die wir nicht haben, und verwenden auch keine Formulierungen, die sie andeuten. Wenn Ihr Einkauf oder Ihre Sicherheitsorganisation eine bestimmte Zertifizierung, einen Prüfbericht oder einen Fragebogen verlangt, fragen Sie direkt: Sie bekommen eine klare Antwort dazu, was heute existiert, was wir belegen können und was nicht. Diese Antwort ist für Ihre Risikobewertung nützlicher als ein Siegel auf einer Website — und sie ist in jedem Gespräch dieselbe.
Was ein Security Review abdeckt

Was ein technisches Review mit uns tatsächlich abdeckt.

Ein Security Review ist eine Arbeitssitzung und keine Präsentation. In der Regel ist es das zweite Gespräch, nachdem die Architektur verstanden ist.

Identität und RollenWie Ihre Rollen auf Gesellschaften, Freigaben und Limits abgebildet werden.
IsolationWie Mandantentrennung durchgesetzt wird und wie Sie das prüfen können.
PrüfungserwartungenWas Ihre Prüfer verlangen werden und woher es kommt.
DatenschutzRechtsgrundlagen, Verarbeitung, Aufbewahrung und Löschung für Ihren Fall.
BetriebUmgebungen, Releases, Rückweg und der Umgang mit Störungen.
Ihr FragebogenWir beantworten Ihren, statt unseren zu schicken.
Nächster Schritt

Schicken Sie uns die Fragen, die Ihr Security Review beantworten muss.

Sagen Sie uns, welche Fragen Ihr CIO, Ihre Sicherheitsorganisation oder Ihre Revision beantwortet braucht und wer dabei sein muss. Wir melden uns innerhalb eines Werktags mit dem, was wir heute belegen können, und mit dem, was wir einschränken müssten.

  • Was Sie zurückbekommen. Eine klare Antwort je Frage — einschließlich der Fragen, die wir heute nicht abschließend beantworten können.
  • Wer antwortet. Die Menschen, die die Kontrollen gebaut haben, nicht ein Vertriebsteam mit einer Sicherheitsfolie.
  • Was danach möglich ist. Ein technisches Review mit Ihren Prüfern, auf Ihrer Fragenliste.
Eingang wird per E-Mail bestätigt. Persönliche Antwort innerhalb eines Werktags.
Das Fazit

Control by Design, detailliert genug zum Prüfen.

Identität, Isolation, Nachvollziehbarkeit und ehrliche Daten — die Architektur, kein Siegel.

Plattformarchitektur Finance Operations Assessment