Cargando…
Cargando…
Cumplimiento / Compliance
Última revisión: 2026-08-16 · Próxima revisión: 2026-11-16 (cadencia trimestral)
simiriki opera en un solo VPS de Hetzner en Ashburn, Virginia, publicado exclusivamente mediante Cloudflare Tunnel. PostgreSQL y Redis escuchan en loopback; Microsoft Entra ID sigue siendo el proveedor de identidad. Esta página declara — sin marketing — qué controles existen hoy y qué sigue planeado.
No reclamamos certificaciones que no poseemos. Cada afirmación lleva un marcador de estado explícito: en-evidencia, comprometido-en-auditoría o planeado. Cualquier proveedor que diga "somos SOC 2" sin un reporte Type II está haciendo una afirmación sin verificar; nosotros no.
Priorizamos por mercado: P0 cubre el sector privado mexicano + empresa LATAM + sede en EE. UU.; P1 amplía a banco de seguridad de nube y exigencias de privacidad europea; P2 son verticales reguladas (salud, banca) activadas por contrato.
| Marco | Prioridad | Estado | Descripción |
|---|---|---|---|
| LFPDPPP (México) | P0 | En evidencia | Ley Federal de Protección de Datos Personales en Posesión de los Particulares. Obligatoria para todo dato de cliente mexicano. Aviso de privacidad publicado; derechos ARCO atendidos en ≤ 20 días hábiles (Art. 32). |
| SOC 2 Type II | P0 | Comprometido en auditoría | Atestación AICPA de criterios de servicios de confianza. Período de observación de ~12 meses; se activa con el primer contrato empresarial. No reclamamos un reporte que aún no existe. |
| ISO/IEC 27001:2022 | P0 | Comprometido en auditoría | Estándar internacional de gestión de seguridad de la información. Controles mapeados vía Microsoft Compliance Manager; auditoría externa Stage 1/Stage 2 activada por contrato empresarial. |
| NMX-I-27001-NYCE (México) | P0 | Comprometido en auditoría | Norma mexicana equivalente a ISO/IEC 27001, emitida por NYCE. Relevante para procurement gubernamental y empresarial mexicano que exige la norma nacional. Mismos controles que ISO 27001; certificación local activada por contrato. |
| Microsoft Cloud Security Benchmark | P1 | Planeado | Línea base de seguridad de Microsoft para cargas Azure. El antiguo estate Azure de simiriki fue eliminado el 2026-08-13; no existe hoy una suscripción productiva sobre la cual afirmar enforcement de Azure Policy. |
| CIS Microsoft Azure Foundations v2.0 | P1 | Planeado | Línea base específica de Azure del Center for Internet Security. No aplica al runtime actual en Hetzner; se evaluaría de nuevo solo si una carga productiva vuelve a Azure. |
| GDPR (UE) | P1 | Planeado | Reglamento General de Protección de Datos de la UE. Relevante si servimos titulares de datos europeos. Las divulgaciones del Artículo 28 (sub-procesadores) ya se publican; el alcance completo se activa con el primer cliente con datos UE. |
| HIPAA (EE. UU.) | P2 | Planeado | Ley estadounidense de portabilidad de seguros de salud. Vertical de salud. No manejamos PHI estadounidense hoy; se activa solo si entramos al mercado de salud de EE. UU. |
| Regulación CNBV (México) | P2 | Planeado | Disposiciones de la Comisión Nacional Bancaria y de Valores (CUB, retención de registros). Vertical bancaria/financiera mexicana. Se activa con el primer cliente regulado por CNBV. |
P0 = máxima prioridad de mercado · P1 = secundaria · P2 = vertical / por contrato. Estado: en-evidencia (controles mapeados, evidencia recolectada) · comprometido-en-auditoría (se atestiguará en el primer contrato empresarial) · planeado (en hoja de ruta, aún no implementado).
El cumplimiento es una responsabilidad compartida entre Hetzner y Cloudflare (infraestructura), Microsoft (identidad e integraciones), simiriki y tú. La frontera es explícita. "PLANEADO" marca lo que aún no está implementado.
| Capa de control | Proveedor de infraestructura | simiriki provee | El cliente provee |
|---|---|---|---|
| Seguridad física de centros de datos | Hetzner y sus operadores de centro de datos | Ninguno | Ninguno |
| Parcheo de infraestructura y sistema operativo | Hetzner parchea hardware, red e hipervisor; Cloudflare opera el borde | Parchea Ubuntu, Docker, PostgreSQL, Redis y runtimes de aplicación | Ninguno |
| Código de aplicación y dependencias | Ninguno | Construir, desplegar, parchear (SBOM CycloneDX en cada PR) | Ninguno |
| Identidad y autenticación | Provee plataforma Entra ID | Configura auth con Microsoft; los usuarios activos registraron MFA, pero CA sigue en report-only y falta acceso de emergencia | Gestiona sus credenciales de administrador de Microsoft 365 usadas en el consentimiento OAuth |
| Autorización y RBAC | Ninguno | Acceso SSH restringido, secretos fuera del repo y RLS en datos de aplicación | Aprueba qué scopes de Microsoft 365 + Azure (Microsoft Graph + Azure Resource Manager) solicita simiriki en el OAuth del conector |
| Encriptación en reposo | No se reclama cifrado de volumen gestionado por plataforma | Credenciales y tokens sensibles usan AES-256-GCM en la aplicación; respaldos offsite se cifran antes de salir del host cuando el canal está habilitado | Ninguno |
| Encriptación en tránsito | Cloudflare termina TLS público y transporta por túnel saliente | No publica puertos web de origen; PostgreSQL y Redis escuchan solo en loopback | Se conecta por HTTPS (navegadores / clientes API del lado del cliente) |
| Respaldo y restauración | Hetzner provee el disco primario; no se reclama PITR gestionado | Genera y verifica dumps PostgreSQL cada hora, monitorea su edad y mantiene un flujo cifrado offsite con estado verificable; existen procedimientos de restauración y simulacro | Decide la ventana de retención de sus exportaciones de datos |
| Registro y monitoreo | Hetzner y Cloudflare proveen eventos de infraestructura/borde disponibles | Registra eventos estructurados en el host, ejecuta monitores sintéticos y mantiene actor_audit_log con cadena de hash | Revisa el rastro de auditoría de su propio tenant de Microsoft 365 |
| Respuesta a incidentes | Hetzner y Cloudflare proveen avisos de estado de sus plataformas | Detecta y responde; objetivo contractual de aviso al cliente ≤ 24h; Art. 19 LFPDPPP rige aviso significativo a titulares | Notifica a simiriki de incidentes en superficies propias de Microsoft 365 |
| Residencia de datos | Hetzner provee el VPS actual en Ashburn, Virginia (EE. UU.) | Un solo host y una sola región; sin failover multi-región | Selecciona al proveedor según sus requisitos de residencia de datos |
| Derechos del titular (LFPDPPP / GDPR) | Provee plataforma | Atiende solicitudes ARCO en ≤ 20 días hábiles (LFPDPPP Art. 31) | Envía solicitudes ARCO en nombre de sus empleados / usuarios |
Cada tercero que procesa datos de cliente por cuenta de simiriki, conforme a las obligaciones aplicables de encargado/subencargado. Se refresca trimestralmente.
| Sub-procesador | Jurisdicción | Datos procesados | DPA |
|---|---|---|---|
| Hetzner Cloud Hetzner Online GmbH | DE | Cómputo, disco, PostgreSQL y Redis del runtime productivo en un VPS de región única en Ashburn, Virginia (EE. UU.) | DPA → |
| Microsoft 365 + Azure / Graph + ARM Microsoft Corporation | US | OAuth de cliente Microsoft 365 + Azure (solo lectura: 155 reglas vía Microsoft Graph + 46 reglas vía Azure Resource Manager) durante escaneos + Graph SendMail para correo transaccional | DPA → |
| Stripe Stripe, Inc. | US | Procesamiento de pagos. Correo del cliente + payment-intent ID (sin datos de tarjeta — Stripe Checkout aloja el flujo). PCI DSS Level 1. | DPA → |
| Cloudflare Cloudflare, Inc. | US | DNS autoritativo, terminación TLS, protección de borde y Cloudflare Tunnel; procesa metadatos de solicitudes HTTP durante el tránsito | DPA → |
| Anthropic Anthropic, PBC | US | Modelos Claude para diagnóstico, memos ejecutivos, flujos comerciales y contenido editorial (los memos ejecutivos operan bajo consentimiento explícito del cliente: generar memos ejecutivos y análisis trimestrales para clientes). El asistente del sitio y la Auditoría de postura son deterministas y no envían sus entradas ni hallazgos a Anthropic. Los datos enviados a Anthropic a través de su API comercial no se utilizan para entrenar sus modelos (Términos Comerciales de Anthropic) y solo se retienen de forma temporal y limitada para operar el servicio y monitorear uso indebido. Los flujos que involucran datos personales se procesan únicamente con la API comercial de Anthropic; nunca se envían a niveles gratuitos de otros proveedores de modelos. | DPA → |
| Google Analytics 4 Google LLC | US | Analítica del sitio público con consentimiento; no se ejecuta en dashboard ni portal autenticado. | DPA → |
El onboarding de Microsoft Compliance Manager (MCM) está activo. MCM es la capa gratuita de seguimiento de evidencia incluida con nuestra licencia Microsoft 365 DEVELOPERPACK; mapea controles heredados de Microsoft (típicamente 30–50% del total) y rastrea las acciones de mejora restantes contra los marcos objetivo.
Las auditorías formales de SOC 2 Type II e ISO 27001:2022 se activan con el primer contrato empresarial. No comprometemos fechas específicas de auditoría públicamente porque el costo del asesor (~$40–60K USD/año) debe estar respaldado por ingresos. Las fechas comprometidas están disponibles bajo solicitud.
Microsoft Compliance Manager mide cuánto de cada marco regulatorio hemos implementado **en nuestro propio tenant**. Instanciamos las 3 evaluaciones el 2026-05-29 como compromiso público de transparencia: el score abajo es un snapshot, no una certificación. La protección de datos depende de los controles actuales de Hetzner, Cloudflare y simiriki, más las garantías contractuales del DPA.
Estado: baseline establecido el 2026-05-29 · Implementación Tier 1 en curso. Los créditos automáticos de Microsoft 365 ya aparecen reflejados; las acciones de mejora pendientes se documentan en el plan de cumplimiento interno (`docs/compliance/LFPDPPP_punchlist.md`).
Última exportación de MCM: 2026-05-29
| Evaluación | Score (baseline) | Acciones | Pruebas |
|---|---|---|---|
| AI Baseline Assessment | 0/1384 (0%) | 80 | 0 auto · 80 manual |
| Data Protection Baseline for Microsoft 365 | 173/10152 (2%) | 489 | 127 auto · 362 manual |
| Federal Consumer Protection Law - Mexico Assessment | 0/1040 (0%) | 21 | 0 auto · 21 manual |
Microsoft Graph no expone la puntuación de Compliance Manager; el único camino oficial para publicar los números fuera del portal de Purview es la exportación a Excel + re-importación. Por eso esta sección se actualiza por commit y no en tiempo real.
Hoy: un solo VPS en Ashburn, Virginia (EE. UU.), sin failover multi-región. Si tu requisito exige México, la UE u otra ubicación, debe quedar resuelto por escrito antes de enviar datos; no afirmamos cobertura que no existe.
simiriki mantiene un proceso documentado de respuesta a incidentes. Resumen de los compromisos contractuales:
Recibimos divulgación responsable de vulnerabilidades de seguridad. Acusamos recibo dentro de 72 horas y ofrecemos safe harbor a investigadores de buena fe.
No enmendaremos esta sección para reclamar certificaciones que no poseemos.
Sometemos nuestro propio producto al estándar que vendemos. Cuando una auditoría encuentra que sobre-afirmamos —una regla que podía fingir un veredicto, copy que exageraba la autonomía— retiramos la afirmación y registramos la corrección aquí. Un proveedor que te dice cuándo se equivocó es la señal que un escáner de caja negra no puede fingir.
| Fecha | Área | Qué encontramos | Qué corregimos |
|---|---|---|---|
| 2026-06-15 | Scan evaluators (Email-Authentication Posture — transport hardening: MTA-STS / TLS-RPT / DNSSEC / BIMI) | Restaurar SPF y DMARC contra el DNS real (en lugar del inventario de Graph que los fabricaba) abrió la puerta a medir el resto de la postura de autenticación de correo que un escáner genérico ignora: si el correo en tránsito exige TLS (MTA-STS), si hay visibilidad de las fallas de cifrado (TLS-RPT), si la zona DNS está firmada contra falsificación (DNSSEC) y si la marca se muestra con un certificado verificado (BIMI). Esos cuatro controles de endurecimiento no existían como reglas. | Se añadieron cuatro diferenciadores verificados por DNS (severidad BAJA, endurecimiento de transporte/integridad): EML-019 (MTA-STS — aprueba solo con el anuncio _mta-sts y la política HTTPS en "mode: enforce", RFC 8461; "testing"/"none" reprueban; política inaccesible → needs_review), EML-020 (TLS-RPT — registro _smtp._tls con "v=TLSRPTv1" y "rua", RFC 8460), EML-021 (DNSSEC — delegación firmada DS+DNSKEY, RFC 4033-4035; "null" indeterminado → needs_review) y EML-022 (BIMI con marca verificada VMC sobre DMARC en aplicación plena — draft IETF BIMI §7.1: sin DMARC aplicado BIMI es inerte). Cada uno califica el DNS publicado en vivo resuelto por el resolver Microsoft-nativo del entorno de Azure; toda resolución indeterminada vuelve a needs_review, nunca a un veredicto fabricado. Con esto el módulo de Postura de Autenticación de Correo restauró 5 de los 6 placebos a verificaciones reales contra el DNS (EML-012, firma DKIM, no es observable desde el registro publicado y permanece en revisión) y sumó 4 diferenciadores nuevos. El conjunto creció de 197 a 201 reglas (plano Graph 151→155; ARM sin cambios en 46). El desglose por categoría —veredicto automático / condicional / en revisión— se publica en vivo en /catalogo desde lib/catalog/coverage.generated.ts (la fuente única); esta nota no fija aquí una cifra que se desactualiza con cada ola. |
| 2026-06-15 | Scan evaluators (Email-Authentication Posture — DKIM selectors restored) | Tras restaurar SPF y DMARC contra el DNS real, faltaba DKIM. La presencia de las claves de firma de Microsoft 365 SÍ es verificable resolviendo los CNAME selector1/selector2._domainkey publicados en el dominio; mantener EML-002 en revisión cuando podía calificarse dejaba sin medir el tercer pilar de la autenticación de correo. | Se restauró EML-002 (DKIM — presencia de los CNAME selector1/selector2._domainkey de Microsoft 365, contra RFC 6376 §3.6.2.1 y Microsoft Learn). Califica el DNS publicado en vivo resuelto por el resolver Microsoft-nativo del entorno de Azure; toda resolución indeterminada vuelve a needs_review, nunca a un veredicto fabricado. EML-012 (firma DKIM habilitada) NO es observable desde el registro DNS publicado y permanece en revisión. Desglose tras esta ola: 86 reglas con veredicto automático, 58 condicionales, 53 en revisión, dentro del conjunto de 197. |
| 2026-06-15 | Scan evaluators (Email-Authentication Posture — SPF + DMARC restored) | Las seis reglas de autenticación de correo se habían movido a needs_review al detectar que leían un campo que el DNS nunca expone. Eso era honesto pero incompleto: SPF y DMARC SÍ son verificables resolviendo el DNS real publicado, no el inventario de Graph. Mantenerlas en revisión cuando podían calificarse contra el estándar dejaba sin medir un control crítico. | Se restauraron EML-001/EML-011 (presencia y rigor de SPF, contra RFC 7208 y el BCP de M3AAWG — "-all" y "~all" aprueban; "+all"/"?all"/sin-all, registro duplicado, exceso de 10 búsquedas DNS recursivas y el mecanismo "ptr" reprueban) y EML-003/EML-013 (presencia de DMARC y aplicación plena, contra RFC 7489 §6.6.4 — aprueba solo con p=quarantine/reject, pct=100 y un destino "rua"). Califican el DNS publicado en vivo resuelto por el resolver Microsoft-nativo del entorno de Azure; toda resolución indeterminada vuelve a needs_review, nunca a un veredicto fabricado. Desglose tras esta ola: 86 reglas con veredicto automático, 57 condicionales, 54 en revisión, dentro del conjunto de 197. |
| 2026-06-15 | Scan evaluators (email-authentication DNS cluster) | Seis reglas de autenticación de correo —SPF (EML-001), DKIM (EML-002), DMARC (EML-003), rigor de SPF (EML-011), firma DKIM (EML-012) y DMARC en rechazo (EML-013)— leían el campo serviceConfigurationRecords de la respuesta de lista GET /domains, un campo que Graph nunca entrega ahí (y que, aun consultándolo aparte, devuelve los registros que Microsoft espera, no los publicados en el DNS). El resultado: marcaban SPF/DKIM/DMARC como ausentes en TODO dominio verificado, un hallazgo CRÍTICO fabricado incluso en tenants correctamente configurados. | Los seis controles se movieron a needs_review (excluidos del puntaje, del PDF y del estado de cumplimiento — nunca un falso aprobado ni un falso reprobado) mientras se construye el módulo real de Postura de Autenticación de Correo: verificación contra el DNS real (DNS-over-HTTPS) para SPF/DMARC y dkimConfiguration de Graph para DKIM, calificando la fuerza de la política (p. ej. DMARC p=none = solo monitoreo) contra CISA / NIST SP 800-177 / M3AAWG. Desglose tras esta ola: 86 reglas con veredicto automático, 53 condicionales, 58 en revisión, dentro del conjunto de 197. |
| 2026-06-14 | Scan evaluators (Backup + guest-invite + email-security connector) | Tres controles más describían un riesgo real pero seguían en needs_review: respaldo nativo de Microsoft 365, postura de invitación de invitados del tenant, y la familia de seguridad de correo de Exchange/EOP (Safe Attachments, anti-phishing, Customer Lockbox, etc.). Sus evaluadores estaban pendientes de un endpoint de Graph o de un conector dedicado, no eran un defecto de lógica. | Se restauraron OPS-003 (respaldo nativo de Microsoft 365) y TMS-002 (re-alcanzado a la postura de invitación de invitados del tenant) con evaluadores reales —solo Graph app-only, sin PowerShell—, y se incorporaron 9 reglas de seguridad de correo de Exchange/EOP mediante el conector de Gestión de Configuración del Tenant basado en Graph (app-only, sin PowerShell). Esas 9 reglas de seguridad de correo están detrás de una bandera y devuelven needs_review hasta que el conector se habilite para el inquilino. Desglose tras esta ola: 92 reglas con veredicto automático, 53 condicionales, 52 en revisión, dentro del conjunto de 197. |
| 2026-06-14 | Scan evaluators (scope-gated restoration) | Algunas reglas en needs_review describían controles que SÍ son legibles desde Microsoft Graph, pero requerían un permiso de solo lectura adicional que el escaneo aún no solicitaba (compartición externa de SharePoint, MFA de dominios federados, reenvío por reglas de bandeja). No eran defectos de evaluador: eran un límite de alcance de consentimiento. | Tras conceder tres scopes de solo lectura (SharePointTenantSettings.Read.All, Domain-InternalFederation.Read.All, MailboxSettings.Read) se restauraron 4 reglas con evaluadores reales: DLP-012/DLP-013 (compartición externa de SharePoint), EXO-001 (MFA de dominios federados) y EXO-004 (reenvío externo por reglas de bandeja, con el alcance acotado y los dos mecanismos solo-PowerShell divulgados). Cada una pasó verificación adversarial independiente y mantiene un respaldo honesto a needs_review hasta que se concede el consentimiento. Desglose tras esta ola: 92 reglas con veredicto automático, 42 condicionales, 63 en revisión, dentro del conjunto de 197. |
| 2026-06-14 | Scan evaluators (restoration) | La cuarentena a needs_review era un estado intermedio honesto, no el final: muchas reglas describían un control real cuyo evaluador era defectuoso. Una clasificación de las 76 confirmó que solo 10 son restaurables con un evaluador real desde el token de escaneo de solo lectura — las demás dependen de datos fuera de alcance (PowerShell de Exchange/Defender/Purview, consentimiento adicional) y permanecen, correctamente, en needs_review. | Se restauraron 9 reglas (DEV-003, MDM-007, MDM-011, APP-001/003/008, IAM-004, OPS-002, TMS-004) con evaluadores reales que leen el estado real del inquilino, cada uno con un respaldo honesto a needs_review. Cada evaluador pasó una verificación adversarial independiente (se detectaron y corrigieron 5 defectos de placebo antes de publicar). Desglose tras esta ola: 92 reglas con veredicto automático, 38 condicionales, 67 en revisión, dentro del conjunto de 197. |
| 2026-06-09 | Scan evaluators (PG-8 round 2) | Una re-auditoría completa del conjunto de evaluadores (entonces 197 reglas) más una verificación adversarial de 51 candidatos confirmó 41 evaluadores MÁS cuyo veredicto no era determinable honestamente desde los datos del escaneo: 18 marcaban una falla CRÍTICA/ALTA falsa contra inquilinos correctamente configurados; 13 siempre aprobaban, ocultando riesgo real. | Los 41 pasan a needs_review (excluido del score, el PDF y el cumplimiento). Desglose honesto actualizado: 92 reglas con veredicto automático, 22 condicionales y 83 en revisión, dentro del conjunto de 197. Reversible: cada una se restaura al obtener un evaluador real. |
| 2026-06-03 | Scan evaluators (PG-8) | Una auditoría adversarial del conjunto completo de evaluadores del escaneo (entonces 197 reglas) encontró 41 que podían fingir un aprobado (endpoints proxy, datos siempre presentes) o fingir una falla (marcar como deficiente a un cliente correctamente configurado). | Retiramos los 41 a needs_review o corregimos la lógica. needs_review se excluye del score, del PDF y del estado de cumplimiento — nunca un aprobado falso, nunca una falla falsa. |
| 2026-06-03 | Detection coverage (PG-9) | La copia pública afirmaba que cada regla del conjunto (entonces 197) era un evaluador real. | Corregido al desglose honesto: ~146 reglas evalúan aprobado/falla y ~49 requieren revisión manual, dentro de un conjunto de 197. |
| 2026-06-03 | Operación autonomy | El marketing implicaba que el agente ejecuta autónomamente los 188 playbooks de remediación. | Corregimos cada superficie al reparto real: de los 188 playbooks, el agente aplica autónomamente vía Microsoft Graph las correcciones que Graph permite; el resto se lo entrega a tu operador como un paso de un clic en el dashboard, con los pasos guiados exactos — siempre con tu aprobación. simiriki nunca toca tu tenant a mano. |
| 2026-06-02 | Power Platform rules (PG-1) | 6 reglas de Power Platform hacían coincidencia de texto con una función no relacionada de Microsoft Graph en lugar de datos de gobernanza reales. | Retiradas a needs_review; construimos 7 evaluadores de gobernanza reales (activos al otorgar el consentimiento de administrador). |
| 2026-05-28 | Status page integrity | La página de estado pública podía mostrar un incidente de muestra ("interrupción de pagos") codificado cuando los datos en vivo no estaban disponibles. | Eliminamos el andamiaje; el respaldo ahora muestra el estado honesto "todo operativo". |
Esta página es el resumen público. El documento completo de postura de cumplimiento (con mapeo de controles a ISO 27001 / SOC 2 y artículos LFPDPPP) está disponible bajo solicitud para equipos de procurement.