--- title: "Auditoría técnica: qué mira y cómo prepararla" description: "Qué revisa una auditoría técnica antes de una ronda o una compra: propiedad del código, de quién dependes, los datos, el dinero y poder cambiarlo." canonical: https://caricalia.com/notas/auditoria-tecnica-antes-de-una-inversion last-updated: 2026-09-29 --- # Auditoría técnica: qué mira y cómo prepararla > Una due diligence técnica no puntúa tu código: mide qué riesgo compra quien entra. Estos son los sitios donde mira y lo que se puede preparar antes. Publicado: 2026-09-09 · Actualizado: 2026-09-29 Autor: carlos Temas: arquitectura, diagnóstico --- ## Qué es una auditoría técnica de software Una auditoría técnica de software es la revisión del sistema de una empresa por alguien de fuera, hecha para medir qué riesgo asume quien va a entrar: un inversor antes de una ronda, un comprador antes de una compra o un cliente grande antes de firmar. No pone nota al código. Mira cinco cosas —de quién es el código, de cuántas personas depende, cómo se tratan los datos, qué pasa con el dinero que atraviesa el sistema y cuánto cuesta cambiarlo— y termina en un informe con cada hallazgo ordenado por lo que cuesta arreglarlo. Es una de las situaciones que trabajamos sobre sistemas en producción, dentro de [software a medida](/software-a-medida), y más abajo hay una lista para prepararla que puedes copiar. ## Una auditoría mide el riesgo que compra quien entra Una auditoría técnica antes de una ronda, de una compra o de la firma de un cliente grande no existe para poner nota a tu sistema. Existe para responder a una pregunta: si esto sale mal, cuánto cuesta y quién lo paga. Las preguntas que se hacen durante la revisión cuelgan de ahí. Entenderlo cambia cómo te preparas. Un sistema con deuda técnica reconocida, documentada y con un plan de plazos pasa mejor que uno sin deuda conocida del que nadie sabe explicar cómo se despliega. Si un inversor, un comprador o un cliente grande va a mirar dentro y no hay nada preparado, esta es tu situación. Es una de las cinco por las que nos llaman, y suele llegar con fecha puesta. ## Los cinco sitios donde mira **Propiedad y procedencia del código.** Quién es dueño de lo que se ha construido. Si hubo proveedores externos, si el contrato cedía los derechos, si el repositorio está a nombre de la empresa o de la cuenta personal de alguien. Aquí también entra el inventario de licencias de las dependencias, porque una licencia contagiosa dentro de un producto que se vende cerrado es un problema legal, no técnico. Desde que parte del código se genera con asistentes, esta pregunta se ha vuelto más frecuente y más incómoda. Se responde con procedencia y con revisión, no negando que se use. **De cuántas personas depende esto.** Cuántas personas pueden desplegar. Cuántas entienden la parte por la que pasa el dinero. Qué pasa si mañana no está la que lleva más tiempo. Un sistema que solo una persona sabe tocar no es un activo estable, y quien invierte lo comprueba mirando quién ha escrito cada parte. Está contado en [un sistema legacy es código sin dueño](/notas/sistema-legacy-codigo-sin-dueno), y qué hacer en treinta días en [software que depende de una sola persona](/notas/software-depende-de-una-persona). Si el código lo escribió un proveedor, los contratos y las cesiones están en [cambiar de proveedor de software: qué pedir](/notas/cambiar-de-proveedor-de-software). **Los datos.** Dónde están, quién puede leerlos, qué se guarda de personas y con qué base legal, cuánto se conserva y qué pasa si alguien pide que se borren. Y la pregunta que más veces se queda sin respuesta buena: cuándo fue la última vez que se restauró una copia de seguridad de verdad, no cuándo se hizo. Una copia que nunca se ha restaurado no está comprobada. **El dinero, si pasa por tu sistema.** Si cobras, facturas o concilias con software propio, esa parte se mira aparte y con lupa. Que los ingresos declarados cuadren con el banco. Que las facturas no tengan huecos de numeración ni se puedan modificar después de emitidas. Que el cumplimiento fiscal esté donde tiene que estar, que en España pasa por lo que exige [Verifactu](/glosario/verifactu). Reconstruir dos años de [conciliación bancaria](/glosario/conciliacion-bancaria) durante una due diligence sale caro y llega tarde. **La capacidad de cambiar.** Se mide por lo que tarda un cambio pequeño en llegar a producción y por lo que se rompe cuando llega. Se mide con hechos: cómo se despliega, si vuelve atrás solo cuando falla, qué se comprueba de forma automática y qué se comprueba mirando. Un sistema donde cada cambio cuesta más que el anterior es un sistema cuyo plan de producto no se puede cumplir, y eso es lo que un inversor está comprando. ## Qué cambia según quién pregunta Las cinco áreas son las mismas. Lo que cambia es el peso que le da cada uno y qué documento espera ver. | Quién mira | Lo que más pesa | Qué suele pedir | |---|---|---| | Inversor antes de una ronda | Que el producto pueda crecer sin reescribirse, y de cuántas personas depende | Documento de arquitectura, inventario de accesos, lista de deuda técnica | | Comprador antes de una adquisición | Propiedad del código y del dato, y contratos con terceros | Cesiones de derechos, licencias de las dependencias, contratos de proveedores | | Cliente grande antes de firmar | Seguridad, protección de datos y qué pasa si el sistema cae | Cuestionario de seguridad, política de copias de seguridad, contrato de tratamiento de datos | | Tu propia empresa antes de invertir en el sistema | Cuánto cuesta cambiarlo y qué se rompe primero | Un informe con hallazgos ordenados por coste | ## Qué dicen las normas de lo que se pregunta Tres bloques de la revisión tienen texto legal detrás, y conviene saber cuál para llevar el documento correcto. - **Propiedad del código.** Los derechos de explotación de un programa hecho por un proveedor externo solo pasan a quien lo encarga con una cesión por escrito, que se limita a lo pactado (artículos 43 y 45 de la [Ley de Propiedad Intelectual](https://www.boe.es/buscar/act.php?id=BOE-A-1996-8930)). Si lo creó un empleado en el ejercicio de sus funciones, es de la empresa salvo pacto en contrario (artículo 97.4). - **Datos personales.** El proveedor que trata datos por cuenta de la empresa es un encargado, y el [artículo 28 del Reglamento general de protección de datos](https://www.boe.es/buscar/doc.php?id=DOUE-L-2016-80807) exige un contrato entre los dos. En España se complementa con la [Ley Orgánica 3/2018](https://www.boe.es/buscar/act.php?id=BOE-A-2018-16673). - **Facturación.** Si el sistema emite facturas, el [Real Decreto 1007/2023](https://www.boe.es/buscar/act.php?id=BOE-A-2023-24840) fija los requisitos que deben cumplir los sistemas informáticos de facturación. ## Cómo se comporta la conversación Un auditor no te va a pedir el código y ya está. Va a pedir que alguien le cuente una decisión y luego va a ir a comprobarla. Las respuestas que sostienen esa comprobación son las escritas: por qué se eligió esta arquitectura, qué se descartó, qué se sabe que está mal y qué plazo tiene. Lo que complica una auditoría es la sorpresa: encontrar algo que el equipo no había mencionado. A partir de ahí se revisa con más detalle todo lo demás. Por eso conviene entregar tú mismo la lista de lo que está mal, con su tamaño y su orden. ## Qué se puede preparar antes, y en cuánto tiempo En dos o tres semanas se puede tener casi todo lo que se pide. Un documento corto de arquitectura con las tres o cuatro decisiones que explican el sistema, y lo que se descartó. El inventario de servicios, cuentas, dominios y licencias, con quién es el titular de cada uno. Una restauración de copia de seguridad hecha de verdad, con la fecha apuntada. La lista de accesos, con las bajas de gente que ya no está. Y el registro de deuda técnica conocida, con tamaño y prioridad. Eso mismo es lo que hace falta para que el sistema deje de depender de quien lleva más tiempo. Las decisiones y el marco de entrega están tratados en [tres decisiones de arquitectura](/notas/arquitectura-tres-decisiones). ## Checklist de due diligence técnica, para copiar Copia el bloque, pégalo en tu gestor de tareas y marca cada línea con fecha y nombre. Una línea marcada es una línea que has comprobado tú, no una que «te han dicho». Lo que no puedas marcar es lo que hay que preparar antes de la fecha. ```text DUE DILIGENCE TÉCNICA: LISTA PARA PREPARARLA 1. Propiedad y procedencia del código [ ] Repositorio a nombre de la empresa, no de una cuenta personal [ ] Contratos con desarrolladores, autónomos y agencias: cesión de derechos por escrito [ ] Alcance, plazo y territorio de cada cesión revisados [ ] Inventario de dependencias con su licencia [ ] Ninguna licencia incompatible con cómo se distribuye el producto [ ] Código generado con asistentes: quién lo revisó y con qué criterio 2. Dependencia de personas [ ] Personas que pueden desplegar a producción, con nombre [ ] Personas que entienden la parte por la que pasa el dinero, con nombre [ ] Qué pasa si falta la persona que lleva más tiempo, escrito [ ] Prueba de relevo hecha: alguien ajeno hace un cambio real con solo el repositorio 3. Accesos y cuentas [ ] Lista de cuentas (alojamiento, dominio, correo, pagos, analítica) con su titular [ ] Gestor de contraseñas de la empresa en uso [ ] Bajas de personas que ya no están, hechas [ ] Doble factor activado en las cuentas críticas 4. Datos [ ] Dónde se guarda cada dato personal y quién puede leerlo [ ] Base legal y plazo de conservación de cada tipo de dato [ ] Contratos de encargado del tratamiento con cada proveedor que toca datos [ ] Procedimiento para atender la petición de borrado de un usuario [ ] Última restauración real de una copia de seguridad, con fecha 5. Dinero y cumplimiento [ ] Los ingresos del sistema cuadran con el banco [ ] Numeración de facturas sin huecos y sin posibilidad de modificar las emitidas [ ] Cumplimiento fiscal de facturación revisado contra la norma vigente [ ] Qué pasa cuando una operación falla a medias, comprobado provocando el fallo 6. Capacidad de cambiar [ ] Cómo se despliega un cambio, documentado y probado por otra persona [ ] Cómo se vuelve atrás cuando un despliegue sale mal [ ] Comprobaciones automáticas: qué cubren y qué no [ ] Tiempo que tarda un cambio pequeño en llegar a producción, medido [ ] Avisos automáticos cuando algo falla 7. Seguridad y continuidad [ ] Quién ha revisado la seguridad del sistema y cuándo [ ] Qué se guarda en los registros y durante cuánto tiempo [ ] Plan por escrito si el sistema cae: quién avisa a quién [ ] Proveedores críticos y qué pasa si uno desaparece 8. Documentación [ ] Documento de arquitectura: cómo está montado, en una página [ ] Decisiones con su fecha y lo que se descartó [ ] Registro de deuda técnica conocida, con tamaño y prioridad [ ] Inventario de servicios de terceros, con coste y renovación ``` ## Si la fecha ya está puesta Cuando la auditoría tiene fecha y no hay nada preparado, la prioridad es saber qué van a encontrar antes de que lo encuentren. Eso es lo que hace un [diagnóstico](/diagnostico). Tres semanas leyendo el código y hablando con quien usa el sistema, y un informe con qué falla, qué cuesta arreglarlo y en qué orden. Tiene precio cerrado; el proyecto que suele venir después se cierra por fases, con el precio de cada fase por escrito antes de empezar. El informe es tuyo, y sirve para llegar a la revisión con la lista escrita y también para decidir que este año no toca. Si el trabajo es reescribir la parte que no aguanta, eso es [software a medida](/software-a-medida). ## Preguntas frecuentes ### ¿Qué es una due diligence técnica? La revisión del sistema y del equipo técnico de una empresa por alguien de fuera, antes de una inversión, una compra o un contrato grande. Mide el riesgo que asume quien entra: de quién es el código, de cuántas personas depende, cómo se tratan los datos, qué pasa con el dinero y cuánto cuesta cambiarlo. ### ¿Qué documentos piden en una auditoría técnica de software? Los más habituales son un documento de arquitectura, el inventario de cuentas y accesos con su titular, los contratos con desarrolladores y proveedores (con la cesión de derechos), el inventario de licencias de las dependencias, la política de copias de seguridad y el registro de deuda técnica conocida. ### ¿Cuánto tiempo hace falta para preparar una due diligence técnica? Con dos o tres semanas se puede tener casi todo lo que se pide, si se empieza por lo que no se puede reconstruir rápido: los accesos, la restauración real de una copia de seguridad y los contratos. Con menos aviso, la prioridad es saber qué van a encontrar antes de que lo encuentren. ### ¿Se puede pasar una auditoría técnica si hay deuda técnica? Sí. Un sistema con deuda reconocida, con tamaño y plan de plazos, pasa mejor que uno sin deuda conocida del que nadie sabe explicar cómo se despliega. Lo que complica una auditoría es la sorpresa, no la deuda. ### ¿Quién puede hacer una auditoría técnica de mi software? Alguien independiente de quien lo construyó, que lea el código y hable con quien lo usa. Puede ser el inversor o comprador con su propio equipo, o tú mismo adelantándote con un tercero, que es el caso del diagnóstico: precio cerrado, tres semanas y el informe es tuyo.