Stop Treating Compliance as a One-Time Event

If you are still manually editing /etc/ssh/sshd_config to satisfy an annual security audit, you have already lost. In the post-Schrems II era, where the Datatilsynet (Norwegian Data Protection Authority) is increasingly vigilant about data transfers and processor agreements, reliance on manual checklists is professional negligence.

I recently audited a fintech setup in Oslo that claimed to be ISO 27001 ready. Their documentation was perfect. Their reality? Three "forgotten" dev servers exposed port 22 to the public internet because a junior developer needed quick access from home. A botnet found them in 14 minutes. The documentation was a lie because the infrastructure had drifted.

The only solution for a pragmatic CTO is Compliance as Code. You define the state of your infrastructure in code, apply it automatically, and continuously scan for drift. Here is how we build a self-healing, compliant architecture on CoolVDS, ensuring your data residency remains strictly within Norwegian borders.

The Foundation: Immutable Infrastructure

Compliance begins with the platform. You cannot secure a noisy neighbor environment where hypervisor escapes are a theoretical probability. This is why we rely on KVM (Kernel-based Virtual Machine) at CoolVDS. Unlike container-based VPS solutions (OpenVZ/LXC) where the kernel is shared, KVM provides strict hardware virtualization. Your memory pages are yours. Your CPU instruction sets are yours.

But the OS layer is your responsibility. Let's automate the hardening process using Ansible. We aren't just "securing" the server; we are applying the CIS (Center for Internet Security) Benchmark Level 1 automatically.

1. Automating SSH Hardening with Ansible

Instead of hoping your admins remember to disable root login, enforce it. This Ansible task ensures that even if someone manually changes the config, the next playbook run reverts it to a secure state.

- name: Secure SSH Configuration
  hosts: all
  become: yes
  tasks:
    - name: Ensure SSH Protocol 2 is used
      lineinfile:
        path: /etc/ssh/sshd_config
        regexp: '^Protocol'
        line: 'Protocol 2'
        state: present

    - name: Disable Root Login
      lineinfile:
        path: /etc/ssh/sshd_config
        regexp: '^PermitRootLogin'
        line: 'PermitRootLogin no'
        state: present

    - name: Disable Password Authentication
      lineinfile:
        path: /etc/ssh/sshd_config
        regexp: '^PasswordAuthentication'
        line: 'PasswordAuthentication no'
        state: present
      notify: Restart SSH

  handlers:
    - name: Restart SSH
      service:
        name: sshd
        state: restarted

Continuous Auditing: OpenSCAP

Applying the configuration is step one. Verifying it is step two. You don't need expensive proprietary scanners. OpenSCAP is the industry standard for checking Linux systems against the Security Content Automation Protocol (SCAP).

On an AlmaLinux 9 or Ubuntu 22.04 instance running on CoolVDS, you can install the scanner and the SCAP security guide to audit against PCI-DSS or GDPR profiles.

Running a Compliance Scan

Here is how you run a scan against the standard security profile and generate a human-readable HTML report. This report is often sufficient evidence for auditors.

# Install OpenSCAP and Security Guides
sudo apt-get update && sudo apt-get install libopenscap8 sshed -y

# Run the evaluation against the Ubuntu 22.04 profile
oscap xccdf eval \
  --profile xccdf_org.ssgproject.content_profile_cis_level1_server \
  --results scan-results.xml \
  --report scan-report.html \
  /usr/share/xml/scap/ssg/content/ssg-ubuntu2204-ds.xml

Pro Tip: Do not run this manually. Add it to a cron job that runs every Sunday night. Have the script `scp` the HTML report to a secure, write-only storage bucket. This gives you an immutable history of your compliance posture.

Network-Level Compliance: Firewalls are not optional

GDPR Article 32 requires "a process for regularly testing, assessing and evaluating the effectiveness of technical and organisational measures." If you are using ufw manually, you are failing. Use Terraform or Ansible to manage iptables or cloud firewalls.

Below is a snippet for nftables (the modern replacement for iptables) that drops all traffic by default and only allows established connections and SSH from a specific VPN IP. This is the level of paranoia required for sensitive data.

#!/usr/sbin/nft -f

flush ruleset

table inet filter {
    chain input {
        type filter hook input priority 0; policy drop;

        # Accept loopback
        iif lo accept

        # Accept established and related traffic
        ct state established,related accept

        # Allow SSH only from Admin VPN IP (Example)
        ip saddr 192.0.2.10 tcp dport 22 accept

        # Allow HTTP/HTTPS for public web server
        tcp dport { 80, 443 } accept

        # ICMP rate limiting to prevent flood
        ip protocol icmp limit rate 10/second accept
    }
    chain forward {
        type filter hook forward priority 0; policy drop;
    }
    chain output {
        type filter hook output priority 0; policy accept;
    }
}

Data Residency & The "Cloud Act" Problem

Technical configuration is meaningless if the physical server falls under a jurisdiction that contradicts your legal obligations. This is the "Schrems II" problem.

Many US-based hyperscalers (AWS, Azure, GCP) are subject to the US CLOUD Act, which can theoretically compel them to hand over data stored in Europe to US authorities. For strictly regulated industries in Norway—healthcare, finance, legal tech—this is a massive risk.

CoolVDS operates differently. We are a Norwegian entity. Our NVMe storage arrays are physically located in data centers in Norway. We are not a subsidiary of a US corporation. When you run a `traceroute` from Oslo, you see 1-3ms latency because the data isn't traversing the Atlantic. This physical sovereignty, combined with the automated hardening described above, creates a robust defense against both hackers and legal ambiguity.

The