¿Debes remediar o reconstruir un SaaS hecho con IA para SOC 2?

Una fecha límite de SOC 2 no convierte un código débil en un proyecto de reconstrucción. Convierte la incertidumbre en aquello que debes eliminar. Si puedes dibujar los límites del sistema, demostrar quién puede acceder a los datos de clientes y probar que los controles funcionan de forma constante, una remediación acotada suele ser más rápida y segura. Si nadie puede explicar la identidad, la separación entre clientes o el movimiento de datos sin leer componentes aleatorios en producción, aplicar parches quizá solo haga que la incertidumbre resulte más difícil de ver.

La elección no es «código antiguo frente a código limpio». La cuestión es si el sistema actual puede sostener controles comprensibles, comprobables y estables durante el periodo de auditoría. He visto equipos reemplazar un servicio feo pero conocido semanas antes de recopilar evidencias y descubrir después que el nuevo servicio no tenía historial operativo. También he visto a fundadores conservar un prototipo porque parecía funcionar mientras cada ruta de la API aplicaba la autorización de una forma distinta. Ambos equipos optimizaron la variable equivocada.

Una decisión sensata aplica cuatro pruebas: estabilidad de la arquitectura, evidencias de control, tratamiento de datos y calendario. Hazlas antes de prometer una fecha de auditoría o encargar una reescritura. Tu auditor debe confirmar el alcance y lo que espera de las evidencias, pero la decisión técnica corresponde a quienes tendrán que operar el sistema después de emitir el informe.

Una auditoría SOC 2 no puntúa la limpieza del código

Un examen SOC 2 trata sobre el sistema de una organización de servicios y los controles relacionados con los Criterios de Servicios de Confianza seleccionados. AICPA describe SOC 2 en términos de seguridad, disponibilidad, integridad del procesamiento, confidencialidad y privacidad. Ese enfoque importa porque un auditor no da puntos por una arquitectura de moda, un framework nuevo ni un repositorio ordenado. El auditor evalúa si la descripción del sistema hecha por la dirección es exacta y si los controles incluidos cumplen los requisitos del encargo.

Los tipos 1 y 2 también crean presiones técnicas diferentes. Un informe de tipo 1 aborda el diseño de los controles en una fecha concreta. Un informe de tipo 2 añade la eficacia operativa durante un periodo. Pregunta a la firma de CPA que realiza el examen qué periodo y muestras espera; la duración y el método de muestreo son decisiones del encargo, no valores que ingeniería deba adivinar en un artículo.

Esta diferencia desmonta un argumento comercial frecuente: «Reconstrúyelo para que apruebe SOC 2». Ninguna aplicación aprueba SOC 2 por sí sola. La organización define un sistema, ejecuta controles alrededor de él, conserva evidencias y formula afirmaciones que el auditor del servicio examina. El comportamiento de la aplicación puede apoyar o debilitar esos controles, pero un repositorio reescrito no sustituye las revisiones de acceso, las aprobaciones de cambios, la respuesta a incidentes, la supervisión de proveedores ni una documentación veraz.

El código desordenado puede permanecer dentro de un sistema defendible cuando el equipo conoce sus límites, prueba el comportamiento importante y aplica cambios mediante un proceso controlado. Un código impecable puede estar dentro de un sistema indefendible si el acceso a producción es compartido, los registros omiten la identidad del actor, los secretos viven en el control de versiones o los despliegues se saltan la revisión. Trata la calidad del código como un indicador de posibles fallos de control, no como el criterio de auditoría.

Empieza por fijar el alcance. Nombra los servicios de producción, almacenes de datos, colas, proveedores de identidad, rutas de despliegue, herramientas administrativas y personas que prestan el servicio al cliente. Marca los componentes excluidos y justifica cada exclusión. Si el equipo no puede ponerse de acuerdo sobre ese inventario, ninguna estimación de remediación o reconstrucción será creíble.

Una arquitectura estable permite prever los cambios

Una arquitectura es lo bastante estable para remediarla cuando los ingenieros pueden predecir el efecto de un cambio y comprobar esa predicción antes de publicarlo. No necesita microservicios, modelado formal de dominios ni una nube concreta. Necesita responsabilidades claras sobre identidad, autorización, acceso a datos, configuración y despliegue.

Comprueba la estabilidad con un ejercicio de impacto del cambio. Elige un requisito corriente, como retirar el acceso administrativo de un empleado que se ha marchado. Pide al equipo que identifique cada punto donde se aplica, la fuente de verdad, el despliegue necesario, la prueba que demuestra la denegación, el registro que se genera y la vía para revertir. Repite el ejercicio para borrar los datos de un cliente y rotar un secreto de producción. Si las respuestas convergen en un conjunto pequeño de componentes conocidos, la remediación tiene una base sólida. Si cada persona encuentra otra ruta oculta, todavía se está descubriendo la arquitectura.

Las aplicaciones generadas con IA suelen fallar esta prueba de maneras reconocibles. Un componente del navegador consulta directamente la base de datos en un flujo, mientras otro usa una API. Varias rutas confían en un ID de usuario enviado por el cliente. La autorización vive en la visibilidad de páginas, middleware, reglas de base de datos y comprobaciones de ruta escritas a mano con supuestos distintos. Las variables de entorno mezclan configuración pública con credenciales. Ningún defecto aislado obliga a reconstruir. Su dispersión sí puede hacerlo.

Cuenta rutas de control, no archivos. Diez rutas vulnerables detrás de una política central pueden repararse y probarse como una unidad. Tres rutas con tres modelos de identidad sin relación pueden exigir sustituir el límite de identidad. Un repositorio grande con una capa de servicios modular puede ser más seguro de remediar que un prototipo pequeño cuyas reglas de negocio viven en callbacks de la interfaz y disparadores de la base de datos.

Uso tres hallazgos arquitectónicos como señales de reconstrucción. Primero, el sistema no tiene un identificador fiable de cliente o cuenta, así que el aislamiento depende de filtros improvisados. Segundo, las acciones privilegiadas no tienen un único límite de aplicación. Tercero, el modelo de datos persistente contradice las reglas reales de propiedad del producto, lo que obliga a cada consulta a reconstruir quién es dueño de qué. Cuando aparecen los tres, los arreglos locales tienden a conservar la misma ambigüedad bajo más código.

No confundas código desconocido con código inestable. Un equipo competente puede cartografiar código desconocido mediante trazas, pruebas y observación en tiempo de ejecución. La inestabilidad aparece cuando la misma entrada llega a decisiones de seguridad materialmente distintas por rutas que nadie puede enumerar. Es una propiedad que puedes investigar, no una sensación acerca de quién escribió el prototipo.

La estabilidad de la arquitectura también incluye la responsabilidad operativa. Pregunta quién recibe una alerta cuando aumentan los fallos de autorización, quién puede distinguir un ataque de una publicación defectuosa, quién puede desactivar la ruta afectada y quién verifica la recuperación. Provoca un fallo controlado en un periodo tranquilo y sigue la respuesta desde la señal hasta el ticket, la decisión, la corrección y el cierre. Si la aplicación tiene alertas pero no un responsable concreto, o si esa persona no dispone de una medida segura de contención, el diseño no es estable en producción. Aún puedes remediarlo, pero el alcance debe incluir el manual operativo, los permisos, la telemetría y la prueba de recuperación. Reconstruir el código sin asignar esas responsabilidades reproduce la misma debilidad en una tecnología más nueva.

Las evidencias sobreviven a una reparación, no a un reinicio improvisado

Las evidencias de control son el argumento práctico más fuerte a favor de remediar cerca de un periodo de observación de tipo 2. Una reparación puede conservar el historial de despliegues, los registros de tickets, las revisiones de acceso, el historial de alertas, las pruebas de copias de seguridad y los registros de producción. Una reconstrucción suele cambiar a la vez los límites del sistema, las herramientas, los repositorios, los roles y quienes ejecutan los controles. El nuevo diseño puede ser mejor, pero sus controles aún tienen que funcionar y dejar pruebas.

Una evidencia no es una captura de pantalla reunida la noche anterior al trabajo de campo. Una buena evidencia identifica el control, el actor, la marca de tiempo, la población, el resultado y el tratamiento de excepciones. La aprobación de una solicitud de cambios sin demostrar que todos los cambios de producción pasan por ese repositorio es débil. Una lista de administradores actuales sin la decisión del revisor ni seguimiento de las bajas está incompleta. La configuración de una alerta sin una prueba o un registro de incidente dice poco sobre su funcionamiento.

Crea una tabla de continuidad de evidencias antes de tocar la arquitectura. Para cada control, anota la fuente actual de evidencias, la fuente prevista después del cambio, la fecha de migración, el responsable y cómo demostrarás la integridad durante la transición. Presta especial atención a los controles cuya población cambia, como los despliegues que pasan a otra canalización o los usuarios que se mueven a otro proveedor de identidad. El auditor puede necesitar ambas poblaciones y una conciliación entre ellas.

Un pequeño registro puede revelar si el historial de cambios se puede recopilar. Exige un registro como este para cada publicación en producción y comprueba después que los identificadores indicados existen en los sistemas que los generaron:

{
  "release_id": "prod-2026-06-18-07",
  "commit": "8c91f14",
  "pull_request": 184,
  "approved_by": "[email protected]",
  "deployed_by": "pipeline",
  "deployed_at": "2026-06-18T14:22:31Z",
  "test_run": "security-4421",
  "exception": null
}

El registro une fuentes de evidencia, pero no basta por sí solo. El commit debe llevar al cambio revisado, la solicitud debe mostrar a un aprobador apto, la prueba debe corresponder a ese commit y el sistema de despliegue debe mostrar que el mismo artefacto llegó a producción. Toma muestras de la población completa de publicaciones y explica bots, cambios de emergencia, reversiones y cambios aprobados que nunca se publicaron. Busca también registros ausentes; una muestra perfecta extraída de una lista incompleta demuestra muy poco. Si no puedes establecer esta cadena para la aplicación actual, reconstruirla no reparará el control de gestión de cambios. Solo iniciará otro historial que necesita la misma conciliación.

Conserva de forma inmutable las evidencias antiguas al migrar. Exporta los registros con límites temporales documentados, conserva los metadatos del repositorio y la canalización según tu política de retención y registra quién verificó la exportación. No mantengas un entorno de producción antiguo como si fuera un museo si eso crea riesgos de acceso o de parches. Conserva los registros, documenta la retirada y apaga el entorno mediante el mismo proceso aprobado que afirmas utilizar.

El tratamiento de datos determina cuánto código debe moverse

Mapea los datos antes de estimar cualquiera de las opciones. Los fundadores suelen empezar por pantallas y funciones porque son visibles. El alcance de SOC 2 y el riesgo de la aplicación dependen de los datos de clientes, credenciales, tokens, registros, copias de seguridad, exportaciones de soporte y servicios que los procesan. Un plan de reconstrucción que redibuja pantallas mientras copia la misma base de datos confusa es un trabajo cosmético.

Crea un inventario del flujo de datos a nivel de grupos de campos, no solo «la aplicación usa una base de datos». Registra qué entra, dónde se valida, dónde se guarda, qué cliente lo posee, qué roles lo leen, por dónde sale, cuánto tiempo permanece y cómo se propaga el borrado. Incluye tareas en segundo plano, analítica, seguimiento de errores, correo, almacenamiento de objetos, copias para pruebas y procesos manuales de soporte. Registra la incertidumbre como un hallazgo; no rellenes los huecos con suposiciones.

El descubrimiento de datos puede inclinar la decisión en ambas direcciones. Quizá descubras que el prototipo tiene un único almacén relacional bien estructurado y que todo el comportamiento peligroso vive en una fina capa de API. Eso favorece la remediación porque sustituir el límite es más pequeño que migrar los datos. También puedes encontrar registros de clientes duplicados, claves de objetos sin ámbito, credenciales guardadas junto a perfiles y tareas que copian filas de producción a tablas de pruebas sin gestionar. Eso favorece un nuevo modelo de datos y una migración controlada.

El riesgo de migración merece una estimación propia. Un esquema limpio no garantiza un cambio limpio. Necesitas reglas de mapeo, totales de validación, tratamiento de registros rechazados, criterios de reversión, comportamiento de borrado y un plan para las escrituras que ocurran durante la migración. Los hashes pueden verificar igualdad de bytes en objetos sin cambios; los recuentos y las invariantes de negocio pueden comprobar tablas transformadas. Nunca declares terminada una migración porque el proceso acabó correctamente.

Los registros exigen moderación. Los equipos que preparan una auditoría a veces aumentan el registro en todas partes y terminan capturando tokens de sesión, cuerpos de peticiones, datos personales o errores de base de datos con secretos. Registra el actor, la acción, el objetivo, el resultado, la marca de tiempo y el identificador de correlación necesarios para atribuir responsabilidades. Excluye credenciales y cargas innecesarias. Restringe el acceso a los registros y prueba la ocultación con fallos realistas.

La diferencia más útil está entre la corrección de los datos y su control. La corrección pregunta si la aplicación guardó el valor previsto. El control pregunta si solo los actores autorizados pudieron causarlo, verlo, cambiarlo, exportarlo o borrarlo, y si la organización puede demostrarlo. Una reescritura centrada en la corrección puede reproducir el mismo fallo de control con tipos más limpios.

La identidad y los límites entre clientes son condiciones decisivas

Una identidad rota y un aislamiento deficiente entre clientes pueden obligar a reconstruir aunque el resto del producto funcione. La autenticación demuestra o establece quién es el actor. La autorización decide qué puede hacer. El aislamiento entre clientes impide que la autoridad y los datos de uno invadan el espacio de otro. Los prototipos generados con IA mezclan a menudo estas tres tareas, y arreglar la página de inicio de sesión solo resuelve la primera.

Sigue una petición desde el borde de la red hasta el almacén de datos. Identifica dónde se valida la sesión o el token, dónde obtiene el servidor al actor, de dónde sale el contexto del cliente, dónde se comprueba el permiso y cómo se restringe la consulta. Los identificadores de usuario, rol o cliente enviados desde el navegador no deben adquirir autoridad porque la interfaz normalmente envíe valores honestos. Las decisiones del servidor necesitan una fuente fiable.

OWASP ASVS resulta útil porque trata la seguridad de aplicaciones como requisitos verificables, no como una lista genérica de vulnerabilidades. OWASP dice que ASVS ofrece una base para probar controles técnicos de seguridad y una lista de requisitos para desarrollar de forma segura. Usa la versión vigente acordada con tus evaluadores y registra identificadores de requisitos con versión en las evidencias de prueba, porque OWASP advierte que pueden cambiar entre versiones. Yo no afirmaría que un sistema «cumple ASVS» tras ejecutar un escáner; relaciona los requisitos pertinentes con pruebas y hallazgos.

Elige remediar cuando puedas establecer una única ruta de identidad fiable, centralizar la autorización en un límite estrecho y aplicar el ámbito del cliente en cada acceso a datos. Sustituye un subsistema cuando solo ese límite es inseguro. Reconstruye el servicio cuando la autoridad depende del estado del navegador en toda la aplicación o cuando el modelo de datos no puede expresar la propiedad del cliente sin inferencias.

Los secretos y las inyecciones requieren contención inmediata, elijas lo que elijas a largo plazo. Revoca las credenciales expuestas, elimina accesos no autorizados, conserva evidencias del incidente e investiga su uso. Después, parametriza las consultas, valida las entradas en los límites de confianza y restringe los privilegios de la base de datos. Una futura reconstrucción no justifica dejar expuesto el sistema actual durante el diseño y la migración.

No mantengas dos sistemas de identidad más tiempo del necesario. Las escrituras duplicadas, la traducción de tokens y una administración dividida amplían la superficie de control y complican las evidencias. Si una migración gradual necesita ambos, define qué sistema manda para cada población, añade criterios de caducidad, prueba la revocación a través del puente y fija una fecha para retirarlo.

Remediar gana cuando el límite se puede conocer

Elige una remediación acotada cuando el modelo de propiedad del producto es coherente, el comportamiento arriesgado se concentra detrás de límites sustituibles y el equipo puede demostrar los cambios con pruebas automáticas y registros operativos. Esto sigue siendo cierto aunque el código generado sea repetitivo o poco elegante. Preparar una auditoría recompensa el comportamiento controlado más que la pureza estética.

Un buen alcance de remediación nombra resultados en lugar de una limpieza vaga. Sustituye la autorización confiada al navegador por comprobaciones del servidor. Lleva los secretos a un almacén aprobado y rótalos. Consolida los despliegues de producción en una sola canalización revisada. Añade restricciones de cliente al acceso a datos. Oculta campos sensibles de los registros. Añade pruebas que intenten acceder a otro cliente y ejecutar acciones privilegiadas como un usuario sin privilegios. Vincula cada cambio a un control, un riesgo, una fuente de evidencia y una prueba de aceptación.

La refactorización fuera de esos resultados puede esperar. Cambiar nombres de archivos, sustituir bibliotecas de estado o convertir cada componente al patrón preferido crea volumen de revisión sin reducir un riesgo declarado. Las diferencias cosméticas grandes también esconden regresiones de seguridad. Mantén los cambios de seguridad lo bastante pequeños para que un revisor pueda razonar sobre ellos y separa las refactorizaciones mecánicas de los cambios de comportamiento.

Define criterios de salida que una persona escéptica pueda comprobar. «Autenticación arreglada» no es un criterio de salida. «Cada ruta de API protegida rechaza un token caducado, obtiene el actor en el servidor, comprueba el permiso necesario, limita el acceso al cliente del actor y emite un evento de auditoría sin datos sensibles» sí se puede probar. Adjunta el inventario de rutas y los resultados, incluidos los fallos.

La remediación se convierte en un falso ahorro cuando cada arreglo exige otra excepción. Busca envoltorios de políticas que las rutas antiguas pueden saltarse, indicadores de compatibilidad que nunca caducan y pruebas que simulan tanto que eliminan la capa de autorización real. Si la lista de excepciones crece durante el primer tramo de reparación, detente y reevalúa el límite. El esfuerzo ya invertido no hace que la arquitectura sea más estable.

Una reparación limitada también puede comprar tiempo para una reconstrucción posterior, pero llámala contención. Define qué riesgo reduce, qué deuda permanece y cuándo se revisará la decisión de sustituir. No describas un control compensatorio temporal como diseño permanente solo porque el calendario de auditoría resulta incómodo.

Reconstruye solo con una migración controlada

Elige reconstruir cuando el sistema no puede expresar o aplicar sus límites de confianza sin excepciones por todas partes, el modelo de datos contradice las reglas de propiedad o el comportamiento esencial no puede caracterizarse lo bastante bien para cambiarlo con seguridad. Reconstruir porque el código resulta vergonzoso es un desperdicio. Hacerlo porque no existe un límite de control comprobable es una decisión técnica que puedes defender.

La reconstrucción debe comenzar con un inventario de comportamiento, no con un editor vacío. Recoge roles de usuario, reglas de cliente, flujos privilegiados, ciclo de vida de datos, integraciones, comportamiento ante fallos y tareas operativas. Marca el comportamiento accidental que no debe sobrevivir. Los registros de producción y los casos de soporte pueden descubrir rutas que la interfaz visible no muestra, pero examínalos sin copiar datos sensibles a herramientas no gestionadas.

NIST SP 800-218 dice que las prácticas de desarrollo seguro suelen tener que incorporarse a cada modelo de ciclo de desarrollo. Su Secure Software Development Framework agrupa el trabajo en preparar la organización, proteger el software, producir software bien protegido y responder a vulnerabilidades. La lección útil es que un repositorio nuevo no incluye de serie un proceso seguro. Integra requisitos, revisión, procedencia, pruebas, protección de publicaciones y respuesta a vulnerabilidades en el plan desde el primer commit.

Haz que la generación de evidencias forme parte de la entrega. Exige cambios revisados, conecta las compilaciones con commits inmutables, registra quién aprobó las publicaciones en producción, conserva los resultados de pruebas y garantiza que los cambios de emergencia entren en el mismo registro después de la contención. Prueba las copias restaurándolas, no mirando el estado de la tarea. Prueba las alertas creando señales controladas. Registra las revisiones de acceso de modo que se vea que el revisor evaluó cada cuenta.

Evita un cambio total de una sola vez cuando sea difícil revertir datos o flujos de clientes. Mueve una función acotada o un grupo de clientes, obsérvalo, concilia los resultados y conserva la posibilidad de volver atrás. Los servicios antiguo y nuevo necesitan responsables explícitos mientras convivan. Duplicar controles es aceptable durante una migración corta; dejar controles ambiguos no lo es.

Una reconstrucción termina cuando se eliminan las antiguas rutas de autoridad, se aprueba la conciliación de datos, se cierran los criterios de reversión, se revocan las credenciales viejas, se retira la infraestructura anterior y la descripción del sistema coincide con producción. Publicar la nueva interfaz es un evento intermedio. Si el usuario de la base de datos antigua todavía tiene acceso amplio o una tarea heredada sigue escribiendo registros de clientes, el límite no se ha movido.

El calendario de auditoría puede imponerse al diseño más limpio

El calendario cambia cuál de las opciones técnicamente válidas resulta responsable. Antes del periodo de observación tienes margen para rediseñar controles, ejecutarlos, corregir fallos y recopilar evidencias. Durante un periodo de tipo 2, una migración importante puede cambiar la población de controles y la descripción del sistema. Cerca del trabajo de campo puede crear tareas de conciliación justo cuando el equipo necesita registros estables y responsables disponibles.

Pon cuatro fechas en una página: la fecha prevista del tipo 1 o el periodo de tipo 2, el último día seguro para un cambio arquitectónico material, la ventana de migración y las fechas de cierre o entrega de evidencias acordadas con el auditor. Añade compromisos con clientes y periodos de negocio de alto riesgo. Si nadie puede facilitar las fechas de auditoría, pausa la promesa técnica en lugar de inventar margen.

Después clasifica los cambios por su efecto en los controles. Actualizar una biblioteca detrás de las pruebas existentes puede dejar intacto el diseño del control. Trasladar los despliegues a otro proveedor cambia las fuentes de evidencia y quizá los roles de acceso. Sustituir la autenticación cambia poblaciones de usuarios, evidencias de acceso, registros, procedimientos de soporte y la descripción del sistema. La cantidad de código modificado predice mal el efecto en la auditoría.

Usa un registro de decisión corto con cuatro dimensiones puntuadas:

1. Claridad de límites: ¿puede el equipo enumerar las rutas de identidad, clientes, datos y despliegue?
2. Concentración de reparaciones: ¿pueden unos pocos componentes contener la mayoría de hallazgos materiales?
3. Continuidad de evidencias: ¿pueden los registros de control permanecer completos durante el cambio?
4. Reversibilidad de la migración: ¿puede el equipo detectar una migración defectuosa y restaurar un servicio seguro?

Puntúa cada dimensión con evidencias, no con optimismo. Un diagrama respaldado por trazas es evidencia. «El framework se ocupa» no lo es. Entrega el registro al responsable técnico, al de seguridad, al del control y al auditor para que lo cuestionen. El auditor debe orientar sobre las consecuencias para el examen, mientras la dirección conserva la responsabilidad sobre el sistema y sus controles.

Si gana la remediación, congela las refactorizaciones ajenas hasta cerrar los fallos de control y estabilizar la recopilación de evidencias. Si gana la reconstrucción, mantén contenido el servicio actual mientras el sustituto crea su historial operativo. FixMyMess puede diagnosticar una base de código generada con IA, reparar seguridad y lógica, refactorizarla o preparar una reconstrucción para el despliegue; usa una revisión experta de ese tipo para cuestionar el alcance, no para delegar las decisiones de control de la dirección.

No prometas que cualquiera de las rutas garantiza un informe limpio. Los auditores prueban lo que funcionó de verdad, y pueden surgir excepciones por personas, procesos, proveedores o evidencias aunque los controles de la aplicación funcionen. Un plan honesto reserva tiempo para encontrar controles fallidos, corregirlos y demostrar cómo operó la corrección.

El informe de decisión debe mostrar la incertidumbre

Escribe la decisión antes de comenzar la implementación. Un informe útil nombra el sistema incluido, los Criterios de Servicios de Confianza seleccionados, los hallazgos conocidos de arquitectura y datos, los fallos de control actuales, el alcance de remediación, el alcance de reconstrucción, los riesgos de migración, los efectos sobre evidencias, las fechas, los responsables, los supuestos y la condición que haría cambiar la elección. Adjunta el material de origen para que otro revisor pueda reproducir después el razonamiento.

No permitas que una sola puntuación oculte una condición decisiva. Una reconstrucción puede puntuar mal en tiempo y seguir siendo necesaria porque el aislamiento entre clientes no se puede reparar. La remediación puede puntuar bien en rapidez y seguir siendo insegura porque nadie puede delimitar el acceso privilegiado. Declara primero las condiciones decisivas y compara después coste y calendario entre las opciones viables.

Haz preguntas precisas al auditor del servicio. ¿Cambiará la migración propuesta la descripción del sistema o la población del control? ¿Qué evidencias demostrarán el funcionamiento antes y después? ¿Cómo debe describir la dirección un control que cambió durante el periodo? ¿Qué límites y organizaciones subcontratadas pertenecen al alcance? La firma de CPA debe responder para ese encargo; un panel de cumplimiento no puede tomar esas decisiones.

Haz también preguntas técnicas que los auditores no pueden responder. ¿Podemos enumerar cada ruta de escritura en producción? ¿Podemos revocar a un usuario en todas partes dentro del proceso declarado? ¿Podemos probar que un cliente no obtiene el objeto de otro cambiando un identificador? ¿Podemos restaurar datos y conciliarlos con un punto conocido? ¿Se puede rastrear un commit aprobado hasta el artefacto en ejecución? Estas respuestas determinan si las afirmaciones sobre los controles son ciertas.

La opción predeterminada debe ser el cambio más pequeño que cree un límite estable y comprobable y conserve evidencias fiables. Abandona esa preferencia cuando el sistema existente no pueda expresar quién posee los datos o quién puede actuar sobre ellos. Una fecha límite de SOC 2 es una mala razón para conservar un sistema imposible de conocer y una razón igual de mala para borrar uno que sí se conoce.