Cargando…
Cargando…
Cumplimiento / Compliance
Última revisión: 2026-05-27 · Próxima revisión: 2026-08-27 (cadencia trimestral)
simiriki opera sobre Microsoft Azure y Microsoft 365, con identidad en Microsoft Entra ID y datos en Azure PostgreSQL de región única (East US 2). Esta página declara — sin marketing — qué marcos regulatorios perseguimos, qué controles existen hoy con evidencia, y qué está comprometido o 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 | En evidencia | Línea base unificada de seguridad de Microsoft, mapeada a los marcos mayores. Iniciativa de Azure Policy desplegada a nivel de suscripción; Defender for Cloud habilita el panel de cumplimiento regulatorio. |
| CIS Microsoft Azure Foundations v2.0 | P1 | En evidencia | Línea base de seguridad específica de Azure del Center for Internet Security. Enforzada vía Azure Policy en rg-simiriki-prod-eastus2 y monitoreada en el Secure Score de Defender for Cloud. |
| 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 Microsoft Azure (proveedor de nube), simiriki (proveedor SaaS) y tú (el cliente). La frontera es explícita. "PLANEADO" marca lo que aún no está implementado.
| Capa de control | Microsoft Azure provee | simiriki provee | El cliente provee |
|---|---|---|---|
| Seguridad física de centros de datos | Sí (todo) | Ninguno | Ninguno |
| Parcheo del SO de servicios de plataforma | Sí (Container Apps, PG Flex, Redis, Front Door — gestionados) | Ninguno | 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 de cliente (Entra External ID — PLANEADO); MFA obligatorio en todo admin | Gestiona sus credenciales de admin M365 usadas en el consentimiento OAuth |
| Autorización y RBAC | Ninguno | RBAC de mínimo privilegio en Azure; 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 | Provee llaves gestionadas por plataforma (PMK) por defecto | Encripta datos en reposo; PLANEADO: Llaves Gestionadas por Cliente (CMK) | Ninguno |
| Encriptación en tránsito | Provee endpoints TLS | Enforza TLS 1.2 mínimo de extremo a extremo | Se conecta por HTTPS (navegadores / clientes API del lado del cliente) |
| Respaldo y restauración | Provee PITR de Azure PG + blob GRS | Configura respaldos; corre simulacros de restauración (PLANEADO primer simulacro 2026-07-15) | Decide la ventana de retención de sus exportaciones de datos |
| Registro y monitoreo | Provee infraestructura de Log Analytics + Application Insights | Configura recolección; instrumenta eventos; corre actor_audit_log con cadena de hash | Revisa el rastro de auditoría de su propio tenant M365 |
| Respuesta a incidentes | Provee alertas de Azure Service Health | Detecta, responde y notifica al cliente en ≤ 24h (LFPDPPP Art. 20) | Notifica a simiriki de incidentes en superficies M365 propias |
| Residencia de datos | Provee infraestructura regional | Región única East US 2 hoy (PLANEADO multi-región por cliente bajo R4) | 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. 32) | Envía solicitudes ARCO en nombre de sus empleados / usuarios |
Cada tercero que procesa datos de cliente por cuenta de simiriki, conforme al Artículo 28 LFPDPPP / Artículo 28 GDPR. Se refresca trimestralmente.
| Sub-procesador | Jurisdicción | Datos procesados | DPA |
|---|---|---|---|
| Microsoft Azure Microsoft Corporation | US | Cómputo, almacenamiento, base de datos, identidad y correo — toda la información de cliente (región East US 2) | 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 → |
| Amazon Web Services (S3) Amazon Web Services, Inc. | US | Destino de respaldo de base de datos (legacy). Volcados lógicos diarios de PG, encriptados en reposo (us-east-2). En migración hacia Azure GRS. | DPA → |
| Cloudflare Cloudflare, Inc. | US | Resolución DNS autoritativa para simiriki.com — solo registros DNS, sin datos de cliente | DPA → |
| Anthropic Anthropic, PBC | US | Procesador de IA (API comercial de Claude) para la generación de hallazgos, recomendaciones y textos. Recibe metadatos de configuración y de hallazgos del escaneo — nunca credenciales ni tokens. No se usa para entrenar sus modelos (Términos Comerciales de Anthropic); retención temporal y limitada. | DPA → |
El onboarding de Microsoft Compliance Manager (MCM) está activo. MCM es la capa gratuita de seguimiento de evidencia incluida con nuestra licencia M365 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 nuestro punto de partida, no nuestro promedio. La protección de tus datos como cliente no depende de nuestro score interno — depende de los controles de Microsoft Azure + las garantías contractuales en nuestro DPA, ambos vigentes en producción.
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: región única en Azure East US 2. El despliegue multi-región por cliente está en diseño bajo R4 (posterior a product-market fit). Si tu requisito de residencia exige una región específica (p. ej. México Central o la UE), conversémoslo antes de firmar — no afirmaremos cobertura que no tenemos.
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 M365, 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 M365) 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 189 playbooks de remediación. | Corregimos cada superficie al reparto real: de los 189 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.