Multi-Tenant Operations for Service Providers

Curriculum

Durations include the exercise and are meant honestly rather than optimistically — a lesson estimated at thirty minutes takes about thirty minutes. A lesson that would run past twenty-five minutes has been split into two.

1. Module 1 · 105 min · 4 lessons

   The tenancy model, honestly

   Before you run twenty tenants, understand exactly where the boundary between them is and what enforces it. This module includes the least comfortable lesson in the programme, and putting it first is deliberate: everything you plan afterwards should be planned knowing it.

   1. Concept30 min

      Where the tenant boundary actually is, and what enforces it

      A single guard installed on the root router ahead of route matching: any path carrying a tenant marker requires a valid credential and requires that credential's organisation to match the path. Because it runs before routing it also covers routes that do not exist yet, which is the property that makes it trustworthy rather than merely present.

      After this lesson you can

      • Explain the enforcement model to a customer's technical stakeholder in under three minutes.
      • State why the guard running before route matching is stronger than a per-route check, and name the failure it prevents.
      • State what is not in place at the database layer, and what that means for the guard's importance.
      • Answer the customer question 'can another tenant see our data?' accurately, including the mechanism rather than a reassurance.
   2. Concept25 min

      The operator identity that spans tenants

      Cross-tenant operation runs through a separate identity domain with its own signing key, and the control plane refuses to start if that key is shared with the tenant one. That refusal is a feature you can point at: because the process will not boot on a shared key, the control plane merely running proves the two identity domains are separate.

      After this lesson you can

      • Distinguish the two identity domains and say which one your work sits in for a given task.
      • Explain why a shared symmetric signing key between the two domains is a full-platform compromise reachable from one customer.
      • Use the boot-time refusal as evidence in a customer security conversation.
      • State what a cross-tenant operator token structurally cannot contain, and why that matters.
   3. Concept25 min

      What a partner console would be, and what exists instead

      The uncomfortable lesson. There is no productised partner portal: no single pane listing your customers with their posture scores, no cross-tenant alert queue, no aggregated billing view, no delegated-access model designed for a service provider. This lesson enumerates what is missing precisely, and then teaches what you actually do instead.

      After this lesson you can

      • List, specifically, the five multi-tenant capabilities that do not exist, so you never promise one to a customer.
      • Describe the working substitute for each, and its cost in your technicians' time.
      • Decide whether your practice can operate on the substitute at your current customer count, and at three times it.
      • Write the sentence you will use with a prospect when they ask whether there is a partner portal.
   4. Hands-on lab25 min

      One account per tenant, and what that costs you

      A user belonging to more than one organisation receives no organisation claim on their token, and parts of the platform then refuse them. For an in-house administrator this is an edge case. For you it is the central case, and this lesson measures the cost rather than describing it.

      After this lesson you can

      • Reproduce the refusal, so you recognise it instantly when a colleague reports it.
      • Identify which surfaces are affected and which work normally.
      • Design your account model around the constraint, and cost the credential management it implies.
      • State the fix that is required and track it, so your account model changes when it lands.

      Exercise

      Reproduce the multi-organisation refusal and cost the workaround

      You need

      • Two tenants you control
      • One test identity

      Steps

      1. Add the same identity to both tenants.
      2. Sign in and attempt an operation on the AI surface. Record the exact response.
      3. Attempt an operation on the billing surface. Record it.
      4. Now attempt several operations that do work, and write down the boundary between the two sets.
      5. Design the account model you will actually use: separate accounts per tenant, a naming convention, and where the credentials live.
      6. Cost it: minutes per technician per week, at your current customer count and at three times it.

      How you know it worked

      A reproduced refusal you can describe from memory, a written boundary between affected and unaffected surfaces, and a costed account model.

2. Module 2 · 110 min · 4 lessons

   Provisioning and onboarding to a standard

   The difference between a practice and a collection of individuals is that a colleague can pick up your tenant and know how it was built. This module produces three artefacts you keep: a provisioning procedure, a baseline configuration and a handover document.

   1. Hands-on lab30 min

      Provisioning a tenant

      End to end: the tenant, its home region, its licence and modules, its first administrator. Do it twice — the second time from your own written procedure, to find out what you left out.

      After this lesson you can

      • Provision a tenant end to end without referring to anything but your own notes.
      • Set the home region deliberately and explain to the customer what it binds and what it does not.
      • Configure module entitlements to match what the customer bought.
      • Produce a provisioning procedure another technician can follow.

      Exercise

      Provision twice, and let the second one find your gaps

      You need

      • Permission to create tenants
      • Two hours

      Steps

      1. Provision the first tenant, writing down every step as you take it.
      2. Provision the second tenant using only what you wrote.
      3. Note every point at which you had to improvise. Those are the gaps in your procedure.
      4. Rewrite the procedure. Include the things you knew and did not write down, which is usually the home-region decision and the first administrator's factor enrolment.
      5. Have a colleague provision a third tenant from your procedure without asking you anything.

      How you know it worked

      A colleague provisioned a tenant from your document without speaking to you. Nothing less counts.

   2. Hands-on lab25 min

      Module entitlements, and the console that shows everything anyway

      The server enforces module entitlement per tenant. The console does not consume that enforcement, so a customer who bought two modules sees navigation for all four and gets a refusal when they click. You will field this call, so you should be able to explain it in one breath.

      After this lesson you can

      • Set entitlements for a tenant and verify the server enforces them.
      • Reproduce the customer experience of clicking into a module they did not buy.
      • Write the explanation you will give when a customer reports it as a bug, which is what it will be reported as.
      • Decide whether to pre-empt it in your onboarding call, and draft the sentence.

      Exercise

      Buy two modules, see four, explain it

      You need

      • A tenant you can change the licence on

      Steps

      1. Set a tenant's entitlements to two modules.
      2. Sign in as a customer-equivalent account.
      3. Navigate to a module the tenant does not have. Record exactly what the customer sees.
      4. Confirm from the server response that the refusal is entitlement and not permission — they look similar to a user and are diagnosed differently.
      5. Write two sentences you would say on a call, one for a technical contact and one for an owner.

      How you know it worked

      You can state, from the response alone, whether a given refusal is an entitlement refusal or a permission refusal. That distinction is Module 4's first diagnostic path.

   3. Hands-on lab30 min

      A baseline configuration you can apply and diff

      Your baseline is the set of settings you apply to every customer unless there is a reason not to. Writing it down converts an argument about a customer's configuration into a diff against a standard, which is the only way a portfolio stays reviewable.

      After this lesson you can

      • Define a baseline covering sign-on policy, zones, roles, autonomy tiers and log sources.
      • Apply it to a tenant and record every deviation with a reason.
      • Diff a second tenant against the baseline and account for every difference.
      • State which baseline items you would never vary, and why.

      Exercise

      Write the baseline, then diff two tenants against it

      You need

      • Two configured tenants
      • Your provisioning procedure from the previous lesson

      Steps

      1. Write the baseline as a list of settings with the intended value for each.
      2. For each item, note whether it is fixed or negotiable per customer.
      3. Walk one tenant against the list. Record every deviation and whether it was deliberate.
      4. Repeat for the second tenant.
      5. For every deviation you cannot explain, decide whether to correct the tenant or amend the baseline. Both are legitimate; not deciding is not.

      How you know it worked

      A baseline document and two completed diffs where every deviation has a written reason.

   4. Concept25 min

      The handover document, and getting it countersigned

      What the customer is now responsible for, what the platform will do without asking, what it will never do, and what it cannot see. Getting this countersigned is not legal defensiveness — it is the artefact that stops the conversation eight months later where the customer believed you were watching at three in the morning.

      After this lesson you can

      • Produce a handover document covering autonomy, coverage gaps, escalation and the on-call reality.
      • State plainly, in writing, that there is no human on call unless the customer has one.
      • List the coverage gaps specific to that customer, including skipped checks and any platform they run that the sensor cannot cover.
      • Get it countersigned, and know what to do when a customer refuses to sign it.

3. Module 3 · 115 min · 4 lessons

   Portfolio operations

   Twenty tenants, one Monday morning, ninety minutes. This module builds the review you will actually run, out of the parts that exist, and teaches the judgement call that consumes most of the time: is this a regression, or is the product correct?

   1. Concept25 min

      What aggregates across tenants, and what you assemble yourself

      A precise inventory. Knowing which questions you can ask once and which you must ask twenty times is what makes a portfolio review fit in ninety minutes instead of a day.

      After this lesson you can

      • List the questions answerable once across the portfolio.
      • List the questions requiring a per-tenant visit, and estimate the per-tenant cost of each.
      • Choose the four you will actually run weekly, and justify dropping the rest.
   2. Hands-on lab35 min

      Building the Monday-morning review

      Design it, run it against your real tenants, and time it. A review that takes longer than the window you have will be skipped in week three, so the timing is the design constraint rather than an afterthought.

      After this lesson you can

      • Design a review that fits the time you actually have.
      • Run it against every tenant you operate and record the elapsed time.
      • Identify the step that consumed the most time and either automate it or drop it.
      • Define the escalation threshold: what, seen in the review, stops the review and becomes an incident.

      Exercise

      Run it, time it, then cut it

      You need

      • At least two tenants, ideally more
      • A timer

      Steps

      1. Write the review as an ordered checklist with a target time per tenant.
      2. Run it against every tenant, timing each.
      3. Total the time. If it exceeds your window, you are not finished.
      4. Cut the lowest-value step. Justify the cut in writing — you are accepting a risk and should be able to name it.
      5. Re-run and re-time. Repeat until it fits.
      6. Define, explicitly, the three findings that stop the review and become incidents.

      How you know it worked

      A timed review that fits your window, with written justifications for what you cut and three named stop conditions.

   3. Judgement35 min

      Regression, or the product behaving correctly?

      Eight cases drawn from the shapes that actually generate partner escalations. In five of them the product is correct and the answer is an explanation; in three it is a real problem. Getting this wrong in either direction is expensive — a wasted escalation, or a missed defect.

      After this lesson you can

      • Given a symptom across tenants, decide between correct behaviour, misconfiguration and defect.
      • Recognise the pattern where one tenant differs because of its licence rather than its configuration.
      • Recognise the pattern where a quiet tenant is quiet because ingestion stopped, not because nothing happened.
      • State the three pieces of evidence you gather before escalating anything to us.
   4. Concept20 min

      Baselining a new tenant against the portfolio

      A new customer's first fortnight looks alarming or looks empty, and neither is informative on its own. Comparing against the distribution across your portfolio is what turns a new tenant's numbers into a judgement.

      After this lesson you can

      • State what the first fortnight of a new tenant should look like, from your own portfolio data.
      • Identify a new tenant that is anomalous rather than merely new.
      • Explain to a new customer why their alert count is low, without implying it will stay low.

4. Module 4 · 130 min · 5 lessons

   The four diagnostic paths

   Four failure shapes account for most of the support traffic a partner generates. Each has a specific diagnostic path, and each has a distinguishing observation that separates it from the other three. This module is the one that makes your practice independent of us.

   1. Hands-on lab30 min

      Refused on a module they paid for

      Three distinct causes produce a near-identical refusal: the tenant lacks the module entitlement, the role lacks the permission, or the permission does not exist for that role in this version. They are diagnosed differently and confusing them costs an hour.

      After this lesson you can

      • Distinguish the three causes from the response and one further check each.
      • Fix each one, and state which of the three you can fix and which needs us.
      • Explain why a tenant's administrator holds every permission that exists rather than an enumerated list, and what that guarantees.

      Exercise

      Produce all three refusals deliberately

      You need

      • A tenant you can change the licence and roles on

      Steps

      1. Remove a module entitlement and attempt an operation in it. Record the response.
      2. Restore the entitlement, revoke one permission from a role, and attempt again. Record the response.
      3. Note the distinguishing observation between the two.
      4. Write the diagnostic as a decision tree with the observation at each branch.
      5. Hand the tree to a colleague and have them diagnose a case you set up without telling them which it is.

      How you know it worked

      A colleague correctly diagnosed a case they had not seen, using only your decision tree.

   2. Hands-on lab25 min

      A detection rule that refuses to activate

      The validation gate refuses to mark a rule active when the fields it depends on are unpopulated in that tenant. This is correct behaviour and it will be reported to you as a bug. Diagnosing it means finding which field is empty and why.

      After this lesson you can

      • Given a rule that will not activate, identify the unpopulated field it depends on.
      • Determine whether the field is unpopulated because of a missing log source, a licence limit, or because nothing in the platform emits it yet.
      • Explain to the customer why the platform refuses rather than letting the rule claim coverage it does not have.

      Exercise

      Find the empty field

      You need

      • A tenant with a shadowed rule

      Steps

      1. Find a rule in shadow that you did not shadow.
      2. Identify the fields it references.
      3. For each, check whether your tenant's ingested events populate it.
      4. Classify the cause: missing source, licence limit, or nothing emits it.
      5. For the third category, confirm no configuration change will help and record it as a coverage gap in that customer's register.

      How you know it worked

      A named field, a classified cause, and — where it applies — a coverage gap written into the customer's register rather than a ticket raised with us.

   3. Hands-on lab30 min

      A rotation that reported success

      The worst shape of failure in the product's history: a rotation that changes the target's password, does not store the new one, and records success — leaving the customer locked out of their own system while the dashboard is green. It is fixed. Verifying rotations end to end anyway is the habit this lesson installs.

      After this lesson you can

      • Verify a rotation by authenticating with the new secret and confirming the old one is rejected.
      • Build that verification into your rotation onboarding so it happens once per target type, not once ever.
      • Recognise the general shape: a subsystem reporting success on a value it never round-tripped.
      • State which credentials must never be placed under automated rotation.

      Exercise

      Rotate, then prove it both ways

      You need

      • One non-production target of a type you actually manage for customers

      Steps

      1. Configure rotation for one target and run it.
      2. Retrieve the new secret from the vault and authenticate to the target with it. Confirm success.
      3. Attempt to authenticate with the previous secret. Confirm rejection.
      4. Record the result per target type. A rotation engine verified against one database does not verify the others.
      5. Write down which of your customers' credentials you will never automate: domain controllers, root, break-glass.

      How you know it worked

      Both directions proven for at least one target type, and a written list of never-automate credentials per customer.
   4. Hands-on lab25 min

      Verification reports content tampering

      This is the highest-stakes support call you will take, and it has a false-positive mode. Content verification compares a recomputed digest against a stored one, and a representation mismatch — key ordering, numeric normalisation, timestamp precision, fixed-width padding — produces the same result as real tampering.

      After this lesson you can

      • Follow the escalation path for a content result, in the correct order, within the first hour.
      • Distinguish a plausible representation mismatch from plausible tampering, and say why you cannot do so conclusively.
      • Explain why the correct default assumption is tampering until proven otherwise.
      • State what you tell the customer, and when.

      Exercise

      Write the runbook before you need it

      You need

      • Nothing but ninety minutes and a colleague to review it

      Steps

      1. Write the first-hour procedure for a content result: who you tell, what you preserve, what you do not touch.
      2. Write the equivalent for a linkage result and mark where the two diverge.
      3. Note the evidence you would gather that lets us distinguish a representation mismatch from tampering.
      4. Have a colleague review it for the step you left out. There will be one, and it is usually preserving the state before investigating it.
      5. Store it somewhere reachable without access to the affected tenant.

      How you know it worked

      A reviewed runbook stored outside the systems it concerns, with a named person for the first notification.
   5. Judgement20 min

      When to escalate to us, and with what

      Six cases. In four of them a certified technician should resolve it. Escalating everything makes you slow and makes us useless; escalating nothing means a real defect sits in a customer's tenant for a month.

      After this lesson you can

      • Decide, for six cases, whether to resolve or escalate.
      • Assemble the three pieces of evidence that make an escalation answerable on the first reply.
      • Recognise the two categories that should always be escalated immediately regardless of your confidence.

5. Module 5 · 100 min · 4 lessons

   Fleet, lifecycle and exit

   Sensor versions across estates you do not own, and the two transitions nobody plans for: taking a tenant over from somebody else, and giving one back. The exit lesson is the one that earns a partner repeat business.

   1. Hands-on lab30 min

      Distributing sensor updates without an updater

      There is no auto-updater. Across one estate that is an inconvenience; across forty it is a process you have to design, own and measure. This lesson designs it.

      After this lesson you can

      • Design a sensor distribution process using your existing tooling, with a named owner and a target lag.
      • Measure current version spread across your portfolio.
      • Define the version-drift threshold at which you act, and what acting means.
      • State the risk you carry between a release and full rollout, in writing, to the customer.

      Exercise

      Measure your drift, then set a threshold

      You need

      • At least two tenants with sensors deployed

      Steps

      1. Produce the sensor version distribution for every tenant you operate.
      2. Identify the oldest version in your portfolio and how long it has been deployed.
      3. Design the distribution process, naming the tool and the owner.
      4. Set a drift threshold — a version count, or a time since release — and write down what happens when it is breached.
      5. Add version spread to your Monday review.

      How you know it worked

      A measured version distribution, a written process with an owner, and a threshold now checked weekly.

   2. Concept15 min

      Version drift as a portfolio metric

      Once you have the number, it becomes the most honest single indicator of how well your practice is actually running. It is also the number a prospective customer should ask you for.

      After this lesson you can

      • Interpret a version distribution as an operational health signal.
      • Explain what a long tail of old versions implies about the estate rather than about the tool.
      • Decide what you would tell a prospect who asked for this number.
   3. Hands-on lab30 min

      Offboarding, and what does not export

      A customer leaves, or moves to another provider. What can you give them, what stays behind, and what does the audit trail require you to preserve? Do this exercise once, calmly, rather than for the first time under notice.

      After this lesson you can

      • Produce a complete export for one tenant and enumerate what it contains.
      • Identify what does not export, and decide what to do about each item.
      • State your retention obligation for the audit trail after the relationship ends.
      • Write the offboarding procedure, including the access removal sequence.

      Exercise

      Offboard a test tenant properly

      You need

      • A test tenant with real history you can afford to close

      Steps

      1. Produce every export the platform offers for that tenant.
      2. List what a receiving provider would need and compare against what you have. The gap is the finding.
      3. Establish what happens to session recordings, vaulted secrets and the audit trail.
      4. Remove your own access last, and confirm from outside that it is gone.
      5. Write the procedure, with the access-removal sequence explicit — removing your access before the export is complete is the classic error.

      How you know it worked

      A written procedure, a completed export, and a gap list you would be willing to show a departing customer.

   4. Judgement25 min

      Taking over a tenant somebody else configured

      The reverse transition, and the more dangerous one. You now own a configuration you did not choose, and the customer believes it works. This lesson is a structured first-week audit that finds the three things previous providers most often get wrong.

      After this lesson you can

      • Run a structured first-week audit against your own baseline and produce a deviation list.
      • Identify the three highest-risk inherited misconfigurations: an over-broad zone allowance, an autonomy tier nobody documented, and a log source that stopped working without anybody noticing.
      • Decide what to change immediately and what to change with the customer's agreement.
      • Write the report you give the customer at the end of week one, including anything the previous provider did well.