Why CER Audit Logs Matter (and What Inspectors Mean by “Evidence”)
Under the CER Directive, inspectors don’t just assess whether controls exist—they verify that controls are operating consistently and that your organization can prove it. Audit logs are the proof layer: time-stamped, attributable records that show what happened, who did it, and what the outcome was.
In practice, reviewers typically evaluate logs as part of broader evidence for:
- Risk management and protective measures
- Incident prevention, detection, and response
- Business continuity and resilience
- Governance, accountability, and continuous improvement
Your goal is to produce logs and documentation that are complete, trustworthy, accessible, and explainable.
What Inspectors Actually Check in Audit Logs
Inspectors generally focus on four questions. Structure your logging program so you can answer them quickly.
1) Can you demonstrate coverage of critical services and assets?
They look for evidence that you’re logging:
- Critical systems supporting essential services
- Security-relevant events (not just operational metrics)
- Third-party and outsourced components where they affect critical operations
Typical pitfalls:
- Logging exists only for perimeter devices, not core systems.
- SaaS/cloud audit logs aren’t retained or reviewed.
- OT/industrial environments are unlogged or “too legacy to log.”
2) Are logs reliable, tamper-resistant, and attributable?
They assess whether a log can be trusted as evidence:
- Time synchronization across systems
- Identity linkage (a real user/service identity, not shared accounts)
- Integrity controls (restricted access, immutability where feasible, change tracking)
- Separation of duties (people who administer systems aren’t the only ones who can alter logs)
Typical pitfalls:
- Shared admin accounts prevent attribution.
- Clocks differ across systems, making timelines unreliable.
- Logs stored locally on the same host are easy to delete.
3) Do you retain logs long enough—and can you retrieve them quickly?
Reviewers often test whether you can:
- Produce logs for a specified date range on request
- Show retention settings and proof they’re enforced
- Retrieve logs in a usable format without heroic manual effort
Typical pitfalls:
- Retention is defined in policy but not implemented in tools.
- Logs exist but are not searchable, indexed, or exportable.
- Archived logs cannot be restored within reasonable time.
4) Are logs reviewed and acted on?
Inspectors want more than “we collect logs.” They look for:
- Documented review processes (who reviews what, how often)
- Alerting and escalation for high-risk events
- Evidence of follow-up actions: tickets, investigations, corrective measures
Typical pitfalls:
- Alerts are configured but no one is accountable for triage.
- Reviews are informal (“we look sometimes”) with no records.
- Incidents are handled but not linked back to log evidence.
Step-by-Step: Build an “Inspector-Ready” Audit Logging Package
Step 1: Define your “loggable events” for critical operations
Start with a controlled list of what must be logged. Keep it practical and tied to risks.
At minimum, define events for:
- Identity and access
- Successful/failed logins (including privileged access)
- MFA enrollments and resets
- Role/permission changes
- New accounts, disabled accounts, reactivations
- System and configuration
- Critical configuration changes (firewalls, IAM policies, backups, EDR settings)
- Software deployments and updates to critical systems
- Changes to logging settings themselves
- Security detections
- Malware/EDR alerts, quarantines, and exceptions
- IDS/IPS alerts where applicable
- Data loss prevention triggers (if used)
- Network and boundary
- Firewall rule changes and admin access
- Remote access sessions (VPN, bastion, jump hosts)
- Operational resilience
- Backup job success/failure
- Restore tests and results
- Failover events and continuity plan activations
- Incident response
- Incident declarations, severity changes
- Containment actions (host isolation, account lockout)
- Evidence handling steps (exports, hashes, chain-of-custody where relevant)
Deliverable to prepare: A one-page “Minimum Audit Logging Standard” for critical services, mapping event types to systems.
Step 2: Standardize log fields so events are explainable
Inspectors favor logs that are consistent and interpretable. Whether your logs are JSON, syslog, or vendor-native exports, ensure you can produce (or transform into) a consistent schema.
Aim to include:
- Timestamp (with timezone and precision)
- Event name/type (normalized categories help)
- Outcome (success/failure/blocked)
- Actor identity (user/service account, role, auth method)
- Source (IP, hostname, device ID)
- Target (system, resource, account, configuration item)
- Action performed (created/modified/deleted/executed)
- Correlation identifiers (request ID, session ID, ticket ID)
- System of record (log source and version)
Actionable advice:
- Create a simple field mapping table: each log source → which fields it provides → how you normalize missing fields.
- Ensure identity events can be tied to real individuals (unique accounts) and privileged sessions.
Step 3: Prove integrity: collection architecture and controls
Inspectors often ask how you prevent deletion or manipulation.
Show these controls:
- Centralized collection: forward logs to a separate log platform/SIEM or centralized repository
- Access restrictions: least privilege, separate admin roles for log systems
- Immutability where feasible: write-once or restricted retention locks for high-value logs
- Audit trail of log access: who searched/exported logs, when, and why
- Time synchronization: NTP or equivalent, monitored for drift
Deliverable to prepare: A logging architecture diagram including sources, transport, storage, retention, and access roles.
Step 4: Set retention and retrieval targets you can defend
Rather than picking arbitrary periods, align retention to:
- Investigation needs (how far back you typically look)
- Regulatory and contractual obligations
- Storage and cost realities
- Criticality of the service
Practical approach:
- Define two tiers:
- Hot/searchable (fast access for investigations)
- Archived (longer retention, slower retrieval, still accessible)
What inspectors tend to test:
- Can you export logs for a requested window (e.g., a week around an incident)?
- Can you demonstrate retention settings with system screenshots/exports?
- Can you restore archived logs within a documented timeframe?
Deliverable to prepare: A retention schedule by log source and tier, plus a short retrieval procedure.
Step 5: Operationalize review: what gets checked, how often, and by whom
Logs don’t satisfy oversight unless you can show routine review and escalation.
Create a review plan with:
- Daily/near-real-time monitoring for high-risk security alerts
- Weekly reviews of privileged access and configuration changes
- Monthly trend checks (recurring failures, noisy accounts, unusual access patterns)
- Quarterly control checks (are sources still logging? are parsers working?)
Make it inspectable:
- Keep review records: dashboards snapshots, signed checklists, or ticket references
- Tie findings to actions: tuning rules, closing gaps, training, or disciplinary steps
Deliverable to prepare: A “Logging & Monitoring SOP” that names roles, frequencies, and escalation paths.
The Documentation Inspectors Expect Alongside Logs
Logs alone are rarely enough. Prepare a compact evidence set:
- Logging policy/standard
- Scope, responsibilities, minimum event types, retention principles
- Asset and service inventory link
- Which systems support essential services and how they’re covered by logging
- Access control records
- Who can administer the log platform; approval evidence for privileged access
- Change management evidence
- How logging configurations are changed, reviewed, and recorded
- Incident response linkage
- Example incidents showing how logs were used to detect, investigate, and resolve
- Continuity and backup evidence
- Proof that backup failures generate logs and are acted upon
- Third-party assurances
- Evidence that outsourced providers supply audit logs or reports for relevant components
Keep these materials versioned and controlled, with a clear owner.
Log Formats and Export Readiness: Make Evidence Portable
Inspectors may request samples in common export forms. Even if your platform is proprietary, ensure you can produce:
- Raw event exports (unaltered where possible)
- Normalized exports (with your schema fields)
- Human-readable summaries (timelines, notable events, access reviews)
Checklist for export readiness:
- Exports include timestamps, identity, action, target, outcome
- Exports preserve original event IDs and source references
- You can explain any transformations (parsing, enrichment, correlation)
- Sensitive data handling is documented (redaction rules and approvals)
Pre-Audit Self-Test: Questions to Run Before Inspectors Arrive
Use this as a practical drill:
- Can we produce logs for a critical system for a specific date/time window within one hour?
- Can we prove time synchronization across sources used in incident timelines?
- Can we show who accessed the logs and what they searched/exported?
- Can we demonstrate that privileged access is uniquely attributable (no shared admins)?
- Can we show at least one example where a log review led to an action or improvement?
- Can we demonstrate retention settings are enforced, not just written in policy?
- Can we show coverage for third-party dependencies that support critical services?
If any answer is “not reliably,” prioritize remediation—inspectors typically reward clear control ownership and a credible improvement plan over vague assurances.
Practical Next Steps (90-Day Improvement Plan)
- Weeks 1–2: Build the minimum logging standard and inventory mapping for critical services.
- Weeks 3–6: Fix attribution and integrity gaps (unique admin accounts, central forwarding, time sync monitoring).
- Weeks 7–10: Implement retention tiers and test export/retrieval with a timed exercise.
- Weeks 11–13: Formalize review routines and keep records; run a tabletop incident using real log exports as evidence.
A CER audit goes smoother when your logging is treated as an operational capability—not a compliance artifact. The strongest position is being able to tell a coherent story, quickly, with trustworthy logs that match documented processes and real-world outcomes.