- Join Our Company
- Email: sanjay@pjnetworks.com
- Phone: +91-9818361787
A SIEM (security information and event management) implementation is where most SIEM disappointment is actually manufactured. The platform choice gets the attention; the eight to sixteen weeks that follow decide whether the console fills with investigations or with noise. This is what those weeks contain, what each phase should hand you, and the one Indian regulatory decision that has to be made before the first log flows.
Before anything is installed, someone has to write down what will send logs, what will not, and why. The inventory is not a formality — it is the document that controls licence spend, retention arithmetic and detection coverage for the life of the platform. A scoping exercise that ends with “everything” has not been done; ingesting everything without a use case is the single most common way estates end up paying for data nobody queries. The phase should end with a source list ranked by the questions each source can answer.
Collectors are placed, parsers are matched to source formats, and the first data arrives. The decisions that matter here are unglamorous: filtering at the collector rather than the platform, time synchronisation across sources, and confirming that what arrives is parsed rather than merely stored. A field that does not parse today is a search that fails during an incident two years from now. The phase should end with a parse-rate report, not a screenshot of a dashboard.
Detection content gets written against the threats the estate actually faces — authentication anomalies, privilege change, exfiltration patterns, the handful of scenarios your sector regulator expects you to evidence. Default rule packs are a starting point and nothing more; unmodified, they are calibrated for an environment that is not yours. The phase should end with a written list of detections, each mapped to the log sources that feed it.
The first weeks of live operation produce false positives — all implementations do. The difference between a SIEM that gets used and one that gets ignored is whether this window is staffed and time-boxed: alerts reviewed daily, thresholds adjusted, noisy rules rewritten or retired. Skip it and alert fatigue arrives by month three, at which point the platform is expensive shelfware. The phase should end with an alert volume your team can actually investigate.
Whoever operates the platform next — your team, a provider, or a managed arrangement — inherits the rule content, the tuning history and a runbook that says what to do when each alert fires. If the implementation was done by an outside party, this is where content ownership gets tested: rules you cannot read or export were never really yours.
One choice cannot wait for phase four. CERT-In’s 2022 directions require ICT logs to be retained on a rolling 180-day basis within India, which shapes the ingestion and storage design from the first collector onward — where data physically sits, how retention tiers are structured, and what the licence model charges for keeping half a year of history searchable. Estates that discover this obligation after go-live retrofit it at the worst possible price. The retention and tiering mechanics are covered in depth on our managed SIEM services page.
We quote implementation from the source list, not from the seat count — which is why the scoping phase exists.
For a mid-size Indian estate — a few hundred devices, a mix of on-premises and cloud, standard sources — the honest range is eight to sixteen weeks from scoping to a tuned, handed-over platform. The spread is not vendor-dependent; it is decision-dependent. Three things reliably stretch it: custom application logs that need bespoke parsers, approval cycles for collector placement inside segmented networks, and — most often — nobody having authority to say which alerts may be retired during tuning. A phase-gated plan survives these; a big-bang go-live date does not.
Two calendar traps specific to India: change freezes around the financial year-end quarter, which can strand a half-onboarded estate for weeks, and audit season, when the same infrastructure team feeding your collectors is busy producing evidence for last year’s controls. Scheduling the ingestion phase away from both is free; discovering them mid-project is not.
If the estate has a platform team, an implementation partner for the first ninety days followed by in-house operation is a reasonable path — and on Fortinet estates there is a well-trodden FortiSIEM version of that roadmap. If nobody in-house will own tuning after go-live, implementing first and outsourcing later usually costs more than starting with a managed service, because the tuning window gets done twice. The distinction between the platform and the function — what a SIEM is versus who operates it — is the useful frame; a SOC delivered as a service bundles the operating half entirely.
A SIEM implementation is five phases, each with an inspectable output: a ranked source list, a parse-rate report, a mapped detection list, a survivable alert volume, and a runbook with ownership attached. Plan the CERT-In retention design before the first log flows, staff the tuning window like the project depends on it — because it does — and decide who owns the rules before someone else writes them.