A managed cloud security service engagement begins, or should, with a scoping exercise the buyer can do before any call: an inventory of what cloud you actually run. Small organisations consistently under-count, remembering the mail platform and forgetting the accounting system, the payroll provider, the booking tool, the e-signature service, the marketing platform with the customer list in it, and the personal-account cloud drives where work quietly lives. The service can only watch what the scope names, and the gap between cloud-you-run and cloud-in-scope is where incidents happen while reports stay green. This guide walks the inventory that sets the scope, the two cloud categories most engagements omit, and the single sentence to demand in any contract, the coverage sentence, that keeps the scope honest as your stack grows.
The inventory that sets the scope
List every service where organisational data lives or organisational credentials sign in: the platforms (mail, files, chat), the business systems (accounting, payroll, CRM, booking, invoicing), the operational tools (e-signature, forms, scheduling, design), and the infrastructure if any (hosting, domains, DNS registrars, the website's admin). For each: what data it holds, who the admin is, whether multi-factor authentication is enforced, and whether it is in the engagement's scope. The exercise takes an evening, surfaces the forgotten admin accounts on the day it is done, and converts the provider conversation from their checklist to your estate.
The two categories engagements omit
First, the business systems that are not the mail platform: quotes default to the big platform because tooling exists for it, while the payroll service and the CRM, holding the most sensitive data you have, sit outside scope with their own unwatched logins. Ask directly which named systems the identity monitoring and posture checks actually cover. Second, the edges of ownership: the domain registrar and DNS accounts, whose compromise redirects everything; and the personal-cloud shadow, work files in private drives, which no service can watch and only the data handling policy can address, by naming where work may live. Both categories belong in the scoping conversation even where the answer is a written exclusion.
The coverage sentence, and the paper around it
Demand one sentence in the contract: the services in scope are listed in Schedule A, reviewed quarterly, and additions to our stack are added to scope by the review, not by renegotiation. That sentence makes scope a living list rather than a signing-day snapshot, and the quarterly review it forces is where the new tool someone adopted in March gets its factors enforced by June. Around the engagement, your own documents carry the intentions: the data handling policy names where work may live, the access policy names admin and factor rules for every system on the inventory. The free sheet counts both into your set; Hardenvo Pro generates them, and the inventory you built becomes an appendix both you and the provider maintain.
Questions people ask about managed cloud security service
How do I scope a managed cloud security service?
Inventory first: every service holding organisational data or credentials, platforms, business systems, operational tools, infrastructure edges, with data, admin, factor status and in-scope noted per row. The engagement can only watch what the scope names.
What do cloud security engagements usually miss?
The business systems beyond the mail platform (payroll, CRM, accounting, holding the most sensitive data), and the ownership edges: domain registrar and DNS accounts, plus the personal-drive shadow only a data handling policy can address.
What contract term keeps the scope honest?
A living-scope sentence: in-scope services listed in a schedule, reviewed quarterly, with stack additions joining by review rather than renegotiation. Your inventory becomes the schedule, maintained on both sides.