Sicherheitsstandards für Unternehmens-CMS

#Konformitäts-Rahmenwerke: das Fundament

SOC 2 und ISO 27001 bewerten den Betreiber, nicht den Theme-Code. Wer das verwechselt, kauft ein Zertifikat und behält ein offenes xmlrpc.php.

#SOC 2 Type II

SOC 2 Type II attestiert, dass Kontrollen für Sicherheit, Verfügbarkeit, Vertraulichkeit, Verarbeitungsintegrität und Datenschutz über einen Prüfzeitraum wirksam waren, nicht nur an einem Stichtag. In deutschen CMS-Projekten sitzt das Attest fast immer beim Hosting- oder Cloud-Anbieter. Raidboxes nennt für die Rechenzentren ISO 27001, ISO 22301 und SOC 2 Type 2, das ist ein Standortnachweis, kein Attest über Ihren Plugin-Bestand. Cloudflare legt SOC 2 und zusätzlich ein C5:2020-Report in das Dashboard. Hetzner hat im März 2026 ein C5-Testat Typ 2 bekannt gegeben.

Keines dieser Papiere deckt Ihr Plugin custom-checkout-fields ab. Der Scope steht im Bericht. Lesen Sie den Scope, bevor Sie in einer Ausschreibung “SOC2-konforme WordPress-Instanz” schreiben.

#ISO 27001

ISO/IEC 27001 verlangt ein Informationssicherheits-Managementsystem: Asset-Inventar, Risikobehandlung, Lieferantensteuerung, interne Audits, Management Review. Für ein CMS heißt das konkret: Liste der Plugins und ihrer Zulieferer, Patch-Prozess mit Frist, Zugriffskonzept für Redaktion und Agentur, Auftragsverarbeitung mit Hosting und CDN.

ISO 27001 auf dem Rechenzentrum von Raidboxes oder Hetzner erbt die WordPress-Installation nicht. Der ISMS-Schnitt sitzt dort, wo Sie Änderungen freigeben: Git, Staging, Production, wer plugin install darf.

SOC 2 und ISO 27001 sind in DAX- und Public-Sector-Beschaffung übliche Filter. Sie sind nicht gesetzlich vorgeschrieben für jeden Mittelstandsauftritt. Wer sie als magische Eigenschaft von WordPress verkauft, fällt im Vendor-Fragebogen bei der ersten Rückfrage zum Scope durch.

#Zero-Trust-Architektur für das Web

Zero Trust für ein CMS bedeutet: keine vertrauenswürdige Quell-IP, jede Admin-Sitzung wird neu bewiesen. Das alte Modell “Büro-VPN gleich Intranet gleich wp-admin” ist der Standardfund in deutschen Agenturnetzen.

#Verbindliche Multi-Faktor-Authentifizierung

Passwort plus E-Mail-Link ist 2026 kein angemessener Schutz für wp-admin. SMS-OTP scheitert an SIM-Swap. Setzen Sie FIDO2: YubiKey, Windows Hello, oder Passkeys. WordPress 7.1 kann Application Passwords für REST und CLI ausstellen. Diese Tokens sind keine zweiten Faktoren, sie sind langlebige Geheimnisse. Rotieren Sie sie, beschränken Sie sie auf den REST-User, und speichern Sie sie nicht in einem öffentlichen Git-Repo der Agentur.

Cloudflare Access (Zero Trust) vor wp-admin und /wp-login.php ersetzt in der Praxis das Firmen-VPN für verteilte Redaktionen. Allowlist nur der Büro-IPs bricht, sobald jemand im Zug arbeitet. Access mit IdP (Entra ID, Google Workspace, Keycloak) hält die Richtlinie zentral.

#Granulares IAM

Redakteure brauchen edit_posts, keine install_plugins. SEO-Rollen brauchen keine manage_options. WooCommerce-Shopmanager brauchen Bestellungen, keine Theme-Datei-Editoren. DISALLOW_FILE_EDIT in wp-config.php bleibt die erste Zeile gegen eine kompromittierte Redaktionskennung.

Für Agenturzugang gilt dasselbe Least-Privilege-Prinzip wie intern. Eine gemeinsame admin-Kennung auf All-Inkl, die fünf Freelancer teilen, macht jedes Audit-Trail wertlos. Pro Person ein Konto, nach Projektende deaktivieren, nicht umbenennen.

#Infrastruktur-Hardening: die Server-Ebene

Ein CMS ist so sicher wie PHP-FPM, der Dateibaum und der Weg in die Datenbank. Hosting-Marketingtexte ersetzen keine sshd_config.

Immutable Infrastructure ist auf Kubernetes- oder Image-basierten Hetzner-Cloud-Instanzen umsetzbar: neues Image, Rolling Replace, kein SSH-Handwerk auf Production. Auf All-Inkl-KAS und vielen Managed-WP-Tarifen existiert dieses Muster nicht. Dort ersetzen Sie Drift durch: keine manuellen Plugin-Uploads, Staging gleich Production, Deploy nur aus Git.

WAF und DDoS. Raidboxes liefert einen Security Shield plus DDoS-Schutz auf der Box. Cloudflare WAF sitzt davor und filtert Credential Stuffing gegen wp-login.php, bekannte Plugin-Paths und XML-RPC. All-Inkl stellt TLS und ein Panel bereit, die WAF bauen Sie selbst oder Sie legen Cloudflare davor. “KI-Firewall” ohne benannten Produktnamen und ohne Regelset ist kein Kontrollziel.

Backend nicht öffentlich. In Hochsicherheitsumgebungen hat wp-admin keinen öffentlichen A-Record. Zugriff läuft über Cloudflare Tunnel oder ein WireGuard-VPN auf Hetzner. Der Origin spricht nur mit dem Tunnel, nicht mit dem Internet. Das ist der Punkt, an dem Headless und gehärteter Monolith sich treffen: die PHP-Fläche verschwindet aus den Shodan-Treffern.

PHP und Core. WordPress 7.1 auf PHP 8.4. Alte 8.1-Images auf einem Root-Server in Falkenstein sind ein Patch-Problem, kein Feature. xmlrpc.php blocken (Nginx return 403 oder WAF), außer ein legitimes System braucht ihn nachweislich. REST für unauthentisierte Nutzer auf das einschränken, was das Frontend wirklich liest.

Deutsche Hosting-Wahl in der Praxis:

#BSI IT-Grundschutz für WordPress- und WooCommerce-Stacks

Im deutschen Beschaffungsprozess entscheidet das Modell, nicht das CMS-Logo. Für WordPress und WooCommerce binden vor allem APP.3.1 Webanwendungen und APP.3.2 Webserver. Wer nur SYS.1.1 auf den Hetzner-Server legt und PHP ignoriert, hat den Stack nicht modelliert.

#APP.3.1 Webanwendungen

APP.3.1 gilt für jede HTTP-Anwendung, die dynamische Inhalte und geschützte Ressourcen anbietet. WordPress ist genau das: Sessions, Cookies, Authentisierung, Dateiupload, REST. Basisanforderung APP.3.1.A1 verlangt Authentisierung, bevor geschützte Ressourcen erreichbar sind. wp-admin und die WooCommerce-REST-API (/wp-json/wc/v3) sind geschützte Ressourcen. Ein öffentlicher Warenkorb ist es nicht, ein Application-Password-Endpunkt ist es.

Weitere APP.3.1-Themen, in WordPress-Sprache:

• Eingaben validieren und ausgeben escapen (Core macht das in den APIs, Custom-Checkout-Felder oft nicht).
• Session-Cookies: secure, httponly, strikte Idle-Timeouts für Shopmanager.
• Fehlerseiten ohne Stacktraces. WP_DEBUG_DISPLAY auf Production bleibt aus.
• Dateiupload nur in kontrollierte Pfade, kein PHP in uploads.
• Protokollierung von Admin- und Gateway-Ereignissen, nicht von jeder Katalogansicht.

WooCommerce erweitert APP.3.1 um Bestell- und Zahlungsflüsse. Jedes Checkout-Plugin ist eine weitere Webanwendung im Sinne des Bausteins, auch wenn es als plugin.php daherkommt.

#APP.3.2 Webserver

APP.3.2 schützt den Dienst, der HTTP entgegennimmt: Nginx oder Apache, TLS, Module, PHP-FPM als vorgeschalteter Interpreter. Ziel des Bausteins ist der Schutz des Webservers und der darüber ausgelieferten Informationen, nicht das Redaktionskonzept.

APP.3.2.A1 (sichere Konfiguration) übersetzt sich so:

• Nur nötige Module. Kein mod_status öffentlich, kein Directory Listing auf /wp-content.
• TLS 1.2/1.3, aktuelle Cipher, HSTS. Let’s Encrypt auf Raidboxes reicht technisch, das Zertifikatsmanagement muss trotzdem im Konzept stehen.
• Getrennte vHosts für Origin und ggf. Staging. Staging nicht über dasselbe Zertifikat und denselben Admin-User wie Production erreichbar aus dem Internet.
• PHP-FPM-Pool nicht als root, open_basedir bzw. systemd-Isolation auf Hetzner-Boxen.

Headless verschiebt APP.3.2: der öffentliche Edge liefert statisches HTML ohne Interpreter. Der Origin bleibt ein Webserver mit PHP und fällt weiter unter APP.3.2, nur nicht mehr öffentlich. Details zur Architektur stehen im TCO-Leitfaden Headless vs. Monolith.

#Weitere Bausteine, die der Stack nachzieht

#C5 an die Hosting-Wahl koppeln

Der C5-Katalog (Cloud Computing Compliance Criteria Catalogue) testiert Cloud-Dienste. C5:2026 ist die aktuelle BSI-Fassung, aufbauend auf C5:2020, mit Bezügen zu ISO 27001:2022 und NIS2. Ein Testat Typ 2 prüft Wirksamkeit über einen Zeitraum.

Mapping, das in Ausschreibungen standhält:

• Hetzner IaaS. C5 Typ 2 deckt Rechenzentrum, Virtualisierung, Provider-API ab. Nginx, Redis, MariaDB, WordPress bleiben Ihre Controls. Wer “wir hosten C5-konform, also ist der Shop C5” schreibt, verfehlt den Scope.
• Cloudflare. Das C5:2020-Report gilt für Cloudflare-Dienste im Berichtsscope (typisch WAF, CDN, DNS, Access). Es gilt nicht für PHP auf dem Origin und nicht für Mollie-Webhooks.
• Raidboxes (Managed WP). Plattform mit ISO 27001, ISO 22301 und SOC 2 Type 2 laut Anbieterangabe, Rechenzentrum in Deutschland. Das ist ein starker Hosting-Nachweis. Es ist kein C5-Testat für Ihren Checkout. Plugin-Updates, die Sie verzögern, fallen aus dem Plattform-ISMS heraus.
• All-Inkl. Geeignet für kleine Auftritte. Für eine C5- oder Public-Sector-Ausschreibung fehlt der Cloud-Katalog-Nachweis. Dann entweder Origin auf Hetzner legen oder den Managed-WP-Anbieter mit testierter Plattform wählen.

C5 ersetzt APP.3.1 nicht. C5 spricht über den Cloud-Anbieter. APP.3.1 spricht über Ihre Anwendung.

#TR-03183 ist SBOM, kein Plugin

Die BSI TR-03183 ist die Technische Richtlinie zu Cyber-Resilienz-Anforderungen, als Einstiegshilfe in den Cyber Resilience Act (Verordnung (EU) 2024/2847). Sie ist weder verbindlich noch eine Konformitätsvermutung. Teil 2 beschreibt die Software Bill of Materials (SBOM), aktuell in Version 2.1.0, mit Zuordnung zu SPDX und CycloneDX. Teil 1 liegt in Version 1.0.0 (veröffentlicht 5. August 2026). Der CRA gilt vollständig ab 11. Dezember 2027, Meldepflichten für ausgenutzte Schwachstellen starten am 11. September 2026.

TR-03183 installiert man nicht als WordPress-Plugin. Man erzeugt aus Core, Themes, Plugins, Composer- und npm-Lockfiles eine maschinenlesbare Stückliste. Ein Shop mit Germanized, Stripe, Mollie, DHL und drei Must-Use-Plugins hat entsprechend viele Zulieferer. Genau das prüft Beschaffung 2026, nicht ein grünes “Security”-Icon im Plugin-Verzeichnis.

#NIS2: Logging, Patch-SLA, Meldung, kein KRITIS-Automatismus

Das NIS-2-Umsetzungsgesetz ist am 6. Dezember 2025 in Kraft getreten und setzt die Richtlinie (EU) 2022/2555 in das BSI-Gesetz um. Wichtige und besonders wichtige Einrichtungen melden erhebliche Vorfälle gestuft an das BSI: Frühwarnung in 24 Stunden, aktualisierte Meldung in 72 Stunden, Abschlussbericht in einem Monat (NIS-2-Richtlinie Art. 23).

Das macht einen WooCommerce-Shop nicht zur kritischen Infrastruktur. KRITIS bleibt an Betreibertypen gebunden (Energie, Wasser, Gesundheit, Finanzen in den dafür vorgesehenen Regimen). Ein Händler mit 800 SKUs ist deshalb nicht KRITIS. NIS2 greift, wenn Ihre Organisation in den Kreis der wichtigen oder besonders wichtigen Einrichtungen fällt, oder wenn Sie IKT-Dienstleister einer solchen Einrichtung sind. Dann verlangt der Kunde Nachweise in der Lieferkette.

Was das am WordPress-Stack konkret heißt:

• Logging. Admin-Logins, Rollenänderungen, Plugin-Installationen, Gateway-Webhooks, fehlgeschlagene MFA. Ziel außerhalb der WordPress-Instanz (Syslog auf Hetzner, oder eine SIEM-Strecke). Aufbewahrung so, dass ein Vorfall von letzter Woche noch rekonstruierbar ist.
• Patch-SLA. Kritische Core- und Gateway-CVEs in einer dokumentierten Frist, nicht “wenn der Freelancer Zeit hat”. Raidboxes-Auto-Updates erfüllen das nur, wenn Sie Ausnahmen (Germanized, PAYONE) ebenfalls fristen.
• Incident Reporting. Ein Runbook mit Erreichbarkeit, Verantwortlichen, und dem 24/72-Stunden-Pfad. Ohne das ist jede NIS2-Klausel im AVV leere Prosa.

DORA (seit 17. Januar 2025) gilt für Finanzunternehmen und ihre IKT-Drittdienstleister, nicht für jeden Shop. Wer WooCommerce für ein beaufsichtigtes Institut betreibt, landet in Vertrags- und Ausstiegsanforderungen der BaFin-Welt. Die Readiness-Strecke dafür liegt unter NIS2- und DORA-Readiness.

#Angriffsfläche: Headless vs. Monolith

Headless reduziert die öffentliche PHP-Fläche. Es löscht nicht die Anwendung im Sinne von APP.3.1.

Monolith. Jede Seite rendert PHP gegen MariaDB. Plugins hängen in init. Angreifer scannen /wp-content/plugins/ auf bekannte Pfade. WAF und Auto-Updates werden zur Überlebensausrüstung, nicht zum Extra.

Headless (Astro 7 vor WordPress). Das CDN liefert HTML, CSS, Assets. Kein PHP-Interpreter am Edge, keine öffentliche Datenbank. wp-admin hängt im privaten Netz oder hinter Cloudflare Access. Die Restfläche sitzt auf dem Origin: REST, Webhooks, Cron, Anwendungs-Passwörter. Ein geleaktes Application Password gegen /wp-json/ ist weiterhin ein Vorfall.

Für Enterprise-Beschaffung ist Headless oft leichter zu argumentieren, weil APP.3.2 am öffentlichen Rand ohne Interpreter auskommt. Der Origin bleibt prüfpflichtig. Eine ehrliche TCO- und Zonenrechnung steht im Headless-vs-Monolith-Leitfaden.

#Governance für Code und Plugins

Der häufigste Enterprise-Fund in WordPress ist nicht eine Zero-Day in Core 7.1, sondern ein Plugin ohne Maintainer, das eval auf einem Transient ausführt.

Inventar vor Installation. Kein Plugin ohne benannten Maintainer, ohne Update-Pfad, ohne Verzeichnis in der SBOM. WooCommerce-Checkout, Germanized, PAYONE, Unzer, DHL: jedes Paket ist Zulieferer. “Einmal schnell Custom Fields” ist ein zweiter Checkout.

Manual Code Review für alles, was nicht vom Hersteller über einen signierten Update-Kanal kommt. Must-Use-Plugins und Agentur-mu-plugins gehören in Git, nicht nur auf den Server.

Vulnerability Tracking. Patchstack, WPScan oder die Advisory-Mails der Gateway-Hersteller. CVE-Listen ohne Patch-SLA sind Dekoration. OPS.1.1.3 verlangt den Änderungsprozess: wer darf Production anfassen, welches Staging, welches Rollback.

Composer und npm. Themes mit Build-Step schleppen Lockfiles ein. Die Lockfile-Versionen gehören in dieselbe SBOM wie die PHP-Plugins. TR-03183 Teil 2 erwartet maschinenlesbare Komponentenkennung, nicht eine Excel-Liste “Plugin XY, aktuell”.

ERP-Anbindung. Sobald Bestände und Preise aus SAP Business One, Microsoft Dynamics, JTL oder plentyONE kommen, ist das Plugin ein zweites IAM. API-Keys nicht in wp_options im Klartext, nicht im Frontend-HTML, Rotation nach Personenwechsel. Architektur und Schnittstellen: WooCommerce-ERP-Integration.

#Datenintegrität und Backups

Ein Sicherheitskonzept ohne getestete Wiederherstellung ist ein PDF.

3-2-1 in der deutschen Hosting-Realität. Raidboxes-Backup ist Kopie 1, oft auf derselben Plattform. Kopie 2 auf eine Hetzner Storage Box in einem anderen Standort (Falkenstein vs. Nürnberg) oder IONOS HiDrive. Kopie 3 offline oder in einem anderen Account, den die Production-Credentials nicht löschen können. Ransomware, die wp-config.php und das Panel-Passwort hat, löscht gern auch das “offizielle” Backup.

RPO für WooCommerce. Tagesbackup reicht für eine Broschüren-Site. Ein Shop mit Tagesumsatz im vierstelligen Bereich verliert bei RPO 24 Stunden Bestellungen, die bereits an DATEV oder das ERP gegangen sein können. Dann brauchen Sie mindestens stündliche DB-Dumps plus Binlog, oder den Managed-Backup-Rhythmus des Hosters plus asynchrone Replikation.

PITR. Point-in-Time Recovery auf MariaDB (Hetzner, eigene VM) oder das Backup-Produkt des Managed-Hosters. Vorher einmal im Quartal restore auf Staging, Stoppuhr, Protokoll. NIS2- und DORA-Fragebögen fragen genau dieses Protokoll, nicht die Marketing-SLA.

Geographie. Frankfurt plus Amsterdam klingt nach Enterprise. Für DSGVO und C5 ist der Satz “EU, AVV liegt vor, Subprozessorliste ist aktuell” relevanter als der Stadtname. Cloudflare als CDN liefert am Edge, Origin und Backup bleiben in der dokumentierten Region.

#Das menschliche Risiko: Social Engineering

Die meisten wp-admin-Übernahmen in Agenturprojekten beginnen mit einer Mail, nicht mit einem Exploit.

Redaktion und Buchhaltung sind das Ziel, weil sie Bestellungen, Rechnungen und PDF-Plugins sehen. Eine Mail “DATEV-Export fehlerhaft, bitte hier anmelden” gegen eine gefälschte Login-Seite zieht, wenn MFA fehlt. Awareness-Training ohne Phishing-Simulation bleibt Folie. Eine Simulation pro Quartal, mit der echten Login-URL als Lehrinhalt, wirkt mehr als ein Jahrestraining.

Audit Trails. Jede Plugin-Installation, jede Rollenänderung, jeder Gateway-Key-Wechsel: User, Zeit, IP, Objekt. WP Activity Log oder das Audit-Log des Hosters, ausgeleitet, nicht nur in wp_posts. Das menschliche Risiko sinkt nicht durch Moral, sondern durch die Gewissheit, dass die Aktion nachvollziehbar ist.

Agentur-Seitenwechsel: wenn der Freelancer das Projekt verlässt, fliegt der Account am selben Tag. Gemeinsame 1Password-Tresore mit einem wp-admin-Passwort für alle sind das Gegenteil von ORP.4.

#Checkout-Plugins und die Angriffsfläche der Zahlungs-Gateways

Der Katalog darf am Edge cachen. Checkout, wc-ajax, PayPal-Webhooks und Mollie-Returns dürfen das nicht. Genau dort hängt die Angriffsfläche, die ein Performance-Leitfaden nicht abdeckt.

Rechtliche Checkout-Plugins (DE). Germanized (Vendidero) und German Market (MarketPress) hängen Widerruf, AGB, USt-IdNr., Kleinunternehmer und PDF-Rechnung in den Checkout. Jedes zusätzliche Feld ist APP.3.1: Speicherung, Validierung, Ausgabe. Die USt-IdNr. ist Steueridentifikationsdatum, kein Marketing-Feld. Sie gehört nicht in ein öffentliches debug.log und nicht in ein HTML-Fragment, das Query Monitor auf Production ausgibt.

Versand. DHL for WooCommerce, Packstation, Postnummer. Packstation-Nummer plus Postnummer ist personenbezogen. Das Plugin spricht Versand-APIs, oft mit einem Token in wp_options. Token-Rechte auf das Minimum (Label, Tracking), nicht auf das gesamte Geschäftskundenkonto.

Gateways, die deutsche Shops wirklich nutzen. WooCommerce PayPal Payments, Stripe, Mollie (Klarna, Sofort, Karte), Amazon Pay, PAYONE, Unzer. Jedes Gateway öffnet:

1. einen Redirect oder ein iframe/hosted field,
2. einen Webhook-Endpunkt unter /wc-api/ oder /wp-json/,
3. oft einen Status-Cron.

Ohne Signaturprüfung am Webhook bucht ein Angreifer Bestellungen auf “bezahlt”. Stripe und PayPal liefern Signaturen. Eigenbau-”Payment complete if GET secret=” ist der klassische Fund.

PCI-adjacent, ohne den Shop zum Acquirer zu machen. Wenn Kartenfelder beim PSP liegen (Stripe Elements, PayPal Hosted Fields, Mollie Components), bleibt der Händler typischerweise bei SAQ A nach PCI DSS. Sobald ein Plugin PAN oder CVC in wp_postmeta schreibt, ist diese Annahme tot. Prüfen Sie die Postmeta-Keys nach einer Testbestellung. Speichert das Plugin card_last4 plus Token, ist das üblich. Speichert es die volle Nummer, ist das Gateway sofort auszubauen.

REST und Application Passwords. wc/v3/orders mit einem zu weit berechtigten Key ist voller Zugriff auf Kundendaten. Keys pro System (ERP, DATEV-Bridge, Versand), read-only wo möglich, IP-Allowlist am Origin.

HPOS (High Performance Order Storage) gehört in den Performance-Stack, nicht hierher. Sicherheitsrelevant ist nur: Bestelltabellen erben dieselben Grants wie wp_posts. Ein SQL-User für WordPress mit GRANT ALL auf den ganzen Cluster bleibt ein Fehler, HPOS hin oder her.

#Object-Cache und PCI-nahes Logging

Redis beschleunigt Objekt-Lookups. Ungefiltert speichert es auch Sessions, Transients und gelegentlich Gateway-Antworten. Das ist der Punkt, an dem Performance-Tuning zum PCI- und GoBD-Problem wird.

Was nicht in Redis darf. Rohantworten von Stripe/PayPal mit Token im Klartext über die Cache-TTL hinaus, Warenkorb-Sessions mit Zahlungsdaten, Query-Monitor-Output, WP_DEBUG-Dumps. Object-Cache-Keys von WooCommerce (wc_, product_, Session-Keys) vor einem Dump nach Staging prüfen. Ein redis-cli monitor auf Production, das in eine Ticket-Datei wandert, ist ein Datenabfluss.

debug.log und Query Monitor. WP_DEBUG_LOG nach wp-content/debug.log plus ein per Verzeichnis listbares uploads ist ein öffentliches Protokoll. USt-IdNr., E-Mail, Adresse, Packstation landen dort, sobald ein Gateway eine Exception wirft. Log-Ziel: außerhalb von DocumentRoot, Rotation, Zugriff nur für Ops.

DATEV ist die Buchhaltungssenke, kein Syslog. Deutsche Shops exportieren Buchungsstapel nach DATEV (Rechnungswesen, Unternehmen online). GoBD verlangt Nachvollziehbarkeit der Buchung, nicht das Ablegen von Kartennummern im Buchungsjournal. Getrennte Pfade:

• Security-Log (Logins, Webhooks, Deploys) auf Syslog oder SIEM.
• Bestell- und Rechnungsjournal in WooCommerce, unveränderbar nach GoBD-Logik (Germanized-Revisions, DATEV-Export).
• Kein Copy-Paste von debug.log in das DATEV-Paket.

Wer “wir loggen alles nach DATEV” schreibt, vermischt zwei Kontrollziele und fällt im PCI-Fragebogen und im Steuer-Audit gleichzeitig auf.

Cache vs. Warenkorb. Full-Page-Cache (Cloudflare, Raidboxes Advanced Cache) nur auf Katalog und Content. Cookie woocommerce_items_in_cart oder die Session darf die Cache-Bypass-Regel auslösen. Ein gecachter Mini-Cart fremder Kunden ist ein Vertraulichkeitsvorfall, kein Performance-Gewinn. Die Performance-Seite dieses Stacks (HPOS, Redis-Hitrate, Cart Fragments) liegt in einem eigenen Leitfaden. Hier zählt nur: Cache-Keys und Logs dürfen keine Zahlungs- oder Session-Fremddaten tragen.

#Warum WPPoland der Partner für Enterprise Security ist

WPPoland härtet WordPress- und WooCommerce-Stacks gegen die Standards, die deutsche Beschaffung tatsächlich prüft: SOC 2- und C5-Scope des Hosters, APP.3.1/APP.3.2, Zero Trust auf wp-admin, SBOM nach TR-03183, Checkout- und Gateway-Fläche.

1. Security-first im Code. OWASP Top 10 als Prüfgrid, nicht als Folientitel. Custom-Checkout und ERP-Mapper gehen durch Review, bevor sie auf Production liegen.
2. Monitoring plus Review. Scanner (CVE, File Integrity) laufen dauerhaft. Menschliche Review sitzt auf Gateway-Updates, Rollenänderungen und Restore-Tests.
3. Nachweise, keine Sprüche. Patch-SLA, Restore-Protokoll, Subprozessorliste, Runbook mit 24/72-Stunden-Pfad. Das ist das Lieferobjekt in NIS2- und DORA-Fragebögen.

Der Einstieg ist ein WordPress-Sicherheitsaudit. Für regulierte Lieferketten ergänzt das die Strecke NIS2- und DORA-Readiness.

#Fazit: Sicherheit ist ein Prozess, kein Produkt

Ein Unternehmens-CMS 2026 besteht die Prüfung, wenn Hosting-Nachweis, Anwendungsmodell und Betrieb zusammenpassen. SOC 2 und ISO 27001 filtern den Anbieter. APP.3.1 und APP.3.2 modellieren WordPress und den Webserver. C5 hängt an Hetzner, Cloudflare oder der Managed-WP-Plattform, nicht am Theme. NIS2 verlangt Logs, Patch-Fristen und eine Meldekette, sobald die Organisation oder der Auftraggeber im Scope ist. KRITIS ist ein Betreibertyp, kein Shop-Feature.

TR-03183 liefert die SBOM-Sprache für den CRA, kein Plugin. Am Checkout entscheiden Signaturprüfung, SAQ-A-Grenze und das, was Redis und debug.log nicht enthalten dürfen. DATEV bekommt Buchungen, das SIEM bekommt Admin- und Webhook-Ereignisse.

Sicherheit bleibt ein Zyklus: inventarisieren, härten, überwachen, wiederherstellen, nachweisen. Wenn dieser Zyklus fehlt, ändert kein Zertifikat des Hosters den nächsten Vorfall.

Entspricht Ihr CMS den aktuellen Sicherheitsstandards? Der nächste Schritt ist ein Sicherheitsaudit.