How Edara handles your data

Both products are designed to hold conversation data, ERP records and account data in Saudi Arabia. That is the goal we build to, and it is what we set up for a deployment.

Parts of a deployment reach outside the Kingdom. A telephony carrier, a business messaging channel or a speech and language model provider may process data elsewhere. Where that happens we say so in the agreement, we send the minimum the step needs, and the transfer follows the PDPL rules for transfer outside the Kingdom. The website itself is served through a global hosting network.

Edara ERP holds the records a developer's own work produces: units, reservations and sales, contracts, buyer details, collections and payment records, invoices, construction milestones and handover.

Edara Agents holds what a conversation produces: the recording where the deployment records calls, the transcript, the messages, the outcome, and the actions the agent took in your systems.

We store what a deployment needs in order to run and to be checked afterwards. We do not sell data, we do not use it for advertising, and this website carries no advertising or tracking network.

Conversation and ERP data we process for one customer is not used to train models for any other customer, and it is not used to improve the service unless that customer's agreement allows it. That position is written into the privacy policy, not only onto this page.

Inside the product, access is by role: a person sees what the role needs and nothing else. Accounts belong to named people, and shared logins are not part of the design.

On our side, access is limited to the people who need it to build and support the deployment. It is granted for the work and withdrawn after it.

Every action in the workspace is written to an audit log: who did it, what changed, and when. The log exists so that a question about a contract, a collection or a handover is settled from the record rather than from memory, and so that a customer can review what the agent did on its behalf.

The design position is encryption in transit and at rest, a backup of each deployment, and a written recovery path that is checked at go live rather than after something goes wrong. No system is completely secure, and we do not tell you otherwise.

Retention is set per deployment rather than fixed by us in advance. Recordings, transcripts and messages are deleted when the period the customer sets for its deployment ends. At the end of an agreement we return or delete that customer's data within the period the agreement states.

Logs and backups are kept for the limited period security and recovery need, and are then overwritten. You can ask us to delete a demo request you sent through this website at any time.

A deployment relies on other providers: telephony and business numbers, business messaging channels, speech and language model providers, and hosting. We do not publish the list on this page, because it follows what each deployment connects to.

We name the providers a deployment uses, and what each one handles, in writing before it starts, and we tell the customer before one of them changes.

This website runs no analytics tool, sets no cookie beyond what it needs to work, and therefore shows no cookie banner. The contact form sends what you type to us by email and does nothing else with it.

We hold no security certification, and we do not describe the product as certified, compliant or externally audited. If that changes we will publish it here with its scope and its date.

Government integrations are built toward, not live. Where the product is still in development we say so on the product page, and the status line there is the one we stand behind.

If your procurement needs a security review, bring it to the demo call and we answer in writing. For questions about this page or about your data, write to osamah@edarahq.com. To report a call or a message from an Edara agent, use the report abuse page. How we handle personal data is set out in the privacy policy.