Ein Due-Diligence-Fragebogen, häufig DDQ genannt, ist ein strukturierter Fragenkatalog zur Prüfung einer Organisation vor Transaktion, Investition, Vertrag oder Drittparteienbeziehung. Er verlangt Fakten und Evidenz etwa zu Eigentum, Finanzen, Security, Datenschutz, Compliance, Betrieb und Resilienz.

DDQs überschreiten Organisationsgrenzen. Ein Workbook kann rechtliche Erklärungen, technische Kontrollfragen, Finanzzahlen und operative Zusagen enthalten. Antworten altern unterschiedlich schnell und Evidenz kann vertraulich sein. Wer die Vorjahresantwort ohne Prüfung von Scope, Datum und Owner kopiert, erzeugt Widerspruch, Over-Disclosure und falsche Sicherheit.

Eine belastbare DDQ-Antwort ist ein evidenzgesteuerter Disclosure-Prozess. Jede wesentliche Aussage braucht verantwortlichen Owner, freigegebene Quelle, aktuellen Scope und Review-Status. Wiederverwendung beschleunigt Discovery, ersetzt aber nie die Verifikation.

Ein DDQ ist breiter als ein Sicherheitsfragebogen

Ein Security Questionnaire fokussiert technische und organisatorische Schutzmassnahmen, ein DDQ kann die gesamte Beziehung prüfen. Je nach Entscheid umfasst er wirtschaftlich Berechtigte, Finanzstabilität, Sanktionen, Versicherung, Datenschutz, Informationssicherheit, Business Continuity, Subunternehmer, Leistung und Rechtsstreitigkeiten. Investment- und M&A-Prüfungen reichen zusätzlich in Kunden, IP, Steuern und Personal.

Kategorien überlappen, aber die Freigabepfade unterscheiden sich. Ein Security Owner validiert keinen geprüften Umsatz, ein Jurist keine operative Wiederanlaufzeit ohne Service Owner. Der Response braucht Domain-Routing und eine zentrale Koordination, welche die Gesamtaussage abgleicht.

Typische Diligence-Domänen und Evidenz
DomäneTypische FragenMögliche Evidenz
CorporateEigentum, Einheiten, GovernanceRegister und Organisationsnachweise
SecurityKontrollen, Vorfälle, TestsPolicies, Auditberichte, Summaries
PrivacyDatenrollen, Transfers, RetentionNotices, Verzeichnisse, Verträge
BetriebDelivery, Continuity, LieferantenPläne, Metriken, Register
FinanzenStabilität, Versicherung, HaftungFreigegebene Abschlüsse, Zertifikate

Evidenz muss zum Claim, Scope und Prüfdatum passen

Eine Policy beweist eine definierte Erwartung, aber nicht allein deren konsistenten Betrieb. Ein Auditbericht kann stärkere Assurance geben, jedoch nur für benannte Systeme und Periode. Ein Zertifikat läuft ab, eine Penetration-Test-Summary ist eine Momentaufnahme. Gute Antworten benennen die relevante Kontrolle und behaupten nicht mehr, als die Evidenz trägt.

Bauen Sie eine Disclosure-Leiter. Öffentliche Dokumentation kann früh geteilt werden, kontrollierte Summaries unter Vertraulichkeit. Detailberichte, Samples oder kundenspezifisches Material benötigen möglicherweise Data Room und Need-to-know-Review. So kann die Gegenpartei echte Evidenz prüfen, ohne unnötige Offenlegung.

  • Source Owner, Freigabedatum, Scope und Ablauf dokumentieren.
  • Evidenz-ID statt unkontrollierter Anhänge verwenden.
  • Umgesetzte Kontrolle, kompensierende Massnahme und Roadmap trennen.
  • Personen- und Kundendaten angemessen redigieren.
  • Inhalt bei verändertem Fragesinn oder Scope neu validieren.

Konkrete Ergebnisse für Due-Diligence-Fragebogen

  • Fachverantwortliche erhalten nur Fragen, die ihr Urteil wirklich benötigen.
  • Wiederkehrende Antworten werden mit Herkunft und aktueller Bestätigung genutzt.
  • Claims, Ausnahmen und geplante Verbesserung bleiben klar getrennt.
  • Sensible Evidenz wird verhältnismässig und über freigegebene Kanäle geteilt.
  • Der eingereichte Fragebogen besitzt einen vollständigen Review- und Freigabenachweis.

So wird die Arbeit ausgeführt

  1. 01

    Request und Disclosure-Grenze klassifizieren

    Bestätigen Sie Gegenpartei, Transaktion, Rechtseinheiten, Produkte, Geografie, Frist und Vertraulichkeit. Trennen Sie Security, Privacy, Legal, Finance und Operations. Entscheiden Sie, welche Dokumente direkt, nur beschränkt, redigiert oder erst in späterer Diligence geteilt werden.

  2. 02

    Antwort- und Evidenzlandkarte bauen

    Routen Sie jede Frage an einen verantwortlichen Fachowner. Suchen Sie freigegebene frühere Antworten, Policies, Auditberichte, Register und Produktdokumentation. Dokumentieren Sie Datum und Scope. Ähnlicher Text bleibt Kandidat, bis der Owner seine Anwendbarkeit bestätigt.

  3. 03

    Mit expliziten Antwortzuständen entwerfen

    Beantworten Sie die konkrete Frage und unterscheiden Sie Ja, Nein, teilweise umgesetzt, nicht anwendbar und geplant. Ergänzen Sie Kontext, wenn eine binäre Antwort irreführt. Verknüpfen Sie Evidenz mit dem Claim und vermeiden Sie Aussagen jenseits der geprüften Einheit, Leistung oder Periode.

  4. 04

    Prüfen, freigeben und bewahren

    Der Cross-functional Review sucht Widersprüche, unbelegte Zusagen und Disclosure-Risiken. Holen Sie nötige Legal-, Security-, Finance- und Commercial-Freigaben. Reichen Sie über den autorisierten Kanal ein, sichern Sie die exakte Fassung und übernehmen Sie neue freigegebene Antworten in die Knowledge Base.

Fragen, die den Entscheid verändern

  • Welche Einheit, welches Produkt, welche Geografie und Periode deckt die Antwort ab?
  • Wer verantwortet Wahrheit und Freigabe in diesem Fragethema?
  • Welche Evidenz ist ausreichend, aktuell und verhältnismässig teilbar?
  • Braucht ein Ja oder Nein eine Qualifikation, um korrekt zu bleiben?
  • Welche Ausnahme verlangt Remediation, Eskalation oder kommerzielle Akzeptanz?

Wo Teams die Kontrolle verlieren

01

Eine übernommene Antwort kann für ein Produkt korrekt und für ein anderes falsch sein.

02

Breite Claims wie immer oder vollständig erzeugen Vertrags- oder Regulierungsrisiko.

03

Unkontrollierte Anhänge legen Kunden-, Architektur- oder Personaldaten unnötig offen.

04

Widersprüchliche Antworten zwischen Security, Privacy und Legal zerstören Vertrauen.

05

Ein Spreadsheet ohne Versionskontrolle kann die freigegebene Sendefassung nicht beweisen.

Das fertige Ergebnis messen

Gemessen wird der abgeschlossene Prozess inklusive Review-Aufwand und Ausnahmen. Reines Output-Volumen beweist noch keine bessere Arbeitsweise.

  • Fragen mit eindeutig verantwortlichem Owner
  • Antworten mit aktueller und freigegebener Quelle
  • wegen Widerspruch oder unbelegter Sprache zurückgesandte Punkte
  • mediane Antwort- und Review-Zeit der Owner
  • neu in die Knowledge Base aufgenommene Antworten
  • Korrekturen oder Käufernachfragen nach Einreichung

Häufige Fragen

Wofür steht DDQ?

DDQ steht für Due Diligence Questionnaire oder Due-Diligence-Fragebogen. Der strukturierte Request bewertet Organisation, Transaktion oder Drittpartei vor Investition, Vertrag oder anderem wesentlichen Entscheid.

Was enthält ein Due-Diligence-Fragebogen?

Der Scope hängt vom Entscheid ab. Häufig sind Eigentum, Finanzen, Versicherung, Security, Datenschutz, Compliance, Business Continuity, Subunternehmer, Betrieb und rechtliche Themen enthalten. Zusätzlich können beweisende Dokumente verlangt werden.

Lassen sich DDQ-Antworten automatisieren?

Retrieval, Routing, Drafting, Konsistenzprüfung und Evidenzverknüpfung können unterstützt werden. Owner müssen Kontext, Fakten, Ausnahmen und Disclosure verifizieren. Riskante Legal-, Security- und Finance-Erklärungen dürfen nicht ungeprüft aus wiederverwendetem Text publiziert werden.

Wie unterscheidet sich ein DDQ von einem RFP?

Ein DDQ prüft, ob Organisation und Kontrollen akzeptabel sind. Ein RFP bewertet, wie ein Anbieter Anforderungen erfüllen will. Eine Beschaffung kann beides enthalten: Lösungsfragen im RFP und Unternehmensprüfung in einem separaten Fragebogen.

Malcolm Ferguson

Malcolm Ferguson

Spezialist für Procurement und Sourcing

Malcolm schreibt aus Käufersicht über Beschaffung, Sourcing, Due Diligence und die Nachweise für eine belastbare Lieferantenbewertung.

Proposal-Software für quellenbasierte Antworten auf RFPs, RFIs, DDQs und Fragebögen.

Bid-Management, Proposal-Teams, Presales sowie Security- und Compliance-Verantwortliche. Ausgangspunkt sind der bestehende Ablauf, seine Grenzen und die vorhandenen Nachweise.

Ziva ansehen