Private corporate batches, live online cohorts and 1-on-1 mentoring in running security operations — telemetry pipelines, detection engineering, triage, incident response and automation — taught by a practitioner who runs it in production.
20 years across DevOps, SRE and Security · 10,000+ engineers trained · Trained teams at JPMorgan Chase, Verizon, Nokia and the World Bank
Principal DevOps Engineer & Architect
Rajesh teaches SecOps as an engineering system rather than a job description: what to collect and why, how a detection is written, reviewed and tested, how triage decisions are made under time pressure, and where automation removes work versus where it hides it. Sessions run against live telemetry from real hosts, cloud accounts and container platforms, and give as much time to false-positive reduction, coverage measurement and log-source health as to writing the first detection — because those are what determine whether a function survives its second quarter.
Twenty years across DevOps, SRE and Security, in principal and architect roles at PayPay, SoftwareAG, ServiceNow, JDA Software, Intuit, Adobe and others. He has trained engineers at JPMorgan Chase, Verizon, Nokia, the World Bank, VMware, Oracle, Mercedes-Benz and Airbus — more than 10,000 people personally. He teaches what he runs, not what he reads.
You are booked with a named engineer, and that is who turns up. Marketplaces and larger providers rotate whoever is free, so the person who sold you the agenda is rarely the person teaching it.
The same trainer is available for the next engagement, which matters when a team builds on what it learned last time.
Your batch is assigned a named trainer before it starts, and that is who teaches it. See the full faculty.
Engagements are matched on the tool, not the calendar. For SecOps that means a trainer who has run it in production — running security operations — telemetry pipelines, detection engineering, triage, incident response and automation — rather than whoever is free that week. You are told who is teaching before you commit, and that person is on the discovery call that shapes the agenda.
Where a batch is large enough to need a second trainer, the pairing is declared up front. The lead trainer stays accountable for the syllabus and the assessment either way.
Principal DevOps Engineer & Architect
Twenty years across DevOps, SRE and Security in principal and architect roles at PayPay, SoftwareAG, ServiceNow, JDA Software, Intuit, Adobe, IBM/Emptoris, Ness, MindTree and Accenture. He has trained more than 10,000 engineers personally, at organisations including JPMorgan Chase, Verizon, Nokia, the World Bank, VMware, Oracle, Mercedes-Benz and Airbus. He teaches what he runs, not what he reads.
Teams of 8–30
Custom agenda, your timezone, onsite or online, NDA-friendly.
Request a quoteIndividual engineers
A private instructor and a curriculum built around your goal.
₹99,999Individuals who want peers
Scheduled batch, max 8 to 10 hours of live instruction.
₹34,999A private batch starts with a discovery call. We look at the stack you actually run — the CI system, the cloud, the constraints — and map the agenda onto it, so examples use your topology rather than a generic one.
Delivery is onsite at your premises, live online, or hybrid, scheduled around your release calendar rather than ours. Batches run 8 to 30 engineers.
Every attendee leaves with recordings, slides, lab repositories and a completion certificate. You receive an attendance and assessment report. Invoicing supports PO and GST.
Talk to us about a private SecOps batchSecOps is the operational side of security: the people, telemetry and workflow that detect an attack in progress, decide what it is, contain it, and get the environment back to a known-good state. Where security architecture asks what controls should exist, SecOps assumes some of them will fail and asks how quickly the failure becomes visible and how reliably it is handled at three in the morning.
A working SecOps function has four parts that all have to be engineered. A telemetry pipeline collects the events that matter — authentication, process execution, network flow, cloud control-plane activity, application audit trails — and delivers them somewhere queryable, in time order, without silently dropping sources. A detection layer turns those events into signals, whether through SIEM correlation rules, threshold logic or behavioural analytics. A triage and response workflow moves each signal through investigation to a decision with an owner and a clock on it. And an automation layer removes the repetitive parts, because analyst attention is the scarcest resource in the whole system.
What makes SecOps distinct as a skill is that its failure modes are operational rather than theoretical. The common problems are alert volume nobody can clear, detections that fire on deployments instead of attacks, log sources that stopped shipping without anyone noticing, playbooks that assume access the responder does not have, and a mean time to respond that nobody measures honestly. Those are the problems this training is built around.
Detection has become the control organisations are actually judged on. Prevention still matters, but every serious framework, cyber-insurance questionnaire and customer security review now asks how quickly you would notice a compromise and what you would do next — and those questions are answered by operations, not by architecture diagrams.
The telemetry has also moved. A decade ago security monitoring meant firewall and endpoint logs from a static estate. Now the highest-value signals come from cloud control planes, identity providers, container runtimes and CI/CD systems, all of which change daily and none of which are owned by a traditional security team. That has pushed security operations towards engineers who understand the platform, and pushed detection work towards being written, reviewed and version-controlled like software.
The hiring gap is in judgement and engineering rather than tool operation. Anyone can forward logs into a SIEM and enable the default rule pack; the result is usually thousands of alerts a week and a team that ignores them. Deciding what to collect, what a detection should assert, what an alert obliges someone to do, and how to prove coverage against real attacker techniques is the work that is genuinely scarce.
The shape of the work before the tooling. The detection-to-response chain, the roles that carry it, the tiering models and their trade-offs, and where SecOps meets platform engineering, SRE and incident management. Also the honest failure modes: alert fatigue, coverage theatre and metrics that measure activity rather than outcome.
Topics: The detection, triage, response and recovery chain · Analyst tiers, or why some teams deliberately have none · In-house, managed and hybrid operating models · Where SecOps overlaps with SRE and platform engineering · Alert fatigue as an engineering problem · Outcome metrics: dwell time, MTTD, MTTR, alert quality · Common ways a SecOps function fails quietly
The pipeline everything else runs on. Choosing sources by the attacker behaviour they reveal rather than by what is easy to enable, then getting the data off the host reliably: agents, forwarders, cloud-native delivery, parsing, normalisation and the cost curve that decides what you can afford to keep.
Topics: Choosing sources by detection value: auth, process, network, DNS, cloud control plane, application audit · Endpoint telemetry: EDR, auditd, Sysmon, eBPF-based collection · Cloud trails, identity provider logs and Kubernetes audit logs · Collection agents, forwarders and buffering under back-pressure · Parsing, normalisation and a common schema · Time synchronisation, ordering and clock skew · Retention tiers, hot versus cold storage, and cost control
The failure nobody sees until an audit or an incident: a source that stopped shipping. Building visibility into the pipeline itself — heartbeats, volume baselines, parse-failure rates and end-to-end latency — so silence is treated as an alert rather than as good news.
Topics: Heartbeat and volume-baseline monitoring per source · Detecting a silent source before an incident does · Parse failures, schema drift and field-mapping breakage · End-to-end latency and its effect on time-to-detect · Buffering, back-pressure and data loss during bursts · Log integrity, immutability and tamper evidence · Onboarding checklist for a new source
Treating detections as code. What a detection asserts, how it is written and reviewed, how it is tested against both benign and malicious activity, and how it is versioned, deployed and retired. The discipline that turns a rule pack into a maintained codebase.
Topics: Anatomy of a detection: hypothesis, data source, logic, expected true positives · Signature, threshold, correlation and behavioural detections compared · Detection as code: repository layout, review and CI · Testing detections with generated activity and replayed data · Tuning: allowlists, suppression and their audit trail · Detection lifecycle — deployment, measurement, retirement · Writing an alert that tells the responder what to do next
Answering 'what would we miss' with evidence. Mapping detections to attacker techniques, distinguishing real coverage from claimed coverage, and validating with safe adversary emulation against systems you own — then converting the gaps into a prioritised backlog.
Topics: MITRE ATT&CK as a coverage vocabulary and its limits · Mapping detections and data sources to techniques · Claimed versus validated coverage · Safe adversary emulation against your own estate · Purple-team exercises and how to run them productively · Prioritising gaps by technique prevalence and impact · Reporting coverage without inflating it
The workflow that turns a signal into a decision. Enrichment, pivoting across data sources, scoping a suspected compromise, and reaching a defensible conclusion inside a time budget — plus the queue discipline that stops a backlog from becoming permanent.
Topics: Alert enrichment: asset, identity, threat intelligence and prior-history context · Pivoting across host, network, identity and cloud data · Scoping: from one alert to the full set of affected entities · Severity assignment and escalation criteria · Investigation notes that another responder can pick up · Queue management, ageing and the cost of an unclearable backlog · When to stop investigating and declare
Declared incidents. Command structure and communications, containment decisions and their business cost, evidence preservation, eradication, and the recovery step that most plans underspecify. Then the post-incident review that actually changes something.
Topics: Incident command, roles and communication discipline · Containment options and their operational trade-offs · Evidence preservation and forensic readiness · Credential compromise: rotation, session invalidation and re-entry paths · Eradication and verifying the environment is clean · Recovery, restore validation and reopening service · Post-incident review that produces engineering work, not blame
Making the function sustainable. Automating enrichment and repeatable containment actions, integrating threat intelligence so it changes detections rather than sitting in a feed, and running the operational rhythm — on-call, handover, review cadence and reporting — that keeps quality from degrading.
Topics: Automating enrichment before automating action · Response automation and the guardrails around destructive actions · Playbook design: what stays human and why · Ticketing, case management and closing the loop · Threat intelligence: indicators, technique reporting and relevance filtering · On-call, handover and shift-free operating models · Reporting to management without vanity metrics
We rebuild the agenda around the tools you actually run.
Request a custom agendaWire security telemetry from a Linux host, a cloud account and a Kubernetes cluster into one queryable store, with normalisation and time synchronisation proven.
Build heartbeat and volume-baseline monitoring, then kill a forwarder and measure how long it takes your own alerting to notice.
Write detections from stated hypotheses, test each against generated benign and malicious activity, and run the whole set in CI on every change.
Safely emulate a short attack chain on systems you own, record which detections fired, and rebuild the coverage map from evidence rather than assumption.
Work a mixed queue of alerts to decisions under a time budget, then rebuild the enrichment so the same queue takes half as long.
Run a credential-compromise incident end to end — containment, evidence, eradication, recovery — and produce a review that generates concrete engineering work.
Billed yearly at ₹9,996
Max 8 to 10 hours of live instruction
Full program, private instructor
8–30 engineers · custom agenda · onsite or online · PO and GST invoicing
Refunds. If we cancel or postpone a cohort, you get a full refund within 15 days. There is no money-back guarantee otherwise.
Terms. Course material remains licensed to the attendee. Read the terms.
Your data. We don't share it with third parties. Privacy policy.
Certificate of completion
Rajesh is a very good trainer I have experienced in DevSecOps training. The number of contents in different topics he has posted on the DevOpsSchool public website are amazing and user friendly for beginners and experienced professionals.
Very good training session. Well explained from the basics to the complex concepts. Also tried to cover practicals and demos within the 3 hour sessions. The learning content and videos are of a great deal of help.
Basics explanation was exemplary from Rajesh where he dealt with complicated topics to be simple. Great learning stuff personally for me.
Very detailed explanation and has lots of patience in attending the questionnaire. Thanks again for your wonderful sessions.
Good discussion, helped us to understand different tools in SRE.
Got good lab sessions which kept the new DevOps tool learnings to the point and it helped a lot in my career.
| What matters | YouTube + blogs | Generic online course | Freelance marketplace | DevOpsSchool |
|---|---|---|---|---|
| Named practitioner | No | Rarely | Varies per booking | Yes — same trainer each time |
| Production experience | Unknown | Unknown | Unverified | 20 years, named employers |
| Custom agenda | No | No | Sometimes | Built from your stack |
| Onsite delivery | No | No | Sometimes | Yes |
| Lab environment | None | Sandbox that expires | Varies | Your own cloud — skill goes with you |
| Assessment | None | Quiz | Rarely | Assignments + capstone per module |
| Per-attendee certificates | No | Sometimes | Rarely | Yes |
| Corporate invoicing | No | Limited | Varies | PO and GST |
| Post-training support | None | Forum, time-limited | None | Lifetime forum access |
Tell us the team, the stack and the timeline. You'll get a straight answer, not a sales sequence.
Talk to an advisorPrefer to call or email?
More ways to reach us on the contact page.