Zum Inhalt springen
toevan
AnmeldenAudit-Pilot buchen
Menü öffnenMenü schließen
Audit-Pilot buchen

Control-Map · Trust Services Criteria (2017)

SOC 2

Audit-Pilot buchenBeispielbericht ansehen

8 von 15 Controls für SOC 2, die Code belegen kann, mit v1.4.0, plus 1 unterstützend

Code-Nachweis heute für Zugriffs-, Abgrenzungs- und Vertraulichkeitskriterien; Änderungsfreigaben mit Prozessnachweis in v1.4.0.

  • Live7
  • Kommt in v1.4.01
  • Unterstützend1
  • Geplant7
  • Ihre Organisation45
  1. 7 mit Code-Nachweis heuteTeilnachweis, bei jedem Pull Request geprüft.
  2. 1 weitere in v1.4.0Prozessnachweis aus Merges, Freigaben und Regeländerungen.
  3. 45 bleiben bei Ihrer OrganisationUnten vollständig aufgelistet, damit nichts angedeutet wird.

Ein SOC-2-Type-II-Bericht prüft, ob Controls über einen Zeitraum hinweg gewirkt haben. Bei Änderungsfreigaben verbringen Engineering-Teams im Audit meist die meiste Zeit: Sie sammeln Tickets und Screenshots für eine Stichprobe von Änderungen.

Heute liefert der SOC-2-Blueprint bei jedem Pull Request Code-Nachweise für sieben Kriterien. Ab v1.4.0 wird jeder gemergte Pull Request als Änderungseintrag mit Freigaben, Checks und Signaturen versiegelt: Nachweis für CC8.1. Die vollständige Map steht unten, einschließlich der 45 Kriterien, die bei Ihrer Organisation bleiben.

Toevan liefert Nachweise für Controls; es zertifiziert sie nie und behauptet nie, ein Framework sei abgedeckt. Ob die Nachweise genügen, beurteilt Ihr Auditor.

Controls erscheinen mit ID und Toevans eigenen Kurznamen. Die offiziellen Titel und Anforderungstexte gehören dem Herausgeber des Frameworks.

Live7

Code-Nachweis heute, bei jedem Pull Request versiegelt. Immer nur teilweise: Das Control verlangt auch Dinge außerhalb des Codes. Code-Nachweis heute: Regeln im Blueprint SOC 2 prüfen einen Teil davon bei jedem Pull Request.

  • CC6.1

    Gestaltung von Zugriffsgrenzen

    CC6 Zugriffsschutz

  • CC6.3

    Änderung von Rollenrechten

    CC6 Zugriffsschutz

  • CC6.6

    Schutz vor externen Bedrohungen

    CC6 Zugriffsschutz

  • CC6.7

    Grenzen der Datenbewegung

    CC6 Zugriffsschutz

  • CC7.2

    Überwachung von Anomalien

    CC7 Sicherheitsbetrieb

  • C1.1

    Kennzeichnung vertraulicher Daten

    C1 Vertrauliche Daten

  • C1.2

    Entsorgung vertraulicher Daten

    C1 Vertrauliche Daten

Kommt in v1.4.01

Prozessnachweis: gemergte Pull Requests, Freigaben, Pflicht-Checks, Branch-Schutz, Rulesets und Umgehungen, pro Änderung versiegelt.

  • CC8.1

    Änderungsfreigaben

    CC8 Änderungsabwicklung

    Prozessnachweis: Jeder gemergte Pull Request wird als Änderungseintrag versiegelt, mit seinen Freigaben auf dem finalen Commit, den Pflicht-Checks beim Merge, der mergenden Person, seinen Signaturen und den mitgeführten Code-Urteilen.

Unterstützend1

Toevan erfasst verwandte Nachweise, heute oder in v1.4.0, doch die Pflicht liegt bei der Organisation und gilt deshalb nie als abgedeckt.

  • CC7.4

    Schritte der Incident Response

    CC7 Sicherheitsbetrieb

    Unterstützender Nachweis heute: Eine Regel erfasst Nachweise zu dieser Pflicht. Die Pflicht selbst betrifft einen betrieblichen Prozess.

Geplant7

Lässt sich aus Code oder GitHub belegen. Die Regel oder die Zuordnung ist noch nicht gebaut.

  • CC6.2

    Vergabe von Zugangsdaten

    CC6 Zugriffsschutz

  • CC7.1

    Überwachung von Schwachstellen-Drift

    CC7 Sicherheitsbetrieb

  • A1.2

    Schutz von Backups

    A1 Kapazität und Backup

  • PI1.2

    Vollständige, korrekte Eingaben

    PI1 Verarbeitungsgenauigkeit

  • PI1.3

    Verlustfehler in der Verarbeitung

    PI1 Verarbeitungsgenauigkeit

  • P4.2

    Aufbewahrung personenbezogener Daten

    P4 Nutzung und Aufbewahrung

  • P4.3

    Löschung personenbezogener Daten

    P4 Nutzung und Aufbewahrung

Ihre Organisation45

Richtlinien, Personal, physische Sicherheit, Verträge, regulatorische Verfahren, Betrieb oder externe Prüfung. Diese belegt Ihre Organisation.

Alle 45 Controls anzeigen

CC1 Verhalten der Leitung

  • CC1.1Verpflichtung zu Integritätdie Richtlinien der Organisation
  • CC1.2Aufsicht durch das Leitungsorgandie Richtlinien der Organisation
  • CC1.3Berichtsliniendie Richtlinien der Organisation
  • CC1.4Einstellung geeigneter MitarbeiterPersonal und HR
  • CC1.5Rechenschaft für AufgabenPersonal und HR

CC2 Informationsaustausch

  • CC2.1Gute Control-Informationendie Richtlinien der Organisation
  • CC2.2Unterweisung der Mitarbeiterdie Richtlinien der Organisation
  • CC2.3Austausch mit Externendie Richtlinien der Organisation

CC3 Risikoprüfung

  • CC3.1Risikozieledie Richtlinien der Organisation
  • CC3.2Risikobewertungdie Richtlinien der Organisation
  • CC3.3Betrugsrisiko-Prüfungdie Richtlinien der Organisation
  • CC3.4Prüfung von Änderungsfolgendie Richtlinien der Organisation

CC4 Control-Überwachung

  • CC4.1Laufende Control-Prüfungeneinen betrieblichen Prozess
  • CC4.2Meldung von Schwächeneinen betrieblichen Prozess

CC5 Control-Auswahl

  • CC5.1Risikomindernde Controlsdie Richtlinien der Organisation
  • CC5.2Wahl technischer Controlsdie Richtlinien der Organisation
  • CC5.3Eingeführte Richtliniendie Richtlinien der Organisation

CC6 Zugriffsschutz

  • CC6.4Physische Zutrittsgrenzendie physische Sicherheit
  • CC6.5Entsorgung von Asset-Datendie physische Sicherheit
  • CC6.8Blockierung unerwünschter Softwareeinen betrieblichen Prozess

CC7 Sicherheitsbetrieb

  • CC7.3Bewertung von Ereignisseneinen betrieblichen Prozess
  • CC7.5Lernen aus Incident-Recoveryeinen betrieblichen Prozess

CC9 Lieferantenrisiko

  • CC9.1Minderung von Störungsrisikendie Richtlinien der Organisation
  • CC9.2Management von LieferantenrisikenVerträge und Lieferanten

A1 Kapazität und Backup

  • A1.1Kapazitätsüberwachungeinen betrieblichen Prozess
  • A1.3Wiederherstellungstestseinen betrieblichen Prozess

PI1 Verarbeitungsgenauigkeit

  • PI1.1Definierte Verarbeitungszieleeinen betrieblichen Prozess
  • PI1.4Prüfung der Ausgabelieferungeinen betrieblichen Prozess
  • PI1.5Integrität gespeicherter Objekteeinen betrieblichen Prozess

P1 Hinweispflichten

  • P1.1Datenschutzhinweisdie Richtlinien der Organisation

P2 Wahlpflichten

  • P2.1Einwilligungsoptionendie Richtlinien der Organisation

P3 Erhebungspflichten

  • P3.1Rechtmäßige Erhebungdie Richtlinien der Organisation
  • P3.2Einwilligung bei sensiblen Datendie Richtlinien der Organisation

P4 Nutzung und Aufbewahrung

  • P4.1Zweckbindungdie Richtlinien der Organisation

P5 Anfragen Einzelner

  • P5.1Antworten auf Auskunftsanfrageneinen betrieblichen Prozess
  • P5.2Umgang mit Berichtigungeneinen betrieblichen Prozess

P6 Weitergabepflichten

  • P6.1Einwilligung vor Weitergabedie Richtlinien der Organisation
  • P6.2Weitergabeprotokolledie Richtlinien der Organisation
  • P6.3Protokolle unbefugter Weitergabedie Richtlinien der Organisation
  • P6.4Datenschutzzusagen von LieferantenVerträge und Lieferanten
  • P6.5Incident-Meldung von LieferantenVerträge und Lieferanten
  • P6.6Benachrichtigung bei Datenpannenein regulatorisches Verfahren
  • P6.7Nachweis über Weitergabeneinen betrieblichen Prozess

P7 Datenqualität

  • P7.1Richtige personenbezogene Dateneinen betrieblichen Prozess

P8 Umgang mit Beschwerden

  • P8.1Umgang mit Beschwerdeneinen betrieblichen Prozess

Im Audit nutzen

  1. Grundgesamtheit aus den Änderungseinträgen entnehmen (ab v1.4.0)

    Jeder Merge in einen geschützten Branch und jeder direkte Push im Zeitraum, beim Eintreten aus GitHub erfasst, ist ein versiegelter Eintrag, den Sie für die Stichprobe exportieren können. Die Grundgesamtheit des Standard-Branches können Sie aus der Git-Historie nachvollziehen; festgelegte Produktions-Branches sind für v1.4.1 geplant.

  2. Code-Nachweise des Zeitraums lesen

    Jeder Pull Request trägt versiegelte Code-Ergebnisse zu den Regeln des Blueprints, festgemacht am Commit und an der geltenden Regelsatz-Version.

  3. Stichprobe testen

    Prüfen Sie für jeden gezogenen Eintrag das Ergebnis, dann Signatur und Platz in der Kette offline.

    toevan audit verify --path evidence-clone --pub-key toevan.pub

Wie jeder Fakt erhoben wurde

Jeder Fakt in einem Eintrag und einem Bericht trägt eines von sechs Labels, damit Ihr Auditor weiß, wie weit er sich darauf stützen kann.

Neu berechnet
Toevan hat es selbst aus Code oder Git-Historie berechnet.
Mit denselben Eingaben nachvollziehen und dasselbe Ergebnis erhalten.
Gemeldet + versiegelt
GitHub hat es gemeldet; Toevan hat es beim Ereignis erfasst und signiert.
Verlassen Sie sich darauf, soweit Sie GitHub vertrauen. Jede spätere Änderung ist erkennbar.
Erklärt + versiegelt
Die Organisation hat es erklärt, etwa eine Änderung dessen, was geprüft wird; Toevan hat die Erklärung und ihre Historie signiert.
Sehen Sie, wer was wann erklärt hat, und jede spätere Änderung.
Toevan-Eintrag, nicht versiegelt
In der Datenbank von Toevan gespeichert, aber nicht im Ledger versiegelt, etwa eine Ausnahmegenehmigung heute. Keine Signatur schützt ihn.
Behandeln Sie ihn als Aussage von Toevan und fragen Sie die Organisation nach der Freigabe dahinter.
Übernommen
Aus dem signierten Eintrag eines anderen Systems übernommen, etwa einer Build-Provenienz, und per Commit oder Digest verknüpft. Geplant.
Den Originaleintrag unabhängig prüfen.
Nicht erfasst
Es gab keine verlässliche Quelle. Toevan schließt nichts daraus.
Auf anderem Weg bei der Organisation einholen.

Im Bericht ansehen

Der Beispielbericht zeigt den Nachweis so, wie Ihr Auditor ihn erhält, jeder Fakt mit Label.

Beispielbericht öffnen

Testen Sie die Zuordnung an einem echten Audit.

Bringen Sie ein Repository und ein anstehendes Audit mit. Wir richten den Blueprint ein und führen Ihren Auditor durch die Prüfung.

Audit-Pilot buchenBeispielbericht ansehen