Customer reviews are public, but a reviewer's name, an employee named in a review and the processing of that data in a SaaS all fall under KVKK, Turkey's personal data protection law. A chain's legal and information security teams assess the review analytics platform the operations team wants through that lens. This post sets out the questions to ask about KVKK and data security, and the concrete answers BranchVoice gives, limited strictly to measures that are actually in place.
What review data means under KVKK and data security
Review analytics brings three kinds of data together. First, the review itself: text, stars, date, published on a public platform. Second, data about the author: display name, profile link. Third, the people mentioned inside the review, most often store employees.
BranchVoice processes this data on behalf of its customer, in the role of data processor: the data controller is the company using the platform, which decides which stores are monitored, which sources are connected and whether author details are kept at all. That separation of roles is the first point a company should consider when setting up its own notices and records of processing.
The option not to store author details
On the review settings step of the store import wizard there is a store personal data option. When it is off, the reviewer's name and profile link are never saved; instead a short pseudonymous identifier is generated that lets repeat reviews from the same author be matched without identifying the person. The review's text, rating and analysis continue to work in full.
For most chains this is the right default: the operations team needs the content of the review and the store it belongs to, not the author's name. Because the option is held per source, it can be left on only for map sources where replies will be written and off everywhere else.
Technical measures
Our security page lists only the measures the product genuinely implements; the same principle applies to the four headings below.
Encryption in transit
All platform traffic travels over HTTPS. Session cookies are sent only on secure connections and are flagged httpOnly, so scripts in the browser cannot read them; a session token cannot be lifted by a third-party script injected into the page.
Password security
Passwords are never stored in plain text; they are hashed one-way with scrypt and a per-user salt. The password policy requires at least 8 characters including an uppercase letter and a digit. Login attempts, password resets and sign-ups are rate limited, so repeated wrong attempts against one account are temporarily blocked.
Short-lived sessions
The access token is short-lived; when it expires a separate refresh token issues a new pair and the old one becomes invalid. Without "remember me", the session ends when the browser closes. Changing a password or deactivating an account also drops that user's open sessions.
Company-scoped data isolation
BranchVoice is a multi-tenant platform and every record belongs to a company. Every query is limited to the requesting user's company; there is no path to another company's stores, reviews or reports. The rule is enforced across all data access, not endpoint by endpoint.
User management
The first user of a company that signs up on its own is activated by e-mail verification. Every later user is added by invitation only: the invitation e-mail carries a time-limited link, and the user sets their first password through it. When a manager leaves and their account is deactivated, access ends immediately.
There is no role separation within a team; every user in the company sees the same data. For chains that want regional managers to see only their own region this is an important design fact and should be discussed openly during evaluation.
An evaluation checklist
| Question | How BranchVoice answers it |
|---|---|
| In which role is data processed? | The company is data controller, BranchVoice is data processor |
| Must author names be stored? | No; it can be switched off per source |
| Is traffic encrypted? | HTTPS, secure and httpOnly cookies |
| How are passwords held? | One-way scrypt hashes, password policy, rate limiting |
| How long does a session last? | Short-lived access token, rotated with a refresh token |
| Can another company's data be seen? | No; all access is scoped to the company |
| How are users added? | By invitation; accounts can be deactivated on request |
The current version of this table always lives on the security page, and the purposes of processing are set out in the KVKK notice. If you believe you have found a vulnerability, report it through the address on the security page; reports are kept confidential and verified.
For the technical detail of the collection flow see scheduled review sync, and for where the author-data option sits in the wizard see importing your store list.
Next steps
KVKK compliance is delivered by a product's defaults, not by a page of text: the option not to store author details, company-scoped isolation and invitation-based user management are the concrete examples. To work through your legal and information security teams' questions together, request a demo.