Empfang Telefon, Chat, Termine, Rückruf
Dokumentation Angebote, Protokolle, Rechnungen
Betrieb Mail, Touren, Projekte, Recruiting
Branchen-Fachwissen SHK, Elektro, Maler
Sichtbarkeit Blog, Google-Profil, Audit
Für Ihre Branche KI-Lösungen für 8 Branchen
Open Source & KI Eigene Plattformen statt SaaS-Inseln
Verkündigung digital Werkzeuge für Gemeinden
Beispiele aus dem Haus KI-Anwendungen, die wir selbst betreiben
Übersicht Alle 56 Produkte auf einer Seite
Alle KI-Lösungen →
Beispiele aus dem Haus
Computer & Laptops PC, Mac, Kaufberatung
Mobilgeräte Smartphone, TV, Fotos
Peripherie & Netzwerk Drucker, WLAN, NAS
Smart Home & IoT Automation, PV, Homeoffice
Alle Hardware-Leistungen →
IT-Infrastruktur VPN, Netzwerk, DSGVO
Business-Software Buchhaltung, Kasse, Zeiterfassung
Web & Marketing Webseite, SEO, WordPress, Newsletter
Entwicklung & Beratung KI-Tools, Automation, Wartung, Beratung
Krypto & Web3 Steuern, Wallets, Mining, DePIN
Monitoring & IoT Sensoren, Dashboards, Alarmierung
Branchen-IT Spezialisierte IT für kleine Betriebe
Service & Recht Termin, Verträge, Karriere
Alle Unternehmens-Leistungen →

Penetrationstest – ehrlich erklärt

Wie tief muss ein Penetrationstest gehen, damit er ehrlich ist?

Ein vollständiger Penetrationstest deckt 13 zentrale Test-Bereiche ab – von der Schwachstellen-Suche im CMS über aktive Injection-Tests, Brute-Force-Versuche auf Login-Strecken, TLS-Tiefenprüfung, DNS-Aufklärung bis zur Phishing-Welle. Diese Seite erklärt jeden Bereich für Laien und Techniker zugleich, mit echten deutschen Cyber-Fällen als Lehrstücke. Und sie sagt offen, wo unsere Grenze liegt.

Schreibtisch mit Laptop, der einen Sicherheits-Befund-Bericht mit roten Markierungen zeigt, daneben ein Stapel Papier mit handschriftlichen Notizen und ein kleiner Netzwerk-Switch
289 Mrd € Schaden durch Cyber-Kriminalität in Deutschland 2025 (Bitkom)
1.041 angezeigte Ransomware-Fälle 2025 (BKA-Lagebild Cybercrime)
~80 % der Angriffe richten sich gegen kleine und mittlere Unternehmen (BSI)
Platz 4 Deutschland im weltweiten Cyber-Angriffsziel-Ranking 2025 (Microsoft Digital Defense)

Was ist eigentlich ein Penetrationstest?

Ein Penetrationstest ist ein beauftragter, kontrollierter Einbruchsversuch in Ihre IT – mit dem Ziel, Schwachstellen zu finden, bevor sie ein echter Angreifer findet. Stellen Sie sich vor: Sie engagieren eine Person, die in Ihr Bürogebäude einsteigen soll – mit Ihrer schriftlichen Erlaubnis. Sie sucht offene Fenster, schlecht abgeschlossene Türen, vergessene Hinterausgänge, freundliche Mitarbeiter, die ihr aufhalten. Am Ende übergibt sie einen Bericht: hier ist die Liste der Schwachstellen, hier die Reihenfolge, in der ich sie ausnutzen würde. Ein Penetrationstest macht genau das – nur digital.

Vier wichtige Begriffe, die oft durcheinandergehen

Schwachstellen-Scan Automatisierte Abfrage einer Datenbank bekannter Lücken: „Ist diese Apache-Version anfällig?" Schneller Überblick, viele falsch-positive Befunde, kein Beweis der Ausnutzbarkeit. Ergebnis: Liste von „könnte sein". Tools: Tenable Nessus, Greenbone OpenVAS.

Penetrationstest Eine Fachperson nutzt Werkzeuge und Erfahrung, um Schwachstellen aktiv auszunutzen und den realen Schaden zu zeigen. Ergebnis: Bericht mit „so weit kam ich, das hätte ich erbeuten können". Tools: Burp Suite, sqlmap, Metasploit, OWASP ZAP – plus Köpfchen.

Red Team Geht weiter: simuliert einen kompletten Angreifer – auch mit Social Engineering, Phishing, physischem Eindringen, Dropbox-Angriffen, Zugriff auf Mitarbeiter. Dauert Wochen bis Monate. Nur für große Organisationen.

Bug Bounty Eine offene Einladung an Sicherheitsforscher weltweit: „Findet Lücken auf unseren Systemen, wir zahlen pro Fund." Plattformen: HackerOne, Bugcrowd, Intigriti. Für kleine Firmen oft zu offen.

Wo Angreifer heute ansetzen – die Angriffsfläche eines KMU

Ihr Unternehmen E-Mail Phishing Website Web-App Cloud M365 VPN Remote Lieferant Supply Mitarb. Endgerät
E-Mail/PhishingHäufigster Eintritts-Vektor 2025. Eine geklickte Mail genügt.
Website/Web-AppVeraltete Plugins, ungeschützte Formulare, SQL-Injection.
Cloud/M365Schwache MFA, kompromittierte Logins, externe Freigaben.
VPN/FernwartungVeraltete Konfiguration, kein MFA, schwache Passwörter.
LieferantSupply-Chain-Angriff: Dienstleister gehackt, Sie betroffen.
MitarbeiterPrivates Endgerät, USB-Stick, Schatten-IT, Datei-Transfer.

Die 13 Test-Bereiche eines vollständigen Penetrationstests

Diese Liste folgt der Praxis großer Sicherheits-Häuser und dem BSI-Standard 200-3. Wir gehen jeden Bereich in der Reihenfolge durch, in der ein realer Angreifer ihn nutzen würde – beginnend mit der Außenaufklärung, dann das gezielte Eindringen, dann die Tiefe.

1

CMS-Schwachstellen – Joomla, WordPress, TYPO3, Shopware

90 Prozent aller echten Joomla- oder WordPress-Lücken stecken nicht im Kern selbst, sondern in den nachinstallierten Erweiterungen – Plugins, Templates, Komponenten. Stellen Sie sich einen Tresor vor, in dessen Wand jemand ein Loch für eine fremde Klimaanlage gebohrt hat. Der Tresor ist sicher, das Loch nicht. Wir suchen nach genau diesen Löchern.

CMS-Version und alle nachinstallierten Komponenten, Module, Plugins und Templates enumerieren. Abgleich mit der CVE-Datenbank des Herstellers und mit öffentlichen Schwachstellen-Listen. Prüfung auf veraltete jQuery-Versionen in Templates, anfällige Komponenten-Routen, ungeschützte Admin-Pfade, Default-Anmeldedaten in Demo-Installationen.

[!] Joomla 4.4.2 erkannt – aktuelle Version 6.1.1 verfügbar (16 CVEs offen) [!] Komponente com_acym 8.0.1 anfällig (CVE-2024-XXXX, RCE über Mail-Template) [!] Template "rt_zephyr" lädt jQuery 1.11.3 (Prototype-Pollution-Lücke) [i] /administrator/ erreichbar, kein IP-Whitelist

Werkzeuge: joomscan, wpscan, nuclei, nikto, Burp Suite, manuelle Component-Enumeration via URL-Parameter-Variation.

2

Aktive Injection-Tests – SQL, XSS, LFI, SSRF, XXE, Command-Injection

Stellen Sie sich ein Formular auf Ihrer Website vor – Kontakt, Login, Suche. Sie tippen einen Namen ein, der Server speichert ihn. Bei einer Injection schickt der Angreifer keinen Namen, sondern eine Anweisung: „Lösche die Tabelle Kunden" oder „Lade die Datei /etc/passwd". Wenn die Website diese Eingabe nicht sauber prüft, führt der Server die Anweisung aus.

Jedes Eingabe-Feld, jeder URL-Parameter und jeder HTTP-Header wird systematisch mit präparierten Werten getestet. SQL-Injection mit klassischen, blinden und zeit-basierten Payloads, sqlmap im Tampering-Modus. XSS in reflektierter, gespeicherter und DOM-basierter Variante. Local-File-Inclusion über Pfad-Traversal-Sequenzen. Server-Side-Request-Forgery gegen Cloud-Metadaten-Endpunkte. XML-External-Entity gegen XML-verarbeitende Routen.

[!] POST /search?q=test'+OR+'1'='1 → Datenbank-Fehler in Antwort (SQLi möglich) [!] GET /profile?name=<script>alert(1)</script> → ungefiltert ausgegeben (reflektiertes XSS) [!] GET /download?file=../../../../etc/passwd → Inhalt der Datei wird ausgeliefert (Path-Traversal) [!] POST /api/import mit XML-DOCTYPE → externe Entität wird verarbeitet (XXE)

Werkzeuge: sqlmap, Burp Suite Repeater und Intruder, OWASP ZAP Active Scanner, manuelle Payload-Konstruktion mit PayloadAllTheThings-Listen.

3

Authentifizierung – Brute-Force, Credential-Stuffing, Session, JWT, Passwort-Reset

Brute-Force heißt: ein Programm probiert systematisch Passwörter durch. Heute nutzt niemand mehr „aaaa, aaab, aaac" – moderne Angriffe nehmen die Top-1.000.000-Liste der häufigsten Passwörter und kombinieren sie mit Listen aus alten Daten-Lecks. Wenn ein Mitarbeiter sein altes LinkedIn-Passwort von 2012 in Ihrem Firmen-Login wiederverwendet, ist er in fünf Sekunden drin.

Login-Endpunkte gegen Wortlisten testen, Rate-Limit-Reaktion prüfen, Lockout-Verhalten messen. Credential-Stuffing-Resistenz mit bekannten Leak-Listen prüfen, ohne dabei echte Anmeldungen zu provozieren. Session-Cookies inspizieren: Secure-Flag, HttpOnly, SameSite, Signatur, Ablauf, Rotation nach Login. JWT-Token analysieren: Algorithmus-Confusion, „none"-Algorithmus, schwache Signatur-Schlüssel, fehlende Audience-Prüfung. Passwort-Reset-Flow testen: vorhersagbare Token, fehlende Bindung an die Session, möglicher Account-Übernahme über die Mail-Adresse.

[!] /login akzeptiert 1.000 Versuche/Minute ohne CAPTCHA und ohne IP-Sperre [!] Session-Cookie ohne Secure-Flag, übertragbar über HTTP [!] JWT signiert mit HS256, geheimer Schlüssel ratbar (Wordlist-Treffer "secret123") [!] Passwort-Reset-Token: 8 Stellen numerisch, Lebensdauer 24h → 10.000 Möglichkeiten

Werkzeuge: Hydra für Login-Tests, Burp Intruder für gezielte Sequenzen, jwt_tool für Token-Analyse, eigene Skripte für Reset-Flow-Tests.

4

HTTP-Methoden und WebDAV

Ein Browser fragt Webseiten meistens mit zwei Befehlen ab: GET (hol mir die Seite) und POST (sende dieses Formular). Es gibt aber viel mehr Befehle – PUT (ersetze diese Datei), DELETE (lösche sie), TRACE (sag mir, was du siehst). Wenn ein Server diese Befehle annimmt, kann ein Angreifer Dateien auf den Server schreiben oder löschen.

Erlaubte HTTP-Methoden pro Endpunkt enumerieren. PUT und DELETE auf Verzeichnisse testen. TRACE auf XST-Verwundbarkeit prüfen. WebDAV-Endpunkte mit cadaver oder curl gegen Authentifizierungs-Bypasse testen. PROPFIND-Antworten auf interne Pfad-Leaks prüfen.

[!] OPTIONS / antwortet mit "Allow: GET, POST, PUT, DELETE, OPTIONS, TRACE, PROPFIND" [!] PUT /test.html mit beliebigem Inhalt → 201 Created (Datei wurde geschrieben) [!] TRACE / → Anfrage-Header werden zurückgespiegelt (XST möglich)

Werkzeuge: curl mit allen HTTP-Methoden, davtest, cadaver, Nikto-Module 0001 bis 0099.

5

API-Sicherheit – Authentifizierungs-Bypass, IDOR, Rate-Limit

Eine API ist die Schnittstelle, über die zum Beispiel eine Smartphone-App mit Ihrer Website redet. Sie ist oft schlechter gesichert als die Website selbst, weil sie unsichtbar ist. Eine häufige Lücke: Sie geben dem Server Ihre Kunden-Nummer 1042 mit – und können einfach 1043 eintippen und sehen die Daten eines anderen Kunden. Das nennt sich IDOR.

Alle API-Endpunkte enumerieren – via Swagger/OpenAPI, robots.txt, Sitemap, Frontend-JavaScript-Analyse. Authentifizierungs-Bypass-Tests an Endpunkten wie /api/v1/users/1, /api/admin, /api/internal. IDOR-Tests durch IDs hochzählen, fremde Daten anfragen, Berechtigungs-Logik prüfen. Rate-Limit-Tests in mehreren Geschwindigkeiten und mit IP-Rotation. JSON-Body-Manipulation für Mass-Assignment-Lücken.

[!] GET /api/v1/users/2 (mit eigenem Token) → Daten eines anderen Users (IDOR) [!] /api/admin/dashboard zugänglich ohne Token, nur via /api Bypass [!] POST /api/profile akzeptiert "is_admin":true im Body (Mass-Assignment) [!] /api/login: 5.000 Versuche/Minute pro IP möglich

Werkzeuge: Postman, Burp Suite Pro mit Logger++, ffuf für Endpunkt-Discovery, Kiterunner.

6

TLS- und SSL-Tiefenprüfung – Cipher-Suites, Heartbleed, BEAST, POODLE, Logjam

Wenn Sie eine Webseite mit https://-Schloss aufrufen, ist die Verbindung verschlüsselt. Aber Verschlüsselung ist nicht gleich Verschlüsselung. Wenn der Server alte Verfahren wie SSLv3 oder TLS 1.0 zulässt, kann ein Angreifer mit Profi-Werkzeugen die Verbindung knacken oder zwischendrin mitlesen. Es gibt eine ganze Reihe historischer Schwachstellen mit Spitznamen wie Heartbleed, POODLE, BEAST, Logjam – wir prüfen sie alle.

Vollständige TLS-Konfiguration testen: erlaubte Protokoll-Versionen, Cipher-Suite-Reihenfolge, Forward Secrecy, OCSP-Stapling, HSTS-Header, HSTS-Preload-Liste, Zertifikats-Kette, Wildcard-Verwendung, Signatur-Algorithmus, RSA-Schlüssel-Stärke, Diffie-Hellman-Parameter, Renegotiation-Verhalten. Klassische Schwachstellen prüfen: CVE-2014-0160 (Heartbleed), CVE-2014-3566 (POODLE), CVE-2011-3389 (BEAST), CVE-2015-4000 (Logjam).

[!] TLS 1.0 und 1.1 noch erlaubt → BEAST-Angriff möglich [!] CBC-Cipher-Suites bevorzugt → Lucky-Thirteen-Risiko [!] Diffie-Hellman-Parameter: 1024 Bit → Logjam-Risiko [i] HSTS aktiv mit max-age=31536000, kein Preload

Werkzeuge: testssl.sh (Open-Source-Profi-Tool), sslyze, SSL Labs (Qualys), nmap mit ssl-enum-ciphers.

7

DNS-Aufklärung – SPF/DKIM/DMARC, Subdomain-Enumeration, Zone-Transfer

DNS ist das Telefonbuch des Internets. Wenn Sie ihre-firma.de eintippen, fragt der Browser einen DNS-Server, wo das liegt. In den DNS-Einträgen stehen aber auch Sicherheits-Regeln – wer darf in Ihrem Namen Mails verschicken (SPF), wie sind die Mails signiert (DKIM), was passiert bei Fälschungen (DMARC). Wenn diese Einträge fehlen, kann jeder Beliebige eine Mail mit Ihrer Domain als Absender verschicken. Genau so funktioniert fast jede Phishing-Welle.

DNS-Records vollständig auflisten: A, AAAA, MX, TXT, NS, SOA. SPF-Record prüfen: Strenge des all-Mechanismus, Anzahl der Lookups, includes. DKIM-Schlüssel der relevanten Selektoren testen. DMARC-Policy auswerten: p=none, p=quarantine, p=reject, rua-Adressen. MTA-STS und DANE-Records prüfen. Subdomain-Enumeration über öffentliche Zertifikats-Transparenz-Logs (crt.sh), passive DNS, Wortlisten-Bruteforce. Zone-Transfer-Versuche gegen alle Nameserver.

[!] SPF: "v=spf1 +all" → jeder darf in Ihrem Namen senden [!] DMARC fehlt komplett [!] Subdomain dev.firma.de gefunden (in crt.sh), läuft auf veraltetem Apache 2.2 [!] MTA-STS fehlt → Mail-Transport unverschlüsselt erzwingbar [i] Zone-Transfer auf ns1 verweigert (gut)

Werkzeuge: dig, dnsrecon, amass, subfinder, crt.sh, MXToolbox, MailHardener, dnstwist für Domain-Squatting-Erkennung.

8

Datei- und Pfad-Discovery – Backups, vergessene Endpunkte, .git, .env

Webserver enthalten oft Dateien, die nicht für die Öffentlichkeit gedacht sind, aber trotzdem erreichbar liegen. Eine Backup-Datei vom letzten Update („index.php.bak"), eine .env-Datei mit Passwörtern, ein vergessenes phpinfo.php, ein zurückgelassenes .git-Verzeichnis mit der kompletten Code-Historie. Wir suchen systematisch nach solchen Datei-Leichen.

Wortlisten-basierte Pfad-Aufzählung mit ffuf oder gobuster gegen Standard-Backup-Endungen (.bak, .swp, .old, ~, .save, .orig, .tmp). Common-Sense-Pfade prüfen: /.git/config, /.env, /phpinfo.php, /admin/, /backup/, /test/, /old/, /dev/, /staging/. Sitemap.xml, robots.txt, Source-Maps in JavaScript-Bundles auf interne Pfade prüfen.

[!] /.git/config erreichbar → komplette Repo-Geschichte ladbar (git-dumper) [!] /backup-2024-12.sql.gz (3.4 MB) → Datenbank-Dump öffentlich [!] /info.php → phpinfo() mit Server-Variablen und Pfaden [!] /staging/ → komplette Test-Umgebung mit unverschlüsselten Beispiel-Daten

Werkzeuge: ffuf, gobuster, dirb mit verschiedenen Wortlisten (SecLists), git-dumper, Linkfinder für JS-Source-Maps.

9

Upload-Funktionen – Bewerbung, Mitgliedsantrag, Dateifreigaben

Wenn Ihre Website ein Upload-Feld hat – für Bewerbungen, Mitgliedsanträge, Dateifreigaben – ist das ein direkter Eintritts-Punkt. Wenn der Server nicht streng prüft, was hochgeladen wird, kann ein Angreifer statt eines Lebenslaufs ein PHP-Skript hochladen und dann ausführen. Die Folge: voller Server-Zugriff.

Upload-Endpunkte mit verschiedenen Datei-Typen testen: PHP, JSP, JSP, EXE, SVG mit eingebettetem Skript, polyglotte Dateien (Bild plus Code). Datei-Endung-Filter umgehen mit Doppel-Endungen (.jpg.php), Null-Byte-Tricks (.php%00.jpg), Case-Variation (.PHP). Content-Type-Header manipulieren. MIME-Type-Sniffing prüfen. Hochgeladene Dateien auf Ausführbarkeit im Web-Pfad testen.

[!] /bewerbung-upload akzeptiert shell.php als Lebenslauf → Datei landet in /uploads/, dort ausführbar [!] /api/avatar erlaubt SVG-Upload, SVG mit <script>-Tag wird ungefiltert ausgeliefert (XSS) [!] Doppel-Endung "lebenslauf.pdf.php" wird vom Filter akzeptiert

Werkzeuge: Burp Suite mit benutzerdefinierten Payloads, Upload-Vulnerabilities-Wordlist, polyglotter Datei-Generator (file-magic-injection).

10

CSRF und Session-Fixation

CSRF bedeutet: ein Angreifer bringt Ihren eingeloggten Browser dazu, im Hintergrund eine Aktion auszuführen, die Sie nicht wollten – zum Beispiel eine Überweisung anstoßen oder eine Mail verschicken. Sie sehen davon nichts. Der Schutz dagegen ist ein geheimer Token, der bei jedem Formular mitgeschickt werden muss und den der Angreifer nicht kennen kann. Wenn dieser Token fehlt oder vorhersagbar ist, geht der Angriff durch.

Jedes zustandsverändernde Formular auf CSRF-Token prüfen. Token-Stärke testen: vorhersagbar, an Session gebunden, einmalig, Server-validiert. Session-Fixation prüfen: lässt sich vor dem Login eine Session-ID setzen, die nach dem Login gültig bleibt? SameSite-Cookie-Attribut prüfen. Referer-basierte Schutz-Mechanismen umgehen mit speziell präparierten Sub-Requests.

[!] /einstellungen/passwort-aendern hat keinen CSRF-Token [!] Token in /profil/aktualisieren ist statisch über die ganze Session (replay-bar) [!] Session-ID lässt sich vor Login per URL setzen, bleibt nach Login gültig

Werkzeuge: Burp Suite CSRF Proof-of-Concept-Generator, OWASP ZAP, manuelle HTML-Form-Konstruktion.

11

User-Enumeration – wer gibt sich verräterisch zu erkennen?

Eine sichere Anwendung verrät nicht, ob ein bestimmter Benutzername existiert. Sagt sie bei einer falschen Anmeldung „Benutzer nicht gefunden", kann ein Angreifer systematisch durchprobieren, welche Benutzernamen es gibt – und dann gezielt deren Passwörter angreifen. Gleiche Falle: ein Passwort-Reset, der nur bei existierenden Mail-Adressen eine Bestätigung schickt.

Login-Fehlermeldungen auf Unterschiede zwischen „falscher User" und „falsches Passwort" prüfen. Antwortzeiten messen – manche Server brauchen für existierende Logins minimal länger (Timing-Attack). Passwort-Reset-Flow testen: kommt die gleiche Bestätigung für jede Eingabe? API-Endpunkte für Account-Existenz prüfen. Registrierungs-Formulare auf „diese Mail ist schon registriert"-Meldungen testen.

[!] /login mit falschem User: "Benutzer existiert nicht" / mit falschem Passwort: "Passwort falsch" [!] Passwort-Reset: existierender User → "Mail wurde gesendet", nicht existierend → "Diese Adresse ist nicht hinterlegt" [!] Antwortzeit Login: existierender User 380ms, nicht existierend 95ms (Timing-Leak)

Werkzeuge: Burp Intruder mit Wortlisten, eigene Python-Skripte für Antwortzeit-Messung, Hydra-Spuren-Analyse.

12

Rate-Limit und DDoS-Resilienz

DDoS heißt: ein Angreifer überflutet Ihre Website mit so vielen Anfragen, dass sie zusammenbricht. Echte DDoS-Tests sind heikel, weil sie genau den Effekt produzieren, den wir verhindern wollen. Wir prüfen daher die Vorstufe: wie viele Anfragen verträgt ein Endpunkt, bevor er drosseln oder Anfragen ablehnen sollte? Wenn ein Login-Endpunkt 5.000 Versuche pro Minute durchwinkt, ist das ein offenes Tor für Brute-Force.

Rate-Limit-Verhalten pro Endpunkt prüfen, ohne Last-Tests durchzuführen. Antwort-Header auf Standard-Rate-Limit-Felder prüfen (X-RateLimit-Remaining). Web-Application-Firewall-Verhalten prüfen, falls vorhanden. CDN-Schutz-Mechanismen identifizieren. Cache-Bypass-Versuche durch Parameter-Variation. Nur mit ausdrücklicher Genehmigung führen wir kontrollierte Last-Tests gegen klar abgegrenzte Endpunkte durch, niemals als Bestandteil eines Standard-Audits.

[!] /login: keine Rate-Limit-Header, 5.000 Requests/Minute pro IP möglich [!] /api/registrierung: kein Schutz gegen Massen-Anmeldung [!] Cache-Bypass via ?_=timestamp möglich → Origin-Server direkt erreichbar

Werkzeuge: hping3 für kontrollierte Last-Tests, Burp Intruder für Sequenz-Tests, eigene Python-Skripte für Header-Analyse.

13

Captcha-Bypass

Captchas sollen Bots von Menschen unterscheiden. „Klicken Sie alle Bilder mit Ampeln an." Aber moderne Captchas sind nicht mehr unknackbar: KI-Modelle lösen Bild-Aufgaben in Millisekunden, alte Text-Captchas sind trivial maschinell lesbar. Wir prüfen, ob Ihr Captcha echten Schutz bietet oder nur dekorativ ist.

Captcha-Anbieter identifizieren (reCAPTCHA, hCaptcha, Cloudflare Turnstile, eigene Lösung, das neue Joomla-6.1-Proof-of-Work-Captcha). Token-Wiederverwendung prüfen: lässt sich derselbe Captcha-Token mehrfach einlösen? Server-seitige Validierung prüfen: wird das Token wirklich gegen den Anbieter validiert oder nur Existenz geprüft? Bei eigenen Captchas: KI-Lösbarkeit mit OCR-Tools testen, Audio-Captchas mit Speech-to-Text. Bypass über versteckte Honeypot-Felder.

[!] reCAPTCHA-Token wird auf Server nicht gegen Google validiert [!] Selber Token funktioniert 50-mal hintereinander [!] Eigenes Bild-Captcha wird von tesseract-OCR mit 92% Erfolg gelöst [!] Honeypot-Feld vorhanden, aber Logik prüft es nicht

Werkzeuge: Burp Suite Repeater, tesseract für OCR-Tests, manuelle Token-Replay-Tests.

Wie Angreifer heute wirklich ins Haus kommen

Die Theorie der 13 Test-Bereiche ist die eine Sache. Die Realität 2025/2026 ist eine andere: Die wenigsten Angriffe beginnen mit einer obskuren Software-Lücke. Sie beginnen mit einer Mail oder einem geklauten Passwort. Hier die typische Kette eines modernen KMU-Angriffs.

Die typische Angriffskette in deutschen Mittelstands-Unternehmen

  1. Schritt 1: Phishing-Mail. Eine glaubwürdige Mail mit gefälschtem Microsoft-Logo, Betreff „Ihr Postfach ist voll" oder „DHL-Sendung wartet auf Bestätigung". Der Mitarbeiter klickt, landet auf einer Login-Seite, die exakt aussieht wie die echte – ist es aber nicht. Er tippt Mail-Adresse und Passwort ein.
  2. Schritt 2: Multi-Faktor-Bypass. Der Angreifer leitet den Login in Echtzeit weiter an die echte Microsoft-Seite. Das Multi-Faktor-Prompt geht ans Telefon des Mitarbeiters, der bestätigt – im Glauben, sich gerade selbst anzumelden. Der Angreifer hat jetzt den vollen Session-Token.
  3. Schritt 3: Postfach lesen. Eine bis vier Wochen still im Postfach mitlesen. Geschäfts-Vorgänge verstehen, Vertreter-Regelungen finden, Rechnungs-Mails identifizieren, Vorgesetzte und Buchhaltung mappen.
  4. Schritt 4: CEO-Fraud oder Rechnungs-Manipulation. Eine Mail an die Buchhaltung mit gefälschter Geschäftsführer-Anweisung „bitte heute noch 87.000 Euro überweisen auf Konto…". Oder eine Manipulation einer echten ausgehenden Rechnung: IBAN ändern, Mail noch einmal verschicken.
  5. Schritt 5: Seitwärts-Bewegung. Mit dem kompromittierten Konto auf Cloud-Speicher zugreifen, OneDrive-Daten exfiltrieren, weitere interne Mails verschicken, IT-Admin-Konten attackieren.
  6. Schritt 6: Ransomware oder Erpressung. Wenn der Zugang weit genug ist, wird verschlüsselt oder mit der Veröffentlichung der gestohlenen Daten gedroht. Lösegeld-Forderung: 50.000 bis 500.000 Euro je nach Unternehmens-Größe.

Was hier nirgends auftaucht: die hochkomplexe Software-Schwachstelle. Der ganze Angriff lief über eine Mail, ein Passwort und ein menschliches Klick-Verhalten. Genau deshalb ist Phishing-Simulation als Test-Bereich so wichtig – und ein guter Penetrationstest deckt nicht nur die Technik, sondern auch diese Vektoren ab.

Berühmte deutsche Fälle, die jedes Unternehmen kennen sollte

Diese Beispiele zeigen, was passiert, wenn Schwachstellen nicht rechtzeitig gefunden werden. Allen Fällen ist gemeinsam: rückblickend hätte ein ordentlicher Sicherheits-Audit den Eintritts-Vektor entdeckt. Manche dieser Vorfälle haben Unternehmen Millionen gekostet, einer hat eine ganze Region in den Cyber-Katastrophenfall gebracht.

September 2020

Universitätsklinikum Düsseldorf

Ransomware verschlüsselte 30 Server. Die Notaufnahme musste mehrere Wochen von der Notfallversorgung abgemeldet werden. Eine Patientin musste verlegt werden, die Diskussion um eine mögliche kausale Folge des Cyber-Vorfalls erreichte die Bundespresse. Wochen langer Notbetrieb, Schaden in Millionen-Höhe.

Eintritts-Vektor: bekannte Schwachstelle in einer Citrix-Komponente (CVE-2019-19781), die monatelang nicht gepatcht wurde.

Dezember 2020

Funke Mediengruppe

Ransomware legte über 1.500 Server lahm. Mehrere Tageszeitungen erschienen tagelang nur als Notausgabe. Die Druckereien arbeiteten an Ausweich-Systemen, Online-Portale waren ausgefallen. Wochenlanger Wiederaufbau, geschätzter Schaden im zweistelligen Millionenbereich.

Eintritts-Vektor: Phishing-Mail mit Schadanhang, Trojaner-Familie Emotet als Türöffner für die Ransomware DoppelPaymer.

Juli 2021

Landkreis Anhalt-Bitterfeld – erster Cyber-Katastrophenfall

72 Kommunen mit 22.000 Arbeitsplätzen lahmgelegt, der Landkreis rief den ersten Cyber-Katastrophenfall in Deutschland aus. Bürger-Dienste, Sozialleistungen und KFZ-Anmeldungen mehrere Wochen offline, manche Verfahren Monate lang nur per Stift und Papier. Tätergruppe Akira/Grief, Lösegeld-Forderung in zweistelliger Millionen-Höhe wurde abgelehnt.

Eintritts-Vektor: Phishing-Mail mit verseuchtem Word-Anhang an einen Sachbearbeiter.

August 2022

Continental AG

Ransomware-Gruppe LockBit drang in das Konzernnetz ein und stahl rund 40 Terabyte Daten – inklusive vertraulicher Geschäfts-Dokumente, Personal-Akten, Verhandlungs-Unterlagen. Lösegeld-Forderung 50 Millionen US-Dollar, Continental zahlte nicht, ein Teil der Daten wurde später im Darknet veröffentlicht.

Eintritts-Vektor: Phishing, Mitarbeiter installierte gefälschte Software (geleakter Initial-Access wurde von einem Broker gehandelt).

September 2024

Deutsche Flugsicherung (DFS)

Die mit dem russischen Militär-Geheimdienst GRU in Verbindung gebrachte Gruppe APT28 drang in die administrative IT-Infrastruktur der DFS ein. Der eigentliche Flugverkehr blieb unbeeinträchtigt, aber sensible Daten und interne Mail-Kommunikation wurden kompromittiert. Politisch erheblicher Schaden, mehrere Wochen Aufklärungs-Arbeit.

Eintritts-Vektor: Phishing mit präzisem Spear-Targeting auf einzelne Mitarbeiter (geheime Details).

2024

Rheinmetall AG

Ransomware-Angriff auf das zivile Geschäft des Rüstungs-Konzerns. Produktion in mehreren Tochter-Gesellschaften musste vorübergehend gestoppt werden, geschätzter Schaden rund 10 Millionen Euro. Sensible Konstruktionsdaten und Lieferanten-Korrespondenz wurden teilweise abgegriffen.

Eintritts-Vektor: Spear-Phishing mit auf den Konzern zugeschnittener Mail, Initial-Access-Broker.

2024

Medion AG

Ransomware-Gruppe BlackBasta erbeutete rund 1,5 Terabyte Daten – darunter Mitarbeiter-Personalakten und vertrauliche Geschäftsdaten. Die Daten wurden auf der Leak-Seite der Gruppe veröffentlicht. Imageschaden und mehrwöchige Wiederherstellungs-Arbeit.

Eintritts-Vektor: verschlüsselte Verbindung über einen kompromittierten Mitarbeiter-Account, nach Phishing.

September 2025

Collins Aerospace / Flughafen BER

Ransomware-Angriff auf den Luftfahrt-Zulieferer Collins Aerospace, dessen Software MUSE an europäischen Flughäfen die Passagier-Abfertigung steuert – inklusive Berlin BER. Über mehrere Tage „Ausnahmemodus" am BER mit manueller Abfertigung, Verspätungen, Flugausfällen. Klassischer Supply-Chain-Vorfall.

Eintritts-Vektor: noch nicht öffentlich, vermutlich Schwachstelle in Wartungs-Zugängen des Software-Lieferanten.

Das Muster ist klar: In sechs von acht Fällen war der erste Eintritt eine Phishing-Mail oder ein gestohlener Account – nicht eine exotische Software-Lücke. Genau deshalb prüfen wir in unseren Audits den menschlichen Faktor (Phishing-Simulation), die E-Mail-Sicherheit (SPF, DKIM, DMARC, MTA-STS), die Multi-Faktor-Abdeckung in Microsoft 365 und Google Workspace – und nicht nur die Server-Konfiguration.

Was wir leisten – und was wir ehrlich nicht leisten

Eine ehrliche Selbstauskunft ist Teil der Beratung. Wir sind eine Manufaktur für Digitales mit Sitz in Gronau, kein BSI-zertifiziertes Sicherheits-Haus mit Auditor-Team. Unsere Audits decken die häufigsten Angriffs-Vektoren mit den gleichen Werkzeugen ab, die ein externer Angreifer nutzen würde – aber sie ersetzen keine formale Zertifizierungs-Prüfung.

Das machen wir verlässlich

  • Externer Sicherheits-Check mit Nmap, testssl.sh, OWASP ZAP, Burp Suite
  • CMS-Audit für Joomla, WordPress, TYPO3, Shopware mit joomscan, wpscan, nuclei
  • Aktive Injection-Tests mit sqlmap und manueller Payload-Konstruktion
  • Login- und Session-Strecken inklusive JWT-Analyse
  • API-Sicherheits-Prüfung inkl. IDOR und Authentifizierungs-Bypass
  • TLS-/SSL-Tiefenprüfung mit testssl.sh und sslyze
  • DNS- und E-Mail-Sicherheits-Audit (SPF, DKIM, DMARC, MTA-STS, DANE)
  • Datei-Discovery mit ffuf und gobuster gegen Standard-Wortlisten
  • Microsoft 365 oder Google Workspace Tenant-Audit mit Lese-Zugang
  • Phishing-Simulation für bis zu 50 Empfänger mit GoPhish
  • Schriftlicher PDF-Bericht mit Priorisierung und Reparatur-Empfehlungen

Das machen wir nicht

  • Penetrationstest nach BSI-Standard 200-3 mit zertifizierter Auditor-Bescheinigung
  • Red Team mit Social Engineering, physischem Eindringen, Dropbox-Angriffen
  • Internes Netzwerk-Pentest mit Vor-Ort-Hardware oder VPN-Mitarbeiter-Profil
  • Source-Code-Audit über 5.000 Code-Zeilen (nur Stichproben)
  • Hardware-Pentest gegen IoT-Geräte, Industrie-Steuerungen, OT-Systeme
  • Echte DDoS-Belastungs-Tests gegen produktive Systeme
  • Forensische Aufarbeitung eines laufenden Sicherheits-Vorfalls
  • Compliance-Zertifizierung für ISO 27001, KRITIS, NIS2, TISAX
  • Mobile-App-Pentest gegen Android- und iOS-Apps
  • Hochskalierte Test-Wellen mit mehreren Mannwochen Aufwand

Wenn Sie etwas brauchen, das wir nicht leisten

Wir nennen Ihnen passende Häuser. Für BSI-zertifizierte Penetrationstests, ISO-27001-Audits und Red-Team-Operationen empfehlen wir je nach Branche secunet (Essen), SySS (Tübingen), HiSolutions (Berlin), syret (Hamburg), TÜV-IT (Köln) oder DEKRA. Wir haben keinerlei Provisions-Vereinbarungen mit diesen Häusern und bekommen kein Geld für Empfehlungen. Unser Audit kann als interner Vor-Check dienen, um vor dem teuren formalen Audit die offenkundigen Mängel zu beheben.

Rechtlicher Rahmen – ohne schriftliche Beauftragung kein Test

Penetrationstests ohne schriftliche Einwilligung sind in Deutschland strafbar. §202a–c StGB stellen das Ausspähen und Abfangen von Daten sowie das Vorbereiten solcher Taten unter Strafe – ausdrücklich auch dann, wenn ein Tester gute Absichten hat. Beauftragte Sicherheits-Prüfungen sind erlaubt, solange die Einwilligung des Berechtigten dokumentiert ist. Wir starten keinen Scan ohne unterschriebenen Auftrag.

Sie wissen jetzt, wie tief ein echter Test geht

Wir riegeln Ihre Systeme wieder ab.

.

Externer Sicherheits-Check ab 290 Euro mit 5-Seiten-PDF binnen eines Werktages. Webseiten-Audit ab 690 Euro mit manueller Login- und Session-Prüfung. Komplett-Audit IT-Infrastruktur ab 1.490 Euro mit Microsoft 365 oder Google Workspace Tenant-Prüfung. Phishing-Simulation für Mitarbeiter ab 490 Euro. Komplett remote, schriftliche Beauftragung nach §202c StGB, fester Festpreis.

Pakete und Preise ansehen Direkt anfragen

Quellen und Werkzeuge

Die hier zitierten Zahlen, Standards und Fall-Berichte stammen aus offiziellen Quellen und der Fach-Berichterstattung. Wir verlinken die Originale, damit Sie nachprüfen können, was hier steht.

BSI-Lagebild 2025

Die Lage der IT-Sicherheit in Deutschland – jährlicher Bericht des Bundesamts für Sicherheit in der Informationstechnik. bsi.bund.de

BKA-Bundeslagebild Cybercrime 2025

Polizeiliche Kriminalstatistik zu Cyber-Delikten – 333.922 registrierte Fälle, 1.041 Ransomware-Angriffe. bka.de

Bitkom Schadens-Studie 2025

Repräsentative Hochrechnung der Schäden durch Datendiebstahl, Industrie-Spionage und Sabotage – 289 Milliarden Euro für 2025. bitkom.org

OWASP Top 10

Die international anerkannte Liste der häufigsten Web-Schwachstellen, Grundlage jedes seriösen Web-Pentests. owasp.org

OWASP ASVS

Application Security Verification Standard – Verifikations-Stufen 1 bis 3 für strukturierte Web-Anwendungs-Audits. owasp.org/ASVS

BSI-Standard 200-3

Standard für IS-Penetrationstests – Methodik-Grundlage für formale Penetrationstests in Deutschland. bsi.bund.de/Standards

OSSTMM 3

Open Source Security Testing Methodology Manual – internationale Methodik-Referenz für strukturierte Sicherheits-Audits. isecom.org

CVE-Datenbank

Common Vulnerabilities and Exposures – internationale Schwachstellen-Datenbank, Stand jeden Tag aktualisiert. cve.org

Beschreiben Sie Ihr Problem

Wir melden uns bei Ihnen und finden eine Lösung.

Häufig gestellte Fragen

Was ist der Unterschied zwischen einem Schwachstellen-Scan und einem Penetrationstest?

Ein Schwachstellen-Scan ist eine automatisierte Liste möglicher Probleme – wie ein Brandmelder, der piept. Ein Penetrationstest geht weiter: ein Mensch versucht aktiv, die Schwachstellen auszunutzen und zu zeigen, ob sie wirklich gefährlich sind und welcher Schaden entstehen würde. Der Scan sagt „Tür wirkt nicht abgeschlossen". Der Pentest probiert die Tür, kommt vielleicht rein, und dokumentiert, was im Inneren erreichbar war. Beides hat seinen Platz: Scan für Breite und Routine, Pentest für Tiefe und Realismus.

Wie kommen Hacker heute typischerweise rein – per Brute-Force oder per E-Mail?

Per E-Mail. Das BKA-Lagebild Cybercrime 2025 weist Phishing-Mails als häufigsten Initial-Vektor aus. Ein Mitarbeiter klickt auf einen Link, gibt seine Anmeldedaten auf einer gefälschten Microsoft-Login-Seite ein, der Angreifer hat das Office-365-Konto. Von dort: Postfach lesen, Multi-Faktor schwächen, weitere interne Mails verschicken, Buchhaltungs-Daten kopieren. Brute-Force gegen Logins ist weiter eine Sekundär-Methode, fast immer mit gestohlenen Passwortlisten aus früheren Daten-Lecks. Echte Server-Lücken werden oft erst genutzt, nachdem der erste Fuß in der Tür war.

Warum reicht ein Anti-Virus-Programm heute nicht mehr?

Weil ein moderner Angriff oft gar keine klassische Schadsoftware mehr nutzt. Phishing, Credential-Stuffing und Session-Hijacking laufen über legitime Werkzeuge: Browser, Web-Mail, Cloud-Speicher. Der Anti-Virus sieht nichts Verdächtiges, weil nichts Verdächtiges ausgeführt wird – nur ein gestohlener Login. Was heute wirklich schützt, ist eine Kombination: Multi-Faktor-Auth, Mail-Filter mit DMARC, Mitarbeiter-Awareness, Endpoint-Detection-Response statt klassischem Anti-Virus, und regelmäßige Sicherheits-Checks von außen.

Wie lange braucht so ein Penetrationstest, und wie schnell merke ich ein Problem?

Unsere Stichprobe für 290 Euro läuft ein bis zwei Werktage, das Webseiten-Audit drei bis fünf, das Komplett-Audit fünf bis zehn. Bei einem aktiven Sicherheits-Vorfall können wir den externen Check binnen 24 Stunden starten. Ein BSI-zertifizierter Penetrationstest nach Standard 200-3 läuft typischerweise zwei bis vier Wochen, oft länger, und kostet ab 8.000 Euro aufwärts.

Was ist eigentlich eine SQL-Injection und warum ist sie so gefährlich?

SQL ist die Sprache, in der Webseiten mit ihrer Datenbank reden („Hol mir alle Bestellungen von Kunde 42"). Bei einer SQL-Injection schmuggelt ein Angreifer eigene Datenbank-Befehle in ein Formular-Feld ein, weil die Seite die Eingabe nicht sauber prüft. Der Server führt diese Befehle aus, als kämen sie vom eigenen Code. Folge: ein Angreifer kann ganze Tabellen auslesen – Kunden, Passwörter, Bestellungen – oder Daten verändern. SQL-Injection steht seit über 15 Jahren auf Platz 1 der häufigsten Web-Schwachstellen weltweit und ist immer noch eine der häufigsten Ursachen großer Daten-Lecks.

Was bedeutet Cross-Site-Scripting, kurz XSS?

Ein Angreifer schmuggelt eigenen JavaScript-Code in eine Webseite ein, der dann im Browser anderer Besucher ausgeführt wird. Beispiel: Kommentar-Funktion, die HTML nicht filtert. Der Angreifer postet einen Kommentar mit Code-Schnipsel, jeder andere Besucher führt diesen Code aus – Cookies stehlen, Session übernehmen, fremde Eingaben mitschneiden. Bei reflektiertem XSS reicht ein präparierter Link, den der Nutzer anklickt. Bei gespeichertem XSS sitzt der Code dauerhaft auf der Seite. XSS ist die häufigste Schwachstelle in Web-Anwendungen überhaupt.

Was ist Brute-Force, und warum sind starke Passwörter dagegen nicht genug?

Brute-Force heißt: ein Programm probiert systematisch Passwörter durch. Im einfachsten Fall „aaaa, aaab, aaac …". In der echten Welt: Angreifer nutzen Listen aus bekannten Daten-Lecks, weil Menschen Passwörter wiederverwenden. Wenn Ihr LinkedIn-Passwort 2012 geleakt wurde und Sie es in Ihrem Firmen-Mail noch nutzen, probiert das Programm es dort einfach. Schutz dagegen: kein Wiederverwenden, Passwort-Manager, und vor allem Zwei-Faktor-Authentifizierung – damit reicht das Passwort allein nicht mehr.

Was prüfen Sie alles im Bereich E-Mail-Sicherheit?

Vier Schichten. SPF legt fest, welche Server in Ihrem Namen Mails verschicken dürfen. DKIM signiert jede ausgehende Mail mit Ihrer Domain, damit Empfänger die Echtheit prüfen können. DMARC bindet beides zusammen und sagt Empfängern, was bei einer Fälschung passieren soll. MTA-STS und DANE erzwingen verschlüsselten Mail-Transport. Ohne diese vier Schichten kann jeder Beliebige eine Mail mit Ihrer Domain als Absender verschicken – das ist die Grundlage fast jeder Phishing-Welle. Wir prüfen den aktuellen Stand, die Strenge der Policies, das DMARC-Report-Aufkommen und schlagen einen schrittweisen Härtungs-Plan vor.

Stimmt es, dass deutsche Behörden besonders oft angegriffen werden?

Ja. Das BSI-Lagebild 2025 zeigt, dass kommunale Verwaltungen, Krankenhäuser und Hochschulen seit Jahren überdurchschnittlich oft Ziel von Ransomware sind – weil die IT-Budgets klein sind, viele Altsysteme laufen und die operative Abhängigkeit hoch ist. Der Cyber-Katastrophenfall im Landkreis Anhalt-Bitterfeld 2021 war der erste deutsche IT-Notstand auf Kreis-Ebene. Die Uniklinik Düsseldorf 2020, Funke Mediengruppe 2020, Anhalt-Bitterfeld 2021, Continental 2022 und die Deutsche Flugsicherung 2024 stehen für eine Reihe, die nicht abreißt.

Was ist ein Vulnerability-Scanner und wozu nutzen Sie ihn?

Ein Vulnerability-Scanner ist ein Programm mit einer riesigen Datenbank bekannter Schwachstellen, das systematisch prüft, ob Ihre Systeme davon betroffen sind. Beispiele: Tenable Nessus, Greenbone OpenVAS, Pentest-Tools.com. Der Scanner fragt Ihre Server höflich ab: „Welche Version läuft hier? Apache 2.4.50? Das hatte die Schwachstelle CVE-2021-41773." Er gibt eine priorisierte Liste mit Schweregraden. Wir nutzen mehrere Scanner parallel, weil keiner alles findet, und prüfen die Treffer manuell – Scanner haben oft falsch-positive Befunde, die nur eine Fachperson aussortiert.

Warum brauche ich vor dem Test einen schriftlichen Auftrag?

Weil das deutsche Strafrecht in §202a–c StGB das Ausspähen von Daten und das Vorbereiten solcher Taten unter Strafe stellt. Beauftragte Sicherheitsprüfungen sind ausdrücklich erlaubt – aber nur mit dokumentierter Einwilligung des Berechtigten. Ohne diesen Auftrag wäre selbst ein gut gemeinter Scan strafbar. Die Pentest-Beauftragung definiert Scope, Zeitraum, erlaubte Test-Tiefe und Notfall-Kontakt. Sie schützt beide Seiten: uns vor Strafbarkeit, Sie vor unkontrollierten Tests an Systemen, die nicht zu Ihnen gehören.

Können Sie auch interne Netzwerke prüfen, oder nur die Außensicht?

Wir prüfen ausschließlich von außen und mit authentifiziertem Cloud-Zugang. Ein interner Netzwerk-Pentest – ein Tester sitzt physisch im Firmen-Netz oder bekommt einen VPN-Zugang mit normalem Mitarbeiter-Profil – ist eine andere Disziplin, die wir nicht anbieten. Für interne Tests empfehlen wir spezialisierte Dienstleister wie secunet, SySS, syret oder lokale Sicherheits-Häuser. Wir können den externen Teil übernehmen und Ihnen einen seriösen internen Tester vermitteln.

Ist eine Phishing-Simulation rechtlich problematisch?

Sie ist erlaubt, braucht aber Vorbereitung. Bei Unternehmen mit Betriebsrat ist eine Mitbestimmung nach §87 BetrVG nötig, weil personenbezogene Mitarbeiter-Daten ausgewertet werden. Datenschutzrechtlich ist die Simulation unkritisch, solange die Auswertung anonymisiert bleibt und nur Klick-Raten als Gesamtwert berichtet werden. Wir liefern eine Betriebsrats-Vorlage und eine Mitarbeiter-Information mit, übernehmen aber keine arbeitsrechtliche Beratung. Bei kleinen Firmen ohne Betriebsrat reicht eine vorherige Mitarbeiter-Information.

Was passiert mit den Ergebnissen, und wie sicher ist die Übergabe?

Der Bericht wird als verschlüsseltes PDF per Mail oder über einen verschlüsselten Übertragungs-Weg übergeben. Alle Test-Daten bleiben in deutschen Rechenzentren. Befunde löschen wir nach Abschluss des Auftrags und der gemeinsamen Nachsorge, sofern Sie nichts anderes wünschen. Eine Auftragsverarbeitung nach Art. 28 DSGVO regeln wir separat, wenn im Scope personenbezogene Daten liegen.

Wir wollen das alles erst einmal beheben – wie geht es nach dem Audit weiter?

Drei Wege. Sie können den Bericht an Ihren bestehenden IT-Dienstleister geben – er ist so geschrieben, dass eine erfahrene Fachperson die Empfehlungen abarbeiten kann. Oder wir beheben die Mängel selbst zum Festpreis nach Befund, üblicher Bereich 590 bis 2.490 Euro für 8 bis 25 Anpassungen. Oder Sie buchen unsere Sicherheits-Pflege für 39 Euro pro Monat – quartalsweiser Re-Scan, jährlicher Stichproben-Audit, Hotline für Rückfragen, Frühwarnung bei neuen relevanten Sicherheits-Meldungen.

Cookie-EinwilligungWir nutzen Cookies und externe Dienste (Statistik, Terminbuchung, Kartenmaterial), um unsere Website zu verbessern. Sie können einzelne Kategorien auswählen oder Ihre Auswahl jederzeit im Footer unter „Cookie-Einstellungen“ anpassen. Mehr erfahren
Direkt per WhatsApp schreiben