A cloud security managed service inserts a third party into an arrangement that already has two, you and your platforms, and the resulting three-party structure is worth mapping precisely, because incidents fall through the seams between parties more than through any party's failures. The platform holds the infrastructure keys: physical security, hypervisors, the service's own code. The managed service holds watching keys: admin or read access to your tenants, the alert queues, the response runbooks. And you hold the sovereign keys that neither can safely hold for you: the ownership of the tenant, the break-glass admin, the decisions about who may access what, and the payment authority that fraud actually targets. This guide maps the keys, the four seams where three-party arrangements actually fail, and the handoff documents that stitch the seams shut.
The key map, party by party
Platform keys are invisible and non-negotiable, you inherit their quality by choosing the platform. Service keys deserve enumeration in the contract: which roles in which tenants, named staff or a service account, logged how, and, critically, less than everything, a monitoring service needs read and security-admin scopes, not billing ownership or the ability to delete the tenant. Your sovereign keys need writing down precisely because they are few: tenant ownership and its recovery codes, one break-glass admin the service cannot revoke, the authority to grant access, and the authority to move money. A service that asks for a sovereign key has misunderstood the arrangement, or intends to.
The four seams where it fails
Seam one: alert-to-action, the service detects, but who acts, on which classes of event, is unwritten, and the alert ages in a queue. Seam two: platform-change-to-baseline, the platform ships a new setting, nobody owns evaluating it, and the baseline silently stops covering reality. Seam three: personnel, your leaver's access is removed from your systems but not from the service's contact list, or vice versa, and authority drifts. Seam four: incident authority, at 2am the service can contain but the sovereign decisions, pay, notify, shut down, have no named holder awake. Each seam is closed by one named owner and one written line, which is cheaper than any product.
The handoff documents
Three short documents stitch the arrangement. The authority matrix: for each event class, detected takeover, destructive action, fraud attempt, who acts, who decides, who is told, with after-hours names. The access schedule: every key the service holds, reviewed quarterly alongside your own access reviews. And the exit sheet: how service keys are revoked, watching transferred and evidence handed over. All three live naturally inside the set the free sheet on this site counts, the incident procedure carries the matrix, the access policy carries the schedule and the sovereign key list, and Hardenvo Pro generates them from your answers with review dates, so the three-party arrangement is a documented machine rather than an assumed one.
Questions people ask about cloud security managed service
What access should a cloud security managed service hold?
Watching keys only: read and security-admin scopes in named tenants, logged, enumerated in the contract. Never sovereign keys: tenant ownership, the break-glass admin, access-granting authority and payment authority stay with you.
Where do three-party cloud security arrangements fail?
At the seams: unowned alert-to-action handoffs, platform changes nobody re-baselines, personnel changes that miss one party's lists, and 2am incidents where sovereign decisions have no awake owner. Named owners and written lines close all four.
What documents should govern the arrangement?
An authority matrix per event class with after-hours names, an access schedule of every key the service holds (reviewed quarterly), and an exit sheet for revocation and handover. All three belong inside your written policy set.