How ITIG Clinic protects patient data.

The controls below are the ones that exist in the software and the hosting today, written so that an IT consultant can check them. Where something is an internal target rather than a commitment, this page says so. We do not claim certifications we do not hold.

Ask a security question

Where it runs

Hosting: Microsoft Azure, UAE North region: container apps for the application and its workers, Azure Database for PostgreSQL version 16, and backups replicated to the paired UAE Central region.
Documents: Patient documents, photos, and recordings are stored in S3-compatible object storage hosted by OVH Cloud in its EU-WEST region, in France, under clinic-prefixed keys and reached only through signed links that expire in 15 minutes. File bytes never pass through the application server.
In transit: TLS on every connection, including the application’s own connection to the database, which refuses unencrypted sessions.
At rest: Azure Database for PostgreSQL and the object storage encrypt stored data at rest by default. On top of that, WhatsApp access tokens, AutoGreet AI conversation text, and authenticator secrets are encrypted field by field with AES-256-GCM, bound to the clinic they belong to.
Where data leaves the region: AutoGreet AI sends the text of patient WhatsApp messages to Anthropic in the United States to draft replies, under commercial terms with a data processing agreement, with no training on the data and deletion by the provider within 30 days. Patient records themselves stay in the UAE regions, and patient documents are stored in France. Every other party that touches data, and what each one receives, is listed in the privacy policy.
This website: Static pages on Cloudflare Pages behind a strict content security policy. It sets no cookies of its own. The only third-party script is the Cloudflare Web Analytics beacon, which counts page views without cookies or identifiers.

Isolation between clinics

Row-level security: Every clinic-scoped table has PostgreSQL row-level security, forced even on the application’s own database role. Each query runs inside a transaction that sets the clinic identity first.
A check at every start: The service refuses to start if its database role could bypass row-level security. The security test suite runs against a role that cannot.
The patient portal: A second, restrictive policy layer limits every portal read to the one signed-in patient.
ITIG Tech staff: Operator access is a separate flag set outside the application. A clinic owner cannot reach the operator console, and an operator has no clinic role.

Accounts and access

Passwords: Argon2id at the 2026 OWASP minimum parameters, 12 characters minimum. Sign-in takes the same time whether or not the email exists, and reset tokens are stored hashed.
Sessions: Signed, HttpOnly, SameSite cookies, 30-day absolute lifetime with a daily sliding refresh. A password change ends every session. A disabled user is refused even with a valid session.
Two-factor login: Optional TOTP with an authenticator app and single-use recovery codes, available to owners and admins.
Brute force: Five failed sign-ins per IP per 15 minutes and ten per email per hour, with one generic error message either way.
Roles: Five roles behind one server-enforced permission map. Treating-doctor-only access by default in multi-doctor clinics. Receptionists see no clinical fields unless the owner widens it. Sensitive visits are visible to doctors only.
Emergency access: A doctor can open another doctor’s patient for 12 hours in one click. Each override writes exactly one immutable audit row, and the owner can list every override.

Who may open a chart

Strict is the default and a clinic owner can widen it. Notes marked sensitive stay with doctors either way, and an override writes one audit row that cannot be edited.

Strict is the default. A clinic owner can widen what the front desk sees. Notes marked sensitive stay with doctors either way.

The audit trail

What is logged: Every write that touches patient data, every chart open, sensitive read, export, emergency access, two-factor event, and refused governance action, with the user, action, resource, IP address, and user agent.
Cannot be edited: A database trigger refuses every update and every delete on the audit table, for every role, including administrators.
What is kept and for how long: Audit rows are never purged. AutoGreet AI conversation text is deleted after 30 days, raw webhook payloads after 30 days, cached idempotency records after 7 days.

Backups and recovery

Point-in-time restore: Azure geo-redundant backups with a 35-day window.
An independent copy: A nightly encrypted dump to Azure Blob storage, encrypted with a key whose private half is held offline, retained 42 days. The job refuses to write an unencrypted dump and checks that the audit table has not shrunk.
Rehearsed: A full restore of both chains was executed on 2026-07-10. The runbook calls for a drill every quarter.
Targets: Recovery time objective under 2 hours. Recovery point objective 5 minutes for point-in-time restore and 24 hours for the independent chain. These are internal targets, not a contractual guarantee.

Application controls

Rate limits: 200 requests per minute per address, with tighter limits on sign-in, password reset, two-factor challenges, and public booking.
Webhooks: Every inbound webhook from Meta or a payment provider is HMAC-verified over the raw body and protected against replay. Unsigned requests are refused.
Secrets: Held as Azure Container Apps secrets, never in files on a machine. Secret scanning runs on every commit and in the build pipeline.
Dependencies: A dependency audit runs on every push, with a written policy that fixes high and critical issues within seven days.
Error tracking: Sentry receives server errors with names, phones, dates of birth, notes, and credentials redacted by field name. The browser sends nothing to Sentry.
Refused at start: Unsafe production configuration stops the service from booting: a database role that could bypass isolation, trusting every proxy, development mail settings, a missing error tracker, a test upload scanner, or one-time codes echoed in responses.

The controls, on screen

Three of the settings above, inside the software rather than described.

The ITIG Clinic team screen showing each account and the role it holds: owner, doctor, doctor, reception — Every account and the role it holds. Demo environment with sample data.

The clinic setting that decides whether a doctor may open another doctor’s patient — Whether a doctor may open another doctor’s patient. Demo environment with sample data.

The two-factor authentication panel in the clinic settings — Two-factor authentication. Demo environment with sample data.

Rights and data handling

Export: The clinic owner can export the whole clinic as spreadsheets at any time, and any patient’s file as a PDF. Every export is written to a ledger the owner can read.
Erasure: A patient can be erased on request with a typed confirmation and a permanent reason. Identifiers are removed at once, a de-identified clinical file is kept for the clinic’s retention period, then deleted. A legal hold blocks erasure. Switched on per clinic.
Breach handling: Our incident runbook works to the 72-hour notification window of Lebanese Law 81 of 2018, with the clinic as the data controller and ITIG Tech as its processor.

What we do not claim

We hold no ISO 27001, SOC 2, or HIPAA certification. No external penetration test has been performed yet. No incident-response drill has been run yet. Some figures on this page are internal targets rather than contractual commitments, and the page says which.

If a statement here is unclear, ask. We will show you the code or the configuration behind it.

Responsible disclosure

If you find a security issue in ITIG Clinic or on this website, write to support@itigtech.com with the details and how to reproduce it. We acknowledge every report and keep you informed until it is resolved. Please do not access or alter data that is not yours while testing.

security.txt