When nobody knows who is responsible for monitoring, security alerts get missed, breaches take weeks to detect, and you only find out when a customer complains or a regulator asks questions. An e-commerce business in Bangalore lost ₹15 lakhs to fraudulent transactions because no one was assigned to check daily payment logs—the vendor thought the client was checking, the client thought the vendor was checking. Without clear responsibility, you also fail DPDP audits (regulators will ask 'who detected this breach?'), lose customer trust, and face potential fines for delayed incident reporting.
Find where your organisation is today. Be honest — the self-assessment is only useful if it reflects reality.
Absent
You have no written monitoring plan. People react to problems only when customers report them or systems crash, and you've never formally assigned monitoring duties to anyone.
Initial
You have one person (usually your IT person or owner) who informally watches for problems, but there's no written job description, no backup if they're absent, and vendors have no clear reporting requirements.
Developing
You've documented who is responsible for monitoring (e.g., 'Rajesh checks server logs daily'), but the rules are loose, inconsistent across vendors, and there's no defined process for what happens when an alert is found.
Defined
You have a written monitoring responsibility matrix covering internal staff and vendors, with clear escalation paths and response times (e.g., 'Critical alerts must be reported within 2 hours'), but you don't measure whether it's actually working.
Managed
Your monitoring responsibilities are formally documented, regularly tested, and tracked—you have records showing who checked what, when they checked, and what they found; vendors sign agreements with specific monitoring clauses; and you review effectiveness quarterly.
Optimised
Monitoring responsibilities are embedded in your security culture with automated tracking, regular audits, independent validation that tasks are done, continuous improvement based on findings, and documented proof that monitoring prevented or caught real incidents.
| Step | What to Do | Who | Effort |
|---|---|---|---|
| 0 → 1 | Write down one page listing who does what: 'Arun checks server login logs every morning; Priya checks firewall alerts; Vendor ABC confirms backups weekly.' Get owner sign-off. | Owner or IT person | 1 day |
| 1 → 2 | Create a one-page 'Monitoring Responsibility Matrix' with columns: Activity (e.g., 'Check failed login attempts'), Owner (name), Frequency (daily/weekly), and What to do if you find something. Include vendor names and their specific tasks. | IT person with owner input | 1 week |
| 2 → 3 | Build a formal document with escalation paths (e.g., 'If 5+ failed logins: notify manager within 1 hour; if 20+: notify owner immediately'). Add response times for each severity level. Include vendor SLAs in service agreements. | IT person and owner | 2-4 weeks |
| 3 → 4 | Create a simple tracking log (spreadsheet or free tool) where the assigned person signs off daily/weekly that they completed monitoring. Document findings. Build vendor reporting into contracts with dates/times. | IT person | 1-2 months |
| 4 → 5 | Review monitoring logs monthly, test that your backup person can step in, audit vendor compliance, and update responsibilities when roles change. Document lessons learned from any actual incidents caught. | IT person and owner, quarterly review | Ongoing |
Documents and records that prove your maturity level.
- Written Monitoring Responsibility Matrix or chart showing each role, task, frequency, and escalation owner
- Signed monitoring logs or checklists showing who checked what and when (at least 3 months of records)
- Vendor service agreements with specific clauses on what they must monitor, how often, and reporting timelines
- Incident record showing at least one security alert was caught, who reported it, when, and what action was taken
- Job descriptions or role summaries that explicitly include monitoring duties for each team member
Prepare for these questions from customers or third-party reviewers.
- "Show me your written document that defines who is responsible for monitoring what. Who monitors the firewall? Who checks server logs? Who verifies vendor compliance?"
- "If your assigned person is absent tomorrow, who takes over their monitoring duties? Show me the backup name and how they're trained."
- "Walk me through one example: you detected a suspicious login attempt or vendor alert last month. Who was responsible for catching it, when did they report it, and to whom?"
- "What agreements do you have with your vendors (hosting, security software, backup)? What specifically must they monitor and report to you, and how fast?"
| Purpose | Free Option | Paid Option |
|---|---|---|
| Track who did monitoring and when (daily sign-off) | Google Sheets or Excel with simple checklist: Date | Task | Owner | Completed Y/N | Findings | — |
| Centralize monitoring alerts from firewall, antivirus, and servers in one place | Syslog server (rsyslog on Linux) or free SIEM-lite like Wazuh (open-source, self-hosted) | Splunk (₹1.5–3 lakhs/year for small setup) or Datadog (₹50,000–2 lakhs/year) |
| Create and store monitoring job descriptions and vendor contracts | Google Docs or free document management (e.g., Alfresco Community) | SharePoint or document management SaaS (₹10,000–30,000/year) |
| Set alerts so monitoring person gets notified of critical events in real-time | Native log viewer on Windows/Linux or free alerting in Wazuh | Grafana (₹0–50,000/year depending on setup) or cloud SIEM alerting |
| Schedule and automate reminders for monitoring duties | Google Calendar with email reminders or free scheduling tool (e.g., Zulip) | Microsoft Teams or Slack integration (if you subscribe; usually included) |
- Assuming your IT vendor (hosting, backup, antivirus provider) is monitoring everything—they are not. Vendors monitor their own systems; you must define what you want them to report and when, or it won't happen.
- Naming only one person responsible without a backup. When that person takes leave or leaves the company, monitoring stops and you don't know for weeks. Always have a documented backup.
- Writing monitoring rules but never checking if people actually follow them. You need proof: a log, a spreadsheet, or email evidence that monitoring happened—not just 'we have a policy.'
- Not including incident response in the monitoring plan. Finding a problem is only half the job—monitoring is pointless if you don't know who to tell and when they need to act.
| Standard | Relevant Section |
|---|---|
| DPDP Act 2023 | Section 8(1) (Data Controller responsibility to implement security measures) and Section 6 (Processing only with consent and lawful basis) |
| CERT-In 2022 | Direction 4 (Incident reporting timeline) and Direction 6 (maintain logs and monitoring infrastructure) |
| ISO 27001:2022 | Annex A, Control A.8.16 (Monitoring activities) and A.5.17 (Supplier relationships and monitoring) |
| NIST CSF 2.0 | Detect function (DE.AE-2: Monitoring is done, DE.AE-3: Events are analyzed) |
Ready to assess your organisation?
Answer all 191 questions and get your NIRMATA maturity score across all 12 pillars.
Start Free Self-Assessment →