Aller au contenu principal
Expert Cybersécurité & IAv9.0
Centres de ressources conformité
Besoin d'un accompagnement expert ?
Devis personnalisé sous 24h — audit, conformité, incident
Checklists Sécurité — Audit & Durcissement
Formats disponibles
📄 PDF 📊 Excel 🌐 Web

11 checklists professionnelles couvrant 2 200+ points de contrôle. Téléchargement gratuit, aucune inscription.

Contrat Niveau de Service Cybersécurité SLA

conformite

Définition

Un Service Level Agreement (SLA) cybersécurité, ou Accord de Niveau de Service dédié à la cybersécurité, est un contrat ou une section de contrat définissant les engagements mesurables d'un prestataire de services de sécurité (MSSP — Managed Security Service Provider, hébergeur, fournisseur SaaS) envers son client en matière de disponibilité, de détection des incidents, de temps de réponse, et de conformité réglementaire. Il traduit les exigences de sécurité du client en obligations contractuelles opposables au prestataire. Les métriques typiques d'un SLA cybersécurité couvrent plusieurs dimensions. La disponibilité (Uptime) — généralement exprimée en pourcentage d'uptime mensuel (99,9% ≈ 8,7h d'indisponibilité/an, 99,99% ≈ 52 minutes/an) — est la métrique la plus connue, mais n'est pas suffisante seule pour couvrir la cybersécurité. Les métriques de détection et réponse aux incidents incluent MTTD (Mean Time to Detect) — délai moyen entre l'occurrence d'un incident et sa détection, MTTR (Mean Time to Respond/Resolve) — délai moyen entre la détection et la résolution, et MTTC (Mean Time to Contain) — délai de confinement de l'incident pour limiter les dommages. Les SLA de cybersécurité pour les MSSP (prestataires SOC externalisé) précisent : les délais de notification des incidents au client (ex. : notification dans les 30 minutes pour les incidents critiques P1, 4h pour les incidents majeurs P2), la plage horaire de couverture (24/7 ou 8h-18h ouvrés), les types d'incidents couverts, et les procédures d'escalade. Certains SLA incluent également des engagements sur la couverture de détection (ex. : couverture de X% des techniques MITRE ATT&CK dans le scope convenu). Les pénalités contractuelles (SLA penalties ou Service Credits) définissent les compensations dues par le prestataire en cas de non-respect du SLA. Elles peuvent prendre la forme de crédits sur la facture suivante (le modèle le plus courant dans le SaaS cloud), de réductions tarifaires, ou de clauses de résiliation sans pénalité en cas de SLA breach grave. Ces pénalités incitent contractuellement le prestataire à respecter ses engagements. La conformité réglementaire est une dimension croissante des SLA cyber : NIS2 et DORA imposent des exigences sur les prestataires de services de sécurité et les fournisseurs ICT critiques. DORA (article 30) impose un contenu minimal pour les contrats avec les prestataires ICT tiers des entités financières, incluant des SLA explicites sur la disponibilité, la performance de sécurité, et les droits d'audit du régulateur.

Métriques clés d'un SLA cybersécurité

Métriques de disponibilité : Uptime mensuel SLA (99,9% = 8,7h/an max d'indisponibilité ; 99,99% = 52 min/an) ; RTO (Recovery Time Objective) — temps maximum avant reprise de service après incident ; RPO (Recovery Point Objective) — perte de données maximale acceptable (en temps). Métriques de détection et réponse : MTTD (Mean Time to Detect) — SLA de détection initial, ex. : P1 critique < 15 min, P2 majeur < 1h ; MTTR (Mean Time to Resolve) — SLA de résolution, ex. : P1 < 4h, P2 < 8h ; MTTC (Mean Time to Contain) — isolation de l'incident pour éviter propagation.

Métriques de reporting et communication : délai de notification incident au client (P1 < 30 min, P2 < 2h) ; fréquence des rapports de sécurité (mensuel, trimestriel) ; délai de livraison des rapports post-incident (PIR — Post Incident Review, souvent < 72h après résolution) ; disponibilité d'un tableau de bord temps réel (accès client au portail de suivi des incidents). Métriques de conformité : délai de patch critique (P0 < 24h, P1 < 72h, P2 < 7 jours) ; taux de couverture des sauvegardes et succès des tests de restauration (mensuels) ; délai de notification RGPD au client en cas de violation (< 24h pour permettre au client de notifier la CNIL dans les 72h).

SLA DORA pour prestataires ICT financiers

DORA (Règlement UE 2022/2554) impose dans son article 30 un contenu contractuel minimal pour les accords avec les prestataires ICT tiers des entités financières : description précise et complète des services, localisation des données, SLA incluant la disponibilité et la performance de sécurité, droits d'audit du client sur le prestataire, droits d'audit des autorités de contrôle (BCE, ACPR), exigences de notification des incidents, et clauses de continuité de service et de sortie (exit plan). Les prestataires ICT critiques désignés par les autorités de contrôle européennes sont soumis à une supervision directe (framework de supervision DORA des prestataires ICT tiers critiques).

La négociation des SLA DORA avec les hyperscalers cloud (AWS, Azure, GCP) est un défi pour les banques et assurances : les grands fournisseurs proposent des contrats standardisés et refusent souvent de personnaliser les SLA pour chaque client. Des clauses additionnelles (Addendum bancaires — ex. : ISDA CDEA pour les banques) et les guides publiés par l'EBA (European Banking Authority) aident à structurer ces négociations contractuelles.

Clause d'audit et droit de contrôle

Le droit d'audit du client sur le prestataire est une clause essentielle des SLA cybersécurité, imposée par DORA (art. 30) et recommandée par le RGPD (art. 28 — preuve de conformité). Cette clause permet au client de vérifier que le prestataire respecte ses engagements de sécurité et de conformité, soit directement (audit sur site du datacenter), soit via des rapports d'audit tiers (SOC 2 Type II, ISO 27001).

En pratique, les grands prestataires SaaS et cloud accordent rarement des droits d'audit sur site individuels (trop coûteux à gérer pour de nombreux clients). L'alternative acceptée est la mise à disposition de rapports d'audit tiers : SOC 2 Type II (sécurité, disponibilité, confidentialité), ISO 27001 (sécurité de l'information), ISO 27017 (cloud), et rapports PCI-DSS pour les services de paiement. Ces rapports doivent être récents (< 12 mois) et couvrir le périmètre du service utilisé.

Articles liés

Un projet cybersécurité ?

Expert dispo · Réponse 24h

Devis