The Cloud Is Just Someone Else’s Computer, Plus Your Configuration Mistakes

It is also not entirely fair.

Cloud services are genuinely useful. SaaS platforms have made a lot of things easier. Nobody sensible is longing for the golden age of running everything under a desk, next to a fan heater, with “DO NOT TURN OFF” written on a Post-it note.

The cloud can be more resilient, more scalable, and easier to manage than traditional infrastructure.

But here is the important bit:

moving something to the cloud does not move all the responsibility away.

It changes the responsibility.

And if nobody understands that, the cloud becomes less of a strategic platform and more of a very expensive place to store assumptions.

The shared responsibility problem

Cloud providers love talking about shared responsibility.

Which is fair enough. It is an important concept.

But in practice, “shared responsibility” is often misunderstood as:

“The supplier handles it.”

They do not.

The provider may handle the platform, infrastructure, physical security, resilience of their service, and various technical controls depending on what kind of service it is.

But the organisation still usually owns things like:

• user access
• administrator roles
• configuration
• data sharing settings
• external access
• retention settings
• integrations
• third-party apps
• licensing decisions
• user behaviour
• incident response
• business continuity decisions

In other words, the provider supplies the house.

You still decide who gets keys, which windows are open, whether the back door is propped open with a brick, and whether the family jewels are sitting on the kitchen table.

SaaS is still part of the estate

One of the strangest habits organisations have is treating SaaS as if it is somehow not really IT.

A server in a rack? Definitely IT.
A laptop? IT.
A firewall? IT.
A cloud platform containing documents, customer data, workflows, permissions, integrations, and business-critical processes? Somehow “the department sorted that one themselves”.

No.

SaaS is part of the IT estate.

If a service stores organisational data, supports a business process, manages identity, integrates with core systems, or affects operational continuity, then it needs governance.

It does not matter that it lives in a browser.

A risky configuration is still risky with rounded corners and a monthly subscription.

Where cloud risk actually appears

Cloud risk does not usually appear as dramatic lightning from the sky.

It appears in settings.

Small, ordinary, deeply consequential settings.

1. Access control

Who has access?

Who approved it?
Who reviews it?
Who removes it when someone leaves?
Who has admin rights?
Are suppliers included?
Are guest users still needed?

Cloud platforms make access easy. That is one of their strengths.

It is also one of their risks.

If access is easy to grant and hard to review, permissions multiply like rabbits with SSO.

2. Administrator roles

Cloud admin roles can be extremely powerful.

A global admin, tenant admin, security admin, billing admin, application admin, or platform owner may have access that affects large parts of the organisation.

Those roles need:

• named ownership
• MFA
• review
• separation from daily activity where appropriate
• logging
• clear justification

Nobody should be carrying broad cloud admin rights because “they might need it one day”.

That is not a role assignment. That is a horoscope.

3. External sharing

Cloud collaboration tools make sharing beautifully easy.

Too easy, sometimes.

A document can be shared externally.
A folder can be opened to a supplier.
A link can be created.
A guest account can be invited.
A workspace can slowly become a borderless information swamp.

External sharing is not bad. It is often necessary.

But it needs rules, ownership, review, and visibility.

Otherwise, nobody knows where data has gone until someone asks a question that begins with “why can they still access…”

4. Third-party app integrations

This one is spicy.

A user connects an app.
The app asks for permissions.
The user clicks approve.
The app now has access to mail, files, calendars, contacts, or other data.

Sometimes this is legitimate.

Sometimes the app is asking for permissions with the subtlety of a raccoon in a kitchen cupboard.

Third-party integrations need review because they can become data access paths outside normal visibility.

The fact that something integrates neatly does not mean it should be trusted automatically.

5. Retention and deletion

Cloud platforms often provide retention settings, deletion rules, archive options, legal hold features, and recovery windows.

But someone has to configure them.

If nobody owns retention decisions, data may be:

• kept longer than needed
• deleted sooner than expected
• unrecoverable after a short window
• retained inconsistently across services

This matters for compliance, legal, operational, and recovery reasons.

6. Backup assumptions

This is a big one.

People often assume that because a service is in the cloud, it is “backed up”.

That assumption needs checking.

Cloud providers usually provide platform resilience. That does not necessarily mean the organisation has the same recovery options it would want after:

• accidental deletion
• malicious deletion
• ransomware
• account compromise
• misconfiguration
• retention expiry
• business process failure

There is a difference between provider availability and organisational recoverability.

If that sounds familiar, it is because Article 12 brought a clipboard.

The cloud can be secure and still be badly configured

This is the point worth landing.

A cloud platform can be secure by design, well-funded, professionally managed, and still be risky in your environment because of how it is configured.

Microsoft 365 can be excellent and still have:

• too many admins
• weak sharing controls
• stale guest users
• poor retention settings
• excessive third-party app permissions
• unmanaged mailbox rules
• inconsistent MFA enforcement
• weak ownership of Teams and SharePoint sites

A CRM can be excellent and still expose too much data.

A file-sharing platform can be excellent and still be used badly.

A password manager can be excellent and still need proper vault structure, ownership, access review, and offboarding.

Good platforms do not eliminate governance.

They make governance more important, because more of the business runs through them.

Warning signs your cloud governance is mostly vibes

You may have a cloud governance problem if:

• nobody has a complete list of cloud services in use
• departments can buy SaaS without review
• admin roles are assigned because someone shouted
• guest users are rarely reviewed
• external sharing is not monitored
• nobody knows which third-party apps have access
• retention settings are assumed rather than checked
• SaaS ownership is unclear
• offboarding does not reliably remove access from all platforms
• backup and recovery expectations are vague
• the phrase “the supplier handles that” is doing too much work

That last one deserves attention.

Sometimes the supplier does handle it.

Sometimes the supplier handles something adjacent, while the organisation quietly keeps the actual risk.

What good cloud governance looks like

Good cloud governance does not need to be huge.

It needs to be deliberate.

1. Know what services are in use

Maintain a register of cloud and SaaS services.

Include:

• service name
• owner
• business purpose
• data held
• users
• admin roles
• supplier contact
• renewal date
• recovery / continuity expectations

If nobody knows a service exists, nobody is governing it.

2. Define ownership

Every cloud service needs a business owner and a technical owner where appropriate.

The business owner understands the process and risk.

The technical owner understands configuration, access, integration, and support.

Without ownership, cloud services become floating islands of subscription-funded mystery.

3. Control access

Access should follow the same principles as any other system:

• named users
• MFA
• least privilege
• regular review
• prompt removal when no longer needed
• stronger controls for administrators

Cloud does not make access governance optional.

It makes it more urgent.

4. Review external sharing and guests

External access should be visible and intentional.

Guests, shared links, supplier accounts, and external workspaces should be reviewed.

If external sharing is business-critical, govern it.

If it is accidental, fix it.

5. Review app integrations

Third-party app permissions should be reviewed before approval where possible.

High-risk permissions need scrutiny.

Apps that are no longer used should be removed.

If an app can read mail, files, users, or business data, it is not “just a plugin”.

6. Define recovery expectations

For each important cloud service, know:

• what the provider protects
• what the organisation must configure
• what can be restored
• how quickly
• by whom
• with what limitations

This prevents cloud recovery becoming a surprise party nobody wanted.

7. Monitor and review

Governance is not a one-time setup.

Cloud platforms change. Users change. Suppliers change. Features change. Risks change.

Settings that were sensible last year may be inadequate now.

That is why periodic review matters.

How to improve cloud governance without becoming the Department of No

The risk with cloud governance is overcorrection.

A business team uses an unapproved SaaS tool, and IT responds by attempting to turn every future request into a procurement pilgrimage.

That will not work.

People will just hide things better.

Instead:

Step 1: Make the approved route clear

If someone needs a new tool, where do they go?

What information is needed?

Who reviews it?

How long should it take?

If the route is not clear, Shadow IT will provide one.

Step 2: Use a lightweight risk assessment

Not every SaaS tool needs the same review.

A low-risk internal whiteboard tool is not the same as a platform storing customer data or integrating with Microsoft 365.

Match the review to the risk.

Step 3: Offer approved alternatives

Sometimes Shadow IT exists because people do not know there is already an approved tool.

Publish what is available.

Make it findable.

Make it usable.

Step 4: Focus on data and access

When assessing cloud tools, ask:

• what data goes in?
• who can access it?
• where is it stored?
• how is access removed?
• what integrations are requested?
• what happens when we stop using it?

Those questions catch most of the important issues.

Step 5: Build review into lifecycle

Cloud governance should cover:

• request
• approval
• onboarding
• access review
• renewal
• change
• offboarding
• retirement

Otherwise, services get adopted with enthusiasm and abandoned with invoices.

The role of policy

This is where a Cloud Service Provider Management Policy earns its keep.

It should define:

• how cloud services are requested
• who approves them
• how risk is assessed
• what access controls are expected
• how data handling is reviewed
• how third-party app integrations are controlled
• how services are monitored, reviewed, and retired

That is not bureaucracy.

That is the organisation recognising that cloud services are now part of how the business operates.

Final thought

The cloud is not the enemy.

Bad assumptions are.

Cloud services can be secure, resilient, and commercially valuable. But they still need ownership, configuration, access control, monitoring, recovery planning, and review.

The provider may run the platform.

But the organisation still owns the data, the users, the access decisions, the configuration choices, and the business impact when something goes wrong.

So yes, the cloud is someone else’s computer.

But the mistakes can still be entirely yours.