---
title: "Eine Sicherheitsarchitektur im RFP belastbar erklären"
description: "Erstellen Sie eine prüfbare Architekturantwort aus Schutzbedarf, Angriffspfaden, freigegebenen Sichten und passend abgegrenzten Nachweisen."
canonical: "https://zephior.com/de/insights/answer-an-rfp-security-architecture-question"
last-updated: 2026-09-04
---

# Eine Sicherheitsarchitektur im RFP belastbar erklären

> Erstellen Sie eine prüfbare Architekturantwort aus Schutzbedarf, Angriffspfaden, freigegebenen Sichten und passend abgegrenzten Nachweisen.

Von [Tony Kim](https://zephior.com/de/authors/tony-kim). Veröffentlicht 2026-09-04; aktualisiert 2026-09-04. 15 Min. Lesezeit.

## Definition

Eine Antwort zur Sicherheitsarchitektur beschreibt, wie die konkret angebotene Lösung schutzbedürftige Geschäftsprozesse, Informationen und Funktionen gegen relevante Gefährdungen absichert. Dafür werden mehrere freigegebene Sichten mit unterschiedlichem Zweck benötigt. Sie zeigen Systemgrenze, Sicherheitsdomänen, Identitäten, Daten- und Administrationswege, Platzierung von Sicherheitsfunktionen, Begrenzung einer Kompromittierung und Überwachung. Jede wesentliche Aussage verweist auf einen datierten Entwurfs-, Umsetzungs-, Betriebs- oder Prüfbeleg mit passendem Geltungsbereich.

## Problem

In einer Ausschreibung wird nach Sicherheitsarchitektur und belastbaren Nachweisen gefragt. Der Bieter fügt ein übliches Cloud-Schaubild ein. Zwischen Internet und Anwendung stehen Symbole für Firewall, Verschlüsselung und SIEM. Nicht erkennbar sind Fachverfahren, angebotene Ausprägung, Mandantengrenze, privilegierte Verwaltung, externe Identitätsquelle, Verantwortlichkeiten oder Verhalten bei Ausfall einer Schutzfunktion. Das Diagramm enthält außerdem eine geplante Komponente, die noch nicht produktiv eingesetzt wird. Eine Zertifikatsnummer unter dem Bild macht diese Lücken nicht prüfbar. Eine detaillierte Netztopologie im offenen Angebot würde dagegen unnötige Angriffsinformation offenlegen.

## Perspektive

Beginnen Sie bei Leistungsgegenstand, Schutzbedarf und unerwünschten Auswirkungen. Leiten Sie daraus nachvollziehbare Angriffspfade und Architekturentscheidungen ab. Eine Sicht ist nur dann nützlich, wenn sie eine konkrete Bewertungsfrage beantwortet. Trennen Sie bestehende Umsetzung, angebotene Zielkonfiguration, Annahme und offene Frage. Beschreiben Sie außerdem, welche Sicherung beim Versagen einer anderen Schicht wirksam bleibt, wie ein Angriff erkannt wird und wer das Restrisiko verantwortet. Die Offenlegung erfolgt abgestuft, damit der Auftraggeber prüfen kann, ohne vermeidbare technische Angriffshilfen zu erhalten.

## Die Antwort braucht eine eindeutige technische Bezugsgröße

Prüfen Sie die Frage zusammen mit Leistungsbeschreibung, Wertungsmethode, Sicherheitsanlage, Datenanforderungen, Betriebsmodell, Schnittstellen, Vertrag und Bieterinformationen. Der Auftraggeber kann eine Darstellung des Ist-Zustands, einen Zielentwurf, eine Umsetzungsmethode oder einen Prüfbericht verlangen. Kennzeichnen Sie diese Gegenstände getrennt. Eine ausführliche Beschreibung verfehlt die Aufgabe, wenn sie den falschen Zustand oder eine andere Produktvariante beschreibt.

Der Antwortkopf nennt Verfahren, Los, Bieter, Dienst, Edition, Mandantenmodell, vorgeschlagene Betriebsorte, produktive und unterstützende Umgebungen, externe Verbindungen, Datenkategorien, betrachteten Zeitraum, Dokumentversionen und Nachweisstichtag. Hinzu kommen die Stellen, die technische Richtigkeit, Risiko, Offenlegung und vertragliche Zusage freigeben dürfen. Diese Angaben bilden den Schlüssel für jede weitere Sicht und jeden Beleg.

Im fiktiven Beispiel beschafft der Verkehrsverbund Falkenried einen Dienst für Fahrgastinformation und Störungsbearbeitung. Leitstellenmitarbeiter pflegen Meldungen, Verkehrsunternehmen liefern Betriebsdaten, Fahrgäste lesen Informationen über Web und App, Servicetechniker verwalten Schnittstellen. Das Angebot umfasst eine bestimmte gehostete Ausprägung. Namen und Sachverhalt sind erfunden und belegen keine Aussage über ein echtes Verkehrsunternehmen.

**Aussagestatus im Falkenried-Angebot**

| Sachverhalt | Status | Zulässige Aussage | Nächster Nachweis |
| --- | --- | --- | --- |
| Trennung der Kundenbereiche | Bestehend und geprüft | Grenze und Prüfdatum für die angebotene Edition nennen | Auswahl der Edition bestätigen |
| Verbundweite Identitätsanbindung | Angeboten, Metadaten fehlen | Unterstütztes Vertrauensmodell und Abnahmeschritt beschreiben | Attribute und Vertrauensniveau prüfen |
| Absicherung der Datenlieferanten | Geteilte Annahme | Gefordertes Identitäts- und Verbindungsprofil nennen | Jeder Lieferant bestätigt seinen Anteil |
| Altgerät eines Verkehrsunternehmens | Offen | Keine Kompatibilitäts- oder Sicherheitszusage erfinden | Frage über den vorgesehenen Vergabekanal |

## Schutzbedarf verbindet Fachschaden und technische Entscheidung

Der BSI-Standard 200-2 beginnt die Sicherheitskonzeption mit Strukturanalyse, Schutzbedarfsfeststellung und Modellierung. Für eine Angebotsantwort bedeutet das: Ordnen Sie Geschäftsprozesse, Anwendungen, Informationen, Systeme, Kommunikationsverbindungen und Infrastruktur ein, bevor Sie Sicherheitsprodukte aufzählen. Begründen Sie Vertraulichkeit, Integrität und Verfügbarkeit über mögliche fachliche Schäden. Die Einstufung eines Datenbestands darf nicht automatisch auf jedes technische Objekt übertragen werden; Abhängigkeiten und Kumulation müssen erkennbar bleiben.

Falkenried schützt die korrekte und zeitnahe Fahrgastmeldung, die nicht öffentliche Betriebsinformation, die Berechtigung zur Veröffentlichung sowie die Nachvollziehbarkeit administrativer Änderungen. Relevante Pfade sind unter anderem ein übernommenes Leitstellenkonto, manipulierte Daten eines Verkehrsunternehmens, ein kompromittierter öffentlicher Dienst, missbrauchte Supportrechte und eine verfälschte Bereitstellung. Ordnen Sie pro Pfad Ausgangspunkt, Voraussetzungen, Zielobjekt, Grenzübertritte, fachliche Wirkung und verbleibendes Risiko zu.

Bedrohungskataloge helfen bei der Gegenprobe, ersetzen aber die Systemanalyse nicht. MITRE ATT&CK beschreibt beobachtete Vorgehensweisen von Angreifern. OWASP strukturiert Threat Modeling über Gegenstand, mögliche Fehler, Gegenmaßnahmen und Prüfung. Wählen Sie nur die Einträge, die zum Einsatz und zur betrachteten Abstraktion passen. Eine lange Liste ohne Verbindung zur Architektur ist keine Risikoanalyse.

**Vom Fachschaden zur Architekturentscheidung**

| Unerwünschte Wirkung | Angriffspfad | Architekturentscheidung | Restrisiko |
| --- | --- | --- | --- |
| Falsche Störungsmeldung wird veröffentlicht | Übernommenes Redaktionskonto | Starke Identität, rollenbezogene Freigabe und Änderungsprotokoll | Berechtigter Missbrauch innerhalb der Rolle |
| Ein Lieferant verändert fremde Daten | Fehlerhafte Mandanten- oder Quellenzuordnung | Eindeutige technische Identität und quellenbezogene Autorisierung | Fehlerhafte Stammdatenfreigabe |
| Öffentlicher Dienst öffnet Verwaltungszugang | Kompromittierung der Webkomponente | Getrennter Administrationsweg und eingeschränkte Dienstidentität | Unbekannte Schwachstelle in einer gemeinsamen Abhängigkeit |
| Angriff bleibt unbemerkt | Manipulation oder Ausfall der Telemetrie | Getrennter Ereignisweg, Zustellkontrolle und Alarm bei Lücke | Kurze nicht beobachtete Zeitspanne |

## Jede Sicht beantwortet eine andere Sicherheitsfrage

Eine Kontextsicht grenzt angebotenen Dienst, Nutzergruppen, Fremdsysteme und Anbieter ab. Die Domänensicht zeigt Bereiche unterschiedlichen Vertrauens und die kontrollierten Übergänge. Die Datenflusssicht verfolgt fachliche Informationen einschließlich Richtung, Klassifikation und Ablage. Identitäts- und Administrationssichten erklären menschliche sowie technische Identitäten, Privilegien und getrennte Verwaltungswege. Eine Bereitstellungssicht zeigt Isolation, gemeinsame Abhängigkeiten und Begrenzungsbereiche auf angemessener Abstraktion.

Vergeben Sie dauerhafte Kennungen für Komponenten und wichtige Flüsse. Jede Sicht enthält Zweck, Umfang, Eigentümer, Version, Stichtag, Abstraktionsniveau und Legende. Begriffe bleiben über alle Sichten gleich oder erhalten eine eindeutige Zuordnung. Ein “Service Gateway” in der Datenflusssicht darf nicht unbemerkt drei verschiedene Komponenten der Bereitstellungssicht zusammenfassen. Die Verdichtung ist zulässig, wenn ihr Zweck und ihre Grenze genannt werden.

Ein freigegebenes Diagramm belegt zunächst einen dokumentierten Entwurf. Ob dieser Entwurf umgesetzt ist, zeigen Konfiguration, Bereitstellungsdaten oder technische Prüfung. Ob er im Betrieb funktioniert, zeigen laufende Aufzeichnungen und Übungen. Schreiben Sie den Belegstatus direkt an die Sicht. Ein Zielbild ohne diesen Hinweis kann beim Leser zu einer falschen Ist-Aussage werden.

- Kontextsichten bestimmen Systemgrenze und externe Abhängigkeiten.
- Domänensichten erklären Vertrauenswechsel und Durchsetzung.
- Datenflusssichten zeigen Zweck, Richtung und Schutzklasse.
- Identitätssichten trennen Nutzer, Dienste, Geräte und Privilegien.
- Bereitstellungssichten machen Isolation und gemeinsame Ursachen sichtbar.

## Ein internes Netz erteilt noch keine Berechtigung

Beschreiben Sie für jeden wesentlichen Zugriff Subjekt, Ressource, Identitätsquelle, relevante Signale, Regel, Durchsetzungspunkt und erlaubte Aktion. Das gilt für Beschäftigte, externe Redakteure, Softwaredienste und Geräte. Zero-Trust-Leitlinien von NIST und NCSC behandeln Netzstandort oder Besitz nicht als ausreichenden Vertrauensbeweis. Eine Verbindung aus dem Verbundnetz kann deshalb weiterhin eine benannte Identität, ein freigegebenes Gerät und eine rollenbezogene Entscheidung benötigen.

Trennen Sie fachliche Datenflüsse von Administration, Steuerung und Überwachung. Die Fahrplandaten eines Verkehrsunternehmens dürfen nicht denselben Berechtigungsweg wie eine Konfigurationsänderung nehmen. Ein technischer Kontrollfluss verteilt Regeln oder Schlüssel. Ein Überwachungsfluss transportiert Sicherheitsereignisse. Die Vermischung in einem einzigen Pfeil verdeckt Privilegien, mögliche Abflusswege und die Zuständigkeit bei Störung.

Die Verwaltung erhält eine eigene Sicht. Darin stehen Vergabe und Entzug privilegierter Identitäten, starke Authentisierung, Aufgabenfreigabe, Reichweite, Sitzungs- oder Aktivitätsnachweis, Notfallzugang und Trennung vom üblichen Arbeitsplatz. Hersteller- oder Providerzugriff wird als eigener externer Pfad geführt. Die Aussage “nur Administratoren” genügt nicht, weil sie weder Herkunft noch Kontrolle dieses Privilegs erklärt.

**Vier Flussarten mit unterschiedlicher Macht**

| Fluss | Beispiel | Zu zeigende Entscheidung | Fehlerreaktion |
| --- | --- | --- | --- |
| Fachdaten | Verspätungsmeldung eines Verkehrsunternehmens | Quelle, Zulässigkeit, Validierung und Veröffentlichungsstatus | Abweisen oder als ungeprüft zurückhalten |
| Administration | Änderung einer Schnittstellenberechtigung | Privilegierte Identität, Genehmigung und getrennte Route | Sperren, alarmieren und untersuchen |
| Steuerung | Verteilung einer Autorisierungsregel | Vertrauenswürdige Quelle, Signatur und erlaubter Empfänger | Alte freigegebene Regel halten oder sicheren Zustand wählen |
| Überwachung | Sicherheitsereignis aus dem Redaktionsdienst | Authentische Quelle, Datenminimierung und Korrelation | Zustelllücke sichtbar machen und eskalieren |

## Mehrere Schutzsymbole sind noch keine unabhängigen Barrieren

Erfassen Sie jede zentrale Sicherheitsfunktion mit Zielobjekt, Platzierung, Entscheidungseingängen, Betreiber, Abhängigkeiten und Verhalten bei Ausfall. Eingangsfilterung, anwendungsbezogene Autorisierung und eingeschränkte Datenbankrechte können verschiedene Abschnitte eines Angriffspfads schützen. Nutzen alle drei dieselbe kompromittierte Dienstidentität oder dieselbe unkontrollierte Konfiguration, ist ihre Unabhängigkeit begrenzt. Die Antwort muss diese gemeinsame Ursache sichtbar lassen.

Beschreiben Sie die Begrenzung einer Kompromittierung. Eine übernommene öffentliche Darstellungskomponente darf beispielsweise Meldungen lesen, die ausdrücklich zur Veröffentlichung bestimmt sind. Sie darf keine Quelle als vertrauenswürdig registrieren, keine Redaktionsfreigabe erteilen und keinen Massenexport nicht öffentlicher Betriebsdaten starten. Diese fachliche Begrenzung ist verständlicher als eine Liste von Subnetzen. Der technische Nachweis bleibt trotzdem nötig.

Überwachung gehört in den Entwurf. Ordnen Sie privilegierte Aktionen, geänderte Regeln, abgewiesene Daten, ungewöhnliche Exporte, fehlerhafte Identitätsentscheidungen und Ausfall von Sicherheitsfunktionen konkreten Ereignisquellen zu. Nennen Sie Korrelation, Empfänger und Reaktion. Vermeiden Sie sensible Inhalte im allgemeinen Protokoll. Auch der Ausfall der Telemetrie braucht einen sichtbaren Zustand.

Bei Verfügbarkeit unterscheiden Sie zufälligen Ausfall und gezielten Angriff. Mehrere gleiche Instanzen können einen Hardwarefehler überstehen und dennoch gemeinsam durch eine Schwachstelle, eine manipulierte Bereitstellung oder den Verlust derselben Verwaltungsebene ausfallen. Verweisen Sie für Wiederanlaufziele auf den dafür freigegebenen Teil des Angebots. Die Architekturantwort benennt nur die Abhängigkeit und den geprüften Störfall.

## Ein Nachweis darf nur seine eigene Schlussfolgerung tragen

Ordnen Sie jedem Beleg Kennung, Objekt, Umgebung, Edition, Datum oder Zeitraum, Methode, Ergebnis, Einschränkung, Eigentümer und zugelassene Zielgruppe zu. Ein Architekturentscheid belegt eine freigegebene Gestaltung. Konfigurations- und Bereitstellungsdaten belegen Umsetzung. Betriebsaufzeichnungen zeigen wiederholte Ausführung. Ein Test belegt das Verhalten unter bestimmten Eingaben und Randbedingungen. Ein externer Prüfbericht trägt nur die Schlussfolgerungen seines festgelegten Umfangs.

Die Aussage zur getrennten Administration verweist in Falkenried auf die Identitätssicht, den genehmigten Architekturentscheid, eine Prüfung der produktiven Zugangswege und die letzte vollständige Berechtigungsrezertifizierung. Ein älterer Penetrationstest kann zusätzliche Sicherheitshinweise liefern. Er schließt die Aussage aber nicht, wenn danach der Verwaltungsweg wesentlich geändert wurde. Dann braucht die neue Ausprägung einen passenden Beleg oder eine sichtbare Lücke.

Rahmenwerke erleichtern Begriffe und Vollständigkeitsprüfung. Sie beweisen keine konkrete Implementierung. NIST SP 800-53 trennt Sicherheitsfunktion und Vertrauensmaß, SP 800-53A liefert anpassbare Prüfverfahren, das OWASP ASVS formuliert versionierte Anforderungen für Anwendungssicherheit. Nennen Sie den Prüfmaßstab und anschließend das wirkliche Prüfergebnis. Für eine atomare Zuordnung einzelner Käuferanforderungen zu Kontrollen führen Sie eine eigene Kontrollmatrix.

**Nachweiskette für drei Architekturaussagen**

| Aussage | Entwurfsbeleg | Umsetzung oder Betrieb | Aussagegrenze |
| --- | --- | --- | --- |
| Jede Datenquelle erhält eine getrennte technische Identität | Identitäts- und Datenflusssicht | Konfigurationsauszug und Negativtests fremder Quellen | Gilt für die benannten Schnittstellen der angebotenen Edition |
| Öffentliche Komponenten können keine Freigabe erteilen | Domänen- und Berechtigungsentscheid | Rollenprüfung und misslungener Freigabeversuch | Deckt keine unbekannte Schwachstelle in gemeinsamer Software ab |
| Privilegierte Änderungen werden überwacht | Administrations- und Ereignissicht | Quelleninventar, Zustellprüfung und Alarmübung | Belegt nicht die Erkennung jedes möglichen Angriffs |

## Schwärzung braucht einen kontrollierten Ersatz für den Prüfer

Das eigentliche Angebot kann Systemgrenze, Sicherheitsdomänen, Kontrollzwecke, Zuständigkeiten und Nachweisverweise enthalten. Eine geschützte Bieteranlage kann redigierte logische Sichten und Auszüge führen. In einem zugelassenen Due-Diligence-Raum können benannte Prüfer tiefere Konfigurationen oder Berichte einsehen. Besonders sensible Feststellungen, Regeln und privilegierte Routen bleiben einem ausdrücklich genehmigten Prüferkreis vorbehalten. Ob diese Abstufung zulässig ist, bestimmen Vergabeunterlagen und anwendbares Recht.

Entfernen Sie konkrete Adressen, unnötige Produktstände, Schlüsselmaterial, Zugangsdaten, genaue Verwaltungsrouten, aktive Abwehrschwellen, ausnutzbare Schwachstellen und Kundendaten. Behalten Sie Zweck, Flussrichtung, Vertrauensentscheidung, Datenklasse, Betreiber, Beziehung zwischen Schutzschichten, Nachweisreferenz und Einschränkung. Ein stabiler Schwärzungscode zeigt, dass zwei Darstellungen dasselbe verborgene Element meinen.

Das Offenlegungsverzeichnis nennt Ursprungsartefakt, entfernte Ebene, Grund, Risiko- und Freigabeverantwortung, Zielgruppe, Ersatzcode und erlaubten Prüfweg. Reicht die redigierte Fassung für einen zwingenden Nachweis nicht aus, stellen Sie rechtzeitig eine neutrale Bieterfrage oder nutzen ein ausdrücklich akzeptiertes alternatives Beweismittel. Geschützte Dateien werden nicht eigenmächtig über einen anderen Kanal versandt.

- Kennzeichnen Sie jede Seite mit Ausprägung, Version, Datum und Offenlegungsklasse.
- Prüfen Sie Bildmetadaten und ausgeblendete Ebenen vor dem Export.
- Verwenden Sie dieselben Komponenten- und Flusskennungen in allen Stufen.
- Lassen Sie Sicherheitsbehauptung und Offenlegungsentscheidung getrennt genehmigen.
- Nennen Sie den kontrollierten Prüfweg nur, wenn das Verfahren ihn erlaubt.

## Ein versionsgebundenes Dossier verhindert wandernde Behauptungen

Das Sicherheitsarchitektur-Dossier enthält Vergabefrage, Angebotsbaseline, Schutzkontext, Sichtregister, Angriffspfad-Entscheidungsnachweis, Verantwortungsmatrix, Nachweisindex, Restrisiken, Annahmen, offene Punkte, Schwärzungsverzeichnis, Querprüfungen, Freigaben und Änderungshistorie. Eine eindeutige Version und ein Nachweisstichtag binden diese Bestandteile zusammen. Aus der Antwort führt jede wesentliche Aussage zu einer Kennung im Dossier.

Gleichen Sie wiederholte Aussagen mit Security-Fragebogen, Datenschutzantwort, Integrationskonzept, Betriebsmodell, Notfallvorsorge, Service Levels und Vertragsanlagen ab. Ein Widerspruch bleibt offen, bis die zuständige Stelle eine Quelle oder Zusage berichtigt. Vereinheitlichen Sie die Texte nicht durch das Entfernen einer berechtigten Einschränkung.

Änderungen an Edition, Mandantenmodell, Betriebsort, Identitätsquelle, Schnittstelle, Provider, privilegiertem Weg, Sicherheitsfunktion, Bedrohungsannahme oder Prüfergebnis öffnen die betroffenen Aussagen erneut. Aktualisieren Sie Sicht und Nachweis und kennzeichnen Sie die alte Fassung als abgelöst. So bleibt die freigegebene Kurzantwort mit dem überprüfbaren technischen Stand verbunden.

## Nützliche Ergebnisse

- Die Antwort bleibt auf Vergabefrage, Wertungsmaßstab und angebotene Systemausprägung begrenzt.
- Geschäftsprozesse, Informationen, Akteure, Abhängigkeiten und Schutzbedarf sind eindeutig zugeordnet.
- Jede Architektursicht besitzt Zweck, Geltungsbereich, Abstraktion, Version, Datum und verantwortliche Stelle.
- Relevante Angriffspfade führen zu erkennbaren Präventions-, Erkennungs-, Begrenzungs- und Wiederanlaufentscheidungen.
- Menschliche, technische und Geräteidentitäten werden nicht mit einem vermeintlich vertrauenswürdigen Netz gleichgesetzt.
- Fachliche Daten-, Steuerungs-, Administrations- und Überwachungsflüsse bleiben unterscheidbar.
- Nachweise belegen nur die Ausprägung, Umgebung, Population und Zeitspanne, die sie tatsächlich abdecken.
- Sensible Details werden geschützt, ohne die für die Bewertung nötigen Beziehungen zu entfernen.

## Ablauf

1. **Vergabegegenstand festhalten.** Dokumentieren Sie Frage, Wertung, Los, angebotenen Dienst, Betriebsmodell, Datenarten, Schnittstellen, geforderte Anlage und zulässige Freigaben.
2. **Schutzkontext bestimmen.** Ordnen Sie Geschäftsprozessen und Informationen Schutzbedarf, nicht akzeptable Schäden, rechtliche Vorgaben, externe Akteure und Abhängigkeiten zu.
3. **Angriffspfade auswählen.** Beschreiben Sie relevante Ausgangspunkte, Voraussetzungen, betroffene Zielobjekte, Grenzübertritte, mögliche Auswirkungen und verbleibende Unsicherheiten.
4. **Geeignete Sichten aufbauen.** Nutzen Sie Kontext-, Zonen-, Datenfluss-, Identitäts-, Administrations- und Bereitstellungssichten nur für Entscheidungen, die der Auftraggeber treffen muss.
5. **Sicherheitsfunktionen erklären.** Zeigen Sie Ort, Entscheidungsgrundlage, Betreiber, Abhängigkeit und Ausfallverhalten jeder wesentlichen Sicherheitsfunktion.
6. **Nachweiskette schließen.** Verbinden Sie Architekturaussagen mit freigegebenen Entwürfen, Konfigurationen, Betriebsaufzeichnungen, Tests und unabhängigen Prüfungen desselben Geltungsbereichs.
7. **Offenlegung abstufen.** Erstellen Sie Angebots-, geschützte Bieter-, Due-Diligence- und Prüfersichten; begründen und protokollieren Sie jede Schwärzung.
8. **Widersprüche vor Freigabe klären.** Gleichen Sie Architektur, Security-Fragebogen, Datenschutz, Integration, Wiederanlauf, Betrieb und Vertrag ab und lassen Sie Aussage sowie Offenlegung genehmigen.

## Wichtige Entscheidungen

- Welche Dokumentversion, welches Los und welche angebotene Ausprägung bestimmen die Antwort?
- Welche Geschäftsprozesse und Informationen verursachen welchen Schutzbedarf?
- Welche Schäden, Akteure und Angriffspfade sind für diesen Einsatz relevant?
- Welche Systeme und Pflichten liegen beim Auftraggeber oder bei einem Unterauftragnehmer?
- Welche Sicht beantwortet eine konkrete Anforderung oder Wertungsfrage?
- Wo ändern sich Vertrauen, Datenverantwortung, Berechtigung oder Administrationsmacht?
- Welche Schutzfunktion bleibt beim Ausfall oder bei der Umgehung einer anderen wirksam?
- Wie weit kann sich eine Kompromittierung bewegen, und welche fachliche Auswirkung bleibt möglich?
- Welcher Nachweis belegt Entwurf, Umsetzung, Betrieb oder Prüfung der angebotenen Lösung?
- Welche Information darf ins Angebot und welche benötigt einen kontrollierten Prüfweg?

## Risiken

- Eine Konzern- oder Referenzarchitektur wird als Nachweis für das angebotene System verwendet.
- Das Diagramm zeigt eine Komponente, verschweigt aber deren geplanten statt bestehenden Status.
- Schutzbedarf und Bedrohungen werden nachträglich an ein vorhandenes Schaubild angepasst.
- Ein internes Netz gilt pauschal als vertrauenswürdig, obwohl Identität und Gerätezustand ungeklärt sind.
- Verschiedene Schutzsymbole hängen von derselben ausfallenden Identitäts- oder Managementkomponente ab.
- Cloud-Verantwortung wird vollständig dem Provider zugeschrieben, obwohl Anwendungskonfiguration beim Bieter liegt.
- Redundante Instanzen teilen dieselbe Schwachstelle oder Verwaltungsebene.
- Ein Auditbericht wird außerhalb seines Dienstes, Zeitraums oder Prüfumfangs zitiert.
- Eine Schwärzung verdeckt genau die Grenze, die der Auftraggeber bewerten muss.
- Adressen, Regelwerke, Schwachstellen oder privilegierte Wege gelangen ohne Notwendigkeit ins Angebot.

## Kennzahlen

- wesentliche Aussagen mit Status bestehend, angeboten, angenommen oder offen
- Geschäftsprozesse und Informationen mit begründetem Schutzbedarf
- relevante Angriffspfade mit Entscheidungen für Prävention, Erkennung, Begrenzung und Wiederanlauf
- Sichten mit Zweck, Umfang, Eigentümer, Version, Legende und Nachweisdatum
- erfasste Vertrauensgrenzen sowie Daten-, Administrations-, Steuerungs- und Überwachungsflüsse
- Sicherheitsfunktionen mit Betreiber, Abhängigkeit und Ausfallverhalten
- Architekturaussagen mit passendem Entwurfs-, Umsetzungs-, Betriebs- oder Prüfbeleg
- Schwärzungen mit Grund, Risikoverantwortlichem, Freigabe und kontrolliertem Prüfweg
- ungeklärte Widersprüche oder unbelegte positive Aussagen bei Freigabe; Zielwert null

## Häufige Fragen

### Reicht ein einziges Architekturdiagramm für die Antwort?

Meist nicht. Kontext, Sicherheitsdomänen, Datenflüsse, Identitäten, Administration und Bereitstellung beantworten verschiedene Fragen. Geben Sie für jede benötigte Sicht Zweck, Umfang und Aussagegrenze an.

### Muss die vollständige produktive Netztopologie ins Angebot?

Nur wenn sie ausdrücklich erforderlich ist und über einen genehmigten Weg offengelegt werden darf. Eine redigierte logische Sicht kann die bewertungsrelevanten Beziehungen ohne Adressen, Regeln oder privilegierte Wege zeigen.

### Wie beschreiben wir eine erst nach Zuschlag mögliche Kundenkonfiguration?

Kennzeichnen Sie sie als angeboten. Nennen Sie das erprobte Muster, offene Eingaben, Verantwortlichkeiten, Validierung, Abnahme und die Folge, falls eine Annahme nicht bestätigt wird.

### Belegt eine ISO-Zertifizierung die angebotene Architektur?

Nur innerhalb des im Zertifikat und Prüfbericht genannten Umfangs. Für konkrete Grenzen, Konfigurationen und Verhalten benötigen Sie zusätzliche Entwurfs-, Umsetzungs- oder Prüfnachweise.

### Was gehört zu einer belastbaren Zero-Trust-Aussage?

Benennen Sie Identitäten, Geräte- oder Dienstsignale, Richtlinie, Durchsetzungspunkt, geschützte Ressource und tatsächliche Berechtigung. Der Begriff allein belegt keine Sicherheitsarchitektur.

### Wie viel Bedrohungsdetail darf der Bieter nennen?

Nennen Sie Schaden, Angriffspfad, Architekturreaktion, Begrenzung und Restrisiko. Ausnutzbare Befunde, genaue Abwehrlogik und sensible Betriebsdaten gehören nur in eine zugelassene geschützte Stufe.

### Welche Angaben braucht eine Nachweisreferenz mindestens?

Kennung, Prüfobjekt, Umgebung, Datum oder Zeitraum, Methode, Ergebnis, Einschränkung, Eigentümer und erlaubter Prüfweg. Ein bloßer Berichts- oder Rahmenwerktitel reicht nicht.

### Wer gibt die Architekturantwort frei?

Architektur bestätigt den Entwurf, Informationssicherheit bewertet Bedrohungen und Offenlegung, Kontrollverantwortliche bestätigen Nachweise, Betrieb und Produkt bestätigen den Ist-Stand und die kaufmännische Stelle genehmigt die Zusage.


## Primärquellen

- [BSI-Standard 200-2, IT-Grundschutz-Methodik](https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Grundschutz/BSI_Standards/standard_200_2.pdf?__blob=publicationFile&v=2), Bundesamt für Sicherheit in der Informationstechnik
- [BSI-Standard 200-3, Risikoanalyse auf der Basis von IT-Grundschutz](https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Grundschutz/BSI_Standards/standard_200_3.pdf?__blob=publicationFile&v=2), Bundesamt für Sicherheit in der Informationstechnik
- [IT-Grundschutz-Kompendium](https://www.bsi.bund.de/DE/Themen/Unternehmen-und-Organisationen/Standards-und-Zertifizierung/IT-Grundschutz/IT-Grundschutz-Kompendium/it-grundschutz-kompendium_node.html), Bundesamt für Sicherheit in der Informationstechnik
- [BSI-Lektion zur Schutzbedarfsfeststellung](https://www.bsi.bund.de/DE/Themen/Unternehmen-und-Organisationen/Standards-und-Zertifizierung/IT-Grundschutz/Zertifizierte-Informationssicherheit/IT-Grundschutzschulung/Online-Kurs-IT-Grundschutz/Lektion_4_Schutzbedarfsfeststellung/4_00_Einleitung.html), Bundesamt für Sicherheit in der Informationstechnik
- [NIST SP 800-160 Band 1 Revision 1, Systems Security Engineering](https://csrc.nist.gov/pubs/sp/800/160/v1/r1/final), National Institute of Standards and Technology
- [NIST-Definition der Sicherheitsarchitektur](https://csrc.nist.gov/glossary/term/security_architecture), National Institute of Standards and Technology
- [NIST SP 800-207, Zero Trust Architecture](https://csrc.nist.gov/pubs/sp/800/207/final), National Institute of Standards and Technology
- [NIST Cybersecurity Framework 2.0](https://www.nist.gov/publications/nist-cybersecurity-framework-csf-20), National Institute of Standards and Technology
- [NIST SP 800-53 Revision 5, Sicherheits- und Datenschutzkontrollen](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final), National Institute of Standards and Technology
- [NIST SP 800-53A Revision 5, Prüfung von Kontrollen](https://csrc.nist.gov/pubs/sp/800/53/a/r5/final), National Institute of Standards and Technology
- [NIST SP 800-218, Secure Software Development Framework](https://csrc.nist.gov/pubs/sp/800/218/final), National Institute of Standards and Technology
- [NCSC-Grundsätze für den Entwurf sicherer Systeme](https://www.ncsc.gov.uk/collection/cyber-security-design-principles/cyber-security-design-principles), UK National Cyber Security Centre
- [NCSC, Kontext vor dem Systementwurf bestimmen](https://www.ncsc.gov.uk/collection/cyber-security-design-principles/establish-the-context-before-designing-a-system), UK National Cyber Security Centre
- [NCSC, Auswirkungen einer Kompromittierung begrenzen](https://www.ncsc.gov.uk/collection/cyber-security-design-principles/reducing-the-impact-of-compromise), UK National Cyber Security Centre
- [NCSC-Grundsätze für domänenübergreifende Architekturen](https://www.ncsc.gov.uk/collection/cross-domain/cross-domain-design-principles), UK National Cyber Security Centre
- [OWASP Threat Modeling Project](https://owasp.org/www-project-threat-modeling/), OWASP Foundation
- [OWASP Application Security Verification Standard 5.0](https://owasp.org/www-project-application-security-verification-standard/), OWASP Foundation
- [MITRE ATT&CK für Unternehmen](https://attack.mitre.org/), MITRE
- [Vergabeverordnung § 58, Zuschlag und Zuschlagskriterien](https://www.gesetze-im-internet.de/vgv_2016/__58.html), Bundesministerium der Justiz und Bundesamt für Justiz
- [Richtlinie 2014/24/EU zu technischen Spezifikationen und Nachweisen](https://eur-lex.europa.eu/eli/dir/2014/24/oj/deu), EUR-Lex


## Weiterführende Artikel

- [Security Questionnaires mit Nachweisen automatisieren](https://zephior.com/de/solutions/security-questionnaire-automation)
- [SaaS-RFP und separaten Sicherheitsfragebogen koordinieren](https://zephior.com/de/industries/coordinate-a-saas-rfp-and-security-questionnaire)
- [Wie ordnen Sie Datenschutzunterlagen einer RFP-Frage zu?](https://zephior.com/de/insights/map-privacy-controls-to-rfp-questions)
- [Healthcare-RFPs mit Patientendaten fundiert beantworten](https://zephior.com/de/industries/answer-healthcare-rfps-involving-patient-data)