Privacy Policy
- Effective
- 6 October 2026
- Last updated
- Version
- 2026-10-14
Earlier versions
- 2026-10-10: Stated that the website used no analytics. Did not describe Google Analytics, which kultarr.io now uses on its homepage, pricing and contact pages for visitors who agree, and named the cookie inventory at /cookies rather than /cookie-preferences.
- 2026-10-06.1: Described paid purchases as not yet available and billing as starting “once paid transactions launch”, rather than describing how Paddle processes a subscription purchase.
- 2026-10-06: Approved version. Mentioned payments only once a payment provider was live; it did not describe Paddle as the expected merchant of record or how billing records are kept.
- 2026-10-03: Did not separate controller and processor roles by data category, gave no purpose-by-purpose legal basis, described transfers only generically, and stated no retention schedule.
- 2026-09-26: First drafted version. Did not describe stored AWS access keys, the sources of information, IP geolocation, or region-specific rights.
This Privacy Policy explains how personal information is handled when you visit the Kultarr. website, create an account, contact us, or use the Kultarr. cloud-security service (the “Service”). The Service is operated by Ofir Benav, an individual based in Israel, operating the service under the name “Kultarr.” Kultarr. is a service name and is not a separate legal entity. In this Policy, “Kultarr.”, “we” and “us” refer to the operator. The Service is offered to businesses internationally. Israeli law governs our processing as a starting point; where the law of another country applies to your information, this Policy says so in a section of its own, and nothing here removes a right that law gives you.
Contents
- 1. Who we are
- 2. Our two roles
- 3. Information we collect
- 4. Where information comes from
- 5. Cloud access, credentials and remediation
- 6. Purposes and legal bases
- 7. Customer Data, product improvement and AI
- 8. Is providing information required?
- 9. Who receives information
- 10. Service providers
- 11. International transfers
- 12. Retention
- 13. Security
- 14. Your rights
- 15. Cookies and browser storage
- 16. Children
- 17. Changes to this Policy
- 18. Contact and complaints
1. Who we are
For the processing described in section 2 as ours, the controller (in Israeli terms, the database controller) is the operator named below. You can reach the operator about anything in this Policy at the privacy address.
- Operator
- Ofir Benav
- Service name
- Kultarr. (not a separate legal entity)
- Based in
- Israel
- Postal address
- Ofir Benav, Bernstein 29, Rishon LeZion, Israel
- Privacy email
- ofirbe@kultarr.io
- General support
- ofirbe@kultarr.io
2. Our two roles
Kultarr. handles personal information in two different capacities, and which one applies changes who decides how the information is used and who you should ask about it.
| Information | Our role | Who decides why it is processed |
|---|---|---|
| Your account, sign-in and security records; messages and requests you send us; website technical data; billing records | Controller (database controller) | The operator, as described in this Policy. |
| Information read from cloud accounts and repositories an organization connects, and what the Service derives from it (“Customer Data”) | Processor or service provider for the organizational customer | The customer that connected the account, under its agreement with us and, where signed, the Data Processing Addendum. |
When we act as processor, the customer organization is responsible for having a lawful basis and for informing the people whose information its cloud accounts contain. If your information appears in a customer’s cloud account, for example as an IAM user or in a CloudTrail record, please direct questions to that organization; we will pass on any request we receive and help it respond.
Accounts are created for organizations. If your organization invited you, its administrators can see your name, email address, role and activity in its workspace, can change or remove your access, and decide which cloud accounts are connected.
This Policy does not describe the privacy practices of Amazon Web Services, GitHub, payment providers, identity providers or other third parties in their own right. Their own terms and privacy notices apply to their services.
3. Information we collect
Information you give us
- account details: your name, business email address, password (stored only as an Argon2id hash) and the workspace name;
- workspace details: your role, invitations you send or accept, and your preferences in the Service;
- what you send us: privacy requests, accessibility barrier reports, security reports, support messages and feedback, including any contact details you choose to add;
- notes, comments, decisions and other text you enter in the Service about your organization’s environment (this is Customer Data).
Sign-in and security records
- sign-in sessions, with the IP address and browser user agent they were created from;
- sign-in attempts, verification codes issued, multi-factor authentication and account-recovery events;
- an audit log of security-relevant actions in a workspace, with the acting user, time, IP address and user agent;
- server and infrastructure logs of requests to the Service, which can include an IP address, user agent, requested path and time.
Payments through Paddle
Paid subscriptions are processed by Paddle (Paddle.com Market Limited and its affiliates), acting as merchant of record and authorised reseller: you buy from Paddle and enter your payment details in Paddle’s checkout. Kultarr. does not receive full card details. For purchases processed through Paddle, Kultarr. receives from Paddle the information needed to administer them, such as the purchase or subscription status, plan and renewal dates, the billing email address you give Paddle, and Paddle’s customer and transaction identifiers.
Paddle processes buyer and payment information as an independent controller under its own privacy notice (https://www.paddle.com/legal/privacy), including for payment processing, tax compliance, fraud prevention and any transfer it makes outside your country. Paddle is not a subprocessor of Customer Data.
Cloud-security information (Customer Data)
When a customer connects an AWS account, the Service reads, through the access the customer grants:
- account, organization, region and resource identifiers, resource configuration and resource tags;
- IAM users, roles, groups, policies, trust relationships and access-key metadata (never secret keys);
- CloudTrail events: the acting identity, role-session name, action, time, source IP address, user agent and region;
- security-service results the account already produces, such as GuardDuty findings;
- certificate metadata, and the results of connecting to endpoints the customer asks the Service to observe.
From that information the Service derives:
- inventories, findings, permission explanations, investigations and remediation proposals;
- identity sessions: a cloud identity’s CloudTrail activity grouped into sessions;
- activity baselines: per identity, counts of the source addresses, regions, services and hours it usually acts from, against which new activity is scored to highlight what is unusual;
- where a geolocation database is installed with the deployment, an approximate country and network operator (ASN) for source IP addresses. The lookup reads a database file stored with the Service; addresses are not sent to a geolocation provider.
Cloud metadata can contain personal information, and Kultarr. does not treat it as anonymous. IAM user and role names, role-session names, resource tags, policy text and CloudTrail records routinely contain people’s names and email addresses, and source IP addresses and activity patterns relate to identifiable people.
If a customer connects a source-code repository, the Service reads the infrastructure-as-code files and ownership (CODEOWNERS) files it needs, and may open pull requests that propose changes. Repository content can include contributor names and email addresses.
Customers must not connect sources intended to send Kultarr. workload content, passwords, secret keys, private keys, payment-card data, health information or other special categories of personal information. The Service does not ask for them, and certificate monitoring reads publicly presented certificates only: private-key material is redacted from event payloads and logs rather than stored.
Website and browser storage
The website and Service use first-party cookies and browser storage, described in section 15. If you agree, and only on the public website’s homepage, pricing page and contact page, Google Analytics measures visits (section 15). The signed-in Service and the legal and cookie pages never load it. There is no advertising, session-replay, heat-mapping or crash-reporting service, and no other third-party script, font or embed.
4. Where information comes from
- from you, when you create an account, use the Service or contact us;
- from your organization, when an administrator invites you, assigns your role or manages your access;
- from the cloud accounts and repositories a customer connects, through the access that customer grants (section 5);
- from your browser, automatically, when you use the website or Service (section 3);
- from Paddle, for purchases processed through it, which tells us the status of a purchase or subscription and the billing email address the buyer gave it;
- from our email provider, which tells us whether a message was accepted for delivery.
5. Cloud access, credentials and remediation
Collection is read-only
The recommended AWS connection is an IAM role the customer creates in its own account, which Kultarr. assumes with temporary AWS STS credentials and a unique ExternalId. The role Kultarr. publishes for collection grants read permissions only; a test in Kultarr.’s build fails if a permission that can change a resource is added to it. Kultarr. does not ask for, and asks customers not to provide, root credentials.
A customer may instead connect with a long-lived IAM access key, after acknowledging the additional risk. In that case the permissions are whatever the customer attached to that key: Kultarr. uses it only for the same read operations, but cannot itself limit what the key would allow. The secret access key is stored only in AWS Secrets Manager, encrypted with an AWS KMS key dedicated to customer credentials; it is not kept in the application database, is never displayed again, and cannot be retrieved through the Service. When the key is replaced, the connection moves to a role, or the account is disconnected, Kultarr. deletes its copy, which AWS removes permanently after a seven-day recovery window. That does not revoke the key in AWS; the customer should disable or delete it there.
Remediation is proposed, not applied
The Service does not currently change anything in a customer’s AWS account, in any remediation mode. It explains problems, prepares proposed changes and, where a repository is connected, opens a pull request for a person to review, merge and deploy. Kultarr. also documents an optional second role, separate from the collection role, that a customer may choose to deploy; it permits one action, removing an inbound rule from a security group, and only on security groups the customer has tagged to opt in. The Service does not currently use that role to make changes.
A repository connection, unlike the AWS collection role, is granted permission to write: the token must allow creating branches and pull requests so that Kultarr. can propose a change for a person to review. The Service cannot merge a pull request. Repository tokens are stored encrypted and are never returned to the browser.
6. Purposes and legal bases
We use the information for which we are controller only for the purposes below. The third column applies where the EU GDPR or the UK GDPR governs our processing of your information; it does not mean that those laws apply to every user.
| Purpose | Information used | Legal basis (GDPR / UK GDPR, where applicable) |
|---|---|---|
| Creating and running your account and workspace, and providing the Service you or your organization signed up for | Account and workspace details | Performance of a contract (Article 6(1)(b)); for invited users, our and the customer’s legitimate interest in providing the workspace it asked for (Article 6(1)(f)) |
| Authenticating you, securing accounts and the Service, detecting abuse, and keeping an audit trail | Sign-in and security records, request logs | Legitimate interests in protecting users and the Service (Article 6(1)(f)); legal obligation where information-security law requires the records (Article 6(1)(c)) |
| Sending account email: address verification, sign-in and recovery codes, password resets, invitations | Name, email address, workspace name | Performance of a contract (Article 6(1)(b)) |
| Answering privacy, accessibility, security and support requests | What you send us and your account details | Legal obligation where the request is a statutory right (Article 6(1)(c)); otherwise legitimate interests in responding (Article 6(1)(f)) |
| Administering purchases and subscriptions and keeping billing records | Purchase or subscription status, billing email, Paddle identifiers | Performance of a contract (Article 6(1)(b)); legal obligation for tax and accounting records (Article 6(1)(c)); legitimate interests in preventing fraud and handling disputes (Article 6(1)(f)) |
| Measuring how the public website is used, only if you agree | Public pages viewed, the referring site, browser and device information, an approximate location derived from your IP address, and a random identifier kept in a cookie | Consent (Article 6(1)(a)), which you can withdraw at any time on the cookie page |
| Maintaining and improving the Service | Aggregated or de-identified information and Service operational data (section 7) | Legitimate interests in a reliable, secure and useful Service (Article 6(1)(f)) |
| Complying with law and establishing, exercising or defending legal claims | Any of the above, as needed | Legal obligation (Article 6(1)(c)); legitimate interests (Article 6(1)(f)) |
Where we rely on legitimate interests, you may object, as section 14 explains. We do not currently send marketing email; if we start, we will ask first wherever law requires consent, and every message will carry a way to stop.
For Customer Data, we process on the customer’s documented instructions, and the customer determines the legal basis.
7. Customer Data, product improvement and AI
Kultarr. processes Customer Data only to provide, secure and support the Service for the customer that connected it, on that customer’s instructions, and as the law requires.
Kultarr. does not use raw Customer Data to develop or improve the Service for other customers. To maintain and improve the Service, Kultarr. may use (a) information about how the Service itself operates, such as error rates, job timings and which features are used, and (b) aggregated or de-identified information derived from Customer Data that cannot reasonably be used to identify the customer or any individual, and that Kultarr. does not attempt to re-identify.
Kultarr. does not use Customer Data to train a general-purpose artificial-intelligence model, and does not send it to an artificial-intelligence provider, unless the customer has separately and expressly agreed to that in writing.
8. Is providing information required?
No law obliges you to give us personal information. Some information is needed to provide the Service: without a name, business email address and password we cannot create an account, and without the information requested in a privacy, accessibility or security form we may be unable to act on it or reply. Fields that are optional are marked as such where they are collected, and each form shows a short notice explaining this at the point of collection.
The Service analyses cloud activity to help a person investigate it. It does not make decisions that produce legal or similarly significant effects about any individual: scores and baselines highlight activity for a human to review, and every conclusion and action is a person’s.
9. Who receives information
We disclose personal information only:
- to service providers that process it for us under contract, listed in section 10 and on the subprocessor page;
- to Paddle, as merchant of record for purchases processed through it; Paddle receives purchase and payment details directly from you and processes them as an independent controller under its own privacy notice;
- to Google, which provides Google Analytics to us, only if you agree to analytics cookies on the public website (section 15);
- within a customer’s workspace, to its authorized administrators and users;
- to the provider of the mailboxes our contact addresses use, when you write to them or a form is sent to them;
- to professional advisers bound by confidentiality, such as lawyers and accountants;
- where required by law or an enforceable request of a competent authority, and where reasonably necessary to protect people, the Service or legal rights;
- to a person who takes over operation of the Service, subject to this Policy and to notice where required;
- otherwise, at your direction or with your consent.
Kultarr. does not sell personal information, does not share it for cross-context behavioral advertising, and does not use it for targeted advertising. If that ever changed, this Policy, and any opt-out the law requires, would change first.
10. Service providers
Service providers receive only what their function needs and are contractually bound to process it on our instructions and protect it. The current list, with what each provider does and where it stores data, is published at https://kultarr.io/subprocessors. Today they are Amazon Web Services (hosting and infrastructure) and Resend (account email). Kultarr. will provide at least 30 days’ advance notice before a new subprocessor begins processing Customer Data, as the Data Processing Addendum describes.
The terms on which we process personal data for business customers are in the Data Processing Addendum at /dpa. A signed copy can be requested at ofirbe@kultarr.io.
11. International transfers
Hosting in the United States
The Service’s database, backups, stored credentials and related application infrastructure are hosted in the United States using Amazon Web Services infrastructure. The hosting location is set for the Service as a whole. Customers cannot choose a different location, and it is not a contractual data-residency commitment unless one is agreed in writing.
Where the GDPR or UK GDPR applies to the information, the transfer to Amazon Web Services in the United States relies on the Standard Contractual Clauses (and UK Addendum) included in the AWS Data Processing Addendum.
Israel
The Service is operated, administered and supported from Israel, so information hosted in the United States is accessed from Israel. The European Commission has recognized Israel as providing an adequate level of protection, and the United Kingdom recognizes Israel as adequate for UK transfers, so transfers from the EEA or UK to the operator in Israel rely on those adequacy findings.
Email delivery
Account email is sent through Resend. Resend stores account data, message content, delivery logs and related records in the United States, whichever region a message is sent from. Where the GDPR or UK GDPR applies, that transfer relies on the Standard Contractual Clauses (and UK Addendum) in Resend’s data processing agreement, and on Resend’s participation in the EU-U.S. Data Privacy Framework and its UK extension.
Payments
Paddle processes buyer and payment information as an independent controller under its own privacy notice (https://www.paddle.com/legal/privacy), including for payment processing, tax compliance, fraud prevention and any transfer it makes outside your country. Paddle is not a subprocessor of Customer Data.
Website analytics
If you agree to analytics cookies, Google LLC and its affiliates process the measurement data described in section 15, including in the United States. Where the GDPR or UK GDPR applies, that transfer relies on Google LLC’s participation in the EU-U.S. Data Privacy Framework and its UK extension, and on the Standard Contractual Clauses in Google’s data processing terms.
Transfers from Israel
Transfers of information from databases in Israel to service providers abroad are made under the Privacy Protection (Transfer of Data to Databases Abroad) Regulations, 5761-2001, on the basis of the providers’ written data-protection undertakings.
12. Retention
We keep personal information only as long as needed for the purposes in section 6, including security, audit and legal obligations. The periods below apply to information for which we are controller, and to Customer Data unless the customer’s agreement says otherwise.
| Information | Retention period | How the period is applied today |
|---|---|---|
| Account and workspace details, including inactive accounts | 24 months after the account or workspace becomes inactive, unless deleted earlier or retention is required by applicable law. | Not yet automated. No job deletes this information on this schedule yet; until one does, it is kept until the workspace is deleted, or deleted earlier on request. |
| Sign-in attempts, audit log and other security records | 24 months from creation, unless a longer period is reasonably required for an active security investigation or by applicable law. | Partly automated. Sign-in sessions, with their IP address and user agent, are removed automatically 30 days after they expire; rate-limiting records of sign-in attempts are removed once they can no longer affect a limit. The workspace audit log is not yet deleted on this schedule and is kept until the workspace is deleted. |
| Application and infrastructure logs, which can include IP addresses, user agents and account identifiers | 12 months. Records of administrative activity in the AWS account that hosts the Service: 24 months. | Automatic. |
| Cloud inventory and configuration history | 12 months on a rolling basis, unless the Customer configures a shorter supported retention period. | Not yet automated. No job deletes this information on this schedule yet; until one does, it is kept until the workspace is deleted, or deleted earlier on request. |
| Findings, investigations and notes | For the duration of the workspace and for up to 30 days following termination or deletion of the workspace, unless deleted earlier at the Customer’s request or retention is required by applicable law. | Applied by the operator, who deletes the workspace’s data after termination. Self-service deletion is not yet available. |
| Raw and normalized security evidence, including CloudTrail events | 90 days on a rolling basis, unless the Customer configures a shorter supported retention period or evidence is preserved as part of an active investigation. | Not yet automated. No job deletes this information on this schedule yet; until one does, it is kept until the workspace is deleted, or deleted earlier on request. |
| Identity sessions and activity baselines | The workspace’s identity-session setting, 180 days unless an administrator changes it. Sessions linked to an investigation that is still open are kept until it is resolved. | Automatic. |
| Stored AWS access keys | Until replaced or disconnected; then permanently deleted after a seven-day recovery window. | Automatic. |
| Support, privacy, accessibility and security correspondence | 24 months after the relevant request or case is closed, unless longer retention is reasonably required for legal, regulatory or security purposes. | Applied by the operator. Correspondence is held in the operator’s mailbox, not in the Service’s database. |
| Billing and transaction records | As long as necessary to meet legal, accounting and tax obligations, to administer transactions, to prevent fraud and to handle disputes, subject to applicable law. | Applied by the operator; not automated. |
| Website measurement data held by Google Analytics, for visitors who agreed | Up to 14 months for data tied to the cookie identifier. The cookies themselves last 13 months from your last visit. | Applied by Google, under the retention setting of the Google Analytics property. Withdrawing consent stops collection and removes the cookies; it does not delete data already collected. |
| Backups | Up to 35 days. | Automatic. Database backups are kept for 30 days and then expire. |
| Completing a deletion after a request or after termination | Data deleted from the live Service may remain in encrypted backups until those backups expire. Such backup copies are deleted through the normal backup-expiration process within 35 days after deletion from the live Service, unless applicable law requires longer retention. | Deletion from the live Service is carried out by the operator; backup expiry is automatic. |
Where the table says a period is not yet automated, that period is our retention policy, but the Service does not yet delete the information on that schedule, so it may currently be kept for longer, until the workspace is deleted. You can ask us to delete information sooner (section 14).
Workspace administrators can also set retention targets for categories of evidence in the Service’s Data & Privacy settings. Only the identity-session setting is enforced automatically today; the settings page says so for the others.
After termination, the customer may request an export of available Customer Data for up to 30 days. After that period, Customer Data is deleted in accordance with this Policy and the Data Processing Addendum, except where applicable law requires retention. When a workspace is deleted, its data is deleted from the database in one operation, including its audit log, and a check confirms nothing is left behind. Application and infrastructure logs are not backups; identifiers they contain are deleted when those logs expire, as the table shows. When information is no longer needed it is deleted or irreversibly de-identified, unless the law requires us to keep it.
13. Security
Safeguards in place include: HTTPS with TLS 1.2 or later; encryption at rest of the database, backups, logs and stored credentials with AWS KMS keys; tenant isolation enforced in application queries and by database row-level security; Argon2id password hashing; multi-factor authentication; role-based access control enforced on the server; rate-limited sign-in; secret redaction in logs; and least-privileged cloud access.
No service can guarantee absolute security. Customers remain responsible for their own accounts, identity provider, devices, cloud environments and authorized users, and should report suspected compromise promptly.
Kultarr. holds no ISO 27001 certification, SOC 2 report or other third-party security certification, and does not claim to be certified as compliant with the GDPR, the CCPA or any other framework. Where a safeguard is described, it is implemented in the Service; it has not been attested by an independent auditor.
14. Your rights
Signed-in users can make a request at /privacy-requests, which ties it to their account. Anyone can write to ofirbe@kultarr.io. We may need to verify your identity and authority before acting, and we will tell you if we keep information after a request, and why. Where we process information only as a processor for a customer, we will refer your request to that customer and help it respond. Consent to analytics cookies can be withdrawn at any time at /cookie-preferences, without affecting anything measured before.
Everyone
Whatever law applies, you can ask what information we hold about you, ask us to correct it, and ask us to delete what we do not need to keep. Some records cannot be deleted on request, such as security and audit records we must keep or records that belong to a customer’s workspace. Where that applies, we will say so. We will not treat you worse for exercising a privacy right.
Israel
Under the Protection of Privacy Law, 5741-1981, you may inspect information about you held in a database, and ask for it to be corrected or deleted if it is not correct, complete, clear or up to date. You may complain to the Privacy Protection Authority.
European Economic Area and United Kingdom
Where the GDPR or the UK GDPR applies to our processing of your information, you also have the rights of access, rectification, erasure, restriction, objection and data portability, and the right to withdraw consent where processing is based on consent, each on the conditions in that law. You may complain to a supervisory authority, or in the UK to the Information Commissioner’s Office.
United States
Where a US state privacy law, such as the California Consumer Privacy Act as amended, applies to Kultarr. and to you, you may have rights to know, access, correct and delete personal information and not to be discriminated against for exercising them. The categories of information we collect, their sources, our purposes and the categories of recipients are in sections 3, 4, 6 and 9. We do not sell or share personal information as those laws define it, and do not use sensitive personal information to infer characteristics about anyone.
Rights that applicable law makes mandatory cannot be waived by this Policy or by any agreement.
16. Children
The Service is for business and professional use and not for children. Account holders must be at least 18. If we learn that a child’s information was collected contrary to this, we will delete it.
17. Changes to this Policy
When this Policy changes, its version and “Last updated” date change, and earlier versions are listed at the top of the page. Material changes will be notified through the Service or by email before they take effect, and where the law requires your agreement we will ask for it.
18. Contact and complaints
- Operator
- Ofir Benav
- Service name
- Kultarr. (not a separate legal entity)
- Based in
- Israel
- Postal address
- Ofir Benav, Bernstein 29, Rishon LeZion, Israel
- Privacy email
- ofirbe@kultarr.io
- General support
- ofirbe@kultarr.io
You may also complain to a data-protection authority. In Israel that is the Privacy Protection Authority. Where the GDPR applies, you may complain to the supervisory authority where you live, work or where the alleged infringement occurred; where the UK GDPR applies, to the Information Commissioner’s Office.