Explain Deployment Choices Without Treating “Cloud” as a Trust Rating

A deck that offers “Cloud” and “Private” is not offering two deployments. It is offering two words and asking the customer to choose between them. Underneath those words sit at least four separate decisions: where each component runs, who operates it, how people and other systems reach it, and who carries the work when something has to change. A label can be entirely accurate and still leave all four unanswered.

The fix is unglamorous. Ask the product owner which configurations are actually for sale, describe each one across those four dimensions, then walk one ordinary change through each. Do that and the slide stops implying something the architecture cannot deliver. It also stops implying that a word on a label is a verdict about how safe the thing is.

Start with what is actually on offer

Before you write a single cell, ask what a customer can sign for today and what name appears on the order form. Not the roadmap, not the pilot someone ran for one account, not the thing the engineering team could assemble if a large enough customer asked. The purchasable configurations.

Then mark the rest honestly. If a third option is planned for next quarter, it can appear on the slide with a date and a label that says it is not available yet. That is more useful than omitting it and more honest than presenting it as a choice. A buyer who discovers later that the option they liked was a proposal will re-read everything else you said with suspicion.

The most common failure at this stage is not a lie. It is a mix. Someone writes a slide that combines the customer's own data center from one configuration, the vendor's maintenance window from another, and the vendor's public API endpoint from a third. Occasionally that combination exists somewhere. Often it is a configuration nobody has built, described with the most attractive property of each available option. Get the combinations from the product owner in writing, one line per option, and keep them intact.

You will also be tempted to open with a vocabulary catalogue: infrastructure as a service, platform as a service, public, private, hybrid, virtual private, dedicated. That sequence teaches nothing about what you sell, and it invites the reader to sort the words into a hierarchy. Skip it unless a term is about to appear in a configuration you are actually describing.

Four questions a label hides

Take each offered configuration and answer these separately. They do not travel together.

Where do the components run? Not “where does the data live,” which is only part of it, and often the part with the least interesting answer. Ask about the application servers, the database, the backups, the logs, and whatever support tooling the vendor uses to see into a customer's instance. A single configuration can place four of those in one building and the fifth somewhere else.

Who operates it? NIST's Computer Security Resource Center glossary defines private cloud so that the infrastructure may be managed by the organization, a third party, or some combination of the two, and may sit on the organization's premises or elsewhere. That is a definition about terminology, and it is enough to show the word “private” deciding neither the operator nor the location. Two configurations can both be legitimately called private and assign completely different work.

How is it reached? Users are one path; other systems are another. A product can be fine for people signing in from anywhere and awkward for an integration that lives outside the customer's network. The reverse also happens.

Who handles change? Who decides that an update happens, who applies it, who is on the hook when it goes wrong, and who confirms afterward that the customer's actual work still works.

Four independent questions, so four ways to be wrong. A managed service and a self-operated instance do not divide the same labor; they divide it differently. And none of the four is a security assessment. The location of a server is a fact about a building. Whether the controls around that server are adequate for a particular customer's risk is a judgment someone has to make, with evidence, in a document that is not this slide. Keeping those two conversations apart is the whole point.

Follow one ordinary change through both options

Here is where the comparison becomes useful. The example below is invented for teaching. Aldergrove is a fictional vendor, Halden is a fictional customer, and nothing here was built, tested, or observed.

Aldergrove offers two configurations. The first is sold as “Cloud”: Aldergrove's managed tenant. The second is sold as “Private”: an installation on Halden's own servers. Both sit in the same colocation facility in the same city — Aldergrove's racks and Halden's racks are two rows apart, in the same building, under the same jurisdiction. What differs is who runs them.

The label-only version of this slide says:

Cloud — fast to start, no infrastructure, always up to date. Private — maximum control, runs in your environment, your data stays yours.

Every phrase there is doing work it cannot support. “Always up to date” describes a maintenance policy, not a hosting location. “Your data stays yours” describes a data-handling commitment, and on this slide it is doing the job of an assurance. Swap it for the update journey instead: release 4.3 is out, and both configurations need it.

Under the Cloud configuration. Aldergrove picks the window and tells Halden's IT contact beforehand. Halden does not approve the date. Aldergrove's operations team applies the release to its own tenant and tests it in the vendor's own staging environment first. When it is done, Aldergrove confirms the service is up. Halden's team still has to check that the reports it depends on and the work-order integration still behave — the vendor can confirm the service, not the customer's workflow.

Under the Private configuration. Halden's change advisory board sets the date; Aldergrove publishes release notes and a supported upgrade path and does not choose the window. Halden's infrastructure team provides the environment and the credentials, and because it wants to test before applying, it maintains a second instance for that purpose — ongoing work, not a one-time task. Aldergrove support has no standing access; if support needs to look at the installation, Halden arranges access first. Halden's team applies the release and coordinates through its own change process. Afterward, Halden's team confirms the service is up, and Halden's users confirm their reports.

The last step is the customer's in both cases. That is the finding. What moves is who carries the first three: who holds the calendar, who provides access, and who does the work.

Notice what this comparison does not say. It does not say one route is easier. It shows a trade. In the managed arrangement, the customer's network team accepts that its users and its work-order integration call a vendor endpoint reachable over the public internet; in exchange, field users take no extra step. In the private arrangement, traffic stays on the customer's network and there is no vendor-operated path into it, but the customer must decide whether to admit an inbound path from the third-party ticketing SaaS — still unresolved — and every field user picks up the VPN step. Both are plain descriptions of the arrangements. Neither is a security grade, and if you find yourself writing one, you have wandered into the conversation that needs a different owner and different evidence.

Leave the empty cell empty

The label-only slide had two bullets. The corrected version is a table with the four dimensions as rows, plus one row for the customer's ongoing work. Here is Aldergrove and Halden's:

The unresolved row is the point of the exercise, so it is worth explaining carefully. Halden's ticketing service is a SaaS product hosted by a different vendor, outside Halden's network. It is supposed to open a ticket when a report is flagged. Under the Cloud configuration, it just calls the published API. Under the Private configuration, there is no published API to call, and Halden's network security team has not decided whether an inbound path from a third-party SaaS is acceptable or what such a path would look like. So the cell says unresolved, with names and a date: Halden's network security lead and Aldergrove's integration lead, before the pilot review.

The discipline here is refusing to borrow. The Cloud column has an answer for that cell, and it is a perfectly good answer for the Cloud column. Putting it in the Private column because the row looks empty is how a comparison slide turns into a promise nobody can keep. The same rule applies to any dimension you cannot get confirmed. “Unresolved” with an owner and a date is a stronger slide than a confident guess, because the customer can act on the first one.

Beneath the table, put the task pathway — the update journey from the previous section, compressed:

1. Decide. Cloud: Aldergrove sets the window. Private: Halden's change board sets it.
2. Prepare. Cloud: Aldergrove stages and tests. Private: Halden stages and tests.
3. Apply. Cloud: Aldergrove's team. Private: Halden's team.
4. Confirm. Both: the customer checks the reports and integrations it actually depends on.

Four lines, and a buyer can see where their people appear in the picture. That is what the slide is for.

Two pieces of housekeeping before it ships. Check every cell with the technical owner of that configuration, and link each cell to the current description it simplifies, so a reader who wants the detail can find it. And keep architectural assessment and control assurance out of the table entirely. The table answers what the arrangements are. It does not answer whether an arrangement is adequate, which is a separate question with a separate owner.

What the reader should be able to do

The test of the finished slide is not whether it sounds reassuring. It is whether a reader can tell the two configurations apart without translating either label into good or bad. If someone finishes the slide knowing that both options sit in the same building, that one of them hands the maintenance calendar to the vendor, that the other hands the field users a VPN step, and that one integration path is still an open question with a name attached to it — they can make a decision. If they finish thinking that “Private” means safer, you have handed them a feeling instead of a comparison, and the feeling will not survive their first conversation with their own security team.

Same building, two rows apart, two completely different working arrangements. That is the whole lesson in one image, and it is why the location column is the least interesting row in the table.

Frequently asked questions

Why isn't offering “Cloud” and “Private” the same as offering two deployments?

It offers two words, not two fully described arrangements. Underneath them sit at least four separate decisions: where each component runs, who operates it, how people and other systems reach it, and who carries the work when something must change. A label can be accurate and still leave all four unanswered.

What four questions should each configuration answer?

Where do the components run; who operates it; how is it reached by users and by other systems; and who handles change — who decides, applies, is accountable when it goes wrong, and confirms the customer's actual work still works. These do not travel together.

In the Aldergrove and Halden example, what differs if both options sit in the same facility?

The working arrangements differ even though the location is shared. Cloud is Aldergrove's managed tenant, with Aldergrove scheduling and applying updates; Private is an installation on Halden's servers, with Halden's change board and team controlling updates, access, testing, and support access. The same building, two rows apart, can still mean different calendars, access paths, and customer work per release.

What should a comparison table do when a dimension cannot be confirmed?

Leave the cell unresolved, with a named owner and a date. Do not borrow the answer from the other column just because the row looks empty. “Unresolved” with an owner and date is stronger than a confident guess because the customer can act on it.

Does this comparison establish that one option is safer?

No. The table describes arrangements, not adequacy. The location of a server is a fact about a building; whether controls around it are adequate for a particular customer's risk is a separate judgment requiring evidence and a different owner. Neither route is a security grade.

Further reading

• Explain What Happens When One Part of the Product Becomes Unavailable — After the change journey, use this to answer the buyer's follow-up about one supporting service going down, with observed, documented, and proposed labels kept apart.
• Show What the Product Actually Does—and Label the Rest — Use this when one slide may mix a working feature, a configured setup, and an unbuilt design; it labels what each image establishes.