07 Secure Configuration

Secure configuration is the process of making sure systems in the Cardholder Data Environment (CDE) are deployed and maintained with security-focused settings instead of insecure defaults.

A secure PCI environment should not rely on:

Vendor Defaults

Unnecessary Services

Weak Protocols

Open Ports

Default Accounts

Uncontrolled Configuration Changes

A practical secure-configuration lifecycle looks like:

System Inventory
      ↓
Secure Configuration Standard
      ↓
Approved Baseline
      ↓
System Hardening
      ↓
Configuration Validation
      ↓
Drift Detection
      ↓
Exception Management
      ↓
Remediation
      ↓
Continuous Compliance

The central question is:

Is every in-scope system configured according to an approved, secure, and repeatable baseline—and can we prove it remains that way?

Learning Objectives

By the end of this lesson, you will be able to:

Explain secure configuration in PCI DSS.
Understand configuration standards.
Build hardened security baselines.
Identify vendor-default risks.
Remove or secure default accounts.
Remove unnecessary services.
Restrict unnecessary ports and protocols.
Understand secure administrative protocols.
Harden operating systems.
Harden databases.
Harden network devices.
Harden cloud resources.
Understand container and Kubernetes hardening.
Validate configuration compliance.
Detect configuration drift.
Manage security configuration exceptions.
Build hardening evidence.
Test configuration controls.
Maintain continuous configuration compliance.

1. Why Secure Configuration Matters

Systems often ship with configurations designed for:

Ease of Installation

Compatibility

Testing

Convenience

rather than maximum security.

Examples may include:

Default Passwords

Unused Services

Sample Applications

Open Management Interfaces

Weak Cryptography

Attackers frequently exploit these weaknesses.

2. Secure Configuration Principle

A strong model is:

Known System
      ↓
Approved Baseline
      ↓
Hardened Configuration
      ↓
Validated
      ↓
Continuously Monitored

not:

Install System
      ↓
Use Defaults
      ↓
Fix Problems Later

3. PCI Secure Configuration Objective

Secure configuration helps reduce:

Attack Surface

Unauthorized Access

Misconfiguration

Weak Services

Configuration Drift

across the CDE.

4. Start With the System Inventory

You cannot define secure configuration if you do not know:

Which Systems Exist

Which Operating Systems

Which Databases

Which Cloud Services

Which Network Devices

Use the:

PCI In-Scope Asset Register

as the foundation.

5. Build Configuration Coverage Register

Create:

01 Configuration Coverage Register

Use:

Asset	Type	Baseline	Compliance Status	Owner

6. Configuration Standard

A configuration standard defines how a technology should be securely deployed.

Examples:

Windows Server Standard

Linux Server Standard

Database Security Standard

Firewall Configuration Standard

Kubernetes Security Standard

7. Build PCI Secure Configuration Standard

Create:

02 PCI Secure Configuration Standard

Include:

Purpose

Scope

Roles

Baseline Requirements

Validation

Exceptions

Monitoring

Review Frequency

8. Baseline vs Standard

A standard defines the overall requirements.

A baseline defines specific technical settings.

Example:

Standard:
Administrative access must use secure protocols.

Baseline:

SSH v2 Enabled
Telnet Disabled

9. Build CDE Hardening Baseline

Create:

03 CDE Hardening Baseline

Use:

Setting	Required State	Rationale	Validation

10. Baseline Sources

Organizations commonly draw from:

Vendor Security Guidance

CIS Benchmarks

NIST Guidance

Internal Security Standards

Cloud Provider Guidance

The selected baseline should fit the technology and risk.

11. Vendor Defaults

One of the first security tasks is identifying default settings.

Examples:

Default Username

Default Password

Default SNMP Community

Sample Application

Default Certificate

12. Default Credential Risk

Example:

Username:
admin

Password:
admin

If unchanged:

Attacker
      ↓
Known Vendor Credential
      ↓
Administrative Access

13. Default Account Review

Create:

04 Default Account Review Register

Use:

System	Default Account	Required?	Secured / Removed	Owner

14. Remove Unnecessary Default Accounts

If not required:

Disable

Remove

If required:

Rename Where Appropriate

Change Credentials

Restrict Access

Monitor Usage

15. Default Passwords

Default passwords should never remain active on production CDE systems.

This applies to:

Applications

Network Devices

Databases

Appliances

Security Tools

16. Unnecessary Services

Every running service increases attack surface.

Ask:

Why Is This Service Running?

If there is no legitimate purpose:

Disable It

17. Example

Server runs:

FTP

Telnet

HTTP

SSH

Database

but only:

SSH

Database

are needed.

Remove or disable the rest.

18. Service Inventory

Create:

05 CDE Service & Port Register

Use:

Asset	Service	Port	Required	Action

19. Unnecessary Ports

Avoid broad exposure such as:

All Ports Open

Use only:

Required Ports

aligned with the communication matrix.

20. Secure Protocols

Avoid insecure protocols such as legacy:

Telnet

FTP

HTTP for Administration

where secure alternatives are available.

Use:

SSH

SFTP

HTTPS

as appropriate.

21. Weak Cryptographic Protocols

Disable outdated protocols and cipher suites according to organizational security requirements.

Examples of legacy concerns may include:

SSL

Old TLS Versions

Weak Ciphers

22. Administrative Interfaces

Restrict management interfaces to:

Admin Networks

Jump Hosts

Privileged Workstations

rather than exposing them broadly.

23. Management Plane Example

Weak:

Firewall Admin Interface
      ↓
Internet Accessible

Strong:

Admin Workstation
      ↓
Management Network
      ↓
Firewall Admin Interface

24. Operating System Hardening

OS hardening may include:

Account Security

File Permissions

Audit Logging

Services

Patching

Remote Access

Kernel / Security Settings

25. Linux Hardening

Examples:

Disable Unused Services

Restrict Root Login

Configure SSH

File Permissions

Audit Logging

Time Synchronization

26. Windows Hardening

Examples:

Security Policy

Local Accounts

RDP Restrictions

Audit Policy

Defender / EDR

Firewall

PowerShell Logging

27. Local Firewall

Host-level firewalls can provide an additional control layer.

Example:

Only Required Sources
      ↓
Required Ports

28. File Permissions

Restrict access to sensitive:

Configuration Files

Application Secrets

Log Files

Payment Data Files

29. Database Hardening

Databases supporting payment systems require specific controls.

Review:

Accounts

Network Access

Authentication

Encryption

Logging

Permissions

Sample Databases

30. Database Default Accounts

Examples:

sa

postgres

oracle

should be tightly controlled.

31. Database Network Exposure

Weak:

Database
      ↓
Reachable From Corporate Network

Strong:

Application Tier
      ↓
Database

with restricted administrative access.

32. Database Least Privilege

Application account:

Only Required Queries

not:

Full DBA Rights

33. Network Device Hardening

For:

Firewalls

Routers

Switches

Load Balancers

review:

Default Credentials

Management Protocols

Unused Services

Logging

SNMP

Administrative Access

34. SNMP

If SNMP is used:

Secure Version

Restricted Sources

Strong Credentials

should be considered.

Avoid insecure default community strings.

35. Network Configuration Backups

Maintain secure backups of critical network-device configurations.

Protect them because they may contain:

Network Architecture

Addresses

Security Rules

Credentials

36. Cloud Secure Configuration

Cloud environments introduce configuration through:

IAM

Network

Storage

Logging

Encryption

Management Plane

37. Cloud Default Risk

New cloud resources may be insecure if deployed without guardrails.

Examples:

Public Storage

Open Security Groups

Unencrypted Storage

Logging Disabled

38. AWS Example

Check for settings such as:

Public S3 Buckets

0.0.0.0/0 Admin Ports

Root Account Usage

CloudTrail Disabled

Unencrypted Storage

39. Azure Example

Review:

Public Storage

NSG Rules

Privileged Roles

Diagnostic Logging

Disk Encryption

40. GCP Example

Review:

Public IAM Bindings

Firewall Rules

Service Accounts

Audit Logging

Storage Exposure

41. Cloud Baselines

Use reusable templates for:

Cloud Accounts

VPCs

Storage

Compute

Databases

42. Infrastructure as Code

A strong model:

Approved IaC Template
      ↓
Secure Configuration
      ↓
Deployment

rather than manual configuration.

43. IaC Security

Scan:

Terraform

CloudFormation

Bicep

for insecure settings before deployment.

44. Policy-as-Code

Examples of rules:

No Public Database

No 0.0.0.0/0 SSH

Encryption Required

Logging Required

45. Container Hardening

Containers require secure configuration across:

Image

Runtime

Privileges

Networking

Secrets

46. Container Image

Avoid:

Unnecessary Packages

Development Tools

Embedded Secrets

Outdated Base Images

47. Non-Root Containers

Where possible:

Container
      ↓
Runs as Non-Root

reduces privilege.

48. Privileged Containers

Avoid:

privileged: true

unless clearly required and risk approved.

49. Kubernetes Hardening

Review:

RBAC

NetworkPolicy

Pod Security

Secrets

Admission Controls

Audit Logging

50. Kubernetes Default Risk

Weak configuration:

Cluster Admin Widely Assigned

No NetworkPolicy

Privileged Pods

Public API Server

51. Kubernetes Baseline

Create:

Kubernetes CDE Hardening Baseline

including:

Restricted RBAC

Network Isolation

Secure Workloads

Logging

Secrets Protection

52. Application Configuration

Applications may have insecure defaults such as:

Debug Mode

Verbose Errors

Default Accounts

Test Endpoints

Sample Files

53. Debug Mode Risk

Production debug mode may expose:

Stack Traces

Credentials

Internal Paths

Payment Information

Disable it.

54. Error Messages

Avoid exposing sensitive details.

Weak:

Database Error:
User paymentadmin
Table cardholder_data

Strong:

Transaction could not be completed.

55. Sample Applications

Remove:

Demo Pages

Test Applications

Sample Accounts

from production systems.

56. Configuration Validation

Do not assume deployment equals compliance.

Validate:

Required Setting
      ↓
Actual Setting
      ↓
Compare

57. Build Configuration Compliance Register

Create:

06 Configuration Compliance Register

Use:

Asset	Baseline	Compliant	Exceptions	Last Validation

58. Validation Methods

Possible methods:

Automated Scanner

Configuration Management Tool

Script

Manual Review

Cloud Security Platform

59. Compliance Example

Population:

80 CDE Servers

Compliant:

Non-compliant:

Result:

Configuration Gap

60. Configuration Drift

Drift occurs when a system moves away from its approved baseline.

Example:

Baseline:
SSH From Jump Host Only

Later:

Temporary Rule
      ↓
SSH From Corporate Network

That is configuration drift.

61. Drift Sources

Common causes:

Manual Changes

Emergency Fixes

Temporary Access

Vendor Changes

Cloud Console Changes

62. Build Configuration Drift Dashboard

Create:

07 Configuration Drift Dashboard

Track:

Metric	Target
CDE Baseline Compliance	100%
Critical Drift	0
Open High Drift Findings	0
Unapproved Config Changes	0

63. Continuous Configuration Monitoring

A mature environment detects:

Security Group Changes

New Accounts

Logging Disabled

Encryption Disabled

New Services

automatically.

64. Configuration Management Tools

Examples include:

Configuration Management

Cloud Security Posture Management

Infrastructure as Code

Compliance Scanners

65. Golden Images

A secure deployment may use:

Approved Golden Image
      ↓
CDE Server

rather than configuring every server manually.

66. Golden Image Risk

If the golden image becomes outdated:

Every New Server
      ↓
Deploys Same Weakness

67. Image Review

Review:

Patches

Configuration

Packages

Security Agents

before release.

68. Immutable Infrastructure

Modern environments may prefer:

Update Image
      ↓
Redeploy

instead of changing production systems manually.

This can reduce configuration drift.

69. Configuration Change Management

Changes to secure settings should follow:

Request
      ↓
Review
      ↓
Approval
      ↓
Implementation
      ↓
Validation

70. Emergency Configuration Changes

Emergency changes should still be:

Documented

Reviewed

Validated

after implementation.

71. Configuration Exception

Sometimes a system cannot meet the standard baseline.

Create:

08 Security Configuration Exception Register

Use:

Asset	Requirement	Exception	Risk	Compensating Control	Expiry

72. Exception Example

Baseline requires:

Disable TLS 1.1

Legacy vendor requires:

TLS 1.1

Exception should document:

Business Requirement

Risk

Restricted Connectivity

Migration Plan

Expiry

73. Exceptions Must Be Time-Bound

Weak:

Legacy Application
Requires Exception Forever

Strong:

Exception
      ↓
Owner
      ↓
Expiry
      ↓
Migration Plan

74. Compensating Controls

Possible controls:

Network Restriction

Additional Monitoring

WAF

Limited Access

Isolation

depending on the risk.

75. Configuration Evidence

Potential evidence includes:

Baseline Documents

Configuration Exports

Scanner Results

IaC Templates

Cloud Policies

Hardening Reports

Exception Records

76. Build Hardening Evidence Catalog

Create:

09 Hardening Evidence Catalog

Use:

Control	Evidence	Source	Owner	Frequency

77. Evidence Example — Linux

Evidence may include:

SSH Configuration

Service Inventory

Audit Configuration

User Configuration

78. Evidence Example — Cloud

Evidence may include:

Security Group Export

Logging Configuration

Encryption Status

IAM Policies

79. Evidence Example — Database

Evidence:

User Configuration

Network Settings

Encryption

Audit Logging

80. Evidence Quality

Evidence should show:

System

Setting

Date

Scope

not simply a cropped screenshot without context.

81. Configuration Testing

A practical testing flow:

Asset Population
      ↓
Select Sample
      ↓
Compare to Baseline
      ↓
Identify Deviations
      ↓
Validate Exceptions
      ↓
Conclusion

82. Build PCI Configuration Testing Checklist

Create:

10 PCI Configuration Testing Checklist

For each sampled system:

Approved baseline exists.
Default credentials removed.
unnecessary services disabled.
secure protocols configured.
management access restricted.
logging enabled.
encryption configured where required.
security agents installed.
configuration exceptions approved.
drift monitored.

83. Sample Testing Example

Population:

50 Linux CDE Servers

Sample:

Results:

13 Fully Compliant

1 Telnet Enabled

1 Root SSH Enabled

Potential:

Configuration Exceptions / Failures

84. Default Account Test

Population:

20 Network Devices

Test:

Check Default Admin Accounts

Finding:

2 Devices
Still Use Default Administrator Name

Investigate.

85. Cloud Configuration Test

Population:

30 CDE Security Groups

Result:

28 Compliant

2 Allow SSH
From 0.0.0.0/0

Risk:

Internet-Exposed Administration

86. Logging Configuration Test

Population:

25 CDE Servers

Result:

23 Logging Enabled

2 Logging Disabled

Potential configuration gap.

87. Encryption Configuration Test

Population:

12 Payment Storage Volumes

Result:

12 Encrypted

Conclusion:

Effective

88. Configuration Finding — Default Password

A payment appliance retains the vendor-supplied administrative password.

Severity:

Critical / High

depending on exposure and context.

89. Configuration Finding — Telnet

Telnet remains enabled on three network devices protecting the CDE.

90. Configuration Finding — Public Admin Port

Two payment servers allow administrative access from the internet.

91. Configuration Finding — Debug Mode

Debug mode is enabled on the production checkout application.

92. Configuration Finding — Unnecessary Service

FTP is enabled on CDE servers without documented business requirement.

93. Configuration Finding — Drift

A security group was modified outside the approved IaC process and now permits unauthorized corporate access to the CDE.

94. Build Configuration Gap Register

Create:

11 PCI Configuration Gap Register

Use:

Gap	Asset	Baseline Requirement	Severity	Owner

95. Root Cause Example — Telnet

Problem:

Telnet Enabled

Why?

Legacy Network Template

Why?

Template Never Updated

Root cause:

Network-device deployment templates are not governed through the secure baseline lifecycle.

96. Correction

Disable Telnet

97. Corrective Action

Update Template

Validate Existing Devices

Block Telnet Through Policy

98. Root Cause Example — Public SSH

Problem:

SSH Open to Internet

Why?

Temporary Troubleshooting

Why?

Manual Rule Never Removed

Root cause:

Temporary security-group changes do not have automatic expiry or drift monitoring.

99. Corrective Action

Restrict SSH

Add Temporary Rule Expiry

Enable Policy-as-Code

100. Root Cause Example — Logging Disabled

Problem:

Two Servers
Not Logging

Why?

New Server Template
Missing Agent

Root cause:

Logging configuration is not included in the approved golden image.

101. Corrective Action

Update Golden Image

Deploy Logging Agent

Validate All Servers

102. Configuration Compliance Dashboard

Recommended metrics:

Metric	Target
CDE Baseline Compliance	100%
Default Credentials Present	0
Unapproved Services	0
Internet-Exposed Admin Ports	0
Unapproved Drift	0
Expired Config Exceptions	0

103. Baseline Compliance KPI

Example:

Percentage of CDE systems
meeting approved secure baseline

104. Default Credential KRI

Example:

CDE systems
with vendor-default credentials

Target:

105. Drift KRI

Example:

Critical configuration deviations
from approved CDE baseline

106. Public Exposure KRI

Example:

Administrative CDE interfaces
accessible from untrusted networks

Target:

107. Exception KRI

Example:

Expired secure-configuration exceptions
still active

108. Practical Activity — Build Server Baseline

Use fictional company:

CloudShop

Create a Linux CDE baseline covering:

Accounts

SSH

Services

Logging

Firewall

Time Synchronization

File Permissions

109. Practical Activity — Review 10 Servers

Classify:

Compliant

Non-Compliant

Approved Exception

Include issues such as:

Telnet Enabled

Root SSH Enabled

Logging Missing

Weak File Permissions

110. Practical Activity — Cloud Hardening

Review:

Payment EC2

Payment Database

Security Groups

S3 Buckets

CloudTrail

Identify insecure configurations.

111. Practical Activity — Firewall Device Hardening

Review:

Default Credentials

Telnet

SNMP

Admin Access

Logging

112. Practical Activity — Kubernetes Hardening

Use:

payments namespace

Review:

Privileged Pods

Root Containers

RBAC

NetworkPolicy

Secrets

113. Practical Activity — Configuration Exception

Legacy application requires:

TLS 1.1

Create:

Risk

Business Justification

Network Restriction

Monitoring

Owner

Expiry

Migration Plan

114. Practical Activity — Drift Investigation

Baseline:

SSH Allowed From Jump Host Only

Actual:

SSH Allowed From Corporate CIDR

Document:

Finding

Risk

Root Cause

Correction

Corrective Action

Retest

115. PCI Secure Configuration Checklist

Governance

configuration standard defined.
technology baselines defined.
owners assigned.
review cycle established.

Defaults

default passwords changed.
unnecessary default accounts removed.
sample applications removed.
default certificates reviewed.

Services

unnecessary services disabled.
unnecessary ports closed.
insecure protocols disabled.
required services documented.

Administration

management interfaces restricted.
secure protocols used.
MFA supported where required.
privileged access controlled.

Operating Systems

baseline applied.
logging configured.
file permissions hardened.
local firewall configured.
unnecessary software removed.

Databases

default accounts reviewed.
network access restricted.
permissions restricted.
encryption configured.
audit logging configured.

Network Devices

secure management configured.
Telnet disabled.
SNMP secured.
logging enabled.
default credentials removed.

Cloud

public exposure restricted.
logging enabled.
storage encrypted.
IAM restricted.
security groups reviewed.
cloud policies enforced.

Containers / Kubernetes

images hardened.
non-root execution used where possible.
privileged workloads restricted.
RBAC hardened.
network policies applied.
secrets protected.

Drift

baseline compliance monitored.
manual changes detected.
unauthorized drift investigated.
remediation tracked.

Exceptions

business reason documented.
risk assessed.
compensating controls implemented.
approver assigned.
expiry date defined.

Evidence

baseline documents retained.
configuration exports retained.
scanning results retained.
exception evidence retained.
remediation evidence retained.

116. Common PCI Secure Configuration Mistakes

Mistake 1 — Vendor Defaults Left in Place

Known credentials create easy attack paths.

Mistake 2 — Baseline Exists Only as a Document

Actual systems are never validated.

Mistake 3 — Unnecessary Services Left Running

Attack surface grows.

Mistake 4 — Weak Protocols Remain Enabled

Legacy compatibility overrides security.

Mistake 5 — Cloud Security Groups Managed Manually

Configuration drift occurs.

Mistake 6 — Management Interfaces Publicly Accessible

Privileged interfaces are exposed.

Mistake 7 — Containers Run Privileged by Default

Workload compromise gains excessive capability.

Mistake 8 — Kubernetes Namespace Considered Sufficient Security

RBAC and network controls are weak.

Mistake 9 — Exceptions Never Expire

Legacy configurations become permanent.

Mistake 10 — Golden Images Not Updated

Weak configuration repeatedly returns.

117. Weak Secure Configuration Model

Server Built
      ↓
Basic Setup
      ↓
Production

118. Strong Secure Configuration Model

Asset
      ↓
Technology Baseline
      ↓
Hardened Build
      ↓
Validation
      ↓
Approved Deployment
      ↓
Continuous Drift Monitoring
      ↓
Exception Governance
      ↓
Remediation

119. GRC Analyst Responsibilities

A GRC professional supporting secure configuration may:

Maintain configuration standards.
Maintain hardening-baseline inventories.
Coordinate baseline reviews.
Review default-account evidence.
Review configuration-compliance reports.
track drift findings.
maintain configuration exceptions.
monitor exception expiry.
coordinate remediation.
review evidence quality.
build dashboards.
support assessor configuration testing.

GRC connects:

Infrastructure

Cloud

Network

Database Teams

Engineering

DevOps

Kubernetes Teams

Security

Configuration Management

Assessors

120. Secure Configuration Maturity Model

Level 1 — Manual

Engineer Hardens
Each System

Level 2 — Standardized

Baselines

Checklists

Configuration Standards

Level 3 — Validated

Compliance Scanning

Drift Detection

Exception Tracking

Level 4 — Automated

Golden Images

IaC

Policy-as-Code

Automated Validation

Level 5 — Continuous Configuration Assurance

Continuous Drift Detection

Automated Remediation

Dynamic Policy Enforcement

Real-Time Compliance

121. Secure Configuration Mindset

For every CDE system ask:

Which secure baseline applies?

Was the system built from that baseline?

Are vendor defaults removed?

Which services are running?

Which ports are open?

Are insecure protocols enabled?

Who can administer it?

Is logging enabled?

Is encryption enabled where required?

Does configuration match the approved standard?

Has drift occurred?

Is any deviation formally approved?

When does the exception expire?

Can we prove the current configuration?

For every new system ask:

Can we prevent insecure
configuration before deployment?

For every configuration change ask:

Could this change weaken
PCI security or expand scope?

When these questions can be answered with reliable evidence, secure configuration becomes a preventive PCI control rather than an audit-time hardening exercise.

Key Takeaways

Secure configuration reduces the attack surface of CDE systems.
Vendor-default accounts, passwords, services, and settings should be reviewed and secured.
Approved configuration standards should be translated into technology-specific baselines.
Unnecessary services and ports should be removed.
Secure administrative protocols should replace insecure alternatives.
Operating systems, databases, network devices, cloud resources, containers, and Kubernetes environments require tailored hardening.
Configuration validation is necessary because documented standards do not prove implementation.
Configuration drift can silently weaken PCI controls after deployment.
IaC, golden images, configuration management, and policy-as-code can improve consistency.
Security configuration exceptions should be justified, risk assessed, approved, time-bound, and monitored.
Hardening evidence should clearly show systems, settings, dates, and scope.
GRC coordinates baseline governance, compliance evidence, drift findings, exceptions, and assessor support.

Knowledge Check

Before continuing, make sure you can answer:

What is secure configuration?
Why are vendor defaults dangerous?
What is a secure configuration baseline?
How does a standard differ from a baseline?
Why should unnecessary services be removed?
Why are insecure protocols a problem?
How should administrative interfaces be protected?
What are common OS hardening areas?
What should database hardening include?
What should network-device hardening include?
Why does cloud configuration require special attention?
How can IaC improve secure configuration?
What is configuration drift?
What causes configuration drift?
What is a golden image?
Why should configuration exceptions expire?
What are compensating controls?
What should configuration evidence demonstrate?
How should secure configuration be tested?
What role does GRC play in configuration assurance?

What’s Next?

➡️ Next: 08 — Logging & Monitoring

In the next lesson, you will move from hardening systems into detecting and investigating activity occurring across the CDE.

You will work through:

CDE Systems
      ↓
Audit Logging
      ↓
Central Collection
      ↓
Time Synchronization
      ↓
Security Monitoring
      ↓
Alerting
      ↓
Daily / Periodic Review
      ↓
Incident Investigation
      ↓
Log Retention
      ↓
Evidence

You will also build practical artifacts including a PCI Logging Standard, CDE Logging Coverage Register, Critical Event Catalog, Log Source Inventory, Daily Log Review Register, SIEM Monitoring Matrix, Time Synchronization Register, Log Retention Register, Logging Exception Register, and PCI Logging & Monitoring Testing Checklist.