Para

Privacy Policy

In effect since October 3, 2026.

Contents
  • Who we are
  • Three kinds of information, and who decides
  • Firm Data: what a workspace holds
  • What Para does in your Microsoft 365
  • Who inside the firm sees what
  • What we receive about each workspace
  • Customer and order data
  • Our public website
  • What we never do
  • Cookies and what the browser keeps
  • Where it is held
  • Sub-processors and other recipients
  • How it is protected
  • How long it stays
  • When a firm leaves
  • Your choices and requests
  • Requests from courts, regulators and law enforcement
  • If something goes wrong
  • California
  • Changes
  • Contact

Interim version, effective October 3, 2026. It will be replaced after legal review; firms are told before any material change.

This policy explains what Para holds, why, who else receives it, how long it stays, and what you can ask us to do about it. It covers Para itself (each firm’s workspace), the pages a firm uses to sign up, and our public website. It is written to be read by a firm’s partners, its general counsel and its IT provider. If something here is unclear, write to us and we will answer plainly, including when the answer is “not yet.”

Who we are

Para is provided by Para (“we”, “us”), Cali. Privacy and legal questions go to order@yitzys.com.

Three kinds of information, and who decides

  • Firm Data: we act for the firm. Everything in a firm’s Para workspace belongs to the firm: its matters, contacts, mail, documents, calendar, deadlines, tasks and notes, the accounts of its people and the record of their sign-ins, and its activity log. We hold and process Firm Data only to run that firm’s workspace, on its instructions, as its service provider. The firm decides what goes in, who may see it, how long it stays and when it is deleted. If you are a firm’s client, an opposing party, a witness or anyone else whose information is in a firm’s workspace, send your request to the firm. If you send it to us, we will pass it on and help the firm answer.
  • Customer and order data: we decide. When a firm buys Para, we keep the order, the details of the person who signed it, billing records, the firm’s record in our operations panel, and the operational facts and alert copies each workspace sends us. We hold these to sell, set up, run, secure and bill for the service.
  • Website visitors: we decide. Our public website collects only what someone types into its demo request form.

Firm Data: what a workspace holds

The firm’s people. For each account: name, work email address, role, job title, whether the account is active, an availability status with an optional note, an “on vacation until” date, display preferences and the date the person first signed in. A password is kept only as a one-way hash, never the password itself. If the person uses two-step sign-in, the secret their authenticator app was set up with is stored encrypted, and their ten one-time recovery codes are stored only as one-way hashes. If the person adds a passkey, Para keeps only its public half, the name they gave it, and when it was added and last used; the passkey itself never leaves their device. Invitation and password-reset links are stored only as hashes too.

Scheduling and office settings. Time-off requests, with their dates, a reason the person types, their status and who decided them. Dates a person is unavailable for trial, with a reason. If the firm limits sign-in to its offices, the approved network address ranges and their labels.

Sign-in records. For each browser signed in to an account: a label for the kind of browser and device (never the browser’s full identification string), its network address, when it was used, why its session ended, and a one-way hash of the session identifier. Para also keeps each network address a person has signed in from, with when it was first and last seen, so that a sign-in from somewhere new can be noticed. Each failed password attempt is kept briefly with its network address, the email address typed and a one-way fingerprint of the browser. If the firm limits sign-in to its offices, the address of anyone turned away is kept so an admin can see the attempt.

Matters and contacts. A matter’s details: claim number, date of loss, parties, court, judge, the team, trial details, and the addresses of people outside the firm invited to its dates. Contacts on a matter: name, email address and role. The firm’s contact list: name, role, organization, email address, phone number and notes.

Mail. Para brings in mail from the Microsoft 365 mailboxes the firm’s people connect. It reads two folders, the Inbox and Sent Items. It never reads Drafts, and never the Bcc line of anything. When a mailbox is first connected, Para brings in up to the last 180 days of its mail. For each message it keeps the sender’s name and address, the To and Cc lists, the subject, Outlook’s preview line, the full text, the dates, the identifiers that tie it to its conversation and to Outlook, and the names and sizes of its attachments. Attachment files themselves are saved only for mail sorted into a matter or into a person’s own folders. For other mail, Para fetches the file from Outlook when someone opens it. Mail in a law firm carries whatever the firm’s work carries: a client’s information, an opposing party’s, a witness’s, and in some practices medical records and bills. Para holds what the connected mailboxes hold, for the mail it brings in.

Documents. Files saved into a matter: attachments, a PDF of each sorted message, and files a person adds directly, up to 40 MB each. Each is encrypted on the server under its own key, in a folder outside the web root that no web address reaches. A person can also give Para an intake sheet or a checklist file to read. Those are read in memory and not kept, and a PDF Para cannot read is refused rather than guessed at.

Calendar, deadlines and tasks. A calendar entry keeps a title, type, date and time, location, meeting link, meeting ID and passcode, who is assigned, notes, and any outside addresses invited. A deadline keeps a label, date, location, a status note and who is assigned. A task keeps a title, due date, assignee, notes and a thread of further notes.

Folders a person keeps for themselves. Each person can keep folders outside every matter for work that belongs to no client, with mail and files in them. Inside Para they are shown to nobody but that person, owners and admins included. They are still part of the firm’s workspace, so the whole-workspace record an owner can download, and the restore points on the server, hold their records. The files in them are left out of an owner’s download unless they are that owner’s own. When the account is removed, those folders and what is in them are deleted rather than handed to the firm.

The activity log. Who did what, and when: mail sorted, matters changed, people added or removed, sign-ins and failed sign-ins, downloads and exports. It records the full network address of each sign-in, and the subject and sender’s address of each message deleted for good. Network addresses are shown masked, and owners can reveal them. The log is hash-chained, so an entry changed, or removed from the middle, breaks the chain. On a firm’s workspace nobody can clear it, not even an owner. It exists so a firm can show chain of custody.

Security alerts. Para emails a firm’s owners, and any addresses an owner adds, when something needs a look. Each alert is kept with its subject, its text, the addresses it went to and a masked network address.

Technical log. When something fails on the server, Para writes a line to a technical log kept apart from the workspace, so the failure can be looked into. A line carries the kind of failure, a reference number and identifiers, such as a mailbox, document or account number. Email addresses, keys, tokens and the names of saved documents are stripped out before it is written. Network addresses are not stripped: a refused attempt to set up a workspace on a new server is logged with the visitor’s address. If the log folder cannot be written, the line goes to the hosting server’s own error log instead.

What Para does in your Microsoft 365

Each person connects their own mailbox through Microsoft’s own sign-in and consent screens. Para never sees a Microsoft password. Access can be withdrawn at any time, in Para or in Microsoft 365. Personal Microsoft accounts are refused, and every connection a firm makes (mailboxes, a calendar account and a document library) must come from the firm’s own Microsoft organization.

  • Mail is read-only by default. Para asks Microsoft for permission to read mail, not to change it. A firm can turn on two optional settings, and each person then approves the wider permission on Microsoft’s own screen. With Act in Outlook, 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 Delete in Outlook too, deleting a message in Para also moves it to Deleted Items in the mailbox it came from, and undoing that moves it back. Para only ever moves mail. It never deletes mail for good.
  • Para never asks for permission to send mail. It cannot send or reply as anyone. Calendar invitations, below, are the one way mail leaves a firm’s mailbox because of something done in Para.
  • Calendars. Para keeps its own “Para - Case Dates” calendar in Outlook for the firm’s deadlines and court dates. A firm can also have Para keep a “Para - My Dates” calendar in each person’s own mailbox. That is off unless the firm turns it on. Para reads one other calendar only if an admin chooses it, either from their own Outlook or from a separate calendar account: a Microsoft account that is nobody’s mailbox and is given calendar access only. When someone edits one of that calendar’s entries in Para, Para changes only what they changed. It does not touch events it did not create or sync.
  • Calendar invitations. When an entry on Para’s calendar has people invited, whether addresses typed into its invite box (which can be outside the firm) or teammates ticked under Assigned to, Para lists them on the Outlook entry. Microsoft then sends the invitations, updates and cancellations from the mailbox that holds Para’s calendar. An invitation carries the entry’s title, which is the matter’s name and a label, and its date and time. Nothing is sent about an entry whose date has passed or that is marked done.
  • One document library, only if the firm connects it. An admin can connect Case files in Microsoft 365, which gives Para one document library the firm chooses and nothing else: not the firm’s other sites, not anyone’s OneDrive. The library is granted once, in the admin’s own browser, through a separate Microsoft sign-in that keeps nothing afterwards. Para puts each matter’s files in that matter’s folder there, and renames, moves or sends to the library’s recycle bin what it put there as those files change in Para. It also takes in what people do inside the matters’ folders: a file added, saved again, renamed, moved or removed there changes in Para too. A file a person puts in a matter’s folder becomes part of that case file, so Para may later move it, or send it to the recycle bin when it is removed in Para. Some changes are put back rather than taken in, such as a file moved into another matter’s folder or out of every matter. A large batch of removals at once waits for an admin to decide. Para never takes in anything outside the matters’ folders, and never sends anything from a person’s own folders.
  • In Microsoft’s own terms. A mailbox connection asks for openid, profile, email, offline_access, User.Read, Mail.Read and Calendars.ReadWrite, with Mail.ReadWrite in place of Mail.Read only where a firm has turned on one of the optional settings above. A calendar account asks for the same sign-in permissions and Calendars.ReadWrite, with no mail. The document library connection asks for the same sign-in permissions and Lists.SelectedOperations.Selected. The one-time grant in the admin’s browser uses Sites.ReadWrite.All and Sites.Manage.All, without lasting access.

Who inside the firm sees what

  • Matters are shared work: everyone at the firm can see the firm’s matters.
  • Every view of mail shows a person their own: their mailbox, their matters’ sorted mail, and the shared intake that concerns them. This holds at every role, owners included. The one firm-wide view is the list of mail waiting to be sorted, which owners and co-owners can widen to the whole firm.
  • Mail from a person’s own mailbox that they have not sorted into a matter stays private to that person in every view, admins and owners included.
  • Admins and owners can use View as to open the workspace of a teammate below them, never an owner’s or a co-owner’s. A banner shows on every page while it lasts, and its start and end are recorded.
  • The one exception to all of these is the whole-workspace copy. The record an owner can download, and the restore points on the server, hold everything Para holds, because that is what putting a workspace back needs. The download asks for the owner’s password, is recorded, is emailed to the owners and is copied to us as an alert.

What we receive about each workspace

Our operations panel, which we use to set up, update and license workspaces, is open only to our own staff. They sign in with a passkey, or with a password plus an authenticator code, and the panel logs their sign-ins and key actions. It is built never to read a firm’s mail, matters, documents or people, and never to sign in as a firm’s user. What reaches us about a workspace is this:

  • Health facts. Each workspace answers our health check with its release, its setup and license state, the Microsoft app identifiers it signs in through, how recently mail came in and backups ran, storage sizes, and counts of encrypted files and log lines. Never a firm’s matters, mail or people. Anyone else who asks gets only a status word and a time.
  • Alert copies. For some alerts we receive a copy: sign-in paused on an account or from a connection, a workspace set up, the lead owner role handed over, the workspace downloaded or restored, files or stored text that cannot be opened, and an activity log that fails its integrity check. Alerts about the server itself (the scheduled job stopped, a restore point missed, server space low, restore points that cannot be opened, repeated errors) come to us alone. Our copy carries the firm’s name, the alert, the role of the account involved (never the person’s name), the time and a masked network address.
  • The weekly integrity check. Each week we receive the firm’s name, the number of activity-log entries, whether the log’s seal is intact, the latest seal, the number of alerts that week and the Para version. Never the entries themselves.
  • A sealed copy of the workspace’s encryption key. Each workspace’s encryption key is made for that firm alone and kept in the workspace’s own settings file, never in its database or in any backup of it. So that a firm’s data can be recovered if its server is lost, each workspace also seals (encrypts) a copy of its key, and during a key change the key being retired, to a safekeeping key of ours. We keep that sealed copy in our operations panel, and it is emailed to our operations staff when it is new or changes. The secret that opens it is not kept on any server that runs Para, our operations panel included. Holding it means we are able to recover a firm’s key, and with it to read that firm’s encrypted data. We use it only to restore a firm’s workspace, at the firm’s request or with its agreement.

The people who run Para’s operations also have administrative access to the hosting where workspaces run, as any hosting operator does. That access could reach a firm’s data, so we limit it by rule: we open a firm’s data only to do something the firm asked, to look into a fault it reported or a security incident, or where the law requires it. If we ever work inside a firm’s workspace, it is through an account the firm gives us, and what we do there goes on the firm’s activity log like anyone else’s.

Customer and order data

The order and its signing. A firm buys Para through a numbered order our staff prepare. It names the firm, the person who will sign, the plan, how the firm will pay and any special terms. The order’s link opens a page for that order alone. To sign, the signer gives the firm’s legal name and address and their own name, title and email address, confirms that they may sign for the firm, and types their name as their signature. We record when the order was opened and signed, the network address it was opened and signed from, and the browser’s identification string. These signing details are stored encrypted. The contact named on the order, and the name and email address of the staff member who issued it, are kept with the order without encryption.

The signed copy. Signing produces one PDF: the order, the agreement in full, and a certificate showing the signer’s name, title and email address, the firm’s legal name and address, when the order was opened and signed, the network address and the browser. We keep it encrypted, and it is emailed to the signer and to our operations staff. Anyone holding a copy can check it against ours on a verification page. A file checked there is not kept.

Payment. A firm pays by card or bank account through Stripe, by invoice, or not at all during a pilot. Card and bank details are entered on Stripe’s own page and never reach us. Stripe receives the signer’s email address, the order number, the plan and the price, and collects a billing address. We keep Stripe’s customer and subscription identifiers, the payment method, the date paid and the date paid through, and we check the subscription with Stripe from time to time.

Setting up the workspace. After signing, we set up the firm’s workspace and email the signer a one-time setup link. Our panel keeps, for each firm: its name and address, the workspace’s address, the plan and billing details, the license, the name and email address of the person the workspace was set up for (encrypted), the setup code until setup is done (encrypted), the latest health facts and the sealed key copy. That person’s name and email address are also written into the workspace’s settings file.

Our own records. Our panel keeps an activity log of our staff’s sign-ins and key actions in it, such as orders, updates, license changes and staff changes, with the network address each came from. Orders made and paid are recorded with the firm’s name. A signing is recorded without the signer’s name. A browser that opens an order link gets a session record with its network address and a one-way fingerprint of its browser string, and a browser that tries wrong order links is paused.

Mail with us. Mail a firm exchanges with us about its account, its order and support is kept in our business mailboxes.

Our public website

The website has one form, to request a demo. It asks for a name and an email address, and optionally the firm, a phone number, team size and a note. A request is saved on the server that runs the website, without encryption (in a plain text file if the site’s database cannot be written), and emailed to our business mailbox. It is used to arrange the demo and nothing else: no list, no newsletter. Ask at order@yitzys.com and we will delete your request.

To limit floods of submissions, the site keeps a one-way fingerprint of the sender’s network address with the times of recent requests. Each is kept for about an hour. The website sets no cookies, runs no analytics and loads nothing from other sites. A light or dark choice is kept in the visitor’s own browser.

What we never do

  • We do not sell Firm Data or anyone’s personal information, rent it, or share it for anyone’s marketing.
  • We do not pool one firm’s data with another’s. Each firm’s workspace has its own folder, database, settings file and encryption key. Firms’ workspaces run side by side on hosting we manage, so they share servers, but no firm’s data is shared with another.
  • We use Firm Data only to run that firm’s workspace.
  • There are no advertising identifiers, tracking pixels, analytics, session-recording tools or scripts from other companies in Para or on our website. Para connects to no outside service but Microsoft’s, apart from sending its alert emails through the hosting server’s own mail system.

Cookies and what the browser keeps

Para sets no advertising or analytics cookies. It sets four cookies of its own:

  • PHPSESSID, the session cookie, so Para knows you are signed in. It is HTTP-only, same-site (Lax) and secure over HTTPS, and it ends when the browser closes. The server also ends the session at sign-out, after 14 hours without use, and at midnight on the firm’s clock, and a password or two-step change ends the person’s other sessions.
  • pf_known1, a signed “known browser” mark, kept up to 180 days. It is signed so it cannot be forged, and it signs nobody in. Its only use is to let Para recognize a browser an account already uses, so that wrong guesses made elsewhere can never lock that person out. It is HTTP-only, same-site (Lax) and secure over HTTPS.
  • tz, the time zone, set by the page for one year. It holds the browser’s time zone name, so times show in the reader’s own zone.
  • pf_touch, set by the page for one year. It notes whether the device is a phone or tablet, for the firm’s computers-only access setting.

The browser also keeps some things on the person’s own computer, which stay there: light or dark, sections left folded, saved table views, rows left open (for 14 hours), and each tab’s scroll position and filters. It also keeps text typed into a form and not yet saved, for up to a day, or up to 7 days for a new calendar entry, so that an error does not lose it. Password, code and token fields are never kept. That typed text is not tied to the account and is not cleared at sign-out, so people should not share one browser profile. On a shared computer, give each person their own.

The order page sets one secure, same-site (Lax) session cookie for the signer, so the page survives the return from Stripe’s page. It lasts at most 24 hours and ends after 2 hours without use. Our website sets no cookies. Our staff’s sign-in to the operations panel uses cookies of its own that no firm or visitor receives.

Where it is held

Each firm’s workspace, with its database, saved files, restore points and archives, is held on servers run by our hosting provider (listed under Sub-processors). The restore points and archives are kept on the same server as the workspace. Para itself does not copy them anywhere else, and because they are encrypted, a copy taken elsewhere cannot be read without the key. Mail stays in Microsoft 365 as the system of record, and Para keeps a copy in the firm’s workspace so it can sort it into matters. Para’s calendars and a connected document library are in the firm’s own Microsoft 365. We will tell any firm the name of our hosting provider and the region on request, before or after signing.

Sub-processors and other recipients

These companies process data so that Para can run:

  • Microsoft: the firm’s own Microsoft 365, where its mail, calendars and any connected document library live, and Microsoft’s sign-in. Each connection is made on Microsoft’s own screens. Microsoft is the firm’s own vendor as much as ours.
  • Web hosting: the hosting provider that runs your firm’s workspace. It also runs our operations panel and order pages, keeps its own logs of requests to them (network address, the page asked for and the browser), and its mail system sends Para’s alert emails, our order and setup emails, and the sealed key copies to our staff.
  • Website hosting: the hosting provider that runs our public website. It holds demo requests, keeps its own logs of requests to the site, and its mail system sends demo requests to us.
  • Payments: Stripe, for firms that pay by card or bank account. It receives the signer’s email address, the order number, the plan, the price, a billing address and the payment details the payer enters on its page. No Firm Data.
  • Business email: the provider that runs our own business mailboxes. It holds signed orders, sealed key copies, our copies of alerts and weekly checks, demo requests and our mail with firms. A sealed key copy cannot be read without our safekeeping secret.

Others receive information only because a person at the firm chose it:

  • People invited to a calendar entry receive Microsoft’s invitation, with the entry’s title and time.
  • Owners can add up to ten addresses to receive security alerts.
  • A matter’s court, department and judge fields offer a link to search for that court’s rules. Following one opens a Google search carrying the court’s name, and the department or judge for those links.
  • Remote images in a message stay blocked until a person chooses to show them. Then the images load from the sender’s servers, which can tell that the message was opened.

We will tell firms at least 30 days before we add a sub-processor. Beyond these, we disclose Firm Data only to our own people who need it to run the service, and where the law compels us, as set out below.

How it is protected

The security page, which anyone can open at a firm’s Para address without signing in, sets this out in detail. In short:

  • HTTPS throughout, with browsers told to use nothing else for a year.
  • Every saved file, restore point, safety copy and weekly archive encrypted on the server, each file under its own key (AES-256-GCM).
  • Encrypted inside the database: the full text of every message; notes on matters, tasks and contacts; a calendar entry’s or trial’s notes, meeting link, meeting ID and passcode; and the records kept for Undo.
  • Not encrypted value by value: names, email addresses, phone numbers, subjects, Outlook’s preview line of each message, the To and Cc lists, a matter’s details, a deadline’s status note, waiting-for-a-reply notes, the note sent with a message passed to a teammate, matter request and hand-off notes, time-off and unavailability reasons, checklist items, and the activity log. These are protected by who can reach the server and its database.
  • Microsoft tokens and two-step secrets encrypted. Passwords and recovery codes kept only as one-way hashes, and of a passkey only its public half.
  • The encryption key kept apart from the database and from every backup of it, apart from the sealed copy we hold for recovery.
  • Four roles, each able to manage only those below it. Two-step sign-in, required for owners and admins on a new workspace. Optional office-only sign-in and computers-only access.
  • A brake on repeated wrong passwords that cannot lock anyone out of their own account. Sessions tied to the browser that opened them.
  • A hash-chained activity log that nobody can clear on a firm’s workspace.
  • Message content cleaned before display, and remote images blocked until a person asks for them.
  • Updates signed when they are built, checked file by file before they are installed, and tried on a workspace holding sample data before any firm’s.

Para has not been audited against SOC 2 or ISO 27001 by an outside firm. The security page lists Para’s current limits plainly.

How long it stays

Firm Data, while the workspace runs:

  • Mail sorted into a matter: until the firm removes it. It is the case file.
  • Mail deleted or set aside, outside any matter: on the firm’s own schedule, counted from when it was deleted or set aside: 30 days, 90 days, 180 days, a year, or keep everything, which is the default.
  • Mail deleted for good: kept encrypted for 30 days so an owner can bring it back, then removed. The activity log keeps its subject and sender’s address.
  • The full text of mail in no matter: cleared 30 days after it arrived. Who it was from and to, its subject, its date and its preview line stay, and opening it reads it from the mailbox again. Mail a person sorted into their own folders, and mail that cannot be read from Outlook again, keep their text.
  • Undo records: deleted items 30 days; a deleted matter 30 days, after which its files are deleted; the copy taken before an edit 1 day; a matter’s change history up to 90 days.
  • Restore points (the database only): five to seven daily ones, plus up to five an owner makes. Weekly full archives (the database and every saved file): the newest three. A safety copy taken before a restore is kept until the workspace is closed. Something deleted stays in these copies until they roll off.
  • The activity log and security alerts: for the life of the workspace.
  • Sign-in sessions: 30 days after last use. Failed sign-in attempts: one day. Addresses each person has signed in from: for as long as the account exists. Addresses turned away by office-only sign-in: for the life of the workspace.
  • The technical log: 30 days.
  • When an account is removed: its matters are unassigned; its unsorted mail, its own folders and their files, its sign-in records and the account itself are deleted; mail it sorted into matters stays. The activity log keeps the person’s name and sign-in addresses.

Customer and order data, and the website:

  • Orders, signed copies, payment records, and our panel’s activity log and session records: kept for as long as we need them to show what was agreed and paid. They have no automatic deletion today.
  • Alert copies, weekly checks and sealed key copies in our business mailboxes: no automatic deletion today.
  • Demo requests: until we delete them, which we do on request.
  • The website’s fingerprints of network addresses: about an hour.
  • Hosting logs: on our hosting provider’s own schedule, outside Para.

Para never deletes anything from a firm’s Outlook for good.

When a firm leaves

Ending a subscription does not delete anything by itself. A workspace is deleted when an owner closes it, in Settings, with their password.

Closing removes the firm from the workspace at once: the database is emptied of it and rebuilt, and that server can never set the workspace up again. The saved files, a safety copy taken at closing, the restore points, download copies and archives are kept for 30 days in case the close was a mistake, then deleted automatically, and the deletion is recorded. Technical log lines age out on their own 30-day schedule. Before closing, and at any time, an owner can download everything: the saved files in each matter’s folders, the owner’s own folders, the whole workspace record in a form any database tool reads, and a list of every file with a fingerprint to check it by.

Closing does not touch the firm’s Microsoft 365. Para’s calendars and the files in a connected library stay there for the firm to keep or remove, and the firm can withdraw Para’s access there at any time.

What stays with us: the signed order, payment records, the firm’s record in our panel, our activity log and the sealed copy of the workspace’s key. The sealed key copy is not deleted automatically. Once a firm has closed its workspace, it can ask us to destroy our copies, and we will confirm in writing when we have. On request, we will also confirm in writing when the workspace’s deletion is complete, including the removal of its install from our hosting.

Copies a firm has taken off the server are the firm’s to keep or destroy. Any backup our hosting provider keeps of its own servers follows that provider’s schedule.

Your choices and requests

If you have an account in a firm’s workspace, you can see every browser signed in to your account and sign any of them out. Your account belongs to your firm’s workspace, so ask your firm’s admins or owners to correct or remove it.

If your information is in a firm’s workspace because you are its client, its opposing party or someone who wrote to it, that information is the firm’s, and often part of a file the firm has professional and legal duties about. Send your request to the firm. If you send it to us, we will pass it on and help the firm answer, but we will not hand over, change or delete a firm’s data on someone else’s instruction.

If you signed an order with us or sent a demo request, write to order@yitzys.com to ask what we hold about you, to correct it, or to delete it where we are not required to keep it.

Where the law gives you rights over your information, such as the right to know, to correct, to delete, to a copy, or not to be treated differently for asking, we honor them for the information we decide about, and we help the firm honor them for Firm Data.

Requests from courts, regulators and law enforcement

If we are asked to hand over a firm’s data, we tell the firm first and give it the chance to respond, unless we are legally forbidden to. We disclose only what the request actually compels, and we refuse requests that do not compel it. A firm’s data in Para is very likely privileged, and we treat it that way.

If something goes wrong

If a security incident affects a firm’s data, we will tell the firm’s owners without undue delay, and in any case within 24 hours of confirming it, with what we know, what we are doing and what the firm should do. We will keep telling them as we learn more. The activity log, which nobody can clear, helps show what was reached and when.

California

For Firm Data we act as a service provider under the California Consumer Privacy Act. We process it only to perform the service for the firm, we do not sell or share it, we do not keep or use it for any other purpose, and we do not combine it with data from anywhere else. The firm is the business. For customer and order data and for website visitors, we act for ourselves, as described above. We have not sold or shared personal information in the preceding twelve months. We do not knowingly collect information from anyone under 16. Para is a tool for a law firm’s staff, not a consumer service.

Changes

If we make a material change to this policy, we will tell each firm at least 30 days before it takes effect, and we will post the new version with its effective date.

Contact

Write to order@yitzys.com, or to Para, Cali. We answer on business days, 9 am to 5 pm Pacific, with a first answer within one business day. You will get a straight answer, including when the answer is “not yet.”

See also the Terms of Service and Security & privacy.

Sign in

Download