Security & your data

Your clients trust you with sensitive information. You should be able to see how Fylely handles it before you upload a file. Here are the safeguards built into your workspace and the settings you control.

These controls are available on every plan, including the trial. This page describes our practices; Fylely does not claim an independent security audit or certification. What we do instead is in section 12: checks that run against the live service every day, and tests that fail if this page stops matching the code. For your firm's review, see our vendor review answers, data processing agreement, Privacy Policy, service providers, and deletion process.

1. Your firm's data is walled off

Matter, client, billing and document records are protected by row-level security in the database itself. Firm-scoped permissions control which records a signed-in user can read or change, and team roles restrict access within your firm.

2. Documents stay private

Uploaded documents live in a private storage bucket. Files are filed under the firm that owns them, and storage rules allow only that firm's team to read, add or remove them. Downloads use signed links that expire within five minutes: one minute for opening or downloading a matter document, and up to five for an export, a bundle of documents or an import file, so a copied link soon stops working. Clients send documents through single-purpose upload links that accept files for one request and cannot browse anything else.

3. Encryption

All traffic is encrypted in transit with TLS. Stored data, including the database and documents, is encrypted at rest by our infrastructure provider. See the sub-processors page for who hosts what.

4. Signing in

• Two-factor sign-in. Each person can enable an emailed six-digit code whenever a password is used from a browser we have not seen. No session is created until the code is entered. Codes expire after ten minutes and lock after five wrong attempts.
• A firm-wide requirement. The owner can require two-step sign-in for everyone, including future team members. People without an authenticator use an emailed code. This requirement is checked on protected server requests, database operations and document storage access.
• Authenticator apps. Instead of an emailed code, anyone can use a code from an authenticator app on their phone (the TOTP standard, RFC 6238), so the second step does not depend on their inbox. The app's secret is stored encrypted, a code is accepted only once, and ten single-use recovery codes — stored only as hashes — cover a lost phone. Removing the app requires one of its codes. The database itself refuses any session for the account that Fylely's own sign-in did not finish, including one opened by a password reset link or any other emailed link.
• Passkeys. Anyone can add a passkey and sign in with their device's own unlock (a fingerprint, a face or the device PIN) instead of a password and a code. The device keeps the private key; we store only the public half.
• Three-step sign-in. Anyone with a passkey can make it a third step: after the password and the code, every sign-in is confirmed with one of their passkeys. A remembered browser skips the code, never the passkey, and a passkey alone no longer signs that account in. The database itself refuses any session for the account that did not pass the passkey, including one opened by a password reset link. In Fylely, turning it on or off asks for one of the person's passkeys.
• Four-step sign-in. Anyone with an authenticator app and a passkey can ask for both kinds of code: every sign-in takes the password, an emailed code, a code from the app, and then a passkey. The two codes are checked together, a remembered browser skips nothing, and a recovery code can stand in for the app. It sits on top of three-step sign-in, so the database refuses any session that did not pass the passkey, and it can be turned on or off only by our servers, after one of the person's passkeys.
• Automatic sign-out. The firm owner can set everyone to be signed out after 15 minutes to 4 hours of inactivity, with a one-minute warning, so an unattended office computer does not leave client files open.
• Remembered browsers. We store only a one-way hash of the browser identifier and of sign-in codes, never the values themselves. Every remembered browser can be forgotten from Settings in one click.
• Breached passwords are refused. When you choose a password in Fylely, we check it against the Have I Been Pwned list of passwords exposed in breaches at other sites, along with a list of commonly used ones. Only the first five characters of a one-way hash leave our server, never the password, and the match is made on our side. If that service cannot be reached, the other rules still apply.
• Limits on guessing. Repeated wrong passwords lock sign-in for that account for 15 minutes, and wrong sign-in codes are capped across every code sent in an hour, not just per code. These limits are kept in the database, so they hold across all of our servers.
• Security alerts. We email you when your password is changed, two-factor sign-in is turned off, three- or four-step sign-in is turned on or off, or an authenticator app or a passkey is added or removed, so a change you did not make does not go unnoticed.
• What stays on a device. The only client information Fylely keeps for offline use is the Court day page, and only on a device where you turn that on, after being told what it holds. It is deleted when you sign out or turn it off; a copy older than 7 days is never shown and is deleted the next time Fylely opens. Separately, Ask keeps what you type into it in the browser: the conversation until you clear it or close the tab, and phrases you teach it until you clear them; signing out does not remove them. What the app keeps, and the Cookie Policy lists everything else.
• Device controls. Settings lists your browser sessions and lets you end another session or sign out all other devices. Revoked sessions lose access on their next protected request. Files already downloaded cannot be recalled; document download links already issued expire within five minutes. A password can only be changed from an emailed reset link used within 15 minutes, never from a signed-in session alone.

5. Knowing who did what

Changes to estate and guardianship records are written to an activity log by the database itself, so your firm can see who added or changed a deadline, hearing, asset, transaction, document or time entry, and when.

A separate security log records sign-ins and refused sign-ins, and changes to sign-in codes, authenticator apps, the team, share links, exports and connected accounts, with the time, IP address and browser. The firm owner can read it under Settings → Security activity. Database rules block changes and early deletion of these entries for 400 days. A daily check flags what looks wrong for us to review: repeated wrong passwords, a second factor turned off, or a whole-firm export.

6. What Fylely staff can see

Our operator console, the screen we use to run Fylely, has no page that shows a matter. It shows each firm's account details; counts, such as how many matters, deadlines and team members a firm has and when they were added; the security log; and what a firm sends us itself: support messages, bug reports and files sent to us for an import. An automated test lists every table the console reads and fails if one is added, so this paragraph cannot quietly go out of date.

The console needs each operator's own account, its password and a code from its authenticator app. Administrative changes are logged under that person's name, with protections against editing the log.

Our servers also hold a key that can read the whole database, because scheduled work such as reminder emails and the daily checks in section 12 needs it. The key is kept in server configuration and never sent to a browser. Today one person, Fylely's founder, has access to the accounts that hold it. We look at a firm's records only when the firm asks us to, for example to help with a support request or an import, to keep the service secure, or when the law requires it.

7. Sharing on your terms

New read-only matter links expire after 1, 7, 30 or 90 days, with seven days selected by default. You can preview the recipient view, replace a link or revoke it at any time. The firm owner can review all matter links and named recipients in Settings → External sharing. Older links with no expiry are clearly marked there. People you name on a matter sign in with a six-digit code sent to their own address, see only that matter, and can be removed one at a time. Their messages with your firm stay behind that sign-in: the email we send says only that a message is waiting, and messages cannot be edited or deleted from inside Fylely. Client invoice and upload links carry long random tokens and reveal only the one invoice or request they were made for. A beneficiary’s personal-items link works the same way: it shows the items still to be divided, what has been set aside for that person, and their own list, never anyone else’s, and its photo links expire within the hour.

8. Connected accounts

Fylely does not touch anyone's email or calendar unless a person at your firm connects their own account in Settings. Connecting Outlook lets us write your matter dates into that person's calendar, read messages in that mailbox so they can be filed against a matter, and send a message when that person asks us to. If that person also allows OneDrive, we can list and read their files so they can copy one into a matter; a file is copied only when they choose it. If they use Edit in Word, Microsoft grants us write access to their OneDrive; we use it only to place a copy of that document in a Fylely folder in their OneDrive and read it back. We do not change or delete their other files. Connecting Gmail lets us send a message from that address when that person asks us to, and nothing more: no reading the mailbox. Connecting Google Calendar, a separate choice, lets us write your matter dates into that person's calendar, keep them up to date and read back the events we wrote to see whether they were moved or deleted; we do not read their other events. Nothing is sent from a mailbox unless a person at your firm wrote that message and pressed Send, or pressed Schedule and chose the time for it. A scheduled message waits in Fylely until then, goes from their own Outlook at that time, and can be cancelled until it goes. Gmail cannot be scheduled.

A connection belongs to the person who made it, not to the firm. The access we hold is stored encrypted, is never visible to colleagues — including partners and administrators — and can be removed from Settings at any time, which deletes it. See the sub-processors page for what Microsoft and Google receive.

Text messages. The firm owner, and nobody else, can set up texting: with a number Fylely gets for the firm in a Twilio subaccount of its own, which no other firm can use and which only Fylely's servers can create, change or release, or by connecting the firm's own Twilio account. Either Auth Token (the subaccount's, or the firm's own) is stored encrypted, is never shown again to anyone, and is used only on our servers, to send a text someone at the firm chose to send and to check the signature on what Twilio sends back; connecting and disconnecting are written to the security log. A text goes only to a number the firm has recorded the client agreed to be texted at, never to a number Fylely has received a STOP from (Twilio refuses those as well), a read-only member cannot send one, and the number of texts a firm can send in an hour and in a day is limited. If the owner sets up replies, each firm's connection has its own address; a reply is accepted only with Twilio's signature made with that firm's own Auth Token (for a number from Fylely, the subaccount's or Fylely's own) over that exact address, and only for that connection's own number or Messaging Service. A repeated delivery is stored once, and Fylely never answers a text by itself.

API keys and webhooks. The firm owner, and nobody else, can make a key that lets the firm's own software read its matters, deadlines, contacts and invoices, or a webhook that tells an address the owner chooses when something happens. Both are off until the owner sets one up. A key can read and cannot change or delete the firm's records. Two more things are possible, each only if the owner allows that key to. It can add a new enquiry, which goes into the same queue as the intake form, for someone at the firm to review, and the firm it lands in is always the key's own. And it can add and remove webhooks of its own, so a tool such as Zapier can switch its events on and off: those follow the same rules as any webhook, are listed for the owner, and are removed when the key is revoked or stopped. A key is shown once and we keep only a fingerprint of it. Notes, messages, document contents and the trust ledger are not available through either. Webhooks go only to public https addresses, each delivery is signed, and every key or webhook made or removed, and every change to what a key may do, is written to the security log.

9. Artificial intelligence

Fylely sends your firm's information to an outside AI service only if the firm owner switches on Claude in Settings → AI. It is off for every firm until then. Ask, drafted replies, document descriptions and the performance review are worked out inside Fylely, from your own records and files, and send nothing anywhere whether Claude is on or off.

When Claude is on, a request goes to Anthropic, the company that makes Claude, only when someone at the firm asks. A question in Ask Claude sends the question and the records Claude reads to answer it: the matters, deadlines, contacts and invoice totals an API key can read, and, as far as the asking person's role allows, matter notes, family messages, the text of documents, time entries and trust balances, read with that person's own sign-in so the same access rules apply as on the page. A document marked privileged or internal is never read, nothing can be changed, and a read-only member cannot use Claude at all. Each answer links to the records it read. “Draft with Claude” sends that one family conversation, the matter's name and its coming hearings and deadlines. “Summarise” sends the text of that one document and its file name. “Fill from this document” sends the text of that one document and its file name, the same as a summary, and nothing it proposes is added to the file until a person ticks it and presses Add. “Write with Claude” sends what you typed and the matter's facts listed under its draft: the matter's details, the people on it (with an address only for the person written to), its coming hearings and deadlines and, on an estate, its accounts by institution and last four digits, its assets, claims and ledger totals, but never notes, documents or a full account number. “Suggest wording” in pre-bill review sends each flagged time entry's description, date and length, the matter's name, the first name of the person who logged it where Fylely holds one, and the titles and first lines of that day's records on the matter, never the hourly rate or the amount billed. “Describe the report you want” on Reports sends what the person typed and the list of report columns their role may use, never the firm's records; the report itself runs inside Fylely afterwards. An attendance note drafted with Claude in court or meeting mode sends the matter's name, that session's title and times, its notes and its transcript. By default Anthropic does not train its models on what businesses send it, and it deletes requests and answers within 30 days unless the law or its usage policy needs them kept longer. Switching Claude on or off is written to the security log. The services that handle your data, Anthropic among them, are listed on the sub-processors page.

If the firm owner connects an assistant of the firm's own choosing to Fylely's API (an MCP connection, signed in by the owner or using an API key), that assistant reads what a key may read, at the firm's request, and nothing is sent to it by Fylely otherwise. Only the owner can sign one in; its access lasts an hour at a time, it can be disconnected in Settings, and connecting or disconnecting it is written to the security log.

What you type into Ask is not sent to us either, unless a person turns on "Help improve Ask". Then only the questions Ask got wrong are sent, with names and figures removed, and they are deleted within 90 days. The firm owner can turn this off for everyone in Settings. The privacy policy sets out exactly what is sent.

10. Your data leaves with you

You can export everything from Settings at any time. Closing your account permanently deletes the firm and its active records and uploaded files. The deletion process explains exceptions for backups, retained security logs, legal obligations and copies already received by others.

11. Recovery and continuity

You can download your records and uploaded documents from Settings. Keep copies that meet your firm's own continuity needs. Our recovery process separates checking an encrypted backup upload from testing that its records and files can actually be restored in an isolated environment. We publish a completed restore check only after receiving its measured results. We do not promise a recovery time or a loss-free recovery window.

Backups today. Our database host, Supabase, takes daily backups only on its paid plans, and Fylely is on its free plan today; we are moving to a paid plan before launch. Our own nightly backup, encrypted and kept outside Supabase and Vercel, has failed every night since 1 October 2026. Until both are running, the only copies of your records are the ones you download.

If your plan ends. Your existing matters stay where they are and stay readable, and the export tools in Settings keep working without a paid plan. Opening new matters, inviting team members and importing need one.

If we ever stop offering Fylely. Our Terms commit us to emailing every account owner at least 30 days before the Service is switched off, with export available throughout.

We do not currently publish a completed restore check. An unconfigured workflow or a successful upload alone is not evidence of recoverability.

12. How we check our own work

Fylely has no audit certificate. Instead, the code checks itself every day, and you can check some of it yourself.

• Every day, against the live service. Our servers make the requests a signed-out stranger could make, to every table and view in our database and to the storage that holds client documents, and confirm that each one returns nothing. The same run confirms that every table has row-level security switched on, that no storage holding files is public, and that the site still sends its security headers. If any check fails, the result comes off this page and we are alerted. The latest result, with its date, is near the top of this page.
• On every change. We run checks before merging a change: a scan for passwords and keys left in the code, a check that no secret reaches a browser, an audit of the libraries the live service uses for known high-severity vulnerabilities, a type check, the full test suite and lint. The repository does not enforce them, and while our automated build service is unavailable we run them on our own machine. Changes reach the live service only when we start a release by hand.
• Tests that hold this page to the code. Several statements here are tested directly: how long security log entries are kept, the reporting address in our security.txt file, which tables our operator console reads, the 72-hour notice below, and the vendor review answers that restate this page. If the code changes so that one of them stops being true, the tests fail.

Check it yourself.

• Open any page with your browser's developer tools, or point a header scanner you trust at fylely.com. You should see HTTPS enforced (Strict-Transport-Security), framing limited to our own pages, content-type guessing turned off, and a Content-Security-Policy that lets pages run scripts only from Fylely itself and, when someone copies in a file, Google's and Dropbox's file pickers, and never through eval. The exceptions are deliberate: the intake form a firm embeds on its own website, and the Outlook and Word add-ins, which Outlook and Word show in a frame.
• Our reporting details are at /.well-known/security.txt, in the standard format (RFC 9116).
• Our API refuses a request that has no key: https://fylely.com/api/v1/me answers 401.

Recent security work.

13. If something goes wrong

If we find that someone without permission got into your firm's records, we will email your firm's account owner within 72 hours of confirming it. The email will say what we know at that point: what was reached, when, and what we have done about it. We will keep you updated as we learn more, so you can meet your own duties to your clients and your regulator. No system is perfectly secure, and we cannot promise absolute security, but we will tell you plainly what happened.

14. Reporting a concern

If you think your account has been compromised, or you have found a security issue, email cole@fylely.com. We will respond promptly. The same address is published in our security.txt file.

Researching in good faith. If you look for a security problem in good faith, testing only against an account of your own, not reading, changing or keeping anyone else's information, not disrupting the service, and giving us reasonable time to fix what you found before telling anyone else, we will not take legal action against you over that research.