Revisado · Recursos de Hosmio
Antes de empezar
Traer un boceto de arquitectura básico, las personas responsables de la aplicación y los respaldos, y cualquier restricción del cliente. Usar categorías y ejemplos sintéticos. No poner registros reales de clientes, contraseñas, tokens de acceso o registros sin redactar en la hoja de trabajo.
01
Seguir una tarea de usuario completa.
Elegir una tarea representativa, como cargar un documento de proyecto a un portal de cliente. Rastrear dónde va la solicitud, dónde se almacenan sus metadatos, dónde termina el archivo y qué sucede después de la carga. Incluir miniaturas, procesamiento en cola, notificaciones salientes y reporte de errores cuando existan. El objetivo es describir tu implementación, no completar todas las categorías posibles.
Luego rastrear una segunda tarea que lea o exporte datos. Las exportaciones a menudo revelan copias ausentes de un diagrama de infraestructura: un archivo descargado por un operador, una integración de informes o un archivo adjunto a una solicitud de soporte. Preguntar quién controla cada destino y por qué se necesita.
02
Separar las copias persistentes del acceso.
| Registro | Propósito / rol responsable | Evidencia aún necesaria |
|---|---|---|
| Base de datos de la aplicación | Metadatos del proyecto / operador de la aplicación | País real del host y regla de retención |
| Documentos cargados | Archivos de cliente / responsable del contenido | Destino de almacenamiento y proceso de eliminación |
| Copia de recuperación | Reconstruir servicio / operador de recuperación | Ubicación del respaldo, acceso y resultado de restauración |
| Reporte de errores | Investigar fallas / responsable de incidentes | Campos exportados y organización receptora |
| Sesión administrativa | Mantener la aplicación / operador autorizado | Arreglo de acceso y proceso de auditoría |
Una fila de acceso es útil incluso cuando no crea una copia retenida intencionalmente. Registrar la organización y el proceso involucrados, qué puede ver la persona y si puede ocurrir una exportación. No sacar una conclusión legal universal de esa fila. Los criterios de transferencia del EDPB dependen de las organizaciones reales y del contexto de procesamiento. EDPB: transferencias internacionales de datos ↗
03
Etiquetar la calidad de cada respuesta.
Usar un pequeño conjunto de estados: documentado, declarado pero no verificado, desconocido, y no aplicable con una razón. Adjuntar la fuente y la fecha de revisión a la respuesta, no solo a la página que contiene la tabla. Un diagrama elaborado por tu propio equipo y un contrato proporcionado por un proveedor responden a tipos diferentes de preguntas.
Por ejemplo, tu código puede establecer que un informe de error excluye el contenido de los documentos, mientras que solo el proveedor de informes puede indicar dónde opera su almacenamiento o proceso de soporte. Mantener esas piezas de evidencia separadas. Cuando no coincidan, plantear una pregunta específica y retener el estado no resuelto hasta que se aborde el conflicto.
04
Dar a cada copia un responsable y una condición de finalización.
Para cada copia persistente, registrar por qué existe, cuánto tiempo la necesita el proyecto, quién controla la eliminación y qué sucede cuando finaliza el servicio. Una copia de recuperación puede ser necesaria y aun así requerir un proceso de retención definido. «Respaldado» no es una respuesta completa a si los datos antiguos pueden eliminarse o cuánto tiempo permanecen recuperables.
Verificar también las exportaciones rutinarias. Si un operador descarga un archivo para investigar un problema, el equipo debe saber dónde se guarda y cuándo se elimina. Referirse a evidencia protegida en lugar de incrustar el archivo en el mapa. El registro en sí debe seguir siendo útil sin exponer los datos que describe.
05
Resolver un mapa de portal incompleto.
En una revisión ilustrativa, el operador de la aplicación puede explicar el almacenamiento de producción y las exportaciones programadas, pero el destino del respaldo se enumera simplemente como «respaldo del proveedor». El operador de recuperación solicita el alcance del destino, las reglas de acceso y un procedimiento de restauración real. Hasta que se proporcionen, la fila permanece desconocida y la decisión del país sigue siendo condicional.
Mientras tanto, se descubre que una integración de reporte de errores incluye URL de solicitud completas. El equipo revisa si esas URL pueden contener identificadores de proyecto, actualiza su inventario de campos y pide al contacto del cliente que evalúe el flujo de datos modificado. No se infiere ningún resultado de país o cumplimiento de este ejemplo; muestra cómo el mapa puede exponer una pregunta concreta sin responder.
06
Verificar la completitud y mantener el mapa.
Hacer que el operador de respaldo y el mantenedor de la aplicación recorran de forma independiente una restauración y una investigación de incidentes. Preguntar dónde obtiene datos cada paso y quién puede acceder a ellos. Si cualquiera de los procesos utiliza un destino que falta en la hoja de trabajo, agregarlo y asignar un responsable para los hechos restantes.
Un mapa utilizable termina con una breve lista de elementos abiertos, cada uno vinculado a un rol responsable y a una decisión que afecta. Revisarlo después de agregar integraciones, cambiar la política de respaldo, otorgar una nueva ruta administrativa o mover regiones. Usar la matriz de decisión de alojamiento para evaluar los hechos resultantes y la guía de aprobación de cambios cuando cambie el arreglo.
Esta hoja de trabajo organiza evidencia operativa para los asesores del proyecto. No establece la ley aplicable, no autoriza una transferencia ni certifica la residencia de datos. El país del servidor seleccionado no establece la ubicación de los respaldos, los datos exportados o el acceso administrativo.