Private corporate batches, live online cohorts and 1-on-1 mentoring in operating with a managed detection and response provider — telemetry onboarding, detection engineering, alert triage, incident response, threat hunting and service governance — 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 managed detection work from the customer's side of the boundary: which telemetry sources to onboard and in what order, how log quality and parsing decide whether a detection can exist at all, detection coverage mapped to MITRE ATT&CK rather than asserted, and triage that distinguishes a tuning problem from a real intrusion. Twenty years across DevOps, SRE and Security and 10,000+ engineers trained inform the operational half — the escalation path and RACI between provider and internal responders, containment actions that need change authorisation, evidence handling and timeline construction, and the metrics that make a service review substantive rather than a slide of alert counts.
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 Deepwatch that means a trainer who has run it in production — operating with a managed detection and response provider — telemetry onboarding, detection engineering, alert triage, incident response, threat hunting and service governance — 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 Deepwatch batchDeepwatch is a managed detection and response provider. Rather than selling a product a customer installs and operates, it delivers security monitoring as a service: telemetry from the customer's endpoints, network, cloud accounts and identity systems is ingested into a managed detection platform, detection content is maintained against it, and analysts triage what fires around the clock, escalating the alerts that represent real activity and handling or directing containment when something is confirmed.
The detection stack is built around a managed SIEM — Splunk in many deployments — with integrations to endpoint detection and response tools, network sensors, firewalls, cloud provider logs and identity providers. Around that sits the service layer that customers actually interact with: a portal for alerts, cases and reporting, an assigned delivery team who learn the environment, agreed escalation paths, and service levels for acknowledgement and response.
What matters for a customer-side team is that MDR is a shared responsibility model, not an outsourcing of security. The provider cannot detect what it is not sent, cannot tune out false positives without context about your business, and in most engagements cannot take containment actions your change process has not authorised. The work that determines whether a Deepwatch engagement succeeds is largely done on the customer side: deciding what telemetry to onboard, supplying asset and business context, agreeing what constitutes an escalation, staffing the response end, and reviewing detection coverage against the threats that actually apply.
Building a twenty-four-hour security operations capability in house is out of reach for most organisations. Genuine round-the-clock coverage needs roughly a dozen analysts across shifts before anyone has written a single detection rule, and the market for experienced detection engineers is thin at any price. Managed detection and response exists because that arithmetic does not work for the majority of organisations that still need continuous monitoring.
At the same time, cyber insurance requirements, customer security questionnaires and regulatory expectations have converged on continuous monitoring and demonstrable incident response as baseline conditions. Signing an MDR contract satisfies that on paper, which is precisely where the risk sits: an organisation can be paying for monitoring while sending incomplete telemetry, ignoring escalations outside business hours, and having never tested the handover between the provider and its own responders.
The skill that is genuinely short, therefore, is not operating a vendor console. It is being a competent customer of a security service — knowing what to onboard and in what order, reading detection coverage against a framework rather than trusting a coverage claim, triaging and challenging escalations, running the response steps that only you can run, and holding the service to measurable outcomes at a review rather than accepting a dashboard of alert counts.
What managed detection and response is, and what it is not. In-house SOC against MSSP against MDR, the functions a security operations capability has to perform regardless of who performs them, and an explicit map of which responsibilities a Deepwatch-style engagement transfers and which stay with the customer.
Topics: Security operations functions: monitor, detect, triage, respond, improve · In-house SOC, MSSP and MDR compared honestly · The Deepwatch service model: platform, portal, delivery team and escalation · Shared responsibility: what the provider cannot do for you · Service levels, escalation paths and out-of-hours expectations · Contract, scope and onboarding expectations · Where MDR engagements fail and why · Building the internal team the service depends on
Detection is bounded by data. The sources that matter, the order to onboard them in when budget and ingest volume are finite, what each source actually reveals, and the collection architecture that gets the data out of your estate reliably.
Topics: Source inventory: endpoint, network, cloud, identity, application, SaaS · Windows event logging and Sysmon configuration · Linux auditing and process telemetry · Network telemetry: flow, DNS, proxy and firewall logs · Cloud provider logs: CloudTrail, Azure activity and sign-in, GCP audit · Identity provider and directory telemetry · Collection architecture: agents, forwarders, syslog and API pulls · Ingest volume, cost and retention trade-offs · Onboarding sequence by detection value per unit of cost
The unglamorous module that determines whether anything downstream works. Parsing and field extraction, normalisation to a common data model, timestamps and timezone errors, enrichment with asset and identity context, and how to tell that a source is technically onboarded but practically useless.
Topics: Parsing, field extraction and structured logging · Common information models and normalisation · Timestamps, timezones and clock skew · Asset inventory and criticality as enrichment · Identity enrichment and account context · Threat intelligence enrichment and its limits · Detecting silent source failure and ingest gaps · Data quality checks as a monitored control
Turning telemetry into detections, and knowing what you can and cannot see. Detection logic across signature, threshold, correlation and behavioural approaches, mapping to MITRE ATT&CK, writing detections that survive tuning, and testing them with adversary emulation rather than assuming they work.
Topics: Detection types: signature, threshold, correlation, anomaly, behavioural · The detection lifecycle: hypothesis, logic, validation, tuning, retirement · MITRE ATT&CK mapping and coverage assessment · Writing detection logic against a normalised data model · Detection as code: version control, review and testing · Adversary emulation with Atomic Red Team style tests · Measuring detection quality: true positives, precision and dwell · Custom detections for your business logic and crown jewels · Reviewing provider-supplied content critically
The daily work. Working a queue under pressure, prioritising by asset criticality and confidence rather than by severity label, pivoting through data to build a picture, and deciding correctly between closing an alert, tuning a detection and declaring an incident.
Topics: Triage workflow and time-boxed decision making · Prioritisation by asset criticality, confidence and blast radius · Pivoting: host to user to network to process · Building an investigation timeline from evidence · Distinguishing a tuning problem from an intrusion · Documenting an investigation so someone else can continue it · Alert fatigue, false positive management and safe suppression · Challenging and returning a weak provider escalation · Handover between shifts and between organisations
What happens after an escalation is confirmed. The incident lifecycle across an organisational boundary, containment actions and who is authorised to take them, evidence preservation, communication and escalation to leadership, and the post-incident review that changes something.
Topics: Incident lifecycle: prepare, detect, analyse, contain, eradicate, recover · Severity classification and declaration criteria · Containment options and the change authorisation problem · Provider-executed versus customer-executed response actions · Evidence preservation, acquisition and chain of custody · Communication: internal stakeholders, legal, customers and regulators · Ransomware and business email compromise playbooks · Post-incident review and corrective action tracking · Tabletop exercises with the provider included
The two highest-value telemetry domains in depth. What EDR sees and what it misses, process and command line analysis, persistence and lateral movement patterns, then network detection through flow, DNS and proxy data — and how the two combine to make an ambiguous alert conclusive.
Topics: EDR architecture, sensor coverage and blind spots · Process trees, command lines and parent-child anomalies · Persistence mechanisms and how each appears in telemetry · Credential access and lateral movement patterns · Living-off-the-land binaries and script-based execution · Network detection: flow, DNS, TLS metadata and proxy logs · Command and control patterns, beaconing and exfiltration · Correlating endpoint and network evidence for one event · Response actions: isolation, kill, quarantine and their consequences
Where attacks increasingly start. Cloud control plane logging across the major providers, the misconfigurations that matter, identity as the primary attack surface, token and session abuse, and detections for the cloud-native techniques that endpoint telemetry will never show.
Topics: Cloud control plane logging: AWS, Azure and GCP · Cloud misconfiguration and posture as a detection input · Identity provider telemetry and sign-in analysis · Impossible travel, MFA fatigue and consent phishing · Token theft, session hijacking and OAuth abuse · Privilege escalation paths in cloud IAM · Container and Kubernetes audit telemetry · SaaS application logging and coverage gaps · Response actions in cloud and identity systems
Looking without waiting for an alert. Structuring a hunt from a hypothesis rather than browsing dashboards, using intelligence at the level where it is actually useful, converting a successful hunt into a permanent detection, and documenting the hunts that found nothing so the coverage claim means something.
Topics: Hypothesis-driven hunting and scoping a hunt · Intelligence sources, quality and the pyramid of pain · Behavioural hunting against ATT&CK techniques · Baselining normal to make abnormal visible · Frequency and stack counting analysis · Hunting across endpoint, network, cloud and identity data · Converting hunt findings into detections · Documenting negative results and coverage assertions · Purple team exercises with the provider
Proving it works and keeping it honest. Producing audit evidence from monitoring data, mapping controls to frameworks, the metrics that make a service review substantive, and the governance to run a provider relationship — including how to exit one without losing your detection content and history.
Topics: Framework mapping: PCI DSS, HIPAA, SOC 2, ISO 27001, GDPR · Producing audit evidence from monitoring and response records · Log retention obligations and cost · Metrics that matter: coverage, detection quality, time to acknowledge, time to contain · Metrics that mislead: alert counts and closure rates · Running a substantive service review · Detection content ownership and portability · Contract, scope change and exit planning · Continuous improvement and the annual coverage cycle
We rebuild the agenda around the tools you actually run.
Request a custom agendaInstrument a Windows and a Linux host with meaningful telemetry, ship it to a SIEM, verify parsing and field normalisation, then build a monitor that catches the source going silent.
Build detection logic for three ATT&CK techniques, validate them with adversary emulation, then tune out the false positives without silently destroying the coverage.
Triage a mixed queue of real and benign alerts under time pressure, pivot through host, user and network evidence, and defend every disposition you assign.
Investigate a simulated intrusion that crosses endpoint, network, cloud and identity telemetry, and produce the full timeline, scope and impact assessment.
Run a ransomware tabletop that includes the provider handover, containment authorisation, evidence preservation and stakeholder communication under a realistic clock.
Scope and execute a hypothesis-driven hunt across historical telemetry, document the result whether or not you find anything, and convert one finding into a permanent detection.
Assemble a coverage assessment, detection quality metrics, response timings and gap analysis, then chair a service review that produces committed actions rather than a status update.
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
My experience with the AIOps training was positive. The course covered important topics in a structured way, and Rajesh Kumar explained the concepts patiently. I found the practical aspects particularly helpful because they made the technical content easier to understand.
I was looking to improve my understanding of AIOps, and this training helped me achieve that goal. Rajesh Kumar explained the subject in a structured and practical manner. The sessions on different AIOps concepts were informative.
I recently did a SRE Session with Rajesh Kumar from DevOps School and the session was great. Right from 1st day till day 15, we had a very interactive session. Rajesh clarified our doubts and the tool demos were excellent without any hiccups. He simplified the concepts while sticking to the content with a fine balance between theory and practice. Am convinced he is one of the best trainers for SRE & DevOps concepts.
The Rundeck developer session was excellent and highly engaging. I appreciated how well the session was structured, with the theoretical concepts explained clearly and in simple terms. What stood out most to me was the demo — it was both informative and enjoyable. I especially liked how Rajesh walked us through not only the happy path but also the sad path, showcasing common issues and sharing practical troubleshooting tips.
Rajesh's experience and knowledge are exceptional and we learnt invaluable practical knowledge which we can apply in our production environment. Incredibly friendly and gave us a fantastic insight both in-depth and at a high level of the Rundeck product.
Great learning experience from a very knowledgeable instructor with well-prepared course notes. The lab exercises on AWS instance work well to learn the hands-on side of the course.
| 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.