Imagina que firmaste la carta de intención hace tres semanas y el cierre está en el calendario. Tu equipo de ingeniería está ocupado preparando el data room, tu CFO is fielding finance questions, and your lawyers are stress testing the purchase agreement. Then the buyer’s technical auditors arrive for M&A due diligence and, within 72 hours, file findings that put the agreed price back on the table.
Esto ocurre con más frecuencia de lo que nadie quiere admitir, y es totalmente prevenible con una auditoría de software oportuna. Según la Encuesta de Tendencias de M&A 2025 de Deloitte, el 79% de los líderes corporativos y el 87% de los de capital privado esperan que el volumen de operaciones siga aumentando este año, lo que significa que más compradores están ejecutando estas auditoríasore often and with sharper questions. Sadly, most sellers learn what those questions actually are about a week too late.
Escribimos esta guía porque casi todas las listas de verificación de due diligence tecnológica en M&A que circulan por internet parecen folletos de marketing de las Big Four: largas listasts, vague categories, and nothing about what the auditor on the other side of the table actually opens first when the data room goes live. So this is not as much an article as a test plan a buyer’s technical auditor really runs in those first three days, the standards they score the target against, and the three findings that most often reset the deal price.
Si eres el vendedor, léelo como tu ensayo general. Si eres el comprador, léelo como una verificación de si tu propio equipo está haciendo las preguntas correctas questions in the right order.
Qué Comprueban los Compradores en M&A Durante la Due Diligence Técnica
Aquí está la respuesta directa, porque eso es lo que viniste a buscar:
Durante la due diligence técnica, los compradores comprueban cuatro cosas, aproximadamente en este orden: cómo desarrolla software la empresa objetivo, qué posee legalmente, cómo protected the software is, and how fragile the architecture is. Everything else in a typical M&A due diligence checklist is supporting evidence for these four questions.
Lo que cambia la conversación, sin embargo, es que el auditor no entra con la mente abierta. Entra con tres estándares de referencia abiertosnt of them. The first is the NIST Secure Software Development Framework, que define el desarrollo disciplinado de software. El segundo es el Software Assurance Maturity Model de OWASP, que puntúa cuán madura es cada una de esas prácticas en el mundo real. El tercero es ISO/IEC 27001, el estándar internacional para la gestión de la seguridad de la información, que confirma si alguien en la empresa objetivo es genuinamente responsable de of it.
Juntos, esos tres marcos se convierten en una tarjeta de puntuación:
- NIST le dice al auditor qué buscar
- OWASP SAMM mide qué tan bien lo está haciendo la empresa objetivo
- ISO 27001 verifica que alguien sea responsable del resultado
Los vendedores que entran a la due diligence sin saber que serán medidos contra estos tres se ven tomados por sorpresa.
Los vendedores que entran a la due diligence sin saber que serán medidos contra estos tres se ven tomados por sorpresa.
Por Qué las Primeras 72 Horas de la Due Diligence en M&A Determinan la Renegociación del Precio
Un proceso típico de due diligence en M&A dura entre 30 y 60 días. Sin embargo, los hallazgos que mueven el precio emergen en los días uno a tres. Eso es porquese of how auditors actually work.
- El primer día es el triaje de documentos.
- El segundo día es el análisis forense del código en sí.
- El tercer día es cuando el auditor se reúne con el responsable de ingeniería para hacer las preguntas que los documentos no pudieron responder.
Al final del tercer día, el equipo de negociación del comprador tiene una tarjeta de puntuación preliminar, y esa tarjeta es la que moldea cada conversación posterior. Si elfirst 72 hours produce confidence, the rest of the diligence period is mostly verification. However, if they produce doubt, the rest is renegotiation.
Hay tres hallazgos, en particular, que vemos que restablecen el precio casi siempre. Entraremos en detalle más adelante, pero aquí está la versión corta. First, gaps in who actually owns the code. Second, change records that fall apart when you look back three years. Third, undocumented pieces of software the business depends on but cannot afford to lose. Each of these cleanly maps to one of the three reference standards, and each one signals to a buyer that the headline valuation may not survive contact with reality.
El Plan de Pruebas de 72 Horas, Hora por Hora
Esto es lo que podemos concluir de nuestra experiencia en consultoría de due diligence en M&A, expresado en un lenguaje sencillo que los no ingenieros y los auditores pueden entenderderstand. In writing the following plan, we used both our experience with such projects and current regulations.
Horas 0 a 24: Triaje de Documentos y Mapeo de Estándares
El primer día es papeleo. El auditor quiere ver rápidamente si la empresa objetivo tiene los artefactos que una organización de software madura debería tener disponibles. The list usually includes:
- Políticas de desarrollo
- Registro de propiedad intelectual
- Lista completa de cada componente de software de terceros que utiliza el producto (software bill of materials, o SBOM)
- Matriz de control de acceso para repositorios de código
- Los dos últimos informes de prueba de penetración
- Historial de incidentes de seguridad de tres años
El auditor todavía no lee estos documentos en detalle. Más bien, comprueba su presencia y vigencia. Por ejemplo, un informe de pentest de hace 18months ago is a yellow flag, but no pentest report at all is a red one. An SBOM that was generated last week, just for the data room, signals that nobody has been paying attention to dependency risk until now.
Cada artefacto se mapea entonces a los tres estándares de referencia. NIST agrupa las prácticas en cuatro categorías: Preparar la Organización, Proteger el Software, Produce Well-Secured Software, and Respond to Vulnerabilities. The auditor checks which of those buckets has supporting evidence and which has only verbal assurances. OWASP SAMM assigns each practice a maturity score from 0 to 3. ISO 27001 maps policies to specific Annex A controls and asks whether they are implemented or only documented.
Al final del primer día, el auditor tiene un mapa de calor. Verde donde la empresa objetivo está bien preparada, amarillo donde la evidencia es escasa, rojo donde no hay nadaat all. This is also the day on which our auditors have historically caught the most serious issues for our clients, simply because the heat map exposes how the target really works in 24 hours, not 24 days.
Horas 24 a 48: Análisis Forense de Código y Repositorios
El segundo día es cuando el auditor realmente toca el código, o más precisamente, los registros alrededor del código. El objetivo aquí es verificar que lo que la empresay says it owns matches what the code repository says happened.
La primera tarea es comprobar quién escribió qué. El auditor extrae el historial de commits y concilia a cada colaborador con los acuerdos de asignación de PIsigned by employees and contractors. Therefore, if a freelancer in 2021 committed a meaningful chunk of the core product but the company cannot produce a signed agreement transferring ownership, the buyer now has a problem. The same applies to code suggested or generated by AI tools, which is why buyers in 2026 are suddenly asking very specific questions about how the engineering team uses them.
La segunda tarea en una lista de verificación de due diligence en M&A es la concesión de licencias. El SBOM del primer día se compara ahora con el contenido real de la base de código. The auditor is hunting for two things:
- Componentes de código abierto utilizados bajo licencias que contaminan el código propietario que los rodea y pueden efectivamente obligar a la empresa a publicar su propiosource code.
- Librerías comerciales sin licencia o con licencia caducada que nadie notó porque el desarrollador original se fue hace dos años.
Una exhaustiva revisión de código a menudo saca a la luz estos problemas semanas antes de lo que lo haría el auditor de un comprador, por eso los vendedores que planifican con anticipación realizan su propio análisis antes de que se abra el data room.
La tercera tarea en la lista de verificación de due diligence técnica del auditor es reconstruir el rastro de gestión de cambios. Recorren el repository for the last three years and ask a simple question: for any given change to production, can I trace it from the original ticket to the pull request to the commit to the deployment?
Si la respuesta es sí para la mayoría de los cambios, la empresa está en buena forma. Sin embargo, si la respuesta es no, o si hay grandes vacíos, pushes forzados a la rama principaln branch, or commits that bypass review, that is a finding the buyer takes very seriously.
La cuarta tarea en la due diligence en M&A es mapear las dependencias. El auditor busca componentes de los que depende el negocio pero que no puede gestionar fácilmentesily replace. Such examples could be a library maintained by a single volunteer who has not committed to it in two years, or a runtime version that the vendor stopped supporting last quarter. These are the silent points of failure that show up in post-merger budgets as eight-figure surprises.
Horas 48 a 72: Validación de Procesos y Personas
El tercer día es el día humano de la due diligence técnica. El auditor se sienta, generalmente durante varias horas, con el responsable de ingeniería y un pequeño grupoful of senior contributors. The goal is to confirm that the picture from days one and two matches what the people building the software actually do.
La conversación sigue un arco familiar. El modelado de amenazas surge primero porque el auditor quiere saber si la seguridad es algo que el equipo designs in or bolts on at the end. Incident response comes next, with the auditor asking the engineering lead to walk through the most recent serious incident from start to finish. The way that the story is told reveals more than any policy document. Then comes key-person risk, where the auditor asks, very politely, what would happen if a particular engineer were to leave next week. The honest answers are often uncomfortable.
Al final del tercer día, el auditor cierra el portátil, escribe un resumen de una página para el equipo de negociación, y la negociación comienza a cambiar según lo que is in it.
Hallazgos Basados en Estándares de Due Diligence en M&A que Renegocian los Precios
A continuación, explicaremos los tres hallazgos más comunes de los auditores que afectan inmediatamente al precio de la operación. También compartiremos perspectivas from our M&A due diligence consulting experience on how to address such issues if they arise. However, the easiest way to avoid problems at this stage of your deal is to conduct an audit on your side before the buyer’s technical due diligence team arrives.
Hallazgo Uno: Brechas de Procedencia de Propiedad Intelectual
Procedencia simplemente significa prueba de dónde vino algo. En la due diligence de M&A, las brechas de procedencia de PI significan que la empresa no puede probar completamente que poseewns the code it is selling.
Esto se manifiesta de formas específicas:
- Contratistas que construyeron partes significativas del producto sin firmar un acuerdo de cesión de PI.
- Componentes de código abierto utilizados de formas que violan los términos de la licencia.
- Código generado por herramientas de IA sin ningún registro de qué prompts produjeron qué resultado.
- Código adquirido en una operación anterior para el que nadie puede encontrar la documentación de transferencia original.
La práctica PS.3 del NIST SSDF, que aborda el archivado y la protección de cada versión, requiere que la empresa mantenga un registro claro de cada artefacto enach release. ISO 27001 control A.5.32 requires explicit protection of intellectual property rights. Therefore, when a buyer’s auditor cannot reconcile the code with the contracts, the response is predictable. Indemnity carve-outs in the purchase agreement get larger. Escrow holdbacks increase, and in serious cases, the headline price is reduced by 5% to 15%, sometimes more if the contaminated code is in the core product.
Para los vendedores, este es el más fácil de los tres hallazgos de corregir con antelación, pero solo si se empieza al menos 60 días antes de que se abra el data room.
Hallazgo Dos: Registros de Gestión de Cambios que No Superan una Revisión de Tres Años
El segundo hallazgo trata sobre la historia de la empresa, no su presente. Los compradores quieren mirar atrás tres años en el sistema de control de código fuente y ver exactamentehow any given change in production got there. This includes who proposed it, who reviewed it, who approved it, and who deployed it.
Cuando ese rastro es sólido, el comprador tiene la seguridad de que la cultura de ingeniería es disciplinada y de que la base de código probablemente no contenga sorpresas ocultasises. However, if the trail is patchy, the auditor starts looking for what else might be missing. Common patterns that fail this test include:
- Despliegues manuales sin el ticket correspondiente
- Pushes forzados que borran el historial
- Ramas que nunca estuvieron protegidas
- Revisiones de código realizadas por la misma persona que escribió el código
- Largos periodos de tiempo durante los cuales no se registró absolutamente nada
La práctica PS.1 del NIST SSDF espera un control claro sobre todas las formas de código y documentación de soporte. La práctica de construcción segura de OWASP SAMM espera que cadachange to be reproducible and traceable. ISO 27001 control A.8.32 requires formal change management. When all three are weak, the buyer responds with what is essentially an integration risk premium. Mandatory pre-close remediation, an extended escrow, or a portion of the purchase price moved into a deferred earn-out tied to engineering hygiene improvements.
Este es el hallazgo que toma por sorpresa a la mayoría de las empresas, porque el equipo de ingeniería generalmente cree que sus prácticas de higiene están bien hasta que alguien realmentey looks.
Hallazgo Tres: Dependencias de Ruta Crítica no Documentadas
El tercer hallazgo es el más caro de corregir después de que se cierra la operación, por eso es el que más les importa a los compradores.
Cada producto de software moderno depende de docenas o cientos de fragmentos de código escritos por otras personas. Algunos de esos fragmentos están bien mantenidos ydely used, and others are fragile. The dangerous ones are the dependencies that the business cannot run without, but that nobody in the company actively monitors. This usually includes:
- Una librería mantenida por un único voluntario en otro país
- Un microservicio que silenciosamente llama a la cuenta personal en la nube de un desarrollador
- Un archivo de configuración con credenciales secretas que no se han rotado desde 2022
- Una tarea programada en un servidor que nadie del equipo actual configuró
La práctica PW.4 del NIST SSDF espera que la empresa reutilice únicamente componentes de software bien protegidos. La práctica de dependencias de software de OWASP SAMM espera monitoreo continuous monitoring of all external code in use. ISO 27001 control A.8.30 requires explicit oversight of outsourced development and third-party code. If a buyer’s auditor finds a critical-path dependency that nobody can explain, the response is rarely a price cut. Instead, it’s a longer transition services agreement, retention bonuses for the engineers who do understand the dependency, and a reserve fund set aside specifically to migrate or replace the fragile component after closing.
El mantenimiento de software constante y continuo es el seguro más barato contra este hallazgo, porque obliga a la empresa a mantener un inventario honesto de aquello de lo que realmente depende su software.
Cómo los Vendedores Pueden Auto-Evaluarse Antes de que Llegue el Comprador
Si estás a entre 30 y 90 días de firmar una LOI, todavía tienes tiempo de arreglar más de lo que crees implementando el siguiente principio sencillo: ejecutan the same test plan on yourself that the buyer’s team will run on you.
Extrae los mismos artefactos, puntúalos frente a los mismos estándares y compara lo que encuentras con los tres hallazgos anteriores. El ejercicio requiere un pequeño team about two weeks if everything is in reasonable shape, and four to six weeks if it is not. In our experience, there are five fixes that move the most score in the least time.
- Firma acuerdos de cesión de PI con cada contratista activo y documenta la cadena de propiedad para cada commit.
- Regenera el software bill of materials y reconcílialo con la base de código, corrigiendo cualquier violación de licencia.
- Activa la protección de ramas en el repositorio principal y exige que todos los cambios pasen por una revisión documentada.
- Haz un inventario de cada dependencia de terceros en producción e identifica las tres o cuatro que representan el mayor riesgo.
- Escribe en lenguaje sencillo qué haría el equipo de ingeniería si una persona clave se fuera mañana.
Estas correcciones no harán desaparecer todos los hallazgos, pero demostrarán al auditor del comprador que la empresa sabe dónde están sus debilidades yd is taking them seriously, which often matters more than the underlying findings themselves.
Si prefieres que un equipo independiente te evalúe antes de que se abra el data room, eso es exactamente lo que hace nuestra práctica de servicios de auditoría de software.are services practice does. We use the same scorecard that the buyer’s team will use, and we tell you in two weeks what they would tell the buyer in three. So, contáctanos hoy, y continuamos desde ahí.
Para un recorrido más profundo del marco que usamos en todas nuestras auditorías, consulta nuestra publicación sobre la Lista de Verificación de Auditoría del SDLC, que cubre el mismo terreno desde la perspectiva del equipo de desarrollo. Y recuerda, si hay una cosa que esperamos que te lleves de este artículo, est is that the buyer’s auditor is not trying to catch you out. They are trying to confirm that the price on the term sheet matches the company’s inside. The faster you can demonstrate that it does, the faster you close. The longer they have to look, the more they find.
FAQ
¿Qué contiene una lista de verificación de due diligence técnica?
Una lista de verificación de due diligence técnica cubre cuatro áreas:
- Proceso de desarrollo de software
- Propiedad intelectual y licencias
- Seguridad y gobernanza de datos
- Riesgo de arquitectura y dependencias
El auditor del comprador evalúa la evidencia de la empresa objetivo en cada área frente a tres estándares de referencia: NIST SSDF, OWASP SAMM e ISO 27001. Los elementos específicoss include the SBOM, IP assignment agreements, change-management records over a three-year lookback, pentest, incident logs, the access control matrix, and an inventory of third-party dependencies.
¿Cuánto tiempo lleva la due diligence técnica en M&A?
Un proceso completo de due diligence en M&A suele durar entre 30 y 60 días, con operaciones más grandes o transfronterizas que se extienden 90 días o más. Los hallazgos que influyence the deal price, however, are typically identified in the first 72 hours of the technical workstream, when the auditor reviews documents, performs code repository forensics, and interviews the engineering lead.
¿Quién realiza la due diligence técnica en M&A?
Para operaciones grandes, una firma externa de auditoría de software o una consultoría especializada en M&A generalmente lidera el trabajo técnico, con apoyo del equipoh support from the buyer’s internal CTO or head of engineering. For smaller deals, the buyer’s internal technical team often runs it directly. Sellers increasingly hire their own external auditor in advance to score themselves before the buyer’s team arrives, which gives them time to fix issues that would otherwise reset the price.
¿Cuál es la diferencia entre una auditoría del SDLC y la due diligence técnica en M&A?
Una auditoría del SDLC mira hacia adentro y ayuda a una empresa a mejorar su propio proceso de desarrollo de software. Mientras tanto, la due diligence técnica en M&A mira hacia afueraand helps a buyer decide what a target company is actually worth. The two share a lot of the same evidence, namely code repositories, development policies, security records, and dependency inventories, but they ask different questions. The SDLC audit asks how to improve the team, and the M&A audit asks whether to pay full price.
¿Qué es la due diligence cibernética en M&A y en qué se diferencia de la due diligence técnica?
La due diligence cibernética en M&A se centra específicamente en la postura de ciberseguridad, incluyendo el historial de brechas, la gestión de identidad y acceso, la protección de datos,and regulatory compliance. Technical due diligence is broader and includes cyber due diligence as one of its four pillars, alongside development process, intellectual property, and architecture. For most software acquisitions, the two workstreams are run in parallel, and findings often overlap.
¿Puede un vendedor autoevaluarse antes de que comience la due diligence?
Sí, y los vendedores que lo hacen bien están notablemente mejor posicionados en la negociación. El ejercicio consiste en ejecutar el mismo plan de pruebas que el equipo del comprador will run, scoring the results against NIST SSDF, OWASP SAMM, and ISO 27001, and prioritizing the fixes that close the biggest gaps in the time available. The window that matters most is 60 to 90 days before the LOI is signed, because that is enough time to remediate the issues that most often re-price deals.
Descubre cómo realizamos una auditoría en una app de mapeo de redes, comprobando la salud de la base de código y la seguridad
