Description

A focused course, tailored for you

The Merchant-Platform Infrastructure Security Engineer's Hardening Playbook

A working playbook for hardening the shared infrastructure that holds merchant stores, checkout, and PII at e-commerce platform scale.

You own the controls that sit underneath thousands of merchant tenants on shared infrastructure, and every quarter the same exception keeps reappearing in the SOC 2 narrative because the workload-identity boundary still has not landed across every namespace.

$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

Infrastructure security at a merchant platform is not a single product. It is a layered tenancy problem on top of a payments-scoped path on top of a fast-moving internal platform. The checkout edge, the merchant admin, the merchant background workers, the internal data plane, and the external API gateway all share node pools, service meshes, and key material in ways the original architecture diagrams no longer reflect. The PCI-scope diagram the auditor wants is six months behind the actual deployment graph. The SOC 2 control owner is hand-writing exception narratives because the workload-identity rollout stalled at sixty percent. The internal red team finds a new lateral path between merchant tenants every quarter because the namespace isolation contract was never written down as a deployable artefact. The platform team will deprecate the current cluster runtime in the next major migration window, and nobody on the security side has a tested plan for moving the boundary controls without dropping coverage on the way. This course is the working playbook for the engineer holding all of that at once.

What you walk away with

Ship a workload-identity rollout plan that names every merchant namespace, every shared service account, and every exception, with an owner and a date for each.
Produce a PCI-scope diagram the auditor signs without follow-up, derived from the live deployment graph rather than from a year-old architecture doc.
Write a tenancy isolation contract for the namespace boundary that the platform team will deploy and the red team will sign off as their test target.
Close out the recurring SOC 2 exception narrative by replacing the hand-written explanation with a deployable control the control owner can point at.
Build a boundary-controls migration plan that survives the next cluster runtime change without dropping coverage during the window.

The 12 modules

Module 1. Mapping the actual tenancy graph

Pull the live deployment graph from the cluster API and the service mesh control plane, reconcile it against the architecture doc, and identify every place a merchant namespace shares a node pool, a service account, a secret store, or a sidecar with another tenant. The output is a tenancy map that names the shared surfaces by exact resource, not by team or by intent. This map is the input to every later module and the artefact the auditor wants when they ask what is in scope.

Module 2. Threat-modelling the merchant boundary

Run a structured threat model against the merchant-to-merchant boundary using the tenancy map from module 1. Walk lateral movement paths between two merchant namespaces, between a merchant namespace and the checkout edge, and between a merchant namespace and the internal control plane. The output is a ranked list of boundary weaknesses with named exploit paths, each tagged to a specific control gap a later module closes.

Module 3. Workload identity at namespace scale

Design and stage a workload-identity rollout that covers every merchant namespace, every shared service account, and every cron job that currently runs with cluster-wide credentials. The rollout includes a phased cut-over, a fallback path for the namespaces that break, and a closure plan for the exceptions list. The output is a workload-identity plan document plus the Terraform modules that implement the first phase.

Module 4. PCI scope as a derived diagram

Derive the PCI-scope diagram from the live deployment graph rather than maintaining a parallel architecture doc. The module walks the data-flow tagging that pulls cardholder-data-handling services out of the cluster API, the inventory reconciliation that catches drift, and the auditor-facing narrative that explains how the diagram stays accurate between audits. The output is a script that regenerates the diagram on every merge to the platform repo.

Module 5. PII residency for EU and Canada merchants

Build the data-residency control plane that pins merchant PII to the right region for EU GDPR and Canadian PIPEDA merchants, including the storage class selection, the cross-region replication block, the encryption-key residency, and the support tooling that respects the boundary when an engineer reads a row. The output is a residency control document plus a residency-violation alert that fires before the data crosses the boundary, not after.

Module 6. Checkout-edge hardening

Harden the checkout edge cluster against the specific failure modes a merchant platform sees. Bot pressure during a flash sale, payment-processor failover, fraud-engine model rollback, and the request rate spikes the rest of the platform never sees. The module covers the network policy, the admission controller rules, the rate-limit configuration, and the secret-handling pattern for the payment-processor credentials. The output is a checkout-edge hardening profile the platform team can apply.

Module 7. Secret material and key rotation

Inventory every shared secret across the merchant tenancy surface, identify the secrets that have not rotated in the last cycle, and build a rotation plan that covers the merchant API keys, the internal service-to-service credentials, the payment-processor secrets, and the cluster-level key material. The output is a key inventory document with rotation owners and a rotation calendar that the secrets-management platform enforces.

Module 8. Internal red team contract

Write the contract between the infrastructure security team and the internal red team. Define the target surfaces, the out-of-scope tenants, the safe-blast-radius rules, the findings handover format, and the closure SLA. The contract turns the red team from an interrupt source into a feedback loop on the controls the rest of the course delivers. The output is a signed contract document plus a findings-tracker template.

Module 9. SOC 2 exception register replacement

Walk the current SOC 2 exception register, classify the exceptions that exist because a control is incomplete versus the exceptions that exist because a control is misclassified, and replace each one with either a deployable control or a precise scope exclusion. The output is a fresh exception register with zero hand-written narrative entries and an owner for each remaining exception.

Module 10. Cluster runtime migration without coverage gaps

Plan the migration of the boundary controls onto the next cluster runtime without dropping coverage during the window. Map every control to the runtime feature it depends on, identify the controls that need a parallel implementation, sequence the cut-over so the high-risk controls move with a fallback, and define the coverage telemetry that proves the gap stayed closed. The output is a runtime migration plan plus the telemetry queries that prove it.

Module 11. Detection at the merchant boundary

Build the detection layer that fires when something crosses the merchant boundary in a way the controls did not stop. Cover the audit log routing, the SIEM rules tuned to merchant-tenancy signals rather than generic Kubernetes signals, the merchant-namespace lateral movement queries, and the response runbooks the on-call team will follow at 3am. The output is a detection pack plus an on-call runbook a new engineer can run on their first rotation.

Module 12. Carrying the boundary across product launches

The merchant platform ships new product surfaces every quarter. Each launch can quietly extend the tenancy surface, the data-flow graph, and the PCI scope. The final module builds the launch review checklist, the security-engineer sign-off contract, and the post-launch reconciliation that catches the surface drift before the next audit. The output is a launch review document the product orgs will actually run because it is short and the security-engineer review is on the critical path.

How this addresses your situation

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

Workload-identity rollout stuck at sixty percent across merchant namespaces, with the SOC 2 control owner hand-writing the exception narrative each cycle.

PCI-scope diagram out of date relative to the live deployment graph, with the auditor asking for the reconciled version before the next interim review.

Internal red team finding a new merchant-to-merchant lateral path each quarter because the namespace isolation contract was never written down.

Next cluster runtime migration window approaching with no tested plan for moving the boundary controls without dropping coverage.

What you get with this course

Twelve written modules in the Art of Service learning environment, each tied to a specific artefact an infrastructure security engineer ships.
Downloadable templates for the tenancy map, the workload-identity rollout plan, the PCI-scope reconciliation script, the residency control document, the exception register, the runtime migration plan, and the launch review checklist.
A hand-built implementation playbook tailored to the buyer's actual cluster runtime, merchant base, and audit cycle, delivered alongside course access.
Thirty-day money-back guarantee.

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

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

Module one through four are designed to fit a single sprint of effort and produce the tenancy map, the threat model, and the first phase of the workload-identity rollout.

Module five through eight extend across the following sprint and produce the residency controls, the checkout-edge hardening profile, the key inventory, and the red team contract.

Module nine through twelve close out the SOC 2 exception register, the runtime migration plan, the detection pack, and the launch review checklist.

Before and after

Before

The exception register grows each cycle because the workload-identity rollout never finishes, the PCI-scope diagram is six months behind the deployment graph, and the red team finds a new lateral path between merchant tenants every quarter.

After

The exception register shrinks each cycle, the PCI-scope diagram regenerates on every merge, the namespace isolation contract is the red team's signed-off test target, and the next runtime migration has a coverage plan the platform team accepted.

What happens if you do not address this

The next audit cycle lands with the same exception register, the next cluster runtime migration window opens with no tested boundary plan, and the next merchant-to-merchant lateral path the red team finds becomes a question from a regulator instead of a question from a colleague.

Who it is for

An Infrastructure Security Engineer or staff-level equivalent inside a multi-tenant merchant platform or large SaaS, with operational responsibility for the controls that protect shared compute, shared networking, and shared key material across thousands of customer tenants. The person who has root in the cluster, a seat in the SOC 2 audit, and a Slack channel with the internal red team.

Who this is NOT for. Not for solo cloud-security generalists at a single-tenant startup. Not for SOC analysts whose work ends at the SIEM. Not for compliance program managers without hands on the deployment surface. The course assumes the buyer reads YAML, owns Terraform modules, and has at least one merge request open against the platform repo this week.

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 twenty-five to thirty hours of focused engineering time across the twelve modules, sized to fit alongside on-call rotations and audit-cycle deadlines.

Why $199 is the right number

Cloud-provider security training covers single-tenant patterns and stops at the cluster boundary. PCI council guidance covers the payments path but not the multi-tenant infrastructure underneath it. Vendor-led platform security workshops cover their product and leave the merchant-tenancy boundary as an exercise. This course is the working playbook for the engineer who has to ship the controls across all of those surfaces at once.

FAQ

Is this tied to a specific cluster runtime or cloud provider?

No. The modules describe the controls in terms of the artefacts an infrastructure security engineer ships, and the hand-built implementation playbook is tailored to the buyer's actual runtime, cloud provider, and merchant base.

Does the course cover the payments path specifically, or the wider infrastructure?

Both. Module four and module six work the payments path explicitly, and the rest of the modules cover the wider tenancy and platform surfaces that the payments path depends on.

What is the implementation playbook?

A hand-built document, written for the buyer's actual environment from the inputs they provide at enrolment, that translates the course modules into the specific tenancy graph, audit cycle, and runtime the buyer operates.

Is there a refund window?

Yes. Thirty days, full refund, no questions.

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.