Vue d’ensemble structurelle de Gestion de la politique et de la conformité
La vue d’ensemble structurelle de vous permet de Gestion de la politique et de la conformité comprendre comment les différents modules qui composent l’application Gestion de la politique et de la conformité s’intègrent ServiceNow et interagissent les uns avec les autres.
- Document de référence
- Gestion de la politique et de la conformité La demande commence par l’identification des documents de référence. Ces documents sont des réglementations externes qui incluent des lois, des règlements et des normes auxquels votre organisation doit se conformer, qui dépendent du type d’activité de votre organisation et de son emplacement. Les exigences réglementaires sont généralement publiées par des organismes de réglementation qui fournissent des exigences définies par la loi ou un certain secteur. Ces exigences peuvent provenir de réglementations fédérales ou étatiques telles que la loi HIPAA (Health Insurance Portability and Accountability Act), de réglementations internationales telles que le règlement général sur la protection des données (RGPD) ou de réglementations sectorielles telles que l’industrie des cartes de paiement (PCI). Chacun de ces documents, tels que HIPAA, GDPR et PCI, est un document de référence.
Par exemple, les normes de sécurité des données de l’industrie des cartes de paiement (PCI DSS) sont une norme de sécurité de l’information et un document de référence destiné à réduire la fraude par carte de paiement. Il fournit un ensemble de normes de sécurité pour toutes les organisations qui acceptent les paiements par carte de crédit. Les fournisseurs de services financiers doivent se conformer aux normes PCI afin de prévenir la fraude, de protéger les données des titulaires de cartes et de s’assurer que leurs services commerciaux sont sûrs et légaux.
- Contenu source d'autorité
- Une citation est un passage ou une expression d’un document de référence (par exemple, Cadre de travail de conformité unifié (UCF)) auquel votre entreprise doit spécifiquement se conformer. Il s’agit d’une exigence individuelle dans un document de référence. Par exemple, le cryptage de la transmission des données des titulaires de cartes sur les réseaux publics est l’une des exigences de la norme PCI DSS pour empêcher le vol des informations financières personnelles des consommateurs par le biais de transactions par carte de paiement.
Les citations peuvent être créées manuellement ou importées via UCF.
- Type d'entité
- Le type d’entité est un regroupement des entités qui correspondent à un ensemble de conditions de filtre. Vous pouvez générer automatiquement des entités en fonction d’une requête conditionnée vers n’importe quelle table de votre instance. Prenons l’exemple d’un client qui détient un compte dans une banque en tant que type d’entité. Le client possède des attributs tels qu’un nom, un ID client, un type de compte, une source de revenu et autres, qui sont stockés dans une table d’informations sur le client, qui peut être interrogée en fonction de l’un des attributs.
- Entité
- Il peut s’agir de personnes, de services, d’applications, d’objets, de serveurs, d’équipements réseau externes, de différents emplacements, de serveurs de données, d’entrepôts de données – essentiellement tout ce que vous allez soumettre à un test de contrôle et qui est de nature politique et de conformité. Par exemple, une personne qui détient un compte dans une banque avec un nom et des informations financières connexes.
Les entités sont automatiquement générées lorsqu’un type d’entité est créé.
- Politique
- Une fois les documents de référence identifiés, les entreprises élaborent des politiques qui précisent comment l’unité commerciale se conformerait aux documents de référence. À un niveau élevé, les déclarations de politique définissent ce que l’entreprise doit ou ne doit pas faire. Par exemple, une organisation peut définir une politique de protection des données qui définit les exigences en matière de protection des informations sensibles des clients. Les politiques sont des documents internes d’une organisation et peuvent prendre la forme d’une politique de pare-feu, d’une politique de mise en réseau, d’une politique d’utilisation acceptable, de la sécurité des informations, de la sécurité des réseaux, de la protection de l’environnement, etc. Il s’agit d’une agrégation de différents contrôles et objectifs de contrôle qui traitent d’un aspect particulier de l’entreprise.
- Confirmation de politique
- Le module de confirmation de politique permet aux propriétaires de politiques ou aux équipes de conformité d’envoyer des politiques pour examen et confirmation par les employés afin de répondre aux exigences de conformité.
- Exception de politique
- Cela vous permet d’avoir une exception sur une politique. Pour une raison quelconque, si vous ne pouvez pas vous conformer à une politique ou à un contrôle, vous pouvez enregistrer une exception.
Le module Exception de politique documente toute situation dans laquelle l’organisation n’est pas en mesure de suivre le contrôle documenté. L’exception de politique a son propre cycle de vie et ses propres approbations.
- Objectif du contrôle
- Les objectifs de contrôle sont des objectifs spécifiques que les contrôles sont censés atteindre. Par exemple, pour assurer une politique de protection des données, l’entreprise peut construire et maintenir un réseau sécurisé. Pour une politique d’utilisation acceptable, il peut y avoir un objectif de contrôle d’avoir un proxy pour garder le contrôle sur les sites Web que les utilisateurs visitent. Pour une stratégie réseau, il peut y avoir un objectif de contrôle d’avoir des mots de passe forts.
C’est par le biais des objectifs de contrôle que les documents de référence et les politiques peuvent être liés entre eux afin d’alléger le fardeau de la conformité – un objectif de contrôle peut faire respecter plusieurs exigences internes et externes. Les citations peuvent également être associées à un ou plusieurs objectifs de contrôle. C’est également au niveau de l’objectif de contrôle que les contrôles et les politiques sont liés les uns aux autres. Sinon, vous pouvez examiner un objectif de contrôle et voir les mappages vers les documents de référence et les politiques qui montrent pourquoi vous effectuez les actions indiquées dans les objectifs.
Le module des objectifs de contrôle est le hub principal de l’application Gestion de la politique et de la conformité . Alors que les documents de référence énoncent des objectifs réglementaires et que les politiques documentent ce que l’organisation doit ou ne doit pas faire, les objectifs de contrôle définissent exactement comment adhérer à ces politiques et documents de référence.
- Contrôle
- Un contrôle est une implémentation spécifique d’un objectif de contrôle. Par exemple, pour une politique de protection des données, l’entreprise peut s’assurer que les données sont sauvegardées régulièrement ou mettre en place un système de sauvegarde automatisé.
Les contrôles sont automatiquement générés lorsque vous associez une politique à un type d’entité ou un type d’entité à un objectif de contrôle où un contrôle est créé pour chaque entité répertoriée dans le type d’entité pour l’objectif de contrôle. Toutefois, les contrôles peuvent également être créés manuellement. Les contrôles sont mis à l’essai pour déterminer s’ils réussissent à atteindre l’objectif de contrôle prévu.
- Test de contrôle
- Un contrôle est mis à l’épreuve pour s’assurer qu’il est efficace pour atteindre l’objectif du contrôle. Par exemple, un test d’intrusion permet de s’assurer de la bonne mise en œuvre du chiffrement des données.
- Indicateur
- Un indicateur vous permet d’effectuer un test sur les contrôles, et les tests peuvent être planifiés quotidiennement, hebdomadairement, mensuellement ou trimestriellement. Une tâche d’indicateur est créée et envoyée à l’utilisateur pour vérifier si le contrôle est conforme, et l’indicateur peut être marqué comme Réussite ou Échec. Si la tâche échoue, le contrôle n’est pas conforme et un problème est créé. Si l’indicateur réussit le test, alors le contrôle est conforme jusqu’au prochain test planifié.
Les modèles d’indicateur permettent la création de plusieurs indicateurs pour des contrôles similaires. Le modèle d’indicateur définit les paramètres des indicateurs et est mappé à la définition du risque ou à l’objectif de contrôle en fonction du type d’indicateur qu’il surveille.
Une tâche est créée à chaque exécution de l’indicateur pour collecter le résultat de l’indicateur. Une tâche d’indicateur est créée selon une planification pour assurer la surveillance selon une fréquence prédéfinie sur le formulaire d’indicateur.
- Attestation
- Une attestation évalue le contrôle afin de surveiller en permanence sa conformité. Contrairement à un indicateur, l’attestation est principalement ponctuelle et peut ne pas être planifiée.
- Problème
- Si un écart est identifié lors du test d’un contrôle, cet écart est considéré comme un problème. Les problèmes peuvent inclure des observations opérationnelles provenant d’audits, des violations de conformité réglementaire, des violations de sécurité ou d’autres résultats négatifs. Ou, lorsqu’un test de contrôle échoue et n’est pas conforme, un problème est créé. Les problèmes peuvent être partagés entre les applications , Gestion des risques, Gestion de la politique et de la conformitéet Gestion de l'audit GRC Vous pouvez mesurer l’efficacité du programme de gestion des risques de votre entreprise en fonction de la rapidité et de la minutie avec lesquelles il identifie les problèmes de risque et de conformité et y réagit.
- Tâche de rattrapage
- Une fois le problème confirmé, l’organisation identifie les étapes nécessaires pour le résoudre. Pour atténuer un risque, vous pouvez créer une tâche de rattrapage pour suivre le travail de rattrapage. Si un triage a été effectué, le problème de triage est converti en un problème réel ou un événement à risque. Vous pouvez également suivre le problème en tant que recommandation ou le fermer en tant que non-problème.