Privacy Policy

Account and administrator data. When someone registers, is invited or signs in: name, work email address, job title (optional), role, organization name, and the sign-in method used. Sign-in is by a one-time emailed link, by Microsoft or Google sign-in, or by the single sign-on (SAML or OpenID Connect) Customer configures; we never see or store a Microsoft or Google password.

Directory data. When Customer connects Microsoft 365, Google Workspace, BambooHR, Workday or ServiceNow, provisions people through SCIM, or imports a CSV file, we synchronize the profile fields needed to build and address signatures: name, email address and aliases, job title, department, office location, phone numbers and profile photo. Where the source supplies them we also read the person's language and country, and whether the account is enabled, and, for Microsoft 365 and Google Workspace, group membership used to assign templates by group. Customer can switch most of these fields off per connection in Settings. We do not synchronize a manager field. Synchronization runs on the schedule Customer configures. Administrators, and the people themselves where Customer allows it, can also add details that appear in a signature, such as pronouns, a personal website, booking and social links, and professional details such as credentials or license numbers. If Customer turns on the optional ServiceNow photo write-back, we write each person's profile photo to their ServiceNow user record. If Customer turns on the optional Gravatar lookup for a directory connection (it is off by default), then for a person with no photo we check Gravatar, a public avatar service run by Automattic, Inc., for a picture registered to that person's work email address, by sending Gravatar a one-way (MD5) hash of the address; if one exists, we store a copy and use it as the person's profile photo, which an administrator or the person can replace or remove.

Mailbox signature settings. To verify that a deployed signature is actually in place, for Google Workspace the Service reads (and, when Customer deploys, writes) the Gmail signature settings of connected mailboxes through the Gmail API. For Microsoft 365 the Service creates and maintains an Exchange transport rule in Customer's tenant that appends the signature at the mail server, and reads that rule back to verify it; it does not read or write individual Microsoft 365 mailboxes. Where Customer uses the Exchange rule on a plan that includes verification, the Service also reads Exchange's rule report and message trace to count how many outbound messages the rule applied to; it reads sender and recipient addresses only momentarily, to reduce them to domains, and stores only daily counts, never addresses, subjects or message text. Unless Customer turns on Cloud signatures (described next), we do not read the content of employees' email, and the Service does not route it. A person may also choose to send one test email from their own mailbox to a one-time address the Service owns, to see whether their signature is on it. We read that message once to see whether the signature's text and images are on it and then discard it. We keep the result (whether the signature was found, and how much of its text and which of its images), the time, whether the message came from that person's own address, and the kind of mail client it came from; never the message, its subject, its text or any other part of it, and never for longer than the period stated on the test page. Apart from the routed email of a workspace that turns on Cloud signatures, that message is the only one that would ever reach the Service.

Routed email (only where Customer turns on Cloud signatures). Cloud signatures is optional and off unless Customer's administrator sets it up. When it is on, outgoing email that matches a routing rule Customer's administrator approves passes through our relay, which reads each message in memory to add the sender's signature and returns it to Customer's own mail system for delivery; Customer's mail system remains the sending server, and the relay never delivers mail to recipients itself. We do not store the message. We keep a record that each copy was delivered (a one-way hash combining Customer's relay identifier, the message's Message-ID and the recipient group) so that a retry is not signed twice, and delete it automatically after seven days; daily message counts; and the prepared signatures the relay uses, looked up by a one-way hash of the sender's address, which is pseudonymised, not anonymised.

Add-ins. The Bantusign Outlook add-in and Gmail add-on identify the signed-in person to us with a Microsoft or Google sign-in token and fetch that person's signature. The Outlook add-in works on the message being written on the person's own device and does not send us its text; it sends us a short receipt for each signature it inserts or each send it flags (the signature version, the type of Outlook client and how it was inserted) and, for a shared mailbox, that mailbox's address.

Signature and campaign content. Templates, banners, images and other brand assets Customer's administrators create or upload, including AI-generated drafts they accept.

Engagement data. Deployed signatures can contain tracked links and a tracking image. (1) When a link in a signature is clicked (a campaign banner, or a social-profile, website, email or phone link), we record the click, the campaign or link type, the sending employee's department and the time. (2) When a signature that carries a live campaign is displayed, the recipient's email app asks us for a one-pixel image that is invisible to the reader, and we record that the campaign was viewed, the sending employee's department and the time. Email apps and image proxies can load that image automatically, so a view count is an estimate and does not prove that a person read the message. For banner clicks we also add one to a count for a coarse category of the recipient's email app (for example Outlook, Gmail, Apple Mail or Other), worked out from the browser and referrer information sent with the click and then discarded. In our engagement records we do not store the recipient's IP address, the browser information itself, or the exact device, browser version or operating system. To avoid counting the same person twice in a day we keep a one-way hash derived from the connection and browser details with a key that changes every day, so it cannot identify anyone or follow them from one day to the next. Attributing a click to a recipient address happens only if Customer switches that option on, and even then we store a one-way hash of the address, never the address itself.

Render-test data. When a person in Customer's organization saves or runs a render test, the signature is rendered with the real signature details of one person in Customer's organization (the person who ran the test or, if that is not possible, an active administrator): name, title, phone number, email address, photo, logo and any live campaign banner. Those renders are made and screenshotted on our own servers; the screenshots are stored privately with the template, show the signature of the person it was rendered for, stay on our servers and are shown only to Customer's own administrators. The automatic review of visual defects (Section 4) looks at a separate rendering of the design made with fictional sample details, never the person. The one render sent to an external email-client rendering service (Mailgun, Section 5) is different: by default it carries Customer's signature design (the layout, the brand colors and fonts, the template's own footer wording) with fictional sample details and our own sample images in place of the person, the photo and the logo, and no campaign banner. Only where Customer has asked us in writing to enable it for its environment does that external render carry the real person's details instead.

Billing data. Plan, seat count, invoices and payment status. Card details are collected and stored by our payment processor, Stripe; we never receive full card numbers.

Support and contact data. What you send us through the contact form, a support conversation or email, including your name, work email and company.

Usage and log data. Technical data generated by using the Service: IP address, browser and device type, pages visited, request logs, and the audit trail of account, billing and signature changes (who changed what, and when) that Customer can see in its own audit log.

• To provide the Service: rendering and deploying signatures, verifying coverage, detecting drift, syncing directories, running campaigns and producing the reports Customer requests.
• To provide AI-assisted features (Section 4).
• To bill for the Service and manage subscriptions through Stripe.
• To provide support and respond to inquiries.
• To secure the Service, prevent abuse and fraud, and keep the audit log.
• To send service notices (for example, a billing, security or trial-ending notice) to administrators.
• To comply with law and enforce our Terms.

We do not sell personal data, we do not use it for advertising, and we do not use Customer Data to train AI models.

Where the GDPR, UK GDPR or Swiss FADP applies, we process personal data to perform our contract with Customer (providing the Service), for our legitimate interests (security, fraud prevention, improving the Service, and communicating with business contacts), to comply with legal obligations, and, for the optional click attribution described in Section 1, on the basis of the consent Customer is responsible for obtaining. Where Customer is the controller, Customer determines the legal basis for the employee data it connects.

Some features use AI models provided by Anthropic. We send Anthropic only what each feature needs:

• Help assistant (any signed-in user, any plan): the question you type and the earlier messages in that conversation. It has no access to account data, and you should not type personal data into it.
• Drafting and suggestions (Growth plan and above): for campaign copy, taglines and recommended templates, the organization's name, industry, size, largest department names and brand font, a campaign's name, link, text and target departments, and any instructions the administrator types.
• Compliance checks (Growth plan and above on request, and, on the Enterprise plan, an automatic daily scan): a signature template rendered with a placeholder person rather than a real employee, the organization's regulatory region and, for the scan, the template's footer text.
• Render-test review (all plans, automatic): screenshots of a separate rendering of Customer's signature design made with fictional sample details and our own sample images, never the person used in the render test (Section 1, Render-test data); and, if an administrator asks for Fix with AI (Growth plan and above), the text of the rendering problems.
• Role-equivalence suggestions (when one organization is linked to another as a subsidiary): the job titles, without names, of both organizations.

Anthropic does not use this data to train its models. Output is a draft or advisory for a human to review before it is published or acted on.

We share personal data only with the providers needed to run the Service, under contracts that restrict their use of it:

• Microsoft Azure (United States): hosting, database, file storage, queues, secrets management, monitoring, and the email service that delivers sign-in links and notifications.
• Amazon Web Services (United States): only where Customer has turned on Cloud signatures, the relay that adds signatures to the outgoing email Customer's Exchange Online or Google Workspace routes to it, in memory, before returning each message to that same mail system.
• Stripe: payment processing and invoicing.
• Anthropic: the AI-assisted features in Section 4.
• Knock: in-app and email notification delivery.
• Cloudflare: bot protection (Turnstile) on sign-in and the contact form.
• Mailgun: render testing of signature templates in a real Outlook client, by default with Customer's signature design and fictional sample details, never the person (Section 1, Render-test data); delivery of the notification emails sent through Knock; receiving the one test email a person chooses to send to their own one-time test address (Section 1).
• Gravatar (Automattic): the one-way address hash described in Section 1, only where Customer has turned on the Gravatar lookup and a person has no photo.
• Microsoft 365, Google Workspace, BambooHR, Workday, ServiceNow: only when Customer connects one, to read directory data (and, for ServiceNow, to write profile photos if Customer turns that on) and, for Microsoft 365 and Google Workspace, to read or write mailbox signature settings, using the permissions Customer grants.

We may also disclose personal data when required by law or legal process, to protect the rights, safety or property of Bantusign, our customers or others, and to a successor in a merger, acquisition or sale of assets, in which case we will give notice as described in Section 13. A current list of sub-processors is also published on our Security page; we will update it and email Customer's administrators at least 30 days before adding a sub-processor that will process Customer Data, so that Customer can object or end the Service.

The Service is hosted in the United States. If you are outside the United States, your personal data is transferred to and processed there. For personal data from the EEA, UK and Switzerland we rely on the European Commission's Standard Contractual Clauses (with the UK Addendum and Swiss amendments where applicable), If Customer needs a Data Processing Addendum, please contact info@bantuvrse.com.

We keep Customer Data for as long as Customer maintains an account. Campaign click and view records, the daily email-app counts and expired invitations are purged automatically after the retention window Customer configures in Settings, or kept with the rest of the account if no window is set. Directory data is refreshed on every sync. When a person is deactivated or leaves the directory, their details are kept unless Customer has set an offboarded-employee retention period in Settings (30 days to 10 years), after which their personal details are removed; Customer can also remove a person at any time. Disconnecting a directory stops synchronization but does not remove the people already synchronized, and the connection's stored credentials are kept, inactive, until Customer deletes its account.

Customer can request deletion of its account and Customer Data at any time from Settings. We review the request and, once we approve it, the account can no longer be used and we delete the account, its data and every file Customer uploaded 30 days after approval. Deletion does not reach every copy at once: for 14 days after a file is deleted, our cloud storage provider keeps it recoverable on its own systems, and our database backups are kept for 7 days, after which our database provider can keep the underlying backup files for a short further period. Billing records and the audit log are retained for up to seven years as required for legal, tax and fraud-prevention purposes, with personal identifiers removed from the retained record at deletion.

We review every account that has been suspended for 12 months: we email Customer's administrators to ask whether the account should be kept or deleted, and we delete it when Customer asks, as described above. Administrator, website and support data is kept for as long as needed for the purpose it was collected, then deleted or anonymized. Server logs are kept for 30 days.

Routed email (Cloud signatures, Section 1) is not retained. Its delivery records are deleted automatically after seven days, and the prepared signatures held for the relay are deleted within one day of Customer turning Cloud signatures off.

Depending on where you live, you may have the right to access, correct, export, restrict or object to the processing of, or delete your personal data, and to withdraw consent where processing is based on consent. You will not be discriminated against for exercising these rights.

If your employer or another organization manages your data through Bantusign, please contact that organization first: it controls the data and can act on it directly. You can also write to us at info@bantuvrse.com and we will route your request to the right place and support that organization in responding. If you hold a Bantusign account yourself, an administrator can export the account's data from Settings as a ZIP of CSV and JSON files (people, signature templates and their layouts, campaigns, deployments, coverage, the audit log and settings; images are listed by address and are not included) and can request deletion of the account's data.

We respond to verifiable requests within the time required by applicable law (for example, 30 days under the GDPR and 45 days under the CCPA). If you are in the EEA or UK you may also lodge a complaint with your local supervisory authority.

We use only strictly necessary cookies and browser storage: what is needed to keep you signed in (a session token held in your browser's session storage, or, where we have turned on cookie sessions, a secure cookie that only our server can read), to remember interface preferences, and the cookie set by Cloudflare Turnstile to tell people from bots on sign-in and the contact form. When you sign in with Microsoft or Google, those providers set their own cookies under their own policies. We do not use advertising cookies or third-party analytics trackers on the website or in the application.

Each customer's data is isolated at both the application and the database layer. Data is encrypted in transit (TLS) and at rest. Credentials that Customer gives us for connected systems are encrypted, with the encryption keys held in a managed key vault, and are never exposed to browsers. Logos, banners, signature image blocks and profile photos that appear in signatures are stored at web addresses that anyone who has the address can open, because recipients' email apps must be able to load them; the addresses contain a random identifier and are not listed publicly. Files that are not part of a signature, such as support attachments and render-test screenshots, are private and are shown only through short-lived addresses issued after we check who is asking. Access to production is limited to the people who operate the Service and is logged. Details are on our Security page. No method of transmission or storage is completely secure, and we will notify affected Customers without undue delay if we become aware of a breach affecting their data.

We do not sell or share personal data for cross-context behavioral advertising, and we do not use or disclose sensitive personal data for purposes other than providing the Service. California residents may exercise the rights in Section 8, including the right to know the categories of personal data we collect (those listed in Section 1), the sources (you, your organization and the systems it connects), the business purposes (Section 2) and the categories of recipients (Section 5). Residents of other US states with comparable laws have equivalent rights. You may use an authorized agent to make a request on your behalf.

The Service is for businesses and is not directed at children. We do not knowingly collect personal data from anyone under 16.

We may update this Policy to reflect changes in the Service, our sub-processors or the law. The effective date at the top shows when it last changed. For material changes we will notify Customer's administrators in the application or by email before the change takes effect.

Bantuvrse, LLC (Bantusign), 5900 Balcones Drive #29306, Austin, TX 78731, United States. info@bantuvrse.com