Usamos StandardOS para llevar StandardOS

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. Preferimos que vea aquí una incidencia a que se entere por nosotros después. Estado del servicio en directo → (en inglés)

Ubicación de los datos

Todos los datos de clientes se almacenan en la UE (Supabase, región de Irlanda). 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. 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. 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 cada registro está encadenado 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. Una restauración alterada no cuadraría, y lo sabríamos en lugar de suponerlo.

Integridad de los registros, nuestra diferencia

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. 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; no existe ruta de borrado para nadie.

Anclaje diario

Cada noche registramos la cabeza de cada cadena y la enviamos por correo a la mañana siguiente (07:00 UTC) a los propietarios y administradores de la organización. Una vez que el recibo está en su buzón, está en un servidor que no operamos, así que una reescritura posterior daría una cabeza que ya no coincidiría con la que usted tiene. Las raíces diarias también se publican abiertamente, para que cualquiera las archive. Esto no hace imposible la manipulación. La hace detectable por quien guardó su correo. Las raíces diarias publicadas → (en inglés)

Verificabilidad

Las exportaciones llevan los hashes y el contenido sobre el que se calculan, además de la regla de hash exacta. 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. La especificación y el script →

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. 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. 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. 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. 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. 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. 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. 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. 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-07-28.

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. 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í.