The 30-second version. Insurance breaks the one-library assumption. A carrier runs two libraries that share a file format and nothing else. First, marketing: disclosure-bearing collateral pushed out to independent agents and brokers who are not your employees — you cannot train or discipline them, so the approved, current, state-appropriate piece has to be the easiest thing to grab or it loses. And because products and disclosures differ by state, permissions gate by territory, not department. Second, claims and loss imagery: adjuster and inspection photographs are evidence, not marketing — enormous volume, attached to a claim, under retention schedules and legal hold, needing an access record and tight scoping. Nobody browses it for a campaign; it must be produced on demand, years later, provably unaltered. The mistake is forcing both under one governance model. Honest caveat up front: a DAM is not a claims system and not a compliance product — it is the library layer, and nothing more.
This page is the insurance asset problem, not a ranking. Because the marketing library’s job is getting approved, state-correct material to an outside network, the tools that do it are the ones we test in our brand portal software ranking and our granular permissions ranking; the review step that clears a piece in the first place is the approval workflows ranking, and that part insurance shares with financial services almost exactly. What insurance adds is a second library with opposite requirements — and the administration depth to run two sets of rules under one roof is what our enterprise DAM ranking exists to test.
The asset problem in insurance
Most DAM buying advice — ours included, on most pages — quietly assumes one library with one set of rules, and spends its energy arguing about how to organise it. Insurance is where that assumption falls apart. A carrier holds two collections that look alike and behave like different species: marketing collateral, and claims photography. Reading them as one problem is the most expensive mistake available here, and it is the common one, because every tool demo is built around the first library and the second never comes up.
Library one: marketing. The outward-facing unit is a compound — a layout, a claim about a product, and the disclosure that makes the claim sayable. That much is shared with financial services, and if the review-and-expiry loop is your question, that page covers it properly. Insurance bends it twice. First, geography: the same product is not the same product across a state line, and the disclosure moves with it. Supervision in the US sits largely with state insurance departments, with equivalents elsewhere, and what a piece may say differs accordingly — the specifics belong to your compliance team, and we quote none of them here. What matters for the library is structural: a piece approved in one state is not approved in another, so the permission question stops being “which department is this person in” and becomes “which territories is this person licensed to sell in, and what is cleared for those”. A folder tree cannot express that. Neither can a group named after a team.
Second, who uses the material. Much of the industry distributes through independent agencies and brokers — not your staff, representing other carriers alongside you, and never sitting through your brand training. There is no employment lever and no mandatory system. What you have is convenience, and that is the entire mechanism: if the approved, state-correct flyer is three clicks away and last year’s version is already on the desktop, the desktop wins. This is a harder position than a bank distributing through branches and salaried advisers, and it is why the portal here is not a nice-to-have — it is the only lever that exists.
Library two: claims and loss imagery. Now the ground shifts. Adjuster photographs, inspection sets, roof and property surveys, catastrophe documentation — these are not marketing assets stored elsewhere. They are evidence. Each belongs to a claim rather than a campaign, and the volume is not comparable: marketing is a curated collection, while claims imagery accumulates continuously as a by-product of the business doing its job. Every requirement points the opposite way. Nobody browses claims photographs for something nice; discovery by wandering is a failure mode, not a feature. Access should be narrow and logged. The set runs on a retention schedule rather than a campaign calendar, and a legal hold can freeze a batch so routine deletion must not touch it — so the same machinery has to both delete on time and refuse to delete on command, depending on a flag. Then the test marketing never faces: produce this set years later, show it has not been altered since capture, and show who opened it in between.
Side by side, the conflict is obvious. Marketing wants to be easy, open, browsable and pushed outward to people you do not employ. Claims wants to be closed, scoped, logged, retained and produced on demand. The mistake is running both under one governance model, and it fails in both directions. Apply claims discipline to marketing and you have built friction into the one library whose only lever is convenience — your agents route around it and use the old file. Apply marketing conventions to claims imagery and you have put evidence under rules designed for a campaign, where the failure is not an off-brand flyer but a retention or hold problem found at the worst possible moment. A tool that offers only one model is not wrong; it is doing half the job, and you should know which half before you sign.
One more piece of honesty, mirroring what we say on financial services and healthcare. A DAM is not a claims system — the claim is a record in your claims platform, where policy, adjuster, reserve and decision live, and no DAM replaces that. It is also not a compliance product: it is one control, and your compliance and legal teams own the requirements, including the retention schedule itself. What a DAM can be is the library layer — where the imagery sits, how it is found, who may see it, what happens to it over time, and whether you can produce it later. That is narrower than most vendors claim in an insurance deck, and it is the only claim we will make.
Where a DAM saves money here
- The approved, state-correct piece becomes the easiest thing to grab. You cannot mandate anything to an independent network, so hours spent writing usage rules for people who don’t work for you are wasted. The only intervention that works is making the right file faster to reach than the wrong one — a brand portal the agency self-serves from, current material first. Convenience is the only control you have, so buy it deliberately.
- Permissions that gate by territory rather than by org chart. A piece cleared for one state is not cleared for the one next door, and an agency licensed in three states needs three sets and none of the others. Through folders that means duplicating the library per state and re-duplicating on every update; granular permissions that model territory keep one library and one update. The failure they prevent isn’t an off-brand asset — it’s a piece used where it was never cleared.
- Claims imagery you can produce years later, provably unaltered. The expensive version of “find the first inspection set and show it hasn’t been touched” is a hunt across phones, mailboxes and a drive, ending in a set nobody can vouch for. An audit trail recording access and change against the asset turns that from archaeology into a lookup.
- Retention and legal hold that run on the asset, not on someone’s memory. Keeping evidence too long carries cost and exposure; deleting it on schedule when a hold applies is the worse outcome — the same mechanism seen from two sides. Making retention a property of the asset across its lifecycle, with a hold that overrides it, means the schedule your legal team wrote is the one that actually runs.
How it plays out
An illustrative composite. The scenario below is not one named insurer — it is a composite of the patterns we see, built entirely from capabilities we have tested and published. No invented benchmarks.
Picture a regional property-and-casualty carrier writing in a handful of neighbouring states. Marketing sits at the centre, producing product sheets, agency flyers and campaign layouts, each carrying a disclosure tied to a product and a state. Distribution runs through independent agencies that carry two or three other carriers as well. Separately, a field adjuster team photographs damage every working day — roofs, vehicles, water intrusion, contents — and every set belongs to a claim number.
On a shared drive, the marketing half fails by geography. An agency principal emails asking for “the current homeowners flyer”; whoever is nearest the drive sends what is there, and the version cleared for one state travels to an agency writing in another, where the product it describes is not quite the product on offer. Nobody was careless: the drive has no concept of a state line, so the only thing between the file and the wrong territory was a person remembering. Meanwhile the agencies keep local copies, because asking marketing takes a day and opening a desktop folder takes a second — and since they do not work for you, that habit is not yours to address.
The claims half fails more quietly. Photographs arrive from phones and email into a folder named after a claim number, and mostly are never looked at again. Then one matters: two years on, a disputed claim turns on what the roof looked like at first inspection. The set has to be found and then vouched for — and a folder on a drive cannot establish who opened those images or whether any changed. Around the same time a legal hold lands on a related batch, and the retention cleanup that has run quietly for years now has to not run, on exactly those files, without anyone being certain which they are.
With a DAM as the library layer, the two halves stop sharing rules. Marketing lives in a portal scoped by territory: an agency signs in, sees the flyers cleared for the states it is licensed in, current version first — the neighbouring state’s version is not discouraged but absent. Because that is the fastest route to a usable file, it is the route the agency takes. Claims imagery lives under different rules in the same system: attached to its claim, not browsable, access recorded, on a retention schedule with a hold that overrides deletion. The claim itself still lives in the claims platform; the DAM holds the pictures and answers for them. The saving isn’t a percentage we can invent — it is the end of a state-wrong piece reaching an agency because a drive cannot know better, and the end of not being able to say who touched a set of evidence. To weigh that against tool cost, our business-case guide counts search time, rework and the cost of waiting.
The capabilities that matter most here
1. Permissions that model territory, not the org chart
The decisive one on the marketing side. The gate is not “which department” but “which state, and which entity is this agency selling for” — and an agency licensed across several states needs the union of those and nothing beyond it. Our granular permissions ranking tests whether a tool expresses that as a rule over one library, or degrades into a duplicated folder per state someone must re-sync on every update. The question to press vendors on: when a piece is cleared for an additional state, is that one change or several?
2. A portal an independent network will actually use
Adoption here is not a mandate you issue — it is a race against a file already on someone’s desktop. The brand portal has to be faster than that: sign in, see what is cleared for your territory, take the current version, leave. Slow search, a login nobody remembers, or a sign-in that shows a broker the whole library and asks them to work out what applies, and you have lost to the old copy. Getting the piece cleared before it lands there is the review loop in our approval workflows ranking — the half that works exactly as it does in financial services.
3. Retention, legal hold and a usable access record
The claims side, where the point is producing a specific set years later and answering for it. That needs three things marketing never asks for: a retention schedule enforced by the system rather than by a recurring reminder; a hold that reliably suspends deletion on a defined set until lifted; and an audit trail recording access and change against the asset that survives the asset being updated. Ask specifically what happens when a hold and a retention rule disagree — a tool without a clear answer does not have the feature, it has a checkbox.
4. Two governance models under one roof — or an honest two systems
If one system holds both libraries, test isolation: can it run open, browsable, externally-shared marketing and closed, logged, retained claims evidence without either set of rules leaking into the other? That administration depth — separate spaces, policies and access models on one platform — is what our enterprise DAM ranking exists to probe. The answer is allowed to be no. Plenty of carriers run marketing in a DAM and leave claims imagery to the claims platform and its storage, which is a coherent design. What is not defensible is buying one tool on a marketing demo and discovering afterwards that the claims library came along with the wrong rules attached.
Buyer’s test: during a trial, run one asset down each library and check the rules do not leak. Marketing: clear a flyer for one state only, sign in as an agency licensed in a different state, and confirm the piece is absent rather than merely marked — then clear it for a second state and count how many things you had to change. Claims: load an inspection set against a claim, place it under hold, run the retention rule that would otherwise delete it, and confirm the hold wins; then ask who has opened those images and whether any changed since ingest. Finally, the real question: with both libraries in one tenant, does the claims library stay out of the portal search, and does the marketing library stay out of the retention job? If “which territory is this cleared for?” and “who touched this evidence?” both return answers, the tool fits insurance. If either returns a folder, it doesn’t.
FAQ
Why does an insurance carrier need a DAM and not just a shared drive?
Because insurance runs two libraries with opposite rules, and a shared drive has exactly one set of rules: whatever the folder permissions happen to say. One library is disclosure-bearing marketing material distributed to independent agents and brokers, where the product and the disclosure vary by state - so a piece approved in one state is not approved in another, and the permission question is which territory somebody sells in, not which department they sit in. The other library is adjuster and inspection photography, which is evidence: attached to a claim, kept under a retention schedule, occasionally frozen by a legal hold, and needing a record of who opened it. A drive cannot gate by territory, cannot hold a set against routine deletion, and cannot tell you who looked at what. None of those are storage problems.
Should claims photos and marketing assets live in the same DAM?
They can, but only if the system can run two sets of rules without one leaking into the other - and that is the thing to test rather than assume. The two libraries want opposite behaviour. Marketing collateral should be easy to browse, easy to find and easy for an outside agent to pull without asking anyone. Claims imagery should be hard to browse, tightly scoped, logged on access, and retained or held on a schedule rather than on somebody's judgement. Force them into one governance model and you get the worst of both: either your agents fight friction that exists to protect evidence, or your evidence sits under conventions designed for a campaign. Plenty of carriers keep the two entirely separate, and that is a defensible answer rather than a failure. One caveat either way: a DAM is not a claims system. The claim itself lives in your claims platform - the DAM is only the library layer under the imagery.
Isn't this the same problem financial services has?
The marketing half is close, and the review-and-expiry loop is genuinely shared - if that is your question, our financial services page is the better read. Two things make insurance its own problem. First, the network: banks distribute through branches and advisers they can at least reach through employment, while insurance sells heavily through independent agencies and brokers who represent other carriers too. You cannot train them, you cannot discipline them, and the approved piece therefore has to win on convenience or it simply loses to the one already on their desktop. Second, and bigger: financial services has one library. Insurance has a second one made of claims and loss photography, which is evidence rather than marketing and which points the opposite way on almost every requirement. No amount of approval workflow addresses that half.
How do you control assets used by independent agents you don't employ?
You do not control them, and any vendor implying otherwise is overselling. Independent agents are not your staff - they carry other carriers, they keep their own files, and the only real lever you have is convenience. So the job is to make the approved, current, state-appropriate piece the fastest thing to grab: a portal scoped so an agency sees what is cleared for the states it is licensed in and not what is cleared for the state next door, current material that comes back first, and no email to anyone required to get it. You can also see who pulled what, which turns a later conversation into a record rather than a guess. The honest framing is that you are making the right piece the easy piece, not installing a lock on somebody else's business.
Which capability matters most for insurance?
It depends which library you mean, which is the whole point of this page. For marketing, it is permissions that model territory - because a piece approved in one state is not approved in another, and a folder tree or a department grouping cannot express that. For claims, it is the ability to retain, hold and prove: a set of inspection photographs that can be produced years later, shown to be unaltered, with a record of who touched them in between. And if you are buying one system to do both, then the capability that matters most is neither of those on its own - it is whether the tool can run two governance models under one roof without one contaminating the other. Ask that during the trial, not after it.
Sources & references
- Granular permissions ranking — whether a tool can gate one library by territory and licensed entity, or degrades into a duplicated folder per state. July 2026.
- Brand portal software ranking — self-serve distribution to an independent agent and broker network, where convenience is the only available control. July 2026.
- Audit trail and asset lifecycle — the access record, retention schedule and hold behaviour the claims-evidence library needs and the marketing library never asks for.
- Approval workflows ranking — routing disclosure-bearing material through review before it reaches the network; the loop insurance shares with financial services. July 2026.
- Enterprise DAM ranking — the administration depth needed to run two governance models under one roof without either leaking into the other. July 2026.
- Digital asset management for financial services — the review, sign-off and expiry loop for compliance-reviewed marketing, covered there rather than repeated here.
- DAM business-case guide — sizing search time, rework and the cost of waiting against tool cost.
The permissions, portal, approval, retention and audit capabilities above are drawn from our own testing and reviews; the composite carrier invents no organization, no claim, no agency and no figures. We deliberately quote no regulation and state no supervisor’s requirement: that insurance is supervised largely at state level is context for why territory-scoped permissions matter, not a rule we are interpreting on your behalf, and your retention schedule comes from your legal team rather than from us. A DAM is not a claims system and not a compliance product — this page is only about the library layer beneath the imagery. Per how we source claims. See how we test.