Partager via

Vue d’ensemble de l’infrastructure de certification Microsoft 365

  • Article

Cet article fournit des informations détaillées sur la certification Microsoft 365, notamment une liste des contrôles de sécurité requis et des conseils pour les éditeurs de logiciels indépendants et les développeurs.

La certification Microsoft 365 est un audit indépendant de la sécurité et de la confidentialité des applications, des compléments et de l’environnement principal de prise en charge (collectivement appelés applications) qui s’intègre à la plateforme Microsoft 365. Les applications qui réussissent sont désignées certifiées Microsoft 365 dans l’écosystème Microsoft 365 et peuvent être facilement trouvées dans les marketplaces Microsoft 365 via des filtres de recherche et une personnalisation axés sur la conformité. Les éditeurs de logiciels indépendants auront la possibilité de partager les attributs de conformité de leur application sur des pages dédiées dans cet ensemble de documentation.

La certification Microsoft 365 est disponible pour les types d’applications suivants :

  • Compléments Microsoft 365 (Word, Excel, Outlook, PowerPoint, OneNote, Project)
  • Applications Teams
  • Solutions SharePoint
  • Applications web (SaaS)
  • Extensions CoPilot

Importante

La certification Microsoft 365 est un examen rigoureux de la sécurité et de la conformité d’une application par rapport à l’infrastructure de certification Microsoft 365 et nécessite un engagement considérable en matière de temps et de ressources. Avant de commencer, consultez les frameworks de contrôle de conformité pour vérifier que votre application est éligible. Si vous avez des questions, envoyez un e-mail à appcert@microsoft.com.

Petits caractères

En participant au programme de certification Microsoft 365, vous acceptez ces conditions supplémentaires et vous conformez à toute documentation connexe qui s’applique à votre participation au programme de certification Microsoft 365 avec Microsoft Corporation (« Microsoft », « nous », « nous » ou « notre »). Vous déclarez et garantissez que vous avez le pouvoir d’accepter ces conditions supplémentaires de la certification Microsoft 365 au nom de vous-même, d’une société et/ou d’une autre entité, le cas échéant. Nous pouvons modifier, modifier ou mettre fin à ces conditions supplémentaires à tout moment. Votre participation continue au programme de certification Microsoft 365 après toute modification ou modification signifie que vous acceptez les nouvelles conditions supplémentaires. Si vous n’acceptez pas les nouvelles conditions supplémentaires ou si nous mettons fin à ces conditions supplémentaires, vous devez cesser de participer au programme de certification Microsoft 365.

Configuration requise

Pour que la certification Microsoft 365 puisse être accordée, une application doit effectuer les opérations suivantes :

Vérification de l’éditeur Lorsqu’une application a un éditeur vérifié, le organization qui publie l’application a été vérifié comme étant authentique par Microsoft. La vérification d’une application inclut l’utilisation d’un compte du programme Microsoft Cloud Partner (CPP) qui a été vérifié et l’association de partnerID vérifié à une inscription d’application. Obtenir la vérification de l’éditeur

Publisher Attestation est un processus libre-service dans lequel les développeurs d’applications (ISV) effectuent un ensemble de questions sur leurs pratiques de sécurité, telles que la gestion des données sensibles. Une fois l’opération terminée, l’application reçoit un badging et un référencement spéciaux sur la Place de marché Microsoft AppSource.

Passer en revue les critères de contrôle Il n’est pas toujours obligatoire de se conformer à tous les contrôles pour obtenir une certification. Toutefois, des seuils (qui ne seront pas divulgués) sont en place pour chacun des trois domaines de sécurité abordés dans ce document de présentation et doivent être passés. Le non-respect des contrôles critiques intitulés « échec dur » entraîne l’échec de l’évaluation.

Délai de soumission

Le processus de soumission pour obtenir la certification comporte deux étapes :

Étape 1 : Soumission initiale du document (délai de 14 jours)

À cette étape, l’éditeur de logiciels indépendant doit envoyer une documentation qui fournit une vue d’ensemble de l’environnement de prise en charge des applications. Cela inclut, sans s’y limiter , les éléments suivants :

  • Diagramme architectural/Flux de données
  • Listes de composants système
  • Inventaires des ressources logicielles

Un analyste examinera cette documentation pour définir l’étendue de l’évaluation. L’éditeur de logiciels indépendant a 14 jours pour terminer et charger la documentation requise. Le non-respect de cette échéance peut retarder le processus ou entraîner un échec de soumission.

Étape 2 : Examen complet des preuves (période de 60 jours)

Une fois l’étendue définie, l’ÉDITEUR de logiciels indépendants passe à la phase de collecte des preuves. À cette étape :

  1. L’éditeur de logiciels indépendant doit charger des preuves sur tous les contrôles applicables définis à partir de l’étendue.
  2. Cette preuve fera l’objet d’un examen, de révisions (si nécessaire) et d’un processus d’assurance qualité final.
  3. Si nécessaire, des tests d’intrusion peuvent également être effectués pendant cette période.

L’éditeur de logiciels indépendant dispose de 60 jours pour effectuer cette étape, à compter de la première soumission de preuves, qui comprend :

  • Chargement de preuves pour tous les contrôles
  • Avis et commentaires des analystes
  • Toutes les révisions nécessaires à la preuve soumise
  • Fin du processus d’assurance qualité

Non-respect de l’échéance

Si l’éditeur de logiciels indépendant ne peut pas terminer le processus dans le délai de 60 jours, l’évaluation échoue. Toutefois, à la discrétion de l’analyste, une prolongation de 60 jours supplémentaires peut être accordée dans des circonstances valides, telles que :

  • Vacances saisonnières.
  • Retards des tests d’intrusion.
  • Modifications internes.
  • Temps nécessaire pour implémenter les modifications nécessaires pour répondre aux exigences de contrôle.

Aucune autre extension ne peut être accordée, une fois que les deux délais de 60 jours ont été épuisés.

Étendue de la certification

L’environnement dans l’étendue englobe tous les systèmes et l’infrastructure nécessaires pour fournir le code de l’application ou du complément, ainsi que tous les systèmes back-end de prise en charge avec ants que l’application/complément peut communiquer. Tous les environnements supplémentaires connectés à l’environnement dans l’étendue doivent également être inclus dans l’étendue, sauf si une segmentation adéquate est implémentée et que les environnements connectés ne peuvent pas compromettre la sécurité de l’environnement dans l’étendue.

Remarque : Tous les environnements de récupération d’urgence distincts doivent également être inclus dans l’environnement dans l’étendue, car ces environnements peuvent être essentiels au maintien de la continuité du service en cas de défaillance de l’environnement principal.

En outre, les environnements de sauvegarde à distance doivent également être incorporés dans l’étendue, car ils peuvent stocker des données Microsoft sensibles. Par conséquent, des contrôles de sécurité appropriés doivent être implémentés pour ces environnements.

Le terme composants système dans l’étendue inclut tous les appareils et systèmes activement utilisés dans l’environnement dans l’étendue défini. Ces composants incluent, sans s’y limiter , les éléments suivants :

  • Applications Web
  • Serveurs (physiques ou virtuels, locaux ou dans le cloud)
  • Commutateurs
  • Équilibreurs de charge
  • Infrastructure virtuelle
  • Portails de gestion web des fournisseurs de cloud
  • Ressources cloud (Machines Virtuelles, Services d’application, comptes de stockage, bases de données, etc.)

Importante

Les composants du système public sont particulièrement vulnérables aux attaques par des acteurs de menace externes et sont donc exposés à un risque plus élevé. En règle générale, ces systèmes doivent être isolés des composants système internes par l’implémentation de contrôles de sécurité réseau (NSC), tels qu’une zone démilitarisée (DMZ). L’objectif d’une zone DMZ est d’agir en tant que zone tampon, en limitant l’approbation étendue aux systèmes externes et en améliorant la sécurité pour protéger les données et les systèmes internes. Bien qu’une zone DMZ puisse toujours être idéale dans certains cas, les architectures cloud modernes s’appuient souvent sur d’autres mesures de sécurité adaptées à des scénarios de déploiement spécifiques.

Infrastructure as a Service (IaaS), PaaS (Platform as a Service) et Software as a Service (SaaS)

Lorsque IaaS et/ou PaaS sont utilisés pour prendre en charge l’environnement dans l’étendue en cours d’examen, le fournisseur de plateforme cloud est responsable de certains contrôles de sécurité évalués tout au long du processus de certification. Les analystes devront disposer d’une vérification externe indépendante des bonnes pratiques de sécurité par le fournisseur de plateforme cloud via des rapports de conformité externes tels que pci DSS, Attestation de conformité (AOC), ISO 27001 ou SOC 2 Type II.

Pour plus d’informations sur les contrôles de sécurité susceptibles d’être applicables au type de déploiement et pour savoir si l’environnement traite ou transfère des données Microsoft 365, consultez l’Annexe C. Les types de déploiement sont les suivants :

ISV Hébergé : application hébergée par des fournisseurs de logiciels indépendants IaaS Hébergée : infrastructure fournie par des plateformes cloud tierces. PaaS/Serverless Hosted : les applications calculent la moyenne de l’architecture basée sur la plateforme ou serverless. Hybride hébergé : combinaison de composants locaux et hébergés dans le cloud. Hébergés partagés : environnements cloud partagés utilisés par plusieurs locataires.

Dans les cas où IaaS ou PaaS est en cours d’utilisation, la preuve doit confirmer que le déploiement s’aligne sur les contrôles de sécurité attendus pour l’architecture appropriée.

Échantillonnage

Pour garantir une évaluation approfondie, l’échantillonnage des composants système dans l’étendue doit prendre en compte des facteurs tels que les systèmes d’exploitation, la fonction de l’appareil principal, le type d’appareil (par exemple, les serveurs, les routeurs, les contrôles de sécurité réseau) et l’emplacement géographique. Des exemples sont sélectionnés au début du processus de certification en fonction de ces considérations. Le tableau ci-dessous indique la taille de l’échantillonnage en fonction de la population de composants dans l’étendue :

Taille de la population Échantillon
<=5 1
>5 & <10= 2
>10 & <=30 3
>30 4

Cela garantit une évaluation représentative de la conformité de l’environnement dans diverses configurations et modèles de déploiement.

Remarque

Si des écarts sont identifiés entre les appareils pendant l’évaluation, la taille de l’échantillon peut être ajustée pour garantir une présentation adéquate de l’environnement.

Vue d’ensemble du processus de certification

Pour commencer le processus de certification Microsoft 365 :

  1. Attestation du serveur de publication Accédez à l’Espace partenaires et remplissez le formulaire Attestation du serveur de publication. Remarque : Si votre soumission date de plus de trois mois, vous devez la soumettre à nouveau pour révision et validation.

  2. Démarrez la certification une fois dans l’Espace partenaires, sélectionnez l’option « Démarrer la certification » pour commencer la soumission de votre document initial. Cette étape aide les analystes de certification à identifier l’étendue de l’évaluation en fonction de l’architecture de votre application et de la façon dont elle gère les données Microsoft.

La certification se déroule en deux étapes main :

  1. Envoi de document initial À ce stade, vous fournissez des détails clés pour aider les analystes à comprendre la conception de votre application, le flux de données et l’environnement dans l’étendue. Les analystes déterminent les contrôles de sécurité applicables et décrivent les composants système nécessitant des preuves. Vous devez fournir une documentation précise pour faciliter cet examen, ce qui représente environ 5 % du processus global.

  2. Examen complet des preuves À cette étape, vous soumettez des preuves détaillées démontrant la conformité aux contrôles de sécurité pour l’environnement dans l’étendue. Les analystes travailleront en étroite collaboration avec vous au cours de cette phase pour examiner, clarifier et vérifier vos soumissions. Cette phase prend le reste du processus.

Évaluation

Une fois la soumission initiale du document approuvée, une liste des contrôles de sécurité requis s’affiche dans le portail. Vous avez 60 jours pour fournir des preuves pour chaque contrôle, confirmant qu’il est en place et opérationnel. Les analystes examineront vos preuves et les approuveront ou demanderont des détails ou des révisions supplémentaires.

Certification

Une fois que votre soumission a été examinée et validée par un analyste, vous recevez une notification concernant la décision de certification. Les applications qui répondent correctement aux critères de certification recevront un badge, qui s’affichera sur leur liste AppSource et les pages Microsoft Docs associées. Ces pages fournissent également des rapports détaillés sur les attributs de sécurité et de conformité de l’application.

Révision et recertification

Les applications certifiées Microsoft 365 doivent faire l’objet d’une recertification annuelle pour garantir une conformité continue aux normes de Microsoft. Le processus de recertification implique la réévaluation des contrôles dans l’étendue pour confirmer leur alignement sur l’environnement actuel. Vous pouvez commencer le processus de recertification jusqu’à 90 jours avant l’expiration de la certification pour éviter toute interruption. Les certifications resteront valides pendant cette période.

Si la recertification n’est pas terminée avant la date d’expiration, la certification est révoquée. Par conséquent :

  • Le badge de certification et la personnalisation de l’application seront supprimés.

  • Les éditeurs de logiciels indépendants ne seront plus autorisés à commercialiser l’application comme certifiée Microsoft 365.

En cas de modifications importantes apportées à l’application en dehors de la période de recertification planifiée, les éditeurs de logiciels indépendants doivent informer le programme de conformité des applications Microsoft pour s’assurer que l’application reste conforme.

Envoi initial du document

Votre soumission initiale doit inclure les informations suivantes :

Vue d’ensemble de la documentation Détails de la documentation
Description de l’application/du complément Description de l’objectif et des fonctionnalités de l’application/du complément. Cela doit fournir à l’analyste de certification une bonne compréhension du fonctionnement de l’application/complément et de son utilisation prévue
Rapport de test d’intrusion Un rapport de test d’intrusion s’est terminé au cours des 12 derniers mois. Ce rapport doit inclure l’environnement qui prend en charge le déploiement de l’application/de l’ajout, ainsi que tout environnement supplémentaire qui prend en charge le fonctionnement de l’application/du complément. Remarque : si l’éditeur de logiciels indépendant n’effectue actuellement pas de tests d’intrusion annuels, Microsoft couvrira le coût des tests de stylet via le processus de certification.
Diagrammes d’architecture Diagramme d’architecture logique représentant une vue d’ensemble générale de l’infrastructure de prise en charge de l’application. Cela doit inclure tous les environnements d’hébergement et l’infrastructure de prise en charge prenant en charge l’application. Ce diagramme DOIT représenter tous les différents composants système de prise en charge au sein de l’environnement pour aider les analystes de certification à comprendre les systèmes dans l’étendue et à déterminer l’échantillonnage. Indiquez également le type d’environnement d’hébergement utilisé . IsV Hébergé, IaaS, PaaS ou Hybride. Note: Lorsque SaaS est utilisé, indiquez les différents services SaaS utilisés pour fournir des services de prise en charge au sein de l’environnement.
Empreinte publique Détail de toutes les adresses IP publiques et URL utilisées par l’infrastructure de prise en charge. Cela doit inclure la plage d’adresses IP routables complète allouée à l’environnement, sauf si une segmentation adéquate a été implémentée pour fractionner la plage en cours d’utilisation (une preuve adéquate de la segmentation sera requise)
Diagrammes de flux de données Diagrammes de flux détaillant les éléments suivants :
✓ Flux de données Microsoft 365 vers et depuis l’application/complément (y compris EUII et OII.)
✓ Flux de données Microsoft 365 au sein de l’infrastructure de prise en charge (le cas échéant).
✓ Diagrammes mettant en évidence où et quelles données sont stockées, comment les données sont transmises à des tiers externes (y compris les détails des tiers) et comment les données sont protégées en transit sur des réseaux ouverts/publics et au repos.
Détails du point de terminaison d’API Liste complète de tous les points de terminaison d’API utilisés par votre application. Pour vous aider à comprendre l’étendue de l’environnement, fournissez des emplacements de point de terminaison d’API au sein de votre environnement.
Autorisations de l’API Microsoft Fournir une documentation détaillant toutes les API Microsoft utilisées, ainsi que les autorisations demandées pour le fonctionnement de l’application/du complément, ainsi qu’une justification des autorisations demandées
Types de stockage de données Documents de stockage et de gestion des données décrivant :
✓ Dans quelle mesure microsoft 365 données EUII et OII sont-ils reçus et stockés
✓ Période de conservation des données.
✓ Pourquoi les données Microsoft 365 sont capturées.
✓ Emplacement de stockage des données Microsoft 365 (doit également être inclus dans les diagrammes de flux de données fournis ci-dessus).
Confirmation de la conformité Documentation de support pour les frameworks de sécurité externes inclus dans la soumission de l’attestation de l’éditeur ou à prendre en compte lors de l’examen des contrôles de sécurité de la certification Microsoft 365. Actuellement, les quatre suivants sont pris en charge :
✓ Attestation de conformité PCI DSS (AOC).
✓ Rapports soc 2 type I/type II.
✓ ISMS / IEC - 1S0/IEC 27001 Déclaration d’applicabilité (SoA) et de certification.
✓ Package d’autorisation FedRAMP FedRAMP et rapport d’évaluation de la préparation FedRAMP.
Dépendances web Documentation répertoriant toutes les dépendances utilisées par l’application avec les versions en cours d’exécution.
Inventaire des logiciels Un inventaire logiciel à jour qui inclut tous les logiciels utilisés dans l’environnement dans l’étendue, ainsi que les versions.
Inventaire du matériel Un inventaire matériel à jour utilisé par l’infrastructure de prise en charge. Cela sera utilisé pour faciliter l’échantillonnage lors de l’exécution de la phase d’évaluation. Si votre environnement inclut PaaS, fournissez des détails sur les services/ressources cloud consommés.

Activités de collecte et d’évaluation des preuves

Les analystes de certification devront examiner les preuves de tous les composants système dans l’exemple d’ensemble défini. Les types de preuves nécessaires pour soutenir le processus d’évaluation incluent tout ou partie des éléments suivants :

Collecte de preuves

  • Documentation initiale, mise en évidence dans le guide de soumission de la documentation initiale
  • Documents de stratégie
  • Traiter des documents
  • Paramètres de configuration système
  • Modifier les tickets
  • Modifier les enregistrements de contrôle
  • Rapports système
  • Minutes de réunion
  • Contrats/accords

Diverses méthodes seront utilisées pour recueillir les preuves nécessaires à la réalisation du processus d’évaluation. Cette collection de preuves peut se présenter sous la forme suivante :

  • Documents
  • Captures d’écran
  • Entrevues
  • Partage d’écran

Les techniques de collecte de preuves utilisées seront déterminées pendant le processus d’évaluation. Pour obtenir des exemples spécifiques du type de preuve requis dans votre soumission, consultez le Guide des exemples de preuves.

Activités d’évaluation

Les analystes de certification examineront les preuves soumises pour vérifier que tous les contrôles requis pour la certification Microsoft 365 sont respectés. Pour accélérer le processus, vérifiez que toute la documentation spécifiée dans la soumission de la documentation initiale est complète et fournie à l’avance.

Pendant l’examen, les analystes évalueront la preuve de la soumission initiale et de l’attestation de l’éditeur. Ils détermineront l’étendue de l’enquête, l’échantillonnage et si des preuves supplémentaires sont nécessaires. Les analystes utilisent toutes les informations collectées pour évaluer la conformité avec la spécification de la certification Microsoft 365 et déterminer si votre application répond aux contrôles définis.

Critères de certification des applications

L’application et son infrastructure de prise en charge, ainsi que la documentation associée, seront évalués dans les trois domaines de sécurité suivants :

  1. Sécurité des applications
  2. Sécurité opérationnelle / déploiement sécurisé
  3. Sécurité et confidentialité de la gestion des données

Chacun de ces domaines de sécurité comprend des contrôles clés spécifiques englobant une ou plusieurs exigences qui seront évaluées dans le cadre du processus d’évaluation. Pour garantir que la certification Microsoft 365 est inclusive pour les développeurs de toutes tailles, chacun des domaines de sécurité est évalué à l’aide d’un système de scoring pour déterminer un score global à partir de chacun des domaines. Les scores pour chacun des contrôles de certification Microsoft 365 sont alloués entre 1 (faible) et 3 (élevé) en fonction du risque perçu de non-implémentation de ce contrôle. Chacun des domaines de sécurité aura une marque de pourcentage minimale à considérer comme une réussite. Certains facteurs entraînent des défaillances automatiques, notamment

  • Utilisation d’autorisations d’API qui ne respectent pas le principe de privilège minimum (PoLP)

  • Absence de rapports de tests d’intrusion si nécessaire.

  • Absence de défenses anti-programme malveillant.

  • Échec de l’implémentation de l’authentification multifacteur (MFA) pour l’accès administratif.

  • Processus de mise à jour corrective manquants ou insuffisants.

  • Absence de déclaration de confidentialité RGPD conforme.

Sécurité des applications

Le domaine de sécurité d’application évalue les domaines suivants :

  • Validation d’autorisation GraphAPI
  • Vérifications de connectivité externe
  • Tests d’intrusion

Validation d’autorisation GraphAPI

Cela garantit que l’application ou le complément ne demande pas d’autorisations excessives ou trop permissives. Les analystes de certification passent en revue manuellement les autorisations demandées par l’application et les case activée par rapport à la soumission d’attestation de l’éditeur.

L’objectif est de confirmer que les autorisations demandées respectent le principe du privilège minimum. Si les analystes constatent que l’application demande des autorisations qui dépassent ce qui est nécessaire, ils collaborent avec l’éditeur de logiciels indépendant pour valider la justification métier de ces autorisations. Toutes les différences identifiées entre les autorisations demandées et la soumission de l’attestation du serveur de publication doivent être traitées et résolues pendant cette révision.

Vérifications de connectivité externe

Dans le cadre du processus de certification, les analystes effectuent un examen de haut niveau des fonctionnalités de l’application pour identifier les connexions externes établies en dehors de Microsoft 365.

Toutes les connexions non identifiées comme étant des services Microsoft ou non liées à votre service seront signalées pour discussion pendant l’évaluation afin de garantir la conformité aux normes de sécurité et de fonctionnalité.

Tests d’intrusion

Les tests d’intrusion sont essentiels pour identifier et atténuer les risques associés à l’application ou au complément et à son environnement de prise en charge. Cela garantit que l’application fournit des garanties de sécurité adéquates aux clients.

Les tests d’intrusion sont obligatoires pour toute application qui se connecte à des services externes non hébergés ou gérés par Microsoft. Si l’application est déployée en tant que solution autonome qui utilise uniquement des services Microsoft tels que GraphAPI, les tests d’intrusion peuvent ne pas être nécessaires. Toutefois, les applications hébergées dans Azure doivent subir des tests d’intrusion pour garantir la sécurité de l’environnement dans l’étendue.

Étendue des tests d’intrusion

Tests d’infrastructure : pour l’infrastructure interne et externe, les tests d’intrusion doivent être effectués dans l’environnement de production actif qui prend en charge l’application ou le complément. Cela inclut les opérations suivantes :

Environnement dans lequel le code de l’application ou du complément est hébergé (généralement référencé dans le fichier manifeste)

Tous les environnements supplémentaires qui interagissent avec ou prennent en charge le fonctionnement de l’application/complément (par exemple, si l’application/le complément communique avec d’autres applications web en dehors de Microsoft 365).

Lors de la définition de l’étendue des tests d’intrusion, il est essentiel d’inclure tous les systèmes ou environnements connectés susceptibles d’avoir un impact sur la sécurité de l’environnement dans l’étendue.

Recommandations

Test d’intrusion des applications web : il est recommandé d’effectuer des tests d’intrusion des applications web directement sur l’environnement de production en direct. Toutefois, les tests d’application web peuvent être effectués sur un environnement de test/UAT (User Acceptance Testing), à condition que le rapport de test d’intrusion confirme que le même code base est utilisé en production au moment du test.

Validation de la segmentation : si des techniques de segmentation sont utilisées pour isoler les environnements dans l’étendue des autres, le rapport de test d’intrusion doit valider l’efficacité de ces techniques de segmentation. Cela garantit qu’aucune vulnérabilité n’est introduite par le processus de segmentation.

Exigences relatives aux tests d’intrusion

Les rapports de tests d’intrusion seront examinés pour s’assurer qu’il n’y a pas de vulnérabilités qui répondent aux critères d’échec automatique suivants décrits dans les contrôles ci-dessous.

Type de critères Contrôles de test d’intrusion
Critères généraux L’application web (authentifiée et non authentifiée) et les tests d’intrusion d’infrastructure interne (le cas échéant) et externe DOIVENT être effectués chaque année (tous les 12 mois) et menés par une entreprise indépendante digne de confiance.
La correction des vulnérabilités critiques et à haut risque identifiées doit être effectuée dans un délai d’un mois après la conclusion du test d’intrusion, ou plus tôt en fonction du processus de mise à jour corrective documenté de l’éditeur de logiciels indépendants.
L’empreinte externe complète (adresses IP, URL, points de terminaison d’API, etc.) DOIT être inclus dans l’étendue des tests d’intrusion et doit être clairement documenté dans le rapport des tests d’intrusion.
À moins que l’environnement ne s’aligne sur PaaS, les réseaux internes complets DOIVENT être inclus dans l’étendue des tests d’intrusion et doivent être clairement documentés dans le rapport de test d’intrusion.
Les tests d’intrusion des applications web DOIVENT inclure toutes les classes de vulnérabilité ; par exemple, le OWASP Top 10 ou sans Top 25 CWE le plus actuel. Il est recommandé que cela soit détaillé dans le rapport des tests d’intrusion, sinon il sera difficile à démontrer.
Les vulnérabilités critiques et à haut risque ou les vulnérabilités considérées comme une défaillance automatique DOIVENT être testées à nouveau par l’entreprise de test d’intrusion et clairement mises en évidence comme étant corrigées dans le rapport de test d’intrusion.
Critères d’échec automatique : Présence d’un système d’exploitation non pris en charge ou d’une bibliothèque JavaScript non prise en charge.
Présence de comptes d’administration par défaut, énumérables ou devinables.
Présence de risques d’injection de code SQL.
Présence de scripts intersites.
Présence de vulnérabilités de traversée de répertoires (chemin d’accès de fichier).
Présence de vulnérabilités HTTP, par exemple, fractionnement de la réponse d’en-tête, trafic de demandes et attaques asynchrones.
Présence de la divulgation du code source (y compris LFI).
Tout score critique ou élevé tel que défini par les instructions de gestion des correctifs CVSS.
Toute vulnérabilité technique importante qui peut être facilement exploitée pour compromettre une grande quantité d’EUII ou OUI.

Importante

Les rapports doivent être en mesure de fournir suffisamment d’assurance que tout ce qui est détaillé dans la section relative aux tests d’intrusion ci-dessus peut être démontré.

Exigences et règles de test d’intrusion complémentaires

Pour les éditeurs de logiciels indépendants qui n’effectuent pas actuellement de tests d’intrusion, Microsoft propose un service de test d’intrusion gratuit dans le cadre du processus de certification Microsoft 365. Ce service couvre jusqu’à 12 jours de tests manuels, avec des coûts supplémentaires pour tous les jours requis au-delà de la responsabilité de l’éditeur de logiciels indépendants.

Principales conditions requises

Conditions préalables au test : les éditeurs de logiciels indépendants doivent soumettre des preuves et recevoir l’approbation de 50 % des contrôles dans l’étendue avant de planifier le test d’intrusion.

Rapport de test : Ce rapport, ainsi que votre certification Microsoft 365, peut être utilisé pour montrer aux clients que votre environnement est sécurisé.

Correction des vulnérabilités : les éditeurs de logiciels indépendants sont chargés de résoudre les vulnérabilités identifiées lors du test avant que la certification ne puisse être accordée. Toutefois, un rapport de propre n’est pas nécessaire, mais seulement la preuve que les vulnérabilités ont été traitées de manière adéquate.

Considérations supplémentaires

Une fois qu’un test d’intrusion est organisé, l’ISV est responsable de couvrir tous les frais associés au replanification ou à l’annulation.

Échelle de temps de rééchelonnement des frais Proportion payable
Demande de replanification reçue plus de 30 jours avant la date de début planifiée. 0 % payable
Demande de replanification reçue 8 à 30 jours avant la date de début planifiée. 25 % payable
Demande de replanification reçue dans les 2 à 7 jours avant la date de début planifiée avec une date de re-réservation ferme. 50 % payable
Demande de replanification reçue moins de 2 jours avant la date de début. 100 % payable
Échelle de temps des frais d’annulation Proportion payable
La demande d’annulation a été reçue plus de 30 jours avant la date de début planifiée. 25 % payable
La demande d’annulation a été reçue 8 à 30 jours avant la date de début planifiée. 50 % payable
Demande d’annulation reçue dans les 7 jours précédant la date de début planifiée. 90 % payable

Sécurité opérationnelle

Ce domaine mesure l’alignement de l’infrastructure de prise en charge et des processus de déploiement d’une application avec les meilleures pratiques de sécurité.

Contrôles

Famille de contrôles Controls
Formation de sensibilisation Fournir des preuves que le organization fournit une formation de sensibilisation à la sécurité établie aux utilisateurs du système d’information (y compris les gestionnaires, les cadres supérieurs et les sous-traitants) dans le cadre de la formation initiale pour les nouveaux utilisateurs ou lorsque les changements du système d’information l’exigent.
Fournir des preuves d’une fréquence définie organization de formation de sensibilisation.
Fournir des preuves de documentation et de surveillance des activités individuelles de sensibilisation à la sécurité du système d’information tout en conservant les enregistrements de formation individuels sur une fréquence définie par organization.
Protection contre les programmes malveillants - antivirus Indiquez que votre solution anti-programme malveillant est active et activée sur tous les composants système échantillonnées et configurée pour répondre aux critères suivants :
Si un antivirus est activé, l’analyse à l’accès est activée et les signatures sont à jour dans un délai d’un jour et bloque automatiquement les programmes malveillants ou les alertes et les mises en quarantaine lorsque des programmes malveillants sont détectés.
OU si EDR/NGAV (Endpoint Detection and Response/Next-Generation Antivirus), une analyse périodique est effectuée, des journaux d’audit sont générés et sont continuellement mis à jour et disposent de fonctionnalités d’auto-apprentissage.
Si EDR/NGAV, il bloque les programmes malveillants connus et identifie et bloque les nouvelles variantes de programmes malveillants en fonction des comportements de macro, ainsi que des fonctionnalités de liste de sécurité complètes.
Protection contre les programmes malveillants - contrôles d’application Fournir des preuves démontrables qu’une liste approuvée de logiciels/applications avec justification métier existe et est à jour.
Que chaque application soit soumise à un processus d’approbation et d’approbation avant son déploiement
Cette technologie de contrôle d’application est active, activée et configurée sur tous les composants système échantillonnés, comme indiqué.
Gestion des correctifs - mise à jour corrective et classement des risques Fournissez une documentation de stratégie qui régit la façon dont les nouvelles vulnérabilités de sécurité sont identifiées et affectées à un score de risque.
Fournir des preuves de la façon dont les nouvelles vulnérabilités de sécurité sont identifiées.
Fournissez des preuves montrant que toutes les vulnérabilités se voient attribuer un classement des risques une fois identifiées.
Indiquez que tous les composants système échantillonnés sont corrigés conformément aux délais de mise à jour corrective définis par les organisations et que les systèmes d’exploitation et les composants logiciels non pris en charge ne sont pas utilisés. Le cas échéant, cela doit inclure la base de code si une technologie serverless ou PaaS est utilisée, ou l’infrastructure et la base de code si IaaS est utilisé.
Recommandations relatives à la période de mise à jour corrective : Critique – dans les 14 jours, Élevé – Dans les 30 jours, Moyen – Dans les 60 jours.
Analyse des vulnérabilités Fournissez les rapports trimestriels d’analyse des vulnérabilités de l’infrastructure et des applications web. L’analyse doit être effectuée sur l’ensemble de l’empreinte publique (adresses IP et URL) et sur les plages d’adresses IP internes.
Fournissez des preuves démontrables que la correction des vulnérabilités identifiées pendant l’analyse des vulnérabilités est corrigée conformément à votre période de mise à jour corrective documentée.
Contrôles de sécurité réseau (NSC) Indiquez que les contrôles de sécurité réseau (NSC) sont installés à la limite de l’environnement dans l’étendue et installés entre le réseau de périmètre et les réseaux internes.
ET si l’iaaS hybride, local, fournit également la preuve que tout accès public se termine au niveau du réseau de périmètre.
Vérifiez que tous les contrôles de sécurité réseau (NSC) sont configurés pour supprimer le trafic qui n’est pas explicitement défini dans la base de règles et que les révisions des règles de contrôle de sécurité réseau (NSC) sont effectuées au moins tous les 6 mois.
Contrôle des modifications Fournir des preuves que les modifications introduites dans les environnements de production sont implémentées par le biais de demandes de modification documentées qui contiennent l’impact de la modification, les détails des procédures de back-out, les tests à effectuer, l’examen et l’approbation par le personnel autorisé.
Fournissez la preuve qu’il existe des environnements distincts afin que : les environnements de développement et de test/préproduction appliquent la séparation des tâches de l’environnement de production, la séparation des tâches est appliquée via des contrôles d’accès, et les données de production sensibles ne sont pas utilisées dans les environnements de développement ou de test/intermédiaire.
Développement/déploiement de logiciels sécurisés Fournissez des stratégies et des procédures qui prennent en charge le développement de logiciels sécurisés et incluent les normes du secteur et/ou les meilleures pratiques pour le codage sécurisé. Par exemple, Open Web Application Security Project (OWASP) Top 10 ou SysAdmin, Audit, Network and Security (SANS) Top 25 Common Weakness Enumeration (CWE).
Fournir des preuves que les dépôts de code sont sécurisés de sorte que : toutes les modifications de code font l’objet d’un processus de révision et d’approbation par un deuxième réviseur avant d’être fusionnées avec main branche, que les contrôles d’accès appropriés sont en place, que tous les accès sont appliqués via l’authentification multifacteur (MFA)
Fournissez la preuve que toutes les mises en production effectuées dans les environnements de production sont examinées et approuvées avant leur déploiement.
Gestion des comptes Indiquez que les informations d’identification par défaut sont désactivées, supprimées ou modifiées dans les composants système échantillonnées.
Indiquez qu’un processus est en place pour sécuriser (renforcer) les comptes de service et que ce processus a été suivi.
Fournissez la preuve que : des comptes d’utilisateur uniques sont émis pour tous les utilisateurs, que les principes des privilèges minimum des utilisateurs sont respectés dans l’environnement, qu’une stratégie de mot de passe/phrase secrète forte ou d’autres mesures d’atténuation appropriées sont en place, qu’un processus est en place et suivi au moins tous les trois mois pour désactiver ou supprimer les comptes non utilisés dans les trois mois.
Vérifiez que l’authentification multifacteur est configurée pour toutes les connexions d’accès à distance et toutes les interfaces d’administration hors console, y compris l’accès aux dépôts de code et aux interfaces de gestion cloud.
Journalisation, révision et alertes des événements de sécurité Fournissez la preuve qu’un minimum de 30 jours de données de journalisation des événements de sécurité est immédiatement disponible, avec 90 jours de journaux d’événements de sécurité conservés.
Fournir des preuves que les journaux sont examinés régulièrement et que tous les événements/anomalies de sécurité potentiels identifiés pendant le processus de révision sont examinés et traités
Indiquez que les règles d’alerte sont configurées afin que les alertes soient déclenchées pour investigation pour les événements de sécurité suivants, le cas échéant : création/modifications de comptes privilégiés, activités ou opérations privilégiées/à haut risque, événements de programmes malveillants, falsification du journal des événements, événements IDPS/WAF. (si configuré)
Gestion des risques liés aux informations Fournir la preuve qu’une politique ou un processus officiel de gestion des risques liés à la sécurité de l’information ratifié est documenté et établi.
Fournir des preuves qu’une évaluation formelle des risques de sécurité des informations à l’échelle de l’entreprise est effectuée au moins une fois par an.
OR pour l’analyse des risques ciblés : une analyse des risques ciblées est documentée et effectuée au moins tous les 12 mois pour chaque instance où un contrôle traditionnel ou une bonne pratique du secteur n’est pas en place, lorsqu’une limitation de conception/technologie crée un risque d’introduire une vulnérabilité dans l’environnement ou met les utilisateurs et les données en danger, en cas de suspicion ou de confirmation de compromission.
Vérifiez que l’évaluation des risques liés à la sécurité des informations inclut un composant système ou une ressource affectée, des menaces et des vulnérabilités ou des matrices d’impact et de probabilité équivalentes ou équivalentes, la création d’un registre des risques/plan de traitement des risques.
Indiquez que vous disposez d’un processus de gestion des risques qui évalue et gère les risques associés aux fournisseurs et aux partenaires commerciaux, et que vous pouvez identifier et évaluer les changements et les risques susceptibles d’avoir un impact sur votre système de contrôles internes.
Réponse aux incidents de sécurité Fournissez votre plan/procédure de réponse aux incidents de sécurité (IRP) ratifié.
Fournissez des éléments de preuve décrivant la façon dont votre organization répond aux incidents, montrant comment il est géré et qu’il inclut les détails de l’équipe de réponse aux incidents, y compris les informations de contact, un plan de communication interne pendant l’incident et la communication externe aux parties concernées telles que les parties prenantes clés, les marques de paiement et les acquéreurs, les organismes de réglementation (par exemple, 72 heures pour le RGPD), les autorités de contrôle, directeurs, clients, ainsi que les étapes pour les activités telles que la classification des incidents, l’endiguement, l’atténuation, la récupération et le retour à des opérations normales selon le type d’incident
Fournissez la preuve que tous les membres de l’équipe de réponse aux incidents ont reçu une formation annuelle qui leur permet de répondre aux incidents.
Fournir des preuves que la stratégie de réponse aux incidents et la documentation connexe sont examinées et mises à jour en fonction des leçons tirées d’un exercice de haut de tableau, des leçons tirées de la réponse à un incident, des changements organisationnels.
Plan de continuité d’activité et plan de récupération d’urgence Fournissez la preuve que la documentation existe et qu’elle est conservée, ce qui décrit le plan de continuité d’activité.
Fournissez des preuves que le plan de continuité d’activité détaille le personnel concerné et ses rôles et responsabilités, notamment les fonctions métier avec les exigences et les objectifs d’urgence associés, les procédures de sauvegarde du système et des données, la configuration et la planification/rétention, les objectifs de priorité et de délai de récupération, un plan d’urgence détaillant les actions, les étapes et les procédures à suivre pour retourner les systèmes d’information critiques, les fonctions métier et les services à fonctionner en cas d’une opération interruption inattendue et non planifiée, un processus établi qui couvre la restauration complète du système et le retour à l’état d’origine.
Fournissez des preuves que la documentation existe, qu’elle est conservée et qu’elle décrit le plan de récupération d’urgence et inclut au minimum : personnel et leurs rôles, responsabilités et processus d’escalade, l’inventaire des systèmes d’information utilisés pour prendre en charge les fonctions et services métier critiques, les procédures et la configuration de sauvegarde des données et du système, un plan de récupération détaillant les actions et procédures à suivre pour restaurer les systèmes d’information critiques et les données à utiliser.
Fournir des preuves que le plan de continuité d’activité et le plan de reprise d’activité sont examinés au moins tous les 12 mois pour s’assurer qu’ils restent valides et efficaces dans les situations défavorables.
Fournissez des preuves que le plan de continuité d’activité est mis à jour en fonction de l’examen annuel du plan, que tous les employés concernés reçoivent une formation sur leurs rôles et responsabilités attribués dans les plans d’urgence, que les plans sont testés par le biais d’exercices de continuité d’activité ou de reprise d’activité, que les résultats des tests sont documentés, y compris les leçons tirées de l’exercice ou des changements organisationnels.

Sécurité et confidentialité de la gestion des données

Pour garantir la sécurité des données, toutes les données en transit entre l’utilisateur de l’application, les services intermédiaires et les systèmes ISV doivent être chiffrées à l’aide d’une connexion TLS (Transport Layer Security). Au minimum, TLS 1.2 est requis, avec TLS 1.3 ou une version ultérieure fortement recommandée. Pour plus d’informations, reportez-vous à l’Annexe A.

Pour les applications qui récupèrent ou stockent des données Microsoft 365, il est obligatoire d’implémenter un schéma de chiffrement de stockage de données. Cela doit être conforme aux spécifications décrites à l’annexe B.

Contrôles

Famille de contrôles Controls
Données en transit Indiquez que la configuration TLS est TLS1.2 ou ultérieure dans les exigences de configuration du profil TLS et qu’un inventaire des clés et certificats approuvés est conservé et tenu à jour.
Indiquez que la compression TLS est désactivée pour tous les services publics qui gèrent les requêtes web afin d’empêcher la fuite d’informations sur le taux de compression made easy (CRIME), et que TLS HSTS est activé et configuré sur 180 jours sur tous les sites.
Données au repos Fournissez la preuve que les données au repos sont chiffrées conformément aux exigences du profil de chiffrement, à l’aide d’algorithmes de chiffrement tels que Advanced Encryption Standard (AES), RSA et Twofish avec des tailles de clé de chiffrement de 256 bits ou plus.
Conservation, sauvegarde et destruction des données Fournir la preuve qu’une période de conservation des données approuvée est formellement établie et documentée.
Indiquez que les données sont conservées uniquement pendant la période de rétention définie, comme indiqué dans le contrôle précédent.
Fournissez la preuve que des processus sont en place pour supprimer en toute sécurité les données après leur période de rétention.
Indiquez qu’un système de sauvegarde automatisé est en place et configuré pour effectuer des sauvegardes à des heures planifiées.
Fournir des preuves que les informations de sauvegarde sont testées conformément à la procédure de planification de sauvegarde et restaurées régulièrement pour confirmer la fiabilité et l’intégrité des données.
Fournir des preuves des contrôles d’accès et des mécanismes de protection appropriés (c’est-à-dire des sauvegardes immuables) sont implémentés pour garantir que les sauvegardes/captures instantanées système sont sécurisées contre les accès non autorisés et pour garantir la confidentialité, l’intégrité et la disponibilité des données de sauvegarde.
Gestion de l’accès aux données Fournissez la preuve qu’une liste d’utilisateurs ayant accès aux données et/ou aux clés de chiffrement est conservée. Inclusion de la justification métier pour chaque personne et confirmation que cette liste d’utilisateurs a été officiellement approuvée en fonction des privilèges d’accès requis pour leur fonction de travail et les utilisateurs sont configurés avec les privilèges décrits dans l’approbation.
Fournissez la preuve qu’une liste de tous les tiers avec qui les données sont partagées est conservée et que des accords de partage de données sont en place avec tous les tiers qui consomment des données.
Confidentialité Votre organization dispose-t-il d’un système de gestion des informations de confidentialité (PIM) établi, mis en œuvre et géré qui contient un engagement de leadership au moyen d’une politique ou d’une autre forme de documentation ou d’un système informatisé pour la façon dont vos efforts de gestion des informations de confidentialité sont maintenus pour la confidentialité et l’intégrité du système. Détermine les rôles, les responsabilités et les autorités de chaque personne qui gère le système, y compris les processeurs et les contrôleurs d’informations d’identification personnelle.
Fournir des preuves de processus pour vérifier que la réduction des piI est en cours, la désidentification et la suppression des informations d’identification personnelles sont effectuées à la fin de la période de traitement, des contrôles sont en place pour la transmission des informations d’identification personnelle, y compris toute confidentialité, l’enregistrement du transfert des informations personnelles d’un pays/région à un autre existe avec le consentement explicite pour le faire.
RGPD Fournissez la preuve que les personnes concernées sont en mesure d’émettre des demandes d’accès partagé, que l’éditeur de logiciels indépendant est en mesure d’identifier tous les emplacements des données des personnes concernées lorsqu’ils répondent à une demande de récupération de données, qu’il existe une période de rétention pour les sauvegardes qui permettent aux clients demandant la suppression de données par le biais de sar à mesure que les sauvegardes propagées sur une période sont supprimées (cycle de vie des suppressions de sauvegarde les plus anciennes/réécriture).
Fournissez la déclaration de confidentialité qui doit contenir tous les éléments requis comme suit : les détails de l’organisation (nom, adresse et autres informations d’identification personnelle), le type de données personnelles traitées, la durée de conservation des données personnelles, la licéité du traitement des données personnelles, les droits des personnes concernées ; notamment : les droits de la personne concernée, le droit d’être informé, le droit d’accès par la personne concernée, le droit à l’effacement, le droit à la restriction du traitement, le droit à la portabilité des données, le droit d’opposition, les droits relatifs à la prise de décision automatisée, y compris le profilage.
Loi américaine HIPAA Fournissez la preuve qu’il existe une stratégie de gestion HIPAA et HIPAA au sein de votre organization pour le personnel, les sous-traitants, les fournisseurs, etc. Vérifiez notre organization garantit la confidentialité, l’intégrité et la disponibilité d’ePH.
Vérifiez que vous : fournissez une protection contre les utilisations raisonnablement anticipées ou les divulgations de telles informations qui ne sont pas autorisées par la règle de confidentialité, assurez-vous que son personnel se conforme à la règle de sécurité. Fournissez un plan de sauvegarde et de récupération d’urgence des données sous 164.308 (a)(7)(ii)(A) et 164.308 (a)(7)(ii)(B).

Révision facultative de l’infrastructure de conformité externe

Si votre organization est déjà conforme aux frameworks de sécurité externes tels que ISO 27001, PCI DSS, FedRAMP ou SOC 2 Type 2, vous pouvez choisir de tirer parti de ces certifications pour satisfaire certains des contrôles de certification Microsoft 365. Les analystes s’efforceront d’aligner vos infrastructures de sécurité externes existantes sur les exigences de certification Microsoft 365.

Toutefois, si votre documentation à l’appui ne montre pas que les contrôles de certification Microsoft 365 ont été explicitement évalués dans le cadre de l’audit ou de l’évaluation de l’infrastructure externe, vous devez fournir des preuves supplémentaires pour vérifier que ces contrôles sont en place.

Documentation requise

La documentation doit démontrer clairement que l’environnement dans l’étendue de la certification Microsoft 365 est inclus dans l’étendue des frameworks de sécurité éternels. La validation de ces frameworks sera effectuée en acceptant des preuves de certifications valides émises par des auditeurs tiers accrédités et dignes de confiance.

Ces auditeurs tiers doivent être membres d’organismes d’accréditation internationaux, tels que :

  • Normes de certification et de conformité pour ISO 27001

  • Évaluateurs de sécurité de la qualité (QSA) pour PCI DSS

Pour plus d’informations, reportez-vous aux directives et normes spécifiques pour les frameworks externes pertinents pour votre certification.

Le tableau ci-dessous présente les frameworks et la documentation requis acceptés par les analystes de certification dans le cadre du processus de validation.

Standard Conditions requises
ISO 27001 Une version publique de la déclaration d’applicabilité (SOA) et une copie du certificat ISO 27001 émis seront nécessaires. La SOA résume votre position sur chacun des 114 contrôles de sécurité des informations et sera utilisée pour identifier si une exclusion de contrôles qui ne sont pas correctement détaillés dans le certificat ISO 27001. Si cela ne peut pas être déterminé en examinant la version publique de la SOA, l’analyste peut avoir besoin d’accéder à la SOA complète si ISO 27001 est utilisé pour valider certains des contrôles de sécurité de la certification Microsoft 365. En plus de valider l’étendue des activités d’évaluation ISO 27001, les analystes confirmeront également la validité de l’entreprise d’audit comme décrit ci-dessus.
PCI DSS Un document d’attestation de conformité (AOC) de niveau 1 valide doit être fourni, identifiant clairement les composants système et d’application dans l’étendue. Un AOC d’auto-évaluation ne sera pas accepté comme preuve de respect des bonnes pratiques de sécurité. L’AOC sera utilisé pour déterminer quels contrôles de la spécification de certification Microsoft 365 ont été évalués et confirmés dans le cadre de l’évaluation PCI DSS.
SOC 2 Le rapport SOC 2 (Type II) doit être à jour (émis au cours des 15 derniers mois et la période déclarée commencée au cours des 27 derniers mois) pour être utilisé comme preuve de conformité avec l’un des contrôles d’évaluation dans ce cadre de certification Microsoft 365.
FedRAMP Le Federal Risk and Authorization Management Program (FedRAMP) est un programme fédéral américain mis en place en 2011. Il fournit une approche standardisée de l’évaluation de la sécurité, de l’autorisation et de la surveillance continue des produits et services cloud.
Infrastructure Considérations supplémentaires
ISO 27001 Annexe C : Collection de preuves – Deltas pour ISO 27001.
PCI DSS Annexe D : Collecte de preuves – Deltas pour PCI DSS.
SOC 2 Annexe E : Collecte de preuves – Deltas pour SOC 2.

Remarque

Bien que les normes ou frameworks de sécurité externes puissent être soumis comme preuve de conformité à certains contrôles de certification Microsoft 365, l’obtention de la certification Microsoft 365 nécessite une évaluation distincte. L’obtention de la certification Microsoft 365 n’implique pas que l’application a entièrement passé des audits pour ces frameworks externes. La spécification de certification Microsoft 365 se concentre sur un sous-ensemble spécifique de contrôles dérivés de ces frameworks pour fournir à Microsoft un niveau plus élevé d’assurance concernant la posture de sécurité de votre application.

Conditions requises pour utiliser des frameworks de conformité externes

✓ L’environnement dans l’étendue ET tous les processus métier de prise en charge doivent être inclus dans l’étendue de tous les frameworks de conformité de sécurité externes pris en charge et doivent être clairement indiqués dans la documentation fournie.

✓ Les frameworks de conformité de sécurité externes pris en charge DOIVENT être à jour, c’est-à-dire au cours des 12 derniers mois (ou dans les 15 mois si la réévaluation est en cours et que des preuves peuvent être fournies).

✓ Les infrastructures de conformité de sécurité externes prises en charge doivent être effectuées par une entreprise indépendante accréditée.

En savoir plus