# Casewave — Compliance (Partner Portal) > Reviewed against production 2026-10-28 · frame: GLBA Safeguards Rule (16 CFR 314) / NAIC MDL-668 · SOC 2 Type I targeted H1 2027 Source: https://partner.casewave.life/compliance ## Compliance isn’t a feature. It’s the architecture. Casewave is a comprehensive life insurance practice management tool. Our focus is on enhancing independent agents’ ability to perform administrative work and service their new business and existing books across carriers and various products. We recognize that this work touches the most sensitive personal information that belongs to customers, and we built our platform with compliance in our DNA. ### What reaches our database - Social Security number: Never stored - Bank and routing numbers: Never stored - Government ID: Never stored - Health answers: Never stored - Date of birth: Encrypted - Policy numbers: Encrypted - Notes and intake answers: Encrypted - Servicing answers: Encrypted - Name, address and policy facts: Readable ## Our safeguards ### Safeguard I: Route, don’t hold Social Security numbers, bank and routing numbers, government IDs and health answers never touch our database. No column for any of these exists in the schema. ### Safeguard II: Lock what we keep Dates of birth, policy numbers, notes and every answer a workflow collects are encrypted per account, per purpose. The application holds no decrypt permission. Only a separate key service can release a key, and every release is checked and logged. ### Safeguard III: Dispose when done The answers a client gives for a form are thrown away the moment the signed document completes. Background records run on fixed clocks. Deleting an account destroys its keys. ## Safeguard I: Route, don’t hold ### Never stored Social Security numbers, bank and routing numbers, government IDs, health answers. No column exists. Typed into the signed document and sent to the carrier. ### Encrypted Date of birth, policy numbers, agent notes, intake answers and every servicing answer a workflow collects. AES-256-GCM per account, per purpose. No plaintext twin. ### Readable A client’s name, how to reach them, their address, occupation and birth month, the policy facts on their carrier statement, and messages exchanged in the app. Readable, so the service knows who it is writing to. ### Enforced by - The schema: There is no field in our database to hold these values, so there is nothing to leak. - The form compiler: The form compiler refuses any field from the sensitive tier, so it can only be filled inside the signed document. - The build pipeline: Our build fails if source code or seed data contains something shaped like a Social Security number. ### Signed documents, kept 7 days. Then shredded. The signed form belongs with the carrier and the agent. Every document is signed through BoldSign, a SOC 2 Type II e-signature provider, which sends the completed document and its certificate straight to the agent. We keep the signed document for 7 days, then shred it. After that, Casewave holds only the status of the request (sent, signed, completed) and the document’s reference. What we keep: - Blank carrier forms - Agent-uploaded blank overrides - Request status: sent, signed, completed - The document’s reference - The signed document, for 7 days What we never keep: - A signed document after 7 days - Any field typed into the signed form ## Safeguard II: Lock what we keep ### Encrypted per account, per purpose. No plaintext copy. Some data we do have to hold: a client’s date of birth to verify them, a policy number to service the right contract. Each is encrypted under a key that belongs to one agent’s account and one kind of data. There is no unencrypted version in a second column, a backup table or a log. Agent notes, intake answers and every servicing answer a workflow collects get the same treatment, and a new collection field is encrypted by default. If the database were copied, those fields are unreadable. ### Our own application cannot unlock client data by itself. The usual weak point in encryption is that the software holding the data also holds the key. We separated them. The application can encrypt new data, but it holds no permission to decrypt; to read an encrypted field it has to ask a separate key service. Someone who takes over our application does not get a master key; they get a rate-limited, audited gate. - Session: Tied to a real, logged-in session for that account - Throttle: Limits how often it will answer, per account - Alarm: Alarms on unusual volume, denials or mismatches - Record: Writes a pii.decrypt audit row for every answer ### Threat models and remediations - Database copied (Stolen backup or a breach at the host): Finds ciphertext for dates of birth, policy numbers, notes and collected answers, and no Social Security, bank or ID numbers at all. Names, contact details, addresses, birth months, policy facts and in-app messages are readable. - Application compromised (An exploited vulnerability): The application holds no decrypt permission. Every decrypt goes through the separate key service: session-checked, rate-limited and logged. - Cloud credentials stolen (Phished or leaked AWS administrator access): Our named administrators carry an explicit deny on decrypt, and every key operation lands in a tamper-evident trail. - Support access (Casewave staff helping an agent): Only inside a session the agent has consented to: time-boxed, a recent second factor required, rate-limited per person, and every row it touches stamped with the session. ### Every agent’s book is fenced by the database. Each agent’s book of business is walled off at the database layer. A query that forgets to say which account it is working for does not return everyone’s data; it fails. Functions inside the database refuse to act for any account other than the one the request is scoped to. We test this in our build pipeline on every change. Row-level security on 69 of 69 tables, fail-closed. The tenant-isolation gate runs in CI against a real Postgres, on every change. ## Safeguard III: Dispose when done ### Deletion destroys the key. The ciphertext becomes noise. Deleting an account does not just remove rows that might linger in backups. It destroys the account’s encryption keys, so every encrypted field written under them becomes unreadable. Readable details are swept, and the deletion itself is recorded. ### What a form collects is thrown away once it is signed. The answers a client gives for a form are discarded the moment the signed document completes. Everything that piles up in the background runs on a fixed clock. - Delivered background jobs: Purged daily after 30 days - Birthday-email claims: Purged after 2 days - Unsubscribe tokens: Purged after 400 days - The encrypted intake answers are discarded when the signing envelope completes - The signed document goes to the agent and the carrier, and is deleted 7 days after completion - A signing request that is never completed expires after 30 days ## Monitoring, without the personal data. When something breaks we need to know what happened, not who it happened to. Our logs carry identifiers only: never names, message bodies or the values someone typed. A scrubber masks anything shaped like personal data before a line is written. What a log records: - What went wrong: The error’s name - Where it happened: Account and workflow identifiers - What state it was in: Status codes, counts and flags What never enters a log: - Names, emails and phone numbers: Masked by shape before anything is written - What anyone typed: No request bodies, chat text or field values - Invitation links: Tokens masked in every log, and never handed to a vendor ## Subprocessors ### Cloudflare — Application runtime, object storage, queues, email sending - Region: US · storage pinned to ENAM - Holds: Request data in memory during processing; blank forms and uploads in private US storage What we configured: - HTTP forced to HTTPS - TLS 1.2 minimum; TLS 1.1 refused - HSTS and DNSSEC - Twenty sanctioned and high-risk countries, and the Tor network, blocked from our API - Requests rate-limited before they reach the database - Database query caching off, so no tenant’s rows are cached beside another’s - Documents in a private bucket with signed URLs - Uploaded PDFs stripped of scripts and active content before they are stored ### Vercel — Web app and client portal hosting - Region: US - Holds: Web requests in transit and short-lived, scrubbed runtime logs; no log drain What we configured: - Sanctioned and high-risk countries denied - Every visitor outside the U.S. challenged - Sign-in form submissions rate-limited - No log drain, by decision ### Neon — Postgres database - Region: US - Holds: The encrypted and readable fields described in Safeguard II What we configured: - Row-level security on every table, fail-closed - The application role cannot bypass it - The application role cannot change the schema - The application role cannot delete encryption keys - US region ### Clerk — Identity and sign-in - Region: US - Holds: Names, emails and phone numbers (for two-factor) of agents and clients What we configured: - Passwordless sign-up - Phone second factor set up at client onboarding - Every session token verified on our servers - Roles read from our database, never from the token - Sessions re-verified independently by the key service ### AWS — Key management only (KMS) and the key service - Region: US · us-east-1 - Holds: Wrapped keys. No personal data transits AWS; only key operations What we configured: - Used for keys only, no client data - One master key per environment - Automatic rotation and deletion protection - The application can encrypt but holds no decrypt permission - Named administrators with enforced MFA and an explicit deny on decrypt - Every key operation logged in a tamper-evident trail - Alarms on unusual key use ### BoldSign — E-signature system of record - Region: US - Holds: Signed documents, including the containment-tier values the client types there What we configured: - Signatures and webhooks verified cryptographically - Signed documents go straight to the agent and carrier - Completed documents deleted after 7 days - Signing requests expire after 30 days ### Anthropic — AI model provider - Region: US - Holds: Conversation content processed to generate responses; column profiles when an agent imports a book What we configured: - Separate API keys per use - Book imports send column profiles, not whole files - Form classification sees blank forms only ### Stripe — Billing, agents only - Region: US - Holds: The agent’s email and billing details; no client data What we configured: - Card details never touch us: hosted checkout and customer portal - Billing is agents-only - Webhook signatures verified ### Apple — Push notifications for the iOS app (APNs) - Region: Global - Holds: Device tokens and fixed notification text only What we configured: - Fixed text such as “You have a new message” - Never message content, names, document titles or policy details ## Frameworks: how rules reach us ### Direct Laws that bind Casewave itself, as a holder of personal data. - FTC Act §5 + state UDAP — Security and privacy statements are advertising; so are marketing numbers. Website accuracy pass done; a content guide lists the claims we do not make. Never present-tense an unshipped control. [Live] - State breach-notification statutes — As data maintainer we notify the data owner, the agent, immediately following discovery. Incident response plan: ≤24 h upstream notice, which clears every state window. [Live] - NY SHIELD Act — Reasonable safeguards for any business holding NY residents’ private information. Met by the WISP’s control set; cited in the WISP. [Live] - MA 201 CMR 17.00 — Direct only if we hold MA name plus SSN, license or financial-account number. Under containment we hold none. Cited in the WISP anyway; the controls exceed it. [Live (by design)] - ESIGN / UETA — Electronic signatures and records require consent. Consent inside the e-signature vendor’s flow; e-records consent language in the terms. [Live] - CAN-SPAM — Header accuracy always applies; servicing email is exempt from opt-out duties. Transactional and relationship email only; relationship emails carry an unsubscribe. [Live] - PCI DSS (SAQ-A, via Stripe) — Contractual, through our payment processor. Hosted checkout and customer portal; card data never touches us. We do not advertise PCI compliance. [Live] - WA My Health My Data Act — Applies if we ever hold consumer health data. Health is containment-tier; never stored. [Live (by design)] ### Flow-down Rules that bind our agents and reach us by contract. - NAIC MDL-668 — Licensees must vet service providers and bind them to safeguards, MFA, encryption and breach notice (§4F). WISP framed against §4; ≤24 h upstream-notice SLA in the agent agreement; the crosswalk is the answer sheet. [Live] - FTC Safeguards Rule, 16 CFR 314 — Binds our agents as financial institutions; reaches us through 314.4(f). We build to the 314.4 element set; under the 314.6 5,000-consumer threshold. [Live] - NY DFS 23 NYCRR Part 500 — NY-licensed producers are covered entities; §500.11 requires a service-provider policy. The Safeguards element mapping doubles as the Part 500 mapping. [Live] ### Voluntary Market credentials buyers ask for. Not laws. - SOC 2 — The attestation IMOs, carriers and acquirers ask for. Control register in place. Type I targeted H1 2027; Type II 6–12 months after. Preparing, not certified. [Roadmap] ### Avoided by design Frames that do not apply, and the design rule that keeps each away. - HIPAA — Not a covered entity or business associate; health data is never stored. Health stays containment-tier; never add a health column. [N/A] - COPPA — We store data about minor beneficiaries, entered by adults; children are never users. Portal accounts are 18+. [N/A] - CCPA and ~19 state privacy laws — Volume and revenue thresholds not met. Build the rights anyway; watch the tripwires. [N/A] - GDPR / UK GDPR — Serves U.S. customers only, stated in the privacy policy. Never serve EU/UK residents without a decision. [N/A] - NACHA — We never store bank account or routing numbers as fields. No bank column, ever. [N/A] - Data-broker laws — We sell no data and process our customers’ clients’ data on their behalf. No de-identified or aggregated data use. Decided 2026-08-18. [N/A] - ISO 27001 — Not pursued; SOC 2 is what this market asks for. — [N/A] ## Element by element ### GLBA Safeguards (16 CFR 314.4) Built to even where 314.6 exempts us, because MDL-668 mirrors it and diligence is written against it. - (a) Qualified Individual: Nicholas Towery, recorded 2026-08-18 [Live] - (b) Written risk assessment: Scenario-based risk assessment with a capability-tiered threat model [Live] - (c)(1) Access controls: Row-level security on all 69 tables, fail-closed; non-owner runtime role; default-deny route policies; the account checked inside database functions [Live] - (c)(2) Data inventory: Tiered data model; column inventory; vendor register [Live] - (c)(3) Encryption in transit and at rest: TLS 1.2 minimum, HSTS, DNSSEC; provider disk encryption; field-level AES-256-GCM per account and per purpose for dates of birth, policy numbers, notes, intake and servicing answers [Live] - (c)(4) Secure development: Architecture decision records; CI gates on every change; SHA-pinned Actions; checksummed build tools [Live] - (c)(6) Disposal: Retention schedule; intake answers discarded at signing; fixed purge clocks; account deletion destroys keys [Live] - (c)(7) Change management: Decision records; CI gates; deploy preflights that refuse a production deploy without real key management [Live] - (c)(8) Monitoring and logging: Append-only audit log; every decrypt audited; multi-region CloudTrail with alarms [Live] - (d) Regular testing: Continuous monitoring: scanners and the tenant-isolation gate on every change; CloudTrail and key-service alarms [Live] - (f) Service-provider oversight: Vendor register with residency; published subprocessor page [Live] - (g) Evaluate and adjust: Written program, reviewed against the live system [Live] - (h) Written incident response plan: IR plan with ≤24 h upstream notice, the NY 30-day cap and the Missouri 4-business-day window [Live] - (j) FTC notification: IR plan commits; field encryption keeps most elements out of “unencrypted” [Live] ### NAIC MDL-668 (§4 and §5–6) Our agents are the licensees; §4F is how these requirements reach us. - §4A Information security program: Written information security program (WISP) [Live] - §4B Objectives: Our safeguards: route, lock, dispose [Live] - §4C Risk assessment: Risk assessment and the posture review against production [Live] - §4D(1) Risk management: The written compliance program, reviewed against production [Live] - §4D(2)(a) Access controls: As 314.4(c)(1) [Live] - §4D(2)(b) Data inventory: As 314.4(c)(2) [Live] - §4D(2)(c) Physical restrictions: No premises; inherited from attested cloud providers [Live (inherited)] - §4D(2)(d) Encryption: TLS 1.2+; field-level encryption per account and per purpose [Live] - §4D(2)(e) Secure development: As 314.4(c)(4) [Live] - §4D(2)(f) Modify as appropriate: Decision records and the written program [Live] - §4D(2)(g) Audit trails: Audit log; every decrypt audited; CloudTrail [Live] - §4D(2)(h) Disposal: Account deletion destroys keys; retention schedule; intake answers discarded at signing [Live] - §4D(2)(i) Data loss prevention: Containment tier never stored; field encryption; logs scrubbed of personal data; signed documents deleted after 7 days [Live] - §4F Third-party service providers: Vendor register; the ≤24 h notice SLA is our §4F term toward agents [Live] - §4G Program adjustments: Written program, reviewed against the live system [Live] - §4H Incident response plan: IR plan with the ≤24 h upstream-notice SLA [Live] - §4I Annual certification: Not a licensee; we furnish the crosswalk and WISP to agents who certify [N/A] - §5–6 Investigation and notification: ≤24 h upstream notice to the agent, inside every state window and the 72 h [Live] ### SOC 2 readiness (Trust Services Criteria) A readiness view, not an attestation. Type I is targeted for H1 2027. - CC1 Control environment: Qualified Individual named; written security program [Live] - CC2 Communication and information: Control register; WISP; decision records; published privacy policy, terms and subprocessor list [Live] - CC3 Risk assessment: Risk assessment; posture review; threat model [Live] - CC4 Monitoring activities: CI gates; scheduled scans; alarms [Live] - CC5 Control activities: The control set in the crosswalk; written policy enforced by hooks and CI [Live] - CC6.1–6.3 Logical access: Row-level security; route policies; server-verified sessions; named AWS identities with MFA [Live] - CC6.4–6.5 Physical access: Inherited from cloud providers [Live (inherited)] - CC6.6 Boundaries / external threats: Country blocking and a non-US challenge at the edge; sign-in rate limits; TLS 1.2+, HSTS, DNSSEC [Live] - CC6.7 Transmission: TLS on every hop [Live] - CC6.8 Malicious software: Dependency floor, secret scanning, SHA-pinned Actions, checksummed build tools, PDF sanitization on upload [Live] - CC7.1 Vulnerability detection: CI scanners; infrastructure scanning [Live] - CC7.2 Anomaly monitoring: CloudTrail alarms; key-service volume and denial alarms [Live] - CC7.3–7.5 Incident response: IR plan with ≤24 h upstream notice to the agent [Live] - CC8.1 Change management: Decision records; CI gates; deploy preflights [Live] - CC9.1 Risk mitigation: KMS destruction controls [Live] - CC9.2 Vendor risk: Vendor register with residency [Live] - C1.1–1.2 Confidentiality: Tier model; containment never stored; field encryption [Live] - P1–P8 Privacy: Privacy policy; minimization by design; deletion on request; no sale [Live] ### CCPA / CPRA rights (built ahead of the threshold) Not triggered today. The CA GLBA exemption is data-level, so non-NPI fields would be in scope past the threshold. - Notice Notice at collection: Privacy policy and client portal terms [Live] - Delete Right to delete: Deletion destroys the account’s keys, sweeps readable details and reaches our identity, billing and e-signature vendors; routed to the agent as controller [Live] - Correct Right to correct: Agents edit client and policy fields; clients update contact details [Live] - Opt out Sale / sharing: No sale, no sharing, no de-identified or aggregated data use [N/A] - Limit Use of sensitive PI: Containment tier never stored; no geolocation; health routed [Live] - §1798.150 Reasonable security: Field encryption with brokered keys is the safe-harbor argument [Live] - Retain Minimization / retention: Retention schedule; intake answers discarded at signing [Live] ### Breach duties (state and regulator clocks) Our primary duty is to notify the agent, who owns the data, fast enough for them to meet theirs. - States Maintainer notifies the data owner immediately; NY caps it at 30 days: IR plan: ≤24 h upstream notice [Live] - MDL-668 Licensee notifies its commissioner within 72 h: The 24 h SLA exists so the agent can meet 72 h [Live] - 314.4(j) FTC notice within 30 days for unencrypted data of 500+ consumers: IR plan; field encryption narrows what counts as unencrypted [Live] - Missouri 4 business days regulator notice, the shortest window we track: Recorded in the IR plan; 24 h clears it [Live] - Triggers ND and WA list full date of birth: Date of birth encrypted with no plaintext twin [Live] ## Program and governance Casewave runs a written information security program modeled on the federal Safeguards Rule and the NAIC’s insurance data-security model law, with a named Qualified Individual, an incident response plan, a vendor register, a retention schedule and a control register, all reviewed against the live system. We are preparing for a SOC 2 Type I audit. - Qualified Individual: Nicholas Towery (Recorded 2026-08-18) Written documents: - Written information security program (WISP) - Incident response plan - Control register - Vendor register - Data retention and disposal schedule - Risk assessment - Deletion request coverage - Redaction rules - 129 architecture decision records CI gates on every pull request: - Typecheck - Lint - PII grep gate - OpenAPI breaking-change diff - Unit suite - Tenant-isolation gate - Secret scanning, full history - Dependency-vulnerability floor - Infrastructure scanning Every pull request runs these. Every GitHub Action is pinned to a commit SHA, build tools are checksummed, and deploys preflight secrets and crypto configuration before migrating. SOC 2 path: - Today: Control register in place [Live] - H1 2027: SOC 2 Type I, targeted [Roadmap] - +6–12 months: SOC 2 Type II [Roadmap] ## Questionnaire answers ### Do you store SSNs, bank account numbers or government IDs? No. No column exists and no form asks for them; they are entered directly into the e-signature document and go to the carrier. ### Do you store health information? No. Health questions are answered inside the signed document; we track status only. ### Is data encrypted at rest? Disk encryption at every provider, plus field-level AES-256-GCM for dates of birth, policy numbers, agent notes, intake answers and every servicing answer, under per-account, per-purpose keys wrapped by AWS KMS. No plaintext twin exists for those fields. ### Is data encrypted in transit? TLS 1.2 minimum at the edge; TLS 1.1 refused; HSTS; DNSSEC on the zone. ### Who holds the decryption keys? A separate key service (AWS Lambda) holds the only decrypt permission; the application can encrypt but not decrypt on its own. Every decrypt is session-bound, rate-limited and audited. ### Can Casewave staff read client data? Only inside a support session the agent has consented to, time-boxed, with a recent second factor, a per-person rate limit, and every row it touches stamped with the session. Outside that, the application holds no decrypt permission, and our named AWS administrators carry an explicit deny on decrypt. ### How is tenant data isolated? Postgres row-level security on all 69 tables, fail-closed, with the account checked inside database functions. Tested in CI on every change. ### Do you restrict where traffic comes from? Yes. Our API blocks twenty sanctioned and high-risk countries and the Tor network at the edge. The web app denies sanctioned and high-risk countries, challenges every visitor outside the U.S., and rate-limits sign-in. ### Where is data stored? Database: Neon, US. Object storage: Cloudflare R2, ENAM. Key management: AWS us-east-1. Each subprocessor’s location is on its card above. ### Do you have a SOC 2 report? Not yet. The program is modeled on the GLBA Safeguards Rule and NAIC MDL-668; SOC 2 Type I is targeted for H1 2027. ### Do you have a written security program and incident response plan? Yes: a WISP, an IR plan with a ≤24-hour upstream-notice SLA, a vendor register, a retention schedule, a risk assessment and a control register. ### How are deletion requests handled? Deleting an account destroys its encryption keys, sweeps readable details, records the deletion, and carries the request to our identity, billing and e-signature vendors. ### Who are your subprocessors? Cloudflare, Vercel, Neon, Clerk, Stripe, BoldSign, AWS (keys only), Anthropic and Apple (push notifications), per our published subprocessor list. ### What is your breach-notification commitment? ≤24 hours upstream notice to the agent (data owner) after discovery, inside every state’s statutory window. ## Claims we do not make - "SOC 2 certified": Preparing. Type I targeted H1 2027. - "HIPAA compliant": Out of scope by design. Health data is routed, not stored. - "End-to-end encrypted": At-rest encryption with brokered keys. The server decrypts to display. - "We never see your data": The application cannot decrypt on its own. - "Signed documents archived": We keep them 7 days, then shred them. - "Bank-level security": Numbers over adjectives. See the rest of this page.