Automating CIS & GDPR Compliance: A CTO’s Guide to Surviving Audits in 2022

Let’s be honest: nobody wakes up excited to configure SELinux contexts. But in a post-Schrems II world, where the Norwegian Data Protection Authority (Datatilsynet) is scrutinizing data transfers more than ever, technical compliance isn't optional. It is survival.

If you are still hardening your servers by hand—logging in via SSH, editing /etc/ssh/sshd_config manually, and restarting services—you are doing it wrong. Manual hardening is prone to drift. It is unscalable. And when the auditor asks for proof of compliance for the last six months, you will have nothing but a vague memory of running an update command.

This guide isn't about policy documents. It is about Infrastructure as Code (IaC) for security. We will look at how to automate CIS Level 1 benchmarks on a Linux VPS, ensuring your infrastructure is compliant from the millisecond it boots.

The "Schrems II" Reality Check

Before we touch the terminal, we need to address the elephant in the server room. Since the CJEU judgment in July 2020, relying on US-owned cloud providers for processing Norwegian citizen data has become a legal minefield. Standard Contractual Clauses (SCCs) are no longer a "get out of jail free" card.

This is where infrastructure choice becomes a technical control. Hosting on CoolVDS isn't just about the raw NVMe I/O performance (though we will get to that); it is about data sovereignty. Our datacenters are physically located in Oslo. The jurisdiction is Norway. When you automate compliance here, you aren't just checking a box for security; you are checking a box for legal defensibility.

Phase 1: The Base Hardening (The "Must-Haves")

Every generic OS image is insecure by default. It has to be, to ensure compatibility. Your job is to lock it down immediately.

Forget complex firewalls for a second. Start with SSH. It is the front door. If you are using passwords, stop. If you are allowing root login, stop.

Here is the baseline sshd_config we deploy on our high-security internal nodes. This restricts key exchange algorithms to the strongest ones available in OpenSSH 8.x (standard in 2022).

# /etc/ssh/sshd_config snippet

# Disable legacy protocol fallback
Protocol 2

# Keys only. No exceptions.
PasswordAuthentication no
ChallengeResponseAuthentication no
PubkeyAuthentication yes

# Stop the bots from hammering root
PermitRootLogin no

# Crypto hardening (Check `man sshd_config` for algorithm details)
KexAlgorithms curve25519-sha256@libssh.org,diffie-hellman-group-exchange-sha256
Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com
MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com

Pro Tip: Always validate your SSH configuration with sshd -t before restarting the service. I have seen seasoned sysadmins lock themselves out of a remote VPS in Oslo while sitting in a cafe in Berlin. It is a long walk to fix it.

Phase 2: Automating with Ansible

Manual edits drift. Automation persists. We use Ansible because it is agentless. You don't need to install extra software on your CoolVDS instance to manage it; you just need SSH access.

We are going to use the CIS (Center for Internet Security) Benchmark rules. Implementing the full 200+ page PDF manually is insanity. Instead, use the Ansible-Lockdown roles.

Here is a practical playbook structure. This assumes you are running AlmaLinux 8 or Ubuntu 20.04 LTS.

The Playbook: harden_server.yml

---
- name: Apply CIS Level 1 Hardening
  hosts: norway_production
  become: yes
  vars:
    # Don't break the app by disabling essential ports
    sysctl_overwrite:
      net.ipv4.ip_forward: 1
      
    # Enforce strong password policies
    pam_password_quality:
      minlen: 14
      dcredit: -1
      ucredit: -1
      ocredit: -1
      lcredit: -1

  tasks:
    - name: Ensure AIDE is installed for file integrity monitoring
      package:
        name: aide
        state: present

    - name: Set permissions on /etc/crontab
      file:
        path: /etc/crontab
        owner: root
        group: root
        mode: '0600'

    - name: Disable unused filesystems (Cramfs, Freevxfs, Jffs2, Hfs, Hfsplus, Squashfs, Udf)
      modprobe:
        name: "{{ item }}"
        state: absent
      with_items:
        - cramfs
        - freevxfs
        - jffs2
        - hfs
        - hfsplus
        - squashfs
        - udf

    - name: Lock down shared memory (prevents buffer overflow exploits)
      lineinfile:
        path: /etc/fstab
        regexp: '^tmpfs\s+/run/shm'
        line: 'tmpfs /run/shm tmpfs defaults,noexec,nosuid,nodev 0 0'
        state: present
      notify: Remount shm

  handlers:
    - name: Remount shm
      mount:
        path: /run/shm
        state: remounted

Running this script takes about 45 seconds on a CoolVDS instance. Doing it manually takes 4 hours.

Phase 3: Verify with OpenSCAP

Trust, but verify. How do you prove to an auditor that the playbook actually worked? You use OpenSCAP (Security Content Automation Protocol).

OpenSCAP scans your system against a specific profile (like PCI-DSS or CIS) and generates an HTML report showing exactly what passed and what failed.

Install it quickly:

# On RHEL/AlmaLinux 8
dnf install openscap-scanner scap-security-guide

Now, run a scan to check for compliance with the standard security profile:

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

You can download that report.html and hand it directly to your compliance officer. It turns a nebulous "we are secure" statement into a factual, timestamped document.

The Hardware Bottleneck

Security has a cost. Encryption (LUKS), File Integrity Monitoring (AIDE), and continuous logging (Auditd) consume CPU cycles and I/O. On a budget VPS with spinning rust (HDD) or oversold SSDs, enabling auditd to log every `execve` system call can tank your application performance. The "iowait" metric will spike, and your site latency will suffer.

This is where the underlying infrastructure matters.

At CoolVDS, we use KVM virtualization exclusively. Unlike OpenVZ or LXC containers used by budget providers, KVM provides a true kernel isolation. This is critical for security modules like SELinux to function correctly without interference from the host node.

Local Nuances: The "Datatilsynet" Factor

In Norway, GDPR is not just a suggestion. The Datatilsynet has been aggressive in 2021 regarding lack of access controls. By automating the pam_password_quality and SSH restrictions shown above, you address specific articles of the GDPR regarding "appropriate technical measures."

Furthermore, latency matters. If your security appliances (WAF, IDS) are routing traffic to Frankfurt and back to verify a request, you are adding 30-40ms of round-trip time. Hosting in Oslo keeps that latency inside the single digits for Norwegian users. We peer directly at NIX (Norwegian Internet Exchange), ensuring your compliant traffic doesn't take unnecessary scenic routes through Sweden or Denmark.

Conclusion

Compliance is a moving target. The script you write today needs to be updated next month when a new CVE drops. But by building a pipeline with Ansible and OpenSCAP, you stop treating security as a one-time project and start treating it as a feature of your deployment.

Don't let legacy infrastructure throttle your security tools. If you need a platform that can handle heavy encryption and logging overhead without breaking a sweat, it is time to upgrade.

Ready to harden your stack? Deploy a CoolVDS NVMe instance in Oslo today and run your first OpenSCAP scan in under 5 minutes.