← Laya

Privacy Policy

Last updated: 3 August 2026

This Privacy Policy explains how Laya.net (“Laya”, “we”, “us”) collects, uses, and protects information when you use Laya at laya.net and app.laya.net (the “Service”). We are the data controller for the information described here. Questions: privacy@laya.net.

Information we collect

  • Account information — your name, email address, a hashed password (we never store the plaintext), your username, and any avatar you set.
  • Sign-in identities — when you sign in with Google, Microsoft, Azure DevOps, Atlassian, or Slack, we receive a stable account identifier and your email from that provider to create or match your Laya account.
  • Workspace content — the workspaces, boards, issues, comments, docs, and files you create in Laya.
  • Connected tool data — if you connect Jira, Azure DevOps, monday.com, GitHub, or GitLab, we import and store a mirror of the issues, comments, and attachments on the boards you choose, so they appear and stay in sync inside Laya. This is a durable copy, not a temporary cache; it is what makes the board render and sync. Edits you make sync back using your own (or the connection owner’s) authorized token. When you disconnect a board, we delete our mirror of it.
  • Security records — sign-in and two-factor events (enrolment, failed challenges, recovery-code use), session records with the browser user-agent and the IP address the session started from, and your acceptance of these terms (which version, and when).
  • Customer records. Laya keeps a customer record about you in its own systems. It is created when you create an account and updated when you confirm your email address, change your display name, create a workspace, or join one. It holds your email address, your first and last name, the internal identifier of your Laya account, and a time we refresh whenever one of those events happens. Signing in through an emailed link refreshes it too, so for anyone who signs in that way it is in effect a record of when they last signed in. It also holds which workspaces you have joined, the role you held in each, and when you joined. If you later leave a workspace, we keep the record of your having been in it, along with the date you left. If someone invites you to a workspace, we create a record for the email address they typed at the moment the invitation is sent, whether or not you accept it and whether or not you already had a Laya account.
  • Email records. For every email we send you we keep a delivery record: the address, the subject line, which template produced it, when it was sent, whether the receiving mail server accepted it, and whether it bounced or was reported as spam. We store the values that were merged into the message, such as your first name, but not the message body, and never a sign-in link. If you unsubscribe or report a message as spam, we keep a record of that against your email address so we do not mail you again, and that record survives deletion of everything else, because it is the only thing that can keep the promise.
  • Usage & technical data — IP address, timestamps, and request logs. When the Service returns an error we store a diagnostic record that includes the signed-in user’s email address so we can tell whose problem it was. We keep these records; see Retention.
  • Website analytics. Only if you accept analytics cookies. See Cookies below. Email measurement is separate and is described there too.

A note on the customer records described above. Laya includes a customer relationship module, and it is not open to general use. A workspace that does not already have it switched on cannot switch it on: the setup controls are marked coming soon, and the server refuses the request behind them. Today it runs only in the workspaces Laya itself operates, and it is the records described above that live there. If you open the CRM section of Laya you can see what it does, but you cannot start setting it up. When we do open it to customers, a customer who switches it on becomes responsible for the contacts they load into it, and we will describe that relationship here before that happens.

Cookies & local storage

Strictly necessary — always on. Your session token, a cached copy of your own profile, and your theme preference are kept in your browser’s local storage under keys beginning “laya_”. During the pre-launch period a “laya_gate” cookie records that you passed the access gate; it is set on .laya.net so one unlock covers the marketing site and the app. None of these have an off switch, because the Service does not work without them.

Analytics — off unless you accept. Our public pages use Google Analytics 4 to count visits and see which pages get used: the marketing site, the Help Centre, and the sign-in and sign-up pages (so we can tell how many visitors go on to create an account). It does not run inside your workspace — once you are signed in, the pages you visit, your boards and your work items are never sent to Google. Google Analytics and its “_ga” cookies load only after you accept analytics on the consent banner; if you reject, ignore the banner, or your browser sends a Global Privacy Control or Do Not Track signal, it is never loaded. Your choice is stored locally under “laya_cookie_consent”. You can change it at any time: — or from the Legal column of the footer on laya.net. Withdrawing consent disables Google Analytics immediately and clears its cookies.

We do not use advertising cookies, we do not sell or share your data with advertisers, and we run no third-party tracking on our website beyond the analytics described above.

Email is different, and here is exactly how. Marketing email we send you contains a small invisible image and links that pass through Laya on their way to their destination. Together these tell us that a message was opened, roughly when, and which link was followed. Amazon SES, which delivers our mail, reports the same events to us. We record that an open or a click happened, when it happened, and which link it was. Amazon also sends us the IP address and browser details of whoever opened the message; we do not store either. Every marketing email carries an unsubscribe link and a preferences link in its footer.

Sign-in links and other service email are not tracked at all. On 3 August 2026 we removed open and click tracking from that stream. Those messages carry no tracking image, and their links are not rewritten or redirected. This matters most for the sign-in link itself, which should go straight from your inbox to Laya and nowhere else.

How we use information, and our legal bases

  • To provide, maintain, and sync the Service, including with the tools you connect — performance of our contract with you.
  • To authenticate you, operate two-factor authentication, prevent abuse, and keep records needed to investigate a security incident — legitimate interests in securing the Service, and our legal obligation to protect personal data.
  • To send you service email such as sign-in links, invitations, and account notices, which is performance of our contract with you.
  • To send you email about Laya itself, such as getting-started guidance and product news, which is our legitimate interest in helping you use a product you signed up for. We treat this as email you would reasonably expect from a service you joined, not as consent you gave us, because we do not ask you to tick a box for it. Every such message carries a one-click unsubscribe link, and unsubscribing stops it immediately and permanently. We do not send you email about anything other than Laya, and we never pass your address to another sender.
  • To measure use of our marketing site — consent, given through the cookie banner and withdrawable at any time.
  • To keep track of who our users are, which workspaces they belong to, and how our product is being taken up, which is our legitimate interest in running and improving a business. We use these records to understand and support our own users. They are not sold, rented, or shared for anyone else’s marketing.

We do not sell your data, we do not use your content to train AI models, and we do not make decisions about you by automated means that produce legal or similarly significant effects.

Service providers

We share data only with providers that help us run Laya, under their standard data processing terms:

  • Amazon Web Services (United States, us-east-1) — hosting, database, and file storage; and Amazon SES for sending email. Where a deployment is configured to use Resend instead, Resend delivers that email.
  • Google — Google Analytics on our public pages, including sign-in and sign-up but never inside your workspace (only with your consent), and Google sign-in if you use it.
  • Anthropic (United States) — powers the optional AI features, and receives only the content you choose to run them on. Laya’s AI provider is configurable; if we switch it to another provider (for example OpenAI) we will update this list before doing so.
  • KLIPY — the GIF search in Board Studio. We proxy your search term; your workspace content is not sent.
  • Atlassian (Jira), Microsoft (Azure DevOps and Microsoft sign-in), monday.com, GitHub, GitLab, and Slack — the integrations and sign-in providers you explicitly connect. Data flows to these only for the connections you set up.

Your rights

You have the right to access, correct, export, restrict, or erase your personal data, to object to processing based on our legitimate interests, and to complain to a supervisory authority (in the UK, the Information Commissioner’s Office). Depending on where you live you may have further rights under the UK GDPR, EU GDPR, or US state privacy laws.

  • See and correct your data — your profile, email address, and security settings are editable in the app under your account settings.
  • Deactivate your account yourself — the danger zone in your profile settings deactivates the account and signs you out everywhere. This is reversible and is not erasure; your data is retained until you ask us to erase it.
  • Export or erasure — email privacy@laya.net. There is no self-service delete button today; erasure is carried out by us on request. We respond within one month.

Data retention

We keep your data for as long as your account exists. There is no automatic expiry and no background job that deletes your content, your workspaces, or your history after a set period. Your boards, issues, comments and attachments are the service, and we do not quietly age them out. The same applies to the customer and email records described above. Contact records, workspace membership history including memberships you have ended, and delivery records for email we have sent you are kept indefinitely. We do not delete them on a schedule. When you ask us to erase your data these records are erased with the rest, apart from the unsubscribe and spam-report record described above, which has to outlive them in order to keep the promise it represents.

The same applies to your sign-in: we keep you signed in for as long as we technically can, and we do not expire sessions on a schedule to force you back through the login screen.

Deletion happens when you ask for it. Email privacy@laya.net and we will erase your personal data. We respond within one month. You can also ask for a copy of it at the same address.

Deleted accounts. When an account is deleted there is a 30-day recovery window during which it can be restored. After that, the account is anonymised in place rather than removed row by row: the display name becomes “Former user”, the email address and handle are replaced with non-identifying values, the avatar is deleted, and the stored password, two-factor secrets, passkeys, linked sign-in providers, sessions and security history are removed — so issues and comments the person authored keep a stable, anonymous author instead of breaking. Note that deactivating your own account does not start this clock; ask us to erase the account if that is what you want.

Two things outlive the rest. Our platform administration audit log is append-only and retained indefinitely, because it is the record of what our own staff did. Records of privacy requests are kept as proof that we handled them; the proof has to outlive the data it was about.

Security

Data is encrypted in transit, passwords are hashed, and credentials for connected tools are encrypted at rest and are never shown to us, exported, or included in any support tooling. Access between customers is strictly separated: no workspace can read another workspace’s data. Laya’s own staff can access customer data under the controls described in the next section. Two-factor authentication (passkeys or an authenticator app) is available on every account and, once enabled, is enforced at every sign-in route. No system is perfectly secure, but we work to protect your information.

Access by Laya staff

Laya is a small operation, and someone has to be able to answer “my board is broken” and “why did this fail”. We would rather tell you exactly what that involves than leave you to assume.

Who. Platform administration is limited to a short list of named accounts held in our deployment configuration. It is not a role that can be granted from inside the product, and an ordinary account cannot promote itself to it. Today that list has one person on it, the founder.

What we can see without entering your workspace. Our internal console shows us, across all workspaces: your account’s email address, name, and username; which workspaces you belong to and your role in each; when you signed up, and your sign-in sessions, including the browser each one used and the IP address it started from; workspaces and their names, plans, and owners; the names of boards; invitations, including the addresses that were invited; how much storage a workspace uses; which boards have public sharing switched on; and which external tools a workspace has connected. If you search our console for a specific issue reference, it will show that issue’s title. When Laya returns an error we keep a diagnostic record that includes the signed-in user’s email address, the request that failed, and the technical detail of the failure, and we can read those. We can also read your workspace’s own activity log.

What we cannot see this way. We do not see the contents of your work from the console: not issue descriptions, not comments, not documents, and not the contents of files you upload. We never see your password, which is stored only as a hash, and we never see your two-factor secrets or passkeys. We never see the credentials for tools you connect, and they are excluded from every export by design.

Support views, and the part you should know. When we need to understand a problem you have reported, we can open a support view: a temporary session that lets us see your workspace as one of its members sees it, including issue descriptions, comments, documents, and files. It is constrained in ways we think matter:

  • It is read-only. It cannot change anything in your workspace. This is enforced by refusing every request that is not a known-safe read, before it reaches the code that would act on it, rather than by a list of things we promise not to do.
  • It lasts at most fifteen minutes, enforced by the database itself, and it can be ended at any time.
  • It is tied to the one workspace it was opened for. It cannot be used to look at another workspace, even if the member we are viewing as belongs to one.
  • Opening one requires a second authentication factor and a written reason, and both are recorded in our own permanent, append-only administration log along with the workspace, the member, and the time.

The part we would rather say plainly than bury: a support view is deliberately invisible to you. It does not appear in your workspace’s activity log, and it does not show anyone as present on your boards. That is a decision we made so that support access does not appear in your records as though one of your own team had done something. The record of it exists in our administration log, not in yours. If you want to know whether we have ever opened your workspace, ask us at privacy@laya.net and we will tell you.

What we can change. With a second authentication factor, a written reason, and a permanent audit record for each, we can suspend or delete a workspace, transfer its ownership, change or remove its members, revoke a public share link, an API token, or a webhook, disable an automation, deactivate or delete an account, reset an account’s two-factor authentication, and sign an account out everywhere. We do these when they are needed to run the service, to act on your request, or to meet a legal obligation.

Exports. We can produce a full export of one workspace or of one person’s personal data, to answer a data request or to hand your data back to you. Both require a second authentication factor and a written reason, and both are recorded. A workspace export contains the workspace’s settings, its members and their email addresses, its boards, its issues including their titles and dates, the filenames and sizes of its attachments, its invitations, its activity log, and which external tools it has connected. It does not contain the contents of your files, and it contains no passwords, no two-factor secrets, no connector credentials, and no share links.

The record. Every action a Laya administrator takes is written to an administration log that can be added to but never edited or deleted, and it is kept indefinitely. It is the record of what we did, so it outlives the data it is about.

International transfers & children

Laya is operated from the United Kingdom, and data is processed in the United States (Amazon Web Services, US East). Where a provider processes personal data outside the UK, we rely on the transfer terms in that provider’s own data processing agreement — standard contractual clauses together with the UK International Data Transfer Addendum. Laya is not intended for children under 16.

Changes & contact

We may update this policy and will revise the date above. The data controller is Laya.net, 29 Highcroft, Waterlooville, PO8 0BT, United Kingdom. Contact: privacy@laya.net. See also our Terms of Service.