Centralized logging and Security Information and Event Management (SIEM) are core requirements of Essential Cybersecurity Controls (ECC – 2 : 2024), specifically Control 2-12-3, which requires consistent collection, retention, and monitoring of security-relevant events to enable detection, investigation, and compliance reporting; this post shows how to design and implement a practical SIEM architecture for a small business operating under the "Compliance Framework" while staying cost-effective and audit-ready.
Why centralized logging is required by Compliance Framework (ECC 2-12-3)
ECC 2-12-3 emphasizes that organizations must collect and retain logs from critical systems, network devices, security controls, and identity services so that security events can be reconstructed and audited. For a small business, centralized logging is not just a best practice — it is the foundation for proving to auditors that security events are visible, correlated, and actionable. The Control expects log integrity, time synchronization, defined retention periods, and the ability to produce evidence or reports on demand.
Key components of a compliant SIEM architecture
A practical SIEM stack for Compliance Framework must include: reliable log sources (endpoints, AD/IdP, firewalls, proxies, cloud APIs), secure transport (TLS-encrypted syslog/HTTPS), an ingestion/normalization layer (beats/agents or cloud collectors), centralized storage with retention tiers, correlation and rule engine, alerting/incident workflows, and audit/reporting capabilities. Implementation notes for ECC alignment: document the sources required by the control, map each source to a retention policy, and use immutable storage or append-only logging where possible for evidentiary integrity.
Step-by-step implementation for a small business
Start with an inventory and risk-based scope: list asset classes, identify the top 20 business-critical assets (domain controllers, email, VPN, web servers, cloud consoles), and decide which events must be captured (authentication success/failure, privilege changes, configuration changes, security product alerts, data exfiltration indicators). Practical rollout plan: 1) deploy time sync (NTP) across the estate, 2) deploy lightweight agents (Filebeat/Winlogbeat/NXLog) or enable native cloud forwarding (CloudTrail, Azure Activity Logs, Microsoft 365 Audit Logs), 3) configure a central collector (Elastic, Splunk, Azure Sentinel, or a managed SIEM) with TLS and mutual authentication, 4) implement parsing/normalization and initial detection rules that map back to ECC 2-12-3 objectives, and 5) define retention, access controls, and audit logging for the SIEM itself.
Technical specifics: for Windows endpoints use Winlogbeat or Microsoft Defender for Endpoint connector; for Linux servers use Filebeat with module configs for syslog, auth, sudo, and auditd. Forward network device logs via TLS-encrypted syslog (RFC 5425) and tag each event with source and environment metadata. Normalize timestamps to UTC and use ISO 8601. Retention sizing: plan for "hot" indexes covering 30–90 days for fast search, "warm" 90–365 days for compliance queries, and cold/archival storage (S3 Glacier or object store) for multi-year retention if required by law or policy; compress and encrypt archived logs and maintain a key management policy aligned with Compliance Framework guidance.
Detection, correlation, and playbooks
ECC 2-12-3 expects active monitoring, so build detection rules that align to real-world threats: correlate repeated failed logins across multiple hosts into a single account brute-force alert; trigger an alert when a low-privileged account suddenly adds an admin group membership; detect data exfiltration by correlating large outbound transfers with unusual hours and failed DLP policy matches. For small teams, script automated enrichment (WHOIS, GeoIP, threat intel) and integrate alerting into a single incident channel (Slack/MS Teams) with a playbook that documents triage steps, evidence collection, and escalation consistent with your incident response policy.
Consider managed options: a small business with limited security staff can leverage cloud-managed SIEM (Azure Sentinel, Elastic Cloud, Splunk Cloud) or MSSP services to meet ECC timelines and reporting needs while preserving evidence integrity. When using managed services, ensure contractual SLAs cover retention, data exportability (so you can produce raw logs for audits), and encryption key control where required by the Compliance Framework.
Risks and consequences of not implementing ECC 2-12-3 controls
Failing to centralize logs and monitor events exposes an organization to prolonged dwell time of attackers, missed indicators of compromise, and inability to demonstrate compliance during audits — which can lead to regulatory penalties, lost customer trust, and legal exposure. From a technical standpoint, lack of centralized logs means you cannot efficiently reconstruct timeline-based evidence for an incident, increasing forensic costs and reducing the effectiveness of remediation efforts.
Summary: Building a centralized SIEM architecture to satisfy ECC 2-12-3 is achievable for small businesses by scoping critical log sources, securing transport and storage, applying normalization and correlation, and operationalizing alerts and playbooks; combine technical controls (TLS syslog, agents, NTP, retention tiers, WORM/immutable storage) with policy controls (logging policy, retention schedule, access controls, and evidence export capability) to meet Compliance Framework expectations and reduce organizational risk.
