Security overview

TriageFit is a health coaching service, so the data it holds is sensitive by nature and the platform is built on that assumption. This page describes the controls as they run in production, in the order a procurement reader usually asks about them. It pairs with the data-flow summary, the sub-processor list and the data processing agreement.

Where data is processed

Processing is kept in the EU wherever we control the region. Application compute is pinned to Frankfurt, the database runs in Frankfurt, member file uploads are stored under EU jurisdiction, error monitoring runs in Germany, and AI requests run in EU regions only, with a runtime check that refuses to start a request against a non-EU region. The sub-processor list states the position per provider, including the global providers, such as the payment and email carriers, where no single region is pinned.

Encryption

All traffic to and from the Service runs over TLS. On top of the platform's storage encryption, sensitive health fields are encrypted at the application layer with AES-256-GCM before they reach the database, so a database-level compromise on its own does not expose their contents. Database backups are taken on a schedule and encrypted with a public key whose private half is held offline, outside the systems that write the backups.

What an employer can and cannot see

Organisation reporting is aggregate by design and enforced in the data engine rather than in the screen. A metric is released only when at least five distinct members contributed to it; below that floor the engine returns a suppressed value that carries no number at all, and the report says why. No role at an employer reaches an individual member's logs, messages or health data through any route, and a clinician seat issued inside a corporate organisation releases nothing. What an organisation admin does see is the roster: who was invited, whether the invitation was redeemed, and each seat's state. A billing admin is held a step further back again and cannot open a health report at all, aggregated or otherwise.

What a clinic can see

A healthcare partner is the one place a named individual's health data leaves their own account, and it moves because that member turned it on. Consent is held per clinic, recorded with the version of the wording the member read, and resolved on every read rather than cached as a flag, so turning it off empties the clinicians' patient list and the clinic's cohort report on the next request. Only a clinician seat opens a patient summary or a patient report: the administrator and billing roles that run a clinic's account are not clinician seats, and a person holds one role per organisation. Every summary shown and every report opened writes a row to the sensitive-read audit trail, one row per patient, so a clinic can be shown who read what and when.

Access control and auditing

Every API route that reads member data checks both who is signed in and whether that account is entitled to the specific record it asks for, so one member, coach or organisation admin cannot reach another's data by changing an identifier. Reads of special-category health records by staff write to a dedicated sensitive-read audit trail recording who read what and when.

Account security

Passwords are stored only as salted hashes under an industry-standard adaptive algorithm, and new passwords are screened against known breach corpuses. Two-factor authentication with an authenticator app is mandatory for every account that is not an ordinary member: our own staff, organisation admins, billing admins and clinicians. Until one is enrolled, such an account reaches its own enrolment page, its own account settings and the way out, and nothing else, and there is no endpoint that lets it skip the step. Members can turn the same protection on for themselves. Authentication and other sensitive endpoints are rate limited.

Payments

Payment is handled by Stripe. Card and bank details are entered with Stripe and never touch or rest on TriageFit's servers; we hold billing references, not payment instruments.

Monitoring without leaking

Error telemetry is scrubbed of known identifying and health fields before it leaves the application, and session replay is disabled, so the monitoring pipeline cannot become a copy of member data.

Software supply chain

Dependencies are installed under a minimum-release-age policy, so a freshly published package version cannot enter a build for several days, and a standing scanner checks the dependency tree for known compromised packages.

Data rights and incident response

Members can export their data and erase their account from inside the product, and consent is versioned and audited. We maintain an internal breach-response runbook, and our Data Protection Officer is named in the privacy policy. The Irish Data Protection Commission is our lead supervisory authority.

Questions and disclosures

Security questions, diligence questionnaires and vulnerability reports all reach us at info@triagemethod.com. If you believe you have found a vulnerability, tell us there before telling anyone else and give us a reasonable period to fix it before you publish. We respond quickly and we will not pursue legal action over good-faith research that stays inside the rules below. There is no paid bounty.

Those rules exist because this platform holds real people's health data, and the line between finding a weakness and causing the harm you were looking for is a short one. Test only against an account you own or an organisation that has asked you to test it. Do not access, alter, retain or exfiltrate any other person's data, and if you reach someone else's record by accident, stop at that point, keep no copy, and tell us what you saw. Do not delete or modify data you do not own, and remove anything you create while testing.

Keep the Service available to the members using it. Automated scanning that degrades performance, load testing, denial-of-service testing and brute-force attempts against live accounts are all out of scope. So is anything aimed at people rather than software: no social engineering, phishing or pretexting of our staff, our members or our suppliers, and no physical access attempts. Our sub-processors run their own infrastructure and their own disclosure programmes, so report anything you find in theirs to them rather than testing it under ours.