Carte des contrôles · Critères Trust Services (2017)

SOC 2

Preuve issue du code pour les critères d’accès, de périmètre et de données confidentielles à chaque pull request, et preuve de processus pour les approbations de changements issue de chaque fusion.

Réserver un pilote d’audit Voir un exemple de rapport

SOC 2 · Critères Trust Services (2017)15 critères dans le périmètre · selon la correspondance de v1.4.1

Code 6
Processus 1
Prévu 8

Preuve issue du code

6critères vérifiés à chaque pull request

Actif (processus)

1issus des fusions, approbations, changements de règle et des déploiements et releases enregistrés par GitHub

Prévu

8peut être prouvé à partir du code ou de GitHub ; pas encore construit

Critères au niveau de l’organisation

Politiques, personnes, fournisseurs, sécurité physique et le reste, listés ci-dessous.Gérés par les processus de votre organisation

Un rapport SOC 2 Type II teste si les contrôles ont fonctionné tout au long d’une période. Les approbations de changements sont souvent ce qui prend le plus de temps d’audit aux équipes d’ingénierie, qui rassemblent tickets et captures d’écran pour un échantillon de changements.

Le blueprint SOC 2 apporte une preuve issue du code pour les critères d’accès, de périmètre et de données confidentielles à chaque pull request. Chaque pull request fusionnée dans la branche par défaut est scellée en enregistrement de changement avec ses approbations, ses checks et ses signatures : une preuve pour CC8.1. La carte complète figure ci-dessous, suivie des critères au niveau de l’organisation.

Toevan apporte des preuves pour des contrôles ; il ne les certifie jamais et ne prétend pas qu’un référentiel est couvert. Que les preuves suffisent relève du jugement de votre auditeur. Les contrôles sont affichés par id avec les noms courts propres à Toevan ; les titres officiels et le texte des exigences appartiennent à l’éditeur du référentiel.

Preuve issue du code6

Scellée à chaque pull request. Toujours partielle : le contrôle exige aussi des éléments hors du code. Les règles du blueprint SOC 2 vérifient une partie de chacun à chaque pull request.

CC6.1Conception des limites d’accèsCC6 Protection des accès
CC6.3Changements de droits par rôleCC6 Protection des accès
CC6.6Défense contre les menaces externesCC6 Protection des accès
CC6.7Limites de circulation des donnéesCC6 Protection des accès
C1.1Marquage des données confidentiellesC1 Données confidentielles
C1.2Élimination des données confidentiellesC1 Données confidentielles

Actif (processus)1

Pull requests fusionnées, approbations, checks requis, protection de branche, rulesets et contournements, et déploiements et releases enregistrés par GitHub, chacun scellé.

CC8.1Approbations de changementsCC8 Gestion des changementsPreuve de processus : chaque pull request fusionnée dans la branche par défaut est scellée en enregistrement de changement avec ses approbations sur le dernier commit, les checks requis à la fusion, la personne qui l’a fusionnée, ses signatures et les verdicts de code qu’elle portait.

Enregistrement de changement rec_5b81d4e

données d’exemple

Pull request payments-api #1921 · Add tenant check to refund handlerRapporté + scellé

Approbations 9d07…e3a4, c58f…71d0 · toutes deux sur le commit final e81b2d0Rapporté + scellé

Indépendant de l’auteur Oui, par identifiant de compte GitHubRecalculé

Checks requis ci/test ✓ · ci/lint ✓ · toevan/gate ✓Rapporté + scellé

Règles en vigueur main-protection : 2 approbations, checks requis, commits signésRapporté + scellé

Prévu8

Peut être prouvé à partir du code ou de GitHub. Aucune règle ne les vérifie encore ; chacun est prévu, et aucun ne compte aujourd’hui comme preuve.

CC6.2Émission des identifiants utilisateurCC6 Protection des accès
CC7.1Suivi des dérives de faiblessesCC7 Opérations de sécurité
CC7.2Suivi des anomaliesCC7 Opérations de sécurité
A1.2Garanties de sauvegardeA1 Capacité et sauvegarde
PI1.2Entrées complètes et exactesPI1 Exactitude du traitement
PI1.3Pertes et erreurs de traitementPI1 Exactitude du traitement
P4.2Conservation des données personnellesP4 Usage et conservation
P4.3Élimination des données personnellesP4 Usage et conservation

Critères au niveau de l’organisation

Les contrôles au niveau de l’organisation (politiques, personnes, fournisseurs, sécurité physique et le reste) restent dans le processus propre à votre organisation ; Toevan ne s’en charge pas.

Afficher la liste

CC1 Conduite de la direction

CC1.1Engagement de conduitede la politique de l’organisation

CC1.2Supervision du conseilde la politique de l’organisation

CC1.3Lignes hiérarchiquesde la politique de l’organisation

CC1.4Recrutement de personnel compétentdes personnes et des RH

CC1.5Responsabilité des tâchesdes personnes et des RH

CC2 Partage d’information

CC2.1Information fiable sur les contrôlesde la politique de l’organisation

CC2.2Information du personnel sur ses tâchesde la politique de l’organisation

CC2.3Échanges avec les tiersde la politique de l’organisation

CC3 Examen des risques

CC3.1Objectifs de risquede la politique de l’organisation

CC3.2Évaluation des risquesde la politique de l’organisation

CC3.3Examen du risque de fraudede la politique de l’organisation

CC3.4Examen de l’impact des changementsde la politique de l’organisation

CC4 Suivi des contrôles

CC4.1Revues continues des contrôlesd’un processus opérationnel

CC4.2Signalement des faiblessesd’un processus opérationnel

CC5 Choix des contrôles

CC5.1Contrôles de réduction des risquesde la politique de l’organisation

CC5.2Choix des contrôles technologiquesde la politique de l’organisation

CC5.3Politiques déployéesde la politique de l’organisation

CC6 Protection des accès

CC6.4Limites d’accès physiquede la sécurité physique

CC6.5Élimination des données des actifsde la sécurité physique

CC6.8Blocage des logiciels indésirablesd’un processus opérationnel

CC7 Opérations de sécurité

CC7.3Évaluation des événementsd’un processus opérationnel

CC7.4Étapes de réponse aux incidentsd’un processus opérationnel

CC7.5Retour d’expérience après incidentd’un processus opérationnel

CC9 Risque fournisseur

CC9.1Réduction du risque de perturbationde la politique de l’organisation

CC9.2Gestion du risque fournisseurdes contrats et des fournisseurs

A1 Capacité et sauvegarde

A1.1Suivi de la capacitéd’un processus opérationnel

A1.3Tests de restaurationd’un processus opérationnel

PI1 Exactitude du traitement

PI1.1Objectifs de traitement définisd’un processus opérationnel

PI1.4Revue de la livraison des sortiesd’un processus opérationnel

PI1.5Intégrité des éléments stockésd’un processus opérationnel

P1 Obligations d’information

P1.1Avis de confidentialitéde la politique de l’organisation

P2 Obligations de choix

P2.1Choix de consentementde la politique de l’organisation

P3 Obligations de collecte

P3.1Collecte licitede la politique de l’organisation

P3.2Consentement explicite sensiblede la politique de l’organisation

P4 Usage et conservation

P4.1Limites de finalité annoncéede la politique de l’organisation

P5 Demandes individuelles

P5.1Réponses aux demandes d’accèsd’un processus opérationnel

P5.2Traitement des rectificationsd’un processus opérationnel

P6 Obligations de partage

P6.1Consentement avant partagede la politique de l’organisation

P6.2Registre des partagesde la politique de l’organisation

P6.3Registre des partages non autorisésde la politique de l’organisation

P6.4Engagements des fournisseursdes contrats et des fournisseurs

P6.5Incidents signalés par fournisseursdes contrats et des fournisseurs

P6.6Notifications de violationd’une procédure réglementaire

P6.7Comptabilité des partagesd’un processus opérationnel

P7 Qualité des données

P7.1Exactitude des données personnellesd’un processus opérationnel

P8 Traitement des réclamations

P8.1Traitement des réclamationsd’un processus opérationnel

L’utiliser dans un audit

Prenez la population dans les enregistrements de changement
Chaque pull request fusionnée dans la branche par défaut et chaque push vers une branche protégée qu’aucune pull request fusionnée n’explique, sur la période, capturés depuis GitHub au fil de l’eau, forment un enregistrement scellé que vous pouvez exporter pour échantillonner. Vous pouvez refaire la population de la branche par défaut à partir de l’historique git ; les branches de production désignées sont prévues.
Lisez les preuves issues du code pour la période
Chaque pull request porte des résultats de code scellés par rapport aux règles du blueprint, rattachés au commit et à la version du jeu de règles en vigueur.
Testez un échantillon
Pour chaque enregistrement échantillonné, vérifiez ses résultats, puis vérifiez-le hors ligne avec la clé publiée, avec openssl et le shell : récupérez la preuve, confirmez la clé, contrôlez l’enregistrement. Pour rejouer toute la chaîne, Toevan fournit la commande toevan sur demande ; elle n’est pas encore publique.
Les trois étapes, avec les commandes exactes

Comment chaque fait a été obtenu6 étiquettes

Recalculé: Toevan l’a calculé lui-même à partir du code ou de l’historique git.
Rapporté + scellé: GitHub l’a rapporté ; Toevan l’a capturé au moment de l’événement et signé.
Déclaré + scellé: L’organisation l’a déclaré, par exemple un changement de ce qui est vérifié ; Toevan a signé la déclaration et son historique.
Enregistrement Toevan, non scellé: Conservé dans la base de données de Toevan mais non scellé dans le registre, comme une dérogation aujourd’hui. Aucune signature ne le protège.
Consommé: Repris des enregistrements de déploiement et de release de GitHub et relié par commit ou empreinte.
Non capturé: Aucune source fiable n’était disponible. Toevan ne le déduit pas.

CC8.1Approbations de changementsFeuille de test · données d’exemple

Population148 changements : 146 pull requests fusionnées et 2 pushes directs
Recalculé listée à partir de l’historique git et rapprochée des enregistrements scellés

Échantillon25 tirés par l’auditeur, chacun un enregistrement scellé

ApprobationsRapporté + scellé depuis GitHub à la fusion, indépendantes de l’auteur

ExceptionsSans PR 2 pushes directs le 19 sept.Écart exigence de revue désactivée pendant 29 minutesLes deux figurent dans l’enregistrement.

Signatures25 / 25 ✓ Verified OK

L’exemple de rapport de preuves de changement montre les preuves telles que votre auditeur les reçoit, chaque fait étant étiqueté.Ouvrir l’exemple de rapport

Testez la correspondance sur un vrai audit.

Venez avec un dépôt et un audit à venir. Nous configurerons le blueprint et guiderons votre auditeur dans la vérification.

Réserver un pilote d’audit Voir un exemple de rapport

Un dépôt, un référentiel
Des preuves dès la première pull request
Vérifiable sans compte Toevan