Explain Shared Security Responsibilities Without Calling the Product "Secure"

Here is a slide to avoid writing. It names your hosting provider, reproduces a strip of that provider's compliance badges, and ticks three boxes: infrastructure, platform, data. The room reads the checkmarks as reassurance.

The slide isn't false, exactly. It's a category error with good typography. A hosting provider's shared responsibility description is a boundary drawing. It says where that provider's work stops. It has nothing to say about the far side of the line, because the provider isn't standing there. Your team is, and so is your customer.

So the useful work a security slide can do is not to vouch for the arrangement. It is to allocate: this task belongs to the provider, this one to us, this one to you, this one to the signing service, and this one nobody has claimed yet. The last row is not an embarrassment. It is usually the most valuable sentence on the deck, because it names the conversation that has to happen before anyone signs.

Name the offered configuration in one sentence

Before you can assign work, you have to write down what you are actually selling. One sentence, in plain language, no marketing:

Alderpoint is a multi-tenant web application we operate on a general-purpose hosting provider's infrastructure; customer documents sit in a managed database in the region we select at setup; customers sign in through their own identity provider; approved packets are sent to a third-party signing service using a credential created inside the customer's workspace.

That sentence is invented, along with Alderpoint and everything else in this article's example. But the shape of it is the point. It names the parties, the storage, the region decision, the identity arrangement and the outbound integration. Everything downstream in the deck is an expansion of that sentence, and anything that doesn't fit inside it doesn't belong in the deck.

Two failure modes show up here.

The first is allocating work by service label. "Cloud" is not a task assignment. Neither is "SaaS." AWS's shared responsibility page, in the version on record checked 2 June 2026, draws the line between what AWS handles and what customers handle, and its examples make the split move with the service: a customer-managed guest system puts far more on the customer than a more abstracted service does. But even in the abstracted case, AWS still places responsibilities for data and permissions with the customer. The lesson you want from that is structural, not commercial — the partition changes with the model, so a label cannot allocate anything on its own.

That page is also a provider describing its own boundary. It is not independent assurance about any product, and it cannot tell you what a particular customer has configured. Borrow the shape of the reasoning, not the credibility.

The second failure mode is mixing models. Decks get assembled from a diagram for one service, a marketing page for another and a support article for a third. The result reads fluently and allocates nothing, because the rows came from different arrangements. Keep one configuration per slide. If you sell two, build two maps.

Turn obligations into tasks with owners and evidence

"Security" is not a task. Neither is "the platform." A task has a verb, an object and an end state. Disable the departing administrator's account at the customer's identity provider is a task. Manage user access is a heading that will be quietly ignored.

Start from the tasks that this buyer actually cares about: configuration, account administration, updates and patching, information handling, monitoring, and incident response where it applies. For each one, do three things — name the party, name the verb, and record why you believe the party owns it.

Four parties belong in the frame, and several decks only ever name two.

The hosting provider. Its rows are supported by its own documentation and service terms. You can cite those documents for the provider's side of the line. You cannot cite them for anything above the line.

The product team. Its rows are supported by its own process: who deploys, who reviews, who owns a dependency update, who is on call. The support here is a person who does the work agreeing that they do it, in writing.

The customer. Its rows are supported by what the customer's administrators can see and change in the product — role assignment, retention settings, which integrations are switched on — and by the customer's own change records.

External parties. A signing service, a payment processor, a support tool vendor. Each describes its own boundary in its own documentation. Don't fold them into "the cloud," and don't let your hosting provider's paperwork stand in for theirs.

One small editing rule catches a surprising number of problems: on your slide, every "we" should be a named party. Is that Alderpoint's application team, Alderpoint's support desk, the hosting provider, or the customer's own IT? Most ambiguous decks are ambiguous precisely at the seam, which is where the buyer's questions live.

And keep two claims apart on purpose. This party is expected to act is a statement about allocation. The work is being performed well is a statement about performance. The first is cheap to establish and the second is expensive, involves evidence you usually don't have, and is a different document. A named owner who has never heard of the row is not coverage. If you can't yet get someone to confirm a row, write "not yet confirmed" and leave it. That phrase is doing more for your credibility than a green square ever will.

Walk one ordinary event across the seam

Abstract maps survive contact with a buyer for about ninety seconds. What breaks the conversation open is a single everyday event, followed all the way across the boundary.

Take the invented case. Calder Mutual, a regional insurer, is a fictional customer that has been running Alderpoint for eight months. Calder's claim documents sit in a managed database on the hosting provider's infrastructure, in the region Alderpoint chose at setup. Calder's staff sign in through Calder's identity provider; Alderpoint stores no passwords. Approved packets are pushed to an external signing service using a credential created inside Calder's workspace. Two Calder employees hold the workspace-owner role, one of whom is the operations lead.

On a Friday, the other owner — the administrator who set the workspace up — leaves Calder.

Follow it.

Friday afternoon. Calder's IT disables the account at Calder's identity provider. The owner here is Calder, and the support is Calder's leaver process plus the change record. The effect is immediate for sign-in: the departing person can no longer authenticate.

The following week. The workspace still has one owner, so Calder can promote a successor without help. That row belongs to the customer too, and it is the ordinary case. The deck should also state the fallback, clearly labelled as a fallback: if the departing person had been the only owner, the customer could not restore owner access alone and the request would run through Alderpoint's support desk. Stating a conditional path is fine. The sin is stating a conditional as though it were the operating case.

Then the row that isn't there. The signing integration authenticates with a credential the departing administrator created about four months earlier. The current slide's row on that credential reads: the integration credential is managed by the workspace owner. True, and useless the moment the owner is gone. Nobody on the Alderpoint side has confirmed whether disabling an account also invalidates a credential that account created. The engineer who owns the signing integration is the person who could settle it, and they haven't been asked.

So the row stays open, and the presentation states both branches rather than picking one:

If the credential survives the account being disabled, a live credential remains in the hands of someone who no longer works at Calder, and it has to be rotated by somebody. If it doesn't survive, the integration is broken and the next approved packet fails to send, which is an availability problem rather than a security one, and it has to be fixed by somebody. Either way there is work, and the current map assigns that work to no one. That is not a hole in the presentation. That is the presentation finally doing its job.

Two more things this walkthrough exposes.

Identity is not hosting. Calder issued and revoked the account because the account comes from Calder's identity provider, even though the application runs on the hosting provider's infrastructure. "The host handles infrastructure" implies nothing about who creates and disables accounts. A diagram that merges identity into an infrastructure row is exactly how the original slide went wrong.

The signing service is a fourth party. It runs its own account administration and describes its own boundary. Its statements get cited to the signing service. They don't get absorbed into your row, and they certainly don't get inherited from your host.

Compress it without asserting the outcome

Now rebuild the slide. The original, as invented:

Security ✓ Infrastructure — provided by our hosting provider ✓ Platform — enterprise-grade, secure by design ✓ Data — encrypted and protected Backed by our hosting provider's certifications

Line by line. The first row moves Alderpoint's work and Calder's work into the hosting provider's column. The second is an outcome with no task behind it; "secure by design" doesn't tell a buyer who applies a dependency update or who decides whether to take one. "Encrypted and protected" conceals three separate questions — which data, who holds the keys, who can read it — behind an adjective. And the badges line puts a hosting provider's audit in the position of evidence about the application running above it. An audit covers the scope its own report defines. Whether that scope reaches anything you built is a question you settle by reading the scope section, not by placing the badge near your product name.

The replacement is a table with three columns and no checkmarks:

A checkmark next to a duty is a performance claim. If you want a status column, make the status honest: documented by the provider, confirmed by the owner, open. Those three words are defensible. A tick is not.

Keep the slide short and route the support behind it. The one-page map points to an appendix or a linked page with the full task list — the same way a spec points to its appendix. Simplification is fine; dropping the support is what turns a clear slide into an unbounded one.

Then have the owners read the rows, not the person who wrote the deck. The deployment engineer confirms the deployment row. Whoever holds the on-call rotation confirms anything about notification timing. A customer-side administrator confirms the rows the customer holds. When an owner disagrees with a row, that disagreement is the review working, and it belongs in the next version rather than in a private note.

Finally, keep four questions apart:

• Allocation — who is expected to do what. The map answers this one.
• Adequacy — whether that split is good enough for this buyer's risk. A different argument, with different evidence.
• Performance — whether the work is happening. A different document again, and not one a sales deck can produce.
• Compliance — against a named framework, in a named scope, on a named date. Not a synonym for the other three.

The word secure is a stand-in for the last three, all at once, about the whole arrangement. That's why it doesn't belong on the slide. The map was never able to produce it, and putting the word there only invites the room to assume someone did.

Leave the open row visible

A finished responsibility slide for Alderpoint ends with one row that still has no owner. That row is the deliverable. It tells Calder exactly what will be true when an administrator leaves, which question has to be answered before go-live, and which party has to answer it.

You can ship the deck with the row visible. What you can't ship is a checkmark in its place, because the checkmark answers a question — is this whole arrangement secure? — that a responsibility map cannot reach, and that nobody in the room can settle from a slide. The supported division of work, plus the one handoff still waiting for a name, is a stronger close than any badge strip, and it's the only version that survives the meeting.

Frequently asked questions

Why can't a hosting provider's shared responsibility description carry a product security slide?

It is a boundary drawing: it says where that provider's work stops. It has nothing to say about the far side of the line, where your team and your customer are. It is also a provider describing its own boundary, so it is not independent assurance about your product, and it cannot tell you what a particular customer has configured.

What should a shared responsibility slide actually allocate?

Tasks with a verb, an object and an end state, assigned among the hosting provider, the product team, the customer and external parties such as a signing service. Each row needs a named party, what they do and the evidence behind the claim. Allocating by service label—cloud or SaaS—does not assign anything. On the slide, every 'we' should be a named party.

What is the difference between allocation, adequacy, performance and compliance?

Allocation is who is expected to do what; the map answers that. Adequacy is whether that split is good enough for this buyer's risk, which is a different argument with different evidence. Performance is whether the work is happening, a different document again. Compliance is against a named framework, in a named scope, on a named date. The word secure is a stand-in for the last three at once, which is why it does not belong on the slide.

How does the departing-administrator scenario show the value of an open row?

Calder disables the departing administrator's account at its identity provider, and because one workspace owner remains, Calder can promote a successor without help. But the signing integration uses a credential the departing administrator created, and nobody has confirmed whether disabling the account invalidates it. If the credential survives, it remains in the hands of someone who no longer works at Calder and must be rotated; if it does not, the integration breaks and the next approved packet fails. Either way there is work, and the current map assigns it to no one.

What should replace a slide full of checkmarks?

A table with tasks, who performs them and how you know, without checkmarks. Statuses can be honest—documented by the provider, confirmed by the owner, open—because a checkmark next to a duty is a performance claim, which is not the same as allocation. Keep the slide short and route the full task list behind it. Have the owners read the rows they own; when an owner disagrees, that belongs in the next version.

Further reading

• Explain an AI Product’s Data Path in a Buyer Presentation — Use this when the slide must also show where customer data goes: one recognised workflow, marked entry, processing, storage and human access, with unresolved points stated plainly.
• Show the Work a Customer Must Do to Adopt the Product — Read this to fill the customer's rows honestly: it separates supplier setup from customer decisions, access grants and named exception owners, and orders work behind the controlling dependency.
• Show What the Product Actually Does—and Label the Rest — Read this before the slide's rows become screenshots: it says what each image actually establishes and how to write a claim those facts can carry.