Automating the Auditor Away: Continuous Security Compliance in the Post-Schrems II Era

If you are still managing server compliance using Excel spreadsheets and manual checklists, you are already compromised. It’s August 2025. The threat landscape has evolved, but more importantly, the regulatory landscape in Europe has solidified into a minefield for the unprepared. For CTOs operating in Norway, the primary adversary isn't just the script kiddie scanning ports; it's the potential for a Datatilsynet audit finding you negligent under GDPR Article 32.

I recently consulted for a Fintech startup in Oslo. They had brilliant code but a chaotic infrastructure. They were deploying to a US-hyperscaler, assuming the provider's certifications covered them. They didn't. When we ran a basic CIS benchmark scan, their "secure" Kubernetes nodes failed 40% of the checks. The fix wasn't buying more security tools; it was treating compliance as code.

This guide moves beyond theory. We will look at how to architect a self-healing, compliant infrastructure using open-source automation tools, specifically tailored for the Norwegian market where data sovereignty is not optional.

The Architecture of "Continuous Compliance"

Security is often seen as a bottleneck. To fix this, we must shift left. Compliance shouldn't be a gate at the end of the development cycle; it should be part of the build process. We are talking about immutable infrastructure where servers are hardened before they ever accept a single byte of production traffic.

We rely on three pillars for this architecture:

1. Base Hardening: The OS layer must be locked down immediately upon provisioning.
2. Configuration Management: State enforcement via tools like Ansible.
3. Continuous Auditing: Automated scanning with OpenSCAP to detect configuration drift.

1. The Base: Hardening SSH and Sysctl

Whether you are running AlmaLinux 9 or Ubuntu 24.04, default configurations prioritize compatibility over security. We need to change that. On a CoolVDS instance, we start by stripping the attack surface.

Your /etc/ssh/sshd_config is the front door. Password authentication in 2025 is unacceptable for root accounts.

# /etc/ssh/sshd_config
PermitRootLogin prohibit-password
PasswordAuthentication no
X11Forwarding no
MaxAuthTries 3
AllowAgentForwarding no
AllowTcpForwarding no
# Use strong algorithms only
KexAlgorithms curve25519-sha256@libssh.org,diffie-hellman-group-exchange-sha256
Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com
MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com

Next, we tune the kernel to mitigate network-based attacks. These settings belong in /etc/sysctl.d/99-security.conf to prevent IP spoofing and man-in-the-middle attacks.

# IP Spoofing protection
net.ipv4.conf.all.rp_filter = 1
net.ipv4.conf.default.rp_filter = 1

# Ignore ICMP broadcast requests
net.ipv4.icmp_echo_ignore_broadcasts = 1

# Disable source packet routing
net.ipv4.conf.all.accept_source_route = 0
net.ipv6.conf.all.accept_source_route = 0

# Log Martians
net.ipv4.conf.all.log_martians = 1

2. Automation with Ansible

Manual editing leads to drift. If you have ten servers, one will eventually be different. Use Ansible to enforce the state. Below is a snippet from a playbook ensuring that auditd (the Linux auditing system) is running and configured—a requirement for most compliance frameworks.

- name: Ensure auditd is installed and running
  hosts: all
  become: yes
  tasks:
    - name: Install auditd
      ansible.builtin.dnf:
        name: audit
        state: present

    - name: Enable auditd service
      ansible.builtin.service:
        name: auditd
        state: started
        enabled: yes

    - name: Set immutable audit rules
      ansible.builtin.lineinfile:
        path: /etc/audit/audit.rules
        line: "-e 2"
        create: yes
        state: present
      notify: Restart auditd

  handlers:
    - name: Restart auditd
      ansible.builtin.service:
        name: auditd
        state: restarted
        use: service # RHEL 9/Alma 9 specific requirement for auditd

Pro Tip: On modern systemd systems (like those on CoolVDS NVMe instances), restarting auditd can be tricky because the kernel holds the process. Use the service command specifically or configure the auditd.service to refuse manual stops to prevent attackers from disabling logging.

3. Continuous Validation with OpenSCAP

You’ve hardened the server. How do you prove it to an auditor? OpenSCAP allows you to scan your system against standard profiles like the CIS Benchmark or DISA STIG.

Install the scanner:

sudo dnf install openscap-scanner scap-security-guide

Run a scan against the CIS Server Level 1 profile. This command generates an HTML report you can literally hand to your compliance officer.

oscap xccdf eval \
  --profile xccdf_org.ssgproject.content_profile_cis_server_l1 \
  --results scan-results.xml \
  --report report.html \
  /usr/share/xml/scap/ssg/content/ssg-almalinux9-ds.xml

If you see red in that report, you have work to do. Integrating this command into a weekly cron job allows you to detect if a sysadmin temporarily opened a port and forgot to close it.

The Sovereignty Trap: Why Location Matters

Technical configuration is only half the battle. The other half is legal. Since the Schrems II ruling and the subsequent transatlantic frameworks, storing personal data of Norwegian citizens on US-owned cloud infrastructure involves complex Transfer Impact Assessments (TIAs). It is a legal headache that pragmatic CTOs avoid by simply choosing local infrastructure.

When we provision infrastructure on CoolVDS, we aren't just buying CPU cycles. We are buying a legal firewall. The data stays in Oslo or compliant European data centers. The NVMe storage guarantees that I/O wait times don't masquerade as application latency, but the jurisdiction guarantees that I don't wake up to a lawsuit.

Infrastructure as Code (IaC) Workflow

For a robust setup, your deployment pipeline should look like this:

1. Provision: Terraform spins up a CoolVDS instance (utilizing the high-performance KVM backend).
2. Configure: Ansible applies the cis-hardening role immediately.
3. Verify: OpenSCAP runs a baseline scan. If the score is <90%, the pipeline fails.
4. Deploy: Only then is the application code deployed.

Conclusion

Compliance is not about checking boxes; it is about operational discipline. By automating your hardening with Ansible and verifying it with OpenSCAP, you reduce the Total Cost of Ownership (TCO) significantly. You stop chasing fires and start preventing them.

However, automation on top of shaky foundations is futile. You need a host that respects data sovereignty and provides the raw I/O performance required for heavy encryption and logging overheads. Don't let compliance slow you down.

Next Step: Audit your current hosting environment. If you aren't hitting 100% on your data sovereignty checks, deploy a hardened test instance on CoolVDS today and experience the peace of mind that comes with local, compliant power.