Information Security and Information Management Policy
This is an English translation provided for convenience. In case of any discrepancy, the Hebrew version prevails.
Last updated: October 5, 2026
1. Purpose and scope
1.1. This document describes how TalkWiz manages, stores and secures the information in the TalkWiz service, and in particular the call data that business customers enter into the Service. It is part of the Terms of Use and the Data Processing Agreement.
1.2. The policy was built under the Privacy Protection Law, 5741-1981, and the Privacy Protection (Data Security) Regulations, 5777-2017. It describes the measures in place at the time of its update. TalkWiz may change specific measures, provided the overall level of protection is not materially reduced.
1.3. This document is for transparency and for giving information to customers. It does not grant an undertaking as to a result, and does not promise that a security incident will not occur.
2. Shared responsibility
Information security is a shared responsibility:
- TalkWiz is responsible for securing the Service itself: the infrastructure, the code, the separation between organizations, encryption, permissions in the system, backup and incident response.
- The customer is responsible for everything under its control: deciding which data to enter, informing the parties to calls and obtaining their consent, managing users and permissions in its organization, keeping passwords, API keys and connection addresses safe, setting retention periods, choosing destinations for data transfer, securing the devices and networks its users log in from, and keeping copies of information that matters to it.
3. Information map
| Type of information | Where it is stored | Protection |
|---|---|---|
| Voice recordings | Private storage, with no direct user access | Deleted right after transcription |
| Transcripts and raw content | The database | Application-level encryption and hiding of payment details and identifiers |
| Analysis outputs and metrics | The database | Separation between organizations and role-based permissions |
| Account and organization details | The database and the authentication system | Passwords stored only as hashes |
| API keys and connection secrets | The database | Hashed or encrypted, shown only once |
| Payment methods | With the payment processor | We do not store card numbers |
4. Separation between organizations and permissions
4.1. Every customer record is linked to its organization. The separation is enforced inside the database itself (Row Level Security), so that even a fault in the application layer should not allow one organization to see another organization's data.
4.2. Within an organization, access is set by role: owners and admins see the whole organization, a team lead sees only their teams, and an agent sees only their own calls and the call library the organization shared.
4.3. Call data is written only by the server, after verifying the organization of the person acting, so the hiding and encryption cannot be bypassed from the browser. The original analysis result cannot be changed by users; a manager's manual score is kept next to it.
4.4. Every user can turn on two-factor authentication (a code from an authenticator app at every login), and the customer can require two-factor authentication for every user in its organization.
4.5. Automated tests of the separation and permissions run on every code change, and check every customer table against users from another organization, a user without an organization and anonymous access.
5. Encryption and hiding
5.1. Communication with the Service is encrypted (HTTPS), with HSTS.
5.2. Information is encrypted at rest by the infrastructure provider. In addition, transcripts, raw content received from outside systems and connection settings are encrypted at the application level with AES-256-GCM, with a key kept outside the database that supports key rotation. Every transcript is cryptographically bound to its call.
5.3. Before storing a transcript and before sending it for analysis, the Service hides credit card numbers, CVV, card expiry dates, ID numbers, bank accounts and IBAN, and keeps only last digits. The hiding is based on pattern recognition and has known limitations (for example numbers spoken as words).
5.4. API keys and webhook secrets are stored only as hashes, checked with constant-time comparison, and shown to the customer only once.
6. Managing the information life cycle
6.1. Minimization: the Service keeps only what it needs to function. Files uploaded to import calls are processed in memory and not stored.
6.2. Recordings: sent for transcription and deleted right after it. A recording that failed, expired or got stuck is deleted automatically within a few hours.
6.3. Transcripts: deleted automatically at the end of the retention period the customer set (default 90 days). Analysis outputs and metrics are kept, so reports keep working.
6.4. Export: the customer can export call data and analysis outputs (without transcripts) to a file.
6.5. Deleting an organization: the organization's owners request deletion, a 30-day grace period to cancel is given, and at its end all the organization's data is permanently deleted and an audit record is written.
7. Outside providers and artificial intelligence
7.1. The sub-processors are listed in the Privacy Policy. The Service sends them only the information needed for their role.
7.2. For transcription and analysis, the recording (for transcription) and the transcript after hiding (for analysis) are sent to the AI provider through its API, without the request being stored on the provider's side for its own product purposes. Under the provider's policy, information sent through the API is not used to train models.
7.3. The instructions to the models forbid inferring sensitive traits, and model results are checked against a strict schema before being stored.
7.4. The database and code execution are in the European Union (Frankfurt).
8. Application and infrastructure security
- Security headers (HSTS, preventing embedding in a frame, preventing content type sniffing, referrer policy and browser permissions).
- Protection against open redirects, and built-in origin checks for every action that saves information.
- Rate, size and volume limits on the public API and on webhook connections.
- Website scanning (for the business memory) with checks that prevent access to internal addresses at every redirect.
- The database service key is available only to server code.
- Dependency checks on every change, and automated tests before every deployment.
- Minimal database permissions: an anonymous user gets access to no table, and every permission is granted explicitly.
9. Access by the TalkWiz team
9.1. Access by the TalkWiz team to production systems is limited to those who need it, and protected by authentication measures.
9.2. The internal console is for authorized platform admins only, and shows account, usage, billing, settings and call metadata, without call content. Management actions on an account (for example changing a plan, managing users or suspending) are recorded in an audit log.
9.3. The TalkWiz team accesses a customer's content only when needed for support, investigating a fault or a security incident, or by law, and only through a "support session": a temporary membership in the organization as an admin, for up to 24 hours. The account owners are notified by email of every such access, it shows in their user list and can be removed at any time, it is logged and ends automatically. A support session does not receive the customer's reports, alerts or messages. Everyone with access is bound by confidentiality.
10. Logging and control
10.1. Sensitive actions are recorded in an audit log, including creating an organization, users joining, deletion requests, rotating connection keys, changing a call's assignment and campaign changes.
10.2. Every request to an AI model is logged (model, volume, cost and response time), without the call content.
10.3. TalkWiz reviews the security measures and risks from time to time, and updates them as needed.
11. Backup and continuity
Information is backed up automatically by the infrastructure provider, and backups are protected and deleted on a regular cycle. In case of a fault, the Service will be restored from the latest backup. The Service is not meant to serve as the customer's backup or archive (see section 6.7 of the Terms of Use).
12. Security incidents
12.1. Every suspected security incident is investigated, documented and handled: identification, containment, scoping, remediation and lessons learned.
12.2. We will notify the customer of a severe security incident affecting customer data as set out in the Data Processing Agreement, and report to the Privacy Protection Authority when the law requires.
12.3. To report a security vulnerability or a suspected incident: the privacy protection officer, info@talkwiz.app. We welcome responsible disclosure and ask that a vulnerability not be published before it is fixed.
13. Recommendations for customers
- Give every user the minimum permission they need, and remove users who left.
- Use a strong, unique password, and don't share accounts.
- Turn on two-factor authentication, and consider requiring it for every user in the organization (organization settings).
- Replace an API key or webhook address right away if there is any concern it was exposed.
- Set the shortest possible transcript retention period.
- Inform customers and employees about the recording, transcription and analysis, and keep the original recordings in the business's recording system.
- Review AI outputs before relying on them or sending them.