Skip to content

You *can* take it with you: musing about cloud principles

Photo courtesy of @psd. Paul, I owe you one.

There was a time when the “high street” bank was a disconnected silo, an island of tranquillity. Except when it came to a busy afternoon and you wanted to withdraw money. Your money. Because the only place you could withdraw it from was the branch with which you held your account. If you weren’t near it, tough. If it was too busy to serve you, tough.

There was a time when the only way you could draw money from a hole in the wall was to use your bank’s ATM network. It was private. Disconnected from all other bank networks. So if you weren’t near an ATM belonging to the bank you banked with, tough.

There was a time when you could only use the cards you had in the country you lived in. If you had to travel anywhere else, tough. Try cash or travellers’ cheques.

There was a time when there were no guarantees for what happened if someone impersonated you, if your cards were stolen, or, for that matter, your bank had a problem.  No guarantee schemes. No nothing.

Thankfully, we’ve moved on from those times. Today we can choose who to bank with, draw money from any branch, any ATM, anywhere, anytime. Securely, efficiently, conveniently. Underpinned by the trust that comes from feeling secure, having guarantees.

And because of all this, we trust our banks with some of our most precious assets. The financial system has had its problems (which system hasn’t?). But people continue to use banks rather than revert to paper money and metal hidden under mattresses.

So it is with the cloud. Your data is a precious asset. Which means that you really have to think about where you keep it, whom you trust to look after it.

The “bank” where you keep your data must use a network that provides you access anywhere in the world; it must support a large variety of “data ATMs”, your mobile devices. It must provide you access swiftly and securely. It must have transparent pricing and charging. If there are legal reasons why someone else seeks to look into your “account” it must tell you about it.

The cloud, like the banking system, like any truly global system, is about openness and standards and transparency and trust and guarantees.

Which is why I’m delighted with what my employer Salesforce is doing, in putting forward a series of “cloud principles”, principles we work by, principles we seek to adhere to. This is something the company has been working on for a while now. Incidentally, where relevant, my posts also appear on

Here they are, ten guiding principles, in draft form:

  • Transparency: Companies that provide enterprise cloud computing platforms should explain their information handling practices and disclose the performance and reliability of their services on their public Web sites.
  • Use Limitation: Companies that provide enterprise cloud computing platforms should claim no ownership rights in customer data and should use customer data only as their customers instruct them, or to fulfil their contractual or legal obligations.
  • Disclosure: Companies that provide enterprise cloud computing platforms should disclose customer data only if required to do so by the customer or by law, and should provide affected customers prior notice of any legally compelled disclosure to the extent permissible by law.
  • Security Management System: Companies that provide enterprise cloud computing platforms should maintain a robust security management system that is based on an internationally accepted security framework (such as ISO 27002) to protect customer data.
  • Customer Security Features: Companies that provide enterprise cloud computing platforms should provide their customers with a selection of security features to implement in their usage of the cloud computing services.
  • Data Location: Companies that provide enterprise cloud computing platforms should make available to their customers a list of countries in which their customer data related to them is hosted.
  • Breach Notification: Companies that provide enterprise cloud computing platforms should notify customers of known security breaches that affect the confidentiality or integrity of their customer data promptly.
  • Audit: Companies that provide enterprise cloud computing platforms should use third-party auditors to ensure compliance with their security management system and with these principles.
  • Data Portability: Companies that provide enterprise cloud computing platforms should make available to customers their respective customer data in an industry-standard, downloadable format.
  • Accountability: Companies that provide enterprise cloud computing platforms should work with their customers to designate appropriate roles for privacy and security accountability.

As I said, these are in draft form right now. Comments welcome. Our intention is to publish them in a more accessible form soon, and to make it possible for you to participate more fully in shaping them and improving them. Watch this space for details.

Posted in Cloud.

67 Responses

Stay in touch with the conversation, subscribe to the RSS feed for comments on this post.

  1. Anish says

    Hi JP,
    As usual u have nailed it on its head. You have indirectly pointed out a few things which are key to getting cloud working as true “cloud” sense. As an end user u could ignore what flavor of cloud the applications are running. Now about a few points which I have had first hand experience as security architect for a platform on the cloud (with my previous employer) which used multiple cloud providers including Salesforce, I really appreciate your comments on transparency, security managment , Audit , Breach notification and Accountability. But I am afraid I havent seen any cloud service providers providing these 6 months back . I beleive one of the things that is missing is the fact that SLA’s dont reflect any of the above attributes and the ability of customer to monitor a large set of these criteria is very limited.
    BTW “use limitation” implies tying together data to policies, it is very hard to achieve ;) my two pence.

  2. Dominic Sayers says

    Two quick points about disclosure:

    (1) You might want to make it clear if there is a difference between customer data and a customer’s data. In other words, will you disclose data about a customer (IP addresses, financials, etc.) under circumstances where you wouldn’t give access to the data the customer had chosen to store in your systems.

    (2) There is often some discretion in what constitutes a legal requirement. Some UK ISPs have said they would challenge in court any attempt under the Digital Economy Act to compel them to hand over details of their customer’s internet usage. Another UK telco, on the other hand, has a policy of allowing wiretaps on the say-so of a relatively junior police officer when it could insist on a court order. It might help to be clear about the extent to which Salesforce would resist “legally compelled disclosure”.


  3. JP says

    @anish @dom thanks. good points, the whole reason for putting this forward in this shape was to figure out how to make the principles better. keep the comments coming.

  4. James Richards says

    Hi JP, I found the post very helpful in helping me order my thinking about the cloud – 1) transparency 2) integrity 3) authority 4) security 5) utility 6) availability 7) stability 8) clarity 9) portability & 10) accountability

  5. John Dodds says

    Excellent framework JP. Two areas of potential clarification occur to me on first reading.

    In terms of disclosure, I wonder if there should be an obligation on cloud service providers to inform/educate users in what circumstances they might be required by law to disclose their customers’ data.

    In respect of the audit principle, might there be an argument for specifying what sort of penalties might be incurred if the auditors find shortcomings?

  6. alan p says

    JP – taking your example, I would argue that the banking system differs from the cloud in that it doesn’t need to be “always on” – the cash in your wallet works even when the system is not around.

    Ditto the Cloud. It needs to have the ability to allow continual operation of systems when they are not connected. Having worked with Clouds (and ASPS, Web Hosting Systems, Grids etc etc) over 15 odd years the 2 things I know for sure are that:

    – Getting “5 Nines” reliability is bl**dy hard in real time networked services, and even “5 nines” means dropping the ball a few times a year.

    – Murphy’s Law predicts that the f*ck-up will occur at the least good time, in the worst place.

    Thus, I would add the Principle of Resilience, (or whatever word works best) that ensures that the system can be run for a period of time for core services while disconnected.

  7. Aswath Rao says

    I am not sure whether this is already covered or is it of the same stature. But I feel openness of Access control is something is important. The wording could be something like:

    Access control: Companies that provide enterprise cloud computing platforms should allow access to people who may not have credentials issued by the provider.

    To be more specific, I am thinking of use of OpenID/OAuth for authenticating “external” users before they are given access to the data they are entitled to. This will facilitate federation between two customers who may use platforms from different companies.

  8. Ric says

    JP – my response is on the blog: … got a bit long :)

  9. Jim Worth says

    Excellent points and well overdue. Too many immature cloud service providers ignore the importance of the 3rd Party Audit assurance to a corporate customer. Just within the last year, one widely used provider answered the question: “What assurance can you give that my data is secure?” by saying “If your data ever got out, we would surely be out of business”. Not the answer I was looking to hear.

  10. Julien Le Nestour says

    Hi JP, 2 short points from my days in Corporate IT Innovation ;-)

    1 – Financial transparency and disclosures: I would add this item, as too many times, especially for smallish and growth companies, the main risk is actually non-orderly bankruptcy, or change of ownership impacting the commercial relationship on strategic levels. Even for companies like Salesforce, I believe a greater amount of financial and accounting disclosure would be needed, something that can be done under NDA for large clients only if that’s required.

    2 – “Disclosure: […] should provide affected customers prior notice of any legally compelled disclosure to the extent permissible by law.“ Here I would of course love to see that the cloud services provider will pursue all legal means to obtain the right to disclose any law enforcement request, even if not permitted at first; ie, act as Twitter in the recent wikileaks subpoenas, not comply to a sealed request unless all avenues to unseal it have been exhausted.

    These are my 2 cents, and thanks for your insightful posts as always ;-)

  11. JP says

    @John both clarifications make sense, but I don’t know how easy they are to achieve. Let’s see what the rest of the comments say, we can review again

  12. JP says

    @Alan the resilience principle makes sense as well, though it will have to be bounded and shaped for any one organisation to be able to commit to it.

  13. JP says

    @swath committing to the use of third party credentials is an interesting one. Why do you feel so strongly about it? Or is the issue to do with “standard” credentials?

  14. JP says

    @ric wow I need to digest that and reply later, thanks.
    @Jim :-) I have seen something similar
    @Julian again this makes sense, but the devil is in the details. I am keen to keep the principles as simple as possible

    Keep the comments coming

  15. Richard Booth says

    JP, great post and a lot of good points about cloud. I must admit as an RSA / EMC employee, the topic you raise is somewhat close to my heart.

    One thing I am always conscious of is that for many existing companies the adoption of cloud services / platform / infrastructure is not an overnight transformation. Getting to the cloud and a place where the principles you listed are all in effect will be a journey. A journey of discovery for most, but also a journey of innovation for many.

    I did like your bank analogy, if only cloud service providers (in various guises and contexts) had a “switching” service like many banks do, how simple life could become in adopting cloud.

  16. Julien Le Nestour says


    Granted, the fin. disclosure may be too much for your set of principles.

    BUT the addition to the disclosure point can be worked in without really adding complexity. In my view, it would make it credible. Right now, when reading it, I can’t shake the inference: “to the extent permissible by law” means every sealed requests will be complied with diligently by my provider without me being aware of it.

    A proposed phrasing (just so that I can feel I’m not just providing negative comments ;-) ):

    Disclosure: Companies that provide enterprise cloud computing platforms should disclose customer data only if required to do so by the customer or by law, and should provide affected customers prior notice of any legally compelled disclosure except if such right has been denied by all legal authorities able to grant it.

  17. Rajnesh Singh says

    Good start to building the set of principles, JP. And pretty much in agreement with what I have been saying (including at the Summer Davos in Tianjin last year). Two points I would like to put forward (but whether they are/should be part of the “principles” is open to discussion): first is the issue of system availability (and related to that availability from geographically dispersed locations in the case of a multi-national using the service) – system availability is a key component to user confidence in the cloud, the second is the notion of inter-cloud computing – can your cloud talk to another cloud service and exchange information, where the second cloud service may be a different vendor but serving the same customer as the first. Once we sort out and standardise the norms for inter-cloud data exchange, I think we are heading for even more interesting times.

  18. Chris Swan says


    I think regulatory shopping will be at least as important with where we put our data as it has been with where we put our money.

    This means that you need to go further with ‘data location’ – the customer doesn’t just want to know where their data might land, you need to empower them to specify where it will be held (assuming that there is some array of choices). This has clear links back to ‘disclosure’, particularly when the conversation turns to ‘permissible by law’ and what that means in practice (e.g. US national security letters [NSLs]) – the customer needs to have choice over which legal framework(s) apply to their data.

    I would say that audit could go further too. Don’t just allow 3rd parties in – provide the API so that customers can audit what you’re doing with their data themselves. This is what CloudAudit ( is all about, and it would be great to see Salesforce getting involved in that initiative. ‘Trust and verify’ is a common cry of infosec experts – why not make ‘verify’ just another part of the service?

  19. Aswath Rao says

    It is not because of standard, but what that standard entails is very amenable to cloud based service: As a customer of a cloud service, I could provide access to you, my cloud provider does not have to have any prior relationship with your id provider to enforce the accessibility rules. Furthermore, your access privilege is determined in a “cloudy” fashion by your status with your Id provider (your employer for example).

    The standardized procedure is very amenable to cloud based services. This is the reason for my strong advocacy of OpenID/OAuth.

  20. DavidE says

    One aspect to add to the Data Portability principle. I should be able to make a clean exit; as well as gettinga copy of all my instance data I should be able to delete all of it AND if required all of my meta data (name, company, etc)

  21. DavidE says

    A more tricky problem involves anonymous activity. Mosts service companies think nothing of amalgamating anonymized data for promotional reasons. For instance, how many companies use their service, and how much data is being transmitted per hour.

    For most clients, this is no issue. But some companies will correctly worry that this can be a security peep hole. If I see that your service is suddenly handling more data, I can correlate this with a new customer who I believe might have joined. Then I can make further assumptions about that company. Possibly they are starting a new campaign?

    To avoid this, a company must be able to ask for exclusion from promotional statistics. But I can still imagine that a lot of potential clients will be worried about “Enigma” type inferences that can be deduced from noisy service companies.

  22. Tom Hughes says

    The analogy to banking is spot-on, but cloud providers might not want to be regulated the way banks are. I wonder if one day we’ll have “deposit insurance” for cloud data and applications?

    Also like banks, the cloud-computing industry has a principal/agent problem: that is, my “agent” (the cloud provider) and I suffer very different outcomes if my data is lost or my privacy is violated. The provider merely loses a customer, whereas I have potentially lost everything. This principal/agent dilemma is why we have industries like bond rating agencies, as well as state regulation of banks and insurance companies.

  23. Michel Burger says

    Love the principles and reflect very well the concerns and requirement we start to have on cloud service providers.

    On data location not only the list of countries should be provided but mechanism should be provided to either implicitity of explicitily geo-distribute the data and a clear differentiation should be made between master data and cached data.

    right to opt out: data analytics is crucial for cloud services providers but it should be possible as a customer to opt out on any analytics generated either on the data or even on the usage of the data. This should also include what France calls “le droit a l’oubli” which I should be able to select on any data: direct or inferred…

    And like other people who gave comments, I am very much in support of openid/oauth support by the cloud service provider.

  24. JP says

    @richard yes, portability and interoperability will become more and more important. agree with the journey bit, but we need to be careful about the time taken. firms have to keep pace with their competition, if the competition moves faster on to cloud and gets the lower operating costs and faster time to market, you’re dead.

  25. JP says

    @julien, some of the conversations I’m having suggest something even further, that there is a duty of care on behalf of the customer to resist legal disclosure rather than just roll over; this is above and beyond the “keep the customer informed” aspect

  26. JP says

    @rajnesh transparent publishing of systems availability is an absolute must. the inter-cloud aspects will happen (as long as we are only talking public cloud, there is no other cloud in practice, just marketing) but it will take time to get the inter-cloud service implications and guarantees right

  27. JP says

    @chris where, for regulatory purposes or for low latency a specific geography is mandated, location may need to be customer-specified; but it cannot be the norm otherwise we are throwing away the economic value of multitenant. I am foreseeing a different model, where the customer indicates where he does •not• want the data to be held, leaving providers to select beyond the constraint. I will take a look at cloudaudit, thanks

  28. JP says

    @aswath fair point, I will bring it into our discussions here

  29. JP says

    @davide the eject button will evolve over time. phase 1: you can take it with you. phase 2: and leave no trace behind. phase 3: parcelled for re-entry anywhere

  30. JP says

    this false anonymisation issue is known for some time, and is not really a function of cloud. it is a function of anonymisation design weaknesses. in the old days HR departments needed to be careful not to create cost or profit centres with just one or two people, because salaries could be deduced quite easily from the summary data. the answer was to understand the granularity of the data and ensure that the bucket size of anonymised aggregates was suitable.

  31. JP says

    @tom the principal-agent problem is exacerbated in situations where the only asset is data, so we need to extend the asset base into processes and on to apps and beyond. when principal and agent start sharing up the stack we can reduce the asymmetry. need to think about how best to design this.

  32. JP says

    @michel thanks, the issues on distribution of data as well as federation of access tools need to be worked on as you say

  33. Aswath Rao says

    JP @davide: If clean erase is postponed to Phase 2, then care must be taken that the data architecture doesn’t foreclose that option. For example Facebook has stated that it can not guarantee that a picture is totally removed because they themselves do not know where else that picture is stored.

  34. Sandeep Raithatha says

    Great blog post, I like the ATM analogy and I think the 10 principles can help highlight “False Cloud” which I see more and more.

    The Data Location principle could be extended to providing a choice of where the customer data is stored which is often an issue or barrier for adoption when customer data has to be stored in a particular geographic location for local regulatory requirements.

    Also a principle on collaboration would be interesting as more and more customer move to the cloud the requirement to share selected data with each other in various applications on cloud computing platforms would be needed.

  35. Chris Swan says


    There should probably be 3 choices for location:

    1. My data must be kept here (e.g. Switzerland, for regulatory purposes).
    2. My data must not be kept there (e.g. US because I fear NSLs).
    3. I don’t care where my data is kept.

    Clearly there would be premiums associated with 1&2 that would offset any difficulties with capacity management for multi tenancy (which shouldn’t be THAT hard, but Salesforce is perhaps an extreme case of what can be accomplished in this area).

    Just as with banking I’d expect that some locations/regulatory regimes would be more popular than others, which would also ease the multitenant problem.

    Do you have any feel for the minimum size of a multitenant infrastructure, and the customer base that would be needed to make it viable?

    Obviously the don’t cares provide some flexibility for load balancing, but that may not be all that dynamic (given large data sets relative to small bandwidth). There will also be softer versions of option 1 (e.g. my data must stay in the EU).

    Something else to bear in mind here is public sector (Gcloud) initiatives. They pretty much all want to be option 1, but services built for .gov users could be scaled out to suit the needs of commercial users in the same locale.

  36. Dominic Sayers says

    For anybody else who doesn’t immediately know what an NSL is, here’s what I managed to find:

    Is this right, Chris? Or did you mean National Skydiving League?

  37. Jonathan says

    For some organizations in the FS industry, they will want to know what USA state their data is held in. This is particulalry important if there is even the remotest possibility of litigation, whereby the litigator attempts to go directly to Salesforce to obtain the data.

  38. Reza Mohsin says


    Clearly very welcome, and not just as contractual assurances, but in establishing a trust between the cloud services provider and its customers that transcends the specifics of terms and conditions.

    Although legal commitments and their minutiae that protect both salesforce and its customers are important, more important will be a recognition by us customers that at the helm of the company, and permeated in its rank and file there is a recognition of those values and principles that guide specific policy. (As a side note, but maybe ever so slightly relevant to this topic of trust and dialogue, the 40 odd comments on confusedofcalcutta and their quality contrasts with the two on cloudblog of the same entry. Maybe its just traffic, or maybe worthwhile to contrast the “here’s a daft – need feedback – genuinely listening” tone of this post with others on cloudblog. I hope I’m not getting you or me into too much trouble :) )

    But back to your principles.

    One theme that stood out for me across them is the proactive stance that several of them imply. A proactive stance that goes beyond the minimum that is legally mandated. Maybe that translates back into company’s committed full time resources and even right up to a senior executive officer in the firm whose day job is to excel and improve on the implementation of these principles. That’s probably covered in your Accountability principle. And it looks like several comments are requesting a stronger wording of that proactive stance in the principles as you’ve stated them – Chris S. on providings APIs for customers to audit themselves, Julien on stiff resistance to disclosure requests, etc.

    Frankly, I think its hard to enhance your proposed set, but the one thing I wanted to put my weight behind was what Rajnesh also picked up on: inter-operability, not just availability of APIs which a cloud provider has to provide anyways to link back with enterprise applications, but as a principle that no barriers will be erected on customers being able to procure, let’s say, cloud infrastructure from Amazon and link it with Sales Cloud. It is after all the strongest point in your bank analogy – the inter-operability of ATMs across banks and countries, but it doesn’t find expression in the principles. Especially in an industry where the major players are renowned for their constant desire to create lock-in, or unfair competitive advantage, this would be a good addition.

    A comment on the phasing response (“the eject button will evolve …”), I am assuming you are not proposing that only those things can be included in the principles that are already implemented today – but this is a set of principles that govern direction, maybe mapping to a maturity model against which to report compliance.

    Again, very welcome! Thanks.

  39. JP says

    Fair point. Something we all have to work on. Nobody can guarantee things that are technically impossible. But we can design things in such a way that there are fewer such problems

  40. JP says

    You’re right, Sandeep. Ecosystems will develop with common principles allowing data sharing between apps from different sources. Already happening

  41. JP says

    @jonathan one of the earlier comments asked for three choices: (a) must be in jurisdiction x (b) must not be in jurisdiction y and (c) don’t care. there are some european companies who want none of their data in the US. we will see this whole thing evolve; not sure it will go in a good direction. data-driven protectionism is already showing its ugly face.

  42. JP says

    @reza the key word is trust. and trust is based on a number of things: transparency, unilateral commitment to published principles, a demonstrable willingness to work out answers where none existed before. the cloud is a new way of doing business. so we need the new answers. hence the principles. which will get better as a result of all your comments.

  43. Jim Nicolson says

    Thank you for creating this set of principles.

    I had come across the post on while I was doing research as part of developing my own set of principles. It is a pity I didn’t follow back to your personal site because the quality of the comments was excellent. (I just found it when rechecking my notes)

    For what it’s worth, my set is here []. They are a kind of synthesis from NIST, US/UK/AU Government Cloud Strategy documents and various blog articles including your post on Principles.

    My focus was really from a Cloud Service Consumer perspective. It was also oriented towards the generalized Cloud Service Model (in NIST terms). In particular, this means it’s not just ‘data’ that needs to be protected, managed etc it’s all assets (software, scripts, configuration and so on)

    Regardless, just some observations, most have been made in some form or other already:

    . There is a very gray ethical area relating to the use of knowledge inferred by analytics. E.g. Without any negative implication intended, companies like Amazon or Google specialize in, and have a business model that heavily exploits, the analytics of customers’ behavior which could equally be applied to Cloud Consumer assets and traffic without going anywhere near their ‘data’. What is inferred, what is disclosed/acceptable to the consumer, and how it should be used is an issue that should be the subject of a principle.

    . I think an explicit principle concerning Availability and Disaster Recovery/Business Continuity is required. Personally, I see this as a major vulnerability, the most difficult to resolve, and the most likely to inhibit Government adoption (in the Public Cloud sense).

    . A related principle is one dealing with the need for an explicit contract/SLA between the Cloud Service Provider and the Cloud Service Consumer.

    . Perhaps, principles involving the Location aspects should be pitched in Sovereign Jurisdiction terms to capture the broadness of the issues for assets that may be simultaneously covered by the regulatory and legal requirements of multiple sovereign jurisdictions.

    Thanks again…

  44. JP says

    thanks for your comments Jim, I will address them when I come to edit the principles in a few weeks.

  45. Joe says

    Your example (corporate banking) to illustrate the need for cloud computing principles for enterprise computing is ridiculous.
    Can you seriously imagine a multi billion dollar a year bank trusting its very existence to a ten/twenty million dollar a year infrastructure provider.
    Once core banking services are stored externally they then have the problem of security. You require the service provider to delineate between internal and external traffic whilst at the same time as the internal walls of the company are being broken by the demands of workers to have corporate (intranet style) access from outside of the normal security walls of the organisation.
    Security which is already a nightmare to administer and maintain will become so unmanageable that the firewalls will be all but useless.
    Ultimately core functionality (the very life blood of a large corporation) will be kept very close to a companies chest as they realise that corporate self destruction is an inevitablity if they do not sufficiently safeguard their future.
    I have seen many fads come and go and many evolutionary steps that have been popular one minute, and less so the next. Policy shifts such as Downsizing, RightSizing, UpSizing, Outsourcing, Insourcing and Off-shoring. All that cloud computing is in essence is a rekindling of the old 1970’s Burea services just as XML is an rekindling of EDI. But every generation has to re-invent the World in its’ own image and Cloud Computing is just another step in this generations development whilst trying to ignore the legacy it inherits simply because it’s not sexy anymore.

  46. JP says

    @joe I think you’ve misinterpreted what I’ve said. I am not using corporate banking as an example anywhere; instead, I’m using •retail• banking as an •analogy• for trust, safety, access, deposits and withdrawals, drawing parallels between banks and cloud service providers in this context.

    And by the way banks •do• use cloud services. They have been doing for a while. And will continue to do so. But that’s a separate point.

  47. JS says

    Hi JP,

    I read with great interest the cloud concept. One of the crucial milestone for a buy in from a medium size organisation would be to ensure how secure my date is and on what grounds can the service provider can break into.

    a comparable example could be:
    In many countries there storage yards where people keep their spare belongings or store stuff as temporary storage.

    when we rent a storage yard it is like us renting a house. The caretaker has a spare key to our storage unit but will not
    1. open or enter in himself unless to protect the belongings from some fire or flood damage etc.
    2. security of the unit and the adjoining area is the responsibility of caretaking organisation.
    3. as with entering an house a law enforcement agencies cannot enter into a storage unit unless a court search warrant is issued and presented to the storage provider and then also storagee provider will open only if the tenant is not contactable.

    If the companies get a similar assurance from the providers and from the governments (in from of some legislation) in those countries where the servers are hosted, organisation then would feel more confident in handing over their data to them.

  48. Naman Sagar says

    Cloud Services are just a step forward for bright future..

Continuing the Discussion

  1. Tweets that mention You *can* take it with you: musing about cloud principles – confused of calcutta -- linked to this post on January 23, 2011

    […] This post was mentioned on Twitter by Steve Gillmor, rossdawson and JP Rangaswami, Ric Hayman. Ric Hayman said: Draft cloud principles from Salesforce: /via @jobsworth /cc @saasu @marclehmann […]

  2. Making a start on cloud principles at achurch & associates linked to this post on January 24, 2011

    […] JP now has a more specific interest in Cloud, and it was evidenced in his recent post “You *can* take it with you: musing about cloud principles” where ten principles for cloud computing providers were posited, as a draft which it seems […]

  3. Cloud principles – a good start from AccMan linked to this post on January 24, 2011

    […] these are transparency and security. Earlier today JP Rangaswami, chief scientist set out a set of draft guiding principles as […]

  4. Médias liquides, presque gazeux » Metamedia | La révolution de l'information linked to this post on January 24, 2011

    […] peu comme quand nous pouvons désormais obtenir du cash (du liquide ) dans les tous les distributeurs du monde […]

  5. Cloud transparency & sanctity of your data | ZDNet linked to this post on January 25, 2011

    […] now sport JP Rangaswami the former British Telecom chief scientist among their ranks, and he has published a draft Cloud manifesto of ten guiding principles, making a compelling case for the virtues of […]

  6. Cloud transparency & sanctity of your data | Constellation Research linked to this post on January 26, 2011

    […] now sport JP Rangaswami the former British Telecom chief scientist among their ranks, and he has published a draft Cloud manifesto of ten guiding principles, making a compelling case for the virtues of […]

  7. Cloud computing (still) needs a bill of rights | ZDNet linked to this post on February 1, 2011

    […] scientist JP Rangaswami had posted some thoughts last week on work at the vendor to define a set of ten guiding principles for cloud computing. He writes that “this is something the company has been working on for a […]

  8. Cloud computing (still) needs a bill of rights linked to this post on February 1, 2011

    […] scientist JP Rangaswami had posted some thoughts last week on work at the vendor to define a set of ten guiding principles for cloud computing. He writes that “this is something the company has been working on for a […]

  9. 10 Guiding Principles of Cloud Computing « In(tegrate) the Clouds linked to this post on February 3, 2011

    […] post originally appeared on his popular blog and has generated 46 comments so far. My favorite so far is this […]

  10. You *Can* Take it With You – Musings About the Cloud [23Jan11] | The Book linked to this post on March 5, 2011

    […] You *Can* Take it With You – Musings About the Cloud [23Jan11] Posted on January 24, 2011 by admin Clipped from […]

  11. Cloud computing linked to this post on March 18, 2011

    […] Rangaswami at, meanwhile, calls for the adoption of 10 simple principles for cloud service providers – ranging from data portability and transparency to security breach […]

  12. High rise linked to this post on March 18, 2011

    […] Rangaswami at, meanwhile, calls for the adoption of 10 simple principles for cloud service providers – ranging from data portability and transparency to security breach […]

  13. Cloud computing | News linked to this post on March 18, 2011

    […] Rangaswami at, meanwhile, calls for the adoption of 10 simple principles for cloud service providers – ranging from data portability and transparency to security breach […]

  14. Cloud computing: How to get your business ready | @IT. Blog for IT, Web, Software. linked to this post on March 19, 2011

    […] Rangaswami at, meanwhile, calls for the adoption of 10 simple principles for cloud service providers – ranging from data portability and transparency to security breach […]

  15. Cloud computing | Internet Stock Traders linked to this post on March 20, 2011

    […] Rangaswami at, meanwhile, calls for the adoption of 10 simple principles for cloud service providers – ranging from data portability and transparency to security breach […]

  16. Cloud computing: How to get your business ready | Wayne Levin's Noticeboard linked to this post on April 25, 2011

    […] Rangaswami at, meanwhile, calls for the adoption of10 simple principles for cloud service providers – ranging from data portability and transparency to security breach […]

  17. Principper for cloud leverandører? linked to this post on September 21, 2011

    […] at JP fremlagde de 10 principper fik han en hel del interessant feedback på sin blog. Dette indlæg blev udgivet i Leverandører, Public Cloud, og tagget cloud […]

  18. - linked to this post on January 20, 2013

    […] Rangaswami at, meanwhile, calls for the adoption of 10 simple principles for cloud service providers – ranging from data portability and transparency to security breach […]

Some HTML is OK

or, reply to this post via trackback.

%d bloggers like this: