The EU's NIS2 Directive (Directive 2022/2555) entered into force in January 2023, with member states required to transpose it into national law by October 2024. If you run a SaaS platform or fintech company serving EU customers, this directive probably applies to you — and the compliance requirements go deeper into your infrastructure stack than most teams realise.
NIS2 is not another GDPR. It is a cybersecurity regulation, not a data protection regulation, and it targets the operational resilience of your systems rather than the privacy of personal data. But here is the part that catches people off guard: NIS2 and GDPR overlap significantly at the infrastructure layer. The encryption, access controls, monitoring, and incident response capabilities you built for GDPR compliance form the foundation — but NIS2 adds new requirements around supply chain security, management accountability, and incident reporting timelines that your existing compliance posture almost certainly does not cover.
This guide covers what NIS2 requires at the infrastructure level for SaaS and fintech companies, where it diverges from GDPR, and how the choice of hosting jurisdiction and infrastructure provider directly affects your ability to comply. We will be specific about configurations, architectural decisions, and the operational processes that turn "we have a policy" into "we can demonstrate compliance under audit."
Who NIS2 Actually Applies To — And Why SaaS and Fintech Companies Cannot Ignore It
NIS2 dramatically expanded the scope of EU cybersecurity obligations compared to the original NIS Directive. The old directive covered a narrow set of "operators of essential services" — mostly energy, transport, banking, and healthcare. NIS2 introduces two categories: essential entities and important entities, and the classification criteria sweep in far more organisations than most people expect.
Under Annex I and Annex II of the directive, the following sectors are in scope:
• Digital infrastructure: Cloud computing providers, data centre operators, CDN providers, DNS service providers, trust service providers
• ICT service management (B2B): Managed service providers and managed security service providers
• Banking and financial market infrastructures: Credit institutions, trading venues, central counterparties
• Digital providers: Online marketplaces, search engines, social networking platforms
If you are a SaaS company providing cloud-based services to EU customers, you likely fall under "digital infrastructure" or "ICT service management." If you are a fintech company, you are almost certainly covered under "banking and financial market infrastructures" — and possibly double-covered if you also provide technology services to other financial institutions.
The size thresholds are relatively low. Medium-sized enterprises (50+ employees or EUR 10 million+ annual turnover) in covered sectors are automatically in scope. Some entities are in scope regardless of size — including trust service providers, DNS service providers, and TLD name registries.
The penalties are meaningful: up to EUR 10 million or 2% of total worldwide annual turnover for essential entities, and EUR 7 million or 1.4% for important entities. But the penalty that should concern technical leadership more than fines is Article 32's management liability provision — NIS2 allows member states to hold management bodies personally liable for compliance failures. This is not theoretical. Board members and C-suite executives can be temporarily prohibited from exercising managerial functions if the entity fails to comply.
The Ten Risk Management Measures: Article 21 Broken Down
Article 21 of NIS2 specifies ten categories of cybersecurity risk management measures that in-scope entities must implement. These are not optional recommendations — they are legal requirements, and each one has infrastructure implications:
1. Risk analysis and information system security policies
This goes beyond having a security policy document on your intranet. NIS2 requires that your risk analysis covers the specific information systems that support your essential or important services. At the infrastructure level, this means maintaining an accurate, up-to-date inventory of every server, network device, storage system, and third-party service that processes data for EU customers — and assessing the risk profile of each component.
# Infrastructure inventory automation example
# Generate server inventory with security-relevant metadata
#!/bin/bash
HOSTNAME=$(hostname -f)
KERNEL=$(uname -r)
OS=$(cat /etc/os-release | grep PRETTY_NAME | cut -d'"' -f2)
OPEN_PORTS=$(ss -tlnp | grep LISTEN | awk '{print $4}' | sort)
DISK_ENCRYPTION=$(lsblk -o NAME,TYPE,FSTYPE | grep -c crypt)
SSH_CONFIG=$(sshd -T 2>/dev/null | grep -E "passwordauthentication|permitrootlogin|pubkeyauthentication")
LAST_UPDATE=$(stat -c %Y /var/cache/apt/pkgcache.bin 2>/dev/null || echo "unknown")
FIREWALL_STATUS=$(ufw status 2>/dev/null || iptables -L -n 2>/dev/null | head -5)
echo "=== NIS2 Infrastructure Inventory: ${HOSTNAME} ==="
echo "OS: ${OS}"
echo "Kernel: ${KERNEL}"
echo "Encrypted volumes: ${DISK_ENCRYPTION}"
echo "Open ports: ${OPEN_PORTS}"
echo "SSH config: ${SSH_CONFIG}"
echo "Last package update: $(date -d @${LAST_UPDATE} 2>/dev/null || echo ${LAST_UPDATE})"
echo "Firewall: ${FIREWALL_STATUS}"Run this across every server in your fleet on a scheduled basis. The output feeds your risk register and provides evidence for auditors that you maintain current awareness of your attack surface.
2. Incident handling
NIS2's incident reporting requirements are more demanding than GDPR's. Under Article 23, you must submit an early warning within 24 hours of becoming aware of a significant incident, a full incident notification within 72 hours, and a final report within one month. Compare this to GDPR's single 72-hour notification requirement — NIS2 adds an earlier trigger and a longer tail.
A "significant incident" under NIS2 is defined as one that has caused or is capable of causing severe operational disruption or financial loss, or has affected or is capable of affecting other natural or legal persons by causing considerable material or non-material damage. For a SaaS platform, a multi-tenant breach or extended outage affecting EU customers would qualify.
The 24-hour early warning clock means your detection-to-notification pipeline must be extremely fast. You cannot rely on next-business-day log review. This requires:
# Real-time alerting for NIS2-significant incidents
# Example: Prometheus alerting rules for critical infrastructure events
groups:
- name: nis2_critical_alerts
rules:
- alert: UnauthorizedAccessAttempt
expr: rate(auth_failures_total{severity="critical"}[5m]) > 10
for: 2m
labels:
severity: nis2_reportable
team: security
annotations:
summary: "Potential brute-force or credential stuffing attack"
description: "{{ $value }} auth failures/sec on {{ $labels.instance }}"
nis2_action: "Assess within 1 hour. If confirmed breach, trigger 24h early warning."
- alert: DataExfiltrationPattern
expr: rate(network_transmit_bytes_total{direction="egress"}[10m]) > 100000000
for: 5m
labels:
severity: nis2_reportable
team: security
annotations:
summary: "Anomalous egress traffic detected"
description: "{{ $value }} bytes/sec egress on {{ $labels.instance }}"
nis2_action: "Investigate immediately. Potential data exfiltration."
- alert: ServiceAvailabilityBreach
expr: up{job=~".*production.*"} == 0
for: 5m
labels:
severity: nis2_reportable
team: sre
annotations:
summary: "Production service down — potential NIS2 significant incident"
nis2_action: "Assess impact scope. If EU customers affected, prepare early warning."Your incident response runbook must include a NIS2-specific decision tree: Is this incident significant under Article 23? Which national CSIRT do we report to? Who in management is authorised to submit the early warning? These decisions cannot happen during the incident — they must be pre-documented and rehearsed.
3. Business continuity and crisis management
NIS2 requires backup management, disaster recovery, and crisis management capabilities. This is more prescriptive than GDPR's availability requirement (Article 32(1)(c)). Your infrastructure must demonstrate:
• Automated backups with tested restoration procedures — "tested" means you have evidence of a successful restore within the last quarter, not just a backup job that runs nightly
• Defined Recovery Time Objectives (RTO) and Recovery Point Objectives (RPO) that are aligned with the criticality of the service
• A crisis management plan that covers communication with national authorities, customers, and the public during a major incident
• Redundancy at the infrastructure layer — not just application-level failover, but hardware redundancy, network path diversity, and geographic separation of critical components
# Automated backup verification script
#!/bin/bash
# Weekly backup restoration test — evidence for NIS2 audit
BACKUP_DATE=$(date -d "yesterday" +%Y%m%d)
RESTORE_DB="nis2_restore_test_$(date +%s)"
LOG="/var/log/backup-verification/test_${BACKUP_DATE}.log"
echo "=== NIS2 Backup Verification Test ===" | tee "${LOG}"
echo "Date: $(date -Iseconds)" | tee -a "${LOG}"
echo "Backup under test: ${BACKUP_DATE}" | tee -a "${LOG}"
# Restore to a temporary database
pg_restore -h localhost -U backup_svc \
-d "${RESTORE_DB}" \
--create \
"/backups/production_${BACKUP_DATE}.dump" 2>&1 | tee -a "${LOG}"
RESTORE_EXIT=$?
# Verify record counts match production (within tolerance)
PROD_COUNT=$(psql -h localhost -U backup_svc -d production -t -c "SELECT count(*) FROM customers;")
TEST_COUNT=$(psql -h localhost -U backup_svc -d "${RESTORE_DB}" -t -c "SELECT count(*) FROM customers;")
echo "Production records: ${PROD_COUNT}" | tee -a "${LOG}"
echo "Restored records: ${TEST_COUNT}" | tee -a "${LOG}"
if [ ${RESTORE_EXIT} -eq 0 ] && [ "${PROD_COUNT}" -eq "${TEST_COUNT}" ]; then
echo "RESULT: PASS — Backup verified successfully" | tee -a "${LOG}"
else
echo "RESULT: FAIL — Backup restoration failed or data mismatch" | tee -a "${LOG}"
# Alert the team
curl -X POST "${ALERTING_WEBHOOK}" \
-H "Content-Type: application/json" \
-d "{\"text\": \"NIS2 backup verification FAILED for ${BACKUP_DATE}\"}"
fi
# Clean up test database
dropdb -h localhost -U backup_svc "${RESTORE_DB}"Keep these test logs. An auditor assessing your NIS2 compliance will ask for evidence of backup testing, and "we run backups every night" without restoration verification evidence is insufficient.
4. Supply chain security
This is the requirement that catches most SaaS teams off guard. Article 21(2)(d) requires entities to address "supply chain security, including security-related aspects concerning the relationships between each entity and its direct suppliers or service providers." Your hosting provider is a direct supplier. Your CDN is a direct supplier. Your DNS provider, your certificate authority, your monitoring SaaS, your CI/CD platform — all direct suppliers whose security posture affects your NIS2 compliance.
At the infrastructure level, supply chain security means:
• Vendor security assessment: You must evaluate the cybersecurity practices of your infrastructure providers. This is not a checkbox exercise — NIS2 expects you to consider "the overall quality of products and cybersecurity practices of suppliers and service providers, including their secure development procedures" (Article 21(3)).
• Contractual security requirements: Your contracts with infrastructure providers must include specific cybersecurity obligations — not just a generic DPA, but explicit commitments about patching timelines, access controls, incident notification, and audit rights.
• Software supply chain integrity: Every package, library, and container image in your stack is part of your supply chain. NIS2's supply chain requirements align with the broader push toward Software Bills of Materials (SBOMs) and verified build pipelines.
# Generate SBOM for container images — supply chain documentation
# Using syft (open-source SBOM tool)
# Generate SBOM for your production image
syft packages registry.internal/app:production -o spdx-json > sbom-app-production.json
# Scan SBOM for known vulnerabilities
grype sbom:sbom-app-production.json --output json > vulnerability-report.json
# Check for critical/high vulnerabilities
CRITICAL=$(cat vulnerability-report.json | jq '[.matches[] | select(.vulnerability.severity=="Critical")] | length')
HIGH=$(cat vulnerability-report.json | jq '[.matches[] | select(.vulnerability.severity=="High")] | length')
echo "Critical vulnerabilities: ${CRITICAL}"
echo "High vulnerabilities: ${HIGH}"
if [ "${CRITICAL}" -gt 0 ]; then
echo "BLOCKING: Critical vulnerabilities must be remediated before deployment"
exit 1
fiThis is where your choice of hosting provider becomes a supply chain decision. A provider operating under managed Swiss infrastructure with documented security practices, transparent sub-processor lists, and contractual commitments to patch management and incident notification gives you a supply chain link you can defend under audit. A provider that just hands you a VM and a best-effort SLA gives you a supply chain risk you have to manage entirely yourself.
5. Security in network and information systems acquisition, development, and maintenance
This covers vulnerability handling and disclosure. Your infrastructure must support a vulnerability management lifecycle: discovery, assessment, prioritisation, remediation, and verification. At the server level:
# Automated vulnerability scanning and patching pipeline
#!/bin/bash
# Weekly vulnerability assessment — NIS2 Article 21(2)(e)
LOG="/var/log/vulnerability-scan/scan_$(date +%Y%m%d).log"
echo "=== NIS2 Vulnerability Assessment ===" | tee "${LOG}"
echo "Date: $(date -Iseconds)" | tee -a "${LOG}"
echo "Host: $(hostname -f)" | tee -a "${LOG}"
# Check for available security updates
echo "--- Available Security Updates ---" | tee -a "${LOG}"
apt-get update -qq 2>&1 | tee -a "${LOG}"
apt-get -s upgrade 2>&1 | grep -i security | tee -a "${LOG}"
# Count pending security patches
PENDING=$(apt-get -s upgrade 2>&1 | grep -c "^Inst.*security")
echo "Pending security patches: ${PENDING}" | tee -a "${LOG}"
# Check kernel version against known CVEs
KERNEL_VERSION=$(uname -r)
echo "Current kernel: ${KERNEL_VERSION}" | tee -a "${LOG}"
# Check SSL/TLS library version
OPENSSL_VERSION=$(openssl version)
echo "OpenSSL: ${OPENSSL_VERSION}" | tee -a "${LOG}"
# Check for listening services on unexpected ports
echo "--- Unexpected Listening Services ---" | tee -a "${LOG}"
ss -tlnp | grep -v -E ":(22|80|443|5432|6379) " | tee -a "${LOG}"
# Log completion
echo "Scan completed: $(date -Iseconds)" | tee -a "${LOG}"
if [ "${PENDING}" -gt 0 ]; then
echo "ACTION REQUIRED: ${PENDING} security patches pending" | tee -a "${LOG}"
fi6. Policies and procedures to assess the effectiveness of cybersecurity risk management measures
This is the "test your controls" requirement. You must regularly assess whether your security measures are working — not just that they are configured, but that they are effective. Penetration testing, red team exercises, and automated security scanning are all relevant here. The key is documentation: every test must produce a report, and every finding must have a remediation timeline and verification of closure.
7. Basic cyber hygiene practices and cybersecurity training
At the infrastructure level, "basic cyber hygiene" means the fundamentals are in place and enforced technically, not just documented in a policy:
• Automatic security updates enabled or applied within a defined SLA
• Default passwords eliminated across all systems
• MFA enforced on all administrative access
• Unused services and ports disabled
• Network segmentation between production, staging, and management environments
8. Policies and procedures regarding the use of cryptography and encryption
NIS2 explicitly requires cryptography policies. This aligns with GDPR Article 32's encryption requirement but adds the expectation of a documented policy that covers key management, algorithm selection, key rotation schedules, and procedures for compromised keys. If you already built GDPR-compliant encryption infrastructure, the NIS2 gap is primarily in documentation and key lifecycle management.
9. Human resources security, access control policies, and asset management
Onboarding and offboarding procedures must be technically enforced. When someone joins, they get the minimum access required. When they leave, every access point is revoked — SSH keys, VPN certificates, database credentials, monitoring system access, CI/CD pipeline permissions. An automated offboarding checklist is not enough. You need technical verification that revocation was effective:
# Offboarding verification script
#!/bin/bash
# Verify all access has been revoked for departed personnel
USERNAME=$1
echo "=== Access Revocation Verification: ${USERNAME} ==="
# Check SSH authorized_keys across all servers
for SERVER in $(cat /etc/ansible/hosts | grep -v "^#" | grep -v "^\["); do
KEYS=$(ssh root@${SERVER} "grep -l '${USERNAME}' /home/*/.ssh/authorized_keys 2>/dev/null" || true)
if [ -n "${KEYS}" ]; then
echo "FAIL: SSH key still present on ${SERVER}: ${KEYS}"
else
echo "OK: No SSH keys on ${SERVER}"
fi
done
# Check database users
DB_USER=$(psql -h localhost -U admin -t -c "SELECT usename FROM pg_user WHERE usename LIKE '%${USERNAME}%';")
if [ -n "${DB_USER}" ]; then
echo "FAIL: Database user still exists: ${DB_USER}"
else
echo "OK: No database user found"
fi
# Check VPN certificates
VPN_CERT=$(ls /etc/openvpn/easy-rsa/pki/issued/ | grep -i "${USERNAME}" || true)
if [ -n "${VPN_CERT}" ]; then
echo "FAIL: VPN certificate still issued: ${VPN_CERT}"
else
echo "OK: No VPN certificate found"
fi
echo "=== Verification Complete ==="10. Use of multi-factor authentication, secured communication, and secured emergency communication
NIS2 explicitly mandates MFA where appropriate. For infrastructure access, "where appropriate" means everywhere — SSH, VPN, database administration tools, monitoring dashboards, CI/CD pipelines. The "secured emergency communication" requirement is new: you need a communication channel for incident response that does not depend on the same infrastructure that might be compromised. If your incident response coordination happens over Slack and your Slack integration runs on the same servers that got breached, you have a problem.
NIS2 vs. GDPR: Where They Overlap and Where They Diverge
Understanding the relationship between NIS2 and GDPR is critical for infrastructure architecture because building two separate compliance programmes is wasteful and error-prone. Here is where they align and where they create distinct requirements:
Overlapping requirements (build once, satisfy both):
• Encryption at rest and in transit — GDPR Article 32(1)(a) and NIS2 Article 21(2)(h)
• Access controls and authentication — GDPR Articles 29/32 and NIS2 Article 21(2)(i/j)
• Incident detection and monitoring — GDPR Article 33 and NIS2 Article 23
• Business continuity and backup management — GDPR Article 32(1)(b/c) and NIS2 Article 21(2)(c)
• Risk assessment — GDPR Article 35 (DPIA) and NIS2 Article 21(1)
NIS2-specific requirements (additional infrastructure work):
• 24-hour early warning: NIS2 requires initial notification within 24 hours, versus GDPR's 72 hours. Your detection and escalation pipeline must be faster.
• Supply chain security: GDPR addresses sub-processors via DPAs, but NIS2 requires active assessment of supplier cybersecurity practices. You must evaluate your hosting provider's security, not just sign their DPA.
• Management accountability: NIS2 Article 32 holds management personally liable. GDPR fines the organisation; NIS2 can disqualify individuals.
• Vulnerability handling: NIS2 requires a documented vulnerability management process. GDPR implies security patching under "appropriate measures" but does not mandate a specific process.
• Regular testing: NIS2 explicitly requires assessing the effectiveness of security measures. GDPR's "regular testing and evaluating" in Article 32(1)(d) is similar but typically interpreted less prescriptively.
Different reporting authorities: GDPR breaches go to Data Protection Authorities. NIS2 incidents go to national CSIRTs or competent authorities. A single incident — for example, a breach that exposes personal data and disrupts a critical service — may require reporting to both, with different timelines, different content requirements, and different follow-up obligations.
The Jurisdiction Question: Why Your Hosting Location Matters More Under NIS2
NIS2 introduces jurisdiction considerations that go beyond GDPR's data residency requirements. Under Article 26, the directive establishes jurisdiction rules for digital infrastructure providers and ICT service providers based on where they have their "main establishment" in the EU — or, for providers without an EU establishment, based on where they provide services.
For SaaS and fintech companies, this creates a practical infrastructure question: which member state's national transposition of NIS2 applies to your infrastructure? NIS2 is a directive, not a regulation — member states must transpose it into national law, and the implementation details vary. Germany's BSI-Gesetz implementation differs from France's ANSSI-administered rules, which differ from the Netherlands' approach.
Switzerland is not an EU member state, so NIS2 does not directly apply to infrastructure hosted in Switzerland. However, Swiss companies that provide services to EU entities or process data for EU-regulated customers face the directive's reach through two mechanisms:
• Contractual flow-down: Your EU-based customers who are NIS2-obligated entities will require their supply chain (including hosting providers) to meet NIS2's supply chain security requirements under Article 21(2)(d). Even though NIS2 does not directly regulate a Swiss hosting provider, the practical effect is that the provider must demonstrate compliance with the cybersecurity standards that NIS2 requires of supply chain participants.
• FADP alignment: Switzerland's revised Federal Act on Data Protection already aligns with GDPR, and Swiss cybersecurity standards (particularly for FINMA-regulated financial infrastructure) exceed NIS2's baseline in several areas. A Swiss dedicated server operating under FADP with FINMA-grade security controls often satisfies NIS2 supply chain requirements without additional modification.
The jurisdictional advantage of Swiss hosting under NIS2 is nuanced: Switzerland's position outside the EU means your infrastructure is not subject to the directive's direct obligations (and the associated supervisory authority oversight), while the Swiss legal framework — FADP, FINMA regulations, and the Swiss adequacy decision under GDPR — provides a compliance foundation that EU customers and their auditors recognise.
For fintech companies specifically, this dual positioning is powerful. FINMA's operational resilience requirements (particularly FINMA Circular 2023/1 on operational risks and resilience) address many of the same concerns as NIS2 — business continuity, ICT risk management, incident handling, and third-party risk. Infrastructure that satisfies FINMA also satisfies the substantive requirements that NIS2 imposes through supply chain obligations.
Building NIS2-Compliant Infrastructure: Practical Architecture
Here is the infrastructure architecture that satisfies both GDPR and NIS2 requirements, built on the assumption that you are running on dedicated or managed Swiss infrastructure:
Layer 1: Network perimeter and segmentation
# Production network segmentation for NIS2 compliance
# Separate VLANs for each functional zone
# Application tier — internet-facing
# VLAN 10: 10.10.0.0/24
iptables -A FORWARD -i vlan10 -o vlan20 -p tcp --dport 5432 -j ACCEPT
iptables -A FORWARD -i vlan10 -o vlan20 -j DROP
# Database tier — no direct internet access
# VLAN 20: 10.20.0.0/24
iptables -A INPUT -i vlan20 -p tcp --dport 5432 -s 10.10.0.0/24 -j ACCEPT
iptables -A INPUT -i vlan20 -p tcp --dport 5432 -j DROP
# Management tier — restricted access, MFA-gated VPN only
# VLAN 30: 10.30.0.0/24
iptables -A INPUT -i vlan30 -p tcp --dport 22 -s 10.30.0.1 -j ACCEPT # VPN gateway only
iptables -A INPUT -i vlan30 -p tcp --dport 22 -j DROP
# Monitoring tier — receives data, does not initiate connections to production
# VLAN 40: 10.40.0.0/24
iptables -A INPUT -i vlan40 -p tcp --dport 9090 -s 10.10.0.0/24 -j ACCEPT # Prometheus scrape
iptables -A INPUT -i vlan40 -p tcp --dport 9090 -s 10.20.0.0/24 -j ACCEPT
iptables -A FORWARD -i vlan40 -o vlan10 -j DROP # Monitoring cannot reach app tier
iptables -A FORWARD -i vlan40 -o vlan20 -j DROP # Monitoring cannot reach DB tierThe monitoring tier isolation is important for NIS2. If your monitoring system is compromised, it should not provide a lateral movement path into production infrastructure. This is a subtlety that GDPR audits rarely check but NIS2 assessments will examine.
Layer 2: Identity and access management
# SSH configuration hardened for NIS2 compliance
# /etc/ssh/sshd_config
# Authentication
PasswordAuthentication no
PubkeyAuthentication yes
PermitRootLogin no
AuthenticationMethods publickey,keyboard-interactive # MFA: key + TOTP
MaxAuthTries 3
LoginGraceTime 30
AllowUsers deploy_svc audit_svc oncall_svc
# Session security
ClientAliveInterval 300
ClientAliveCountMax 2
MaxSessions 3
# Logging (feeds NIS2 audit trail)
LogLevel VERBOSE
SyslogFacility AUTH
# Cryptography (NIS2 Article 21(2)(h))
KexAlgorithms curve25519-sha256,curve25519-sha256@libssh.org
Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com
MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com
HostKeyAlgorithms ssh-ed25519,rsa-sha2-512Note the AuthenticationMethods publickey,keyboard-interactive line — this enforces MFA by requiring both an SSH key and a second factor (typically TOTP via PAM). NIS2 Article 21(2)(j) explicitly mandates multi-factor authentication. An SSH key alone, while strong, does not satisfy the "multi-factor" requirement because it is a single factor (something you have).
Layer 3: Continuous monitoring and anomaly detection
NIS2's incident handling requirements demand that you can detect anomalies in near-real-time. This means going beyond availability monitoring to behavioural analysis:
# auditd rules for NIS2 behavioural monitoring
# /etc/audit/rules.d/nis2-monitoring.rules
# Monitor all privilege escalation
-a always,exit -F arch=b64 -S setuid -S setgid -k privilege_escalation
-a always,exit -F arch=b64 -S execve -F euid=0 -F auid!=0 -k root_command
# Monitor network configuration changes
-w /etc/network/ -p wa -k network_config
-w /etc/iptables/ -p wa -k firewall_config
-w /etc/nftables.conf -p wa -k firewall_config
# Monitor user/group changes
-w /etc/passwd -p wa -k identity_change
-w /etc/group -p wa -k identity_change
-w /etc/shadow -p wa -k identity_change
-w /etc/sudoers -p wa -k privilege_change
-w /etc/sudoers.d/ -p wa -k privilege_change
# Monitor SSH configuration
-w /etc/ssh/sshd_config -p wa -k ssh_config
# Monitor cron job changes (persistence mechanism)
-w /etc/crontab -p wa -k cron_change
-w /var/spool/cron/ -p wa -k cron_change
-w /etc/cron.d/ -p wa -k cron_change
# Monitor kernel module loading (rootkit detection)
-a always,exit -F arch=b64 -S init_module -S finit_module -k kernel_module
-a always,exit -F arch=b64 -S delete_module -k kernel_module
# Monitor data directories
-w /var/data/ -p rwxa -k data_access
-w /var/lib/postgresql/ -p wa -k database_filesShip these audit logs to your SIEM (or a managed log aggregation service) with alerting rules that trigger on suspicious patterns. The NIS2 requirement is not just that you collect logs — it is that you actively monitor them and can detect incidents fast enough to meet the 24-hour early warning deadline.
Layer 4: Automated compliance evidence collection
NIS2 compliance is not a point-in-time certification — it is an ongoing obligation. Your infrastructure should continuously generate compliance evidence that you can present to supervisory authorities on request:
# Monthly NIS2 compliance evidence generation
#!/bin/bash
MONTH=$(date +%Y-%m)
REPORT_DIR="/var/compliance/nis2/${MONTH}"
mkdir -p "${REPORT_DIR}"
echo "=== NIS2 Compliance Evidence: ${MONTH} ===" > "${REPORT_DIR}/summary.txt"
# Evidence 1: Patch compliance
echo "--- Patch Status ---" >> "${REPORT_DIR}/summary.txt"
apt list --installed 2>/dev/null > "${REPORT_DIR}/installed-packages.txt"
apt-get -s upgrade 2>&1 | grep -i security > "${REPORT_DIR}/pending-security-patches.txt"
PENDING=$(wc -l < "${REPORT_DIR}/pending-security-patches.txt")
echo "Pending security patches: ${PENDING}" >> "${REPORT_DIR}/summary.txt"
# Evidence 2: Access control audit
echo "--- Access Control ---" >> "${REPORT_DIR}/summary.txt"
cat /etc/passwd | grep -v nologin | grep -v false > "${REPORT_DIR}/active-users.txt"
echo "Active users: $(wc -l < "${REPORT_DIR}/active-users.txt")" >> "${REPORT_DIR}/summary.txt"
lastlog | grep -v "Never" > "${REPORT_DIR}/recent-logins.txt"
# Evidence 3: Encryption status
echo "--- Encryption Status ---" >> "${REPORT_DIR}/summary.txt"
lsblk -o NAME,TYPE,FSTYPE,SIZE | grep crypt > "${REPORT_DIR}/encrypted-volumes.txt"
openssl s_client -connect localhost:443 2>/dev/null | grep -E "Protocol|Cipher" > "${REPORT_DIR}/tls-config.txt"
# Evidence 4: Firewall rules
echo "--- Firewall Configuration ---" >> "${REPORT_DIR}/summary.txt"
iptables -L -n --line-numbers > "${REPORT_DIR}/firewall-rules.txt"
# Evidence 5: Backup verification logs
echo "--- Backup Verification ---" >> "${REPORT_DIR}/summary.txt"
ls -la /var/log/backup-verification/ | tail -5 >> "${REPORT_DIR}/summary.txt"
# Evidence 6: Incident log summary
echo "--- Incident Summary ---" >> "${REPORT_DIR}/summary.txt"
grep -c "severity=nis2_reportable" /var/log/alertmanager/*.log 2>/dev/null >> "${REPORT_DIR}/summary.txt" || echo "No reportable incidents" >> "${REPORT_DIR}/summary.txt"
# Archive and encrypt the evidence package
tar czf "${REPORT_DIR}.tar.gz" -C "/var/compliance/nis2" "${MONTH}"
gpg --encrypt --recipient compliance@company.com "${REPORT_DIR}.tar.gz"
echo "NIS2 evidence package generated: ${REPORT_DIR}.tar.gz.gpg"Supply Chain Security in Practice: Evaluating Your Hosting Provider
Article 21(2)(d) of NIS2 makes supply chain security a direct compliance obligation. For most SaaS and fintech companies, the hosting provider is the most critical supply chain link because it underpins every other technical control. Here is a practical framework for evaluating whether your infrastructure provider supports or undermines your NIS2 compliance:
Questions to ask your hosting provider:
• Patch management SLA: What is the maximum time between a critical vulnerability disclosure and patch application on shared infrastructure components (hypervisors, network equipment, storage controllers)? An acceptable answer is hours for critical, days for high. "We follow vendor recommendations" is not an answer.
• Incident notification timeline: How quickly will they notify you of a security incident affecting your infrastructure? NIS2 requires you to submit an early warning within 24 hours — if your provider takes 48 hours to tell you about an incident, you are already non-compliant.
• Physical security and access logging: Who has physical access to the servers? Is physical access logged and auditable? Can they provide evidence of access control effectiveness?
• Sub-contractor transparency: Does the provider use sub-contractors for hardware maintenance, network operations, or data centre management? Each one is part of your supply chain under NIS2.
• Jurisdiction of control plane: Even if the servers are in Switzerland, where does the management infrastructure live? If the provider's control panel, ticketing system, or monitoring runs on AWS us-east-1, your management access may traverse jurisdictions you did not intend.
• Audit rights: Can you audit the provider's security practices, or are you limited to reviewing certifications? NIS2's supply chain requirements imply the ability to verify, not just trust.
A Swiss VPS or dedicated server provider that can answer these questions with specific, verifiable commitments gives you a defensible supply chain position. A provider that responds with vague assurances or points to a generic ISO 27001 certificate is a supply chain risk that your NIS2 compliance programme must account for.
The FADP Advantage: How Swiss Law Complements NIS2 Compliance
Switzerland's revised Federal Act on Data Protection (FADP), effective since September 2023, creates a legal environment that naturally complements NIS2 compliance for hosting infrastructure. While the FADP is a data protection law (not a cybersecurity directive), its requirements for technical and organisational measures overlap significantly with NIS2's risk management measures.
Key FADP provisions that support NIS2 compliance:
• Article 8 FADP (Data security): Requires controllers and processors to ensure data security through appropriate technical and organisational measures. The "appropriate measures" standard considers the purpose, nature, scope and circumstances of processing, the risks to data subjects, and the state of the art. This aligns with NIS2 Article 21(1)'s "appropriate and proportionate" measures standard.
• Article 24 FADP (Breach notification): Requires notification to the FDPIC "as soon as possible" for breaches that pose a high risk. While less prescriptive than NIS2's 24/72-hour timelines, it establishes a notification culture and infrastructure requirement that supports faster reporting.
• Article 9 FADP (Processing by a processor): Requires contractual guarantees of data security from processors. This aligns with NIS2's supply chain security requirements — a hosting provider operating under FADP already has legal obligations to maintain security standards.
For fintech companies, the FINMA regulatory overlay adds additional cybersecurity requirements that exceed NIS2's baseline. FINMA Circular 2023/1 on operational risks requires financial institutions to maintain ICT risk management frameworks, conduct regular security testing, and ensure operational resilience — all of which parallel NIS2's Article 21 requirements. Infrastructure built to satisfy FINMA will satisfy NIS2 supply chain expectations with minimal additional work.
The practical effect: hosting on managed Swiss infrastructure gives you an infrastructure foundation that is already governed by a privacy-protective legal framework (FADP), recognised by the EU (adequacy decision), and — for financial services — subject to a financial regulator (FINMA) whose cybersecurity expectations match or exceed NIS2. This is not compliance by accident. It is a deliberate jurisdictional strategy that reduces the gap between your infrastructure's existing security posture and NIS2's requirements.
Implementation Roadmap for SaaS and Fintech Teams
If you are starting from a GDPR-compliant infrastructure baseline, here is the incremental work required to achieve NIS2 compliance:
Phase 1: Gap assessment (weeks 1-2)
• Map your current infrastructure against all ten Article 21 measures
• Identify your supply chain: every hosting provider, SaaS dependency, and third-party service
• Determine which member state's NIS2 transposition applies to your entity
• Assess whether you are classified as essential or important (penalties and supervisory regime differ)
Phase 2: Quick wins (weeks 3-4)
• Enforce MFA on all administrative access (if not already done)
• Enable comprehensive audit logging with remote, tamper-evident storage
• Document your incident response procedure with NIS2-specific timelines (24h early warning, 72h notification, 1-month final report)
• Establish a secure emergency communication channel independent of production infrastructure
Phase 3: Infrastructure hardening (weeks 5-8)
• Implement network segmentation with monitoring tier isolation
• Deploy automated vulnerability scanning and patch management
• Set up SBOM generation and supply chain integrity verification for your deployment pipeline
• Conduct a supply chain security assessment of your hosting provider and critical SaaS dependencies
Phase 4: Continuous compliance (ongoing)
• Monthly automated compliance evidence generation
• Quarterly backup restoration testing with documented results
• Annual penetration testing or red team exercise with NIS2-specific scenarios
• Regular management briefings on cybersecurity posture (Article 32 management accountability)
The Honest Assessment
NIS2 adds real compliance work on top of GDPR. There is no way around that. The supply chain security requirements, the 24-hour early warning obligation, and the management accountability provisions are genuinely new obligations that require infrastructure investment, process changes, and ongoing operational attention.
But NIS2 also rewards the work you have already done. If your GDPR compliance is not just paperwork — if you actually built the encryption, access controls, monitoring, and incident response infrastructure that Articles 25 and 32 require — then NIS2 is an incremental step, not a ground-up rebuild. The technical controls overlap significantly. The gap is primarily in supply chain documentation, faster incident reporting, vulnerability management process formalisation, and management accountability structures.
The infrastructure choice matters. A hosting provider that operates under Swiss law (FADP), maintains FINMA-grade security for financial workloads, and can demonstrate its own cybersecurity practices under contractual audit rights gives you a supply chain foundation that satisfies NIS2 Article 21(2)(d) without requiring you to build a vendor assessment programme from scratch. The jurisdiction gives you legal alignment (EU adequacy), the regulatory environment gives you security culture (FINMA/FADP), and the infrastructure gives you the technical controls that both GDPR and NIS2 demand.
That said, no hosting provider eliminates your compliance obligations. Under NIS2, you are responsible for your own risk management, your own incident reporting, and your own management accountability. The provider gives you a platform. The compliance is yours to build, maintain, and demonstrate under audit.