SOC 2 : critères de contrôle de sécurité

1) SOC 2 en quelques mots

SOC 2 est une évaluation indépendante de la façon dont l'organisation conçoit (Design) et exécute (Operating) les contrôles conformément à la Trust Services Critique (TSC) de l'AICPA.
Dans iGaming, cela renforce la confiance des régulateurs/banques/PSP/partenaires et simplifie TPRM.

• Type I - un état instantané (à une date donnée) : si les contrôles sont correctement conçus.
• Type II - par période (habituellement 6-12 mois) : si les contrôles fonctionnent de manière stable dans la pratique (avec des échantillons).

2) Trust Services Critique (TSC) et comment les lire

3) Modèle de contrôle et éléments obligatoires (Sécurité - CC)

Gouvernance et risque : politique de l'IB, registre des risques, objectifs, rôles/RACI, formation.
Contrôle d'accès : RBAC/ABAC, SoD, JIT/PAM, mots de passe/MFA, provisionnement SCIM/IGA, offbording ≤ 15 min.
Change & SDLC : DevSecOps, SAST/DAST/DS, IaC-scan, BOU, journaux de déployage, retours en arrière.
Logging & Monitoring : logs centralisés (WORM + signature), SIEM/SOAR, alertes par KRI.
Vuln & Patch : processus d'identification/classification, SLA sur High/Critical, confirmation de déploiement.
Incident Response : playbook, RACI, salle de guerre, postmortem et CAPA.
Vendor/TPRM : diligence raisonnable, DPA/SLA, droit d'audit, suivi des vendeurs.

4) Critères élargis (A, C, PI, P)

Availability (A)

SLO/SLA et dashboards ; DR/BCP (RTO/RPO), tests annuels ; capacité/région cross ; le processus des incidents d'accessibilité.

Confidentiality (C)

Classification des données ; Le cryptage en transit (KMS/HSM) ; Tokénisation du PII ; contrôle des exportations (signature, journal) ; la rétention.

Processing Integrity (PI)

Contrôle de la qualité des données : schémas/validations, déduplication, reconciliation ; contrôle du lancement des tâches ; gérer les changements dans les pipelines.

Privacy (P)

Politique de confidentialité ; RoPA/motifs légitimes ; CMR/consentement ; DPIA/DSAR; masquage/rétention ; audit des traceurs/SDK.

5) Mapping SOC 2 ↔ vos politiques/contrôles

L'ISO 27001/ISMS → couvre le cadre de la CC (gestion des risques, politiques, logs, vulnérabilités).
ISO 27701/PIMS → ferme de nombreux critères de confidentialité.
Sections internes : RBAC/Least Privilège, Politique de mot de passe et MFA, Politique de logs, Incidents, MRPT, DR/BCP - mappez directement sur TSC.

6) Catalogue de contrôles et exemples d'evidences

Pour chaque contrôle : ID, cible, propriétaire, fréquence, méthode (automatique/manuel), sources de preuves.

• 'SEC-ACCESS-01 '- MFA sur les accès admin → rapport IdP, sélection des paramètres, échantillonnage des logs.
• 'SEC-IGA-02 '- Offboarding ≤ 15 min → SCIM-logs, tiquets de licenciement, journal de blocage.
• 'SEC-LOG-05 '- Journaux invariables (WORM) → configis, chaînes de hachage, exportation d'échantillons.
• 'AVAIL-DR-01 '- Test de RD annuel → protocole d'essai, RTO/RPO réel.
• 'CONF-ENC-03 '- Gestion des clés KMS/HSM → politique de rotation, audit KMS.
• « PI-DATA-02 » - Reconnaissance des paiements → rapports de rapprochement, incidents, CAPA.
• « BOU-DSAR-01 » - SLA par DSAR → registre des requêtes, des temporisations, des modèles de réponse.

7) Procédures (SOP) pour maintenir le SOC 2

SOP-1 Incidents : détail → triage → containment → RCA → CAPA → rapport.
SOP-2 Gestion des changements : PR→CI/CD→skany→CAB→deploy→monitoring→otkat/fiksy.
SOP-3 de vulnérabilité : intake→klassifikatsiya→SLA→verifikatsiya fiksa→vypusk du rapport.
Accès SOP-4 : JML/IGA, re-certification trimestrielle, unités SoD, JIT/PAM.
SOP-5 DR/BCP : tests annuels, exercices partiels, publication des faits par RTO/RPO.
SOP-6 Exportation/confidentialité : listes blanches, signature/journal, retrait/suppression.

8) Préparation à l'audit : Type I → Type II

1. Analyse gap TSC : matrice des revêtements, liste des contrôles manquants.
2. Politiques et procédures : actualiser, désigner les propriétaires.
3. Stockage unique evidence : logs, rapports IdP/SIEM, tickets, exportations d'échantillons (avec signatures).
4. Audit de la réalité interne : lancer le questionnaire de l'auditeur, enregistrer les échantillons.
5. Type I (date X) : montrer la conception des contrôles et le fait de démarrer.
6. Période d'observation (6-12 mois) : collecte continue d'artefacts, fermeture des découvertes.
7. Type II : fournir des échantillons pour la période, rapport sur l'efficacité opérationnelle.

9) Métriques (KPI/KRI) pour SOC 2

• MFA adoption (admins/rôles critiques) = 100 %
• Offboarding TTR ≤ 15 min
• Patch SLA High/Critical fermé ≥ 95 % à temps
• Tests DR : exécution du planning = 100 %, les RTO/RPO réels sont normaux
• Coverage Loging (WORM) ≥ 95 % des systèmes critiques

• Accès à PII sans 'purpose' = 0
• Irrégularités SoD = 0
• Incidents notifiés plus tard que les règlements = 0
• Vulnérabilités répétées High/Critical> 5 % - escalade

10) RACI (agrandi)

11) Chèques-feuilles

11. 1 Lecture (avant Type I)

• Scope (TSC et systèmes) fixe
• Politiques/procédures pertinentes et approuvées
• Les propriétaires des contrôles et des métriques ont été désignés
• Prototype de stockage evidence prêt (logs, rapports IdP/SIEM, tickets)
• Pilule d'incident et mini-test DR effectués
• Les risques et la matrice SoD sont confirmés

11. 2 Période d'observation (entre I et II)

• Collecte hebdomadaire d'échantillons/exportations de loges
• Rapport mensuel KPI/KRI
• Fermeture des vulnérabilités dans l'ALS
• Certification trimestrielle des droits
• Test DR/BCP comme prévu

11. 3 Avant Type II

• Ensemble complet d'evidence pour la période (pour chaque contrôle)
• Registre des incidents/vulnérabilités et CAPA
• Rapport d'examen de la gestion (résultats de la période)
• Matrice de mapping mise à jour TSC↔kontroli

12) Erreurs fréquentes et comment les éviter

« Politiques sans pratique » : montrer des logs, des tiquets, des protocoles de RD/incidents - pas seulement des documents.
Logique faible : Sans WORM/signatures et sémantique claire des événements, l'audit est plus difficile.
Il n'y a pas de certification des droits : le risque d'accès « suspendu » est un inconvénient critique.
Scope incomplète des vendeurs : SOC 2 voit la chaîne - ajouter TPRM, DPA/SLA, droits d'audit.
Un bond ponctuel sans routine : mettre en place des SSM/Dashboards et des rapports mensuels.

13) Feuille de route (12-16 semaines → Type I, 6-12 mois supplémentaires. → Type II)

Semaines 1-2 : analyse de gap TSC, Scope, propriétaires, plan de travail.
Semaines 3 à 4 : mettre à jour les politiques/procédures, assembler le catalogue des contrôles et la matrice de mapping.
Semaines 5 à 6 : configurer les logs (WORM/signature), SIEM/SOAR, vulnérabilités/correctifs SLA, IdP/MFA, IGA/JML.
Semaines 7-8 : DR/BCP tests minimums, mises à jour TPRM (DPA/SLA), répétition de l'incident.
Semaines 9-10 : evidence-storage, rapports KPI/KRI, audit de lecture interne.
Semaines 11-12 : modifications finales, réservation de l'auditeur, Type I.
Suivant : collecte hebdomadaire d'artefacts, revues trimestrielles → Type II à la fin de la période.

TL; DR

SOC 2 = clair Scope TSC → le catalogue контролей avec les propriétaires et les actes de naissance → evidence selon Design et Operating → continu логи/SIEM/IGA/DR/TPRM → Readiness → Type I → la période de l'observation → Type II. Faites "la démontrabilité par défaut" - et l'audit passera sans surprises.