Pour les agents de conformité, directeurs TI et RSSI de BPO

FrontLine pour la conformité et l'informatique — l'arsenal du questionnaire d'approvisionnement.

Journal d'audit immuable. Isolation multi-locataire au niveau des lignes. Journal d'accès RPS. Flux DSAR. Trousse de preuves SOC 2 Type II. AAU d'entreprise. Tout ce que la révision sécurité d'un client d'entreprise demande — répondu dans le modèle de données, pas dans des diapos.

app.frontlinehq.io/compliance/overview

Tableau de bord conformité

Acme BPO · 247 agents · 4 clients · SOC 2 Type II — période : T2 2026

Événements audit · 30 j

2.1M

Révélations RPS · 24 h

14

DSAR ouverts

2

Mises en attente actives

3

Surfaces conformité

Journal d'audit · 2 147 892 événements · rétention 7 ans

Journal d'accès RPS · Agent de conformité seulement · alertes activées

Journal accès en échec · Force brute + sondages inter-locataires

Politiques de rétention · 8 catégories · plancher LPRPDE forcé

File DSAR · 2 ouverts · prochaine échéance 7 j

Mises en attente · 3 actives · évaluateur de portée en direct

Preuves SOC 2 · Trousse T2 générée · URL 24 h

Activité récente

HIGH

Trousse de preuves SOC 2 T2 générée · CC6/CC7/CC9/A1 · 14 217 événements · URL signée 24 h

12 m

MEDIUM

Demande DSAR soumise (LPRPDE) · Sujet employé · échéance 2026-06-18 · étape : en cours

1 h

HIGH

Sondage inter-locataire signalé · Acteur : jeton api n° 4128 · classé HAUT · ligne audit n° au-8921

2 h

MEDIUM

Édition politique de rétention — recruiting_applications_rejected · Fenêtre : 730 j → 365 j · confirmation rétroactive requise (409)

3 h

Journal d'audit · dernière heure

En direct

Aisha D.

employee.update

08:42

Hannah C.

pii.read

08:14

Balayage

retention.run

03:00

Système

audit.export

Hier
Agents de conformité · Directeurs informatique · RSSI

Ce qui est difficile pour la conformité dans un BPO multi-clients

Les SIRH et outils d'horaire génériques répondent aux questionnaires de conformité avec des diapos et de bonnes intentions. Les clients d'entreprise signent des ACDI qui disent « vos données opérationnelles ne peuvent pas toucher les nôtres ». La couche données est le seul endroit où cette réponse tient.

Risque : violation d'ACDI

Chaque client d'entreprise signe un ACDI différent

Chaque ACDI a sa propre clause d'isolation : « notre activité agent ne touche pas l'infrastructure d'autres clients ». Sur 7+ clients avec vérifications applicatives, chaque nouvelle requête est un endroit où une ligne inter-client peut fuir. L'approvisionnement le sait.

Risque : Excel forensique

Le journal d'audit vit dans 6 systèmes

RH, paie, horaire, AQ : quatre outils. « Qui a changé ce dossier à cette date ? » devient une extraction Excel forensique à travers les exports. Réponse une semaine en retard, jamais sûre d'être complète.

Fenêtre : 30 / 45 jours

Les demandes DSAR déclenchent un exercice d'urgence de 30 jours

« Donnez-moi tout ce que vous avez sur moi. » LPRPDE : 30 jours ; CCPA : 45. Chasse à travers 6 systèmes en espérant qu'aucune fuite inter-locataires ne se produise. Chaque DSAR est un test de crédibilité que vous pouvez échouer en silence.

Coût : audit de 3 semaines

Les preuves SOC 2 sont assemblées à la main chaque trimestre

Rassembler journaux, écrire CSV, étiqueter par contrôle, rédiger une narration. L'audit SOC 2 Type II prend trois semaines par année — si rien ne manque. L'officier de conformité passe son temps à réassembler des preuves au lieu de travailler le prochain risque.

Risque : fuite de RPS

L'accès aux RPS est à un message Slack d'une fuite

Sans journal d'accès RPS séparé et scoping par rôle, chaque employé avec accès RH voit les numéros d'identité nationale. Quand l'incident atterrit, le journal n'existe pas — vous ne pouvez pas prouver l'étendue de l'exposition.

Approvisionnement : matrice AAU

L'AAU fonctionne pour 4 clients, pas 7

Certains clients sur Entra ID, d'autres Okta, d'autres Google Workspace. Les petits veulent un repli natif. La plupart des plateformes en supportent 2 sur 4. L'approvisionnement demande les quatre — avec AMF, confiance d'appareil, bris-de-glace audité.

Ce que FrontLine fait

Ce que FrontLine donne à la conformité et à l'informatique

Sept contrôles que les questionnaires d'approvisionnement demandent vraiment — câblés dans le modèle de données, pas boulonnés sur un tableau de bord. Chaque affirmation ci-dessous est vérifiable depuis le code ou l'Atlas.

Fonctionnalité 01

Journal d'audit immuable + visionneuse unifiée

Chaque changement à chaque enregistrement à travers RH, horaire, AQ, formation, facturation — une seule table audit_events. En écriture seule par architecture : aucun point de terminaison DELETE, aucun UPDATE. Filtrez le journal en direct par acteur, action, ressource, plage de dates, IP, texte libre. Export CSV/JSON plafonné à 50K lignes ; chaque export émet son propre événement d'audit pour que la chaîne de garde reste intacte.

  • Immuable par architecture. Aucun point de terminaison DELETE ou UPDATE sur les routes du journal d'audit. La table est en écriture seule. Il n'y a aucun chemin « passe-droit administrateur ».
  • Unifié à travers les modules. RH, horaire, AQ, formation, facturation, recrutement, intégration, demandes de changement, acquittements de politique, rétention, DSAR — tous émettent vers la même table audit_events.
  • Interrogeable en secondes. Filtrez par actor_id, préfixe d'action, resource_type, resource_id, plage de dates, client_account_id, client_lob_id, IP, recherche texte libre sur action + métadonnées.
  • Export avec chaîne de garde. Plafond dur d'export CSV / JSON 50K lignes ; indicateur de troncature dans la réponse. Chaque export émet son propre événement d'audit (l'auditeur voit que vous l'avez exporté).
  • Paginé par curseur. 50-200 lignes par page. Spec 36 §4 empêche les analyses accidentelles de table complète par les utilisateurs privilégiés.
app.frontlinehq.io/compliance/audit-log

Journal d'audit unifié — chaque changement à chaque enregistrement

Filtres

Acteurtout
Actioncompliance.*
Ressourcetout
Plage dates30 derniers jours
Résultattout
ID sessiontout

Événements · 2 147 892 au total · paginés par curseur

09:42:18Z

j.tremblay@belov.com

compliance.soc2.package_generated

soc2:T2-2026

OK
09:38:02Z

p.singh@belov.com

employees.private_profile.national_id.reveal

employee:emp-1284

OK
09:35:11Z

api-token-4128

auth.session.cross_tenant_probe

tenant:other-tenant

REFUSÉ
09:32:47Z

j.tremblay@belov.com

compliance.retention_policy.update

policy:recruiting_apps

409
09:28:33Z

system-worker

compliance.retention_run.purge

category:dsar_records

OK
09:24:01Z

m.brown@belov.com

compliance.legal_hold.create

hold:case-2024-08

OK

Export CSV / JSON · plafond 50K lignes · chaque export émet son propre événement d'audit.

Fonctionnalité 02

Journal d'accès RP + détection d'accès refusé

Deux surfaces filtrées séparées sur le journal d'audit. Les révélations RP (numéros d'identité, adresses, notes privées) et les échecs d'authentification atterrissent dans leurs propres visionneuses, limitées au rôle compliance_officer. Les sondages inter-locataires (JWT tenant_id ≠ tenant_id de la ressource) auto-classés à gravité HAUTE ; l'agrégation force-brute par acteur + IP fait surface d'une vague de credential-stuffing avant qu'elle ne se noie dans le bruit d'une seule ligne.

  • L'accès aux RP a son propre journal. 8 actions RP de base suivies (national_id.read, home_address.read, private_note.read, etc.). Projection filtrée sur audit_events ; vue compliance_officer seulement.
  • Rapport par employé. /compliance/pii-access-log/report regroupe les événements d'accès par employé. Quand un employé demande « qui a consulté mon dossier », la réponse tient sur un écran.
  • Surface d'accès en échec/refusé. Échecs d'authentification, refus de permission, sondages inter-locataires — un seul journal. Agrégation force-brute (≥5 échecs depuis la même IP en 10 min) fait surface des motifs ; les sondages inter-locataires auto-marqués à gravité HAUTE.
  • Sur la feuille de route — annotation d'intention + alertes de volume. Une porte d'annotation d'intention (l'administrateur RH déclare pourquoi avant qu'une révélation revienne) et les alertes de volume configurables par locataire (ex. « > 5 révélations national_id par le même acteur en 1 h ») sont sur la feuille de route Atlas. Aujourd'hui le journal d'accès aux RP est de qualité investigative : chaque révélation est capturée avec acteur + horodatage + portée, et le responsable conformité peut l'interroger. Le worker d'alerte qui se déclenche sur les seuils de volume est une phase différée de la spec 36 — suivez-la sur l'Atlas.
app.frontlinehq.io/compliance/pii-access-log

Journal d'accès RPS — vue agent de conformité

Révélations RPS · 8 actions de base suivies

Projection filtrée sur audit_events · compliance_officer seulement · admin RH refusé

09:38:02Z

p.singh@belov.com

national_id.reveal

AGT-1284

Vérification intégration

09:24:11Z

m.brown@belov.com

private_note.read

AGT-1612

Enquête dossier RH

08:51:47Z

h.davis@belov.com

home_address.read

AGT-2298

Changement dossier

08:42:09Z

p.singh@belov.com

national_id.reveal

AGT-1284

Vérification intégration

08:14:33Z

p.singh@belov.com

national_id.reveal

AGT-2417

Vérification intégration

07:58:21Z

p.singh@belov.com

national_id.reveal

AGT-1284

Vérification intégration

ALERTE : p.singh@belov.com — 5 national_id.reveal en 1 h 45 · seuil (≥5/1 h) déclenché · notification envoyée aux agents de conformité.

Fonctionnalité 03

Flux DSAR (LPRPDE + CCPA) avec droit à l'effacement

Réception de demande → suivi d'échéance → collecte de données inter-modules → paquet ZIP + téléchargement par URL signée → effacement avec pré-vérification de mise en attente légale. L'horloge de 30 jours LPRPDE ou 45 jours CCPA démarre à la soumission ; alertes d'échéance à 7 j / 3 j / jour-même. L'effacement est une anonymisation au niveau du champ avec jetons déterministes — l'intégrité relationnelle survit, les valeurs originales non. Les journaux d'audit ne sont jamais effacés.

  • Échéances par juridiction. LPRPDE = submitted_at + 30 jours ; CCPA = submitted_at + 45 jours. La machine à états survit : SUBMITTED → IN_PROGRESS → DATA_GATHERED → REVIEWED → FULFILLED, avec des branches PENDING_HOLD_RELEASE + REJECTED_WITH_REASON.
  • Collecte inter-modules. 6 collecteurs DSAR spécifiques par module en direct aujourd'hui — employés, info privée, recrutement + évaluation, intégration, main-d'œuvre, notifications, bureau de service. Paquet ZIP avec manifest.json + un JSON par module.
  • Anonymisation au niveau du champ. Pas une suppression dure. Jetons déterministes par locataire préservent les clés étrangères ; valeurs originales parties. Raisons de rétention par champ capturées (les planchers réglementaires honorés).
  • Les journaux d'audit ne sont jamais effacés. Contrainte architecturale. Le minimum de rétention de 7 ans LPRPDE s'applique. La surface d'effacement exclut explicitement audit_events ; les auditeurs ont confiance en ceci.
  • Pré-vérification de mise en attente légale. Avant que l'effacement s'exécute, l'évaluateur de portée de mise en attente vérifie le sujet. Si retenu, la demande passe à PENDING_HOLD_RELEASE ; l'horloge se met en pause et reprend à la libération de la mise en attente.
app.frontlinehq.io/compliance/dsar/req-4221

Demande DSAR n° req-4221 — LPRPDE

Sujet : ancien employé · type de demande : ACCÈS + EFFACEMENT

Soumis 2026-05-19 · échéance 2026-06-18 (30 jours · LPRPDE)

LPRPDE30 jours

Soumis

✓

2026-05-19 09:14 · formulaire d'intake · identité sujet vérifiée

En cours

✓

Collecteurs en exécution : employés, info_privée, recrutement, audit_events

Données collectées

✓

Paquet ZIP prêt · manifest.json + 6 JSON modules

Révisé

…

Agent de conformité signe · pré-vérification mise en attente : clair

Livré

…

Téléchargement URL signée émis · effacement s'exécute · ligne d'audit

Chaque transition d'état consignée à l'audit. L'effacement passe par pré-vérification de mise en attente. Le journal d'audit lui-même n'est jamais effacé.

Fonctionnalité 04

Politiques de rétention + mises en attente légales

Fenêtres de rétention par catégorie (dossiers employés, paie, audit, accès RPS, DSAR, chat, AQ, recrutement) avec le plancher de 7 ans LPRPDE comme minimum dur. Aperçu à blanc par défaut ; les changements plus stricts rétroactifs exigent une confirmation explicite. Les mises en attente légales priment sur la rétention — les enregistrements retenus sautent automatiquement la purge. La création et la libération sont verrouillées AMF et idempotentes.

  • 8 catégories de rétention. Configurables par locataire, avec des planchers réglementaires comme minimums durs (7 ans pour dossiers employés, paie, audit, événements d'accès RPS).
  • Aperçu à blanc. Chaque changement de politique part en mode à blanc par défaut. Prévisualisez quelles lignes seraient purgées ou archivées avant l'engagement. Les exécutions en direct exigent une étape de confirmation explicite.
  • Porte d'application rétroactive. Les changements de rétention plus stricts (fenêtre plus serrée) retournent 409 RETROACTIVE_CONFIRMATION_REQUIRED jusqu'à acquittement. Une règle plus stricte ne peut pas supprimer silencieusement des années d'historique.
  • Les mises en attente priment sur la rétention. La portée de mise en attente est JSONB : employee_ids, candidate_ids, date_range, data_categories, client_account_ids. L'exécuteur de rétention consulte recordMatchesAnyHold() avant chaque purge.
  • Les deux verrouillés AMF. Les changements de politique + création/libération de mise en attente exigent X-MFA-Verified + Idempotency-Key. Trace d'audit capturée pour chaque changement.

Politiques de rétention + mises en attente légales

Politiques de rétention · 8 catégories

Dossiers employés

7 ansARCHIVE

Journal d'audit

7 ansARCHIVE

Paie et T&P

7 ansARCHIVE

Événements accès RPS

7 ansARCHIVE

Dossiers DSAR

3 ansARCHIVE

Transcriptions clavardage

1 anPURGE

Évaluations AQ

3 ansARCHIVE

Recrutement (rejetés)

1 anPURGE

Mises en attente légales actives · 3

case-2024-08

12 employés · audit + info_privée

Active
case-2025-02

Dossiers recrutement · 2025-T1

Active
case-2025-12

Candidat unique · fenêtre 30 jours

Libérée

Les mises en attente priment sur la rétention — les enregistrements retenus sautent automatiquement la purge. Création + libération verrouillées AMF.

Fonctionnalité 05

Trousse de preuves SOC 2 Type II — une requête, pas un trimestre

Export ZIP préfabriqué d'événements d'audit organisé par critères de services de confiance SOC 2 — CC6 (Accès logique), CC7 (Opérations système), CC9 (Gestion du changement), A1 (Disponibilité). Borné par période ; un CSV par critère. La collecte de preuves Type II qui prenait 3 semaines est un téléchargement par URL signée. La génération elle-même émet un événement d'audit CC9 pour que l'auditeur voie que vous l'avez généré.

  • 4 critères de services de confiance. CC6 (Accès logique), CC7 (Opérations système), CC9 (Gestion du changement), A1 (Disponibilité). Chacun mappe à des préfixes d'action d'événements d'audit spécifiques par spec 36 §11.
  • Borné par période. Spécifiez period_start + period_end à la génération. Les événements hors période exclus. Compatible avec la fenêtre d'audit.
  • Page de couverture + CSV. cover_sheet.json liste les catégories avec record_count + scope_note ; un CSV par catégorie demandée. Les auditeurs le chargent dans leurs papiers de travail tel quel.
  • Audit auto-référentiel. Événement de génération (`compliance.soc2.package_generated`, gravité HAUTE) apparaît dans l'export CC9 suivant. L'auditeur voit littéralement l'horodatage de quand vous avez collecté la preuve.
  • TTL d'URL signée 24 h. Les liens de téléchargement expirent. Pas d'URL à longue durée laissant fuiter la trousse de preuves auditeur sur un disque partagé.
app.frontlinehq.io/compliance/soc2

Trousse de preuves SOC 2 Type II

Période

1 avr → 30 juin 2026 (T2)

CC6

Accès logique

4 128 événements

.csv
CC7

Opérations système

6 892 événements

.csv
CC9

Gestion du changement

2 447 événements

.csv
A1

Disponibilité

750 événements

.csv

Contenu du paquet

cover_sheet.json + 4 fichiers CSV (un par critère) · ZIP · URL signée 24 h

La génération émet compliance.soc2.package_generated (gravité HAUTE) — apparaît dans l'export CC9 suivant.

Fonctionnalité 06

Isolation locataire + compte au niveau des lignes (RLS)

tenant_id et client_account_id scopés au niveau de la ligne PostgreSQL via des politiques RLS. Les requêtes inter-comptes retournent zéro ligne dans la base — pas dans le code applicatif. La même infrastructure de données gère un client fintech de 50 agents et un client retail de 2 000 agents sans que l'un puisse interroger l'autre. Survit au sondage « essayez de récupérer les données d'un autre locataire » de la révision sécurité.

  • Forcé dans la base de données. Politiques RLS sur tenant_id (chaque table) + client_account_id (chaque table opérationnelle). La base refuse les requêtes inter-locataires — il n'y a aucun filtre côté application à oublier.
  • Le JWT porte le contexte. current_setting('app.current_tenant_id', true) sourcé depuis les claims JWT ; immuable dans le cycle de vie d'une requête (per ADR-001). Aucun gestionnaire de requête ne peut changer de locataire en milieu de requête.
  • Sondages inter-locataires marqués. Quand le tenant_id du JWT d'une requête ne correspond pas au tenant_id d'une ressource référencée, l'événement d'audit est auto-classé `auth.session.cross_tenant_probe` à gravité HAUTE. L'équipe sécurité voit le sondage avant qu'il soit une fuite.
  • Plus de 50 tables sous RLS. Chaque table contenant des données locataire — incluant les tables conformité elles-mêmes. Testé en intégration par spec 12.
  • Seule exception : lecture audit_events. Les lectures compliance_officer peuvent couvrir l'historique d'audit complet du locataire sans restriction RLS — mais jamais inter-locataires. L'architecture vous laisse enquêter dans la portée de votre propre locataire.

Isolation au niveau des lignes — essayer d'interroger un autre locataire

SET app.current_tenant_id = 'belov-tenant';

SELECT * FROM employees WHERE tenant_id = 'other-tenant';

RLS policies

employees

tenant_isolation · client_account_scope

audit_events

tenant_isolation

compliance_dsar_requests

tenant_isolation

client_user_account_bindings

portée locataire + compte

Résultat

(0 lignes)

La base de données a refusé la requête — la politique RLS l'a filtrée avant que le code applicatif ne voie de données. Aucun filtre à oublier.

Même requête sans contexte locataire → ligne d'audit `auth.session.cross_tenant_probe` gravité HAUTE.

Fonctionnalité 07

AAU d'entreprise + CGAR

OIDC et SAML 2.0 avec Entra ID, Okta, Google Workspace, ou tout IdP conforme aux normes. Repli courriel/mot de passe natif pour bris-de-glace et petits clients. AMF via TOTP ou OTP courriel ; témoin de confiance d'appareil (TTL 30 jours) pour contournement AMF sur appareils de confiance. Les permissions suivent les clés `<module>.<resource>.<action>` avec valeurs par défaut de rôle par locataire — environ 80 permissions enregistrées aujourd'hui à travers tous les modules.

  • OIDC + PKCE. Code d'autorisation + PKCE + validation state + nonce. URL de découverte configurable par IdP. Entra ID, Okta, Google Workspace testés contre des IdP réels.
  • SAML 2.0. Assertions signées, prévention des attaques par rejeu, tolérance de décalage d'horloge de 5 minutes. Téléchargement XML de métadonnées ou collage.
  • Repli natif. Courriel/mot de passe avec vérification de brèche HaveIBeenPwned à l'inscription. Politique locataire (enforce_sso vs allow_native_break_glass) contrôle la disponibilité.
  • AMF + confiance d'appareil. TOTP ou OTP courriel. Optionnel par défaut ; politique locataire mfa_required_for_all force. Témoin de confiance d'appareil TTL 30 jours pour contournement appareil de confiance ; révocable par session.
  • Clés de permission CGAR. <module>.<resource>.<action> — ex. `compliance.audit_log.export`, `recruiting.requisition.create`. ~80 permissions à travers tous les modules. Valeurs par défaut de rôle par locataire ; le rôle client verrouillé aux points de terminaison du portail client seulement.
app.frontlinehq.io/admin/sso

AAU d'entreprise + CGAR

Fournisseurs d'identité

Microsoft Entra ID

OIDC + PKCE

Actif

Okta

SAML 2.0

Actif

Google Workspace

OIDC

Actif

Natif (repli)

Courriel + mot de passe

Bris-de-glace

Politique locataire

enforce_sso = true · natif permis pour bris-de-glace seulement

mfa_required_for_all = true · TOTP ou OTP courriel

device_trust_ttl = 30 jours · révocable par session

Exemple de permission CGAR

compliance_officer → compliance.* (joker) · hr_admin → compliance.dashboard.read + compliance.audit_log.read (sans export)

Pour le décideur

Résultats d'affaires pour ceux qui dirigent le BPO

Ce que cela donne pour le COO, le RSSI ou le responsable conformité.

Approvisionnement

Les révisions sécurité d'entreprise se ferment en jours, pas en semaines

Le questionnaire d'approvisionnement qui mâchait deux semaines de temps conformité + TI à travers plusieurs disciplines se ferme en jours. Chaque case à cocher a une réponse architecturale — pas une intention de diapo. Gagnez l'entente que vous auriez stoppée.

Audit

Les preuves SOC 2 Type II deviennent un téléchargement par URL signée

La course annuelle de 3 semaines devient un seul ZIP par période. Catégories CC6 / CC7 / CC9 / A1 préfabriquées. L'auditeur l'ouvre et commence à travailler — pas de suivi « pouvez-vous aussi envoyer le journal de changements du T2 ».

Risque

L'exposition de données inter-locataires est structurellement impossible

L'isolation au niveau des lignes dans la base signifie que la requête du pire cas — « donnez-moi les agents d'un autre locataire » — retourne zéro ligne. Pas géré dans le code applicatif, pas barré par un middleware, pas dépendant d'un développeur qui se souvient. La plateforme elle-même refuse.

Responsabilité

Les exercices d'urgence DSAR deviennent des flux de 30 jours

Les 30 jours LPRPDE et 45 jours CCPA sont des jalons de flux, pas des déclencheurs de panique. Alertes d'échéance à 7 j / 3 j / jour-même. L'effacement passe par une pré-vérification de mise en attente légale. Le dossier de cas à la livraison est sa propre trace d'audit.

Ce que la conformité et la TI récupèrent vraiment

Résultats indicatifs — la magnitude réelle dépend de votre flux d'audit antérieur et de votre base de référence de départ. Les propriétés architecturales (RLS, audit immuable, machine à états DSAR) ne sont pas des estimations — elles sont livrées comme la plateforme.

Preuves SOC 2

Semaines → jours

Des CSV préfabriqués par critère de confiance remplacent l'exercice trimestriel d'assemblage à partir de CSV. La magnitude dépend de votre longueur de cycle antérieure.

Journal d'audit

Une seule table immuable, chaque événement

Chaque changement, chaque lecture de RP, chaque sondage inter-locataire — une seule table d'audit en ajout seul. Aucune dispersion à travers des journaux par module à réconcilier.

Isolation inter-locataires

Zéro chemin de requête inter-locataires

Isolation au niveau des lignes dans la base de données. Aucun filtre côté application à oublier — les données ne peuvent physiquement pas être interrogées au-delà des frontières du locataire.

Délai DSAR

Échéances statutaires suivies en-application

Échéances LPRPDE + CCPA suivies en-application avec alertes à 7 j / 3 j / jour-même. Aucune feuille de calcul à pourchasser pour la conformité.

Posture réglementaire et cadres

LPRPDE (Canada)CCPA / CPRA (Californie)Loi 25 (Québec)SOC 2 Type II — générateur de trousse de preuves (audit T3 2026)Conscient HIPAA (gestion côté effectif)Conscient PCI-DSS (les enregistrements vivent dans votre CCaaS)Droits sujets alignés RGPDLAPHO · WCAG 2.1 AAJournal d'audit (plancher 7 ans)RLS locataire + compte

FrontLine pour la conformité et l'informatique vs un SIRH générique

Six choses que les équipes conformité + TI remarquent dans leur premier questionnaire d'approvisionnement après un SIRH générique.

FrontLine pour la conformité et l'informatiqueSIRH générique

Isolation multi-locataire au niveau des lignes forcée dans la base

Les SIRH génériques partagent les schémas entre locataires ; l'isolation est dans le code applicatif — facile à contourner avec une nouvelle requête.

Journal d'audit immuable sans points UPDATE / DELETE

Les journaux d'audit SIRH génériques permettent généralement un passe-droit administrateur ou une suppression douce. La table FrontLine est en écriture seule par architecture.

Flux DSAR (LPRPDE + CCPA) avec suivi d'échéance

Les SIRH génériques n'ont pas de concept DSAR. Vous construisez le flux vous-même avec courriel + Excel.

Générateur de trousse de preuves SOC 2 Type II

Les SIRH génériques vous donnent les données ; l'assemblage des preuves Type II est votre problème (et le mal de tête de votre auditeur).

AAU OIDC + SAML avec repli natif + AMF + confiance d'appareil

Les SIRH génériques supportent une famille d'IdP bien, d'autres mal. Le repli natif est souvent manquant ou requis par défaut.

CGAR avec clés de permission `<module>.<resource>.<action>`

Les CGAR SIRH génériques sont couplés au nom de rôle — pas codés en permission. Les rôles personnalisés exigent des tickets de support vendeur.

En production aujourd'hui

Tableau de bord conformité et audit (Module 36) livré 2026-05-17 — couverture complète : journal d'audit + journal d'accès RPS + flux DSAR + rétention + mises en attente légales + preuves SOC 2 + droit à l'effacement. Authentification (11) et CGAR (11A) livrés plus tôt avec la plateforme cœur. Voir le statut par fonctionnalité sur l'Atlas.

Voir la conformité sur l'Atlas →
FAQ

Questions que la conformité et la TI posent vraiment avant de signer

Tirées de vrais appels d'évaluation. Réponses courtes et directes.

Qu'est-ce qui empêche un de nos locataires d'interroger les données d'un autre ?+
Les politiques de sécurité au niveau des lignes PostgreSQL sur tenant_id (chaque table) et client_account_id (chaque table opérationnelle). Le JWT porte le contexte locataire ; current_setting('app.current_tenant_id', true) est défini par requête depuis les claims et immuable dans le cycle de vie de la requête (per ADR-001). La base refuse les requêtes inter-locataires — il n'y a aucun filtre côté application à oublier. Les sondages inter-locataires sont aussi auto-classés à gravité HAUTE dans le journal d'audit.
Le journal d'audit est-il vraiment immuable, ou juste supprimé doucement ?+
La table audit_events n'a aucun point de terminaison DELETE ou UPDATE. Les routes n'existent pas. Il n'y a aucun chemin de passe-droit administrateur. Elle est architecturalement en écriture seule — la seule façon de supprimer une ligne est une opération de base de données manuelle qui déclenche elle-même une alerte. Le plancher de rétention de 7 ans (LPRPDE) est forcé comme minimum dur sur le moteur de politique de rétention.
Quel est le délai DSAR ? Et comment gérez-vous l'effacement sous mise en attente légale ?+
LPRPDE = 30 jours depuis submitted_at ; CCPA = 45 jours. Machine à états avec alertes d'échéance à 7 j / 3 j / jour-même. Pour l'effacement : l'évaluateur de portée de mise en attente s'exécute en pré-vérification. Si le sujet correspond à une mise en attente active, la demande passe à PENDING_HOLD_RELEASE et l'horloge se met en pause ; les deux reprennent à la libération de la mise en attente. L'effacement lui-même est une anonymisation au niveau du champ avec jetons déterministes — l'intégrité relationnelle survit, le RPS original non. Les journaux d'audit ne sont jamais effacés (architectural).
Que contient réellement la trousse de preuves SOC 2 Type II ?+
Un ZIP par période (vous spécifiez début + fin) avec un cover_sheet.json + un CSV par critère de services de confiance SOC 2 demandé. Nous couvrons CC6 (Accès logique), CC7 (Opérations système), CC9 (Gestion du changement) et A1 (Disponibilité). Chaque CSV est les événements d'audit filtrés pour les préfixes d'action de ce critère per spec 36 §11. L'événement de génération émet lui-même un événement d'audit CC9 — donc la trousse de la période suivante montre à l'auditeur quand vous avez collecté la preuve.
Quels IdP supportez-vous ? Et exigez-vous l'AAU ?+
OIDC (Code d'autorisation + PKCE + validation state + nonce) testé contre Microsoft Entra ID, Okta, Google Workspace, et tout IdP OIDC conforme à l'URL de découverte. SAML 2.0 avec assertions signées, prévention des attaques par rejeu, et tolérance de décalage d'horloge de 5 minutes via téléchargement XML de métadonnées. Le courriel/mot de passe natif est disponible comme repli avec vérification de brèche HaveIBeenPwned à l'inscription ; la politique locataire (enforce_sso vs allow_native_break_glass) contrôle si le natif est permis.
Pouvons-nous obtenir un rôle personnalisé avec des permissions très spécifiques ?+
Oui. Les permissions suivent les clés `<module>.<resource>.<action>` — ex. `compliance.audit_log.export`, `recruiting.requisition.create`. Il y a environ 80 permissions enregistrées à travers les modules aujourd'hui. Les administrateurs locataires composent les rôles à partir de ces clés ; nous pouvons aussi pré-construire des rôles personnalisés pour des exigences spécifiques d'approvisionnement pendant l'intégration. Le rôle client est limité aux points de terminaison du portail client par architecture — aucune trappe de sortie.
Et l'AMF ? La confiance d'appareil ? Le bris-de-glace ?+
AMF via TOTP ou OTP courriel. Optionnel par défaut ; politique locataire mfa_required_for_all force. Témoin de confiance d'appareil (TTL 30 jours) permet à un appareil de confiance de sauter l'AMF aux connexions suivantes — révocable par session, et les tentatives de bris-de-glace (compte verrouillé, repli natif) émettent leurs propres événements d'audit gravité HAUTE pour révision.

Prêt pour la révision d'approvisionnement ?

Deux façons de passer à l'étape suivante.

Planifier une révision sécurité
Voir l'architecture Voir les tarifs

Autres équipes qui utilisent FrontLine

La conformité et la TI soutiennent toutes les autres équipes. Voici à quoi ressemble le reste de FrontLine de l'équipe d'à côté.

Pour les RH

Changements de dossier prêts LPRPDE, probation, info privée — chaque lecture privilégiée atterrit sur votre journal d'accès RPS.

Explorer

Pour les clients

Isolation au niveau des lignes par compte forcée dans la base ; chaque accès portail client consigné à l'audit.

Explorer

Pour AQ et coaching

Les journaux d'accès évaluateur AQ, la chaîne d'audit de calibrage et chaque événement du cycle de vie d'évaluation alimentent votre trousse de preuves. Les enregistrements d'appel eux-mêmes vivent dans votre CCaaS ; FrontLine audite la gestion côté effectif.

Explorer
FrontLine pour la conformité et l'informatique | FrontLine