1. Scope and register status
This draft describes product-supported services and observed historical information. It does not establish which production accounts, contracting entities or regions are currently used. A brand, library, setting or local test does not prove supplier approval. Before publication the operator verifies and dates the effective register; an unverified integration is not represented as approved.
For each actual service, the register records the precise entity and product, function, data and subject categories, processing and support locations, onward processors, contract/DPA, transfer mechanism, retention/deletion, contact and verification date. A supplier may process one activity and independently control another. Listing grants no medical permission beyond the particular instructions.
2. Application, database and operational infrastructure
Hosting the public site, protected portal and API may process network and session information, accounts, contacts, authorized clinical content and metadata. The database holds clinical descriptions, permissions, history, organization and accounting records; cache, queue, log and backup systems may process necessary technical records. PostgreSQL, Redis, Laravel and Next.js are technologies, not identities of external contracting entities.
A historical record dated 4 September 2026 mentions Netlify and AWS/Sentry settings. It is dated evidence requiring fresh confirmation of environment, contracting entity, functions, countries and remote staff access. API, database, cache, queue, backup and monitoring suppliers are established through the operator register rather than guessed.
3. File storage, archive and backups
The product supports private local and S3-compatible storage, including Amazon Web Services when configured. Data may include medical files, returned results, technical objects, checksums and necessary storage/restoration history. A self-operated disk is not a new external supplier, but its underlying infrastructure must still be identified.
An S3 region or historical eu-north-1 setting does not establish locations of backups, logs, administrative access or onward providers. The operator confirms contracts, selected services, regions, transfers, keys, lifecycle/deletion policies and every backup system. Working restoration and reapplication of revocations require evidence separate from archive code.
4. Email and SMS
Supported email includes Brevo and configurable SMTP/API channels; code also contains Postmark, Amazon SES and Resend capabilities. This does not mean all are active. SMS supports an SMSAPI channel to api.smsapi.bg; local log mode sends no real SMS. The contracting entity, countries, support, onward processors and retention are verified for the selected actual account.
A communication supplier receives the contact, generated message, reference and delivery states. Named-recipient SMS contains a link and expiry without its separately shared PIN. A separate Patient Key may send its own code/PIN by the selected SMS. Login and security messages may contain authentication codes. Protected links and codes are themselves sensitive; templates, logs and retention require review and minimization. Unnecessary clinical content must be excluded from notices.
5. Form protection and technical diagnostics
Cloudflare Turnstile is conditional protection for relevant public forms against automated abuse and may process network, browser and challenge signals. It is not intended for clinical content or advertising. Other Cloudflare DNS/CDN/WAF functions are not declared active merely because Turnstile exists; the operator confirms actual services and information.
Sentry is conditional technical diagnostics when a DSN is configured. The reviewed configuration restricts personal information, event contents and detailed telemetry; session recording is not an authorized product activity. This does not establish the actual project, region, retention or all external scripts. Historical EU-region information needs current operator evidence. An actual log or monitoring supplier is listed separately when it receives information.
6. Payments and accounting
Stripe supports explicitly initiated card checkout and a customer portal when configured. It processes customer/billing details, plan, amounts, currency, payment references and security signals; medical files are outside the intended payment flow. Stripe may independently control regulated and anti-fraud activities under applicable terms. Stripe code proves neither approved tax settings nor settlement.
Banks and accounting recipients are identified from actual contracts and details. They may process legal identity, invoices, payments and corrections in independent or instructed roles. A bank, VAT status, country or legal retention period is not invented from sample settings. Referral credit is an internal accounting contribution to an eligible new proforma, not a promised cash payment.
7. Scanning, support and Customer systems
Internally operated ClamAV is a checking tool, not a separate external cloud processor. An externally managed scanner or external service receiving copies must be reviewed and listed with its file-data scope. Local development and simulated checks do not establish production scanning.
Support conversations are application functionality using safe information. Their screen does not establish an external support supplier, which must be listed if actually used. Customer-selected software, API recipients or webhook endpoints do not automatically become Karizo subprocessors. The Customer approves its integration and disclosure basis, and supplies only the permitted scope.
8. Safeguards, transfers and information
Instructed processing requires sufficient assurances and corresponding contractual obligations. Transfers outside the EEA require an applicable mechanism, assessment and supplementary measures where needed. Adequacy, certification, EU-only processing or contractual clauses are not asserted without evidence for the particular entity, service and account. Overseas support and onward access form part of the assessment.
Customers may request the current register and applicable safeguards at [email protected]. Necessary information is supplied while protecting commercial and security secrets; missing current evidence is identified clearly. Do not send medical files or access secrets for this review.
9. Notice, objection and termination
The effective DPA model provides at least 30 days’ advance notice of a new or replacement subprocessor to the verified contract contact, with entity, function, information, countries, start and objection channel. Necessary urgent security or legal changes record reasons and minimum scope and are notified as soon as possible. This draft preserves that model without silently shortening notice.
Substantiated data-protection objections are reviewed with the Customer. The parties seek restrictions, safeguards or an acceptable alternative; if unresolved, they arrange termination of the affected service and authorized return/deletion. Approved changes record version, date, evidence and customer notice. A list of supported integrations does not replace that procedure.
Product scope for review · 20 October 2026
A queue, durable sending record or support screen does not establish a new external supplier. The operator identifies the actual execution, transport, storage and monitoring services and their contracting entities. Synthetic local mail or an SMS receiver establishes no production supplier, location or delivery.
The register must cover contacts and minimal messages, including the sensitivity of protected links and codes. Support receives no general permission to send medical files to an external service. A new external tool requires its own assessment and applicable contractual notice.
Evidence for the actual register before publication
Prepare a separate dated record for the public site/portal, API, database, cache/queues, files/archive, backups, logs/monitoring, email, SMS, payments and form protection. For each function record actually used, disabled or operated internally, an owner and evidence from the target environment. For an external service add the entity/product, account without secrets, processing and support countries, contract/DPA and transfers, retention/exit and approval date. An empty field remains unverified; it does not mean there is no supplier or transfer.
Clarified product scope · 23 October 2026
The public check on 22 October 2026 observed Cloudflare responses for the marketing site and API and Netlify responses for the portal. This establishes observed delivery endpoints, not the complete processing chain, contracting entity, support countries, executed DPA, subprocessors or retention. Current contractual-account evidence must complete those facts before the register is approved.
For the database, storage and archive, backups, email, SMS, payments, monitoring and form protection, record the service actually enabled, specific recipient, purpose, data categories and applicable safeguards. A configuration name or historical check does not establish a current supplier. Changing delivery channel does not authorize an undisclosed subprocessor or new purpose.
Decisions before approval
The clauses above are complete proposed text. These decisions must be resolved before publication or a request for acceptance.
Operator and contract owner
Confirm every actual entity, account, service, country/region, remote support and onward processor, including frontend, API, database, cache/queues, logs and backups. Historical 4 September information is not current confirmation. Preserve dated evidence; do not publish this review as the final active register.
Counsel and security/privacy owners
Approve contracts/DPAs, activity-specific roles, transfer mechanisms/assessments, retention and each supplier’s exit process. Check actual templates and logs for protected links, codes and clinical data, and tax/payment settings with an accountant.
Contract owner and counsel
Approve and exercise the 30-day notice procedure, urgent exception and objection/termination handling. Confirm verified customer contacts and notice evidence. Update the register on approved changes without automatically accepting a new contract.
Operator, privacy and procurement
Confirm the actual register, contracts, regions, support access, onward processors and transfers for every active service. Do not infer a supplier from a library or test.
Operator, contract owner and counsel
Do not approve publication until every function has a verified record and contract owner. For a supplier change attach the dated notice to verified contract contacts, objection outcomes and approved effective date.
Counsel, privacy owner and product owner
Approve the precise contractual scope and difference from 2026-09-02.2, match clauses to the target environment and apply the notice and renewed-acceptance plan. The public check does not confirm signed-in operation; do not assume unverified deployment or operational periods.
