What does control A.3.25 require?
Logs that record activities, exceptions, faults and other relevant events related to PII processing shall be produced, stored, protected and analysed.
This control sits within the Shared security controls annex (A.3) and establishes comprehensive logging requirements for PII processing activities. Logging serves multiple purposes: detecting unauthorised access to PII, supporting incident investigation, demonstrating compliance to auditors and providing evidence in the event of a data breach. Without adequate logging, an organisation may not know that a breach has occurred, who accessed PII or when.
What does the Annex B implementation guidance say?
Annex B (section B.3.25) provides extensive guidance covering several areas:
- Review and monitoring — Event logs should be reviewed using continuous automated monitoring and alerting, or manually at a specified documented periodicity, to identify irregularities and propose remediation
- PII access logging — Where possible, event logs should record access to PII including by whom, when, which PII principal’s data was accessed and what changes were made (additions, modifications or deletions)
- Multi-provider environments — Where multiple service providers are involved, roles in implementing logging should be clearly defined and documented, and agreement on log access between providers should be addressed
- Logs as PII — Log information recorded for security monitoring and operational diagnostics can itself contain PII. Access controls must ensure logged information is only used as intended
- Log retention and deletion — A procedure, preferably automatic, should ensure logged information is either deleted or de-identified as specified in the retention schedule
- See also A.3.22: User Endpoint Devices for related requirements
- See also A.3.24: Information Backup for related requirements
Implementation guidance for PII processors
- Customer log access criteria — The organisation should define criteria for if, when and how log information can be made available to or usable by the customer
- Customer isolation — Where customers are permitted access to logs, they must only access records relating to their own activities, cannot access other customers’ logs and cannot amend the logs
A key tension in the guidance is that logs themselves can contain PII (e.g. usernames, IP addresses, data subject identifiers), meaning the logs are simultaneously a privacy control and a privacy risk that must be managed.
How does this map to GDPR?
Control A.3.25 maps to the following GDPR article:
- Article 5(1)(f) — The integrity and confidentiality principle, requiring appropriate security measures. Logging is a key detective control that supports the ability to identify and respond to security incidents affecting personal data
Logging also supports GDPR Article 33 breach notification obligations by providing the evidence needed to detect breaches and determine their scope and impact.
What changed from ISO 27701:2019?
For a step-by-step approach, see the Transition from 2019 to 2025.
In the 2019 edition, this requirement was covered by Clauses 6.9.4.1 (event logging), 6.9.4.2 (protection of log information) and 6.9.4.3 (administrator and operator logs). The 2025 edition consolidates all three into a single control A.3.25, with unified implementation guidance in B.3.25 that includes new processor-specific guidance on customer log access. See the Annex F correspondence table for the full mapping.
Manage all your compliance, all in one place
ISMS.online supports over 100 standards and regulations, giving you a single platform for all your compliance needs.
What evidence do auditors expect?
When assessing compliance with A.3.25, auditors will typically look for:
- Logging policy — A documented policy specifying what events must be logged, log retention periods, who has access to logs and how logs are protected from tampering
- Log coverage — Evidence that all systems processing PII generate event logs covering at minimum authentication events, PII access, data modifications and administrative actions
- Log monitoring — Evidence of active log monitoring, whether through a SIEM platform, automated alerting or documented manual review schedules
- Log protection — Technical controls preventing log tampering, including write-once storage, integrity checksums or centralised log collection to a separate system
- Log retention management — Automated or procedural controls ensuring logs are retained for the specified period and then deleted or de-identified
What are the related controls?
| Control | Relationship |
|---|---|
| A.3.11 Incident management planning | Logs provide the evidence base for detecting and investigating incidents |
| A.3.12 Response to security incidents | Incident response relies on log analysis to determine scope and impact |
| A.3.23 Secure authentication | Authentication events are a critical category of logged events |
| A.3.9 Access rights | Access to logs must be restricted to authorised personnel |
| A.1.4.8 Retention | Log retention must comply with the PII retention schedule |
Who does this control apply to?
A.3.25 is a shared control that applies to both PII controllers and PII processors. Controllers must log PII processing activities across their own systems. Processors have additional obligations around customer log access: they must define when and how customers can access logs, ensure customer isolation (each customer can only see their own logs) and prevent customers from amending log records.
Get started easily with a personal product demo
One of our onboarding specialists will walk you through our platform to help you get started with confidence.
Why choose ISMS.online for PII logging compliance?
ISMS.online provides practical tools for managing logging compliance:
- Audit log management — Built-in audit trails that record all actions within the platform, demonstrating compliance with logging requirements for your PIMS itself
- Policy management — Publish logging policies with version control and staff acknowledgement tracking
- Log review scheduling — Schedule and track regular log review activities, with task assignments and completion records for audit evidence
- Incident integration — Link log analysis findings directly to incident records, creating a documented chain from detection through to resolution
- Retention tracking — Manage log retention requirements alongside your broader data retention schedule, highlighting conflicts and expiries
FAQs
What events should be logged for PII processing?
At minimum, logs should capture who accessed PII, when, which PII principal’s data was accessed and what changes were made. This includes successful and failed authentication attempts, data reads and writes, administrative actions (such as creating or modifying user accounts), data exports, consent changes and any automated processing decisions. The level of detail should be proportionate to the sensitivity of the PII and the risk profile of the system.
How should organisations handle PII within logs?
Logs often contain PII such as usernames, email addresses, IP addresses and data subject identifiers. Organisations should minimise PII in logs to what is necessary for their intended purpose, apply access controls to restrict who can view logs, include log data in data retention schedules and apply de-identification or deletion when the retention period expires. Logs should not be used for purposes beyond their intended scope (e.g. security monitoring, operational diagnostics).
What are the processor-specific logging obligations?
Processors must define and communicate criteria for when and how log information can be made available to customers. If customers are permitted access, the processor must implement controls ensuring each customer can only access logs relating to their own activities, cannot see other customers’ logs and cannot modify any log records. These arrangements should be documented in the data processing agreement and the criteria made available to the customer.
