Microsoft 365 et ISO 27001 : mapping des contrôles Annexe A

Microsoft 365 équipe aujourd'hui plus de 80 % des PME françaises. Exchange Online, SharePoint, Teams, Entra ID — la suite Microsoft est devenue l'épine dorsale du système d'information. Pourtant, lorsqu'une PME engage une démarche ISO 27001, la première erreur est de croire que « Microsoft s'occupe de la sécurité ». C'est faux — ou plutôt, c'est incomplet.

ISO 27001:2022 impose un Système de Management de la Sécurité de l'Information (SMSI) structuré autour de 93 contrôles répartis dans l'Annexe A. Microsoft 365 couvre effectivement plusieurs de ces contrôles — parfois totalement, souvent partiellement. Comprendre ce mapping est indispensable pour construire votre Déclaration d'Applicabilité (SOA) et piloter votre conformité sans redondances ni angles morts.

Ce guide détaille, contrôle par contrôle, ce que M365 couvre réellement, et ce que votre organisation doit compléter pour satisfaire un auditeur ISO 27001 certifié.

Responsabilité partagée Microsoft / organisation (clause A.5.23)

Le contrôle A.5.23 « Sécurité de l'utilisation des services cloud » est souvent mal compris. Il ne dit pas que le prestataire cloud est responsable de la sécurité de vos données — il impose à l'organisation de définir, surveiller et contracter les mesures de sécurité attendues du fournisseur.

Microsoft publie son modèle de responsabilité partagée (Shared Responsibility Model) : il varie selon le type de service (IaaS, PaaS, SaaS). Pour Microsoft 365 (SaaS) :

• Microsoft est responsable : infrastructure physique des datacenters, disponibilité de la plateforme, sécurité du réseau sous-jacent, chiffrement en transit et au repos des données hébergées, patchs du système d'exploitation des serveurs
• Votre organisation reste responsable : configuration des politiques d'accès, gestion des identités et des droits, classification des données, sensibilisation des utilisateurs, détection des incidents dans votre tenant, continuité d'activité applicative

En pratique : un tenant M365 mal configuré (MFA désactivé, permissions administrateur excessives, absence de DLP) reste une surface d'attaque majeure — même si Microsoft garantit la disponibilité de la plateforme à 99,9 %. L'attestation ISO 27001 de Microsoft (disponible dans le Microsoft Trust Center) ne se transfère pas à votre organisation.

Microsoft Entra ID → Contrôles d'accès et identités

Entra ID (anciennement Azure Active Directory) est le pilier central de la gestion des identités dans M365. Il couvre directement plusieurs contrôles critiques de l'Annexe A :

A.5.15 — Contrôle d'accès

Entra ID permet de définir des politiques d'accès conditionnel (Conditional Access) basées sur l'identité, l'emplacement, le device, le risque. Ces politiques constituent une implémentation directe du contrôle A.5.15. Pour être conforme, votre organisation doit :

• Documenter une politique de contrôle d'accès formelle
• Configurer les Conditional Access Policies dans Entra ID
• Activer l'authentification multifacteur (MFA) pour tous les comptes, à minima pour les administrateurs

A.5.16 — Gestion des identités

L'annuaire Entra ID constitue votre système de gestion des identités. La conformité A.5.16 exige un processus formalisé de création, modification et suppression des comptes. M365 fournit les outils ; votre organisation doit fournir les procédures : procédure d'onboarding/offboarding utilisateur, révision périodique des comptes actifs, désactivation immédiate à la fin du contrat.

A.5.18 — Droits d'accès

L'attribution, la révision et la révocation des droits d'accès (A.5.18) sont supportées par les fonctionnalités d'Access Reviews d'Entra ID (disponible en Entra ID P2). Ces révisions permettent de demander aux responsables de confirmer périodiquement les accès de leurs équipes. Sans cette fonctionnalité activée et documentée, la conformité A.5.18 reste partielle.

A.8.2 — Droits d'accès privilégiés

Privileged Identity Management (PIM) est la réponse de Microsoft au contrôle A.8.2. PIM permet d'attribuer les rôles d'administrateur en mode « just-in-time » : l'élévation est temporaire, auditée, et nécessite une justification. Un auditeur ISO 27001 recherchera systématiquement la preuve que les accès privilégiés sont tracés et limités dans le temps. PIM est disponible en Entra ID P2 / Microsoft 365 E3/E5.

Microsoft Purview → Classification et protection des données

Microsoft Purview (anciennement Microsoft Information Protection + Compliance Center) couvre les contrôles liés à la classification, à l'étiquetage et à la prévention des fuites de données.

A.5.12 et A.5.13 — Classification et étiquetage de l'information

Les labels de sensibilité Purview permettent de classifier les documents et emails (Public, Interne, Confidentiel, Hautement confidentiel) et d'appliquer des protections automatiques (chiffrement, watermark, restrictions de partage). Cette fonctionnalité couvre directement A.5.12 (classification) et A.5.13 (étiquetage). Prérequis : une politique de classification documentée, des labels déployés via Purview, et une formation des utilisateurs à l'étiquetage manuel.

A.8.12 — Prévention des fuites de données (DLP)

Les politiques DLP Purview permettent de détecter et bloquer le partage non autorisé d'informations sensibles (numéros de carte bancaire, NIR, données de santé, secrets d'affaires) dans Exchange Online, SharePoint, OneDrive, Teams et les endpoints Windows. La couverture A.8.12 est partielle sans DLP Endpoint activé sur les postes de travail. Un inventaire des flux de données sensibles reste à produire manuellement.

A.8.15 — Journalisation (via Purview Audit)

Purview Audit (Standard et Premium) journalise les activités des utilisateurs et des administrateurs dans M365 : connexions, accès aux fichiers, modifications de configuration, suppressions. Les journaux sont conservés 90 jours (Standard) ou 1 an (Premium, Microsoft 365 E5). Pour satisfaire A.8.15, votre organisation doit définir une durée de conservation des logs adaptée au risque, et documenter les procédures de revue des journaux.

Microsoft Defender → Détection des menaces et protection

La famille Microsoft Defender couvre plusieurs contrôles de protection technique de l'Annexe A :

A.8.7 — Protection contre les malwares

Defender for Office 365 (Plans 1 et 2) protège Exchange Online contre le phishing, les pièces jointes malveillantes (Safe Attachments) et les liens suspects (Safe Links). Defender for Endpoint assure la protection antimalware, l'EDR (Endpoint Detection and Response) et la réponse aux incidents sur les postes Windows. Ces deux outils couvrent substantiellement A.8.7, à condition d'être activés en mode Bloc (et non Audit) et de définir une procédure de gestion des alertes.

A.8.16 — Surveillance des activités

Defender for Identity analyse le trafic Active Directory on-premise et détecte les attaques de type pass-the-hash, Golden Ticket, reconnaissance LDAP. Il couvre A.8.16 pour les environnements hybrides (AD + Entra ID). Defender XDR (eXtended Detection and Response) corrèle les alertes de l'ensemble des capteurs Defender pour une vision unifiée des incidents de sécurité.

Microsoft Sentinel → SIEM/SOAR (A.8.15, A.8.16, A.5.26)

Microsoft Sentinel est le SIEM cloud-natif de Microsoft, intégré nativement avec l'ensemble des sources de données M365 et Azure. Pour ISO 27001 :

• A.8.15 (Journalisation) : Sentinel centralise les logs M365, Azure, Active Directory, et les sources tierces (pare-feu, EDR, cloud providers), avec des durées de rétention configurables jusqu'à 7 ans
• A.8.16 (Surveillance des activités) : les règles d'analyse Sentinel (UEBA, threat intelligence, règles KQL) détectent les comportements anormaux en temps réel
• A.5.26 (Réponse aux incidents) : les playbooks Sentinel (Logic Apps) automatisent les premières réponses — isolation d'un compte compromis, notification des équipes, création de ticket ITSM

Sentinel est un service Azure payant (facturation à l'ingestion de données, en Go/jour). Pour une PME de 50-200 utilisateurs M365, le coût mensuel est typiquement entre 200 et 800€/mois selon le volume de logs ingérés. Pour déployer Sentinel avec les connecteurs M365, Microsoft fournit des guides détaillés dans sa documentation.

Tableau de mapping Microsoft 365 / Annexe A ISO 27001:2022

Ce que Microsoft 365 ne couvre PAS dans ISO 27001

M365 est un excellent levier technologique, mais ISO 27001 est avant tout un système de management. Les aspects suivants restent entièrement à la charge de votre organisation, indépendamment des outils Microsoft déployés :

Clauses du référentiel non couvertes par M365

• Clause 4 — Contexte de l'organisation : parties prenantes, périmètre SMSI, analyse des enjeux internes/externes — aucun outil Microsoft ne produit ce document
• Clause 5 — Leadership : engagement de la direction, politique de sécurité formalisée, attribution des rôles SMSI — documents internes obligatoires
• Clause 6 — Planification : appréciation des risques (méthodologie EBIOS RM ou autre), plan de traitement des risques, objectifs de sécurité — M365 ne fait pas d'analyse de risque
• Clause 7 — Support : compétences des équipes, sensibilisation (security awareness), communication interne — M365 propose Viva Learning mais ne gère pas la conformité de formation
• Clause 9.2 — Audit interne : programme d'audit, rapports d'audit, non-conformités — entièrement organisationnel
• Clause 9.3 — Revue de direction : réunion annuelle formalisée avec compte-rendu — aucun outil automatique
• Clause 10 — Amélioration : traitement des non-conformités, actions correctives — processus manuel

Contrôles Annexe A non couverts par M365

• A.5.1 — Politiques de sécurité de l'information (documents internes)
• A.6.1 à A.6.8 — Sécurité RH (screening, NDA, discipline, départ)
• A.7.1 à A.7.14 — Sécurité physique et environnementale (vos locaux)
• A.8.13 — Sauvegarde (M365 propose la réplication, pas la sauvegarde indépendante)
• A.5.29 / A.8.29 — Continuité / Sécurité dans le développement (si votre organisation développe)

En résumé : M365 constitue un socle technique solide qui couvre partiellement une quinzaine de contrôles sur 93. Pour une certification ISO 27001, votre organisation doit compléter avec des politiques écrites, des procédures, des formations et un programme de management formel. C'est précisément l'objet d'un accompagnement ISO 27001 par un cabinet spécialisé.

Foire aux questions — Microsoft 365 et ISO 27001

Est-ce que la certification ISO 27001 de Microsoft s'applique à mon organisation ?

Non. La certification ISO 27001 de Microsoft couvre ses propres services et datacenters. Elle atteste que Microsoft gère la sécurité de son infrastructure selon la norme. Votre organisation doit obtenir sa propre certification, indépendamment de celle de Microsoft.

Faut-il Microsoft Sentinel pour être certifié ISO 27001 avec M365 ?

Non, Sentinel n'est pas obligatoire. Mais un SIEM (qu'il soit Sentinel, autre outil cloud, ou on-premise) est généralement attendu par les auditeurs pour justifier la conformité A.8.15 (journalisation) et A.8.16 (surveillance). Purview Audit seul peut suffire pour les périmètres M365-only avec peu de flux.

M365 E5 est-il suffisant pour couvrir tous les contrôles techniques de l'Annexe A ?

Microsoft 365 E5 inclut Defender XDR, Entra ID P2, Purview E5, et Sentinel inclus (jusqu'à un certain volume). C'est la licence M365 la plus complète pour ISO 27001. Elle couvre partiellement ou totalement environ 20 contrôles sur 93 — les 73 restants nécessitent organisation, procédures et management.

Comment prouver la conformité M365 lors d'un audit ISO 27001 ?

L'auditeur vérifiera : les configurations Entra ID (MFA, Conditional Access activés), les politiques DLP Purview (actives en mode Bloc), les Access Reviews (logs de révision), les journaux Defender et Purview Audit, et la documentation de gouvernance associée (politiques, procédures). Exportez les configurations et conservez les rapports de révision.

Quelle licence M365 est le minimum pour démarrer une certification ISO 27001 ?

Microsoft 365 Business Premium est le minimum raisonnable : il inclut Defender for Business (EDR), Entra ID P1 (MFA + Conditional Access), et Purview Information Protection basique. Pour les fonctionnalités avancées (PIM, Access Reviews, Sentinel), une licence E3/E5 est nécessaire.

Checklist : préparer son audit ISO 27001 avec Microsoft 365

Avant l'audit Stage 2, votre environnement Microsoft 365 doit être en ordre. Les auditeurs (Bureau Veritas, BSI, AFNOR) demandent des preuves concrètes pour chaque contrôle couvert par M365. Voici les 10 vérifications indispensables.

Les 10 points à vérifier avant l'audit Stage 2

1. MFA enforced, pas seulement activé — vérifiez que les Conditional Access Policies imposent le MFA pour tous les utilisateurs, y compris les administrateurs. Un MFA "activé" mais non forcé est une non-conformité classique relevée en audit.
2. Logs Entra ID conservés 120 jours minimum — exportez et archivez les logs de connexion et d'audit Entra ID vers un Log Analytics Workspace ou un SIEM externe. Par défaut, Entra ID P1 ne conserve que 30 jours.
3. Rapports Defender for Endpoint en ordre — vérifiez le Secure Score M365 (ciblez >70%), les recommandations prioritaires appliquées, et les incidents clôturés avec preuves.
4. Labels Purview déployés et utilisés — un Purview configuré mais sans labels déployés sur les documents, emails et SharePoint est un contrôle A.5.12/A.5.13 non implémenté.
5. Politiques DLP actives sur tous les canaux — Exchange Online, SharePoint, OneDrive, Teams, Endpoint. Testez avec un faux numéro de carte bancaire ou NIR pour vérifier le déclenchement.
6. PIM configuré pour les comptes privilégiés — les rôles Global Admin, Security Admin et Exchange Admin doivent être en Just-In-Time via Privileged Identity Management (contrôle A.8.2).
7. Revue des accès documentée — exportez le rapport Access Review Entra ID des 3 derniers mois. Les accès non revus sont une non-conformité A.5.18.
8. Sentinel actif avec règles d'alerte — au moins 10 règles analytiques activées, couvrant les connexions impossibles, les élévations de privilèges et les exfiltrations de données.
9. Procédures de réponse aux incidents documentées — les playbooks Sentinel ou Logic Apps ne remplacent pas les procédures écrites (A.5.26). Préparez le document de procédure RIR.
10. Rapport de configuration exporté — générez un Secure Configuration Assessment depuis le Centre de sécurité M365 et annexez-le à votre dossier d'audit.

Preuves exportables pour l'auditeur

L'auditeur vérifiera les preuves suivantes lors du Stage 2 :

• Logs Entra ID : export CSV des connexions réussies et échouées sur les 90 derniers jours, avec géolocalisation.
• Rapport Secure Score : capture d'écran horodatée du tableau de bord M365 Defender avec le score et les actions réalisées.
• Alertes DLP déclenchées : rapport des incidents DLP des 90 derniers jours depuis le Portail de conformité Microsoft.
• Revues d'accès PIM : export des activations de rôles privilégiés et des justifications associées.
• Journaux Sentinel : incidents générés, temps de détection et de résolution, playbooks déclenchés.

Erreurs classiques à corriger avant l'audit

En accompagnement ISO 27001, les 5 erreurs M365 les plus fréquemment relevées par les auditeurs sont : MFA activé mais non enforced via Conditional Access (60% des cas), logs Entra conservés seulement 30 jours faute de Log Analytics Workspace, Purview déployé mais labels non publiés aux utilisateurs, Sentinel configuré sans règles analytiques personnalisées, et politiques DLP créées en mode simulation uniquement.

Un accompagnement spécialisé permet d'identifier et corriger ces écarts avant l'audit. Découvrez notre guide complet des 93 contrôles Annexe A ISO 27001 pour comprendre le référentiel complet, et consultez notre offre d'accompagnement ISO 27001 pour votre projet de certification.

Pour aller plus loin, consultez notre guide complet des 93 contrôles de l'Annexe A ISO 27001:2022 et notre page dédiée à l'accompagnement ISO 27001 pour PME. Notre cabinet accompagne les organisations dans la mise en conformité M365 dans le cadre des projets de certification ISO 27001 PME.