Transformez un audit SOC 2 en un dossier de preuves organisé. Joy met vos politiques, billets, exports de configuration et revues d'accès en correspondance avec les critères des services de confiance, en montrant pour chaque contrôle ce qui est déjà en main, ce qui manque encore et à qui revient la lacune.
Nous avons un audit [type SOC 2] à venir, et notre fenêtre d'observation est [fenêtre]. Voici le contexte : [contexte]. Organisez nos preuves selon les critères des services de confiance dans un index prêt pour l'audit, en montrant pour chaque contrôle les preuves que nous avons déjà dans le Knowledge Center, ce qui manque encore et à qui revient chaque lacune.
Un exemple illustratif. Votre résultat dépendra de vos sources, de vos données et de vos demandes.
J'ai organisé vos preuves selon les critères des services de confiance, en m'appuyant sur les politiques, billets, exports de configuration et revues d'accès déjà présents dans votre Knowledge Center. Chaque contrôle montre ce qui est en main par rapport à ce qui manque encore, avec un responsable nommé pour chaque lacune, pour que vous sachiez exactement qui relancer avant la fermeture de la fenêtre.
Voici vos preuves organisées par contrôle. Pour chacun, ce qui est déjà dans le Knowledge Center, où en sont les choses et à qui revient la fermeture de la lacune.
| Contrôle | Preuves en main | Statut | Responsable / prochaine étape |
|---|---|---|---|
| CC1.4 — Vérifications des antécédents des nouvelles recrues | Politique de vérification des antécédents ; vérifications complétées pour les 9 personnes embauchées dans la fenêtre | En main | Ressources humaines — terminé |
| CC6.1 — Contrôles d'accès logiques | Politique de contrôle des accès ; export de configuration de l'application de l'authentification unique (SSO) et de l'AMF depuis Okta | En main | Sécurité — terminé |
| CC6.2 — Provisionnement et déprovisionnement | Billets d'intégration présents ; billets de départ pour 2 des 5 partants pas encore rattachés | Partiel | TI — rattacher les 3 billets de départ manquants |
| CC6.3 — Revues d'accès trimestrielles | Revues d'accès des utilisateurs des T2 et T3, approuvées dans le Knowledge Center | En main | Sécurité — terminé |
| CC7.2 — Surveillance et alertes de sécurité | La surveillance fonctionne, mais l'export de la configuration des alertes et une alerte triée à titre d'exemple ne sont pas rassemblés | Manquant | Sécurité — sortir la configuration des alertes et une alerte traitée |
| CC7.3 — Réponse aux incidents | Plan de réponse aux incidents ; aucun incident ne s'est produit dans la fenêtre, il faut donc un compte rendu d'exercice sur table à la place | Manquant | Sécurité — mener et documenter un exercice sur table |
| CC8.1 — Gestion des changements | Politique de changement en main ; les enregistrements d'approbation de pull request et de déploiement existent dans l'outillage mais ne sont pas exportés comme preuve | En cours | Ingénierie — exporter un échantillon d'approbations de PR et de déploiements |
| A1.2 — Sauvegardes et reprise | Politique de sauvegarde ; export de configuration des tâches de sauvegarde en main ; le dernier test de restauration est antérieur à la fenêtre | Partiel | TI — effectuer un test de restauration dans la fenêtre et le consigner |
Six des huit contrôles ont une preuve complète ou partielle ; le vrai travail, ce sont les quatre lacunes. Deux d'entre elles, la surveillance CC7.2 et la réponse aux incidents CC7.3, sont celles sur lesquelles un auditeur a tendance à insister, et les deux relèvent de la Sécurité, c'est donc par là que je commencerais. Les exports de gestion des changements (CC8.1) et les billets de départ (CC6.2) se ferment rapidement une fois quelqu'un affecté. Rien ici n'est une preuve fabriquée — chaque ligne reflète ce qui est réellement téléversé, de sorte que les lignes manquantes sont véritablement manquantes, et non simplement non indexées.
Voulez-vous que je rédige la note de demande de lacune que vous pouvez envoyer à chaque responsable, ou que je séquence les quatre lacunes en un échéancier de préparation pour le reste de la fenêtre ?
Le Collecteur de Preuves SOC2 prend les critères sur lesquels vous êtes audité et tout le contexte que vous pouvez lui donner, et organise vos preuves dans un index mis en correspondance contrôle par contrôle. Joy, l'assistante JoySuite, confronte chaque critère des services de confiance à ce qui se trouve dans votre Knowledge Center, marque les preuves en main par rapport à ce qui manque encore, et nomme un responsable pour chaque lacune.
Dites à Joy quel rapport SOC 2 vous visez, la fenêtre d'observation et les critères dans la portée. Mentionnez tout ce que vous savez déjà solide ou manquant. Une esquisse suffit.
Demandez un index de preuves mis en correspondance avec les critères des services de confiance, chaque contrôle marqué en main ou manquant et un responsable pour chaque lacune. Joy comble les contrôles standards et des responsables sensés si vous ne les précisez pas tous.
Obtenez vos preuves présentées contrôle par contrôle, avec les statuts et les responsables, et les lacunes rassemblées dans une lecture claire à la fin. Confrontez-le à ce qui est réellement téléversé et à la façon dont vos contrôles fonctionnent vraiment.
Demandez un ajustement, « déplacez l'export de gestion des changements vers Ingénierie » ou « ajoutez une ligne pour les revues fournisseurs », puis copiez l'index dans votre outil GRC, votre lecteur partagé ou la note que vous envoyez à chaque responsable de lacune.
Enregistrez cette demande comme commande personnalisée sur l'assistant que votre équipe utilise déjà, pour que chacun puisse la lancer en une seule étape.
Les preuves sont organisées selon les critères des services de confiance de la manière dont un auditeur les demande, de sorte que l'index s'aligne contrôle par contrôle avec la demande.
Chaque contrôle est marqué en main, partiel ou manquant, pour que vous voyiez l'écart de couverture d'un coup d'œil au lieu de le chercher à travers les lecteurs.
Chaque lacune nomme qui a la responsabilité de la combler, pour que rien ne reste sans preneur à l'approche de la fenêtre d'observation et des travaux sur le terrain.
Les contrôles sans preuve sont signalés avec une lecture de ceux sur lesquels un auditeur a tendance à insister, pour que vous sachiez quoi combler en premier.
Transformez les lacunes ouvertes en une courte note que vous pouvez envoyer à chaque responsable avec la preuve dont vous avez besoin et pour quand.
Séquencez les lacunes en un plan de travail pour les semaines précédant la fermeture de la fenêtre d'observation.
Partez de l'ensemble de preuves de l'an dernier et marquez ce qui se reporte, ce qui doit être rafraîchi et ce qui entre nouvellement dans la portée.
Lancez le même index à un instant donné pour vérifier la conception des contrôles avant de vous engager dans une fenêtre Type II.
Il organise vos preuves selon les critères des services de confiance dans un index prêt pour l'audit. Vous donnez le contexte à Joy et elle met chaque contrôle en correspondance avec les politiques, billets, exports de configuration et revues d'accès de votre Knowledge Center, marque ce qui est en main par rapport à ce qui manque, nomme un responsable de lacune et fait ressortir les lacunes à combler en premier.
Non. Joy organise et indexe les preuves que vous avez téléversées dans votre Knowledge Center, et ne peut lire dans un système connecté que là où un connecteur le prend réellement en charge. Elle ne fabriquera pas de preuves et ne prétendra pas tirer automatiquement des données d'outils auxquels elle n'est pas connectée. Un contrôle n'apparaît couvert que lorsque la preuve est vraiment là.
Ceux sur lesquels vous êtes audité, quels qu'ils soient. L'ensemble Sécurité (critères communs) est toujours dans la portée, et vous pouvez y ajouter la Disponibilité, la Confidentialité, l'Intégrité du traitement ou la Vie privée. Dites à Joy les critères dans la portée et elle met vos preuves en correspondance avec les contrôles pertinents, de l'accès logique à la gestion des changements en passant par la réponse aux incidents.
Quand votre Knowledge Center contient les preuves du rapport précédent, Joy s'en sert pour distinguer ce qui se reporte et ce qui est déjà en place de ce qui doit être rafraîchi pour la nouvelle fenêtre, de sorte que vous ne reconstruisez pas l'index à partir d'une liste de critères vierge.
Joy nomme un responsable suggéré pour chaque lacune, et vous pouvez en réattribuer n'importe laquelle dans la même conversation, « déplacez l'export de gestion des changements vers Ingénierie ». Copiez ensuite l'index dans votre outil GRC ou la note que vous envoyez à chaque responsable. Joy rédige et organise ; elle n'envoie pas.
Rejoignez la liste d'attente et soyez parmi les premiers à essayer ce workflow lors du lancement de JoySuite.