Release notes

September 8, 2026: Your reply-to address now has to be confirmed

Mail Pishik sends for you (reviewer routing, reminders, status notices) goes out from our own sending domain, signed by us, with your workspace's reply-to address on it so replies reach you rather than us. Until now nobody had to prove they could read that address. Anyone with an admin seat could put any address at all there, and replies to a Pishik-signed message would go to it. That is a relay we do not want to run, so we closed it.

What changes. An address is used as your reply-to once it has been confirmed: open Settings → Company, send the six-digit code to the address, and enter it. Any address that is already a member's own Pishik account address counts as confirmed (it was verified when they joined), so for most workspaces nothing changes at all. The same rule now applies to the personal reply-to under Settings → Your profile.

If your reply-to is a shared inbox (a contracts@ or legal@ address that is not any one person's login), it needs confirming once. Until it is, replies go to the workspace owner's account address instead (they still reach your workspace, just not the shared mailbox), and we send the owner a notice in the app saying so. If your workspace requires the company reply-to on every message, we send no reply address at all rather than quietly routing replies to one individual.

Acknowledgement emails are off by default. When you write to us through the contact form, we no longer send an automatic "we got your message" email. Every automatic email competes for the same hourly sending allowance as password resets and sign-in codes, and an acknowledgement is the one message in that queue nobody is waiting on. Your message is still filed the moment you send it, the form itself confirms that on screen, and a person replies. That reply is the acknowledgement. A message our filters quarantine as spam gets no automatic reply either, exactly as before.

Privacy Policy. The list of security records that carry a signed-in person’s email address is widened by two cases, both new in this release: a workspace reload a rate limit refused is now listed alongside a refused in-app support request, and “a sign-in where the one-time code email failed” now reads “a sign-in or a two-factor setup”, because two-factor setup from Settings sends the same code. Same 90-day clock, same records, nothing new is collected. Section 1; DPA Annex I matches.

Also in this release. Subscriber alerts for a blog post that could not be delivered now keep those readers recorded as still owed, so publishing the post again picks them back up rather than reporting the send finished. That covers a dead address, a provider refusal, messages an operator discarded from the queue, and messages the outbound queue was too full to accept.

September 6, 2026: Security tools for the Command Center, and an honest update to the privacy policy

Our public contact form was hit by a flood of automated spam: tens of thousands of messages, each one filed as a support ticket, and each one triggering an acknowledgement email to whatever address the sender typed in. The defences we had (a per-address limit and a bot trap) were not built for that volume. This release is the fix, and it changes one thing we tell you about your data.

Contact-form protections

• A site-wide ceiling. The form now accepts a bounded number of messages per hour in total, on top of tighter per-address limits. A real person rarely notices; a script notices immediately.
• Proof the page was loaded. The form carries a short-lived token issued when the page loads. A submission without one (a script posting straight at the endpoint) is held to the strictest budget instead of the normal one. With JavaScript off, the form still works; it simply gets that stricter budget.
• Quarantine, not delivery. A message that is mostly non-Latin script, carries more than a couple of links, comes from an email domain we have blocked, or repeats an identical message we have already seen twice is set aside as spam. It sends no acknowledgement email and no alert to us, and it never reaches the inbox.
• A pause switch. We can close the form outright while an incident is under way. If you ever see “temporarily closed”, the message tells you where to email us instead.

A Security section for the Command Center

Our operator console now shows who is knocking (blocked requests, rate limits, failed sign-ins, quarantined and refused messages) and lets us block an address or a range for a day, a week, a month, or until we lift it. An address that keeps hammering the form or the sign-in page is blocked automatically for a day. A bulk-cleanup tool clears a spam flood from the inbox in one pass rather than one ticket at a time. And messages now record the address and browser they came from, so one that slips past the filters can be blocked straight from the inbox.

Privacy Policy and DPA updated

Privacy Policy. Last updated September 6, 2026. In July we told you we do not log IP addresses, and at the time that was true. It no longer is, and we would rather say so plainly than let the old sentence stand. IP addresses are now kept in security records (the blocklist, and a log of security events that is deleted after 90 days, covering blocked requests, failed sign-ins, refused requests, and the address each contact-form message was accepted, quarantined or refused from) and on messages sent through our contact and support forms, together with the browser identifier they came from, so that abuse can be blocked. One more thing belongs in that sentence, because it is the part about a named person rather than a network address: where the request came from someone signed in, the security-event record also carries that person’s email address, on the same 90-day clock. Those records are sign-ins to our operator console and actions it refused, requests missing our client header, in-app support requests a rate limit refused, and a sign-in where the one-time code email failed and that check was bypassed. Nothing else stores them: sign-in sessions do not, and there is still no general web access log. Section 1 and the retention table in Section 7 set this out in full. DPA Annex II is corrected to match, and Annex I now lists the address and browser identifier attached to a support request.

July 28, 2026: Correcting what we said about email delivery

We audited every published claim against the code that actually runs. Most held. This one didn't, and it ran through several pages at once, so it's worth stating plainly.

Email delivery is ours, not yours

Our Privacy Policy, DPA, product page, and several Support Center pages described email delivery as something your workspace configures, whether through your own Microsoft 365 tenant, your own Azure subscription, or an SMTP provider you designate. That was never true of the hosted service. Pishik sends all review, reminder, and notification email through a single channel we operate and configure, currently Azure Communication Services. Mail leaves from a Pishik address carrying your company name and logo, with replies routed to your team.

Nothing about the actual processing changed, and no new vendor was introduced. Microsoft was already named in Annex III as our email subprocessor, and still is. What changed is that the documents now describe it correctly, without a conditional that implied a choice the software never offered. We've also removed the "not a subprocessor, because you direct it" carve-out for customer-run mail, since no customer runs mail here. Privacy Policy §3 and §6, and DPA §3, §6 and Annex III are all effective July 28, 2026.

One consequence worth being direct about: if you were counting on review email arriving from your own domain, it does not, and that is not something the hosted service offers today. If it matters to your rollout, tell us and we'll give you an honest answer about the roadmap rather than an arrangement we can't deliver.

Reviewers: how to tell a request is genuine

Our reviewer guidance used to say a real request "comes from the company's own email." It doesn't. It comes from Pishik on their behalf. That mattered more than the other corrections, because it's an anti-phishing checklist: the old wording quietly trained reviewers to distrust genuine mail and to trust anything sent from the company's own domain. Fixed here. The best check hasn't changed: confirm out-of-band with the person who asked.

Smaller corrections, same audit

• Enterprise seats. Billing help said Enterprise gets "as many seats as you need." Seat counts are set on your workspace by us, up to 100. Reworded.
• Changing plans. We said your team carries over "unchanged" on any plan change. True going up; going down, a downgrade is only accepted once your team already fits the smaller tier. Now documented.
• Price changes. Billing help promised notice before a price change and attributed that to the Terms, which say the opposite. The Terms govern; the support page no longer claims otherwise.
• Enterprise support. The pricing page offered "priority help." There is no priority queue: every topic reaches the same team, as our contact page has always said. Removed.
• Sign-in branding. The product page said your logo brands the sign-in screen. It doesn't, and can't, because sign-in happens before we know which workspace you belong to. Removed.
• Open-source notices. Our shipped notices file listed nodemailer as MIT; it's MIT-0, which our licenses page already said. The two now agree, and every package carries its own license.

July 27, 2026: A Data Processing Addendum, and a more accurate Privacy Policy

New: Data Processing Addendum

There's now a Data Processing Addendum covering the personal information we handle on your behalf: your reviewers' details and your teammates'. It applies to every customer automatically, with no signature needed, and it's the document to hand your procurement or legal team. It carries the CCPA service-provider terms and the GDPR processor terms, plus two annexes worth reading on their own: Annex II lists our security controls one by one, and Annex III names every subprocessor and what it does. We'll give 30 days' notice before that subprocessor list changes. Need it signed, or a security questionnaire filled in? Ask us.

Privacy Policy updated

Privacy Policy. Effective July 27, 2026. Some of this is new disclosure; some of it is us correcting our own description of what the software does. We think the corrections matter more.

• We don't log IP addresses, and the old policy said we did. (Superseded September 6, 2026; see above.) We audited the policy against the code and found this claim was simply wrong: your IP is read while a request is in flight, used to rate-limit sign-in and form abuse, and never written to our database. There is no web access log. The policy now says so, and Section 1 also states plainly what we never collect at all: no government IDs, no card numbers, no health data, no biometrics, no location.
• We store the emails we send, not just their delivery record. The old wording said we kept only recipient, subject, timestamp, and status. The sent-email record also keeps the message the Service generated, which is what makes Resend work. Corrected. What hasn't changed: we never read, sync, or store your mailbox.
• Retention, by category, honestly. Section 7 is now a table instead of a paragraph, and it says the awkward part out loud: your workspace records don't disappear on a timer, and erasing a workspace leaves behind our own support tickets, account notes, trial-code records, and subscription timeline. You can ask us to remove those too.
• Do Not Track, answered. New Section 5 states how we respond to browser DNT signals (nothing changes, because nobody is tracked) and confirms that no other party can track you through our site. California law requires that disclosure of every commercial website regardless of size, and ours was missing it.
• Your California privacy rights. New Section 11 covers what you can ask us for, how to ask, how we verify it's you, how fast we answer, authorized agents, and Shine the Light. We honour access, correction, deletion, and portability requests for everyone, not only where a law compels it.
• Who our vendors are. Section 6 now names them by category (hosting, payments, email delivery) instead of describing them in the abstract.

Terms of Service updated

Terms of Service. Effective July 27, 2026. Section 10 now incorporates the Data Processing Addendum by reference and confirms that Pishik receives reviewer information solely as a service provider, so routing it to us is not a sale or sharing of personal information.

Corrections to our Security page

The same audit checked every factual claim on Security & privacy against the code. Five were broader than what the software guarantees, and we've narrowed them: how two-factor enrollment is enforced on the sign-up path, what a minimum-password-length setting actually applies to, how much of a removed comment lands in the audit trail, which exports the server logs on its own, and the fact that restoring a backup also restores that backup's workspace name and idle-sign-out setting.

Fixed: personal exports carried live review links

Writing down the security guarantees turned one up that wasn't being kept. Export my data, the per-member export in Settings → My data, was including the single-use approval tokens for any review still pending on your contracts, so the downloaded file contained working approve/reject links. The server-built workspace and member exports have always stripped those; this one was assembled in the browser and missed the same treatment. It now strips them the same way, and the export still shows which reviews were decided and when. If you exported your own data previously and still have the file, treat it like a credential, or delete it. Any review that has since been decided or has expired is closed regardless.

July 19, 2026: Two-factor authentication for everyone, and clearer Terms

Two-factor authentication is now required

Every Pishik account is now protected by two-factor authentication. It's part of sign-in, not an option you can skip. You pair an authenticator app and save your backup codes; accounts that haven't enrolled yet are walked through it. The full picture is in Security & privacy.

Terms of Service updated

Terms of Service. Last updated July 19, 2026.

• No refunds; no proration. Section 5 now says explicitly what was always the deal: fees are non-refundable once charged, there are no credits for partial billing periods or unused seats, and cancelling stops future renewal charges rather than refunding the current one. Paid access runs through the end of the period you've paid for. Section 15 repeats the cancellation part where you'd look for it.
• Paid subscription or trial, stated plainly. Section 5 now spells out that using Pishik requires an active paid plan or an active trial. The limited, unpaid state exists only to complete checkout, restore a lapsed plan, or export your data. It is not a free tier, because there isn't one.