Zusammenfassung

  • Die Identitätsbrücke ist außergewöhnlich stark: derRIPE-Eintrag für AS202842nennt SC HIGH-TECH SYSTEM&SOFTWARE SRL und enthält die Registrierungsnummer 30126940, dieselbe Nummer, die auf HTSS-Software- und Rechtsseiten verwendet wird. Die geringen Unterschiede in Leerzeichen und Pluralformen in öffentlichen Registern beschreiben keine unterschiedlichen rumänischen Unternehmen.
  • AS202842 belegt eine enge historische Netzinfrastruktur: ein beobachtetes IPv4-Präfix, 95.128.174.0/24, eine registrierte Routing-Policy mit Nennungen vonGTS TelecomundVodafone Romania, sowie eineöffentliche Sichtbarkeit, die am 17. Dezember 2025 endete. Sie belegt nicht, welche HTSS-Anwendungen dort liefen, wo deren Daten gespeichert wurden oder ob eine der genannten Verbindungen tatsächlich ein aktives Failover war.
  • Der kommerzielle Randbereich änderte sich, bevor die Route verschwand.Setrio kündigteden Erwerb der Software-Sparte für den Einzelhandel im Februar 2025 an;Smart ID kündigteden Kauf des Business-Solutions-Teams, von Mindclass und Shiftin im Juli an; der alleinige Gesellschafter entschied dann im Septembereine freiwillige Liquidationvorzunehmen. Einaktueller rumänischer Firmeneintragkennzeichnet die ursprüngliche Gesellschaft nun als radiert.
  • Für einen Käufer ist daher entscheidend: produktbezogene und vertragliche Evidenz in Form von Nachfolgeinhaber, Datenfluss und Datenresidenz, aktueller Sicherheitszusicherung, benannter Support-Mitarbeitern, Wiederherstellungstests, Exportformaten und einem einsatzfähigen Übergangsplan. Routingdaten können einen kleinen Teil der Transporthistorie verifizieren, die Beschaffung muss aber weit früher aufhören, diese Historie als direkte Aussage zu Applikation, Sicherheit oder Kontinuität zu verwenden.

Der letzte Morgen der Route

Um 08:00 Uhr UTC am 17. Dezember 2025 änderte sich ein kleines Stück der öffentlichen Internet-Landkarte. Die historische RIPE-Sicht zeigt, dass 95.128.174.0/24, ein Block mit 256 IPv4-Adressen, zu diesem Zeitpunkt zuletzt mit AS202842 als Ursprung gesehen wurde. DerselbeRIPE-Routing-Status-Eintragvermerkt die erste Beobachtung auf den 27. Juli 2016. Einezeitfensterbasierte RIPE-Abfragezeigt, dass das Präfix von Anfang Dezember bis zu diesem letzten Zeitstempel kontinuierlich sichtbar war.

Die Versuchung ist groß, diesen Zeitstempel in eine Unternehmenserzählung zu überführen: Das Netz wurde abgeschaltet, weil die Firma abgeschaltet wurde. Die Daten machen diese Erzählung plausibel, aber sie beweisen sie nicht. LautEconomica-Bericht zur Beschlusslage der Anteilseignerentschied Kaseke Limited am 18. September 2025, High Tech Systems & Software freiwillig zu liquidieren, eine/r Liquidator*in zu bestellen und die Vollmachten der Geschäftsführer zu beenden. Die Route blieb rund drei weitere Monate öffentlich sichtbar. Der Rückzug könnte einer Stilllegung, einem Provider-Wechsel, einer Vermögensübertragung, einer administrativen Entscheidung oder einer anderen Ursache gefolgt haben. BGP enthält keinen Liquidationsvermerk.

Die Unterscheidung ist relevant, weil sich Unternehmens- und Netzwerkzeitachsen nicht gemeinsam anhielten. Im Februar 2025kündigte Setrioan, die HTSS-Sparte für Einzelhandelsapotheken übernommen zu haben. Im Julikündigte Smart IDden Erwerb der Business-Solutions-Division, des kundenspezifischen Software-Teams, von Mindclass und Shiftin an. Im September folgte die Liquidationsentscheidung. Im Dezember verschwand das letzte global sichtbare Präfix. Zum Zeitpunkt dieser Untersuchung markiert derTermene-Eintrag für CUI 30126940das Unternehmen als radiert, während dieRIPE-Registrierungweiterhin existiert und eine Änderung des Organisationsdatensatzes im Mai 2026 enthält.

Diese asynchrone Reihenfolge ist die Kernwarnung. Ein Registereintrag kann nach der Löschung einer juristischen Person fortbestehen. Eine Produktwebsite kann lesbar bleiben, nachdem der benannte Anbieter kein tragfähiger Vertragspartner mehr ist. Eine Route kann nach einem Asset-Verkauf fortbestehen und vor dem Aufholen aller öffentlichen Register verschwinden. Jede Oberfläche besitzt ihren eigenen Wartungszyklus. Keine sollte mit einer Frage belastet werden, die sie nicht beantworten kann.

Zum Stand vom 18. Juli 2026 ist die Netzwerk-Evidenz klar, aber eng. Dieaktuelle RIPE-AS-Übersichtzeigt, dass AS202842 kein Präfix mehr ankündigt. Dieaktuelle Präfixabfrageliefert für den 4.–18. Juli kein Ergebnis.IPinfo klassifiziert die ASN unabhängig als inaktiv, ohne bekannte Adressräume, gehostete Domains, Peers oder Upstreams in dieser Sicht. Diese Beobachtung rechtfertigt die Aussage, dass die öffentliche Netzwerkoberfläche in üblichen Schwellen nicht mehr sichtbar ist. Sie rechtfertigt nicht die Aussage, dass jede historische Anwendung gestoppt wurde, dass Kundeninstallationen verschwunden sind oder dass keine private Konnektivität mehr besteht.

Eine Nummer löst das Identitätsproblem

Der zugewiesene Name ist unangenehm spezifisch: SC HIGH-TECH SYSTEM&SOFTWARE SRL. Anderswo tritt die Firma als High-Tech Systems & Software S.R.L., HIGH TECH SYSTEMS & SOFTWARE SRL oder einfach HTSS auf. Aus „System“ wird „Systems“; Leerzeichen um den Kaufmanns-Und werden anders gesetzt; das rumänische Gesellschaftspräfix wird vorübergehend weggelassen. Der Name allein ließe Raum für eine falsche Zuordnung.

Die Registrierungsnummer 30126940 schließt diese Lücke. DerRIPE-OrganisationsdatensatzverbindetSC HIGH-TECH SYSTEM&SOFTWARE SRLmitreg-nr: 30126940. Der verbliebeneHTSS-Lösungs-Katalogordnet High-Tech Systems & Software S.R.L., Steuernummer RO 30126940 und Handelsregisternummer J40/4847/2012 im rechtlichen Fußbereich zu. DieTelemedica-Nutzungsbedingungennennen High-Tech Systems & Software SRL, dieselbe Handelsregister- und dieselbe Steuernummer wie das Unternehmen, das den auf der Seite beschriebenen Dienst anbietet. DerTermene-Firmenregistereintragnutzt eine weitere typografische Variante, aber dieselbe CUI.

Das ist mehr als Markenassoziation. Es ist eine Kette von einer öffentlichen Netzregistrierung zu einer rumänischen Rechtskennung und von dort zu Software-Bedingungen und Produktmarketing. Es stützt die Schlussfolgerung, dass AS202842 derselben Rechtsfirma hinter den HTSS-Seiten zugeordnet werden kann. Es verhindert außerdem einen häufigen Fehler: die Verwechslung mit einer ähnlich benannten ausländischen Technologiefirma, einem nicht verbundenen „HTSS“-Domänennamen, einem Mutterinvestor oder einer Produktmarke als der zugewiesenen Firma.

Die Brücke ist sowohl historisch als auch technisch. Als Rumäniens Wettbewerbsrat die Übernahme durch Kaseke Limited im Jahr 2021 genehmigte,beschrieb AGERPRES den Zweckals Entwickler und Umsetzer kundenspezifischer und proprietärer Software, als Lieferant von Hardware-Infrastruktur sowie als Anbieter von Wartung und Support für die von ihm entwickelten IT&C-Services. Diese unabhängige Quelle verknüpft die Rechtsgesellschaft sowohl mit Application-Arbeit als auch mit Infrastrukturbereitstellung. Sie ist ein stärkeres Indiz für die Betriebskette als eine reine ASN.

Aber dieselbe Kennung, die die Vergangenheit belegt, begrenzt zugleich Aussagen über die Gegenwart. Der aktuelle Firmeneintrag für 30126940 nennt das Unternehmen radiert. Die öffentlich zugänglichen Telemedica-Bedingungen benennen diese Zahl weiterhin als Servicegesellschaft. Beide Aussagen können wahr sein, weil sie auf unterschiedlichen Aktualisierungszyklen beruhen; zusammen beantworten sie nicht, wer heute gültig einen neuen Servicevertrag unterschreiben könnte.

Die korrekte Reaktion ist nicht, die bequemer erscheinende Seite zu wählen, sondern ein aktuelles Handelsregisterzeugnis und eine dokumentierte Kette zu verlangen, die den relevanten Vertrag, geistiges Eigentum, Datenverarbeitungsaufgaben und Support-Verpflichtungen auf einen live-rechtlichen Vertragspartner überträgt.

Was die operative Gesellschaft nachweislich tat

Auf der weiten öffentlichen Oberfläche wirkte HTSS weniger wie ein reines Cloud-Abonnementgeschäft, sondern eher wie ein kombiniertes Softwarehaus, Systems Integrator und Support-Operator. DerAGERPRES-Bericht von 2021nennt die breiten Kategorien: kundenspezifische Anwendungen, proprietäre Anwendungen, Hardware-Infrastruktur sowie Wartung und Support. Dereigene Katalogergänzt Produkt- und Workflow-Namen: Apothekenverwaltung, Omnimedica für Ärzte und Kliniken, Telemedica, Mindclass, kundenspezifige Entwicklung und IT-Infrastrukturdienste inklusive Sicherheit, Anwendungsentwicklung, Migration und Datenspeicherung.

Erste Inhouse-Kataloge beschreiben Absichten, nicht Auslieferung. Zwei Beschaffungseinträge machen die Software- und Support-Aktivität konkreter. DasRumänische Rechnungshof-Register 2024listet HIGH-TECH SYSTEMS & SOFTWARE SRL für einen RON-58.459-Vertrag zur Wartung einer behördlichen Lernplattform und kennzeichnet ihn als abgeschlossen. Ein separaterÖffentliche Vergabewert 2024identifiziert dieselbe Firma unter RO30126940 als Gewinner eines RON-374.900-Vertrags für Learning-Management-Services. Der zweite Datensatz ist ein Aggregator statt der originären Vergabemitteilung, daher dient er als Bestätigung, nicht als Basis für extensive Schlussfolgerungen. Kein Datensatz rechtfertigt eine Umetikettierung als Mindclass ohne vertraglichen Text.

Die Gesundheitsseite ist ebenfalls der Rechtsentität zugeordnet und nicht nur zu einer Marke. DieTelemedica-Bedingungenbezeichnen das Produkt als kostenpflichtiges B2B-Software-as-a-Service-Angebot und nennen Unternehmensnummer 30126940. Die Bedingungen beschreiben Browser- und mobilen Zugriff, Kundenadministratoren und Nutzer, kostenpflichtigen Zugriff nach separater Vereinbarung sowie Kontoinformationen wie Name, E-Mail und Organisationsrolle.Die öffentliche Telemedica-Seitezeigt Video- und Chat-Konsultationen, Termin- und Patientenhistorie-Workflows. Das sind Aussagen der Produktseite, aber die rechtliche Seite macht die Zuordnung Firma-zu-Produkt belastbar.

Mindclass besitzt eine ebenso direkte, produktbezogene Brücke. Einevon Microsoft gehostete Zertifizierungsseite für den Publishernennt High-Tech Systems & Software SRL als Partnerfirma von Mindclass und datiert die Entwicklerantworten auf den 30. August 2024. Sie beschreibt eine mit Azure verbundene Lernanwendung. Wiederum ist die Beweisgrenze klar: Sie sagt etwas über die Selbstaussagen des Entwicklers für eine Anwendung zu einem Zeitpunkt. Sie macht Azure nicht zur Architektur des Apothekenpakets, von Telemedica oder von kundenspezifischen Projekten.

Das Apothekensortiment hatte den tiefsten operativen Fußabdruck in der öffentlichen Darstellung. Der HTSS-Katalog nannte Software für Apothekenmanagement, während eineTransaktionsankündigung aus 2025DataKlas Pharmaceutical und Pharma Original als Produkte der von Setrio übernommenen Einzelhandels-Apothekensoftware identifizierte. Eine bestandskräftige regulatorische Dokumentation gibt zusätzlichen Marktvergleich: Das2024 Universal Registration Document von Cegedimnennt HTSS, Setrio und Softeh als Hauptwettbewerber im rumänischen Apotheken-Softwaremarkt, macht aber klar, dass es eine eigene Markteinschätzung ist.

Diese Evidenz unterstützt einen substantiellen historischen Betreiber: Anwendungsentwicklung, regulierte Industrieworkflows, Infrastrukturlieferung, Support und öffentliches Lern-Serviceteil. Sie unterstützt aber nicht eine einheitliche Architektur. Eine kundenspezifische Anwendung auf Kundensystemen, ein Apothekensystem mit fiskalen Geräten, ein Teams-Lernserviceder mit Azure betrieben wird, ein Telemedizin-Webservice und ein geroutetes /24 können zu einem Lieferantenportfolio gehören, ohne dieselbe Hosting-Schicht zu teilen. Beschaffung geht schief, wenn die Unternehmensliste fälschlich als produktbezogenes Abhängigkeitsdiagramm behandelt wird.

Was AS202842 tatsächlich belegt

Ein autonomes System ist eine administrative Einheit der Internet-Routenführung, nicht ein Serverkatalog.RFC 4271definiert BGP als Protokoll, das Erreichbarkeitsinformationen zwischen autonomen Systemen austauscht. Das AS_PATH teilt anderen Routern mit, welche autonomen Systeme eine Ankündigung durchlaufen hat. Es kann zeigen, dass ein Netz ein Präfix angekündigt hat und über welche externen Netze die Route lief. Es wurde nie dafür entwickelt, einen Softwarelizenzinhaber, eine Datenbank-Engine, einen Patientendatenspeicher oder einen Support-Desk zu identifizieren.

DieRIPE-Dokumentation für einenaut-num-Datensatzist ebenso präzise. Ein solcher Datensatz repräsentiert ein autonomes System und dessen externe Routing-Policy; die eingehenden und ausgehenden Policy-Attribute beschreiben, welche Routen ein Betreiber annehmen oder ankündigen möchte. Im registrierten Datensatz von AS202842 erklärt die Gesellschaft, dass sie Routen von AS5606 und AS12302 akzeptiert und AS202842 jeweils an sie ankündigt. Der Status ist „assigned“ und der Datensatz stammt aus Mai 2016.

Die beobachtete Oberfläche war klein.Die RIPE-Routing-Status-Historieidentifiziert nur 95.128.174.0/24 als erstes und letztes beobachtetes Ursprungspräfix. Im aktuellen Status wurde kein IPv6-Raum beobachtet. Ein /24 ist der kleinste IPv4-Präfix, der in der Regel ohne weit verbreitetes Filtern im öffentlichen Internet transportiert wird, was jedoch nichts darüber aussagt, wie die Adressen tatsächlich genutzt wurden. Der wesentliche unternehmensspezifische Punkt ist die Skalierung: Die öffentliche Ursprungsbeweislage deckt 256 Adressen ab, nicht ein unbestimmtes globales Portfolio.

Was kann ein Käufer sachlich daraus ableiten? Erstens hatte HTSS einmal genügend Kontrolle über die Netzwerkrichtlinie, um über die eigene ASN ein öffentliches Präfix zu originieren. Das deutet auf eine absichtlich verwaltete Perimeterkante hin statt ausschließlicher Nutzung von Adressen eines Hosting-Anbieters. Zweitens zeigen zwei benannte externe Provider in der registrierten Policy die Absicht mehrerer Pfade an. Drittens spricht die Persistenz des Präfixes bis Dezember 2025 dafür, dass mindestens ein Netzwerk-Setup nach den Asset-Transfers und der Liquidationsentscheidung sichtbar blieb.

Jede Schlussfolgerung braucht eine Bremse. Die Ankündigung eines Präfixes beweist nicht, dass das zugrunde liegende Adressblock-Eigentum dort liegt; Routenursprung, Adressregistrierung und physische Anlage können auf verschiedene Parteien verweisen. Zwei Policy-Zeilen beweisen keine zwei parallelen Arbeitszustände, keine echte Diversität der Glasfaserpfade und kein automatisches Failover. Ein öffentliches /24 zeigt nicht, ob es Produktionsverkehr, Desaster-Recovery, Büro-Internet, VPN-Endpunkte, Monitoring, E-Mail oder gar nichts kundensichtbares trug. Der letzte Zeitstempel identifiziert keinen Serviceausfall.

Der Datensatz zeigt die Kontrolle am Routing-Rand und fast nichts darüber hinaus.

Die aktuelle Beobachtung ist noch enger. DerRIPE-Übersichtsberichtmeldet am 18. Juli 2026 keine qualifizierte Ankündigung, und diezweiwöchige Präfixabfragegibt eine leere Liste zurück. Das bedeutet, Beschaffung kann AS202842 nicht als Beweis für eine derzeitig erreichte Produktionskante verwenden. Es bedeutet aber auch, dass eine Leerstelle der Route nicht den Schluss zulässt, dass übertragene Produkte offline sind: diese Produkte könnten migriert worden sein, konnten stets anderswo liegen, in Kundensystemen betrieben werden oder Adressraum eines Cloud-Anbieters genutzt haben.

Zwei erklärte Provider, nur ein beobachteter Nachbar

Die beiden Policy-Gegenstellen sind keine Randgruppe. DieRIPE-Übersicht für AS5606identifiziert den Backbone von GTS Telecom SRL. DieÜbersicht für AS12302identifiziert Vodafone Romania. Auf dem Papier ist dies eine plausible Dual-Provider-Kante für einen rumänischen Unternehmensanbieter: zwei große externe Netze und eine Kunden-ASN, die dieselbe Identität gegenüber beiden anmeldet.

Aber Registrierung und Beobachtung divergieren. EineRIPE-Historische-Nachbarschaftsabfrageliefert in der betrachteten Phase AS5606 als einzigen linken Nachbarn im Snapshot. AS12302 wird nicht zurückgegeben. Das Abdeckungsmuster des Collectors ist nicht vollständig, also ist dies kein Beweis für eine Trennung von Vodafone; es ist der Nachweis, dass die eingefrorene öffentliche Beobachtung GTS bestätigt und Vodafone dort nicht unabhängig bestätigt.

Sogar die GTS-Nennung verlangt präzise Formulierungen.GTS gibt an, Rechenzentrum in Bukarest und Cluj-Napoca zu betreiben und Colocation- sowie Cloud-Services zu verkaufen. Es wäre leicht, HTSS-Hardware annehmen zu können, wenn man diese Assoziation zieht. Aus den hier vorliegenden Quellen gibt es keinen solchen Nachweis. Ein Transit-Pfad durch das GTS-Backbone kann bei einem Kundenstandort, einem vermieteten Rack, einem Carrier Hotel oder einem Managed Service enden. Die Angebotsliste des Providers ersetzt kein Architekturdiagramm von HTSS.

Und auch eine Doppel-Provider-Absicht ist nicht automatisch physische Resilienz. Zwei BGP-Sitzungen können denselben Gebäudeeingang, dieselbe Stromversorgung, denselben Router, dieselbe Firewall, dieselbe Cross-Connect-Trasse oder denselben Konfigurationsfehler teilen. Eine Verbindung kann kalter Standby sein. Eine Policy kann veraltet sein. Die Provider können gemeinsame Infrastruktur nachgelagert teilen. Die einzige sichere Netzfolgerung ist, dass die registrierte Policy zwei externe Systeme benennt und dass dieRIPE-Abfrage in der gewählten Historie nur einen davon bestätigt.

Für die Beschaffung führt diese Unterscheidung zu einem Dokumentenbedarf. Behauptet ein Service-Nachfolger Carrier-Diversität, sollte er die produktspezifische Topologie unter Vertraulichkeit offenlegen: Demarkationspunkte, Standorte, letzte Meile, Edge-Hardware, Ausfallsicherungsmethode, Monitoring-Eigentümer und kürzlich dokumentierte Failover-Tests. Der AS-Datensatz ist ein nützlicher Abgleichspunkt gegen dieses Diagramm, aber kein Ersatz für das Diagramm.

Der Anwendungsbestand war größer als die geroutete Kante

Die Diskrepanz zwischen einem /24 und einem breiten Softwarekatalog ist nicht verdächtig; sie ist für einen Integrator normal. Entscheidend ist, dass der Katalog sehr unterschiedliche Kundenworkflows beschreibt und damit sehr unterschiedliche Ausfallfolgen.

Im Apothekenhandel standen die übertragenen Produkte nahe bei Bestand, Verkauf, Steuer- und Regulierungsprozessen. DieSetrio-Übernahmeankündigungversprach, dass Kunden ihre bestehenden DataKlas Pharmaceutical- oder Pharma Original-Anwendungen behalten würden, während Setrio Expertise und Support bündelt. Diese Zusage zeigt das Wechselproblem selbst ohne veröffentlichte Architektur: Apothekenkunden waren so eingebunden, dass Kontinuität den Erhalt der aktuellen Anwendung bedeutete, nicht eine sofortige Migration.

Im Lernsegment lagen die Workflows bei Identität, Einschreibung, Inhalten, Bewertung und organisatorischem Reporting. DieMicrosoft-Publisher-Bescheinigung für Mindclasssagt, dass die Anwendung Namen, Nachnamen, E-Mail-Adressen und Unternehmensrollen verarbeitet, mit Microsoft-Identität integriert ist und eine delegierte BerechtigungUser.Readnutzt. HTSS'Katalogbeschreibungordnet Mindclass der Mitarbeiterschulung und Shiftin der Dienstplanung zu. Das sind Flächen mit Betriebssteuerung: Zugriffsregeln, Personaldaten, Kursverlauf, Schichtbeschränkungen und Management-Reporting, nicht nur Webseiten.

In der Telemedizin verschiebt sich das Risiko erneut. DieTelemedica-Bedingungenbeschreiben eine B2B-Anwendung, in der Kundenadministratoren Nutzer anlegen und Zugänge steuern. DieDatenschutzerklärungnennt Geräte-, Orts- und Nutzungsdaten und unterscheidet Situationen, in denen das Unternehmen als Verantwortlicher agiert oder als Prozessor im Rahmen von Supportleistungen. Das Marketing beschreibt Krankheitsgeschichte, Termine, Video- und Chatfunktionen. Eine Routenankündigung kann nicht zeigen, ob Konsultationsdaten verschlüsselt ruhend gespeichert sind, ob Video durch Relais oder Peer-to-Peer läuft, ob Sicherungen Gesundheitsdaten enthalten oder welche Partei im Störfall wiederherstellen kann.

Individuelle Software macht die Unternehmensebene am schwächsten. Ein Entwicklungsteam kann Anwendungen in ein Kunden-Tenant oder Rechenzentrum liefern, einen gehosteten Service betreiben, eine Plattform eines Dritten warten oder bei Abnahme Code übergeben.Das AGERPRES-Papier von 2021bestätigt, dass HTSS eigene Entwicklung, proprietäre Software, Hardware-Infrastruktur und Wartung verband. Es sagt nicht, dass alle diese Aktivitäten auf AS202842 beruhten.

Die plausible Architektur ist daher heterogen: Einige Services können die Unternehmenskante genutzt haben, manche eine Public-Cloud, manche im Kundenumfeld laufen, manche mehrere Arrangements kombinieren. Das ist keine verifizierte Topologie, sondern eine aus den unterschiedlichen Bereitstellungsarten abgeleitete Hypothese. Eine Beschaffung muss die Antwort pro Serviceinstanz verlangen. Jede Due-Diligence, die das gesamte Portfolio als „selbstbetrieben in Rumänien“ wegen AS202842 einstuft, oder aus Mindclass auf ein„gehostet in Azure Ireland“ für allesschließt, überschreitet die Beweisschwelle.

Der Portfolio-Split änderte die Kontinuitätsfrage

Vor 2025 konnte ein Kunde plausibel alles bei einem Unternehmen zu Software, Infrastruktur und Support anfragen. Nach den offen gelegten Übertragungen wurde die Frage „Betreibt HTSS noch?“ zur falschen Frage. Die sinnvolle Frage ist: „Welche aktive Partei besitzt und betreibt genau diese Bereitstellung, unter welcher übertragenen Verpflichtung?“

Der erste Split war sektorspezifisch. Am 13. Februar 2025 sagte dieSetrio-Ankündigung, dass es die HTSS-Sparte für Einzelhandelsapotheken übernommen habe, die DataKlas Pharmaceutical und Pharma Original hielt. Setrio sagte, jeder Kunde behält seine bestehende Software, operative Kontinuität sei ein Ziel, und das kombinierte Team verbessere den technischen Support. Das sind sinnvolle Zusagen des Käufers, bleiben aber Zusagen. Eine Apotheke sollte weiterhin den novierten Vertrag, Supportkontakte, Eigentum an Releases, Quellcode-Haftung und den Wartungsfahrplan der eingesetzten Version prüfen.

Die zweite Aufteilung war fähigkeitsspezifisch. Am 11. Juliberichtete Smart ID, dass es die Business-Solutions-Division, ein Team mit Erfahrung in Architektur, kundenspezifischer Entwicklung und Bereitstellung sowie Mindclass und Shiftin erworben habe. Das aufnehmende Unternehmen erklärte, das Team in seinen Bereich „Logistics and Business Solutions“ zu integrieren. Der Finanzvorstand von HTSS stellte die Transaktion als Kontinuität für übertragene Produkte und Personen dar. Für Nutzer dieser benannten Produkte ist das stärkste öffentliche Nachfolge-Signal im eingefrorenen Datensatz.

Die genannten Sets decken nicht alles ab. Weder dieSetrio-Mitteilungnoch dieSmart-ID-Mitteilungnennen Telemedica, omnimedica, AS202842 oder jede Infrastruktur- und Support-Verpflichtung. Das Fehlen eines Namens in einer Pressemitteilung beweist nicht, dass ein Asset hinterblieb, verlagert wurde, eingestellt wurde oder unter einem breiteren Begriff gebündelt wurde. Es bedeutet nur, dass die öffentliche Kette unvollständig ist. Die Restdienste einem anderen Akteur ohne Transaktionsunterlagen zuzuordnen wäre eine Erfindung; derLiquidationsberichtliefert diese fehlende Asset-Kette nicht.

Die Liquidationsentscheidung machte die fehlende Kette anschließend kommerziell dringlich. DieEconomica-Berichterstattungzeigt, dass der alleinige Gesellschafter am 18. September die freiwillige Auflösung beschloss. Dieselbe Veröffentlichung im Vergleich zuTargetare-Zahlen 2024zeigt ein Unternehmen mit noch erheblicher Bilanzgröße: rund 118 Millionen RON Umsatz, einen Verlust von 67,7 Millionen RON, 74,6 Millionen RON Schuld und durchschnittlich 337 Beschäftigte. Die Größe eliminierte nicht das Kontinuitätsrisiko.

Der aktuelleTermene-Eintragmarkiert die CUI 30126940 als radiert. Dieser Status verschiebt die Nachweispflicht. Ein Käufer darf kein altes Website, kein altes Rechnungsvorlage oder bekannte Support-Adresse als Beweis für den Gegenpart akzeptieren. Der Nachfolger muss sich ausweisen, die Rechtsgrundlage seiner Software- und Kundendatennutzung offenlegen und den alten Vertrag mit der neuen Betriebsstruktur abstimmen.

Telemedica ist der unaufgelöste Gegenparteitest

Telemedica macht das Problem deutlicher als einzelne übertragene Produkte, weil seine öffentliche Handelsoberfläche weiterhin offen ist. DiePreisseitebietet einen Monat kostenlos, dann 40 EUR pro Arzt und Monat mit einem Mindestumfang von fünf Ärzten und damit mindestens 200 EUR pro Monat. DieNutzungsbedingungenbezeichnen den Service als kostenpflichtig, B2B und sowohl über Browser als auch mobile App verfügbar. Sie nennen High-Tech Systems & Software SRL, J40/4847/2012 und Steuernummer 30126940 als Firma, die den Service verwaltet.

Dennoch sagt deraktuelle Unternehmensdatensatz für diese Zahl„radiated“ aus. Eine aktive Marketingseite und eine entfernte Rechtsperson sind nicht gleichwertige Indikatoren, die man mittelt. Die Marketingseite kann ein unbeaufsichtigtes Überbleibsel sein, der Service kann in einer Übergangsphase betrieben werden oder eine nicht veröffentlichte Nachfolge existieren. Der öffentliche Datensatz löst nicht, wer hier aktuell Vertragspartner ist.

Die üblichen Vertragsbedingungen wären selbst vor diesem Widerspruch schon schwache Kontinuitätsbelege. Sie erlauben eine Kündigung mit 30 Tagen Frist. Sie erlauben die Übertragung oder Untervergabe ohne Kundenzustimmung. Sie stellen den Service als verfügbar dar, verzichten auf kontinuierlichen Betrieb und nennen die Möglichkeit von Zugriffsunterbrechungen oder Änderungen. Die Preisgestaltung wird teilweise in einer separaten Vereinbarung festgelegt. Für ein kollaboratives Hilfswerkzeug mit geringerem Risiko wäre das aushandelbar.

Für klinische Workflows mit Patientenhistorie, Terminplanung und Kommunikation, erfordern sie einen stärkeren, ausgehandelten Serviceplan.

DieDatenschutzerklärungwirft weitere Fragen auf. Sie nennt einen Cloud-Drittanbieter als Unterauftragsverarbeiter, doch der Providerlink ist leer. Sie sagt, Daten könnten auf Servern des Unternehmens oder Unterauftragsverarbeiters liegen, jedoch ist ein anderer Serverbezug ebenfalls leer. Die Aufbewahrungsdauer für Anmelde- und Zugriffsprotokolle ist ebenfalls nicht spezifiziert. Die Richtlinie listet mögliche Support-, Hosting-, Analyse-, E-Mail- und SMS-Anbieter auf, ohne ein aktuelles benanntes Set oder Standorte zu veröffentlichen. Diese Befunde sind Beobachtungen des Dokuments, nicht der Befund, dass der laufende Service unkontrolliert sei.

Ein möglicher Klinik-Anbieter benötigt daher vor ersten Tests eine neue Evidenzlage. Das erste Dokument ist kein Sicherheitszertifikat, sondern ein aktuelles Zertifikat der vertraglich bindenden Partei. Danach folgen eine unterzeichnete Auftragsverarbeitungsvereinbarung, benannte Unterauftragsverarbeiter und Länder, eine aktuelle Leistungsbeschreibung, Support- und Eskalationskontakte, Verfügbarkeits- und Wiederherstellungszusagen, Nachweise zu Berufshaftpflicht und eine Übergangserklärung.

Für einen bestehenden Kunden ist die Reihenfolge etwas anders. Zugang und Exporte sichern, festlegen, wer gegenwärtig Gebühren und Supportanfragen entgegennimmt, und schriftlich bestätigen lassen, welche Partei die Umgebung kontrolliert. Das öffentliche Seitenwiderspruch darf nicht als Anlass dienen, klinische Abläufe abrupt zu stoppen. Ziel ist kontrollierte Kontinuität: rechtliche und technische Zuständigkeit sichern und sichere Patientenabläufe aufrechterhalten.

Produktbezogene Hosting-Evidenz schlägt ASN-Inferenz

Mindclass zeigt, wie besser abgegrenzte Evidenz aussehen sollte, obwohl diese Evidenz historisch ist und selbstberichtend. Auf derMicrosoft-Seitegab HTSS an, Mindclass nutze Microsoft Azure Infrastructure as a Service und speichere die berücksichtigten Microsoft-Kundendaten in Irland. Es wurden Daten wie Name, Nachname, E-Mail und Unternehmensrolle genannt. Die Antworten wurden zuletzt am 30. August 2024 vom Entwickler aktualisiert.

Diese Aussage ist nützlich, weil sie ein Produkt, eine Cloud-Ebene, einen Provider und ein Land nennt. Sie trägt aber eine klare Begrenzung: Microsoft kennzeichnet die Seite als Entwickler-Selbsteinschätzung ohne Genauigkeitsgarantie. Außerdem liegt die Aussage vor demKauf von Mindclass durch Smart ID. Ein Käufer im Jahr 2026 sollte Smart ID nach der aktuellen Architektur und Zusicherung fragen, statt die alte Aussage als fortbestehende Wahrheit zu übernehmen.

DieTelemedica-Datenschutzerklärungzeigt das Gegenbeispiel. Sie nennt einen Cloud-Unterauftragnehmer, benennt ihn aber nicht, und nennt keinen konkreten Ländernamen. AS202842 kann diese Lücke nicht schließen. Auch wenn Telemedica einmal eine Adresse aus 95.128.174.0/24 genutzt hätte – ein solcher Hinweis findet sich hier nicht – kennt eine Route nur einen Ursprungs-ASN, nicht die Jurisdiktion jedes primären Datenbanksystems, jeden Sicherungsspeicher, jeden Content-Store, jede Analyse-, E-Mail- oder Videokomponente.

Die gleiche Zurückhaltung gilt für GTS. AS5606 war ein deklarierter Provider, und der einzige im ausgewählten Snapshot beobachtete Nachbar.GTS wirbt Rechenzentren in Bukarest und Cluj-Napoca. Kein öffentliches Dokument ordnet hier HTSS-Hardware einem dieser Standorte zu. „An einen Anbieter mit rumänischen Rechenzentren angeschlossen“ ist nicht „in Rumänien gehostet“, und keine dieser Formulierungen beantwortet, wo Cloud-Backups oder Subunternehmerdienste Daten verarbeiten.

Eine nutzbare Produktarchitektur sollte mindestens sechs Ebenen trennen: Nutzerzugang, Anwendungs-Compute, Primärdaten, Sicherungen, Identität und ausgehende Integrationen. Bei Telemedica können Video, Chat, Benachrichtigungen und medizinische Akten unterschiedliche Pfade haben. Bei Mindclass könnten Teams-Identität, Lerninhalte und Berichte unterschiedlich angebunden sein. Bei Apothekensoftware können ein lokaler Store-Server, zentrale Datenbank, Fiskalgeräte und Supportkanal unterschiedlich liegen. Das sind Beschaffungsfragen, keine Behauptungen zu tatsächlichen Deployments.

Das praktische Ergebnis ist ein Datenflussdiagramm mit rechtlichen Namen je Service. Es sollte Datentypen, Prozessorrolle, Land, Verschlüsselungseigentum, Wiederherstellungsquelle und Exportformat ausweisen. Das Diagramm muss nach den Übertragungen von 2025 aktuell sein. Weder die alte ASN noch eine alte Cloud-Bescheinigung können es ersetzen.

Sicherheitszusicherung muss Produkt und Eigentümer folgen

DieMindclass-Publisher-Bescheinigungenthält in dieser Recherche die reichhaltigste öffentliche Kontrollliste. HTSS berichtete jährliche Penetrationstests, vierteljährliche Schwachstellen-Scans, einen dokumentierten Notfall-Wiederherstellungsplan, Perimeter-Kontrollen, Ereignisprotokollierung, Alarmierung, formales Incident-Response-Verfahren, Change-Approval und Multifaktor-Authentifizierung für Code-Repositories, DNS-Management und Zugangsdaten. Es wurde ebenfalls ISO 27001 angegeben.

Die gleiche Seite dokumentiert Begrenzungen: keine SOC 2 oder SOC 3, kein ISO 27017 und kein FedRAMP; einige andere Standards wurden als nicht anwendbar eingestuft. Vor allem aber stammen alle Antworten vom Entwickler. Es gibt weder Zertifikatsnummer, noch aktuellen Geltungsumfang, noch einen Zusammenfassungsnachweis zu Penetrationstests, noch Testzeitraum auf der öffentlichen Seite. Das ist ein nützliches Diligence-Index und ein schwaches Abschluss-Paket.

Die Eigentümeränderung schafft ein Scope-Problem. Ein Managementsystemzertifikat kann eine juristische Person, Standorte, Personen und Prozesse abdecken. Der Transfer eines Produkts und Teams anSmart IDzeigt nicht automatisch, dass die alte Zertifikatsspanne des Vorgängers auf die aktuelle Umgebung des Käufers übergeht oder dass jede Kontrolle unverändert weiterlief. Richtigerweise ist ein aktuelles Zertifikat und sein Scope erforderlich, eine Anwendbarkeitsdarstellung, wo verfügbar, und produktbezogene Tests unter der Kontrolle des Nachfolgers.

Für Telemedica braucht es eine getrennte Prüfung. Dieöffentliche Datenschutzerklärungbeschreibt personenbezogene Daten und Drittanbieter-Supportkategorien, aber keine namentliche Cloud-Plattform und keine präzise Aufbewahrungsdauer für Login-Verlauf. DieNutzungsbedingungenschließen keine unterbrochene Verfügbarkeit aus. Keines der Dokumente liefert technische Evidenz zu Verschlüsselung, Mandantentrennung, Sicherungsunveränderlichkeit, Wiederherstellungszeit, Wiederherstellungspunkt, Schwachstellenoffenlegung oder Sicherheitsmonitoring. Diese Lücke ist ein Hinweis auf unvollständige Nachweise, nicht auf ein Fehlen von Maßnahmen.

Europäische Anforderungen zeigen, warum ein Käufer nicht bei einem ISO-Logo aufhören darf.Die DSGVO in Art. 32fordert risikoadäquate Vertraulichkeit, Integrität, Verfügbarkeit, Resilienz, Wiederherstellung und regelmäßige Prüfungen; Art. 28 regelt Auftragsverarbeiter und Unterauftragsverarbeiter. Für Unternehmen im Anwendungsbereich verlangtNIS2 Art. 21Incidentbehandlung, Geschäftskontinuität, Backup und Desaster-Recovery, Sicherheit entlang der Lieferkette und Wirksamkeitstests im gleichen Risikoprogramm. Keine der beiden Quellen belegt, dass jedes HTSS-Produkt oder jeder Kunde in jeder ihrer Bestimmungen erfasst wäre. Zusammen zeigen sie die Kategorien von Evidenz, die ein regulierter Käufer nachzuweisen hat.

ENISA's Baseline-Anforderungen an sichere Beschaffungsind operativ hilfreich: Mindestanforderungen entlang der gesamten Laufzeit, Zertifizierung nur im relevanten Scope, Mindestzeitfenster für den Lebenszyklus, sowie Regelungen für Schwachstellenbehandlung und Servicekontinuität. Auf den vorliegenden Fall übertragen heißt das: Absicherung folgt der benannten Anwendung, Umgebung und Nachfolger. Sie kann nicht allein durch das Fortbestehen der HTSS-Marke geerbt werden.

Ausfälle und die Gefahr einer leeren Sichtbarkeit

Der eingefrorene öffentliche Datensatz enthält keinen belegten Sicherheitsvorfall, der SC HIGH-TECH SYSTEM&SOFTWARE SRL, AS202842 oder ein nennenswertes HTSS-Produkt direkt zugeordnet werden kann. Ebenso enthält er keinen produktspezifischen öffentlichen Postmortem-Bericht. Das sind bewusst abgegrenzte Aussagen. Sie bedeuten nicht, dass kein Vorfall vorlag; sie bedeuten nur, dass die geprüften Materialien keine Schlussfolgerung über Vorfallleistung erlauben.

Es gibt eine sichtbare Netzwerkänderung: die Route hörte am 17. Dezember 2025 auf zu erscheinen. DieRIPE-Historiedokumentiert Erreichbarkeit, nicht Ursache oder Produktwirkung. Eine Ausblendung als Störung zu bezeichnen wäre Spekulation. Wenn kein Kunde die Präfixe nutzte, könnte keine Auswirkung entstanden sein. Wenn eine Migration vorausging, war die Entfernung womöglich geplant. Wenn Services darauf angewiesen waren und kein Alternativpfad bestand, kann der Effekt materiell gewesen sein. Die Routenlage kann diese Fälle nicht trennen.

DieTelemedica-Bedingungennennen ausdrücklich Wartung, internetbedingte Nichtverfügbarkeit und Beendigungs- oder Änderungsfälle beim Zugriff, während sie keine durchgehende Funktion zusichern. Diese Vertragsklausel ist keine Incident-Historie. Sie besagt nur, dass Verfügbarkeitsverpflichtungen verhandelbar in einem Zusatzplan mit Messquelle, Wartungsfenstern, Ausschlüssen, Service-Credits und Kündigungsrechten festgelegt werden müssen.

Derberichtete Vorfall im Februar 2024des rumänischen Gesundheitsministeriums ist keine HTSS-Vorwerfung. Dort wurden bei einem anderen Vorfall Produktionsdateien und Datenbanken verschlüsselt, was Systeme in mehreren Krankenhäusern betraf. Die Mitteilung belegt nicht, dass HTSS beteiligt war. Sie zeigt jedoch, warum jede Klinik, die ein digitales Versorgungssystem beschafft, geübte Wiederherstellung, Offline-Verfahren und klare Abhängigkeiten braucht.

Die Beschaffungsantwort auf eine leere öffentliche Incidentlage ist weder Vertrauen noch Vorwurf. Ein aktueller Betreiber sollte ein dreijähriges Incident-Tagebuch liefern mit Schwere, Dauer, betroffenen Leistungen, Meldezeiten und Korrekturmaßnahmen. Er sollte mit aktuellen Wiederherstellungstests und dem Status offener Remediation belegen. Diese Aussagen sind mit Überwachungsberichten und Referenzen zu reconciliieren. Wenn Vertraulichkeit detaillierte Offenlegung einschränkt, helfen redaktionell reduzierte Zusammenfassungen oder ein externer Prüfer. Schweigen ist unbekannt, nicht automatisch ein sauberes Gesundheitszeugnis.

Support-Evidenz wurde in Verträgen nachgewiesen, dann mit Teams übertragen

HTSS tat mehr als Lizenzen verkaufen. DasRegister des rumänischen Rechnungshofsdokumentiert ein abgeschlossenes Wartungsengagement 2024 für eine E-Learning-Plattform.AGERPRESnannte Wartung und Support als Teil der Tätigkeit des Betreibers. Das sind belastbare historische Signale einer Supportorganisation.

Die Transaktionen 2025 zeigen, dass Menschen und nicht nur Code Teil der Kontinuität waren.Setrio erklärte, dass es Fachwissen bündelt und den Support für die Pharmaprodukte stärkt.Smart ID erklärte, dass es ein erfahrenes kundenspezifisches Team sowie Mindclass und Shiftin übernimmt. Diese Aussagen verbessern die Nachfolgebilanz für benannte Assets, weil Wissenstransfer explizit genannt wird.

Sie lassen aber Käuferfragen offen. Welche Support-Tickets, Wissensartikel, Quell-Repositories, Deployment-Tools und kundenspezifischen Konfigurationen wurden übertragen? Wurden Reaktionszeit-Verpflichtungen unverändert übernommen? Sind die gleichen Ingenieur*innen geblieben? Wer hat Zugriff auf privilegierte Zugänge zu Altumgebungen? Wer patcht stark angepasste Versionen eines Kunden? Die Ankündigungen sagen es nicht.

Für kleine und mittlere Kunden ist die Konzentration von Wissen ein besonderes Kontinuitätsrisiko. Eine Bereitstellung kann von wenigen Personen abhängen, die steuerliche Integrationen, Bestandsregeln, Identitätszuordnungen oder Datenkonvertierungen verstehen. Hohe Beschäftigtenzahlen können diese enge personelle Abhängigkeit verdecken. Die von Economica gemeldeten rund 337 Mitarbeitenden im Durchschnitt 2024 sagen nichts darüber aus, wie viele Personen ein konkreter Kunde tatsächlich verstand.

Ein Nachfolge-Supportplan sollte deshalb benannt und testbar sein: Servicezeiten, Schweregrade, Reaktions- und Wiederherstellungsziele, Eskalationskontakte, Sprache der Betreuung in Rumänien und darüber hinaus, Bereitschaftsmodelle, Verletzungszeiten, Ersatzteil-/Hardware-Haftung wo relevant und ein Wissenstransferplan bei Personalwechseln. Eine echte Übung – das Anlegen eines Prioritätstickets und das Verfolgen der Eskalation – ist informativer als eine reine Supportbroschüre.

Preis ist sichtbar; TCO nicht

Telemedica ist der seltene Teil des historischen Portfolios mit einer öffentlichen Zahl. DiePreisseitebietet einen Monat Testbetrieb, dann EUR 40 je Arzt und Monat mit mindestens fünf Ärzten, also mindestens EUR 200 monatlich. DieNutzungsbedingungennennen den finalen Zugriffstyp, Preis, Fakturierung und Zahlungsbedingungen in einer separaten Vereinbarung.

Diese Zahl ist als kommerzieller Hinweis nützlich und als Budgetannahme unsicher. Sie zeigt nicht Implementierung, Datenmigration, Identitätsintegration, Schulung, Videoeinsatz, Speicher, Supportstufe, Sicherheitsbewertung, kundenspezifische Reports, Steuern oder Ausstiegsarbeiten. Sie sitzt zudem auf einer Seite, deren benannte rechtliche Provider als radiert gekennzeichnet ist. Ein Käufer muss daher ein aktuelles Angebot eines verifizierten Nachfolgers einholen, bevor diese Zahl als verbindlich genutzt wird.

Die übrigen Produkte sind typischerweise stärker von Konfiguration und Integration abhängig. Pharmasysteme betreffen Bestand, Verkauf, Fiskalprozesse und Reporting-Workflows. Mindclass kann Identität und Organisations-Lernhistorie integrieren. Schichtplanung hängt von Arbeitszeitregeln und Personalstammdaten ab. Individuelle Software ist definitionsgemäß mandantenbezogen. In jedem Fall ist das Lizenzmodell nur eine Schicht.

Der größte verdeckte Aufwand liegt häufig im Wechsel. Apothekendaten müssen bei laufendem Geschäft korrekt und prüfbar bleiben. Lernhistorie kann für Compliance- oder Beschäftigtennachweise benötigt werden. Schichtregeln binden lokale Praxisvorgaben. Klinische Daten und Kommunikation brauchen sichere Kontinuität. Schnittstellen zu Buchhaltung, Identität, Geräten, Messaging und Reporting müssen rekonstruiert oder erhalten werden. Ein Käufer sollte Datenextraktion, Mapping, Parallelbetrieb, Abgleich, Nutzerschulung und sichere Löschung von Altbeständen von Anfang an kalkulieren.

Der Data Act der EUsagt, die Verordnung gilt seit 12. September 2025 und schafft Mindestanforderungen für Vertrags- und Schnittstellen-Transparenz bei Datenverarbeitungsdiensten im Anwendungsbereich. Er behandelt offene Schnittstellen und maschinenlesbare Exporte für relevante Plattform- und Softwaredienste, mit ab 12. Januar 2027 vorgesehenen Entfall von Wechselgebühren. Die exakte Anwendung kann je Service und Ausnahmen variieren, besonders bei stark individuellen Bereitstellungen. Beschaffung sollte die Verordnung als Untergrenze nutzen, nicht als Ersatz für einen konkreten Ausstiegsplan.

Für eine Nachfolgeplattform sollte ein Angebot folgende Blöcke trennen: wiederkehrender Service, Implementierung, Drittleistungen, Support, Sicherheitsoptionen und Ausstiegsassistenz. Es sollte zusätzlich die Verantwortlichkeiten für Altanpassungen benennen. Ein niedriger monatlicher Betrag mit unklarem Datentransfer und ungesicherter Rechtskette ist nicht billig; er verschiebt Migrationskosten in die Zukunft.

Wettbewerb ist nun nach Nachfolgern zu bewerten

Vor der Teilung konnte HTSS als breiter rumänischer Technologieanbieter verglichen werden. Im Apothekenbereich nannteCegedims 2024er EinreichungHTSS neben Setrio und Softeh als Hauptwettbewerber in seiner eigenen Bewertung. Nach demErwerb der HTSS-Pharmacy-Sparte durch Setriowürde eine Verwendung dieser alten Liga in der Konkurrenzanalyse denselben Produktstrang auf beiden Seiten zählen.

Für Mindclass und Shiftin ist der relevante Anbieter nun der Erwerb durchSmart ID, nicht mehr ein radiertes HTSS-Unternehmen. Für DataKlas Pharmaceutical und Pharma Original ist es das Kontinuitätsversprechen von Setrio. Für Telemedica, omnimedica und verbleibende Infrastrukturdienste kann diese Recherche keinen Nachfolger benennen. Solche Produkte sollten nicht in einen Wettbewerbsvorgang aufgenommen werden, bis aktueller Eigentümer und Vertragspartei verifiziert sind.

Die Vergleichskriterien sollen der Workflow-Gegebenheit folgen. Ein Apothekenkäufer sollte gesetzliche Updates, Bestand- und Fiskalintegrationen, Offline-Modus, Rollout im Handel, Supportabdeckung, Datenkonvertierung und Roadmap testen. Ein Lernkäufer sollte Identität, Inhaltsstandards, Barrierefreiheit, Mandantentrennung und Exporte prüfen. Eine Klinik sollte Zustimmungen, Zugriffskontrolle, Konsultationskontinuität, Umgang mit Gesundheitsdaten, Unterauftragnehmer, Wiederherstellung und sichere Downtime-Verfahren testen.

Für kundenspezifische Entwicklung ist Eigentumsnachweis, Reproduzierbarkeit der Bereitstellung, Dokumentation, Personalausstattung und Übergabe zu prüfen.

Netzautonomie ist bestenfalls ein sekundäres Differenzierungsmerkmal. Eine aktuelle ASN und duale Transit-Beziehung können für eine selbst betriebene Plattform wertvoll sein, aber ein cloud-nativer Service kann ohne eigene ASN resilient sein, und eine ASN kann existieren, ohne dass die Anwendung resilient ist. Vergleichen Sie messbare Serviceergebnisse und Abhängigkeitsdesigns. Nutzen Sie Routingbelege, um konkrete Architekturbehauptungen zu prüfen, nicht um Anbieter anhand Infrastrukturinhaberschaft einzuordnen.

Eine Beschaffungsvorlage, die auf der gebrochenen Kette aufbaut

Die nützlichste Due-Diligence-Prozedur für das Erbe dieses Unternehmens ist kein Standardfragebogen. Sie ist eine Sequenz, die genau die Lücken schließt, die durch die Übertragungen 2025, die radiierte Rechtsgesellschaft, die fortbestehenden Produktseiten und die zurückgezogene Route entstanden sind.

1. Die aktuelle Rechts- und Asset-Kette festlegen

Beginnen Sie mit dem exakten Produkt und der installierten Version. Fordern Sie ein aktuelles Registerzeugnis der vorgeschlagenen Vertragseinheit an. Verlangen Sie den Nachweis des Asset-Kauf- oder Übertragungsdokuments, das Eigentums- oder Nutzungsrechte für Lizenzen belegt, ohne unnötige Transaktionsdetails, die geschäftlich irrelevant sind. Ordnen Sie den alten HTSS-Vertrag jedem Novierungs-, Abtretungs- oder Neuanhangsvertrag zu. Bestätigen Sie, wem kundenspezifischer Code, generischer Produktcode, Dokumentation und Bereitstellungswerkzeuge gehören.

Für DataKlas Pharmaceutical und Pharma Original ist dieSetrio-Ankündigungein starker Hinweis, nicht der Vertrag. Für Mindclass und Shiftin erfüllt dieSmart-ID-Ankündigungdieselbe Rolle. Für Telemedica stehenalte Bedingungenund derradiierte Firmeneintragim Widerspruch, daher sollte ein neuer Käufer die Bindungsentscheidung aussetzen, bis die Kette vorgelegt ist.

2. Die instanzspezifische Architektur zeichnen

Fragen Sie nach einem Diagramm der tatsächlichen Kundeninstanz, nicht nach einem Referenzarchitektur-. Markieren Sie Applikationskomponenten, Identitäten, Datenbanken, Objektspeicher, Sicherungen, Monitoring, Supportzugänge und Messaging-Provider. Benennen Sie die rechtliche Betreiberin und den Landstandort je Bereich. Trennen Sie Kundensysteme, Infrastruktur des Nachfolgers und Public-Cloud klar voneinander.

Nutzen Sie AS202842 nur als Abgleichpunkt. Wenn das Diagramm keine Abhängigkeit von diesem alten Netz behauptet, fragen Sie nach Migrationstermin und ob Allow-lists, VPNs, Zertifikate oder Monitoring weiterhin auf 95.128.174.0/24 verweisen. Wenn das Diagramm ein Ersatznetz benennt, dokumentieren Sie neuen Ursprung und neue Provider. Nehmen Sie nicht an, dass der alte Präfixentzug eine Migration ausgelöst oder abgeschlossen hat.

3. Kontinuität als betriebliche Funktion testen

Fordern Sie kürzlich ausgeführte Backup-Wiederherstellungsergebnisse mit Wiederherstellungspunkt und Wiederherstellungszeit statt nur von Richtlinien. Üben Sie den Verlust des Primärstandorts, der Cloud-Region, des Identitätsanbieters, einer Schlüsselperson im Support und einer externen Integration. Definieren Sie manuelle Verfahren für Apotheke, Personal, Lernen oder Klinikbetrieb bei Ausfall. Legen Sie fest, wer Vorfälle meldet, wer Kunden informiert und wer die Wiederherstellung autorisiert.

Für das Gesundheitswesen zeigt der4Gbericht des rumänischen Gesundheitsministeriums von 2024die operative Folge nicht erreichbarer Produktionsdaten, ohne HTSS zu belasten. Dort wurden bei einem anderen Vorfall Produktionsdateien und Datenbanken verschlüsselt, was Systeme in mehreren Krankenhäusern betraf. Die Mitteilung belegt nicht, dass HTSS beteiligt war. Sie zeigt jedoch, warum jeder klinische Betrieb bei einem digitalen Versorgungssystem einen realistischen Ausfall wie ver- und offline testen sollte.

4. Historische Zusicherungen durch aktuelle Evidenz ersetzen

Nutzen Sie dieMindclass-Microsoft-Zertifizierungals Fragenliste: Azure-Standort, Testfrequenz, Wiederherstellungsplan, Logging, MFA, Schwachstellenbehandlung und Zertifikatsumfang. Fordern Sie danach aktuelle Evidenz beim Nachfolger an. Bestätigen Sie, was sich in Hosting, Personal und Kontrollzuständigkeit nach der Übernahme geändert hat.

Für Telemedica klären Sie jede fehlende Angabe in derDatenschutzerklärung: Cloud-Provider, Serverstandorte, Unterauftragnehmer, Übertragungsgrundlage, Aufbewahrungsfristen, Supportzugang und Löschung. Stimmen Sie die Auftragsverarbeitung mitder DSGVOab. Soweit der Kunde im Geltungsbereich liegt, ordnen Sie die Beweise zuNIS2in Lieferkette, Vorfällen und Kontinuität zu. Ein Zertifikatslogo ersetzt diese Zuordnung nicht.

5. Supportfähigkeit nachweisen

Listen Sie benannte Rollen statt nur Gesamtstärke: Produktverantwortliche*r, Release-Engineer, Datenbankspezialist*in, Integrationsspezialist*in, Sicherheitsverantwortliche*r und Eskalationsleitung. Zeigen Sie Abdeckung sowie Ersatzorganisation. Prüfen Sie Ticketstatistiken nach Schweregrad, Alter und Wiederkehr. Führen Sie einen Tickettest durch. Verifizieren Sie, dass das erworbene Team den Support für die Kundenumgebung und die Kundenbranche tatsächlich trägt.

Für Apotheken- und Lernkunden vergleichen Sie die inSetrioundSmart IDzugesagten Kontinuitätsziele mit personeller, Release- und Reaktionsdatenlage. Die Ankündigungen sprechen von Wissenstransfer; der Betrieb muss zeigen, wie viel davon praktisch übernommen wurde.

6. Einen Ausstieg vor dem Einstieg ausführbar machen

Inventarisieren Sie alle Exporte: Stammdaten, Transaktionen, Dokumente, Audit-Trails, Anlagenhistorie, Lernhistorie, Zeitpläne, klinische Datensätze, Identitätszuordnungen. Definieren Sie Format, Frequenz, Kosten, Verschlüsselung und Validierung. Ergänzen Sie dies durch Dokumentation und Unterstützung für kundenspezifische Schnittstellen. Bewahren Sie ein rechtlich angemessenes schreibgeschütztes Archiv auf, wenn Unterlagen dauerhaft zugänglich bleiben müssen.

Die Data-Act-Empfehlungenschärfen die Erwartungen beim Wechsel bei betroffenen Datenverarbeitungsdiensten, ersetzen aber nicht den Migrationsplan eines Kunden. Vereinbaren Sie einen Exporttest im Rahmen des Vertrags, prüfen Sie Vollständigkeit, fordern Sie Korrekturmaßnahmen ein. Legen Sie sichere Löschung und Nachweise für den Übergang fest.

7. Netzbehauptungen im richtigen Layer verifizieren

Wenn der Service eine eigene Netzarchitektur nutzt, sammeln Sie aktuellen Präfix, Ursprung, Provider, Standort und Route-Sicherheitsbelege. Testen Sie Failover aus mehr als einer Beobachtungsstelle. Fragen Sie, ob beide Provider physisch getrennt sind. Wenn der Service cloud-nativ ist, fokussieren Sie auf Regionendesign, private Verbindungen, Egress-Kontrollen und Cloud-Abhängigkeiten.

Der alte Datensatz zeigt eine wichtige Vorsichtsmaßnahme:zwei registrierte Provider,ein im Snapshot beobachteter Nachbarund keine aktuelle öffentliche Ankündigung. Eine Beschaffungserklärung muss klären, was Politik, was Messung und was nicht mehr aktuell ist.

Wo Beschaffung aufhört zu inferieren

Die Qualifizierungsfrage hat eine klare Antwort. Historisch entwickelte und unterstützte das rechtliche Unternehmen hinter der Nummer 30126940 Unternehmensoftware, stellte Infrastruktur bereit, betrieb benannte Gesundheits- und Lernprodukte und kontrollierte AS202842. Öffentliche Kunden- und Plattformunterlagen bestätigen Teile dieser Aktivitäten über das Marketing des Unternehmens hinaus.

Zum Stand vom 18. Juli 2026 kann kein neues Beschaffungsgeschäft sicher dieser rechtlichen Entität allein zugewiesen werden.Die Firma ist als radiert markiert. Benannte Assets wurden übertragen:DataKlas Pharmaceutical und Pharma Original im Setrio-Transaktionsfall für die Einzelhandelspharmazie, undMindclass, Shiftin und ein kundenspezifisches Entwicklungsteam im Smart-ID-Transaktionsfall für Business Solutions. Die öffentliche Kette für Telemedica, omnimedica, verbleibende Infrastrukturlast und AS202842 bleibt unvollständig.

AS202842 belegt ein historisches Präfix, eine autonome Routing-Identität und eine deklarierte Dual-Provider-Policy.Die öffentliche Beobachtung bestätigt GTS als Nachbarn in der gewählten historischen Ansicht; sie bestätigt Vodafone dort nicht.Die Route wurde zuletzt am 17. Dezember 2025 gesehenund ist aktuell nicht mehr sichtbar auf demnormalen RIPE-Schwellenwert. Das ist die vollständig begründete Schlussfolgerung im Netzwerkbereich.

Beschaffung muss aufhören, eine Anwendung aus dem Präfix abzuleiten, ein Rechenzentrum aus einem Provider zu schließen, Redundanz aus zwei Policyzeilen zu schlussfolgern, Sicherheit aus Netzwerksteuerung zu übernehmen oder Geschäftskontinuität aus einer sichtbaren Website abzuleiten. Sie muss auch aufhören, ein nicht genanntes Produkt einem Transaktionskäufer zuzuordnen. Jeder dieser Sprünge ersetzt ein fehlendes Dokument durch eine plausible Erzählung.

Das Verschwinden der Route ist dennoch wertvoll. Es gibt der Beschaffung eine präzise Frage: Wovon hing 95.128.174.0/24 wirklich abhängig? Wohin ist es gewandert und wer hat die Verantwortung übernommen? Ein glaubwürdiger Nachfolger kann das mit Asset-Kette, Architektur, aktueller Zusicherung und einem getesteten Ausstieg beantworten. Bis dahin ist die alte ASN kein Resilienz-Zertifikat. Es ist eine Abgrenzungslinie, die genau zeigt, wo offene Netzwerkbelege enden.