This page describes the technical and organizational measures ("TOMs") that VENDI AI LTD, doing business as Obert, maintains to protect Personal Data processed through the Obert platform. It is the document referenced as the "Security Documentation" in our Data Processing Agreement, and it serves as Annex II of the Standard Contractual Clauses incorporated into that DPA.

These measures are implemented in accordance with Article 32 of the GDPR, taking into account the state of the art, the costs of implementation, and the nature, scope, context and purposes of processing. We may update this page as our infrastructure evolves. We will not materially reduce the overall level of security described here during the term of a customer agreement.

Where your data lives, in short

Obert's production infrastructure runs inside the European Union, in Frankfurt, Germany. Customer Data is stored in the EU by default, in an EU-managed PostgreSQL database.

Obert is operated by VENDI AI LTD, a company established in Israel. Israel is the subject of a European Commission adequacy decision under Article 45 of the GDPR, adopted in 2011 and confirmed in the Commission's review of existing adequacy decisions published in January 2024. Transfers of Personal Data from the EEA to Israel therefore require no additional transfer safeguards such as Standard Contractual Clauses.

A limited number of sub-processors process Personal Data in countries that are not covered by an adequacy decision. Each is named, with its purpose and location, in Schedule 2 of the DPA, and those transfers are covered by the Standard Contractual Clauses incorporated into the DPA.

1. Data residency and hosting

Obert's core application, database, queueing, and worker infrastructure is hosted on Render (Render Services, Inc.) in the European Union, Frankfurt region.
Customer Data is stored in a Render-managed PostgreSQL 17 database located in Frankfurt, Germany.
Obert does not operate its own physical data centres. Physical and environmental security controls are inherited from the underlying cloud provider infrastructure, which is subject to independent third-party audit.
A limited number of sub-processors process Personal Data outside the EU. Each is listed, with its processing location, in Schedule 2 of the DPA. Transfers outside the EEA are covered by the Standard Contractual Clauses incorporated into the DPA, or by an applicable adequacy decision.

2. Data flow and retention at a glance

Stage	Encryption	Purpose	Retention
Ingress API, CSV import, LinkedIn and email connectors, website visitor tracking, webhooks	TLS 1.2 or higher	Receive lead, account, and engagement data	Held only for as long as needed to complete ingestion, then discarded or written to storage
Processing Signals, ICP scoring, AI drafting and classification	TLS in transit, AES-256 at rest	Qualify leads, score fit, draft and classify outreach	Duration of the subscription. Model provider processes for inference only, with no training on Customer Data
Storage PostgreSQL, Frankfurt	AES-256 at rest, plus application-level encryption for credential material	Campaign execution, reporting, CRM sync	Duration of the subscription, then 7 days to purge production and 35 days for backups to roll off
Egress LinkedIn, email, outbound webhooks, CRM sync	TLS 1.2 or higher	Deliver messages and synchronise records	Copies persist in the customer's own channels and systems, outside Obert's control
Telemetry Errors, traces, product analytics	TLS in transit, AES-256 at rest	Reliability, debugging, abuse detection	90 days for error and trace telemetry, 12 months for product analytics

3. Encryption, pseudonymisation and data minimisation

3.1 Data in transit

All traffic between users and the Obert application and API is encrypted using TLS 1.2 or higher. Plaintext HTTP connections are redirected to HTTPS at the platform edge.
Connections between Obert services and the database, cache, and workflow engine take place over encrypted internal networking within the Frankfurt region.
Connections to third-party APIs and sub-processors are made over TLS.

3.2 Data at rest

Database storage and backups are encrypted at rest at the platform layer using AES-256.
In addition to storage-level encryption, Obert applies application-level encryption (Fernet, AES-128 in CBC mode with HMAC-SHA256 authentication) to high-risk credential material before it is written to the database. Encryption keys are held in the environment secret store and are never committed to source control.
Fields protected by application-level encryption include: OAuth access and refresh tokens for connected integrations (HubSpot, Pipedrive, Slack, GitHub), email mailbox credentials, outbound webhook signing secrets, and stored custom request header values.
Credentials for connected LinkedIn and email sending accounts are held by our communications sub-processor. Obert stores only an opaque account reference, not the underlying platform credentials.
Payment card data is never transmitted to or stored by Obert. Card processing is handled entirely by our PCI DSS compliant payment sub-processor.

3.3 Pseudonymisation and data minimisation

The Services process only the categories of Personal Data described in Schedule 1 of the DPA. Customers determine what data they import and can delete it at any time.
Records are keyed by opaque, system-generated identifiers rather than by directly identifying attributes, so internal references to a data subject do not themselves reveal identity.
Where Obert integrates with a third-party platform on a customer's behalf, it holds an opaque account reference rather than the underlying platform credential.
Payment data is tokenised by the payment sub-processor and does not reach Obert's systems.
Customer Data is not used to train foundational or general-purpose machine learning models. AI features transmit data to our model provider for inference only.

4. Access control

4.1 Customer access

Authentication is provided by Descope, a dedicated identity platform. Obert does not store user passwords.
Users authenticate with a one-time email code or federated Google sign-in. Sessions are issued as short-lived signed JWTs and validated on every API request.
SAML 2.0 and OIDC single sign-on, including Okta, Microsoft Entra ID, and Google Workspace, and SCIM user provisioning and deprovisioning, are available on Enterprise plans and are enabled on request.
Programmatic access uses scoped API access keys issued through the identity provider. Keys are stored as references and hints only, never in retrievable cleartext, and can be revoked by a workspace administrator at any time.
Workspaces support role separation between administrators and members. Sensitive operations, including workspace deletion and outbound webhook configuration, are restricted to administrators.

4.2 Tenant isolation

Obert is a multi-tenant application. Every record containing Customer Data carries a workspace identifier, and all authenticated requests resolve to a single workspace context that scopes data access.
Customer Data belonging to one workspace is not accessible to users of another workspace through the application or API.

4.3 Internal access

Access to production systems and Customer Data is limited to the minimum number of personnel who require it to operate the service, on a documented need-to-know basis, and is granted according to the principle of least privilege.
Production secrets are held in the hosting platform's encrypted environment secret store. They are not stored in source control and are not distributed to personnel who do not require them.
Production secrets and credentials are rotated at least annually, and immediately on suspected compromise or on the departure of personnel who had access to them.
Access rights and role assignments are reviewed quarterly, and access is revoked promptly on role change or departure.

5. Personnel security

All personnel and contractors with access to Personal Data are bound by written confidentiality obligations that survive the end of their engagement.
Personnel complete security and data protection awareness training when they join and at least annually thereafter.
Obert carries out pre-engagement screening of personnel who will have access to production systems, to the extent permitted by applicable law.
Personnel are instructed to report suspected security incidents without delay, and the internal reporting route is documented.
On departure, access to production systems, source control, the identity provider, and company communication tools is revoked as part of a documented offboarding process.

6. Endpoint and device security

Devices used to access production systems require full-disk encryption, automatic screen lock, and a supported, patched operating system.
Administrative accounts on the hosting platform, source control, and the identity provider require multi-factor authentication.
Production systems are not accessed from shared or unmanaged devices.

7. Application security

The API enforces authentication on all customer data endpoints. Requests without a valid session or access key are rejected.
Cross-origin access to the API is restricted to an explicit allowlist of Obert origins.
Public ingestion endpoints, such as the website visitor tracking collector, are rate limited per site and source address to protect against abuse and flooding.
Outbound webhooks are signed with a per-endpoint secret so that receiving systems can verify authenticity, and secrets support rotation with an overlap period.
Database access uses parameterized queries through an ORM, which protects against SQL injection.

8. Vulnerability and patch management

Application dependencies are pinned in lockfiles and monitored for published vulnerabilities through automated dependency scanning. Alerts are routed to the engineering team and triaged by severity.
Remediation targets, measured from the point at which Obert becomes aware of a vulnerability affecting production: critical within 7 days, high within 30 days, medium within 90 days. Where a fix is not available within the target, Obert applies a compensating control and records the exception.
Security-relevant patches are prioritised ahead of routine work. Patching of the underlying operating system, container runtime, and managed database is performed by the hosting provider.
An independent penetration test of the production application is carried out at least annually. Material findings are remediated on a risk-prioritised basis, and a summary is available to customers on request.

9. Logging and monitoring

Application errors and exceptions are captured in Sentry. Distributed tracing and structured application telemetry are captured in Pydantic Logfire. Product usage analytics are captured in PostHog.
Error and trace telemetry is retained for 90 days. Product analytics are retained for 12 months. Telemetry is used for reliability, debugging, and abuse detection.
The platform maintains domain-level activity records for key customer-facing workflows, including campaign actions taken per lead, lead lifecycle events, content approval decisions, and webhook delivery attempts. These are available to customers in the product and support investigation of what the system did on a customer's behalf.

10. Security incident response

Obert maintains an internal process for identifying, triaging, containing, and remediating security incidents.
Where Obert becomes aware of a Personal Data Incident affecting Customer Data, Obert notifies the affected customer without undue delay and in any event within 48 hours of confirming the incident, in line with Section 7 of the DPA. Notification includes the information reasonably available to allow the customer to meet its own notification duties under Articles 33 and 34 of the GDPR, within the 72 hour window those articles allow.
While an incident is open, Obert provides status updates to affected customers at least every 24 hours.
Obert investigates root cause, takes remediation steps within its reasonable control, and provides a written root cause summary to affected customers within 10 business days of resolution.
Suspected vulnerabilities or incidents can be reported to security@obert.io. We acknowledge reports within 3 business days. We do not pursue legal action against researchers who report findings in good faith and who do not access, modify, or exfiltrate data belonging to other customers.

11. Resilience, backup, and recovery

The production database is a managed service with automated backups and point-in-time recovery, operated in the Frankfurt region. Backups are encrypted at rest and remain within the EU.
Obert targets a recovery point objective (RPO) of 24 hours or less and a recovery time objective (RTO) of 24 hours or less for the production database. Point-in-time recovery ordinarily permits a materially smaller data loss window than the stated RPO.
Restore procedures are tested periodically and the results are recorded.
Application services are deployed as immutable containers and can be redeployed or rolled back to a previous known-good release.
Long-running and asynchronous work runs through a durable workflow engine, so that jobs interrupted by a failure resume rather than silently drop.

12. Secure development and change management

Changes are delivered through version control with peer review before merge to the production branch.
An automated test suite runs on every pull request, and a failing suite blocks the change.
Development, staging, and production environments are separated, with separate credentials. Production secrets are not available in development environments.
Secrets are injected at runtime from the platform secret store. Secret files are excluded from version control.
Direct changes to production data are restricted to a small number of personnel and are made only where necessary to resolve an incident or a support request.

13. Testing and evaluating effectiveness

In accordance with Article 32(1)(d) of the GDPR, Obert maintains a process for regularly testing, assessing and evaluating the effectiveness of the measures described on this page.

The measures are reviewed at least annually, and additionally whenever there is a significant change to the architecture, the hosting arrangements, or the categories of Personal Data processed.
Reviews cover access rights and role assignments, the sub-processor inventory, encryption coverage, backup restoration, and the status of open vulnerability findings.
Where a review identifies a gap, it is recorded and tracked to closure with a named owner and a target date.
Obert's control environment is additionally assessed by an independent auditor as part of its SOC 2 programme.

14. Sub-processor management

Obert maintains a current, public list of sub-processors at obert.io/dpa#sub-processors, including the purpose and location of each one.
Each sub-processor is engaged under a written agreement imposing data protection obligations no less protective than those in our DPA, as required by Article 28(4) of the GDPR. Obert remains liable to the customer for its sub-processors' performance of those obligations.
Sub-processors are assessed before engagement and reviewed at least annually thereafter.
Customers are notified of an intended addition or replacement of a sub-processor at least 30 calendar days before it begins processing, by publication and by email to addresses registered for that purpose. Customers have 15 calendar days from that notice to object on GDPR grounds, and where a timely objection is made the new sub-processor will not process that customer's data while the objection remains unresolved. To register for sub-processor change notices, write to privacy@obert.io.

15. Data retention and deletion

Customer Data is retained for the duration of the customer's subscription.
Customers can delete individual records, connected accounts, and campaigns from within the product at any time.
A workspace administrator can delete the entire workspace. On workspace deletion or contract termination, Customer Data is removed from production systems within 7 days, and from encrypted backups within 35 days as backups roll off their retention window.
On request following termination, and at the customer's choice, Obert will return or delete Customer Data in accordance with Section 8 of the DPA, subject to any retention required by applicable law.
Data subject requests can be sent to privacy@obert.io. We acknowledge a request within 5 business days and, where Obert acts as processor, forward it to the relevant controller and provide the assistance they need within 10 business days.

16. Certifications and audits

Obert previously held a SOC 2 attestation, which lapsed in June 2026. We are currently engaged in the renewal audit. Confirmation of the audit engagement is available on request, and the renewed report will be shared with customers once issued.
On written request at reasonable intervals, and subject to confidentiality, Obert makes available a copy or summary of its most recent third-party audit reports or certifications, in accordance with Section 6 of the DPA.
Customers may request further audit rights as set out in Section 6 of the DPA.

17. Contact

VENDI AI LTD, d.b.a Obert.io
Ibn Gabirol 72, Tel Aviv, Israel

Security: security@obert.io
Privacy and data protection: privacy@obert.io
Legal: legal@obert.io

Security at Obert