UTMStack

Articles, updated 12 min read

SIEM Compliance Requirements: Logging Rules by Framework

By UTMStack Team

Every security framework an auditor brings up, from the Payment Card Industry Data Security Standard (PCI DSS) to the Health Insurance Portability and Accountability Act (HIPAA) and ISO/IEC 27001, the international standard for security management, ends up asking the same questions. Do you record what happens on your systems? Does anyone look at those records? Would you notice an attack, and could you prove afterwards what happened? Almost none of these rules use the word “SIEM”. But once you run more than a handful of systems, a security information and event management (SIEM) system is how most organizations answer those questions with evidence instead of promises.

This guide lists the clauses that drive logging and monitoring in the frameworks most organizations face, what each one asks for, how long each expects you to keep logs, and what a SIEM can and cannot do for an audit.

The short answer: No major framework requires a product called a SIEM. They require what a SIEM does: collect security logs from every in-scope system, protect them from change, review them regularly, detect and respond to suspicious activity, and keep them for a set time. PCI DSS Requirement 10, the HIPAA audit controls standard (45 CFR 164.312(b) in the Code of Federal Regulations), National Institute of Standards and Technology (NIST) SP 800-171 family 3.3 (used by the Cybersecurity Maturity Model Certification, CMMC), ISO/IEC 27001:2022 Annex A 8.15 and 8.16, System and Organization Controls (SOC) 2 criterion CC7.2, Articles 32 and 33 of the General Data Protection Regulation (GDPR), the Gramm-Leach-Bliley Act (GLBA) Safeguards Rule at 16 CFR 314.4(c)(8) and the NIST SP 800-53 Audit and Accountability (AU) family and SI-4 all point the same way. Few of them set a retention number. PCI DSS does: 12 months.

Why auditors care about logs

Logs are the record of who did what, when and from where. In an audit they do four jobs:

  1. Prove that controls work. A policy says only administrators can change firewall rules. The logs show who actually did.
  2. Support investigations. After an incident, logs are often the only way to establish what was accessed, and that decides who must be notified.
  3. Detect incidents early. Frameworks expect you to notice problems, not only to record them. Under HIPAA, a breach counts as discovered on the first day it would have been known with reasonable diligence (45 CFR 164.404(a)(2)). Logs that nobody reads do not stop that clock.
  4. Reduce risk. Logs reveal failed controls, misconfigurations and policy violations before they turn into incidents.

What auditors check, whatever the framework

Five capabilities, with example clauses that require each one

  1. CollectLog the right events on every in-scope system. PCI 10.2, HIPAA 164.312(b), NIST 800-171 3.3.1, ISO 8.15
  2. ProtectLimit access, block changes, sync clocks. PCI 10.3, NIST 800-171 3.3.8, ISO 8.17
  3. ReviewLook at logs regularly, and correlate across systems. PCI 10.4.1.1, HIPAA 164.308(a)(1)(ii)(D), NIST 800-171 3.3.5
  4. Detect and reportAlert on anomalies and handle incidents. SOC 2 CC7.2, NIST 800-53 SI-4, GLBA 314.4(c)(8), GDPR Art. 33
  5. RetainKeep logs long enough to investigate and to prove it. PCI 10.5.1, NIST 800-53 AU-11
Review is the step that usually forces a tool: correlation across systems and automated daily review are hard to do by hand.

The logging clauses in each framework

FrameworkClauses that drive logging and monitoringWhat they ask forLog retention rule
PCI DSS v4.0.1Requirement 10 (10.2 to 10.7)Log all access to cardholder data and system components, protect logs, review them daily with automated tools, detect failed security controls12 months, last 3 immediately available (10.5.1)
HIPAA Security Rule45 CFR 164.312(b) audit controls; 164.308(a)(1)(ii)(D) information system activity review; 164.308(a)(5)(ii)(C) log-in monitoring; 164.308(a)(6)(ii) response and reportingRecord and examine activity in systems with electronic patient data, review it regularly, monitor log-in attempts, handle incidentsNone for logs; 6 years for required documentation (164.316(b)(2)(i))
CMMC Level 2 / NIST SP 800-171 Rev 23.3.1 to 3.3.9; also 3.14.6 and 3.14.7Create and keep logs, trace actions to users, correlate review, alert on logging failure, monitor for attacksNone set; keep monitoring data 90 days after reporting an incident (Defense Federal Acquisition Regulation Supplement, DFARS 252.204-7012)
NIST SP 800-53 Rev 5AU family (AU-2 event logging, AU-6 review, AU-11 retention, AU-12 generation); SI-4 system monitoringThe full federal control set for logging and monitoringSet by the organization; federal civilian agencies follow OMB M-26-14
ISO/IEC 27001:2022Annex A 8.15 logging; 8.16 monitoring activities; 8.17 clock synchronizationProduce, protect and analyze logs; monitor networks and systems for abnormal behaviorNone set; defined in your own policy
SOC 2Trust Services Criteria CC7.2 (with CC7.3 and CC7.4)Monitor system components for anomalies, evaluate security events, respond to incidentsNone set; auditors test evidence across the report period
GDPRArticle 32 security of processing; Article 33 breach notificationAppropriate security, ability to detect a breach and report it within 72 hours, record every breach (33(5))No minimum; personal data kept no longer than necessary (Article 5(1)(e))
GLBA Safeguards Rule16 CFR 314.4(c)(8); 314.4(d)(2); 314.4(j)Monitor and log authorized users’ activity, continuous monitoring (or yearly penetration tests and twice-yearly scans), tell the Federal Trade Commission (FTC) within 30 days of an event affecting 500 or more consumersNone set
NIST Cybersecurity Framework (CSF) 2.0PR.PS-04; DE.CM; DE.AE-03Generate logs for monitoring, monitor assets continuously, correlate information from multiple sourcesNone set

A few notes on the table:

  • PCI DSS made automated log review mandatory on March 31, 2025, under requirement 10.4.1.1. Our PCI DSS logging requirements guide walks through every item in Requirement 10.
  • CMMC Level 2 is built on NIST SP 800-171 Revision 2, not the newer Revision 3. Requirement 3.3.5, correlating log review across systems, is worth 5 points and cannot be deferred to a plan of action. See CMMC SIEM requirements for the scoring detail.
  • SOC 2 never lists events or a retention period. Our SOC 2 logging requirements guide maps each criterion to the logs and evidence auditors ask for.
  • NIST CSF 2.0 is voluntary, but its own implementation example for DE.AE-03 suggests event correlation technology such as a SIEM. That is the closest any of these documents comes to naming the product category.
  • Federal agencies follow NIST SP 800-53 under the Federal Information Security Modernization Act (FISMA). In May 2026, Office of Management and Budget (OMB) memo M-26-14 replaced the older logging memo M-21-31 and lists a SIEM as one way to give the agency’s security operations center access to logs.

Why a SIEM ends up being the answer

You can meet some logging rules with native tools. You can switch on Windows auditing, forward syslog to a server and keep the files for a year. Four requirements are where that approach usually breaks:

  • Correlation across systems. NIST SP 800-171 3.3.5 and NIST CSF DE.AE-03 ask you to analyze events from different sources together. A password spray that hits the virtual private network (VPN) and then email in the same hour only shows up when both logs sit in one place.
  • Automated daily review. PCI DSS 10.4.1.1 requires automated mechanisms for audit log reviews. Reading logs by hand no longer passes.
  • Alerts when logging stops. PCI DSS 10.7, NIST SP 800-171 3.3.4 and NIST SP 800-53 AU-5 all expect you to notice when a system stops sending logs.
  • Fast answers during an incident. GDPR gives you 72 hours to notify the regulator where feasible. The GLBA Safeguards Rule gives 30 days for the FTC notice. You cannot scope a breach in that time if the evidence is spread across fifty servers.

What to log for compliance

The frameworks differ in wording but agree on the events that matter. This list covers the common ground:

  • Sign-ins, successful and failed, for users and administrators (PCI DSS 10.2.1.4, HIPAA log-in monitoring).
  • Administrative actions and privilege changes (PCI DSS 10.2.1.2 and 10.2.1.5).
  • Account creation, change and removal (PCI DSS 10.2.1.5).
  • Access to regulated data: cardholder data, patient records, controlled unclassified information (CUI) or customer records (PCI DSS 10.2.1.1, HIPAA 164.312(b), GLBA 314.4(c)(8)).
  • Changes to logging itself: logs started, stopped or paused, and any access to the logs (PCI DSS 10.2.1.3 and 10.2.1.6).
  • Network connections from firewalls, VPNs and cloud flow logs, with source, destination, port and protocol.
  • Alerts from security tools such as endpoint protection, intrusion detection and email security.
  • Changes to systems: new devices, configuration changes and software installs.

Every record needs enough detail to stand on its own. PCI DSS 10.2.2 lists six details: user, type of event, date and time, success or failure, origin, and the affected data, system or resource. That is a good standard for any framework.

How long to keep logs

Who sets a log retention period, and who leaves it to you

Retention rules in the frameworks covered in this guide

Sets a log periodPCI DSS 10.5.112 months, with the last 3 months immediately available
Sets a log periodOMB M-26-14Federal civilian agencies: 6 months searchable, 12 months retrievable
Sets a related periodHIPAA 164.316(b)(2)(i)6 years for required documentation, not for raw logs
Sets a related periodDFARS 252.204-7012Keep monitoring data 90 days after reporting a cyber incident
No numberISO 27001, SOC 2, NIST 800-171, GLBAYou set the period in policy, and auditors check that you follow it
No minimumGDPR Article 5(1)(e)Personal data in logs kept no longer than necessary
Sources: PCI DSS v4.0.1, OMB M-26-14 (May 22, 2026), 45 CFR 164.316, 48 CFR 252.204-7012 and GDPR.

Most frameworks leave retention to you, which means two things. Write the period down, and make sure your tools actually enforce it. Many organizations choose 12 months as a floor because it meets PCI DSS and covers a full audit year. Healthcare organizations often keep audit evidence longer because of the 6-year documentation rule; our guide to HIPAA log retention requirements explains how to separate raw logs from the reports that must last six years.

The federal number changed this year. OMB M-21-31, issued in 2021, had pushed agencies to keep most logs 12 months in active storage plus 18 months in cold storage. M-26-14 rescinded it on May 22, 2026, noting that keeping vast amounts of log data without clear use had proved neither feasible nor cost-effective for most agencies. The new minimum is 6 months searchable and 12 months retrievable, with details in the Logging Reference Architecture that the Cybersecurity and Infrastructure Security Agency (CISA) published in August 2026.

What a SIEM does not do for compliance

A SIEM produces evidence. It does not make you compliant, and auditors know the difference.

  • It does not write policies or do your risk analysis, training or vendor contracts.
  • It only sees what you send it. A missing domain controller or cloud account is a gap in your evidence, whatever the dashboard says.
  • It is in scope itself. Who can sign in to the SIEM, whether multi-factor authentication is on and whether logs can be deleted are all audit questions (PCI DSS 10.3, NIST SP 800-171 3.3.8 and 3.3.9).
  • People still have to act. Auditors ask who reviewed an alert, what they decided and how the incident was closed. A queue of untouched alerts is evidence against you.

A checklist for choosing a SIEM for compliance

  1. Coverage of every in-scope source: Windows, Linux, firewalls, VPNs, identity providers, Microsoft 365 and cloud accounts.
  2. Correlation rules that combine events from several systems, not only search.
  3. An alert when a source goes quiet, so a logging failure does not go unnoticed for weeks.
  4. Tamper-resistant storage and least-privilege access to the SIEM, with multi-factor sign-in.
  5. Retention you control, with older logs still searchable when an investigator needs them.
  6. Reports mapped to your frameworks, so evidence exists before the auditor asks.
  7. Case management that records who handled each alert and how it ended.
  8. A pricing model that does not punish logging. If every new log source raises the bill, teams start switching logs off.

How UTMStack helps

We build UTMStack, so weigh our view accordingly. UTMStack collects logs from servers, endpoints, firewalls, identity providers and cloud platforms, and checks each event against more than 600 detection rules mapped to MITRE ATT&CK as it arrives, before storage. Alerts become incidents your team can track to closure, which gives auditors the record of who reviewed what.

Its compliance module scores nine frameworks from your live events, using one control library based on NIST SP 800-53, and produces PDF reports with reviewer sign-off. CMMC 2.0 and GDPR are included in the free Community edition. Banking Audit, HIPAA, ISO/IEC 27001:2022, NIST SP 800-171 Rev 3, NIST CSF 2.0, PCI DSS 4.0 and SOC 2 are in the Enterprise edition. UTMStack does not score GLBA or FISMA as separate frameworks, although it collects the evidence their safeguards depend on.

Retention goes up to 5 years, with recent data in a hot tier and older data in a cold tier that stays searchable without a restore. You can run it on your own servers, including networks with no internet access, or use UTMStack Cloud, a dedicated instance per customer. It is priced per device, never by log volume, so you never have a reason to log less; see pricing. To try it, install the free edition or open the live demo with no sign-up.

Frequently asked questions

Is a SIEM required for compliance? No regulation in this guide requires a SIEM by name. They require logging, review, monitoring and retention. A SIEM is the usual way to meet those requirements once you have more than a few systems, especially where correlation or automated review is required.

Which regulations require log monitoring? PCI DSS (Requirement 10), HIPAA (164.312(b) and 164.308(a)(1)(ii)(D)), CMMC and NIST SP 800-171 (family 3.3), NIST SP 800-53 (AU and SI-4), ISO/IEC 27001:2022 (Annex A 8.15 and 8.16), SOC 2 (CC7.2), the GLBA Safeguards Rule (314.4(c)(8)) and GDPR through Articles 32 and 33.

How long should logs be kept for compliance? PCI DSS requires 12 months with 3 months immediately available. Federal civilian agencies need 6 months searchable and 12 months retrievable under OMB M-26-14. Most other frameworks leave it to your policy, and 12 months is a common floor.

Does PCI DSS require a SIEM? Not by name. Since March 31, 2025, requirement 10.4.1.1 requires automated mechanisms for log review, and a SIEM is the most common way to meet it.

Is log management enough, or do I need a SIEM? Log management collects and stores logs. A SIEM adds correlation, alerting and incident tracking. Frameworks that ask for correlation, automated review or alerts on logging failures usually need the SIEM part.

Does a SIEM make us compliant? No. It produces evidence that technical controls work. Policies, risk analysis, training and the audit itself are still your work.

Sources

Keep reading