The Audit Log Your Publisher Doesn’t Know They Need

This article is for general informational purposes only and does not constitute legal advice. Copyright law is complex and fact-specific. If you have received a demand letter or believe you may be facing an infringement claim, consult a qualified intellectual property attorney.

---

When a copyright demand letter arrives, the first question is always the same: where did this image come from? Who uploaded it? When? Did anyone check the license before it went live?

If your CMS does not log image uploads, the answer to every one of those questions is the same: we do not know.

Why the Log Matters More Than the Check

A reverse image search at upload is useful. It surfaces information the editor would not otherwise have. But the check alone is not documentation. Documentation is a record that the check happened, who was present for the results, and what decision was made.

That distinction matters the moment a dispute arrives. A check with no record is invisible. A check with a timestamped log entry showing the editor’s name, the match results, and the acknowledgment is a paper trail. Those are different things legally and practically.

The publisher who can say “our system checked this image on this date, our editor reviewed these results, and here is the log entry showing the acknowledgment” is in a different conversation than the publisher who can say “we have a policy that editors are supposed to check images.” One is documentation. The other is a statement of intent with no evidence behind it.

What an Audit Log Actually Contains

A useful image upload log captures the attachment ID, the user who uploaded it, the timestamp, the number of matches returned by the reverse image search, which API provider ran the check, whether the editor acknowledged the results, and when the acknowledgment happened.

That is not a complicated data set. It is six fields per upload. But it is the difference between having a record and having nothing.

The log tells you several things over time. It tells you which editors are uploading images that return matches regularly, which is a training signal. It tells you which images were acknowledged and uploaded anyway, which is a risk signal. It tells you the total volume of checks your site is running, which is useful for API cost management. And it tells you, for any specific image under dispute, exactly what happened at the moment it entered your CMS.

What Your Publisher Actually Needs

Publishers and editors in chief generally do not think about audit logs until they need one. By then it is too late to create one retroactively. The log has to exist before the dispute, not after.

What your publisher needs, even if they do not know it yet, is the ability to answer the question “did we take reasonable steps?” with documentation rather than assertion. Reasonable steps is the language that matters in copyright disputes and in any internal review of how a problematic image got onto the site.

An audit log answers that question automatically for every upload from the moment the system is running. The publisher does not have to think about it. The IT director does not have to compile it manually. It exists because the workflow generates it.

That is the difference between a reactive organization and a documented one. Reactive organizations pay settlements and have uncomfortable conversations afterward. Documented organizations have the same conversations from a position of evidence.

The Conversation the Log Makes Possible

Once an audit log exists, a different kind of editorial conversation becomes possible. Not a blame conversation, not a policy lecture, but a data conversation.

Over time the log shows patterns. If one editor’s uploads return matches at a higher rate than others, that is information worth acting on with training rather than discipline. If a particular content category, sports photos, event photography, wire-adjacent images, generates more matches than others, that is information worth acting on with sourcing guidance.

The log turns an invisible problem into a visible one. Invisible problems do not get solved. Visible ones do.

PhotoCheckWP creates and maintains this log automatically. Every upload generates a row. The admin can view the log, sort by date, user, or match count, and see the full history of what the system found and what editors did with that information. Nothing has to be compiled manually. Nothing gets lost when a staff member leaves.

The Practical Setup

The log table is created when the plugin activates. From that point forward every image upload generates an entry. The admin view is under Settings in the WordPress dashboard. It is paginated, sortable, and shows the full record for each upload.

There is no export in the current version. If a dispute requires producing the log, a database export via your hosting panel gets the data in a format any attorney can work with. That is a five-minute task when you know the table exists and where to find it.

The alternative is explaining to an attorney that your CMS has no record of image uploads and that you cannot reconstruct what happened or when. That conversation is shorter and more expensive.

The Bottom Line

The audit log is not the feature that sells the plugin. The reverse image search is the feature that sells the plugin. The log is the feature that makes the plugin worth keeping.

Any organization can run a check. The check is cheap and the information is useful. But the check without the log is a tree falling in an empty forest. The log is what makes the check matter when it matters most, which is after something has gone wrong and someone is asking what you did about it.

Your publisher does not know they need this log yet. They will, eventually. The question is whether it exists when they need it.

---

---

The PhotoCheckWP Team writes about image copyright, editorial workflow, and the real cost of unlicensed images in digital publishing. We built this tool because we watched the problem happen from inside newsrooms — and because we paid for it ourselves.