Dine data, sikret i hjertet af Europa

We maintain a written incident response plan that defines severity levels, assigns roles for detection and response, and sets out containment, eradication and recovery steps. It includes communication paths for notifying customers, authorities and CSIRTs.

Production systems are monitored continuously rather than on a schedule. Alerting is automated, and runtime security policies detect unexpected behaviour on running workloads as well as at the network edge.

Application access, authentication events, privileged activity, and changes to critical configuration and backup files are logged centrally. Archives are written to immutable, encrypted storage with a defined retention period so that records cannot be altered after the fact.

Availability is checked from outside our own infrastructure, by a monitoring system we run at a separate provider. If our primary environment fails, the system that notices is not part of it.

Suspicious events are assessed against criteria defined in advance to determine whether they are incidents and how severe they are. Logs are correlated as part of that assessment, and events are reclassified when new information emerges.

Anyone can report a suspected security issue to security@invoro.lu. Reports reach the person responsible for incident response directly.

After recovery we review what happened, identify the root cause, and feed the result back into our security measures rather than closing the incident and moving on.

Access to production systems and internal tooling goes through a single identity provider that we operate ourselves, with multi-factor authentication required.

Permissions are granted by role on a least-privilege basis, both for our own staff and for users within a customer account. Access is only granted to users who have been authenticated.

Every identity belongs to one named individual. Shared accounts are used only where there is no technical alternative, and identity lifecycle changes are logged.

System administration is performed with accounts dedicated to that purpose and separate credentials. Administrative privileges are individualised and kept as narrow as the task allows.

Application API access uses DPoP (RFC 9449), which binds a token to the client that requested it. A stolen token cannot be replayed from somewhere else.

We keep a register of granted access rights, changes to them are authorised and logged, and access is modified or removed when someone changes role or leaves.

Administration systems are reachable only over a controlled network path, are separated from application workloads, and require authentication and encryption in their own right.

All connections to our services use TLS. Documents exchanged over the Peppol network use AS4 with signed and encrypted payloads.

Databases, persistent volumes and backup archives are encrypted at rest. Selected sensitive fields are additionally encrypted at application level, so they stay protected even with database access.

Credentials and keys are held in a dedicated secret management system with audited access and injected into workloads at runtime. Secrets are never stored in source code or container images.

Database logins are issued dynamically with a limited lifetime rather than being long-lived shared passwords, so a leaked credential expires on its own.

Key generation, distribution, storage, rotation, revocation and handling of compromised keys follow a defined approach, and key management activity is logged.

Our infrastructure is described in version-controlled configuration and deployed from it. What is running is therefore inventoried by construction, and every change has an author, a review and a history.

Assets are classified so that the strength of the protection applied to them, including cryptographic protection and authentication requirements, matches their sensitivity. Classifications are reviewed periodically.

Every container image is scanned for known vulnerabilities as part of the build. Critical findings stop the release rather than being recorded and shipped.

We keep a register of the third-party providers we rely on, recording what each one does, how critical it is, and what data it can reach. The providers that process data for our customers are published on this page.