Security and privacy
An application for life insurance asks about someone's health. That single fact sets the requirements for this entire program, so it is worth being specific about what is in place and what is not.
Where the program stands
An honest position is more useful to a compliance officer than a badge, so here is ours.
Solved Insurance is building a product that will handle applicant health information. A simplified issue life application is, in substance, a set of health questions, and the answers are the most sensitive thing in the system. Everything on this page follows from that.
We operate a documented security and HIPAA program with administrative, physical, and technical safeguards, and formal audit readiness work is underway. We do not hold a completed SOC 2 report or a third-party HIPAA attestation today, there is no named auditor and no certificate, and we are not going to imply one exists. This page describes the controls in place and the program that governs them.
One thing is worth saying before anything else. The waitlist on this site collects an email address, an interest, and a state. It collects no health information at all. There is no application here yet, so there is nothing else to protect on this site today.
Solved Insurance products are in development and pending state approval. Nothing on this site is an offer of insurance and no coverage can be purchased yet, so the controls described for an application describe a program being built rather than one processing applicants today. Join the waitlist to hear when coverage opens in your state.
Security controls
Six control families, each shaped by the fact that the data is regulated rather than merely sensitive.
Encryption in transit and at rest
TLS for every connection, including partner interfaces, with plain HTTP refused rather than redirected into the application. Applicant records, health answers, decisions, and signed documents are encrypted at rest with strong symmetric encryption, and keys are managed centrally and rotated on a schedule rather than living in application configuration.
Access control and least privilege
Roles grant the minimum needed to do the job and nothing beyond it, and access to applicant health information is separated from access to general business systems. Administrative access is limited, individually attributed, and reviewed. Nobody gets standing access to a category of data because it was convenient once.
Minimum necessary by default
The application being designed asks the next question that would actually change the outcome and stops when nothing remaining would. Health information that was never collected does not have to be secured, retained, or disposed of, which makes minimization a security control rather than a courtesy.
Logging and attribution
Access to an applicant record, a health answer, a decision, or a signed document is logged with who did it and when, and the log is retained at least as long as the records it describes. A trail that outlives nothing is not a trail.
Credential handling
Partner tokens are scoped to one account and one integration, issued per integration so revoking one does not break the others, shown once at creation, and stored hashed. Rotation issues a new credential alongside the old one so a cutover is not an outage. Webhook deliveries are signed and timestamped so a receiver can verify origin and reject replays.
United States data residency
Applicant records, health answers, and signed documents are held in United States data centers with encrypted backups, and vendors that would store or process that data are reviewed against that requirement before they are used.
Health answers on an application
The lifecycle of the most sensitive thing the product will hold, from why it is asked to when it is gone.
| Why it is collected | Underwriting a life policy requires health information. A simplified issue application asks health questions instead of ordering a paramedical exam, so the answers are most of what the insurer has to reason about. |
|---|---|
| How it is collected | Through a guided application whose questions adapt to the answers already given, rather than a fixed form that asks everybody everything. The applicant sees the authorization for what is being checked as part of the application, not buried elsewhere. |
| How much is collected | The minimum that changes the outcome. When no remaining question would alter the decision, the flow stops asking. Identifiers needed for a submission are collected because a submission requires them, and masked in interfaces and exports where the full value is not needed. |
| Who can see it | The people who need it to work the case: the licensed agent attached to it, the internal roles whose job requires it, and nobody else by default. Access is logged with attribution. |
| How long it is kept | For the period the applicable state and carrier requirements demand for the product and the state of sale, configured per product and per state rather than set to one global default, then aged out on schedule. |
| What is never asked | On the waitlist, everything. The waitlist collects an email address, an interest, and a state. It does not ask for health information, a Social Security number, a date of birth, or a payment method. |
No underwriting rule, threshold, or knockout condition is published anywhere on this site, on purpose. Why that is
The HIPAA program and business associate agreements
What the program covers, and the two sentences a careful reader is looking for.
The program
Administrative, physical, and technical safeguards for protected health information, with named internal ownership, documented policies, workforce training, a risk assessment process, and a breach notification process. Minimization is built into the application design rather than added as a policy statement.
- Policies are written and owned internally rather than adopted from a template and left unread.
- Workforce training covers handling, reporting, and the fact that raising a concern is supposed to be cheap.
- Risk assessment is periodic and drives control changes rather than filling a binder.
- Formal audit readiness work is underway ahead of a product being approved and sold.
Business associate agreements
We intend to operate under written business associate agreements where HIPAA requires them, and that review is part of onboarding any partner or vendor who would handle protected health information on our behalf.
- We do not claim an agreement is already executed with any named party, because saying so would be a specific factual claim about somebody else.
- A vendor that would process protected health information without an appropriate agreement in place does not get used for that purpose.
- There is no completed SOC 2 report, no third-party HIPAA attestation, no named auditor, and no certificate today.
- If your organization needs to see terms before a conversation, email contact@solved.insure and ask.
State insurance and privacy law
Four bodies of rules apply at once, and the program treats them as one operating requirement rather than four projects.
- State insurance data security law. Several states require licensees to maintain a written information security program, perform risk assessments, oversee third-party service providers, and notify the state insurance department of a cybersecurity event. The program is built to those obligations rather than to a generic checklist.
- State insurance privacy rules. Notice, consent, and limits on disclosure of nonpublic personal information, including health information, are handled per state of sale rather than to one national default.
- Consumer health data laws. A growing set of state laws treats consumer health data as its own category, with separate consent, disclosure, and deletion requirements. That is a reason the waitlist deliberately collects no health information at all.
- Comprehensive state privacy laws. Access, correction, deletion, and opt-out rights vary by state. Where a state law gives a consumer a right, that right applies regardless of what a web page says.
None of this is legal advice, and it does not replace your own organization’s compliance program. It describes what we do so your compliance officer can see where the line sits.
Retention
Two obligations pull in opposite directions: keep records long enough for a state or a carrier, and do not keep health information longer than there is a reason to. Windows are configured rather than assumed.
| Waitlist records | Held while you are on the list and removed when you leave it. An unsubscribe request removes the address; a suppression record that you asked not to be contacted is kept, because that record is what honors the request. |
|---|---|
| Application and health answers | Retained for the period the applicable state and carrier requirements demand for the product and the state of sale, then aged out automatically once the window closes. |
| Underwriting decisions and factors | Retained so a past decision can be reconstructed against the rule set that produced it, because a decision nobody can account for later is not defensible. |
| Signed documents | Retained with the case for the recordkeeping period that applies to the product, alongside the delivery method, consent text, and completion evidence. |
| Access logs | Retained at least as long as the records they describe. |
| Legal hold | A record under review, dispute, or legal hold is kept past its window deliberately, with the reason recorded, rather than silently. |
Retention is set to the longest applicable requirement for the product and the state of sale, not to one convenient global default, and aging runs on a schedule so nobody has to remember to clean up a book of business.
Vendors, subprocessors, and credentials
The product will depend on other services. The ones that touch regulated data are reviewed rather than simply chosen.
Vendor and subprocessor review
Any vendor that would store, transmit, or process applicant data is reviewed before it is used and re-reviewed on a cycle.
- Review covers data residency, encryption, access control, breach notification terms, and whether a business associate agreement is required.
- A vendor that would process protected health information without an appropriate agreement in place is not used for that purpose.
- The subprocessor list is maintained internally and shared with a partner during a security review on request.
- Card payments, when there are premiums to collect, are handled by a payment processor rather than stored on our systems.
Secure credential handling
Access is credentialed per integration, so revoking one does not break the others, and nothing is self-provisioned.
- Tokens are scoped to one account and one integration, shown once at creation, and stored hashed rather than recoverable.
- Rotation issues a new credential alongside the old one so a cutover does not require downtime, then revokes the old one.
- A token inherits the permissions of the account it belongs to and cannot see more than its owner.
- Webhook deliveries are signed and timestamped so a receiver can verify origin and reject replays. See the conventions.
Incident response and breach notification
A documented process, run the same way every time, so the first hour is not spent deciding who does what.
-
Detect and declare
Anyone inside the company, and any partner or researcher outside it, can raise an incident. Raising one is deliberately cheap, because the expensive failure is a report nobody escalated. Declaring an incident assigns an owner immediately.
-
Contain
Stop the exposure before explaining it. Credentials are revoked, access is cut, and affected components are isolated. Containment actions are recorded as they happen so the timeline is not reconstructed from memory afterward.
-
Assess scope and data involved
Determine which records were reachable, which were actually accessed, whether health information or identifiers were involved, and who is affected. Access logs are the primary evidence, which is one reason they cover reads and exports rather than only writes.
-
Notify
Affected people and organizations are notified without unreasonable delay, with what happened, what data was involved, what we have done, and what they should do. Where an incident is a reportable breach of protected health information, notification follows the HIPAA breach notification requirements. State insurance data security laws and state breach notification laws carry their own timelines and their own recipients, including notice to a state insurance department, and those apply on top.
-
Remediate and write it up
Fix the cause rather than the symptom, then produce a post-incident review with the timeline, the root cause, and the control changes that follow from it. Anything that affects what is publicly running also appears on the status page.
Security contact and responsible disclosure
One address, read by people who can act on what you send.
Report a suspected vulnerability, a data handling concern, or a security question to contact@solved.insure with "security" in the subject line, or call +1 (866) 415-6192 if it is urgent. Include enough detail to reproduce the issue, the time you observed it, and how you would like to be credited if you want to be. We acknowledge reports, keep you updated while we work the issue, and tell you when it is fixed.
We ask researchers to test only against their own accounts and their own data, to avoid accessing, modifying, retaining, or exfiltrating anyone else’s records, to avoid denial of service and social engineering against our staff, and to give us a reasonable window to remediate before publishing. We will not pursue a researcher who follows those terms in good faith. There is no paid bounty program today, and we would rather say so than let you assume there is one.
For a security review, a questionnaire, or a conversation about handling health information as part of a partner integration, start at contact and say what you need. For what is actually running today, the status page is the public record.
FAQs
Security and privacy questions
Are you SOC 2 certified or HIPAA certified?
No, and we will not imply otherwise. Solved Insurance products are in development and pending state approval. We operate a documented security and HIPAA program with administrative, physical, and technical safeguards, and formal audit readiness work is underway. There is no completed SOC 2 report, no third-party HIPAA attestation, no named auditor, and no certificate to send you today. When that changes we will say so plainly, with the scope and the period covered.
Will you sign a business associate agreement?
We intend to operate under written business associate agreements where HIPAA requires them, and that review is part of onboarding a partner or a vendor who would handle protected health information. We are not going to claim an agreement is already executed with any particular party. If your organization needs to see terms before a conversation, email contact@solved.insure and ask.
What does the waitlist actually collect?
An email address, what you are interested in, and your state. Nothing else. There is no application on this site, so there is no health information, no Social Security number, and no payment data anywhere in it. That is unusual for an insurance site, which is exactly why it is worth stating plainly.
Do you sell or share my information?
We do not sell or rent the waitlist. Information is shared with service providers who need it to operate the site and send the email, under contract and limited to that purpose, and with a licensed agent or a carrier where that is what processing an application requires once there is an application to process.
Where is data stored?
In United States data centers, with encrypted backups. Applicant records, health answers, and signed documents are not moved outside the United States, and vendors that would store or process them are reviewed against that requirement before they are used.
How do I report a vulnerability?
Email contact@solved.insure with "security" in the subject line and enough detail to reproduce the issue. We acknowledge reports, keep you updated while we work them, and tell you when the issue is fixed. Please test only against your own data, and give us a reasonable window to remediate before publishing.
Do you use health information to train models?
Health information collected on an application exists to produce a decision for that applicant and to evidence that decision afterward. Using an individual's health answers as general training data is not what the comparative underwriting method does; it reasons about a case against encoded product rules, which is also why the same case reproduces the same decision and a past case can be reconstructed.
How do I ask what you hold about me?
Email contact@solved.insure. You can ask what we hold, ask us to correct it, and ask us to delete it, subject to any record we are required to keep. State privacy law varies and several states give consumers specific rights, including rights over consumer health data. Where a state law gives you a right, you have it regardless of what a web page says.
Something else? Contact us
Need to review this with a compliance officer?
Tell us what your organization has to document and we will walk through the controls, the retention model, and the gaps with you.