Security & compliance audit report
This is the kind of deliverable behind our Cybersecurity & Compliance work: a scan from our audit toolchain, mapped against frameworks like CIS, PCI DSS, and NIST SP 800-53, and turned into findings a team can actually act on.
Sample report — read before the findings
This host is a test system we built and own, intentionally configured with security and compliance gaps, purely to demonstrate the kind of report we produce for a real customer engagement — it is not a client's system and contains no client data. The findings below are a representative sample, not the full extent of what our audits check.
This sample reflects a real scan of a lab environment we built specifically for this demo: an intentionally under-hardened Ubuntu 20.04 host running nginx, PostgreSQL, and SSH. It surfaces the categories of issues a production audit typically finds — unpatched dependencies with known CVEs, configuration drift against CIS benchmarks, exposed service-level weaknesses, and gaps against GDPR's Article 32 security-of-processing requirements — with the same evidence and remediation guidance we deliver in a real client engagement.
Scope: Single Linux server (Ubuntu 20.04, nginx, PostgreSQL, SSH) — an isolated lab environment we built and own for this demo.
Local privilege escalation in systemd (CVE-2023-26604)
Vulnerability scanning matched the installed systemd package (245.4-4ubuntu3.24) to a published local privilege-escalation CVE (CVSS 7.8) affecting unpatched Ubuntu 20.04 hosts.
Remediation: Patch systemd to the latest distro-supported release and restart affected services.
Outdated Werkzeug library with multiple known CVEs
The application stack ships Werkzeug 0.16.1, several releases behind current, matching multiple published CVEs (highest CVSS 8.0) including request-smuggling and denial-of-service issues.
Remediation: Upgrade Werkzeug (and the Flask/cryptography packages pinned alongside it) to current patched versions.
SSH root login permitted
CIS benchmark check 5.2.8 ("Ensure SSH root login is disabled") failed — sshd_config permits direct root login rather than requiring per-user authentication with escalation.
Remediation: Set PermitRootLogin no in sshd_config; require named accounts with sudo for privileged access.
No file integrity monitoring tooling installed
CIS check "Ensure AIDE is installed" failed — there is no host-based file integrity monitoring in place, so unauthorized changes to system or web content would not be detected.
Remediation: Install and baseline a file integrity monitoring tool (e.g. AIDE, or the FIM module of an existing security agent) covering system binaries and the web root.
Host-based firewall not installed or enabled
CIS checks for ufw ("installed" and "service enabled") both failed — the host has no host-based firewall filtering inbound connections.
Remediation: Install ufw (or equivalent) and enable a default-deny inbound policy, allowing only the ports the host actually serves.
Untrusted TLS certificate and verbose server banner
The web service presents a self-signed TLS certificate (not chained to a trusted CA), and CIS Nginx check "Ensure server_tokens directive is set to off" failed — nginx returns its full version string ("nginx/1.18.0 (Ubuntu)") in response headers.
Remediation: Issue a certificate from a trusted CA (or internal PKI trusted by clients) and set server_tokens off in the nginx configuration.
Database accepts unencrypted connections
The database is configured with ssl = off and listens on all interfaces, so any personal data it holds would transit the network — and authenticate — in plaintext rather than under "appropriate technical measures" for confidentiality.
Remediation: Enable TLS on the database (ssl = on with a valid certificate) and require it for all connections (hostssl in place of host in the access-control config).
Brute-force login attempts detected and logged
A simulated brute-force run against SSH was correctly detected: repeated authentication failures triggered a real alert ("Maximum authentication attempts exceeded", severity 8) with the source, account, and timestamp captured. This is the kind of monitoring GDPR expects for "regularly testing and evaluating" security measures and for meeting the 72-hour breach-notification clock — but detection alone doesn't fix the underlying weak-auth exposure in F-03.
Remediation: Route this alert class to an on-call channel or SIEM rule with automated blocking (e.g. fail2ban or an active-response rule) rather than log-only visibility.
A real engagement covers considerably more ground than fits on one page: the full CIS benchmark for every installed service, deeper GDPR/PCI DSS/HIPAA/SOC 2 control mapping, authenticated and unauthenticated application testing, and a prioritized remediation roadmap. This page is a glimpse of the format and depth, not the complete scope of what we check.
Our role is to help you find security and compliance gaps and work with you to fix them. We are not a certification body or accredited auditor for any framework referenced here, and nothing in this report — or in an engagement with us — is or implies a certification, attestation, or compliance seal (for example, a PCI DSS Attestation of Compliance, an ISO 27001 certificate, or a SOC 2 report). Any public claim of compliance with a given standard can only be made through that standard's own accredited certifying body, and remains your organization's responsibility to obtain and represent accurately.