Auditoría de arquitectura frente a due diligence técnica

01El mandato cambia la evaluación

Auditoría de arquitectura

Suele encargarse para entender un sistema, evaluar un enfoque o priorizar cambios. Defina qué evidencia de arquitectura, código y operación se incluye y qué hallazgos escritos necesita el equipo.

Due diligence técnica

Se encarga en torno a una transacción. Defina las preguntas del comprador, los sistemas objetivo, los límites de acceso y la audiencia del reporte. Vincule las observaciones técnicas con los riesgos y los supuestos sin resolver que son relevantes para esa transacción.

Sesión de revisión enfocada

Un punto de partida más acotado cuando una decisión o una parte del sistema necesita atención. No reemplaza una evaluación con alcance definido de un código o de una transacción.

Un reporte largo no prueba una evaluación amplia. Un reporte corto no es necesariamente superficial. La pregunta útil es si el trabajo examinó la evidencia necesaria para la decisión que motivó el encargo y si identifica con claridad lo que no pudo verificar.

02Pregunte en qué se basa cada conclusión

Pida que se distinga entre el comportamiento observado, la documentación proporcionada, las entrevistas y las inferencias. Un diagrama puede describir un sistema previsto sin probar que producción coincide con él. Una prueba que pasa solo respalda el comportamiento que realmente ejercita. Un artefacto que falta debe seguir siendo una pregunta abierta hasta que se investigue.

El Secure Software Development Framework v1.1 del NIST describe prácticas y un vocabulario común que los compradores pueden usar en sus conversaciones con los proveedores. Puede orientar las preguntas sobre las prácticas de desarrollo; citarlo no convierte una evaluación en una certificación de seguridad. NIST SP 800-218: SSDF v1.1 (2022).

Para su alcance, identifique qué afirmaciones afectan de manera importante la decisión y qué evidencia las respaldaría. El acceso al código por sí solo puede no responder preguntas sobre el despliegue, el manejo de incidentes, las dependencias de proveedores o las personas necesarias para operar el sistema.

03Defina el alcance antes de encargar el trabajo

• Decisión y audiencia: ¿quién encarga el trabajo, quién lo recibe y qué decisión debe respaldar?
• Límite: ¿qué productos, repositorios, entornos e integraciones se incluyen o se excluyen?
• Evidencia y acceso: ¿qué se puede inspeccionar, quién puede responder preguntas y qué no está disponible?
• Entregable: ¿qué hallazgos, referencias a la evidencia, prioridades y preguntas sin resolver deben registrarse?
• Plazos: ¿cuándo estará disponible la evidencia y qué pasa si el acceso llega tarde?
• Seguimiento: ¿quién puede aclarar los hallazgos, y la remediación o la investigación adicional tienen un alcance aparte?

En una transacción, acuerde también con los asesores correspondientes la confidencialidad, los destinatarios permitidos y el manejo de la información de terceros. Los hallazgos técnicos contribuyen a la decisión; no reemplazan la asesoría legal o financiera ni garantizan el resultado de una inversión.

04Compare las propuestas por cobertura y límites

Compare las propuestas con el mismo brief. Compare los sistemas cubiertos, el acceso a la evidencia, los entregables, las exclusiones y el enfoque ante la incertidumbre. Pregunte cómo aparecerá en el reporte una afirmación no verificada. Si alguien garantiza descubrir todos los defectos o un diagnóstico limpio incondicional, tómelo como una razón para aclarar qué se está prometiendo realmente.

Para un sistema existente y una decisión de mejora, revise la oferta de Auditoría de arquitectura. Para una inversión o una adquisición, revise Due diligence técnica. Ambos proyectos de Robles Consulting tienen un alcance definido por separado; sus precios publicados son puntos de partida, con el alcance y la entrega acordados antes de comenzar el trabajo. Ninguno es un pago inmediato.