Privacy Policy

Last updated: 10 November 2026

This Privacy Policy explains how LayaNet LTD (“Laya”, “we”, “us”), a company registered in England and Wales (company number 17430595), collects, uses, and protects information when you use Laya at laya.net and app.laya.net, and planningpoker.org, a planning poker site we also run (together, 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 remove a board, we delete our mirror of it; a disconnected Jira connection keeps its boards, paused, until you remove them.
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. If you answer “Product news and tips” on planningpoker.org, we also record your answer in it, with the fact that you gave it on planningpoker.org, and that refreshes the time too. 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.

SprintPoker for Azure DevOps

SprintPoker for Azure DevOps is our extension for Azure Boards. When it asks Laya something on a person’s behalf, such as whether their Azure DevOps organization is paired with a Laya workspace, or what is happening in a session shared between the two, its server passes us the Azure DevOps access token that the extension holds for that person. This section says what we do with that token and what we keep, including for people who never use laya.net themselves.

Your Azure DevOps token. Our servers present your token to Microsoft, from their own internet addresses rather than from your browser, to check who you are and that you belong to the organization, and, where it matters, whether you are a member or a guest there, whether you administer it, and whether you can see a project in it. These checks only read: we never use the token to change anything. We do not store the token or write it to our logs; we keep only a one-way fingerprint of it, in memory, for at most 10 minutes, so that we do not ask Microsoft again on every request. This happens whether or not your organization is paired.

What we keep. Your organization’s Azure DevOps identifier and name, and, once it is paired, the identifier of its Microsoft Entra directory. If you pair or disconnect your organization, or take part in a shared session, also your Azure DevOps user identifier and your name as Microsoft gives it to us. A shared session keeps its name and settings, its work items (each one’s number, title, type, state and current estimate), the votes and the final estimates. What you do in a shared session is recorded in the paired workspace’s activity log, as a workspace member’s actions are. When you pair or disconnect your organization, or delete, erase or change the sharing of a shared session from Azure DevOps, that record also holds the Microsoft Entra tenant, object and token identifiers of your sign-in, so that your organization can match it with its own records. We keep all of this with no set expiry. When a shared session is erased, we erase our copy and tell the extension’s server to erase its copies too.

AI hints. If an AI hint is asked for a work item in a shared session, our AI provider (see Service providers) receives the work item’s number and title and the name of the field being estimated, and not its description.

Approving a pairing on Laya. A workspace member who approves or restores a pairing on laya.net first confirms their own Azure DevOps access by signing in with Microsoft. We use that sign-in for the same checks, and keep no token from it unless the same sign-in also connects the workspace to Azure DevOps (see Connected tool data). We delete the record of the check a day later; the approval keeps the member’s Azure DevOps user identifier and name, and the workspace’s activity log records it with the Microsoft Entra identifiers of that sign-in.

Cookies & local storage

Strictly necessary, always on. Your session token and a cached copy of your own profile 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.

When you sign in or sign up with an account from another service, such as Google, Microsoft or Atlassian, a “laya_social_state” cookie ties the sign-in to the browser that started it, so a sign-in link cannot be finished in someone else’s browser. It lasts up to 10 minutes and is removed when you come back.
A “laya_social_exchange” cookie then does the same for the last step of that sign-in. It lasts up to 2 minutes and is removed once used.
When you join, or ask to join, a SprintPoker session as a guest without an account, a “laya_poker_guest” cookie holds your place in that one session, and your browser sends it only to that session. Your seat ends after 8 hours without use, you can read the session’s results for 7 days after it closes or until it is deleted, if that is sooner, and the cookie expires after 8 days. Leaving the session removes it.
When you start an idea on laya.net/build without an account, a “laya_build” cookie keeps the draft yours, so you can come back to it and keep it when you sign up. It is set on .laya.net so the page and the app both see it, lasts 30 days, and is removed when you claim the draft.
When you confirm your Azure DevOps access with Microsoft to approve or restore the pairing of an Azure DevOps organization with a workspace, a “laya_ado_l0_state” cookie ties that check to the browser that started it, so it cannot be finished in someone else’s browser. It lasts up to 15 minutes and is removed when you come back.

None of these have an off switch, because the Service does not work without them.

Preferences you set. If you pick a theme, a “laya_theme” cookie remembers your choice for a year, and your browser’s local storage keeps a copy. It is set on .laya.net so the marketing site and the app look the same.

Analytics: off unless you accept. Our public pages use Google Analytics 4 to count visits and see which pages get used: the marketing site and the Help Centre. 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 or ignore the banner, it is never loaded, and a Global Privacy Control or Do Not Track signal from your browser counts as a refusal unless you turn analytics on yourself. 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.

planningpoker.org. planningpoker.org has its own cookie banner and its own Google Analytics, counted separately from laya.net’s, and a choice made on one site does not apply on the other. There it counts visits only to the public pages, such as the home page, the guides and the glossary, and what is done on them: how long you spend on a page, whether you scroll to its end, which links to other sites and which files you open, and which of the site’s buttons you press, such as Start a session. It never records a session’s pages, its links, the sign-in pages or anything you type. With each of these Google receives a random identifier kept in its “_ga” cookies, your browser and its language and version, your operating system and type of device, your screen size, and your IP address, from which it estimates a rough location. The page addresses it sends carry no query, apart from the campaign tags a link may carry (such as utm_source), and the page you came from is cut to the name of its site. It loads only if you accept it on planningpoker.org, and a Global Privacy Control or Do Not Track signal counts as a refusal unless you turn analytics on yourself. Your choice is stored locally under “ppo_cookie_consent”, and you can change it from Cookie settings in planningpoker.org’s footer; withdrawing it disables Google Analytics there and clears its cookies. Strictly necessary storage on planningpoker.org holds your sign-in and a cached copy of your profile when you sign in with Laya, your display preferences, the team workspace you last chose, short-lived records while a sign-in is in progress, and your reading position for the Back button. In a guest session a cookie holds your seat: it is sent only to that one session, the page’s scripts cannot read it, and it stops working when the session is deleted. If you start a guest session, a second cookie shows that this browser started it, so that only you can keep it in a Laya.net workspace: it is sent only to planningpoker.org, the page’s scripts cannot read it, and it is cleared when you keep or delete the session, and in any case ends 26 hours after you started it.

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 run guest sessions on planningpoker.org and stop them being misused, including the human check and the limits per network described in Guest sessions on planningpoker.org, which is our legitimate interest in offering a free planning poker site that works and is not abused. For the host who starts a session, it is also performance of our contract with you under our Terms.
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. When you create an account with your email address, you can tick “No thanks, don’t send me product news and tips” and we will not send it. You can also turn off “Product news and tips” when you first open Laya or planningpoker.org, or at any time in your account settings, under Notifications. Every such message also 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 and of planningpoker.org’s public pages, which is based on your consent, given through each site’s 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): 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 and on planningpoker.org’s public pages, but never inside your workspace or in a planningpoker.org session (only with your consent), and Google sign-in if you use it.
Cloudflare (Cloudflare, Inc.; processing in the United States and other countries) runs Turnstile, the check that tells people from automated programs, on our sign-up page, on the form a guest without an account uses to join, or ask to join, a SprintPoker session, and when someone starts a guest session on planningpoker.org. It receives the visitor’s IP address. On the sign-up page and the join form the check runs as soon as they are on screen, whether or not the visitor then signs up or joins.
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.
OpenAI (OpenAI Ireland Limited; processing in the United States): grades how ready a Jira work item is to estimate when a workspace member runs a SprintPoker Ready or Not scan of a Jira project. It receives the work item’s text and status fields, never its assignee, reporter or creator, and no account ID, name or email field.
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, and for the Azure DevOps checks described above.

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. Amazon SES, which delivers our mail, also keeps an address on its suppression list if a message to it bounced permanently or was reported as spam, so we do not email that address again; erasing your account does not remove that entry. Working copies we keep only to sync a change between your tools lose their issue text once used; your content itself is unchanged. Guest sessions on planningpoker.org, which belong to no account, are the exception: see Guest sessions on planningpoker.org below.

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. Signing in to planningpoker.org with your Laya.net account (Sign in with Laya) is the exception. That sign-in lasts 30 days at most, and it ends sooner if the Laya.net sign-in behind it ends: signing out of Laya.net in that browser also signs you out of planningpoker.org. It is listed on the Security page of your Laya.net account, where you can end it.

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.

Guest sessions on planningpoker.org

planningpoker.org is a planning poker site run by LayaNet LTD, and this policy covers it. Anyone can start a session there without an account and share its link (a “guest session”). Unlike work kept in a Laya workspace, a guest session is deleted on a schedule.

What it holds. The session’s name and settings; the items typed into it, with any descriptions; the names the host and the guests type in; and everyone’s votes, notes and final estimates. It also holds what keeps it running: who is connected, and a hashed copy of each browser’s key to its seat. We do not ask for an email address or an account, and the names the host and the guests type in cannot contain an @ sign. The session itself does not record anyone’s IP address (our request logs do: see below). Anyone with the link can see the session’s name and the host’s name, and the session’s pages are kept out of search engines.

How long it is kept. We delete a guest session 24 hours after it was started. If people are still in it then, we wait until it has been empty for 10 minutes, and we delete it no later than 26 hours after it was started. Deleting it removes everything listed above. The host can also delete it sooner. As with anything deleted from Laya, a copy can stay in our database backups until they are replaced in their normal cycle.

What stays afterwards. Counts and statistics that name nobody, such as how many guest sessions were started, kept or deleted each day. They hold no session name, no name anyone typed, no item and no vote. Nothing about a guest session is written to a customer record or to a workspace’s activity log. If our staff look a guest session up, or delete it after a report of misuse, our administration logs record that with the session’s identifier (see Access by Laya staff).

The human check. To tell people from automated programs, starting a guest session and joining one go through Cloudflare Turnstile. Cloudflare receives your IP address when your browser runs the check, and we send it your IP address again when we confirm the result with Cloudflare.

Limits per network. To stop one network starting too many sessions, we count the sessions started from each IP address and from the network it belongs to. Each count is kept under a key made from the address with a one-way function that changes every day, so the address itself is not stored, and we delete these keys after two days. Each guest session also keeps a key made from the network it was started from with a one-way function, so that we can limit how many sessions started from one network exist at a time, and how many people are active in them, across our servers and after a restart; the session keeps neither the address nor the network itself, and the key is deleted with the session.

Request logs. Like every request to Laya, the requests a guest session makes are written to our request logs, which record the IP address each request came from and the address it asked for, which includes the session’s identifier. We keep request logs for 30 days, then they are deleted automatically, and they are not deleted with the session.

If the host keeps the session. A host who signs in with Laya can keep a guest session. Keeping it moves the whole session, with everyone’s names, votes and notes, into a Laya.net team workspace the host chooses or creates. From then on it is that workspace’s content: it is kept like the workspace’s other work instead of being deleted after 24 hours, the workspace decides who can see it and when it is deleted, and the terms that cover that workspace apply to it. Everyone is told this before they type their name to join a guest session, and the people in the room are told when it happens.

Who is responsible for it. Until a guest session is kept, LayaNet LTD is its data controller. Once it is kept, the workspace is, and we hold the session for the workspace.

While a guest session exists, our staff can see it in our console like any SprintPoker session (see Access by Laya staff).

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 Laya.net sign-in route. planningpoker.org does not ask for your second factor again: Sign in with Laya relies on your Laya.net sign-in in the same browser, which asked for it if two-factor was on when you signed in. 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 reaches us from our Jira apps. The same console shows what Laya holds from its two Jira apps, Laya Board for Jira and SprintPoker for Jira, and from the service that runs SprintPoker for Jira: which Jira sites use which app, the address and identifier of each site, who connected it, which workspace it is connected to and whether that connection works; and, for SprintPoker sessions held on Laya, each session’s name, the keys of its items and their final estimates, and who took part in them: Laya members by name and email address, Jira users by the Atlassian account identifier and name SprintPoker received for them, and guests by the name they typed when they joined. The console may also show anything else we keep about those sessions, such as their items’ titles, the votes and the comments. SprintPoker does not receive Jira users’ email addresses, so we cannot see them, and someone whose Atlassian account has been closed is shown only as a former Jira user. From the service that runs SprintPoker for Jira we see counts of sessions and, when we look up one Jira site, when its sessions ran and who took part in them (by Atlassian account identifier and name). We may also see anything that service keeps about a session, such as its name, its issues, the votes, final estimates and comments. We look that up when we need it and do not keep a copy. We use all of this for the reasons this section began with: to answer support requests, to keep the service secure and running, and to be able to trace what happened. We may also use figures about whole companies from it, never about one person, for our sales and marketing.

What reaches us from SprintPoker for Azure DevOps. For a session shared with the extension, the console’s SprintPoker pages also show the Azure DevOps users who took part, by the name we hold for them. They may also show each person’s Azure DevOps user identifier and the identifier of their Azure DevOps organization. The console’s Azure DevOps apps page shows each Azure DevOps organization we have checked, by identifier and name: which workspace it is paired with and whether that works, which versions of the extension its people use, and counts of its sessions, saves and refused requests. It names no person. Opening that page is recorded in the same way, as described next.

We record when we look. Opening the console’s SprintPoker pages or its Jira apps page is itself recorded: which administrator, which page, with which filters, about which workspace or site, and when. We keep that record for 13 months. Exporting a list from those pages that names people needs a second authentication factor and a written reason, and the export is written to our administration 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. The exception is the estimation sessions described above: the console may show what we keep about them. 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, United States). 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 LayaNet LTD (company number 17430595), whose registered office is at 29 Riverside Walk, Wickford, England, SS12 0DU. Contact: privacy@laya.net. See also our Terms of Service.