Security & Compliance

Part of the Anaya Care Handbook — the source of truth for how the product must behave. When the product needs to change, change this document first, then make the system match it.

Implementation status — this module is specified but not yet built. Every rule below is 🚧 Spec only until the feature ships and this page is audited against the code. Legend: ✅ In code · ⚠️ Partial · 🚧 Spec only (not yet built).

What this covers

This page governs the platform-wide non-functional requirements that every other module must meet: how data is protected in transit and at rest, how privacy is handled, the performance and scalability targets, what happens when something fails, and the accessibility standard the product must reach. These are obligations on the platform as a whole, not features a user operates. The accessibility obligations are owned in full on the dedicated Accessibility page; this page restates the baseline so the security and compliance picture is complete. Data retention and ownership are a separate concern and have their own page — Data Ownership & Retention.

Key terms

• In transit — data moving between a device and the platform over the network.
• At rest — data stored on disk, in the database, in backups, or on a device.
• MFA (multi-factor authentication) — a second proof of identity required at sign-in beyond a password.
• Session timeout — automatic sign-out after a configurable period of inactivity.
• Account lockout — temporarily blocking sign-in after repeated failed login attempts.
• Audit log — a tamper-proof record of who accessed, changed, or deleted what, and when.
• RBAC (role-based access control) — granting access by role, enforced everywhere including the API layer, so a request that bypasses the screens is still checked.
• Penetration test — an authorised simulated attack to find security weaknesses.
• SOC 2 Type II — an independent report attesting that security controls operate effectively over time.
• HIPAA-aligned — handling health data to the standard expected of HIPAA-covered entities, used here as the platform's baseline; the platform also aligns with HITECH, CCPA, and applicable state laws.
• Data minimisation — collecting only the data necessary to deliver care, and nothing more.
• Privacy rights — the rights a person has over their own data: access, correction, deletion, portability, and restriction.
• Data Use Agreement / BAA (Business Associate Agreement) — a signed contract that binds a third-party partner to handle data to the platform's standard; Anaya acts as a Business Associate to subscribing agencies.
• Data classification — sorting data by sensitivity so each tier gets the right protection: PHI (highest), PII (high), and operational data (standard).
• Breach response — the defined process for notifying people after a data breach: affected parties within 60 days, and subscribers immediately on discovery.
• Uptime — the proportion of time the platform is available and serving requests.
• Horizontal scaling — adding more servers to handle load, rather than enlarging one server.
• Multi-tenant isolation — keeping each subscribing company's data completely separate from every other's.
• Backup — a stored copy of platform data used to recover after loss or corruption.
• Point-in-time recovery — restoring data to its exact state at a chosen earlier moment.
• RTO (Recovery Time Objective) — the maximum acceptable time to restore service after an outage.
• RPO (Recovery Point Objective) — the maximum acceptable amount of data loss, measured as a window of time.
• Failover — automatically switching to a standby system when the primary one fails.
• WCAG 2.1 AA — the web accessibility standard the product's interfaces must satisfy.

How it works

These requirements sit beneath the whole platform. They are grouped here by theme so each one can be tested on its own. None of them are user-facing features; they are guarantees the system must keep at all times.

Security

All traffic is encrypted in transit and all stored data is encrypted at rest. Every account signs in with multi-factor authentication. Sessions end automatically after a configurable period of inactivity, and an account is locked after repeated failed login attempts. Access is granted by role through role-based access control, enforced at every level including the API layer, so a request that skips the screens is still checked. Every access, edit, and deletion is written to a tamper-proof audit log — the same log that records access-control decisions in Identity, Access & the Business. The platform is tested by penetration testing at least twice a year and audited by an independent third party each year, and SOC 2 Type II certification is to be pursued as the platform matures.

Privacy

Health data is handled to a HIPAA-aligned standard as the baseline, and the platform also aligns with HITECH, CCPA, and applicable state laws. The platform collects only the data needed to deliver care, and never sells or shares user data without explicit authorisation. Data is classified by sensitivity — PHI gets the highest protection, PII high, and operational data standard — so each tier is protected to the right level. People can exercise their privacy rights over their own data: access, correction, deletion, portability, and restriction. Every third-party partner must sign a Data Use Agreement or Business Associate Agreement before handling any data, and Anaya itself acts as a Business Associate to each subscribing agency. If a breach occurs, affected parties are notified within 60 days and subscribers are notified immediately on discovery. Care Feed photos are stored securely and can never be downloaded or shared outside the platform.

Performance

The platform targets 99.9% uptime. A page loads in under three seconds on a standard mobile connection. Push notifications are delivered within thirty seconds of the event that triggered them. The platform serves every subscribing company at the same time without degrading.

Scalability

The platform scales by adding servers rather than enlarging one. New subscribers are onboarded without any downtime, and multi-tenant isolation holds no matter how large the platform grows.

Reliability & disaster recovery

Backups run automatically every day and support point-in-time recovery. They are stored in a geographically separate location. A documented RTO and RPO are defined before launch. If a server fails, the platform fails over automatically, and disaster recovery is tested regularly.

Compliance

The platform's regulatory baseline is HIPAA-aligned data handling, extended to align with HITECH, CCPA, and applicable state laws. Data is sorted into classification tiers — PHI, PII, and operational data — so each gets the right level of protection. Third-party partners sign Data Use Agreements or BAAs, and Anaya acts as a Business Associate. A documented breach-response process governs notification: affected parties within 60 days, subscribers immediately on discovery.

Accessibility

Every user-facing interface meets WCAG 2.1 AA. Images and icons carry alt text. Colour is never the only way information is conveyed. Every interactive element can be reached by touch and by voice, and the interfaces work with screen readers. The full accessibility requirements live on the Accessibility page; the rules below restate the baseline here.

Rules

Security

1. SEC-1 — All data in transit must be encrypted using TLS 1.2 or higher. (🚧 Spec only)
2. SEC-2 — All data at rest must be encrypted using AES-256. (🚧 Spec only)
3. SEC-3 — Multi-factor authentication must be required for every user account. (🚧 Spec only)
4. SEC-4 — The system must automatically end a session after a configurable period of inactivity. (🚧 Spec only)
5. SEC-5 — The system must lock an account after repeated failed login attempts. (🚧 Spec only)
6. SEC-6 — Every data access, edit, and deletion must be recorded in a tamper-proof audit log. (🚧 Spec only)
7. SEC-7 — Penetration testing must be carried out at least twice a year. (🚧 Spec only)
8. SEC-8 — An independent third party must conduct a security audit at least once a year. (🚧 Spec only)
9. SEC-9 — The platform must pursue SOC 2 Type II certification. (🚧 Spec only)

Privacy

10. SEC-10 — Health data must be handled to a HIPAA-aligned standard as the platform's baseline. (🚧 Spec only)
11. SEC-11 — The system must collect only the data necessary to deliver care. (🚧 Spec only)
12. SEC-12 — User data must never be sold or shared without explicit authorisation. (🚧 Spec only)
13. SEC-13 — Care Feed photos must be stored securely and must not be downloadable by any user. (🚧 Spec only)

Performance

14. SEC-14 — The platform must achieve 99.9% uptime. (🚧 Spec only)
15. SEC-15 — A page must load in under three seconds on a standard mobile connection. (🚧 Spec only)
16. SEC-16 — A push notification must be delivered within thirty seconds of the event that triggered it. (🚧 Spec only)
17. SEC-17 — The platform must serve every subscribing company concurrently without degradation. (🚧 Spec only)

Scalability

18. SEC-18 — The platform must scale horizontally as subscriber count grows. (🚧 Spec only)
19. SEC-19 — A new subscriber must be onboarded without any system downtime. (🚧 Spec only)
20. SEC-20 — Multi-tenant data isolation must be maintained at scale, with no cross-company data access under any circumstance. (🚧 Spec only)

Reliability & disaster recovery

21. SEC-21 — Backups must run automatically every day and must support point-in-time recovery. (🚧 Spec only)
22. SEC-22 — Backups must be stored in a geographically separate location. (🚧 Spec only)
23. SEC-23 — A documented RTO and RPO must be defined before launch. (🚧 Spec only)
24. SEC-24 — The platform must fail over automatically when a server outage occurs. (🚧 Spec only)
25. SEC-25 — Disaster recovery must be tested regularly. (🚧 Spec only)

Accessibility

26. SEC-26 — Every user-facing interface must comply with WCAG 2.1 AA. (🚧 Spec only)
27. SEC-27 — All images and icons must include alt text. (🚧 Spec only)
28. SEC-28 — Colour must never be the sole means of conveying information. (🚧 Spec only)
29. SEC-29 — Every interactive element must be reachable by both touch and voice. (🚧 Spec only)
30. SEC-30 — All user-facing interfaces must be compatible with screen readers. (🚧 Spec only)

Compliance & privacy rights

31. SEC-31 — Role-based access control must be enforced at every level, including the API layer, so that a request that bypasses the user interface is still checked against the requester's role. (🚧 Spec only)
32. SEC-32 — The system must support each person's privacy rights over their own data: access, correction, deletion, portability, and restriction. (🚧 Spec only)
33. SEC-33 — Every third-party partner that handles platform data must sign a Data Use Agreement or Business Associate Agreement before any data is shared, and Anaya must act as a Business Associate to each subscribing agency. (🚧 Spec only)
34. SEC-34 — The platform's compliance baseline must align with HIPAA, HITECH, CCPA, and applicable state laws. (🚧 Spec only)
35. SEC-35 — All data must be classified by sensitivity — PHI (highest protection), PII (high), and operational data (standard) — and protected to the level its classification requires. (🚧 Spec only)
36. SEC-36 — On a data breach, the system's documented breach-response process must notify affected parties within 60 days and notify subscribers immediately on discovery. (🚧 Spec only)
37. SEC-37 — Care Feed photos must not be shareable outside the platform. (🚧 Spec only)

Who can do what

These rules apply platform-wide and are not operated by any role; they are obligations the system must meet for every user. Role permissions are defined in Identity, Access & the Business and operated through Platform Operations.

Decisions needed

• What is the session timeout period? The PRD requires the inactivity period to be configurable but does not state a default. Sign-in already enforces a 15-minute idle timeout today (Identity, Access & the Business ACCESS-10), so the configurable period effectively defaults to 15 minutes; the open question is whether to make it configurable per subscriber or per role. Options: a single platform-wide default; a per-subscriber setting; a per-role setting.
• What are the lockout thresholds? The PRD requires lockout after "repeated" failed attempts but gives no number or duration. Options: fix a standard count and lockout window; make them configurable per subscriber; use a graduated back-off.
• How is a locked account unlocked? The error-handling notes mention unlock via email verification, but the recovery flow is not specified. Options: self-service email verification; administrator unlock; both.
• What exactly are the RTO and RPO targets? The PRD requires them to be documented before launch but does not set the numbers. Options: agree platform-wide targets; vary by subscriber tier or contract.
• What counts as "explicit authorisation" to share data? The PRD forbids sharing without it but does not define who gives it or how it is recorded. Options: per-client consent captured in the profile; subscriber-level contractual authorisation; both, with an audit entry.
• Who owns and triggers the breach-response process, and how are affected parties identified? SEC-36 sets the notification windows (affected parties within 60 days, subscribers immediately on discovery) but not who declares a breach, how the affected set is determined, or the channel used. Options: an Anaya-led process with a defined incident owner; a shared process with the subscribing agency; automated detection feeding a manual review.
• How are the privacy rights in SEC-32 surfaced and fulfilled? The PRD lists access, correction, deletion, portability, and restriction but not the request flow or who fulfils each. Options: self-service in the profile; requests routed to the agency; requests routed to Anaya via Data Ownership & Retention.