Normas de seguridad

En ProcureLabs, la seguridad es fundamental para nuestra plataforma. Esta página describe las medidas establecidas para proteger sus datos de compras, así como lo que cubren y lo que no cubren.

Cumplimiento de certificaciones

Cifrado de datos

Seguridad de la infraestructura

• Infraestructura en la nube: Alojada en AWS, que cuenta con las certificaciones SOC 2, ISO 27001 y PCI DSS. Estas son certificaciones de AWS, no de ProcureLabs.
• Aislamiento de datos: La seguridad a nivel de fila está habilitada en las tablas de la base de datos que contienen datos de clientes, por lo que las consultas de un usuario que ha iniciado sesión devuelven únicamente las filas de su propia organización. Los trabajos en segundo plano y las rutas administrativas que se ejecutan con acceso elevado a la base de datos no pasan por la seguridad a nivel de fila; aplican el filtro del inquilino en el código de la aplicación.
• Disponibilidad: Una única región de AWS (Singapur); sin conmutación por error entre regiones
• Recuperación ante desastres: Copias de seguridad de la base de datos con recuperación a un momento dado, proporcionadas por nuestro proveedor de bases de datos (Supabase)

Control de acceso

Supervisión y respuesta de seguridad

• Gestión de vulnerabilidades: Cada solicitud de fusión se analiza en busca de secretos incluidos en el código (Gitleaks) y vulnerabilidades críticas de dependencias que puedan corregirse (Trivy).
• Respuesta a incidentes: El fundador de ProcureLabs gestiona los incidentes mediante los manuales de respuesta a incidentes de la plataforma, y los clientes afectados reciben una notificación por correo electrónico.
• Los problemas de seguridad pueden notificarse a nuestro contacto de seguridad, indicado a continuación.

Seguridad del procesamiento de datos de IA

Nuestras funciones de IA están diseñadas teniendo en cuenta la seguridad y la privacidad:

• Tratamiento por OpenAI OpenAI permite conversaciones, análisis y evaluaciones acotadas de Decisions para seleccionar herramientas y analizar evidencia de compras. Sujeto a los permisos vigentes del cliente y a la configuración regional acordada, Decisions recibe contexto y preguntas minimizados y con datos sensibles ocultados para el fin permitido. Los datos de la API de OpenAI solo se utilizan para entrenar modelos con una aceptación expresa. Decisions puede conservar el estado cifrado de la caché de instrucciones hasta 24 horas y los registros ordinarios de supervisión de abusos hasta 30 días, sujeto a las excepciones de seguridad, protección o legales aplicables.
• Permiso para el tratamiento mediante Decisions El tratamiento mediante Decisions requiere instrucciones vigentes del cliente y permiso para el fin, la cuenta, el encargado del tratamiento y la transferencia a Estados Unidos específicos. Desactivar la IA o retirar la autorización correspondiente impide nuevas solicitudes a Decisions. Las acciones con consecuencias siguen sujetas a las salvaguardas requeridas y a revisión independiente.
• La conservación depende de la categoría de datos, las instrucciones del cliente, las obligaciones de preservación legal y las condiciones del proveedor. El historial de chat, el contenido derivado, los registros de auditoría y los registros del proveedor tienen condiciones de conservación separadas. Las solicitudes de eliminación se gestionan conforme al acuerdo de tratamiento de datos y la legislación aplicable.
• Los administradores pueden desactivar las funciones de IA opcionales
• Un administrador puede desactivar las funciones de IA para toda la organización, o cada usuario puede desactivarlas para sí mismo
• Registro de auditoría de las decisiones sobre acciones propuestas por la IA

Residencia de datos

Todos los datos de los clientes se almacenan en una única región. Las funciones de IA procesan los datos que necesitan con proveedores de IA en los Estados Unidos. Actualmente no hay regiones de almacenamiento adicionales disponibles.

Gobernanza

• Mantenemos una política escrita de seguridad de la información, con un índice de nuestras políticas y procedimientos, que se revisa al menos anualmente.
• Mantenemos un código de conducta escrito que abarca la honestidad, la confidencialidad y los conflictos de intereses.
• ProcureLabs tiene tres fundadores. David Hodge, CEO y Director, es responsable de la seguridad y la protección de datos. La revisión por parte de los cofundadores y los mecanismos independientes de recuperación se están documentando y verificando.
• Mantenemos un registro de riesgos escrito, que se revisa al menos anualmente y antes de realizar cambios significativos.
• Mantenemos un proceso escrito para comprobar y revisar nuestros subencargados del tratamiento. AWS y Supabase proporcionan la seguridad física de los servidores que ejecutan ProcureLabs; no operamos ningún centro de datos propio.
• Mantenemos un plan escrito de continuidad del negocio, que se revisa al menos anualmente.
• Contamos con un procedimiento escrito para probar la restauración de nuestra base de datos a partir de una copia de seguridad. Se ha completado un ejercicio de restauración únicamente de la base de datos y se ha eliminado la copia temporal. La recuperación completa de la aplicación, la autenticación y el almacenamiento de objetos, así como el acceso independiente de un operador alternativo, aún deben verificarse.

Gestión de cambios e integridad del procesamiento

• Los cambios de código llegan a nuestra rama principal mediante solicitudes de fusión que deben superar las comprobaciones obligatorias del pipeline, incluido el análisis de secretos, las comprobaciones de migraciones de bases de datos y una comprobación de que las declaraciones de seguridad y privacidad de este sitio siguen coincidiendo con el código. La producción solo se publica desde esa rama. Una prueba automatizada falla si se elimina una comprobación obligatoria o se permite que falle.
• Las debilidades conocidas del código se registran en las líneas base y en nuestro registro de evidencias de cumplimiento. Un cambio que añada una nueva debilidad, como un gestor de errores que descarte silenciosamente un error o una declaración publicada cuyo código de respaldo haya cambiado, se bloquea hasta que se corrija o se registre.
• La mayoría de los endpoints de escritura de nuestra API comprueban cada cuerpo de solicitud con un esquema declarado y rechazan con un error 400 cualquier solicitud que no coincida.
• Cada ejecución de nuestros motores de detección registra, para cada detector, si se completó y cuántos resultados devolvió, o si falló. Un fallo se registra como fallo, nunca como «sin hallazgos».