Audit Trail and Document Control Gaps in QHSE Software

Across the 212 QHSE, EHS and ESG software profiles researched on this site, two capability families are mentioned least often in the research records. Audit trail appears in 28 profiles (13%) and document control in 30 (14%), against 136 (64%) for API and integrations and 130 (61%) for reporting and dashboards. Only 5 profiles have both.

That is a statement about records, not about products. This article looks at why the two families are thin, what auditors and regulators may ask for, and how a buyer can test both in a demonstration instead of relying on a feature list.

How thin the two families are

The capability map sorts the capability statements in every profile record into ten families by a keyword rule on the statement title. A profile counts toward a family when its strongest matching statement is documented or conditional. The chart shows how many of the 212 profiles that is, family by family.

Audit trail is the least common family of the ten and document control the second least. The next lowest, ESG data collection, reaches 35 profiles, and the most common family reaches almost five times as many as audit trail. Among the 28 audit trail profiles, 17 have a documented statement, and 11 have only conditional ones, which means the record ties the capability to a plan, module or set-up. Document control is less often conditional: 22 of its 30 profiles are documented, and 8 conditional only. It is the family with the lowest conditional share of the ten.

Why these families are thin in the records

It would be easy to read the chart as "most QHSE software has no audit trail". The records do not support that. They show what the research records state, and the explanations below are possibilities that the records do not test.

The map reads titles. A statement counts when its title uses a keyword such as audit trail, change history, document control or version history. A vendor that mentions an audit log in the body of an incident or CAPA description, without titling a capability that way, is not counted. This produces undercounting whenever a function is a property of other features rather than a feature of its own.

Public pages may favour what a buyer can see. A change log, a revision history or a document register may appear in a help article, an admin guide or a security document rather than on a feature page, and the review reads public pages.

Some evidence may sit behind a login or a contract. Retention periods, log export and immutability may be described only in documentation shared after an enquiry. A record that cites public pages cannot confirm them, and the statuses unverified and conditional exist for that reason.

Some products are focused tools. An app built to capture an inspection or a near-miss quickly may not manage controlled documents at all, and that can be a sensible design choice for its use.

The records cannot tell you the share of each explanation. What they do establish is narrower and still useful: for 184 profiles there is no audit trail statement in the research record, and for 182 there is no document control statement. If either matters to you, the absence is a reason to ask, not a reason to assume.

What auditors and regulators ask for

The two families answer different questions.

Document control is about the version of a document a person is using. Management system standards such as ISO 9001 include requirements on documented information, and the clause numbers and wording depend on the edition you work to. An internal auditor may pick a procedure or a work instruction and ask four things: who approved this version, when, what changed from the last one, and how do you know the person on the floor is not using the old one.

Audit trail is about the history of a record. Who created or changed it, when, what the value was before and sometimes why. For persons who use closed systems to keep electronic records under US FDA rules, for example, 21 CFR 11.10(e) calls for secure, computer-generated, time-stamped audit trails that independently record the date and time of operator entries and actions that create, modify or delete records, and says that record changes shall not obscure previously recorded information. A buyer outside FDA-regulated work is not bound by that rule, but the question travels. An incident investigation, a risk assessment or a corrective action (CAPA) that can be edited without a trace is hard to defend after an event, and a reviewer of an ESG figure that is later restated may ask where the earlier number went.

Both matter most at the moments when a record is challenged: an audit finding, a claim, a regulator's request or a reviewer's question about a disclosed figure.

Where the gap is widest, by category

Document control is most often found in one category. Of the 22 quality management profiles, 14 have a documented or conditional statement (64%), 9 of 43 EHS management profiles (21%) and 6 of 17 QHSE management profiles (35%) do, and it appears in 1 of 16 audits and inspections profiles. No profile has it in ESG and sustainability (30 profiles), safety management (12), occupational health (11), asset management (7), construction safety (7), emergency management (6), environmental management (6), chemical management (5), risk and compliance (5) or the 25 profiles in smaller categories.

Audit trail is spread more evenly and thinly:

In the small categories one profile moves a row by 14 to 20 points, so the shares are coarse. Read the table as a prompt for questions. Quality management is the category where the records most often show document control. A buyer in EHS or safety who also needs controlled procedures, permits or safety data sheets should not assume the same.

How to test an audit trail in a demonstration

Use a real record from your own process and ask the vendor to run each step while you watch.

1. Edit and look. Change a field on a closed incident, risk assessment or action. Ask to see the history for that record. It should show who, when, the old value and the new value.
2. Ask for the reason. Check whether the system can require a reason for a change and whether the reason appears in the history.
3. Try to remove it. Ask whether an administrator can edit or delete history entries. If they can, ask what leaves a trace of that.
4. Delete a record. See what remains, whether a deletion is logged and whether a record can be restored.
5. Export it. Ask for the log in a file you can give to an auditor, and check that it covers the same fields as the screen.
6. Ask about time. Confirm whether timestamps use server time, whether time zones are stored, and how long history is kept.

How to test document control in a demonstration

1. Follow one document through. Create a draft procedure, send it for review, approve it and publish it. Note who can do each step and whether the approver can be the author.
2. Revise it. Issue a new version and ask what happens to the old one. It should remain retrievable and be marked superseded, not silently overwritten.
3. Check the reader's view. Open the document as a frontline user. Does the reader see only the current version, and can the system show what changed between versions?
4. Prove it was read. Ask whether the system records acknowledgement and training linked to the version.
5. Check the field. If people read procedures on a phone or tablet, test an obsolete document on the device after the new version is published, with and without a connection. The offline support article lists the questions to ask about content that is downloaded before a user goes offline.
6. Test review dates. Ask how overdue reviews are flagged and who is notified.

If controlled documents are central to your process, compare dedicated options on the QMS document control and document management pages, and the wider quality management software page. The demo checklist and RFP template can carry both lists into your own evaluation.

How to cite these figures

Say what was counted. "28 of 212 researched profiles have a documented or conditional audit trail statement in their research record" is accurate. "Only 13% of QHSE software has an audit trail" is not, because the map counts statement titles in a researched set, not product features in the market. The family counts, the category rows and the downloadable CSVs are on the capability map, and the datasets page explains reuse.

Method and limits

The figures come from the generated capability map data: 212 profiles, 2,449 capability statements, ten families, records checked through 14 October 2026. A statement belongs to the audit trail family when its title contains a phrase such as audit trail, audit log, change history, version history, edit history or reason for change, and to the document control family when it contains document control, controlled documents, document management, document revisions or document versioning, among others. The full keyword rules are printed on the capability map. The overlap figures, 53 and 5, are computed from the per-profile CSV published with the map.

Limits to keep in mind:

• Documentation review, not hands-on testing. Nobody here ran the products or looked at their logs.
• Titles, not text. A capability described under another title is not counted.
• Statuses. Documented means described without a stated dependency, conditional means tied to a plan, module or set-up, and unverified means the review could not establish it.
• The researched set. The profiles are not a census of vendors.

One of the 212 profiles belongs to a vendor that pays for sponsored placement on this site, and the editor works at that vendor. Its record was read by the same rules as every other and is counted in every figure above like any other profile; it is not named here. The methodology page holds the full disclosure.