Control 2-12-1 of the Essential Cybersecurity Controls (ECC – 2 : 2024) requires organizations to build and document event logging requirements that support detection, investigation, and remediation of security incidents; this post gives Compliance Framework-specific, actionable steps and ready-to-use templates you can drop into policy and operational procedures to meet that requirement.
\n\nLogging is the primary evidence source for detecting intrusions, tracing attacker activity, and meeting regulatory or forensic needs. Without documented event logging requirements, teams lack consistency in what is logged, where logs are stored, how long they are retained, and who reviews them — producing gaps that attackers exploit, causing delayed detection, incomplete investigations, and potential regulatory penalties. For a small business, that can mean prolonged downtime, data loss, and loss of client trust that a single breach can amplify.
\n\nStart by creating a catalog of event types required by Control 2-12-1. At minimum capture: authentication success/failure, privilege escalations, user and admin account changes, configuration changes on critical systems, access to sensitive data, system start/stop, firewall allow/deny, and anti-malware alerts. Each log entry should include a standardized set of fields: timestamp (ISO 8601 + timezone), hostname/service, component (application/process), event_id, event_type, username/account, source_ip/dest_ip, source_port/dest_port, protocol, severity, outcome (success/failure), and message. Use structured formats (JSON or CEF) and align to syslog RFC5424 if using syslog transport.
\n\nCentralize logs to a dedicated collector or SIEM to prevent local log tampering. For Compliance Framework environments, require encrypted in-transit transport (TLS 1.2+ for syslog over TLS, HTTPS for API ingestion) and ensure at-rest encryption (AES-256 or equivalent). Use authenticated log forwarding (mutual TLS or API keys) and restrict write access to log buckets. Examples: Windows Event Forwarding (WEF) to a Windows collector that forwards to a SIEM; Linux auditd -> filebeat -> centralized Elastic/Cloud SIEM; cloud logs shipped from AWS CloudWatch Logs to a KMS-encrypted S3 bucket with lifecycle rules. Enable immutability or WORM where legal/regulatory requirements dictate.
\n\nDocument retention periods per log type in a retention matrix (example templates below). A practical baseline for small businesses could be: 90 days for system logs and web server access logs for operational troubleshooting; 1 year for authentication and security logs; 3+ years for logs tied to regulated data or legal holds. Implement log rotation (size/time-based), central index pruning, and lifecycle policies to move older logs to cheaper storage. Ensure log integrity with periodic hashing and automated tamper checks (store hashes separately or in an append-only ledger). Enforce accurate timestamps by synchronizing all systems to an internal NTP pool or reliable external NTP servers and validate timezone handling to keep audit trails consistent.
\n\nDefine who reviews logs, the frequency of reviews, and the escalation path. For small businesses, assign Tier 1 to an IT generalist for high-confidence alerts (account lockouts, multiple failed logins), and a responsible security lead for incident validation. Implement automated detection rules in your SIEM with threshold-based and behavioral detections (e.g., multiple privileged actions from a single admin account in a short window). Maintain alert tuning to reduce false positives; map alerts to documented playbooks that specify containment, evidence collection, and notification steps. Include periodic tabletop exercises to validate that logs are comprehensive and useful during investigations.
\n\nBelow are three templates you can copy into your policy repository and adapt. Each template is intentionally concise so it can be included in formal documentation, audit artifacts, or operational runbooks.
\n\n# Event Logging Requirements - Control 2-12-1 (Compliance Framework)\nlogging_policy_version: \"1.0\"\neffective_date: \"2026-01-01\"\nowner: \"IT Security Lead\"\nscope: \"All production systems, network devices, cloud infrastructure, and security appliances\"\n\nrequired_event_categories:\n - authentication: [\"login_success\",\"login_failure\",\"account_lockout\",\"password_reset\"]\n - authorization: [\"privilege_escalation\",\"role_assignment\",\"group_membership_change\"]\n - system: [\"system_start\",\"system_shutdown\",\"service_install\",\"service_remove\"]\n - configuration: [\"config_change\",\"patch_apply\",\"kernel_update\"]\n - data_access: [\"sensitive_data_read\",\"sensitive_data_export\",\"file_delete\"]\n - network: [\"fw_allow\",\"fw_block\",\"vpn_connect\",\"vpn_disconnect\"]\n - security: [\"antivirus_alert\",\"malware_detected\",\"ids_alert\",\"sudo_command\"]\n\nminimum_fields:\n - timestamp_iso8601\n - timezone\n - hostname\n - component\n - event_id\n - event_type\n - username\n - src_ip\n - dst_ip\n - src_port\n - dst_port\n - protocol\n - severity\n - outcome\n - message\nlog_format: \"JSON | RFC5424-compatible syslog\"\ntransit_encryption: \"TLS 1.2+ (mutual TLS where possible)\"\nat_rest_encryption: \"AES-256 (KMS-managed keys)\"\nintegrity: \"SHA-256 hashes stored separately; weekly integrity checks\"\n# FieldName,Description,Format,Example,Required\ntimestamp_iso8601,\"Event timestamp in ISO 8601 with timezone\",\"YYYY-MM-DDThh:mm:ssZ\",\"2026-04-21T14:05:30+00:00\",Yes\nhostname,\"FQDN or inventory hostname\",\"string\",\"web01.example.local\",Yes\ncomponent,\"Application or service name\",\"string\",\"nginx\",Yes\nevent_id,\"Vendor or app-specific event identifier\",\"string\",\"EVT-1003\",Yes\nevent_type,\"Category from policy (authentication, system, etc.)\",\"string\",\"authentication\",Yes\nusername,\"Account name or service account\",\"string\",\"alice.smith\",Conditional\nsrc_ip,\"Source IPv4/IPv6\",\"IP\",\"203.0.113.45\",Conditional\ndst_ip,\"Destination IPv4/IPv6\",\"IP\",\"10.0.1.12\",Conditional\nseverity,\"Low/Medium/High/Critical or numeric score\",\"string\",\"High\",Yes\noutcome,\"success/failure/unknown\",\"string\",\"failure\",Yes\nmessage,\"Human-readable event description\",\"string\",\"User failed password attempt\",Yes\n# LogType,StorageLocation,RetentionDays,AccessRestrictions,LegalHoldPolicy\nauthentication_logs,central-siem-s3,365,\"security-team-only, RBAC enforced\",\"retain until release by legal\"\nsystem_event_logs,central-siem-s3,90,\"it-team, readonly for security\",\"N/A\"\nfirewall_logs,fw-collector-s3,365,\"security & network admins\",\"retain 3 years if tied to incident\"\napplication_audit,app-audit-bucket,730,\"app-owner, security-read\",\"apply legal hold when requested\"\nExample: a 50-employee SaaS company with 2 Linux web servers, 1 Windows domain controller, cloud-hosted PostgreSQL, and a managed firewall. Use the Event Logging Requirements Template to mandate that the Windows DC forwards authentication events via WEF to a central Windows collector; deploy filebeat on Linux hosts to ship auditd and nginx access logs to a cloud SIEM; configure the firewall to send logs over syslog/TLS to the same collector. Set retention per the matrix: 365 days for authentication/firewall logs, 90 days for system logs. Use simple SIEM rules: trigger an alert when an account has 5 failed logins in 10 minutes or when a privileged role change occurs. Document roles: IT generalist performs daily dashboard checks; Security Lead reviews high severity alerts and runs the incident playbook. Without these steps you face slow detection, incomplete evidence capture (e.g., missing src_ip or timestamp drift), and likely fail a compliance audit for Control 2-12-1.
\n\nSummary — implement the templates early, iterate quickly, and make logging a living part of your Compliance Framework: document the event types and minimum fields, centralize and secure log transport and storage, define retention for each log class, enforce integrity and time sync, and operationalize monitoring with clear roles and playbooks. Doing so will close common gaps auditors look for under ECC – 2 : 2024 Control 2-12-1 and materially improve your organization's ability to detect and respond to security incidents.
", "plain_text": "Control 2-12-1 of the Essential Cybersecurity Controls (ECC – 2 : 2024) requires organizations to build and document event logging requirements that support detection, investigation, and remediation of security incidents; this post gives Compliance Framework-specific, actionable steps and ready-to-use templates you can drop into policy and operational procedures to meet that requirement.\n\nWhy clear logging requirements matter (and the risk of not implementing them)\nLogging is the primary evidence source for detecting intrusions, tracing attacker activity, and meeting regulatory or forensic needs. Without documented event logging requirements, teams lack consistency in what is logged, where logs are stored, how long they are retained, and who reviews them — producing gaps that attackers exploit, causing delayed detection, incomplete investigations, and potential regulatory penalties. For a small business, that can mean prolonged downtime, data loss, and loss of client trust that a single breach can amplify.\n\nPractical, Compliance Framework–specific implementation steps\n1) Define what to log and the minimum fields\nStart by creating a catalog of event types required by Control 2-12-1. At minimum capture: authentication success/failure, privilege escalations, user and admin account changes, configuration changes on critical systems, access to sensitive data, system start/stop, firewall allow/deny, and anti-malware alerts. Each log entry should include a standardized set of fields: timestamp (ISO 8601 + timezone), hostname/service, component (application/process), event_id, event_type, username/account, source_ip/dest_ip, source_port/dest_port, protocol, severity, outcome (success/failure), and message. Use structured formats (JSON or CEF) and align to syslog RFC5424 if using syslog transport.\n\n2) Centralize collection and secure transport/storage\nCentralize logs to a dedicated collector or SIEM to prevent local log tampering. For Compliance Framework environments, require encrypted in-transit transport (TLS 1.2+ for syslog over TLS, HTTPS for API ingestion) and ensure at-rest encryption (AES-256 or equivalent). Use authenticated log forwarding (mutual TLS or API keys) and restrict write access to log buckets. Examples: Windows Event Forwarding (WEF) to a Windows collector that forwards to a SIEM; Linux auditd -> filebeat -> centralized Elastic/Cloud SIEM; cloud logs shipped from AWS CloudWatch Logs to a KMS-encrypted S3 bucket with lifecycle rules. Enable immutability or WORM where legal/regulatory requirements dictate.\n\n3) Retention, rotation, integrity and time synchronization\nDocument retention periods per log type in a retention matrix (example templates below). A practical baseline for small businesses could be: 90 days for system logs and web server access logs for operational troubleshooting; 1 year for authentication and security logs; 3+ years for logs tied to regulated data or legal holds. Implement log rotation (size/time-based), central index pruning, and lifecycle policies to move older logs to cheaper storage. Ensure log integrity with periodic hashing and automated tamper checks (store hashes separately or in an append-only ledger). Enforce accurate timestamps by synchronizing all systems to an internal NTP pool or reliable external NTP servers and validate timezone handling to keep audit trails consistent.\n\n4) Monitoring, alerting and operational roles\nDefine who reviews logs, the frequency of reviews, and the escalation path. For small businesses, assign Tier 1 to an IT generalist for high-confidence alerts (account lockouts, multiple failed logins), and a responsible security lead for incident validation. Implement automated detection rules in your SIEM with threshold-based and behavioral detections (e.g., multiple privileged actions from a single admin account in a short window). Maintain alert tuning to reduce false positives; map alerts to documented playbooks that specify containment, evidence collection, and notification steps. Include periodic tabletop exercises to validate that logs are comprehensive and useful during investigations.\n\nReady-to-use templates (drop into your Compliance Framework documentation)\nBelow are three templates you can copy into your policy repository and adapt. Each template is intentionally concise so it can be included in formal documentation, audit artifacts, or operational runbooks.\n\nEvent Logging Requirements Template (YAML-style)\n# Event Logging Requirements - Control 2-12-1 (Compliance Framework)\nlogging_policy_version: \"1.0\"\neffective_date: \"2026-01-01\"\nowner: \"IT Security Lead\"\nscope: \"All production systems, network devices, cloud infrastructure, and security appliances\"\n\nrequired_event_categories:\n - authentication: [\"login_success\",\"login_failure\",\"account_lockout\",\"password_reset\"]\n - authorization: [\"privilege_escalation\",\"role_assignment\",\"group_membership_change\"]\n - system: [\"system_start\",\"system_shutdown\",\"service_install\",\"service_remove\"]\n - configuration: [\"config_change\",\"patch_apply\",\"kernel_update\"]\n - data_access: [\"sensitive_data_read\",\"sensitive_data_export\",\"file_delete\"]\n - network: [\"fw_allow\",\"fw_block\",\"vpn_connect\",\"vpn_disconnect\"]\n - security: [\"antivirus_alert\",\"malware_detected\",\"ids_alert\",\"sudo_command\"]\n\nminimum_fields:\n - timestamp_iso8601\n - timezone\n - hostname\n - component\n - event_id\n - event_type\n - username\n - src_ip\n - dst_ip\n - src_port\n - dst_port\n - protocol\n - severity\n - outcome\n - message\nlog_format: \"JSON | RFC5424-compatible syslog\"\ntransit_encryption: \"TLS 1.2+ (mutual TLS where possible)\"\nat_rest_encryption: \"AES-256 (KMS-managed keys)\"\nintegrity: \"SHA-256 hashes stored separately; weekly integrity checks\"\n\n\nLog Field Definition Template (CSV-style)\n# FieldName,Description,Format,Example,Required\ntimestamp_iso8601,\"Event timestamp in ISO 8601 with timezone\",\"YYYY-MM-DDThh:mm:ssZ\",\"2026-04-21T14:05:30+00:00\",Yes\nhostname,\"FQDN or inventory hostname\",\"string\",\"web01.example.local\",Yes\ncomponent,\"Application or service name\",\"string\",\"nginx\",Yes\nevent_id,\"Vendor or app-specific event identifier\",\"string\",\"EVT-1003\",Yes\nevent_type,\"Category from policy (authentication, system, etc.)\",\"string\",\"authentication\",Yes\nusername,\"Account name or service account\",\"string\",\"alice.smith\",Conditional\nsrc_ip,\"Source IPv4/IPv6\",\"IP\",\"203.0.113.45\",Conditional\ndst_ip,\"Destination IPv4/IPv6\",\"IP\",\"10.0.1.12\",Conditional\nseverity,\"Low/Medium/High/Critical or numeric score\",\"string\",\"High\",Yes\noutcome,\"success/failure/unknown\",\"string\",\"failure\",Yes\nmessage,\"Human-readable event description\",\"string\",\"User failed password attempt\",Yes\n\n\nRetention and Handling Matrix (table-style plain text)\n# LogType,StorageLocation,RetentionDays,AccessRestrictions,LegalHoldPolicy\nauthentication_logs,central-siem-s3,365,\"security-team-only, RBAC enforced\",\"retain until release by legal\"\nsystem_event_logs,central-siem-s3,90,\"it-team, readonly for security\",\"N/A\"\nfirewall_logs,fw-collector-s3,365,\"security & network admins\",\"retain 3 years if tied to incident\"\napplication_audit,app-audit-bucket,730,\"app-owner, security-read\",\"apply legal hold when requested\"\n\n\nApplying templates in a small-business scenario\nExample: a 50-employee SaaS company with 2 Linux web servers, 1 Windows domain controller, cloud-hosted PostgreSQL, and a managed firewall. Use the Event Logging Requirements Template to mandate that the Windows DC forwards authentication events via WEF to a central Windows collector; deploy filebeat on Linux hosts to ship auditd and nginx access logs to a cloud SIEM; configure the firewall to send logs over syslog/TLS to the same collector. Set retention per the matrix: 365 days for authentication/firewall logs, 90 days for system logs. Use simple SIEM rules: trigger an alert when an account has 5 failed logins in 10 minutes or when a privileged role change occurs. Document roles: IT generalist performs daily dashboard checks; Security Lead reviews high severity alerts and runs the incident playbook. Without these steps you face slow detection, incomplete evidence capture (e.g., missing src_ip or timestamp drift), and likely fail a compliance audit for Control 2-12-1.\n\nSummary — implement the templates early, iterate quickly, and make logging a living part of your Compliance Framework: document the event types and minimum fields, centralize and secure log transport and storage, define retention for each log class, enforce integrity and time sync, and operationalize monitoring with clear roles and playbooks. Doing so will close common gaps auditors look for under ECC – 2 : 2024 Control 2-12-1 and materially improve your organization's ability to detect and respond to security incidents." }, "metadata": { "description": "Step-by-step guidance and ready-to-use templates to define, implement, secure, and document event logging requirements to meet Control 2-12-1 of ECC – 2 : 2024.", "permalink": "/how-to-build-and-document-event-logging-requirements-with-ready-to-use-templates-essential-cybersecurity-controls-ecc-2-2024-control-2-12-1.json", "categories": [], "tags": [] } }