TyriaCore Security Measures Addendum
Last Updated: May 31, 2026
This Security Measures Addendum ("Security Addendum") summarizes Provider's security controls and Customer responsibilities.
This Security Addendum is incorporated by reference into the Agreement between Provider and Customer to the extent referenced in an Order Form or otherwise incorporated into the Agreement.
Order of precedence. If there is a conflict between this Security Addendum and the Agreement (or an Order Form, SOW, DPA, or BAA), the order of precedence in the Agreement controls. If there is a conflict with the BAA regarding PHI, the BAA controls.
No guarantee / no expanded liability. This Security Addendum does not guarantee that Customer Data will be secure against all threats. Provider's disclaimers, limitations of liability, and remedies limitations in the Agreement apply.
1. Scope of Security Commitments (Production Scope)
Provider's formal security and compliance controls apply to TyriaCore production systems ("Production") that deliver the Subscription Services.
Non-production environments (including sandbox, demo, pre-production, and development/test) may be excluded from formal compliance scopes and are intended for development and validation.
2. PHI in Non-Production Prohibited
Unless expressly authorized in writing by Provider and safeguarded appropriately:
- PHI is not permitted in non-production environments.
Provider maintains controls intended to prevent production PHI or production Customer Data from being used in non-production environments absent such authorization.
3. Security Program (SOC 2-Aligned Controls)
Provider maintains an information security program designed to align with recognized industry frameworks, including SOC 2-aligned controls.
If Provider has a SOC 2 report available for distribution, Provider will make it available to Customer under NDA upon request.
4. Core Security Controls (Summary)
Provider's program includes controls such as:
4.0 Production Architecture Summary
As of the Last Updated date, Provider's current production product stack uses AWS ECS Fargate application hosting behind an AWS Application Load Balancer with TLS, AWS RDS/PostgreSQL and RDS Proxy for production databases, AWS ElastiCache for Valkey for shared cache, AWS S3 with AWS KMS for object storage and encryption controls, AWS Secrets Manager for runtime secrets, AWS CloudWatch for logs and alarms, AWS EventBridge/SQS for scheduled operational workflows, and AWS Lambda/API Gateway for the dedicated PDF generation service.
Authentication is implemented inside the application using the self-hosted Better Auth framework backed by Provider-controlled database tables. Better Auth is a software framework, not a separate hosted auth subprocessor.
Customer-configured integrations may route data to listed subprocessors such as Mailgun, Twilio, Google APIs, Juspay Hyperswitch, Stripe, OpenAI, and browser/OS push service providers only when the relevant feature is enabled/configured.
4.1 Access Controls
- role-based access control (RBAC) and least privilege;
- MFA for administrative and privileged access systems (where applicable);
- periodic privileged access reviews.
4.2 Encryption
- TLS encryption in transit;
- encryption at rest for applicable data stores and object storage using managed key services and key-management controls;
- SSE-KMS for applicable AWS S3 object storage, including file/PDF/audit-storage flows where configured;
- encrypted or hashed application fields for sensitive identifiers, credentials, tokens, and user/customer payloads where applicable;
- authorization checks enforced prior to decryption for sensitive data where applicable.
4.3 Logging & Monitoring
- audit logging for key application actions;
- restricted access to logs;
- security monitoring and alerting;
- log and audit metadata practices designed to avoid recording raw PHI/PII values where field-level metadata is sufficient.
4.4 Change Management and Testing
- controlled change management with tracking and review; and
- pre-production validation/testing practices designed to reduce deployment risk.
4.5 Incident Response
Provider maintains documented incident response procedures for investigation and mitigation. Notification obligations are governed by the Incident Response & Notification Policy and the Agreement, and by the DPA/BAA where applicable.
4.6 Subprocessor Governance
Provider uses subprocessors under written agreements and appropriate safeguards. Provider's current subprocessor list is available on the Subprocessor List page and identifies core infrastructure, communications, payment, browser push, Google, and AI subprocessors by feature category.
5. Backups and Disaster Recovery (Production)
Provider maintains backup and recovery procedures for Production designed to support restoration of the Platform and Customer Data following certain service interruptions.
Backup frequency, retention periods, and recovery practices may be updated consistent with Provider policies. Recovery objectives, if any, are targets only and not guarantees, and do not modify the SLA.
6. Customer Security Responsibilities (Recommended)
Customer is responsible for: (a) enforcing MFA for Platform users, especially administrators; (b) configuring roles/permissions consistent with least privilege and minimum necessary; (c) restricting or prohibiting PHI transmission over SMS or email unless appropriate consents and safeguards are in place; (d) securing API integrations and avoiding PHI in outbound webhooks unless required and appropriately protected; and (e) ensuring Customer devices and networks meet Customer regulatory requirements.
7. Security Documentation Availability
Upon request and under NDA, Provider may provide additional security documentation consistent with Provider disclosure practices.
8. Changes to Security Controls
Provider may update security controls over time to maintain or improve security, provided such updates do not materially reduce the overall security posture of the Subscription Services.
9. Contact
Security questions: support@tyria.app