Legal
Privacy Policy
What we collect, why, and for how long. In brief: your email address, which you sign in with, and a record of who did what, which is your workspace's audit log. We use nothing for advertising.
1. Who this covers
This policy says how Assessly Pte. Ltd. (UEN 202613864N), trading as Forculus, handles personal data when you visit forculuslabs.tech, sign in to the dashboard at app.forculuslabs.tech, use the CLI or the API, or open an app someone has shared with you on forculuslabs-apps.tech.
We are a Singapore company, and Singapore's Personal Data Protection Act 2012 (the PDPA) applies to everything we do with personal data. Where the GDPR or the UK GDPR applies too, this policy covers what they require.
For the account data described below, we are the organisation responsible for it under the PDPA, and its controller under the GDPR. For the data inside our customers' apps, such as what an app stores about the people who use it, the customer who deployed the app is responsible for it. We are their data intermediary under the PDPA, and their processor under the GDPR, under the Data Processing Addendum. If you have a question about an app's data, ask the app's owner. The dashboard shows their email address to everyone the app is shared with.
You can write to our Data Protection Officer at dpo@forculuslabs.tech.
2. What we collect
Account
- Your email address. It is your identity on the platform: how you sign in, how apps are shared with you, and how you appear in audit logs. We don't collect a name unless you write one to us, or your workspace's identity provider sends one (see Workspaces and apps).
- Terms acceptance. Which version of the terms you accepted, and when.
Sign-in and sessions
- For every sign-in code we send and every session we create: the time, the IP address, the browser or CLI user agent, and the country the request came from, as Cloudflare reports it. Each session also records how it was made: by a code, with Google or Microsoft, or through your workspace's own identity provider. A browser session lasts 12 hours and a CLI session 30 days, and neither can be extended. You can see your active sessions in the dashboard and revoke any of them.
- Sign-in codes themselves are stored hashed, expire after ten minutes, and are deleted after use.
- If you add a passkey: its public key, an ID for it, the name you give it, the browser that added it, whether it can be synced to your other devices, and when it was added and last used. The private key stays on your device or in your password manager. We never receive your fingerprint, face or PIN.
- If you sign in with Google or Microsoft, we keep the provider's identifier for your account, which is its issuer and its account id, the email address the provider vouched for when your account was first linked, and when the link was last used. The provider tells us who you are. It never gives us your password.
- While a sign-in with Google, Microsoft or a workspace's identity provider is under way, we keep a hash of its state and the IP address it started from. It can be used for ten minutes at most.
- If you connect an AI client to an app: the client's name and addresses, the IP it registered from, which apps you let it use and when, and its tokens, stored hashed. Access tokens last an hour.
Workspaces and apps
- Workspace names and members.
- If a workspace signs its people in through its own identity provider, over SAML or OpenID Connect: the provider's settings, the domains the workspace has proved it holds, and a hash of each SAML answer already used, so that it can't be used twice. A client secret for the provider is encrypted and never shown back to a person.
- If a workspace's identity provider adds and removes its members over SCIM: what the provider sends about each person. That is their email address, the provider's own id for them, their name, given name and family name, whether they are active, and the groups they are in. The SCIM token itself is stored hashed.
- App names, addresses and versions.
- Each app's environment variables, names and values, which anyone who can edit the app can read.
- The names of secrets and where each is sent. A secret's value is encrypted and never shown back to a person.
- An app's public paths, and which provider signs the deliveries to each path that has a webhook verifier. The verifier's signing secret is encrypted and never shown back to a person.
- Bearer token names and when each was last used. The token itself is stored hashed.
- If an app deploys from GitHub: the repository, branch, and each run's id and commit.
- Which hosts each app sends requests to, how many each hour, and how many were refused for not being on the app's list of hosts. We count the host only, never the path, the headers or the body, and keep the counts for 90 days.
- A workspace's key for an AI provider (Anthropic, OpenAI, Gemini, Mistral, Groq, Cohere, Azure OpenAI or Amazon Bedrock), if an owner stores one, encrypted and never shown back to a person, the Azure resource or AWS region an Azure or Bedrock key is for, and what each app granted it has spent each month. Requests your apps send to those providers with the key pass through our outbound proxy. It reads only the usage counts in the provider's answer, to count the cost against the app's budget, and does not store the prompts, the answers or anything else in them.
- The lines your apps write to their logs, which Cloudflare keeps for us. Only the people who can change an app, and the workspace's owners and admins, can read them. If someone who can share an app sets up a log drain for it, we send its lines to the destination they chose, and hold them only until they are sent.
- The code and files you deploy, and the data your apps store, which we host on your instructions and do not read, except to look into a report of abuse or infringement about an app.
Audit log
- Every action on a workspace, such as a deploy, a share, a token or a change of settings, with who did it and when.
- Every request to an app: the time, the app, the path and method, the response status, and who the caller was. The caller is recorded as an email address, a token's id, or the webhook provider for a delivery whose signature the platform checked, with the identifier the provider gives that delivery where it gives one. Any other request to a public path is recorded with no caller. We also keep the IP address each request came from. The audit log the workspace sees doesn't show it. This is the audit log the workspace's owners and admins can see, and it is why the platform exists. From the same entries we count, for each person, app and day, how many visits and requests they made. The workspace's owners and admins see these counts as usage insights, and so do members the workspace gives a role that can view its audit log. An app's owners see that app's counts for the last 30 days, including who opened it and how often. The counts hold no address, path or device.
Usage
- For each app, by hour: its requests, the CPU time its code used, and the rows its database read and wrote, which Cloudflare reports to us. To measure CPU time, we briefly receive Cloudflare's record of each request to your Worker apps. It includes the request's headers, its address and your app's logs. Of that record, we keep only the CPU time and which app it was, and store and log nothing else from it.
Billing
- If a workspace is on a paid plan, we create a customer for it at Stripe, with the workspace owner's email address as the customer's email and the workspace's name as the customer's name. When someone pays at Stripe's checkout, the billing name they enter there replaces the workspace's name on the customer, so the invoices carry the name they gave, such as a business's own next to its tax ID. Stripe also collects your billing address, card details and tax information, including a VAT, GST or tax ID if you enter one. We never see the card number. We keep Stripe's customer and subscription identifiers, the plan, its status and the dates of the current billing month. We also keep the hourly counts we report to Stripe of requests, CPU time, database rows and database storage over the plan's limit. The allowances, and the charges past them, are worked out from those counts. Stripe issues and keeps the invoices. We keep a copy of each one's number, status, amounts, dates and its address at Stripe, so the Billing tab of an Enterprise contract can list them and our staff can see what was billed.
Support
- Emails you send us, and what we need to answer them.
- Copyright notices and counter-notices, and the contact details in them.
Status page updates
- If you subscribe to email updates from the status page, which needs no account: the email address you give, and whether you have confirmed it. For a day, a keyed one-way hash of that address and of the IP address the request came from, so we can limit how often anyone asks.
The website
- forculuslabs.tech itself sets no cookies and runs no analytics. Cloudflare, which serves it, keeps standard access logs for a short time for security and operations. Everything the pages load, the typefaces included, comes from forculuslabs.tech itself.
- Most of our emails show a small picture of Yun, our mascot, which your email app loads from forculuslabs.tech. It is the same picture at the same address in every email of its kind, with nothing in the address that names you or the email. Cloudflare's access logs note the request like any other, and we don't use it to tell whether, or which, email you opened.
We don't buy data about you, add to your profile from other sources, or track you across other sites.
3. Why, and on what basis
We collect, use and disclose personal data only for the purposes below. If we want to use it for a new purpose, we tell you first, and ask for your consent where the law needs it.
| Purpose | Data | Basis (PDPA) | Basis (GDPR) |
|---|---|---|---|
| Signing you in, and keeping your account yours | Email, sign-in metadata, sessions, links to a Google or Microsoft account | Deemed consent, since we need it to give you the Service you signed up for. Legitimate interests, in preventing account takeover | Performance of the contract. Our legitimate interest in preventing account takeover |
| Running the platform: deploying, serving and sharing apps | Workspace and app data, your content | Deemed consent, since we need it to give you the Service | Performance of the contract |
| Signing a workspace's people in through its own identity provider, and keeping its members in step with that provider over SCIM | What the workspace's provider sends us | Deemed consent, since the workspace asked for it | Performance of the contract. The customer's legitimate interest in managing who works in its workspace |
| The audit log: showing a workspace's owners and admins who did what | Audit events, request logs | We keep it for the workspace, as its data intermediary, under the DPA | We keep it for the workspace, as its processor, under the DPA |
| Usage insights: showing a workspace's owners and admins, members whose role can view the audit log, and each app's owners for their own app, who opens which app, and how often | Counts of visits and requests per person, app and day, made from the audit log | We keep them for the workspace, as its data intermediary, under the DPA | We keep them for the workspace, as its processor, under the DPA |
| Keeping our own record of account and workspace events: terms accepted, an account or workspace deleted, a workspace suspended | The event, when it happened and whose account it was | Deemed consent. Legitimate interests, in being able to show what was agreed and what happened | Our legitimate interest in being able to show what was agreed and what happened. Legal obligation |
| Letting an AI client you approve use an app as you | The client's details, which apps you let it use, its tokens | Deemed consent, since you asked to connect it | Performance of the contract |
| Deploying an app from GitHub | The repository, branch, and each run's id and commit | Deemed consent, since the app's owner set it up | Performance of the contract |
| Billing and tax | Billing records | Deemed consent. Required by Singapore tax and company law | Performance of the contract. Legal obligation under tax and accounting law |
| Emailing people who subscribed to the status page when we post an incident or schedule maintenance | The subscriber's email address | Consent: you confirm by opening the link we email you, and you can withdraw it from any of the emails | Consent, given and withdrawn the same way |
| Answering you | Support emails | Deemed consent, since you wrote to us for an answer | Performance of the contract. Legitimate interest |
| Security: detecting abuse, attacks and fraud, and reporting illegal content | Sign-in metadata, request logs, account details | Legitimate interests, in keeping the Service and its customers safe. Investigations, and disclosures the law requires | Legitimate interest in keeping the Service and its customers safe. Legal obligation |
| Handling copyright notices and counter-notices | The notice or counter-notice and the contact details in it | Legitimate interests, in keeping the protection the Copyright Act 2021 gives network service providers | Legitimate interest in keeping the protection the Copyright Act 2021 gives network service providers. Legal obligation |
| Telling a workspace's owners what is happening to it: a payment failing, the move to Free that follows, the Free request allowance running out, a suspension, audit-log entries about to be deleted | Owners' email addresses, and the workspace's plan, billing status and request counts | Deemed consent | Performance of the contract |
| Telling a workspace's owners that it was deleted, deleted for good or restored, and by whom, and telling you that your account was deleted and what became of the workspaces you owned | Owners' email addresses, the workspace's name and short name, the email address of the owner who made the change, and the names of the workspaces you owned | Deemed consent | Performance of the contract |
| Measuring and billing usage: requests, CPU time and database rows | Usage counts per app and hour, and Cloudflare's record of each request to a Worker app, received briefly and not stored | Deemed consent | Performance of the contract |
| Telling a workspace's owners about its usage: allowances, usage charges, the usage limit, an invoice during the billing month that failed, a credit | Owners' email addresses, and the workspace's plan and usage counts | Deemed consent | Performance of the contract |
| Understanding how the Service is used, so that we can improve it | Daily totals per workspace: counts and sums, never content | Business improvement | Legitimate interest in improving the Service |
| Telling you about changes to the Service, the terms or the prices | Deemed consent. Required by law where a change needs notice | Performance of the contract. Legal obligation |
Deemed consent means the PDPA treats you as agreeing, because you gave us the data for that purpose or we need it to provide what you asked for. Where we rely on legitimate interests under the PDPA, we have assessed that the benefit outweighs any adverse effect on you. You can ask us about that assessment.
We don't use your data for advertising, we don't send marketing email, and we don't make automated decisions about you that have legal or similarly significant effects. If we ever send marketing email, it will go only to people who agreed to get it, each one will have a working way to unsubscribe, and we will follow the Spam Control Act 2007 and the PDPA in sending it.
4. Cookies
The dashboard and the apps use four cookies, and all of them exist only to sign you in. None is used for tracking, and there are no third-party cookies.
| Cookie | Set by | What it does | Lasts |
|---|---|---|---|
__Host-forculus_session | app.forculuslabs.tech, and each app's own address once you open it | Your signed-in session. We sign it, and the platform checks the signature on every request. | 12 hours, or until you sign out or revoke it |
__Host-forculus_state | An app's address, during sign-in | Ties the redirect back from the dashboard to the browser that started it, so a sign-in link can't be replayed elsewhere. | Minutes. It is deleted once the sign-in completes |
__Host-forculus_signed_in | app.forculuslabs.tech, with your session | Holds only the number 1, so the dashboard's page can tell you are signed in without asking our servers. It says nothing about who you are and lets nobody in. | As long as your session. It is deleted when you sign out |
__Host-forculus_oauth | app.forculuslabs.tech, when you start signing in with an account at another provider | Ties the provider's answer to the browser that started the sign-in, so it can't be used from anywhere else. | 10 minutes at most. It is deleted once the sign-in completes or fails |
These cookies are strictly necessary to provide the service you asked for, so they need no consent banner. The website at forculuslabs.tech sets none. Apps deployed by our customers may set their own cookies, and those are the app owner's responsibility.
The Cookie Notice says the same on a page of its own.
5. Who we share it with
We share personal data only with:
- Our subprocessors: the providers that host the platform, store data, send and hold email, and take payment. The current list, with what each does and where, is on the Subprocessors page. Each is bound by a contract that limits what it may do with the data. We tell workspace owners 30 days before adding one.
- The people in your workspace. Your email address is visible to the other members of a workspace you belong to. If an app is shared with you, your email address is on its access list, which everyone in the app's workspace who can open the app can see. Your actions in a workspace and its apps are visible to that workspace's owners and admins, in the audit log. That is what the product does.
- Our own staff. A small number of our staff can see account information to run the service and help customers: your workspace's name, plan, billing status and usage totals, its members' email addresses and when they last signed in, and the names of its apps. They can't see your apps' code, data, logs, secrets or anything your apps store, and they can't sign in as you. Every time staff look up or change a workspace, we record who did it, when and why, and we keep that record for seven years. Changes staff make to your workspace also appear in its own audit log. To report on how the service is used, we keep daily totals per workspace (counts and sums, not content) under the workspace's ID. These stay after a workspace is deleted, but no longer name it or anyone in it.
- Authorities, in two cases. The first is when a law, a court order or a binding request obliges us to, and then only as far as it does. The second is when we report illegal content on the Service. That includes reporting child sexual abuse material to the Singapore Police Force and to the National Center for Missing & Exploited Children (NCMEC), with the account and app details the report needs. We may also report other illegal content on the Service to law enforcement, with the details they need to act on it. Where we are allowed to, and it puts no one at risk, we tell the affected customer first.
- The other side of a copyright complaint. If you send us a copyright notice, we send a copy, with your contact details, to the owners of the workspace it is about. If you send a counter-notice, we send a copy, with your name, address and phone number, to the person who sent the notice. The terms describe the process.
- A successor, if the business is sold or merged. The successor takes over this policy, and you are told.
We don't sell personal data, and we don't share it with advertisers or data brokers.
6. Where it is processed
The platform runs on Cloudflare's global network, so a request is handled at the Cloudflare location nearest the person making it. The control plane, which runs the dashboard and the API, runs on Cloudflare in the Asia-Pacific region. Its database, which holds accounts, workspaces and the recent audit log, is with Neon in AWS ap-southeast-1 (Singapore). Most audit-log entries older than 30 days are kept in Cloudflare R2 object storage, which Cloudflare is asked to keep in the Asia-Pacific region. Each app's database and files are made in the Cloudflare region nearest where the person who created the app was, as a hint Cloudflare follows where it can. They stay where they were made. Billing data is with Stripe in the United States. The platform's email, meaning sign-in codes, invitations, notices to workspace owners and status page updates, is sent through Resend from ap-northeast-1 (Tokyo), and Resend also processes it in the United States. The email you send us is held by Proton in Switzerland, Germany or Norway. The Subprocessors page has the detail.
When we send personal data out of Singapore, we do it as the PDPA's transfer limitation obligation and the Personal Data Protection Regulations 2021 require. Each recipient is bound by a legally enforceable contract to protect the data to a standard comparable to the PDPA.
Where data about people in the European Economic Area, the United Kingdom or Switzerland goes to a country without an adequacy decision, we rely on the Standard Contractual Clauses and the UK Addendum in each provider's data processing terms with Assessly Pte. Ltd., together with the safeguards in section 9. You can ask us for a copy of the clauses we have in place.
7. How long we keep it
We keep personal data only as long as a purpose in section 3, or a legal or business reason, needs it. After that we delete it or make it anonymous. The table says when that is.
| Data | Kept |
|---|---|
| Account (email, terms acceptance, links to a Google or Microsoft account) | Until you delete your account, then removed within 30 days |
| Sign-in codes | 10 minutes, or until used. The record that one was sent stays an hour longer, for rate limiting |
| Browser sessions and their metadata | Until they expire after 12 hours, or are revoked. The record of the session is kept for 30 days after it ends, for security |
| Passkeys | Until you remove them or delete your account |
| CLI sessions and their metadata | Until they expire after 30 days, or are revoked. The record of the session is kept for 90 days after it ends, for security |
| What a workspace's identity provider sends over SCIM | While the workspace exists, unless the provider removes the person first. It goes with the workspace's other records |
| Apps and your content (code, files, databases, containers) | Until the app or the workspace is deleted. We may keep a deleted app or workspace for up to 30 days so that it can be restored, and then delete it for good. Deleted for good, it is removed from Cloudflare at once. That is permanent, and nothing is restorable |
| The control plane's records of a deleted app | Its configuration, versions, sharing grants, secrets and environment variables are kept with the app while it can be restored, and removed when it is deleted for good. Its tokens are revoked at once. Its entries in the workspace's audit log, including the one that records the deletion, stay there. The workspace's owners and admins can still see them, and its owners can export them. They are deleted with the rest of the log, as below |
| The emails about a deleted or restored workspace, or a deleted account, while they wait to be sent | The email address, the workspace's name and who made the change until the email is sent, or until we stop trying after 3 days. Then only a one-way hash of the address and of who made the change, so nobody gets the same email twice or too many in a day, removed 30 days after the change. Once you delete your account, your address is taken out of the ones still waiting |
| The control plane's records of a deleted workspace (names, members, configuration, billing status) | 30 days after the deletion, then removed. While the workspace can be restored they come back with it. Once it is deleted for good they are kept only for accounting, and can't be restored |
| Audit log | 3 months on Free and Team, 12 months on Business and Enterprise, measured from the event, then deleted within two days. Most entries older than 30 days are kept in Cloudflare R2 object storage, which Cloudflare is asked to keep in the Asia-Pacific region, encrypted with a key that belongs to the workspace, and are shown, exported and deleted like the rest. After any change of plan, events older than the new plan's retention are deleted 30 days after the plan changed. A deleted workspace's log goes with its other records, 30 days after the deletion. A workspace owner can export it on every plan |
| Usage insights | As long as the audit log they are counted from, as above. An app's counts go when it is deleted for good |
| App logs: what your apps print, the exceptions they throw and a container's output | Kept by Cloudflare for 7 days, then deleted. They can be read back for 1 day on Free and 7 days on Team, Business and Enterprise |
| Log lines waiting to go to a log drain | Deleted once the destination takes them. A batch that fails for a day is kept up to 7 days so it can be sent again, then deleted |
| AI clients connected to an app | Access tokens last an hour, and a connection 30 days at most. Tokens are deleted a day after they end, and the record of a connection within 60 days of its end. A client nobody connects is deleted after a day, and any other 90 days after its last use, once no connection holds it |
| GitHub deploys | The repository and branch, until an owner changes them or the app is deleted. Each run's id and commit, a day after the run's 15-minute deploy credential ends |
| A hash of a webhook delivery's signature, on a verified public path, so a replayed copy can be refused | Deleted within an hour |
| Usage counts | While the workspace exists. They go with its other records |
| Billing records | 7 years after the transaction. Singapore's Income Tax Act 1947 and Companies Act 1967 require us to keep them for at least 5, and we keep them 2 years more for audits and disputes. Stripe keeps its own records under its policy |
| Support email | 2 years after the last message in the thread |
| Status page subscriptions | Until you unsubscribe, when we delete the address. An address never confirmed is deleted within an hour of its link expiring, 48 hours after we sent it. The hashes kept to limit asks are deleted after a day |
| Copyright notices and counter-notices | 3 years after the last notice about the same account, so that we can tell a repeat infringer |
| Security and access logs at the edge | Up to 30 days |
| Our own record of account and workspace events: terms accepted, an account or workspace deleted, a workspace suspended | 7 years, like billing records. Once you delete your account, your email address in these records, and in our log of your sign-ins and sessions, is replaced by a one-way hash of it |
| Backups of the control-plane database | Neon's point-in-time restore keeps up to 7 days of history. A deletion is gone from it within that time. The restore history is for disaster recovery, and is never used to restore a deleted workspace or app |
| Point-in-time history of each app's database | A Workers app's database is Cloudflare D1, which keeps a point-in-time history of the last 30 days. Cloudflare maintains it, it is always on and it cannot be switched off, so a row an app deletes or overwrites stays in that history for up to 30 days. A workspace owner can put the database back as it was at a moment in that history. Nothing else restores from it |
Where a legal hold, a dispute or an investigation requires it, we keep the relevant data for as long as that requires, and no longer. A report to the authorities, and what it covers, is kept for one year after we make it, or longer if the authorities ask us to keep it.
8. Your rights, and how to use them
Wherever you are, you can ask us what personal data we hold about you and how we have used or disclosed it in the past year, and ask us to correct or delete it. Under the PDPA, these are your rights of access and correction. If you are in the EEA, the UK, Switzerland or another place with similar law, you also have the rights to restrict or object to processing, to data portability, and to complain to your supervisory authority. You can do most of this yourself, straight away, in the dashboard:
- Access and portability. On every plan, a workspace owner can export the workspace as one JSON document from the workspace's Settings. It holds the workspace's configuration, members, sharing grants, the names of its tokens, secrets and environment variables, and the audit log the plan retains. Each app's database can be exported on its own, as SQL, from the dashboard or with
forculus db export. A static site is the files you uploaded. Your sessions are listed in the account menu. - Correction. Your email address is your identity, so it can't be edited in place. Sign in with the new address and move your workspaces across, or ask us. If your workspace's identity provider sent the data, correct it there, and the provider updates us. We make a reasonable effort to keep your data accurate and complete when we use it to make a decision about you or disclose it. When we correct your data, we also send the correction to any organisation we disclosed it to in the year before, unless it no longer needs it.
- Erasure. Delete an app from its page, or a workspace from its Settings, with a typed confirmation. We may keep a deleted app or workspace for up to 30 days so that it can be restored. To erase it at once, delete it for good: the dashboard offers that for a deleted app or workspace it keeps, and the CLI has
forculus app delete --for-good. Deletion for good is immediate and permanent. The app's data is removed from Cloudflare right away, and its records with it, except its entries in the workspace's audit log, which stay for the log's retention. Only the control plane's records of a deleted workspace linger, for 30 days for accounting, and they are never restorable, so export first. Deleting a workspace on a paid plan cancels its subscription at once, with no refund for the rest of the billing month. Delete your account from the account menu. Deleting it is refused while you are the sole owner of a workspace or of an app, and while the law requires us to keep the data of a workspace you are in, of one that shares an app with you, or of one you left or lost access to while we had to keep its data. While the law requires us to keep a workspace's data, as above, it and its apps can't be deleted. - Withdrawing consent. Where we rely on your consent, or on deemed consent, you can withdraw it at any time by writing to us. We act on a withdrawal within 10 business days, and tell you if it will take longer. Before we act on it, we tell you what withdrawing means. For status page emails, it means you get no more of them, and every one of them has a link to do that yourself. For the data we need to run your account, it means closing the account, because we can't provide the Service without it. Withdrawing doesn't undo what we did before, and doesn't stop us keeping what the law requires us to keep.
- Objection and restriction. Email us. The audit log is kept in the interest of the workspace whose apps you used. We will weigh your objection against that interest, and tell you what we decided and why.
For anything you can't do yourself, write to privacy@forculuslabs.tech from the address on your account, or to our Data Protection Officer at dpo@forculuslabs.tech. We answer within 30 days. If we need longer, we tell you within those 30 days when we will answer. We don't charge for it unless a request is plainly unfounded or repetitive.
If you are unhappy with our answer, you can complain to Singapore's Personal Data Protection Commission (PDPC), at pdpc.gov.sg. If you are in the EEA, the UK or Switzerland, you can also complain to the supervisory authority where you live. We would rather you told us first.
9. Security
The Security page says how the platform is built to protect your data: every app behind one door, signed identity on every request, row-level isolation between workspaces, secrets encrypted with a platform key, and revocation within a minute. Data is encrypted in transit, and the providers that store it encrypt it at rest. Our staff's access to production is limited to what operating the service needs, and is logged.
If we learn of a breach affecting your personal data, we tell you without undue delay, and the affected workspace owners within 72 hours of confirming it, with what we know and what we are doing about it.
For data we are responsible for, we also follow the PDPA's rules on data breaches. We assess a suspected breach quickly, and within 30 days of first learning of it. If it is likely to cause significant harm to the people it affects, or affects 500 or more people, we notify the PDPC as soon as we can, and no later than 3 calendar days after we find that it must be notified. If it is likely to cause you significant harm, we tell you directly, at the same time or soon after. For data inside a customer's app, we tell the customer, who then decides what to notify, as the DPA says.
10. Children
The Service is for businesses and professional use, and is not directed at children. We don't knowingly collect data about anyone under 18. If you think we have, tell us and we will delete it.
11. Changes
When this policy changes in a way that affects you, we email workspace owners at least 30 days before it takes effect, and the date at the top changes. Clarifications take effect when published.
12. Contact
Privacy questions and requests: privacy@forculuslabs.tech. Our Data Protection Officer: dpo@forculuslabs.tech. Everything else: support@forculuslabs.tech, or by post to the address above.