Security Measures

1. One database per workspace

This is the most important measure, and one that few cloud applications adopt because it costs more: each workspace has its own database, not a “customer” column inside shared tables.

The difference shows on the day something goes wrong. With shared tables, a query that misses the customer filter shows everyone’s data; here no such query exists, because other customers’ data lives in another database. The same goes for backups, which can be restored one workspace at a time without touching anyone else.

2. Encryption

3. Access control

• Sign-in with a personal email address and password; sessions expire and can be ended.
• The session cookie is HttpOnly (cannot be read by scripts), Secure (sent only over encrypted connections) and SameSite=Lax (not sent with requests from other sites).
• Roles and permissions: owner, admin, member and guest. Guests see only the projects they have been invited to.
• API keys and AI-assistant (MCP) keys act with the permissions of the person who created them, and can be read-only.
• Support access uses a temporary user that expires after 15 minutes, with administrator permissions for as long as it lasts; every access is shown to the owner and administrators of the workspace in the admin console (Privacy and compliance) — when, for how long, by whom, why, and the files downloaded — the owner is notified by email when it is opened, and the full data export is blocked while it lasts.
• A workspace’s data can only be reached from within that workspace: there is no screen, not even for us, that shows the work data of several customers together.

4. Infrastructure

• Servers at IONOS SE in Germany, in the European Union.
• The database is not exposed to the internet: it listens only on the server itself.
• Private pages (the application, the admin console, onboarding, APIs) are excluded from search-engine indexing.
• Scheduled jobs run on an internal channel protected by a shared secret: without that secret the endpoint refuses every request instead of staying open.
• Outgoing calls to webhooks and API connectors are allowed only over HTTPS and only to public IP addresses, so the service cannot be used to reach internal networks.
• Operating-system and dependency updates are applied regularly; releases go through a verified build, not manual changes on the server.

5. Backups and restore

• Daily backup of all databases, compressed; the size of each copy is checked when it is made.
• Rotation: 7 daily, 4 weekly and 3 monthly copies. Older copies are deleted automatically.
• Copies are kept on the same European infrastructure, with permissions limited to the system user that produces them.
• Restores are per workspace: one customer can be rolled back without touching the others.
• Restores are carried out by hand. We undertake to test the procedure at least twice a year, on a copy: a backup that has never been restored is not a backup.

6. How the software is written

• User input is validated before it is saved; database queries are parameterised and cannot be manipulated from outside.
• Operations that write data go through server-side actions with role checks: they cannot be reached by calling an address by hand.
• Public form links use unguessable codes that can be revoked: regenerating a code immediately invalidates the previous one.
• Secrets are not in the code but in the server’s environment variables.
• Before every release, automated checks verify that the features work and that configurations are consistent.

7. If something happens

Personal data breaches are notified to the customer within 48 hours of our becoming aware of them, with the information needed to assess notification to the authorities. The procedure is set out in section 6 of the Data Processing Agreement.

If you find a vulnerability, write to amministrazione@outlinedigital.it. We undertake to reply within 5 business days and not to take action against anyone who reports in good faith, without accessing other people’s data, without degrading the service and without disclosing the problem before it is fixed.

8. What we do not do (yet)

A list of measures without its limits is advertising. These are the things that are not in place today, so that you know them before rather than after:

• Two-factor authentication: not available. Use a long password that you do not use elsewhere, and a password manager.
• Encryption of the whole database at rest: not enabled. Passwords and the credentials of connected services are protected; the rest of the data is protected by access control and system isolation, not by encryption.
• Certifications (ISO/IEC 27001, SOC 2): we have none. We do not claim standards we have not been audited against.
• IP address restrictions and a per-user sign-in log visible to the customer: not available.
• Backups of files, and copies kept elsewhere: not in place. The backups cover the databases; they are kept on the same server, protected by file permissions and not encrypted, and no copy is kept at another site. The files you upload — attachments, documents — are stored on the server and are not part of the backups: keep your own copy of the files you could not afford to lose.
• Separate database credentials for each workspace: not in place. Each workspace has its own database, but the application reaches all of them with the same database account.
• Encryption of channel addresses: not in place. The addresses and signing secrets of the channels you connect for notifications (Slack, Microsoft Teams, Discord, Google Chat, Telegram, webhooks) are stored in the workspace database without additional encryption.

When one of these is implemented, it will move to the sections above and the version of this document will go up.

9. Your part

At least half of the security of work software is decided outside the software:

• use strong passwords and do not reuse those of other services;
• create one user per person: shared accounts make it impossible to know who did what;
• grant the minimum permissions needed and remove people immediately when they leave;
• regenerate public links if you suspect they have circulated, and revoke API keys you no longer use;
• keep the devices you sign in from up to date;
• export regularly the data you could not afford to lose.