Trust Center
Sicherheit und Architektur für vertrauliches Melden
QReportly ist eine produktive EU-SaaS-Plattform für interne Hinweisgeberkanäle — mit Organisationsisolation, rollenbasiertem Zugriff, verschlüsseltem Transport und einem öffentlichen Meldefluss, der Identifikationsrisiken minimiert.
Diese Seite richtet sich an technische Einkäufer, Datenschutzbeauftragte und Führungsteams, die prüfen, ob QReportly für vertrauliches internes Melden geeignet ist. Wir beschreiben Kontrollen, die wir tatsächlich betreiben — ohne Details, die einem Angreifer helfen würden.
Vertrauenssäulen
01
Vertrauliches Melden by Design
Der öffentliche Kanal ist für Personen gebaut, die ohne Mitarbeiterkonto melden müssen.
- Anonyme Meldungen nutzen Tracking-Code und Zugangsschlüssel getrennt von der Arbeitsidentität.
- Der öffentliche Flow speichert bewusst keine IP-Adresse, User-Agent oder Fingerprinting-Daten.
- Bildanhänge werden beim Upload neu verarbeitet, um EXIF und ähnliche Metadaten zu entfernen.
- Nachfragen bleiben im Fall — nicht in gemeinsamen Postfächern oder generischen E-Mail-Threads.
02
Zugriffskontrolle und Trennung der Aufgaben
Nur autorisierte Unternehmensrollen können Fallmaterial öffnen. Partner- und Beauftragten-Flows sind vom Hauptdashboard getrennt.
- Workspace-Daten sind organisationsbezogen — Meldungen und Dateien werden nicht vermischt.
- Plattformrollen umfassen Eigentümer, Admin, Mitglied und benannten Beauftragten mit klaren Aufgaben.
- Partnerkonten und Beauftragtenzugang nutzen eigene Authentifizierungspfade.
- Sitzungsbasierte Authentifizierung schützt Admin-Oberflächen; öffentliche Melde-URLs reichen nicht zur Unternehmensverwaltung.
03
Infrastruktur und Zahlungen
Produktionslasten laufen auf etablierten EU-Cloud-Anbietern; Kartenzahlungen über einen spezialisierten Processor.
- Plattforminfrastruktur ist in der Europäischen Union gehostet (Anwendung und verwaltete Datenbank-/Speicherdienste).
- Gesamter Browser- und API-Verkehr nutzt TLS-Verschlüsselung in Transit.
- Objektspeicher für Anhänge nutzt Zugriffskontrolle pro Organisation.
- Abonnements laufen über Stripe Checkout und Kundenportal — Kartendaten bleiben bei Stripe.
04
Operative Integrität
Compliance-Workflows sind Produktfunktionen, keine nachträglich angehängten Tabellen.
- Eingangsbestätigung und Fallbearbeitung sind im Produktworkflow für Kanäle nach Richtlinie (EU) 2019/1937 integriert.
- Aufbewahrung kann der internen Richtlinie des Arbeitgebers folgen; Anhänge können bei Ablauf gelöscht werden.
- Ein elektronisches Register unterstützt auditnahe Falldokumentation.
- Rechtliche Hinweise, Datenschutz- und Cookie-Richtlinie sind öffentlich — nicht hinter Sales-Calls versteckt.
Architektur im Überblick
- Multi-Tenant-Anwendungsmodell
- Jede Kundenorganisation ist ein eigener logischer Workspace. Meldungen, Mitgliedschaft und Anhänge sind an diese Organisationsgrenze gebunden.
- Authentifizierungsschichten
- Unternehmensnutzer melden sich am Dashboard mit Kontodaten an (optional Google, sofern konfiguriert). Beauftragte und Partner nutzen eigene Flows, damit Privilegien getrennt bleiben.
- Passwortschutz
- Kontopasswörter werden als einseitige bcrypt-Hashes gespeichert — nicht als umkehrbarer Klartext.
- Transportsicherheit
- HTTPS/TLS schützt Daten zwischen Browsern, APIs und der Plattform-Edge. Wir behaupten keine clientseitige Ende-zu-Ende-Verschlüsselung von Meldeinhalten als Produktfeature.
- Anhangverarbeitung
- Uploads werden ggf. von identifizierenden Metadaten bereinigt und unter organisationsbezogenen Zugriffsregeln gespeichert.
- Billing-Isolation
- Zahlungsinstrumente werden von Stripe verarbeitet. QReportly speichert Abonnement- und Kundenreferenzen für den Betrieb — keine vollständigen Karten-PANs.
- Administrator-Authentifizierung heute
- E-Mail/Passwort (bcrypt) mit Authenticator-TOTP und gehashten Wiederherstellungscodes. MFA ist Pflicht für Inhaber, Admins und Meldestellen und bleibt optional für andere Mitglieder. Eine privilegierte Google-Anmeldung verlangt danach weiterhin den Plattform-Authenticator.
Technische und organisatorische Maßnahmen
- Transportverschlüsselung
- Browser-, API- und Edge-Verkehr nutzt TLS. Wir behaupten keine clientseitige Ende-zu-Ende-Verschlüsselung der Meldungstexte.
- Zugriffskontrolle
- Rollenbasierter Zugriff und logische Isolation jedes Organisations-Workspace, seiner Meldungen, Mitglieder und Anhänge.
- Passwörter
- Kontopasswörter werden als bcrypt-Hashes gespeichert, nicht als umkehrbarer Klartext.
- MFA
- Natives TOTP mit verschlüsselten Geheimnissen und gehashten Wiederherstellungscodes. Pflicht für Inhaber, Admins und Meldestellen. Optional für andere Mitglieder.
- Unabhängiger Pentest
- Wir haben keinen Dritt-Penetrationstestbericht veröffentlicht. Wir behaupten auf dieser Seite weder ISO 27001, SOC 2 noch einen abgeschlossenen externen Pentest.
- Backups
- Primäre Produktionsdaten werden in EU-gehosteter Infrastruktur gesichert, mit verschlüsselten Backups des Hosting-Stacks.
- Anhangsbereinigung
- Bild- und Dokument-Uploads werden verarbeitet, um EXIF und ähnliche identifizierende Metadaten vor der Speicherung zu entfernen.
- Kennungen der meldenden Person
- Der öffentliche Meldefluss ist so gestaltet, dass IP, User-Agent oder Fingerprinting-Daten der meldenden Person nicht persistiert werden.
- Vorfälle
- Betrifft eine Verletzung des Schutzes personenbezogener Daten Kanaldaten, benachrichtigen wir den Kunden unverzüglich gemäß AVV.
- Statusseite
- Diese Website enthält eine Live-Erreichbarkeitsprüfung (kein historisches SLA-Dashboard auf status.qreportly.com). Wesentliche Verfügbarkeitsvorfälle werden Administratoren weiterhin über operative Kanäle mitgeteilt.
Aufbewahrungsmatrix
Dies sind die in den Datenschutzbestimmungen beschriebenen Produktdefaults. Der Kunde als Verantwortlicher kann die Aufbewahrung im Rahmen des für seine Organisation geltenden Rechts konfigurieren. Diese Tabelle ist keine Rechtsberatung.
| Rechtsordnung (Produktdefault) | Anhänge nach Fallschluss | Register / Falltext |
|---|---|---|
| Default (die meisten EU-Mitgliedstaaten) | 180 Kalendertage | 5 Jahre, dann endgültige Löschung |
| Deutschland (Workspace für 3-Jahres-Register) | 180 Kalendertage | 3 Jahre, dann endgültige Löschung |
| Kundenkonfiguration | Im Rahmen des geltenden Rechts | Im Rahmen des geltenden Rechts |
Verantwortungsvolle Transparenz
Vertrauen heißt auch zu wissen, was wir nicht veröffentlichen. Zu viele Infrastrukturdetails erhöhen das Risiko für alle Kunden.
- Was wir hier teilen
- Sicherheitsprinzipien, Zugriffsmodell, Hosting-Region, Zahlungsabwicklung, Anonymitätsdesign des öffentlichen Kanals und Links zu Rechtsdokumenten.
- Was wir nicht veröffentlichen
- Interne Netzdiagramme, exakte Firewall-Regeln, unveröffentlichte Schwachstellendetails, Mitarbeiterzugangsdaten oder schrittweise Angriffsflächenkarten.
- Zertifizierungen
- Wir beschreiben Kontrollen, die wir heute betreiben. Wir beanspruchen auf dieser Seite kein SOC 2, ISO 27001 o. Ä., sofern nicht unabhängig abgeschlossen und hier gelistet.
- Sicherheitskontakt
- Für Datenschutz- oder Sicherheitsfragen zu Evaluation oder Einsatz kontaktieren Sie den Support über den veröffentlichten Kanal. Senden Sie keine Live-Zugangsdaten oder Exploit-Payloads per E-Mail.
Technische & Sicherheits-FAQ
- Wo werden Kundendaten gehostet?
- Kunden-Meldeinhalte und primäre Produktions-Workloads werden in der EU gehostet. Bestimmte Zusatzanbieter (Abrechnung, Authentifizierung) können begrenzte Kontodaten außerhalb des EWR mit DSGVO-Transfergarantien verarbeiten.
- Kann ein Unternehmen die Meldungen eines anderen sehen?
- Nein. Meldungen, Mitglieder und Anhänge sind organisationsbezogen. Administrativer Zugriff erfordert eine autorisierte Rolle in dieser Organisation.
- Ist der Meldekanal anonym?
- Melder können ohne Mitarbeiterkonto einreichen — mit Tracking-Code und Zugangsschlüssel. Der öffentliche Kanal speichert keine Reporter-IP oder Fingerprinting-Daten. Absolute Anonymität hängt auch davon ab, was der Melder schreibt oder anhängt.
- Nutzen Sie Ende-zu-Ende-Verschlüsselung für Meldeinhalte?
- Der Verkehr ist mit TLS in Transit geschützt, und Speicherzugriff ist organisationsbezogen kontrolliert. Wir vermarkten keine echte clientseitige E2E-Verschlüsselung von Meldeinhalten als Kernfeature — wir bevorzugen präzise Sprache statt Buzzwords.
- Wer kann einen Fall im Unternehmen lesen?
- Nur Nutzer mit der passenden Unternehmensrolle (z. B. Eigentümer, Admins oder benannte Beauftragte je nach Konfiguration). Partner- und Beauftragtenportale sind wo zutreffend von allgemeinen Unternehmenseinstellungen getrennt.
- Wie sind Zahlungen abgesichert?
- Abonnements werden über Stripe abgerechnet. Kartennummern werden auf Stripe-Checkout-Oberflächen eingegeben; QReportly speichert keine vollständigen Kartennummern auf eigenen Servern.
- Was sollte ein DPO oder IT-Reviewer als Nächstes prüfen?
- Prüfen Sie Datenschutzbestimmungen, Auftragsverarbeitungsvertrag, Unterauftragsverarbeiter-Liste, Cookie-Richtlinie und AGB, dann Rollen und Aufbewahrungseinstellungen. Für Vendor-Fragebögen senden Sie Ihre Checkliste an den Support — wir antworten mit Fakten, nicht mit Marketing.
- Erzwingen Sie MFA für Administratoren?
- Ja für privilegierte Rollen: Inhaber, Admin und Meldestelle müssen Authenticator-TOTP aktivieren. Andere Mitglieder können es optional nutzen. Die Durchsetzung erfolgt serverseitig für Meldungen, Anhänge und Organisationsverwaltung. Google-Anmeldung umgeht diese Anforderung nicht.
- Haben Sie ISO 27001, SOC 2 oder einen unabhängigen Pentest?
- Derzeit kein veröffentlichter ISO-27001-, SOC-2- oder Dritt-Pentestbericht. Wir beschreiben tatsächlich betriebene Kontrollen. Sobald eine unabhängige Bewertung vorliegt, wird sie hier gelistet, nicht unterstellt.
Verwandte Dokumente
QReportly mit klaren Erwartungen bewerten
Starten Sie einen Workspace, prüfen Sie Preise oder stellen Sie vor der Entscheidung eine Sicherheitsfrage. Vertrauliches Melden verdient eine Plattform, die ihre Kontrollen ehrlich erklärt.