Legal changelog

Trust and policy page pack added; sub-processor list moved

• New policy pages published: Security (including a plain "what we have not done yet" list), Data Processing Addendum, Sub-processors (with a commitment to update it at least 14 days before adding a new sub-processor), Refunds & cancellation, Accessibility, Service status, Contact, and About. Why: these commitments existed only implicitly (or not at all) before; a customer doing vendor due diligence had nothing to cite.
• Privacy Policy section 7 restructured. The inline sub-processor table moved to its own page (now also disclosing that pages load fonts from Google Fonts, which receives the visitor's IP for the font request), and the "we haven't yet built a self-serve DPA" sentence was replaced with a link to the published DPA. Why: both statements were superseded by the new pages; the Google Fonts disclosure was previously missing entirely.

Fact/consistency audit and DPDP rewrite

• Entity name standardized. Every legal page previously said "Klairtech" — replaced with "Klair Technology Solutions Private Limited (Klair Labs)" on first mention per page and "Klair Labs" thereafter, in terms.html and privacy.html. Why: the operating entity's actual registered name was never used; "Klairtech" was an informal shorthand that had drifted into legal copy.
• Terms of Service now describes all three plans. Section 3 previously described only Free and Pro, with a Pro feature list ("unlimited requests, custom branding on your intake page and embeds") that didn't match the actual Pro feature set or the homepage pricing card. It now lists Free, Pro and Premium with the same features and prices as the homepage pricing section, cross-checked against lambda/dsardesk/index.mjs. Why: a customer reading Terms would have seen a different (and in the "custom branding on embeds" case, incorrect — embeds are free and unbranded) feature set than the one being sold on the homepage.
• Pro's annual price stated as an exact number, not "2 months free." $389/year is actually $1 better than 10 × $39 (=$390, the "2 months free" amount) — the homepage pricing toggle previously used a blanket "2 months free" label that undersold Pro and was flatly wrong as a literal description. The toggle now reads "Save yearly" and each plan's annual subnote states the real number ($389/year — $79 less than paying monthly for Pro; $790/year — 2 months free, exactly, for Premium, since Premium's number really does work out to an even 2 months). Why: a specific dollar figure is a testable claim; "2 months free" was an inexact paraphrase of it for one of the two plans it was applied to.
• DPDP given its own jurisdiction card and full rewrite, instead of being lumped into "Other / DPDP & general" with a bare "30 days" figure that visually implied a fixed statutory count on par with GDPR/CCPA. The homepage jurisdictions section and deadline guide now state: DPDP Rules notified 14 November 2025; Data Protection Board provisions effective immediately; most compliance duties phase in over 18 months to 13 May 2027; Consent Manager registration expected to open around 13 November 2026; a fixed 72-hour clock for notifying affected individuals of a data breach; and explicitly, that DPDP sets no single statutory day-count for a data-principal request the way GDPR and CCPA do — a business publishes its own process. Source: PIB, "DPDP Rules, 2025 Notified" (17 November 2025). Why: the previous copy hedged correctly in places but still displayed "30 days" in the same bold, monospace treatment used for GDPR's and CCPA's real fixed counts, which reads as a statutory figure even when the caption underneath says otherwise. Splitting DPDP into its own card lets the copy be honest about what actually is and isn't fixed (the Board, the phase-in dates, and the 72-hour breach clock are fixed; the general request-response count is not).
• "Deletion requests up 567% since 2021" now links its source everywhere it appears, including the homepage's top stats strip, which previously stated the figure with no link at all (a separate section lower on the same page did cite the source, but the strip's copy stood alone). Why: house rule — no statistic ships without a source link directly next to it.
• Created apps/dsardesk/content/facts.json as the single source of truth for prices, features, the free-tier limit's current behavior, and the DPDP facts above, checked against both the marketing copy and lambda/dsardesk/index.mjs / app.html. Every page carrying a fact from it now links to it via an HTML comment. Why: the contradictions above existed because no single file was the answer key — the homepage, Terms, and the deadline guide had each accumulated their own slightly different version of the same facts.

Resolved the 90-day DPDP question the first pass flagged

• The 90-day figure is real, but scoped to a different thing than the request deadline. A Government of India press backgrounder (PIB, 17 Nov 2025) contains a line reading "Data Fiduciaries are required to address all requests related to access, correction, updating or erasure within a maximum of ninety days" — read in isolation, that sounds like a fixed statutory response window for the request itself, the same category of thing GDPR (1 month) and CCPA (45 days) fix. Checking the actual Rule text (Rule 14(3), via a rule-by-rule legal breakdown at dpdpa.com) shows PIB's own paraphrase blurred two different things: Rule 14(3) requires a Data Fiduciary to publish its grievance-redressal mechanism "within a reasonable period not exceeding ninety days" — that 90-day cap is on how long the Fiduciary's own grievance process may take to resolve a complaint about how a request was handled. It is not a cap on the original access/correction/erasure request, which DPDP still leaves to the Fiduciary's own published process, uncapped. The deadline guide and this product's homepage JSON-LD now state both facts precisely and separately, citing Rule 14(3) directly instead of only PIB's paraphrase of it. Why: getting this exactly right matters more here than almost anywhere else on the site — this product's whole job is telling a compliance team what their actual deadline is, so a table-stakes accuracy bar applies. Omitting a real, verifiable 90-day figure because it looked awkward to explain would have been its own kind of inaccuracy; the fix was in the scoping, not in choosing a side.

Baseline (pre-audit)

Terms of Service and Privacy Policy last carried this date before the 26 August 2026 audit above. No changelog existed prior to this page being created.

Removed the free-plan hard block at the intake form

The Free plan previously declined a business's 4th data-subject request in a calendar month at the intake form, telling the requester to contact the business directly. Removed this entirely: every request is now accepted, stored and deadline-tracked regardless of plan or count — a real statutory request is the business's legal obligation whether or not they're paying us, and refusing to even track it was a risk this product cannot carry. Past 3 requests in a month, the business's notification email for that request now includes one additional line noting they're over the Free plan's count and that Pro removes it, but nothing about how the request itself is handled changes. Updated terms.html and the pricing card to describe this accurately.

Corrected the privacy policy's self-serve deletion claim; surfaced the requester status page

The privacy policy said "DSAR Desk does not yet have... a self-serve delete my workspace button" — that button has existed in Settings for a while; the policy text was simply never updated when it shipped. Corrected it to describe what actually happens on deletion. Separately, a requester-facing status page (status.html, backed by /api/dsar-status) already existed but was never linked from anywhere a requester would actually see it — added a link to it in the request-confirmation email and on the intake form's "request submitted" screen.