The Era of "Check-Box" Compliance is Dead

If the Schrems II ruling in July 2020 didn't wake you up, nothing will. For those of us managing infrastructure in Norway, the legal landscape shifted violently. The Datatilsynet (Norwegian Data Protection Authority) made it clear: relying on the Privacy Shield for US data transfers is no longer a valid strategy. But strict data sovereignty is only half the battle. The other half is proving that your local infrastructure is actually secure.

I recently audited a fintech startup in Oslo. They had perfect legal contracts but their servers were a disaster. They were running Ubuntu 18.04 instances that hadn't been patched in six months, and SSH keys were being shared via Slack. Documentation doesn't stop hackers; configuration does.

As a CTO, you cannot rely on manual checklists. Humans forget. Humans get tired. Automation is the only way to ensure that the server you deployed today adheres to the same security standards as the one you deployed six months ago. Here is how we enforce compliance through code, ensuring your VPS Norway infrastructure satisfies both the auditors and your engineering team.

The Core Problem: Configuration Drift

You spin up a fresh NVMe instance. You lock it down. It’s perfect. Two weeks later, a junior dev temporarily opens port 8080 for debugging. They forget to close it. Six months later, you fail a PCI-DSS scan—or worse, you get breached.

To solve this, we treat compliance as code. We don't manually edit /etc/ssh/sshd_config. We deploy a state.

Step 1: Hardening at the Source with Ansible

In 2021, if you are manually typing commands into a terminal to configure a production server, you are doing it wrong. We use Ansible to enforce CIS (Center for Internet Security) benchmarks. Unlike shell scripts, Ansible is idempotent—you can run it a thousand times, and it will simply ensure the state matches the definition.

Here is a snippet from our base hardening role used on internal CoolVDS management nodes. This ensures SSH is locked down immediately upon provisioning:

- name: Secure SSH Configuration
  hosts: all
  become: yes
  tasks:
    - name: Disable password authentication
      lineinfile:
        path: /etc/ssh/sshd_config
        regexp: '^PasswordAuthentication'
        line: 'PasswordAuthentication no'
        state: present
      notify: Restart SSH

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

    - name: Ensure SSH Protocol 2 is used
      lineinfile:
        path: /etc/ssh/sshd_config
        regexp: '^Protocol'
        line: 'Protocol 2'
        state: present

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

This is basic, but foundational. If a developer tries to manually change PasswordAuthentication to yes, the next Ansible run changes it back. Compliance becomes self-healing.

Step 2: Continuous Auditing with OpenSCAP

Applying configurations is one thing; proving them is another. OpenSCAP is the industry standard for verifying system compliance against known profiles (like NIST or PCI-DSS). It is lightweight and runs natively on most Linux distributions.

Instead of hiring an external consultant to manually check your servers, you can run an automated scan. Here is how you install and run a compliance scan on an Ubuntu 20.04 LTS server:

# Install OpenSCAP and the security guide
sudo apt-get update
sudo apt-get install libopenscap8 ssg-base ssg-deb ssg-modules ssg-applications

# Run a scan against the standard 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-ubuntu2004-ds.xml

The output is an HTML report you can hand directly to an auditor. It highlights exactly which configurations passed and which failed.

Pro Tip: Do not run heavy SCAP scans during peak traffic hours. While efficient, the CPU usage can spike during the file system crawl. On CoolVDS, our isolated vCPU resources mitigate the impact on neighbors, but your own application latency might jitter. Schedule these via cron for 03:00 AM CET.

The "Data Sovereignty" Architecture

Automation means nothing if the underlying platform violates the law. This is where the choice of hosting provider becomes a compliance decision, not just a technical one. Since the Schrems II verdict, sending personal data to US-owned cloud providers (even their "European" regions) carries legal risk due to the US Cloud Act.

We built CoolVDS on a simple premise: Jurisdictional purity.

• Physical Location: Our datacenters are in Oslo. Data does not leave Norway unless you move it.
• Ownership: We own the hardware. There are no sub-processors with ambiguous legal standings.
• Virtualization: We use KVM. This provides a hard kernel separation between your environment and the host. Unlike container-based VPS solutions where kernel exploits can leak data between tenants, KVM offers the isolation required for strict GDPR compliance.

Automating Updates (Unattended Upgrades)

One of the most common findings in audit reports is outdated packages. You cannot rely on logging in to run apt-get upgrade. On Debian/Ubuntu systems, unattended-upgrades is mandatory for security patches.

# /etc/apt/apt.conf.d/50unattended-upgrades
Unattended-Upgrade::Allowed-Origins {
    "${distro_id}:${distro_codename}";
    "${distro_id}:${distro_codename}-security";
    // Extended Security Maintenance (ESM)
    "${distro_id}ESMApps:${distro_codename}-apps-security";
    "${distro_id}ESM:${distro_codename}-infra-security";
};

Combine this with a monitoring agent (like Zabbix or Nagios) to alert you if a reboot is required. This ensures your kernel is patched against the latest CVEs without human intervention.

Comparing Security Approaches

Conclusion: Compliance is an Engineering Problem

The days of separating "DevOps" from "Security" are over. If you are handling Norwegian user data in 2021, you are legally obligated to ensure appropriate technical measures are in place. Manual hardening is not an appropriate measure—it is a gamble.

By combining Infrastructure as Code with a sovereign hosting provider like CoolVDS, you reduce your Total Cost of Ownership and sleep better at night. You satisfy the Datatilsynet, you satisfy your customers, and you protect your business.

Ready to build a compliant infrastructure? Deploy a KVM instance on CoolVDS today and start with a secure foundation.