Read together with the other Legal Centre documents and the signed order. For relationships governed by Italian law, the Italian version prevails over the bilingual version unless otherwise agreed.
1. Security model
ISOPILOT follows a security-by-design, risk-based model. Actual measures depend on configuration, hosting and Plan. Security is shared: UESE protects the platform and components under its control; the Customer protects devices, networks, users, data, configurations and internal procedures.
2. Identity, authentication and authorisation
Separate roles, hashed passwords, controlled recovery, QR-code TOTP 2FA, protected sessions and user revocation are supported. The Customer must apply least privilege. Administrative and impersonated access is logged.
3. Multi-tenant segregation and storage
Records and files are associated with company_id and project_id, with backend checks preventing cross-tenant access. Attachments are stored in private paths and served only after authorisation. Validation checks name, extension, MIME type, size and hash; anti-malware systems may depend on infrastructure.
4. Encryption and secrets
Public connections must use HTTPS/TLS. API keys, SMTP passwords and secrets are stored server-side and, where implemented, encrypted with the application key. They are not displayed again in plaintext. Secure management of APP_KEY, backups and environment variables is the hosting administrator’s responsibility.
5. Audit logging and monitoring
The platform logs events such as access, creation, changes, approvals, settings, impersonation and material operations. Logs must be protected from improper access and retained proportionately. Infrastructure monitoring and alerts depend on the hosting service used.
6. Backup, recovery and continuity
The strategy should include encrypted or protected backups, rotation, separate copies and restoration tests. Frequency, RPO and RTO are not implied and must be defined in the offer/SLA. The Customer must retain copies of published documents and continuity procedures for critical activities.
7. Development, patching and vulnerabilities
Maintenance includes syntax checks, dependency updates, input validation, error management and configuration review. Before production, hardening, vulnerability assessment and independent penetration testing are recommended. Responsible disclosures may be sent to UESE with technical details and no further exploitation.
8. Incident response
Incidents are classified, contained, analysed and documented. UESE coordinates customer and authority communications according to role and law. The Customer must provide reachable contacts, preserve local logs and cooperate without premature disclosure.
9. Customer obligations
- enable 2FA and unique passwords;
- promptly manage joiners, role changes and leavers;
- limit uploaded data and verify permissions;
- protect endpoints, browsers, networks and email;
- do not share keys or credentials;
- export and retain copies of critical documents;
- report anomalies without delay.
10. Limits and independent assurance
This page describes a control framework and is not a security certification or SLA commitment. Measures must be verified in the production environment. Certifications, audits or independent reports are stated only if actually available.
11. Public trust evidence
The operator may make certifications, credentials and related documents available in the Trust Center. Such evidence supports, but does not replace, the Customer’s assessment of the service, contractual scope and measures applicable to its configuration.
