Terms of Service

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

These Terms govern a law firm’s use of Para. They are written to be read before signing: what each side gets, what each side owes, and what happens when something goes wrong. Where a point matters more to a law firm than to an ordinary software customer, such as privilege, the file, deadlines, or what happens to the data when the firm leaves, it is said in full.

1. The agreement

1.1 Parties. These Terms are between Para, the provider named on the Order (“Para”, “we”, “us”), and the firm named as the customer on the Order (“the firm”, “you”).

1.2 What makes the agreement. The Order, these Terms, Schedule 1 (Support and service commitments) and Schedule 2 (Data Processing Addendum) are together the whole agreement. Where they differ, the Order controls, then Schedule 2, then these Terms, then Schedule 1.

1.3 The Order. We issue each Order with its own number. It names the plan, the fee, any onboarding fee, the term, how the fees are paid, the workspace’s address and any special terms. It also names the version of these Terms it incorporates, with that version’s fingerprint (a SHA-256 hash of its words), so the words signed are the words kept. An Order stays open for 30 days from the day it is issued. If it is not signed by then, it closes. We send each Order as a link, and if we send a new link, the old one stops working.

1.4 Signing. The person signing reads the Order and these Terms in full, enters the firm’s legal name and address and their own name, title and email, and types their name as their signature. In doing so they confirm that they may sign for the firm, agree for the firm to the Order and these Terms, and agree to sign and receive them electronically. An electronic signature has the same effect as a handwritten one. The signed copy is one PDF: the Order, these Terms in full, and a certificate that records who signed, their title and email, when the Order was issued, opened and signed, the network address and browser it was signed from, and the fingerprints of what was signed. We email it to the signer and keep it encrypted. Anyone holding a copy can check on our verification page that it is unchanged.

1.5 Who accepts these Terms. The firm accepts these Terms by signing an Order. Its Authorized Users are not asked to accept them, and the firm is responsible for their use of Para under section 5.

1.6 This interim version, and changes. This version will be replaced after legal review, and we may change these Terms at other times. A signed Order keeps the version it was signed on until a new version applies to the firm under this section. We will send the firm any new version at least 30 days before it applies to the firm. It applies from the firm’s first renewal date that falls at least 30 days after that notice, unless the firm agrees in writing to an earlier date. A firm that does not accept it may end the agreement at that renewal by telling us before the renewal date, and leave with its data under section 10.4. Except where the law requires it, no change applies to the firm in the middle of a term without the firm’s written agreement.

2. Definitions

• Workspace. The firm’s own installation of Para at the address on the Order, with its own folder, database, settings file and encryption key.
• Owner. A person who holds the lead owner or co-owner role in the workspace.
• Authorized User. A person the firm gives an account: its staff, or a contractor working under its supervision and bound to the same obligations.
• Firm Data. Everything the firm or its Authorized Users put into Para or connect to it: matters, contacts, mail and its attachments, documents, deadlines, calendar entries, tasks, notes, accounts and the activity log. Firm Data includes information about the firm’s own clients and about third parties.
• Microsoft 365. The firm’s own Microsoft 365 organization, used under the firm’s own agreement with Microsoft.
• Service. Para as we make it available to the firm, including updates and support.
• Para staff. Our employees and contractors who run the Service, including through our operators’ console, the system we use to sign up, install, license and update workspaces.

3. The Service

3.1 What Para does. Para brings a firm’s Microsoft 365 mail into a workspace, sorts it into matters, and keeps each matter’s dates, tasks, contacts and documents in one place. It is a workflow and organization tool for a law firm’s own staff.

3.2 One firm, one workspace. Each firm has its own workspace, with its own folder, database, settings file and encryption key. No firm’s data is shared with another firm, and an account from another firm is refused. Workspaces run with our hosting provider (listed under Sub-processors), on hosting that serves more than one firm.

3.3 The Microsoft 365 connection. Each Authorized User connects their own mailbox through Microsoft’s own sign-in and consent screens. No Microsoft password reaches us. Every Microsoft connection a workspace makes, whether a mailbox, a calendar account or a document library, must belong to the same Microsoft organization. By default Para may read mail and read and write calendars. It reads only the Inbox and Sent Items, never Drafts, and it never asks for anyone’s Bcc line. A mailbox’s first connection brings in up to the last 180 days of that mail. Para never asks Microsoft for permission to send mail, so it cannot send or reply to a message as anyone. Microsoft 365 remains the firm’s system of record for mail, and Para holds a copy so it can sort it. Access can be withdrawn at any time, from Para or from Microsoft.

3.4 What Para may change in Microsoft 365. Para changes things in Microsoft 365 only in these ways:

• Its own calendar. Para keeps a calendar of its own, “Para - Case Dates”, in the firm’s connected Outlook, for the firm’s matter dates. If the firm turns it on (it is off by default), Para also keeps a “Para - My Dates” calendar in each person’s own mailbox.
• One calendar the firm chooses. An admin may choose one calendar for Para to read, either from their own Outlook or from a separate Microsoft account the firm connects for calendars only, which has no access to mail. Para changes an entry in that calendar only when a person edits it in Para, and only the details they changed.
• Calendar invitations. When a dated entry lists people under Assigned to, or addresses typed into its invite box, Para adds them to the Outlook entry as attendees. Microsoft then sends the invitation, and any update or cancellation, from the mailbox that holds the calendar, including to addresses outside the firm. An invitation carries the entry’s title, which names the matter, and its date and time. Nobody is invited to an entry whose date has passed or that is marked done.
• Acting in a person’s mailbox. Only if the firm turns it on and each person consents again in Microsoft, Para acts in that person’s own mailbox when they ask it to: it opens a forward in their Drafts folder for them to send themselves, or moves a message they chose to Junk Email. If the firm also turns on deleting in Outlook, a message deleted in Para moves to Deleted Items in the mailbox it came from.
• Case files. Only if the firm connects a document library, as described in section 3.5.

3.5 Case files in Microsoft 365. If the firm chooses, Para keeps its matters’ files in one document library in Microsoft 365 that the firm grants it. An admin grants that library once, in their own browser. The broader permission used to make the grant is not kept, and Para’s access afterward reaches that one library and nothing else. Para puts each matter’s files in that matter’s folder there, and renames, moves or sends to the library’s recycle bin what changes in Para. It also takes in what people add, save, rename, move or remove inside the matters’ folders, so the library and Para stay the same. A file a person puts in a matter’s folder becomes part of that matter’s file, so Para may move it, or send it to the recycle bin, when it is moved or removed in Para. Para may put back some changes made in the library, such as a file moved into another matter’s folder or out of every matter’s folder. Para takes in nothing from outside the matters’ folders. When many items are removed from the library at once, Para waits for an admin before removing them in Para. Files in a person’s own My folders are never sent to the library.

3.6 Updates. We improve Para and bring updates to every workspace. Each release is signed. Our console checks that signature and every file before it uses a release, and refuses one that has been changed or that carries a firm’s data or settings. A release is proved on a workspace that holds sample data only before it reaches any firm, and firms are then updated one at a time. For each firm, a restore point of the firm’s database is taken 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, and Para staff are told. An update replaces code. It does not move or replace the firm’s database, saved files or restore points, and it never changes the database in a way that stops the earlier release from running on it. We will not materially reduce the Service’s core functionality during a paid term. If we must, the firm may end the agreement for that reason and receive a refund of fees paid for the unused part of the term.

3.7 What Para staff may look at. We do not read a firm’s mail or matters. We access Firm Data only to do something the firm has asked us to do, to investigate a security incident or a fault the firm has reported, or where the law requires it. Access we make through the application is recorded in the firm’s own activity log like anyone else’s. Work done on the server itself, such as a restore, a move or a fault we are fixing, is not recorded there, which is why we will not do it without telling the firm, and why the firm can keep its own copy of the log off the server. Our operators’ console is built never to read a firm’s mail, matters, documents or people, and it never signs in as a firm’s user.

3.8 What Para staff receive without looking. To run the Service, we receive:

• The workspace’s health. Our console checks each workspace’s release, setup and license state, when mail last came in and when the last backup was taken, storage sizes and counts. This check carries no content from the workspace and no names of people.
• Copies of some security alerts. When sign-ins are paused or slowed, the workspace is set up, the lead owner role is handed over, the workspace is downloaded or restored, the activity log’s chain is broken, or saved files or stored text cannot be read, we receive a copy of the alert. Alerts about the server itself (the scheduled job, a restore point, space on the server, restore points that cannot be read, repeated errors) come to us alone. A copy names the firm, the role of the account involved but not the person, the time and a masked network address. It carries nothing from a matter or a message.
• The weekly check of the activity log’s seal.

3.9 Safekeeping of the firm’s encryption key. The firm’s encryption key is made for its workspace alone when the workspace is installed. It is kept in the workspace’s own settings file, never in its database and never in any backup. So that the firm’s data can be recovered if the server that runs it is lost, the workspace also seals a copy of its key to a safekeeping key of ours. We keep that sealed copy in our operators’ console and send it by email to Para staff, so it outlives any one server. The secret that opens it is held by us and is not stored on any server that runs Para or our console. This means we can recover the firm’s key and, with it, read the firm’s encrypted data. We will open the sealed copy only to restore the firm’s workspace at the firm’s request, or after the loss or failure of the server that runs it. We will tell the firm in writing before we do or, where that is not possible, as soon as we can. What happens to the sealed copy when the firm leaves is in section 10.4.

4. What Para is not

This section is the one a law firm should read twice.

4.1 Not legal advice, and not a lawyer. Para does not practice law and gives no legal advice. Nothing in the Service creates an attorney-client relationship between Para and anyone, and nothing in it is a substitute for a lawyer’s or a paralegal’s judgment.

4.2 Deadlines and calculated dates are aids, and the firm verifies them. Para’s deadline calculator, court-date handling and reminders help a team stay organized. They are not authority. Para ships no court rules: deadline presets are the firm’s own, and the calculator counts court days on the California state or federal court holiday calendar only, whichever the firm picks. The firm remains solely responsible for every deadline, filing and court date, and must verify each calculated date against the applicable rules and the court’s own calendar. Para says so at the foot of every page, for the same reason it is said here.

4.3 Not the system of record for mail. Microsoft 365 remains the firm’s system of record for mail. Para holds a synced copy so it can sort it.

4.4 The firm’s professional duties stay with the firm. Duties of competence, confidentiality, supervision, conflicts and file retention under the rules of professional conduct of every jurisdiction the firm practices in are the firm’s. Using Para neither transfers nor discharges any of them.

5. Accounts, access and acceptable use

5.1 Accounts. The firm decides who gets an account and at what level, and is responsible for what its Authorized Users do. Accounts are personal: one per person, never shared.

5.2 Setting up the workspace. When the Order is signed, and paid where it is paid by card, we install the workspace and email the signer a setup link. The link works once, for 30 days. Whoever opens it first sets up the workspace and becomes its first owner, so the firm must keep the link to the right person. If it is lost, or may have reached the wrong person before setup, tell us and we will make a new link, which stops the old one working. A new workspace requires two-step sign-in for owners and admins from the start. Its creation is recorded with the network address it came from, and we are told when it happens.

5.3 Keeping the workspace safe. The firm will keep its credentials confidential, remove accounts for people who leave, and use the protections Para provides where they fit its policy, such as required two-step sign-in, office-only sign-in and computers-only access. We will tell the firm about anything on our side that needs its attention.

5.4 Acceptable use. The firm will not resell the Service or provide it to another firm; use it for anyone other than the firm and its clients; reverse-engineer it, copy it, or build a competing product from it; use it, or let anyone use it, to copy its features, design or workflows for someone else; take content from it by automated means other than the exports Para provides; probe or attack it; or use it unlawfully. We welcome good-faith security testing of the firm’s own workspace: tell us first, and we will not treat it as a breach of these Terms.

5.5 Suspension. We may suspend access to the workspace, or to a single account, only where it is necessary to stop active harm: a compromised account, an attack in progress, or a legal requirement. We will tell the firm as soon as we can, and keep the suspension no wider and no longer than its cause. We never suspend access, hide data or lock the firm out for non-payment. The only effect of non-payment in the product is the one in section 8.3.

6. Firm Data

6.1 It is the firm’s. The firm owns all Firm Data. Nothing in these Terms transfers any right in it to us.

6.2 What we may do with it, and nothing else. The firm grants us only what it takes to run the Service for the firm: to host, store, transmit, back up, display and process Firm Data as the firm directs, and to do the things the firm asks for. That permission ends when the data is deleted under section 10.4.

6.3 What we will not do with it. We will not sell it, share it for anyone’s marketing, combine it with another firm’s data, or use it for any purpose other than running the Service for the firm. We will not use it to build aggregate products or benchmarks. This survives the end of the agreement.

6.4 Privilege and confidentiality. Firm Data is presumed confidential and privileged. We treat it that way, we do not intend and will not assert that our access waives any privilege or protection, and we will cooperate with the firm, at the firm’s expense, in asserting privilege against anyone who seeks the data from us.

6.5 Compelled disclosure. If the law compels us to disclose Firm Data, we will tell the firm first unless the law forbids it, give the firm the chance to seek protection, disclose only what is actually compelled, and object where an objection is available.

6.6 Security and incidents. We will keep the security measures described in Annex A and on the security page in the product, and will not materially weaken them during a term. We will tell the firm without undue delay, and in any case within 24 hours of confirming a security incident affecting its data, with what we know, what we are doing and what the firm should do. We will keep the firm updated as we learn more.

6.7 Getting it out, any time. At any time during the term, an owner can download everything in one .zip file, with no fee, no request to us and no notice period. The owner confirms with their own password. The file holds the saved files in each matter’s folders and the unsorted files, the owner’s own My folders, the whole workspace record as a SQLite database file that opens in any database tool, a README, and a list of every file with its SHA-256 fingerprint. It is built as it downloads, and no readable copy is left on the server. It leaves out files deleted but still within their 30-day Undo, restore points, the encryption key, other people’s My folders, and any file the server cannot read, which it lists. Each download is recorded in the activity log, the owners are emailed, and a copy of that alert comes to us without people’s names. The workspace record can be restored from that file in Settings, up to 200 MB. The firm can also export the activity log as a spreadsheet with each entry’s seal, each matter as a printable packet, the sorting map, the deadline presets, the calendar import list, each saved file, and a sorted message’s Outlook file.

7. Confidentiality

Each side will protect the other’s confidential information with at least the care it uses for its own, and use it only for this agreement. Firm Data is the firm’s confidential information. Para’s non-public documentation, security detail, pricing, and how the Service works beyond what we publish, including how it sorts mail and calculates dates, are ours. The usual exceptions apply: information already known, publicly available through no breach, independently developed, or received from someone free to disclose it. Disclosure compelled by law is handled under section 6.5. These obligations last three years after the agreement ends, and indefinitely for Firm Data.

8. Using Para: the license

8.1 The right to use. During the term, we grant the firm a non-exclusive, non-transferable right for its Authorized Users to use the Service for the firm’s own work, in its workspace at the address on the Order.

8.2 The license key. We give the workspace a signed license key that names the firm, the workspace’s address, the plan and the last day it runs. For a paid Order, it runs 35 days past the day the firm has paid through, so a renewal that arrives a little late changes nothing. For a pilot, it runs for the pilot’s months. The firm can read its own key. Only we can issue one.

8.3 A license never locks the firm out. While the license is valid, nothing is shown. In the 30 days before it ends, the firm’s owners and admins see a notice. If it has ended, owners and admins see a notice and everything keeps working. Only 45 days after the license ends does anything change, and then only one thing: new matters cannot be created. Mail keeps arriving and being sorted, dates keep counting, and every file stays readable and exportable. Nothing is deleted, hidden or locked. Renewing lifts it at once. A problem on our side with the license key is never held against the firm.

8.4 What stays ours. The Service, its software, its methods for sorting mail and calculating dates, its design and documentation, and everything we develop, including improvements made while serving the firm, are ours. The firm owns its Firm Data (section 6.1); otherwise no right passes to the firm except the right to use in section 8.1.

8.5 Suggestions. If the firm suggests an improvement, we may use it freely, without any obligation to the firm. Suggestions are never Firm Data, and using one never uses Firm Data.

9. Fees and payment

9.1 What is owed. The fees on the Order, in US dollars. Fees are priced per firm, and the Order sets no limit on the number of Authorized Users. Fees do not include sales, use or similar taxes. Where such a tax applies, the firm pays it, and it is added to the same charge or invoice as the fee it applies to. Taxes on our income are ours.

9.2 How fees are paid.

• Each period. The fee is charged for each period on the Order: monthly, or yearly in advance. A twenty-four-month Order is paid one year at a time in advance, at a price fixed for both years.
• Onboarding. An onboarding fee, where the Order has one, is charged once, with the first payment.
• By card or bank account. Paid at signing through Stripe, on Stripe’s own pages, and then automatically at each renewal. Card and bank details never reach us. A bank payment that is still clearing is not held against the firm. Where we offer it, the firm can change its card or see its invoices on Stripe’s billing page.
• By invoice. We invoice at signing and at each renewal, and each invoice is due within the number of days on the Order.

9.3 Changes to fees. Fees are fixed for the term on the Order, and for both years of a twenty-four-month Order. We may change them for a later renewal by written notice at least 30 days before that renewal date. A firm that does not accept the change may end the agreement at that renewal by telling us before the renewal date.

9.4 Late payment. An amount not paid when due may carry interest at 1% a month, or the highest rate the law allows if that is lower, from the due date until paid. Late payment never leads to suspension (section 5.5). Its only effect in the product is the one in section 8.3, and section 10.3 still applies.

9.5 Refunds. Fees are non-refundable except where these Terms say otherwise: sections 3.6, 10.3, 12.2 and 13.1, and section 5 of Schedule 2.

9.6 Pilots. A pilot Order has no fee and no onboarding fee. It runs for the months on the Order, from 1 to 12, starting on the day it is signed. It ends on its own at the end of that time: nothing is charged and nothing renews. To continue, the firm signs a paid Order, and before it signs we will agree with the firm how its pilot workspace carries over. If the firm does not continue, section 10.4 applies from the day the pilot ends.

10. Term and termination

10.1 Term and renewal. The term starts on the day the Order is signed and is the term on the Order: one month, renewing month to month; twelve months, renewing for twelve months at a time; or twenty-four months, with both years committed, then renewing for twelve months at a time. A pilot does not renew.

10.2 Ending at renewal. For a month-to-month Order, the firm may end the agreement at the end of the current month by telling us at any time before the next renewal date. For a twelve- or twenty-four-month Order, either side may end the agreement at the end of the current term by written notice at least 30 days before the renewal date. We give the firm at least 30 days’ notice in every case. A twenty-four-month Order cannot be ended for convenience before its 24 months are over. The firm gives notice by email to our address for notices (section 15.5). When a card subscription ends, we stop it with Stripe so that no further charge is taken, and confirm that in writing. Ending at renewal does not refund the current term.

10.3 Termination for cause. Either side may end the agreement on 30 days’ written notice of a material breach the other has not cured in that time, and either side may end it at once if the other becomes insolvent. If the firm ends the agreement for our uncured breach, we refund the fees paid for the unused part of the term.

10.4 What happens to the data.

• Getting it out. For 60 days after the agreement ends, the workspace stays available so the firm can download everything under section 6.7, and we will help if it asks.
• Closing. An owner can close the workspace at any time in Settings, by typing CLOSE and their own password. The firm’s data is removed from the database at once, and setup can never run again on that server. The saved files, the safety copy taken at closing, the restore points and the archives are kept for 30 days in case the close was a mistake, then deleted from the server automatically, and the deletion is recorded.
• If it is not closed. If the workspace has not been closed by the end of those 60 days, or sooner if the firm asks, we remove it ourselves: its folder, database, saved files, restore points, archives and settings file, including its encryption key, and its scheduled jobs.
• The sealed key copy. Within 30 days after the firm’s data is deleted, we also delete the sealed copy of its key that we hold (section 3.9), from our console and from Para staff’s email.
• Confirmation. We will confirm in writing when deletion is complete.
• What stays elsewhere. Closing does not touch the firm’s Microsoft 365. Para’s calendars and the files in the case-files library stay there for the firm to keep or remove, and the firm can withdraw Para’s access in Microsoft. Copies the firm has taken are its own. Backups our hosting provider keeps of its servers, if any, are outside our control and age out on that provider’s own schedule.
• Our own records. We keep the signed Order, our billing records and our record of the workspace (its name, address, license and update history) as business records. They hold no content from the workspace.

10.5 What survives. Sections 3.9, 6.1, 6.3, 6.4, 6.5, 7, 8.4, 8.5, 10.4, 12.3, 13, 14 and 15, and any fees already owed.

11. Availability and support

Support hours, response times, backups, recovery objectives and monitoring are in Schedule 1. Para runs on managed hosting, and we do not promise an uptime percentage unless the Order does. What we do promise in Schedule 1 is meant to be kept.

12. Warranties

12.1 Each side warrants that it may enter this agreement and will comply with the laws that apply to it.

12.2 We warrant that the Service will perform materially as described in our documentation and on the product’s own security page; that we will not materially weaken the security measures in Annex A during a term; and that we will use current methods to keep the Service free of malicious code. If the Service fails this warranty, tell us. We will fix it, and if we cannot within 30 days, the firm may end the agreement and receive a refund of fees paid for the unused part of the term. That is the firm’s exclusive remedy for a breach of this warranty.

12.3 Otherwise, as it is. Except as stated in section 12.2 and Schedule 2, the Service is provided as it is, and we disclaim all other warranties, express or implied, including merchantability, fitness for a particular purpose and non-infringement. We do not warrant that any date the Service calculates or displays is correct, timely or complete (see section 4.2), and the firm is responsible for verifying them.

13. Indemnities

13.1 Ours. We will defend the firm against a third-party claim that the Service as we provide it infringes a US patent, copyright or trademark or misappropriates a trade secret, and pay damages finally awarded or agreed in settlement. If the Service becomes, or we think it may become, the subject of such a claim, we may obtain the right to keep providing it, change it so it no longer infringes, or end the agreement and refund fees paid for the unused part of the term. This does not apply to a claim arising from Firm Data, from use in breach of these Terms, or from a combination with something we did not provide.

13.2 The firm’s. The firm will defend us against a third-party claim arising from Firm Data or from its use of the Service in breach of these Terms, and pay damages finally awarded or agreed in settlement.

13.3 How. The side seeking defense gives prompt notice, lets the other side control the defense, and cooperates reasonably at the defending side’s expense. Neither side settles a claim in a way that admits the other’s liability without its consent.

14. Limitation of liability

14.1 The cap. Except for the claims in section 14.3, each side’s total liability arising out of or relating to this agreement is limited to the fees the firm paid under this agreement in the 12 months before the claim arose.

14.2 No indirect damages. Except for the claims in section 14.3, neither side is liable for lost profits, lost revenue, lost business, or indirect, incidental, special, punitive or consequential damages, even if told they were possible.

14.3 What is not capped. Sections 14.1 and 14.2 do not apply to: a side’s indemnity obligations under section 13; a side’s breach of its confidentiality obligations under section 7, which cover Firm Data; a side’s gross negligence, willful misconduct or fraud; or the firm’s obligation to pay fees owed.

14.4 The bargain. These limits allocate risk between the parties and are reflected in the fees.

15. General

15.1 Third-party services. Microsoft 365, Stripe and our hosting provider are not under our control, and their own terms govern them. The firm uses Microsoft 365 under its own agreement with Microsoft. We are responsible for our sub-processors’ performance of what we have engaged them to do, as set out in Schedule 2.

15.2 Independent contractors. Nothing in this agreement makes a partnership, joint venture or agency.

15.3 Assignment. Neither side may assign this agreement without the other’s consent, except to a successor to its business or to substantially all of its assets, on notice.

15.4 Publicity. Neither side will use the other’s name or logo publicly without written consent. Consent for one use is not consent for another.

15.5 Notices. Notices under this agreement are in writing and take effect on delivery. Notices to us go by email to order@yitzys.com or to the address for notices on the Order. A notice of breach or termination to us also goes by post to Cali. Notices to the firm go by email to the signer’s address on the Order, or to another address the firm gives us in writing.

15.6 Force majeure. Neither side is liable for a delay caused by something genuinely outside its control. This does not excuse paying money owed, and it does not excuse our obligations in section 6.6.

15.7 Governing law and venue. The laws of the State of California govern this agreement, without regard to its conflict-of-laws rules. The state and federal courts located in California have exclusive jurisdiction over any dispute arising out of it, and both sides consent to that jurisdiction.

15.8 Entire agreement, severability and waiver. The Order, these Terms and the Schedules are the whole agreement and replace anything said before. If a provision is unenforceable, the rest stands. A right not exercised is not waived.

Schedule 1: Support and service commitments

What we commit to.

• Support by email, at the address shown at the foot of the security page in the firm’s workspace or at order@yitzys.com, on business days (Monday to Friday, except US federal holidays), from 9 am to 5 pm Pacific time.
• A first answer within one business day. For something that stops the firm working, such as nobody being able to sign in, mail no longer coming in, or data that appears to be missing, we make it our first priority and keep working on it during support hours until it is resolved or a workaround is in place.
• Daily restore points. The workspace takes an encrypted restore point of its database every day. The most recent 5 to 7 are kept. Restore points hold the workspace record, not saved files. An owner can also take a restore point at any time, and the newest 5 of those are kept.
• Weekly archives. Every week, a full archive holding the database and every saved file is encrypted as a whole, with the key left out, and the newest 3 are kept.
• Where they are kept. Restore points and archives are kept on the same server as the workspace.
• Restores. An owner can roll the workspace back to a restore point, or restore it from a backup file, behind their own password. A safety copy of the current state is taken first, and nothing is restored without one, so a restore can be undone. An automated test unpacks a real archive back into a working workspace, so recovery is tested rather than assumed.
• Recovery objectives. After a mistake or damaged data, we aim to restore service within one business day of the firm telling us, from the copies on the server, losing no more than about 24 hours of the workspace record and no more than 7 days of saved files. Those copies protect against mistakes and damage, not against the loss of the server itself. Recovery from the loss of the server depends on copies kept elsewhere and on the sealed key copy in section 3.9, and we do not promise a recovery point for it.
• Monitoring. The workspace watches what fails silently: the scheduled job, the daily restore point, mail coming in, space on the server, restore points that can no longer be opened, and repeated errors on the server. When one stops, we are told, once rather than on every retry: the server is ours to keep, so the firm is not emailed about it. When mail stops coming in for a mailbox, the firm’s owners are told, because reconnecting it is the firm’s to do.
• Updates. Made as described in section 3.6. An update does not sign anyone out. We tell the firm in advance of any change to how the product is used.
• Changes to sub-processors. We tell the firm at least 30 days before adding one (Schedule 2, section 5).

What we do not commit to unless the Order says so: an uptime percentage, support outside the hours above, on-site work, backup copies kept off the workspace’s server, or a server for the firm alone.

Schedule 2: Data Processing Addendum

This Schedule governs our processing of personal information contained in Firm Data. It applies whether or not any particular privacy law does, because a law firm’s counsel will ask the same questions either way.

1. Roles. The firm is the controller and, under the California Consumer Privacy Act, the business. We are its processor and service provider. We process personal information only to provide the Service, only on the firm’s documented instructions, of which these Terms and the Order are the standing set, and for no other purpose. We do not sell or share it, do not retain, use or disclose it outside the direct business relationship with the firm, and do not combine it with personal information from any other source.

2. What is processed. Subject matter and duration: providing Para for the term and the wind-down in section 10.4. Nature and purpose: hosting, syncing, sorting, storing, displaying and backing up a law firm’s matter and mail records so its staff can work them. Categories of individuals: the firm’s staff; its clients; opposing parties, counsel, witnesses, insurers, medical providers, and anyone else who corresponds with the firm or is named in a matter. Categories of personal information: identifiers and contact details; the content of correspondence and its attachments; matter, calendar and deadline information; staff information such as job titles, availability, time off and its reasons, and sign-in records with network addresses and browser labels; and whatever else the firm’s own practice carries, which in a personal-injury or insurance practice includes medical and financial information.

3. People. Everyone at Para with access is bound to confidentiality and is given access only where their work needs it.

4. Security. The measures in Annex A, which match the product’s own security page. We will not materially weaken them during a term, and we will keep them under review as the Service changes.

5. Sub-processors. The firm authorizes those in Annex B. We will give at least 30 days’ notice before adding one, and the firm may object on reasonable data-protection grounds. If we cannot resolve the objection, the firm may end the affected part of the Service and receive a refund of fees paid for the unused part of the term. We remain responsible for a sub-processor’s performance.

6. Helping the firm. We will help the firm, at reasonable cost where the work is substantial: to answer a request from an individual about their information; to assess the security of the processing; to notify a regulator or an individual after an incident; and to respond to a regulator.

7. Incidents. We give notice without undue delay, and in any case within 24 hours of confirming an incident affecting the firm’s personal information, with the facts we have, the categories and approximate numbers involved, the likely consequences, and what we are doing, updated as we learn more.

8. Deletion and return. As in section 10.4, with written confirmation.

9. Demonstrating compliance. We hold no third-party security certification today. We will make available what is needed to show these obligations are met: the security page, our answers to the firm’s security questionnaire, and the records we keep of each release. A firm may audit no more than once a year, on 30 days’ notice, at its own cost, during business hours, without disrupting the Service and without access to another firm’s data. A current third-party audit report, once we have one, satisfies this.

10. Where data is processed. On request, we will tell the firm which hosting provider runs its workspace and in which region. We will give the firm at least 30 days’ notice before moving its workspace to a different country, and put a lawful transfer mechanism in place first where one is needed. What the firm keeps in Microsoft 365 stays in its own Microsoft organization, under its agreement with Microsoft. The copies Para keeps are held in the workspace.

Annex A: Security measures

• Encryption in transit. HTTPS throughout. A page asked for over plain HTTP is redirected, a form sent over it is refused, and a one-year HSTS header tells browsers to use HTTPS only.
• Encryption of files. Every saved file, restore point, safety copy and archive is sealed with AES-256-GCM, each file under its own key derived from the workspace key, and checked piece by piece when it is read.
• Encryption inside the database. The full text of every message, the notes on matters, trials, calendar entries, tasks and firm contacts, task note threads, meeting links, IDs and passcodes, calendar import lists, and the records kept for Undo are sealed the same way.
• What is not encrypted field by field. Names, email addresses, phone numbers, subjects, each message’s To and Cc lists and preview line, a matter’s information sheet, short notes (a deadline’s status note, waiting-for-a-reply notes, the note on 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.
• Secrets. Microsoft tokens for mailboxes, the calendar account and the case-files library, and two-step secrets, are encrypted with the workspace key before they are written. Passwords are kept only as one-way hashes. Each person’s ten recovery codes are shown once, kept only as hashes, usable once each, and replaced as a set. Invitation and password-reset links work once, for 7 days by default, are stored only as a hash, and a newer link voids the older one.
• The workspace key. Made for that workspace alone, kept in its own settings file outside the web root, never stored in its database, and left out of every backup and archive. A sealed copy is held by us as described in section 3.9.
• Separation between firms. Each firm has its own folder, database, settings file and encryption key. An account from another firm is refused, and every Microsoft connection must belong to the firm’s own Microsoft organization.
• Roles. Four roles, lead owner, co-owner, admin and member, with a strict rule that nobody can manage someone at or above their own level. An owner or admin can view a teammate’s workspace only for someone below them; it is shown on screen and its start and end are recorded.
• Sign-in. Passwords of at least 10 characters with a number or symbol, not the person’s email and not a common password. Two-step sign-in, required for owners and admins on a new workspace and available for everyone, with a passkey counting as the second step. Optional office-only sign-in and computers-only access. The most consequential actions, such as downloading or restoring the workspace, ask for the person’s password again.
• Wrong-password brake. Repeated wrong passwords are slowed and paused, by connection and by account. A browser the account already uses is spared, and every pause lifts on its own, so it cannot lock a firm out.
• Sessions. Session cookies are HTTP-only, same-site and secure over HTTPS, and the session is renewed at every sign-in. A session is tied to the browser that opened it, a move to a new network asks for the password again, and a session ends after 14 idle hours, at the end of the firm’s day, when the browser closes, and on any password or two-step change. Each person can see every browser signed in to their account and sign any of them out.
• Activity log. A hash-chained record of who did what and when, so an entry edited, or removed from the middle, breaks the chain. On a firm’s workspace nobody can clear it. Its seal is re-checked every day, it exports in full with each entry’s seal, and it can be emailed weekly so a copy is kept off the server. Network addresses are recorded in full, shown masked, and can be revealed only by owners.
• Alerts. Owners are emailed when something needs a look, such as an account paused after wrong passwords, a password or two-step reset, a role change, the workspace downloaded or restored, a security setting loosened, or Outlook mail no longer coming in. An alert never carries anything from a matter or a message.
• Untrusted content. Mail is sanitized before it is shown, remote images stay blocked until a person chooses to load them, and hidden direction and control characters are stripped from names. Attachments are stored under internal identifiers outside the web root. Only PDFs and images (never SVG) preview in the browser, under a locked-down policy, and everything else downloads.
• Uploads. Every upload is checked, each saved file is capped at 40 MB, and an upload is refused when the server is low on space. Intake sheets and checklist files are read in memory and not kept, and a PDF that cannot be read is refused rather than guessed at.
• Browser protections. A content security policy that lets only the page’s own scripts run, each page load with its own one-time value, no framing by other sites, no content-type guessing, a strict referrer policy, cross-origin isolation, the camera, microphone, location, payment and USB features turned off, and pages that are not cached.
• No outside parties in the page. No analytics, trackers or third-party scripts. The application talks only to Microsoft, and the only email it sends itself is security alerts, through the hosting provider’s own mail server.
• Technical log. Failures on the server are written to a log kept apart from the workspace, with email addresses, keys, sealed values and document names stripped out, and kept 30 days.
• Health checks. The workspace’s public health answer is a status word and a time. Anything more needs a secret key.
• Releases. Every release is signed and checked file by file before use. It is proved on sample data first, rolled out one firm at a time, proved to be running and put back if it is not (section 3.6). Our console can compare a workspace’s code with the signed release it runs and name any file that was changed, removed or added.
• Para staff access. Para staff sign in to our operators’ console with a passkey, or with a password and a one-time code from an authenticator app. A password alone never signs anyone in, and each code works once. Sensitive actions need a fresh confirmation, and sessions end after a short idle time and after a set maximum length. Sign-ins, updates, license changes, staff changes, settings changes and every download of the sealed key copies are written to a hash-chained activity log. The console is built never to read a firm’s data and never signs in as a firm’s user.
• Testing. Before a release, we run an automated test suite that covers permissions, separation between firms, security behavior and recovery.
• Limits stated plainly. The current limits are stated on the security page rather than left to be discovered.

Annex B: Sub-processors

• Microsoft 365: Microsoft Corporation, for mail, calendars and, if the firm connects one, the case-files document library, in the firm’s own Microsoft organization, at the firm’s direction. Connected and revocable by the firm.
• Web hosting: the hosting provider that runs your firm’s workspace. Its mail server also carries the emails Para sends, including security alerts.
• Payments: Stripe, for card and bank payments, taken on Stripe’s own pages. It receives the signer’s email, the Order number, the plan and price, the billing address and the payment details the payer gives it, and no Firm Data.
• Business email: the provider of our own business mailbox. It receives the signed Order, our copies of some security alerts, and the sealed key copy described in section 3.9, and no other Firm Data.

No others.