Security & Compliance
How ECIW Systems protects Nonpublic Personal Information and responds when something goes wrong — written for brokers, carriers, and regulators.
GLBA & FTC Safeguards Rule compliance
16 C.F.R. Part 314 — Standards for Safeguarding Customer Information
ECIW Systems is built from the ground up to support broker compliance with the Gramm-Leach-Bliley Act (“GLBA”) and the FTC Safeguards Rule, including the December 2022 amendments. The platform is operated as an information-security program with identified administrative, technical, and physical safeguards.
- Designated Qualified Individual appointed to implement and supervise the program (16 C.F.R. §314.4(a)).
- Documented risk assessment covering reasonably foreseeable internal and external risks to NPI — published in our WISP and reviewed at least annually (§314.4(b)).
- Safeguards designed to control identified risks — encryption, access controls, MFA-ready authentication, secure development, change management, and logging (§314.4(c)).
- Regular testing & monitoring of key controls, with audit logging of access to systems containing NPI (§314.4(d)).
- Personnel training & vendor oversight for everyone with access to NPI, and contractual safeguards on all sub-processors (§§314.4(e), 314.4(f)).
- Written incident response plan, published in full further down this page (§314.4(h)).
- Annual program review with material changes reported through internal governance (§314.4(i)).
- Notification to the FTC within 30 days of discovery for any event involving the NPI of 500+ consumers (§314.4(j), effective May 2024).
NAIC Insurance Data Security alignment
Model #668 — Insurance Data Security Model Law, as adopted by the states
ECIW Systems supports licensees subject to state laws based on the NAIC Insurance Data Security Model Law (Model #668), already adopted in more than twenty U.S. states. The platform is designed so that brokers can rely on us as a third-party service provider while meeting their own state-level obligations.
- Information security program commensurate with the size, complexity, and sensitivity of the NPI in scope (Model #668 §4.A).
- Documented risk assessment covering threats, likelihood, and impact — updated when material changes occur (§4.C).
- Risk-based controls on access, authentication, encryption of NPI in transit and at rest, and secure development (§4.D).
- Oversight of third-party service providers with due diligence and contractual safeguards (§4.F).
- Cybersecurity event investigation procedures documented in our Incident Response Plan (§5).
- 72-hour notification to the state Insurance Commissioner for cybersecurity events involving NPI of state residents, where required by adoption (§6).
- Annual written certification of compliance available to licensed broker-customers on request (§4.I).
Broker-customers remain the licensed entity and the responsible party for their own state insurance regulator filings. ECIW Systems provides the technical and procedural underpinning and supports incident-time coordination.
Data protection practices
Encryption, secure links, role-based access, and audit logging — by default
NPI never travels in the clear and is never accessible to anyone who does not need it. The following controls are enforced platform-wide and are not opt-in.
Encryption in transit and at rest
- TLS 1.3 enforced on every public endpoint, with HSTS and an HTTPS-only canonical host.
- Encryption at rest on managed Cloudflare and Totalum storage tiers, with provider-side key management.
- Email delivery routed through ZeptoMail over TLS; uploaded files served exclusively over signed, expiring URLs.
Secure share links for client intake
- Each client intake form gets a unique, single-purpose token unrelated to any account ID.
- Tokens expire automatically (14 days by default) and can be revoked or regenerated by the broker at any time.
- A revoked link is invalidated instantly across browsers; previously captured data remains scoped to the original broker.
- Public client routes carry no broker session cookies — there is nothing for a stolen link to escalate to.
Role-based access control
- Distinct roles (Super Admin, Agency Admin, Broker) gate every dashboard, API route, and database query.
- Brokers see only the intakes they own; Agency Admins see only their own agency; cross-agency access is denied at the middleware and at the data-access layer.
- Better Auth manages password hashing, session cookies, password reset, and session timeout (idle and absolute).
- MFA-ready: the auth layer supports stepping up to additional factors when a broker organization elects to enable it.
Audit logging
- Server-side activity log records intake creation, share-link creation, share-email send, broker-email send, client submission, and PDF download.
- Every privileged administrative action (plan upgrade, revocation, auto-expiry) is recorded to a separate admin audit log with actor, target, and timestamp.
- Logs are retained for at least five (5) years and are available on a need-to-know basis to support investigations and broker diligence.
- Super Admins can review and filter the activity log by agency, action, and time range from the admin panel.
SOC 2 readiness statement
Trust Services Criteria — Security, Availability, and Confidentiality
Current status (May 2026): ECIW Systems is in the SOC 2 readiness phase. We have not yet completed an external Type I or Type II audit and we do not currently hold a SOC 2 report. We are choosing to publish this status transparently rather than claim certifications we have not earned.
The platform has been engineered to the AICPA Trust Services Criteria for Security, Availability, and Confidentiality, with the following posture in place today:
- Security (CC-series) — documented WISP, role-based access, MFA-ready authentication, encryption, vulnerability monitoring, and a published Incident Response Plan.
- Availability (A-series) — managed Cloudflare and Totalum infrastructure with provider-side redundancy and automated backups; status surfaced to broker-customers when material.
- Confidentiality (C-series) — least-privilege access to NPI, encrypted storage, signed-URL file delivery, and audit logging of access to sensitive records.
- Change management — controlled deployment pipeline with type-checking, automated build verification, and reviewed releases.
- Vendor management — documented sub-processor inventory and contractual safeguards (see next section).
A Type I audit is on our compliance roadmap. Until that report is issued, ECIW Systems will continue to provide letters of attestation, architecture summaries, and policy excerpts on request to support broker and carrier diligence.
Third-party oversight and data processing agreements
How we vet, contract with, and supervise the vendors that touch NPI
Every vendor that processes NPI on behalf of ECIW Systems is inventoried, contractually bound, and reviewed on a recurring basis.
- Due diligence before onboarding — review of the vendor’s security program, certifications, breach history, and data-handling commitments.
- Contractual safeguards — Data Processing Agreements (DPAs), confidentiality terms, breach-notification obligations, and limits on sub-processing flow down from our customer terms to each downstream vendor.
- Scoped credentials — each vendor receives the minimum credentials and dataset required to perform its function; keys are rotated on schedule and revoked on offboarding.
- Periodic review — vendor compliance posture and access are reviewed at least annually, and immediately on any material change to scope.
- Sub-processor list — a current list of sub-processors handling NPI is available to broker-customers on request; brokers are notified of material changes before they take effect.
- Cloud hosting & edge (Cloudflare)
- Managed application data (Totalum)
- Transactional email (ZeptoMail)
- Billing & subscription (Stripe)
To request a copy of our standard DPA, our current sub-processor list, or a security questionnaire, contact us at [email protected].
Risk assessment, safeguards, training, vendor management and program review are all documented in the WISP.
Incident Response Plan
What ECIW Systems does in the minutes, hours, and days following the discovery of a cybersecurity event — aligned with GLBA Safeguards Rule §314.4(h) and NAIC Insurance Data Security Model Law (Model #668).
Purpose
This Incident Response Plan (the “IRP”) establishes the procedures ECIW Systems follows to prepare for, detect, contain, eradicate, recover from, and learn from security incidents that affect Nonpublic Personal Information (“NPI”) processed through the ECIW platform.
The IRP is a required component of our Written Information Security Program (“WISP”) and is designed to satisfy the incident-response obligations of the Gramm-Leach-Bliley Act (GLBA) Safeguards Rule (16 C.F.R. Part 314.4(h)) and the NAIC Insurance Data Security Model Law (Model #668), as adopted by the states in which our broker-customers are licensed.
Its goals are to: (i) minimize harm to consumers whose information we hold, (ii) restore normal operations as quickly as is safely possible, (iii) preserve evidence for forensic review, and (iv) meet every applicable regulatory notification deadline.
Roles and responsibilities
A standing Incident Response Team (“IRT”) is appointed by the Information Security Program Coordinator. The IRT is on-call during any active incident and convenes within one (1) hour of an incident being declared.
- Information Security Program CoordinatorECIW Systems
Overall accountability for the IRP. Declares incidents, authorizes containment actions, approves external notifications, and chairs the post-incident review.
- Incident CommanderOn-call engineering lead
Runs the technical response: triage, evidence preservation, containment, eradication, and recovery. Maintains the incident log in real time.
- Communications LeadDesignated officer (or Coordinator)
Owns all internal and external communications, including notices to affected consumers, brokers, carriers, regulators, and law enforcement.
- Legal & Compliance LiaisonOutside counsel (engaged as needed)
Determines notification triggers under state insurance, state breach-notification, and federal law; supervises regulator-facing communications.
- Vendor & Forensics LiaisonEngineering lead
Coordinates with hosting, storage, email, and security vendors; engages an independent forensic firm when scope warrants.
Every member of the IRT has a designated alternate. Contact details and escalation order are maintained in an internal runbook reviewed quarterly.
Detection and reporting process
Potential incidents are surfaced through a combination of automated monitoring, vendor alerts, and human reports.
- Platform audit logs (authentication, administrative actions, access to sensitive records).
- Provider-side security alerts from Cloudflare and Totalum (anomalous traffic, suspicious authentication, rule triggers).
- Reports from brokers, clients, employees, or contractors via[email protected]or215.645.2288.
- Third-party advisories (carrier notices, sub-processor breach notifications, security researcher disclosures).
- Anyone observing a suspected incident reports it immediately to the Information Security Program Coordinator.
- The Coordinator opens a numbered incident ticket and a private incident channel within fifteen (15) minutes.
- Severity is classified (P1 — confirmed exposure of NPI; P2 — suspected exposure or material control failure; P3 — minor control deviation with no NPI impact).
- For P1 and P2 events, the IRT is activated and the regulatory notification clock is started immediately as a precaution, even before scope is confirmed.
Reporters acting in good faith are protected from retaliation. Late or unreported incidents may themselves constitute a control failure.
Containment, eradication, and recovery
Once an incident is declared, the IRT executes the following phases in parallel where safe to do so.
Containment
- Isolate affected accounts, sessions, share tokens, or API credentials. Revoke and rotate compromised secrets.
- Disable or scope-down the impacted code path or feature flag if the source is application-level.
- Preserve volatile evidence (logs, request traces, session metadata) before remediating.
- Engage hosting and storage vendors to apply provider-side blocks where necessary.
Eradication
- Identify and remove the root cause (vulnerable code, misconfiguration, leaked credential, malicious account).
- Patch, redeploy, and verify that the underlying defect is no longer reachable in production.
- Hunt for related indicators of compromise across the platform and across affected vendor systems.
- Confirm with the Incident Commander that no persistent foothold remains before moving to recovery.
Recovery
- Restore impacted services in a staged manner, with elevated monitoring during the first 72 hours.
- Validate data integrity from authoritative backups where any records may have been altered.
- Re-issue credentials, tokens, and links that were rotated during containment.
- Confirm that all affected workflows (intake, share links, PDF generation, email) operate normally end-to-end.
A real-time incident log (timestamps, actions, decisions, evidence references) is maintained throughout, and is retained for at least five (5) years after closure of the incident.
Communication and notification procedures
The Communications Lead, working with the Legal & Compliance Liaison, determines who must be notified, when, and through what channel. All external statements are reviewed by the Coordinator before they leave ECIW Systems.
Where required by state law adopting the NAIC Insurance Data Security Model Law (Model #668) — including, among others, AL, CT, DE, IN, KY, LA, ME, MI, MN, MS, NH, ND, OH, SC, TN, VA, & WI — ECIW Systems will notify the affected state’s Department of Insurance Commissioner no later than seventy-two (72) hours after determining that a cybersecurity event involving NPI of residents of that state has occurred. The clock starts at the time of determination, not the time of detection.
For brokers licensed in additional states, equivalent notifications are also made under the applicable state insurance-data-security statute, state general breach- notification law (e.g., MA 201 CMR 17.00, NY 23 NYCRR 500, CA Civ. Code §1798.82), and any contractual notice obligations to carrier partners.
- State insurance commissioners — within 72 hours of determination, where adopted; consistent with NAIC Model #668 §6 contents (nature of event, NPI involved, remediation, contact point).
- Affected consumers — written notice in the most expedient time possible and without unreasonable delay, consistent with the applicable state breach-notification law (typically within 30–60 days), describing the incident, the categories of information involved, steps taken, and resources available (including credit-monitoring where warranted).
- Broker-customers — informed promptly so they can fulfill their own producer-level notification duties to clients, carriers, and regulators.
- Carrier & sub-processor partners — notified per contract, generally no later than 72 hours.
- Federal authorities — including the FTC under the GLBA Safeguards Rule notification amendment (within 30 days for events affecting 500+ consumers), and law enforcement (FBI / IC3 / Secret Service) where criminal activity is suspected.
- Credit reporting agencies — where required by state law based on the number of affected residents.
Post-incident review and lessons learned
Within fifteen (15) business days of closing the incident, the Coordinator chairs a written post-incident review. Reviews are blame- free and focus on systemic improvement.
- Timeline reconstruction — a clean narrative of detection, triage, containment, eradication, recovery, and communications, with timestamps.
- Root-cause analysis — technical, procedural, and human factors that allowed the event to occur or to escalate.
- Effectiveness review — whether each phase of this IRP performed as designed, including responsiveness of the IRT and of vendors.
- Corrective actions — tracked with owners and due dates, covering controls, monitoring, training, and vendor management. Completion is verified by the Coordinator.
- Documentation update — the WISP, this IRP, and internal runbooks are updated to reflect lessons learned. A redacted summary is shared with affected broker-customers when material to their own compliance posture.
- Regulatory follow-up — any supplemental filings, consumer notices, or status updates required by the receiving regulator are completed within the deadlines they set.
The full incident record, post-incident review, and corrective-action register are retained for a minimum of five (5) years and are available to regulators and to broker-customers’ auditors on request.
ECIW Systems treats every confirmed security event as an opportunity to strengthen our controls and our commitment to the brokers, clients, and carriers who rely on us.