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, its own saved files and its own encryption key, and no firm’s data is shared with another’s. Para’s staff look after the servers; what they can see, and the one way they could reach your data, are set out under Para’s side and Encryption below.

Can Para send email as us?

No. Para never asks Microsoft for permission to send mail, so it cannot send or reply as anyone, not with either setting below on and not ever. One thing does go out from your mailbox because of Para: calendar invitations. When someone adds invitees to an entry on Para’s calendar, or ticks a teammate under Assigned to, Microsoft sends the invitation, and later any update or cancellation, from the mailbox that holds that calendar, as Outlook does for any meeting. The invitation carries the entry’s title, which names the matter, its date and time, and who is invited, and nothing else from Para. Two optional settings let it change mail in narrow ways, described under Act in Outlook and Delete in Outlook too: with the first, a person’s Forward opens as a draft in their own mailbox for them to send, and Move to Junk moves that one message to Junk Email; with the second, deleting a message in Para also moves it to Deleted Items in the mailbox, and undoing that moves it back. Nothing else in your mail is altered.

Does Para change anything in Outlook or Microsoft 365?

Your calendars: Para keeps its own Para - Case Dates calendar for your deadlines and court dates, and, only if your firm turns it on, a Para - My Dates calendar in each person’s own mailbox with the dates assigned to them. It reads one other calendar only if an admin chooses it, from their own Outlook or from a calendar account (a Microsoft account your firm connects for its calendars alone), and when someone edits one of that calendar’s entries in Para, it updates that entry there, changing only what they changed. An entry with invitees goes out as an Outlook invitation, as above. Your files: only if your firm connects a document library for case files, and then only inside your matters’ folders there (see below). Your mail is changed only if your firm turns on Act in Outlook, and then only when a person presses Forward (a draft in their own mailbox, which they send) or Move to Junk (that one message), or on Delete in Outlook too, which moves a message deleted in Para to Deleted Items, and back again if that delete is undone.

Is our data encrypted?

In transit, yes: over HTTPS, and browsers are told to use nothing else. At rest: every file saved into a matter, every restore point and safety copy of the workspace record, and every weekly archive, is encrypted on the server, each with a key of its own; inside the database, the full text of every message, the notes kept on matters, tasks and contacts, and every meeting’s link, ID and passcode are encrypted too, as are the credentials that reach your Microsoft 365 (the Microsoft tokens) and every two-step secret; and passwords and recovery codes are stored only as one-way hashes. The keys are kept apart from the data and from every backup of it, and Para keeps one sealed copy of your workspace’s key so your data can be recovered if the server is lost; see Encryption below. The rest of the database (names, email addresses, subjects and dates, each message’s preview line and a few short notes, which lists and search are built from) is protected by who can reach the server; see Current limits below.

Do you sell or mine our data?

No. Your data is never sold, shared, or pooled with another firm’s. It is used only to run your firm’s workspace.

Can we get our data out?

Yes, at any time. An owner can download everything in one file: every saved file in its matter’s folders, the whole workspace record, which reads in any database tool and restores in one step, and a list of every file with a fingerprint to check it by. It is streamed straight to the owner’s browser, so no readable copy is left on the server. Each matter also prints as a packet, and the audit log exports in full. No lock-in.

Is there an audit trail?

Yes. A hash-chained log of who did what and when, designed to support chain of custody. On a firm’s workspace nobody can clear it, not even an owner.

Separation between firms

Para is single-tenant. Each firm gets its own instance and its own database file, so there is no other firm’s data in it to reach. Each instance also keeps its own saved files, its own settings and its own encryption key. An account belonging to another firm cannot sign in to your instance at all: it is refused outright rather than shown anything.

What Para does with your email

• Read-only on your mail, unless your firm chooses otherwise. By default Para asks Microsoft for read-only access to mail: it cannot send on your behalf, cannot reply or forward, and cannot delete or modify anything in your mailbox. Two optional settings change that in narrow ways. If an admin turns on Act in Outlook, a person’s Forward opens the forward as a draft in their own mailbox, for them to send, and Move to Junk moves that one message to Junk Email; if an admin turns on Delete in Outlook too, deleting a message in Para also moves it to Deleted Items in the mailbox it came from. Either takes effect only after each person reconnects and approves the wider permission on Microsoft’s own consent screen, both are off unless someone turns them on, neither can send mail, and Para only ever moves mail, never permanently deletes it.
• Read and write on calendars. Para keeps its own Para - Case Dates calendar in Outlook and puts your deadlines and court dates there, so they show up beside everything else you already keep. If your firm turns it on, and only then, each person also gets a Para - My Dates calendar in their own mailbox with the dates assigned to them. Para reads nobody’s calendar unless an admin chooses one, either from their own Outlook or from a calendar account: a Microsoft account your firm connects for its calendars alone, with no access to mail, whose credentials are encrypted like a mailbox’s. It reads that calendar alone, with its private entries left where they are. When someone edits one of its entries in Para, Para updates that entry in Outlook, changing only what they changed. It does not touch events it did not create or sync. An entry on Para’s calendar with invitees, typed in or ticked under Assigned to, goes out as an Outlook invitation from the mailbox that holds the calendar, and Microsoft sends any update or cancellation the same way. Nobody is invited to an entry whose date has passed or that is marked done.
• One document library, only if your firm connects it. If an admin connects Case files in Microsoft 365, Para asks for access to the one document library your firm grants it, and nothing else in your Microsoft 365: not your other sites, not anyone’s OneDrive. It works both ways, inside your matters’ folders there. Para puts your matters’ files in the library, renames and moves them as they change in Para, and sends them to the library’s recycle bin when they are removed in Para. It also takes in what your team does in a matter’s folder: a file added, saved again, renamed, moved or removed there is the same in Para, recorded on the matter under the name of whoever Microsoft says made the change. A file someone adds to a matter’s folder becomes part of that matter’s case file, and from then on Para looks after it like any other. Some changes are put back rather than taken in, such as a file moved into another matter’s folder or out of every matter, because a file changes matters only in Para, where the move is recorded. A large batch of removals at once waits for an admin, who chooses whether to remove them in Para too or put them back in the library, so a sync program that empties a folder by mistake cannot empty a matter. Para never takes in anything outside the matters’ folders, never overwrites a file already there, and removes one of its folders only when it holds nothing. The library is granted once, in the admin’s own browser, through a separate Microsoft sign-in that Para’s servers never see and that keeps nothing afterwards.
• 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. It reads two folders, the Inbox and Sent Items, so a matter holds both sides of its correspondence. It never reads Drafts, and never the Bcc line of anything.
• Access can be withdrawn at any time. Disconnecting in Para deletes the stored credentials at once. Revoking Para in Microsoft 365 ends the access when Microsoft stops honoring the token it last issued, which can stay usable until it expires, at most about 90 minutes later.
• One Microsoft organization per firm. Personal Microsoft accounts are refused, and once a firm’s first mailbox is connected, a mailbox from any other organization is refused before anything from it is saved. The same check runs when the calendar account or the document library is connected.

Encryption

• In transit: HTTPS across the whole application. A request that arrives over plain HTTP is sent to HTTPS (a form sent that way is refused, not processed), and browsers are told to use HTTPS alone for a year.
• Saved files, sealed. Every file saved into a matter, whether an attachment, the saved copy of a message or a file somebody added, is encrypted where it sits, each with a key of its own (AES-256-GCM), and checked piece by piece as it is read, so a file that was altered, cut short or swapped is refused rather than shown. A copy of the documents folder, of a restore point or of an archive holds nothing readable without the key.
• Message text, notes and meeting details, sealed inside the database. The full text of every message, a matter’s notes, a task’s notes and a contact’s notes, and a calendar entry’s or a trial’s notes, meeting link, meeting ID and passcode are encrypted before they are written, with the same ciphers as the files and under a key used for nothing else, so a copy of the database file, or a query that reads it directly, holds nothing readable of them. The same holds for the records that keep whole rows for Undo, a deleted matter or message, a removed calendar entry, and what a matter’s details said before a change. Each value is checked as it is opened, and one that was altered or moved is refused rather than shown.
• At rest: the Microsoft access tokens, for mailboxes, a calendar account and a connected library alike, and two-step secrets are encrypted with AES-256-GCM, which also shows any change made to them. The key is never stored in the database, never included in a backup or archive of it, and kept where the web server will not serve it, so that a copy of the database, or of any backup, cannot decrypt them on its own. The one copy of it kept anywhere else is sealed, as the next point explains.
• Your key, kept safe for recovery. So a workspace can be brought back if its server is ever lost, your server seals a copy of its encryption key, and of the key it is retiring during a change, to a safekeeping key that belongs to Para. Para keeps that sealed copy apart from your server, so it outlives any one server. The secret that opens it is not on your server or on any server Para runs. This means Para’s staff could recover your workspace’s key and, with a copy of your data, read what that key protects. A replacement safekeeping key does not take effect at once: it waits a set period after it is requested, and every member of Para’s staff is told of the request.
• Keys can be changed without losing anything. When the key is replaced, what was encrypted under the old one still opens while saved files, sealed text and stored secrets move to the new one in the background, and the server reports when nothing is left under the old key. A file encrypted under a key the server does not hold is reported to the owners, never guessed at.
• 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 (lead owner, co-owner, admin, member) governs what each person may do (manage accounts, create matters, restore or close the workspace), under a strict rule that you can only manage someone below you: an admin can never reset or remove an owner, co-owners cannot act on each other, and only the lead owner manages co-owners. Deleting mail for good is open to everyone, but only from the Trash, never a teammate’s private mail, always recorded first, and an owner can bring it back for 30 days. Inside a firm the case file is shared work: everyone sees the firm’s matters, with a Just me filter each person can switch on for their own view. What is enforced is the separation between firms, and a teammate’s personal unsorted mail, which stays private to them either way.
• Mailbox privacy. Where each person connects their own inbox, mail they have not sorted into a matter, both what arrived and what they sent, stays private to that person and is not visible in Para to teammates, admins or owners. When a person leaves, it goes with them rather than to the firm. Every view of mail is the person’s own, at every tier, owners included: their mailbox, their matters’ sorted messages, and the shared intake that concerns them. The one firm-wide view is Need to sort, where owners and co-owners can choose Everyone to help clear the firm’s backlog of shared intake and mail on its matters. To cover for someone, an admin or owner can open the workspace of a person below them, never a peer’s or an owner’s, with View as: a banner shows on every page while they do, the start and end are recorded in the audit trail, what they do is recorded as themselves, and that person’s private unsorted mail stays hidden even then. The one exception is the owner’s download of the whole workspace: a copy of the entire database holds everything, which is why it asks for the owner’s password and is recorded every time.
• Folders of your own. Each person can keep folders outside every matter for the work that belongs to no client, such as continuing education, bar dues, HR letters and receipts, and the mail and files in them are visible to nobody else in Para: not teammates, not admins, not owners, and not while an admin or owner is viewing that person’s workspace with View as. Sorting mail into one changes nothing for anybody else, and mail that belongs to a matter always goes to the matter, so nothing that belongs to a client can be quietly kept out of its case file. The download of everything gives each person their own folders and never another’s, and when somebody leaves, their folders and what is in them go with them rather than to the firm. The one exception is the one above, for the same reason: the copy of the whole database an owner can download, and the restore points kept on the server, hold everything Para holds, because that is what putting a workspace back needs.
• Two-step sign-in (2FA) using any standard authenticator app. A firm can require it for its owners and admins or for everyone, and a new workspace starts out requiring it for owners and admins. While it is required, nobody it covers can switch theirs off. A lost phone is reset by someone above that person in the firm, who confirms with their own password; the reset is recorded in the audit trail. Each person also gets ten one-time recovery codes for a lost phone, shown once and stored only as one-way hashes; making new ones replaces the whole set, and a reset wipes the old secret and codes together.
• Passkeys, for anyone who wants them. A person can add a passkey to their own account, made on their own device and opened with their face, fingerprint or the device’s PIN. Para keeps only its public half, and a passkey works only at your workspace’s own address, so a look-alike site cannot collect it. Adding one, like turning on the authenticator app, takes the person’s own password, or a sign-in they made moments before. Where the firm requires two-step sign-in, a passkey counts as the second step: the device checks who is holding it, so it is both steps in one, and a person whose second step is a passkey cannot sign in with their password alone. A reset by someone above them takes their passkeys off along with their authenticator, and taking one off signs out every other browser they were signed in on.
• No one can claim an install. Creating a workspace on a new server takes a one-time setup code that Para makes for that server and sends to the person your firm named, as a link with a last day after which it stops working. A wrong code is refused and written down with the address it came from. Whoever uses the link first sets up the workspace and becomes its owner, so treat it like a key. Creating the workspace is recorded in the audit trail with where it was done from, and both the new owner and Para’s staff are told at once, so a link used by the wrong hands is seen the moment it is used. A workspace that has been closed can never be set up again on the same server.
• Links that work once. An invitation or a password-reset link works once and for 7 days. Only a fingerprint of it is stored, never the link itself, and sending a new one stops the old one working.
• Optional office-only sign-in. A firm can restrict sign-in to its own network addresses, built so the firm can never lock itself out.
• Optional computers-only access. A firm can keep Para off phones and tablets and allow individuals one at a time. Stated plainly: this holds a firm’s own policy in place against the ordinary ways around it and records every attempt it turns away; it is not a barrier against someone deliberately working around it. Office-only sign-in above is the control that decides who reaches the workspace.
• Brute-force protection and password rules on every sign-in, every two-step code and every password check inside Para, braked two ways: by the connection and by the account. The brake can never lock anybody out of their own account: the browsers its owner already signs in from are exempt, so no one can pause somebody’s sign-in by guessing at their address. What it stops is guessing from somewhere new: wrong answers in a row make each next try wait longer, repeated wrong answers against one account pause sign-in to it from browsers it has never been used on, however many connections they arrive from, and a daily ceiling pauses it for the rest of the day. Every failed attempt against a real account is recorded in the audit trail, how long a wrong answer takes never reveals whether an address has an account, and an unusual sign-in is flagged for an admin to review.
• Password rules. At least 10 characters with at least one number or symbol; never the person’s own email address or the part before the @; never one character repeated; never one of the passwords most often guessed. The same rule applies everywhere a password is set.
• The password, first. The most consequential actions (downloading the whole workspace, restoring or rolling it back, closing it, handing over the lead role, and turning off or resetting two-step sign-in) each ask for the person’s own password, even in the middle of a session.
• Session protection. Session cookies are HTTP-only, same-site, and secure over HTTPS; the session identifier is regenerated at every sign-in and an identifier the server never issued is never adopted; each sign-in starts a clean session, so on a shared computer nothing of the last person’s is left in the next one’s; and every state-changing action carries a CSRF token verified with a constant-time comparison.
• Session binding. A session is tied to the browser it was opened in and checked, on every request, for where it comes from. A different browser presenting the same session ends it; a move to a network the person has not used before asks for their password again before anything else is served; and where a firm has locked sign-in to approved locations, a connection that leaves them is signed out.
• What Para keeps, and for how long. Mail sorted into a matter is the case file and is kept until the firm removes it. Everything else can be put on a schedule: a firm chooses how long mail it has deleted or set aside is kept (30 days to a year, or keep everything, which is the default), and clearing it is the ordinary permanent deletion, recorded per message, with an owner able to bring it back for 30 days afterwards. Separately, a message that never went into a matter or into someone’s own folders keeps who it was from or to, its subject, date and preview line, but not its full text after 30 days: opening it reads the message from the mailbox again. Nothing Para does removes anything from your Outlook.
• What the server writes down when something fails. A failure on the server, whether a mailbox refusing a token, a scheduled job that did not finish or an error behind a neutral page, is written to a technical log kept apart from your workspace, so it can be looked into rather than guessed at. A line carries the shape of the failure, a reference number and identifiers: a mailbox, a document, an account. It carries nothing from a matter or a message, and email addresses, keys and the names of saved documents are stripped out before a line is written, so a copy of the whole log says that something failed and nothing about whose. The one network address it keeps is that of someone refused while trying to set up a new workspace, so the attempt can be traced. Lines are kept 30 days and then deleted. If the log cannot be written where it belongs, a line goes to the hosting server’s own error log instead, which keeps its own schedule. If errors start piling up, Para’s staff are told, the same way they are told when a backup is missed: the server is theirs to keep.
• Sessions end when they should. Each person can see every browser signed in to their account, what it is, roughly where it last was and when it was last used, and can sign any one of them out, or all the others at once. Changing a password or a two-step setting signs out every other browser on its own; a password reset, a two-step reset, or a disabled account ends every one of them; and an admin can sign someone below them out of everything, for a computer that has gone missing. Sessions also end when the browser closes, after a working day’s idleness, and at the end of the firm’s own day. Ending one deliberately, your own or an admin’s on an account below them, is recorded in the audit trail.

Audit trail and chain of custody

Every meaningful action is recorded with who did it and when: mail sorted, documents sorted, matters changed, people added or removed, sign-ins and failed sign-ins, every look at a teammate’s workspace through View as, every download of the whole workspace and every export. The log is hash-chained: each entry incorporates the previous entry’s hash, so an entry edited, or removed from the middle of the record, breaks the chain, and Para checks the chain whenever an admin opens the log. On a firm’s workspace the log cannot be cleared by anyone. It exports in full to a spreadsheet, each entry with its seal, so keeping a copy elsewhere can later show that nothing was taken off the end; Para’s staff are sent the log’s latest seal each week, so a copy is kept off your server either way. Network addresses are recorded in full and shown masked to everyone; an owner can reveal them for a security review. Each matter can be printed as a packet for the file.

Backups and recovery

• Automatic daily snapshots of the workspace record (the saved files are in the weekly archive below), each encrypted on the server like the archives, with the most recent five to seven kept, and one-click roll-back for an owner. Rolling back saves the current state first, and does not go ahead if it cannot, so it is always reversible.
• A full archive bundles the workspace record with every saved file, weekly, and the newest three are kept, ready to be copied off the server. The archive is encrypted as a whole, and the encryption key is deliberately not in it: it is kept separately, so an archive that goes astray is unreadable.
• Recovery is tested, not assumed. An automated test suite covers a real database round trip, a full archive decrypted and unpacked back into a working record with its documents, and a corrupt or unrecognized backup file refused without altering live data.
• When a firm leaves. Closing a workspace removes it from Para at once: the database is emptied of the firm and rebuilt, so nothing of it lingers in the file, and that server can never set the workspace up again. The safety copy, restore points, archives and saved files are kept for 30 days in case the close was a mistake, then deleted from the server automatically, and the deletion is recorded. Closing does not reach into your Microsoft 365: Para’s calendar and the files in a connected library stay there for your firm to keep or remove. Copies taken off the server, and the sealed copy of the workspace key that Para keeps for recovery, are kept apart from the server and are not removed by closing.
• Security alerts. Owners are emailed the same day something needs a look: an account paused after wrong passwords, an unusual sign-in to an owner or admin account, a password or two-step reset, a passkey added to an owner or admin account, a role change, the workspace downloaded or restored, a security setting loosened, or Outlook mail no longer coming in for a mailbox. Every sign-in’s network address is on the activity log either way, shown masked; a person’s own browser on a new network is recorded there without alarming anyone. Owners choose, person by person, what each receives: all alerts, only the urgent ones, or just the kinds picked for them, and the weekly integrity check. Up to ten addresses can be added, and each can be sent a test; the alerts that say the activity log, the saved files or stored text, or these settings were touched always go out, and anyone taken off the list is told. An alert carries what happened, when and a masked network address, never anything from a matter or a message, and it goes out through the hosting provider’s own mail server. Para’s staff are sent a copy of the alerts about paused or blocked sign-ins, a new workspace, the lead role handed over, the workspace downloaded or restored, and integrity problems, with the firm’s name and the account’s role but never the person’s name. The upkeep of the server itself (the scheduled job, the daily restore point, space on the server, repeated errors) is told to them alone, since it is theirs to put right. The activity log’s seal is re-checked every day, and a firm can have it emailed weekly so a copy is kept off the server.
• Health monitoring. An operator check reports when mail syncing, the scheduled job or backups stop, when the server runs low on space, or when a saved file or stored text cannot be opened, so a silent failure is caught rather than discovered later. The owners hear of what needs them, such as a mailbox to reconnect or a file that cannot be opened. The detail is for Para’s staff alone. A failure is reported once, when it starts, and again when it is put right, never once per retry, so a count of errors means new errors. A mailbox Microsoft keeps refusing is tried again on a lengthening interval, and is tried at once when someone presses Sync now or connects it again.

Para’s side: updates, staff access and what we can see

• Every release is signed. Before an update reaches any workspace, its signature and the fingerprint of every file in it are checked: a release with one byte changed, a file added or missing, or a signature from any other key is refused before anything is written. A release that carries any firm’s data or settings is refused too.
• Updates are proved first, and reversible. An update is proved on a workspace that holds sample data only, never a firm’s, before it reaches any firm, and firms are then updated one at a time. A restore point of each firm’s database is taken first where the server allows it, and the workspace must be proved running the new release; if it is not, its previous release is put back at once, the rollout stops before any other firm, and Para’s staff are told. A release can be taken back from every firm it reached the same way.
• An update moves only code. It never touches your saved files or your settings, and never changes your database in a way the release before cannot run on, so going back never needs your data to go back.
• Code checked against what was signed. Each workspace keeps the signed record of its release, and Para’s staff can check its code against that record, file by file. A file changed, missing or added is named, and Para’s staff are emailed the first time a difference is found.
• How Para’s staff sign in. Para’s staff manage firms’ servers from an operations console of their own. It is built never to read a firm’s mail, matters, documents or people, and it never signs in as anyone at a firm. Staff sign in to it with a passkey, or with a password plus a code from an authenticator app; a password alone never signs anyone in, each code works once, and a passkey works only on the console’s own address, so a look-alike site cannot capture it. Sensitive actions, such as releasing or rolling back an update, changing a license, changing who has access, or touching the sealed key copies, ask for a fresh passkey or code, even in the middle of a session. Repeated wrong attempts pause sign-in, and the pause lifts on its own. A session is tied to the browser that opened it and ends after a short time idle and after a set maximum length. Sign-ins, updates, license changes, changes to staff access and settings, and every download of the sealed key copies are written to the console’s own hash-chained activity log, so an entry changed or removed from the middle breaks the chain.
• What Para’s staff can see. A workspace answers Para’s health check with its release, whether it is set up, its license, whether mail, the scheduled job and backups are running, how much space it uses, how many items are sealed or cannot be opened, and, when asked, its recent technical log lines, which carry nothing from a matter or a message. It never sends the firm’s people or anything the firm wrote. Para’s staff are also sent copies of some security alerts, with the firm’s name and the account’s role but not the person’s name, the alerts about the server’s upkeep, and the weekly seal of the activity log. The sealed copy of your workspace key is the one thing Para holds that could reach your data; see Encryption.
• A lapsed license never locks you out. Each workspace runs under a signed license. From 30 days before it ends, and after, only admins see a notice, and everything keeps working. Once it has been ended for 45 days, new matters cannot be opened; nothing else changes: mail keeps arriving and sorting, dates keep counting, and every file stays readable and exportable.

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 kept encrypted, where the web server will not serve them, and handed only to signed-in members of the owning firm.
• Incoming mail is sanitized at the boundary. Control characters and text-direction override characters, which are used to disguise a file as something else, are stripped before anything is shown to your staff.
• The browser is told to be strict. Every page carries a content security policy under which only Para’s own scripts, stamped for that one page, can run. No other site can show Para’s pages in a frame, files are never reinterpreted as another type, pages are never cached, a link to another site passes on only Para’s address and never the page’s, and the camera, microphone, location and payment features are switched off for Para.
• Nothing from anyone else. Para loads no scripts, fonts, trackers or analytics from other sites; the one exception is a message’s own images, when a person presses Show images. The server talks only to Microsoft, and Para’s own emails, which are security alerts only, go out through the hosting provider’s mail server.
• Documents open safely. Only PDFs and ordinary images are shown inside Para, under a policy that lets them load nothing and run nothing. Para decides a file’s type from its name, never from what the sender claimed, and never shows an SVG image inline, since one can carry script. Everything else downloads. A Word, Excel or PowerPoint file in a connected library is shown as a PDF Microsoft makes of it, fetched by Para’s server, so the short-lived address Microsoft issues never reaches a browser.
• Uploads are checked. A saved file can be up to 40 MB, nothing new is saved while the server is low on space, a file can go only into a matter and folder of your own firm, and it is encrypted as it is saved. Intake sheets and checklist files are read in memory to fill in a form and are not kept, and a PDF Para cannot read for certain is refused rather than guessed at.
• Automated test suite. Tests covering permissions, firm isolation, security behavior and recovery run before any update ships.