Continuous monitoring of networks, systems, applications, and outsourced development
Primary statement
Continuous monitoring covers: (1) networks, systems, and applications for anomalous behaviour (ISO A.8.16) with appropriate actions evaluating potential incidents; (2) outsourced development activities — directed, monitored, reviewed (A.8.30); (3) log generation and availability for continuous monitoring (NIST PR.PS-04); (4) critical systems identification and Board approval driving differential monitoring (SEBI ID.2); (5) operational improvements identified from monitoring (NIST ID.IM-03); (6) cyber risk management framework integration (SEBI GV.4).
Audit-fatigue payoff
A unified monitoring fabric — SIEM + EDR + network telemetry + application telemetry + outsourced-development oversight — satisfies monitoring requirements across all 11 contributing frameworks. The monitoring coverage matrix, alert-to-response sample, and improvement tracker are the consolidated evidence pack.
Strictness matrix
Scope
Scope: networks, systems, AND applications. Three layers monitored, not just network or just endpoint. ISO 27001 A.8.16 specifies the three-layer scope; SEBI ID.2 adds the criticality-driven differential.
Ceiling source: iso27001:A.8.16
Rationale: ISO 27001 A.8.16 specifies the broadest scope with three-layer coverage. Other frameworks address subsets (network-only, endpoint-only).
Threshold
Threshold for monitoring depth: critical systems identification using SEBI criticality criteria + Board approval. Critical systems receive enhanced monitoring (real-time, higher-fidelity, faster alert routing). Non-critical systems receive baseline monitoring.
Ceiling source: sebi_cscrf:CSCRF.ID.2
Rationale: SEBI CSCRF ID.2 sets the criticality-driven threshold with Board approval. The Board-approved-list requirement is uniquely strict.
Method
Method: (1) monitoring covering networks + systems + applications; (2) anomalous behaviour detection rules; (3) alert evaluation routing to IR pipeline (per A.5.25 event-to-incident categorisation); (4) outsourced development oversight (A.8.30) with documented monitoring; (5) log records generated and centrally available (NIST PR.PS-04); (6) differential monitoring per criticality (SEBI ID.2); (7) continuous improvement identified from monitoring outcomes (NIST ID.IM-03).
Ceiling source: iso27001:A.8.16
Rationale: ISO 27001 A.8.16 combined with NIST PR.PS-04 log availability and SEBI ID.2 criticality differential is the most prescriptive method.
Frequency
Monitoring cadence: continuous (real-time or near-real-time). Improvement cycle from monitoring: continuous (incident-driven) + periodic deep-dive (quarterly). Outsourced development monitoring: continuous through pipeline integration; periodic deep review (quarterly).
Ceiling source: iso27001:A.8.16
Rationale: Continuous monitoring is the universal floor. Quarterly improvement deep-dive is the audit-defensible periodic cadence.
Evidence
Required evidence: (1) Board-approved critical systems list (SEBI ID.2); (2) monitoring coverage matrix per layer (network / system / application); (3) SIEM / EDR / NDR configuration; (4) alert-to-response sample (sample 3 recent alerts and trace to actions); (5) outsourced development monitoring evidence (sample 3 outsourced projects with monitoring records); (6) log availability evidence (centralised log store); (7) improvement-from-monitoring tracker.
Ceiling source: sebi_cscrf:CSCRF.ID.2
Rationale: SEBI CSCRF ID.2 with the Board-approved critical systems list is the audit-defensible anchor evidence. Other frameworks reference monitoring but do not require Board approval of the critical systems list.
Auditor test pattern
Step 1: Inspect the Board-approved critical systems list. Step 2: Verify monitoring coverage matrix shows critical systems with enhanced monitoring. Step 3: Sample 3 recent alerts from the SIEM and trace each to a response action. Step 4: For outsourced development, inspect oversight records of one project. Step 5: Verify log availability — sample 3 systems and confirm their logs are centrally accessible. Step 6: Inspect the improvement tracker; verify monitoring outcomes are driving improvements (not just noted).
Common findings
Common 2024–26 findings: (1) Monitoring covers networks but applications and especially SaaS applications excluded; (2) Critical systems list exists but not Board-approved; (3) Alerts generated but trace-to-response absent — alerts closed without action; (4) Outsourced development monitoring absent — vendors self-report; (5) Improvement tracker theoretical — monitoring outcomes do not drive control changes.