Architektur-Audit oder technische Due Diligence?

01Das Mandat verändert die Bewertung

Architektur-Audit

Wird meist beauftragt, um ein System zu verstehen, einen Ansatz zu bewerten oder Änderungen zu priorisieren. Legen Sie fest, welche Belege zu Architektur, Code und Betrieb einbezogen werden und welche schriftlichen Befunde das Team braucht.

Technische Due Diligence

Wird im Zusammenhang mit einer Transaktion beauftragt. Legen Sie die Fragen des Käufers, die Zielsysteme, Zugangsbeschränkungen und die Empfänger des Berichts fest. Verknüpfen Sie technische Beobachtungen mit den Risiken und offenen Annahmen, die für diese Transaktion relevant sind.

Fokussierte Review-Session

Ein engerer Einstieg, wenn eine Entscheidung oder ein Teil eines Systems Aufmerksamkeit braucht. Sie ersetzt keine abgegrenzte Bewertung einer Codebasis oder einer Transaktion.

Ein langer Bericht ist kein Beweis für eine umfassende Bewertung. Ein kurzer Bericht ist nicht unbedingt oberflächlich. Die entscheidende Frage ist, ob die Arbeit die Belege untersucht hat, die für die beauftragende Entscheidung nötig sind, und klar benennt, was sie nicht verifizieren konnte.

02Fragen Sie, worauf jede Schlussfolgerung beruht

Verlangen Sie eine Unterscheidung zwischen beobachtetem Verhalten, bereitgestellter Dokumentation, Interviews und Schlussfolgerungen. Ein Diagramm kann ein beabsichtigtes System beschreiben, ohne zu beweisen, dass die Produktion ihm entspricht. Ein bestandener Test stützt nur das Verhalten, das er tatsächlich prüft. Ein fehlendes Artefakt sollte eine offene Frage bleiben, bis es untersucht ist.

Das Secure Software Development Framework v1.1 des NIST beschreibt Praktiken und ein gemeinsames Vokabular, das Käufer in Gesprächen mit Lieferanten nutzen können. Es kann Fragen zu Entwicklungspraktiken anregen; ein Verweis darauf macht eine Bewertung nicht zu einer Sicherheitszertifizierung. NIST SP 800-218: SSDF v1.1 (2022).

Bestimmen Sie für Ihren Umfang, welche Aussagen die Entscheidung wesentlich beeinflussen und welche Belege sie stützen würden. Code-Zugang allein beantwortet möglicherweise keine Fragen zu Deployment, Incident-Handling, Abhängigkeiten von Lieferanten oder den Menschen, die für den Betrieb des Systems nötig sind.

03Den Umfang vor der Beauftragung festlegen

• Entscheidung und Zielgruppe: Wer beauftragt die Arbeit, wer erhält sie, und welche Entscheidung soll sie unterstützen?
• Grenze: Welche Produkte, Repositories, Umgebungen und Integrationen sind eingeschlossen oder ausgeschlossen?
• Belege und Zugang: Was kann eingesehen werden, wer kann Fragen beantworten, und was ist nicht verfügbar?
• Ergebnis: Welche Befunde, Belegverweise, Prioritäten und offenen Fragen müssen festgehalten werden?
• Zeitplan: Wann sind die Belege verfügbar, und was passiert, wenn der Zugang verspätet kommt?
• Umsetzung: Wer kann Befunde erläutern, und werden Behebung oder weitere Untersuchungen separat abgegrenzt?

Vereinbaren Sie bei einer Transaktion außerdem mit den zuständigen Beratern die Vertraulichkeit, die zulässigen Empfänger und den Umgang mit Informationen Dritter. Technische Befunde tragen zur Entscheidung bei; sie ersetzen keine Rechts- oder Finanzberatung und garantieren kein Investitionsergebnis.

04Angebote nach Abdeckung und Grenzen vergleichen

Legen Sie Angebote neben dasselbe Briefing. Vergleichen Sie abgedeckte Systeme, Zugang zu Belegen, Ergebnisse, Ausschlüsse und den Umgang mit Unsicherheit. Fragen Sie, wie eine nicht verifizierte Aussage im Bericht erscheinen wird. Wird garantiert, jeden Fehler zu finden, oder eine bedingungslose Unbedenklichkeit bescheinigt, sollten Sie klären, was tatsächlich versprochen wird.

Für ein bestehendes System und eine Verbesserungsentscheidung sehen Sie sich das Angebot Architektur-Audit an. Für eine Investition oder Übernahme sehen Sie sich die Technische Due Diligence an. Beide Aufträge von Robles Consulting werden separat abgegrenzt; die veröffentlichten Preise sind Einstiegspreise, und Umfang und Lieferung werden vor Arbeitsbeginn vereinbart. Keiner von beiden ist ein Sofortkauf.