Insurance runs on data. Claims frequency, loss ratios, exposure by ZIP code, telematics signals from 50 million policyholders. The person who turns that raw feed into pricing decisions and reserve estimates is the insurance data analyst. This guide is for hiring teams: VPs, heads of talent, COOs, and line-of-business leads trying to fill the role correctly the first time.
Role overview.
An insurance data analyst sits at the junction of actuarial science, business intelligence, and product operations. Their job is to make insurance data usable: cleaning it, modeling it, and presenting findings that actuaries, underwriters, and product managers can act on.
They're different from a pure actuary (who holds exam credentials and signs off on reserves) and from a generic BI analyst (who wouldn't know a loss development triangle from a pivot table). The insurance data analyst occupies the space between those two: technically strong, domain-aware, and able to speak both languages.
What this role does day-to-day.
Monday morning might start with a product manager asking why the combined ratio in commercial auto crept up 3 points last quarter. By Tuesday afternoon, the analyst has pulled claims data by vehicle class, written a SQL query against the policy management system, and built a chart that shows the spike is concentrated in fleet accounts over 25 vehicles in three specific states.
That's the job. Specific, transactional, under a deadline.
On any given week, an insurance data analyst will:
- Pull and clean policy, claims, and billing data from multiple systems (policy admin, claims TPA, reinsurance ledger)
- Build and maintain dashboards for underwriting performance, claims frequency, and loss ratio by segment
- Support actuarial teams with data prep for reserve reviews and pricing studies
- Run ad hoc analyses for product or finance when a line of business behaves unexpectedly
- Identify data quality issues before they corrupt a pricing model
- Document data definitions and maintain the data dictionary for insurance-specific fields
Senior analysts add another layer: they start owning the analytical output directly, presenting recommendations to leadership and designing the models rather than just feeding them.
Key responsibilities.
Underwriting analytics. Monitoring loss ratios, hit rates, and book composition by segment. Flagging adverse selection signals before they compound.
Claims analysis. Tracking claim frequency and severity trends. Identifying weather events, litigation spikes, or process changes that explain shifts in development patterns.
Pricing support. Preparing exposure and loss data for rate filings and actuarial rate reviews. Joining policy-level data with external datasets (telematics, credit, weather) to test rating factor hypotheses.
Reporting infrastructure. Building and owning dashboards that give underwriting, product, and finance teams a daily view of portfolio health. Keeping those dashboards accurate as source systems change.
Data governance. Maintaining field definitions, flagging inconsistencies across systems, and working with IT to fix upstream data problems before they reach the model layer.
Required skills and qualifications.
- Junior SQL, Excel/Google Sheets, basic statistics, insurance terminology (premium, loss ratio, deductible)
- Mid-level Advanced SQL, Python or R, BI tools (Tableau, Power BI, Looker), familiarity with policy admin or claims systems
- Senior Predictive modeling, GLMs for pricing, actuarial data prep, stakeholder communication, data architecture input
Domain knowledge matters more than most hiring teams expect. A candidate who has worked in P&C insurance understands why earned premium differs from written premium, why you develop losses to ultimate before comparing periods, and why a 72% loss ratio in workers' comp is very different from 72% in homeowners. That context shortens onboarding by months.
Soft skills to screen for: comfort with ambiguous questions ("why did our new business ratio drop?"), ability to translate technical findings for non-technical stakeholders, and genuine curiosity about insurance as a business.
Tools and certifications.
Core tools: SQL (Snowflake, BigQuery, Redshift, or Postgres depending on stack), Python (pandas, scikit-learn for senior roles), Excel for actuarial data prep, Tableau or Power BI for dashboards, and dbt if the team runs a modern data stack.
Insurance-specific platforms: Duck Creek, Guidewire, Applied Epic, Majesco. Candidates won't always have your exact system, but prior experience with any of these signals they understand structured insurance data.
Certifications worth noting: CAS (Casualty Actuarial Society) exams at any level signal serious domain commitment, though most data analysts won't be pursuing the full exam track. CPCU coursework is a strong signal for P&C-focused roles. For insurtech or health, familiarity with HL7/FHIR or claims EDI formats is a plus.
One honest note: tool lists in JDs scare off good candidates. If you list 12 required tools, you'll get candidates who claim all 12 and have actually used 3. List your 3 non-negotiables and treat the rest as nice-to-haves.
Salary range.
These are US base salary ranges as of 2026. They reflect the insurance vertical specifically; general BI analyst roles typically run 5-10% lower for equivalent seniority because insurance domain expertise carries a premium. Totals can run 15-25% higher once you add annual bonus and equity at insurtech companies.
| Level | Experience | US base salary (2026) | Typical bonus |
|---|---|---|---|
| Junior insurance data analyst | 0-2 years | $75,000 - $90,000 | 5-8% |
| Mid-level insurance data analyst | 2-5 years | $90,000 - $115,000 | 8-12% |
| Senior insurance data analyst | 5+ years | $115,000 - $130,000+ | 12-18% |
Insurtech startups (Series A-C) often pay at the top of these bands and add equity. Carriers and MGAs tend to be 5-8% lower but offer stronger benefits and more stable data infrastructure. In major markets (NYC, San Francisco, Chicago), add roughly 10-15% to the base.
Career path.
Most insurance data analysts start in one of 3 places: a carrier's actuarial support team, a consulting firm doing insurance analytics, or a reinsurer's data function. From there the path branches.
The actuarial track leads toward ACAS/FCAS credentials and pricing or reserving leadership. The data/engineering track moves toward data science, ML engineering for pricing models, or data platform ownership. The business track goes into underwriting analytics management, product analytics, or eventually head of data at an MGA or insurtech.
At the senior analyst level, candidates are usually deciding which direction to lean. When you're hiring, it's worth asking which track interests them, because it tells you a lot about whether they'll still be engaged in 18 months.
How to write the job description.
Most insurance data analyst JDs are either too generic ("analyze data to support business decisions") or too tool-heavy ("must have Guidewire, Duck Creek, Snowflake, Python, R, Tableau, Power BI, SQL, Excel, and SAS"). Both approaches produce bad applicant pools.
Write for impact first. Tell candidates what they'll own, what problems they'll solve, and why the data function matters to the business. Then list requirements in order of actual importance, with a honest distinction between must-haves and nice-to-haves.
Here's a copy-paste template you can adapt:
Insurance data analyst
About the role
We're looking for an insurance data analyst to own the analytical layer between our policy and claims systems and the business decisions that depend on them. You'll work closely with underwriting, product, and our actuarial team to turn raw policy data into clear answers about how our book is performing and where the next opportunity is.
What you'll do
- Build and maintain dashboards tracking loss ratio, claim frequency, and book composition by segment
- Support quarterly reserve reviews with actuarial data prep: cleaning, reconciling, and documenting policy and claims extracts
- Run ad hoc analyses for underwriting and product when a line of business behaves unexpectedly
- Identify and escalate data quality issues before they affect pricing or reporting
- Own the data dictionary for insurance-specific fields and maintain documentation as source systems change
What we're looking for
- 2-5 years working with insurance data at a carrier, MGA, reinsurer, or insurtech
- Strong SQL; you can write complex queries against policy and claims tables without help
- Familiarity with P&C insurance concepts: earned vs. written premium, loss development, combined ratio
- Experience with at least one BI tool (Tableau, Power BI, or Looker)
- Python or R experience is a plus, not a requirement
Nice to have
- Experience with Guidewire, Duck Creek, or a similar policy admin system
- CAS exam progress or CPCU coursework
- Experience with dbt or a modern data stack
The best JD you can write is honest about the data environment. If your policy system is held together with Excel exports and manual reconciliations, say so. Candidates who thrive in messy environments exist. Candidates who discover the mess after they start don't stick around.
How to hire one.
Source differently. Insurance data analysts with real domain experience aren't browsing LinkedIn job posts the way junior developers do. Many are embedded at carriers and not actively looking. Referrals from actuarial teams, CAS networking events, and targeted outreach to people with insurance carrier experience on their profile are more productive than a job board post.
Screen for domain first, tools second. Ask early: "Walk me through how you'd calculate an accident year loss ratio from a claims extract." A candidate who can answer that question correctly has the domain knowledge you need. You can teach them your specific tools. You can't quickly teach insurance concepts to someone who's never worked in the vertical.
Give a realistic exercise. A short take-home using anonymized data similar to what they'd actually work with will tell you more than any interview question. Keep it under 2 hours. Ask them to explain their approach, not just produce an output.
Interview questions that work:
- "Our combined ratio jumped 4 points last quarter in commercial property. Walk me through how you'd investigate that."
- "How do you approach a dataset where the policy admin system and the claims system use different policy identifiers? What's your first move?"
- "Tell me about a time you found a data quality problem that was affecting a business decision. What did you do?"
- "What's the difference between an accident year and a policy year view of losses, and when does it matter?"
The fourth question is a quick filter. Anyone who's worked in P&C analytics for more than a year should be able to answer it without hesitation. If they can't, the domain experience on their resume probably doesn't run as deep as it looks.
If you want pre-vetted candidates who've already passed this kind of screen, our insurance data analyst recruiting page covers how we source and shortlist for this specific role.
Frequently asked questions.
An actuary holds professional credentials (ACAS/FCAS or ASA/FSA) and is legally responsible for signing reserve opinions and rate filings. An insurance data analyst does the data work that supports those decisions: cleaning extracts, building models, running analyses. Many analysts work alongside actuaries and eventually pursue credentialing, but the roles are distinct. If you need someone to sign off on reserves, you need an actuary. If you need someone to build the data infrastructure those reserve calculations run on, you need an analyst.
For a junior role, you can often hire from adjacent fields (banking analytics, healthcare data) and get someone up to speed in 3-6 months if you have strong actuarial or underwriting mentorship available. For mid-level and above, insurance experience is worth paying for. The concepts (loss development, earned exposure, reinsurance structures) take time to internalize, and you'll feel the gap when the analyst is presenting to underwriting leadership or supporting a rate filing.
If you're posting on job boards and running a standard process, plan for 8-12 weeks from job post to signed offer. Qualified candidates with genuine P&C experience are not abundant, and the ones worth hiring are usually juggling multiple conversations. Working with a recruiter who has insurance vertical coverage and a warm candidate network can cut that to 3-4 weeks. JobCompass delivers shortlists in 48 hours for mid-level roles.
Compensation mismatch discovered late in the process. Many hiring teams benchmark against generic data analyst salaries rather than insurance-specific ranges, then lose candidates at the offer stage after 4-5 rounds of interviews. Get your comp range on the table in the first conversation. It saves everyone time and builds goodwill with candidates who see you're operating in good faith.
It depends on the work. If the analyst is primarily doing reporting and ad hoc SQL queries, Python is nice to have but not a day-one requirement. If they'll be building pricing models or working directly with the data science team, require it. Listing Python as required when the actual job is mostly SQL and Tableau will cost you good candidates who'd be perfectly effective in the role.
Ask them to explain a concept specific to your line of business. For P&C, "walk me through how you'd develop losses to ultimate" works well. For health, ask about medical loss ratio calculations. For specialty lines, ask about bordereau reporting. A candidate who can walk through the concept clearly, without hesitation, has genuine depth. A candidate who gives a vague answer and pivots to talking about their SQL skills probably has insurance on their resume but general BI in their day-to-day.
In the first 30 days: understand the data environment, document the main data sources and known quality issues, and shadow the existing reporting process. Days 30-60: own at least one existing dashboard, run an independent ad hoc analysis, and present findings to a stakeholder. Days 60-90: identify one gap in current reporting and propose a solution. Productivity ramps faster if you invest in onboarding documentation and give them a clear problem to solve in week one rather than asking them to "get up to speed."