MatrizdePreparaciónparaProcurement

La base Agency SaaS define organizaciones, membresías, roles por tenant, escrituras de suscripción protegidas y límites respaldados por RLS.

El billing de Agency y las mutaciones protegidas del Centro de Mando validan ahora el assurance de la sesión en servidor y rechazan usuarios enrolados cuya sesión puede llegar a AAL2 pero sigue en AAL1. Las denegaciones MFA del Centro de Mando quedan registradas sin persistir tokens de acceso ni valores TOTP. El enrolamiento obligatorio por rol sensible y el enforcement universal en RPC/RLS continúan pendientes.

MIRMC ya contiene una base SAML SSO staged para inicio/callback, binding explícito del UUID del proveedor con la organización y guardas negativas cross-tenant. Producción continúa en planned porque todavía no existe un IdP real registrado y verificado, y no se afirma OIDC como implementado.

Está staged una base SCIM 2.0 Users por tenant, credenciales de organización hash-only, enlace de primer login ligado a SAML, plano de control AAL2 y precondiciones ETag atómicas opcionales. Producción continúa en planned hasta completar con éxito un canary con IdP y cliente SCIM reales.

Las mutaciones del tenant y transiciones comerciales anexan evidencia estructurada al audit trail de la organización. Las mutaciones protegidas del Centro de Mando conservan denegaciones de autorización y evidencia del ciclo de ejecución, y un límite staged de exportación AAL2 para owner/admin añade flujos JSON/NDJSON acotados, controles explícitos de origen del navegador y recibos SHA-256 por página.

MIRMC ya contiene una autoridad staged de publicación por tenant con AAL2 de sesión actual, separación maker/checker, dos aprobaciones independientes para producción, caducidad, binding al commit exacto y un límite service-only ligado al release receipt de Cloudflare. Todavía no se afirma activación productiva.

No se afirma enforcement productivo. La arquitectura de fuente ya cierra los bypasses privilegiados registrados: 9/9 superficies tienen evaluación de red y quedan 0 bypasses conocidos en fuente. Producción todavía requiere provisión coordinada de secretos, conformidad de migraciones en staging, ventana OBSERVE, canary medido y activación v4 service-only.

MIRMC ya contiene un plano staged de retención por tenant con políticas acotadas por categoría, administración AAL2, legal holds con separación creador/liberador y un gate service-only de elegibilidad para borrado. La eliminación automática está apagada por defecto y no se afirma purge productivo.

MIRMC ya contiene un plano staged de retención por tenant con políticas acotadas por categoría, administración AAL2, legal holds con separación creador/liberador y un gate service-only de elegibilidad para borrado. La eliminación automática está apagada por defecto y no se afirma purge productivo.

MIRMC ahora mapea ocho actividades de tratamiento respaldadas por código a límites canónicos de proveedores, clases de datos, sujetos, categorías de retención y estados de evidencia de residencia, y puede construir un paquete JSON de procurement desde registros canónicos. El mapa es solo evidencia de ingeniería: no se infiere del código un DPA, rol legal, mecanismo de transferencia, garantía de residencia ni certificación de cumplimiento.

MIRMC publica un registro de proveedores/integraciones respaldado por código que distingue dependencias core de servicios condicionales y opcionales. Deliberadamente no se presenta como lista legal firmada de subprocesadores ni garantía de residencia de datos.

No. La evidencia del repositorio registra proveedores y límites arquitectónicos, pero no establece una garantía contractual de residencia.

No. El mapa de evidencia de ingeniería y el inventario de proveedores son insumos de procurement, no un DPA ejecutado ni una lista legal de subprocesadores.

MIRMC no afirma certificación SOC 2 en este registro de confianza.

MIRMC no afirma certificación ISO 27001 en este registro de confianza.

MIRMC ya tiene objetivos RPO/RTO explícitos de ingeniería y un protocolo aislado de pruebas de restauración, pero esta auditoría todavía no afirma evidencia DR periódica completada ni el cumplimiento verificado de esos objetivos.

Ya existe transparencia operativa en vivo y está definido un modelo de operación de incidentes, pero todavía no se afirman como completos el uptime histórico, la evidencia histórica de incidentes ni compromisos contractuales de uptime/remedios.

La identidad del candidato Cloudflare y las sondas frescas del runtime son el límite de evidencia productiva. Un check alojado ausente o fallido nunca se convierte silenciosamente en éxito.

Agency Overview ya contiene una superficie staged multi-sitio de métricas agregadas para cobertura de repositorios, autonomía, aprobaciones preview, dominios y gobierno de publicación. El snapshot exige autoridad del tenant y no expone filas crudas de clientes/proyectos.

La auditoría del 25 de agosto de 2026 encontró main sin protección ni status checks obligatorios. CODEOWNERS y una política escalonada de ruleset ya están preparados, pero GitHub debe aplicarlos antes de considerar este control implementado.

No existe concesión de plan desde el navegador. Los redireccionamientos de Stripe no otorgan un plan. Se requieren webhooks firmados, mapeos de precios controlados por servidor y transiciones aprobadas antes de converger la suscripción.