Centralized Security Logging Is Not Finished Until You Can Use the Evidence
When I review centralized security logging, I want more than confirmation that a destination exists.
I want to know whether the right evidence reaches it, whether an investigator can retrieve that evidence, and whether the organization will notice when the process breaks.
That distinction matters because configuration, delivery, and investigation readiness are different things.
A configuration response can confirm that a service accepted an export destination. It cannot, by itself, prove that the full evidence path works.
Define the question before collecting the data
I start with the investigation questions:
Who changed a permission?
Which identity accessed a sensitive resource?
What did the application record around the event?
Which detection fired, and what evidence supports it?
Different sources answer different questions. An exported security finding is not a replacement for the underlying activity records.
For example, AWS documents GuardDuty exports as generated findings. Its export settings are regional, and S3 delivery depends on appropriate bucket and encryption-key permissions. Those details belong in the validation plan—not just the installation instructions. GuardDuty export documentation. Amazon GuardDuty
Build a coverage register
I recommend maintaining a small register with:
FieldWhat it establishesSource and scopeWhich service, account, and region should contributeExpected event typeWhat evidence the source should produceDestinationWhere the evidence should arriveDelivery expectationWhen evidence should be availableValidation evidenceWhat was checked and whenOwnerWho investigates a failure
Separate “configured” from “delivery verified.” If a source has not produced an expected event, mark delivery as unverified rather than assuming success.
A quiet environment is not automatically broken. An empty destination is not automatically healthy, either.
Use new coverage tools without overreading them
On September 30, 2026, AWS introduced CloudTrail Event Coverage to show which supported services and resource types have data-event logging enabled at account and organization scope.
That is useful for finding configuration gaps. I would use it as an input to a wider review—not as proof that every required record arrived, remained readable, or supported a detection. AWS’s announcement lists availability in commercial Regions where CloudTrail is supported. AWS announcement. AWS
Walk through the evidence path
Here is a reproducible validation exercise I would use in an approved test scope:
Select one event that the chosen source is documented to record.
Perform a harmless, authorized action with an identifiable timestamp.
Confirm that the source recorded the expected event.
Locate the corresponding record in the central destination.
Retrieve it using the intended investigator role.
Record the result, observed delay, and any missing fields.
This is a proposed exercise, not a claim that I tested it in your environment. Event selection and expected timing must match the service.
For finding exports, use a documented sample-generation method only after confirming its export behavior. Do not create a real security incident to test collection.
Verify integrity separately
CloudTrail provides another useful distinction: enabling log-file integrity validation causes digest delivery, but does not itself execute validation of the files.
Where this feature is part of the design, I would retain evidence that validation actually ran—not merely that the setting was enabled. CloudTrail integrity-validation documentation. AWS CloudTrail
Design access and retention around actual use
Least privilege means separating permissions to publish evidence, investigate it, and administer its storage or encryption.
Defense in depth means checking configuration, delivery, retrieval, and integrity independently.
For retention, I would document the investigation needs, applicable obligations, storage cost, and acceptable retrieval delay before choosing durations. A long archive period has limited operational value if nobody knows how to restore and query the records.
I apply Zero Trust by checking the evidence path rather than trusting a successful deployment.
Make completion measurable
My acceptance criteria would include:
Required sources and event types are documented.
Delivery is verified in the intended scope.
Investigators can retrieve usable records.
Failures have an owner and escalation path.
Retention and archive retrieval are documented.
Validation is repeated after material changes.
Centralization is valuable when it produces evidence people can use.
Explore related work in my Security Engineering Case Studies.