Playbooks/Sharing your book with a vendor
A spreadsheet of your clients' policies is regulated personal financial data, and you are the one answerable for it. Here is what to ask, what good answers sound like, and how to send far less than they ask for.
Sharing a book of business with a vendor can be perfectly safe, and the way to make it safe is to know four things before the file leaves your system: where it goes, who can see it, how long it is kept, and what the vendor will sign.
This page is a checklist you can use on anyone, us included. We sell a service that asks for exactly this data, so read the last section with that in mind — but the questions above it are the right questions regardless of who you are evaluating.
Before any of the vendor-diligence questions, ask a better one: how much of this do they actually need?
For most analysis of a life book — deadlines, opportunities, lapse risk, valuation — the work runs on dates, ages, policy types, terms, statuses and amounts. None of that requires knowing that row 412 is Margaret Chen. Replace the name column with row IDs, keep the mapping on your side, and match the results back yourself.
That single step removes most of the risk from the engagement, and it removes it at the exact moment it is largest: the first exchange with a vendor you have not worked with before. Names become genuinely necessary only when the vendor is contacting your clients on your behalf, and by then you know a great deal more about them.
Strip these before the file leaves your system, always. Social Security and tax identification numbers, bank account and card details, medical records and underwriting correspondence, and beneficiary designations. No book analysis needs any of them, and sending them creates exposure for you with no corresponding benefit.
Ask these in writing and keep the answers. A vendor who answers quickly and specifically has thought about it. A vendor who is vague, or who wants to answer on a call rather than in text, has told you something.
Specific, bounded, and written down. "Stored encrypted in US-region infrastructure, accessible to three named people, deleted thirty days after we deliver, here are our four subprocessors, yes to the DPA, seventy-two hours on breach notification, and no we are not SOC 2 certified" is a good set of answers — including the last part.
Bad answers are not usually refusals. They are fog: "enterprise-grade security", "bank-level encryption", "we take privacy very seriously". Those phrases are compatible with any actual practice at all, which is why they get used.
The other useful signal is speed. A vendor who has answered these before will send you something within a day, because it already exists as a page or a document. One who takes a week is assembling it for the first time.
This is the part worth being clear-eyed about. Handing data to a vendor does not hand over responsibility for it. Producers handle personal financial information and are subject to GLBA-derived obligations implemented through state insurance regulation, most states have now adopted some form of the NAIC Insurance Data Security Model Law, which carries expectations about third-party service providers, and your carrier agreements may impose requirements of their own.
Practically, that means vendor diligence is not a formality you perform for the vendor's benefit. It is part of your own compliance posture, and the written answers you collect are what evidences it. Take the specifics to your compliance officer or counsel rather than to a page on a vendor's website — this one included.
It would be strange to publish this and be coy. Our security and data handling page works through the same list: the transfer path, storage and encryption, who has access, what happens to the file when the work is done, the DPA and NDA, and breach notification.
On two of the questions above it deliberately does not publish a number: the exact retention period and the full subprocessor list are things we put in the agreement, and give you before you send anything, rather than posting on a web page where they read as marketing. By the standard set out above you should treat that as an answer owed to you in writing, and hold us to it — so ask, and judge the reply.
It also says plainly that we do not hold SOC 2, because we would rather tell you that than let a page of security language imply otherwise. And the redacted first scan described above is something we actively offer: the deadline arithmetic runs without names, so for a first engagement you can send row IDs and keep the mapping entirely on your side.
If your compliance officer wants to put a question to us directly, they can, and we will answer it rather than routing it into a sales conversation.
It can be, if you know where the data goes, who can see it, how long it is kept, and what the vendor will sign. The single most effective safeguard is to send less: for most analysis, client names can be replaced with row IDs, because the work runs on dates, ages, policy types, terms and amounts rather than on identities.
Where is it stored and in what region, is it encrypted in transit and at rest, who specifically has access, how long is it retained and when is it deleted, who are the subprocessors, will you sign a data processing agreement, what happens in a breach and how quickly are we told, and do you hold any certification. A vendor who cannot answer these quickly and in writing has told you something useful.
Usually, yes, and it is the right default for a first engagement. Deadline and opportunity analysis depends on dates, ages, policy types, terms and amounts, none of which require a name. Replace the name column with row IDs and match the results back on your side. Names only become necessary if the vendor is contacting clients on your behalf.
Producers handle personal financial information and are subject to GLBA-derived obligations implemented through state insurance regulation, and most states have now adopted some form of the NAIC Insurance Data Security Model Law, which includes expectations around third-party service providers. Your carrier agreements may impose their own requirements. Confirm your specific obligations with your compliance officer or counsel.
Not advice. This page describes how these situations generally work. Policy terms, carrier rules and state regulations vary, and the governing document is always the contract. Confirm anything you act on with the carrier, and take compliance questions to your own counsel or compliance officer.
The scan is free and there's nothing to integrate. Tell us about your agency and we'll come back with who to call, why, and what it's worth.