SMILE EDITOR — TECHNICAL AND ORGANIZATIONAL MEASURES (TOMs)

Internal control baseline + customer-facing annex after verification

> IMPORTANT: This is the required control baseline. Do not publish a control as implemented until engineering verifies it in production and evidence exists.

1. Governance

• Named security and privacy owners.
• Security policies reviewed at least annually and after material changes.
• Documented asset/information classification.
• Workforce confidentiality obligations.
• Role-based security/privacy training.
• Vendor security review for processors of Patient Data.

2. Identity and Access Management

• Unique user accounts.
• Least privilege.
• Role-based access control.
• MFA required for privileged/admin access.
• MFA available or required for HIPAA-eligible customer admins.
• Secure password hashing managed by approved authentication infrastructure.
• Rate limiting and anti-brute-force controls.
• Session expiration and revocation.
• Timely removal of departed users.
• Periodic privileged-access review.

3. Tenant Isolation

• Every organization-owned object contains an immutable `organization_id` or equivalent tenant boundary.
• Server-side authorization is mandatory.
• Row-Level Security (RLS) enabled on all exposed multi-tenant tables where using Supabase/Postgres.
• No authorization decision may rely solely on hidden UI controls.
• Automated tests verify that Organization A cannot read/write Organization B resources.

4. Storage Security

• Patient files stored in private buckets only.
• No permanent public URLs for Patient Data.
• Downloads use signed URLs with short expiration.
• Object paths include tenant/case identifiers but should avoid patient names.
• Server validates tenant authorization before generating signed URLs.
• Storage deletion is linked to case/patient/account deletion workflows.

5. Encryption

• TLS for data in transit.
• Encryption at rest through approved infrastructure.
• Secrets stored in secret-management/environment systems, never client code.
• Sensitive tokens rotated after compromise or staff/vendor change where appropriate.

6. Application Security

• Secure development/review process for material changes.
• Dependency vulnerability monitoring.
• Prompt remediation of critical security issues.
• Input validation.
• CSRF/CORS controls appropriate to architecture.
• Secure headers.
• Rate limiting on sensitive endpoints.
• Protection against IDOR/BOLA and broken access control.
• File-type/size validation.
• Malware scanning where risk assessment requires it.

7. Logging and Auditability

Security/audit logs should record:

• login/logout;
• failed login;
• MFA changes;
• user invite/remove;
• role change;
• file upload/download/delete;
• case access where appropriate;
• data export;
• privacy deletion request;
• BAA/DPA/Terms acceptance;
• admin/security configuration change.

Audit logs should not store unnecessary clinical content.

Define retention based on legal/security needs and plan type. Higher-assurance/HIPAA plans may require longer retention.

8. Backups and Recovery

• Documented backup schedule.
• Encryption and access control for backups.
• Restoration testing.
• Recovery objectives defined according to service tier.
• Deleted active data not restored into live production without reapplying deletion obligations.
• Backup retention documented and aligned with Privacy/DPA statements.

9. Availability and Resilience

• Monitoring for service availability and critical errors.
• Incident escalation.
• Capacity/rate controls.
• Recovery procedures.
• Dependency failure handling.

10. Vulnerability Management

• Dependency scanning.
• Periodic vulnerability assessment.
• Penetration testing before major regulated expansion and periodically thereafter.
• Responsible Disclosure program.
• Remediation SLAs based on severity.

11. Workforce and Administrative Access

• Production admin access limited to personnel with legitimate need.
• MFA for all admin access.
• Privileged actions logged.
• Patient Data access for support only when necessary, authorized and logged.
• No use of production Patient Data for casual development/testing.
• De-identified/synthetic data preferred in development.

12. Analytics and Marketing Isolation

• Marketing pixels limited to public marketing surfaces.
• No Meta Pixel, ad retargeting tag, unnecessary session replay, or equivalent tracker on authenticated clinical routes.
• Analytics events from clinical pages must exclude patient name, file content, diagnosis, raw images and other Patient Data.

13. AI Processing

• AI calls routed through approved server-side gateway where feasible.
• No Patient Data in prompts unless the feature is approved for it.
• AI provider appears in Subprocessor List when applicable.
• PHI sent only to HIPAA-eligible providers/configurations where required.
• Provider training/data-retention settings configured consistently with Smile Editor policy.
• Patient Data prohibited from generalized model training under v1.0.

14. Privacy Engineering

• Data minimization by default.
• Patient name optional where functionality permits.
• Export workflow.
• Case/patient deletion workflow.
• Organization deletion workflow.
• Retention jobs.
• Legal-hold capability if required.
• Privacy request tracking.

15. Incident Response

• Written incident response plan.
• Defined severity levels.
• Security contact.
• Evidence preservation.
• Containment/remediation.
• Legal/privacy assessment.
• Customer notification without undue delay where required.
• Post-incident review.

16. Business Associate / HIPAA Controls

Before enabling a HIPAA-eligible plan:

• execute Customer BAA;
• verify required vendor BAAs;
• complete HIPAA security risk analysis;
• identify PHI systems/data flows;
• implement access controls and audit controls;
• define breach escalation;
• train applicable workforce;
• document contingency/recovery plans;
• disable non-approved analytics/integrations.

17. Evidence Register

Maintain evidence for each control:

• owner;
• status: Planned / Implemented / Verified;
• implementation link/config;
• last test date;
• reviewer;
• remediation notes.