abusend: privacy and data handling

This page covers what abusend stores, how long it keeps it, how to erase it, and who else sees it. It is written for the teams integrating the service and for their privacy/DPO reviewers. It describes the software's behaviour, not a legal opinion: check your own privacy notice and legal basis (fraud prevention and security are commonly handled as a legitimate interest) with your counsel.

What abusend does with the data. It makes rule-based access decisions and orchestrates verifications: your rules, on facts you send (account age, amount, country, usage) and on client signals it measures (hints, not verdicts), decide whether a request is allowed, left to your app, blocked, or asked to pass a check (a captcha widget, or your own SMS, e-mail, KYC or custom flow). It does not build profiles for marketing and does not sell or share data.

For a hosted (SaaS) deployment the service operator processes this data on your behalf. A self-hosted deployment keeps everything in your own PostgreSQL, ClickHouse and Valkey services.

Türkiye / KVKK: see the KVKK annex (in Turkish, with an English summary) for roles, legal basis, cross-border transfer and a ready-to-paste privacy notice. Hosted service: where the data lives, sub-processors and a data processing agreement template.

What is stored

1. Per token request (POST /v1/assess, from the browser) — signals

No decision is made or stored at this step.

JavaScript signals (collected by abusend.js at the moment a token is requested):

Deep signals (the hardened probe). Additional client signals; each is bucketed or hashed where possible, and only signals relevant to spotting automation and tampering are collected (never clipboard, precise geolocation, or contacts). Like every client signal, they are hints that feed rules and a risk score, not decisions.

Rendering / device fingerprints — only collected when device identity is on (settings.privacy.device_id = on or recognition). When it is off, the SDK is told not to collect them (the handshake returns policy.fp = false) and the edge additionally discards them if a stale client sends them anyway, so no fingerprint is stored:

Consistency cross-checks and tamper/hook detection — collected regardless of the device id setting; they are booleans about the browser environment, not personal data: ua_platform_mismatch, ua_ch_mismatch, tz_lang_mismatch, clean_dirty_mismatch, screen_anomaly, native_tostring_tampered, navigator_getter_overridden, timing_hooked, debugger_present, vm_selfcheck_fail, bytecode_integrity_fail, cdp_detected, webdriver_advanced.

Behavioural entropy — pointer_entropy, untrusted_events, interaction_timing: bucketed counts / coarse timings of pre-submit interaction. No keystrokes, text, pointer coordinates or event targets are recorded — only aggregate numbers. (The one exception is the task box of abusend's own visible checks, and only while the visitor does the task: see verifications.)

Unknown keys are dropped and all values are length-capped on the server.

Device identity

Unless the project turns it off (settings.privacy.device_id = "off", panel → Setup → Privacy), /v1/assess gives the browser a device id: 16 random bytes, the project id, the creation time and an HMAC signature (d1.…). It carries no information about the person or the device; it only lets abusend recognise the same browser again (e.g. "this browser was used by 12 accounts today", "this browser passed a check an hour ago").

• Where it is kept: in a cookie of the abusend edge host, __Host-ab_did (Secure; HttpOnly; SameSite=None; Partitioned; Max-Age one year). Partitioned (CHIPS) means the browser keeps a separate cookie per top-level site: the id is not shared between your site and any other site that uses abusend. The SDK also keeps a copy in your site's localStorage (abusend.did), so the id survives browsers that drop third-party cookies.
• Scope: one id per project. Ids of another project are ignored; nobody (including other abusend customers) can link your visitors' ids to theirs.
• What is stored with it: the device (first/last seen, the fingerprint hash it was last seen with; when you put the device on allow_devices, the fingerprint hash it had then, so the allow only works from that browser), the device id and its source (cookie or localStorage) on each assessment, the device on the verifications it was issued (binding and remembered passes), and — when your server names a user in a verdict — a device–user link (first/last seen, number of verdicts, last decision).
• Turned off: no id is issued, stored, set as a cookie or returned (/v1/assess answers "device_id": null, which makes the SDK delete its localStorage copy); no fingerprint hash is computed or stored; an existing cookie is deleted on the next request; rules about devices see "no device", and widget passes are not remembered.

Under the EU ePrivacy rules (and similar national laws) storing an identifier on the visitor's device needs consent unless it is strictly necessary for a service the user requested; abuse and fraud prevention on login, sign-up and checkout is commonly treated as strictly necessary security processing. Check this with your counsel and mention the cookie in your cookie notice; if in doubt, turn device ids off.

Device recognition (opt-in)

Off by default. With settings.privacy.device_id = "recognition" (panel → Setup → Privacy → Recognise devices in private windows; test and live projects alike) abusend also links a desktop browser that sends no device id — a private / incognito window, a browser whose storage was cleared — to a known device on the same network, from the fingerprint of the browser. It links, it never merges: the browser always gets its own new device id.

• Purpose and legal basis: fraud and abuse prevention (your rules can tell that a private window on the same network looks like a blocked or heavily shared computer). Legitimate interest (GDPR art. 6(1)(f), KVKK art. 5(2)(f)); this is device fingerprinting: document your balancing test, describe it in your privacy notice and, where your counsel says the ePrivacy rules require it for reading device characteristics, collect consent before turning it on.
• Whom it covers: desktop browsers only (Windows, macOS, Linux, ChromeOS). Phones and tablets — every iPhone and iPad browser, Android, other touch-first devices — are never fingerprinted into storage and never linked: identical models look identical.
• How: when an assess request from a desktop browser carries no valid device id, the edge derives a print from the components that stay the same in a private window — the canvas, WebGL render, WebGL vendor/renderer, audio and font-set hashes, the Math-quirk hash, screen size, time zone, number of languages and the first Accept-Language tag, the operating system, CPU cores and touch points, the TLS fingerprint (JA4N) and the browser family and major version. Window size, interactions, timings, behavioural entropy and anything the browser stores are not part of it. The print is compared only with the project's devices last seen on the same network block (IPv4 /24, IPv6 /48, public addresses only) in the last 30 days: one device with exactly the same print → linked with confidence high; otherwise one device with the same browser family whose components mostly agree, better than any other → medium. Weaker or ambiguous candidates are never linked. Busy networks are skipped (more than 20 devices with a print on the block in 7 days: mobile carrier NAT, offices, campuses, hotels), and a print seen on two devices in use at the same time (identical machines, two browser profiles) is marked shared and never used again.
• What a link does: it is recorded on the assessment (the linked device id and the confidence) and your rules can read it (device.recognized, device.recognition, device.recognized_blocked, device.recognized_users). It never blocks anyone by itself (block lists apply only to the browser's own id) and never carries trust (allow lists, remembered verification passes, "known device of this user" and the device's age are the new id's). What happens on a link is decided by your own rules.
• What is stored: per desktop device, one row of keyed hashes only (HMAC-SHA256 with a server key, bound to the project, truncated to 96 bits): one per component, one over all of them, one of the browser family and one of the last network block, plus the device it was linked to, if any; per project, the keyed hashes of prints marked shared. No raw value (no canvas hash, time zone or IP) is stored, the hashes cannot be reversed without the server key, and the same browser gives unrelated hashes in two projects. On each linked assessment: the linked device id and the confidence (high · medium).
• Limits (a hint, never a verdict): browsers that randomise their fingerprints — Safari private browsing, Firefox with fingerprinting protection, Brave — are detected (signal fingerprint_randomized) and not linked. Identical desktop machines on one network (a family's two identical laptops) may be linked once, until the second one's id is established (a day); the print is then marked shared. A browser update or a new monitor can prevent a link; a laptop on another network is not linked. Every client-side value can be forged.
• Retention and erasure: a print is deleted 30 days after the device was last seen with it (or after retention_days when shorter), with the device, when an end user linked to the device is erased (together with the prints of browsers linked to it, the shared mark of its print and every link to it), and — all prints and shared marks of the project at once — when the project turns recognition off. Shared marks are otherwise kept while recognition stays on. privacy.device_id = off still means no id, no fingerprint and no print.

2. Per verdict (POST /v1/verdict, from your server) — decisions and their inputs

3. Per verification (checks and challenges)

A check is a verification tool your project connects; a challenge is one issued verification of it.

• Widget checks (Cloudflare Turnstile, Google reCAPTCHA / reCAPTCHA Enterprise, hCaptcha, Friendly Captcha, GeeTest): the visitor's browser loads the provider's script and talks to the provider directly; the provider receives what any embedded script receives (IP address, browser and device data, its own cookies; Friendly Captcha also interaction timing, GeeTest the network type) and processes it under its own terms (Cloudflare Turnstile privacy addendum, Google privacy policy, hCaptcha privacy policy, Friendly Captcha privacy, GeeTest privacy policy). A visible check shows the widget in a dialog the abusend browser SDK draws; the data flows are the same. The abusend server verifies the result with the provider: it sends the provider's response token, your provider secret and the visitor's IP address; for Turnstile an idempotency key; for hCaptcha the site key; for reCAPTCHA Enterprise the site key, expected action and the User-Agent. For Friendly Captcha it sends only the response and the site key (no IP address; the API key in a header) to its global API or, with region: eu, its EU API (Germany); for GeeTest only the widget's result (lot_number, captcha_output, pass_token, gen_time), the captcha_id and a signature made with your key (no IP address, the key itself never travels). It gets back success, hostname or origin, action and (reCAPTCHA) a score.
• GeeTest is a Chinese provider (Wuhan Jiyi Network Technology Co., Ltd.). Its privacy policy says it stores what it collects in the People's Republic of China, for one year; the visitor's browser sends it IP address, network and device data when the widget loads. Connecting a GeeTest check is therefore a transfer to a third country without an adequacy decision (GDPR chapter V: you need a transfer mechanism such as standard contractual clauses and a transfer impact assessment; KVKK art. 9, see the annex). Tell your users in your privacy notice. Friendly Captcha GmbH is in Germany (EU hosting).
• abusend's own checks (abusend_pow, abusend_hold, abusend_trace) involve no third party: the browser loads nothing from another host, and the abusend edge verifies the answer itself (no egress). abusend_pow is a proof-of-work puzzle the visitor's browser solves (CPU time only; no personal data beyond the request itself). For abusend_hold and abusend_trace the browser SDK records the pointer events on the task's box only, while the task is shown: time, position inside the box, press / release, the pointer type (mouse, touch, pen), the box's size and pixel ratio, and a count of events the page dispatched itself — no keystrokes, nothing outside the box. The recording is sent with the answer to the abusend edge, scored there in memory (by heuristics, a hint) and not stored or logged; what remains is the challenge's status, detail code and movement score, and a SHA-256 hash of the recording's relative movements kept one day to refuse a replay. The panel's "try it" preview works the same way and stores nothing.
• App checks (SMS, e-mail, KYC, custom) are run by you, in your app and with your own providers (your SMS gateway, your KYC vendor), who are your processors, not abusend's. abusend never sees the phone number, the code, the document or the result details: it records only that a verification was issued and the outcome your server reports (passed, failed, abandoned).
• Per challenge abusend stores: the check, kind and provider, the action, the flow, status and a short detail code (e.g. timeout, abandoned, low_score), the provider score, attempt count and times; its bindings — your user id link, the device id, fingerprint hash and the network prefix (IPv4 /24 · IPv6 /48, never the full address); and, once a verdict consumes it, that caller's identity (user id, client IP, device id, action) and a copy of the verdict answer, used to answer an identical retry within 5 seconds. A SHA-256 hash of each accepted provider token — for abusend's own checks, of the recording's relative movements — is kept for one day (replay protection).
• A widget check's provider secret is stored encrypted (AES-256-GCM, bound to the project and the check) and never shown again. App checks and abusend's own checks have no secret.

Enabling a widget check makes that provider a recipient of your visitors' data — list it in your privacy notice (KVKK art. 9 / GDPR chapter V, see the annex). abusend's own checks add no recipient; mention in your notice that the visible ones process pointer movement on the task box to score the attempt (and do not store it).

4. Panel

• Allow/block list entries: value (IP, CIDR, user id or device id), note, expiry, author.
• Check configuration and encrypted provider secrets (write-only).
• Rule hit counts per hour (no personal data).
• Panel accounts of your team: email, name, password hash (argon2id), session tokens (stored as SHA-256 hashes), last login, two-factor authentication data (TOTP secret, single-use recovery codes stored as hashes), and an audit log of configuration changes (actor, time, IP, before/after; see retention).
• Invitations: invited email, role, expiry. The invite link token is stored as a hash.
• API keys are stored only as SHA-256 hashes. The secret is shown once.
• Personal access tokens (for the panel API and the MCP server) are stored only as SHA-256 hashes, with their name, prefix, scope (organization, maximum role), expiry and last use. The token is shown once.
• Notifications: the platform's SMTP settings (server, user name, sender; the password is AES-GCM encrypted and write-only), and per project the webhook / Slack destinations you add (URL and signing secret encrypted, shown masked). Every queued notification is a row of the outbox with the recipient's e-mail address (a panel user or an invitee) or the destination id, and the rendered message; a message that has been sent (or given up) drops its body at once and the row keeps only the subject or event, the address, status and error text for 30 days. Invitation e-mails carry the one-time invitation link; it is never logged and, once the message is sent, no longer stored.
• AI assistant (optional, off by default): the organization's provider settings, with the provider API key AES-GCM encrypted (write-only), plus each user's conversations (questions, answers, the tools called and their results). A conversation can only be seen by the user who owns it. See AI assistant and MCP.

Retention

Erasure API

DELETE /v1/users/{id}          Authorization: Bearer sk_…   → {"ok": true, "erased": true}
                                                            → {"ok": true, "erased": false}   (nothing stored for this id)

The call is idempotent: erasing an id that is unknown or already erased succeeds with "erased": false (never 404), so retries and repeated data-subject requests are safe.

Admins can also erase a user from the panel. The part in the main database runs in one transaction; the parts in the analytics store and in Valkey follow in the same call (see What "erased" means below). Together the erasure:

1. deletes the end user, all their attributes and every event your server reported for them (POST /v1/events, with its properties and id; events live in the analytics store),
2. removes the user id from every user list of the project (e.g. allow/block users),
3. anonymises the user's assessments (found through the verdicts that redeemed them): IP truncated to its /24 (IPv4) or /48 (IPv6) network; headers, header names, JS signals, user agent, origin, device id and fingerprint hash cleared; the link to the user removed,
4. deletes the user's device–user links (the devices themselves stay until retention removes them; they no longer point to the user) and the recognition prints of those devices, the prints of the browsers linked to them and the shared marks of their prints; the user's assessments lose their recognition link, and every other assessment's link to those devices is cleared,
5. anonymises the user's verdicts: client IP truncated the same way, the stored inputs (attribute snapshot, context, counters) and the feedback note cleared, device id and user link removed,
6. unlinks the user's verifications (and those of the user's flows): user link, device id, fingerprint hash, the consumed caller identity and the stored verdict answer are cleared; the network prefix and the outcome stay until retention,
7. removes the user's attribute values from the project's attribute examples,
8. deletes the organization's AI assistant conversations that mention the user id (typed in a question, or in a tool call or result; Watch's investigations are such conversations), clears the summary of any Watch run that names it and the findings and open counter episodes of Watch that list it as a value,
9. scrubs the user id from the audit log (e.g. entries recording that an analyst allow- or block-listed the user). The audit entry for the erasure itself stores only a hash reference of the id, never the id, so you can show that an erasure happened (by hashing the id from the request again) without keeping the identifier.
10. deletes the user's window of verdict ids in Valkey and the hot records of the assessments its verdicts redeemed (a record holds the derived user id and the client IP of the redemption). The other short-lived state there (the windows of a device, an IP address or a fingerprint, which hold opaque ids and no user id, and the records of assessments no verdict has redeemed yet) expires on its own within the times in Retention (at most 24 hours; a record within its token's lifetime plus 10 seconds).

What "erased" means. The call answers 200 once the erasure is recorded and its part in the main database is done. abusend then also changes the analytics store and Valkey in the same call and waits up to 10 seconds for the analytics store's mutations. Whatever fails or is still running at that point stays as a pending erasure: a row in the main database that names the user only by its derived ids (and by the assessments, flows and devices its verdicts named), never by your id, which abusend retries with a growing delay until every step succeeded. It also runs once more about 30 seconds after the call, for rows another pod wrote in between. So the erasure is guaranteed to finish without another call, normally within a minute; an outage of the analytics store or of Valkey delays it until the service is back, and the operator is alerted (AbusendErasurePending) when one has been pending for 15 minutes. The answer does not say whether those parts are already done: if you must be certain of the state at a given moment, wait a minute before you tell the person that it is complete.

Verdicts written behind the answer. Verdict rows are written a few milliseconds after the answer (log.async; operator documentation: "Write-behind verdict log") and reach the analytics store about a second later. Erasure fences that queue and the analytics store's own: rows of the user still waiting on any of abusend's pods are anonymised (IP cut to its network, user, device and inputs dropped) before they are written, every pod is told, and the erasure is repeated about 30 seconds later to catch rows another pod wrote in between. What a queued verdict names, although the masked verdict no longer names the user (the assessment behind it with its IP, user agent, headers and JS signals, the verifications of its flow, the recognition prints of its device and the hot record in Valkey), is erased with the user: the pod that masked the row records it as a pending erasure of its own. A row is masked only if it is not newer than the erasure, so a user who returns afterwards starts a new record. A call for a user whose row was still queued can answer "erased": false although its queued rows were masked. Traffic of the same user sent while the erasure runs may leave a row that the repeat removes.

The analytics store. abusend keeps verdicts, assessments, events and the verification history in its ClickHouse service (same processor and location as the main database); these are the only copies of that data. Erasure changes them: events are deleted, the IP is cut to its network block, the user, device, fingerprint, inputs and feedback note are cleared; rows still waiting to be written are anonymised before they are. The mutations name the user only by its derived ids, never by your id (the server keeps the text of its mutations). If that service is unreachable at that moment the erasure of the main database still succeeds and the analytics rows are changed by the pending erasure as soon as it is back (see What "erased" means). The verdict rows are changed last, and only when every other step succeeded: they are what the other rows are found through, so a failed step is retried from the unchanged verdicts.

Backups. The nightly backups of the analytics store are kept for 7 days: an erased user's rows in a backup are not changed and leave with the backup when it ages out. The same holds for the dumps of the main database, for as long as the operator keeps them (data location). After a restore from a backup, repeat the erasures made since it was taken (each one leaves a hash reference in the audit log).

What stays until normal retention removes it is not linked to the user: TLS/HTTP-2 fingerprints, the truncated network, IP data (ASN/owner/country), decisions, reasons and verification outcomes. Erasure cannot be undone. Call it from your account-deletion flow. A later verdict that sends the same user id creates a new, empty user.

Only the user's own events are anonymised. An assessment is linked to a user through the verdicts that redeemed its token; assessments that were never redeemed with a user id carry no user link and expire through retention.

Third-party IP reputation

• Default: IP data is local only, for every project. The server embeds public datasets (Tor exit list, X4BNet datacenter and VPN ranges, iCloud Private Relay egress ranges) and refreshes them from their public URLs. Those downloads send no customer data.
• Optional remote providers are enabled by the service operator in the server configuration (iprep.drivers):
  • scamalytics: sends the IP address only (HTTPS GET https://scamalytics.com/ip/<ip>) and reads back a fraud score.
  • httpjson: a provider of the operator's choice. The IP address is sent to the configured URL.
• Per-project opt-in: settings.privacy.third_party_iprep (panel → Setup → Privacy) defaults to false: lookups use local datasets only, and no IP address of your users leaves the service. Only when you switch it on and the operator has enabled a remote provider is the end-user IP address (nothing else) sent to that provider. The provider may be outside your country: check the cross-border transfer rules that apply to you (for Türkiye, KVKK art. 9, see the annex).

Where the data lives (data residency)

All stored data lives in services chosen by whoever runs the server: end users, devices, running challenges, lists, the audit log and panel accounts in one PostgreSQL database; the traffic data (assessments, verdicts, reported events, the verification history) in the operator's ClickHouse next to it; and the short-lived hot state (assessment records, velocity windows, what rules read of events and counters) in the operator's Valkey, see Retention. Nothing is copied to a service outside the operator's stack; the IP reputation cache is in memory only.

• Self-hosted: your database, in your infrastructure and region.
• Hosted service: the operator configures where the database, the servers and the backups run. The reference deployment is a single-node k3s cluster in the operator's own infrastructure (no public-cloud database service). Operators fill in their statement:

Data location (operator to fill in): servers and database: [country, city / data centre, provider or "own hardware"]. Backups: [country, location, encryption, retention]. Remote administrative access from: [countries]. Any change is announced [N] days in advance to [contact].

If any of these locations is outside Türkiye, that is a cross-border transfer under KVKK art. 9 (see the annex); outside the EEA, check GDPR chapter V.

Sub-processors

By default there are none. A default installation sends no personal data to any third party: IP data uses local datasets, no check is connected, and the hosting of the reference deployment is the operator's own infrastructure.

App checks are not sub-processors of abusend. The SMS gateway, e-mail service or KYC vendor behind an app check is chosen, contracted and called by you; abusend only records the outcome your server reports.

abusend's own checks (abusend_pow, abusend_hold, abusend_trace) have no sub-processor: the abusend edge verifies them itself and sends nothing anywhere.

Operators keep this list current and notify customers before adding a sub-processor.

AI assistant and MCP

• AI assistant (BYOK). When an organization admin enables the in-panel assistant, the questions of your panel users and the panel data the assistant looks up to answer them are sent to the LLM provider your organization chose, under your own contract and API key with that provider. The data can include verdict and flow details (IP addresses, User-Agents, end-user ids, device ids, attributes, context, reasons), rules and settings. This is a transfer you control: disable the assistant or remove the key to stop it. If the provider is outside your jurisdiction, assess the transfer (GDPR chapter V, KVKK art. 9) and name the provider in your records of processing. abusend sends nothing to an LLM provider unless you set this up, and API keys are never sent to the model. Messages are kept for at most the project's retention (retention_days, at most 30 days), and erasing an end user deletes every assistant conversation of the organization that mentions the id (see retention and erasure).
• Watch (Nöbet). When an admin switches Watch on for a project (off by default) and the assistant is enabled, abusend starts investigations on its own when the traffic looks unusual: the same assistant, with the same key and provider, reading the same kinds of panel data (traffic excerpts: IP addresses, end-user ids, device ids, attributes, flow details) — but with nobody reading along at that moment, up to the project's run limits (4 an hour, 24 a day unless changed). The transfer is therefore continuous while Watch is on: switch Watch off (or the assistant, or remove the key) to stop it. Everything that came from your traffic is presented to the model as untrusted data, never as instructions; it may only add Monitoring rules and new counters on its own, and every other change waits for an admin's approval. What Watch itself stores is aggregate: traffic counts per project, action, country and ASN in 5-minute buckets (8 days, no personal data), and its runs (the findings' numbers, the model's summary, kept 90 days; the summary is cleared when a user it names is erased). Its alerts and reports (e-mail, webhooks, Slack) contain numbers, the action name, a country code or ASN and that summary, and no e-mail addresses by design. A note about an enforcing rule that applies to the values of a counter (one note per rule, not per value) also names up to five of those values as examples, and the run record keeps up to 50: when the counter is grouped by IP address, end-user id or device id these are IP addresses or ids, so treat the recipients and the webhook destinations as people and systems that may see them. A summary written by the model can also quote what it read.
• MCP server. A panel user can connect an AI client (Claude, Cursor, VS Code, …) with a personal access token. Tool results, which include the same kinds of panel data, then go to that client and to its model provider. That is the user's (your organization's) choice and responsibility. Tokens can be limited to one organization and to read-only access, and every change made through them is recorded in the audit log.

Data processing agreement (DPA) template

Not legal advice. A starting point for the agreement between you (controller) and the operator of a hosted deployment (processor) under GDPR art. 28 / KVKK art. 12(2). Have it reviewed by counsel; fill in the […] fields. A Turkish version is in the annex. Self-hosted installations need no DPA with an abusend operator.

DATA PROCESSING AGREEMENT

Parties: [Customer legal name, address] ("Controller") and [Operator legal name, address]
("Processor"), under the service agreement dated [date] ("Agreement").

1. Subject and duration. The Processor processes personal data only to provide the
   abusend rule-based access decision and verification orchestration service for the
   term of the Agreement.
2. Nature and purpose. Evaluating login, sign-up, payment and similar requests against
   the Controller's rules to decide whether to allow them, leave them to the Controller's
   application, block them or ask for an additional verification, in order to prevent
   fraud, abuse and account takeover; recording the outcome of such verifications. No
   profiling for marketing, no sale or other use of the data.
3. Data subjects. Visitors and users of the Controller's websites and apps; the
   Controller's panel users.
4. Data categories. IP address; User-Agent and an allowlist of HTTP headers; TLS/HTTP-2
   fingerprints; browser signals listed in the privacy documentation; a per-project device
   identifier (cookie / local storage) and a fingerprint hash, unless disabled; the opaque
   user id, attributes and request context the Controller sends; decisions with their
   inputs; verification records (outcome, network prefix, device binding); panel account
   data and audit log. The Controller will not send special categories of data, e-mail
   addresses, phone numbers or national ids.
5. Instructions. The Processor acts only on the Controller's documented instructions
   (this Agreement, the project configuration chosen in the panel, API calls) and informs
   the Controller if an instruction appears unlawful.
6. Confidentiality. Persons authorised to process the data are bound by confidentiality.
7. Security. The Processor implements the measures in the privacy documentation (TLS,
   role-based access with 2FA, hashed credentials and keys, encrypted provider secrets,
   audit log, retention) and keeps them at least at that level.
8. Sub-processors. None at signature, except: [none / list]. The Processor gives [30]
   days' notice of a new sub-processor; the Controller may object on reasonable grounds.
   Widget check providers (Cloudflare Turnstile, Google reCAPTCHA, hCaptcha, Friendly
   Captcha, GeeTest) and a third-party IP reputation provider are used only if the
   Controller enables them in its project; abusend's own checks involve none. Providers behind the Controller's own app checks (SMS, e-mail, KYC) are the
   Controller's processors, not the Processor's.
9. Location. Data is processed and stored in [country / data centre]; see the operator's
   data location statement. No transfer outside [country] without the Controller's prior
   written consent and a lawful transfer mechanism.
10. Data subject requests. The Processor enables the Controller to answer requests
    (access: GET /v1/users/{id}; erasure: DELETE /v1/users/{id}) and assists with others.
11. Personal data breaches. The Processor notifies the Controller without undue delay and
    within [24/48] hours of becoming aware, with the information the Controller needs for
    its own notifications (KVKK: to the Board within 72 hours).
12. Retention and deletion. Data is deleted per the retention settings ([30] days by
    default for assessments, verdicts and verifications, 365 days for the audit log). On
    termination the Processor deletes all Controller data within [30] days, including
    backups within [N] days, and confirms in writing.
13. Audits. The Processor provides the information needed to demonstrate compliance and
    allows audits by the Controller or its auditor on [30] days' notice, [once a year].
14. Liability and governing law. [As in the Agreement.] Governing law: [ ]. Courts: [ ].

Signatures: [Controller]  [Processor]  Date: [ ]

Recommendations

• Keep PII out of user.attributes and context. Don't send emails, names, phone numbers, addresses, national ids, payment card data, dates of birth or free text. Send derived, non-identifying facts instead:

  {"user": {"attributes": {"registered_at": 1726000000000, "payment_count": 7, "plan": "pro", "country": "TR"}},
   "context": {"amount": 100, "currency": "USD"}}
  

• Use a pseudonymous user.id: an HMAC of your internal id (or of the normalised login name) with a key only you hold. Don't use the raw email (see choosing a user id).

• Remove attributes you no longer need with null: PATCH /v1/users/{id} {"attributes": {"old_field": null}}.

• Keep feedback notes factual and without PII (e.g. "chargeback 2026-09", not the customer's name).

• Set the shortest retention that still serves you. 30 days is usually enough for tuning, replay and investigations.

• Wire erasure into account deletion and data-subject requests (DELETE /v1/users/{id}).

• Leave third-party IP reputation off (the default) if your policy forbids sending IPs to other parties.

• Device ids: keep them on if you use device rules or remembered widget passes, and mention the __Host-ab_did cookie / abusend.did storage in your cookie notice; turn them off (privacy.device_id = off) if you cannot justify them.

• Device recognition (privacy.device_id = recognition) is fingerprinting: turn it on only when you need private-window evasion covered, after updating your privacy notice (and, where required, your consent flow); treat device.recognized as a hint — prefer Verify over Block in rules on device.recognized_blocked.

• Checks: connecting a widget check adds that provider as a recipient of your visitors' data (see verifications); app checks use your own providers; abusend's own checks add no recipient (the visible ones score pointer movement on abusend's edge without storing it). Update your privacy notice first.

• Mention the processing in your privacy notice: rule-based access decisions and additional verification on login/sign-up/payment, the data categories above, and the retention.

• Keep secret keys server-side. Anyone holding one can read user attributes, report verification results and erase users of that project.

Access control

• Panel roles per organisation: viewer (read), analyst (feedback, rules, actions, lists, attributes), admin (checks and their secrets, settings, API keys, erasure, inviting members, the organisation's 2FA policy), owner (member roles and removal, deleting projects). A project the user cannot see is reported as not found.
• Two-factor authentication (TOTP authenticator apps) with 8 single-use recovery codes. Owners and admins can require 2FA for the whole organisation: members without it cannot use that organisation until they set it up.
• New members are invited by an owner or admin and join through a personal invitation link (valid 7 days), choosing their own password. Nobody sees another person's password.
• Every configuration change is recorded in the audit log (kept 365 days).

Annex: KVKK (Law No. 6698) / Ek: KVKK (6698 sayılı Kanun)

Not legal advice / Hukuki tavsiye değildir. This annex describes how the software processes data so that you and your counsel can map it to KVKK. It does not replace your own assessment, your VERBİS registration or your privacy notice. Bu ek, yazılımın veriyi nasıl işlediğini KVKK açısından değerlendirmenize yardımcı olmak için hazırlanmıştır; kendi hukuki değerlendirmenizin, VERBİS kaydınızın ve aydınlatma metninizin yerine geçmez.

English summary. You (the customer running abusend on your site) are the data controller (veri sorumlusu); the service operator of a hosted deployment is your data processor (veri işleyen). Purpose: rule-based access decisions and verification orchestration to prevent fraud and abuse; legal basis: legitimate interest (KVKK art. 5(2)(f)). Data processed: IP address, User-Agent and an allowlist of headers, TLS/HTTP-2 fingerprints (JA4/JA4N), the JavaScript signals listed above, the user id you send (use an opaque HMAC), the attributes and request context you choose, decisions with their inputs, verification records (outcome, network prefix, device binding), and — unless turned off — a per-project device id kept in a partitioned cookie and the site's localStorage, with device–user links. Only when you opt in (privacy.device_id = recognition), device recognition across private windows: per desktop device (never phones or tablets), keyed hashes (no raw values) of stable browser fingerprint components and of the last network block, used to link a desktop browser that sends no id to a known device on the same network (it keeps its own new id; busy networks and prints shared by identical machines are skipped) — device fingerprinting for fraud prevention under legitimate interest, a hint for the controller's rules and never a decision on its own (no automatic block, no carried trust), not effective against browsers that randomise fingerprints, kept 30 days after last seen and erased with a linked user. Retention: traffic 30 days by default (1–730), events 90 days (1–1095), inactive users 365 days (or until erased), per project, purged automatically every 10 minutes; audit log 365 days, with erased user ids scrubbed. Third-party IP reputation is off by default; switching it on sends end-user IP addresses to the provider. Widget checks (Cloudflare Turnstile, Google reCAPTCHA, hCaptcha, Friendly Captcha, GeeTest) are also off until you connect one; connecting a US one sends the end-user IP address (and, for reCAPTCHA Enterprise, the User-Agent) to that US provider, and every widget loads in the visitor's browser from its provider (Friendly Captcha: Germany; GeeTest: China) — cross-border transfers under art. 9. abusend's own checks (abusend_pow, abusend_hold, abusend_trace) involve no third party: the visible ones send the pointer movements on their task box to the abusend edge, which scores them and does not store them (only the score, the outcome and a one-day replay hash remain). App checks (SMS, e-mail, KYC) are run by you with your own processors; abusend records only the outcome. Erasure: DELETE /v1/users/{id} (idempotent) or the panel. Panel access is role-based with optional or organisation-enforced 2FA. Data location: operator-configured (see data residency); sub-processors: none by default. A Turkish data processing agreement template and a ready-to-paste Turkish privacy notice paragraph are at the end.

1. Roller

2. İşlenen kişisel veri kategorileri

SDK, cihaz kimliği açıkken yalnızca abusend'in kendi __Host-ab_did çerezini ve sitenizde abusend.did localStorage anahtarını kullanır; başka çerez okumaz ve saklamaz. Çerezin bölümlenmiş (CHIPS) olması, aynı tarayıcının farklı sitelerde farklı kimlik alması demektir: kimlik siteler ve projeler arasında paylaşılmaz. Cihaz kimliğini çerez politikanızda belirtin; güvenlik amaçlı "zorunlu" çerez sayılıp sayılmayacağını hukuk danışmanınızla değerlendirin.

Uygulama doğrulamalarında (SMS, e-posta, KYC) telefon numarası, kod, belge veya sonuç ayrıntısı abusend'e hiç gelmez: bunları siz kendi sağlayıcılarınızla işlersiniz; abusend yalnızca bir doğrulama adımı verildiğini ve sunucunuzun bildirdiği sonucu (passed, failed, abandoned) kaydeder.

3. Amaç ve hukuki sebep

• Amaçlar: giriş, kayıt ve ödeme gibi adımlarda, veri sorumlusunun belirlediği kurallara göre isteğe izin verilmesi, isteğin uygulamaya bırakılması, engellenmesi veya ek doğrulama istenmesi (kurallara dayalı erişim kararları ve doğrulama orkestrasyonu); bu yolla dolandırıcılığın, hesap ele geçirmenin ve kötüye kullanımın önlenmesi; bilgi güvenliğinin sağlanması.
• Hukuki sebep: KVKK m. 5/2-f: ilgili kişinin temel hak ve özgürlüklerine zarar vermemek kaydıyla, veri sorumlusunun meşru menfaati için veri işlenmesinin zorunlu olması. Meşru menfaat dengesi değerlendirmenizi (amaç, gereklilik, ilgili kişiye etkisi, alınan önlemler: kısa saklama süresi, veri minimizasyonu, opak kimlik) yazılı hale getirin.
• Hizmet profil çıkarıp pazarlama yapmaz; sonuçlar yalnızca sizin güvenlik kararınız için kullanılır. İstemci sinyalleri ipucudur; kararı sizin kurallarınız verir.
• Otomatik karar: deny (Engelle) kararları kullanıcıyı etkileyebilir. Mümkün olduğunda engellemek yerine ek doğrulama isteyin ve itiraz için bir destek kanalı sunun (m. 11/1-g: münhasıran otomatik sistemlerle analiz sonucu aleyhe bir sonuca itiraz hakkı).

4. Saklama ve imha

Bu süreleri kişisel veri saklama ve imha politikanıza yansıtın.

5. Yurt dışına aktarım (m. 9) ve üçüncü taraflar

• IP itibarı — varsayılan: kapalı. third_party_iprep her projede varsayılan olarak false'tur. IP verisi yalnızca sunucuya gömülü, herkese açık veri setleriyle (Tor çıkış listesi, veri merkezi/VPN aralıkları, iCloud Private Relay aralıkları) yerel olarak hesaplanır; bu durumda son kullanıcı verisi üçüncü bir tarafa gönderilmez.
• Açılırsa: yalnızca son kullanıcının IP adresi, operatörün yapılandırdığı sağlayıcıya (ör. Scamalytics, HTTPS üzerinden) gönderilir ve bir risk skoru alınır. Sağlayıcı yurt dışındaysa bu, KVKK m. 9 kapsamında yurt dışına aktarım olur. Açmadan önce sağlayıcının konumunu ve m. 9'daki şartlardan birinin (yeterlilik kararı, Kurul'a bildirilen standart sözleşme gibi uygun güvenceler veya istisnai hâller) sağlandığını değerlendirin ve aydınlatma metninize ekleyin.
• Barındırılan kurulumda veritabanının, sunucuların ve yedeklerin yerini operatör belirler. Referans kurulum, operatörün kendi altyapısında tek düğümlü bir k3s kümesidir. Operatörün doldurduğu veri konumu beyanını isteyin: Türkiye dışında bir konum da m. 9 kapsamında aktarımdır.
• Widget doğrulamaları — varsayılan: bağlı değil. Projenize Cloudflare Turnstile, Google reCAPTCHA veya hCaptcha bağlarsanız: ziyaretçinin tarayıcısı sağlayıcının betiğini doğrudan sağlayıcıdan yükler (sağlayıcı kendi koşullarıyla IP adresi, tarayıcı bilgileri ve kendi çerezlerini işler); abusend sunucusu sonucu doğrulamak için sağlayıcıya yanıt jetonunu ve son kullanıcının IP adresini gönderir (hCaptcha için site anahtarı; reCAPTCHA Enterprise için site anahtarı, işlem ve User-Agent da). Üç sağlayıcı da ABD merkezlidir (Cloudflare, Inc.; Google LLC; Intuition Machines, Inc.): bu, KVKK m. 9 kapsamında yurt dışına aktarımdır. Bağlamadan önce m. 9 şartlarını değerlendirin ve aydınlatma metninize ekleyin.
• Friendly Captcha (Friendly Captcha GmbH, Almanya): tarayıcı widget'ı cdn.jsdelivr.net üzerinden yükler ve *.frcapi.com ile konuşur (IP adresi, tarayıcı ve cihaz bilgileri, etkileşim zamanlaması); abusend sunucusu yalnızca yanıtı ve site anahtarını gönderir (IP adresi göndermez), region: eu ile AB API'sine. Almanya'ya aktarım da KVKK m. 9 kapsamındadır.
• GeeTest v4 (Wuhan Jiyi Network Technology Co., Ltd., Çin): tarayıcı widget'ı doğrudan GeeTest'ten yükler; GeeTest gizlilik politikasına göre topladığı verileri (IP adresi, ağ türü, cihaz bilgileri) Çin Halk Cumhuriyeti'nde bir yıl saklar. abusend sunucusu yalnızca widget sonucunu (lot_number, captcha_output, pass_token, gen_time), captcha_id'yi ve anahtarınızla yapılmış bir imzayı gönderir (IP adresi göndermez). Çin için yeterlilik kararı yoktur: GeeTest bağlamak KVKK m. 9 kapsamında uygun güvence (ör. standart sözleşme ve Kurula bildirim) veya istisnai hâl gerektiren bir yurt dışına aktarımdır; AB'deki kullanıcılar için de GDPR V. bölüm (standart sözleşme maddeleri ve aktarım etki değerlendirmesi) geçerlidir. Bağlamadan önce değerlendirin ve aydınlatma metninize ekleyin.
• abusend'in kendi doğrulamaları (abusend_pow, abusend_hold, abusend_trace): üçüncü taraf yoktur. Tarayıcı başka bir adresten hiçbir şey yüklemez, yanıtı abusend edge'i kendisi doğrular ve hiçbir yere veri göndermez; bu doğrulamalar yurt dışına aktarım veya alt işleyen gerektirmez.
• Uygulama doğrulamaları (SMS, e-posta, KYC): sağlayıcılarını siz seçer ve siz çağırırsınız; onlara yapılan aktarım sizin sorumluluğunuzdadır ve abusend üzerinden geçmez.
• Alt işleyenler: varsayılan kurulumda yoktur. Üçüncü taraf IP itibar sağlayıcısı yalnızca operatör açtığında ve projeniz third_party_iprep ayarını açtığında, widget doğrulama sağlayıcısı yalnızca projeniz o doğrulamayı bağladığında kullanılır. abusend'in kendi doğrulamalarının alt işleyeni yoktur.

Yapay zekâ asistanı (BYOK) ve MCP. Kuruluşunuzun bir yöneticisi panel içi asistanı kendi API anahtarınızla açarsa, kullanıcıların soruları ve asistanın yanıt için okuduğu panel verileri (IP adresi, User-Agent, son kullanıcı kimliği, cihaz kimliği, öznitelikler ve bağlam dahil verdict ve akış ayrıntıları, kurallar, ayarlar) sizin seçtiğiniz LLM sağlayıcısına, sizin o sağlayıcıyla olan sözleşmeniz kapsamında gönderilir. Bu aktarımı siz kontrol edersiniz. Sağlayıcı yurt dışındaysa bu aktarım m. 9 kapsamındadır ve aydınlatma metninize eklenmelidir. Asistanı kapatmak veya anahtarı silmek aktarımı durdurur. Bir kullanıcı kişisel erişim anahtarıyla bir MCP istemcisi (Claude, Cursor, VS Code…) bağlarsa, araç sonuçları o istemciye ve onun model sağlayıcısına gider.

Nöbet (Watch). Bir yönetici bir proje için Nöbet'i açarsa (varsayılan kapalı) ve asistan etkinse, trafik alışılmadık göründüğünde abusend incelemeleri kendiliğinden başlatır: aynı asistan, aynı anahtar ve sağlayıcı, aynı türden panel verilerini (IP adresi, son kullanıcı kimliği, cihaz kimliği, öznitelikler, akış ayrıntıları) okur — ama o sırada kimse izlemiyordur; projenin çalışma sınırlarına kadar (aksi ayarlanmadıkça saatte 4, günde 24). Bu yüzden Nöbet açık olduğu sürece aktarım süreklidir: durdurmak için Nöbet'i (ya da asistanı, ya da anahtarı) kapatın. Trafikten gelen her şey modele güvenilmez veri olarak sunulur, talimat olarak değil; kendi başına yalnızca İzleniyor durumunda kural ve yeni sayaç ekleyebilir, diğer her değişiklik bir yöneticinin onayını bekler. Nöbet'in kendi sakladığı toplamlardır: proje, işlem, ülke ve ASN başına 5 dakikalık sayılar (8 gün, kişisel veri yok) ve çalışmaları (bulguların sayıları, modelin özeti; 90 gün). Uyarıları ve raporları sayı, işlem adı, ülke kodu veya ASN ve o özeti taşır; tasarım gereği e-posta adresi yok. Bir sayacın değerleri için devreye giren, Uygulanıyor durumundaki bir kuralla ilgili not (değer başına değil, kural başına tek not) ayrıca bu değerlerden en fazla beşini örnek olarak anar, çalışma kaydı ise 50 tanesini saklar: sayaç IP adresi, son kullanıcı kimliği ya da cihaz kimliğine göre gruplanmışsa bunlar IP adresi ya da kimliktir; alıcıları ve webhook hedeflerini buna göre seçin. Model tarafından yazılan bir özet de okuduğundan alıntı yapabilir.

6. İlgili kişi hakları (m. 11) ve silme

• Bilgi talebi: GET /v1/users/{id} bir kullanıcının öznitelikleri ile son kararlarını döndürür.
• Silme: DELETE /v1/users/{id} (gizli anahtarla) veya panelden silme (admin rolü). İşlem idempotent'tir: kayıt yoksa {"ok": true, "erased": false} döner. Kullanıcı, öznitelikleri ve sunucunuzun onun için bildirdiği olaylar silinir, kullanıcı listelerinden çıkarılır, öznitelik değerleri panelin öznitelik örneklerinden kaldırılır, kuruluşun kimliği içeren yapay zekâ asistanı konuşmaları silinir, cihaz–kullanıcı bağlantıları ve bu cihazların tanıma özetleri silinir; assessment kayıtları anonimleştirilir (IP /24 veya /48 ağına kısaltılır, başlıklar, JS sinyalleri, User-Agent, origin, cihaz kimliği ve parmak izi özeti temizlenir, kullanıcı bağlantısı kaldırılır); verdict kayıtlarının IP'si kısaltılır, girdileri (öznitelik kopyası, bağlam, sayaçlar) ve geri bildirim notu temizlenir; doğrulama adımlarının kullanıcı bağlantısı, cihaz kimliği, parmak izi özeti, çağıran kimliği ve saklanan yanıt kopyası temizlenir. Kullanıcı kimliği denetim kaydından da temizlenir; silme işleminin denetim kaydı yalnızca kimliğin hash referansını tutar. Kalan, kişiyle ilişkilendirilemeyen kayıtlar normal saklama süresi sonunda silinir. Verdict kayıtları yanıttan birkaç milisaniye sonra yazıldığından silme bu kuyruğu da kapsar: kullanıcının kuyrukta bekleyen kayıtları yazılmadan önce anonimleştirilir (o kayıtların adını verdiği assessment, doğrulama adımları ve cihaz tanıma özetleri de silinir), işlem yaklaşık 30 saniye sonra bir kez daha tekrarlanır. Analitik depo (ClickHouse) ve Valkey adımları aynı çağrıda denenir; tamamlanamayan adım, kimliğinizi değil yalnızca türetilmiş kimlikleri içeren bir bekleyen silme kaydı olarak tutulur ve başarılı olana kadar yeniden denenir (genellikle bir dakika içinde; çağrı 200 döner, bu adımların bittiğini söylemez). Analitik deponun günlük yedekleri 7 gün saklanır: silinen kullanıcının kayıtları yedeklerde değişmez, yedek süresi dolunca birlikte gider; yedekten geri yükleme sonrasında yedekten sonra yapılan silmeleri yineleyin.
• Hesap silme akışınıza ve başvuru süreçlerinize (30 gün içinde yanıt, m. 13) bu çağrıyı ekleyin.

7. Veri güvenliği (m. 12)

• Panelde rol tabanlı erişim: viewer, analyst, admin, owner.
• İki adımlı doğrulama (TOTP) ve tek kullanımlık kurtarma kodları; organizasyon sahibi veya yöneticisi (admin) 2FA'yı tüm organizasyon için zorunlu kılabilir.
• Yeni üyeleri sahip veya yönetici davet eder; üyeler 7 gün geçerli kişisel davet bağlantısıyla katılır ve parolalarını kendileri belirler.
• Parolalar argon2id, oturum ve API anahtarları SHA-256 özetleri olarak saklanır; gizli anahtar yalnızca bir kez gösterilir. Yapılandırma değişiklikleri denetim kaydına yazılır (365 gün saklanır).
• Tüm trafik TLS ile şifrelenir. Çerez ve Authorization başlıkları hiçbir zaman saklanmaz (abusend'in kendi cihaz kimliği çerezinin değeri hariç).
• Cihaz kimlikleri HMAC ile imzalıdır ve proje başınadır; widget doğrulama sağlayıcılarının gizli anahtarları AES-256-GCM ile şifreli, proje ve doğrulamaya bağlı saklanır, hiçbir API'de geri gösterilmez. Uygulama doğrulama sonuçları yalnızca gizli anahtar ve eşleşen kullanıcı kimliğiyle bildirilebilir.

8. Aydınlatma metni için örnek paragraf (m. 10)

Aşağıdaki paragrafı kendi aydınlatma metninize uyarlayarak ekleyebilirsiniz. Köşeli parantez içindeki alanları doldurun ve kullanmadığınız seçenekleri çıkarın.

Güvenlik, dolandırıcılığın ve kötüye kullanımın önlenmesi

[Şirket unvanı] olarak, internet sitemizde ve uygulamamızda giriş, üyelik ve ödeme gibi
işlemlerde, belirlediğimiz kurallara göre işleminize izin verilmesine, ek doğrulama
istenmesine veya işlemin engellenmesine karar veren bir hizmet kullanıyoruz. Bu kapsamda
IP adresiniz, tarayıcınızın gönderdiği teknik bilgiler (User-Agent ve bazı HTTP başlıkları,
TLS/HTTP-2 bağlantı parmak izleri), tarayıcınıza ilişkin teknik sinyaller (ör. ekran boyutu,
saat dilimi, etkileşim olaylarının sayısı; yazdıklarınız ve tıklama konumlarınız
kaydedilmez), hesabınıza ve işleminize ilişkin bilgiler (ör. hesap oluşturma tarihi, işlem
tutarı) ile tarafımızca atanan ve sizi doğrudan tanımlamayan bir kullanıcı kimliği
işlenmektedir. [Cihaz kimliği açıksa: Tarayıcınızı tekrar tanıyabilmek için tarayıcınızda
rastgele bir cihaz kimliği (çerez ve yerel depolama) saklanır.] [Cihaz tanıma açıksa:
Cihaz kimliği gönderilmediğinde (ör. gizli pencerede) tarayıcınızı tanıyabilmek için,
tarayıcınızın teknik özelliklerinden (ekran, saat dilimi, grafik ve ses işleme özellikleri
gibi) türetilen ve geri döndürülemeyen özetler en fazla 30 gün saklanır.] [Widget doğrulaması
bağlıysa: Gerekli durumlarda [Cloudflare Turnstile / Google reCAPTCHA / hCaptcha /
Friendly Captcha / GeeTest] ile bir insan doğrulaması yapılır; bu sırada IP adresiniz ve
tarayıcı bilgileriniz, KVKK'nın 9. maddesine uygun olarak [ABD'deki Cloudflare, Inc. /
Google LLC / Intuition Machines, Inc. / Almanya'daki Friendly Captcha GmbH / Çin'deki Wuhan
Jiyi Network Technology Co., Ltd. (GeeTest)] ile paylaşılır.] [abusend'in kendi
görünür doğrulaması kullanılıyorsa: Gerekli durumlarda ekranda gösterilen küçük bir görevi
(noktalara basılı tutma veya bir alanda imleç gezdirme) yapmanız istenir; bu sırada yalnızca
o alandaki imleç veya dokunma hareketleriniz, işlemin bir kişi tarafından yapılıp
yapılmadığını değerlendirmek için işlenir ve saklanmaz; üçüncü bir tarafla paylaşılmaz.] [SMS / e-posta doğrulaması kullanılıyorsa: Gerekli durumlarda
[telefonunuza / e-posta adresinize] bir doğrulama kodu gönderilir; bu gönderim
[sağlayıcı adı] aracılığıyla tarafımızca yapılır.] Bu veriler, 6698 sayılı Kişisel
Verilerin Korunması Kanunu'nun 5/2-f maddesi uyarınca, temel hak ve özgürlüklerinize
zarar vermemek kaydıyla meşru menfaatimiz için zorunlu olması hukuki sebebine
dayanılarak, otomatik yollarla işlenir. Veriler, hizmet sağlayıcımız [hizmet sağlayıcı /
operatör unvanı] tarafından veri işleyen sıfatıyla adımıza işlenir ve [30] gün sonra
otomatik olarak silinir. [Üçüncü taraf IP itibar hizmeti kullanılıyorsa: IP adresiniz,
risk skoru alınması amacıyla [sağlayıcı adı, ülke] ile KVKK'nın 9. maddesine uygun olarak
paylaşılır.] KVKK'nın 11. maddesindeki haklarınızı, otomatik sistemlerle yapılan analiz
sonucunda aleyhinize bir sonucun ortaya çıkmasına itiraz hakkınız dahil, [başvuru adresi /
e-posta] üzerinden kullanabilirsiniz.

9. Veri işleme sözleşmesi şablonu (m. 12/2)

Hukuki tavsiye değildir. Barındırılan kurulumda sizinle (veri sorumlusu) operatör (veri işleyen) arasındaki sözleşme için bir başlangıç metnidir. Hukuk danışmanınıza inceletin ve […] alanlarını doldurun. Kendi sunucunuzda çalıştırdığınız kurulumda bir abusend operatörüyle sözleşme gerekmez. İngilizce sürüm: DPA template.

VERİ İŞLEME SÖZLEŞMESİ

Taraflar: [Müşteri unvanı, adresi] ("Veri Sorumlusu") ve [Operatör unvanı, adresi]
("Veri İşleyen"); [tarih] tarihli hizmet sözleşmesi ("Ana Sözleşme") kapsamında.

1. Konu ve süre. Veri İşleyen kişisel verileri yalnızca abusend kurallara dayalı erişim
   kararı ve doğrulama orkestrasyonu hizmetini sunmak için, Ana Sözleşme süresince işler.
2. Niteliği ve amacı. Giriş, üyelik, ödeme ve benzeri isteklerin Veri Sorumlusunun
   kurallarına göre değerlendirilmesi; isteğe izin verilmesi, Veri Sorumlusunun
   uygulamasına bırakılması, engellenmesi veya ek doğrulama istenmesi ile dolandırıcılık,
   kötüye kullanım ve hesap ele geçirmenin önlenmesi; bu doğrulamaların sonucunun
   kaydedilmesi. Pazarlama amaçlı profil çıkarılmaz; veriler satılmaz veya başka amaçla
   kullanılmaz.
3. İlgili kişiler. Veri Sorumlusunun internet sitesi ve uygulamalarının ziyaretçileri ve
   kullanıcıları; Veri Sorumlusunun panel kullanıcıları.
4. Veri kategorileri. IP adresi; User-Agent ve izin listesindeki HTTP başlıkları; TLS/HTTP-2
   parmak izleri; gizlilik belgesinde listelenen tarayıcı sinyalleri; kapatılmadıkça proje
   başına cihaz kimliği (çerez / yerel depolama) ve parmak izi özeti; Veri Sorumlusunun
   gönderdiği opak kullanıcı kimliği, öznitelikler ve istek bağlamı; kararlar ve girdileri;
   doğrulama adımı kayıtları (sonuç, ağ öneki, cihaz bağı); panel hesap verileri ve denetim
   kaydı. Veri Sorumlusu özel nitelikli kişisel veri, e-posta adresi, telefon numarası veya
   T.C. kimlik numarası göndermez.
5. Talimatlar. Veri İşleyen yalnızca Veri Sorumlusunun belgelenmiş talimatlarıyla (bu
   sözleşme, panelde seçilen proje yapılandırması, API çağrıları) hareket eder; hukuka
   aykırı görünen bir talimatı Veri Sorumlusuna bildirir.
6. Gizlilik. Verileri işleyen kişiler gizlilik yükümlülüğü altındadır.
7. Güvenlik (m. 12/1). Veri İşleyen gizlilik belgesindeki tedbirleri (TLS, 2FA'lı rol tabanlı
   erişim, özetlenmiş parola ve anahtarlar, şifreli sağlayıcı anahtarları, denetim kaydı,
   saklama süreleri) uygular ve en az bu seviyede tutar.
8. Alt işleyenler. İmza tarihinde: [yok / liste]. Veri İşleyen yeni bir alt işleyeni [30] gün
   önceden bildirir; Veri Sorumlusu makul gerekçeyle itiraz edebilir. Widget doğrulama
   sağlayıcıları (Cloudflare Turnstile, Google reCAPTCHA, hCaptcha, Friendly Captcha, GeeTest)
   ve üçüncü taraf IP itibar sağlayıcısı yalnızca Veri Sorumlusu projesinde açarsa
   kullanılır. Veri Sorumlusunun kendi
   uygulama doğrulamalarının (SMS, e-posta, KYC) sağlayıcıları Veri Sorumlusunun veri
   işleyenleridir, Veri İşleyenin alt işleyenleri değildir.
9. Konum. Veriler [ülke / veri merkezi] içinde işlenir ve saklanır (operatörün veri konumu
   beyanı). Veri Sorumlusunun önceden yazılı onayı ve KVKK m. 9'a uygun bir aktarım
   mekanizması olmadan [ülke] dışına aktarılmaz.
10. İlgili kişi başvuruları. Veri İşleyen, Veri Sorumlusunun başvuruları yanıtlamasını
    sağlar (bilgi: GET /v1/users/{id}; silme: DELETE /v1/users/{id}) ve diğerlerinde destek olur.
11. Veri ihlalleri. Veri İşleyen bir ihlali öğrendiğinde gecikmeksizin ve en geç [24/48] saat
    içinde, Veri Sorumlusunun Kurul'a (72 saat) ve ilgili kişilere bildirim yapabilmesi için
    gereken bilgilerle birlikte bildirir.
12. Saklama ve imha. Veriler saklama ayarlarına göre silinir (assessment, verdict ve
    doğrulama adımı kayıtları için varsayılan [30] gün, denetim kaydı 365 gün). Sözleşme
    sona erdiğinde Veri İşleyen tüm verileri [30] gün içinde, yedekleri [N] gün içinde siler
    ve bunu yazılı olarak teyit eder.
13. Denetim. Veri İşleyen uyumu göstermek için gereken bilgileri sağlar ve Veri Sorumlusunun
    veya denetçisinin [30] gün önceden bildirilen denetimlerine [yılda bir] izin verir.
14. Sorumluluk ve uygulanacak hukuk. [Ana Sözleşmedeki gibi.] Uygulanacak hukuk: Türk
    hukuku. Yetkili mahkeme: [ ].

İmzalar: [Veri Sorumlusu]  [Veri İşleyen]  Tarih: [ ]