In dit scenario beheert de cloudprovider de gehele beveiligingsketen. De data is weliswaar versleuteld op hun schijven, maar de provider heeft zelf de sleutel in handen om die data te ontsleutelen voor onderhoud of back-ups.

Het risico:  Omdat de provider de technische middelen heeft om de data leesbaar te maken, zijn ze onder de CLOUD Act wettelijk verplicht om de data ontsleuteld te overhandigen als de Amerikaanse overheid daar een bevel voor geeft. Dit vormt een hoog risico voor de soevereiniteit van je data.

Hierbij genereer je als organisatie zelf een sleutel en "leent" deze uit aan de cloudprovider zodat zij jouw applicaties kunnen draaien. Dit voelt veiliger, maar er zit een addertje onder het gras: de sleutel bevindt zich nog steeds in de infrastructuur van de provider om de data te kunnen verwerken.

Het risico: De provider heeft nog steeds functionele toegang. In een juridisch conflict kunnen zij gedwongen worden om de sleutel die in hun systeem draait te gebruiken om toegang te verschaffen. Het risico is daarom gemiddeld: je hebt meer controle, maar de juridische kwetsbaarheid blijft bestaan.

Dit is de enige methode waarbij de organisatie de sleutel volledig buiten de cloudomgeving houdt. De data wordt versleuteld vóórdat deze de eigen veilige omgeving verlaat en naar de cloud gaat. 

De cloudprovider krijgt alleen onleesbare "ruis" te zien en heeft nooit de beschikking over de sleutel.

Het risico: Dit scenario biedt een laag risico. Zelfs als de provider een dwangbevel krijgt, kunnen zij de data simpelweg niet ontsleutelen. Ze kunnen alleen een stapel versleutelde bestanden overhandigen waar de Amerikaanse diensten zonder jouw sleutel niets mee kunnen.