NIS2 & GDPR: Automating Security Compliance for Norwegian Infrastructure

It is October 2025. The NIS2 directive has been fully enforceable for a year, and the grace period for "figuring it out" is over. If you are running infrastructure in Europe—or handling the data of Norwegian citizens—the days of manual security hardening are dead. You cannot manually SSH into 50 servers to check if PasswordAuthentication is set to no without expecting a breach or a fine from Datatilsynet.

I speak to CTOs weekly who treat compliance as a PDF they sign once a year. That is a fatal error. Compliance is a state of infrastructure, not a document. If your VPS Norway nodes aren't self-healing and self-auditing, you are already non-compliant.

In this guide, we are going to build a compliance-as-code pipeline. We will move from "hoping we are secure" to mathematically proving it using OpenSCAP, Ansible, and the raw performance of CoolVDS NVMe storage to handle the I/O overhead of continuous scanning.

The Sovereignty Baseline: Why Location Matters

Before we touch a single config file, we must address the physical layer. Under GDPR and current Schrems II interpretations, where your data sits is as important as how it is encrypted. Hosting sensitive EU data on US-controlled hyperscalers remains a legal minefield.

Pro Tip: Latency is the best lie detector. If your provider claims "Norwegian Hosting" but your ping to NIX (Norwegian Internet Exchange) in Oslo is >30ms, they are likely routing you through Frankfurt or Amsterdam. Real domestic hosting like CoolVDS delivers sub-5ms latency within Norway, ensuring data actually stays within the jurisdiction.

Step 1: The Initial Hardening (Cloud-Init)

Security starts before the server accepts its first request. When provisioning a new instance, we utilize cloud-init to lock down the environment immediately. We don't want a window of opportunity where the root user has a default password.

Here is a production-grade user-data script we use to bootstrap secure nodes. This disables root login, sets up a firewall, and installs the audit daemon immediately.

#cloud-config
users:
  - name: deploy_admin
    groups: sudo
    shell: /bin/bash
    sudo: ['ALL=(ALL) NOPASSWD:ALL']
    ssh_authorized_keys:
      - ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAI... secure-key

package_update: true
package_upgrade: true

packages:
  - ufw
  - fail2ban
  - auditd
  - libpam-tmpdir

runcmd:
  - sed -i -e '/^PermitRootLogin/s/^.*$/PermitRootLogin no/' /etc/ssh/sshd_config
  - sed -i -e '/^PasswordAuthentication/s/^.*$/PasswordAuthentication no/' /etc/ssh/sshd_config
  - ufw default deny incoming
  - ufw default allow outgoing
  - ufw allow 22/tcp
  - ufw allow 443/tcp
  - ufw enable
  - systemctl restart sshd

This script ensures that by the time the server creates its SSH keys, it is already rejecting password attempts. It is basic, but 40% of breaches happen because someone forgot the basics.

Step 2: Kernel Level Tuning for DDoS Protection

While CoolVDS provides upstream ddos protection, your OS network stack must be tuned to handle the noise without collapsing. We need to mitigate SYN floods and bogon networks at the kernel level.

Apply these settings to /etc/sysctl.conf:

# 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

# SYN Flood protection
net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_max_syn_backlog = 2048

To apply these changes without a reboot, run:

sysctl -p

Step 3: Automated Auditing with OpenSCAP

This is where the "Elite" separate themselves from the amateurs. Instead of manually checking configs, we use the OpenSCAP (Security Content Automation Protocol) scanner against the CIS (Center for Internet Security) benchmarks.

First, install the necessary tools on your Ubuntu 24.04 or RHEL 9 system:

sudo apt-get install libopenscap8 scap-security-guide -y

Now, run a scan to see how your server stacks up against the official CIS Level 2 Server benchmark. Warning: This process is I/O intensive. On standard HDDs, this can lock up your system for minutes. On CoolVDS NVMe storage, it completes rapidly without impacting web traffic.

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

This command generates an HTML report telling you exactly which configurations violate the standard. It provides a pass/fail status for hundreds of checks, from file permissions to kernel modules.

Step 4: Remediation via Ansible

Scanning is useless if you don't fix the issues. We use Ansible to enforce the state. If a junior developer accidentally opens port 8080 or changes a file permission, Ansible reverts it on the next run.

Here is a concise Ansible playbook snippet that enforces SSH hardening rules compliant with most GDPR audits:

---
- name: Hardening SSH and Sysctl
  hosts: all
  become: yes
  tasks:
    - name: Ensure SSH Protocol 2 is enforced
      lineinfile:
        path: /etc/ssh/sshd_config
        regexp: '^Protocol'
        line: 'Protocol 2'
        state: present
      notify: restart_ssh

    - name: Disable X11 Forwarding
      lineinfile:
        path: /etc/ssh/sshd_config
        regexp: '^X11Forwarding'
        line: 'X11Forwarding no'
        state: present

    - name: Ensure maximum auth tries is low
      lineinfile:
        path: /etc/ssh/sshd_config
        regexp: '^MaxAuthTries'
        line: 'MaxAuthTries 3'
        state: present

    - name: Set idle timeout interval
      lineinfile:
        path: /etc/ssh/sshd_config
        regexp: '^ClientAliveInterval'
        line: 'ClientAliveInterval 300'
        state: present

  handlers:
    - name: restart_ssh
      service:
        name: sshd
        state: restarted

Step 5: File Integrity Monitoring (FIM)

Compliance requires knowing when a file changed. Tools like Wazuh or OSSEC are standard here. They monitor key system files and alert on modifications.

Below is a configuration snippet for the Wazuh agent (ossec.conf) to monitor critical directories for realtime changes. This is crucial for detecting web shell injections.

  
  43200
  
  
  /etc
  /usr/bin
  /usr/sbin
  
  
  /etc/mtab
  /etc/hosts.deny
  /etc/mail/statistics

Note on Performance: Real-time FIM consumes CPU cycles. On over-provisioned budget hosts, this agent will get throttled, causing missed alerts. We recommend dedicated CPU cores or high-performance KVM slices (like our Performance tiers) for active FIM deployments.

Comparison: The Cost of Compliance

Why automate? Let's look at the numbers for maintaining a 50-node fleet in 2025.

The CoolVDS Advantage: Infrastructure Transparency

You can have the most secure OS config in the world, but if the hypervisor is leaky or the datacenter lacks physical security, you fail the audit. We built CoolVDS to be the invisible foundation of your compliance stack.

• ISO 27001 Certified Datacenters: Our facilities in Oslo meet the physical security requirements for banking and healthcare workloads.
• No Noisy Neighbors: Strict KVM isolation means a compromised neighbor cannot read your memory pages—a known vulnerability in older container-based setups.
• Managed Hosting Options: For teams that don't want to write Ansible playbooks, our managed support team can implement these hardening baselines for you.

Final Thoughts

In 2025, security is not a feature; it is a legal requirement. The combination of strict Norwegian privacy laws and the technical rigor of the NIS2 directive means you cannot afford "best effort" security.

Automate your baseline. Audit with OpenSCAP. And run it on hardware that respects your data sovereignty. Don't let slow I/O or shaky jurisdiction kill your business.

Ready to harden your infrastructure? Deploy a fully compliant, NVMe-powered instance on CoolVDS in under 55 seconds and keep your data safe in Norway.