Personal data processing policy

1.1. This Policy applies to the public website, Buyer, Supplier and administrator accounts, support communications, electronic documents and technical Platform logs.

1.2. The Operator processes data lawfully, for predetermined purposes and to the minimum extent necessary, and ensures accuracy, restricted access and retention no longer than necessary.

1.3. Data about a legal entity are not, in themselves, personal data; however, the full name, IIN, phone number, email, voice, signature and other information about its employees and representatives are protected as personal data.

2.1. The Operator obtains data:

• directly from the data subject during sign-in, registration, profile completion, ordering, correspondence, signing and requests;
• from an organisation that added or identified its representative, employee, driver, courier or recipient, only where a proper basis for transfer exists and is preserved;
• from the counterparty to an Order, only to the extent necessary for supply, acceptance, return and resolution of a claim, with the source and basis recorded;
• automatically from the browser, device, session and security infrastructure;
• from lawful publicly available sources and government services when verifying an organisation, digital-signature certificate and authority.

2.2. An organisation may not accept consent on behalf of a legally capable employee or another individual. Before processing data of a person without an account, the Operator identifies a specific basis, provides the person with the necessary information and obtains direct consent where no statutory exception applies. The transferring organisation must retain and, on request, provide evidence of its basis, but this does not transfer the Operator's duties to that organisation.

2.3. An individual's publication of their own data online does not establish that subsequent processing is lawful. For each publicly available source, the Operator preserves the link, date, legal basis, permitted purpose and scope; information not subject to dissemination is masked.

2.4. The Platform is intended for adult business representatives and does not knowingly collect children's data.

3.1. Depending on role and action, the following are processed:

• full name, position, basis of authority, IIN from a digital-signature certificate and BIN of the represented organisation;
• phone number, email, delivery or work address and preferred language;
• user, organisation, membership and role identifiers and access rights;
• Orders, supplies, accepted quantities, returns, claims, comments and action history;
• chat text, support requests, return photographs, images, voice messages and attached files;
• canonical electronic-document payloads, CMS signatures, certificates, serial numbers, fingerprints, OCSP/CRL results and authority-verification results;
• the IP address and user agent technically necessary at the time of a request; HMAC pseudonyms of the IP address, user agent, session, OTP recipient and QR token; cookies, request identifier, date and time, security events, errors and access logs;
• public particulars of an individual entrepreneur and other information about an individual conducting business.

3.2. The Operator does not request biometric data or information about health, political opinions or religious beliefs. Such information should not be submitted in free-text fields or attachments.

4.1. Data are processed for:

• account creation, authentication, role management and authority verification;
• concluding and performing the Platform-access contract and facilitating performance of Orders between counterparties;
• delivery, acceptance, return, claims, support and legally significant notifications;
• creation, signing, verification, retention and provision of electronic documents;
• fraud prevention, incident investigation, backups and information security;
• compliance with requirements of courts, tax authorities and other authorised government bodies;
• quality analytics and service improvement solely using irreversibly de-identified or aggregated data; using personal data for this purpose requires separate voluntary consent or a precisely documented statutory exception.

4.2. As a general rule, processing is based on the data subject's separate demonstrable consent. Without consent, the Operator processes data only in cases expressly provided by Article 7(5) and Article 9 of the Law of the Republic of Kazakhstan on Personal Data and Their Protection, and only within the relevant exception.

4.3. Concluding or performing a contract with the organisation represented by the data subject, and protecting the interests of the Operator or the parties to an Order, do not themselves replace consent and are not an independent basis for processing personal data.

4.4. Buyer/supplier does not send a full name and phone number or email into the OTP flow before a separate express checkbox is selected. The form shows the exact disclosure in advance, and before creating an OTP or calling the provider the server stores a short-lived encrypted receipt and its append-only commitment; after successful code verification, the exact evidence is linked to the userId, and only then is a client-accessible session created. The page’s first HTTP request, reverse proxy, CDN/WAF and other infrastructure preceding the form are qualified separately under an exact basis and are not covered by subsequent consent. Internal admin sign-in processes a work email, password verification, a session, cookies and security events only after a separate employee/admin basis, access assignment and individual acknowledgement record; a password is not consent. Production surfaces remain programmatically blocked until the complete map of fields, purposes, bases, recipients, location, periods and deletion is approved and linked to the SHA-256 of the current Policy.

4.5. Until current consent is recorded, an address is entered manually: the server does not send address fragments to an external geocoder. Sending a request from an account and other optional external transfers are also blocked until consent is confirmed.

4.6. The concept of a “necessary cookie” or the service's technical necessity does not, by itself, create an exception to the Law. Until demonstrable consent is obtained, visitor identifiers, IP addresses, user agents and security events are stored only on a documented applicable basis under Article 9; absent such a basis, optional recording and further storage do not occur.

4.7. Marketing communications are not included in mandatory consent. They require separate voluntary consent with a simple opt-out; until such a mechanism is implemented, the Operator does not send marketing communications.

5.1. The Operator performs collection, recording, organisation, accumulation, storage, updating, retrieval, use, transfer, provision of access, masking, hashing, anonymisation, de-identification, restriction of processing, blocking, deletion and destruction of data.

5.2. Filters, catalogue matching, ranking, risk notifications and queue priority may be generated algorithmically. Such decisions must not result in discrimination. Where a fully automated decision produces legal consequences or may affect a person's rights and legitimate interests, the data subject receives, in cases provided by law, information that the system was used, an explanation of key factors and criteria without disclosure of protected code or secrets, and an opportunity to request review by an authorised specialist.

5.3. Until the process is separately approved, the Operator does not use a solely automated decision to refuse registration, block an account, determine authority, finally resolve a claim or produce another material legal result.

6.1. Access may be granted to the minimum extent necessary to:

• the Buyer or Supplier that is the counterparty to a specific Order;
• a Kazakhstan-resident hosting provider, data centre, backup storage provider and telecommunications operator;
• OTP, SMS, email and messenger-notification providers: Company Hoster.KZ LLP, BIN 070440006808, Kazakhstan: primary database, objects and server components in Almaty; backups in Astana; registered contact at 45G Komissarov Street, office 405, Karaganda. Plus Five Five, Inc. (Resend), 2261 Market Street #5039, San Francisco, CA 94114, USA: email address, one-time code and technical delivery information for email sign-in; for voluntary enquiries, requester-provided contact details, organisation details, message and consent information; storage in the USA. Gmail (Google): working copies of enquiries at webberdyev@gmail.com, including copies delivered by Resend after the requester explicitly submits the form. Google uses global infrastructure; no fixed country list or single provider retention period for all correspondence is confirmed. Automatic forwarding of auth records, profiles, orders, delivery notes or the complete evidence archive to Gmail is not authorised. SMS, external geocoding, the digital-signature verifier and Sentry are disabled in the pilot;
• the digital-signature and authority-verification provider: digital-signature verification is disabled in the limited pilot;
• the error-monitoring provider: Sentry is disabled in the limited pilot;
• advisers, auditors and support contractors under confidentiality agreements;
• government authorities and courts where there is a lawful requirement; state-revenue authorities only where Article 56(5) of the Tax Code has been determined to apply and only as part of the prescribed internet-platform-owner form.

6.2. The open digital-signature verification service required by Article 61(4) of the Digital Code is separate from an optional QR check of a stored status. The former verifies a user-supplied document or standalone package without login and is introduced before production digital signatures; the latter is disabled by default and enabled only after a separate privacy/legal review. A minimal QR response does not disclose an IIN, personal contact details, CMS or certificate, and shows an individual entrepreneur's name containing a full name only on a documented basis and with approved masking.

6.3. Before interacting with a personal-data-containing digital object of a government authority or government legal entity, the Operator classifies the particular request and applicability of the Article 9 exceptions. Where Article 8-1 requires integration, the request is not sent until the government personal-data access control service is connected and the consent or other verifiable result it prescribes is obtained; ordinary aluber consent does not replace that result.

6.4. The Operator enters into agreements with processors covering confidentiality, purpose, security, deletion periods and prohibition of independent use of data.

6.5. The Operator does not sell personal data or provide them for third-party advertising.

7.1. The production decision must be recorded before launch: transfer of email address, one-time code and delivery information to Plus Five Five, Inc. (Resend) in the USA for email sign-in; when an enquiry is voluntarily submitted, transfer of its contacts, message and consent information through Resend to the Gmail working mailbox. Resend's Free plan retains email and logs for 30 days; deletion after termination is completed within 90 days. Google uses global infrastructure and no fixed country list is confirmed. The application does not automatically forward account records, orders or documents to Gmail; the independent enquiry archive is stored in Kazakhstan.

7.2. If a foreign email, monitoring, messenger or other service is used, the transfer is disclosed in the Policy and Consent, permissibility is reviewed under Article 16 of the Law, and separate consent is obtained before transfer begins where required.

8.1. The primary database, file storage and backups containing personal data are located in data centres within the Republic of Kazakhstan. Actual location is evidenced by the provider's contract and completion documents, not merely the cloud-account region.

8.2. Protection includes:

• an approved internal policy and lists of processes, processed data, persons with access and responsible persons;
• a documented access procedure, role-based and tenant restrictions applying least privilege, and regular access-right reviews;
• registration and accounting of consent-related actions concerning third-party transfer, cross-border transfer, dissemination in publicly available sources and the list of collected data;
• installation of information-security tools and timely software updates;
• logging database-management-system events and actions of users with access to restricted personal data, with logs protected against unauthorised alteration;
• integrity-control tools for restricted personal data;
• transfer of restricted personal data to other persons over protected communication channels and/or with encryption and with any required consent;
• storage and transfer of restricted personal data using cryptographic protection with parameters no lower than the third security level under ST RK 1073-2007, except for an expressly established cross-border-transfer exception;
• identification and authentication of persons with database access; for a database containing more than one hundred thousand personal-data records, including biometric authentication of such persons;
• secure secret storage, backups and verifiable recovery;
• application-level logging of administrative and legally significant actions in addition to mandatory database logs;
• masking and hashing personal data in digital objects in the cases and manner established by legislation, with separate review of public pages and exports;
• vulnerability management, updates, incident response and staff training;
• contractor due diligence, contractual requirements and a secure-deletion procedure.

9.1. The account and profile are retained until the relationship ends and requests are completed, and then for the period necessary to protect rights and comply with mandatory requirements.

9.2. After separate owner adoption, the limited pilot uses this Operator policy, not a universal legal retention rule: a profile with no transactions is deleted or anonymised within 30 days after closure; minimum contract data, orders, PDFs and consent evidence are retained for 5 years after the relationship ends or the last transaction; complete enquiries, their consent and the local archive are retained for 5 years after enquiry closure; the Gmail working copy is deleted within 30 days after closure after the Kazakhstan archive has been verified; security logs are retained for 1 year. Deletion is not represented as fully automated: the responsible person performs a documented monthly manual review. A lawful hold for a specific dispute or mandatory retention is documented separately with its basis and review deadline.

9.3. A one-time code is valid for 5 minutes. Better Auth retains the stated phone number or email in the verification record until the code expires and the next independent cleanup pass; the sending-rate-limit log retains only an HMAC pseudonym of the recipient for no more than 48 hours.

9.4. The account-request rate-limit log contains no message text and is retained for no more than 24 hours. Before email delivery, the enquiry and exact consent revision with SHA-256, HMAC evidence and request ID are durably stored in a separate local archive in Kazakhstan; the provider receipt is added after delivery. Application records are append-only, but the archive is not represented as administrator-resistant WORM storage. A daily encrypted backup is stored at a separate site in Kazakhstan. Only a copy of the user-submitted enquiry with consent information is delivered through Resend to webberdyev@gmail.com; account records, profiles, orders and delivery notes are not forwarded there automatically. The complete enquiry and archive are retained for 5 years after closure; the Gmail working copy is deleted within 30 days after closure after the Kazakhstan archive is verified, with documented monthly manual review and separately recorded lawful holds.

9.5. Where public verification is separately enabled, aggregated HMAC rate-limit buckets are retained for up to 25 hours. If the verification bearer pair matches, a security event is retained for up to 90 days: a daily HMAC pseudonym of the request/IP, a stable HMAC of the document type, UUID and SHA-256, request surface, “matched” outcome and time. This event proves only a token match, not an integrity or digital-signature verification result. Raw IP addresses, UUIDs and SHAs from QR, CMS and personal contact details are not written to these logs.

9.6. Acceptance evidence in the append-only log contains the data subject's name, account identifier, document, revision, SHA-256, exact tick-box wording and time; the IP address, user agent and session identifier are stored only as HMAC pseudonyms with the key version. It is retained with the legally significant relationship history for the approved period, with access restricted.

9.7. Other technical logs and incident records are retained for the minimum periods in the internal schedule; test data are regularly deleted.

9.8. When the purpose is achieved, data are deleted, destroyed or irreversibly de-identified, with the result confirmed. Retention for a mandatory period, an outstanding contractual obligation, court proceedings or protection of rights expressly provided by law is permitted only to the necessary extent, with a documented basis, restricted access and a legal hold; the mere existence of an undefined “dispute” is not a basis.

10.1. The data subject may:

• obtain information about the existence, purposes, sources, composition, methods and recipients of processing;
• obtain an accessible copy of their data and information about transfers;
• request correction, supplementation, blocking, deletion or destruction of unlawfully processed data;
• request deletion, anonymisation or restriction of processing of data in the digital environment regardless of the basis on which they were obtained, except in cases expressly provided by law;
• where a mandatory retention period applies, request access restriction and suspension of other processing except performance of a court act or an obligation established by law or contract and archival retention;
• withdraw consent, except where an obligation remains outstanding or retention is mandatory by law;
• object to optional processing and opt out of marketing;
• challenge the Operator's actions before the authorised authority or a court.

10.2. An authenticated data subject may submit a structured request or withdraw consent in the Privacy section of their account. The system immediately issues an opaque receipt token and restricts processing pending a decision. On withdrawal, active sessions are terminated; a minimal request status is available on the public verification page, where the token is passed only in the URL fragment. That page does not accept new requests or disclose identity, contact details, category or content.

10.3. Without an active session, a new request is sent to webberdyev@gmail.com or Republic of Kazakhstan, Zhetysu Region, Taldykorgan, 204 Abylai Khan Street, 040000. The Operator verifies the applicant's identity proportionately. If additional information is needed to fulfil a structured request, the Operator separately identifies a permitted channel for providing it; the public receipt is not such a channel.

10.4. Information about the existence and processing of data, or a reasoned refusal, is provided within 3 business days. Only corrections, supplementation, blocking, unblocking and destruction for which that period and the corresponding basis are expressly established by the current version of Article 25(2) of the Law are performed within 1 business day. Other deletion, anonymisation or restriction requests under Article 41 of the Digital Code are fulfilled within the applicable statutory period under the approved procedure; the extension of the one-day period under Law No. 326-VIII applies from 25 August 2026. Following withdrawal of consent, processing ceases within 15 business days or a reasoned refusal is sent.

10.5. When a data subject's request concerning restricted personal data is received, data relating to the request are blocked until a decision is made, in accordance with the current Rules for Implementing Personal Data Protection Measures. Blocking does not mean that the request is automatically granted and is documented separately.

11.1. The Operator maintains a response plan, contains consequences, preserves evidence and, within one business day after discovering a personal-data security breach, notifies the authorised authority and provides the responsible person's contact details. Data subjects are notified in the cases, with the content and in the manner established by special rules.

11.2. Responsible person: Бердыев Дамиль Безиргенович. Data contact: webberdyev@gmail.com; general support: webberdyev@gmail.com; phone: +7 778 787 66 66.

12.1. For each revision, the publication date, effective date, hash and a brief description of changes are published; previous revisions remain archived.

12.2. If a new purpose, recipient, data composition or cross-border transfer requires fresh consent, the Operator obtains it before such processing begins. Merely continuing to visit the website does not replace consent.