The 30-second version. Energy and utilities break the assumption sitting underneath almost every DAM buying guide — that a library is a marketing library. Here it isn’t. The overwhelming majority of a utility’s images are operational records of physical infrastructure: drone passes along a line, pole and substation inspections, turbine blades, pipeline surveys, meter photographs. They exist to prove what a piece of infrastructure looked like on a date — for maintenance planning, regulatory reporting and incident investigation — and nobody browses them for a campaign. Three things follow. The natural index is the asset and its coordinates, not campaigns or products, because the query that matters is “show me every photo of this substation, oldest to newest” — a time series about a thing, which is not what most DAMs are designed around. Retention runs in years, because the value is evidentiary. And a slice is security-sensitive: detailed pictures of critical infrastructure are not press material, yet they sit in the same library as photos meant for press. Honest caveat up front: a DAM is not an EAM and not a GIS. It is the library layer beside them, and nothing more.
This page is the energy-and-utilities asset problem, not a ranking. Because the whole library hangs on whether the coordinates and asset identifiers your field tools already write survive ingest as real, searchable fields, the ranking that matters most here is our metadata management ranking, which tests exactly that round-trip. Keeping the sensitive classes away from the people who shouldn’t see them is our granular permissions ranking; for organisations that conclude this material shouldn’t sit in someone else’s cloud, the on-premise ranking covers the self-hosted deployment. And the administration depth to run an operational library and a comms library under one roof is what our enterprise DAM ranking exists to probe.
The asset problem in energy & utilities
Nearly every piece of DAM advice ever written — most of ours included — quietly assumes the library is full of marketing. Logos, campaign photography, product shots, the things a brand made on purpose to sell something. In a utility that library exists, and it is the minority of what you hold. The bulk of a utility’s imagery was never made to sell anything at all, and reading the whole problem through the marketing half is how buyers here end up with a tool that is excellent at the smaller job.
Consider what the bulk actually is. Drone passes along a transmission line. Pole and pole-top inspections. Substation walk-downs. Turbine blades photographed from a lift or a UAV. Pipeline and right-of-way surveys. Meter and service-point photographs taken by a technician who needed to record what was there. None of it was commissioned by a creative team, and each frame exists to establish exactly one thing: what this piece of infrastructure looked like on this date. That purpose is evidentiary, and it is why the material is retained for years rather than archived when a campaign ends — it feeds maintenance planning, it supports regulatory reporting, and if something fails it becomes the record an investigation works from. Note the inversion: a marketing asset’s value decays as it ages, while an inspection frame is valuable partly because it is old. The comparison with last cycle’s frame of the same object is the entire point.
The asset is a place, so location is the primary key. This is where energy departs from every other industry we cover, and it is worth being precise. Elsewhere the natural index is an abstraction the business invented: a campaign, a product SKU, a project, a claim number. Here the thing an image is of is a physical object standing at a fixed location, which your organisation already identifies with a number it uses everywhere else. So the index that fits is the asset and its coordinates — geotagging and asset IDs — and the query that matters is “show me every photo of this substation, oldest to newest”. Look at the shape of that request. It is a time series about a thing. Most DAMs are built for the opposite shape: a collection about a theme, assets gathered together because they belong to a launch or a season. A system that can only express “things grouped because someone grouped them” will make you hand-build, by hand and forever, the one view your library exists to produce.
The closest page on this site is architecture & construction, and the difference between them is the difference between a project and an asset. An AEC firm documents a project: it has a start, phases, a handover, and after that the archive is essentially closed and consulted occasionally. A utility never hands over. You own the structure for decades, you photograph it again on a cycle, and the twelfth photograph of it is the point rather than a duplicate of the eleventh. One is a project archive that finishes; yours is a permanent register that keeps growing on a schedule. That is why their index is project-and-phase — a container with an end date — and yours is asset-and-location, which has neither.
The evidentiary framing, meanwhile, sits close to the claims imagery we describe on insurance — close enough that it’s worth naming the difference rather than letting a reader assume. Claims evidence is per-incident and adversarial: it exists because something happened, and because someone may later dispute what happened. Inspection imagery is per-asset and cyclical. Most of it records that nothing was wrong, on a schedule, and its worth comes from being an unbroken series rather than from one decisive frame. Insurance’s evidence answers “what happened here?”. Yours answers “what has been happening here, all along?” — and a single frame in isolation barely answers it at all.
Some of this material is security-sensitive. Detailed imagery of critical infrastructure — how a facility is laid out, what is inside a cabinet, where things connect — is not something to hand out, and the specific rules governing it belong to your own security team; we quote none of them here and you should be wary of any vendor who does. What matters for the library is structural, and it is uncomfortable: the same system holds material that must never leave, sitting beside photographs actively intended for press. That means classification has to be a property of the asset rather than a convention about where somebody filed it, and permission has to be hard — the sensitive set should be absent from a comms user’s search rather than present with a label asking them not to.
The comms side does exist, and it is a perfectly normal job: public information, outage communication, renewables and community project work, recruitment. It wants what any brand library wants — a portal, current material, a consistent look — and our marketing-facing pages cover that job properly. It is simply not the centre of gravity here, and a tool chosen on a comms demo has been chosen on the smaller half of your problem.
One last piece of honesty, and it is the point at which we part company with most energy decks. A DAM is not an EAM and it is not a GIS. The asset register, the work order, the condition rating and the maintenance schedule live in your enterprise asset management system. The spatial model of the network lives in GIS. Neither is a job a DAM does, or should attempt. What a DAM can be is the library layer beside them — where the images themselves sit, how they are found, who may see them, and what happens to them across years of retention — keyed on the same asset identifiers, so the picture and the record point at each other. Those systems hold records about assets and point at attachments; they were not built to hold and search image files at volume. That gap is the DAM’s and it is narrower than the deck implies. It is also the only claim we will make.
Where a DAM saves money here
- The photograph becomes findable by the thing it is a photograph of. The default is a folder named for a contractor and a flight date, which is findable only if you already know when someone flew — a fact nobody has when the question arrives. Indexing on coordinates and the asset identifier you already use turns “every image of this structure, oldest first” into a query rather than an excavation. That is the difference between an archive that answers questions and one that merely stores them.
- A record you can produce years later, and stand behind. The imagery’s whole purpose is evidentiary, which means the expensive failure isn’t losing it — it’s holding it and being unable to produce it, or producing it and being unable to say it hasn’t been touched. Retention as a property of the asset across its lifecycle, with an audit trail recording access and change, turns “find the last inspection before the failure and show it is unaltered” from archaeology into a lookup.
- Stop re-visiting ground you already photographed. Field visits and flights cost real money, and when nobody can find the last pass, the cheapest-looking path is always to go again. An unfindable archive quietly buys you a second inspection of something you already have on disk — and keeps buying it, cycle after cycle, because the reason it was unfindable never got fixed.
- The sensitive set stops being one folder permission away from the wrong audience. When classification is a property of the asset and permissions are enforced by the system, the material that must not circulate is invisible to the accounts that shouldn’t have it — instead of being separated from the press library by a folder tree and somebody’s good judgement on a busy day.
How it plays out
An illustrative composite. The scenario below is not one named utility — it is a composite of the patterns we see, built entirely from capabilities we have tested and published. No invented benchmarks.
Picture a mid-size distribution utility: poles and lines across a region, a set of substations, and a growing renewables site. Inspection is a mix, as it usually is — internal crews with phones, a drone contractor flying the lines on a cycle, engineers photographing substations during scheduled walk-downs. A small communications team handles outage notices, the public website and the community work around the new site.
On a shared drive, everything lands the way it arrives: a folder per contractor per flight date, a folder per crew per month, phones syncing into someone’s cloud drive. This works perfectly until a question is asked of it. After a storm, an investigation needs to know what one particular structure looked like at its last inspection before the failure. The image almost certainly exists. Finding it means guessing which contractor covered that stretch, then which flight date preceded the storm, then opening frames until the structure appears — and having found it, nobody can say whether the file has been altered since it landed. The record was kept and is, functionally, not there. Meanwhile the comms team, hunting a turbine shot for a community page, is browsing the same drive — and the whole drive runs one permission model, so the substation interiors are right there beside the press photos.
With a DAM as the library layer, the shape of the thing changes. At ingest each frame carries its coordinates and the asset identifier the utility already uses everywhere else, so the unit of search is the asset rather than the flight. “This structure, oldest to newest” returns a strip, and the pre-storm frame is second from the end — next to last cycle’s, which is what makes it mean anything. Retention is a property of the class rather than a habit somebody maintains, and the access record answers the question that follows retrieval. The sensitive classes are scoped so a comms search does not return them: absent, not marked. Comms itself works from a portal that only ever contained comms material. What has not happened is equally worth saying: the maintenance decision is still the EAM’s, the network model is still the GIS’s, and the DAM has not replaced either — it holds the pictures and answers for them, keyed on the same IDs. The saving isn’t a percentage we can invent — it is the end of an inspection record that exists but cannot be produced, and the end of a second flight over ground already on disk. 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. Location and asset identity as the primary index
The decisive one, and the one demos skip. Your drones, field apps and cameras already write coordinates, and your organisation already has an identifier for every structure. The question is whether both survive ingest as first-class, searchable fields — or arrive flattened into a free-text notes box, or stripped entirely. Our metadata management ranking tests exactly that round-trip, and geotagging is what turns coordinates into a map view and a spatial search rather than a number nobody reads. Press vendors on this specifically: after ingest, can I search on the asset ID as a field, and does the coordinate still round-trip out intact?
2. A time series about one thing, not a collection about a theme
The view your library exists to produce is one asset in chronological order, and it should assemble itself from the metadata rather than requiring somebody to hand-build an album per structure. Ask to see it: pick an object, ask the tool for everything of that object oldest-to-newest, and watch whether the answer is a query or a curation exercise. Pair it with retention that lives on the asset across its lifecycle, since the series only has value if the old end of it is still there.
3. Classification and hard permissions
The same library holds material that must never leave beside material meant for press, so classification has to be a property of the asset and the permission has to bite. Our granular permissions ranking tests whether a restricted class can be made genuinely absent for an account that shouldn’t see it, rather than visibly labelled and one drag away. Some organisations conclude this material shouldn’t sit in someone else’s cloud at all; that is a coherent conclusion, and the on-premise ranking covers the deployment it implies.
4. The library layer beside your systems of record — and the comms half
A DAM earns its place here by being keyed on the same asset identifiers as your EAM and GIS, so the image and the record find each other, and by not pretending to be either. Integration is therefore a requirement rather than a bonus. The other thing one roof has to survive is two audiences: an operational library that is closed, scoped and retained for years, and a comms library that is open, browsable and pushed outward. Running both without either set of rules leaking into the other is administration depth, which is what our enterprise DAM ranking exists to probe — and the answer is allowed to be two systems, honestly chosen.
Buyer’s test: during a trial, ingest a real batch — an actual drone or inspection set carrying the coordinates and identifiers your field tools write, not sample JPEGs — and ask three things of it. Can it return one asset, oldest to newest, without you hand-building that collection first? Did the coordinates and the asset ID survive ingest as searchable fields, and do they still round-trip out? And can you make a sensitive class absent — not merely marked — for an account with a comms role, then confirm it never surfaces in portal search? If “every photo of this structure, in order” is a query and the restricted set is genuinely invisible to the people who shouldn’t see it, the tool fits a utility. If the honest answer is still a folder named after a flight date, it doesn’t.
FAQ
Why does a utility need a DAM and not just a shared drive?
Because almost none of what a utility photographs is marketing, and a shared drive can only answer the question you thought to ask when you named the folder. The bulk of the library is operational: drone passes along a line, pole and substation inspections, turbine and pipeline surveys, meter photographs. Each frame exists to establish what a piece of infrastructure looked like on a date, and it is kept for years because that is evidence - for maintenance planning, for regulatory reporting, and for an investigation if something fails. That work needs the library indexed on the asset and its location, so that 'every photo of this substation, oldest to newest' is a query rather than a hunt through folders named after contractors and flight dates. A drive cannot do that, cannot tell you whether a file changed since it landed, and cannot keep security-sensitive material apart from the photos meant for press. None of those are storage problems.
Isn't inspection imagery the job of our EAM or GIS system, not a DAM?
Partly, and the honest answer is that a DAM does not replace either. The asset register, the work order, the condition rating and the maintenance schedule belong in enterprise asset management; the spatial model of the network belongs in GIS. A DAM is the library layer beside them: where the images themselves live, how they are found, who is allowed to see them, and what happens to them across years of retention. The reason it is a separate job is that those systems are built to hold records about assets and to point at attachments, not to hold and search image files at volume. Keyed on the same asset identifiers, the two sides point at each other, and the photograph stops being an attachment nobody can search. Any vendor telling you their DAM is your asset management system is overselling.
How is this different from architecture and construction, which also photographs structures?
The difference is that a project ends and an asset does not. An architecture or construction firm documents a project through to handover - it has a start, phases and a finish, after which the archive is essentially closed and consulted occasionally. A utility never hands over. You own the structure for decades, you photograph it again on a cycle, and the twelfth photograph of it is the point rather than a duplicate of the eleventh. That makes your library a permanent register that grows on a schedule instead of a project archive that closes. The practical consequence is the index: AEC organises by project and phase, which is a container with an end date, while you organise by the asset and its location, which has neither.
Should security-sensitive infrastructure photos live in the same library as press photos?
They can, but only if the system can keep them genuinely apart rather than politely labelled, and that is the thing to test rather than assume. Detailed imagery of critical infrastructure is not public material, and the specific rules about it come from your own security team rather than from us. What matters for the library is structural: classification has to be a property of the asset and permission has to be hard, so that someone with a communications role searching the portal does not merely see a warning on the sensitive set - they do not see the set at all. If a tool can only run one permission model over one library, that is not necessarily wrong, but it means you are really running two libraries, and you should say so deliberately rather than discover it later. Some organisations conclude this material should not sit in someone else's cloud at all, which is a coherent answer rather than a failure.
Which capability matters most for energy and utilities?
Indexing on the asset and its location, because everything else depends on it. The library's job is to answer questions about a physical thing over time, and if the coordinates and the asset identifier your field tools already write do not survive ingest as first-class searchable fields, no amount of search speed, storage or portal polish recovers it - you are back to folders named after a flight date. Retention and classification matter enormously and are the next two questions to ask. But an inspection record you cannot retrieve by the thing it is a record of was not really kept, whatever the storage bill says.
Sources & references
- Metadata management ranking (IPTC/XMP round-trip) — whether the coordinates and identifiers written by a camera, drone or field tool survive ingest as first-class fields, or arrive flattened. July 2026.
- Geotagging — coordinates as searchable metadata, and the map view and spatial search that make “everything shot at this location” a query.
- Granular permissions ranking — whether a restricted class can be made genuinely absent for an account rather than visibly labelled. July 2026.
- Asset lifecycle and audit trail — retention as a property of the asset over years, and the access-and-change record an evidentiary library needs.
- On-premise DAM ranking — the self-hosted deployment for organisations that conclude this material shouldn’t sit in someone else’s cloud. July 2026.
- Enterprise DAM ranking — the administration depth to run a closed operational library and an open comms library under one roof. July 2026.
- Digital asset management for architecture & construction — the project-archive version of this problem, which finishes at handover; covered there rather than repeated here.
- DAM business-case guide — sizing search time, rework and the cost of waiting against tool cost.
The indexing, metadata-fidelity, permission, retention and audit capabilities above are drawn from our own testing and reviews; the composite utility invents no organization, no incident and no figures. We deliberately quote no regulation and no safety or security standard: that inspection imagery supports maintenance planning, regulatory reporting and incident investigation is context for why the library is evidentiary, not a rule we are interpreting on your behalf — your retention schedule and your classification rules come from your own legal and security teams rather than from us. A DAM is not an EAM and not a GIS; this page is only about the library layer beside them. Per how we source claims. See how we test.