NNeXsoft
de — Deutschen — English
Security · Data protection · Concrete

Six concrete layers of protection — no marketing platitudes.

We have no SOC 2, no ISO 27001 — that would be dishonest for a company of this size. What we do have: implementations you can verify yourself, for example at /api/health or in security.txt.

Technical from here — for your IT team

The six points below are written for specialists and each names the file in which the claim can be verified. If you are not from IT, the line above it is enough: verifiable rather than certified.

Transport and headers of this site

Every response from this site carries a fixed set of security headers. They can be checked from outside, without you having to take our word for it.

  • Strict-Transport-Security enforces the encrypted connection, including subdomains.
  • frame-ancestors and X-Frame-Options prevent embedding in third-party pages.
  • base-uri and form-action tie the base URL and form targets to our own origin; camera, microphone and location are switched off via the permissions policy.
  • The content security policy deliberately stays wide for scripts while no nonce chain exists — that is written as a comment at the place itself, not only here.

Proof in next.config.ts

Execution region fra1

This site's functions are pinned to the fra1 region in Frankfurt. That is one line in the deployment configuration, and it can be read there directly.

  • The region sits in the configuration, not only in an assurance.
  • Static files run through the platform's delivery network; that is a property of the hosting, not a setting in this file.
  • We make no wider statement about data residency, because we could not evidence it here.

Proof in vercel.json

Protection of the writing routes

The routes that trigger something — contact, sign-up, assistant — check every request before any work begins. What they do not achieve is written in the source at the same place.

  • A platform bot check runs before the first billable call is triggered.
  • A counter per address and route limits how often a send can be triggered.
  • The form routes check every input against a schema; free text is escaped before it reaches an email. The assistant has no schema — there, message length and count are what limit the work.
  • The counter lives in a single instance's memory — a hurdle, not a wall. It is commented as exactly that.

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

Measurement only after consent

Reach and load-time measurement are mounted only once someone has agreed — not hidden, but not loaded at all. The same principle applies in the other direction to the sign-up.

  • Without consent no measurement script is mounted; a withdrawal takes effect without the page reloading.
  • For our own content there is no external image source; the reasoning sits in the configuration. Where a booking widget is embedded, it loads its files from the provider — that is the one exception.
  • A sign-up takes effect only through the click in the address holder's own mailbox; the confirmation token is signed and expires.
  • A durable record of consent is missing because there is no store for it — that is named in the source, not glossed over.

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

Verifiable rather than certified

We hold no certification, and we do not claim one. What is open instead is which integrations a deployment actually wires up, and where a security report goes.

  • An open status endpoint states, per integration, whether it is configured in this deployment.
  • A security.txt at the location provided for it names the reporting route for vulnerabilities.
  • No ISO 27001, no SOC 2, no TISAX — for an organisation of this size the claim would be dishonest.
  • Where a protective layer reaches its limit, that is written as a comment at the place itself — for the counter as much as for the content security policy.

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

What is added in your system

This site needs no user sign-in, no database and no roles — which is why you will find none of that here. In a client project we would set that layer up, and it would be agreed before anything is built.

  • Sign-in and roles would connect to existing company accounts where those exist.
  • Access rights would be enforced at the data layer, not in the interface alone.
  • A case history would record who changed what and when, and on whose approval.
  • Credentials, backup and restore would be settled before the start, not afterwards.

A commitment for your project — not a statement about this website.

Documents for your review

Do you need a DPA, technical and organisational measures, a sub-processor list?

You will get them. Reply within 24 hours on business days. No legalese, no collection of boilerplate — specific, readable documents that stand up to scrutiny.

Request the documents
Privacy policy

Found a security issue? Write to security@nex-soft.com · machine-readable via /.well-known/security.txt (RFC 9116).

NX
NeXsoft
Management
Koblenz·Reply < 24 h on business days
Speak directly with management

Ohne Zwischenstationen. You speak directly with management.

We listen for 30 minutes, ask a few pointed questions and tell you openly at the end whether — and how — we can help. If we cannot, you get at least two recommendations for who can.

  • 30 minutes, with no sales pitch
  • A concrete assessment of your project
  • A clear view of which project scope fits
Rather write an email →