Privacy Policy

01 Who we are

Kunduz Suite is developed and operated by Ayberk Ergezen, acting as an individual (natural person) data controller. No operating company has been incorporated yet, so there is no registered trade name, commercial registry or MERSIS entry, and no registered electronic mail (KEP) address to publish.

Contact runs through a single e-mail address: destek@kunduzsuite.com. General enquiries, privacy questions and requests to exercise your rights all go there. No postal address and no telephone line are published for the service; e-mail is the channel we operate and the one we answer.

02 Scope and our two different roles

This policy covers the Kunduz Suite mobile application (iOS and Android), the web and desktop application, the backend service, and the public marketing website.

Kunduz Suite is sold to companies. That means we act in two distinct roles, and your rights differ depending on which one applies:

• As a processor — for almost all operational data inside a customer's workspace: employee records, drivers, trips, work orders, photos, messages, customer and invoice records. The subscribing company decides what is entered and why. It is the controller; we process on its documented instructions.
• As a controller — for the limited data we determine ourselves: the accounts we create for administrators, billing and correspondence with the subscribing company, security and audit logging, and error diagnostics required to keep the service running.

If you are an employee, driver or business contact of a company that uses Kunduz Suite, your first point of contact for a data request is normally that company. We will assist it, and we will forward any request sent directly to us. See section 11.

Under Turkish law (KVKK) the equivalent terms are veri sorumlusu (controller) and veri işleyen (processor). Data-processing terms with each subscribing company are set out in the service agreement signed with it. The corresponding agreements with our own sub-processors — the vehicle-tracking provider, Google, Expo and Apple — are being put in place; we do not claim here that they are all already concluded.

03 Data we process

The table below lists every category of personal data the software actually stores. It was compiled from the database schema, the migrations and the API routes.

Special categories

We do not intend to collect special-category (sensitive) data. However, the leave-record field is free-form: if a subscribing company enters sickness or medical leave into it, that constitutes health data and requires a separate legal basis under Article 9 GDPR / Article 6 KVKK. We ask subscribing companies not to record sickness or medical information in that field, and it should not be used for that purpose.

What we do not collect

• No analytics, crash-reporting, attribution or advertising SDKs of any kind. We verified this across the entire codebase.
• No device fingerprinting. The only device information stored is the push token and the platform name.
• No smartphone location (see section 06).
• No microphone access and no audio recording of any kind.
• We do not sell personal data, and we do not use it for advertising or for training machine-learning models.

04 Purposes and lawful bases

Where GDPR applies, we rely on the bases below. Where Turkish KVKK applies, the corresponding grounds in Article 5 are relied upon. The subscribing company is responsible for identifying the basis for data it enters about its own staff and customers.

Where we rely on legitimate interests, we have considered the impact on the individuals concerned; you may object at any time (section 11). Where we rely on consent, you may withdraw it at any time without affecting the lawfulness of prior processing.

05 How we collect it

• Entered by your employer or its administrators — most operational data, including your account, your employee record and your identity number. You may not have entered any of it yourself.
• Entered by you in the app — messages, photographs, expense receipts, task completions, notes.
• Generated automatically by the system — timestamps, status history, audit records, last-seen indicator.
• Received from a third party — vehicle location and the driver name reported by the vehicle tracking provider (section 06), and accounting records pulled from the customer's own ERP when that integration is enabled.
• Marketing website — the public website makes no external requests, sets no cookies, contains no analytics and has no forms. It stores only a language preference in your browser. Contact is by e-mail only.

06 Location data — read this carefully

The Kunduz Suite mobile app does not collect location from your phone. The app contains no location library, requests no location permission, and makes no call to any positioning API. We verified this in the source code, not merely in policy.

Location comes from the tracking device installed in the vehicle, through a third-party fleet-tracking provider. When the office or a customer opens a live map, our server calls that provider and returns the result. The call is not made per plate: the provider's service returns the current position of every vehicle on the subscription in one response, and the filtering down to the vehicles you are allowed to see happens on our server, by matching against the plates we hold. Trip mileage is fetched the same way, by date range, and selected by plate on our side. The data received includes coordinates, speed, heading, ignition state, street address, province, country, odometer readings and the driver name held by the provider.

This location data is not written to our database. It is held in a short-lived in-memory cache (30 seconds) and served live. The historical trail is retained by the tracking provider under its own policy, not by us.

Two consequences you should be aware of:

• Because the tracking record identifies the assigned driver by name, vehicle location is employee location data in practice, even though it does not come from a personal phone. Employers should treat it accordingly.
• A customer can see the live position of the vehicle carrying their own active shipment — plate, coordinates, speed, address, province and country — but only for their own shipment and only while it is in transit.

07 Push notifications — including message content

When you are sent a message and your app is closed or in the background, we deliver a push notification. The notification body currently contains the full text of the message, and the title contains the sender's full name. For file attachments, the body contains the file name.

This means that message content passes through the push infrastructure of Google (Firebase Cloud Messaging, on Android), Expo and Apple (on iOS) before reaching your device. Those providers process it in order to deliver it. Other notifications also contain personal data: customer or reference names and province-to-province routes, trip numbers and status changes.

We state this plainly because a policy that said "only notification content is sent" would be technically true and practically misleading.

Push notifications are optional. They can be switched off in your profile, or at operating-system level, and the platform functions without them.

We are reviewing whether to replace the message push body with a generic "New message" notice for data minimisation. If we make that change, this section will be updated to match.

08 Who receives data

The complete list of external recipients, and exactly what reaches each one:

We may also disclose data to courts, public authorities or professional advisers where we are legally required to do so, and to a successor entity in the event of a merger or acquisition — in which case you will be informed.

09 Where data is stored and international transfers

Primary storage

The application, its PostgreSQL database and all uploaded files run on servers rented from Hetzner Online GmbH. There is no managed cloud database and no object-storage service: uploaded photographs and message attachments sit on the same server's disk, in per-tenant directories. Traffic is served over HTTPS with automatically renewed certificates.

Data centre location: Falkenstein, Germany (Hetzner region fsn1) — inside the European Union. This was confirmed from the server's own instance metadata rather than assumed. A WHOIS lookup on the server's IP address may show "Amsterdam"; that reflects only how the address block is registered with RIPE, and the physical data centre is in Germany.

Under Turkish law this is a transfer abroad and is treated as one throughout this policy. Under GDPR, Germany is inside the EEA, so the hosting itself does not give rise to a Chapter V transfer.

Transfers outside your country

The following processing involves recipients that are, or may be, outside Türkiye and outside the EEA:

• Push notifications — Google, Expo and Apple operate globally, with infrastructure including the United States. Because notification bodies carry message text, this is a transfer of message content, not merely of a token.
• The weekly backup spreadsheet — uploaded to Google Drive, which is processed on US-based infrastructure. It contains customer and employee names and financial figures. This step is conditional: it is produced only for tenants with the tank-cleaning module enabled, and the upload is skipped entirely if it is not configured on the server. We are reviewing whether to keep this step at all or to hold the backup only on our own server; if it is removed, this policy will be updated.
• Map tiles, fonts and the exchange-rate service — these receive your IP address only, from the web/desktop client.
• The mobile map — Apple (iOS) or Google (Android) receive your IP address and the map region and marker positions being displayed, because the map is drawn by the operating system's map component.

Transfer mechanism: under KVKK Article 9 a specific ground is required for each transfer abroad — including the hosting in Germany — and under GDPR Chapter V an appropriate safeguard is required where data leaves the EEA. Putting standard contractual clauses in place with these recipients is work in progress. We deliberately do not claim a mechanism we have not yet concluded. In the meantime the optional ones can be avoided: push notifications can be switched off, and the map screens need not be opened.

10 Retention — an honest statement

Personal data is retained for the periods set out below. At the end of the applicable period it is deleted or irreversibly anonymised.

Removal from backups. Because backup files are rotated, a deleted record may still exist inside a backup for a short while. It is removed from backups within 90 days at the latest of the deletion request.

Where a statutory obligation prevents immediate deletion, the request is not refused: the record is kept only to the extent that obligation requires, is not processed for any other purpose, and is deleted once the period expires. We tell you which records were kept and why.

Two time limits in the system are sometimes mistaken for retention periods, and are not: signed file access links expire after 7 days by default (the file itself is not deleted), and weekly backup files are rotated locally, keeping roughly the last twelve copies.

11 Your rights

Subject to the conditions of applicable law, you have the right to:

• Access — obtain confirmation of whether we process data about you and a copy of it.
• Rectification — have inaccurate or incomplete data corrected.
• Erasure — have data deleted where there is no overriding legal obligation to keep it.
• Restriction — have processing limited while a dispute over accuracy or lawfulness is resolved.
• Objection — object to processing based on legitimate interests, on grounds relating to your particular situation.
• Portability — receive data you provided, in a structured, commonly used, machine-readable format, and have it transmitted to another controller where technically feasible.
• Withdraw consent — at any time, where processing is based on consent.
• Not be subject to automated decision-making — we do not carry out automated decision-making or profiling that produces legal or similarly significant effects.
• Complain — to your supervisory authority. In Türkiye this is the Personal Data Protection Authority (KVKK Kurumu); in the EEA, the authority of your habitual residence.

How to exercise them

Write to destek@kunduzsuite.com. We will respond within 30 days, the period required by KVKK, and within one month as required by GDPR. Because the controller is a natural person with no published postal address, an e-mail is sufficient as a written request.

Two practical points, stated openly:

• If the data concerns your work at a company that subscribes to Kunduz Suite, that company is the controller. We will forward your request to it and support it in responding; we will not delete a subscriber's operational records on a third party's instruction alone.
• There is currently no self-service "delete my account" or "export my data" button in the app. Deletion is therefore requested one of two ways, and both delete the account record permanently: (1) your organisation's administrator deletes it from the Users screen of the web panel; or (2) you write to destek@kunduzsuite.com with the subject "Account deletion request", giving your name, the e-mail or phone number on the account, your company and your role. We verify that the request comes from the account holder, delete the account within 30 days at the latest, and confirm in writing. An in-app account-deletion request screen and a self-service export are planned; App Store Guideline 5.1.1(v) expects deletion to be initiable from inside the app.

What deletion actually removes

12 Security measures

Only measures that are actually implemented are listed here. No certifications are claimed, and none are implied.

• Tenant isolation enforced by the database. Every operational table carries a tenant identifier and is protected by PostgreSQL row-level security in forced mode, applied to both read and write. The application connects with a database role that cannot bypass it. On startup the service verifies this and refuses to run in production if the guarantee is missing. An application bug therefore cannot leak one customer's data to another.
• Credentials are hashed. User passwords and driver PINs use bcrypt. Site staff PINs use HMAC-SHA256 with a secret "pepper" kept in the server environment rather than in the database. If that secret is missing in production, the application fails closed rather than degrading silently. We do not claim that a stolen database backup could not expose short PINs today: a migration bridge still in place is described under "Known limitations" below.
• Administrators can set a staff PIN but cannot read it. The PIN and its hash are stripped from API responses; only a "PIN is set" flag is returned.
• Encryption in transit. All traffic between the apps and the server uses HTTPS/TLS with automatic certificate management.
• Signed, time-limited file links. Uploaded photographs and attachments are stored under random UUID filenames and are not publicly served. Each link carries an expiry and an HMAC signature, verified with a constant-time comparison. Path traversal is rejected, HTML/SVG/JavaScript files are never served, content type is forced from the extension, and a restrictive content-security policy plus no-sniff headers are applied.
• Role-based access control across ten roles, with endpoints restricted to the roles that need them — for example a customer account can only ever reach records tied to its own account, and the warehouse role has no access to messaging.
• Audit logging with credential masking. Changes are recorded with the acting user, the action and the request payload; fields whose names suggest a password, PIN, token, key or secret are masked before the payload is written to disk.
• Login hardening. A uniform error message, a constant-time response floor and a decoy hash computation prevent account enumeration; failed attempts are rate-limited.
• Further controls: rate limiting, restricted cross-origin access, size and connection ceilings on the real-time channel, separate signing keys for user and administrator sessions with a minimum key length enforced in production, and a session-version mechanism that allows existing sessions to be invalidated.
• Token storage. On mobile, the session token, your user profile and your workspace record are held in the device's secure keystore (iOS Keychain / Android Keystore).

If there is a breach

If personal data is unlawfully accessed, we will notify the Turkish Personal Data Protection Authority (KVKK Kurumu) as soon as possible and in any event within 72 hours of becoming aware of it, and we will inform the affected individuals and, where we act as processor, the subscribing company without undue delay. Where GDPR applies, the same 72-hour rule under Article 33 is followed.

13 Known limitations

No system is without weak points. These are the ones we know about and consider material enough to disclose:

• The audit log records changes only, not reads. There is no record of who viewed a given record — only of who modified it. We do not claim otherwise.
• Signed file links are not bound to a specific user. Anyone who obtains a link can open that file until it expires — up to 7 days by default.
• The audit log's request payload is not scrubbed of personal data. Masking covers credentials only; an identity number or phone number submitted in a form is written to the log in readable form.
• National identity numbers are stored without field-level encryption or masking. They are protected by tenant isolation, role restrictions and transport encryption, but not by encryption of the field itself. Note also that the identity number held on a tractor-unit record is visible to every office role (administrator, manager, operations, owner and accounting), not only to administrators; only the identity number on the employee record is restricted to administrator and manager.
• A plain-text PIN column still exists for site staff. PINs were moved to HMAC-SHA256 hashes, but the old plain-text column was not dropped, and where a hash has not yet been generated for a person, verification still accepts the plain-text PIN. The plain text is cleared when that person's PIN is next changed, or when the back-fill tool is run. Until the column is dropped, a stolen database backup could expose the PINs of any staff record that has not yet been migrated. The column will be dropped once every record has been migrated to a hash; when it is, this item will be removed from the list.
• Messages are not end-to-end encrypted, and their content passes through third-party push infrastructure (section 07).
• In the web client, the session token is stored in browser local storage; a successful cross-site scripting attack against the browser could expose it. The mobile app is not affected.
• A provider system administrator can technically reach all tenants' data, including messages (section 08).

14 Children

Kunduz Suite is workplace software. It is not directed at children, contains no content intended for them, and accounts are created only by an employer for its own personnel and business contacts. Users are expected to be 18 or older, or of legal working age.

We do not knowingly collect personal data from children. If you believe a child's data has been entered into the system, contact us at destek@kunduzsuite.com and we will act on it together with the subscribing company.

15 Cookies, tracking and local storage

Kunduz Suite does not use cookies. Authentication uses a bearer token sent in a request header, not a session cookie. There are no advertising, analytics or tracking cookies anywhere in the product or on the marketing website.

What is stored on your device:

• Mobile app: the session token, your user profile and your workspace identifier, in the operating system's secure storage.
• Web and desktop client: the session token and preferences in browser local storage. The session lasts 30 days by default; administrator sessions last 12 hours.
• Marketing website: one entry recording your language choice. It is strictly functional, is never sent anywhere, and does not identify you. The site makes no external requests at all — fonts are embedded in the page rather than loaded from a font provider — which is why no cookie banner is shown.

You can clear this storage at any time through your browser or by signing out; doing so simply ends your session.

16 Mobile app permissions

The app requests no permission other than the three above. On iOS, usage descriptions are declared only for the camera and the photo library; no location, contacts, calendar or health permission is declared.

17 Changes to this policy

If we change this policy we will update the version number and the "last updated" date at the top of this page. For changes that materially affect how your data is used — a new recipient, a new category of data, a new transfer abroad — we will notify affected users in the application or by e-mail before the change takes effect.

Superseded versions are kept so that it is possible to see what changed and when, and are sent to you on request to destek@kunduzsuite.com.

18 Contact

For any question about this policy, or to exercise the rights described in section 11:

• All enquiries, privacy questions and rights requests: destek@kunduzsuite.com

This is the only contact channel we operate. No telephone support line and no postal address are published; a written request sent by e-mail is sufficient to exercise the rights described in section 11.

If you are in Türkiye, you may also apply under the procedure set out in KVKK and, if unsatisfied with our response, complain to the Personal Data Protection Authority. If you are in the EEA or the UK, you may complain to your local supervisory authority.