Security & privacy

At a glance

Who can see our data?

Only your firm. Each firm runs on its own isolated instance with its own database — nothing is shared between firms.

Can Para send email as us?

No. Para connects to Outlook with read-only mail access. It cannot send, reply, delete, or alter a message.

Is our data encrypted?

Yes — in transit over HTTPS, and sensitive stored values, including your Microsoft tokens, are encrypted at rest with a key held outside the database.

Do you sell or mine our data?

No. Your data is never sold, shared, or pooled with another firm’s, and it is not used to train anything.

Can we get our data out?

Yes, at any time — the full workspace record, per-matter packets, and CSV exports. No lock-in.

Is there an audit trail?

Yes — a tamper-evident log of who did what and when, designed to support chain of custody.

Separation between firms

Para is single-tenant. Each firm gets its own instance and its own database file — not a shared database with a customer column. There is no query that can cross from one firm to another, because another firm’s data is not in the same database to begin with.

What Para does with your email

• Read-only access. Para requests only permission to read mail. It cannot send on your behalf, cannot reply or forward, and cannot delete or modify anything in your mailbox.
• Consented through Microsoft. Each person connects their own inbox through Microsoft’s official sign-in and consent screen. Para never sees or stores anyone’s Microsoft password.
• Your mailbox stays the source. Microsoft 365 remains the system of record for mail; Para syncs a copy into your isolated workspace so it can sort it into matters.
• Access can be withdrawn at any time. Disconnecting in Para, or revoking Para in Microsoft 365, ends the access immediately.

Encryption

• In transit: HTTPS across the whole application.
• At rest: sensitive values — notably the Microsoft access tokens — are encrypted using libsodium’s authenticated encryption where available, with an OpenSSL AES fallback. The key is stored outside the database and outside the web root, so a copy of the database alone cannot decrypt them.
• Passwords are never stored — only a one-way hash, so they cannot be recovered from the database by us or by anyone else.

Who can get in, and what they can reach

• Role-based access. A four-tier model governs what each person can see and change. Staff work from a scoped view of their own matters; owners and admins see the firm.
• Mailbox privacy. Where each person connects their own inbox, mail that does not match a matter stays private to that person — not visible to teammates, and not to admins.
• Optional two-step sign-in (2FA) using any standard authenticator app.
• Optional office-only sign-in. A firm can restrict sign-in to its own network addresses, with a break-glass path so the firm can never lock itself out.
• Brute-force protection and password rules on every sign-in, and a sign-in from an unfamiliar location is flagged for an admin to review.
• Session protection. Session cookies are HTTP-only, same-site, and secure over HTTPS; the session identifier is regenerated on sign-in, and every state-changing action carries a CSRF token verified with a constant-time comparison.

Audit trail and chain of custody

Every meaningful action — mail sorted, documents filed, matters changed, people added or removed, sign-ins — is recorded with who did it and when. The log is hash-chained: each entry incorporates the previous entry’s hash, so a later edit or deletion breaks the chain and is detectable. The log is exportable to CSV, and each matter can be printed as a packet for the file.

Backups and recovery

• Automatic daily snapshots of the workspace record, kept on a rolling window, with one-click roll-back for an owner. Rolling back saves the current state first, so it is reversible.
• A full archive bundles the workspace record together with every saved attachment for off-server storage.
• Recovery is tested, not assumed. The restore path is covered by an automated test suite that verifies a real round trip and confirms a corrupt or unrecognized backup file is refused without altering live data.
• Health monitoring. An operator endpoint reports when mail syncing or backups stop, so a silent failure is caught rather than discovered later.

How the software itself is built

• Untrusted email is treated as untrusted. Message HTML is sanitized before display and remote images are blocked until a person chooses to load them, so simply opening a message does not report back to a sender. The sanitizer is covered by an adversarial test suite of known attack payloads.
• Attachments are stored safely. Saved files are written to paths derived from internal identifiers, never from the sender’s filename, so a malicious attachment name cannot escape its folder. Files are stored outside the web root and served only to authenticated members of the owning firm.
• Incoming mail is sanitized at the boundary. Control characters and text-direction override characters — used to disguise a file as something else — are stripped before anything is shown to your staff.
• Automated test suite. Tests covering permissions, firm isolation, security behavior and recovery run before any update ships.