GDPR and data residency in malware scanning

Buying a malware scanner is a data-protection decision as much as a security one, because the product’s job is to read every file your customers put on your server. Whether those bytes stay on the machine decides how much paperwork, and how much risk, comes with the purchase.

The Art. 28 question comes first

Customer files on a hosting server routinely contain personal data — form submissions, invoices, uploaded documents, database dumps left in a web root. If your scanner transmits those files, or samples of them, to the vendor for analysis, the vendor is processing personal data on your behalf. Under Art. 28 GDPR that means a processor contract with everything it entails: documented instructions, confidentiality, sub-processor authorisation, assistance obligations, audit provisions, and deletion or return at the end of the engagement.

None of that is impossible. It is simply work you take on, and risk you accept, in exchange for a detection feature. The alternative — processing that happens entirely on the server you already control — does not eliminate the vendor relationship, but it removes customer file content from it.

Art. 32 is the other half. It requires security measures appropriate to the risk, “taking into account the state of the art” — the same phrase that § 30 BSIG uses for NIS2 risk-management measures, and the phrase BSI attaches to IT-Grundschutz. The three instruments interlock deliberately: what counts as state of the art in one is meant to be recognisable in the others.

The transfer question, stated accurately

This is the part where marketing copy usually goes wrong, so here it is precisely, as at 4 September 2026.

The EU-US Data Privacy Framework adequacy decision remains in force. The General Court dismissed Philippe Latombe’s action to annul it on 3 September 2025 (Case T-553/23, ECLI:EU:T:2025:831); as the IAPP reported , the court “confirmed the framework validity based on the facts and law at the time of the European Commission’s adequacy determination for the U.S. in 2023.” An appeal to the Court of Justice, C-703/25 P, was lodged on 31 October 2025 and is pending; no judgment and no Advocate General’s opinion exists yet.

The honest framing, and the one that stays true whichever way the court rules:

Transfers to the US currently rest on an adequacy decision that has been upheld at first instance and is under appeal to the Court of Justice, which has struck down its two predecessors. Processing that never leaves the EU is not exposed to that outcome either way.

Anyone telling you the framework has been struck down is wrong, and anyone predicting the court is guessing.

What BSI actually says about cloud-assisted detection

German buyers reach for IT-Grundschutz, and OPS.1.1.4.A3 is the requirement that gets misquoted. It says, in substance, that only enterprise products with support tailored to the organisation may be used in professional operation — no home-use or unsupported products — and, on cloud detection:

Cloud-Dienste zur Verbesserung der Detektionsleistung der Virenschutzprogramme SOLLTEN genutzt werden. Falls Cloud-Funktionen solcher Produkte verwendet werden, MUSS sichergestellt werden, dass dies nicht im Widerspruch zum Daten- oder Geheimschutz steht.

Cloud services to improve detection should be used; if they are used, it must be ensured that this does not conflict with data-protection or secrecy obligations (IT-Grundschutz OPS.1.1.4 ). BSI is not telling you to avoid cloud detection. It is telling you to resolve the tension. A product that reaches good detection without shipping content off the machine satisfies both halves instead of trading one against the other.

The same building block is where the neighbouring requirements live — automatic blocking with central reporting (A9), and the rule that users must not be able to change security-relevant settings (A5) — which is why a host-level daemon outside the tenant’s reach maps onto German baseline expectations more comfortably than an in-site plugin does.

The questions to put to any vendor

1. Does the product send file contents anywhere by default? Not “can it be configured not to” — what does a default installation do?
2. What else leaves the machine: file names, paths, hashes, domain names, IP addresses, scan verdicts, telemetry?
3. Where is that documented, and do the technical documentation, the DPA and the licence terms describe the same thing? Where vendor documents disagree, “which one governs?” is a fair procurement question rather than an accusation.
4. Who processes, where, and with which sub-processors? An EU-registered company is not the same as EU-only processing.
5. What is the retention and deletion story at the end of the contract? Point (h) of the supplier-contract requirements in Commission Implementing Regulation (EU) 2024/2690 makes data retrieval and disposal at termination an explicit clause for in-scope providers.
6. Can you get an audit report rather than a marketing page?

Those questions are not optional politeness for regulated buyers: § 30 BSIG requires supply-chain security measures and requires that compliance be documented (BSIG 2025 ). The full list, and how it overlaps with Art. 28(3) GDPR so that one questionnaire can serve both, is in questions to ask a security vendor . The NIS2 scoping picture for hosting providers is in NIS2, GDPR and malware scanning for hosting providers .

Where Shelltrap sits, from its own documentation

• By default no file, no sample and no telemetry leaves the host. Scanning happens on your server, in an unprivileged worker.
• Logs contain no secrets and no file contents. Findings record paths, hashes, sizes, verdicts and the signals that fired.
• The daemon has no network by default. Its systemd unit restricts address families to AF_UNIX; the drop-in that grants network access is installed only if you configure SMTP or webhook notification targets yourself.
• Two outbound connections exist in normal operation, both to Panomity in Germany: licence activation and renewal, which sends the licence key, the server fingerprint, the hostname, the version and the OS; and signature feed downloads, authenticated with the licence token. The fingerprint is a SHA-256 over a fixed prefix and /etc/machine-id.
• Retention is configurable and deletion is never silent. quarantine.retention_days and findings.retention_days are policy values; quarantined material survives package removal unless you pass an explicit purge variable.

That is a short list on purpose, and it is the list we would want to see from a vendor before signing.

What this means for CyberPanel operators

1. Run the Art. 28 assessment on your scanner before you deploy it, and file the result — § 30 BSIG expects documentation, not intentions.
2. Ask what leaves the server by default, and get the answer from technical documentation rather than a brochure.
3. If you use a cloud-assisted product, record how you satisfied the second half of OPS.1.1.4.A3; if you use a local-only product, say so and keep the evidence.
4. Keep the incident evidence chain local too — quarantine, findings and audit records are also personal data, so set retention deliberately; see quarantine or delete .
5. Deployment details, including exactly which sockets and services exist on the host, are in the installation docs .

Shelltrap scans on your server, keeps your customers’ files where they are, and talks to Panomity only about licences and signatures. See what it does .