NIS2, GDPR and malware scanning for hosting providers

This article is not legal advice. It summarises published legal texts and official guidance with links to the primary sources so you can read them yourself. Whether any of it applies to your company, and what you must then do, is a question for your own counsel or data protection officer.

With that said: two things changed for German hosting providers, and both are now in force. Germany’s NIS2 implementation became law in December 2025, and a directly applicable EU regulation has since November 2024 told in-scope entities what their supplier contracts must contain. Together they turn “do you scan for malware, and what does your vendor do with the files” from a preference into a documented obligation.

Germany’s NIS2 law: in force, no transition period

The Gesetz zur Umsetzung der NIS-2-Richtlinie (NIS2UmsuCG) was signed on 2 December 2025 and published in the Bundesgesetzblatt as BGBl. 2025 I Nr. 301 on 5 December 2025. Its Article 30 reads: “Dieses Gesetz tritt am Tag nach der Verkündung in Kraft.” — it entered into force on 6 December 2025.

It is not a small standalone act. Article 1 is a complete recast of the BSI-Gesetz, now consolidated at gesetze-im-internet.de , alongside amendments to around 29 other statutes.

There is no transition period for the substantive duties, and the registration deadline has already expired. The BSI’s own page carries the banner, verbatim:

Frist ist abgelaufen — Die gesetzliche Registrierungsfrist ist bereits abgelaufen. Von NIS-2 betroffen und noch nicht registriert? Dann jetzt umgehend im BSI-Portal registrieren!

(BSI, NIS-2-regulierte Unternehmen , opened 4 September 2026.) Under § 33 BSIG, registration is due three months after an entity first qualifies, changes are notifiable within two weeks, and § 33(3) allows the BSI to register an entity itself if it fails to.

If you are wondering why this arrived late: the EU transposition deadline was 17 October 2024, the Commission issued a reasoned opinion to Germany and eighteen other Member States on 7 May 2025, and on 8 July 2026 it referred Ireland, Spain, France and the Netherlands to the Court of Justice. Germany was not among them — consistent with the law now being in force (Commission, NIS2 transposition ).

Are hosters in scope? Yes, but not under a line that says “hosting”

This is the nuance most summaries get wrong. “Webhosting” is not a listed Einrichtungsart. German hosters are caught through Anlage 1, Nr. 6 “Digitale Infrastruktur”, specifically:

• 6.1.4 Anbieter von Cloud-Computing-Diensten
• 6.1.5 Anbieter von Rechenzentrumsdiensten
• 6.1.10 Managed Services Provider
• 6.1.11 Managed Security Services Provider
• 6.1.2 DNS-Dienstanbieter — size-independent, if you run DNS as a service

The size thresholds in § 28 BSIG then decide which category you land in:

Note the consequence for anyone who resells managed security — an MSSP is named explicitly, and running DNS as a service removes the size threshold entirely.

The BSI operates a free, anonymous Betroffenheitsprüfung already updated to the new BSIG. It states plainly that its result is “rechtlich nicht bindend”. It takes ten minutes and is a better use of your time than any vendor’s compliance page, including this one.

(One figure you will see quoted everywhere — roughly 30,000 affected German companies — we could not confirm against a BSI or BMI primary source, so we do not publish it.)

What § 30 BSIG actually asks for

The risk-management measures in § 30 BSIG must meet the “Stand der Technik”, and the list explicitly includes “Sicherheit der Lieferkette einschließlich sicherheitsbezogener Aspekte der Beziehungen zu unmittelbaren Anbietern oder Diensteanbietern” alongside vulnerability management. Crucially, compliance must be documented: “Die Einhaltung der Verpflichtung nach Satz 1 ist durch die Einrichtungen zu dokumentieren.”

§ 38 places implementation, supervision and training duties on management personally, and § 65 sets the fines. § 32 sets the reporting clock: a 24-hour early warning, a 72-hour notification including indicators of compromise, an interim report on request, and a final report within one month.

Here is the part that turns detection speed into a regulatory variable rather than an operational preference. Under the Commission implementing regulation, for cloud, data-centre and MSP/MSSP-classified providers, an incident is significant where the integrity, confidentiality or authenticity of stored, transmitted or processed data is compromised as a result of a suspectedly malicious action — with no user-count threshold attached, unlike the parallel limb about service disruption. A single confirmed website compromise on a customer account can therefore trip the reporting duty. The same Annex requires logs “from security tools, such as antivirus, intrusion detection systems or firewalls” — meaning your scanner’s own logs are the evidence base for the report you have 72 hours to file.

The supplier questionnaire is written into EU law

Commission Implementing Regulation (EU) 2024/2690 of 17 October 2024 entered into force on 7 November 2024. It is a Regulation — binding in its entirety and directly applicable, with no national transposition needed — and it binds cloud, data-centre, MSP, MSSP and DNS entities.

Its Annex point 6.9 is the closest thing in EU law to a duty to run malware detection on a hosting platform:

The relevant entities shall protect their network and information systems against malicious and unauthorised software. […] the relevant entities shall in particular implement measures that detect or prevent the use of malicious or unauthorised software. The relevant entities shall, where appropriate, ensure that their network and information systems are equipped with detection and response software, which is updated regularly …

Note the drafting: technology-neutral, “detect or prevent”, and no mention of cloud lookups.

Its Annex point 5 then tells in-scope buyers what their supplier contracts must specify. An in-scope hoster is legally obliged to require of its security-tool vendor:

• secure development procedures (5.1.2(a));
• staff training, certifications and background checks (5.1.4(b), (c));
• incident notification without undue delay (5.1.4(d));
• the right to audit or to receive audit reports (5.1.4(e));
• vulnerability handling (5.1.4(f));
• subcontracting terms (5.1.4(g));
• retrieval and disposal of information at contract termination (5.1.4(h));

plus a maintained registry of direct suppliers (5.2) and periodic re-evaluation (5.1.6). The selection criteria in 5.1.2 even name “the ability of the relevant entities to diversify sources of supply and limit vendor lock-in”.

Two practical consequences. First, points (d) to (h) mirror Art. 28(3) GDPR closely enough that one vendor questionnaire can serve both. Second, after the ConfigServer wind-down, a buyer asking a security vendor “what happens if you disappear?” is not being difficult — they are doing what the regulation asks. We wrote about that wind-down in what CXS operators should do next , and it is the clearest recent illustration of why lock-in is a named criterion.

What the BSI expects of a scanner

IT-Grundschutz is still Edition 2023, available since 1 February 2023, and the BSI states that its requirements “bilden den aktuellen Stand der Technik … ab” — which is what ties them to § 30 BSIG and to Art. 32 GDPR. Requirements are graded Basis (B), Standard (S) and erhöhter Schutzbedarf (H), with MUSS and SOLLTE in the RFC 2119 sense.

APP.3.2.A3 — Absicherung von Datei-Uploads und -Downloads (B):

Alle mithilfe des Webservers veröffentlichten Dateien MÜSSEN vorher auf Schadprogramme geprüft werden.

All files published by way of the web server must be checked for malware beforehand. That is upload scanning, mandated as a Basis-Anforderung.

From OPS.1.1.4 , Schutz vor Schadprogrammen:

• A3 (B) — only enterprise products with support tailored to the institution may be used; home-user products and products without support MUST NOT be used in professional operation. A3 also makes scanning compressed archives a hard MUSS.
• A3 (B), on cloud detection — and read this carefully, because it is routinely misquoted: cloud services to improve detection performance SHOULD be used, and if they are used it MUST be ensured that this does not conflict with data protection or secrecy obligations. The BSI does not say avoid cloud detection. The honest reading is that a product resolving that tension — keeping content local while remaining effective — satisfies both halves without a trade-off.
• A5 (B) — users must not be able to make security-relevant changes to the scanner’s settings. Set that against documented cases of malware renaming or patching an in-site security plugin, covered in why webshell detection belongs on the server : a control the tenant can switch off does not meet A5; a host-level daemon outside the tenant’s reach does.
• A9 (S) — the scanner SHOULD automatically block and report an infection, to a central point.
• A10 and A11 (H) — automated analysis in sandboxes for suspicious files, and scanners with multiple alternative scan engines for high-value systems.

And the line worth having in mind when you are deciding whether to run a host with no detection at all, from A1 (B): “Ist kein verlässlicher Schutz möglich, so SOLLTEN die identifizierten IT-Systeme NICHT betrieben werden.”

The BSI’s 2025 situation report supplies the reason signatures alone are insufficient, in the federal authority’s own words: around 280,000 new malware variants per day, which BSI notes are often generated automatically “um signaturbasierter Detektion zu entgehen”. The same report puts the average lifespan of a malware-distributing website at about 1.77 hours , and describes 3.1 million German SMEs — 99.4% of companies as a population short of IT staff and behind on patching. That population is exactly who small hosters and agencies serve.

The GDPR questions customers actually ask

Three of them, and they are all reasonable.

“Does the software send our customers’ files anywhere?” This is an Art. 28 question. A security vendor whose software uploads customer files to a vendor cloud becomes a processor, with the full contractual machinery that follows. A product that processes only on the customer’s own server materially reduces that surface. It does not remove your own controller duties.

“Where is the data processed?” Art. 32 is the “Stand der Technik” hook — the same phrase the BSI attaches to IT-Grundschutz and § 30 BSIG uses. The three instruments interlock, and it is worth saying that once rather than treating them as three separate projects.

“What about transfers to the US?” Here is the accurate status as of 4 September 2026, and it is worth stating carefully because it is the easiest thing on this page to get wrong. The EU-US Data Privacy Framework adequacy decision was upheld at first instance: the General Court dismissed Case T-553/23, Latombe v Commission, on 3 September 2025 (CURIA press release ; IAPP coverage ). An appeal, C-703/25 P, was lodged on 31 October 2025 and is pending; no judgment and no Advocate General’s opinion exists yet, and the Commission’s adequacy page still lists the US for DPF participants.

So: the framework is in force, upheld once, and under appeal to the court that annulled both of its predecessors. Anyone telling you it has been struck down is wrong. The framing that is true whichever way the Court rules is simply this — processing that never leaves the EU is not exposed to that outcome either way.

How a local scanner answers them

Shelltrap’s default profile transmits nothing outward. Outbound destinations are allow-listed; sample and telemetry code is not loaded without opt-in; and a sample never leaves the server without case-specific administrator approval. The only outbound connections in normal operation are the signed signature feed and the licence check, both to Panomity servers in Germany. Detection runs in an unprivileged sandboxed worker on your own machine, across ClamAV, YARA, hash sets and heuristics, with nested archives passed through the pipeline under explicit recursion, ratio and expanded-size limits.

Mapped against the requirements above — and this is our mapping, not a BSI certification or a legal opinion:

The vendor-assessment questions you should be asking us are the same ones we suggest putting to every other vendor, including in our comparison with Imunify360 .

What this means for CyberPanel operators

1. Run the BSI scoping tool this week. It is free, anonymous and explicitly non-binding, and the registration deadline has already passed. If you are in scope, being late is a worse position than being unsure.
2. Ask every security vendor, in writing, what leaves the server. Ask which document governs — DPA, EULA or technical documentation — and its version and date. CIR 2024/2690 point 5.1.4 is your list of questions; you do not have to invent it.
3. Treat time-to-detect as a reporting variable. With no user-count threshold on the data-integrity limb, one compromised customer site can start a 24-hour clock. How quickly you notice is now a regulatory parameter, not just an operational one.
4. Keep the evidence your report will need. Scanner logs, quarantine manifests and audit trails are named in the Annex as evidence. Decide the retention period before you need it, and check that you can export it.
5. Take actual legal advice on scope and category. Everything above is published law and official guidance with links. Whether you are a besonders wichtige or wichtige Einrichtung, and what your management is personally on the hook for under § 38, is a question for your counsel.

Shelltrap processes files locally on your server, keeps an exportable audit trail, and ships from a German vendor with a German-language DPA. See the installation documentation for what it requires, or the pricing page for terms.