Logging and monitoring is the nervous system of PCI DSS compliance. Without it, security incidents go undetected, investigations cannot be conducted, and controls cannot be demonstrated to QSAs. Requirement 10 is deceptively straightforward — log everything, review it daily, protect the logs — but the operational implementation of a compliant logging program requires careful architecture decisions about collection, storage, retention, integrity, and alerting.
What Must Be Logged — Requirement 10 Event Types
PCI DSS v4.0 specifies the minimum events that must generate audit log entries for all in-scope system components:
| Event Category | Specific Events | Typical Log Source |
|---|---|---|
| User access to CHD | All queries or access to any system containing cardholder data | Database audit logs, application logs |
| Privileged actions | All actions taken by root, admin, or any account with elevated privileges | OS security logs, sudo logs, cloud IAM logs |
| Access to audit logs | Any read, modification, or deletion attempt on audit log files | SIEM platform logs, log server access logs |
| Invalid access attempts | Failed login attempts, failed authentication, account lockouts | Authentication logs, Active Directory, identity provider |
| Authentication changes | Account creation, modification, deletion; privilege elevation | AD Security Event Log, IAM audit logs |
| Log initialization | Start/stop/pause of audit log processes; log file creation/deletion | OS event log, syslog |
| System-level object changes | Creation, modification, deletion of system-level objects (files, processes, services) | OS audit logs (Windows Event Log 4656, 4663; Linux auditd) |
Log Content — What Each Entry Must Contain
Every audit log entry must contain: event type, date and time, success/failure indication, origination of the event (user, source IP, process), and identity of the affected data, system component, or resource. Time synchronization is critical — all system clocks must be synchronized to a reliable time source (NTP). Without synchronized time, log correlation across systems is unreliable and incident investigation is compromised.
SIEM Architecture and Implementation
SIEM Selection
For PCI DSS compliance, a SIEM must provide: centralized log collection from all in-scope sources, log integrity protection (immutable ingestion), alerting on defined event types, long-term storage (12 months), search and query capability for investigation, and an audit trail of SIEM admin access.
| SIEM Solution | Type | PCI DSS Features | Indonesian Deployment |
|---|---|---|---|
| Splunk Enterprise | On-premise/cloud | PCI DSS compliance app, pre-built correlation rules, immutable indexing | Available on-premise or Splunk Cloud (Singapore) |
| Microsoft Sentinel | Cloud SIEM (Azure) | Native Azure log ingestion, PCI DSS workbook, AI-driven analytics | Azure Southeast Asia / paired with Indonesia North |
| Amazon Security Lake / OpenSearch | AWS-native | S3-backed immutable storage, integration with GuardDuty, CloudTrail | AWS ap-southeast-3 Jakarta |
| IBM QRadar | On-premise/cloud | PCI DSS content pack, mature threat intelligence integration | Available through IBM Indonesia |
| Google Chronicle | Cloud SIEM (GCP) | Petabyte-scale storage, retroactive alerting, GCP log integration | GCP asia-southeast2 Jakarta |
| Elastic Security (ELK) | Open-source / cloud | Flexible, cost-effective; PCI DSS dashboards via community modules | Self-hosted or Elastic Cloud (Singapore) |
Log Source Onboarding
All CDE log sources must be onboarded to the SIEM. Critical sources: Windows Security Event Log (forwarded via WEF or Syslog), Linux auditd/syslog (via syslog-ng, rsyslog, or Beats agent), network device syslog (firewall, router, switch), database audit logs (Oracle Audit Vault, MySQL general log, PostgreSQL pgaudit), cloud audit logs (AWS CloudTrail, GCP Cloud Audit Logs, Azure Activity Log), application security logs (web server access logs, payment application security events), and authentication provider logs (Active Directory, Okta, Azure AD).
| KEY IDEA | Log coverage gaps are one of the most common Requirement 10 findings. Organizations configure their SIEM to collect the obvious sources (Windows events, firewall logs) but miss critical sources like database audit logs, cloud management plane logs (CloudTrail, GCP Audit Logs), and authentication provider logs. QSAs will ask for a list of all log sources and verify that coverage is comprehensive. |
Log Integrity Protection
Audit logs must be protected from modification and unauthorized deletion. Implementation approaches:
- Write-once storage: Send logs directly to an append-only, write-once log storage system (SIEM with immutable storage, S3 with Object Lock in COMPLIANCE mode, Azure Blob Storage with immutability policies)
- Cryptographic hashing: Hash each log entry (or batch of entries) and store hashes separately — any modification to logs is detectable by recomputing hashes
- Separate log server: Forward logs to a dedicated log server that is separate from the systems generating the logs — an attacker who compromises a CDE server cannot modify logs already forwarded to the separate SIEM
- Strict access controls: Log viewing/analysis access is separate from log write access; administrators cannot modify logs even with admin credentials
- Log file monitoring: Alert on deletion or modification of log files on CDE systems (before forwarding to SIEM)
Daily Log Review Implementation
The daily review requirement must produce evidence of review. Implementation: configure SIEM alert rules for all Requirement 10-specified event types, configure alert delivery to security team (email, ticketing system integration, Slack/Teams notification), require security analyst acknowledgment and sign-off for all alerts within 24 hours, and maintain a log review record (analyst ID, date, alerts reviewed, findings, actions taken).
| IMPORTANT | The daily log review requirement does not mean reviewing all logs — it means reviewing all alerts generated from automated analysis of those logs. No human team can read every log line from a production environment. The SIEM alert rules are the detection layer; the daily review is confirmation that alerts were reviewed and acted upon. QSAs will ask to see daily review records — typically a spreadsheet, SIEM ticket queue, or SOAR playbook records. |
| For smaller Indonesian organizations that cannot afford enterprise SIEM platforms, we recommend Microsoft Sentinel with the Azure Government Student/NGO or pay-as-you-go pricing model. Sentinel's PCI DSS workbook provides out-of-the-box correlation rules, and its integration with Azure Log Analytics provides the log retention and integrity requirements at a cost point accessible to mid-market Indonesian fintech companies. | |