Centro de confianza
Usamos StandardOS para llevar StandardOS
La afirmación más fuerte que puede hacer un producto de cumplimiento es que quienes lo fabrican le confían su propio cumplimiento. Nuestro sistema de gestión ISO 27001, con su alcance, sus riesgos, sus controles, sus auditorías y sus revisiones, vive dentro de StandardOS. En lugar de pedirle que se fíe de un sello, aquí está exactamente cómo se protege y se opera el servicio, y cómo comprobar sin nosotros la parte que más importa.
La lista de subencargados de abajo cambió por última vez el 2026-09-27; todo lo demás en esta página se puede comprobar con los enlaces que incluye.
Infraestructura y alojamiento
Disponibilidad
Vigilada de forma continua desde fuera de nuestra propia infraestructura, y el resultado es público, también cuando es malo.
Leer más
Preferimos que vea aquí una incidencia a que se entere por nosotros después.
Ubicación de los datos
Todos los datos de clientes se almacenan en la UE (Supabase, región de Irlanda).
Leer más
Elegimos regiones de la UE allí donde el servicio toca registros de clientes.
Entrega
Las aplicaciones se sirven solo por TLS 1.2+, con HSTS.
Leer más
Los archivos estáticos van por CDN; en el borde no hay registros de clientes.
Copias de seguridad
Copias diarias gestionadas de la base de datos principal, en la misma región de la UE, con aviso automático si una copia programada no aparece.
Leer más
Además se guarda una copia cifrada semanal fuera del proveedor de base de datos, para que un fallo de esa cuenta no se lleve todas las copias.
Recuperación
Comprobable en lugar de afirmada. Como sus registros de cumplimiento están encadenados por hash y las raíces diarias se publican, una base de datos restaurada puede contrastarse con una copia que no controlamos: es la misma comprobación que ponemos en manos de su auditor.
Leer más
Una restauración alterada no cuadraría, y lo sabríamos en lugar de suponerlo.
Integridad de los registros, nuestra diferencia
1. Registro de auditoría a prueba de manipulación
Cada cambio en sus registros del SGSI (documentos, riesgos, la declaración de aplicabilidad, evidencias, no conformidades, auditorías, revisiones y los accesos concedidos) se escribe en un historial de solo anexado y encadenado por hash.
Leer más
Cada entrada sella la anterior, junto con quién hizo el cambio, de modo que reescribir la historia o cambiar su autoría rompe la cadena de forma visible. Las personas identificadas tienen acceso de solo lectura a ese historial a nivel de base de datos; UPDATE y DELETE están revocados en él incluso para el rol de servicio con el que operamos la plataforma, por lo que no existe ruta de borrado para nadie. La cadena se adjunta tabla por tabla y no a nivel de esquema: los registros anteriores están en ella, las tablas operativas de la propia plataforma no.
2. Anclajes, al menos semanales
Cada noche registramos la cabeza de cada cadena.
Las raíces diarias publicadasLeer más
Al menos cada semana (el lunes por defecto; a diario o cada mes si sus propietarios lo eligen) la enviamos a los propietarios y administradores de la organización, con el número de registros añadidos desde el último recibo; una semana en la que la cadena no se movió no trae correo. Una vez el recibo está en su buzón, está en un servidor que no operamos, de modo que una reescritura posterior produciría una cabeza que ya no coincide con la que usted conserva. Las raíces diarias también se publican abiertamente, para que cualquiera pueda archivarlas. Esto no hace imposible la manipulación. La hace detectable para quien guardó su correo.
3. Verificabilidad
Las exportaciones llevan los hashes y el contenido sobre el que se calculan, además de la regla de hash exacta.
La especificación y el scriptLeer más
Puede recalcular toda la cadena usted mismo, en cualquier lenguaje, sin que StandardOS esté funcionando. La especificación y un script sin dependencias que lo hace en unas cien líneas están publicados, y ese mismo script es el que nuestra propia CI ejecuta contra una cadena real en cada push. No hemos encontrado otra herramienta en este mercado que permita a un cliente comprobar el historial sin confiar en el proveedor. Si conoce alguna, díganoslo y corregiremos esta página.
Control de acceso
Aislamiento entre organizaciones
Seguridad a nivel de fila en cada tabla, aplicada en la propia base de datos y no en el código de la aplicación, y probada en CI (pgTAP) en cada cambio.
Autenticación
Inicio de sesión con contraseña y hash moderno, inicio de sesión con Microsoft y Google, o inicio de sesión único SAML 2.0 a través del proveedor de identidad de la propia organización, que un propietario configura en la página de Seguridad y puede exigir a todos los miembros.
Leer más
Las sesiones son cortas y se renuevan. Cualquiera puede añadir un segundo factor (TOTP) a su cuenta, y un propietario puede exigirlo: para los inicios con contraseña, o para todos los inicios sea cual sea el proveedor. Ambas exigencias se aplican en la base de datos, no en la interfaz: una sesión que no las cumple no ve ningún dato de la organización.
Nuestro propio acceso
Roles internos con el mínimo privilegio.
Leer más
Cada acción de un operador sobre un cliente se escribe en un libro de solo anexado que no podemos editar ni borrar, y que el cliente lee en su propia página de Registro de auditoría, bajo las acciones del personal de StandardOS. Cuál de nuestros empleados actuó no se revela, porque son datos personales de nuestra plantilla; la entrada dice qué ocurrió, cuándo y qué cambió. Es de solo anexado y no encadenado por hash: la cadena y sus anclajes protegen sus registros, no nuestro historial de acceso, y preferimos decir cuál es cuál.
Prácticas de desarrollo
Control de cambios
Cada cambio pasa por CI: comprobación de tipos, pruebas, pruebas de las políticas de base de datos y búsqueda de secretos en cada commit.
Verificado fuera del producto
Cada push construye una cadena de hashes real en Postgres, la exporta y la vuelve a verificar con el mismo script sin dependencias que publicamos, ejecutado con Node a secas y sin StandardOS.
Leer más
Un cambio en la regla de hash que olvidara actualizar la especificación hace fallar nuestra compilación en lugar de su auditoría.
Aislamiento probado en la base de datos
La seguridad a nivel de fila se comprueba con pgTAP contra un Postgres real en cada push.
Leer más
Las políticas se prueban donde se aplican, no se repasan a ojo en el código de la aplicación.
Secretos
Se buscan en CI y otra vez mediante un hook de git antes de que el código salga de una máquina de desarrollo, con todo el historial del repositorio revisado y limpio.
Dependencias
Fijadas y revisadas; avisos automáticos de vulnerabilidad sobre todo el grafo de dependencias.
Disciplina con la IA
En el producto, lo generado con ayuda de IA es siempre un borrador señalado como tal hasta que una persona lo confirma.
Leer más
La misma regla se aplica a cómo construimos.
Privacidad y protección de datos
RGPD
Responsable del tratamiento danés. Nuestro contrato de encargo del artículo 28 está publicado íntegro en getstandardos.com/legal/dpa, para todos los clientes y todos los planes, sin firma y sin llamada comercial.
Leer más
El detalle de qué tratamos y por qué está en la política de privacidad.
Sin rastreo
Ningún rastreador de analítica ni de publicidad en este sitio; sin banner de cookies, porque no hay nada que aceptar.
Diagnóstico
Las direcciones de correo, las direcciones IP, los identificadores de registro, las cookies y las cabeceras de autorización se eliminan de los informes de error antes de que salgan de nuestros servidores.
Leer más
Configurado en el código y revisado en cada cambio, en lugar de prometido en una política.
Salida
Exportación completa con un clic en formatos abiertos, en cualquier momento: durante la prueba, con la suscripción activa y durante 90 días tras la cancelación.
Leer más
El bloqueo no es nuestra estrategia de retención.
Subencargados
Deliberadamente pocos. Los cambios se anuncian aquí, con aviso previo a los clientes. Esta lista y la de nuestra política de privacidad(en inglés) son la misma lista, mostrada dos veces. Última modificación: 2026-09-27.
Supabase
Database, authentication, file storage
Lugar de tratamiento: EU (Ireland)
Vercel
Application hosting & delivery; cookieless traffic analytics (no cookies, no cross-site identifiers)
Lugar de tratamiento: EU serving; global CDN for static assets
Sentry
Error monitoring, diagnostics only; email addresses, IP addresses and record identifiers are stripped before events leave our servers
Lugar de tratamiento: EU region (Frankfurt)
Paddle
Merchant of record: checkout, payment, VAT & invoicing (card data never touches our servers)
Lugar de tratamiento: UK, under the EU adequacy decision
Resend
Transactional email
Lugar de tratamiento: EU region
Cambios anunciados
Están decididos y anunciados, pero aún no se usan. Ninguno trata datos hasta que lo activemos, y este aviso llega antes.
ZeroBounce
Anunciado el 2026-09-27, se aplica una vez activadoEmail address verification for outreach prospects: a company role address is checked for deliverability before a first letter is sent, so the sending domain is not spent on dead mailboxes and spam traps. Only the address is sent, never a name, and the answer we keep is the service's own status word
Lugar de tratamiento: EU. ZeroBounce states it hosts its servers in the EU and that data sent for processing is transmitted, stored and processed only on servers in the EU, on its own hardware rather than a public cloud, and it offers an EU data processing addendum incorporating the Commission's standard contractual clauses (zerobounce.net/gdpr and its EU DPA, read 2026-09-27). We call the EU-only endpoint api-eu.zerobounce.net, which its documentation describes as the endpoint where validations occur only within the EU; the global endpoint is not used
Divulgación responsable
¿Ha encontrado una vulnerabilidad? Escríbanos a security@getstandardos.com y acusaremos recibo en un plazo de dos días hábiles.
Leer más
No emprendemos acciones legales contra la investigación de buena fe, le mantenemos informado mientras corregimos, y damos crédito a quien lo desee. Por favor, evite acceder a datos de otras organizaciones. La seguridad a nivel de fila debería hacerlo imposible, y nos gustaría de verdad saberlo si no es así.
Para una revisión de seguridad
Nuestro contrato de encargo del tratamiento(en inglés) está publicado íntegro, así que no hay nada que solicitar. ¿Necesita algo más para una revisión de seguridad, cuestionarios o detalle de arquitectura? Escriba a security@getstandardos.com. Respondemos en un día hábil desde el propio StandardOS, para que la respuesta salga del código y no de un folleto.
Véase también:Quiénes somosContactoRegistro de cambiosVerificar sus registros