Security at Kinevie

Kinevie is built for Canadian physiotherapy, massage, and allied-health clinics. Security is treated as a feature, not a checkbox: it is a board-level priority, owned by our CTO and reviewed at least quarterly. We design the patient portal, clinic operating system, and the underlying platform around the principle of least privilege and defence in depth — so that a single failure cannot cascade.

This page describes our technical, administrative, and physical safeguards in summary. Specific contractual commitments live in each clinic's services agreement and data processing addendum.

• Confidentiality. Information is accessible only to people and systems with a genuine need.
• Integrity. Records cannot be altered without an auditable trace.
• Availability. Clinics need to operate every day — we engineer for redundancy, graceful degradation, and tested recovery.
• Accountability. Every privileged action is logged; every change is attributable.
• Autonomy. Patients retain control of their information through access, correction, withdrawal, and portability requests honoured by the custodian clinic.
• Privacy by design. New features go through privacy and security review before they ship — data minimization, encryption, retention, and access scope are decided up front.

Encryption in transit. All connections to Kinevie use TLS 1.2 or higher with modern cipher suites. HTTP Strict Transport Security (HSTS) is enforced on all production hostnames so browsers refuse insecure connections.

Encryption at rest. Production databases, file storage, and database backups are encrypted at rest using AES-256. Encryption keys are managed by our cloud provider's KMS, with strict role-based access and automatic rotation.

Sensitive fields. Specific sensitive fields (authentication secrets, API tokens, certain healthcare identifiers) are protected with an additional layer of application-level encryption so they remain unreadable even if a database snapshot is mishandled.

Data minimization. We collect what is needed for the service and no more, and we tier retention so non-clinical data has a shorter life than the clinical record. See the Privacy Policy for category-by-category retention.

Tenant isolation. Every record in the clinic operating system carries its tenant identifier; all queries are scoped to the current tenant at the application layer, and tested with cross-tenant access checks in CI. Sub-domains and storage paths are also segregated per tenant.

Authentication. Patients and clinic staff sign in with passwords that must meet length and complexity requirements; passwords are stored as salted hashes using a modern, slow KDF (argon2id / bcrypt-family). Repeated failed sign-ins trigger progressive throttling and account-lockout protections.

Multi-factor authentication. MFA is available for all clinic staff and strongly recommended (and required by default for owner/admin roles). Patients can enable MFA from the portal.

Sessions. Sessions are bound to the device, expire after a period of inactivity, and can be revoked centrally. Sensitive actions (changing email, deauthorizing a device) require re-authentication.

Role-based access. Permissions inside the clinic operating system are assigned by role — owner, administrator, billing, regulated therapist, receptionist — and enforced at the API layer, not just the UI. Therapists see only their own patient records by default; cross-therapist access is a tenant-level setting.

Least privilege for Kinevie staff. Production database access is restricted to a small on-call group; all access is logged and reviewed. Engineers do not have routine access to patient health information. Support staff use scoped tools that surface only the information needed to resolve a ticket.

Joiner / mover / leaver. Access for Kinevie staff is provisioned by role at hire, reviewed on every role change, and revoked within 24 hours of departure.

Canadian-region hosting. Production data for Canadian clinics is hosted in Canadian regions of our cloud provider. We use redundant availability zones to tolerate the loss of a single data center.

Network controls. Production systems sit behind a managed Web Application Firewall, DDoS protections, and rate limiting. Inbound traffic is restricted to the minimum required ports; outbound traffic is restricted by allowlist where practical.

Hardened images. Servers are built from immutable, hardened base images. Operating-system patches are applied on an aggressive cadence; critical CVEs are targeted within 48 hours of a vendor patch.

Secrets management. Credentials, API keys, and certificates are stored in a dedicated secret manager with short rotation cycles. Secrets are never committed to source control; commit hooks and CI scans block accidental leakage.

Every change to Kinevie's production code follows the same pipeline:

• Peer review. No code reaches production without review by another engineer.
• Automated testing. Unit, integration, and end-to-end tests run in CI. Critical paths — auth, tenant isolation, payment, intake — have dedicated regression suites.
• Static analysis and dependency scanning. Linters, type-checks, container scans, and dependency-vulnerability tools run on every pull request. New critical/high vulnerabilities block merge until patched.
• Threat modelling. Significant new features (auth flows, payment, third-party integrations, AI assistance) go through a threat-modelling exercise before implementation.
• Penetration testing. Independent third parties test Kinevie on at least an annual basis and after major architectural changes.
• Change management. Deployments are automated, observable, and reversible. Risky changes ship behind feature flags so we can roll back without a redeploy.

We centrally collect application, infrastructure, and audit logs from production. Logs are tamper-evident, retained for the periods required by law and our internal policy, and alerted on through automated detection rules covering:

• authentication anomalies (impossible travel, repeated failures, credential stuffing);
• cross-tenant access attempts and privilege escalation;
• unusual data-export volume;
• configuration drift on production systems; and
• known-exploit patterns at the edge (WAF) and inside the application.

On-call engineers receive alerts 24/7 and follow documented runbooks. Severity-1 issues page our incident-commander rotation immediately.

Kinevie maintains a written incident-response plan that is exercised on a regular cadence. Confirmed incidents follow a documented lifecycle — detect, contain, eradicate, recover, learn — with clear ownership at each step.

Breach notification. Where an incident involves personal or health information, Kinevie will:

• notify the affected clinic (the health information custodian) without unreasonable delay so they can meet their own legal duties under PHIPA, HIA, Law 25, or other applicable laws;
• cooperate with the clinic's notification to the patient and to the relevant privacy regulator(s) where required by law;
• for breaches affecting Kinevie itself, notify the Office of the Privacy Commissioner of Canada and affected individuals where PIPEDA's real-risk-of-significant-harm threshold is met; and
• preserve evidence and document the timeline, scope, and remediation in a post-incident report.

We target a high level of availability for the patient portal and clinic operating system, with service-level commitments stated in clinic services agreements.

Backups. Production databases are backed up with point-in-time recovery across multiple availability zones. Backups are encrypted at rest, access-controlled, and tested by performing routine restores. Retention is set so that recovery is possible from both recent operational mistakes and longer-running issues.

Disaster recovery. We maintain documented RPO (recovery point objective) and RTO (recovery time objective) targets, and we exercise the recovery process on a regular cadence so that the runbooks are accurate.

Graceful degradation. Where a non-critical dependency fails (an email provider, an analytics service), Kinevie continues to function on the critical paths — patient booking, intake, clinical notes — and queues retries where appropriate.

Kinevie's privacy and security program is aligned with the requirements of:

• PIPEDA — Canada's federal private-sector privacy law, and the Office of the Privacy Commissioner's published guidance for service providers.
• Provincial health-information laws applicable to the clinics we serve, including Ontario's PHIPA, Alberta's HIA, B.C.'s PIPA, and Québec's Law 25.
• WHO health-data governance principles — confidentiality, integrity, availability, accountability, transparency, and respect for individual autonomy.
• Industry frameworks — we map our internal controls to recognized frameworks such as NIST CSF and ISO 27001 control families.

We undergo regular independent assessment of our controls. Clinics under NDA can request our current attestation reports and security questionnaire responses.

Background checks are performed where permitted by law before granting access to production systems. All Kinevie staff sign a confidentiality agreement and complete mandatory training that covers:

• Canadian privacy and health-information law fundamentals;
• secure-coding and threat-awareness practices;
• phishing and social-engineering recognition;
• incident-response responsibilities; and
• handling of sensitive data, including the do-not-touch rules for clinical records.

Training is refreshed at least annually and additional role-specific training is required for engineering, support, and on-call staff.

We carefully select sub-processors (cloud infrastructure, email, SMS, voice synthesis, analytics, payment processing). Before engagement, vendors are reviewed for:

• their privacy and security posture (certifications, public reports, references);
• where they store and process data (Canadian residency preferred);
• contractual data-processing protections; and
• the principle of using the minimum scope of data necessary.

A current list of sub-processors and what they do is maintained in our Privacy Policy and the data-processing addendum we maintain for clinic subscribers.

Security is a partnership. We protect the platform; you protect your account.

For patients: use a unique, strong password; enable MFA where offered; sign out on shared devices; be cautious about sharing your portal screen with anyone who is not part of your care; report suspicious messages to security@kinevieapp.com.

For clinics: use unique work accounts (no shared logins); enable MFA for every clinic-staff user; assign roles by need-to-know; deprovision departing staff promptly; keep your devices patched; never store clinic credentials in chat or email; and follow your regulatory college's electronic-records standards.

A reminder: Kinevie staff will never ask for your password, MFA code, or session cookie. Treat any such request as a phishing attempt.

We welcome reports from security researchers. If you believe you have found a security vulnerability in any Kinevie surface, please email security@kinevieapp.com with:

• a clear description of the vulnerability;
• the affected URL or component;
• a proof of concept or reproducible steps; and
• your contact information for follow-up.

We aim to acknowledge reports within two business days, share an initial triage within five business days, and provide regular updates until remediation. We credit researchers in our acknowledgements list (with permission) once a fix has shipped.

Security disclosures and incident reports: security@kinevieapp.com

Privacy questions: privacy@kinevieapp.com

Legal notices: legal@kinevieapp.com

For PGP-encrypted reports, request our public key from security@kinevieapp.com.