What Is Cloud Data Security? Protecting Data on Microsoft 365, SaaS, AWS, Azure and Google Cloud

Cloud Data Security is the security approach that ensures that the corporate data created, stored, processed and shared in cloud environments is protected against risks such as unauthorized access, data leakage, misconfiguration, account takeover, malicious internal users, uncontrolled sharing and data loss. Cloud Data Security, expressed in Turkish as bulut veri güvenliği, does not mean only enabling encryption on cloud storage. It requires many security layers such as data discovery, data classification, identity and access management, DLP, DSPM, cloud security posture, sharing controls, encryption, logging and incident response to work together.

The place where corporate data is located has changed considerably in recent years. While in the past a large part of the critical data was located in the file servers, databases and applications in the organization's own data centre, today the same data can move between Microsoft 365, SharePoint, OneDrive, Teams, SaaS applications, AWS, Microsoft Azure, Google Cloud and a large number of third-party platforms.

An Excel file can be created on the company computer in the morning, can be uploaded to OneDrive a few minutes later, can be shared over Teams, can then be transferred to a SaaS application and finally can be added to the prompt of an AI application.

For this reason in modern data security the physical or logical network perimeter is no longer sufficient on its own.

The real security boundary is becoming the data itself.

The fundamental question of Cloud Data Security is for this reason:

"On which cloud platform is our data?"

much wider than this question.

The organization must at the same time know the answers to these questions:

Which sensitive data is located in the cloud environments?

Who can access this data?

With whom is it shared?

Is there public access?

Can external users access it?

Is the data encrypted?

Which user downloaded the data?

Which SaaS application accesses the data?

Can AI applications use this data?

Are uncontrolled copies of the data located in other cloud environments?

If these questions cannot be answered the organization can be using the cloud but does not have sufficient visibility in terms of cloud data security.

What Is Cloud Data Security?

Cloud Data Security is the whole of the policies, processes and technologies aimed at the protection of the data located in IaaS, PaaS and SaaS environments throughout its whole lifecycle.

The aim is not only to prevent attackers accessing the data.

Cloud Data Security at the same time tries to manage risks such as sharings made by mistake, more user authorizations than necessary, public storage configurations, unmanaged SaaS use, forgotten data copies and Shadow Data.

For this reason modern Cloud Data Security must answer three fundamental questions:

Where is the data?

Who can access it?

What is being done with the data?

These three questions being answered together forms the foundation of cloud data visibility.

Are Cloud Security and Cloud Data Security the Same Thing?

No.

Cloud Security is a wider concept.

Inside the cloud infrastructure:

Network Security

Workload Security

IAM

Container Security

Cloud Configuration

API Security

it can cover areas such as these.

Cloud Data Security, on the other hand, focuses especially on the data.

For example a cloud storage resource may have been configured technically correctly but if millions of pieces of personal data are being kept inside it unnecessarily the Data Security problem continues.

Cloud Security:

"Is the resource secure?"

while it asks this question Cloud Data Security in addition to this:

"Which data is inside the resource and is it safe for this data to be located here?"

asks this question.

This distinction is important in terms of understanding the modern cloud security architecture.

The Shared Responsibility Model and Data Security

One of the most important concepts on the subject of cloud security is the Shared Responsibility Model, that is the shared responsibility model.

The cloud provider can be responsible for the physical infrastructure, the underlying platform and certain security controls.

However, the customer their own:

Data

Identity

Permissions

Configurations

Applications

Security Policies

continues to carry important responsibility over these.

The cloud provider's infrastructure being secure does not mean that the customer data is automatically secure.

For example if a user makes sensitive storage public by mistake a data breach can occur without the provider infrastructure being compromised.

Is the Biggest Risk in the Cloud Always a Hacker?

No.

Cloud Data Security incidents are not created only because of external attackers.

Some of the very common risks:

Misconfiguration

Excessive Permissions

Public Sharing

Stolen Credentials

Unmanaged SaaS

Shadow Data

Human Error

Third-Party Access

Insider Threat

can be these.

For example an employee can create "Anyone with the link" sharing for a Confidential document.

In this case a sophisticated cyber attack may not be necessary.

A single wrong sharing configuration can create data exposure.

What Is a Cloud Misconfiguration?

A Cloud Misconfiguration is a cloud resource being configured in a wrong or risky way in terms of security.

For example:

Public Storage

Overly Permissive IAM

Unencrypted Database

Open Network Access

Anonymous Sharing

situations such as these can be evaluated as a misconfiguration.

Because cloud environments are very dynamic these configurations can change continuously.

For this reason only an annual audit may not be sufficient.

The Public Cloud Storage Risk

Cloud storage can be made accessible over the internet by mistake.

If there is sensitive data inside the storage this can create a critical exposure.

For this reason the security team not only:

"Is the storage public?"

this question but:

"Which data is located inside the public storage?"

must ask this question too.

Marketing images being located inside public storage and customer personal data being located there are not the same risk.

Why Is Data Context Important?

Cloud security findings can be prioritized wrongly without data context.

For example two storage resources can be public.

The first contains public website images.

The second contains a customer database export.

Although the configuration finding looks the same the business risk is completely different.

DSPM for this reason is becoming important inside Cloud Data Security.

Microsoft 365 Data Security

Microsoft 365 has become one of the biggest unstructured data repositories in many organizations.

E-mail,

Word,

Excel,

PowerPoint,

Teams messages,

SharePoint documents,

OneDrive files

can host a very large amount of corporate data.

For this reason Microsoft 365 must be evaluated not only as a collaboration platform but at the same time as a critical Data Security environment.

Where Can Sensitive Data Be Located in Microsoft 365?

Sensitive information can be located inside different services.

For example:

Exchange Online → E-mails

SharePoint Online → Corporate Documents

OneDrive → Personal Work Files

Teams → Messages and Shared Files

Office Documents → Embedded Sensitive Data

For this reason applying only e-mail DLP is not sufficient.

Data protection must cover the whole collaboration ecosystem.

SharePoint Data Security

SharePoint is a strong platform for document collaboration.

However, the permissions can become complex over time.

Site permissions,

folder permissions,

file permissions,

sharing links,

guest users

when these come together understanding the effective access can become difficult.

For this reason the important question of SharePoint security:

"Who can really access which sensitive document?"

must be this.

SharePoint Permission Creep

As an employee works inside different projects and departments SharePoint sites accesses can accumulate.

If the access is not removed after the project finishes Permission Creep can be created.

Over the years the user can become able to access hundreds of sites.

For this reason a periodic access review is important.

OneDrive Data Security

Because OneDrive is user-centred cloud storage it can host a large amount of corporate data.

An employee:

a customer list,

a contract,

a financial spreadsheet,

source code,

personal data

can store documents such as these.

For this reason OneDrive must not be seen only as a personal workspace.

It must be taken into the scope of corporate Data Governance.

The OneDrive External Sharing Risk

A user can create an external sharing link for a document.

This can be necessary for legitimate collaboration.

However, the link can stay open for a long time.

For this reason external links:

Owner

Creation Date

Expiry

Data Classification

Guest Identity

must be evaluated with these.

Why Is "Anyone with the Link" Risky?

Anonymous sharing links can weaken identity-based access control.

The link can be forwarded to other people.

For this reason for Confidential or Restricted documents anonymous links can be limited.

Classification-aware sharing policies are important here.

Microsoft Teams Data Security

Teams is not only a messaging platform.

The files shared over Teams can mostly be stored in the SharePoint or OneDrive infrastructure.

For this reason Teams Data Security is actually:

Identity

Sharing

SharePoint

OneDrive

DLP

Retention

the combination of controls such as these.

Data Leakage over Teams

A user can share a sensitive document inside a Teams conversation where an external participant is present.

This can be accidental data leakage.

A DLP policy can take action according to the data classification and the recipient context.

For example when a Restricted document is sent to an external user a block or a warning can be applied.

Microsoft Purview and the Data Security Approach

In the Microsoft ecosystem controls such as data classification, information protection, DLP, audit and governance can be handled centrally over solutions such as Microsoft Purview.

However, technology is not sufficient on its own.

First:

Data Classification Model

Data Owners

Protection Policies

Exception Process

Incident Response

must be defined.

The tool is the technical application layer of this governance model.

What Is SaaS Data Security?

SaaS Data Security expresses the protection of the data located inside the Software-as-a-Service applications the organization uses.

For example an organization:

CRM

HR SaaS

Project Management

File Sharing

Marketing Platform

Support Platform

can use these.

Every SaaS application creates a new data repository.

This also widens the Data Security attack surface.

What Is SaaS Sprawl?

SaaS Sprawl is too many SaaS applications starting to be used inside the organization in an uncontrolled way.

A department can buy a new SaaS without IT knowing.

Employees can use free cloud tools.

As a result sensitive data can spread to dozens of external services.

This creates a visibility problem.

What Is Shadow SaaS?

SaaS applications that have not been officially approved by the security or IT team can be thought of as Shadow SaaS.

For example an employee can upload a corporate document to a free online converter.

This application may not have passed a security assessment.

The data retention policy may not be known.

For this reason Shadow SaaS is an important risk in terms of Data Security.

The Difference Between Shadow IT and Shadow Data

Shadow IT expresses the use of technology or applications not managed by the organization.

Shadow Data, on the other hand, expresses data copies or repositories the security or governance team is not aware of.

A Shadow SaaS application can create Shadow Data.

However, forgotten storage inside an approved cloud platform can be Shadow Data too.

For this reason the two concepts are related but are not the same.

OAuth Access to SaaS Applications

Modern SaaS applications can connect to other cloud platforms over OAuth.

For example a third-party application:

Read Mail

Read Files

Access Contacts

can request these permissions.

When the user gives permission the application can obtain continuous access to corporate data.

For this reason OAuth application governance has become critical for Cloud Data Security.

Risky OAuth Applications

An attacker can create a malicious application and request permissions from the user.

If the user gives consent data access can be provided without the password being stolen.

This can be evaluated as OAuth consent phishing.

For this reason:

Application Permissions

Publisher Trust

Requested Scopes

Consent Activity

must be monitored.

SaaS-to-SaaS Data Movement

Data is not carried only by the user.

One SaaS application can transfer data to another SaaS application over an API.

For example CRM → Marketing Platform.

This machine-to-machine data flow must be in the inventory.

Otherwise the organization cannot know exactly where its data goes.

What Is CASB?

CASB, that is Cloud Access Security Broker, is the solution category that supports the security controls between users and cloud services.

CASB:

Cloud Application Visibility

DLP

Access Control

Shadow IT Discovery

Threat Protection

can be used in use cases such as these.

CASB has become an important cloud security control especially in the periods when SaaS adoption accelerated.

The Relationship Between CASB and DLP

DLP detects sensitive data and applies a movement policy.

CASB provides the cloud applications context.

For example:

Confidential Data

Upload to Unsanctioned SaaS

=

Block.

This is the cloud-aware DLP approach.

Inline CASB and API-Based CASB

CASB can use different architectures.

The inline approach can inspect user traffic real-time.

The API-based approach can scan the stored data inside the cloud application.

These two approaches provide different visibility.

Some environments can use the two together.

What Is Cloud DLP?

Cloud DLP is the Data Loss Prevention approach that aims to control the movement of sensitive data inside cloud services or between cloud services.

For example:

Personal Data uploaded to public cloud

Confidential document shared externally

Restricted file downloaded to unmanaged device

events such as these can be taken into the policy scope.

Why Is DLP More Difficult in the Cloud?

In on-premise environments data flows can be more predictable.

In the cloud, on the other hand, data:

Browser

Mobile App

API

Sync Client

SaaS Integration

AI Application

can move over these.

For this reason the enforcement points diversify.

Modern DLP must be cloud-aware.

AWS Cloud Data Security

In AWS environments data can be located inside different services.

Object Storage

Managed Databases

Data Warehouses

Block Storage

Backups

Logs

Secrets

there are many data repositories such as these.

The Cloud Data Security programme must create the inventory of these repositories.

Object Storage Security

Object storage can host a large amount of structured and unstructured data.

The risks:

Public Access

Overly Broad IAM

Unencrypted Objects

Old Backups

Unknown Data

Cross-Account Sharing

can be these.

Data Discovery can carry out a sensitive information scan on object storage.

Cloud Bucket Exposure

A "public bucket" is one of the best known risks of cloud security.

However, modern security does not consist only of a public/private binary check.

For example a bucket may not be public but:

10,000 internal identities

or:

multiple external accounts

may be able to access it.

This can create excessive exposure too.

Azure Data Security

In Microsoft Azure environments storage, databases, analytics services and application platforms can create different sensitive data repositories.

Azure Data Security not only resource configuration but:

Identity

RBAC

Encryption

Network Access

Data Classification

Monitoring

requires layers such as these to be evaluated together.

Azure RBAC and Data Access

Azure RBAC provides access control to cloud resources.

However, broad roles can create excessive permissions.

A user must not receive a broad administrative role only to see a storage list.

Least Privilege must be applied.

Cloud permissions must be reviewed regularly.

Google Cloud Data Security

In Google Cloud environments too object storage, managed databases, analytics platforms and data processing services can host sensitive data.

The fundamental security principles are independent of the provider:

Know Your Data.

Know Your Identities.

Control Access.

Encrypt Data.

Monitor Usage.

Reduce Exposure.

Multi-Cloud Data Security

Many organizations do not use only a single cloud provider.

AWS,

Azure,

Google Cloud,

Microsoft 365,

and different SaaS platforms can be used at the same time.

In this case Data Security visibility can be fragmented.

Every platform has its own dashboard.

However, what the organization needs is not provider-centric but data-centric visibility.

Multi-Cloud Data Visibility

The Security Team can want to answer this question centrally:

"Where is Restricted data inside all the cloud environments?"

The answer to this question can be difficult with only provider configuration tools.

DSPM for this reason has gained importance in multi-cloud environments.

What Is DSPM and Why Is It Important in Cloud Data Security?

DSPM, that is Data Security Posture Management, is the security approach that focuses on discovering sensitive data inside cloud and data environments, classifying it, analyzing the access exposure and relating risky configurations with data context.

DSPM tries to answer these questions:

Which sensitive data is where?

Who can access it?

Is there public exposure?

Is there encryption?

Are there unused copies?

Has the data been copied to other environments?

For this reason DSPM is one of the important visibility layers of modern Cloud Data Security.

The Difference Between DSPM and CSPM

CSPM focuses on the cloud infrastructure configuration posture.

DSPM focuses on the data posture.

For example CSPM:

Storage Public.

DSPM:

Storage contains 250,000 Restricted Personal Records and is Public.

The second finding expresses the business risk more clearly.

For this reason CSPM and DSPM are complementary.

Data Security with CNAPP

CNAPP can approach the infrastructure and workload security of cloud-native applications from a wide perspective.

DSPM, on the other hand, provides data context.

For example the amount of sensitive data a vulnerable cloud workload can access can change the risk priority.

For this reason in the future workload security and data security can be expected to combine more.

Cloud IAM and Data Security

In cloud environments identity is most of the time seen as the new security perimeter.

When a user or a service account receives a permission to a cloud resource they can gain data access.

For this reason Cloud IAM is the fundamental layer of Data Security.

Excessive Cloud Permissions

Cloud IAM policies can widen over time.

Developers can receive temporary permissions.

After the project finishes the permissions may not be removed.

This creates Permission Creep.

CIEM or access governance processes can help to reduce excessive entitlements.

CIEM and Cloud Data Security

CIEM analyzes the permissions and entitlements of cloud identities.

DSPM analyzes the sensitive data.

The two approaches together:

Which identity can access which sensitive data?

help to answer this question.

This provides strong context for Data Access Governance.

Human and Machine Identity

Not only employees access cloud data.

Service Accounts

Managed Identities

API Keys

Applications

Automation Tools

AI Agents

can access it too.

For this reason the identity inventory must not be limited to human accounts.

The Service Account Risk

Service accounts generally carry long-lived permissions.

Some of them can be used for years.

If a service credential is compromised the attacker can access a large amount of cloud data.

For this reason machine identities must be kept under Least Privilege.

Cloud Secrets Management

API keys, database credentials and encryption keys must not be stored inside the source code.

A secrets manager or a vault must be used.

Secret rotation automation must be applied as much as possible.

This is important especially for CI/CD and cloud-native applications.

Cloud Encryption

One of the important layers of Cloud Data Security is encryption.

Sensitive data:

At Rest

In Transit

must be protected appropriately.

However, encryption does not solve the excessive permissions problem on its own.

An authorized identity can decrypt the data.

For this reason IAM and encryption must be designed together.

Customer-Managed Encryption Keys

For some high-sensitivity workloads customer-managed keys can be used.

This can enable the organization to have more control over the key policy.

However, key management brings operational responsibility.

Key loss can turn into an availability risk.

Cloud KMS

Cloud Key Management Services can provide the centralized management of encryption keys.

Key access logs are important in terms of security monitoring.

Unusual decrypt operations can be a security incident indicator.

Cloud Backup Security

Cloud backups contain sensitive data too.

Backup storage:

Encrypted

Immutable

Access-Controlled

Monitored

must be these.

Even if the production environment is secure weak backup permissions can create a data breach.

Snapshot Security

Cloud snapshots can contain a large copy of database or virtual machine data.

Snapshots can be shared with an external account by mistake.

For this reason snapshot permissions and lifecycle must be managed.

Orphaned Snapshots

Even if the resource is deleted the snapshot can remain.

This forgotten copy can become Shadow Data.

Sensitive data can be stored for longer than the retention period.

Data Discovery must detect these copies.

What Is Shadow Data?

Shadow Data is data copies, repositories or datasets over which the security or governance teams do not have sufficient visibility.

For example:

Old Database Snapshot

Forgotten Backup

Developer Copy

Temporary Export

Unmanaged SaaS Upload

Abandoned Storage

can be Shadow Data.

Cloud environments can cause Shadow Data to grow quickly.

What Is Dark Data?

Dark Data can express data the organization stores but does not use actively or whose business value is uncertain.

Dark Data and Shadow Data are different concepts.

Dark Data can be known but not used.

Shadow Data, on the other hand, can be outside security visibility.

Both of them can create unnecessary exposure.

What Is ROT Data?

ROT:

Redundant, Obsolete, Trivial

means data.

That is:

unnecessary copies,

old data,

data with no business value.

Because cloud storage is cheap and easy ROT Data can grow over time.

This is both a cost and a security risk.

Why Is Data Minimization Important for the Cloud?

The easiest data to protect is data that is not kept unnecessarily.

Because with cloud adoption storage capacity has become easier organizations can store more data than necessary.

Data Minimization and Retention policies reduce the attack surface.

Data Retention

Every piece of data must not be stored forever.

Retention periods must be defined in line with business, legal and regulatory requirements.

Data whose retention period has expired must be deleted securely.

This is a part of Data Lifecycle Management.

How Is Secure Deletion Handled in the Cloud?

Because of cloud storage abstraction the traditional disk wiping approach is not always applicable.

For this reason provider deletion mechanisms, encryption key destruction and lifecycle policies can be used.

The organization must understand the provider's deletion model.

What Is Data Residency?

Data Residency is related to in which country or geographic region the data is stored physically or logically.

While the cloud architecture is being designed regulatory, contractual and business requirements can be taken into account.

However, Data Residency and Data Security are not the same thing.

Data can be located in a certain country but can be exposed because of wrong permissions.

What Is Data Sovereignty?

Data Sovereignty is related to the data being able to be subject to the legal rules of the jurisdiction it is located in.

It is an important governance subject for global cloud architectures.

Security teams must work together with legal and privacy teams.

Cross-Border Data Transfer

SaaS and multi-cloud architectures can cause data to move between different regions.

For this reason data flow mapping is important.

The organization must know not only where the data is stored but where it is transferred too.

Why Is Data Lineage Important in the Cloud?

Data Lineage shows how the data moves from the source to the destination.

For example:

CRM

↓

Data Warehouse

↓

BI Platform

↓

Export

↓

SaaS Analytics

If this flow is not known the control of sensitive data becomes difficult.

Cloud Data Flow Mapping

With Data Flow Mapping:

Source

Destination

Data Type

Transfer Method

Owner

Purpose

can be determined.

This provides common visibility for the privacy, security and architecture teams.

External Sharing Governance

One of the biggest advantages of cloud collaboration is easy sharing.

However, this is at the same time a data leakage risk.

External sharing:

Business Purpose

Recipient Identity

Expiry

Classification

must be managed with these.

Guest User Lifecycle

An external guest can remain in the system after the project is completed.

This creates orphaned external access.

Guest identities must be reviewed periodically.

Inactive guests must be removed.

Download Control

In some sensitive data use cases the user must be able to view the document but must not be able to download it.

This can be provided with browser-only or controlled access models.

The aim is to reduce an uncontrolled copy being created on the endpoint.

Unmanaged Device Access

A user can access corporate cloud data over a personal device.

In this case the data can remain outside endpoint security controls.

The policy:

Allow Browser View

Block Download

Require Managed Device

can apply controls such as these.

Conditional Access and Data Security

Conditional Access can control cloud access according to the identity, device, location and risk context.

For example:

Restricted Data

Unmanaged Device

=

Block Download.

This is one of the important applications of Zero Trust Data Security.

Zero Trust Cloud Data Security

The Zero Trust approach does not trust the network location in cloud data access.

The access decision:

Identity

Device

Application

Data Sensitivity

Risk

Context

is given over these.

This is the data-centric authorization model.

Cloud Data Security and DLP

DLP provides data movement control.

For example a user can try to upload a Confidential document to personal cloud storage.

DLP can detect and block this.

However, for DLP to be successful classification and business context are important.

Cloud Data Security and DAM

For cloud databases DAM can monitor the database activity.

DSPM shows the data location and the exposure.

DLP controls the data movement.

These three layers together cover different stages:

DSPM → Where is the data?

DAM → Who is querying it?

DLP → Where is it going?

This is a strong distinction in terms of modern Data Security Architecture.

Cloud Data Security and the SIEM

Cloud security events can be transferred to the central SIEM.

For example:

Public Sharing

Sensitive File Download

OAuth Consent

KMS Activity

Database Export

Guest Access

events such as these can be correlated.

This provides SOC visibility.

Cloud Data Security and UEBA

User behavior analytics can analyze cloud data access patterns.

For example an employee normally opens 20 documents a day.

If one night they download 5,000 documents an anomaly can be created.

This can be an insider threat or compromised account indicator.

Impossible Travel + Data Download

The identity platform can produce an impossible travel alert for a user.

If at the same time a large SharePoint download is taking place the risk rises.

For this reason identity and data signals must be analyzed together.

Ransomware and Cloud Data

Ransomware does not affect only local file servers.

A compromised cloud account:

files encrypt,

delete,

overwrite

can do these.

Because of cloud sync destructive changes can spread quickly.

Versioning and backup are for this reason important.

Is Cloud Backup Sufficient Against Ransomware?

Only having a backup is not sufficient.

If the attacker can delete the backup over the same account the recovery is put at risk.

Backup isolation and immutable recovery copies are important.

This is the Data Resilience approach.

Cloud Data Security and Insider Threat

An authorized employee can download large amounts of data.

For this reason internal user activity must also be monitored.

Especially:

Bulk Download

External Sharing

Mass Copy

Unusual SaaS Upload

behaviors such as these are valuable.

Cloud Data Exfiltration

Cloud Data Exfiltration can take place through different channels:

Download

External Share

API

OAuth Application

Sync Client

SaaS Integration

AI Prompt

For this reason only network egress monitoring is not sufficient.

API-Based Data Exfiltration

An attacker can download thousands of files over an API with a stolen OAuth token.

Traditional browser monitoring may not see this.

Cloud audit logs and API telemetry are important.

Token Theft and Cloud Data

Modern attackers can take over a session token or an OAuth token instead of a password.

Even if MFA is used a stolen token can provide an active session.

For this reason token protection and ITDR are important.

Cloud Data Security and ITDR

ITDR produces compromised identity signals.

DSPM provides sensitive data context.

For example:

High-Risk Identity

Access to Restricted Data

=

Critical Priority.

This is the combination of Identity Security with Data Security.

AI and Cloud Data Security

Generative AI adoption is changing the boundaries of cloud data security again.

Employees can upload cloud documents to AI tools.

AI applications can connect to SaaS data with an API.

AI Agents can carry out autonomous actions on corporate cloud environments.

For this reason AI Data Security is now an important part of Cloud Data Security.

What Is Shadow AI?

Shadow AI is AI tools that have not been approved by the organization being used by employees.

An employee can upload a confidential document to a public AI service.

This can create a data governance problem.

Shadow AI can be evaluated as a new and faster growing subcategory of Shadow SaaS.

AI Prompt Data Leakage

A user inside the prompt:

Customer Data

Source Code

Contract

Financial Information

Personal Data

can add these.

This information can be transferred to an external AI platform.

For this reason DLP is gaining importance for AI traffic too.

AI SaaS Governance

A security assessment must be carried out for AI applications.

The questions:

Is data retained?

Is it used for training?

What is the data location?

Are there access controls?

Is enterprise isolation present?

Are audit logs provided?

This evaluation can be added to the procurement and security processes.

Microsoft 365 Copilot and Corporate Data Authorizations

Enterprise AI assistants can retrieve documents over the existing permissions inside the organization.

In this case old SharePoint permission problems can become more visible through AI.

AI may not create wrong permissions but can enlarge the effect of the existing excessive permissions.

For this reason Data Access Governance is important before an AI deployment.

Why Can AI Enlarge the Permission Creep Problem?

An employee may not be able to find one by one the thousands of documents they could access in the past.

An AI search or assistant can surface these documents within seconds.

For this reason excessive permissions that have been invisible for years can now create a higher business risk.

AI readiness actually requires Data Governance readiness.

RAG and Cloud Data Security

RAG systems can retrieve content from SharePoint, OneDrive, cloud storage and databases.

During the retrieval the document permissions must be preserved.

Data the user does not have access to must not be included in the AI answer.

This is the Permission-Aware RAG approach.

Vector Database Cloud Security

RAG pipelines can create cloud vector databases.

These databases can keep the embeddings and metadata of sensitive content.

Encryption, access control, tenant isolation and monitoring must be applied.

Because the vector store is an "AI component" it must not be left outside the Data Security scope.

AI Agent Cloud Permissions

An AI Agent:

Read Files

Send Email

Create Documents

Query Database

Call APIs

can receive permissions such as these.

If broad permissions are given the agent can create large data exposure.

For this reason AI Agent Least Privilege must be applied.

AI Agent + OAuth

AI Agents can connect to SaaS platforms over OAuth.

The agent's scopes must be task-specific.

For example if a reporting agent needs only read permission write/delete scopes must not be given.

AI Agent Data Exfiltration

Prompt Injection or a malicious instruction can cause the agent to send sensitive cloud data to an external destination.

For this reason:

Tool Permissions

DLP

Destination Controls

Human Approval

Monitoring

must be used together.

Human-in-the-Loop

For high-risk AI actions human approval can be required.

For example:

Share Restricted Document Externally

Export Customer Database

Send Confidential Attachment

actions such as these must not be done autonomously.

This is an important guardrail for Agentic Data Security.

How Is a Cloud Data Security Architecture Established?

A modern architecture is not established over a single product.

An example data security flow:

Cloud & SaaS Data Sources

↓

Data Discovery

↓

Data Classification

↓

Identity & Access Analysis

↓

DSPM / Exposure Analysis

↓

Encryption

↓

DLP / Sharing Controls

↓

DAM / Activity Monitoring

↓

SIEM / UEBA / SOC

↓

Incident Response

↓

Retention & Secure Deletion

This model provides protection throughout the data lifecycle.

Must Data Discovery Be the First Step?

For most organizations yes.

It is difficult to protect data you do not know.

First the sensitive data repositories must be found.

Then the classification and the access exposure must be evaluated.

For this reason Data Discovery is the foundation layer of Cloud Data Security.

How Is a Cloud Data Security Project Started?

In the first stage a cloud and SaaS inventory must be created.

Which cloud providers are used?

Which SaaS applications are present?

Which repositories contain sensitive data?

Which external sharing is active?

Which identities can access it?

Which data is encrypted?

Which public exposure is present?

After this baseline is created risk-based remediation can be carried out.

Starting from the Crown Jewel Data

Instead of trying to fix all the cloud data at the same time critical data can be prioritized.

For example:

Customer Data

Financial Data

HR Data

Source Code

Credentials

Contracts

can be prioritized.

This approach provides quick risk reduction.

Cloud Data Risk Scoring

The risk must not be calculated only over the vulnerability.

An example model:

Data Sensitivity

Access Exposure

Configuration Risk

Identity Risk

Business Criticality

=

Data Risk

This is the Data-Centric Risk Management approach.

Sensitive Data + Public Exposure

If Restricted Data is located on public storage it can be a critical risk.

Public marketing images, on the other hand, may not carry the same severity.

For this reason data context changes the prioritization.

Sensitive Data + Excessive Internal Access

The data may not be public.

However, if 20,000 employees can access it the risk continues.

For this reason internal exposure must be measured too.

Sensitive Data + Dormant Repository

An old backup that has not been used for 10 years can contain sensitive data.

The business value can be low but the breach impact can be high.

This data can be a delete candidate.

This is the security benefit of Data Minimization.

Cloud Data Security KPIs

The success of the programme must be measured.

Example KPIs:

Sensitive Data Discovered

Classified Data Coverage

Public Sensitive Repositories

External Sharing Count

Anonymous Links

Excessive Access Count

Dormant Guest Users

Shadow SaaS Applications

Shadow Data Repositories

Unencrypted Sensitive Data

Data Without Owner

Sensitive Data DLP Incidents

Bulk Downloads

OAuth High-Risk Applications

Cloud Data Exposure Remediation Time

ROT Data Volume

AI Tool Data Upload Events

AI Agents with Broad Permissions

metrics such as these can be used.

Public Sensitive Data KPI

The total number of public resources is not sufficient on its own.

The really important metric:

Public Resources Containing Sensitive Data

can be this.

This provides risk-based measurement.

External Sharing KPI

How many documents have been shared externally?

How many of them are Confidential?

How many of them have no expiry?

This provides more meaningful governance.

Shadow Data KPI

The number of sensitive repositories located outside the security inventory can be measured.

This is a visibility maturity indicator.

As Shadow Data decreases governance increases.

The Most Frequently Made Mistakes in Cloud Data Security

The most common mistake is thinking that the cloud provider manages data security completely. Because of the Shared Responsibility Model the customer configuration, identity and data governance responsibility continues.

The second mistake is focusing only on the cloud infrastructure and ignoring SaaS applications.

The third mistake is checking public exposure and ignoring excessive internal permissions.

The fourth mistake is applying DLP without classification.

The fifth mistake is leaving old backups, snapshots and forgotten data copies outside the inventory.

The sixth mistake is not taking OAuth applications and SaaS integrations into the identity governance scope.

The seventh mistake is not removing external guest access after the project finishes.

The eighth mistake is evaluating AI tools separately from the Data Security programme.

The ninth mistake is overlooking that RAG and AI Agents can access sensitive data over existing cloud permissions.

The tenth mistake is looking only at the configuration risk and not including data sensitivity in the risk scoring.

Cloud Data Security Checklist

• Is a cloud and SaaS inventory present?
• Is Microsoft 365 Data Security in scope?
• Are SharePoint permissions being reviewed?
• Is OneDrive external sharing being monitored?
• Is Teams data sharing being controlled?
• Is sensitive data discovery being carried out?
• Is Data Classification being applied?
• Is public cloud storage being detected?
• Is the data sensitivity inside public storage being analyzed?
• Are anonymous sharing links being monitored?
• Is external sharing expiry being applied?
• Are guest users being reviewed periodically?
• Is Shadow SaaS being detected?
• Are OAuth applications in the inventory?
• Are OAuth scopes being reviewed?
• Are SaaS-to-SaaS integrations visible?
• Is CASB being used or evaluated?
• Is Cloud DLP being applied?
• Is DSPM being used or evaluated?
• Is data context being related with CSPM?
• Is Cloud IAM under Least Privilege?
• Are excessive permissions being detected?
• Are CIEM capabilities being evaluated?
• Are service accounts in the inventory?
• Are machine identities being monitored?
• Are the secrets inside a centralized vault?
• Is cloud storage encrypted?
• Are customer-managed keys being evaluated in the necessary workloads?
• Are Cloud KMS logs being monitored?
• Are the cloud backups encrypted?
• Are immutable backups present?
• Are snapshots under governance?
• Are orphaned snapshots being detected?
• Are database clones being monitored?
• Is Shadow Data discovery being carried out?
• Is Dark Data being analyzed?
• Is ROT Data being cleaned?
• Is Data Retention being applied?
• Is there a Secure Deletion process?
• Have the Data Residency requirements been determined?
• Are Cross-Border Data Flows in the inventory?
• Is Data Lineage visible?
• Is Unmanaged Device Access being controlled?
• Is Conditional Access being applied?
• Are bulk cloud downloads being detected?
• Are cloud audit logs being transferred to the SIEM?
• Is UEBA analyzing data access behavior?
• Are token theft use cases being monitored?
• Is Shadow AI being detected?
• Is sensitive data upload to AI platforms being controlled?
• Is RAG permission-aware?
• Have vector databases been taken into the security scope?
• Are AI Agents using a unique identity?
• Are AI Agent OAuth scopes Least Privilege?
• Do high-risk AI actions require human approval?
• Are Cloud Data Security KPIs being followed?

Cloud Data Security Maturity Model

Level 1 – Lack of Cloud Visibility: The organization does not know exactly inside which SaaS applications and cloud repositories sensitive data is located. External sharing and Shadow Data visibility is limited.

Level 2 – Basic Cloud Protection: Encryption, MFA, basic DLP and cloud configuration controls are applied. Public resources and major sharing risks start to be monitored.

Level 3 – Data-Aware Cloud Security: Data Discovery, Classification, CASB, DSPM and access governance are integrated. Sensitive data exposure is managed risk-based.

Level 4 – Multi-Cloud Data Security: Different environments such as Microsoft 365, SaaS, AWS, Azure and Google Cloud are evaluated in a central data-centric risk model. Identity, data sensitivity and behavior are analyzed together.

Level 5 – Adaptive Cloud & AI Data Security: Human, machine and AI Agent accesses are verified continuously. DLP, DSPM, DAM, IAM, CIEM, SIEM and AI security controls work inside a common policy framework.

This transformation:

Cloud Visibility

↓

Cloud Protection

↓

Data-Aware Security

↓

Multi-Cloud Data Security

↓

Adaptive Cloud & AI Data Security

proceeds in this way.

Frequently Asked Questions

What is Cloud Data Security?

Cloud Data Security is the security approach that ensures that the data stored, processed and shared in cloud and SaaS environments is protected against unauthorized access, data leakage, misconfiguration and data loss.

What is the difference between Cloud Security and Cloud Data Security?

Cloud Security covers wide security areas such as infrastructure, workloads, network and identity. Cloud Data Security focuses especially on the sensitivity, access, exposure and movement risks of the data inside the cloud.

What is SaaS Data Security?

SaaS Data Security is the protection of the corporate data located inside Microsoft 365, CRM, HR, collaboration and other SaaS applications.

How is Microsoft 365 data security provided?

Data Classification, DLP, identity security, SharePoint and OneDrive permission governance, external sharing controls, audit, Conditional Access and monitoring must be applied together.

What is the most important risk in SharePoint data security?

Excessive permissions, anonymous sharing links, external users and Permission Creep are among the important risks.

How is OneDrive data leakage prevented?

Classification, DLP, external sharing controls, managed device policies, access reviews and activity monitoring can be used together.

What is CASB?

Cloud Access Security Broker is the security solution category that can provide visibility, access control, DLP and Shadow IT/SaaS monitoring on cloud applications.

What is Cloud DLP?

Cloud DLP focuses on detecting or preventing sensitive data being shared and carried uncontrolled inside cloud applications or between cloud services.

What is DSPM?

Data Security Posture Management is the data-centric security approach that analyzes where sensitive data is located, who can access it and which exposure risks it has.

What is the difference between DSPM and CSPM?

CSPM focuses on the cloud configuration posture, DSPM on the data sensitivity and data exposure posture. When they are used together the risk can be prioritized more accurately.

What is Shadow Data?

Shadow Data is data copies, backups, snapshots, repositories or datasets over which the security or governance teams do not have sufficient visibility.

What is Shadow SaaS?

It is SaaS applications that are not officially managed or approved by the organization being used by employees.

What is Shadow AI?

It is AI applications that have not been approved by the organization being used with corporate data and it can create a sensitive data leakage risk.

Why is Cloud IAM important for data security?

Cloud IAM determines which human or machine identity can access which cloud resource and data. Excessive permissions increase the data exposure risk.

Is cloud encryption sufficient?

No. Encryption provides protection against a storage or transmission compromise but an authorized or compromised identity can access the decrypted data. IAM, DLP and monitoring are necessary too.

How do AI systems affect Cloud Data Security?

AI applications, RAG systems and AI Agents can access and process cloud data much faster. For this reason Permission-Aware Retrieval, Agent Least Privilege, DLP and AI activity monitoring gain importance.

Why is it important to go over the data accesses for corporate AI systems such as Microsoft 365 Copilot?

Corporate AI assistants can discover a large amount of content quickly over the existing user permissions. Excessive SharePoint or cloud permissions that have been created over the years can for this reason become more visible and higher impact.

Conclusion: It Is Necessary to Put Not Cloud Security but the Data Inside the Cloud at the Centre

The fundamental problem of Cloud Data Security is not whether the cloud is secure or not.

Modern cloud providers can provide very strong infrastructure security controls.

The real problem is how the organization manages its own data.

Where is the sensitive data?

Who can access it?

With whom is it shared?

Which copies are present?

Which SaaS applications use the data?

Which OAuth applications can access it?

Which service accounts can read the data?

Which AI Agents can access the same data?

Without these questions being answered it is difficult to speak of real Cloud Data Security visibility.

For this reason the modern cloud security approach:

Resource-Centric Security

from this model:

Data-Centric Security

is proceeding towards this model.

Now only:

"Is this bucket public?"

asking this question is not sufficient.

It is necessary to ask this:

"Is this bucket public and what is inside it?"

Not only:

"Does this user have SharePoint access?"

but:

"Which Restricted documents can this user access?"

Not only:

"Has this AI Agent been given an OAuth permission?"

but:

"Which sensitive data can it reach over this permission and which actions can it carry out with this data?"

these questions must be asked.

For this reason a modern Cloud Data Security Architecture:

Data Discovery + Classification + DSPM + IAM + CIEM + Encryption + DLP + DAM + CASB + SIEM + Zero Trust

requires these approaches to work together.

Especially with Generative AI and Agentic AI adoption this need is growing even more.

Because cloud data is now used not only over files opened by users or API calls made by applications.

AI systems can search inside thousands of documents at the same time, can send queries to databases, can carry data between SaaS platforms and can carry out autonomous actions.

For this reason the Cloud Data Security model of the future not only:

Human Access

but:

Human + Machine + AI Agent Access

has to manage this model.

And the most important sentence of this chapter:

Modern Cloud Data Security is not only encrypting the data located on Microsoft 365, SaaS, AWS, Azure or Google Cloud, but making continuously visible and controllable where the sensitive data is, who can access it, with whom it is shared, which applications and AI Agents use it, where it is carried and which risks it is exposed to at every stage of its lifecycle.