Der Einkauf fragt nach "SOC-2-Konformität" wie nach einer Verschwiegenheitsvereinbarung. Es ist ein Häkchen im Sicherheitsfragebogen. Anbieter antworten mit Ja, hängen einen Bericht an, und der Abschluss geht weiter.
Das ist in Ordnung, solange die Antwort stimmt. Schief geht es, wenn Käufer nicht wissen, was der Bericht wirklich belegt. SOC 2 ist eine Kontrollprüfung, keine Sicherheitsgarantie. Ein SOC-2-Type-II-Bericht ist der Beleg, dass ein Anbieter gesagt hat, er werde bestimmte Dinge tun, und dass eine Prüfstelle 6 bis 12 Monate lang zugesehen hat, wie er es tut. Nicht mehr. Nicht weniger.
Dieser Leitfaden richtet sich an Sicherheitsverantwortliche, Compliance-Zuständige und Supportleitungen, die einen Anbieter für Wissensdatenbanken oder Help Center bewerten. Er zeigt, was SOC 2 tatsächlich prüft, den Unterschied zwischen Type I und Type II, welche Kontrollen für Dokumentationssysteme zählen und wie du den Bericht anforderst und liest, damit die Antwort in deinem Fragebogen echt ist.
Was SOC 2 wirklich belegt (und was nicht)
SOC 2 steht für Service Organization Control 2. Es ist ein Berichtsrahmenwerk des American Institute of Certified Public Accountants (AICPA). Eine SOC-2-Prüfung führt eine zugelassene Wirtschaftsprüfungsgesellschaft durch. Das Ergebnis ist ein Bericht, kein Zertifikat. Das AICPA vergibt kein "SOC-2-zertifiziert"-Abzeichen. Wer dir sagt, er sei "SOC 2 zertifiziert", meint verkürzt "wir haben einen SOC-2-Prüfbericht".
Das Rahmenwerk bewertet eine Dienstleistungsorganisation anhand der Trust Services Criteria, einer Sammlung gemeinsamer und kategoriespezifischer Kriterien des AICPA. Die Prüfung schaut auf zwei Dinge: Sind die Kontrollen richtig entworfen, und laufen sie über die Zeit wirksam.
Was SOC 2 belegt: Der Anbieter hat dokumentierte Kontrollen, die Kontrollen bilden definierte Kriterien ab, sie wurden entworfen, um diese Kriterien zu erfüllen, und die Prüfstelle hat eine Stichprobe getestet und sie im Prüfzeitraum wie entworfen arbeitend vorgefunden.
Was SOC 2 nicht belegt: dass der Anbieter gute Sicherheit hat. Dass es keinen Vorfall geben kann. Dass das Produkt tut, was es verspricht. Dass die Daten im Produkt korrekt sind. Dass die Architektur richtig ist. Dass der Support kompetent ist. Nichts davon liegt im Umfang.
Ein Anbieter mit SOC-2-Type-II-Bericht kann trotzdem ein kaputtes Produkt ausliefern. Ein Anbieter ohne SOC-2-Bericht kann trotzdem ein straffes Sicherheitsprogramm fahren. Der Bericht belegt einen Prozess, nicht ein Ergebnis. Behandle ihn so.
Die fünf Trust Services Criteria
SOC 2 kennt fünf Trust Services Criteria, oft TSCs genannt:
- Sicherheit. Das System ist gegen unbefugten Zugriff geschützt, physisch wie logisch. Das ist das einzige Pflichtkriterium. Jeder SOC-2-Bericht enthält Sicherheit.
- Verfügbarkeit. Das System ist wie zugesagt betriebsbereit und nutzbar.
- Verarbeitungsintegrität. Die Verarbeitung ist vollständig, gültig, korrekt, zeitgerecht und autorisiert.
- Vertraulichkeit. Als vertraulich gekennzeichnete Informationen sind geschützt.
- Datenschutz. Personenbezogene Daten werden entsprechend den Zusagen des Anbieters erhoben, genutzt, aufbewahrt, offengelegt und gelöscht.
Der Anbieter wählt, welche Kriterien im Umfang liegen. Die meisten Wissensdatenbank-Anbieter nehmen Sicherheit und Verfügbarkeit. Anbieter auf Unternehmensniveau ergänzen Vertraulichkeit. Datenschutz ist seltener, weil die meisten Anbieter über Administrationskonten hinaus wenig personenbezogene Daten von Endnutzenden verarbeiten. Verarbeitungsintegrität ist bei Dokumentationssystemen selten, weil es keine Transaktionsintegrität zu prüfen gibt.
Beim Lesen eines Berichts nennt die Titelseite die geprüften Kriterien. Zählt Vertraulichkeit für deinen Anwendungsfall und deckt der Bericht nur Sicherheit und Verfügbarkeit ab, belegt er nicht, was du brauchst.
SOC 2 Type I gegen Type II bei Wissensdatenbanken
Die wichtigste Frage an einen Anbieter lautet, ob sein Bericht Type I oder Type II ist. Beides ist SOC 2. Gleichwertig ist es nicht.
Type I ist eine Momentaufnahme. Die Prüfstelle bewertet, ob die Kontrollen zu einem Stichtag so entworfen sind, dass sie die Kriterien erfüllen. Die Prüfung dauert wenige Wochen. Der Bericht sagt: Am 15. Mai 2026 hatte der Anbieter Kontrollen, die funktionieren sollten.
Type II ist ein Bericht über die Wirksamkeit im Betrieb. Die Prüfstelle bewertet, ob die Kontrollen richtig entworfen waren und über einen Zeitraum wirksam liefen, üblicherweise 6 bis 12 Monate. Die Prüfung dauert ein Jahr. Der Bericht sagt: Vom 1. Juni 2025 bis 31. Mai 2026 waren die Kontrollen nicht nur entworfen, sie liefen tatsächlich, und wir haben Stichproben getestet.
Type I ist das, was ein neuer Anbieter im ersten Compliance-Jahr produziert. Eine Momentaufnahme. Type II ist das, was ein reifer Anbieter danach jedes Jahr produziert. Der Betriebsbeleg.
Für eine produktive Wissensdatenbank, die kundenseitige Inhalte, Entwürfe und Administrationszugriff auf deinen Support-Stack hält, ist Type II die richtige Hürde. Type I sagt dir, dass die Rechtsabteilung gute Richtlinien geschrieben hat. Type II sagt dir, dass das Engineering sie auch befolgt hat.
Sagt ein Anbieter "wir haben SOC 2", frag: "Ist das Type I oder Type II, und wie lautet der Prüfzeitraum?" Lautet die Antwort Type I, steht das Compliance-Programm am Anfang. Für einen Pilotversuch ist das in Ordnung. Für einen langfristigen Vertrag ist es ein dünner Beleg.
Wissensdatenbank-Anbieter mit aktuellen SOC-2-Type-II-Berichten (2026)
Die folgende Tabelle spiegelt den öffentlich genannten SOC-2-Status großer Anbieter von Wissensdatenbanken und Help Centern, Stand Mai 2026. Der Status ändert sich. Bestätige ihn vor der Unterschrift beim Anbieter.
| Anbieter | Status Type II | Kriterien im Umfang | Anforderung |
|---|---|---|---|
| Document360 | Im Trust Center als verfügbar gelistet (Vereinbarung nötig) | Nicht öffentlich | Anfrageformular im Trust Center, Vereinbarung nötig, 3 Berichte: Zusammenfassung, Bridge Letter, Vollbericht |
| Help Scout | Type 2 bescheinigt, öffentlich genannt | Sicherheit und Verfügbarkeit | E-Mail an help@helpscout.com |
| Zendesk | Type II aktuell, regelmäßige Prüfungen | Auf der Übersichtsseite nicht öffentlich, vollständige Kriterien im Bericht | Conveyor-Trust-Portal (app.conveyor.com/profile/zendesk), Vereinbarung nötig |
| HubSpot | Type-2-Bericht plus Bridge Letters verfügbar | Verfügbarkeit, Vertraulichkeit, Sicherheit laut öffentlicher Aussage | Bereich mit herunterladbaren Berichten für Kundschaft, veröffentlicht zudem SOC 3 |
| Intercom | Auf trust.intercom.com gelistet | Auf der Übersichtsseite nicht öffentlich | Anfrage im Trust-Portal, Vereinbarung nötig |
| KnowledgeOwl | Keine öffentliche SOC-2-Type-II-Aussage auf der Sicherheitsseite gefunden | Beim Anbieter anfragen | Sicherheitsbewertungen im Enterprise-Plan enthalten, in anderen Plänen kostenpflichtig |
| Helpjuice | Keine öffentliche SOC-2-Seite an den üblichen Adressen gefunden | Beim Anbieter anfragen | Vertrieb kontaktieren |
Ein paar Hinweise zum Lesen dieser Tabelle. "Als verfügbar gelistet" heißt, der Anbieter hält einen Type-II-Bericht hinter einem Anfrageformular bereit. Es heißt nicht, dass der Bericht aktuell ist. Frag immer nach dem Prüfzeitraum und fordere ein Bridge Letter an, wenn er vor mehr als ein paar Monaten endete. "Keine öffentliche Aussage gefunden" heißt nicht, dass der Anbieter keinen Bericht hat. Viele kleinere Anbieter veröffentlichen keine Trust-Seiten. Manche haben einen Type-II-Bericht und verlangen vorher eine Vereinbarung. Frag direkt.
Bewertest du einen Anbieter außerhalb dieser Liste, ist der Test einfach: Nennt seine öffentliche Sicherheits- oder Trust-Seite SOC 2 Type II beim Namen, und gibt es einen Weg, den Bericht anzufordern? Vage Formulierungen wie "wir folgen Branchenstandards" oder "konform mit SOC-2-Prinzipien" sind nicht dasselbe wie ein Type-II-Bericht.
Kontrollen, die für Dokumentationssysteme zählen
SOC 2 deckt hunderte Prüfpunkte über die Kriterien hinweg ab. Nicht alle zählen für eine Wissensdatenbank gleich viel. Beim Lesen eines Berichts lohnen diese Kategorien besondere Aufmerksamkeit.
Zugriffskontrollen
Wer darf Entwürfe lesen, wer veröffentlichen, wer löschen, wer Berechtigungen verwalten. Ein SOC-2-Type-II-Bericht sollte rollenbasierte Zugriffskontrolle, Mehrfaktor-Authentifizierung für Administrationskonten, regelmäßige Zugriffsprüfungen und formale Abläufe für Ein- und Austritt beschreiben. Achte darauf, wie oft Zugriffsprüfungen stattfinden. Quartalsweise ist Standard. Jährlich ist dünn.
Bei einer Wissensdatenbank zählt Zugriff in zwei Richtungen. Zugriffskontrollen für Endnutzende entscheiden, ob dein Help Center geschützte Inhalte für zahlende Kundschaft tragen kann. Administrationskontrollen entscheiden, wer beim Anbieter deine Entwürfe lesen kann. Beides sollte dokumentiert sein.
Änderungsmanagement für Artikel und Plattformcode
Dieses Kriterium übersehen die meisten Käufer. Änderungsmanagement in SOC 2 deckt traditionell Code-Auslieferungen ab. Bei einem Wissensdatenbank-Anbieter zählen zwei Änderungsströme: Änderungen an der Plattform selbst und Änderungen an Kundeninhalten. Das Plattform-Änderungsmanagement sollte Code-Review, Staging, automatisierte Tests und Rückrollverfahren beschreiben. Das Änderungsmanagement für Inhalte ist weniger standardisiert. Manche Anbieter haben Versionierung, Prüfpfade und Freigabeabläufe. Manche nicht.
Frag den Anbieter konkret: Umfasst der SOC-2-Umfang Kontrollen darüber, wie Kundeninhalte (Entwürfe, veröffentlichte Artikel, Löschungen) geändert und protokolliert werden? Wenn ja, geben dir diese Kontrollen den Beleg, dass niemand beim Anbieter still deine Artikel ändern kann. Wenn nein, schützt der Umfang nur ihren Code, nicht deine Inhalte.
Audit-Logs
Der Bericht sollte beschreiben, was protokolliert wird, wie lange Protokolle aufbewahrt werden, wer sie lesen darf und wie ihre Integrität geschützt ist. Bei einer Wissensdatenbank zählen Protokolle über Administrationsaktionen (Anmeldung, Rollenwechsel, Veröffentlichung, Löschung) und über Zugriffsmuster auf geschützte Inhalte.
Die Aufbewahrungsfristen schwanken. 90 Tage sind der Boden. 12 Monate sind Standard. Kundschaft in regulierten Branchen verlangt oft 7 Jahre. Prüfe, dass die Aufbewahrung deinem Bedarf entspricht.
Verschlüsselung in Übertragung und im Ruhezustand
Beides sollte in jedem modernen SOC-2-Bericht stehen. TLS 1.2 oder höher in der Übertragung. AES-256 im Ruhezustand. Der Bericht sollte die Schlüsselverwaltung beschreiben. Kundenseitig verwaltete Schlüssel sind eine Enterprise-Funktion, keine SOC-2-Anforderung. Brauchst du sie, frag separat.
Lieferantenmanagement
Wissensdatenbank-Anbieter laufen auf Cloud-Infrastruktur, mit Suchanbietern, KI-Diensten, Analytik, Fehlerverfolgung und CDNs von Dritten. Der SOC-2-Umfang sollte diese Unterdienstleister auflisten und sie entweder ausklammern oder einbeziehen. Lies die Ausklammerungen. Stützt sich der Anbieter auf AWS oder GCP und klammert sie aus, musst du zusätzlich deren SOC-2-Bericht lesen oder ihre öffentlichen Aussagen akzeptieren. Das ist übliche Praxis.
Vorfallbearbeitung
Der Bericht sollte beschreiben, wie der Anbieter Sicherheitsvorfälle erkennt, bearbeitet und der Kundschaft meldet. Fristen für die Benachrichtigung sollten ausdrücklich stehen. "Ohne schuldhaftes Zögern" ist vage. "Binnen 72 Stunden nach bestätigtem Vorfall" ist konkret.
Für einen tieferen Blick darauf, wie Dokumentationssysteme veralten und wo das operative Risiko wirklich sitzt, behandelt unser Beitrag zu den versteckten Kosten veraltender Dokumentation die Kontrolllücke, die SOC 2 nicht adressiert.
Wie du einen SOC-2-Bericht anforderst und liest
Die meisten Anbieter veröffentlichen ihren SOC-2-Type-II-Bericht nicht offen. Der Bericht enthält Kontrolltexte, Angaben zu Unterdienstleistern und teils Stellungnahmen des Managements zu Abweichungen. Das schützen Anbieter über eine Verschwiegenheitsvereinbarung.
Der übliche Ablauf:
- Finde das Trust-Portal des Anbieters. Gängige Plattformen: Conveyor, Vanta Trust Center, SafeBase, Whistic, OneTrust Trust Center. Adressmuster sind
trust.[anbieter].com,[anbieter].com/trustoder[anbieter].com/security. - Stelle eine Anfrage mit Firmenname, Rolle und E-Mail. Manche Portale verlangen eine Domainprüfung.
- Unterzeichne die gegenseitige Vereinbarung. Meist per Klick, manchmal mit Gegenzeichnung.
- Lade den Bericht herunter. Manche Portale befristen den Link.
Worauf du achten solltest, wenn du den Bericht hast:
Abschnitt I ist der Bericht der unabhängigen Prüfstelle. Der Urteilsabsatz ist das Entscheidende. Zwei Formulierungen zählen: "nach unserer Auffassung" gefolgt von einer uneingeschränkten Aussage (die Kontrollen liefen wirksam) oder einer eingeschränkten Aussage (mit Abweichungen). Ein eingeschränktes Urteil disqualifiziert nicht zwingend, doch du musst die Abweichungen lesen und entscheiden, ob sie für deinen Anwendungsfall wesentlich sind.
Abschnitt II ist die Erklärung des Managements. Die eigene Aussage des Anbieters zum Umfang. Lies, welche Trust Services Criteria abgedeckt sind. Prüfe die Daten des Prüfzeitraums.
Abschnitt III ist die Systembeschreibung. Für Käufer der nützlichste Teil. Er beschreibt Architektur, Kontrollen, Unterdienstleister, die geprüften Produkte und die Datenflüsse. Lies ihn. Passt die Beschreibung nicht zu dem Produkt, das du kaufst, deckt der Bericht deinen Anwendungsfall nicht ab.
Abschnitt IV ist die Beschreibung der Kontrolltests. Die Tests der Prüfstelle, die Grundgesamtheit, der Stichprobenumfang, die Ergebnisse. Suche nach "Abweichung". Hat die Prüfstelle Abweichungen gefunden, liefert der Anbieter eine Stellungnahme.
Abschnitt V (falls vorhanden) sind sonstige Informationen. Manchmal führt der Anbieter ergänzende Kontrollen auf, die bei dir als Kundin oder Kunde liegen. Lies sie. Sie sind meist offensichtlich (eigene Konten verwalten, starke Passwörter), enthalten aber gelegentlich Überraschendes (Sicherung der aus dem System exportierten Daten).
Bridge Letters
SOC-2-Type-II-Berichte decken einen Zeitraum ab, der an einem Stichtag endet. Die Prüfung des Folgejahres deckt einen neuen Zeitraum ab, der danach beginnt. Zwischen Ende des einen Zeitraums und Ausgabe des nächsten Berichts liegt eine Lücke von drei bis neun Monaten.
Ein Bridge Letter (auch Gap Letter oder Interimsschreiben) ist ein kurzes Dokument des Anbieters, das bestätigt, dass sich am Kontrollumfeld zwischen Ende des geprüften Zeitraums und dem Datum des Schreibens nichts Wesentliches geändert hat. Es ist keine Prüfung. Es ist eine Zusicherung des Anbieters. Es überbrückt die Lücke.
Endet der jüngste Bericht mehr als sechs Monate vor heute, fordere ein Bridge Letter an. Kann der Anbieter keines liefern, spricht das dafür, dass das Compliance-Programm nicht aktiv gepflegt wird.
Häufige Missverständnisse zu SOC 2
Einkauf und Sicherheitsteams verwechseln SOC 2 regelmäßig mit benachbarten Rahmenwerken. Keines davon ist dasselbe.
Nicht ISO 27001. ISO 27001 ist ein internationaler Standard für Managementsysteme der Informationssicherheit. Es ist eine Zertifizierung, kein Bericht, und wird von akkreditierten Zertifizierungsstellen ausgestellt. ISO 27001 ist stärker auf das Managementsystem ausgerichtet, SOC 2 stärker auf Kontrollbelege. Viele Anbieter halten beides. Sie überlappen sich, sind aber nicht austauschbar. Manche europäischen Käufer bevorzugen ISO 27001 als globalen Standard. Manche US-Käufer bevorzugen SOC 2, weil es im SaaS-Markt verbreiteter ist.
Nicht HIPAA. HIPAA ist US-Gesundheitsrecht. Es gilt für betroffene Einrichtungen und deren Dienstleister im Umgang mit geschützten Gesundheitsdaten. HIPAA-Konformität ist eine Selbstauskunft, keine Zertifizierung, und verlangt eine Vereinbarung zwischen Anbieter und Kundschaft. Ein Anbieter kann SOC 2 Type II halten und trotzdem nicht HIPAA-konform sein. Käufer im Gesundheitswesen brauchen beides.
Nicht DSGVO. Die DSGVO ist europäisches Datenschutzrecht. Sie gilt unabhängig vom Sitz des Anbieters, sobald personenbezogene Daten von Menschen in der EU verarbeitet werden. Ein SOC-2-Bericht mit dem Kriterium Datenschutz überlappt einige DSGVO-Kontrollen, doch Datenschutz in SOC 2 bezieht sich auf die Zusagen des Anbieters, nicht auf die DSGVO. Ein Anbieter mit SOC 2 Type II ohne das Kriterium Datenschutz hat aus SOC 2 keinen Beleg für DSGVO-Konformität.
Nicht SOC 1. SOC 1 deckt Kontrollen mit Bezug zur Finanzberichterstattung ab. SOC 2 deckt Kontrollen mit Bezug zu den Trust Services Criteria ab. Zwei verschiedene Berichte für zwei verschiedene Zielgruppen. Ein Wissensdatenbank-Anbieter braucht SOC 1 selten, außer sein Produkt wirkt direkt auf Kundenabschlüsse.
Keine Garantie. Das ist das wichtigste Missverständnis. SOC 2 belegt, dass der Anbieter einen Kontrollprozess hat. Es belegt nicht, dass die Kontrollen ausreichen, dass der Entwurf richtig ist, dass die Umsetzung stimmt oder dass der Anbieter nicht kompromittiert werden kann. Ein SOC-2-Type-II-Bericht ist ein Ausgangspunkt für die Sorgfaltsprüfung, kein Endpunkt.
Für Käufer, die überlegen, wie die Korrektheit der Dokumentation eines Anbieters in die Compliance-Lage spielt, behandelt unsere Analyse zur KI-Reife von Wissensdatenbanken die operativen Kontrollen, die SOC 2 nicht erreicht.
Die Korrektheitslücke: SOC 2 verlangt keine korrekte Dokumentation
Diesen Teil übersehen die meisten Käufer. SOC-2-Kontrollen decken Zugriff, Änderungsmanagement, Verschlüsselung, Lieferantenmanagement, Vorfallbearbeitung und Verfügbarkeit ab. Sie decken nicht ab, ob die Artikel in deinem Help Center noch stimmen.
Ein nach SOC 2 Type II geprüfter Anbieter kann ein Help Center betreiben, in dem 40 Prozent der Artikel einen Ablauf beschreiben, der im letzten Release anders ausgeliefert wurde. Die Prüfung schaut darauf nicht. Sie bestätigt, dass Änderungen an Artikeln protokolliert wurden, dass die ändernden Personen autorisiert waren, dass das System verfügbar war und dass die Daten verschlüsselt waren. Sie bestätigt nicht, dass der Inhalt zum Produkt passt.
Korrektheit ist keine SOC-2-Kontrolle. Sie ist eine Produktkontrolle. Du erreichst sie, indem du die Schleife zwischen Produktänderungen und Doku-Änderungen schließt. Ist deine Wissensdatenbank ein von der Codebasis getrenntes System, ist diese Schleife manuell. Manuelle Schleifen brechen unter Auslieferungstempo.
Unser Beitrag zu wie ein selbst aktualisierendes Help Center funktioniert geht die Architektur durch, die diese Schleife schließt. Kurzfassung: Artikel müssen wissen, welchen Code sie beschreiben. Ändert sich der Code, aktualisiert sich der Artikel automatisch oder meldet sich zur Prüfung. Ohne diese Verdrahtung schützt SOC-2-Konformität Zugriff und Verschlüsselung, aber nicht die Korrektheit.
Dasselbe Prinzip gilt dafür, wie Inhalte für die Nutzung durch KI strukturiert sind. Unsere Analyse zur Struktur einer Wissensdatenbank für KI-Chatbots behandelt die Metadaten und Aktualitätssignale, die darüber entscheiden, ob veraltete Inhalte als Tatsache zitiert werden. SOC 2 prüft davon nichts.
Das ist die Lücke. SOC 2 hält die falschen Menschen aus deinem Help Center heraus. Es hält keine falschen Informationen darin auf.
Wie HappySupport mit SOC 2 und der Korrektheitslücke umgeht
HappySupport fährt ein SOC-2-Type-II-Programm für Sicherheit, Verfügbarkeit und Vertraulichkeit. Der Bericht ist unter Verschwiegenheitsvereinbarung über unser Trust-Portal verfügbar. Kundschaft kann Bericht, Bridge Letter und Zusammenfassung anfordern. Wir veröffentlichen Prüfzeitraum und Name der Prüfstelle im Bericht. Gehostet wird auf AWS in der EU-Region. Daten sind in der Übertragung (TLS 1.3) und im Ruhezustand (AES-256) verschlüsselt. Der Zugriff läuft über rollenbasierte Kontrollen, verpflichtende Mehrfaktor-Authentifizierung für alle Administrationskonten, quartalsweise Zugriffsprüfungen und vollständige Audit-Logs mit 12 Monaten Aufbewahrung.
Das SOC-2-Programm deckt unsere Plattform ab. Die Korrektheitslücke deckt das Produkt selbst ab. Die Artikel von HappySupport sind an den Code gebunden, der im zugrunde liegenden Produkt ausgeliefert wird. Ändert sich das Produkt, tauchen die betroffenen Artikel zur Prüfung auf. Die Verbindung zwischen Code und Dokumentation ist technisch, nicht prozedural. Das ist die Schicht, die SOC 2 nicht erreicht, und die Schicht, die den meisten Help Centern fehlt.
Wenn du Anbieter für Wissensdatenbanken oder Help Center bewertest und dir Compliance und operative Korrektheit gleichermaßen wichtig sind, vergleicht unser Beitrag zur besten Wissensdatenbank-Software 2026 die Abwägungen über die großen Optionen hinweg. Compliance ist eine Spalte. Korrektheit ist die Spalte, die oft fehlt.
Häufige Fragen
Was ist SOC 2 Type II für eine Wissensdatenbank?
Ein SOC-2-Type-II-Bericht ist die Bewertung der Sicherheits- und Betriebskontrollen eines Anbieters durch eine unabhängige Prüfstelle über einen Zeitraum von 6 bis 12 Monaten. Er belegt, dass die Kontrollen richtig entworfen waren und im gesamten Prüffenster wirksam liefen. Bei einer Wissensdatenbank betreffen die relevanten Kontrollen Zugriff, Änderungsmanagement, Verschlüsselung, Audit-Logs und Vorfallbearbeitung.
Ist SOC 2 für Wissensdatenbanken im Gesundheitswesen Pflicht?
SOC 2 ist im Gesundheitswesen nicht Pflicht, HIPAA schon. SOC 2 und HIPAA sind getrennte Regelwerke. Käufer im Gesundheitswesen brauchen einen Anbieter, der beides unterstützt: einen SOC-2-Type-II-Bericht für allgemeine Sicherheitskontrollen sowie eine Vereinbarung als Business Associate plus HIPAA-konforme Konfiguration für geschützte Gesundheitsdaten. Viele Anbieter bieten beides. Kläre es vor der Unterschrift.
Wie fordere ich einen SOC-2-Bericht bei einem Anbieter an?
Die meisten Anbieter stellen ihren SOC-2-Type-II-Bericht hinter einer Verschwiegenheitsvereinbarung in einem Trust-Portal bereit (Conveyor, Vanta, SafeBase, Whistic). Suche die Trust-Seite unter trust.[anbieter].com oder [anbieter].com/security, stelle eine Anfrage mit den Angaben zu deinem Unternehmen, akzeptiere die Vereinbarung und lade den Bericht herunter. Ist kein Portal sichtbar, schreib direkt an den Sicherheits- oder Vertriebskontakt.
Was ist der Unterschied zwischen SOC 2, ISO 27001 und HIPAA?
SOC 2 ist ein aus den USA stammendes Berichtsrahmenwerk für Kontrollen auf Basis der Trust Services Criteria des AICPA. ISO 27001 ist eine internationale Zertifizierung für Managementsysteme der Informationssicherheit. HIPAA ist US-amerikanisches Gesundheitsrecht für geschützte Gesundheitsdaten. Sie sind nicht austauschbar. SOC-2-Berichte zeigen Belege für Kontrollen. ISO 27001 zertifiziert das Managementsystem. HIPAA definiert rechtliche Pflichten im Umgang mit Gesundheitsdaten. Reife Anbieter halten oft alle drei.
Welche Wissensdatenbank-Werkzeuge haben aktuelle SOC-2-Berichte?
Stand Mai 2026 weisen Help Scout, Zendesk, HubSpot, Intercom und Document360 auf ihren Trust-Seiten SOC 2 Type II aus und stellen Berichte unter Verschwiegenheitsvereinbarung bereit. KnowledgeOwl und Helpjuice haben an den üblichen Sicherheitsadressen keine öffentlichen SOC-2-Type-II-Aussagen und sollten direkt gefragt werden. Der Status ändert sich. Prüfe immer den Prüfzeitraum und fordere ein Bridge Letter an, wenn der Bericht älter als sechs Monate ist.
Demo buchen