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.
Aujourd’hui, le blueprint SOC 2 apporte une preuve issue du code pour sept critères à chaque pull request. À partir de v1.4.0, chaque pull request fusionnée 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, y compris les 45 critères qui restent à votre 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 présentés par identifiant avec les noms courts propres à Toevan. Les titres officiels et le texte des exigences appartiennent à l’éditeur du référentiel.
Actif7
Preuve issue du code dès aujourd’hui, scellée à chaque pull request. Toujours partielle : le contrôle exige aussi des éléments hors du code. Preuve issue du code dès aujourd’hui : les règles du blueprint SOC 2 vérifient une partie de ce point à chaque pull request.
CC6.1Conception des limites d’accès
CC6 Protection des accès
CC6.3Changements de droits par rôle
CC6 Protection des accès
CC6.6Défense contre les menaces externes
CC6 Protection des accès
CC6.7Limites de circulation des données
CC6 Protection des accès
CC7.2Suivi des anomalies
CC7 Opérations de sécurité
C1.1Marquage des données confidentielles
C1 Données confidentielles
C1.2Élimination des données confidentielles
C1 Données confidentielles
Prévu pour v1.4.01
Preuve de processus : pull requests fusionnées, approbations, checks requis, protection de branche, rulesets et contournements, scellés par changement.
CC8.1Approbations de changements
CC8 Gestion des changements
Preuve de processus : chaque pull request fusionnée 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.
En appui1
Toevan enregistre des preuves connexes, aujourd’hui ou dans v1.4.0, mais l’obligation relève de l’organisation : elle n’est donc jamais comptée comme couverte.
CC7.4Étapes de réponse aux incidents
CC7 Opérations de sécurité
Preuve d’appui dès aujourd’hui : une règle enregistre des preuves liées à cette obligation. L’obligation elle-même relève d’un processus opérationnel.
Prévu7
Peut être prouvé à partir du code ou de GitHub. La règle ou la correspondance n’est pas encore construite.
CC6.2Émission des identifiants utilisateur
CC6 Protection des accès
CC7.1Suivi des dérives de faiblesses
CC7 Opérations de sécurité
A1.2Garanties de sauvegarde
A1 Capacité et sauvegarde
PI1.2Entrées complètes et exactes
PI1 Exactitude du traitement
PI1.3Pertes et erreurs de traitement
PI1 Exactitude du traitement
P4.2Conservation des données personnelles
P4 Usage et conservation
P4.3Élimination des données personnelles
P4 Usage et conservation
Votre organisation45
Politique, personnes, sécurité physique, contrats, procédure réglementaire, exploitation ou audit externe. Votre organisation en apporte la preuve.
Afficher les 45 contrôles
CC1 Conduite de la direction
CC1.1Engagement de conduitede la politique de l’organisationCC1.2Supervision du conseilde la politique de l’organisationCC1.3Lignes hiérarchiquesde la politique de l’organisationCC1.4Recrutement de personnel compétentdes personnes et des RHCC1.5Responsabilité des tâchesdes personnes et des RH
CC2 Partage d’information
CC2.1Information fiable sur les contrôlesde la politique de l’organisationCC2.2Information du personnel sur ses tâchesde la politique de l’organisationCC2.3Échanges avec les tiersde la politique de l’organisation
CC3 Examen des risques
CC3.1Objectifs de risquede la politique de l’organisationCC3.2Évaluation des risquesde la politique de l’organisationCC3.3Examen du risque de fraudede la politique de l’organisationCC3.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érationnelCC4.2Signalement des faiblessesd’un processus opérationnel
CC5 Choix des contrôles
CC5.1Contrôles de réduction des risquesde la politique de l’organisationCC5.2Choix des contrôles technologiquesde la politique de l’organisationCC5.3Politiques déployéesde la politique de l’organisation
CC6 Protection des accès
CC6.4Limites d’accès physiquede la sécurité physiqueCC6.5Élimination des données des actifsde la sécurité physiqueCC6.8Blocage des logiciels indésirablesd’un processus opérationnel
CC7 Opérations de sécurité
CC7.3Évaluation des événementsd’un processus opérationnelCC7.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’organisationCC9.2Gestion du risque fournisseurdes contrats et des fournisseurs
A1 Capacité et sauvegarde
A1.1Suivi de la capacitéd’un processus opérationnelA1.3Tests de restaurationd’un processus opérationnel
PI1 Exactitude du traitement
PI1.1Objectifs de traitement définisd’un processus opérationnelPI1.4Revue de la livraison des sortiesd’un processus opérationnelPI1.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’organisationP3.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érationnelP5.2Traitement des rectificationsd’un processus opérationnel
P6 Obligations de partage
P6.1Consentement avant partagede la politique de l’organisationP6.2Registre des partagesde la politique de l’organisationP6.3Registre des partages non autorisésde la politique de l’organisationP6.4Engagements des fournisseursdes contrats et des fournisseursP6.5Incidents signalés par fournisseursdes contrats et des fournisseursP6.6Notifications de violationd’une procédure réglementaireP6.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 (à partir de v1.4.0)
Chaque fusion dans une branche protégée et chaque push direct de 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 pour v1.4.1.
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 sa signature et sa place dans la chaîne, hors ligne.
toevan audit verify --path evidence-clone --pub-key toevan.pub
Comment chaque fait a été obtenu
Chaque fait d’un enregistrement et d’un rapport porte l’une de six étiquettes, pour que votre auditeur sache dans quelle mesure s’y fier.
- Recalculé
- Toevan l’a calculé lui-même à partir du code ou de l’historique git.
- Le refaire à partir des mêmes entrées et obtenir le même résultat.
- Rapporté + scellé
- GitHub l’a rapporté ; Toevan l’a capturé au moment de l’événement et signé.
- S’y fier dans la mesure où vous vous fiez à GitHub. Toute modification ultérieure est détectable.
- 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.
- Voir qui a déclaré quoi, quand, et chaque modification ultérieure.
- 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.
- Le considérer comme une déclaration de Toevan et demander à l’organisation l’approbation qui la fonde.
- Consommé
- Repris de l’enregistrement signé d’un autre système, comme une provenance de build, et relié par commit ou empreinte. Prévu.
- Vérifier l’enregistrement d’origine de façon indépendante.
- Non capturé
- Aucune source fiable n’était disponible. Toevan ne le déduit pas.
- L’obtenir auprès de l’organisation par d’autres moyens.
Le voir dans un rapport
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 rapportTestez la correspondance sur un vrai audit.
Apportez un dépôt et un audit à venir. Nous configurons le blueprint et guidons votre auditeur dans la vérification.