NNeXsoft
Sicherheit · Datenschutz · Konkret

Sechs konkrete Schutzschichten — keine Marketing-Floskeln.

Wir haben kein SOC 2, kein ISO 27001 — das wäre für ein Unternehmen dieser Größe unehrlich. Was wir haben: Implementierungen, die Sie selbst nachprüfen können, etwa unter /api/health oder in security.txt.

Ab hier technisch — für Ihre IT

Die folgenden sechs Punkte sind für Fachleute geschrieben und nennen jeweils die Datei, in der die Aussage nachprüfbar ist. Wenn Sie nicht aus der IT kommen, genügt der Satz darüber: nachprüfbar statt zertifiziert.

Transport und Header dieser Seite

Jede Antwort dieser Seite trägt einen festen Satz Sicherheits-Kopfzeilen. Sie sind von außen prüfbar, ohne dass Sie uns dafür glauben müssen.

  • Strict-Transport-Security erzwingt die verschlüsselte Verbindung, auch für Subdomains.
  • frame-ancestors und X-Frame-Options verhindern das Einbetten in fremde Seiten.
  • base-uri und form-action binden Basis-URL und Formularziele an die eigene Herkunft; Kamera, Mikrofon und Standort sind über die Permissions-Policy abgeschaltet.
  • Die Content-Security-Policy lässt Skripte bewusst weit zu, solange keine Nonce-Kette existiert — das steht als Kommentar an der Stelle selbst, nicht nur hier.

Belegt in next.config.ts

Ausführungsregion fra1

Die Funktionen dieser Seite sind auf die Region fra1 in Frankfurt festgelegt. Das ist eine Zeile in der Bereitstellungskonfiguration und damit dort direkt nachzulesen.

  • Die Region steht in der Konfiguration, nicht nur in einer Zusage.
  • Statische Dateien laufen über das Auslieferungsnetz der Plattform; das ist eine Eigenschaft des Hostings, keine Festlegung in dieser Datei.
  • Weiter reichende Aussagen zur Datenresidenz treffen wir nicht, weil wir sie hier nicht belegen könnten.

Belegt in vercel.json

Schutz der schreibenden Routen

Die Routen, die etwas auslösen — Kontakt, Anmeldung, Assistent — prüfen jede Anfrage, bevor Arbeit entsteht. Was sie dabei nicht leisten, steht im Quelltext an derselben Stelle.

  • Eine Bot-Erkennung der Plattform läuft, bevor der erste kostenpflichtige Aufruf ausgelöst wird.
  • Ein Zähler je Adresse und Route begrenzt, wie oft Versand ausgelöst werden kann.
  • Die Formularrouten prüfen jede Eingabe gegen ein Schema; Freitext wird maskiert, bevor er in eine Mail gelangt. Im Assistenten greift kein Schema — dort begrenzen Länge und Anzahl der Nachrichten den Aufwand.
  • Der Zähler liegt im Arbeitsspeicher einer einzelnen Instanz — eine Hürde, kein Schutzwall. Genau so ist er auch kommentiert.
  • Was Sie in den Assistenten eingeben, verlässt diese Seite: Die Anfrage läuft über einen Vermittlungsdienst an ein Sprachmodell. Der Verlauf liegt in Ihrem Browser, nicht bei uns — und es gibt keine Datenbank, in der er landen könnte.

Belegt in app/api/contact/route.ts, lib/rate-limit.ts

Messung erst nach Einwilligung

Reichweiten- und Ladezeitmessung werden erst eingebunden, wenn jemand zugestimmt hat — nicht ausgeblendet, sondern gar nicht geladen. Für die Anmeldung gilt dasselbe Prinzip in die andere Richtung.

  • Ohne Zustimmung wird kein Messskript montiert; ein Widerruf greift, ohne dass die Seite neu geladen wird.
  • Für eigene Inhalte gibt es keine externe Bildquelle; die Begründung steht in der Konfiguration. Wo ein Terminwidget eingebunden ist, lädt es seine Dateien beim Anbieter — das ist die eine Ausnahme.
  • Eine Anmeldung wird erst durch den Klick im Postfach des Adressinhabers wirksam; das Bestätigungstoken ist signiert und läuft ab.
  • Ein dauerhaftes Einwilligungsprotokoll fehlt, weil es keinen Speicher dafür gibt — das ist im Quelltext benannt, nicht beschönigt.

Belegt in components/visual/AnalyticsGated.tsx, lib/newsletter-token.ts

Nachprüfbar statt zertifiziert

Wir tragen keine Zertifizierung, und wir behaupten auch keine. Offen liegt stattdessen, was in einer Bereitstellung tatsächlich verdrahtet ist und wohin ein Sicherheitshinweis geht.

  • Ein offener Statusendpunkt nennt je Integration, ob sie in dieser Bereitstellung konfiguriert ist.
  • Eine security.txt an dem dafür vorgesehenen Ort nennt den Meldeweg für Schwachstellen.
  • Kein ISO 27001, kein SOC 2, kein TISAX — für ein Unternehmen dieser Größe wäre die Behauptung unehrlich.
  • Wo eine Schutzschicht an ihre Grenze stößt, steht das als Kommentar an der Stelle selbst — beim Zähler ebenso wie bei der Content-Security-Policy.

Belegt in app/api/health/route.ts, app/.well-known/security.txt/route.ts

Was in Ihrem System dazukommt

Diese Seite braucht keine Benutzeranmeldung, keine Datenbank und keine Rollen — deshalb finden Sie hier auch nichts davon. In einem Kundenprojekt würden wir diese Ebene einrichten, und sie würde abgestimmt, bevor gebaut wird.

  • Anmeldung und Rollen würden wir an bestehende Unternehmenskonten anbinden, wo es sie gibt.
  • Zugriffsrechte würden auf Datenebene durchgesetzt, nicht allein in der Oberfläche.
  • Eine Vorgangshistorie würde festhalten, wer wann was geändert hat und auf welche Freigabe hin.
  • Zugangsdaten, Sicherung und Wiederherstellung würden vor dem Start festgelegt, nicht danach.

Zusage für Ihr Projekt — keine Aussage über diese Website.

Unterlagen für Ihre Prüfung

Brauchen Sie AVV, TOMs, Sub-Auftragsverarbeiter-Liste?

Bekommen Sie. Antwort innerhalb von 24 Stunden an Werktagen. Kein Anwaltsdeutsch, keine Textbausteinsammlung — konkrete, leserliche Dokumente, die einer Prüfung standhalten.

Sicherheitslücke gefunden? Schreiben Sie an security@nex-soft.com · maschinen-lesbar via /.well-known/security.txt (RFC 9116).

NX
NeXsoft
Geschäftsleitung
Koblenz·Antwort < 24 h werktags
Direkt mit der Geschäftsleitung sprechen

Ohne Zwischenstationen. Sie sprechen direkt mit der Geschäftsleitung.

Wir hören Ihnen 30 Minuten zu, stellen ein paar gezielte Fragen und sagen Ihnen am Ende offen, ob — und wie — wir Ihnen helfen können. Wenn nicht, erhalten Sie mindestens zwei Empfehlungen, wer es könnte.

  • 30 Minuten, ohne Verkaufsgespräch
  • Konkrete Einschätzung Ihres Vorhabens
  • Klare Einordnung, welcher Projektrahmen passt
Lieber per Mail schreiben →