If you don't monitor critical systems closely, you may not notice when someone breaks in, steals customer data, or causes an outage until significant damage is done. For example, a Delhi-based e-commerce business lost ₹8 lakhs when their payment gateway was hacked but nobody noticed for 14 hours because they weren't monitoring login attempts or transaction logs. If a regulatory audit finds you're not monitoring where customer data flows, you could face DPDP Act penalties. Without prioritised monitoring, your IT person spends time looking at unimportant alerts while real threats go undetected.
Find where your organisation is today. Be honest — the self-assessment is only useful if it reflects reality.
Absent
You have no idea which systems are critical or why. You either monitor everything equally or monitor nothing at all, and alerts (if they exist) are ignored or go to spam.
Initial
You can name 3-5 critical systems (like GST billing, customer database, email), but monitoring is ad hoc—you check logs manually only after someone complains or you remember to.
Developing
You have documented which systems are critical and have basic log collection running on those systems (event logs, application logs). Someone checks these logs weekly but there's no automated alert for suspicious activity.
Defined
You have a written list of critical systems with defined monitoring rules. Automated alerts fire for critical events (failed logins, large data exports, configuration changes) and go to your IT person or manager within minutes.
Managed
You have a monitoring dashboard showing health and security status of critical systems in real time, with alerts prioritised by severity. You review logs at least daily and have a log retention policy in place for compliance.
Optimised
Your critical system monitoring is integrated with threat intelligence, anomaly detection, and automated response. You have documented runbooks for each alert type, audit trails are immutable, and monitoring data is regularly reviewed with management and auditors.
| Step | What to Do | Who | Effort |
|---|---|---|---|
| 0 → 1 | Hold a 1-hour meeting with business owners and IT staff to list 5–10 systems that, if broken or hacked, would seriously harm the business. Classify each as Critical, Important, or Standard. Write this down and sign off on it. | Business owner or operations manager | 1 day |
| 1 → 2 | Enable application and system event logging on all critical systems (Windows Event Viewer, application log files, firewall logs, database audit logs). Confirm logs are being written to a central location or backup drive. Test by checking logs after a known event (e.g., a failed login). | IT administrator or IT support person | 3-5 days |
| 2 → 3 | Create a simple monitoring checklist for critical systems (e.g., 'Check failed login attempts daily', 'Review database changes weekly', 'Monitor outbound data transfers'). Set up email or SMS alerts for at least 3 high-risk events (e.g., 5+ failed logins in 10 minutes, user account creation, large file download). Test each alert manually. | IT administrator | 2-4 weeks |
| 3 → 4 | Deploy a low-cost centralised log management tool (Graylog, Splunk Free, or ELK stack). Configure it to ingest logs from critical systems, create dashboards for system health and security metrics, and set severity-based alerts. Document how to respond to each alert type. | IT administrator or external consultant | 1-2 months |
| 4 → 5 | Integrate monitoring with threat intelligence feeds, establish a log retention policy aligned with compliance requirements (DPDP Act), implement immutable audit logs, and conduct quarterly reviews with senior management and external auditors. Document lessons learned and update monitoring rules based on real incidents. | IT manager and cybersecurity consultant | Ongoing (quarterly reviews, monthly tuning) |
Documents and records that prove your maturity level.
- A written document listing all critical systems (e.g., billing software, CRM, payment gateway, email server) with justification for why each is critical and signed off by management
- Screenshots or logs showing that monitoring/alerting is actively running on these systems (e.g., event logs from last 7 days, alert delivery confirmations, dashboard screenshots)
- A monitoring checklist or runbook document showing what events are monitored on each critical system and how often they are reviewed
- Email or log records showing that alerts have been triggered, received, and acted upon in the last 30 days (e.g., alert for failed login attempts, unusual data access, or system configuration change)
- An audit trail or access log showing who accessed critical systems in the last 90 days and from where (e.g., VPN logs, database audit logs, application user activity logs)
Prepare for these questions from customers or third-party reviewers.
- "Can you show me a list of which systems you consider critical to your business and why? Who decided this, and when was it last reviewed?"
- "Walk me through how you monitor your billing system. What alerts have fired in the last month, and what did you do about them?"
- "If someone unauthorised accessed your customer database, how long would it take you to notice? How do you know?"
- "Show me proof that you're actually checking logs on critical systems. Who does this, how often, and where do they record what they found?"
- "Do you monitor your critical systems more closely than non-critical ones? What's the difference in monitoring effort?"
| Purpose | Free Option | Paid Option |
|---|---|---|
| Centralised log collection and real-time alerting for critical systems | Graylog Community Edition (self-hosted, unlimited logs); ELK Stack (Elasticsearch, Logstash, Kibana—open source, self-hosted) | Splunk Enterprise (₹12–18 lakhs/year); Datadog (₹2–5 lakhs/year depending on volume) |
| Windows event log and system monitoring | Windows Event Viewer (built-in); Splunk Universal Forwarder (free agent) | ManageEngine EventLog Analyzer (₹2–4 lakhs/year); Solarwinds SolarWinds Event Log Consolidator (₹3–6 lakhs/year) |
| Database activity monitoring and audit logging | Native database audit features (MySQL general log, PostgreSQL log, SQL Server event logs—built-in but manual review) | Redgate SQL Monitor (₹4–6 lakhs/year); Imperva SecureSphere (₹8–15 lakhs/year) |
| User and privileged access monitoring | Auditd (Linux); Windows Event Viewer for logon events (built-in) | Delinea Privileged Access Management (₹5–10 lakhs/year); BeyondTrust PAM (₹8–12 lakhs/year) |
| Network and firewall log analysis | Suricata IDS (open source); Zeek (formerly Bro, open source) | Fortinet FortiAnalyzer (₹3–6 lakhs/year); Palo Alto Networks Cortex (₹10–20 lakhs/year) |
- Monitoring everything equally: Many small businesses use basic antivirus or firewall logging that treats every system the same, so important alerts drown in noise. Identify 3–5 truly critical systems and ignore the rest initially.
- Logs exist but nobody reads them: You enable logging but logs pile up unread for months. Without a weekly log review checklist or automated alerts, monitoring is useless. Assign one person 2 hours per week to review critical system alerts.
- No documentation of what is critical: Business owners and IT staff disagree on which systems matter most, leading to gaps in monitoring. Write down your critical systems list, get the owner's signature, and review it annually.
- Monitoring stopped after a security incident: Companies add monitoring after a breach, then gradually turn it off or disable alerts because they're 'too noisy'. Commit to monitoring for at least 2 years; tune alerts instead of turning them off.
- Confusion between availability monitoring and security monitoring: You monitor system uptime but not security logs. CPU usage and disk space alerts don't catch hacking. Separately monitor for intrusion attempts, data exfiltration, and unauthorised access.
| Standard | Relevant Section |
|---|---|
| DPDP Act 2023 | Section 8(1) - Data Processor obligation to maintain security measures; Section 10 - Personal data breach notification requirement (implies detection capability) |
| CERT-In 2022 Guidelines | Direction 4: Real-time threat monitoring and incident detection required for organisations handling sensitive data |
| ISO 27001:2022 | Annex A.8.3 (Detection of activities), Annex A.8.4 (Logging), Control A.8.15 (Monitoring and measuring) |
| NIST CSF 2.0 | Detect Function (DE): DE.AE-1 (Audit logs), DE.AE-3 (Event detection), DE.CM-1 (System monitoring) |
Ready to assess your organisation?
Answer all 191 questions and get your NIRMATA maturity score across all 12 pillars.
Start Free Self-Assessment →