OverviewEffective October 4, 2026
Legal Change Log
Every material change to the agreements and notices published here is recorded on this page, with the date it took effect and what changed.
Where a change materially and adversely affects a customer's rights or obligations, we give account administrators at least 30 days' notice before it takes effect, as the Platform Terms of Service require. This page is the durable record of that.
Version 3.10 — October 4, 2026
WorkMonitor can now check whether the work an employer's AI agents report done held up — whether a pull request stayed merged and passed its checks, whether a customer came back after an AI agent marked their conversation resolved — and the documents describe the data that takes. For a pull request an AI agent made or helped make, it records what each person who reviewed or merged it did, when, and their GitHub account, linked to their WorkMonitor account only where the employer has confirmed that the account is theirs. Managers who can see an AI agent see how many reviews each person made on its pull requests, with a person named only to a manager allowed to see them, and that count is not part of any score about the person. A pull request a person opened is kept, with its title, its link and the opener's GitHub account, when its description, its branch name or its commits carry a mark that an AI tool made or co-wrote it, when the repository, branch and time of the person's AI coding sessions match it, or when an AI agent reports it as its work; it is then linked as work an AI agent did or helped with, confirmed where the AI tool's own record names the pull request, and otherwise it can be suggested for a manager to confirm or reject. Reviews are recorded the same way on any other GitHub pull request WorkMonitor keeps. The documents also now say plainly that, where a business connects GitHub to track work, the pull requests and issues the connected account opened or is assigned to are kept with their title, link, state and dates and the GitHub accounts of their author and assignees, never their description, and that they can be matched to the people who worked on them and to their tracked time and activity, with a GitHub account linked to a person only once the employer confirms it; that was so before this edition and was described only as deliverables.
For a conversation or call an AI agent handled, whether the agent's service is connected or the agent reports to WorkMonitor directly, the employer's customer is known by a one-way coded reference made from their email address, telephone number or another identifier they are known by, never the identifier itself, so that a customer who comes back can be recognised. From Intercom Fin, WorkMonitor reads the customer's ratings of the AI agent and of the conversation, never the remark left with a rating and never which member of staff was rated, and when a person first replied after a handoff, without recording who. An employer can erase the references to one of its own customers as they stand at that moment. Erasing a person removes that person, and any GitHub account the employer confirmed as theirs, from the reviews and merges recorded at that moment, removes that account from the pull requests and issues it appears on, and removes the person as the reviewer of any link between a pull request or issue and someone's work; a link already made between a pull request or issue and their work stays, and a later read from GitHub can record that account on a pull request or issue again, but never link that account to the person again. The export an employer makes of a person's data now includes the reviews and merges recorded for them, the pull requests and issues their confirmed GitHub account opened or is assigned to, and the work AI agents handed to them by name. It is read from services the employer connects and kept in WorkMonitor's own service, so no processor is added.
An earlier edition of the Worker Privacy Notice and the Global Privacy Policy said that, for an AI coding session a person drives, the record of each step does not keep which tool was used, whether it worked or whether the person allowed it. Only the last still holds, so the sentence is replaced. The record now keeps which tool was used when it is one of the AI tool's own built-in tools, such as running a command or editing a file, and an error's standard code where the tool reports one, but never the name of any other tool. And the session keeps, as it always has, how many errors it had, failed tool calls included, which that edition did not say; the record never marks which call failed or whether the person allowed it.
| Document | Change |
|---|---|
| Worker Privacy Notice | What the software can record now gives the AI coding tool's own built-in tool names kept for a session a person drives, with the session's error count, the repository and branch a session worked in, and, where the employer checks its AI agents' work, the reviews and merges recorded for a person, the review count managers see, a person's own pull requests kept and linked to AI work, reviews on any pull request WorkMonitor keeps, and work AI agents hand to them. It now also lists the pull requests and issues kept when an employer connects GitHub to track work, and says they can be matched to the people who worked on them. Its retention section and its section on rights cover them, and the rights section says what a later read from GitHub can record again after an erasure. |
| Global Privacy Policy | The same change to AI coding tool data, and a new category of AI agent outcome data, with where it comes from, how long it is kept and how it is erased. Work records now describe the pull requests and issues kept when a business connects GitHub to track work. Who the policy is for, and where a request goes, now include people who open, review, merge or are assigned to pull requests or issues a business keeps from GitHub and the customers of a business who contact its AI agents. |
| US State Privacy Rights Notice and Data Processing Addendum | Add AI agent outcome data, and the GitHub accounts on pull requests and issues kept to track work, to the categories collected. In the Addendum, Annex I also adds the repository and branch to AI coding tool data, names those pull requests and issues among work records, adds the employer's own customers and other people who open, review, merge or are assigned to pull requests or issues it keeps from GitHub to the categories of data subjects, and names checking AI agents' work among the purposes; its section on assistance with data subject rights describes how an employer erases one of its own customers. |
| This Legal Change Log | Updated to match. |
Version 3.9 — October 4, 2026
The WorkMonitor agent can now help an employer see how its developers use AI coding tools, such as Claude Code and Codex, and the documents describe what it does. Three settings, each off until the employer turns it on and none of them active until the person has consented. With the AI tool telemetry relay on, those tools send their usage telemetry through the agent, which passes it on and ties each session to the person the computer is enrolled to: when a session ran, the AI models used, tokens and cost, and a record of each step of the session, never the text of prompts, replies or code. For a session the person drives, that record keeps the kind, timing, tokens and cost of each step and the model used, but not which tool was used, whether it worked or whether it was allowed; for an AI tool set up to work on its own, it keeps those too. With AI tool discovery on, the agent checks which AI coding tools from a fixed list run on the computer and whether each is set up to report, by reading the reporting settings in those tools' own settings files; only the result leaves the computer. And where the employer also chooses to configure AI tools on each computer, the agent adds WorkMonitor's reporting settings to those files, changes only its own entries, and removes them when the employer turns this off, when the person signs out, or when the computer is removed from the employer's account; if the agent is uninstalled without signing out first, its entries stay until they are removed.
The documents also now describe AI telemetry sent directly. An employer can set AI coding tools or AI agents to report the same usage telemetry, with its record of each step, straight to WorkMonitor without the agent, for example through a company-wide setting or from an automated pipeline. That path does not ask for the person's consent in WorkMonitor, and a session whose report carries an email address or WorkMonitor member identifier that matches a person's account is attributed to them. It was possible before this edition and was not described.
An earlier edition of the Worker Privacy Notice said the software does not read a person's files. That is no longer true of AI coding tools' settings files, so the sentence is replaced: the agent does not read a person's email, messages or documents, and the only files of theirs it reads are those settings files, while any of the three settings is on, only to check or set their reporting settings. The telemetry goes to WorkMonitor's own service, so no processor is added.
| Document | Change |
|---|---|
| Worker Privacy Notice | What the software can record now includes the three AI coding tool settings, with what each reads, the record kept of each step, what leaves the computer and when the agent takes its entries back, and AI telemetry an employer has sent directly. Its retention section now gives the periods for AI coding tool data. The statement that the software does not read a person's files is replaced by the narrower one above. |
| Global Privacy Policy | Adds AI coding tool data and AI telemetry sent directly to the personal data described, and how long it is kept. |
| US State Privacy Rights Notice and Data Processing Addendum | Add AI coding tool data, through the agent or sent directly, to the categories collected (the Addendum in Annex I). |
| This Legal Change Log | Updated to match. |
Version 3.8 — October 3, 2026
We now advertise WorkMonitor in ChatGPT as well as on Google, and OpenAI is added as a processor for measuring those advertisements. The advertising permission is unchanged — one answer covers both — and so are the ways to refuse it.
On our public website, where advertising is allowed for you, we load OpenAI's measurement script. It has no cookieless mode, so where advertising is not allowed it is not loaded at all. It reports page views and conversions with the page address but no query string, sets the __oppref, __obref and __oaiq_consent cookies, and never reads form fields for email addresses: our site checks the script's form-matching setting before loading it and does not load it while that setting is on. A new first-party cookie, wm_oppref, holds the ChatGPT advertisement's click identifier for 30 days, under the same rules as wm_gclid.
For an account created from a visit that arrived on one of our ChatGPT advertisements and allowed advertising, our servers report to OpenAI once when the account is created and once if it pays its first invoice — the click identifier, a random browser identifier, the time, the page and, for the payment, the plan, amount and currency, with no email address and no hash of one. Every report to OpenAI says it may not be used to personalize advertising. The Platform Terms' advertising carve-out now names these two reports; that part applies only to accounts created under this edition, so no existing customer's agreement is affected by it.
| Document | Change |
|---|---|
| Cookie Policy | Adds the Advertising in ChatGPT section and the wm_oppref, __oppref, __obref and __oaiq_consent cookies. |
| Sub-processors | Adds OpenAI, with what it receives from your browser and from our servers. |
| Global Privacy Policy, Privacy FAQ and US State Privacy Rights Notice | Describe OpenAI as a recipient of advertising and conversion data alongside Google, under the same permission and the same opt-outs. |
| Platform Terms of Service | The advertising carve-out names the two reports made to OpenAI, for accounts created under this edition only. |
| This Legal Change Log | Updated to match. |
Version 3.7 — October 3, 2026
Consent now depends on where you are. In the United Kingdom, the European Union, the rest of the European Economic Area and Switzerland, analytics, website session recording and advertising stay off until you accept them in our cookie banner, as before. Everywhere else — including the United States, Canada and Australia — they are on by default and no banner is shown; you can switch them off at any time with Cookie Settings or "Do Not Sell or Share My Personal Information" in our footer, and a Global Privacy Control signal still refuses advertising. We tell which rule applies from your browser's time zone; Google's tag decides from the location of your connection.
Google's tag now loads for every visitor. Earlier editions said that nothing was requested from Google until you accepted. Where analytics or advertising is not allowed for you, the tag still writes no cookie and stores no identifier, but it does send Google cookieless signals that it uses to estimate the visits and conversions it cannot count — in the UK and the EU before you answer the banner and after you decline it. Outside the UK and the EU, switching advertising off stops advertising signals from your browser entirely. Session recording is never made where analytics is not allowed for you.
For visitors outside the UK and the EU who have not opted out, the report our servers make when an account pays its first invoice now applies too, and a new first-party cookie, wm_consent_region, lets our servers apply the same rule on sign-up. The cookie banner is shorter. This edition adds no processor.
| Document | Change |
|---|---|
| Cookie Policy | Describes the regional rule, the tag loading for every visitor and the cookieless signals it sends where a purpose is not allowed, the wm_consent_region cookie, the footer controls as opt-outs outside the UK and the EU, and what switching off removes. |
| Sub-processors, Global Privacy Policy, Privacy FAQ and US State Privacy Rights Notice | Describe analytics, website session recording and advertising as allowed by acceptance in the UK and the EU and on by default elsewhere; the US notice describes advertising as on unless you opt out. |
| Platform Terms of Service | The first-payment report applies to accounts whose visit allowed advertising, rather than to those that recorded an acceptance. |
| This Legal Change Log | Updated to match. |
Version 3.6 — October 3, 2026
The paid plan we sold as Team is now called Pro. Its price, its screenshot retention cap of 180 days and its support response targets are unchanged: only the name is. The documents that name the plan now call it Pro.
This renames a plan and changes no term. It neither reduces a customer's rights nor adds to a customer's obligations, and it changes nothing for a person monitored through the Services, so the notice period for changes that adversely affect a customer does not apply.
| Document | Change |
|---|---|
| Global Privacy Policy, Worker Privacy Notice, Privacy FAQ and Data Processing Addendum | The screenshot retention cap of up to 180 days is stated for Pro, the plan formerly called Team. |
| Support Policy | The first-response targets table names that plan Pro. |
| This Legal Change Log | Updated to match. |
Version 3.5 — October 2, 2026
The Google advertising tag now also runs in the signed-in application, on the pages where an account is created and nowhere else: the sign-up form, the email confirmation page and first-time setup. It is there so that we can tell which advertisements led to an account actually being created, rather than only to a click on a sign-up button. On those pages it reports the account created, sends no page views of its own and asks for no advertising personalization. Like the tag on our public website, it sends Google the address and title of the page it starts on, and an email address handed to the sign-up form in its link is removed from the address before the tag reads it. No other page of the application configures it, and leaving those pages withdraws it.
Edition 3.4 said the signed-in application does not configure the advertising tag, while two passages elsewhere described the tag as running in the application without qualification. Both are replaced by the narrower statement above. Advertising still waits for consent, a Global Privacy Control signal still refuses it, and nothing about a person monitored through the Services reaches an advertising system.
Separately, our public website now makes session recordings for visitors who accept analytics cookies, using Smartlook. A recording shows the pages opened, clicks, mouse movement, scrolling and each page as it was displayed. Every form field, email address and number is masked in the browser before anything is sent, no IP address and no network traffic is recorded, and nothing is recorded in the signed-in application. Withdrawing analytics stops the recording and deletes what Smartlook stored in the browser. The cookie banner now names recordings among what analytics covers. Smartlook is a new processor for visitors to our public website only: it receives nothing a customer gives us, so the notice period for new sub-processors of customer data does not apply, and the Sub-processor list now says so.
| Document | Change |
|---|---|
| Cookie Policy | "Where it runs" names the application's account-creation pages alongside the public website, and says what the tag does and does not do there. Session recording of our public website is described under analytics, with its cookie, its place among third parties and what withdrawing removes. |
| Sub-processors | Describes the advertising tag as running on the public website and, in the application, on the account-creation pages only. Adds Smartlook for session recording, and states why the notice period does not apply to a processor engaged only for visitors to our public website. |
| Global Privacy Policy and US State Privacy Rights Notice | Describe the advertising tag the same way, and add session recordings of our public website to the website data described, with how long they are kept. |
| This Legal Change Log | Updated to match. |
Version 3.4 — September 29, 2026
The Google advertising tag now runs on our public website for visitors who accept advertising cookies. Google's tag sends the advertising account the full address of the page, including its query string, and the page's title with every advertising page view and conversion, and no setting we can give it prevents that. Earlier editions said the advertising account received a coarse bucket for the kind of page and never the page's address. That stopped being true once the tag ran, so this edition describes what the account receives instead.
The signed-in application does not configure the advertising tag, and the documents now say so rather than describing it as running there. Your advertising choice is still honoured in the application, and the report our servers make when an account's first invoice is paid is unchanged. Nothing else changes: advertising still waits for consent, a Global Privacy Control signal still refuses it, and nothing about a person monitored through the Services reaches an advertising system. This concerns visitors to our public website, and it adds no processor.
| Document | Change |
|---|---|
| Cookie Policy | What the advertising tag sends from your browser now includes the full address and title of the page, and the referring address where your browser provides one. The statement that the page address is withheld from the advertising account is withdrawn. "Where it runs" names the public website only. |
| Sub-processors, Global Privacy Policy and US State Privacy Rights Notice | Describe the page address and title among what Google receives for advertising, on the public website only, and remarketing audiences as built from the pages visited and their buckets. |
| This Legal Change Log | Updated to match. |
Version 3.3 — September 26, 2026
The Security Policy and Annex II of the Data Processing Addendum now describe the technical and organizational measures we have in place, and no longer publish a list of their current limitations or operational detail about how our infrastructure is arranged. A detailed description of our controls and their current limitations is available to customers and prospective customers under a non-disclosure agreement, and the Data Processing Addendum says so where a customer needs it: in its Security, Impact assessments and Audits sections and in Annex II.
No measure was removed or reduced. Two measures that were already in place are now stated: every member of our staff must complete two-factor authentication to sign in to our administration console, and passwords are stored only as salted one-way hashes. The security-related items that were listed among the commitments at the end of this page are now tracked in the non-disclosure description rather than here; they were moved, not completed.
| Document | Change |
|---|---|
| Security Policy | Describes the measures in place, including two-factor authentication for our staff, and where to obtain the detailed description of our controls and their limitations. The list of limitations and the description of how our infrastructure is arranged are withdrawn. |
| Data Processing Addendum | Annex II lists the measures in place and states that a detailed description of our controls and their current limitations is available under a non-disclosure agreement; its row of limitations is withdrawn, and its row on sub-processor management now refers to the commitments in the Sub-processors section instead of restating them. The Security, Impact assessments and Audits sections point to the same description. Annex III describes OVHcloud by the service it provides. |
| Global Privacy Policy, Privacy FAQ and DPA FAQ | The answers on security, encryption and audits describe the measures in place and where the detailed description can be obtained, in place of a list of limitations. The Privacy Policy and Privacy FAQ now say that HTTP Strict Transport Security is enforced, rather than that it is preloaded. |
| Sub-processors and Cookie Policy | OVHcloud is described as providing hosting and object storage, and Cloudflare as DNS hosting, without detail of how our infrastructure is arranged. References to a named test environment now say "non-production environments". |
| Legal Overview and this Legal Change Log | Updated to match. The note on the two withdrawn archived editions no longer dates the company's history. |
Version 3.2 — September 25, 2026
The report our servers make to our advertising account, when an account that came to us from one of our advertisements pays its first invoice, no longer includes a hash of the email address of the person who created the account. It carries the advertisement click identifier, an internal reference that stops the same payment being reported twice, the amount and currency of the invoice, when it was paid, and a consent signal stating that the visitor allowed advertising measurement and that the report may not be used to personalize advertising — and nothing else about the account. The Cookie Policy, Privacy Policy, Sub-processor List, US State Privacy Rights Notice, Platform Terms of Service, Privacy FAQ and Worker Privacy Notice are amended to say so.
This amendment reduces what is disclosed and adds no processor, so it is not a change that adversely affects a customer and the notice period does not apply. The hash of an email address a visitor types into one of our own forms, computed in that visitor's browser, is unchanged and is still described where it was.
Version 3.1 — September 8, 2026
WorkMonitor began advertising on Google, and a Google Ads conversion tag now runs on our website and in the signed-in application for visitors who accept it. This edition says so everywhere it is relevant. Version 3.0 stated in eight documents that we ran no advertising, set no advertising cookie, and did not share personal information for cross-context behavioural advertising. All three were true when they were written. None of them survives an advertising tag, so all three have been replaced rather than softened.
On the effective date, which is the same day as version 3.0 and is deliberate. Version 3.0 took effect on September 8, 2026 and this amendment was made later the same day, in the release that carried the advertising tag itself — because the Cookie Policy commits us to updating it before a new non-essential cookie is set, and that is a sequencing promise rather than a formality. A date in the future would have published a Cookie Policy describing cookies while its own masthead said it was not yet in force; a date in the past would have backdated an amendment nobody could have read. A same-day amendment is the only one of the three that is true, and no visitor was ever shown the version 3.0 text while an advertising cookie could be set: the tag writes nothing until a visitor accepts a banner that names advertising and conversion measurement in terms.
The boundary this edition draws, because it is the load-bearing part, and it has two limbs rather than one. Nothing the platform captures about a monitored person, and no identifier of one — in the clear or as a hash — is disclosed to an advertising provider, used to build an audience, or used to target an advertisement. That limb is absolute and admits no exception. Alongside it sits one narrow disclosure that is described rather than denied: where an account came to us from one of our advertisements and pays its first invoice, we report that payment once to our advertising account, with the click identifier, an internal account reference, the invoice amount and a hash of the email address of the person who created the account. That is an account holder's own commercial relationship with us. The Platform Terms of Service carry both limbs as express terms, and the Worker Privacy Notice states them in plain terms to the person being measured.
Where the corpus was corrected against the code before this edition took effect, because these are the sentences a reader is most entitled to have right. Three things were described from the design of the change rather than from what shipped, and all three are now written the other way round. The footer "Do Not Sell or Share My Personal Information" control performs an advertising-only refusal directly on one click; the cookie banner asks both permissions together, with one Accept and one Decline covering both, and is described as the coarse control it is instead of as a per-purpose one. The hashing of an email address happens in two places, not one — in your browser on a form you submitted, and on our servers when a first invoice is paid — so both are described. And conversion reporting is described as what advertising consent permits, because a conversion is only reported for a conversion action created in our advertising account and those are created one at a time; on the day this edition takes effect the only thing reaching that account is the remarketing page view.
What withdrawal now reaches, which is the other half of a promise this corpus had been making about cookies alone. Refusing advertising deletes the advertising cookies in your browser and sends a request to our servers to delete the advertisement click identifier stored against your account, cancelling any conversion queued and not yet reported. The stored identifier has no automatic expiry yet; an automatic purge once it passes the ninety-day window Google itself applies is listed below as committed work rather than described as though it already runs.
| Document | Change |
|---|---|
| Cookie Policy | A new section on advertising and conversion measurement, and the advertising cookies added to the first-party table: wm_consent_ads, which records the advertising decision separately from the analytics one; wm_gclid, which holds the click identifier of the advertisement you arrived through for 90 days; and Google's _gcl_au, _gcl_aw, _gcl_dc, _gcl_gb, _gcl_gs and _gac_* cookies, which are set on our own domain. Corrects the claim that advertising and personalization storage stay denied whatever you choose, and the claim that Google's script is never requested — there is one script and the two purposes are configured from two separate answers. Describes both routes by which an email address of yours can reach Google as a hash: one you typed into our own form, hashed in your browser, and the account creator's address, hashed on our servers when a first invoice is paid. Says plainly that remarketing audiences are built, from a coarse page bucket rather than from the page address, because "we build no audiences" was one of the sentences this edition had to retract; and states that the page's own address, path, query string and fragment are not sent to the advertising account at all. Separates the two footer controls: Cookie Settings reopens a banner that asks both permissions together, and "Do Not Sell or Share My Personal Information" refuses advertising alone on one click. Records that refusing advertising also asks our servers to delete the stored click identifier. |
| US State Privacy Rights Notice | The section that said we neither sell nor share is now headed and written as what it is: we do not sell, and we share one narrow category — website-visitor identifiers, the kind of page viewed, the conversion completed and a hashed email address — with Google for cross-context behavioural advertising, where the visitor accepted it. The twelve-month lookback is kept as a lookback rather than deleted. The claim that a "Do Not Sell or Share My Personal Information" link would be pointless is replaced by a section describing that link, which performs the refusal on one click, and the Global Privacy Control signal, which refuses advertising for a browser that sends it without asking and overrides an acceptance already recorded there. The same section says outright that the cookie banner is not a third, per-purpose control. A new section sets out what a conversion report contains along each of its two routes, the browser one and the server one. The CCPA category table now names the advertising disclosure against categories A, D and F, and records that nothing the agent collects on a device is ever disclosed for advertising. |
| Global Privacy Policy | A new category of personal data for advertising and conversion data, an advertising row in the legal-basis table with consent as the basis, an advertising recipient in the sharing list, a retention row for the click identifier and the advertising cookies, and a rewritten cookies section covering both permissions and both footer controls. The two sentences denying any sharing for cross-context behavioural advertising are replaced by a disclosure with a boundary: a website visitor's data and the purchase their account later makes, yes; anything the platform captured about a monitored person, never. The retention row states three different lives rather than one, and says plainly that the click identifier stored in our database has no automatic expiry yet. |
| Sub-processors | The analytics section is now "Website analytics and advertising measurement", and Google stays a single row doing two jobs under two consents rather than becoming a second row in a second section. The row states what each purpose sends along each of its two routes — the browser tag, and the server-side report made when an account acquired from an advertisement pays its first invoice — what none of them sends, and that with advertising accepted Google may use what it receives to select advertisements on other sites. The notice-of-changes section no longer says that nothing about the new purpose could concern a customer. |
| Platform Terms of Service | The Customer Data section now states the advertising boundary expressly, in two limbs. Nothing captured from or about a Monitored User, and no identifier of one in the clear or as a hash, is disclosed to an advertising, remarketing or conversion-measurement provider, used to build an advertising audience, or used to target an advertisement — absolute, with no exception. Carved out of it, and described rather than implied, is the first-payment report we make to our advertising provider for an account acquired through one of our advertisements: the click identifier, an internal account reference, the invoice amount, and a hash of the account creator's address, with a route to stop it. Widening that carve-out is a material change requiring notice. |
| Worker Privacy Notice | The sentence "We do not use it for advertising" is replaced by a paragraph that says we do advertise, explains that the measurement uses data about visitors to our website, and states that nothing the software records on your device is used to advertise anything to anyone or reaches an advertising system. A second paragraph covers the case where the person reading it is also the person who bought the subscription, since the first-payment report concerns that purchase. |
| Privacy FAQ | The answer to "Do you sell our data?" no longer claims we set no advertising cookie. It answers the sale question, states the advertising change and where the opt-out is, names the first-payment report made for an account acquired through an advertisement, and then states the boundary that everything the platform captures stops here. |
| Legal Overview | Corrects a stale line that said the Cookie Policy describes no analytics cookie, which had been untrue since analytics shipped, and removes the reference to a legacy-terms group that has not existed since version 3.0 withdrew the two archived editions. |
Version 3.0 — September 8, 2026
A full replacement of the published corpus. The previous edition was written when WorkMonitor was a smaller product, and it had stopped describing either the software or the company accurately.
Twelve documents were added and every existing one was rewritten. Live agreements now carry clause numbers so that a paragraph can be cited in a contract or a redline.
| Document | Change |
|---|---|
| Platform Terms of Service | Rewritten and expanded. New: dispute resolution by individual arbitration with class-action and jury-trial waivers, an opt-out, and express carve-outs for consumers in the EEA, the UK and Switzerland; a limitation of liability capped at twelve months of fees; mutual indemnities; a section on the customer's responsibility for deploying monitoring lawfully; our express right to refuse or suspend a deployment we reasonably believe unlawful; export control and sanctions; a one-year limitation period; and an order-of-precedence clause covering the whole corpus. |
| Billing terms | Now stated in full: automatic renewal, fees non-refundable except under a new 14-day money-back guarantee on a first paid subscription term, 30 days' notice before any price increase, pro-rata charging for seats added mid-term, suspension after 10 days' non-payment, and interest on overdue invoices. |
| Data Processing Addendum | Rewritten with Annexes I, II and III. The EU Standard Contractual Clauses are now incorporated by reference with the modules, options and annexes completed, together with the UK International Data Transfer Addendum and the Swiss adaptations. Adds CCPA service-provider terms, a 48-hour breach-notification commitment, audit rights, and deletion and return obligations. |
| Annex II, technical measures | New. It states the technical and organizational measures in place and, until version 3.3, also listed their limitations. |
| Privacy Policy | Rewritten against what the software actually does. Corrects an earlier edition that described session recordings the product has never had and a company address that was not ours. Adds a legal-basis table, a retention table, a description of the location data recorded at clock-in, and an explicit statement that we do not participate in the Data Privacy Framework. |
| Sub-processors | Restated as tables with a privacy-policy link for every named vendor, and a clear separation between our sub-processors and the destinations a customer configures for itself. Google is listed for analytics, with what is sent, what is rewritten before it is sent, and what is never sent at all. |
| Cookie Policy | Rewritten as a table of the cookies actually set, each with its real lifetime read from the code: wm_consent at 180 days, wm_hero_cta at 30, and the wm_ref attribution cookie at the referring partner's window, 90 days by default — the previous edition said 30, which matched neither the code nor the Affiliate Terms. Google Analytics 4 is described as it behaves: nothing is requested from Google until you accept, advertising and personalization storage stay denied whatever you choose, and withdrawing consent deletes the cookies already set. Records that the dashboard session is a token in local storage rather than a cookie. |
| Service Level Agreement | A measurable commitment for the first time: 99.5% monthly availability for paid plans, a three-tier service-credit schedule, a defined measurement method, exclusions, a 30-day claim window, and a chronic-failure termination right. |
| Acceptable Use Policy | Expanded, with the monitoring-specific prohibitions first: no covert monitoring outside narrow lawful circumstances, no monitoring outside the working relationship, no monitoring aimed at union activity or protected complaints, and no inference of special categories of personal data. |
| Worker Privacy Notice | Rewritten for the person being measured, stating what the software cannot do — no keystroke content, no audio, no camera, no continuous recording, no location trail — and where to take a request or a complaint. |
| New documents | Website Terms of Use, US State Privacy Rights Notice, AI Features Terms, API and Developer Terms, Beta and Early Access Terms, Support Policy, Security Policy, Vulnerability Disclosure Policy, Copyright and DMCA Policy, Brand and Trademark Usage Policy, Law Enforcement and Government Requests, and this Legal Change Log. |
Two archived editions were withdrawn, not superseded
Until this version, the register published a "Terms of Service, 2024 Edition" and a "Terms of Service, 2023 Edition", each stating the period of subscriptions it had governed.
Neither had governed anything. WorkMonitor had no subscriptions in 2023 or 2024, and so no terms that applied to them. Those two pages were template residue that arrived with a purchased layout and was never removed.
They have been deleted rather than corrected, and this entry is left in their place. A published contract that claims a history the company does not have is not a harmless page: it is a document that, once noticed, invites a reader to discount every other document beside it.
If you believe you held a subscription under an earlier edition of our terms, write to legal@workmonitor.ai and we will tell you exactly what applied and when.
Commitments we have made and not yet completed
Statements elsewhere in this corpus that describe something we are going to do are collected here, so that they are findable in one place and cannot quietly lapse. Each will be updated on this page when it is done.
| Commitment | Where it is stated | Status |
|---|---|---|
| Appoint representatives under Article 27 of the EU GDPR and the UK GDPR, and publish their details | Privacy Policy; Data Processing Addendum | In progress. Until appointed, EU, UK and Swiss individuals and authorities should contact the Data Protection Officer at dpo@workmonitor.ai. |
| Complete designation of a copyright agent in the US Copyright Office directory | Copyright and DMCA Policy | In progress. Notices sent to the address in that policy reach us and are acted on in the meantime. |
| Delete a stored advertisement click identifier automatically once it passes the ninety-day window in which a conversion can still be reported | Global Privacy Policy, retention table | Committed, not yet in place. Today such a record is deleted when advertising consent is refused, and on request. Nothing yet removes one that simply grows old, and it is deliberately not tied to the life of the workspace, because it explains a payment the accounting record has to keep. Stated rather than covered over by publishing a period we do not enforce. |
| Publish an annual transparency report on government and law-enforcement requests | Law Enforcement and Government Requests | No requests have been received, so there is nothing to report. The first report will cover the first calendar year in which a request is received. |
| Publish annual request metrics under California law | US State Privacy Rights Notice | No full reporting year has closed since this notice took effect. Figures will be published rather than estimated. |
| Complete SOC 2 Type II and ISO/IEC 27001 | Security Policy; Data Processing Addendum; across the site | In preparation. No certification is held today. |
How we tell you about a change
A change that materially and adversely affects your rights or obligations: at least 30 days' notice to account administrators by email or in-product notice, taking effect at the end of that period or at the start of your next Subscription Term, whichever is later. If you do not accept it you may terminate the affected subscription before it takes effect and receive a pro-rata refund.
A new or replacement sub-processor: at least 30 days' notice, with a right to object on reasonable data-protection grounds.
A change required by law, by a regulator, or to address a security risk: effective immediately, with notice as soon as we reasonably can.
Everything else: effective when posted, and recorded here.
Notices go to the administrator email addresses on your account. Keep them current — a notice sent to an address you have not updated is still effective.
Questions
Questions about a change, or a request for a copy of a superseded version that is not published here: legal@workmonitor.ai.