Skip to content
Skip to main content
Logs, Records & Provider Evidence Technical Explainer

Could a script or application generate the event?

Yes. Software can perform many recorded actions after one trigger, with no separate human decision for each event. Repetition, regular timing and common process ancestry often indicate this kind of automation.

One launch can produce a broad activity trail

A script or application may create files, query databases, call APIs, send messages, change settings and connect to multiple services. It may start through direct input, an application event, a scheduled task or a background service.

Logs may name the account under which it ran rather than its author, operator or approver. Parent and child processes are especially useful for distinguishing the initiating program from the actions it generated.

Recover the automation and its trigger

Preserve executable and script paths, command-line arguments, hashes, process ancestry, configuration, task definitions and linked request identifiers. Source code or scripts can show intended behaviour, while runtime records show what occurred in that instance.

Keep attribution questions distinct: who wrote or configured the automation, who or what launched it, and which actions followed automatically. Evidence may answer some of those questions without resolving all of them.

The point to remember

Trace software-generated events back through process ancestry and triggers before treating them as separate human actions.

Reference: LOG-077Logs, Records & Provider Evidence