Privacy Notice

1. Who we are & how to contact us

Clavis operates Stasis. For any privacy question, or to exercise your rights, contact our data-protection contact at [email protected].

Since its 2024 amendment, the PDPA requires organisations whose processing crosses the volume thresholds in the Commissioner's guidelines to appoint a data protection officer. At our current size we are below those thresholds, so the law does not yet require an appointment. The address above still reaches one responsible person: it forwards directly to the founder, who handles every privacy request personally. If our processing grows past the thresholds, we will appoint a data protection officer and register them with the Commissioner as the guidelines require.

2. The two roles we play

Stasis handles personal data in two distinct roles, in the terms the amended PDPA itself uses. Since the 2024 amendment the Act says "data controller" where it previously said "data user", and it places obligations on data processors directly.

• As a data controller · for the account and contact data of the people who sign up, subscribe and administer a workspace (for example an owner's name, email and billing details). We decide how this data is used.
• As a data processor · for the personal data our customers put into their workspace about their own staff (names, work emails, roles, schedules, leave, task notes and related work data). The customer is the controller of that data; we process it on the customer's behalf and on their instructions. Since the 2024 amendment the PDPA's Security Principle binds data processors directly, so protecting this data is our own statutory duty as well as a contractual one. Our commitments as processor are set out in our Data Processing Addendum.

3. What we collect

• Account & contact data · name, email, company name, role, and login credentials (passwords are stored only as salted hashes by our authentication provider).
• Billing data · subscription plan, billing cycle and seat counts, and the invoices and receipts we issue for them. Each issued document records the workspace name, the amounts and any tax, the payment method used and the address it was emailed to. Card details are handled by our payment processor and are never stored on our servers.
• Customer workspace data · the staff and work data a customer enters (see the processor role above).
• How long a task took · Stasis never asks anyone to log hours. Instead, when a person starts a task and later submits it, the service records the time between those two actions, capped at three times the original estimate and left blank entirely for anything under fifteen minutes. It is a cycle-time figure rather than measured effort: the span includes lunch, meetings, waiting on a client and any other work done in between. Owners, managers and HR can see it; nobody else can, including the person it was measured from. It is used to price completed work against the workspace's own rates, to show past utilisation, and to propose a correction to a template's estimate, which a manager has to approve before anything changes.
• Client contact data · when a customer records a client in their workspace, they can add the people they deal with there: name, email address, phone number, job title, and which one is the main contact. The customer decides what to enter, so we hold this as processor, on the same terms as the rest of their workspace.
• Push notification registrations · if you switch browser notifications on, your browser issues a delivery address for that one browser plus the two keys used to encrypt a message to it, and we store those so a notification can be sent. Turning notifications off in the app deletes the entry, and so does deleting the workspace.
• Waitlist entries · if you ask for early access, we keep your name, work email, company, team size, whatever you told us you were struggling with, and which link you arrived through. We use it to email you about Stasis. That is marketing rather than service email, so every message carries a one-click unsubscribe, and using it stops all of them.
• Usage & technical data · logs, device and browser information, and security events needed to run and protect the service.
• Data kept in your browser · your sign-in session and a few display preferences are stored on your own device rather than collected by us. We set no cookies. Section 4 lists everything and why it is there.

4. Cookies and local storage

Stasis sets no cookies. Not on the marketing site, not inside the app, and none belonging to an advertiser or an analytics network. That is why you are never asked to accept or decline any.

What the service does use is your browser's own local and session storage. These entries sit on your device, are readable only by Stasis itself, and are not sent automatically with every request the way a cookie is. Everything we keep there falls into five groups:

• Keeping you signed in · when you log in, our authentication provider stores your session token under a key beginning sb-. Remove it and you are signed out; without it the service cannot work at all.
• Remembering how you like the app · your light or dark choice (stasis-theme), the Simple or Comprehensive view (stasis-simple-mode), and small pieces of view state such as which sidebar groups and lists you left open and which setup tips you have already dismissed.
• The interactive demo · the sample workspace runs on two keys (stasis-demo-mode and stasis-demo-role) held in session storage, so it is scoped to that browser tab, disappears when you close it, and can never mix with a real signed-in account.
• Getting your signup right · a referral or plan tag on the link you arrived through (stasis-ref, stasis-pending-plan) is held so the plan you picked survives the move to the app and so we can tell a referred signup from a direct one.
• Carrying a step across a round trip · when something you started has to leave the site and come back, the part we would otherwise lose is held briefly. The workspace name you typed before signing in with Google or Microsoft (stasis-pending-company) waits up to an hour, so your workspace is not created under a placeholder name. Attaching a file from OneDrive holds which job you were attaching it to and the provider's sign-in reply (stasis-onedrive-resume, stasis-onedrive-return-hash) for fifteen minutes, in that tab only. One flag (stasis-chunk-reload) lets a tab refresh itself once when we ship an update underneath it. Each of these expires on its own and is removed as soon as the step it belongs to finishes.

None of this profiles you, and none of it follows you to any other website. If you connect Microsoft or Google document storage to a workspace, that provider's own sign-in library also keeps its session in your browser so you are not asked to sign in again on every attachment.

On measurement: we use no advertising or cross-site tracking technology, and any usage measurement we run is cookieless and stores nothing on your device. It records the page visited, not a person, and nothing it collects can be used to recognise you on another site.

Because none of these entries is used for advertising or tracking, none of them requires your consent under the PDPA or the GDPR. You can still remove all of them at any time: clear site data for Stasis in your browser settings and every entry above is gone. Clearing the sign-in entry signs you out; clearing the rest simply returns the app to its defaults.

5. Why we use it (purposes)

• to provide, operate, secure and support the service;
• to authenticate users and manage accounts and subscriptions;
• to send transactional messages such as notifications, digests and service emails;
• to tell people who joined the waitlist when early access opens, which is the one marketing use we make of any of this, and which every such email lets you stop in one click;
• to bill for the service and comply with financial and legal obligations;
• to detect, prevent and respond to fraud, abuse and security incidents;
• to improve reliability and develop the service, using aggregated or de-identified data where possible.

6. Consent & the seven PDPA principles

We process personal data in line with the seven principles of the PDPA:

• General Principle · we process personal data only with consent or as otherwise permitted by law, and only for lawful purposes connected to our activities.
• Notice & Choice Principle · this Notice tells you what we collect, why, and your choices; where we rely on consent you may withdraw it.
• Disclosure Principle · we disclose personal data only for the purposes described here, or with consent, or as required by law.
• Security Principle · we take practical steps to protect personal data against loss, misuse, unauthorised access, alteration or destruction (see Security below).
• Retention Principle · we keep personal data only for as long as needed for the purposes above, then delete or anonymise it.
• Data Integrity Principle · we take reasonable steps to keep personal data accurate, complete and up to date; you can help by keeping your details current.
• Access Principle · you may request access to, and correction of, your personal data (see Your rights below).

These principles are enforceable: since the 2024 amendment, breaching them is an offence carrying a fine of up to RM1,000,000, imprisonment of up to three years, or both.

7. Disclosure & sub-processors

We do not sell personal data. We share it only with service providers who help us run the service, and with authorities where required by law. Every provider we engage is under a contract that requires it to protect personal data and to use it only on our instructions. Two entries below are not providers we engage and we hold no contract with either: the public holidays API, which is a free public service your own browser calls, and the browser push services, where the one that delivers to you is whichever your own browser registered with, so there is no single party for us to sign with. They are listed anyway, because this list is meant to name everyone who can receive anything, not only the companies we pay. Our current list is:

Some of these your browser contacts directly, rather than us contacting them for you. The main one is our database and sign-in provider: the app runs in your browser and talks to it straight, so your workspace data travels between the two without passing through a server of ours. Our own hosting carries the rest, both the pages themselves and the API behind them. Three others are reached only in passing, and none of them receives any workspace data: the cookieless analytics counted on each page load; a public holidays API, asked for one country's holiday dates when a workspace picks a country; and Google's or Microsoft's own sign-in and picker code, loaded into the page when somebody signs in that way or attaches a file from Google Drive or OneDrive. Each of those requests carries your IP address, because every web request does.

8. Cross-border transfer

Stasis is hosted primarily in Singapore, and some sub-processors operate globally, so personal data may be processed outside Malaysia. Where personal data is transferred abroad we rely on contractual safeguards with the providers we engage that are equivalent to recognised standards such as the EU Standard Contractual Clauses and the ASEAN Model Contractual Clauses, so that the data continues to be protected to a comparable standard. The two recipients named in section 7 that we do not engage are outside those safeguards, which is the reason section 7 names them: neither receives anything from us, and neither receives anything from your browser beyond the address the request itself carries.

9. Retention

We keep account and workspace data for as long as the workspace exists. Cancelling a subscription does not delete it: the data stays until the owner deletes the workspace or asks us to, so that nobody loses a year's records by missing a payment.

Deleting a workspace erases it from our live database in one operation, and deletes the backup copies of it at the same time. Backups are in any case kept to a fixed rule rather than indefinitely: of any one workspace we keep the seven most recent copies, the four most recent taken on a Sunday and the three most recent taken on the first of a month, and delete every other one. That is at most fourteen copies at any moment, reaching back roughly three months while a workspace is being backed up nightly.

Two things are deliberately excluded from that. Where a longer period is required by law, we keep what the law requires (see the invoices below). And where a customer has removed a person from their workspace rather than deleted the whole workspace, that person's past records are anonymised rather than erased, so the work history stays coherent without naming them. Customers can export or request deletion of their workspace data as described in our DPA.

Waitlist entries sit outside all of the above, because they belong to no workspace. We keep yours until you ask us to delete it. Unsubscribing stops every email, and we keep a record that you unsubscribed so that filling the form in again cannot put you back on the list by accident. Write to us and we will remove the entry itself.

One specific example: invoices and receipts issued for your subscription are the merchant of record's statutory tax records. Deleting your workspace unlinks these documents from your account and erases every other personal detail they carried (who they were emailed to), but the documents themselves are retained as required by tax law. This does not affect any other part of an erasure request.

10. Security

We apply organisational and technical measures appropriate to the risk, including encryption of data in transit, tenant isolation enforced at the database row level, access controls and least-privilege access, encrypted end-to-end push notifications, and logging of security-relevant events. No system is perfectly secure, but we work to reduce risk and to respond quickly to incidents.

11. Your rights

Subject to the PDPA, you may:

• access the personal data we hold about you;
• correct data that is inaccurate, incomplete or out of date;
• withdraw consent to processing where we rely on consent (this may limit our ability to provide the service);
• obtain a portable copy of your data in a commonly-used machine-readable format, the data portability right the 2024 amendment added, which also covers transmission to another provider where that is technically feasible and the data formats are compatible. The workspace export is how we deliver it: an owner can export the whole workspace, as JSON plus per-table CSV, from the admin area at any time, with no support ticket.

To exercise any of these, email [email protected]. If your personal data sits inside a customer's workspace (where we are the processor), we will refer your request to that customer as the controller and assist them in responding.

12. If something goes wrong

Since its 2024 amendment the PDPA makes breach notification mandatory, and we keep a written breach-response runbook so the steps below are prepared in advance rather than improvised on the day. If we have reason to believe personal data we hold has been exposed, altered, lost or misused, we will:

• contain it first · revoke the credentials involved, close the gap, and preserve the logs and audit records that show what happened;
• notify the Commissioner · where the breach causes or is likely to cause significant harm, or affects more than 1,000 people, we notify the Personal Data Protection Commissioner through the JPDP's data-breach notification channel as soon as practicable and within 72 hours;
• notify you · where the breach is likely to cause you significant harm, we tell you directly, without unnecessary delay and within seven days of notifying the Commissioner: what happened, what data of yours was involved, what we have done, and what you can do to protect yourself;
• notify the workspace owner · where the affected data sits in a customer's workspace and we act as processor, we notify that customer without undue delay so they can meet their own notification duties as controller;
• keep the record · every breach goes into a breach register we keep for at least two years, whether or not it met the thresholds above.

"Significant harm" carries the meaning in the Commissioner's guidelines: a risk of physical harm, financial loss, damage to credit record or property, misuse of the data for unlawful purposes, exposure of sensitive personal data, or data that could be combined to commit identity fraud. Failing to notify the Commissioner is itself an offence under the amended Act, which is one more reason the runbook exists.

13. How to complain

Please contact us first at [email protected] so we can try to resolve your concern. You also have the right to complain to the Personal Data Protection Commissioner of Malaysia (Jabatan Perlindungan Data Peribadi) at pdp.gov.my.

14. Updates

We may update this Notice from time to time. Material changes will be reflected in the "Last updated" date above and, where appropriate, notified in the app or by email.