Normes de sécurité

Chez ProcureLabs, la sécurité est fondamentale pour notre plateforme. Cette page décrit les mesures mises en place pour protéger vos données d’achat, ainsi que ce qu’elles couvrent et ne couvrent pas.

Conformité aux certifications

Chiffrement des données

Sécurité de l’infrastructure

• Infrastructure cloud : Hébergée sur AWS, qui détient les certifications SOC 2, ISO 27001 et PCI DSS. Il s’agit des certifications d’AWS, et non de celles de ProcureLabs.
• Isolation des données : La sécurité au niveau des lignes est activée sur les tables de la base de données contenant les données client, de sorte que les requêtes d’un utilisateur connecté ne renvoient que les lignes de sa propre organisation. Les tâches en arrière-plan et les chemins administratifs qui s’exécutent avec un accès élevé à la base de données ne passent pas par la sécurité au niveau des lignes ; ils appliquent le filtre du locataire dans le code de l’application.
• Disponibilité : Une seule région AWS (Singapour) ; aucun basculement interrégional
• Reprise après sinistre : Sauvegardes de la base de données avec récupération à un instant précis, fournies par notre hébergeur de bases de données (Supabase)

Contrôle des accès

Surveillance et réponse aux incidents de sécurité

• Gestion des vulnérabilités : Chaque demande de fusion est analysée afin de détecter les secrets intégrés au code (Gitleaks) et les vulnérabilités critiques corrigibles des dépendances (Trivy).
• Réponse aux incidents : Les incidents sont traités par le fondateur de ProcureLabs à l’aide des procédures de réponse aux incidents de la plateforme, et les clients concernés sont informés par e-mail.
• Les problèmes de sécurité peuvent être signalés à notre contact sécurité ci-dessous.

Sécurité du traitement des données par l’IA

Nos fonctionnalités d’IA sont conçues dans le respect de la sécurité et de la confidentialité :

• Traitement par OpenAI OpenAI prend en charge les conversations, les analyses et les évaluations limitées de Decisions pour sélectionner les outils et examiner les éléments probants des achats. Sous réserve de l’autorisation actuelle du client et de la configuration régionale convenue, Decisions reçoit un contexte et des questions minimisés et expurgés pour la finalité autorisée. Les données de l’API OpenAI ne sont utilisées pour entraîner les modèles qu’en cas d’adhésion explicite. Decisions peut conserver l’état chiffré du cache des instructions jusqu’à 24 heures et les journaux habituels de surveillance des abus jusqu’à 30 jours, sous réserve des exceptions applicables en matière de sécurité, de protection ou de droit.
• Autorisation du traitement par Decisions Le traitement par Decisions nécessite des instructions actuelles du client et une autorisation pour la finalité, le compte, le sous-traitant et le transfert vers les États-Unis concernés. La désactivation de l’IA ou le retrait de l’autorisation applicable empêche toute nouvelle demande à Decisions. Les actions ayant des conséquences restent soumises aux garanties requises et à un examen indépendant.
• La conservation dépend de la catégorie de données, des instructions du client, des obligations de préservation légale et des conditions du fournisseur. L’historique des conversations, les contenus dérivés, les journaux d’audit et les journaux du fournisseur ont des conditions de conservation distinctes. Les demandes de suppression sont traitées conformément à l’accord de traitement des données et au droit applicable.
• Les fonctionnalités d’IA facultatives peuvent être désactivées par les administrateurs
• Les fonctionnalités d’IA peuvent être désactivées pour toute l’organisation par un administrateur, ou par chaque utilisateur pour lui-même
• Journal d’audit des décisions relatives aux actions proposées par l’IA

Résidence des données

Toutes les données clients sont stockées dans une seule région. Les fonctionnalités d’IA traitent les données dont elles ont besoin avec des fournisseurs d’IA situés aux États-Unis. D’autres régions de stockage ne sont pas disponibles aujourd’hui.

Gouvernance

• Nous tenons à jour une politique écrite de sécurité de l’information, accompagnée d’un index de nos politiques et procédures, révisée au moins une fois par an.
• Nous tenons à jour un code de conduite écrit couvrant l’honnêteté, la confidentialité et les conflits d’intérêts.
• ProcureLabs compte trois fondateurs. David Hodge, CEO et administrateur, est responsable de la sécurité et de la protection des données. L’examen par un cofondateur et les dispositifs indépendants de reprise sont en cours de documentation et de vérification.
• Nous tenons à jour un registre écrit des risques, révisé au moins une fois par an et avant toute modification importante.
• Nous tenons à jour une procédure écrite de vérification et d’examen de nos sous-traitants ultérieurs. La sécurité physique des serveurs qui exécutent ProcureLabs est assurée par AWS et Supabase ; nous n’exploitons aucun centre de données nous-mêmes.
• Nous tenons à jour un plan écrit de continuité d’activité, révisé au moins une fois par an.
• Nous disposons d’une procédure écrite pour tester la restauration de notre base de données à partir d’une sauvegarde. Un exercice de restauration limité à la base de données a été réalisé et la copie temporaire a été supprimée. La reprise complète de l’application, de l’authentification et du stockage d’objets, ainsi que l’accès indépendant d’un opérateur de remplacement, restent à vérifier.

Gestion des changements et intégrité du traitement

• Les modifications du code atteignent notre branche principale par l’intermédiaire de demandes de fusion qui doivent satisfaire aux contrôles requis du pipeline, notamment l’analyse des secrets, les vérifications des migrations de base de données et une vérification confirmant que les déclarations de sécurité et de confidentialité publiées sur ce site correspondent toujours au code. La mise en production s’effectue uniquement depuis cette branche. Un test automatisé échoue si un contrôle requis est supprimé ou autorisé à échouer.
• Les faiblesses connues du code sont consignées dans les référentiels de référence et dans notre registre des éléments de preuve de conformité. Une modification qui en introduit une nouvelle, telle qu’un gestionnaire d’erreurs qui ignore silencieusement une erreur ou une déclaration publiée dont le code justificatif a changé, est bloquée jusqu’à sa correction ou sa consignation.
• La plupart des points de terminaison d’écriture de notre API vérifient le corps de chaque requête par rapport à un schéma déclaré et refusent toute requête non conforme avec une erreur 400.
• Chaque exécution de nos moteurs de détection consigne, pour chaque détecteur, s’il s’est achevé et le nombre de résultats renvoyés, ou s’il a échoué. Un échec est enregistré comme un échec, jamais comme « aucun résultat » .