Who downloaded that drawing? Why PLM audits the item and loses the file

Abstract

Ask any PLM vendor whether the platform has an audit trail and the answer is yes, with justification. All of them record who created a part, who revised it, who approved the change and when the state moved. That machinery is mature and it satisfies the change-control half of most regulatory regimes.

Now ask a narrower question, the one that actually gets asked in an investigation: who took a copy of this drawing, when and where did it go?

On most platforms that question is answered badly or not at all, and the reason is not vendor negligence. It is architectural. A metadata change passes through the business-logic layer, where it can be intercepted. A file download does not. It is an HTTP GET against a file server, frequently a different host entirely, and by design it bypasses the machinery that records everything else. The audit trail follows the item. The file leaves by a different door.

This paper explains that asymmetry, maps the doors a file actually leaves by, surveys how the major platforms handle it and sets out what a log has to contain to survive an auditor who is not satisfied by a screenshot.

It is not theoretical. The approach described here is running in production on Aras Innovator, built end to end as configuration, with no compiled component and no service restart at any point in its delivery.

1. Why this is a compliance problem rather than an IT preference

Download logging tends to be treated as a nice-to-have until a specific event makes it urgent. The events are predictable:

Export control. Under ITAR, EAR and their equivalents, the controlled act is disclosure to a foreign person, and disclosure includes providing access to technical data. If an auditor asks you to demonstrate that no non-authorised person obtained the drawing, an access-control policy is a statement of intention. A download log is evidence. Those are not the same standard of proof.

The departing engineer. The most common real-world IP loss is not a breach. It is an employee who, in their last fortnight, downloads a few hundred drawings. Permissions did not stop it because the person was entitled to the files right up to their final day. Only a log distinguishes "did their job" from "took the product with them", and only if the log existed before anyone suspected anything.

Contractual and customer audits. Defence primes, medical OEMs and automotive customers increasingly require their suppliers to demonstrate controlled handling of shared data. "We restrict access" is a weaker answer than "here is every access, by whom, on what date."

Regulated quality regimes. FDA 21 CFR Part 11, ISO 13485, AS9100 and ISO 27001 all, in different words, require that access to controlled records be traceable. Change history alone does not discharge this. A record can be perfectly version-controlled and still have been copied by fifty people with no trace.

Incident response. After a leak, the first question is scope: which files, which people, what window. Without a log the answer is a guess, and a guess is not a notification you can defend to a regulator or a customer.

Notice the common shape. In every case the value of the log is retrospective, and retrospective value is only available if the log was switched on in advance. This is the argument that loses budget meetings — it is insurance, not capability — and it is the reason so many organisations discover the gap on the day they most need it not to exist.

2. The architectural reason this is hard

Here is the core of the paper, and it is the part most discussions of PLM auditing skip.

When a user edits a part, the change passes through the platform's business layer. There is a defined extension point — a server event, a listener, a trigger, a method — where the platform will hand you control and let you write an audit record. That is why change auditing works everywhere. The event is interceptable by design.

When a user downloads a file, typically none of that happens. The client asks the application server for a location, then fetches the bytes over HTTP directly from a file vault or content server — often a separate machine, deliberately, so that large-file traffic does not go through the application tier. That is good architecture for performance and terrible architecture for auditing, because the transfer never enters the layer where business rules live.

The consequence is a split that runs through every design in this space:

• The intent to download is visible in the client, where the user clicked.
• The transport is visible at the vault, which knows bytes moved.
• Neither alone is an audit record. The click does not prove the file arrived. The vault transaction frequently does not know which business object the file belonged to, or which user in business terms requested it, as opposed to which service account fetched it.

A credible download log therefore has to be correlated from two sources, which is a materially harder engineering problem than adding a listener to a save event. It is why this capability is thin across the industry, and why an organisation that needs it usually ends up building it.

It also explains a detail that confuses people reading such logs for the first time: well-built download logs tend to record reported or requested events rather than asserted completions, because honesty about what the system actually observed is worth more than a confident record that cannot be substantiated.

3. Mind map: the doors a file actually leaves by

The second reason download auditing fails is scope. Teams instrument the browser download button, declare the problem solved and miss that the browser is one of five routes out. A file that leaves by any of the others leaves unlogged.

                              ┌── Download button  (direct vault GET)
                              ├── View / open in place (still a copy)
         ┌── INTERACTIVE ─────┤
         │   (a person, in    ├── Print, or export to PDF
         │    the browser)    ├── Viewer "save as" / measure + export
         │                    └── Screenshot, photo of screen  [UNLOGGABLE]
         │
         │                    ┌── CAD connector check-out
         ├── CAD TOOLING ─────┼── "Load to CAD" / "Copy to CAD" exchange
         │   (bypasses the    ├── Local workspace / cache sync
         │    browser wholly) └── Neutral-format conversion (STEP, JT, PDF)
         │
FILE ────┤                    ┌── Supplier / partner data pack
EGRESS   ├── PACKAGED ────────┼── Bulk zip export, multi-select download
         │   (many files,     ├── Report or BOM export with attachments
         │    one action)     └── Baseline or snapshot export
         │
         │                    ┌── REST / SOAP / API file get
         ├── PROGRAMMATIC ────┼── Integration pull (ERP, MES, quality)
         │   (no human at     ├── Service account used by a connector
         │    the keyboard)   └── Vault replication to another geography
         │
         │                    ┌── Direct file-share access to vault storage
         └── INFRASTRUCTURE ──┼── Backup, restore, database or vault copy
             (outside the     ├── Administrator console / DBA query
              application)    └── Storage-layer snapshot

Three observations that follow from the map, and they are the practical value of drawing it.

The browser is the minority path. In a real engineering organisation most file movement is CAD tooling and integrations. Instrumenting only the download button produces a log that is technically accurate and materially misleading, because it under-reports the paths that carry the most data.

Some paths are outside the application entirely. Nothing in the PLM layer can log a DBA copying the vault directory, or a storage snapshot. Those must be covered by infrastructure controls — file-system auditing, privileged access management, backup custody — and a design that claims complete coverage without addressing them is overclaiming. Say where the application's authority ends.

One path is genuinely unloggable. A photograph of a screen defeats every control in this paper. That is not a reason to skip the others; it is a reason to be precise about what the log does and does not prove, because an auditor will ask and the credible answer is a bounded one.

4. What a defensible audit record has to contain

A log line reading "user downloaded file" is not evidence. It cannot be correlated, challenged or defended. A record that survives scrutiny answers seven questions:

Two further properties matter as much as the fields.

The log must be append-only and outside the reach of the people it watches. An audit trail that an administrator can edit is not an audit trail. If the same identity can both download a file and delete the record of it, the log has no evidential value — and this is the same separation-of-duties argument made in permission design, applied to the record rather than the data.

Retention must match the regulatory window, not the disk budget. Export control and product liability horizons run to years. A log that rolls over after ninety days will be empty exactly when a claim arrives.

5. How the major platforms implement it

Most comparisons ask which platform logs downloads out of the box. That is the wrong question, and section 3 is why. There are five egress paths, and no vendor's built-in event list covers all five. So the question that decides whether you end up compliant is not what ships. It is what you can reach when the vendor has not instrumented the path you need.

That splits the platforms into two groups: those that give you a fixed menu of auditable events, and the one that gives you authorship.

PTC Windchill has the most explicit story. Auditing is configured through an auditing configuration file that determines which events are recorded for which object types, and PTC's documentation states that out of the box Windchill records system usage, organization usage and download events (PTC Help Center). Additional events are enabled individually, and — a detail that matters operationally — after changing the configuration you must restart the method server for the update to take effect. PTC also publishes a dedicated support article on getting download information into security audit reporting (CS135740), which is both evidence the capability exists and evidence it is not self-explanatory.

Siemens Teamcenter provides the framework and leaves you the definitions. Audit Manager captures who did what to which object and when, through Audit Definitions that specify exactly which attributes to capture for a given event on a given type, with logs exportable to CSV or XLS. Enabling it is a configuration act, and the granularity is genuinely good. Whether file download specifically is captured is a recurring question in Siemens' own community — there are long-standing threads asking how to audit dataset download and requesting audit reports for file download. The persistence of that question in a mature product is the most honest indicator available of where the boundary sits.

Dassault 3DEXPERIENCE frames audit around governance. The documented audit story is change and approval history — who approved which change, version comparison, the record that satisfies a regulated change process — and authentication-level logging is configured separately through the platform's identity component. Public documentation of content download auditing as a distinct, configurable event is thin, and we could not verify it; a prospective buyer for whom this matters should ask for it to be demonstrated rather than assumed.

Aras Innovator is the one platform where the audit scope is yours to set. Start with the concession, because it matters on day one: Aras ships no download-audit feature. File download is a vault transaction, and because a vault may be a separate server — in a replicated estate, a different server in another geography — it sits outside the item event model. On the morning you install it, Windchill logs more downloads than Aras does.

Now look at day ninety, when the requirement has moved. This is where the platforms diverge sharply, and it follows directly from the code boundary. In Aras the log type, the client-side intent capture, the vault correlation and the server logic that writes the record are all runtime configuration — item types and methods that an administrator creates through the same API as any other data, with no build, no deployment package and no service restart. Which means you can instrument any path in section 3's map that you are able to observe: the browser click, the vault read, the CAD exchange, the supplier pack, the API call. Each one is an afternoon, not a release.

You can also change the shape of the record. When an auditor asks a question your log was not designed to answer — add the field, backfill what you can, carry on. On a fixed-menu platform the answer to "we need to capture the destination supplier as well" is a vendor enhancement request or a compiled customisation with a restart behind it. In Aras it is a property.

That is the honest form of the Aras advantage here. Not that it audits downloads better out of the box, because it does not audit them at all out of the box. It is that audit scope on Aras is a configuration decision you own, and on every other platform it is a product decision somebody else already made.

This is not a thought experiment. It is running in production. We have built this pattern on Aras and it is live today, capturing real file activity on a real estate: intent captured at the client, correlated with what the vault reports, with separate instrumentation for the CAD-exchange and supplier-pack routes, plus the log and its configuration modelled as item types carrying their own permissions so the record is readable by auditors and not editable by the people it watches.

There is no compiled component anywhere in it. No service was restarted at any point in its delivery. The entire capability is a package of items, which means it installs like data, versions like data and can be extended next quarter when somebody asks a question it was not built to answer.

The effort was days rather than a release cycle, and that is the difference the table above is really describing. Every argument in this section about what Aras makes possible is a description of something already working, not a projection of what the architecture ought to allow.

Read that table row by row and Windchill wins the first column outright. Read it column by column and the picture inverts: the only platform whose audit coverage is not capped by a decision the vendor made years ago is the one that shipped nothing.

6. The three ways this goes wrong in practice

Logging the click and calling it a download. The click is intent. If the transfer failed, or the user cancelled, or the vault refused, the log asserts something that did not happen. A log that overstates is worse than one that under-reports, because an auditor who finds one unsupportable record will disbelieve the rest. Record intent as intent and delivery as delivery, and do not collapse them.

Logging only the browser. By the map in section 3, this misses CAD connectors, packaged exports and every integration — which together usually move more data than the browser does. The log then shows light activity and management concludes there is no problem, which is precisely the wrong conclusion drawn from an incomplete instrument.

Service accounts with no human behind them. Integrations authenticate as one identity. If the log records that identity, every file that left through an integration is attributed to "the connector", and attribution is exactly what the log exists to provide. The requesting human must be carried through the call and recorded, or that route must be declared out of scope explicitly.

A fourth, quieter failure: nobody reads it. A log that is written and never reviewed detects nothing. A monthly ten-minute look at the top downloaders by volume, and at anyone downloading outside their project, converts a passive archive into a control. The metric worth watching is simple — unusual volume, unusual breadth, unusual timing, particularly in someone's final weeks.

7. How to test whether yours works

Do not assume. Run the exercise, which takes an afternoon and is the only way to know:

1. Take one controlled drawing. Get it out by every route in the map you believe is available — browser, CAD connector, supplier pack, API, viewer print.
2. Then go to the log and try to find all of them. Count how many of your own deliberate extractions you can see.
3. For each one you find, check the seven fields. Can you name the human, the revision, the route and the time, from the record alone?
4. Try to delete a record as an administrator. If you can, the log is not evidence.
5. Ask for it as an auditor would. "Show me every access to this part number's drawings in the last two years, by named individual." If that takes a developer and a database query, it is not a control, it is an archive.

Whatever fraction you fail is the fraction of your file movement that is currently invisible. That number is the whole business case and it is usually higher than the people responsible expect.

8. Conclusion

The industry solved change auditing because change flows through the business layer, where it can be intercepted. It has not solved file auditing because files flow around that layer by design, through a set of paths that no single extension point observes.

That makes download logging an integration problem rather than a feature request: intent captured at the client, transport observed at the vault, the two correlated into one append-only record, across every route in the map and not merely the obvious one. It is genuinely more work than it sounds, which is why so few organisations have it and why so many discover the absence in the week they are asked to prove something.

The question worth putting to your platform, your integrator and yourself is the one at the top of this paper, and it should be answerable without a project: who took a copy of this drawing, when and by which route? If the answer requires an investigation rather than a query, you do not have file audit. You have change history, and a hope that nobody asks.

And when you ask what it would take to fix, the answer divides along the line this paper has been drawing throughout. On a platform where auditing is a fixed menu, the answer is a vendor roadmap conversation or a compiled customisation with a deployment behind it. On a platform where the model and its behaviour are both configuration, the answer is a package of items and a few days. Compliance requirements do not stop changing, so the capability that matters is not the one that shipped. It is the one you can still add.

---

White paper. PLMClub implements on Aras Innovator; the platform comparison in section 5 is drawn from each vendor's own documentation and community where available, and says plainly where a capability could not be verified rather than assuming its absence. Platform behaviour is as documented in September 2026 and all four vendors change it. If you have a documented download-audit capability we have understated, tell us and we will publish the correction.