Security

Everything runs in AWS Canada (Central), in Ontario. Records, files, backups and credentials never leave the country in the course of normal operation. Databases run Multi-AZ with automatic failover, so a single data-centre failure does not take an agency offline.

Tenant isolation is enforced in three independent layers, and the important one is the last:

• A separate portal per agency, on its own subdomain.
• Application role-based access, scoped to the individual home rather than the whole agency.
• PostgreSQL row-level security, enabled and forced on every table holding personal information.

The third layer means isolation does not depend on application code being correct. A query that forgets its tenant context returns zero rows rather than someone else’s data — the database refuses, not the application. Isolation tests run in continuous integration on every change.

Everything at rest — database, uploaded files, backups, and application secrets — is encrypted under a customer-managed KMS key with automatic annual rotation, rather than a shared default key. Key access is scoped to the application roles that need it, and every use is recorded in AWS CloudTrail.

TLS 1.2 or better in transit, at the edge and between the application and the database.

The audit trail is append-only and records reads, not just writes — opening a record, downloading a document, and running an export are all logged to a named account. Audit visibility itself follows the role hierarchy, so the trail cannot be used as a way around the access model.

Records lock when approved. Corrections are signed, dated amendments that sit alongside the original, which never changes. A screen opened on any client record carries a faint watermark naming the person signed in, the agency and the time — on screen and on anything printed from it — so a photographed or photocopied record traces back to an account.

Per-agency accounts with argon2id password hashing, optional TOTP two-factor authentication that an agency can require of everyone, lockout after repeated failures, and both idle and absolute session expiry. Agencies can additionally restrict front-line sign-in to the shifts a person is actually rostered for, so a client record is not opened at home on a day off.

Staff see the homes they work in. A supervisor scoped to one home cannot exercise org-wide powers, and agencies can hide selected client-record fields from front-line staff entirely — though never allergies, medications, emergency contacts, risk level or the safety plan, which no setting can take away from someone on shift.

Every upload passes a type and size allowlist and is scanned for malware before it is ever stored. The scanner is fail-closed: if it cannot scan a file, the upload is refused rather than allowed through. This is verified in production, not only in testing.

Outbound email is content-minimised by code. Notifications carry generic alerts and counts — never a client’s name or any health detail. Anything specific requires signing in.

Agencies set their own retention period from their written retention policy, as CYFSA Part X requires them to have. Destruction runs through a single controlled pathway and leaves a de-identified certificate as evidence. A full export of an agency’s data — records, documents, and audit history — is available at any time, because a custodian should never have to ask permission to retrieve its own information.

Deployments run from GitHub to AWS over OIDC with no long-lived cloud credentials anywhere. Container images are scanned on push. Database migrations and administrative operations run as auditable one-off tasks rather than by hand on a console. Releases roll out gradually and roll back automatically on failure.

Built for CYFSA Part X and PHIPA for agency client records, and PIPEDA for our own relationship with the agency. A completed Privacy Impact Assessment is shared with prospective agencies for their own PIA process, and a Data Processing Agreement — including technical-measures and subprocessor annexes — is offered to every agency. Breach response follows a documented detect, contain, assess, notify procedure aligned to what the Information and Privacy Commissioner of Ontario expects.

A security page that lists only strengths tells you nothing, because every vendor’s does. So, plainly:

• We have not yet commissioned an independent penetration test. It is planned, and we will share the report and remediation when it is done.
• Our backup restore procedure is not yet exercised on a documented schedule. Backups run and are encrypted; the drill is what is missing.
• Our Content-Security-Policy is in place but not yet nonce-based.
• We hold no third-party certification such as SOC 2 or ISO 27001 today.

We would rather you learn this here than discover it in a questionnaire. If any of it is a blocker for your procurement, tell us — it moves up the list.

If you believe you have found a security issue, email security@carepath247.com. Tell us what you found and how to reproduce it, and please give us a reasonable chance to fix it before publishing. We will acknowledge within two business days.

For the full technical-measures annex, the Privacy Impact Assessment, or a completed vendor security questionnaire, get in touch.