What is ISO 27001 Annex A 8.16 – Monitoring Activities?
ISO 27001 Annex A 8.16 focuses on monitoring networks, systems, applications, and other information-processing environments for anomalous behaviour and potential information security events.
The purpose is to identify suspicious or unusual activity early enough for the organization to investigate and respond.
Monitoring may include:
- User activity
- Authentication activity
- Network traffic
- Endpoint activity
- Cloud activity
- Application activity
- Database activity
- Administrative actions
- Security alerts
- Resource usage
- System behaviour
- Access to sensitive information
- Unusual data transfers
Simple explanation:
Logging records what happened. Monitoring looks at what is happening and identifies activity that may require attention.
Why is Monitoring Important?
A security incident may begin with a completely legitimate-looking action.
For example:
Valid employee account
↓
Successful login
↓
Unusual location
↓
Access to production
↓
Large database query
↓
Bulk data download
Every individual event might be logged.
However, monitoring helps identify that the overall pattern may be suspicious.
Effective monitoring can help an organization:
- Detect attacks
- Identify compromised accounts
- Detect unauthorized activity
- Identify malware
- Detect abnormal network behaviour
- Identify suspicious administrative actions
- Detect unusual data access
- Support incident response
- Reduce the time required to identify security events
Simple principle:
Do not wait for someone to report that something is wrong. Monitor important systems for signs that something may be wrong.
A.8.15 Logging vs. A.8.16 Monitoring
These two controls are closely related but should not be treated as the same thing.
| A.8.15 Logging | A.8.16 Monitoring Activities |
|---|---|
| Records events | Observes and analyzes activity |
| Creates an evidence trail | Looks for unusual behaviour |
| Focuses on event collection | Focuses on detection and awareness |
| Example: login recorded | Example: unusual login generates alert |
| Example: admin change recorded | Example: unexpected admin change investigated |
| Provides historical information | Helps identify current or emerging issues |
Simple example
Logging:
User
admin@company.comlogged into production at 2:15 AM.
Monitoring:
The system detects that this privileged account normally operates during business hours and generates an alert for investigation.
Therefore:
Logging gives you the records. Monitoring helps you understand when those records indicate something unusual.
What Does ISO 27001 Annex A 8.16 Require?
The organization should determine appropriate monitoring activities based on its:
- Information security risks
- Critical systems
- Threat environment
- Business requirements
- Regulatory requirements
- Customer requirements
- Contractual obligations
- System architecture
- Sensitivity of information
- Incident response requirements
Monitoring should be proportionate to the organization’s risks.
A small startup does not necessarily need a large 24×7 Security Operations Center (SOC).
However, it should still have an appropriate method for identifying and responding to important security events.
What Should a Startup Monitor?
A startup should prioritize systems and events that could materially affect:
- Confidentiality
- Integrity
- Availability
- Customer data
- Production systems
- Privileged accounts
- Security controls
- Business operations
Typical monitoring areas include:
1. Identity and Authentication
Monitor:
- Failed login attempts
- Repeated authentication failures
- MFA changes
- New privileged accounts
- Privilege escalation
- Suspicious login locations
- Impossible-travel patterns where applicable
- Disabled security controls
- Password reset activity
2. Privileged Accounts
Privileged accounts deserve particular attention.
Monitor:
- Administrator logins
- Privilege changes
- Creation of new administrators
- Removal of administrators
- Changes to security configurations
- Access to critical infrastructure
For example:
Normal:
Developer → Development Environment
Potentially unusual:
Developer → Production Database → Bulk Export
This does not automatically mean an incident occurred.
It means the activity may deserve investigation based on the organization’s rules and context.
3. Cloud Infrastructure
For AWS, Azure, Google Cloud, or similar environments, monitoring may include:
- Administrative actions
- IAM changes
- Security-group changes
- Firewall changes
- Public exposure changes
- New resources
- Resource deletion
- Logging configuration changes
- Encryption configuration changes
- Network configuration changes
4. Endpoint Devices
Monitor:
- Malware detections
- Suspicious processes
- Unauthorized software
- Security-agent failures
- Endpoint compromise indicators
- Privilege escalation
- Unusual device activity
5. Network Activity
Depending on the environment, monitor:
- Suspicious connections
- Unusual traffic
- Blocked connections
- Unexpected external communication
- Scanning activity
- Network security alerts
6. Applications
Application monitoring may identify:
- Authentication attacks
- Authorization failures
- Abnormal API activity
- Excessive requests
- Suspicious transactions
- Unexpected administrative activity
- Application security exceptions
7. Data Access
For sensitive systems, monitor:
- Unusual data access
- Bulk downloads
- Large exports
- Access outside expected patterns
- Unusual administrative queries
- Attempts to access restricted information
Monitoring Should Be Risk-Based
One of the most important concepts for startups is:
You do not have to monitor everything equally.
For example:
| System | Risk | Monitoring Priority |
|---|---|---|
| Production database | High | High |
| Identity platform | High | High |
| Cloud infrastructure | High | High |
| Customer portal | High | High |
| Development laptop | Medium | Medium |
| Marketing website | Low | Lower |
| Public blog | Low | Lower |
The exact classification should come from the organization’s risk assessment.
Activities Required to Implement A.8.16
Step 1 – Identify Critical Systems
Start with the organization’s asset inventory.
Identify:
- Production systems
- Critical applications
- Databases
- Cloud environments
- Identity systems
- Security infrastructure
- Endpoints
- Network infrastructure
- Critical SaaS services
Step 2 – Identify What “Normal” Looks Like
Monitoring becomes more useful when the organization understands normal activity.
For example:
Normal:
Employee logs in from usual location
↓
Accesses normal business applications
↓
Works during normal hours
Potentially unusual:
Same account
↓
New country
↓
02:30 AM
↓
MFA settings changed
↓
Production access
↓
Large data download
Each individual event may require context, but the combination may justify investigation.
Step 3 – Identify Important Events
Determine which events require:
- Alerting
- Investigation
- Immediate response
- Periodic review
- Escalation
Examples:
- Multiple failed administrator logins
- New privileged account
- Security configuration disabled
- Public access enabled for sensitive storage
- Unexpected production access
- Large data export
- Malware detection
- Unusual API activity
Step 4 – Configure Monitoring
Use appropriate capabilities already available in the environment.
Examples include:
- Cloud security monitoring
- Endpoint Detection and Response (EDR)
- Identity security monitoring
- Firewall monitoring
- Application monitoring
- Database monitoring
- SIEM
- Security alerting
- Vulnerability monitoring
A startup should select technology based on its risk and environment rather than purchasing tools simply for certification.
Step 5 – Define Alerts
Not every event should generate an alert.
For example:
High-priority alert
New administrator created
+
Security logging disabled
Medium-priority alert
Repeated failed login attempts
Informational event
Normal employee login
This helps prevent alert fatigue.
Step 6 – Define Response
For important alerts, determine:
- Who receives the alert?
- Who investigates?
- How quickly should it be reviewed?
- When should it be escalated?
- When does it become an incident?
- Where is the investigation recorded?
Monitoring without a response process has limited value.
Step 7 – Review Monitoring Effectiveness
Periodically review:
- Alert volume
- False positives
- Missed events
- Critical incidents
- Detection gaps
- New threats
- New systems
- Configuration changes
Monitoring should evolve as the organization evolves.
Startup Example
Consider a SaaS startup with:
- AWS
- GitHub
- Google Workspace
- Production PostgreSQL
- Customer web application
- 50 employees
The company has enabled logging but does not monitor security events.
Current situation
Events occur
↓
Logs are stored
↓
Nobody actively reviews important events
↓
Suspicious activity may remain unnoticed
The startup implements basic monitoring:
Identity logs
Cloud logs
Application logs
Endpoint alerts
Database events
↓
Monitoring / Alerting
↓
Security Team
↓
Investigation
↓
Incident Response
Now important events can be identified and investigated more quickly.
Example Monitoring Rules for a SaaS Startup
| Monitoring Rule | Potential Reason |
|---|---|
| Multiple failed admin logins | Possible credential attack |
| New privileged account | Privilege escalation risk |
| MFA disabled | Security-control weakening |
| Unexpected production access | Possible unauthorized access |
| Large database export | Potential data leakage |
| Public cloud storage enabled | Potential data exposure |
| Security agent disabled | Endpoint protection risk |
| Logging disabled | Loss of security visibility |
| Firewall rule changed | Network exposure risk |
| Unusual API request volume | Potential abuse/attack |
These are examples, not universal requirements.
The startup should define monitoring rules according to its own risks and architecture.
Monitoring and SIEM
A Security Information and Event Management (SIEM) platform can collect and analyze security events from multiple sources.
For example:
AWS
+
Identity Provider
+
Firewall
+
EDR
+
Application
+
Database
↓
SIEM
↓
Correlation & Alerts
↓
Investigation
However:
ISO 27001 does not mean that every startup must purchase a SIEM.
A smaller organization may use a combination of:
- Cloud-native security alerts
- Identity-provider alerts
- EDR alerts
- Application monitoring
- Managed security services
- Centralized log management
- Email/Slack/Teams notifications
- Periodic security reviews
The appropriate solution depends on risk and business requirements.
24×7 Monitoring – Is It Mandatory?
Not necessarily.
A common misunderstanding is:
“If we implement A.8.16, we must have a 24×7 SOC.”
The actual approach should be based on the organization’s:
- Risk
- System criticality
- Customer requirements
- Business model
- Threat exposure
- Regulatory obligations
- Availability requirements
A high-risk financial service may have very different monitoring needs from a small low-risk SaaS startup.
The organization should be able to explain and justify its monitoring approach.
Monitoring During Remote Work
Remote working increases the importance of monitoring:
- Identity activity
- Endpoint security
- VPN activity where applicable
- Cloud access
- Administrative actions
- Suspicious authentication
- Data transfer
For example:
Remote Employee
↓
Identity Authentication
↓
Endpoint Security
↓
Cloud Application
↓
Security Monitoring
Monitoring Third-Party and Cloud Services
Organizations increasingly depend on external providers.
Monitoring responsibilities should therefore consider:
- Cloud providers
- SaaS providers
- Managed service providers
- Security service providers
- Critical technology suppliers
The organization should understand:
- What security events the supplier detects
- What alerts are available
- What information is provided to customers
- How incidents are communicated
- What logs the customer can access
Supplier monitoring should align with the organization’s supplier risk requirements.
Monitoring and Privacy
Monitoring can involve personal information.
Examples include:
- User IDs
- IP addresses
- Device identifiers
- Location information
- User activity
- Access history
Therefore, organizations should consider:
- Purpose limitation
- Data minimization
- Access restrictions
- Retention
- Applicable privacy requirements
- Employee transparency
- Appropriate safeguards
Security monitoring should provide useful security visibility without becoming unnecessary surveillance.
Audit Evidence
An ISO 27001 auditor may request evidence such as:
Governance
- Information security monitoring policy
- Monitoring standard
- Risk assessment
- Monitoring requirements matrix
- System inventory
Technical evidence
- SIEM configuration
- Cloud monitoring configuration
- EDR console
- Identity security alerts
- Firewall monitoring
- Application monitoring
- Database monitoring
- Alert rules
Operational evidence
- Security alerts
- Alert investigation records
- Incident tickets
- Monitoring review records
- Escalation records
- Evidence of corrective actions
Testing evidence
- Monitoring test results
- Alert simulation
- Detection testing
- Incident-response exercises
A.8.16 Audit Checklist
| Audit Question | Evidence |
|---|---|
| Have critical systems been identified? | Asset inventory |
| Has monitoring scope been defined? | Monitoring standard |
| Are critical systems monitored? | Monitoring configuration |
| Are privileged activities monitored? | IAM/cloud logs |
| Are authentication anomalies monitored? | Identity alerts |
| Are security events detected? | Alerts |
| Are important cloud changes monitored? | Cloud monitoring |
| Are endpoint security events monitored? | EDR |
| Are unusual data-access patterns monitored where appropriate? | Data monitoring |
| Are alert thresholds defined? | Alert rules |
| Is someone responsible for reviewing alerts? | Roles/responsibilities |
| Is there an escalation process? | Incident procedure |
| Are alerts investigated? | Tickets/cases |
| Is monitoring periodically reviewed? | Review records |
| Are monitoring gaps identified and addressed? | Risk/corrective-action records |
Common Mistakes
1. Collecting logs but not monitoring them
This is one of the most common weaknesses.
Logging ≠ Monitoring
A company may have millions of log records but still have poor detection capability.
2. Monitoring everything
Monitoring every event can generate excessive alerts.
The result can be:
- Alert fatigue
- High operational cost
- Missed important events
- Unnecessary investigation
Prioritize important events.
3. Buying a SIEM without defining requirements
A SIEM is a tool, not the control itself.
The organization should first understand:
- What needs monitoring
- Why it needs monitoring
- Who reviews alerts
- What happens after an alert
- What evidence is required
Then select appropriate technology.
4. No one owns alerts
If an alert is generated but nobody is responsible for investigating it, the monitoring control becomes ineffective.
Define:
Who receives → Who reviews → Who investigates → Who escalates.
5. Too many false positives
Poorly configured alerts can produce hundreds of unnecessary notifications.
Review and tune monitoring rules.
6. No incident integration
Monitoring should connect to incident management.
Alert
↓
Triage
↓
Investigation
↓
Security Event
↓
Incident?
↓
Response
Not every alert is necessarily an incident.
7. Monitoring stops after deployment
New applications, cloud services, employees, integrations, and infrastructure may introduce new monitoring requirements.
Monitoring should be reviewed when the environment changes.
Practical Startup Implementation Model
A startup can implement A.8.16 using this model:
1. Identify
Identify critical systems and security-sensitive activities.
2. Prioritize
Determine which activities require active monitoring.
3. Define
Define alert conditions and thresholds.
4. Configure
Enable appropriate monitoring capabilities.
5. Alert
Generate alerts for important anomalies.
6. Triage
Determine whether an alert requires investigation.
7. Investigate
Review relevant logs and other evidence.
8. Respond
Escalate security incidents through the incident-management process.
9. Review
Analyze false positives, missed events, and monitoring gaps.
10. Improve
Update monitoring as the business and threat environment changes.
Identify → Prioritize → Define → Configure → Alert → Triage → Investigate → Respond → Review → Improve
Minimum Viable Monitoring for a Startup
A startup does not have to build an enterprise SOC on day one.
A practical baseline could include:
Identity
- Login alerts
- Failed authentication
- Privilege changes
- MFA changes
- New administrator accounts
Cloud
- Administrative actions
- IAM changes
- Public exposure changes
- Security configuration changes
- Critical resource deletion
Endpoint
- Malware
- Suspicious activity
- Security-agent failure
Application
- Authentication attacks
- Authorization failures
- Suspicious API behaviour
- Critical security events
Data
- Unusual access
- Large exports
- Sensitive-data access where appropriate
Incident Response
- Alert ownership
- Investigation procedure
- Escalation criteria
- Incident ticketing
This provides a practical foundation without requiring excessive technology.
Example Monitoring Responsibility Matrix
| Monitoring Area | Owner | Alert | Response |
|---|---|---|---|
| Identity | IT/Security | Suspicious login | Investigate |
| Cloud | Cloud/Security | Privilege change | Review |
| Endpoint | IT/Security | Malware | Contain |
| Application | Engineering/Security | Security anomaly | Investigate |
| Database | Engineering/Security | High-risk activity | Review |
| Network | Security/IT | Suspicious traffic | Investigate |
The actual ownership model should reflect the organization’s structure.
Policy vs. Process vs. Evidence
| Layer | Example |
|---|---|
| Policy | Critical systems shall be monitored for security-relevant activity |
| Standard | Defined events and anomalies shall generate alerts where appropriate |
| Process | Security team reviews, investigates and escalates alerts |
| Technical Control | Cloud monitoring, EDR, IAM alerts, SIEM |
| Evidence | Alerts, investigations, tickets and review records |
This is important for audit readiness.
A monitoring policy alone does not demonstrate that monitoring is operating.
The organization should demonstrate:
Requirement → Configuration → Alert → Investigation → Response → Evidence
Relationship With Other ISO 27001 Controls
A.5.24 – Information Security Incident Management Planning and Preparation
Monitoring provides information needed for incident response.
A.5.25 – Assessment and Decision on Information Security Events
Monitoring generates events that may need assessment.
A.5.26 – Response to Information Security Incidents
Confirmed incidents can be escalated into the incident response process.
A.5.27 – Learning From Information Security Incidents
Incident lessons can identify monitoring gaps.
A.5.28 – Collection of Evidence
Monitoring records may support investigations.
A.8.8 – Management of Technical Vulnerabilities
Monitoring may help identify exploitation or suspicious activity associated with vulnerabilities.
A.8.9 – Configuration Management
Monitoring can detect unauthorized or unexpected configuration changes.
A.8.12 – Data Leakage Prevention
Monitoring can help identify suspicious data transfers or access patterns.
A.8.13 – Information Backup
Monitoring can identify backup failures or unusual backup activity.
A.8.15 – Logging
Logging provides the underlying event records used by monitoring.
A.8.17 – Clock Synchronization
Consistent timestamps are important when correlating events across systems.
A.8.20 – Networks Security
Network monitoring can help identify suspicious network activity.
Useful Resources
MAE can provide supporting templates and practical implementation documents for this control.
Recommended documents
- [Insert Draft Document Link] – Security Monitoring Policy
- [Insert Draft Document Link] – Monitoring Requirements Matrix
- [Insert Draft Document Link] – Security Alert Classification Matrix
- [Insert Draft Document Link] – Security Alert Review Procedure
- [Insert Draft Document Link] – Monitoring Review Checklist
- [Insert Draft Document Link] – ISO 27001 A.8.16 Audit Checklist
Questions an Auditor May Ask
- Which systems are monitored?
- How did you determine the monitoring scope?
- What security events generate alerts?
- Show me a recent security alert.
- Who reviews alerts?
- How quickly are critical alerts investigated?
- What happens when an alert indicates a possible incident?
- How are false positives handled?
- How do you monitor privileged accounts?
- How do you monitor cloud administrative activity?
- How do you detect unusual authentication activity?
- How do you monitor critical applications?
- How do you know that monitoring is working?
- When did you last test an alert?
- How are monitoring requirements updated when systems change?
Startup-Focused Final Takeaway
ISO 27001 Annex A 8.16 is about actively watching for unusual or potentially harmful activity, rather than simply storing technical records.
For a startup, the key questions are:
What systems are most important to our business?
What behaviour would indicate that something may be wrong?
Are we monitoring those events?
Who receives the alerts?
Who investigates them?
When does an alert become a security incident?
Can we demonstrate that we responded appropriately?
A practical implementation can be summarized as:
Identify critical systems → Define normal and abnormal activity → Prioritize important events → Configure monitoring → Generate alerts → Triage → Investigate → Respond → Review → Improve.
The key lesson for startups
You do not need to monitor everything.
You need to monitor the right things.
Effective monitoring means that important security events do not simply disappear into millions of technical logs. They are identified, assessed, investigated, and escalated when necessary.
That is the practical objective behind ISO 27001 Annex A 8.16 – Monitoring Activities.