Personal Data Protection Policy

1Purpose and scope

This policy states how Fitalthy (Private) Limited handles personal data in practice: who is accountable, how data is classified, what may be done with it, and what must happen when somebody asks for their rights or something goes wrong.

It binds everybody who works on Fitalthy — employees, contractors, and anybody given access to production data — and it governs every system that touches personal data, including the databases, the document store, the payment integrations and the AI provider that reads document text.

It is published deliberately. An internal-only policy cannot be checked by the people it is supposed to protect. If we fail to follow it, you can point at the clause.

It sits alongside the Privacy Policy, which is the user-facing statement of the same commitments, and Safety, which covers the clinical boundary.

2The standard we hold ourselves to

The operating rule: one standard, applied to everybody. We do not give a user in Lahore fewer rights than a user in London because the law in one place is not yet written. Where two frameworks disagree, the stricter one governs.

Legal position reviewed 26 September 2026, and re-checked quarterly.

3Who is accountable for what

Accountability that is not assigned to a named role is accountability nobody has.

Two separations are deliberate. Clinical safety review does not report to the people who build the feature, so a safety concern cannot be closed by its author. And support cannot close a data rights request, so a rights request cannot be quietly filed as "answered".

4Data classification and the controls each class carries

Classification is not labelling for its own sake: the class determines the control, and the control is what an auditor tests.

5Record of processing

Every processing activity, its basis and its retention is recorded. The user-facing extract is published as sections 3, 4 and 6 of the privacy policy; the full register, including systems and controls, is held by the data protection contact and available to a regulator on request.

Processors currently engaged:

Retention schedule:

6Handling a data subject request

A request is valid however it arrives and whatever words are used. "Delete my father's records" is a valid erasure request and is treated as one.

Clocks are set by the system, not by a person. When a request is filed through the complaints form the deadline is computed at intake from the category and written to the record. It cannot be extended by whoever picks the ticket up.

Free of charge, always. We do not charge for a copy of your own records and we do not charge for deleting them.

7Personal data breach management

A breach is any unauthorised access to, loss of, alteration of or disclosure of personal data — including one caused by us.

Reporting one. Anybody — a user, a doctor, a researcher, an employee — can report a suspected breach to dpo@fitalthy.com or through the complaints form, which routes that category straight to the data protection contact on a 24-hour clock.

We will not retaliate against anybody who reports a vulnerability in good faith, and we will not threaten legal action over a report made responsibly.

8Data leaving Pakistan

Some processors operate outside Pakistan, so personal data is transferred abroad. Each transfer must be recorded in the register and covered by a mechanism that binds the recipient to this standard — Standard Contractual Clauses or an equivalent.

A new transfer destination requires the accountable owner's sign-off, a DPIA where health data is involved, and an update to the published processor list before any data moves. Adding a vendor quietly is the control this clause exists to prevent.

9When an impact assessment is required

A data protection impact assessment must be completed and recorded before anything below is built — not after it ships.

• Any new use of health data beyond explaining a document the user uploaded and charting values over time.
• Any automated decision that would affect a person — including anything that ranks, scores or triages patients.
• Any new recipient of personal data, or any new country it is stored in.
• Any feature that would make records visible to someone the user did not explicitly add.
• Any change that would retain data longer than the schedule in section 6 of the privacy policy.
• Any proposal to use records for research, statistics or model training — which is currently prohibited outright.

The assessment names the risk, the mitigation and the residual risk, and is signed by the accountable owner. If residual risk to individuals remains high after mitigation, the feature does not ship.

10Complaints, and the clocks attached to them

Complaints are filed into one register with a deadline computed at intake. The categories and their promises:

Overdue complaints are counted, not hidden. The register reports open complaints past their promised date, and that number is reviewed at the cadence in section 11.

File a complaint or a data rights request →

11Training, audit and review

• Anybody with access to production data is briefed on this policy before access is granted, and again whenever it materially changes.
• The clinical boundary is enforced by tests, not by policy alone — the test suite scans rendered output for diagnostic language and fails the build if it appears.
• This policy is reviewed at least annually, and immediately on: a change in Pakistani law, a new processor, a new category of data, or any breach.
• The legal position in section 2 is re-checked quarterly and dated, because the whole point of stating it accurately is that it will change.
• Request and incident logs are retained three years so that patterns are auditable rather than anecdotal.

12Contacts

Version 1.0, in force from 26 September 2026. Owned by the accountable owner named in section 3.