Risk and insurance
Avrosh is operated by PT Laras Teknologi International, a company incorporated in Indonesia. This page answers the question a procurement team asks before it signs: what happens if something goes wrong, and who absorbs it. The short answer first, because burying it would be worse than saying it. No cyber liability insurance policy is currently in force. There is no insurer, no policy number and no limit, so there is no certificate to send you. What follows is what is actually true instead: the controls that make a loss less likely, the controls that make a loss smaller, what we hold and for how long, how an incident would be handled, and what you should ask us for before you sign.
No policy is in force
PT Laras Teknologi International does not currently hold cyber liability insurance. It does not hold technology errors and omissions cover either. Nothing on this site or in a sales conversation should be read as saying otherwise, and if you receive a document from us that implies a policy exists, it is wrong and we want to know.
This has a direct consequence for you and we would rather state it than let you discover it. If we caused you a loss and you were awarded compensation, that award would be paid out of this company's own assets. There is no insurer standing behind it. Treat that as a real input to your risk assessment, alongside the size of the data you are placing with us and the ceiling your agreement sets on our liability.
We are not pretending this is ideal. Cover is on the list, and the decision on whether to bind a policy and at what limit sits with the owner. When a policy is in force, this page will name the class of cover and the limit, and a certificate will be available on request. Until then this paragraph stays as it is.
What we hold, because that sets the size of the loss
Insurance questions are really questions about blast radius, so here is what an incident could reach. Your business content and knowledge base. Your bookings, orders, service jobs and their history. Customer accounts and the CRM contact record: name, email address, phone number, and the one time login codes sent by email. The append only consent ledger. Payment proof images uploaded by customers for bank transfers, which carry names and bank details. Call records and their written transcripts. Any outbound calling list you supply and its consent attestation. API keys issued to your own servers. The integration outbox, which queues booking and customer events for destinations you configure.
No call audio is recorded or stored. A written transcript and a call record are.
No card data ever reaches us. Subscription billing runs through a payments provider acting as merchant of record, so card numbers are entered on their surface and are held by them, never by us. A card breach at Avrosh is not a scenario because there are no cards here to breach.
One category deserves naming rather than implying. Avrosh ships dental and clinic verticals, and a transcript from a clinic call can contain health information. We hold no HIPAA business associate status and no health data certification, and we are not offering one. If you are a covered entity or your regulator treats your customer notes as special category data, tell us before you sign so we can say honestly whether the product fits, and configure your deployment so that clinical detail is not what the AI is asked to take down.
Controls that make a loss less likely
Isolation between businesses is enforced by the database, not by application code remembering to filter. Every query runs inside a transaction with a PostgreSQL row level security context set on it, so a query with a missing WHERE clause returns nothing rather than someone else's rows.
One layer sits above that and is worth reading, because it is the difference between a control and a habit. When a route acts on a specific property on behalf of its owner, the helper that opens the transaction verifies ownership against the properties table before it sets the tenant context, in the same transaction. A route that forgets its own permission check therefore fails closed by construction. That was written after an audit found exactly one route that had forgotten, and the fix was made structural instead of local.
The customer surface collects nothing. The QR chat has no account, no phone number and no login, so on the surface most of your customers touch there is almost nothing to lose.
Operator passwords are hashed with argon2. Traffic is encrypted in transit with TLS. Encryption at rest is provided by the hosting platform. Login, chat and session creation are rate limited. There are no advertising trackers or ad network pixels on this site or in any customer chat, so there is no third party quietly holding a copy of your traffic.
Controls that make a loss smaller
Collection is deliberately thin. The busiest surface in the product holds no identifiers at all, which means the population exposed by a worst case is far smaller than the number of conversations would suggest.
Call audio is never written to disk as a stored recording, so a storage compromise cannot yield voice recordings of your customers. It can yield transcripts, which is why we say both facts in the same breath every time.
Your servers and your database live in one assigned region: Northern Virginia, Singapore or Frankfurt. Be aware that a region decides where your servers and database live and does not yet decide where the AI runs. Every model certified to serve an account today is hosted outside the European Union. The security page sets that out in full, and it is a residency fact worth reading before an insurance question rather than after.
Deletion is real rather than cosmetic. A deleted business and soft deleted catalogue rows are purged permanently after a seven day recovery window. A customer erasure strips identifiers in place, and where branches are grouped it leaves no identifying bytes at any of them.
Retention, stated accurately
What is pruned automatically: platform bookkeeping rows at fourteen days, internal error logs at thirty days, deleted businesses and soft deleted catalogue rows at seven days, integration outbox events on a fixed window once delivered, past booking ranges nightly, and stale waitlist entries after seven days.
What is not pruned automatically: conversations, chat sessions, call records and their written transcripts. These have no automatic expiry today and live for the life of the account. If your policy requires a transcript retention window, it is something we set for you rather than something the product enforces on its own, and we will tell you that in writing instead of letting an unstated default become your answer to an auditor.
Customer side export and erasure are built in and are a click rather than a support ticket. An export returns the contact record, bookings, waitlist entries and consent history. An operator side export of your own business content is not self serve yet. Ask and we provide a copy.
Backups and continuity
We would rather describe this thinly and accurately than write a target and let you read it as a commitment.
What exists today: a full database dump is taken before any schema migration is applied, and the hosting platform provides its own storage level durability. What does not exist today: a scheduled automated backup job inside the product, a published recovery point objective, a published recovery time objective, and a documented restore drill. Your deployment runs in one region and is not replicated to a second one for failover.
If a backup schedule and a tested restore are a condition of your purchase, say so during evaluation. That is a decision the owner has to make and fund, not something we can satisfy with wording on a page.
If something goes wrong
Report a suspected security issue to hello@avrosh.com. Every report is investigated and acknowledged.
On becoming aware of a personal data breach affecting your data we will investigate and contain it, and notify you without undue delay so that you can meet your own regulatory clock. Under the GDPR the notification duty to a supervisory authority is yours as controller, and our job is to give you what you need to file it in time. We will tell you what we know, what we do not yet know, which data categories and roughly how many records are involved, what we have done to contain it, and what we are doing to stop it recurring. We will send updates as the picture changes rather than waiting for a complete one.
Because GDPR applies to us extraterritorially and Indonesia has no EU adequacy decision, transfers to us rest on Standard Contractual Clauses and a transfer impact assessment. An EU representative under Article 27 is being appointed and is not in place yet. Indonesia's own Law 27 of 2022 on Personal Data Protection also applies to us directly. These are the frameworks an incident would be handled under, and none of them is a substitute for insurance.
Where the risk actually lands
Absent insurance, the contract is the only instrument allocating risk between us, so read it rather than assuming a market default.
An account with no separately signed agreement is governed by the public Terms alone. There is no side letter, no bespoke indemnity and no negotiated cap on such an account, and any figure in the public Terms is the figure that applies to you. A signed agreement is where a different cap, an indemnity or a security schedule gets set, and those figures are set at signature rather than published here.
Disputes are resolved by binding arbitration seated in Singapore, administered by SIAC, in English. The governing law of the contract is Indonesian law. Those are two different things and we do not conflate them. The reason for the Singapore seat is practical and in your favour: an Indonesian court judgment is not enforceable in the United States or the European Union, and vice versa, while an arbitral award is enforceable in more than 170 countries under the New York Convention, to which Indonesia, the United States and every EU member state are party. If you win, you can collect.
No certifications
We hold no SOC 2 report, no ISO 27001 certificate, no HIPAA attestation and no PCI certification. If a certification is a hard gate in your procurement process, we will not pass it, and we would rather you learned that on this page than three weeks into an evaluation.
What we offer instead is verifiable detail. The sub processor tables on the security page are generated from the same configuration the running system picks models from, so they cannot silently go stale, and they publish where each request is served and where each vendor is incorporated as two separate facts. We will complete your security questionnaire and answer it with what is built rather than what is planned.
What to ask us for
A serious buyer should push on the parts of this page that are thin. Ask, and we will answer in writing.
- Whether a cyber liability policy has since been bound, and at what limit.
- The named vendor behind each platform sub processor role, and a signed data processing agreement with Standard Contractual Clauses.
- The status of our EU Article 27 representative appointment.
- A written retention window for conversations, call records and transcripts on your account, since the product does not enforce one by default.
- Our current backup and restore position, including whether a scheduled backup and a tested restore have been put in place since this page was last reviewed.
- The liability cap, indemnity and security schedule that would apply to a signed agreement, as opposed to the public Terms that govern an account without one.
- A completed copy of your own security questionnaire.
This page describes how Avrosh operates today and is reviewed regularly. It is a statement of risk posture, not a warranty, and it does not vary the Terms or any signed agreement. Questions, security questionnaires and requests for the items listed above go to hello@avrosh.com.