Security
Insurance data is sensitive by default.
We built Evrment knowing what an insurance agency actually holds: health, identity, financial and policy information, and private communications. Security cannot be an add-on when that is the payload. Here is what protects it today, and what is still required before general availability.
Security at a glance
Evrment is in daily use by its founding agency today. The hosted service for other agencies at evrment.ai is being prepared now, and several controls are required before it opens. We would rather show you that list than round it up.
We will not put a badge on this page before an independent party has signed the report behind it.
- HTTPS / TLSIn place
- Encryption at restIn place
- AES-256-GCM credential vaultIn place
- Workspace and role isolationIn progress
- Audit trailIn place
- DNC and communication controlsIn place
- Recording consentIn place
- AI workspace boundariesIn place
| Control | Status | How | Evidence |
|---|---|---|---|
| Encryption in transit | Implemented | evrment.com and evrment.ai are served only over HTTPS (TLS). | The certificate presented by both production domains. |
| Encryption at rest | Implemented | The workspace database runs on managed Supabase Postgres, which encrypts data and its backups at rest. | The Postgres datasource and the Supabase project the application connects to. |
| Vault credential encryption | Implemented | Each stored credential is sealed with AES-256-GCM under its own data key, and every data key is sealed under a separate master key. | The enc:v1 envelope format; with no master key configured the vault refuses to store or reveal. |
| Masked credentials with logged reveals | Implemented | Passwords are masked by default and each reveal writes an audit entry naming who revealed it and when. | Reveal entries in the workspace audit log. |
| Individual accounts | Implemented | Every person signs in with their own account through Supabase Auth; there are no shared logins.You: Remove members who leave your agency. | One auth identity per workspace member. |
| Role-based access control | Implemented | Owner, manager and agent roles are checked on the server before sensitive actions run.You: Assign the least role each person needs. | Server actions that reject a request with a forbidden error when the role does not match. |
| Tenant isolation | In progress | Every server action and API route requires membership of the workspace before it runs; per-query separation for many agencies on one database is being completed before other agencies are onboarded. | The workspace membership check on every server path; the per-query filter is not yet on every query. |
| Row-level security, deny by default | Implemented | Row-level security is enabled on every database table, so a client key cannot read rows without an explicit policy. | The migration that enables row-level security on every public table. |
| Marketing site holds no customer data | Implemented | evrment.com has no sign-in, no database client and no customer data; waitlist entries pass server-to-server over a signed request. | The signed waitlist proxy is the only path from the site to evrment.ai. |
| Audit log on every change | Implemented | Each change records the actor type, module, action, subject and a before-and-after diff. | The System Log, filterable and exportable to CSV. |
| Internal do-not-call list | Implemented | Your agency's own do-not-call list, enforced on every outbound call and text path and at import; suppression survives lead deletion and is tracked by phone and by email. It is not a lookup against the national registry.You: Registering with and honouring the National Do Not Call Registry and state lists remains your obligation; Evrment does not check numbers against them. | Blocked sends and suppressed import rows, recorded in the audit log. |
| Quiet hours for automation | Implemented | Automated sends hold to 9am–8pm in the lead's local time, Monday to Saturday. | The quiet-hours status computed for each lead's state before a send. |
| Recording off by default | Implemented | Calls are recorded only when auto-record is switched on, and a disclosure plays first.You: Decide whether to record, and follow your states' consent rules. | The consent-gated recording options on every outbound call. |
| Signed telephony webhooks | Implemented | Inbound telephony webhooks are rejected unless the provider's request signature validates. | Failed signature checks return an error before any processing. |
| AI inside the workspace boundary | Implemented | AI features run on the server behind the same workspace check, and today use a deterministic engine that sends no workspace data to an outside model. | The engine module has no model-provider calls. |
| Self-serve export of your full workspace | Planned | One export of every record in your workspace; the audit log and contacts already export to CSV. | Available when the hosted service opens to other agencies. |
| Automated daily backups with tested restores | Planned | Scheduled backups retained for a limited window, with restores tested on a schedule rather than assumed. | A restore log, once the schedule is running. |
| Independent penetration / security assessment | Planned | An outside party tests the application and infrastructure. | The assessor's report, when it exists. |
| Sensitive insurance data support | Required before GA | Health, identity, financial, policy and communication data held in designated protected fields and workflows, never in free-text areas.You: Keep sensitive identifiers, account numbers and detailed health information out of notes, team messages, SMS and email. | Not built yet. Today date of birth and health flags are ordinary structured fields, and no SSN or bank-account field exists. |
| Application-level protection for restricted fields | Required before GA | Field-level encryption, masked display, a deliberate audited reveal and restricted roles for especially sensitive values. | The mechanism exists for vault credentials only; it is not yet applied to customer data fields. |
| Retention and secure deletion rules | Required before GA | Defined retention periods for sensitive records, recordings and messages, with deletion that reaches backups on a known schedule. | No written retention schedule is enforced in the application today. |
| Multi-factor authentication | Required before GA | A second factor at sign-in for every workspace member. | Not enabled today; sign-in is email and password. |
| Automatic session timeout | Required before GA | Idle sessions end automatically after a set period. | Not configured today; sessions refresh while the browser holds them. |
| Sensitive values kept out of logs | In progress | Application logs record error types, not the data being processed; a checked rule that no sensitive value is ever logged is still to be enforced. | Current server logs print error names only, apart from one setup-time console message that must be removed before general availability. |
| Central AI data boundary | Required before GA | One policy layer deciding which provider may receive which categories of data, with redaction, minimum-necessary context and fields that never leave Evrment. | A requirement, not an achievement: no model provider is connected today, so no boundary has been needed yet. |
| HIPAA-ready hosted environment | Required before GA | A hosting and database configuration set up for regulated health data, with the provider agreements in place. | Not started. The current database project has not been configured for regulated health data. |
| BAAs with PHI-handling subprocessors | Required before GA | A business associate agreement with every provider that would carry protected health information. | No agreement is signed today. |
| HIPAA-regulated workflow support | Required before GA | Controls, agreements and procedures that let a customer run workflows where HIPAA applies. Not offered today; Evrment is not a business associate unless separately agreed in writing. | Tracked in the sensitive-data readiness checklist. |
| GLBA and insurance information-security controls | In progress | Safeguards for nonpublic personal information: access control, encryption, audit and a written information-security program.You: Your own obligations under the laws that apply to your agency remain yours. | Several technical safeguards above are in place; the written program, risk assessment and incident procedures are not yet written. |
| Payment card data | Not applicable | Evrment does not store card numbers, CVV, PIN or track data. Card data stays with the payment provider, and Evrment keeps tokens and payment-method references only. | No card-number field exists in the application; payments are not yet connected. |
Sensitive data belongs in protected fields.
Not in arbitrary text boxes. An SSN belongs in a masked, encrypted field with an audited reveal, never in notes. Health details belong in the underwriting data area, never in team chat. Bank details belong in a protected workflow, never in a text message.
Most of this protected domain is still being built, and the statuses say so. Until it ships, sensitive identifiers, account numbers and detailed health information stay out of every unstructured field.
- HealthProtected storage · restricted access · auditable accessMedical history, prescriptions, underwriting answersRequired before GA
- IdentityMasked · encrypted · controlled revealSSN, date of birth, address, licence informationRequired before GA
- FinancialRestricted · encrypted · auditedBank details, commission informationRequired before GA
- PolicyWorkspace-scoped · permissioned · traceableApplications, coverage, beneficiary informationIn progress
- CommunicationsConsent-aware · access-controlled · retention-awareCalls, messages, recordingsRequired before GA
Generic architecture was not designed around the insurance data lifecycle.
Evrment is. Where that is still the design target rather than the product, the row says so.
| Generic architecture | Evrment | Today |
|---|---|---|
| A notes field | A purpose-built protected data domainDesign target; the protected domain has not shipped. | Required before GA |
| One permission model | Field- and workflow-sensitive permissionsRoles are enforced today; field-level permissions are the design target. | Required before GA |
| Activity history | Human, AI and system provenanceEvery change records its actor type, module, action and diff. | In place |
| AI sees it because the user can | AI data access is explicitly governedNo model provider is connected; the governing boundary is a requirement. | Required before GA |
| Compliance documented in a handbook | Compliance controls in the execution pathDo-not-call, quiet hours and recording consent run in code. | In place |
How Evrment protects the business
Data protection
HTTPS everywhere, a database encrypted at rest, and carrier logins sealed with AES-256-GCM envelope encryption.
Where data lives. evrment.com, this site, is a marketing website. It has no sign-in, stores no customer data, and sets no tracking cookies. The contact form is delivered to our inbox and is not stored by the site. When you join the waitlist, the site passes what you entered, over a signed server-to-server request, to Evrment's own database on evrment.ai; your browser never connects to that database, and nothing from it is ever shown back on this site.
evrment.ai is the product. Your workspace data (leads, clients, policies, messages, call records, ledger entries and vault credentials) is stored there. The hosted service is planned to run on a managed cloud database in the United States. The two domains are separate, so nothing about your account can be read or set from the marketing site.
In transit: traffic to evrment.com and evrment.ai is served over HTTPS.
At rest: the hosted database and its backups are encrypted at rest by the database provider (Supabase).
Credential vault. The vault stores carrier portal logins, license details and tool accounts. Passwords are masked by default. Revealing one is a deliberate action, and every reveal is written to the audit log with who revealed it and when.
Implemented: envelope encryption of stored credentials (AES-256-GCM), where each credential is encrypted with its own data key and those keys are protected by a separate master key.
Access & isolation
Individual accounts, roles checked on the server, and AI units confined to your workspace and downline. Multi-agency isolation is in progress.
Implemented: individual accounts for every person, roles that limit what each person can do, and a server-side check that every request comes from a member of the workspace. Atlas and the other AI units operate inside the same boundary.
In progress: tenant isolation for many agencies on one database. Today the service holds a single agency's workspace; per-query separation is being completed before any other agency is onboarded.
Evrment staff access to customer workspaces will be limited to what support requires, and will be recorded.
Audit & accountability
Every human, AI and system action is recorded with its actor, module, action, subject and diff, and exports to CSV.
Every change in a workspace is recorded with the type of actor (a person, an AI employee or the system), the module, the action, the subject and a before-and-after diff. You can filter the log, open any entry, and export it to CSV. Each lead also carries its own activity history.
Compliance guardrails
Your internal do-not-call list on every outbound path, quiet hours for automation, and recording that stays off until you turn it on.
Internal do-not-call list. Your agency's own do-not-call list, enforced on every outbound call and text path and at import; suppression survives lead deletion and is tracked by phone and by email. It is not a lookup against the national registry.
Your obligation. Registering with and honouring the National Do Not Call Registry and state lists remains your obligation; Evrment does not check numbers against them.
Quiet hours. Automated sends hold to 9am–8pm in the lead's local time, Monday to Saturday.
Recording consent. Calls are recorded only when auto-record is switched on, and a disclosure plays first.
Signed telephony webhooks. Inbound telephony webhooks are rejected unless the provider's request signature validates.
Trust & assurance
Backups, the providers we rely on, what we do and do not claim, your data rights, and how to report an issue.
Certifications
Evrment does not hold a SOC 2 report, ISO 27001 certification, or PCI DSS attestation, and is not a HIPAA business associate. We will not describe the product as having any of them until an independent party has confirmed it. An independent security assessment is planned.
Current
- Independent penetration / security assessment
- Planned
Roadmap
- SOC 2 Type II
- Roadmap
- ISO/IEC 27001
- Under evaluation
Not currently claimed
- HIPAA business associate program
- Not offered today. HIPAA-regulated workflow support is required before general availability.
Not applicable
- PCI DSS
- Not applicable — card data is tokenized outside Evrment. Evrment never stores card numbers, CVV, PIN or track data.
HIPAA is not the whole story, and it applies only to covered entities and their business associates. Life insurers are generally not covered entities merely because they handle medical information, but the data is still highly sensitive. Depending on the agency and the states it works in, the rules that may apply include:
- Gramm-Leach-Bliley financial privacy rules for nonpublic personal information
- FTC and state financial-data safeguards requirements
- State insurance privacy requirements
- The NAIC Insurance Data Security Model Law in adopting states: an information-security program, and cybersecurity event investigation and notification duties
- State breach-notification laws and state consumer privacy laws
- Insurance-department cybersecurity rules
- HIPAA, where a workflow is genuinely regulated by it
No single statute applies to every customer. Evrment is designed to support regulated insurance workflows; each agency's own obligations remain its own. HIPAA-regulated workflow support is required before general availability.
Evrment does not store raw payment card numbers, and never stores CVV, PIN or track data. Card data stays with a PCI-compliant payment provider, and Evrment keeps tokens and payment-method references only. Any future need for cardholder data would be a deliberate project before a feature ships. Evrment is designed to handle health, identity, insurance and financial data without becoming a raw card vault.
Planned: automated daily backups of the hosted database, retained for a limited window, with restores tested on a schedule rather than assumed to work.
Evrment relies on a small number of service providers to run. They are listed here by category. A named list will be published before the hosted service opens, and customers will be notified of changes.
- Hosting and database. Runs the application and stores workspace data.
- Authentication. Handles sign-in and sessions on evrment.ai.
- Telephony and messaging. Carries calls and texts, and stores call recordings when recording is on.
- Email delivery. Sends account email, and campaign email once that feature ships.
- Payments. Processes subscription payments. Evrment never stores card numbers.
- AI model providers. Powers AI features. Providers are not permitted to train on your data.
- Error monitoring. Records application errors so they can be fixed.
Your data belongs to you. The audit log can be exported to CSV today, and self-serve export of your full workspace is planned for the hosted service. If you cancel, your workspace remains available for export for 30 days and is then deleted.
For requests about your data, email support@evrment.com. The details are in our Privacy Policy and Data Processing Addendum.
If you believe you have found a security issue in evrment.com or evrment.ai, email support@evrment.com with the subject line “Security report”. Include enough detail for us to reproduce it. Please do not access data that is not yours, degrade the service, or disclose the issue publicly before we have had a reasonable chance to fix it. We will not pursue good-faith research that follows these guidelines.
Governance is a scale problem before it is a security problem.
One producer governs their own work by remembering. An agency with a hundred producers has more people, more records, more interactions and more permissions to govern than any one person can hold, and the exposure grows with each of them. That is why role-based access, consent records, the audit trail and the autonomy ladder are part of the product rather than a policy document — and why every control on this page states what is actually in place today, and what is not.
Be there when Evrment goes live.
Join the waitlist for early access, launch updates and founding-user benefits. No spam, and you can leave any time.
Want to see it early? Request a private preview