Technical and organisational security measures

MediSend supplies a technical service for exchanging specific medical files. The customer determines the lawful purpose, recipients and instructions for customer data. Karizo EOOD organises supplier application and operational safeguards; distinct roles for customer data and the provider’s platform data are addressed in the Privacy Policy and data-processing agreement.

Measures are assessed against risk, the health data involved, permitted operations and the actual environment. We do not claim a GDPR certificate, absolute protection or full end-to-end encryption. Publishing a final description requires verification of application boundaries and evidence of operational infrastructure, personnel and procedures.

Passwords are protected by one-way hashing. Email verification, multi-factor protection and attempt limits are supported according to the workflow and configuration. Application sessions have expiry and revocation, defaulting to twelve hours or up to thirty days with selected remembering. Browser session material is carried in encrypted HttpOnly cookies; higher-risk actions may require recent authentication.

Session revocation or permission loss must end subsequent authorised requests. Remembering a device is not a universal exemption from multi-factor checks. Actual administrator, trusted-device, expiry and access-removal policies must be documented and periodically verified.

Organisation resources are checked against the current organisation and permission for the particular action. Clinics have separate memberships, files, settings and billing. The customer assigns staff roles and removes unnecessary memberships. A saved contact, template, registration or professional verification does not by itself create medical access authorisation.

Switching between a personal workspace and clinics does not merge permissions. Linking separate accounts requires authentication and confirmation and preserves distinct identities and permissions. Unlinking neither deletes an account nor automatically expands or removes medical authorisations outside the defined workflow.

Email, SMS and in-person link delivery use the same named-recipient authorisation for the selected files. It has expiry, download and reply permissions and can be revoked. A required PIN is stored as a hash; named-recipient SMS contains the secure link and expiry without the PIN. The sender shares the PIN separately and checks the correct contact.

A verified professional can receive an examination in their account and open it after sign-in. A Patient Key is a separate workflow with a code, PIN and its own grant rules. When the sender explicitly selects SMS for that key, code and PIN can be included together and the encrypted material required for delivery is retained. Revoking or reissuing a key must not be represented as automatically revoking every separate grant already issued.

Public links use random tokens and checks of the relevant resource, expiry and permissions. PINs, one-time checks and attempt limits apply according to the workflow. Resending can replace a link and invalidate the old one; it does not grant general organisation access. Registration, account linking or saving an item for later does not restore an expired, revoked or deleted source.

Renewal occurs only through an authorised workflow and does not automatically extend physical retention. Revocation stops future service access but does not remove data already downloaded, copied or printed. The recipient must protect those copies and avoid forwarding a link and PIN to unauthorised people.

Current download routes check application access and stream contents without issuing a general public file address. This does not prove immediate termination of a transfer already started or removal of cached copies. Signed S3 addresses in the reviewed workflow are for bounded upload parts, defaulting to up to five minutes and not beyond reservation expiry. An already-issued short-lived address has its own boundaries; we do not promise that every application revocation instantly invalidates it.

Downloads and previews follow permission and state checks rather than a general public directory. Uploads have size/count limits, dangerous-content checks and checksums. Pending, blocked, failed or unavailable checks must not present a file as checked and downloadable. Scanning reduces risk but does not guarantee that every file is harmless.

Interrupted-upload recovery uses server reservations, expiry and verification of the selected file and received parts. Name and size alone do not prove identical contents. Browser local storage does not retain file bytes, patient fields, PINs or login tokens; secret resume material is in protected cookies. Uploaded, being checked and ready are distinct states.

The code uses cryptographic protection for certain identifiers, evidence, private notes and session material, hashing for passwords and secrets, and SHA-256 file checksums. This does not automatically prove encryption of every database, file or backup. Key access, rotation and recovery require separate management with restricted privileges.

Production requires HTTPS/TLS, private storage, correct access policies and verified server configurations. Regions, the actual storage-encryption mode, network isolation, backups and external access are deployment facts requiring evidence. A configuration variable alone does not establish a verified location or infrastructure guarantee.

Platform roles for owner, support, billing, verification, security and operations are separated; the privileged interface requires corresponding permissions and confirmed multi-factor authentication. Ordinary support views use organisation, account, billing, verification and safe status data rather than medical contents.

By default, support does not receive filenames or contents, clinical titles/context, full patient references, PINs, one-time codes, tokens, hashes or storage paths. No product workflow for user impersonation or exceptional medical access is established. Operator infrastructure access is governed by separate technical and organisational rules; support-interface restrictions do not prove the absence of every form of infrastructure access.

Significant actions create audit events and access, delivery, checking and management history. Accepted for sending, delivered, opened and downloaded are distinct facts. Failed notification must not be presented as successful delivery. Supplier status must be assessed against the returned confirmation, and test logging does not mean that an SMS or email was actually sent.

When Sentry is enabled, final scrubbing permits a limited exception class and source information without raw messages, request bodies, user context, arbitrary tags or contents. Breadcrumbs, application logs, tracing and session replay are excluded by the current configuration. The operator verifies actual recipients, retention, regions and settings following supplier or version changes.

Checks are provided for workers, the scanner, scheduler, private storage and a dedicated backup target. A configuration check or synthetic object write/read/delete probe is not a database backup or evidence of successful production restoration. Automatic recovery and specific data-loss or recovery-time objectives are not promised without separate evidence and agreement.

The operator must establish approved schedules, backup isolation/protection, failure monitoring and periodic restoration tests. Restorations must reapply revocations, deletions and valid expiry values. A command or procedure present in the project does not certify its successful execution in the actual environment.

A suspected incident is assessed for affected systems and data, its consequences are contained and necessary evidence is retained with restricted access. When acting as processor and becoming aware of a breach of customer personal data, the provider notifies the customer without undue delay using available facts and subsequent updates. A complete investigation is not awaited before reporting an established breach.

An internal operational objective is proposed for initial notification within 24 hours of awareness where practicable. It is a response-organisation objective, not a guaranteed SLA, separate statutory period or permission to delay earlier possible notification. The customer as controller separately assesses duties towards the authority and individuals; the applicable GDPR 72-hour regime does not replace the processor’s duty to notify without undue delay.

The customer protects devices, verifies recipients, assigns minimum roles, shares PINs safely, manages exported copies and fulfils medical-record duties. Support requests should not contain PINs, tokens or unnecessary health data. Security reports may be sent to [email protected] or the agreed verified contact.

Before publication, the risk assessment, actual environment, contracting suppliers, personnel confidentiality, training, privilege review and incident arrangements must be approved. Material changes to safeguards are reflected in this document and the applicable agreement. Evidence requests and audits are arranged to protect other customers and security secrets.