Without noticing failed logins or weird access patterns, attackers can try password guessing attacks hundreds of times without anyone knowing, eventually breaking in. A textile exporter in Tiruppur lost customer payment data when an attacker made 5,000 failed login attempts over two weeks—no one was watching the logs. Your bank or large customers auditing you will fail you if you cannot show you monitor login activity. If a breach happens and you never noticed the warning signs, regulators and customers will hold you liable for negligence.
Find where your organisation is today. Be honest — the self-assessment is only useful if it reflects reality.
Absent
You have no system in place to track or notice failed logins. Your IT person, if you have one, only hears about a breach after it is reported by a customer or the police.
Initial
Your IT person occasionally checks server or router logs manually when something feels wrong, but there is no regular schedule or automated notification—most suspicious activity goes unseen.
Developing
You have set up basic log collection (e.g., Windows Event Viewer on one or two servers) and your IT person reviews failed login reports weekly, but alerts are not automated and you have no written policy for response.
Defined
You have centralized logging in place (all servers send logs to one location), automated alerts notify your IT person of repeated failed logins within minutes, and you have a written procedure for how to respond to alerts.
Managed
You have 24/7 monitoring with detailed reports showing login patterns, geographic anomalies, and time-of-day analysis; your IT person reviews trends monthly and updates access controls based on findings; documented incident response is tested quarterly.
Optimised
You have real-time AI-assisted detection flagging suspicious behavior instantly, automatic account lockdowns for clear attacks, correlation with other security events, and quarterly board-level reporting on login security metrics and trends.
| Step | What to Do | Who | Effort |
|---|---|---|---|
| 0 → 1 | Ask your IT provider or in-house IT person to show you where login logs are stored on your main servers/network device (Windows Event Viewer, router admin panel, etc.). Document the location. | IT Manager or IT Provider | 2–4 hours |
| 1 → 2 | Set up a simple weekly log review routine: IT person exports failed login events every Friday afternoon and documents any repeated failed attempts from the same user or IP address in a spreadsheet. | IT Manager | 1 week to establish routine |
| 2 → 3 | Deploy a centralized log collection tool (e.g., open-source ELK Stack or paid SolarWinds); configure all servers and network devices to send logs there; set up email alerts for >5 failed logins in 10 minutes from one account. | IT Manager or external IT consultant | 3–4 weeks including configuration and testing |
| 3 → 4 | Create written Incident Response Playbook for login alerts (who to notify, what to check, how to reset passwords, when to block IPs); conduct quarterly tabletop drills simulating a brute-force attack. | IT Manager and Security Lead | 1–2 months |
| 4 → 5 | Implement advanced analytics (behavior baseline, geographic anomaly detection, impossible travel flags) and integrate with SIEM; conduct annual security assessment and update detection rules based on threat intelligence. | Security Analyst or SOC vendor | Ongoing—quarterly tuning and monthly reporting |
Documents and records that prove your maturity level.
- Documented location of login logs (e.g., 'Logs stored on File Server at \\SERVER\Logs or in Azure/AWS CloudTrail')
- Written log review schedule or checklist (e.g., 'Every Friday, IT reviews failed logins and documents in LogReview.xlsx')
- Sample of failed login report from last month showing at least date, user, IP address, and outcome
- Alert configuration documentation or screenshots showing thresholds (e.g., 'Email alert triggered after 5 failed logins in 10 minutes')
- Incident response log or ticket showing at least one instance where an alert was investigated and action taken (e.g., 'Password reset after 12 failed logins detected on 2024-01-15')
Prepare for these questions from customers or third-party reviewers.
- "Show me your login logs from the past 30 days. How many failed login attempts do you see, and from where?"
- "How do you get notified of suspicious login activity? Is it automatic or manual? How long does it take you to know about a problem?"
- "Walk me through what you do when you notice a failed login attempt. Do you have a written procedure?"
- "Can you show me an example of a suspicious login attempt you detected in the past three months and what action you took?"
| Purpose | Free Option | Paid Option |
|---|---|---|
| Centralized log collection and monitoring from all servers and network devices in one place | ELK Stack (Elasticsearch, Logstash, Kibana)—self-hosted, requires technical setup; Graylog Community Edition—easier interface | Splunk (₹20,000–₹100,000/year depending on data volume); SolarWinds Eventlog Analyzer (₹150,000–₹500,000/year); Datadog (₹50,000–₹300,000/year) |
| Real-time alerts and notifications when login attempts fail repeatedly or come from unusual places | Built-in alerts in ELK/Graylog; simple scripts using Windows Task Scheduler or Linux cron to email alerts | Splunk, SolarWinds, or Datadog include alerting; Microsoft Sentinel (Azure) ₹5,000–₹20,000/month for SMBs |
| Analyze patterns and trends in login behavior to spot anomalies (e.g., logins from 10 countries in one day, 3 AM access when user normally works 9–6) | Manual analysis using spreadsheets; Python scripts with pandas library | Splunk, Datadog, or dedicated UEBA (User and Entity Behavior Analytics) tools like Rapid7 (₹100,000+/year) |
- Collecting logs but never reading them—logs pile up for months and when a breach happens, you cannot tell when the attacker got in because no one looked at the data.
- Only watching failed logins on one server (e.g., email) and missing attacks on other systems like file servers, accounting software, or remote access points.
- Setting alert thresholds too high (e.g., only alert after 100 failed logins) so attackers have time to break in before you notice; typical brute-force attacks succeed between attempts 50–200.
- Not investigating alerts because your IT person is too busy with day-to-day tasks; alerts pile up unread and lose their value.
- Sharing login credentials across users so you cannot tell who actually tried to log in; this makes detection and investigation impossible.
| Standard | Relevant Section |
|---|---|
| DPDP Act 2023 | Section 8 (Lawful basis and consent), Section 4.11 (organisational measures including monitoring and auditing access) |
| CERT-In 2022 Guidelines | Guideline 4.3 (logging and monitoring); Guideline 4.6 (incident response) |
| ISO 27001:2022 | Annex A.8.2 (User access management); Annex A.8.4 (Access rights review); Annex A.8.2.2 (Privileged access rights) |
| NIST CSF 2.0 | Detect (DE) – DE.AE-1 (Audit and accountability), DE.CM-1 (Monitoring and anomaly detection for networks and systems) |
Ready to assess your organisation?
Answer all 191 questions and get your NIRMATA maturity score across all 12 pillars.
Start Free Self-Assessment →