Technical and organisational security measures — MUNUS+ platform
Courtesy translation of the document updated on 30 August 2026. The Italian original is the only binding version; in the event of any discrepancy, the Italian text prevails. This document is not versioned by number: it carries the date of the last check on the systems in operation, which is the same as the Italian one.
W.F.B. Srl — Via Romolo Gessi 13, 20146 Milan (MI), Italy — VAT no. IT04724770237 Contact: privacy@wfbservice.it
This is the technical annex referred to in the privacy notice (§ "How we protect your data"). It describes the measures adopted pursuant to art. 32 GDPR and constitutes, pursuant to arts. 5.2 and 24 GDPR, the documentation by which the controller demonstrates that it has adopted measures appropriate to the risk. It is provided on request to data subjects, clients and authorities, by writing to privacy@wfbservice.it. It is updated whenever the measures change: the date at the end is that of the last check on the systems in operation.
1. How the system is built
MUNUS+ is a web and mobile application with a PostgreSQL database, hosted on dedicated servers of Hetzner Online GmbH (Germany and Finland, European Union). The environments are two, separated on distinct machines: production (real data) and staging (anonymised data). Uploaded documents reside in a private object store, in the same EU region.
The data of each client company is isolated at individual database row level. The isolation is not entrusted to a hand-maintained list: it is derived automatically from the data structure and verified by a check at startup, which prevents the application from starting if the structure changes shape. A system that is down is preferable to a system that serves the wrong data.
2. Access and identity
| Measure | How it is implemented |
|---|---|
| Passwords | minimum requirements imposed by the system (length ≥ 10, uppercase, lowercase, digits, special characters, no consecutive repetition); stored only as a non-reversible cryptographic hash (bcrypt) — not even administrators can read them |
| Second factor | mandatory for all internal staff (administrators and operators): temporary code on an authenticator app, TOTP RFC 6238 standard; available and recommended for other users, with single-use recovery codes stored in encrypted form |
| Access profiling | four distinct roles, plus named permissions and a per-site scope: each user sees only what their role and scope allow |
| Defence against login attempts | double automatic limit: by origin of the request and by individual account (temporary block after a few failed attempts), effective also against attempts distributed across many addresses |
| Revocation | deactivating an account takes effect immediately: validity is re-checked on every single request, not only at login |
| Invitations and password recovery | single-use, expiring links, invalidated on first use with an atomic operation (a link cannot be consumed twice) |
3. Protection of communications
All traffic travels over an encrypted connection (HTTPS/TLS) with automatically renewed certificates. The browser receives security instructions that enforce the use of the encrypted channel (HSTS), limit the origins of executable content (Content Security Policy) and prevent the application from being embedded in third-party pages.
Push notifications travel with encrypted content according to the Web Push standard: the device service that delivers them is not able to read them.
4. Traceability
The system keeps an operations log that records who created or modified a piece of data, when, and — for significant operations — the stated reason. Significant entities are never physically deleted: they are deactivated and remain reconstructable. The log serves data security and correctness and is not used to monitor work performance.
5. Continuity and backups
| Measure | Frequency / term |
|---|---|
| Database copy | daily, with automatic completeness check (a truncated copy is not accepted) |
| Document copy | daily, with temporary retention of removed files to allow their recovery |
| External copy (different provider and country) | daily, encrypted before sending with AES-256: the provider that holds it cannot read its content |
| Rotation | copies expire automatically; the deletion of a piece of data propagates with the natural rotation |
| Restore test | the restore has been actually performed and compared with the original, not merely planned |
6. Monitoring
- Daily health check on both environments: disk space, service status, certificate expiry, age of the last backup, outcome of the automated tasks.
- Automatic check every 10 minutes: if a service is found to be down it is restarted once and an alert is sent.
- Independent external monitoring, outside our infrastructure, which verifies that the sites are reachable and warns if they do not respond.
- Backup sentinels: if a backup is not performed, the silence itself triggers the alert. A tool that says nothing is not saying that everything is fine.
7. Server security
Administrative access exclusively with a cryptographic key (password authentication disabled), direct access by the privileged system user disabled, keys held in a secrets manager and never as plain files. Double firewall (network-level, outside the machine, and system-level) with only three public ports. Automatic protection against repeated remote login attempts (fail2ban), active and verified on both environments. Operating system security updates applied periodically.
8. Suppliers
The suppliers that process data on behalf of the controller are bound by contracts compliant with art. 28 GDPR and process all data within the European Union: Hetzner Online GmbH (Germany), Backblaze Inc. (Netherlands, with data encrypted before sending), Brevo/Sendinblue SAS (France). No data is transferred for marketing, profiling or the training of artificial intelligence systems.
9. Organisational measures
Access to data limited to authorised staff and for the sole purposes of their role; staging environment fed exclusively with anonymised data (names replaced, contact details made undeliverable); legal documents versioned, with a record of who saw which text and when; separation of credentials between environments, so that staging accounts can in no case reach real data.
10. Stated limits, and what happens in the event of a breach
No IT system can be considered 100% secure. The law does not impose an absolute result: it imposes measures appropriate to the risk and the ability to demonstrate them — which is the reason this document exists.
The measures are subject to periodic review. Before the portal is opened to external users, a structured application security assessment (penetration test) is planned, on the staging environments only.
In the event of a personal data breach the controller:
1. contains the incident and reconstructs its extent using the operations log and the system logs; 2. notifies the Italian Data Protection Authority within 72 hours of becoming aware of it, where the breach presents a risk to the rights of the data subjects (art. 33 GDPR); 3. communicates the breach to the data subjects without undue delay, where it entails a high risk to their rights and freedoms (art. 34 GDPR), stating the nature of the breach, the data involved, the likely consequences and the measures adopted; 4. documents every breach — including those not requiring notification — in its own incident register.
Document updated on 30 August 2026. The measures described were verified on the systems in operation as at that date.