Privacy Policy

Who we are, and what this page covers

Diwan is a platform for running meetings, tasks and a document archive. It is published by Smart Vision and operates on the domain diwan.im. This policy covers everything that happens on that domain.

Our customer is the organisation, not the individual. When your organisation subscribes to Diwan, it decides who is added, who is removed and what is uploaded; we process that data on its behalf and on its instructions. So if you are a member of an organisation that uses Diwan and you want your data corrected or deleted, your organisation is the first party to ask, and we carry out what it requests.

What we collect

Four kinds of data, and no fifth kind today:

Account data: a member name, email address, role in the organisation, time zone and interface language. Passwords are stored hashed, not encrypted, which means we cannot read them or recover them; the most we can do is reset one.
The content you enter: tasks, comments, spaces and projects; meetings, invitees and attendance records; minutes, decisions and action items; archive files and their versions.
Operational data needed to run the service: notification preferences and quiet hours, notification read state, and usage counters measured against your plan limits.
Security logs: an audit trail of sensitive actions. IP addresses in it are deliberately truncated (the last octet of an IPv4 address and the last eighty bits of an IPv6 address are zeroed) alongside a hashed browser fingerprint, which is enough to investigate an incident and not enough to follow a person.

What we do not collect

We do not ask for card details and do not store them: there is no payment gateway in the platform at all, and subscriptions are handled by talking to us directly.

There are no tracking cookies, no third-party cookies and no advertising analytics. What actually exists is one session cookie without which sign-in cannot work, and a cross-site request forgery token. Your dark-mode preference is kept in your own browser and never reaches us.

We do not sell your data, do not rent it, and do not use it to train AI models, neither ourselves nor through our providers.

Where your data is stored

On a server in Frankfurt, Germany, with the hosting provider Hostinger. We say so plainly, because vagueness on this particular question is what kills an enterprise deal after signature rather than before it.

Your data is therefore not stored inside Saudi Arabia or any Gulf country. For anyone whose regulations require data residency, what we can offer today is a dedicated deployment on a server in the location you require. That is a contractual arrangement we carry out by agreement, not a switch in the interface and not something enabled by a click.

Our backups are kept encrypted; the details are in the security section below.

Why we process it

For four purposes. Any processing beyond them needs a new stated reason:

Running the service itself: showing your meetings, tasks and files to the people entitled to see them.
Telling you things: in-product notifications and transactional email — a task assigned, a mention in a comment, a meeting invitation, minutes distributed, a morning digest. You can turn off whichever of these you want from notification settings.
Security and abuse prevention: the audit trail, request rate limiting, and malware scanning of uploaded files.
Our commitments to you: matching your usage against your plan limits, and warning you before you hit a limit rather than after.

How long we keep your data

As long as your organisation account exists, your data stays. And we will say it plainly: there is no automated job today that erases an organisation data after its subscription ends. Deletion happens when you ask for it, we perform it by hand, and we confirm it to you in writing.

Deleting a file from the archive today hides it rather than erasing it: the file disappears from the interface and can no longer be downloaded, while its bytes remain recoverable by us until an explicit request erases them. We say this because a "delete" that means "hide" is exactly the kind of ambiguity this page exists to prevent.

What is actually pruned automatically today: failed queue job records and their batches after fourteen days.

The full retention schedule — a ninety-day freeze then deletion after a subscription ends, with notices at sixty, thirty and seven days — is written in our internal policy and is not yet implemented as a scheduled job. It appears in the "what we have not built yet" section below.

Who can reach your data inside your organisation

Access is governed by the roles and permissions you configure, and refusal here fails closed: without an explicit right, nothing is shown.

Separation between organisations is not one condition in a query that can be forgotten. It is seven consecutive enforcement layers, the least of which is that a query without an organisation context returns not a single row rather than every row. Automated tests guard those layers and fail the build if one row leaks between two organisations.

Our own access to your data

This is the hardest question we get asked, and it is the clearest thing on this page.

Nobody on our team has standing access to your organisation content. There is no panel a support agent opens to browse your tasks, and no side query. Any viewing requires a support session opened through a gate whose conditions are enforced in code, not in a written policy:

It lasts sixty minutes at most and cannot be extended. Its expiry moment cannot be modified once written, whoever the caller is, so extension is prevented structurally rather than by discipline.
It cannot be opened without a written reason of at least twenty characters and a support ticket reference. Both are shown to you verbatim.
Every owner of the organisation is notified the moment it opens, deliberately outside quiet hours and outside notification mute preferences, because this is a security notice and not a marketing message.
It appears to you in full on the "Support access" screen inside your organisation settings: who viewed, when, why, in which mode, and how much of its time is left. An owner can cut it off at any moment with one button.
You can turn on a setting that requires your approval before every session, so no viewing begins until an owner approves it in person.
Writing to your data always requires owner approval, whether or not you turned that setting on: someone who did not enable the setting consented to us reading their data for support, not to us writing to it.
In read mode every state-changing request is refused at the request level itself, not on one screen or two, and the refusal is logged.
Every page opened inside the session is recorded in the audit trail.
One of our staff can hold only one live session at a time, so sessions cannot be opened on ten organisations in the morning and used all day.

Who processes your data outside our infrastructure

Three parties, no fourth, and this is exactly what reaches each of them:

Party	What reaches them	Why
Brevo	The recipient email address and name, and the message content itself, which may include a meeting title, a task, or minutes you distributed.	Delivering transactional email: invitations, notifications, minutes distribution and the morning digest.
Anthropic	The minutes text that a member of your organisation sends with a button press, and nothing else.	Suggesting the action items contained in that text.
Google	Data for the meeting you create: its title, time and invitees, and only when your organisation connects its own calendar.	Creating the event in your calendar and the video meeting link. This integration is not enabled today, and nothing goes to Google before you connect your calendar yourselves.
Hostinger	Everything the platform stores, by virtue of being the provider of the server it runs on.	Hosting the server in Frankfurt, Germany.

Nothing else leaves our infrastructure to any party: not archive files, not tasks and comments, not the audit trail, not passwords. And no audio leaves, because audio transcription is not built at all.

AI extraction

The minutes screen has a button that extracts action items from the text of the minutes. Exactly what happens when it is pressed: the minutes text that you wrote or uploaded is sent to Anthropic, and a list of suggested items comes back.

This never happens automatically. We do not sweep your minutes or process them in the background: text leaves only on an explicit button press by a member of your organisation, on one specific set of minutes.

No audio leaves. Recording transcription is not built here, so no audio is sent anywhere.

Every item that comes back carries a verbatim quote from your own text that justifies it, and it becomes a task only after a human in your organisation approves it. A suggestion with no matching text in your minutes is dropped before it is ever shown.

What actually protects your data today

Every item under this heading is built, running now, and we can show it to you:

All traffic to the platform runs over HTTPS, with a header that forces the browser never to connect to us unencrypted.
Every file uploaded to the archive is scanned for malware before it is made available. An unscanned file can never be downloaded, not by its owner and not by anyone else, and its bytes never even reach the disk that files are served from. An environment with no scanner configured refuses uploads entirely rather than accepting them and scanning later.
The audit trail is built as a hash chain: each row carries the fingerprint of the row before it, so deleting or altering a row in the middle breaks the chain and becomes visible. This does not prevent deletion, it exposes it, which is what can honestly be guaranteed from inside an application. A scheduled command asks the chain about its own integrity every day.
Passwords are stored hashed and we cannot read them.
Daily backups are encrypted with GPG, and the private key is not on the server, so whoever seizes the server cannot open the backups. Restoring from backup was actually tested on 6 August 2026, not merely written down as policy.
The application itself is isolated on the server with its own system user, its own PHP process and a database no other application has rights on.

What we have not built yet, said out loud

It would be easy to write these in the present tense and have nobody notice before signature. But one exposed claim destroys trust in the entire list, so here they are:

We have never undergone an independent security review or an external penetration test. We hold no ISO 27001 certificate and no SOC 2 report, and we do not claim "compliance" with any framework, because compliance is not a status a party declares about itself.
Archive files are not encrypted at rest with a key specific to each organisation. That is a rule written in our internal policy and not yet implemented, so we do not say "your data is encrypted with your own key".
Two-factor authentication is not available to organisation members. It is built and structurally mandatory for our own platform administrators only.
Self-service password recovery is not built, and neither is an active-devices screen, ending other sessions, or an absolute session timeout.
One-click self-service export of your data is not built. Export today happens on request and we perform it by hand.
Self-service permanent deletion is likewise not built, and happens on request as described in the retention section.
We commit to no service level agreement today and promise no uptime figure. Any commitment of that kind belongs in writing in an enterprise contract.

Your organisation rights

You may ask for a copy of your data, correction of anything wrong in it, deletion of what you want deleted, and a record of who viewed what.

Since these requests are not self-service yet, the route today is an email to the contact address below from an organisation owner or their delegate. We reply within thirty days at most and confirm what was done in writing.

We will not charge you a fee for exercising any of these rights.

If an incident happens

If we confirm unauthorised access to your data, we notify the organisation owners within seventy-two hours of confirming the incident, with what we know, what we do not yet know, and what we are doing about it. We do not stay silent waiting for the full picture.

Minors

Diwan is an organisational work tool, is not directed at anyone under eighteen, and we do not knowingly collect their data. If we learn otherwise, we delete the account and its data.

Changes to this page

When we change something material — a new external processor, a different storage location, or a new processing purpose — we notify organisation owners by email thirty days before the change takes effect, and we update the last-updated date at the top of this page.

How to reach us

For any privacy or data question or request, write to the address below. And for anyone who wants to see the proof rather than the description: ask, and we will show you.

info@diwan.im