What is ISO 27001 Annex A 8.15 – Logging?
ISO 27001 Annex A 8.15 requires organizations to produce, store, protect, and review logs of relevant activities, exceptions, faults, and security events.
Logging helps an organization understand what happened, when it happened, where it happened, and who or what was involved.
Logs can be generated by:
- Servers
- Applications
- Databases
- Firewalls
- Network devices
- Cloud platforms
- Identity and access management systems
- Endpoint devices
- Security tools
- SaaS applications
- APIs
- Administrative consoles
- Backup systems
- Critical business applications
Simple explanation: If something important happens in your IT environment, logging should create a reliable record that helps you investigate and prove what happened.
Why is Logging Important?
Without appropriate logging, an organization may know that something went wrong but not know what actually happened.
For example:
A developer account is compromised and someone accesses a production database.
Without useful logs, the organization may struggle to determine:
- When the account was accessed
- Where the access originated
- Which systems were accessed
- What actions were performed
- Which records were viewed or changed
- Whether data was exported
- Whether additional accounts were created
- How long the attacker remained in the environment
With appropriate logging, these questions can often be investigated much more effectively.
Logging helps organizations with:
- Security incident investigation
- Unauthorized access detection
- Troubleshooting
- Fraud investigation
- Change tracking
- Accountability
- Compliance requirements
- Customer security investigations
- Forensic analysis
- Operational monitoring
Simple principle:
If you cannot reconstruct important events, you may not be able to investigate or prove what happened.
What Does ISO 27001 Annex A 8.15 Require?
The organization should determine which activities need to be logged based on its:
- Information security risks
- Business requirements
- System criticality
- Legal and regulatory requirements
- Contractual requirements
- Customer requirements
- Incident response needs
- Privacy considerations
The objective is not to log everything blindly.
Instead, the organization should identify the events that are important for security, operations, investigation, and accountability.
What Should Be Logged?
The exact logging requirements will depend on the organization’s environment.
Typical security-relevant events include:
| Event | Example |
|---|---|
| User authentication | Successful login |
| Failed authentication | Multiple failed login attempts |
| Privileged activity | Administrator changes configuration |
| Account changes | User created or deleted |
| Access changes | User granted admin privileges |
| Configuration changes | Firewall rule changed |
| Security events | Malware detected |
| Data access | Sensitive database accessed |
| Data modification | Important records changed |
| Data deletion | Production records deleted |
| Application events | Critical application error |
| Network events | Suspicious connection |
| Cloud activity | Cloud administrator changes resource |
| API activity | Sensitive API endpoint accessed |
| Backup events | Backup failed |
| System events | Server shutdown or restart |
The organization should determine which events are relevant to its risk profile.
Important Logging Sources
A startup may have dozens or hundreds of possible logging sources.
The key is to prioritize the systems that matter most.
1. Identity and Access Management
Examples:
- Microsoft Entra ID
- Google Workspace
- Okta
- Auth0
- AWS IAM
- Privileged access management systems
Useful logs include:
- Login
- Failed login
- MFA activity
- Password changes
- Account creation
- Account deletion
- Privilege changes
2. Cloud Infrastructure
Examples:
- AWS
- Microsoft Azure
- Google Cloud
Logs may include:
- Administrative actions
- Resource creation
- Resource deletion
- Configuration changes
- IAM changes
- Network changes
- API calls
3. Firewalls and Network Devices
Logs can help identify:
- Connection attempts
- Blocked traffic
- Suspicious traffic
- Configuration changes
- Network anomalies
4. Servers
Depending on the operating system, logs may include:
- Login attempts
- Privilege escalation
- Service activity
- System errors
- Configuration changes
- Process activity
5. Applications
Application logging may capture:
- User activity
- Administrative actions
- Authentication
- Authorization failures
- Important transactions
- Security exceptions
- Application errors
6. Databases
Depending on the risk and technical environment, database logging may include:
- Authentication
- Administrative access
- Schema changes
- Sensitive queries
- Data modification
- Data deletion
7. Endpoints
Relevant endpoint logs may include:
- Login activity
- Malware detection
- Security alerts
- Device changes
- Administrative activity
Logging vs. Monitoring
Logging and monitoring are related but different.
Logging
Creates and retains records of events.
Monitoring
Reviews events or data to identify conditions requiring attention.
For example:
Logging:
Administrator account logged into production at 02:13 AM.
Monitoring:
System detects an unusual administrator login at 02:13 AM and generates an alert.
Therefore:
Logging creates the evidence. Monitoring helps identify what requires attention.
ISO 27001 Annex A 8.15 focuses on Logging, while Annex A 8.16 focuses specifically on Monitoring Activities.
Activities Required to Implement A.8.15
Step 1 – Identify Critical Systems
Create a list of systems where security logging is important.
For example:
- Production application
- Production database
- Cloud infrastructure
- Identity provider
- VPN
- Firewall
- Source-code repository
- Endpoint security platform
- Customer portal
- Administrative systems
Step 2 – Identify Important Events
Determine what should be logged for each system.
For example:
Production database
Log:
- Administrative access
- Authentication failures
- Configuration changes
- Privileged activity
- Important data modifications
Identity platform
Log:
- Successful login
- Failed login
- MFA changes
- New user
- User disabled
- Privilege changes
Step 3 – Configure Logging
Enable appropriate logging within each technology.
For example:
AWS
↓
CloudTrail / relevant service logs
↓
Central log storage
↓
Retention
↓
Review / monitoring
Step 4 – Protect Logs
Logs can contain sensitive information and therefore should themselves be protected.
Controls may include:
- Access restrictions
- Encryption
- Integrity protection
- Restricted administrator access
- Separation from normal users
- Retention controls
- Backup where appropriate
Step 5 – Define Retention
Determine how long logs should be retained.
The retention period may depend on:
- Security requirements
- Incident investigation requirements
- Customer contracts
- Legal requirements
- Regulatory requirements
- Business needs
- Storage costs
Avoid choosing an arbitrary period simply because another company uses it.
Step 6 – Protect Against Unauthorized Modification
Logs should be protected from unauthorized:
- Modification
- Deletion
- Manipulation
- Access
This is particularly important because an attacker with administrative privileges may attempt to remove evidence of their activities.
Step 7 – Centralize Important Logs
Where practical, important logs should be collected into a controlled central location.
For example:
Cloud
├── Application logs
├── Database logs
├── IAM logs
└── Infrastructure logs
↓
Central Log Platform
↓
Security Monitoring
Centralization can make investigation significantly easier.
Step 8 – Test Logging
Do not assume that logging is working simply because it has been enabled.
Periodically verify:
- Logs are being generated
- Logs are reaching the intended destination
- Timestamps are correct
- Logs are retained
- Logs cannot be casually modified
- Important events are captured
- Access to logs is restricted
Startup Example
Consider a SaaS startup with:
- 45 employees
- AWS infrastructure
- PostgreSQL database
- GitHub
- Google Workspace
- Customer web application
- Production API
- Admin portal
The company initially has only basic application logs.
One day, a privileged employee account is compromised.
The startup knows that suspicious activity occurred but cannot determine exactly what happened.
Weak approach
Application logs only
↓
Limited visibility
↓
Difficult investigation
Better approach
Identity logs
+
Cloud administrative logs
+
Application logs
+
Database/security logs
+
Endpoint/security logs
↓
Centralized logging
↓
Retention + access protection
↓
Investigation / monitoring
Now the organization has significantly better visibility into important activities.
Startup-Focused Quick Summary
A startup does not necessarily need a huge SIEM implementation to begin addressing A.8.15.
Start with the systems that create the greatest security risk.
Minimum practical approach:
- Identify critical systems
- Identify important security events
- Enable appropriate logging
- Centralize critical logs where practical
- Restrict access to logs
- Protect logs from unauthorized modification
- Define retention
- Regularly verify that logging works
- Integrate important logs with monitoring where appropriate
- Maintain evidence of the process
Example Logging Register
| System | Important Events | Log Location | Retention | Owner | Review |
|---|---|---|---|---|---|
| Identity Platform | Login, MFA, privilege changes | Central platform | Defined by policy | IT/Security | Regular |
| AWS | Administrative activity | Cloud log storage | Defined by policy | Cloud Team | Regular |
| Production DB | Admin access, changes | Central log platform | Defined by policy | Engineering | As required |
| Application | Authentication, security events | Log platform | Defined by policy | Engineering | Monitoring |
| Endpoint | Security events | EDR platform | Defined by policy | IT/Security | Monitoring |
Example Logging Requirements Matrix
| System | Event | Required? | Reason |
|---|---|---|---|
| Production application | Authentication | Yes | Security investigation |
| Production database | Privileged activity | Yes | High-risk access |
| Cloud platform | Administrative actions | Yes | Change accountability |
| Identity platform | Failed authentication | Yes | Attack detection |
| Endpoint | Malware events | Yes | Security monitoring |
| Marketing website | Every page view | Risk-dependent | Usually low security value |
This demonstrates an important ISO 27001 principle:
Logging should be risk-based, not simply volume-based.
Protecting Logs
Logs can contain sensitive information.
For example:
- Usernames
- Email addresses
- IP addresses
- Internal hostnames
- API information
- Customer identifiers
- Error messages
- Security details
- Potentially personal information
Therefore, organizations should consider:
Confidentiality
Who can access the logs?
Integrity
Can someone modify or delete them?
Availability
Can investigators access them when needed?
Privacy
Does logging unnecessarily capture personal or sensitive information?
Avoid Logging Sensitive Information Unnecessarily
One common mistake is logging too much information.
For example, an application should generally avoid placing sensitive secrets into logs.
Examples of information that should not normally be logged unnecessarily include:
- Passwords
- Authentication secrets
- API keys
- Access tokens
- Private encryption keys
- Full payment-card information
- Sensitive personal information
Instead of:
User password: ********
the application should be designed so that the password is not logged at all.
Similarly, tokens and secrets should not appear in application logs.
Good logging means capturing useful security information without creating a new data-exposure risk.
Logging and Cloud Services
For startups using cloud services, logging responsibilities should be clearly understood.
Do not assume:
“AWS/Azure/GCP automatically handles everything.”
Instead, determine:
- Which logs are available
- Which logs are enabled
- Which logs are retained
- Who can access them
- How logs are protected
- Whether logs can be exported
- How long they are retained
- What happens if logging stops
The organization should understand the division of responsibility between itself and its cloud provider.
Logging in Development and Production
Logging requirements may differ between environments.
Production
Usually requires stronger security logging because production systems contain real business or customer information.
Development
May require less extensive logging but should still capture relevant security events.
Developers should also ensure that debugging does not accidentally expose sensitive production information.
Logging and Incident Response
Logging is closely connected to incident management.
During a security incident, investigators may need to answer:
- What happened?
- When did it happen?
- Which account was involved?
- Which system was accessed?
- What actions were performed?
- Was data accessed?
- Was data changed?
- Did the attacker move to another system?
Good logging provides the underlying evidence needed to answer these questions.
Audit Evidence
An ISO 27001 auditor may ask for evidence such as:
Policies and procedures
- Logging policy
- Logging standards
- Log retention requirements
- Security monitoring procedure
- Incident response procedure
Technical evidence
- Screenshots of logging configuration
- Cloud logging configuration
- IAM audit logs
- Firewall logs
- Application logs
- Database audit logs
- EDR logs
- SIEM/log-management configuration
Operational evidence
- Log review records
- Security alerts
- Incident investigations
- Evidence of retention
- Log integrity controls
- Periodic verification of logging
Governance evidence
- Risk assessment
- System inventory
- Logging requirements matrix
- Data classification
- Applicable contractual/regulatory requirements
ISO 27001 A.8.15 Audit Checklist
| Audit Question | Evidence |
|---|---|
| Have important systems been identified? | System inventory |
| Have important events been identified? | Logging matrix |
| Is logging enabled for critical systems? | Configuration evidence |
| Are authentication events logged? | IAM logs |
| Are privileged activities logged? | Admin/audit logs |
| Are important configuration changes logged? | Cloud/system logs |
| Are logs protected from unauthorized access? | Access controls |
| Are logs protected from unauthorized modification? | Technical controls |
| Is log retention defined? | Policy/configuration |
| Are logs available when needed for investigation? | Retrieval test |
| Are timestamps reliable? | Time configuration |
| Are sensitive secrets excluded from logs? | Application/config review |
| Are important logs centrally collected where appropriate? | Log platform |
| Are logging failures detected? | Monitoring/alerts |
| Is logging periodically reviewed or tested? | Review/test records |
Common Mistakes
1. “We have application logs, so we are compliant.”
Application logs alone may not provide sufficient visibility.
Important systems such as identity, cloud infrastructure, endpoints, databases, and administrative platforms may also require logging.
2. Logging everything
More logs do not automatically mean better security.
Excessive logging can create:
- Higher storage costs
- More noise
- Privacy concerns
- Difficult investigations
- Operational complexity
3. Logs are stored only on the same server
If the server is compromised, the attacker may be able to modify or delete the logs.
Critical logs should be protected appropriately and, where practical, stored separately from the system generating them.
4. No retention requirements
The organization may have useful logs today but discover that historical logs have already been deleted.
Define retention based on risk and requirements.
5. Logging passwords or secrets
This creates a serious secondary security risk.
Applications should be designed to prevent secrets from appearing in logs.
6. No verification that logging works
A logging configuration can fail because of:
- Configuration changes
- Storage problems
- Agent failures
- Network issues
- Permission changes
- Service outages
Logging should therefore be periodically verified.
7. Treating logging as monitoring
Collecting logs does not necessarily mean that anyone is reviewing or analyzing them.
Logging and monitoring should be considered together, but they serve different purposes.
Practical Startup Implementation Model
A startup can implement A.8.15 using the following model:
Step 1 – Identify
Identify critical applications, systems, users, and infrastructure.
Step 2 – Prioritize
Determine which systems require the strongest logging.
Step 3 – Define
Define important events and retention requirements.
Step 4 – Configure
Enable appropriate logging.
Step 5 – Centralize
Collect important logs into a controlled location where practical.
Step 6 – Protect
Restrict access and protect log integrity.
Step 7 – Verify
Periodically test that logging is operating correctly.
Step 8 – Monitor
Use monitoring and alerting for important security events.
Step 9 – Investigate
Use logs during incidents and investigations.
Step 10 – Improve
Review incidents, risks, and operational experience and improve logging requirements.
Identify → Prioritize → Define → Configure → Centralize → Protect → Verify → Monitor → Investigate → Improve
Minimum Viable Logging for a Startup
For a typical SaaS startup, a practical starting point may include:
Identity
- Login events
- Failed authentication
- MFA changes
- Privilege changes
- User lifecycle events
Cloud
- Administrative actions
- IAM changes
- Network/security changes
- Critical resource changes
Application
- Authentication
- Authorization failures
- Administrative actions
- Critical transactions
- Security events
Database
- Administrative access
- Privileged actions
- Important configuration changes
- High-risk data activities where justified
Endpoints
- Security events
- Malware detection
- Important administrative events
Security Infrastructure
- Firewall events
- VPN events
- EDR alerts
- Security-system configuration changes
The exact scope should be determined through risk assessment rather than copying another company’s architecture.
Policy vs. Process vs. Evidence
| Layer | Example |
|---|---|
| Policy | Security logging must be implemented for critical systems |
| Standard | Authentication, privileged activity and security events must be logged |
| Process | IT identifies systems, configures logging and periodically verifies it |
| Technical Control | CloudTrail, application logs, database audit logs, EDR |
| Evidence | Configuration screenshots, exported logs, review records |
This distinction is important during an ISO 27001 audit.
Having a Logging Policy does not prove that logging has actually been implemented.
The auditor normally wants to see:
Requirement → Implementation → Operation → Evidence
Relationship With Other ISO 27001 Controls
A.5.9 – Inventory of Information and Other Associated Assets
You need to know which systems exist before determining where logging is required.
A.5.12 – Classification of Information
Information classification helps determine the importance of logging and protection requirements.
A.5.15 – Access Control
Logs help demonstrate and investigate access to systems.
A.5.16 – Identity Management
Identity events are important sources of security logs.
A.5.18 – Access Rights
Changes to access rights should often be logged.
A.5.24 – Incident Management Planning
Logging supports incident response preparedness.
A.5.25 – Assessment of Information Security Events
Logs provide information for assessing suspicious events.
A.5.26 – Response to Information Security Incidents
Logs support investigation and response.
A.5.28 – Collection of Evidence
Logs may become important evidence during an investigation.
A.8.8 – Management of Technical Vulnerabilities
Logs can help identify exploitation attempts and suspicious behavior.
A.8.9 – Configuration Management
Configuration changes should often be recorded.
A.8.16 – Monitoring Activities
Monitoring uses logs and other signals to identify security events.
A.8.17 – Clock Synchronization
Reliable timestamps are important for correlating events across systems.
Useful Resources
MAE can provide supporting templates and practical implementation documents for this control.
Recommended documents
- [Insert Draft Document Link] – Information Security Logging Policy
- [Insert Draft Document Link] – Logging Requirements Matrix
- [Insert Draft Document Link] – Log Retention Standard
- [Insert Draft Document Link] – Security Monitoring Procedure
- [Insert Draft Document Link] – Log Review Checklist
- [Insert Draft Document Link] – ISO 27001 A.8.15 Audit Checklist
Questions an Auditor May Ask
An auditor may ask:
- Which systems are required to generate security logs?
- How did you determine which events need to be logged?
- Show me the logs for a privileged user.
- Can you demonstrate a recent authentication event?
- How long are logs retained?
- Who has access to the logs?
- Can administrators delete or modify logs?
- How are logs protected?
- How do you know logging is still working?
- How are logs used during security incidents?
- Are cloud administrative activities logged?
- Are database activities logged where required?
- Are application logs protected against sensitive-data exposure?
- How do you ensure timestamps are reliable?
- Can you demonstrate how you investigated a previous security event?
A strong answer should be supported by actual evidence, not just a written policy.
Startup-Focused Final Takeaway
ISO 27001 Annex A 8.15 is not about collecting the maximum possible number of logs.
It is about ensuring that important activities are recorded in a reliable, protected, and usable way.
For a startup, the practical questions are:
What systems are critical?
What events would we need to investigate after a security incident?
Are those events being logged?
Are the logs protected?
Can we retrieve them when needed?
Do we know how long we need to keep them?
Have we verified that logging actually works?
A practical implementation can be summarized as:
Identify critical systems → Define important events → Enable logging → Protect logs → Define retention → Verify logging → Monitor important events → Use logs for investigation → Improve.
The key lesson for startups
You do not need to collect every possible event from every system.
You need to make sure that the right security-relevant events are recorded, protected, retained, and available when the business needs them.
That is the practical objective behind ISO 27001 Annex A 8.15 – Logging.