Description

A focused course, tailored for you

The SOC Implementation Engineer's Customer Onboarding Playbook

Stand up a customer SOC tenant the way an enterprise security team actually runs it, from first log source to first validated detection.

The customer's CISO does not measure your implementation by the go-live demo. They measure it by the first incident at 03:00 a month later, when the on-call analyst opens the runbook you left behind.

$199 one-time

Tailored to your situation. Access within 24 hours. 30-day money-back.

Includes a hand-built implementation playbook delivered alongside course access, generated for your specific situation.

Why this course

SOC implementation engineers sit on the seam between the vendor's product reality and the customer's operational reality. The product ships with a reference architecture and a use-case library. The customer ships with an asset inventory that lags by a quarter, a security team that is two analysts short, an EDR rollout that is 78 percent complete, and an SIEM the previous MSSP configured. The engineer who lands the tenant well is the one who closes that gap on paper before closing it in the console. That means an asset register the customer can keep current after the engineer leaves, a use-case catalogue that names the customer's actual crown-jewel applications instead of generic verticals, a detection-engineering changelog the customer's blue team can read and extend, and an analyst runbook written for the customer's overnight shift in plain language. When those four artefacts exist and are owned by the customer, the implementation survives the first 90 days. When they do not, the customer logs a string of re-tickets, the renewal conversation gets harder, and the next implementation engineer inherits the cleanup. This course is the playbook for the engineer who wants every handover to be the kind the customer's security director quotes when their CFO asks why the SOC line item is worth what it costs.

What you walk away with

Run a customer kickoff that produces a working asset register the customer agrees to keep current, not a vendor spreadsheet that goes stale week two.
Translate the product's reference use-case library into a customer-branded catalogue mapped to the customer's actual crown-jewel applications and regulatory obligations.
Stand up a log-source onboarding plan that ranks sources by detection value, not by ease of integration, and survives the customer's quarterly asset changes.
Build a detection-engineering changelog the customer's blue team can read, extend, and tune after handover without re-engaging the implementation team.
Write the customer-side analyst runbook in plain language so the overnight analyst on shift week four can actually use it.
Hand over with a 30-60-90 day measurement plan the customer's security director can take to their CFO at renewal.

The 12 modules

Module 1. The implementation engineer's seat at the customer table

Maps the four conversations the engineer has to lead in week one, with the customer's security director, the customer's IT operations lead, the customer's compliance owner, and the customer's overnight analyst. Names the artefact each conversation must produce by Friday. Includes the kickoff agenda template the customer can take to their own internal stakeholders, and the decision log that tracks who said yes to what scope.

Module 2. Asset register the customer will keep current

Walks through building an asset register the customer's own IT team can update after the engineer leaves, instead of the spreadsheet they will abandon. Covers the join keys between the CMDB, the EDR, the identity provider, and the cloud account inventory. Includes the asset-tier definitions that drive use-case priority, and the quarterly review cadence the customer security director will own.

Module 3. Customer-branded use-case catalogue

Translates the product's reference use-case library into the customer's own language: crown-jewel applications named, regulatory obligations cited, business-impact tiers stated. Includes the catalogue template, the priority-scoring rubric, and the worked example for a mid-size financial services customer and a mid-size manufacturer. Each use case carries a named owner on the customer side.

Module 4. Log-source onboarding ranked by detection value

Ranks log sources by the detections they unlock, not by how easy they are to integrate. Covers identity logs first, endpoint logs second, network logs third, application logs fourth. Includes the ingestion-gap monitoring rule that catches a silent source within four hours instead of four weeks. Includes the onboarding-status report the customer's security director sees weekly.

Module 5. Detection engineering the customer can extend

Covers writing detections so the customer's own blue team can read, tune, and extend them after handover. Names the changelog format, the test-data harness, the false-positive review cadence, and the deprecation rule for detections that have not fired in 90 days. Includes the analyst-facing detection description template that turns a SIEM rule into a sentence the customer's analyst understands at 03:00.

Module 6. Threat intelligence pipeline the customer owns

Stands up the threat-intelligence ingestion and tagging pipeline so the customer's analysts see context, not raw IOCs. Covers the provider mix, the dedup logic, the confidence scoring, and the rule for promoting a community indicator to a high-confidence one. Includes the weekly intel report the customer's security director uses to brief their leadership.

Module 7. Analyst runbook the overnight shift actually uses

Writes the customer-side analyst runbook in plain language for the analyst on shift at 03:00, not the engineer who built it. Covers the triage decision tree, the escalation matrix, the customer-specific business-context notes, and the runbook-versioning rule. Includes the runbook walkthrough the engineer leads with the customer's overnight team before go-live, and the question log that drives runbook revision in week two.

Module 8. Integration with the customer's ITSM and ticketing

Closes the loop between the SOC tenant and the customer's existing ITSM. Covers the ticket-template fields the customer's incident manager needs, the bidirectional sync rule for status changes, the SLA mapping that aligns SOC severity with the customer's operational severity, and the after-hours notification path that respects the customer's own on-call rota.

Module 9. Compliance evidence the customer's auditor will accept

Maps SOC tenant outputs to the audit evidence the customer's compliance team needs for their own framework obligations. Covers log retention proofs, detection-coverage reports, incident-response timelines, and analyst-action audit trails. Includes the evidence package template the customer's compliance owner can hand directly to their auditor, with field-by-field guidance on what auditors challenge.

Module 10. Performance metrics for the customer's CFO conversation

Picks the four metrics the customer's security director will use at renewal: mean time to detect on the customer's top three crown-jewel applications, false-positive rate trend, log-source coverage percentage, and analyst-action quality score. Includes the dashboard template, the data lineage notes, and the script the security director uses to explain each metric to their CFO.

Module 11. Handover that survives the first quarter

The week-12 handover that the customer's security team can run without the implementation engineer. Covers the artefact inventory, the named-owner ratification, the customer-side training session agenda, the 30-60-90 day check-in cadence, and the escalation path for the questions that will come up in week six. Includes the customer-signoff template that records which artefacts the customer has accepted ownership of.

Module 12. What goes back into the next implementation

Closes the loop on the engineer's own practice. Covers the lessons-learned format that feeds the next customer, the reusable-artefact library the engineer builds across implementations, the customer-anonymous use-case patterns that compound across the engineer's account base, and the conversation the engineer has with their own manager about which customer kinds suit this onboarding pattern best. Ends with the engineer's own 90-day plan for the next tenant.

How this addresses your situation

Specific modules that map to what you said you are dealing with.

Module 1-3 covers the week-one customer conversations and the artefacts that anchor scope: asset register, customer-branded use-case catalogue, decision log.

Module 4-6 covers the technical build that the customer can own after handover: ranked log-source onboarding, detection engineering with a changelog, customer-owned threat intelligence pipeline.

Module 7-9 covers the operational handover artefacts: analyst runbook, ITSM integration, compliance evidence package the customer's auditor will accept.

Module 10-12 covers measurement, handover, and the engineer's own practice: the renewal-conversation metrics, the week-12 signoff, and the lessons-learned that compound into the next implementation.

What you get with this course

12 written modules in the Art of Service learning environment, with worked examples for a mid-size financial services customer and a mid-size manufacturer.
Downloadable templates: asset register, use-case catalogue, onboarding plan, detection changelog, analyst runbook, ITSM integration mapping, compliance evidence package, renewal-metric dashboard, handover signoff.
The hand-built implementation playbook scoped to your customer mix, delivered alongside course access within 24 hours.
30-day money-back guarantee.

What you will have in hand by Day 1, Week 1, Month 1

Week 1: customer kickoff, asset register draft, use-case catalogue draft.

Week 2-4: log-source onboarding by detection-value ranking, detection-engineering changelog stood up.

Week 5-8: threat intelligence pipeline, analyst runbook, ITSM integration.

Week 9-11: compliance evidence package, renewal-metric dashboard.

Week 12: handover signoff with named owners on every artefact.

Before and after

Before

Customer tenant goes live green, then accumulates re-tickets through the first quarter. The customer's security director cannot answer their CFO's renewal question. The next implementation engineer inherits the cleanup.

After

Customer tenant goes live with four customer-owned artefacts the customer's own team maintains. The security director walks into renewal with four metrics that defend the SOC line item. The implementation engineer leaves a tenant that compounds into the next one.

What happens if you do not address this

The renewal conversation goes to the customer's CFO with the SOC engineer's product report instead of the customer security director's outcome report. The customer churns to a competitor, or the implementation engineer is brought back at zero margin to fix what the handover did not transfer.

Who it is for

SOC implementation engineer, customer security engineer, or cyber-security delivery consultant standing up customer SIEM, XDR, or managed-detection tenants. Comfortable in the product console. Wants the customer-facing operational artefacts that turn a green go-live into a tenant the customer can run after handover.

Who this is NOT for. Not for SOC analysts running triage on an already-stood-up tenant, not for pre-sales engineers writing scoping documents, and not for CISOs evaluating vendors. This is for the engineer whose name is on the implementation ticket and who has to leave the customer with something that works after the engineer logs off.

How it arrives

Text-based course in the Art of Service learning environment, plus downloadable templates and worked examples for every module, plus the hand-built implementation playbook delivered alongside course access.

Time investment. Roughly four to six hours to read the modules and adapt the templates to your current customer tenant. The implementation playbook is hand-built around your actual customer mix, so the work compounds rather than running alongside.

Why $199 is the right number

Vendor product documentation tells you how the console works. The product's reference use-case library names generic verticals. Customer-specific community posts are unevenly authored. This course is the missing layer: the customer-facing artefacts that turn a green go-live into a tenant the customer can run after handover.

FAQ

Does this teach the product console?

No. It assumes you already work in the console daily. It teaches the customer-facing artefacts that survive after you log off the customer tenant.

Is this vendor-specific?

No. The artefacts are vendor-agnostic and apply to SIEM, XDR, and managed-detection tenants. The worked examples reference the kinds of tooling SOC implementation engineers encounter at customer sites.

What does the hand-built implementation playbook cover?

It is scoped to your actual customer mix. After purchase, share the rough shape of your account base (industry, customer size, current tooling), and the playbook returns within 24 hours with the artefact templates pre-filled for your situation.

What if I work pre-sales rather than implementation?

This is for engineers whose name is on the implementation ticket. Pre-sales engineers will get value from modules 1-3 and 9-10 but the course centre of gravity is week-one through week-12 implementation.

30-day money-back guarantee. If after a week of working through the materials this is not what you needed, reply to the receipt email and a full refund is processed. No questions, no forms.

Within 24 hours your account in the learning environment is provisioned and the tailored implementation playbook is delivered alongside it.