Data processing agreement

This agreement governs processing of Customer Personal Data by Karizo EOOD, company number 207562809 (Processor), for the organization identified in the accepted contract or order (Customer). The Customer normally acts as controller; if it processes for another controller, it confirms authority to appoint Karizo as subprocessor and passes on applicable lawful instructions. The agreement applies during the service and while data is retained, returned or deleted on authorized instructions.

For Customer Personal Data, this agreement prevails over conflicting general commercial terms; mandatory rules and applicable transfer clauses prevail over incompatible contractual text. Karizo’s own controller activities described in the Privacy Notice do not become customer-instructed processing. A receiving doctor may have separate controller duties determined by their actual clinical activity.

The subject matter is medical-file handover and receiving with the necessary related work: upload, safety checks, organization, private storage, selected-recipient disclosure, replies, requests for missing information, history, archive, preparation of retained content, authorized export and removal. The purpose is the professional task determined by the Customer. MediSend does not determine diagnosis, treatment or emergency priority and does not replace a required medical archive.

Instructions concern the particular clinic, handover, file, request or grant and its permissions and deadlines. Email/SMS notices and chosen API/webhook events are supporting operations. They authorize no advertising, sale, model training, global patient search or independent new clinical purpose for the Processor.

Data subjects include patients, lawful representatives, recipients, healthcare professionals and authorized staff whose information the Customer supplies. Categories may include health data, images, documents and results; names and patient or business identifiers; contact details; filenames and technical file characteristics; clinical purpose, context and messages; authorized replies; grants, deadlines and access history. The Customer selects content and minimizes third-party information.

Authorized personal receiving may include private clinical notes and saved examinations with a separate controller determined by the professional activity. The contractual basis for that scope must be established; a free account or reading this draft does not prove DPA acceptance. Karizo’s contract, billing and own security information follows the separate roles in the Privacy Notice.

The Processor follows the contract, approved settings and authorized users’ service actions, including recipients, retention and transfers. The Customer ensures an Article 6 GDPR basis, an applicable Article 9(2) condition, information to individuals, professional authority and permitted disclosure. It checks the organization, contact, permissions and deadline before sending and keeps exports required for its independent records.

If the Processor believes an instruction infringes applicable data-protection rules, it informs the Customer and suspends the disputed operation pending clarification. If applicable law requires processing beyond instructions, advance notice is given unless legally prohibited. An unauthenticated recipient request cannot authorize access to another organization or another person’s medical records.

Access is granted only as necessary to persons subject to applicable confidentiality duties and an approved role. Organization roles are separate from platform support, billing, verification, operations and security roles. Privileged actions are subject to MFA, recent authentication, applicable permissions and traceability. A technical role is not general permission to browse clinical content.

Ordinary support uses safe operational information and cases without medical files, original filenames, patient names, PINs, OTPs, passwords or protected links. An implemented emergency clinical-content viewer is not promised. A request to ‘look at the file’ does not itself authorize broad access; the Customer inspects it within its authorized account and provides a safe description.

Measures include organization and grant checks; separate viewing, download and return permissions; bounded revocable sessions; MFA and recent authentication for sensitive actions; private storage; protected password, PIN and token representations; traceable issuance and revocation; abuse controls and upload checks. Linking logins, saving a contact or holding a professional badge transfers no medical permission.

The Security Measures schedule describes the observed scope and required operational evidence. The Processor assesses safeguards against risk and changes. TLS, scanning, workers, storage, backups and restoration must be established in an approved environment before real health data. Certification, end-to-end encryption or absence of risk is not asserted without supporting evidence.

A named-recipient SMS sends a link and expiry without its required PIN, which the Customer shares separately. Email and in-person delivery use the same particular grant with selected protection. A separate Patient Key has its own code/PIN and delivery policy. Resending may rotate the link; the Customer uses current credentials and checks history without creating unnecessary duplicate grants. Communication acceptance proves neither delivery nor clinical review.

An authorized Customer enables an API key or webhook with the required scope. It approves its external software, protects keys and secrets, verifies signatures and minimizes exported content. Neither integrations nor shared tasks override clinic and permission checks. Medical information and secrets must not be placed in URLs, general telemetry or support cases.

The Customer gives general authorization only for subprocessors listed and approved for the relevant activity in the effective register. Contracting entity, function, data categories, countries, onward access, retention and sufficient assurances are checked before use. The Processor imposes corresponding obligations and remains responsible to the Customer for their performance within the applicable scope.

A new or replacement subprocessor receives at least 30 days’ advance notice to the verified contract contact, identifying function, data, countries, intended start and objection procedure. For a necessary urgent legal or security change, reasons and minimum scope are recorded and notice is given as soon as possible. The Customer may raise a substantiated data-protection objection; the parties seek safeguards or an alternative, and if unresolved arrange termination of the affected service and return/deletion. This draft does not shorten the existing 30-day model.

Processing outside the EEA requires permitted documented instructions and an applicable Chapter V GDPR mechanism, with assessment and supplementary measures where necessary. An integration or selected region does not establish the location of all copies, support and onward processors. Unverified transfers are not enabled and exclusively EU processing is not promised.

Authority requests are checked for competence, legal basis and necessary scope. The Customer is informed where permitted and disclosure is limited to what is required. A supplier request or unauthenticated message alone authorizes no disclosure. Conflicts with data-protection duties receive qualified legal review.

Taking account of processing and available information, the Processor assists with individual rights, safeguards, impact assessments and prior consultation. Customer-data requests are routed to the Customer with safe accountability evidence; clinical content is not exported or erased for an unauthenticated applicant. Actions follow verified instructions and exclude secrets and other people’s information. A request-tracking screen does not itself prove deletion or export.

On becoming aware of a breach affecting Customer data, the Processor notifies the Customer without undue delay. It provides known data and subject categories, likely consequences, measures and a contact, updating information in stages. The internal objective of initial information within 24 hours is not a guaranteed SLA and does not alter the without-undue-delay duty. The Customer assesses authority and individual notifications; the Processor assists and limits incident preservation to what is necessary.

A request received by the Processor concerning Customer data is passed without undue delay to the Customer’s verified contact with the minimum necessary context. The parties coordinate timing and information so the Customer can meet the applicable GDPR deadline; internal forwarding does not restart a statutory period and does not require the individual to buy or create an account. The Processor makes no independent clinical decision to erase, refuse or disclose and does not request unnecessary identity or health information through general support.

The Processor supplies information necessary to demonstrate performance and allows and contributes to audits by the Customer or an authorized independent auditor. Reasonable scope, timing, confidentiality and other customers’ protection are coordinated. Existing evidence may reduce duplication but cannot replace a legally necessary audit. Audits provide no unrestricted access to clinical content, other customers’ information or security secrets.

Any agreed charges for exceptional assistance are determined beforehand and do not defeat mandatory assistance or breach response. Local tests do not establish production effectiveness. Necessary supplier, scanning, backup, restoration and access evidence is maintained and reviewed when changes occur.

At termination the Customer chooses return or deletion through authenticated instructions, except where law requires retention. The parties arrange authorized export and removal from primary storage and copies. Non-payment, link expiry or disabling discovery is not a hidden instruction for immediate destruction. Retained data after termination is used only for the authorized residual process or legal duty.

File-byte deletion is conditional and disabled by default; descriptive records, original filenames, clinical context and audit do not automatically disappear with the bytes. Fully executing instructions requires separate review and minimization of those records and a verified backup schedule. Restores must reapply revocations and deletions; this operational requirement must be demonstrated. The Processor reports scope, failures, lawful holds and remaining copies without claiming unverified complete erasure.

The sending record serves the particular instruction and safe recovery after interruption. Processing rechecks the current recipient, channel, expiry and revocation. This does not make external transport part of one shared transaction or authorize a new clinical purpose or unlimited repeat notifications.

Ordinary staff screens expose authorized conversations and minimal operational data. Saved replies and internal response targets do not expand medical permissions. A professional’s personal conversation does not authorize linking or inspecting clinical operations without the separate organization permission.