Security

1Reporting a security problem

If you have found a way to reach data, money or a booking that should not be open to you, tell us before you tell anybody else. Reports go to security@adaptiwise.com, which is also the address published in this deployment’s security.txt.

• What you did, in enough detail that somebody else can do it again — the URL or the endpoint, the method, the shape of the request.
• What came back that should not have. Describe it rather than paste it.
• When you did it, with a time zone, and the request ID if the response carried one.
• How you would like to be credited if we write about the fix, and whether you would rather not be named at all.

There is no OpenPGP key for this address today, so treat the message as ordinary email and keep the sensitive part out of it. If a finding cannot be described without the sensitive part, say so in the email and we will arrange another way.

2Testing: what is fair, and what is not

You need no permission from us to look at the parts of Adaptiwise AI that are open to everybody — a booking page, a sign-in screen, this document. What follows is what we ask of anybody who goes further than looking.

• Use your own account, your own workspace and your own bookings. A real clinic’s calendar is somebody’s patient list, and a test appointment in it is a real person losing a slot.
• Stop at the first proof. Once you can show that something is reachable you do not need to read the rest of it, and you should not.
• Nothing that degrades the service for other people: no load testing, no brute forcing, no denial of service, no bulk automated scanning.
• No social engineering, no phishing of staff or of customers, and nothing physical.
• Do not change, delete or move data that is not yours, and do not leave anything behind — no test account, no persistent hold, no way back in.
• Delete whatever you did retrieve once the report is in, and tell us that you have.
• Give us a reasonable time to fix it before you publish. Ninety days is the convention we will work to, sooner when the fix is quick, and we will not ask you to stay quiet indefinitely.

If you follow those and report privately, we will treat the work as help rather than as an attack: we will not ask a hosting provider, a registrar or the police to act against you over it, and we will not use the Terms of Service as a reason to. What we cannot do is give you immunity from somebody else’s law, or waive a third party’s rights — a clinic, a payment processor and a hosting provider are not ours to speak for.

3What happens after you report

• We read it and reply to say so.
• We work out what is reachable and what has already been reached. Those are different questions, and the second one is what decides whether anybody has to be told.
• We fix it, and we tell you when it is fixed.
• If your finding means somebody’s personal information was exposed, the section below on exposure is what happens next — and it happens whether or not the finding came from outside.

4What this page covers

The Adaptiwise AI platform at app.adaptiwise.com: the console a business signs in to, the public booking pages it serves, the manage links a reminder sends a customer, the API behind all three, and the deployment that runs them.

It does not cover a business’s own website, whatever software it used before, or a service it connected itself; and it does not cover our processors’ own systems — Stripe, Twilio, Postmark and OVHcloud each publish their own disclosure programme. If you cannot tell which of those you have found, send it here anyway and we will pass it on rather than let it sit.

5Health records: who has to tell whom

A clinic using Adaptiwise AI is the health-information custodian for its patients’ records. We are its agent: we hold and process those records on its instructions, and we are not the organisation accountable to the patient for them.

That is a division of duties, not a way of passing one along. Ontario’s PHIPA requires an agent to notify the custodian at the first reasonable opportunity when personal health information it handles on the custodian’s behalf is stolen, lost, or used or disclosed without authority. The other provinces’ health statutes regulate whoever handles a custodian’s records too, in their own words and with their own triggers; where they differ we work to the earlier of them, because telling the clinic sooner has never been anybody’s breach. Telling the clinic is our duty. Telling the patient, and telling the provincial commissioner where the statute requires it, is the clinic’s — and we give the clinic what it needs to do it.

We do not contact a clinic’s patients on the clinic’s behalf unless the clinic asks us to and it is lawful for us to do it. Which statute applies depends on where the business operates: PIPEDA federally, with Quebec’s Law 25, Alberta’s PIPA and the provincial health acts adding their own duties on top.

6If personal information is exposed

Under PIPEDA and its Breach of Security Safeguards Regulations, an organisation must report a breach to the Office of the Privacy Commissioner of Canada and notify the people affected when it is reasonable to believe the breach creates a real risk of significant harm — and must do both as soon as feasible after determining that the breach happened. There is no fixed statutory countdown in Canada; the clock starts at the moment of determining, not at a convenient moment.

• Contain it. Close the way in and revoke what has to be revoked, before working out how big it was.
• Tell the affected businesses. At the first reasonable opportunity — we work to within one business day of confirming — saying what we know and what we do not, rather than waiting until the story is complete.
• Decide who is accountable to the person. For a patient record or a customer record that is the business, because it is the organisation in control of the information. For an Adaptiwise AI account and the people who sign in to it, that is us.
• Notify the individuals, and the commissioner, where the risk requires it. The accountable organisation makes the report; whichever of us that is, the other supplies the facts.
• Keep the record. PIPEDA requires a record of every breach of security safeguards — including one judged not to create a real risk of significant harm — kept for twenty-four months and produced to the Commissioner on request.

7What we keep, and where a copy can be

Working out what actually happened depends on records that exist before anybody needs them. These are the ones this system keeps — and they are also the places a copy of your information can sit after the original is gone, which is the honest other half of the same list.

Audit trail

Who read or changed a customer, a booking or a chart, when, and through which screen. The application can add to it and cannot rewrite or delete it.

Authentication ledger

Every sign-in, failed attempt, sign-out and session revocation. The application cannot read it back at all.

Server logs

Request-level records. Addresses, tokens, card-shaped digits and booking links are stripped before a line is written, and the files rotate, so they are short-lived by design.

Backups

A copy of the database can be encrypted and sent off this machine every six hours, to storage the operator provisions and installs; until that is done the only copy is on the server itself. Where it is running, a backup is everything as it stood at that hour: an erasure reaches the next copy but never one already written — those are locked against change for about a month — so a copy taken before the request still holds what was erased until it ages out, and a restore recreates the data an incident touched.

Error reports

A crash or a server fault can be posted, with personal details scrubbed, to a destination the operator configures. Whatever receives it holds a copy of that fault outside this deployment.

In an incident those are preserved before anything is repaired — a server rebuilt in a hurry takes its logs with it — and kept for as long as the investigation and the twenty-four-month record require. What is collected and how long it is otherwise kept is in the Privacy Policy.

8If you think your own account is affected

• Change your password. That signs out every session on every device, including anybody else’s.
• Tell us at security@adaptiwise.com with your business or workspace name and roughly when you noticed. If you cannot sign in at all, Support is the other way through.
• If it concerns a booking, a clinical record or a clinic charge, tell the business as well — it holds that record and it is the one accountable for it.
• If a payment card is involved, tell your bank. No card number ever reaches Adaptiwise AI, so the processor and your bank are where that thread runs.

9What we do not claim

• We do not claim any health-data certification or attestation — not HIPAA, not PHIPA, not SOC 2. If a regulator or an insurer requires one, Adaptiwise AI does not have it.
• No independent penetration test has been carried out. One is planned. Nothing on this page should be read as saying it has already happened.
• No bug bounty, no reward and no published list of finders.
• No twenty-four-hour monitoring desk and no promised response time.
• This document is a draft that a lawyer has not settled — the notice at the top of the page is not decoration.

10Contact

Security reports: security@adaptiwise.com. The machine-readable version of that contact is at /.well-known/security.txt, in the format RFC 9116 describes, and this page is what its Policy field points at.

A privacy question that is not a security problem is answered in the Privacy Policy; ordinary product trouble goes to Support, and whether the deployment itself is up is on the service-status page.

This page names no individual. Who leads an incident for this deployment belongs to the operator’s own governance — the registered entity named in the Terms of Service, to be completed, and inventing a security officer here would be worse than the gap.