SOC 1 Berichte,
verständlich erklärt

SOC 1 ist ein Attestierungsbericht über die Controls einer Dienstleistungsorganisation, die für die interne Kontrolle über die Finanzberichterstattung ihrer Kunden relevant sind. Die AICPA nennt ihn einen "report on controls at a service organization relevant to user entities’ internal control over financial reporting", was ein Zungenbrecher ist, weshalb alle SOC 1 sagen. Die Prüfung erfolgt nach dem Attestierungsstandard SSAE 18, konkret AT-C Section 320, durch eine lizenzierte CPA-Firma, und das Ergebnis ist ein Bericht mit dem Urteil dieser Firma.

Der entscheidende Begriff ist "user entities". Eine User Entity ist ein Kunde, der sich so auf Ihren Service verlässt, dass es seinen eigenen Jahresabschluss betrifft: Sie führen seine Lohnbuchhaltung, verwalten seinen Fonds, verarbeiten seine Zahlungen, berechnen seine Schadenfälle oder hosten das System, von dem sein Hauptbuch abhängt. Seine Prüfer müssen sich ein Urteil über Controls bilden, die sie nicht sehen können, weil diese Controls in Ihrer Organisation liegen. Ein SOC 1 Bericht ist der Weg, dieses Urteil zu bekommen, ohne Sie selbst zu prüfen.

Wie jeder SOC Bericht ist SOC 1 keine Zertifizierung. Niemand ist "SOC 1 certified", und es gibt kein Zertifikat zum Einrahmen. Was Sie nach der Prüfung haben, ist ein Bericht: eine Beschreibung Ihres Systems, die von Ihnen gesetzten Kontrollziele, die Controls dahinter, die vom Prüfer durchgeführten Tests und das Urteil, zu dem er gelangt ist. Dieser Bericht ist das Produkt, und er ist das, was die Prüfer Ihrer Kunden tatsächlich lesen.

Jedes börsenkotierte Unternehmen, und viele private dazu, muss eine interne Kontrolle über die Finanzberichterstattung unterhalten: die Gesamtheit der Controls, die hinreichende Sicherheit gibt, dass der Jahresabschluss verlässlich ist. Ihre Prüfer testen diese Controls jedes Jahr. Läuft ein Teil des Prozesses bei einem externen Dienstleister, bleibt die Verantwortung für den Control beim Kunden, aber der Nachweis liegt bei Ihnen.

Bevor es SOC 1 gab, waren die Optionen schlecht. Entweder schickte der Prüfer jedes Kunden ein eigenes Team, um Ihre Controls zu testen, oder er nahm Sie beim Wort, oder er behandelte den ganzen ausgelagerten Prozess als ungeprüfte Blackbox und prüfte drumherum mehr. Ein SOC 1 Bericht gibt jedem dieser Prüfer eine einzige unabhängige Prüfung, auf die er sich verlassen kann, einmal durchgeführt, von einer Firma, die er an einen Berufsstandard binden kann.

Dieser Ursprung prägt alles am Bericht. Der Umfang richtet sich danach, was die Zahlen des Kunden betrifft, nicht danach, was ein Sicherheitsteam priorisieren würde. Gelesen wird er von Prüfern und Controllern, nicht von CISOs. Und der Bericht ist bewusst in der Verwendung eingeschränkt, weil sein Detailgrad für Leser gedacht ist, die sich bereits auf Ihren Service verlassen und genau verstehen müssen, wie er kontrolliert wird.

Ein Type 1 Bericht beschreibt Ihr System und sagt, ob die Controls, wie sie zu einem Stichtag ausgestaltet sind, geeignet sind, die Kontrollziele zu erreichen. Er ist eine Momentaufnahme. Der Prüfer untersucht die Ausgestaltung und die Beschreibung, nicht, ob die Controls am Vortag oder im Vormonat tatsächlich gelaufen sind.

Ein Type 2 Bericht deckt einen Zeitraum ab, üblicherweise sechs bis zwölf Monate, und ergänzt ein Urteil zur Wirksamkeit: Hat jeder Control in diesem Fenster tatsächlich und durchgängig funktioniert. Der Prüfer zieht über den ganzen Zeitraum Stichproben, von Abstimmungen und Zugriffsreviews bis zu Change-Tickets und Ausnahmeberichten, und berichtet die Ergebnisse Test für Test, einschliesslich aller gefundenen Abweichungen.

Dem Prüfer einer User Entity bringt ein Type 1 sehr wenig. Ein Control, der an einem Tag gut ausgestaltet war, sagt nichts über die elf Monate Transaktionen aus, die er prüft, deshalb verlangen Kunden Type 2 und deren Prüfer brauchen ihn. Type 1 ist ein sinnvoller erster Schritt, um die Beschreibung und die Kontrollziele festzulegen, aber selten das Ziel.

Hier unterscheidet sich SOC 1 am stärksten von SOC 2. SOC 2 bringt die Trust Services Criteria mit, eine veröffentlichte Liste, an der Sie gemessen werden. SOC 1 hat keine solche Liste. Sie, die Dienstleistungsorganisation, definieren die Kontrollziele, die Ihr System erreichen soll, und die Prüfung testet, ob Ihre Controls sie stützen. Das Management erklärt, dass die Ziele angemessen sind und die Controls sie erreichen, und der Prüfer gibt sein Urteil zu dieser Erklärung ab.

Die Ziele folgen dem Geld. Bei einem Lohnverarbeiter lauten sie etwa "Controls geben hinreichende Sicherheit, dass Löhne vollständig und korrekt berechnet und nur an berechtigte Mitarbeitende ausbezahlt werden". Bei einem Fondsadministrator decken sie Bewertungen, Kapitalabrufe und Anlegerzuteilungen ab. Neben diesen Geschäftszielen trägt jeder SOC 1 Ziele für die IT-Basiskontrollen, weil die Anwendungskontrollen darüber von ihnen abhängen: logischer Zugriff, Change Management, IT-Betrieb und Backup, oft auch physischer Zugang.

Gute Ziele zu formulieren ist der Grossteil der Designarbeit. Zu vage, und der Prüfer kann sie nicht testen; zu viele, und Sie haben sich verpflichtet, Controls nachzuweisen, die keinen Kunden interessieren. Das richtige Set ist das kleinste, das abdeckt, wonach die Prüfer Ihrer Kunden tatsächlich fragen werden, üblicherweise eine kurze Liste von Geschäftsprozesszielen plus die Handvoll IT-Basiskontrollziele, die diese Prozesse ehrlich halten.

Die Systembeschreibung ist das Rückgrat des Berichts. Sie sagt, welcher Service abgedeckt ist, welche Prozesse und Anwendungen ihn betreiben, welche Personen beteiligt sind, wie Transaktionen von der Auslösung bis zur Berichterstattung fliessen und welche Controls an jedem Schritt bestehen. Ein Leser muss eine Transaktion auf dem Papier durch Ihre Organisation verfolgen und sehen können, wo sie kontrolliert wird.

Der Umfang sollte den Services folgen, die in die Jahresabschlüsse der Kunden einfliessen, und dort aufhören. Eine Produktlinie, die Kunden für etwas nutzen, das nichts mit ihren Büchern zu tun hat, bringt Seiten und Nachweise, aber keine zusätzliche Sicherheit. Die Grenze entscheidet auch, worauf sich die Prüfer Ihrer Kunden verlassen können: Alles ausserhalb der Beschreibung ist für ihre Zwecke ungeprüft.

Die Frage ist, ob Ihr Output im Jahresabschluss eines Kunden landet. Lohn- und HR-Verarbeiter, Fondsadministratoren und Transfer Agents, Zahlungs- und Abrechnungsverarbeiter, Schaden- und Leistungsadministratoren, Kreditplattformen und Loan Servicer sowie Rechenzentren oder SaaS-Plattformen, die das Buchhaltungs-, Abrechnungs- oder Handelssystem eines Kunden hosten, gehören alle klar in diese Gruppe. Wenn der Prüfer eines Kunden Ihre Controls verstehen müsste, um dessen Zahlen zu testieren, werden Sie gefragt werden.

Die Anfrage kommt üblicherweise vom Finanzteam oder der Prüfungsgesellschaft eines Kunden, nicht vom Einkauf, und oft mit einer Frist, die am Jahresabschluss des Kunden hängt. Dieses Timing sollten Sie früh verstehen: Ein Type 2 muss einen Zeitraum abdecken, der sich mit dem Geschäftsjahr des Kunden überschneidet, ein erster Bericht muss also oft ein Jahr, bevor der Prüfer ihn braucht, geplant werden.

Viele Softwareunternehmen werden nach SOC 1 gefragt, wenn der Kunde eigentlich SOC 2 braucht, und umgekehrt. Eine direkte Frage klärt es: Betrifft Ihr Service die Beträge im Hauptbuch des Kunden oder die Sicherheit seiner Daten. Ersteres: SOC 1. Letzteres: SOC 2. Beides: Dann landen Sie vermutlich bei beiden Berichten, und die gute Nachricht ist, dass sie sich die meisten IT-Basiskontrollen teilen.

Nur eine unabhängige, lizenzierte CPA-Firma kann einen SOC 1 Bericht ausstellen, und diese Unabhängigkeit ist es, die den Prüfer eines Kunden darauf vertrauen lässt. Die Firma prüft Ihre Systembeschreibung und die Erklärung des Managements, testet die Controls hinter jedem Ziel und stellt einen Bericht mit Urteil aus. Bei einem Type 2 heisst das, Stichproben über den ganzen Zeitraum zu ziehen und jeden durchgeführten Test und jede gefundene Abweichung festzuhalten.

Das Urteil ist das Erste, was ein Leser aufschlägt. Ein uneingeschränktes Urteil sagt, dass die Beschreibung angemessen dargestellt ist, die Controls angemessen ausgestaltet sind und, bei einem Type 2, über den Zeitraum wirksam funktioniert haben. Ein eingeschränktes Urteil benennt ein Ziel, das nicht erreicht wurde, oder einen Control, der seine Tests nicht bestanden hat. Abweichungen führen nicht automatisch zu einer Einschränkung, aber jede wird aufgeführt, und die Prüfer Ihrer Kunden werden sie lesen und entscheiden, welche zusätzliche Arbeit sie auf ihrer Seite leisten müssen.

Diese Leser sind das Publikum, das Sie beim Schreiben der Beschreibung und beim Wählen der Ziele im Kopf behalten sollten. Es sind Controller und Abschlussprüfer, die Ihren Bericht auf ihr eigenes Prüfprogramm abbilden. Eine Beschreibung, die für einen Sicherheitsreviewer geschrieben ist, viel Architektur und wenig Transaktionsfluss, schickt sie mit Rückfragen zurück.

Ein Type 2 Bericht deckt einen Zeitraum ab, und Kunden brauchen einen Bericht für jedes ihrer Geschäftsjahre, SOC 1 wird also zum Jahreszyklus: jedes Jahr eine neue Prüfung, dieselben Controls in Betrieb, dieselben Nachweise aufbewahrt. Die Controls, die den ersten Bericht eingebracht haben, durchgeführte und geprüfte Abstimmungen, rezertifizierte Zugriffe, freigegebene und getestete Änderungen, verifizierte Backups, sind genau die, aus denen die nächste Prüfung Stichproben zieht. Teams, die sie als Teil des laufenden Geschäfts betreiben, erleben den Jahresbericht als weitgehend administrativ.

Die Lücke zwischen einem Berichtszeitraum und dem Jahresabschluss des Kunden deckt ein Bridge Letter ab, manchmal Gap Letter genannt: eine kurze Erklärung Ihres Managements, dass die im letzten Bericht beschriebenen Controls ohne wesentliche Änderung weiter funktioniert haben. Er trägt kein Prüfungsurteil, aber er ist es, was den Prüfer eines Kunden sein Vertrauen über die Monate ausdehnen lässt, die der Bericht nicht abdeckt, und die meisten Kunden werden einen verlangen.

Das Honorar des Prüfers skaliert mit der Zahl der Kontrollziele, der Komplexität der Transaktionsflüsse, der Zahl der Anwendungen im Umfang und damit, ob es ein Type 1 oder ein Type 2 ist. Ein Type 2 kostet mehr, weil ein Zeitraum an Nachweisen stichprobenweise zu prüfen ist statt eines einzelnen Stichtags. Einen Subdienstleister inklusiv statt per Carve-out zu behandeln, nimmt dessen Controls in Ihre Prüfung auf und verschiebt die Kosten entsprechend.

Wie bei jedem SOC Bericht liegen die grösseren Kosten auf Ihrer Seite: die Controls entwerfen, die Beschreibung schreiben, die Controls jeden Monat betreiben und die Nachweise in einer Form aufbewahren, aus der ein Prüfer Stichproben ziehen kann. Ein Jahr Abstimmungen und Zugriffsreviews zum Prüfungszeitpunkt aus E-Mails zu rekonstruieren, ist der Punkt, an dem Projekte im ersten Jahr Wochen verlieren. Diese Nachweise direkt beim Control abzulegen, während sie entstehen, macht das zweite Jahr günstiger als das erste.

Die zwei Hebel, die die Gesamtkosten bewegen, sind Umfang und Kontinuität. Beschränken Sie die Ziele auf das, was die Prüfer Ihrer Kunden brauchen, und halten Sie die Controls und ihre Nachweise zwischen den Prüfungen am Laufen, statt sie vor jeder neu aufzubauen. Der Grossteil der Kosten von SOC 1 sind die Kosten eines gut kontrollierten Services, und die hätten Sie ohnehin getragen.