Data security

Draft for legal review. This document is a draft prepared for review by qualified legal counsel and our security team before publication. It is not legal advice and does not state any certification or compliance as established fact. Bracketed items marked [TO CONFIRM] are placeholders for facts that the team must confirm, including hosting providers, specific ciphers, and any certifications. We do not claim certifications we have not earned.

Last updated: [TO CONFIRM]

1. Our security commitment

Security is not an add-on at Ēnel. It is built into how the platform is designed. We hold identity and health data apart, we link them only by a random code, and we bind ourselves to the five prohibitions in Section 14. This policy describes the controls we use and intend to use to protect your data. It works alongside the Privacy Policy and Terms of Use.

2. The two-database architecture

We keep your data in two separate databases. One holds your account: who you are, your consent record and your daily logs. The other holds your health data: the health records you import, voice measures and coded research data. The health database holds no names, email addresses or account details.

Keeping the two apart is a deliberate containment boundary. The health database on its own does not show who any record belongs to.

3. Coded health data

The only link between the two databases is a random code.

• Each member’s health data is filed under a code made at random. It is not built from your name, email address or any other detail, so it cannot be recreated from them.
• The list that matches each code to an account stays on the account side. It is never stored with the health data.
• As a result, a record in the health database cannot be traced back to a person through that database.

This lets us study coded health data without the people who study it seeing who it belongs to. Deleting your account or your data also removes your health data and research contributions, as described in the Privacy Policy.

4. Encryption in transit and at rest

• In transit. We encrypt data in transit using current, industry-standard Transport Layer Security (TLS), targeting TLS 1.2 or higher. [TO CONFIRM: minimum TLS version and cipher suites enforced.]
• At rest. We encrypt data at rest using strong, industry-standard algorithms, with AES-256 as the intended standard. [TO CONFIRM: at-rest encryption implementation and scope across data stores and backups.]
• Our own encryption. On top of the storage provider’s encryption, the app adds its own. Health records, files, voice recordings, videos and connected-device sign-ins each have their own keys, and each member’s health data has a key of its own.
• Key management. Encryption keys are kept apart from the data they protect. They are never stored in our code or our databases, and access to them is restricted.

The specific ciphers above are stated as standard or intended and must be confirmed against the production configuration before publication.

5. Access control

We follow the principle of least privilege: people and systems get only the access they need, for only as long as they need it.

• Role-based access control (RBAC). Access is granted by role, scoped to the minimum required.
• Multi-factor authentication (MFA). MFA is required for administrative and privileged access. [TO CONFIRM: MFA enforcement scope.]
• Audit logging. Access to sensitive systems and data is logged, and logs are retained and reviewed.
• Access reviews. Access rights are reviewed periodically and revoked promptly when no longer needed, including on role change or departure.

6. Infrastructure and hosting

The Services run on established cloud infrastructure with strong physical and network security operated by our hosting provider. [TO CONFIRM: hosting provider(s), regions, and data residency.] We use network controls such as firewalls, segmentation, and restricted administrative access to limit exposure. [TO CONFIRM: network architecture specifics.]

7. Sub-processors and vendor management

We use a limited set of vendors to operate the Services, such as hosting, security, communications, analytics, and, if paid tiers launch, payment processing. We manage them as follows:

• We assess a vendor’s security before onboarding.
• We sign data processing agreements (DPAs) that require vendors to protect data, restrict its use to our instructions, and support breach notification.
• We limit the data each vendor receives to what its function requires.

A list of sub-processor categories is maintained, and a current list of sub-processors is available on request. [TO CONFIRM: where the sub-processor list is published and how changes are communicated.]

8. Secure software development

Security is part of how we build.

• Code review. Changes are peer-reviewed before they ship.
• Dependency scanning. We scan dependencies for known vulnerabilities and update them.
• Secrets scanning. We scan for committed secrets and rotate any that are exposed.
• Separation of environments. Development, staging, and production are separated, and production data is not used casually in lower environments.
• Change management. Changes are tracked and tested before release. [TO CONFIRM: CI/CD and testing specifics.]

9. Monitoring, logging, and threat detection

We monitor the Services for security and reliability. We collect and retain logs from key systems, alert on suspicious activity, and investigate anomalies. [TO CONFIRM: monitoring and detection tooling and retention periods.]

10. Vulnerability management and penetration testing

• Patching. We track and remediate vulnerabilities on a risk-based schedule, prioritizing the most serious first. [TO CONFIRM: remediation timelines by severity.]
• Testing. We intend to conduct periodic security testing, including penetration testing by qualified parties. [TO CONFIRM: penetration testing cadence and provider.]
• Reports from researchers. We welcome good-faith reports from security researchers. See Section 16.

11. Data minimization and retention

We collect only what the Services need, and we keep it only as long as needed, then delete or de-identify it, as described in the Privacy Policy. The two-database model and the random code mean that the health side holds no names or contact details by design, which limits what a compromise could expose. [TO CONFIRM: retention periods by data category.]

12. Incident response and breach notification

We maintain an incident response process to detect, contain, investigate, and recover from security incidents, and to notify affected parties and regulators as required.

• GDPR and UK GDPR. Where a personal data breach is likely to result in a risk to people’s rights and freedoms, we will notify the relevant supervisory authority without undue delay and, where feasible, within 72 hours of becoming aware of it, and we will notify affected individuals where the breach is likely to result in a high risk to them.
• US state laws. We will notify affected individuals and authorities within the timeframes required by applicable US state breach-notification laws.
• Records. We document incidents and our response, including any law enforcement disclosure made under a valid legal order, as stated in Section 14.

[TO CONFIRM: incident response plan owner, escalation path, and notification templates.]

13. Backups, business continuity, and disaster recovery

We maintain backups to protect against data loss, and we have business continuity and disaster recovery practices intended to restore the Services after a disruption. Backups are protected with the same care as production data, including encryption. Deletion requests are applied to backups on a defined schedule. [TO CONFIRM: backup frequency, recovery objectives (RPO and RTO), and backup deletion schedule.]

14. The five prohibitions as a data-handling commitment

These prohibitions are security commitments as much as privacy ones. They govern every internal and external request for data:

1. We never sell your personal data.
2. We never share it with insurers.
3. We never share it with employers.
4. We never share it with law enforcement, except under a valid legal order, which we record.
5. We never let a brand buy, place, or edit a verdict. The evidence is uninfluenced.

We also do not attempt to re-identify de-identified evidence, and our access controls are designed to prevent re-identification.

15. Personnel security

• Least access. Personnel get only the access their role requires (Section 5).
• Confidentiality. Personnel are bound by confidentiality obligations.
• Training. Personnel receive security and privacy training appropriate to their role. [TO CONFIRM: training cadence.]
• Onboarding and offboarding. Access is provisioned on a least-privilege basis and revoked promptly on departure or role change.

16. Compliance posture

We design the platform to meet the requirements of the privacy and consumer health data laws described in the Privacy Policy, including GDPR, UK GDPR, the CCPA and CPRA, the Washington My Health My Data Act, the Nevada consumer health data law (SB 370), and the Connecticut Data Privacy Act.

We do not claim any certification we have not earned. We do not state that we are “HIPAA compliant” or “SOC 2 certified” as established fact. Where we pursue a framework or certification, we will describe it as intended or targeted until it is achieved and independently confirmed. [TO CONFIRM: current and targeted certifications and audit status, for example SOC 2, ISO 27001, with dates.]

17. How to report a vulnerability

If you believe you have found a security vulnerability, please tell us so we can fix it. Contact our security team at [TO CONFIRM: security@ contact]. Please give enough detail to reproduce the issue, and please do not access, modify, or delete data that is not yours, or disrupt the Services, while testing. We will acknowledge good-faith reports and work to resolve confirmed issues. [TO CONFIRM: vulnerability disclosure policy, safe-harbor language, and response targets.]

For other security questions, contact us at [TO CONFIRM: security@ contact] or through our contact page.