M&A-Due-Diligence-Checkliste: Was Auditoren des Käufers in den ersten 72 Stunden testen

Stellen Sie sich vor, Sie haben vor drei Wochen das Letter of Intent unterzeichnet, und der Abschluss steht im Kalender. Ihr Engineering-Team ist damit beschäftigt, den Datenraum vorzubereiten, Ihr CFO beantwortet Finanzfragen, und Ihre Anwälte testen den Kaufvertrag auf Herz und Nieren. Dann kommen die technischen Auditoren des Käufers für die M&A-Due-Diligence an und reichen innerhalb von 72 Stunden Befunde ein, die den vereinbarten Preis wieder auf den Tisch bringen.FO 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.

Das passiert häufiger, als irgendjemand zugeben möchte, und ist mit einem rechtzeitigen Software-Audit völlig vermeidbar. Laut dem 2025 M&A Trends Survey von Deloitte erwarten 79 % der Unternehmens- und 87 % der Private-Equity-Führungskräfte, dass das Deal-Volumen in diesem Jahr weiter steigt, was bedeutet, dass mehr Käufer diese Audits häufiger und mit schärferen Fragen durchführen. Leider erfahren die meisten Verkäufer, was diese Fragen tatsächlich sind, etwa eine Woche zu spät.ore often and with sharper questions. Sadly, most sellers learn what those questions actually are about a week too late.

Wir haben diesen Leitfaden geschrieben, weil fast jede M&A-Technologie-Due-Diligence-Checkliste im Internet wie eine Big-Four-Marketingbroschüre klingt: lange Listen, vage Kategorien und nichts darüber, was der Auditor auf der anderen Seite des Tisches tatsächlich zuerst öffnet, wenn der Datenraum live geht. Das hier ist also weniger ein Artikel als ein Testplan, den ein technischer Auditor des Käufers in diesen ersten drei Tagen wirklich ausführt, die Standards, gegen die sie das Zielunternehmen bewerten, und die drei Befunde, die am häufigsten den Deal-Preis zurücksetzen.ts, 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.

Wenn Sie der Verkäufer sind, lesen Sie dies als Ihre Generalprobe. Wenn Sie der Käufer sind, lesen Sie es als Plausibilitätsprüfung, ob Ihr eigenes Team die richtigen Fragen in der richtigen Reihenfolge stellt. questions in the right order.

Was prüfen M&A-Käufer bei der technischen Due Diligence

Hier ist die direkte Antwort, denn das ist es, weshalb Sie gekommen sind:

Bei der technischen Due Diligence prüfen Käufer vier Dinge, ungefähr in dieser Reihenfolge: wie das Zielunternehmen Software baut, was das Zielunternehmen rechtlich besitzt, wie geschützt die Software ist und wie fragil die Architektur ist. Alles andere auf einer typischen M&A-Due-Diligence-Checkliste ist unterstützende Evidenz für diese vier Fragen.tected 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.

Was das Gespräch jedoch verändert, ist, dass der Auditor nicht mit offenem Geist hereinkommt. Er kommt mit drei Referenzstandards vor sich herein. Der erste ist das nt of them. The first is the NIST Secure Software Development Framework, das disziplinierte Softwareentwicklung definiert. Der zweite ist das Software Assurance Maturity Model von OWASP, das bewertet, wie ausgereift jede dieser Praktiken in der realen Welt ist. Der dritte ist ISO/IEC 27001, der internationale Standard für Informationssicherheitsmanagement, der bestätigt, ob in dem Zielunternehmen tatsächlich jemand für irgendetwas davon verantwortlich ist. of it.

Zusammen werden diese drei Frameworks zu einer Scorecard:

• NIST teilt dem Auditor mit, wonach er suchen soll
• OWASP SAMM misst, wie gut das Zielunternehmen es umsetzt
• ISO 27001 verifiziert, dass jemand das Ergebnis verantwortet

Verkäufer, die in die Due Diligence gehen, ohne zu wissen, dass sie gegen diese drei gemessen werden, werden überrascht.

Warum die ersten 72 Stunden der M&A-Due-Diligence die Neupreisgestaltung entscheiden

Ein typischer M&A-Due-Diligence-Prozess läuft 30 bis 60 Tage. Die Befunde, die den Preis bewegen, tauchen jedoch an den Tagen eins bis drei auf. Das liegt daran, wie Auditoren tatsächlich arbeiten.se of how auditors actually work.

• Tag eins ist Dokumenten-Triage.
• Tag zwei ist Forensik am Code selbst.
• Tag drei ist, wenn der Auditor sich mit dem Engineering-Lead trifft, um die Fragen zu stellen, die die Dokumente nicht beantworten konnten.

Am Ende von Tag drei hat das Deal-Team des Käufers eine vorläufige Scorecard, und diese Scorecard ist es, die jedes folgende Gespräch prägt. Wenn die ersten 72 Stunden Vertrauen erzeugen, ist der Rest des Due-Diligence-Zeitraums größtenteils Verifizierung. Wenn sie jedoch Zweifel erzeugen, ist der Rest Neuverhandlung.first 72 hours produce confidence, the rest of the diligence period is mostly verification. However, if they produce doubt, the rest is renegotiation.

Es gibt drei Befunde, die insbesondere den Preis fast jedes Mal zurücksetzen. Wir werden sie im Detail besprechen, aber hier ist die Kurzversion: Erstens Lücken darin, wer den Code tatsächlich besitzt. Zweitens Änderungsaufzeichnungen, die auseinanderbrechen, wenn man drei Jahre zurückblickt. Drittens nicht dokumentierte Softwareteile, von denen das Unternehmen abhängt, aber die es sich nicht leisten kann zu verlieren. Jedes dieser Probleme entspricht sauber einem der drei Referenzstandards, und jedes signalisiert einem Käufer, dass die Überschriftsbewertung den Kontakt mit der Realität möglicherweise nicht überlebt.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.

Der 72-Stunden-Testplan, Stunde für Stunde

Das ist, was wir aus unserer M&A-Due-Diligence-Beratungserfahrung schließen können, in einfacher Sprache ausgedrückt, die auch Nicht-Ingenieure und Auditoren verstehen können. Beim Schreiben des folgenden Plans haben wir sowohl unsere Erfahrung mit solchen Projekten als auch aktuelle Vorschriften verwendet.derstand. In writing the following plan, we used both our experience with such projects and current regulations.

Stunden 0 bis 24: Dokumenten-Triage und Standards-Mapping

Der erste Tag ist Papierkram. Der Auditor möchte schnell sehen, ob das Zielunternehmen die Artefakte hat, die eine reife Softwareorganisation zur Hand haben sollte. Die Liste umfasst in der Regel:The list usually includes:

• Entwicklungsrichtlinien
• Geistiges-Eigentum-Register
• Vollständige Liste jeder Drittanbieter-Softwarekomponente, die das Produkt verwendet (Software Bill of Materials oder SBOM)
• Zugriffskontrollmatrix für Code-Repositories
• Die letzten zwei Penetrationstest-Berichte
• Drei-Jahres-Geschichte der Sicherheitsvorfälle

Der Auditor liest diese Dokumente noch nicht im Detail. Stattdessen prüft er auf Vorhandensein und Aktualität. Zum Beispiel ist ein Pentest-Bericht von vor 18 Monaten ein gelbes Flag, aber kein Pentest-Bericht überhaupt ist ein rotes. Ein SBOM, das letzte Woche generiert wurde, nur für den Datenraum, signalisiert, dass niemand bis jetzt auf das Abhängigkeitsrisiko geachtet hat.months 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.

Jedes Artefakt wird dann den drei Referenzstandards zugeordnet. NIST gruppiert Praktiken in vier Bereiche: Prepare the Organization, Protect the Software, Produce Well-Secured Software und Respond to Vulnerabilities. Der Auditor prüft, welcher dieser Bereiche unterstützende Evidenz hat und welcher nur mündliche Zusicherungen. OWASP SAMM weist jeder Praxis einen Reifegrad von 0 bis 3 zu. ISO 27001 ordnet Richtlinien bestimmten Annex-A-Kontrollen zu und fragt, ob sie implementiert oder nur dokumentiert sind.ware, 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.

Am Ende von Tag eins hat der Auditor eine Heatmap. Grün, wo das Zielunternehmen gut vorbereitet ist, gelb, wo die Evidenz dünn ist, rot, wo es nichts gibt. Das ist auch der Tag, an dem unsere Auditoren historisch gesehen die schwerwiegendsten Probleme für unsere Kunden entdeckt haben, einfach weil die Heatmap zeigt, wie das Zielunternehmen wirklich in 24 Stunden funktioniert, nicht in 24 Tagen.at 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.

Stunden 24 bis 48: Code- und Repository-Forensik

Tag zwei ist, wenn der Auditor den Code tatsächlich berührt, oder genauer gesagt, die Aufzeichnungen rund um den Code. Das Ziel hier ist zu verifizieren, dass das, was das Unternehmen sagt, dass es besitzt, mit dem übereinstimmt, was das Code-Repository sagt, was passiert ist.y says it owns matches what the code repository says happened.

Die erste Aufgabe ist die Überprüfung, wer was geschrieben hat. Der Auditor ruft die Commit-Historie ab und gleicht jeden Mitwirkenden gegen die IP-Abtretungsvereinbarungen ab, die von Mitarbeitern und Auftragnehmern unterzeichnet wurden. Wenn daher ein Freiberufler im Jahr 2021 einen bedeutenden Teil des Kernprodukts committet hat, das Unternehmen aber keine unterzeichnete Vereinbarung zur Eigentumsübertragung vorlegen kann, hat der Käufer nun ein Problem. Dasselbe gilt für Code, der von KI-Tools vorgeschlagen oder generiert wurde, weshalb Käufer 2026 plötzlich sehr spezifische Fragen dazu stellen, wie das Engineering-Team diese verwendet.signed 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.

Die zweite Aufgabe auf einer M&A-Due-Diligence-Checkliste ist die Lizenzierung. Das SBOM von Tag eins wird nun gegen den tatsächlichen Inhalt der Codebasis verglichen. Der Auditor sucht nach zwei Dingen: The auditor is hunting for two things:

• Open-Source-Komponenten, die unter Lizenzen verwendet werden, die den proprietären Code darum herum kontaminieren und das Unternehmen effektiv zwingen können, seinen eigenen Quellcode freizugeben.source code.
• Nicht lizenzierte oder abgelaufene kommerzielle Bibliotheken, die niemand bemerkt hat, weil der ursprüngliche Entwickler vor zwei Jahren gegangen ist.

Ein gründliches Code-Review bringt diese Probleme oft Wochen vor einem Auditor des Käufers ans Licht, weshalb Verkäufer, die vorausplanen, ihren eigenen Durchlauf machen, bevor der Datenraum öffnet.

Die dritte Aufgabe auf der technischen Due-Diligence-Checkliste des Auditors ist die Rekonstruktion des Change-Management-Pfades. Sie gehen durch das Repository der letzten drei Jahre und stellen eine einfache Frage: Kann ich für jede beliebige Änderung an der Produktion vom ursprünglichen Ticket über den Pull Request bis zum Commit bis zum Deployment nachverfolgen?ry 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?

Wenn die Antwort für die meisten Änderungen ja lautet, ist das Unternehmen in guter Form. Wenn die Antwort jedoch nein lautet oder wenn es große Lücken, Force-Pushes in den Main-Branch oder Commits gibt, die die Überprüfung umgehen, ist das ein Befund, den der Käufer sehr ernst nimmt.n branch, or commits that bypass review, that is a finding the buyer takes very seriously.

Die vierte Aufgabe der M&A-Due-Diligence ist das Kartieren der Abhängigkeiten. Der Auditor sucht nach Komponenten, von denen das Unternehmen abhängt, die aber nicht leicht zu ersetzen sind. Solche Beispiele könnten eine Bibliothek sein, die von einem einzigen Freiwilligen gepflegt wird, der seit zwei Jahren keinen Commit gemacht hat, oder eine Laufzeitversion, die der Anbieter letztes Quartal nicht mehr unterstützt. Das sind die stillen Ausfallpunkte, die in Post-Merger-Budgets als achtstellige Überraschungen auftauchen.sily 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.

Stunden 48 bis 72: Prozess- und Personenvalidierung

Tag drei ist der menschliche Tag der technischen Due Diligence. Der Auditor setzt sich, normalerweise für mehrere Stunden, mit dem Leiter des Engineerings und einer kleinen Gruppe von Senior-Mitwirkenden zusammen. Das Ziel ist zu bestätigen, dass das Bild aus den Tagen eins und zwei mit dem übereinstimmt, was die Menschen, die die Software bauen, tatsächlich tun.ful 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.

Das Gespräch bewegt sich durch einen vertrauten Bogen. Bedrohungsmodellierung kommt zuerst, weil der Auditor wissen möchte, ob Sicherheit etwas ist, das das Team einplant oder am Ende aufschraubt. Incident-Response kommt als nächstes, wobei der Auditor den Engineering-Lead bittet, den letzten schwerwiegenden Vorfall von Anfang bis Ende durchzugehen. Die Art, wie die Geschichte erzählt wird, verrät mehr als jedes Richtliniendokument. Dann kommt das Key-Person-Risiko, bei dem der Auditor sehr höflich fragt, was passieren würde, wenn ein bestimmter Entwickler nächste Woche gehen würde. Die ehrlichen Antworten sind oft unbequem. 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.

Am Ende von Tag drei schließt der Auditor den Laptop, schreibt eine einseitige Zusammenfassung für das Deal-Team, und die Verhandlung beginnt sich basierend auf dem Inhalt zu verschieben. is in it.

Standards-basierte M&A-Due-Diligence-Befunde, die Deals neu bepreisen

Im Folgenden erläutern wir die drei häufigsten Befunde von Auditoren, die den Preis des Deals sofort beeinflussen. Wir werden auch Erkenntnisse aus unserer M&A-Due-Diligence-Beratungserfahrung teilen, wie man solche Probleme angeht, wenn sie auftreten. Der einfachste Weg, Probleme in dieser Phase Ihres Deals zu vermeiden, ist jedoch, auf Ihrer Seite ein Audit durchzuführen, bevor das technische Due-Diligence-Team des Käufers eintrifft. 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.

Befund Eins: IP-Provenienz-Lücken

Provenienz bedeutet einfach den Nachweis, woher etwas stammt. In der M&A-Due-Diligence bedeuten IP-Provenienz-Lücken, dass das Unternehmen nicht vollständig beweisen kann, dass es den Code besitzt, den es verkauft.wns the code it is selling.

Das zeigt sich auf spezifische Weisen:

• Auftragnehmer, die bedeutende Teile des Produkts gebaut haben, ohne eine IP-Abtretungsvereinbarung zu unterzeichnen.
• Open-Source-Komponenten, die auf eine Weise verwendet werden, die die Lizenzbedingungen verletzt.
• Code, der von KI-Tools generiert wurde, ohne jegliche Aufzeichnung darüber, welche Prompts welche Ausgabe erzeugt haben.
• Erworbener Code aus einem früheren Deal, für den niemand die ursprünglichen Übertragungsunterlagen finden kann.

NIST-SSDF-Praxis PS.3, die die Archivierung und den Schutz jedes Releases behandelt, verlangt vom Unternehmen, eine klare Aufzeichnung jedes Artefakts in jedem Release zu führen. ISO-27001-Kontrolle A.5.32 erfordert expliziten Schutz der Rechte an geistigem Eigentum. Wenn ein Auditor des Käufers den Code nicht mit den Verträgen in Einklang bringen kann, ist die Reaktion vorhersehbar: Haftungsausnahmen im Kaufvertrag werden größer. Treuhandeinbehalte steigen, und in schwerwiegenden Fällen wird der Überschriftspreis um 5 bis 15 % reduziert, manchmal mehr, wenn der kontaminierte Code im Kernprodukt ist.ach 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.

Für Verkäufer ist dies der einfachste der drei Befunde, im Voraus zu beheben, aber nur, wenn Sie mindestens 60 Tage vor der Öffnung des Datenraums beginnen.

Befund Zwei: Change-Management-Pfade, die einen Drei-Jahres-Rückblick nicht überstehen

Der zweite Befund betrifft die Geschichte des Unternehmens, nicht seine Gegenwart. Käufer möchten drei Jahre im Source-Control-System zurückblicken und genau sehen, wie eine beliebige Änderung in der Produktion dorthin gelangt ist. Dazu gehört, wer sie vorgeschlagen hat, wer sie überprüft hat, wer sie genehmigt hat und wer sie deployed hat.how any given change in production got there. This includes who proposed it, who reviewed it, who approved it, and who deployed it.

Wenn dieser Pfad solide ist, wird der Käufer bestätigt, dass die Engineering-Kultur diszipliniert ist und dass die Codebasis wahrscheinlich keine versteckten Überraschungen enthält. Wenn der Pfad jedoch lückenhaft ist, beginnt der Auditor, nach dem zu suchen, was sonst noch fehlen könnte. Häufige Muster, die diesen Test nicht bestehen:ises. However, if the trail is patchy, the auditor starts looking for what else might be missing. Common patterns that fail this test include:

• Manuelle Deployments ohne entsprechendes Ticket
• Force-Pushes, die die Historie löschen
• Branches, die nie geschützt wurden
• Code-Reviews, die von derselben Person durchgeführt wurden, die den Code geschrieben hat
• Lange Zeiträume, in denen überhaupt nichts protokolliert wurde

NIST-SSDF-Praxis PS.1 erwartet klare Kontrolle über alle Formen von Code und unterstützender Dokumentation. Die OWASP-SAMM-Secure-Build-Praxis erwartet, dass jede Änderung reproduzierbar und nachverfolgbar ist. ISO-27001-Kontrolle A.8.32 erfordert formales Change-Management. Wenn alle drei schwach sind, reagiert der Käufer mit dem, was im Wesentlichen eine Integrationsrisikoprämie ist: obligatorische Sanierung vor dem Abschluss, ein verlängerter Treuhandauftrag oder ein Teil des Kaufpreises, der in einen aufgeschobenen Earn-Out verschoben wird, der an Engineering-Hygiene-Verbesserungen geknüpft ist.change 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.

Das ist der Befund, der die meisten Unternehmen überrascht, weil das Engineering-Team in der Regel glaubt, dass seine Hygiene in Ordnung ist, bis jemand tatsächlich schaut.y looks.

Befund Drei: Nicht dokumentierte kritische Abhängigkeiten

Der dritte Befund ist nach dem Abschluss des Deals am teuersten zu beheben, weshalb sich Käufer am meisten darum kümmern.

Jedes moderne Softwareprodukt hängt von Dutzenden oder Hunderten von Code-Teilen ab, die von anderen Menschen geschrieben wurden. Einige dieser Teile sind gut gepflegt und weit verbreitet, andere sind fragil. Die gefährlichen sind die Abhängigkeiten, ohne die das Unternehmen nicht laufen kann, die aber niemand im Unternehmen aktiv überwacht. Dies umfasst normalerweise:dely 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:

• Eine Bibliothek, die von einem Freiwilligen in einem anderen Land gepflegt wird
• Ein Microservice, der still in das persönliche Cloud-Konto eines Entwicklers ruft
• Eine Konfigurationsdatei mit geheimen Zugangsdaten, die seit 2022 nicht rotiert wurden
• Ein geplanter Job auf einem Server, den niemand im aktuellen Team eingerichtet hat

NIST-SSDF-Praxis PW.4 erwartet, dass das Unternehmen nur gut gesicherte Softwarekomponenten wiederverwendet. Die OWASP-SAMM-Software-Abhängigkeits-Praxis erwartet eine kontinuierliche Überwachung aller verwendeten externen Codes. ISO-27001-Kontrolle A.8.30 erfordert explizite Aufsicht über ausgelagerte Entwicklung und Drittanbieter-Code. Wenn ein Auditor des Käufers eine kritische Abhängigkeit findet, die niemand erklären kann, ist die Reaktion selten eine Preissenkung. Stattdessen ist es ein längerer Übergangsdienstleistungsvertrag, Halteprämien für die Entwickler, die die Abhängigkeit verstehen, und ein Reservefonds, der speziell für die Migration oder den Ersatz der fragilen Komponente nach dem Abschluss beiseitegelegt wird.inuous 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.

Stetiges, laufendes Software-Wartung ist die günstigste Versicherung gegen diesen Befund, weil es das Unternehmen zwingt, ein ehrliches Inventar darüber zu führen, wovon seine Software tatsächlich abhängt.

Wie Verkäufer sich selbst bewerten können, bevor der Käufer ankommt

Wenn Sie 30 bis 90 Tage von einem unterzeichneten LOI entfernt sind, haben Sie noch Zeit, mehr zu beheben, als Sie denken, indem Sie das folgende einfache Prinzip umsetzen: Führen Sie denselben Testplan an sich selbst durch, den das Team des Käufers an Ihnen durchführen wird.n the same test plan on yourself that the buyer’s team will run on you.

Ziehen Sie dieselben Artefakte, bewerten Sie sie gegen dieselben Standards und vergleichen Sie, was Sie finden, gegen die drei oben genannten Befunde. Die Übung dauert für ein kleines Team etwa zwei Wochen, wenn alles in vernünftiger Form ist, und vier bis sechs Wochen, wenn es nicht so ist. Nach unserer Erfahrung gibt es fünf Korrekturen, die in der kürzesten Zeit die meisten Punkte verbessern. 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.

• Unterzeichnen Sie IP-Abtretungsvereinbarungen mit jedem aktiven Auftragnehmer und dokumentieren Sie die Eigentumsübertragungskette für jeden Commit.
• Regenerieren Sie die Software Bill of Materials und gleichen Sie sie gegen die Codebasis ab, wobei Sie alle Lizenzverstöße beheben.
• Aktivieren Sie den Branch-Schutz im Haupt-Repository und verlangen Sie, dass alle Änderungen eine dokumentierte Überprüfung durchlaufen.
• Inventarisieren Sie jede Drittanbieter-Abhängigkeit in der Produktion und identifizieren Sie die drei oder vier, die das höchste Risiko darstellen.
• Schreiben Sie in einfacher Sprache auf, was das Engineering-Team tun würde, wenn eine Schlüsselperson morgen gehen würde.

Diese Korrekturen werden nicht jeden Befund verschwinden lassen, aber sie werden dem Auditor des Käufers demonstrieren, dass das Unternehmen weiß, wo seine Schwachstellen sind und sie ernst nimmt, was oft mehr bedeutet als die zugrunde liegenden Befunde selbst.d is taking them seriously, which often matters more than the underlying findings themselves.

Wenn Sie es vorziehen, ein unabhängiges Team zu haben, das Sie bewertet, bevor der Datenraum öffnet, ist das genau die Arbeit, die unsere Software-Audit-Services-Praxis tut. Wir verwenden dieselbe Scorecard, die das Team des Käufers verwenden wird, und wir sagen Ihnen in zwei Wochen, was sie dem Käufer in drei sagen würden. 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, Kontaktieren Sie uns noch heute und wir gehen von dort aus weiter.

Für eine tiefere Durchführung des Rahmens, den wir bei all unseren Audits verwenden, sehen Sie unseren SDLC-Audit-Checklisten-Beitrag, der dasselbe Terrain aus der Perspektive des Entwicklungsteams abdeckt. Und denken Sie daran: Wenn es eine Sache gibt, die wir hoffen, dass Sie aus diesem Artikel mitnehmen, dann ist es, dass der Auditor des Käufers nicht versucht, Sie zu erwischen. Er versucht zu bestätigen, dass der Preis auf dem Term Sheet mit dem Inneren des Unternehmens übereinstimmt. Je schneller Sie demonstrieren können, dass dies der Fall ist, desto schneller schließen Sie. Je länger sie suchen müssen, desto mehr finden sie.t 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

Erfahren Sie, wie wir ein Audit einer Netzwerk-Mapping-App durchgeführt haben und Codebase-Gesundheit und Sicherheit geprüft haben

Bitte geben Sie Ihre Geschäfts-E-Mail-Adresse ein ist keine Geschäfts-E-Mail

Fallstudie erhalten