Built so a buyer's security team can say yes in one read.

Monirum is the workspace your team runs in — tasks, KPIs, inbox, time tracking, sourcing, and research. The data inside it includes employee information, team activity, files, and the operational records that belong to your business. We treat that data the way you'd expect a tool you depend on to treat it.

This page describes the technical and operational measures we use. Most of the same content is also in our Data Processing Agreement (Annex C). Your security team can use either format.

• Email + password through Supabase Auth. Passwords are hashed with bcrypt — never stored in plaintext.
• OAuth sign-in via Google or Microsoft. If a user signs in this way, we never see or store their provider password.
• Session cookies set by Supabase keep users signed in. They expire and rotate per Supabase Auth defaults.
• Three workspace roles — Owner, Co-Admin, and Member — enforced at the API and database layer. Co-Admin invites, removes, and edits role labels; only the Owner can dissolve a workspace.
• No shared accounts. Every user has their own account. Workspace access is granted per user, not per seat.

Monirum is a multi-tenant workspace product. Customer data is isolated at the database row level, not just at the application layer.

• Row-level security (RLS) policies in Postgres scope every read and write to the workspace and user the row belongs to. Policies are enforced by the database — not by the application — so a bug in app code can't escape the boundary.
• Per-workspace scoping on every workspace-owned table: tasks, KPIs, time logs, inbox conversations, files, audit events, and the rest.
• No cross-workspace queries are possible from the API. Workspaces are siloed from each other at the database layer.
• Audit log records administrative events — joins, role changes, removals, label edits — and is scoped per workspace, visible only to that workspace's admins.

• In transit: TLS 1.2 or higher on every client–server connection. Modern browsers and our edge layer reject older protocols.
• At rest: encryption is applied by our hosting providers (Supabase for the database and file storage; Vercel for application hosting). Keys are managed by the providers per their published practices.
• Secrets: API keys and provider tokens are stored in our hosting platform's encrypted environment storage — never committed to source control, never exposed to the client bundle.

Monirum engages a small set of vendors to run the service. Each is contractually bound to data-protection terms no less protective than our DPA. The current list:

Sub-processor changes are notified to account owners at least 30 days in advance for material updates, per the DPA.

• Logging: application and infrastructure logs are produced by Vercel and Supabase. Workspace administrative events are also written to the workspace activity log inside the product.
• Backups: the production database is backed up by Supabase per their published retention window. Backups inherit the same encryption-at-rest as the live database.
• Production access: limited to a small number of authorised engineers. Access is granted on a need-to-know basis and revoked when no longer required.
• Deployments: code reaches production through Vercel's build pipeline. Reviews precede deployment. Failed deployments are rolled back from the same dashboard.
• Dependencies: tracked in package manifests with version pinning. Security advisories on dependencies are triaged and patched.

If we confirm a personal-data breach affecting a customer's workspace, we notify the customer within 72 hours — as committed in the DPA, Section 7. The notification includes, to the extent known:

• The nature of the breach and the categories of data and people involved.
• The likely consequences.
• Measures taken or proposed to address it.
• A point of contact for follow-up questions.

We'll also cooperate with the customer's investigation, including helping with any notification obligations to supervisory authorities or data subjects where required.

Monirum is designed to align with the data-protection laws of the regions our customers operate in:

• EU / UK GDPR — Article 28 covered by our DPA, including Standard Contractual Clauses for international transfers with sub-processors outside the EU.
• Saudi PDPL — processor obligations covered by the DPA; sub-processor list, breach notification, and audit cooperation reflect the law's requirements.
• UAE Federal Decree-Law 45/2021 — same controller / processor framework reflected in our processor obligations.

We don't currently hold SOC 2 or ISO 27001 certification. If your team requires either before signing, write to us and we'll share where we are and our position on the next audit window.

If you find a vulnerability in Monirum, we want to know. Send us a message via the Help Center and choose Security or privacy issue as the topic. Include:

• What you found.
• How you reproduced it.
• What you think the impact is.

We'll acknowledge your report within 5 business days, work the fix as a priority, and credit you once it's shipped (unless you prefer to stay anonymous). Please don't exfiltrate customer data, run denial-of-service attacks, or access accounts that aren't yours.

Security questions, privacy and data requests, sub-processor questions, or anything else — send us a message via the Help Center and pick the topic that matches. A human reads every message.