Logging, monitoring, and vulnerability management are the continuous-assurance layer of PCI DSS. Unlike architectural controls that are implemented once, these require ongoing operational discipline — daily log reviews, quarterly scans, annual penetration tests, and constant patch management. Building the infrastructure and processes that make these sustainable is as important as the initial implementation.
Organizations often underestimate the operational burden of these controls. Once a firewall is segmenting the CDE, it remains segmented without much ongoing effort. But a vulnerability scanning program requires purchasing scanner licenses, scheduling scans, triaging findings, coordinating remediation, and verifying remediation for every new system added to the environment. The long-term success of the compliance program depends on building sustainable processes for these ongoing controls.
SIEM Architecture for PCI DSS
SIEM Requirements
A Security Information and Event Management (SIEM) system is the practical implementation of Requirement 10's daily log review requirement. The SIEM must: collect logs from all in-scope CDE system components (operating systems, applications, network devices, databases), correlate events to detect suspicious activity (identifying patterns like brute force attacks or unusual access), generate alerts for defined events (notifying security team when important events occur), protect log integrity (ensuring logs cannot be modified after ingestion, using append-only logging), and retain logs for 12 months with 3 months immediately available online.
The SIEM is the window into what is happening in the CDE. Attackers leaving no logs are the nightmare scenario — the SIEM must ensure that important events are captured and retained long enough to detect and investigate incidents.
Log Source Coverage
All CDE system components must forward logs to the SIEM. Common log sources include: operating system security logs (Windows Event Log with security events, Linux auditd or syslog with authentication and authorization events), application logs (payment application logs, web server access logs, error logs), network device logs (firewall allow/deny logs, router logs, VPN logs), database audit logs (all access to cardholder data tables, all schema modifications, all user authentication events), authentication system logs (Active Directory, LDAP, identity provider), and cloud platform logs (AWS CloudTrail tracking all API calls, GCP Cloud Audit Logs, Azure Activity Log).
Ensuring complete log coverage is tedious but critical. Missing a log source means that an entire class of events goes unmonitored. A common gap is database logs — database administrators often do not realize that database audit logs must be forwarded to the SIEM, and therefore database-level attacks go undetected.
Alert Rule Configuration and Daily Review
Configure SIEM alert rules for PCI DSS-relevant events. Minimum alert rules required:
- Multiple failed login attempts (threshold-based — e.g., 5 failures in 5 minutes)
- Successful login after failed attempts (indicates brute force success)
- Privileged account creation or modification
- Access to audit logs or SIEM console (unauthorized access to monitoring systems)
- User account added to privileged group (Administrators, Domain Admins)
- Service or daemon started/stopped on CDE systems (unauthorized service manipulation)
- Firewall rule changes on CDE perimeter (unauthorized network changes)
- Access to CDE systems outside business hours (access from unusual times)
- Large data volume transfers from CDE systems (potential data exfiltration)
Once alert rules are configured, the security team must review alerts daily. Daily review does not mean reading every alert — it means reviewing the alerts generated by the SIEM rules, investigating any suspicious alerts, and documenting the investigation. A log entry showing "user X logged in at 2 AM from an unusual location" may be a legitimate incident or may be a contract support person in a different time zone — the security team investigates and documents the outcome.
| KEY IDEA | The daily log review requirement does not mean a human reads every log line every day — that is operationally impossible at scale. It means that alerts generated from automated SIEM rules are reviewed and investigated daily by security personnel. The alert rules are the mechanism; daily human review of alerts is the control. Both the alert configuration and evidence of daily review are tested by QSAs. |
Vulnerability Scanning Implementation
Internal Vulnerability Scanning
Deploy an internal vulnerability scanner (Qualys, Rapid7 Nexpose, Tenable Nessus, OpenVAS, or cloud-native scanning tools) to scan all in-scope CDE systems at least quarterly. The scanner must be configured to scan all in-scope IP addresses, all protocols, and all ports. Findings must be classified by severity (using CVSS score — Common Vulnerability Scoring System), all Critical and High vulnerabilities remediated, the scanner run again until a clean result (no Critical/High findings), and the results documented.
The internal scan is the baseline for vulnerability management. It identifies vulnerabilities in systems you control and operate. The challenge is defining "critical" and "high" in your environment — a vulnerability in a non-production system might be treated differently than the same vulnerability in the payment processing system.
ASV Selection and External Scanning
Select an Approved Scanning Vendor (ASV) from the PCI SSC's official list of approved ASV companies. The ASV performs quarterly external scans of all internet-facing systems in or connected to the CDE. The ASV scan is not optional — PCI DSS requires external scans by approved vendors to ensure independent verification of security posture.
The ASV scan must achieve "passing" status — all vulnerabilities classified as High or Critical must be remediated and rescanned before passing status is granted. ASV scanning is more rigorous than internal scanning because the ASV is testing your external security posture from an attacker's perspective.
Selecting a good ASV is important. The ASV should be experienced in PCI DSS assessments, responsive to questions, and capable of rerunning scans quickly after remediation. A poor ASV relationship (unresponsive vendors, scan methodology disputes, slow rescans) creates bottlenecks in your compliance program.
Post-Change Scanning
Whenever significant changes are made to the CDE (new systems added, major network changes, operating system upgrades, application updates), a vulnerability scan should be run after the change to verify that no new vulnerabilities were introduced. Post-change scanning is a best practice that catches issues before they propagate into the production environment.
| Scan Type | Frequency | Who Performs | Pass Criteria | Evidence for QSA |
|---|---|---|---|---|
| Internal vulnerability scan | Quarterly minimum | Internal staff or third-party qualified scanner | No High or Critical vulnerabilities (or documented risk acceptance) | Scan reports for all 4 quarters, remediation records |
| External ASV scan | Quarterly minimum | PCI SSC-approved ASV | Official "pass" status from ASV — all High/Critical remediated | Signed ASV passing scan reports for all 4 quarters |
| Post-change scan | After significant changes | Internal staff | No new High/Critical vulnerabilities | Change management record + scan report |
| Penetration test — network | Annual minimum | Qualified internal or third-party pen tester | All critical/high findings remediated and verified | Penetration test report, remediation evidence, retest confirmation |
| Penetration test — application | Annual minimum | Qualified internal or third-party pen tester | All critical/high findings remediated and verified | Application pen test report, remediation evidence |
| Segmentation test | Annual + post-change | Qualified pen tester | Confirmation that CDE is isolated from out-of-scope systems | Segmentation test report |
Patch Management Implementation
Patch Management Process
Build a formal patch management process for all CDE system components. The process must: monitor for new security vulnerabilities (subscribe to vendor advisories — Microsoft Security Updates, Oracle Critical Patch Updates, Linux distribution security lists, AWS security bulletins, GCP security notices), classify each vulnerability by severity (using CVSS or vendor-supplied severity rating), test patches in a non-production environment before CDE deployment (ensure patches do not break applications or infrastructure), deploy critical patches within 30 days (PCI DSS requirement), and document the timeline and evidence for each patch deployment (change management records, scan results showing patches applied).
Patch management at scale is complex. A single operating system update can affect dozens of production systems. A database security patch may require downtime. Coordinating patch deployment with business requirements while maintaining compliance deadlines requires careful planning and automation.
Patch Management Tooling
Common tooling for CDE patch management: WSUS (Windows Server Update Services) or Intune for Windows systems, Ansible, Puppet, or Chef for infrastructure-as-code patch management, cloud-native patch management (AWS Systems Manager Patch Manager for EC2 and on-premises, GCP OS Patch Management for Compute Engine, Azure Update Manager for all platforms), or container orchestration patches (Kubernetes security patches, container image scanning and updates).
All patch deployments must be documented in the change management system with timestamps, what was patched, and evidence that the patch was successful (e.g., vulnerability scan showing the vulnerability is no longer present).
End-of-Life (EoL) Components
End-of-life system components — operating systems, applications, or libraries that no longer receive security updates from the vendor — are a significant PCI DSS risk. Windows Server 2008 has not received updates for years, but some organizations still run it in production. Older versions of Java, Ruby, or Python no longer receive security updates.
For CDE systems on EoL software, PCI DSS requires documented compensating controls: network isolation to reduce attack surface (the EoL system is segmented from other systems), WAF (Web Application Firewall) or IPS (Intrusion Prevention System) rules to compensate for unpatched vulnerabilities, and a documented migration plan (committing to moving away from EoL software by a specific date).
| IMPORTANT | End-of-life system components — operating systems, applications, or libraries that no longer receive security updates from the vendor — are a persistent QSA finding. EoL systems in the CDE are a major vulnerability. Develop a migration roadmap and commit to replacing EoL systems. Do not plan to run EoL software in the CDE indefinitely. |
Penetration Testing Methodology
Annual penetration testing must follow a recognized methodology (PTES — Penetration Testing Execution Standard, OWASP, NIST SP 800-115). The test must cover: all external-facing systems in or connected to the CDE (external network penetration test — an attacker's perspective from the internet), all internal CDE systems and their trust relationships (internal network penetration test — what an insider attacker could do), all public-facing web applications and APIs that handle CHD (application penetration test — looking for OWASP Top 10 vulnerabilities), and network segmentation verification (confirming that an attacker in an out-of-scope segment cannot reach CDE systems).
Critical and high findings must be remediated and the penetration tester must confirm remediation (a retest of the vulnerability confirms it is fixed). The penetration test report should be detailed enough that a QSA can understand the testing scope and methodology.
Selecting a Penetration Tester
Penetration testing quality varies enormously. Bad penetration testers run a vulnerability scanner and call it a penetration test. Good penetration testers combine automated tools with manual testing, attempt to chain vulnerabilities together (one finding enables another), and understand the business context of the systems being tested.
Look for testers with OSCP (Offensive Security Certified Professional), CEH (Certified Ethical Hacker), or equivalent credentials, using a written methodology document. QSAs will review the penetration test report and may question its scope and depth — a thin report covering only automated scanner results will not satisfy Requirement 11.
| Penetration testing quality varies enormously. Indonesian organizations seeking QSA-acceptable penetration tests should look for testers with OSCP, CEH, or equivalent credentials, using a written methodology document. QSAs will review the penetration test report and may question its scope and depth — a thin report covering only automated scanner results will not satisfy Requirement 11. Build relationships with reputable penetration testing firms that understand PCI DSS requirements and can provide assessment-ready reports. |
Evidence Package for Requirements 5, 6, 10, and 11
QSAs testing these requirements require: vulnerability management policy (documenting the process), internal scan reports (for all 4 quarters), ASV passing scan reports (for all 4 quarters), patch management records (showing patches deployed), evidence of post-change scans, SIEM configuration documentation (alert rules, log sources), SIEM daily review records (evidence that alerts are reviewed each day), penetration test reports (for the past year, showing scope and remediation), segmentation test results, and evidence that critical vulnerabilities are remediated within 30 days.
The strongest evidence is actual scan reports with timestamps, actual patch deployment records from change management, actual daily review logs showing alerts were reviewed, and actual penetration test reports from qualified testers. Do not prepare generic policy documents and hope they satisfy requirements — QSAs want evidence that controls are actually operating.