Control Definition
Organizations must watch their networks, systems, and applications for behavior that deviates from the norm, and follow up on what monitoring surfaces so that potential information security incidents are evaluated and acted upon.
Control Objective
To catch unusual activity and potential security incidents early by continuously monitoring networks, systems, and applications, analyzing logs and alerts, and responding appropriately to suspicious events before they cause significant damage.
What This Really Means
Monitoring activities means deploying technical tools that continuously watch your IT infrastructure for suspicious or unusual behavior—failed login attempts suggesting password attacks, unusual data transfers indicating data theft, malware command-and-control traffic, privilege escalation attempts, or unauthorized system changes. When something anomalous happens, security teams are alerted to investigate and respond.
Think of monitoring like CCTV cameras in a building: cameras record activity continuously, security staff watch for unusual behavior (someone trying doors after hours, unknown person in restricted area), and guards respond to incidents. Similarly, security monitoring tools (SIEM, IDS/IPS, EDR, log analysis) watch network traffic, system logs, and application behavior, detect threats, and alert security teams.
This control requires you to define what to monitor (network traffic, system logs, application logs, user activity, file integrity), deploy monitoring technology (SIEM, intrusion detection, endpoint detection and response, log aggregation), establish baselines for normal behavior, configure alerts for anomalies, assign teams to review alerts and investigate incidents, and continuously tune monitoring rules to reduce false positives. The goal is early detection and response to security threats before they cause significant harm.
Why It Matters
Most data breaches are not discovered immediately—average dwell time (time between initial compromise and detection) is weeks or months. Effective monitoring drastically reduces this window, limiting damage and meeting regulatory requirements.
Without security monitoring, organizations face:
- •Undetected Breaches and Prolonged Compromise – Attackers can operate inside networks for months undetected, exfiltrating data, escalating privileges, and establishing persistence before discovery
- •Regulatory and Legal Violations – CERT-In mandates reporting covered incidents within 6 hours; the DPDP regime requires notifying the Data Protection Board and affected individuals without delay; both are impossible without monitoring that detects incidents quickly
- •Failed Incident Response – Without monitoring logs and forensic data, investigating breaches becomes guesswork; you cannot determine what was accessed, by whom, when, or how to remediate
- •Insider Threat Invisibility – Malicious insiders with legitimate access credentials avoid detection without user behavior analytics and privilege monitoring
- •Compliance Audit Failures – ISO 27001, SOC 2, PCI DSS all require demonstrable security monitoring with evidence of log retention, alert investigation, and incident handling
Indian organizations face specific requirements: CERT-In directions mandate retaining ICT system logs for 180 days and reporting covered incidents within 6 hours of noticing them. Lack of monitoring makes compliance impossible and leaves organizations legally vulnerable.
Implementation Guidance
Define Monitoring Scope and Objectives
Identify critical assets requiring monitoring: network perimeter (firewalls, internet gateways), servers (production databases, application servers, domain controllers), endpoints (laptops, workstations), cloud infrastructure (AWS, Azure, Google Cloud), SaaS applications (Office 365, Salesforce, GitHub), and critical data repositories. Define monitoring goals: detect unauthorized access, identify malware infections, spot data exfiltration, track privilege escalation, alert on policy violations, and meet compliance log retention (CERT-In 180 days minimum). Start with highest-value and highest-risk systems.
Deploy Monitoring Tools and Log Aggregation
Implement security monitoring technology stack: (1) SIEM (Security Information and Event Management) - Splunk, IBM QRadar, Elastic Security, Microsoft Sentinel for centralized log aggregation and correlation, (2) IDS/IPS (Intrusion Detection/Prevention) - Snort, Suricata, Palo Alto for network threat detection, (3) EDR (Endpoint Detection and Response) - CrowdStrike, SentinelOne, Microsoft Defender for endpoint threat monitoring, (4) Cloud-native monitoring - AWS CloudWatch + GuardDuty, Azure Monitor + Sentinel, Google Cloud Operations, (5) Application logging - ensure applications generate security-relevant logs (auth events, access violations, errors).
Configure Log Sources and Ensure Comprehensive Coverage
Enable logging and forward logs to SIEM from all critical systems: network devices (firewall logs, VPN connections, proxy logs), servers (Windows Event Logs, Linux syslog, authentication attempts), applications (web server access logs, database audit logs, API gateway logs), cloud platforms (CloudTrail for AWS, Activity Log for Azure, Audit Logs for GCP), SaaS apps (Office 365 audit logs, GitHub audit log, Salesforce Event Monitoring), and endpoint security tools. Verify log completeness—missing logs create blind spots attackers exploit.
Establish Baseline Behavior and Anomaly Detection Rules
Define what constitutes normal vs. suspicious activity: baseline normal working hours, typical data transfer volumes, expected geographic locations, standard user access patterns. Configure detection rules for: failed authentication (5+ failed logins within 10 minutes), unusual access times (database queries at 3 AM by marketing staff), geographic anomalies (user logging in from India and US within 1 hour), privilege escalation (standard user added to admin group), data exfiltration patterns (large uploads to personal cloud storage), malware indicators (connections to known malicious IPs).
Implement Alert Prioritization and Response Workflows
Categorize alerts by severity: Critical (confirmed breach, ransomware detected, admin account compromised) - immediate response 24/7, High (multiple failed logins, suspicious file modifications, anomalous data access) - investigate within 1 hour during business hours, Medium (policy violations, unusual user behavior) - review daily, Low (informational events) - review weekly. Define escalation procedures: who investigates, when to escalate to management, when to engage incident response team, and notification requirements for CERT-In (covered incidents reported within 6 hours) and the DPDP regime (Data Protection Board and affected individuals notified without delay).
Assign Security Operations Team and Monitoring Responsibilities
Designate who monitors security alerts: in-house SOC (Security Operations Center) team, managed security service provider (MSSP), or hybrid model. Define responsibilities: continuous monitoring schedule (24/7 for critical systems or business-hours-only for lower risk), alert triage process (reviewing SIEM dashboards, filtering false positives), incident investigation procedures, and escalation protocols. For smaller organizations without dedicated SOC, assign IT security lead to review daily summaries and configure automated escalation for critical alerts.
Retain Logs and Maintain Forensic Readiness
Implement log retention per regulatory requirements: minimum 180 days for CERT-In compliance, 1 year for ISO 27001 typical audit needs, 3+ years for certain regulated sectors (banking, healthcare). Store logs securely: encrypted storage, access-controlled (only SOC and authorized investigators), and write-once/append-only to prevent tampering. Regularly test log retrieval and analysis: ensure you can query historical logs quickly for incident investigations and generate evidence for legal/regulatory proceedings. Archive older logs to cost-effective long-term storage.
Audit Evidence
During your ISO 27001 certification audit, auditors will expect to see the following evidence to demonstrate compliance with A.8.16:
Documentation
- Security Monitoring Policy defining scope, responsibilities, and response procedures
- SIEM architecture diagram showing log sources and data flows
- Alert response playbooks for different incident types
- Log retention schedule meeting CERT-In 180-day requirement
- Monitoring coverage inventory listing all systems being monitored
Interviews
- SOC team about monitoring processes, alert triage, and incident response
- IT Security lead about alert investigation and escalation procedures
- SIEM administrator about log source configuration and retention
Observations
- Review SIEM dashboard showing active monitoring rules and recent alerts
- Demonstration of alert investigation workflow from detection to resolution
- Verification of log retention (query 180-day-old logs successfully)
- Testing of alert escalation for critical security events
Practitioner Insights
A failure pattern I see across audits: an expensive SIEM is deployed but nobody actually reviews the alerts. In ransomware postmortems it is depressingly common to find the early warnings sitting in the SIEM well before the outbreak spread company-wide—ignored because the team was overwhelmed by false positives. Monitoring without dedicated review and tuned alerts is useless. Either resource a proper SOC or use managed security services.
Many Indian companies think antivirus is sufficient monitoring. It is not. You need visibility into network traffic, authentication events, and data access patterns. I have seen breaches where attackers used stolen valid credentials—antivirus detected nothing because there was no malware. Only SIEM detecting unusual login times and abnormal data downloads revealed the compromise. Monitoring must extend beyond malware detection.
Common Challenges & Solutions
Challenge
SIEM generates overwhelming volume of alerts (thousands daily) and security team cannot review them all.
Solution
Aggressive tuning is essential: whitelist known-good sources (monitoring tool heartbeats, scheduled maintenance scripts), suppress duplicate alerts (same alert from 50 servers = 1 notification), increase thresholds for noisy rules (5 failed logins may be normal in large org; escalate at 20+), use correlation rules to group related events, and focus on high/critical alerts first. Automate triage where possible using SOAR (Security Orchestration and Response) platforms. Accept that not all alerts can be reviewed—prioritize based on risk.
Challenge
Cloud and SaaS applications generate logs in different formats making centralized monitoring difficult.
Solution
Use SIEM with pre-built integrations: Splunk has add-ons for AWS, Azure, Google Cloud, Office 365; Microsoft Sentinel natively integrates with Azure and Microsoft 365. For custom SaaS apps, use APIs to pull logs or configure webhook-based real-time forwarding to SIEM. Normalize log formats during ingestion (map different time formats, IP field names, user identities to common schema). Consider cloud-native SIEM solutions (Sumo Logic, Datadog Security Monitoring) designed for multi-cloud environments.
Challenge
Log storage costs are prohibitively expensive for retaining 180 days across all systems.
Solution
Implement tiered storage: hot storage (last 30 days) in SIEM for fast searching, warm storage (31-180 days) in cheaper cloud object storage (S3, Azure Blob) searchable but slower, cold storage (beyond 180 days) for archive-only needs. Compress logs aggressively. Filter out low-value logs before ingestion (debug logs, heartbeat messages with no security value). For high-volume sources (web server access logs), sample or aggregate data rather than keeping every event. Calculate required capacity: bytes per event × events per second × 86400 × 180 days.
Challenge
Applications do not generate sufficient logs to monitor security events effectively.
Solution
Work with development teams to enhance application logging: log authentication attempts (success and failure with username, source IP, timestamp), authorization checks (denied access attempts revealing privilege escalation), data access (who accessed what sensitive data when), configuration changes (admin actions modifying system settings), and errors with security implications. Implement structured logging (JSON format) making parsing easier. For third-party applications, enable maximum audit logging even if it increases storage costs—gaps in visibility are worse than storage expenses.
Challenge
We have no dedicated security team to monitor alerts 24/7; should we still implement monitoring?
Solution
Yes—implement monitoring even without 24/7 SOC. Options: (1) Business-hours monitoring only (review SIEM daily during work hours, configure after-hours alerts for only critical events via SMS/email), (2) Managed Security Service Provider (MSSP) providing 24/7 monitoring at fraction of in-house SOC cost, (3) Cloud-native security tools with automated response (AWS GuardDuty auto-blocks malicious IPs, Microsoft Defender auto-quarantines malware), (4) Hybrid: automated response for known threats, daily manual review for anomalies. Any monitoring is better than none.
