ECSS vs. ISO 27001/BSI: Wo unsere Verantwortung beginnt
ECSS, ISO 27001 und BSI: drei Welten, eine Mission
Im Satellitenbetrieb treffen zwei Normwelten aufeinander, die oft verwechselt werden. Die Raumfahrtnorm ECSS regelt die flugkritische Engineering-Domäne, ISO 27001 und der BSI-Grundschutz regieren die Boden-IT. Wer diese Grenze sauber zieht, vergibt Aufträge richtig. Wie groß das Feld am Boden inzwischen ist, zeigt eine Marktanalyse von MarketsandMarkets: Der Markt für Satellitenbodenstationen wächst von rund 41 Milliarden US-Dollar im Jahr 2025 auf 82,7 Milliarden bis 2030, und das Segment Ground-Station-as-a-Service legt mit etwa 20 Prozent jährlich am schnellsten zu. Hinter diesem Wachstum steckt eine klare Verschiebung: weg von Spezialhardware, hin zu software-definiertem Betrieb. Genau dort entsteht der Bedarf an verlässlichen Software-Zulieferern – und damit die Frage, wer für welche Schicht geradesteht. Den größeren Rahmen dieses Themenfelds spannt die Übersichtsseite zur Software für Erdbeobachtung und Fernerkundung auf.
Was ist die ECSS und wofür steht sie?
ECSS steht für European Cooperation for Space Standardization, ein von der ESA getragenes Normenwerk für Raumfahrtprojekte. Es gliedert sich in drei Zweige: Engineering (E), Quality beziehungsweise Product Assurance (Q) und Management (M). Die ECSS ist die gemeinsame Sprache der europäischen Raumfahrt. Wichtig ist die Abgrenzung zur bloßen Abkürzung: ECSS hat nichts mit Stahlbau, Kernkraft-Notkühlung oder Komplexitätsforschung zu tun, die unter ähnlichen Kürzeln firmieren. In der Raumfahrt meint ECSS ausschließlich dieses Standardisierungswerk, dessen Dokumente frei über das ECSS-Portal zugänglich sind. Für Software sind nur zwei dieser Normen wirklich entscheidend.
Wofür gelten ECSS-E-ST-40 und ECSS-Q-ST-80?
ECSS-E-ST-40 beschreibt den Software-Engineering-Lebenszyklus, von der Anforderung über Design und Code bis zu Test und Wartung. ECSS-Q-ST-80C ergänzt ihn um die Software Product Assurance, also die Qualitätssicherung über den gesamten Lebenszyklus. Beide Normen betrachten dieselbe Arbeit aus zwei Blickwinkeln. Sie verlangen eine durchgängige Nachweiskette: jede Anforderung verfolgbar, jeder Testfall dokumentiert, jede Abweichung begründet. Dieser Aufwand ist gewollt, denn er gilt vor allem dort, wo ein Softwarefehler die Mission gefährdet. Für eine reine Bodensoftware ohne flugkritische Funktion wäre dieselbe Strenge unverhältnismäßig – und genau hier setzt die Verantwortungsteilung an.
ISO 27001 und BSI-Grundschutz: die Sprache der Boden-IT
Während die ECSS auf die Raumfahrttechnik zielt, regeln ISO 27001 und der BSI IT-Grundschutz die Informationssicherheit klassischer IT-Systeme. ISO 27001 liefert das Managementsystem, der BSI-Grundschutz die konkrete Methodik, BSI C5 die Kriterien für Cloud-Dienste. Das ist die Welt, in der das Bodensegment tatsächlich lebt. Eine nach ISO 27001 entwickelte Software ist auditfähig, vergabetauglich und für Prüfer wie Auftraggeber unmittelbar verständlich. Diese Rahmenwerke sind kein Ersatz für die ECSS, sondern für eine andere Schicht zuständig: nicht für den Satelliten im Orbit, sondern für die Software, Daten und Sicherheit am Boden.
Wo sich die Verantwortung teilt: flugkritisch und bodengebunden
Die entscheidende Trennlinie verläuft nicht zwischen guter und schlechter Software, sondern zwischen flugkritischer und bodengebundener. Beide Welten brauchen Qualität, aber unterschiedliche Nachweise. Die eine wird über Jahre qualifiziert, getestet und für eine einzige Mission gehärtet, die andere muss skalierbar, integrierbar und gegen Cyberangriffe gehärtet sein. Diese Unterscheidung ist mehr als eine Formalie: Sie bestimmt, welcher Partner welche Aufgabe seriös übernehmen kann und wo überzogene Versprechen beginnen würden.
Was unterscheidet flugkritische Software von Bodensoftware?
Flugkritische Software läuft an Bord des Satelliten und steuert Funktionen, deren Ausfall die Mission kostet: Lageregelung, Energieversorgung, Antrieb. Sie wird unter ECSS qualifiziert, oft auf Spezialhardware, mit jahrelanger Verifikation. Ihr Maßstab ist die Unumkehrbarkeit eines Fehlers im Orbit. Bodensoftware dagegen empfängt, verarbeitet und verteilt Daten am Boden – sie lässt sich aktualisieren, neu starten und absichern wie jede anspruchsvolle IT. Die Telemetrie-Auswertung gehört dazu, wie der Schwestertext zur Satelliten-Telemetrie-Software zeigt, ebenso die EO-Datenprozessierung und ihre Bereitstellung. Wer beide Welten vermischt, riskiert entweder gefährliche Lücken oder unnötig teure Überqualifizierung.
Gilt ECSS auch für das Bodensegment?
Grundsätzlich kennt die ECSS auch Anforderungen an Ground Software, denn ECSS-E-ST-40 und ECSS-Q-ST-80 unterscheiden nach Kritikalität, nicht pauschal nach Ort. Entscheidend ist die Funktion, nicht der Standort. In der Praxis trifft die schwere Qualifikation jedoch die flug- und missionskritischen Teile, während die kommerzielle Boden- und Downstream-Software über ISO 27001, BSI-Grundschutz und BSI C5 geführt wird. Diese IT-Standards sprechen die Sprache, in der Behörden und Auftraggeber prüfen, und sie passen zu Systemen, die im Dauerbetrieb wachsen und integriert werden müssen. Ein Satellitenbetreiber gewinnt also nichts, wenn er reine Bodensoftware durch das volle ECSS-Korsett zwängt – er verliert Zeit und Budget.
Die Kritikalitätskategorien der ECSS
Die ECSS skaliert ihre Anforderungen über vier Kritikalitätskategorien, von katastrophal bis vernachlässigbar. Eine Software erhält dabei die Kategorie ihrer kritischsten Funktion. Je höher die Kategorie, desto strenger Test und Nachweis. Das sogenannte Tailoring legt fest, welche Anforderungen für welche Kategorie verbindlich sind:
- Kategorie A – katastrophal: Verlust der Mission oder schwere Folgen
- Kategorie B – kritisch: erhebliche Beeinträchtigung der Missionsziele
- Kategorie C – mäßig: begrenzte, beherrschbare Einbußen
- Kategorie D – gering bis vernachlässigbar: minimale Auswirkung
Bodensoftware ohne flugkritischen Bezug landet typischerweise in den unteren Kategorien – ein klares Indiz dafür, dass IT-Standards der angemessenere Rahmen sind.
Make-or-Buy für NewSpace: was sich auslagern lässt
NewSpace lebt von Geschwindigkeit, und genau deshalb lagern Betreiber das aus, was nicht zu ihrem Kern gehört. Eine PwC-Studie zu Ground Segment as a Service beschreibt, wie Anbieter Investitionskosten in laufende Kosten verwandeln und das Risiko verlagern. Die Software am Boden ist der natürliche Kandidat zum Zukauf. Dass es sich dabei um einen reifen Markt handelt, zeigt die NewSpace Initiative des BDI: Rund 120 Unternehmen und Verbände sind organisiert, und 76 Prozent der NewSpace-Unternehmen haben bereits Kunden außerhalb der Raumfahrt. Die Make-or-Buy-Frage lässt sich entlang einer einfachen Logik beantworten – wer trägt die Verantwortung für welche Schicht?
| Software-Schicht | Maßgebliche Norm | Wer verantwortet |
|---|---|---|
| Flug-/Bordsoftware (Lage, Antrieb, Energie) | ECSS-E-ST-40 / Q-ST-80 | Betreiber bzw. Raumfahrt-Spezialist |
| Telemetrie-Auswertung, Mission-Daten am Boden | ISO 27001 / BSI-Grundschutz | IT-Software-Partner |
| Datenprozessierung und -bereitstellung | ISO 27001 / BSI C5 | IT-Software-Partner |
| Plattform, Schnittstellen, Integration in Fachsysteme | ISO 27001 / BSI-Grundschutz | IT-Software-Partner |
| Informationssicherheit und Betrieb | ISO 27001 / BSI C5 / NIS-2 | IT-Software-Partner |
Welche Schichten ein IT-Partner übernimmt
Ein erfahrener Softwarepartner übernimmt die gesamte boden- und datengebundene Schicht: Verarbeitungspipelines, Plattformen, Schnittstellen und die Auswertung bis hin zur Anzeige. Das ist klassische Ingenieursarbeit, kein Raketenbau. Dazu gehören die Integration in bestehende Fachsysteme, eine belastbare EO-Datenplattform mit offenen Standards sowie die Visualisierung in einem Geodaten-Dashboard. Für sensible Bestände kommt eine souveräne Cloud-Lösung infrage, wo es fachlich sinnvoll ist. Diese Schichten sind aktualisierbar, skalierbar und über IT-Standards prüfbar – sie lassen sich also ohne Risiko in erfahrene Hände geben.
Was beim Satellitenbetreiber bleibt
Beim Betreiber oder seinem Raumfahrt-Spezialisten bleibt, was Missionserfahrung, Spezialhardware und jahrelange Qualifikation verlangt: die flugkritische Bordsoftware und ihre Verifikation nach ECSS. Diese Verantwortung lässt sich nicht delegieren. Eine reine Softwareagentur kann und sollte sie nicht übernehmen, denn dafür fehlen ihr Prüfumgebungen, Flugerbe und Qualifikationsnachweise. Genau diese ehrliche Grenze ist der Kern dieses Leitfadens – und zugleich ein Qualitätsmerkmal: Ein Partner, der seine Grenzen klar benennt, liefert auch innerhalb dieser Grenzen verlässlich. Überzogene Versprechen dagegen kosten am Ende beide Seiten.
ECSS oder ISO 27001: welche Norm gilt für welche Schicht?
Die kurze Antwort lautet: ECSS für das Fliegende, ISO 27001 und BSI für das Bodengebundene. Nicht die Herkunft des Projekts entscheidet, sondern die Funktion der Software. Wer eine Bodenplattform, eine Auswertekette oder eine Schnittstelle vergibt, fragt nach ISO 27001, BSI-Grundschutz und – sobald das Bodensegment als kritische Infrastruktur gilt – nach NIS-2 und KRITIS. Wer Bordsoftware qualifizieren lässt, fragt nach ECSS und Flugerbe. Diese Trennung macht Ausschreibungen präziser und Angebote vergleichbar.
Braucht ein Software-Dienstleister eine ECSS-Zertifizierung?
Für die Bodensoftware ist eine ECSS-Zertifizierung in aller Regel weder nötig noch sinnvoll. Maßgeblich sind hier IT-Sicherheitsnachweise, nicht Raumfahrtqualifikation. Ein Dienstleister, der die Daten-, Plattform- und Sicherheitsschicht verantwortet, weist seine Eignung über ISO 27001, BSI-Grundschutz und C5 nach – also über die Standards, in denen Betrieb und Audit am Boden tatsächlich stattfinden. Wer von einem reinen Software-Partner eine ECSS-Zertifizierung verlangt, adressiert die falsche Schicht und verengt den Wettbewerb ohne Sicherheitsgewinn. Sinnvoll ist umgekehrt zu prüfen, ob der Partner Informationssicherheit von der ersten Zeile an mitdenkt.
Warum ISO 27001 und BSI-Grundschutz für die Bodensoftware ausreichen
Das Bodensegment ist heute die am stärksten exponierte Angriffsfläche, weil es auf konventioneller IT aufsetzt. Die ENISA-Analyse zur Bedrohungslage im Weltraum benennt genau diese Bodenseite samt Lieferketten- und Insider-Risiken als zentrale Schwachstelle – nicht den Satelliten im Orbit. Sicherheit entsteht dort, wo die Daten verarbeitet werden. Genau das ist die Domäne von ISO 27001 und BSI-Grundschutz: Zugriffskontrolle, Protokollierung, Verschlüsselung und ein gelebtes Sicherheitsmanagement. Diese Standards sind auditfähig, vergabetauglich und für die Bodensoftware vollständig ausreichend. Nachträglich aufgesetzte Sicherheit dagegen bleibt lückenhaft und im Ernstfall wertlos – deshalb gehört sie von Anfang an in die Architektur.
Die Verantwortungsgrenze als Entscheidungshilfe
Die Trennung zwischen flugkritischer und bodengebundener Software ist kein juristisches Detail, sondern eine praktische Entscheidungshilfe für jede Vergabe. ECSS gehört zur Bordsoftware mit ihrer langjährigen Qualifikation, ISO 27001 und BSI-Grundschutz gehören zur Software, zu den Daten und zur Sicherheit am Boden. Wer diese Grenze im Lastenheft sauber zieht, vergleicht Angebote auf der richtigen Grundlage. So lassen sich überzogene Erwartungen an einen einzelnen Partner vermeiden und Zuständigkeiten von Beginn an klar verteilen. Für die bodengebundene Schicht zählt dabei, dass individuelle Softwareentwicklung von Anfang an auf Informationssicherheit, Integration und einen planbaren Dauerbetrieb ausgelegt ist – inklusive Wartung und Support über die gesamte Lebensdauer. Erst dann bleibt die Verantwortungsgrenze nicht nur sauber definiert, sondern auch über Jahre belastbar.
