Security overview

This document describes the controls that are actually implemented in the Care Tales platform as of the effective date. It is written to be used as an answer to a security questionnaire, so it also lists what is missing. Nothing here is a forward looking promise unless it says so.

Architecture in one paragraph

Care Tales runs on Google Cloud and Firebase in a single project. Firebase Authentication handles identity, Firestore holds application data, Cloud Storage holds files and Cloud Functions and Firebase App Hosting run server code. Patients reach modules by QR code, link, an embeddable widget or the mobile apps. Staff and providers use a web console and portal.

Authentication and session management

• Identity is handled by Firebase Authentication. Supported sign-in providers are email, Google, Apple and Microsoft.
• Sessions use server minted session cookies that are httpOnly, secure and same site lax. They are not readable by page scripts.
• Revocation is checked on every API request and every session check, so disabling an account or signing a user out everywhere cuts off data access on the next request rather than at cookie expiry. Page routing checks the cookie's signature and expiry only, so an already open page shell can still load until its next data request is refused.
• The session cookie is shared by caretales.com and its subdomains, so one sign-in covers both the console and the provider portal. The domain is chosen per request and is never set for hosts outside caretales.com.
• Session lifetime is 12 hours, or 14 days when the user chooses to be remembered.
• Roles are read from the database on the server for each request. A role claim carried in a cookie is never trusted. The staff "view as" preview cookie is readable by scripts on purpose and carries no authority.

Two factor authentication

• Two factor authentication with an authenticator app is required for every staff role and every provider role. A US phone number can be added as a backup that receives a code by text; it cannot replace the app. An account that has enrolled and does not present a valid code is refused, not downgraded.
• Patients are excluded from the two factor requirement.

Authorization, tenancy and data rules

• Firestore rules default to deny. Access is granted path by path.
• Organization data is tenant scoped. A member of one organization cannot read another organization's records.
• Patient chat transcripts are readable only by Care Tales admin and team roles, or by a provider of the organization that owns the conversation.
• No client path allows a user to grant themselves or anyone else a role.
• Per organization model keys are unreadable by any client.
• Cloud Storage rules enforce tenant isolation on knowledge base files, restrict profile photos to their owner, cap file size, restrict content types and otherwise deny.
• Every non public API route checks the caller's role on the server. Routes that expose protected health information narrow further to admin and team only.
• Aggregate chatbot insight terms are surfaced only once a term appears in at least three conversations, and raw patient messages never leave the server for reporting purposes.

Rate limiting and abuse controls

Rate limits are applied to the chat, contact, speech and SMS endpoints. Bot traffic on module landing pages is flagged. See the gap list below for the limits of this control.

Transport and browser security

• HTTP Strict Transport Security is enabled.
• X-Content-Type-Options is set to nosniff.
• A referrer policy is set.
• Framing is denied on the console and the portal.
• All traffic is served over TLS.

Encryption

Encryption in transit and at rest is provided by Google Cloud defaults. Care Tales does not add application level field encryption, and does not manage its own encryption keys.

Secret management

Application secrets, including model keys, are held as server side configuration and are never delivered to a browser or a mobile client. Per organization model keys are stored so that no client role can read them.

Internal connector and audit

Care Tales staff use an internal connector to reach operational data. The connector issues grants per functional area rather than blanket access, and writes an audit log entry for every call. This is the only audited read path in the system today.

Content review

Modules move through Draft, then Submitted, then Verified. Verification is a human review by Care Tales staff before a module is published to patients. AI safety rules applied at generation and at answer time are described in the AI disclosure.

Where data lives

• Firestore databases (the main database, the staff console database and one per translated language) are in Google's nam5 multi-region in the United States.
• Uploaded files are in Cloud Storage in us-central1. The website, background jobs and functions run in us-central1.
• The main database is backed up weekly and each backup is kept for 98 days. Point in time recovery covers the last 7 days on every database, and every database has delete protection turned on.
• Application request logs are kept for 30 days. Audit logs, including a record of every read and write to the databases, file storage, the sign-in system and secrets, are kept for 400 days.

Data deletion that works today

• Deleting an account deletes the user record and its subcollections, organization membership, storage files and the Firebase Authentication user.
• Deleting an organization recursively deletes its visits, module sessions and chatbot transcripts from the live database.
• Deleted data can remain in the weekly backups until they expire after 98 days. There are no other copies of patient records outside the live database and those backups.
• Share links expire after 90 days. Connector access tokens last one hour and refresh tokens 90 days.

What is not in place

This list is accurate as of the effective date and is not an exhaustive risk assessment.

1. No SOC 2. Care Tales has no SOC 2 Type I or Type II report and no equivalent certification.
2. No external penetration test. No third party has tested the platform. No penetration test report exists.
3. No external security audit or HIPAA certification.
4. No Content Security Policy. The web application does not send a CSP header. Public chat endpoints accept cross origin requests from any origin.
5. No per person log of staff reads of patient data through the product. Google Cloud audit logs record every database read, but reads made through the web application are attributed to the application's own identity, not to the staff member. Internal connector calls are audited per person.
6. No automated retention deletion. There is no retention schedule and no scheduled job that removes patient data. Visits, module sessions, survey answers, rating comments and chatbot transcripts are kept indefinitely unless the account or the organization is deleted.
7. No self service patient access or deletion for patients who have no account. Those requests must be routed through the customer organization.
8. Rate limiting is per server instance, not global, so a distributed caller can exceed the intended rate.
9. No application level field encryption.
10. The embeddable WordPress widget stores a full untruncated IP address, plus country, city, region, coordinates, browser, operating system, device type, language, timezone, screen size and referrer. The main site chat path truncates IP addresses and does not store them.
11. Anonymous chat identity is caller asserted. Anyone who learns a session identifier can retrieve that conversation's context.
12. No cookie consent banner and no consent management platform.
13. No age verification, although the published terms state a minimum age of 13.
14. No scripted staff offboarding. Access removal is a manual process.
15. No business associate agreement workflow in the product.

Reporting a vulnerability

Send details to support@caretales.com. Please include steps to reproduce and do not access, modify or retain any data belonging to another party while testing.

Contact

support@caretales.com

Changes to this document

This overview is revised whenever a control in it is added, changed or removed, and at minimum when a gap on the list above is closed. Each revision carries a new effective date. Customers with an active agreement are notified by email at the administrative contact on file.