Failure Patterns, Contracts and Official Sources
Why managed security engagements fail for Indian MSMEs, and how to avoid it
The common patterns behind disappointing MSSP, MDR and SOC contracts — partial onboarding, alerts nobody reads, short log retention, weak SLAs, lock-in — and the fixes for each.
Managed security engagements rarely fail because the technology is bad. They fail in a few familiar ways: assets that were never onboarded, alerts sent to people who do not act, response that stops at "we notified you", logs kept too briefly to investigate or meet CERT-In's 180 days, contracts that hide costs and exits that leave you without your data. Each has a simple prevention that costs far less than the incident it allows. This guide describes the patterns generically, without naming companies, and links to every guide in this section.
Pattern 1: the estate was only half onboarded
The quote covered 150 endpoints; the agent reached 110. Servers in a branch, a new batch of laptops and the cloud mailbox were never connected. The monthly report showed "all green" because it only reported what it could see.
Prevention: compare your asset list with the provider's inventory at the end of onboarding and every month. Ask for a "silent endpoints" list in each report and make full onboarding a milestone before the first full invoice.
Pattern 2: alerts went to an inbox
High-severity alerts were emailed to a shared mailbox read the next morning. The provider met its SLA ("notified within 15 minutes"); the business lost a night.
Prevention: an escalation matrix with phone calls for critical alerts, a named person and deputy on your side for every hour, and a default action the provider takes if nobody answers. See SLA and contract questions.
Pattern 3: response meant "advice"
The contract said "response". In practice the provider sent instructions; nobody in the business could carry them out at 3 a.m.
Prevention: agree in writing what analysts may do without approval: isolate a device, disable a user, block an address. Test it in a tabletop exercise. Compare MSSP, MDR and SOC services.
Pattern 4: logs were kept for 30 days
After a slow, quiet compromise discovered two months later, the logs that would show how attackers entered were gone. CERT-In's Directions expect ICT logs to be kept for a rolling 180 days within India.
Prevention: at least 180 days of retention (hot plus archive) for key sources, with the copy's location named. See the CERT-In Directions guide.
Pattern 5: nobody owned the relationship
The provider sent monthly reports full of numbers; nobody read them. Recommendations to patch an exposed server repeated for six months.
Prevention: one internal owner, a monthly 30-minute review, and a short list of open risks with owners and dates. A virtual CISO a few days a quarter can fill this role.
Pattern 6: the cheapest quote had the smallest scope
The lowest per-endpoint price excluded servers, cloud logs and night-time response. Adding them later cost more than the next quote.
Prevention: normalise quotes to the same scope before comparing. See pricing models and hidden costs and renewal traps.
Pattern 7: the pen test caused an outage, or a legal problem
A tester ran an aggressive scan on a production ERP during month-end close, or tested a system hosted by a third party without that party's permission.
Prevention: written authorisation, a scope letter naming systems and time windows, and permission from hosting and SaaS providers where needed. See pen-test authorisation under the IT Act.
Pattern 8: leaving was harder than joining
At the end of the term the provider removed its agents and SIEM; the business had no logs, no reports in usable form and no firewall configuration backup.
Prevention: exit terms in the first contract: hand-over of logs for the retention period, reports, configurations and admin credentials, plus a transition period.
Pattern 9: sector rules were assumed to be the provider's job
A regulated entity assumed its provider "handled RBI" or "handled SEBI". Regulators hold the regulated entity responsible, including for outsourced activities.
Prevention: map your regulator's requirements yourself and show the provider which ones it must support. See RBI and SEBI cyber rules.
A quick health check for an existing contract
| Question | Healthy answer |
|---|---|
| How many of our endpoints reported in the last 7 days? | Matches the asset list |
| When did we last test the night escalation? | Within the last 6 months |
| How far back can we search logs today? | At least 180 days |
| What may the provider do without us? | Written, approved list |
| What do we get at exit? | Written, with formats and timelines |
| Who reviews the monthly report? | A named person with a calendar slot |
Where to check the rules
Every pattern above is easier to prevent when you read the rules at their source rather than in a sales deck. Our list of official sources shows where to check the CERT-In Directions, the IT Act and DPDP texts, sector rules and tax, and who to contact during an incident.
FAQ
Should we change provider after a bad incident?
First find out which pattern caused it. If it was scope or contract, fix the contract; if it was the provider's performance against clear terms, use the SLA remedies and plan an orderly exit.
Are these failures common?
They are patterns seen across many outsourcing arrangements, described here generically. We do not publish statistics or case studies.
What is the single most useful fix?
A tested escalation path for critical alerts at night. Most of the damage in incidents happens in the hours nobody is watching.
Sources
- CERT-In — Directions, advisories and incident reporting
- MeitY — IT Act and DPDP framework
- National Cyber Crime Reporting Portal — reporting cyber crime
- RBI and SEBI — rules for regulated entities
