Ne nous croyez pas.
Vous allez confier à un éditeur vos risques, vos écarts et vos preuves d’audit. Voici les mécanismes qui les tiennent, et comment les vérifier vous-même.
chaque table porte la marque de son organisation, et la base refuse de servir celle d’une autre
une exigence commune à plusieurs normes n’existe qu’une fois
ISO 27001, 9001, 14001, 17025, 22000 — plus le plan de maîtrise sanitaire seul
L’isolation
L’isolation ne dépend pas du code.
Chaque table porte la marque de son organisation, et c’est la base de données elle-même qui refuse de servir les lignes d’une autre. L’oubli d’un filtre dans une requête — la façon dont la plupart des fuites multi-clients arrivent — ne peut donc rien exposer : il faudrait que la base accepte, et elle n’accepte pas.
Ce que cela ne couvre pas, et nous préférons l’écrire : si le produit posait la mauvaise organisation en début de requête, la base servirait docilement les bonnes lignes du mauvais compte. C’est le point que nous surveillons le plus, et il est tenu par des tests d’isolation que chaque modification doit passer.
Une garde énumère toutes les tables du produit et refuse celle qui n’aurait pas sa règle d’isolation. Elle lit la base, pas une liste tenue à la main.
L’éditeur
Nous ne lisons pas vos données.
Notre équipe d’exploitation voit QUE votre organisation existe, qui en est membre et quelles briques sont actives. Elle ne voit rien de ce que vous y produisez : ni vos risques, ni vos preuves, ni vos écarts, ni votre journal d’audit.
Toute intervention sur votre compte — une suspension, la réinitialisation d’un second facteur — exige un motif écrit, et ce motif est inscrit dans VOTRE journal. Vous le lisez ; nous ne pouvons pas l’effacer.
Nos comptes d’exploitation ne peuvent pas devenir membres d’une organisation cliente : le produit le refuse. C’est ce qui empêche de contourner la règle en s’invitant soi-même.
Démontrable à votre auditeur par un test : une donnée est écrite chez un client, puis comptée à zéro depuis l’espace d’administration. Ce n’est pas une procédure interne, c’est un refus de la base.
Le journal
Rien ne s’efface
Le journal d’audit est en écriture seule. Un déclencheur de base de données refuse toute modification, et les droits de modification sont retirés au compte applicatif : ni l’un ni l’autre n’est le seul rempart, et aucune voie applicative ne permet d’effacer une ligne.
L’accès administrateur à la base existe — il faut bien sauvegarder et migrer. Il est nominatif et tracé, et nous ne prétendrons pas qu’il n’existe pas : c’est exactement le genre d’affirmation que vous devriez mettre en doute chez tous vos fournisseurs. Ce que nous tenons, c’est la maîtrise de l’information documentée au sens du § 7.5.3 : identification, protection contre l’altération non voulue, récupération, durée de conservation.
Ce qui sort
Ce qui sort. Ce qui ne sort pas.
Normfield fonctionne sans aucun modèle de langage. Les aides à la saisie viennent de règles et d’un catalogue versionné. Rien de ce que vous écrivez n’est envoyé à un fournisseur d’intelligence artificielle — ce qui vous évite d’avoir à l’expliquer dans votre propre analyse de risques.
Ce qui sort, et nous préférons l’écrire : quand une erreur technique survient, son rapport part vers un service de suivi des incidents — le message de l’exception et la pile d’appels. Le corps de vos saisies et vos cookies de session sont coupés à la source dans notre configuration ; vos fichiers de preuve ne quittent jamais le stockage du produit.
Ce que nous ne tenons pas encore
Ce que nous ne pouvons pas encore dire.
Nous ne sommes pas certifiés ISO 27001. Notre propre système de management de la sécurité est en construction — vous le sauriez tôt ou tard, autant que ce soit par nous.
Le lieu d’hébergement n’est pas encore arrêté. Aucune promesse de souveraineté n’apparaîtra ici avant que le contrat soit signé.
Envoyez votre questionnaire.
Nous répondons par des mécanismes, et nous disons ce que nous ne tenons pas encore.
Nous écrire