> ## Documentation Index > Fetch the complete documentation index at: https://docs.tryoto.com/llms.txt > Use this file to discover all available pages before exploring further. # Security & compliance > How OTO protects your data: hosting options including in-Kingdom hosting in Saudi Arabia, access control, credentials, encryption, testing and fraud controls. OTO holds order records, customer addresses, phone numbers and payment methods for merchants across three markets. Everything on this page exists because that data is not ours — it is yours, and your customers’. ## Where OTO stands | Standard | Status | What it covers | | - | - | - | | **ISO/IEC 27001** | **Certified — 2026** | An audited information security management system: how risk is assessed, how controls are chosen, and how the whole thing is reviewed and improved. | | **SOC 2 Type II** | **Attested — 2026** | The Security criteria, examined by an independent auditor *over an observation period* rather than on a single day. | | **Saudi PDPL** | **Compliant** | The Kingdom’s Personal Data Protection Law — lawful basis, data subject rights, and the rules governing where personal data may go. | | **UAE PDPL** | **Compliant** | Federal Decree-Law No. 45 of 2021, for merchants and customers in the Emirates. | | **Türkiye KVKK** | **Compliant** | Law No. 6698 on the Protection of Personal Data, for the Türkiye market. | > [!TIP] > > **Why both ISO 27001 and SOC 2, and why the difference matters** > > They are not duplicates, and a reviewer who knows the difference will check for both. **ISO 27001** certifies the *system*: that OTO has a defined way of identifying risk, selecting controls and improving them, and that an accredited body has examined it. **SOC 2 Type II** reports on the *evidence*: that specific controls did not merely exist on paper but operated effectively across months of real activity. > > A Type I would say the controls were designed correctly on the day someone looked. Type II says they held up. That distinction is the reason enterprise procurement asks for Type II by name, and it is the one OTO holds. ## Where your data lives Data residency is a deployment decision, not a fixed property of the platform. **In-Kingdom hosting is available** for merchants whose regulatory position, customer base or procurement policy requires Saudi data to stay in Saudi Arabia; other deployments run outside the Kingdom where that is the better fit. > [!NOTE] > > **Settle residency before the contract, not after** > > Residency is straightforward to arrange at the start of a deployment and expensive to change once historic data exists and integrations are pointed at an environment. > > If in-Kingdom hosting is a requirement rather than a preference — and for government-adjacent buyers and regulated sectors it usually is — raise it during evaluation so the environment is provisioned correctly the first time. ## Who can get in | Control | What it does | | - | - | | **Multi-factor authentication** | Available on every account, from **Settings → My Profile**. Time-based codes from an authenticator app, so a stolen password on its own is not enough to sign in. | | **Passkeys** | Passwordless sign-in bound to the device, as an alternative to a password. There is no shared secret to phish, reuse or leak. | | **Roles and permissions** | Access is granted by role rather than per person, from role templates you can adapt. See [Users, roles & permissions](https://docs.tryoto.com/platform/users-roles-and-permissions.md). | | **Financial visibility as its own permission** | Prices, COD values and invoice figures are controlled separately from operational access, so a picker or a customer-service agent can do their job without seeing what anything costs. | | **Scoped warehouse access** | Warehouse users are issued their own tokens and are scoped to the hubs they work in. A picker at one site has no reach into another’s queue. | | **Scoped API access** | API permissions are bound to the account’s package and to specific endpoints — an integration cannot call surface it was never granted. | ## How credentials work The [API](https://docs.tryoto.com/developers/authentication.md) uses a two-token model deliberately. A permanent `refresh_token`, issued from the dashboard, can do exactly one thing: obtain a short-lived `access_token`. That access token expires after **one hour**, and every other call carries it as a bearer token. > [!TIP] > > **Short-lived tokens limit the blast radius** > > The point of the split is what happens when something leaks. A captured access token is useful to an attacker for at most an hour, and then it is worthless. > > Which is why the permanent token deserves the care you would give a password — secrets manager or environment variable, never a repository, a mobile bundle, a support ticket or a screenshot. It is the one credential that does not expire on its own. ## How data is protected | Layer | Control | | - | - | | **In transit** | All API traffic is HTTPS only. Requests over plain HTTP are not served. | | **Between services** | Payloads are encrypted or encoded on the internal paths that carry customer data — the webhook sender, the e-commerce gateway, the SMS gateway and the REST API. | | **At rest** | Stored data is encrypted. | | **Outbound events** | Every [webhook](https://docs.tryoto.com/developers/webhook-events.md) payload is signed with HMAC-SHA256 against a secret you choose, so your endpoint can prove a message came from OTO and not from whoever else discovered the URL. | | **Public endpoints** | Tokens for publicly reachable surfaces — tracking pages, return portals — are generated and encoded server-side, so a URL cannot be guessed or edited into someone else’s order. | | **At the edge** | A web application firewall sits in front of the platform, including rules targeting SQL injection. | ## How it is tested | | | | - | - | | **Independent penetration testing** | Both the platform infrastructure and the public API are tested by external specialists, with findings tracked to closure. | | **Bug bounty** | A standing programme for researchers to report vulnerabilities, so problems arrive as reports rather than as incidents. | | **Continuous control monitoring** | Compliance controls are monitored continuously rather than assembled in the weeks before an audit — which is what makes a Type II observation period survivable. | > [!NOTE] > > **A bug bounty is a statement about posture, not just a budget line** > > Running one means accepting that outsiders will find things, and building the process to triage and fix them quickly. Organizations that are not confident in their own code do not invite strangers to look at it. ## Fraud controls In a market where cash on delivery is normal, fraud is an operational cost rather than an edge case. OTO carries detection for the patterns that matter here — including customers cycling through multiple addresses, and abuse of account deletion to escape a history. Related merchant-side controls live in [pre-fulfillment checks](https://docs.tryoto.com/modules/omnichannel-oms/prefulfillment.md): blacklisting, COD order confirmation and payment-method verification before an order is allowed to consume stock. ## What is yours to do Security of the platform is OTO’s responsibility. Security of how you use it is shared, and these are the four that matter most. | | | | - | - | | **Turn on MFA for every account** | Particularly administrators and anyone who can see financial data. | | **Grant the narrowest role that works** | Role templates make this quick. Most people need far less than full access, and access granted “temporarily” is rarely withdrawn. | | **Protect and rotate the refresh token** | It does not expire on its own. Regenerate it when someone with access to it leaves. | | **Verify webhook signatures** | Recompute the HMAC and reject anything that does not match, or anything whose timestamp is stale. See [Webhook events](https://docs.tryoto.com/developers/webhook-events.md). | ## Requesting documentation The ISO 27001 certificate, the SOC 2 Type II report and penetration test summaries are available to customers and to prospects under evaluation. The report is shared under NDA, as is standard. Ask your account contact, or write to [support@tryoto.com](mailto:support@tryoto.com), and include the regime or questionnaire you are working against so the right documents come back the first time. ## Related * [Users, roles & permissions](https://docs.tryoto.com/platform/users-roles-and-permissions.md) — how access is actually granted. * [API authentication](https://docs.tryoto.com/developers/authentication.md) — tokens, lifetimes and scope. * [Webhook events](https://docs.tryoto.com/developers/webhook-events.md) — signature verification. * [Pre-fulfillment checks](https://docs.tryoto.com/modules/omnichannel-oms/prefulfillment.md) — merchant-side fraud controls. ## Related topics - [Platform architecture](https://docs.tryoto.com/get-started/architecture.md) - [Users, roles & permissions](https://docs.tryoto.com/platform/users-roles-and-permissions.md) - [Quick start: ship your first order with OTO](https://docs.tryoto.com/get-started/quickstart.md) This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.