KSI-MLA-LET—Logging Event Types
Formerly KSI-MLA-07
>Control Description
>NIST 800-53 Controls
>Trust Center Components3
Ways to express your implementation of this indicator — approaches vary by organization size, complexity, and data sensitivity.
From the field: Mature implementations express log transparency as a product feature — complete log event taxonomy published as machine-readable schemas, customer-facing APIs for log export and SIEM integration, and log access verified through automated endpoint testing. Audit trail transparency becomes a measurable service backed by API documentation and integration guides.
Customer Audit Log Access
Customer-facing audit log access and export as a product feature — API-based log export with SIEM integration support
Log Event Types Documentation
Complete log event taxonomy expressing all logged event types, formats, and field schemas
Log Retention and Export
Human-readable log retention periods and customer log export options
>Programmatic Queries
CLI Commands
aws cloudtrail get-trail-status --name <trail-name> --query "{Logging:IsLogging,LatestDelivery:LatestDeliveryTime}" --output tableaws cloudtrail lookup-events --max-results 50 --query "Events[].EventName" --output text | tr '\t' '\n' | sort -u>20x Assessment Focus Areas
Aligned with FedRAMP 20x Phase Two assessment methodology
Completeness & Coverage:
- •Does your logging event type list include all security-relevant events — authentication, authorization, privilege changes, data access, configuration changes, and administrative actions?
- •Are there information resources where certain event types are not logged due to technical limitations or cost constraints, and how are those gaps documented?
- •How do you ensure the event type list covers events from all layers — application, infrastructure, network, identity, and data?
- •When new resources or services are deployed, what process ensures they are added to the logging scope with appropriate event types before going live?
Automation & Validation:
- •What automated checks validate that every resource on your list is actually sending the defined event types to your logging system?
- •How do you detect when logging stops for a resource — if a log pipeline breaks or a resource stops emitting expected events?
- •What alerting fires when there is a gap between the documented event type list and what is actually being collected?
- •How do you validate that logged events contain sufficient detail (who, what, when, where, outcome) for security analysis?
Inventory & Integration:
- •How do you maintain the mapping between each information resource and its required event types — is this a machine-readable inventory or a manual document?
- •What tools auto-discover new resources and compare them against the required logging configuration?
- •How does your event type list integrate with your SIEM ingestion configuration to ensure all required events are parsed and indexed?
- •Are logging configurations for each resource type defined as code and applied automatically during provisioning?
Continuous Evidence & Schedules:
- •How frequently is the event type list reviewed and updated, and what evidence proves each review occurred?
- •Is logging coverage data (percentage of resources logging all required event types) available via API or dashboard?
- •How do you demonstrate that logging, monitoring, and auditing have been continuous and gap-free over the past 90 days?
- •What evidence shows the event type list has been updated in response to new threats, new resources, or past incidents that revealed logging gaps?
Update History
Ask AI
Configure your API key to use AI features.