What it means
Logs describe observations made by software or devices: an account signed in, a file changed, a request failed, or a connection started. A useful record identifies when and where the observation happened, the actor or object involved, the action, and its result. The record’s meaning depends on the system producing it. A successful authentication record establishes that a credential was accepted; it does not establish who physically used it. Collection delays and missing fields can change how a timeline should be interpreted.
See the idea / Evidence
An event becomes a record.
One application writes an export observation; its copy arrives at a separate collector.
Illustrative test on 2026-09-29. TestDB uses account Ops and job TEST-7. Both clocks use UTC and are synchronized in this example.
01 / 04
Act
TestDB observes job TEST-7 completing an export. That activity is separate from recording it. The local log and collector do not yet contain E42.
More about this step
This is a controlled application test. Completion is the application’s reported outcome, not an independent proof that a recipient received data. Software can act without producing a useful log entry; here the next step explicitly writes one.
Step through at your own pace.
Keep in mindE42 reports what TestDB observed. It does not identify a human, prove authorization, or show where the data went. Other records may be missing, delayed, or inaccurate.
Read the visual, step by step
- Act. TestDB observes job TEST-7 completing an export. That activity is separate from recording it. The local log and collector do not yet contain E42. This is a controlled application test. Completion is the application’s reported outcome, not an independent proof that a recipient received data. Software can act without producing a useful log entry; here the next step explicitly writes one.
- Write. TestDB writes E42 with account Ops, job TEST-7, 200 records, completed status, and event time 02:06:00 UTC. These fields are the application’s observation, not the identity or intent of the person behind Ops. The record remains inside the application’s local log. Its fields describe what, when, source, account, and result for this example. This is an illustrative schema, not a required log format. No secrets or exported record contents are included.
- Collect. A copy of E42 travels to the collector while the local record stays in place. The collector displays it after receipt at 02:06:03 UTC. Event time remains 02:06:00; arrival time does not replace it. The moving token represents the record copy. The observed event preceded collector receipt by three seconds under the example’s synchronized-clock assumption. This delivery is not an alert or a finding. Collection mechanisms, encryption, retries, parsing, and failures are outside this drawing.
- Read. Read E42 as a report: TestDB recorded a completed 200-record export under Ops for TEST-7. Keep the original fields and collection context. Who controlled Ops, whether the export was authorized, and what happened afterwards need other evidence. The two copies remain visible; inspection moves no record and grants no additional certainty. A missing search result is not proof of absence. Check logging health, query scope, clocks, and transformations before reconstructing a larger story.
E42 reports what TestDB observed. It does not identify a human, prove authorization, or show where the data went. Other records may be missing, delayed, or inaccurate.
Flow references: NIST SP 800-92: Log generation, transmission, and storage · OWASP: Logging event attributes and protection
AN ILLUSTRATIVE SCENARIO
Finding who changed a shipping address
A small retailer notices an order redirected after checkout. Web access logs show requests, while application audit logs identify the order and the account that changed its delivery address. The analyst compares both with sign-in records. A shared office IP address alone cannot identify a person. If the application never recorded the change, collecting more firewall logs will not reconstruct that missing business action.
Put it to work
- Choose security questions first, then identify the records needed to answer them. Include application actions as well as operating-system and network events.
- Synchronize clocks and record time zones. Preserve original records alongside parsed fields, and restrict access because logs can contain personal or sensitive information.
- Define retention, collection-health checks, and ownership. Avoid recording passwords, session secrets, or complete sensitive request bodies simply because storage is available.
How to check your work
Perform an approved test action and find its complete record in the destination system. Compare the event time, arrival time, actor, object, outcome, and retained raw data with what actually happened.
Connect the ideas
- Alert
A notification that a rule or model wants a human to look at one or more records.
- Evidence
A record you are willing to cite in a decision, with enough provenance to explain what it can prove.
- Provenance
The recorded origin, collection method, transformations, and completeness limits of a piece of evidence.
- Audit trail
An append-oriented history of security-relevant actions that can be shown to a later reviewer.