La vue d’ensemble structurelle de vous permet de Policy and Compliance Management comprendre comment les différents modules qui composent l’application Policy and Compliance Management s’intègrent ServiceNow et interagissent les uns avec les autres.

Document de référence

Policy and Compliance Management L’application 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, Unified Compliance Framework (UCF)) auquel votre entreprise doit spécifiquement se conformer. Il s’agit d’une exigence individuelle au sein d’un document de référence. Par exemple, le chiffrement 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 d’entités qui correspondent à un ensemble de conditions de filtre. Vous pouvez générer automatiquement des entités basées sur une requête conditionnelle pour n’importe quelle table de votre instance. Par exemple, considérez un client détenant un compte dans une banque comme un type d’entité. Le client dispose d’attributs tels qu’un nom, un ID client, un type de compte, une source de revenu, etc., qui sont stockés dans une table d’informations sur le client, qui peut être interrogée en fonction de n’importe lequel 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 faire 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éé.

Stratégie

Une fois les documents de référence identifiés, les entreprises élaborent des politiques qui spécifient comment l’unité business 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, d’une sécurité des informations, d’une sécurité des réseaux, d’une 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 consigner 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 pour avoir un proxy pour garder le contrôle sur les sites Web que les utilisateurs visitent. Pour une politique réseau, il peut y avoir un objectif de contrôle pour 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 pour alléger le fardeau de la conformité – un objectif de contrôle peut imposer 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. Vous pouvez également 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 d’objectifs de contrôle est le hub principal de l’application Policy and Compliance Management . 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, dans le cadre d’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 générés automatiquement 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é de l’objectif de contrôle. Toutefois, les contrôles peuvent également être créés manuellement. Les contrôles sont testés pour déterminer s’ils parviennent à atteindre l’objectif de contrôle prévu.

Test de contrôle

Un contrôle est testé pour s’assurer qu’il est efficace dans la réalisation de l’objectif de 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, le contrôle est conforme jusqu’au prochain test planifié.

Les modèles d’indicateurs 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 fois que l’indicateur est exécuté pour collecter le résultat de l’indicateur. Une tâche d’indicateur est créée selon un calendrier pour assurer le monitoring selon une fréquence prédéfinie sur le formulaire d’indicateur.

Attestation

Une attestation évalue le contrôle pour surveiller en permanence sa conformité. Contrairement à un indicateur, l’attestation est principalement ad hoc 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. Il peut s’agir d’observations opérationnelles issues d’audits, de violations de conformité réglementaire, de violations de sécurité ou d’autres résultats négatifs. 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 risqueset Policy and Compliance ManagementAudit Management GRC . Vous pouvez mesurer l’efficacité du programme de gestion des risques de votre entreprise en fonction de la rapidité et de la rigueur avec lesquelles il identifie les risques et les problèmes 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 afin de suivre le travail de rattrapage. Si un triage a été effectué, le problème de triage est converti en problème réel ou en événement à risque. Vous pouvez également suivre le problème comme une recommandation ou le fermer comme un non-problème.