Event logging

Event logging is one of the fastest ways an auditor will test whether your PII protection program works in practice: can you reconstruct who accessed PII, what they did, and whether the access was appropriate. ISO/IEC 27018:2019 Clause 12.4.1 is explicit that logs must be produced, kept, and regularly reviewed, and it singles out access to PII as the priority. ¹

For a CCO or GRC lead, the operational challenge is not “turn on logging.” It is defining a defensible logging scope, getting engineering to emit the right events from the right places, centralizing and protecting those logs so they are trustworthy, and proving that reviews happen and drive action. The requirement becomes real only when your team can answer common examination questions: Which PII stores are covered? Can you show a PII access event for a privileged admin? How do you detect suspicious access patterns? What happens after an alert triggers?

This page gives requirement-level implementation guidance you can hand to security engineering and cloud operations, plus the evidence package you should expect to produce.

Regulatory text

Requirement (verbatim excerpt): “Event logs recording user activities, exceptions, faults and information security events shall be produced, kept and regularly reviewed, with particular attention to logging access to PII.” ¹

Operator interpretation:
You must (1) generate logs for security-relevant activity, (2) retain them, and (3) review them on a recurring basis. The “particular attention” clause raises the bar for PII: you should be able to identify who accessed PII, when they accessed it, what system they used, and what they did. Where your systems support it, you should also capture the business purpose or ticket/reference that authorizes the access.

Plain-English interpretation (what this means in practice)

Event logging under ISO 27018 is an accountability control for cloud PII processing. If a customer asks, “Who accessed my data?” you need an evidence trail. If you have a suspected incident, you need forensic-quality records. If an auditor tests the control, they will expect to see not just raw logs, but a working process that detects and responds to risky events.

Your logs need to cover four buckets called out in the text:

• User activities: logons, role assumption, data reads/writes/exports, admin actions, privilege changes.
• Exceptions: authorization failures, denied requests, application errors that indicate abuse or misconfiguration.
• Faults: system failures that could impact integrity/availability or cause unusual data behavior.
• Information security events: alerts, policy violations, malware detections, suspicious network activity.

And you must treat PII access as the highest-priority subset across these buckets. ¹

Who it applies to (entity and operational context)

Primary applicability: Cloud Service Providers acting as PII processors in a public cloud context. ¹

Operationally, assume it applies anywhere your organization:

• Hosts, processes, or administers PII for customers (multi-tenant SaaS, managed services, data platforms).
• Operates privileged access paths to PII (SRE, DBAs, support engineers, incident responders).
• Runs cloud control planes and identity systems that can grant access to PII stores.

Systems typically in scope:

• Cloud identity and access management (SSO, MFA, role assumption, API keys).
• Cloud control plane logs (admin console actions, policy changes).
• Workload logs at the app and database layers (read/export endpoints, direct DB queries).
• Data platform audit logs (object storage access, data warehouse query logs).
• Security tooling logs (EDR/SIEM alerts, DLP events) when they relate to PII access pathways.

What you actually need to do (step-by-step)

1) Define “PII access” in your environment (write it down)

Create a short logging scope statement that engineering can implement and audit can test. Include:

• PII data stores: databases, buckets, indexes, backups, data warehouse tables, support tooling mirrors.
• Access types: view/read, query, export/download, delete, modify, privilege grant, token issuance for access.
• Actors: end users, customer admins, internal staff, third parties, service accounts, automated jobs.
• Interfaces: application UI, API, direct DB access, cloud console, break-glass flows.

Deliverable: “PII Access Logging Standard” (1–2 pages) that maps stores → events → log source.

2) Inventory log sources and gaps (control plane + data plane)

Build a table that lists:

• System/component
• What events it emits today
• Whether events include identity, timestamp, action, object, result
• Where logs go (local disk, cloud-native logging, SIEM)
• Gaps (e.g., “DB reads not audited,” “service account identity missing”)

Practical note: most teams have strong control plane logs and weak data plane logging. ISO 27018 cares about PII access, which is usually data plane. ¹

3) Standardize the minimum fields for PII access events

Define a minimum schema so logs are usable:

• Who: user ID, role, service account, and identity provider subject
• When: timestamp with timezone and clock source
• Where: source IP, device/session ID, region, workload identifier
• What: action (read/query/export/delete), object (table/bucket/record set), sensitivity tag if available
• Outcome: success/failure, error code
• Why (where feasible): ticket ID, customer request ID, support case, change record

If your application cannot capture “why,” document the constraint and enforce a compensating workflow for privileged access (for example, a support tool that requires a case ID before granting time-bound access).

4) Centralize, protect, and retain logs so they are trustworthy

To satisfy “produced, kept,” you need central collection and retention that prevents quiet deletion or tampering. Focus on:

• Central aggregation: ship logs to a managed log platform/SIEM or centralized log store.
• Access control: least privilege for log viewing and export; separate duties for log administration.
• Integrity safeguards: immutable storage/WORM where available, or write-once patterns plus monitoring for deletion attempts.
• Time sync: consistent time sources across systems so correlation works.

Artifact to aim for: a “Logging Architecture Diagram” showing sources → collectors → storage → SIEM/alerting → review workflow.

5) Implement “regular review” as an operational process, not a meeting

Auditors will look for proof that review happens and drives remediation. Build a repeatable workflow:

• Define review triggers: alert rules for suspicious PII access (unusual volumes, new geography, privilege escalation followed by export, repeated denials).
• Assign ownership: Security Operations owns triage; Data/Platform owns fixes; Compliance/GRC samples evidence.
• Document outcomes: every alert leads to a ticket with disposition (benign/true positive/needs tuning), investigation notes, and corrective action.

If you do nothing else, implement a review cadence for:

• Privileged access to PII stores
• Bulk exports/downloads
• Access from break-glass accounts
• Access policy changes affecting PII stores

6) Test the control with “audit-ready” scenarios

Run tabletop-style tests that produce artifacts:

• Reconstruct a user’s PII access history for a defined period.
• Identify all internal staff who accessed a given PII dataset.
• Show evidence of review: alert → ticket → investigation → resolution.
• Prove logs are retained and searchable.

7) Operationalize through third parties (where they touch your PII)

If a third party has administrative access, remote support access, or data processing access, ensure:

• Their actions are captured in your logs or forwarded to you.
• Contracts/SOWs require audit logging and cooperation during investigations.
• Access paths use federated identity so “who” resolves to a human when needed.

Required evidence and artifacts to retain

Maintain an evidence pack that matches the clause language:

1. Event Logging Policy/Standard referencing PII access logging expectations.
2. System logging configuration baselines (screenshots/exports) for key platforms emitting PII access events.
3. Log source inventory and coverage map (systems, PII stores, log types, gaps and remediation status).
4. Sample log extracts showing PII access events with required fields (redacted as needed).
5. Retention configuration evidence (log store retention settings and access controls).
6. Review evidence: alert rules, review schedule, tickets, investigation notes, and sign-off records.
7. Exception register for systems that cannot log required events, with compensating controls and target remediation.

Common exam/audit questions and hangups

Expect these, and prepare answers with artifacts:

• “Show me logs of access to PII. Which system proves the access occurred?”
• “How do you know logs weren’t altered or deleted?”
• “Who reviews logs, and what do they do when they find something suspicious?”
• “Do service accounts and third parties show up as accountable identities?”
• “What is your process for logging failures and exceptions, not just successful actions?”
• “How do you handle support access to customer PII? Is it recorded and tied to a case?”

Hangup to avoid: providing massive raw logs without a narrative and proof of review. The requirement includes review; evidence must show follow-through. ¹

Frequent implementation mistakes and how to avoid them

• Mistake: Logging only the cloud admin console.
  Fix: add data plane auditing for databases, object storage, and application-level read/export actions.

• Mistake: Logs record “service-account-123” without a human chain of custody.
  Fix: require federated identity, short-lived credentials, and runbooks tying service-account actions to approved automation or a change record.

• Mistake: No consistent event schema, so searches are brittle.
  Fix: define minimum fields and validate with sample events in CI/CD for critical services.

• Mistake: “Regularly reviewed” is informal.
  Fix: route high-risk events into a ticketing system with documented disposition and management visibility.

• Mistake: Log access is too open.
  Fix: restrict log viewing/export, monitor for log deletion attempts, and separate admin duties.

Enforcement context and risk implications

No public enforcement cases were provided in the source materials for this requirement, so you should frame risk based on audit outcomes and incident response realities rather than case law. Practically, weak PII access logging increases:

• Breach impact (slower containment and unclear scope).
• Customer trust risk (you cannot answer who accessed what).
• Audit findings risk (inability to demonstrate review and accountability).

ISO 27018 positions logging as a baseline operational control for cloud PII processing. ¹

A practical 30/60/90-day execution plan

First 30 days (stabilize scope and accountability)

• Publish a “PII Access Logging Standard” and define minimum event fields.
• Inventory PII stores and current audit logging coverage; identify top gaps.
• Ensure centralized log collection exists for core systems (identity, cloud control plane, primary PII stores).
• Stand up an initial review workflow: alert routing to tickets, ownership, and documentation templates.

By 60 days (close high-risk gaps and prove review)

• Enable or improve auditing on primary PII data stores and key applications (read/export/admin actions).
• Add detection rules focused on privileged access, exports, and anomalous access patterns.
• Run an internal audit test: produce a “PII access report” for a sample dataset and show investigation records from the review workflow.
• Implement tighter controls on log access and exports.

By 90 days (make it durable and auditable)

• Expand coverage to secondary PII stores (backups, analytics copies, support tooling mirrors).
• Formalize exceptions with compensating controls and planned remediation.
• Add continuous validation: periodic checks that logging remains enabled after deployments and configuration changes.
• Package evidence for audit: diagrams, configs, sample logs, review tickets, and management sign-off.

If you need to coordinate this across many systems and third parties, Daydream can help you track log-source coverage, collect standardized evidence from system owners, and keep review records tied to the requirement so audits do not become a scramble.

Frequently Asked Questions

Do we need to log every single read of PII, or is logging admin access enough?

The clause calls out “particular attention to logging access to PII,” which generally means reads/queries/exports matter, not only admin actions. If you cannot log every read due to technical limits, document the gap and implement compensating controls that still establish accountability. ¹

What does “regularly reviewed” mean for auditors?

They look for a repeatable process with assigned ownership, evidence of review activity, and documented outcomes (tickets, investigations, tuning decisions). A calendar reminder without recorded results usually fails the intent of the requirement. ¹

How do we handle service accounts and automated jobs that access PII?

Ensure the event includes the service account identity and the workload context (job name, pipeline ID, environment). Then maintain a mapping from service accounts to approved automation owners so you can explain “who” is accountable during an investigation.

Are application logs enough, or do we need database audit logs too?

Application logs often miss direct queries, maintenance actions, or alternate access paths. For PII stores, database or platform-native audit logs are usually required to cover non-application access paths and to strengthen completeness of evidence.

How should we log “purpose” for PII access without building a huge new feature?

Start with privileged or support access flows: require a ticket/case ID before granting time-bound access, and record the ticket ID in the access event. For routine customer-user access, purpose may be implied by the authenticated session and business function, but document your approach.

What evidence should we show if an auditor asks for proof that logs are “kept”?

Provide retention configuration evidence, access controls to the log store, and sample historical events demonstrating logs remain searchable over time. Pair that with evidence that deletion or tampering is restricted and monitored.

Footnotes

1. ISO/IEC 27018:2019 Information technology — Security techniques — Code of practice for protection of personally identifiable information (PII) in public clouds acting as PII processors