Compliance Control Mapping: CMS Audit Logs to SOC 2, NIST 800-53, and HIPAA

This document maps specific compliance controls to CMS-level audit log signals emitted by the Logystera WordPress plugin and Drupal module. It focuses on the controls where CMS audit logs provide direct, actionable evidence for auditors.

Scope. This mapping covers controls where CMS-level signals are the primary or supporting evidence source. Infrastructure-level controls (network segmentation, disk encryption, physical access) are out of scope — those are satisfied by cloud provider certifications and infrastructure configuration, not application-level logs.

Signal notation. Signals are written as event_type values. Where WordPress and Drupal use different signal names for the same concept, both are listed. "WP" = WordPress plugin, "D" = Drupal module.

---

SOC 2 Trust Service Criteria

CC6 — Logical and Physical Access Controls

CC6.1 — Logical Access Security for Protected Information Assets

Control requirement. The entity implements logical access security software, infrastructure, and architectures over protected information assets to protect them from security events.

What auditors ask for:

• Evidence of authentication mechanisms (MFA, password policies)
• Logs showing who accessed what and when
• Evidence of session management controls

CMS signals that satisfy this:

Signal	CMS	Evidence provided
auth.attempt / auth.login	WP / D	Every authentication event with success/failure, timestamp, IP address. Proves authentication controls are enforced and logged.
auth.logout	WP + D	Session termination records. Proves session lifecycle is tracked.
http.request	WP + D	Every authenticated request with actor ID, path, method, status code. Demonstrates access to protected resources is logged.
rest.request / api.access	WP / D	API-level access with route, method, status, actor. Proves programmatic access is logged separately from UI access.
access.denied	D	Explicit record of denied access attempts. Proves enforcement is active.

Auditor-ready narrative: "All authentication events (success and failure) are captured with timestamp, actor identifier, source IP, and outcome. Every authenticated HTTP request is logged with the actor, resource path, and response status. Failed access attempts are recorded separately. Logs are transmitted to a centralized platform within 15 minutes and retained for [retention period]."

---

CC6.2 — Prior to Issuing System Credentials, Registration and Authorization

Control requirement. Prior to issuing system credentials and granting system access, the entity registers and authorizes new internal and external users whose access is administered by the entity.

What auditors ask for:

• Evidence of user provisioning workflow (request, approval, creation)
• Timestamps showing when access was granted
• Evidence that access was authorized before credentials were issued
• Quarterly/semi-annual user access reviews

CMS signals that satisfy this:

Signal	CMS	Evidence provided
user.created	D	New account creation with actor (who created it), roles assigned, timestamp. Proves provisioning is tracked.
user.role_changed	D	Role modifications with before/after state, actor who made the change. Proves privilege changes are logged.
wp.state_change (user-related)	WP	User lifecycle events within WordPress.
config.save (user.settings)	D	Changes to user-related configuration (registration settings, role permissions).

Auditor-ready narrative: "User account creation is logged with the creating administrator's identity, timestamp, and initial role assignment. All subsequent role changes capture the before and after state, the administrator who authorized the change, and the timestamp. These logs support user access review by providing a complete provisioning trail."

Gap note: CMS signals capture when accounts are created and who created them, but the approval workflow (ticket, manager sign-off) typically lives outside the CMS. Logystera signals provide the execution evidence; pair with ticketing system exports for the authorization evidence.

---

CC6.3 — Authorization, Modification, or Removal of Access

Control requirement. The entity authorizes, modifies, or removes access to data, software, functions, and other protected information assets based on roles, responsibilities, or the system design and changes, giving consideration to the concepts of least privilege and segregation of duties.

What auditors ask for:

• Evidence of role-based access control implementation
• Logs showing access modifications with before/after states
• Evidence of timely deprovisioning (typically within 24 hours of termination)
• Periodic access review artifacts

CMS signals that satisfy this:

Signal	CMS	Evidence provided
user.role_changed	D	Complete before/after role diff with roles_added and roles_removed arrays. Direct evidence of RBAC modifications.
user.blocked	D	Account deactivation with actor and timestamp. Proves timely deprovisioning.
user.deleted	D	Account removal with actor and timestamp. Proves access termination.
auth.login (with roles)	D	Login events include current role list, providing point-in-time evidence of effective permissions.
config.save (user.role.*)	D	Changes to role definitions themselves (not just assignments).

Auditor-ready narrative: "Role changes are logged with the complete before and after role set, including which roles were added and removed, the administrator who made the change, and the timestamp. Account deactivation and deletion events are captured with the same detail. Login events include the user's current role list, providing a point-in-time snapshot of effective permissions at each authentication."

---

CC6.6 — Restricting Access from Outside System Boundaries

Control requirement. The entity implements logical access security measures to protect against threats from sources outside its system boundaries.

What auditors ask for:

• Evidence of boundary protection (firewalls, WAF)
• Logs showing external access attempts and their outcomes
• Evidence of additional authentication for external access

CMS signals that satisfy this:

Signal	CMS	Evidence provided
auth.attempt / auth.login_failed	WP / D	Failed login attempts from external IPs. Volume and pattern data for brute-force detection.
rest.request / api.access	WP / D	All API access with source IP, method, route, and status. Proves external API access is monitored.
upload_blocked	WP	Blocked file uploads (dangerous extensions). Proves input validation at the boundary.
http.request (with IP)	WP + D	All HTTP requests with source IP. Baseline for identifying anomalous external access patterns.

---

CC6.8 — Prevention or Detection of Unauthorized or Malicious Software

Control requirement. The entity implements controls to prevent or detect and act upon the introduction of unauthorized or malicious software.

What auditors ask for:

• Evidence of malware/unauthorized software detection
• Logs showing blocked malicious uploads
• Software inventory and change tracking

CMS signals that satisfy this:

Signal	CMS	Evidence provided
wp.state_change (plugin/theme)	WP	Plugin activation, deactivation, updates. Complete software change trail.
module.install / module.uninstall	D	Module installation and removal with actor and sync flag.
wp.environment / drupal.environment	WP / D	Periodic software inventory snapshot (installed plugins/modules, versions).
upload_blocked	WP	Blocked uploads of executable file types (.php, .exe, etc.).
wp.integrity	WP	File integrity monitoring of critical files (wp-config.php, .htaccess). Detects unauthorized modification.
config.import	D	Configuration imports tracked with actor. Detects bulk configuration injection.

Auditor-ready narrative: "The CMS agent maintains a complete software inventory emitted every 15 minutes, including all installed plugins/modules and their versions. Every software change (installation, activation, deactivation, update, removal) is logged with the actor and timestamp. Critical file integrity is monitored hourly via hash comparison, and unauthorized file uploads are blocked and logged."

---

CC7 — System Operations

CC7.1 — Detection and Monitoring to Meet Objectives

Control requirement. To meet its objectives, the entity uses detection and monitoring procedures to identify changes to configurations that result in the introduction of new vulnerabilities, and susceptibilities to newly discovered vulnerabilities.

What auditors ask for:

• Evidence of configuration change monitoring
• Logs showing configuration baseline and deviations
• Vulnerability scanning results (out of scope for CMS signals)

CMS signals that satisfy this:

Signal	CMS	Evidence provided
config.save / config.delete	D	Every configuration change with config object name, category, change type, actor. Complete configuration audit trail.
config.import / config.export	D	Bulk configuration changes tracked with actor.
wp.environment / drupal.environment	WP / D	Software version snapshot detects outdated/vulnerable components (processor can cross-reference with CVE databases).
wp.integrity	WP	Critical file hash changes detected within 1 hour.
wp.state_change (core_updated, plugin_updated, theme_updated)	WP	All software updates tracked with timestamp.
update.status	D	Drupal update availability status changes.

Auditor-ready narrative: "Every configuration change in the CMS is logged with the configuration object name, change type (create/update/delete), and the actor who made the change. Software inventory is captured periodically with version details, enabling detection of outdated components. Critical file integrity is monitored via hash comparison."

---

CC7.2 — Monitoring System Components for Anomalies

Control requirement. The entity monitors system components and the operation of those components for anomalies that are indicative of malicious acts, natural disasters, and errors affecting the entity's ability to meet its objectives.

What auditors ask for:

• Evidence of anomaly detection capabilities
• Alert configuration and thresholds
• Sample alerts triggered during the audit period
• Evidence that detection covers: unauthorized access, compromised credentials, unusual activity patterns

CMS signals that satisfy this:

Signal	CMS	Evidence provided
auth.attempt / auth.login_failed	WP / D	Failed authentication volume — processor derives brute-force detection metrics.
http.request	WP + D	Request volume, error rate (4xx/5xx), admin area access frequency. Baseline for anomaly detection.
php.warning / php.fatal / php.error	WP / D	Application error rate spikes indicate compromise or system degradation.
db_error / db_deadlock / db_connection_failed	WP	Database-level anomalies indicating infrastructure issues or attack patterns.
db.slow_query	D	Query performance anomalies indicating resource exhaustion or injection attempts.
memory_near_limit	WP	Resource exhaustion approaching thresholds.
cron.run / wp.cron	WP	Cron health and execution anomalies (missed schedules, errors during execution).
perf.hook_timing	WP	Performance profiling detects anomalous execution patterns (potential cryptominers, resource abuse).

Auditor-ready narrative: "The platform continuously monitors authentication patterns, HTTP traffic volume and error rates, application error frequency, database health, and resource utilization. Anomaly detection rules evaluate these signals against configurable thresholds. When thresholds are exceeded, alerts are generated and routed to the incident response team."

---

CC7.3 — Evaluation of Security Events

Control requirement. The entity evaluates security events to determine whether they could or have resulted in a failure of the entity to meet its objectives and, if so, takes actions to prevent or address such failures.

What auditors ask for:

• Evidence that detected events are triaged and classified
• Escalation procedures for confirmed incidents
• Documentation showing event-to-incident workflow

CMS signals that satisfy this (as input to the triage process):

Signal	CMS	Evidence provided
All auth.* signals	WP + D	Authentication events feed into rule evaluation. The processor classifies patterns (e.g., 10 failed logins in 5 minutes from same IP = potential brute force).
wp.integrity	WP	File integrity change = automatic high-severity event requiring investigation.
upload_blocked	WP	Blocked malicious upload = automatic security event logged and evaluated.
access.denied	D	Authorization failures feed into pattern analysis.
wp.state_change / module.install	WP / D	Unauthorized software changes trigger security event evaluation.

Auditor-ready narrative: "Security-relevant signals are processed by the Logystera rule engine, which evaluates events against defined detection rules. Rules classify events by severity and trigger alerts that route to the appropriate response team. The rule engine evaluates authentication anomalies, file integrity changes, unauthorized software modifications, and access control violations."

---

CC7.4 — Incident Response

Control requirement. The entity responds to identified security incidents by executing a defined incident response program.

What auditors ask for:

• Documented incident response plan
• Evidence of incident response execution (communication, containment, remediation)
• Post-incident review documentation

CMS signals that support incident response (forensic evidence):

All CMS signals serve as forensic evidence during incident response. Key signals for investigation:

Signal	CMS	Forensic value
http.request	WP + D	Request timeline reconstruction. Correlate via request_id.
auth.*	WP + D	Authentication timeline — when was the account compromised?
config.save / wp.state_change	D / WP	What did the attacker change? Configuration and software modification timeline.
wp.integrity	WP	When were critical files modified?
rest.request / api.access	WP / D	API abuse timeline.
user.role_changed / user.created	D	Privilege escalation and backdoor account creation timeline.

---

CC8 — Change Management

CC8.1 — Changes to Infrastructure, Data, Software, and Procedures

Control requirement. The entity authorizes, designs, develops or acquires, configures, documents, tests, approves, and implements changes to infrastructure, data, software, and procedures to meet its objectives.

What auditors ask for:

• Change management tickets with approval, testing, and deployment evidence
• Logs showing what changed, when, and who authorized it
• Evidence of separation between development and production

CMS signals that satisfy this:

Signal	CMS	Evidence provided
wp.state_change	WP	All software lifecycle events: plugin_activated, plugin_deactivated, theme_switched, core_updated, plugin_updated, theme_updated. Timestamp and request context for each.
module.install / module.uninstall	D	Module changes with is_syncing flag distinguishing manual changes from config sync (deployment pipeline).
config.save / config.delete	D	Every configuration change with actor, category, and change type.
config.import	D	Configuration sync operations (typical deployment mechanism). Actor and timestamp prove the deployment event.
wp.environment / drupal.environment	WP / D	Before/after software inventory snapshots with changed flag. Proves the change was applied and the resulting state.

Auditor-ready narrative: "Every software change in the CMS is logged with the type of change (install, update, activate, deactivate, remove), the affected component, and the actor. Configuration changes are tracked at the individual configuration object level with actor attribution. Drupal distinguishes between manual changes and config-sync deployments via the is_syncing flag, proving changes followed the deployment pipeline. Periodic environment snapshots provide point-in-time proof of the software inventory."

Gap note: CMS signals capture the execution of changes. The approval and testing evidence (peer review, QA sign-off) typically lives in version control and CI/CD systems. Logystera signals prove what changed and when in production; pair with Git history and deployment pipeline logs for the full CC8.1 evidence chain.

---

NIST 800-53 Rev. 5

AC — Access Control

AC-2 — Account Management

Control requirement. Create, enable, modify, disable, and remove accounts in accordance with policy. Monitor the use of accounts. Review accounts for compliance with account management requirements.

What auditors/assessors ask for:

• Evidence of account lifecycle management (creation, modification, disabling, removal)
• Account review documentation (periodic reviews of active accounts)
• Automated notifications for account lifecycle events

CMS signals:

Signal	CMS	Evidence provided
user.created	D	Account creation with actor, roles, timestamp.
user.role_changed	D	Account modification with complete before/after role diff.
user.blocked	D	Account disabling with actor and timestamp.
user.deleted	D	Account removal with actor and timestamp.
auth.login / auth.attempt	D / WP	Account usage monitoring — last login timestamps, frequency.
auth.login_failed	D / WP	Failed access attempts on accounts (potential unauthorized use).

AC-2 enhancement (7) — Privileged accounts. The auth.login signal from Drupal includes the roles array, enabling the processor to flag privileged account usage (accounts with administrator role). The user.role_changed signal tracks privilege escalation.

---

AC-6 — Least Privilege

Control requirement. Employ the principle of least privilege, allowing only authorized accesses for users which are necessary to accomplish assigned tasks.

What assessors ask for:

• Evidence that users have only the minimum access necessary
• Logs showing privileged actions and who performed them
• Evidence of privilege escalation detection

CMS signals:

Signal	CMS	Evidence provided
user.role_changed	D	Privilege changes with roles_added/roles_removed. Proves roles are actively managed.
auth.login (with roles)	D	Point-in-time role snapshot at login. Enables periodic least-privilege review.
http.request (is_admin)	WP + D	Tracks admin-area access by user. Identifies users accessing administrative functions.
config.save	D	Configuration changes attributed to specific actors. Proves only authorized users modify settings.
rest.request / api.access	WP / D	API access patterns by user. Identifies users with unnecessary API access.

---

AC-7 — Unsuccessful Logon Attempts

Control requirement. Enforce a limit of consecutive invalid logon attempts by a user and automatically lock/delay/disable the account or take other action when the maximum is exceeded.

What assessors ask for:

• Evidence of account lockout configuration
• Logs showing failed login attempts with count, timing, and source
• Evidence that lockout/throttling was enforced

CMS signals:

Signal	CMS	Evidence provided
auth.attempt (success: false)	WP	Every failed login with HMAC-hashed username, IP, timestamp. Processor derives consecutive failure counts.
auth.login_failed	D	Failed login with username (plaintext for non-existent accounts), IP.
auth.attempt (success: true)	WP	Successful login after failures — proves account was not permanently locked (or was unlocked).

Auditor-ready narrative: "Every failed authentication attempt is logged with timestamp, source IP, and hashed user identifier. The Logystera processor evaluates failed login patterns against configurable rules (e.g., N failures within M minutes from same IP or targeting same account) and generates alerts when thresholds are exceeded."

---

AU — Audit and Accountability

AU-2 — Event Logging

Control requirement. Identify the types of events that the system is capable of logging in support of the audit function. Coordinate the event logging function with other organizational entities requiring audit-related information.

What assessors ask for:

• Documented list of auditable events
• Evidence that the identified events are actually being logged
• Justification for event selection

CMS signals — complete auditable event inventory:

Event category	Signals	Description
Authentication	auth.attempt, auth.login, auth.login_failed, auth.logout	All authentication lifecycle events
Account management	user.created, user.role_changed, user.blocked, user.deleted	Account lifecycle and privilege changes
Configuration changes	config.save, config.delete, config.import, config.export	All CMS configuration modifications
Software changes	wp.state_change, module.install, module.uninstall	Plugin/module/theme/core lifecycle
File integrity	wp.integrity	Critical file hash monitoring
Access attempts	http.request, rest.request, api.access, access.denied	All resource access with outcomes
Malicious input	upload_blocked	Blocked dangerous file uploads
System health	wp.environment, drupal.environment, drupal.heartbeat	System state snapshots
Errors	php.warning, php.fatal, php.error, db_error, db.*	Application and database errors
Content workflow	content.moderation, content.created, content.updated, content.deleted	Content lifecycle (Drupal)
Scheduled tasks	cron.run, wp.cron	Scheduled task execution and health

This table itself serves as the AU-2 "auditable events list" artifact.

---

AU-3 — Content of Audit Records

Control requirement. Ensure that audit records contain information that establishes the following: what type of event occurred, when the event occurred, where the event occurred, the source of the event, the outcome of the event, and the identity of any individuals, subjects, or objects associated with the event.

What assessors ask for (the "who, what, when, where, outcome" test):

Every audit record must answer these five questions. Here is how CMS signals satisfy each:

Required element	How CMS signals satisfy it
What (event type)	event_type field on every signal (e.g., auth.login, config.save).
When (timestamp)	timestamp / created_at field on every signal. Unix epoch, processor-normalized.
Where (source)	labels.site.url (WP) or entity context (D). Identifies the specific CMS instance.
Source (origin)	labels.actor.ip / ip field. Client IP on every signal. labels.req.ua for user agent.
Outcome	payload.success (auth), payload.status (HTTP), payload.change_type (config). Signal-type-specific outcome fields.
Who (identity)	labels.actor.user_id (WP) or actor_uid / uid (D). HMAC-hashed for privacy, but consistently correlatable.

AU-3 enhancement (1) — Additional information. Signals also include: request_id (WP) / event_id (D) for correlation, HTTP method and path, role list at time of action (Drupal auth.login), and before/after state for changes (user.role_changed).

---

AU-6 — Audit Record Review, Analysis, and Reporting

Control requirement. Review and analyze system audit records for indications of inappropriate or unusual activity. Report findings to appropriate organizational officials. Adjust the level of audit record review, analysis, and reporting as needed.

What assessors ask for:

• Evidence of regular log review (automated or manual)
• Alert/rule configuration showing what patterns are monitored
• Sample alerts generated during the audit period
• Evidence that findings were reported and acted upon

CMS signals role: All CMS signals feed into the Logystera processor, which applies rule-based detection. The processor's metric definitions and rule DSL serve as the "review and analysis" mechanism. Evidence artifacts include:

• Metric definitions showing which patterns are monitored (stored in definitions table)
• Rule definitions showing alert thresholds and conditions
• Alert history showing triggered rules and their disposition
• Dashboard screenshots showing ongoing monitoring

---

AU-12 — Audit Record Generation

Control requirement. Provide audit record generation capability for the events identified in AU-2. Allow designated organizational personnel to select which auditable events are to be logged. Generate audit records containing the information identified in AU-3.

What assessors ask for:

• Evidence that logging is configurable (can enable/disable specific event types)
• Evidence that logging is active and generating records
• Evidence that generated records meet AU-3 content requirements

CMS signals role:

Both the WordPress plugin and Drupal module provide configurable signal selection:

• WordPress: Hook flags (environment_signals, cron_signals, integrity_signals, hook_timing) control which signal categories are active. Admin UI at Settings > Logystera.
• Drupal: Config keys per signal type (signals.config_save, signals.auth_login, advanced_signals.content_moderation, etc.) with default on/off states. Admin UI at /admin/config/system/logystera.

This configuration capability directly satisfies AU-12's "select which auditable events are to be logged" requirement.

---

CM — Configuration Management

CM-3 — Configuration Change Control

Control requirement. Determine and document the types of changes to the system that are configuration-controlled. Review proposed changes and approve or disapprove with explicit consideration for security and privacy impact. Document change decisions. Implement only approved changes. Retain records of changes.

What assessors ask for:

• Change control records with approval, testing, implementation evidence
• Logs showing configuration changes with attribution
• Evidence that unauthorized changes are detected

CMS signals:

Signal	CMS	Evidence provided
config.save / config.delete	D	Every configuration object change with name, category, actor, change type. Granular enough to show individual setting changes.
config.import	D	Bulk configuration deployment with actor. The is_syncing flag on module.install distinguishes pipeline-driven changes from manual ones.
wp.state_change	WP	Software configuration changes (plugin/theme activation, core updates).
wp.integrity	WP	Detects unauthorized changes to critical configuration files.
views.change	D	Views configuration changes (advanced signal).

---

CM-6 — Configuration Settings

Control requirement. Establish and document configuration settings for components of the system. Identify, document, and approve any deviations from established configuration settings. Monitor and control changes to the configuration settings.

What assessors ask for:

• Documented baseline configuration
• Evidence of configuration monitoring
• Logs showing deviations from baseline

CMS signals:

Signal	CMS	Evidence provided
wp.environment / drupal.environment	WP / D	Periodic configuration baseline snapshot (versions, installed software, settings). The changed flag detects deviations.
config.save	D	Real-time configuration change detection with attribution.
wp.integrity	WP	Critical file configuration integrity monitoring via hash comparison.

---

SI — System and Information Integrity

SI-4 — System Monitoring

Control requirement. Monitor the system to detect attacks, indicators of potential attacks, unauthorized local/network/remote connections, and identify unauthorized use.

What assessors ask for:

• Evidence of monitoring tools and their configuration
• Alert rules and thresholds
• Sample alerts from the monitoring period
• Evidence that monitoring covers: inbound/outbound traffic, unauthorized access, privilege escalation, malware

CMS signals:

Monitoring objective	Signals	How it satisfies SI-4
Attack detection	auth.login_failed, upload_blocked, access.denied	Failed logins, blocked uploads, and denied access feed brute-force and attack pattern detection rules.
Unauthorized access	http.request (admin paths by non-admin users), rest.request / api.access	API and admin access monitoring. Processor rules flag access from unexpected roles or IPs.
Privilege escalation	user.role_changed, user.created (with admin roles)	New admin account creation and role elevation trigger alerts.
Malware/unauthorized software	wp.state_change, module.install, wp.integrity, upload_blocked	Software changes, file integrity violations, and blocked malicious uploads.
System degradation	php.fatal, db_error, memory_near_limit, db.slow_query	Application errors, database failures, and resource exhaustion.

---

SI-7 — Software, Firmware, and Information Integrity

Control requirement. Employ integrity verification tools to detect unauthorized changes to software, firmware, and information.

What assessors ask for:

• Evidence of file integrity monitoring (FIM)
• Logs showing integrity check results
• Evidence of response to integrity violations

CMS signals:

Signal	CMS	Evidence provided
wp.integrity	WP	Hash-based integrity monitoring of wp-config.php and .htaccess. Emits old and new hashes when changes are detected. Checked hourly.
wp.environment / drupal.environment	WP / D	Software inventory with version tracking. Detects unexpected version changes (potential tampering).
wp.state_change (plugin_updated, core_updated)	WP	Authorized update events. Enables distinguishing authorized updates from unauthorized file changes.
config.save / config.import	D	Configuration integrity — every change is attributed to an actor. Unauthorized configuration changes are detectable by correlating actor with expected change windows.

---

HIPAA Technical Safeguards (45 CFR 164.312)

164.312(a)(1) — Access Control

Standard. Implement technical policies and procedures for electronic information systems that maintain electronic protected health information (ePHI) to allow access only to those persons or software programs that have been granted access rights.

(a)(2)(i) — Unique User Identification (Required)

What auditors ask for: Evidence that each user has a unique identifier and that all actions are attributable to a specific user.

Signal	CMS	Evidence provided
auth.login / auth.attempt	D / WP	Every authentication tied to a unique user identifier (uid or user_id).
http.request	WP + D	Every request attributed to a specific actor.user_id or actor_uid.
config.save, user.created, etc.	D	All administrative actions include actor_uid.

HIPAA note: WordPress signals use integer user_id (0 = anonymous). Drupal signals use HMAC-hashed uid. Both provide unique, consistent user identification across all signal types.

(a)(2)(iii) — Automatic Logoff (Addressable)

What auditors ask for: Evidence of session timeout configuration and enforcement.

Signal	CMS	Evidence provided
auth.logout	WP + D	Session termination events. Proves logout is tracked.
http.request (with timestamps per user)	WP + D	Session activity timeline. Processor can derive inactivity gaps.

Gap note: CMS signals do not directly capture session timeout enforcement (that is a server/application configuration). Signals provide evidence of logout events and session activity patterns. Pair with CMS configuration exports showing session timeout settings.

(a)(2)(iv) — Encryption and Decryption (Addressable)

Not directly evidenced by CMS audit signals. This is satisfied by infrastructure configuration (TLS, disk encryption).

---

164.312(b) — Audit Controls (Required)

Standard. Implement hardware, software, and/or procedural mechanisms that record and examine activity in information systems that contain or use electronic protected health information.

What auditors ask for:

• Evidence that all access to ePHI systems is logged
• Evidence that logs are reviewed regularly
• Evidence of log integrity (tamper protection)
• Evidence of log retention

CMS signals — complete coverage:

This is the core requirement that CMS audit logging directly satisfies. The complete signal set provides:

Audit requirement	Signals	Coverage
Authentication logging	auth.* signals	All login attempts, successes, failures, logouts
Access logging	http.request, rest.request, api.access	All resource access with actor, path, outcome
Administrative action logging	config.save, user.*, module.*, wp.state_change	All configuration and administrative changes with actor
Error and anomaly logging	php.*, db_*, memory_near_limit	Application and database errors
Integrity monitoring	wp.integrity, wp.environment	File and system integrity checks

Log integrity. Signals are HMAC-signed before transmission to the gateway. The Logystera platform stores processed signals in PostgreSQL (durable, append-only for audit purposes) and exposes metrics via VictoriaMetrics (time-series with configurable retention).

Log review. Logystera's rule engine provides automated review. Dashboard access and alert history provide evidence of regular review.

---

164.312(c)(1) — Integrity (Required)

Standard. Implement policies and procedures to protect electronic protected health information from improper alteration or destruction.

(c)(2) — Mechanism to Authenticate Electronic Protected Health Information (Addressable)

What auditors ask for: Evidence that data integrity is verified (checksums, hashes, digital signatures).

Signal	CMS	Evidence provided
wp.integrity	WP	File integrity verification via SHA hash comparison. Detects unauthorized modification of critical files.
config.save / config.delete	D	Configuration change attribution. Every modification has an actor and timestamp, enabling detection of unauthorized changes.
content.moderation	D	Content state transitions are logged with actor. Proves content changes follow workflow.
content.created / content.updated / content.deleted	D	Complete content lifecycle audit trail.

---

164.312(d) — Person or Entity Authentication (Required)

Standard. Implement procedures to verify that a person or entity seeking access to electronic protected health information is the one claimed.

What auditors ask for: Evidence of authentication mechanisms and their enforcement.

Signal	CMS	Evidence provided
auth.attempt / auth.login / auth.login_failed	WP / D	Complete authentication trail. Proves authentication is required and enforced for all access.
auth.login (with roles)	D	Authentication includes role verification — proves identity is verified before access is granted.
http.request (user_id = 0 vs. authenticated)	WP + D	Distinguishes authenticated from anonymous requests. Proves authentication enforcement.

---

Cross-Framework Summary: Signals by Compliance Value

This table ranks CMS signals by how many controls they provide evidence for across all three frameworks.

Signal	Controls evidenced	Primary compliance value
auth.attempt / auth.login / auth.login_failed	CC6.1, CC6.6, CC7.2, CC7.3, AC-2, AC-7, AU-2, AU-3, AU-12, SI-4, 164.312(a), 164.312(b), 164.312(d)	Authentication and access control — the single most valuable signal category for compliance
http.request	CC6.1, CC7.2, AC-6, AU-2, AU-3, SI-4, 164.312(a), 164.312(b)	Access monitoring — proves all resource access is logged with actor attribution
config.save / config.delete	CC7.1, CC8.1, CM-3, CM-6, AU-2, SI-4, 164.312(b), 164.312(c)	Configuration integrity — proves all changes are tracked and attributed
user.created / user.role_changed / user.blocked / user.deleted	CC6.2, CC6.3, AC-2, AC-6, AU-2, SI-4, 164.312(a), 164.312(b)	Account lifecycle — proves provisioning, privilege changes, and deprovisioning are logged
wp.state_change / module.install / module.uninstall	CC6.8, CC7.1, CC8.1, CM-3, AU-2, SI-4, SI-7	Software change management — proves all software changes are tracked
wp.environment / drupal.environment	CC6.8, CC7.1, CM-6, AU-2, SI-7, 164.312(b)	Configuration baseline — periodic inventory proving system state
wp.integrity	CC6.8, CC7.1, CC7.3, SI-4, SI-7, 164.312(c)	File integrity monitoring — detects unauthorized modification
rest.request / api.access	CC6.1, CC6.6, AC-6, AU-2, SI-4, 164.312(b)	API access monitoring — proves programmatic access is separately logged
upload_blocked	CC6.6, CC6.8, CC7.3, SI-4	Input validation — proves malicious input is blocked and logged
auth.logout	CC6.1, AU-2, 164.312(a)	Session management — proves session lifecycle is tracked

---

Gaps and Complementary Evidence Sources

CMS audit signals are strong evidence for execution-level controls but do not cover every control requirement in isolation. Common gaps and how to fill them:

Gap	Controls affected	Complementary evidence source
Access approval workflow	CC6.2, CC6.3, AC-2	Ticketing system (Jira, ServiceNow) showing request-and-approval before account creation
Change approval and testing	CC8.1, CM-3	Git history (peer review), CI/CD pipeline logs (test results), deployment approvals
Network boundary controls	CC6.6, SI-4	Firewall/WAF logs, VPC flow logs, Cloudflare analytics
Encryption at rest/in transit	CC6.1, 164.312(a)(2)(iv), 164.312(e)	Infrastructure configuration (TLS settings, disk encryption), cloud provider certifications
Session timeout configuration	164.312(a)(2)(iii)	CMS configuration exports, server configuration
Physical access controls	CC6.4, CC6.5	Cloud provider SOC 2 report (AWS, GCP, Azure)
Incident response plan	CC7.4	Written IRP document, tabletop exercise records
Backup and recovery	CC7.5	Backup configuration, recovery test results
Vulnerability scanning	CC7.1	Scanner reports (Nessus, Qualys), dependency audit results
Log retention and integrity	AU-11, 164.312(b)	Logystera platform configuration showing retention period, PostgreSQL backup policy

---

Implementation Checklist

For maximum compliance coverage from CMS audit signals, ensure these signal categories are enabled:

WordPress Plugin — Minimum for Compliance

Hook flag	Default	Required for
Core signals (auth, http, state_change)	ON	All frameworks — non-negotiable
environment_signals	ON	CC7.1, CM-6, SI-7, 164.312(b)
integrity_signals	ON	CC6.8, SI-7, 164.312(c)
cron_signals	ON	CC7.2 (system health monitoring)
hook_timing	OFF	CC7.2 (performance anomaly detection) — enable if performance monitoring is in audit scope

Drupal Module — Minimum for Compliance

Config key	Default	Required for
signals.auth_login	ON	All frameworks
signals.auth_login_failed	ON	AC-7, CC6.1, CC6.6, CC7.2
signals.auth_logout	ON	CC6.1, 164.312(a)
signals.config_save	ON	CC7.1, CC8.1, CM-3, CM-6
signals.config_delete	ON	CC7.1, CM-3
signals.config_import	ON	CC8.1, CM-3
signals.user_created	ON	CC6.2, AC-2, 164.312(a)
signals.user_updated (role_changed, blocked)	ON	CC6.3, AC-2, AC-6
signals.user_deleted	ON	CC6.3, AC-2
signals.module_install	ON	CC6.8, CC8.1, SI-7
signals.module_uninstall	ON	CC6.8, CC8.1
signals.page_visit (http.request)	ON	CC6.1, AU-3, SI-4, 164.312(b)
advanced_signals.content_moderation	OFF	164.312(c) — enable if CMS manages ePHI content
advanced_signals.api_access	OFF	CC6.6, SI-4 — enable if API access is in audit scope

---

References

• AICPA Trust Services Criteria (2017)
• NIST SP 800-53 Rev. 5
• 45 CFR 164.312 — HIPAA Technical Safeguards