How Is a Corporate Data Security Architecture Built? Classification + DLP + DSPM + DAM + Encryption + Zero Trust

A corporate data security architecture is the integrated security structure created in order to discover the sensitive data an organization has, to classify it, to control who can access this data, to encrypt the data, to monitor data movements, to prevent data leakage, to audit database activities and to intervene as early as possible in active data threats. A modern Data Security Architecture does not consist of a single DLP, encryption or database security product; it requires different security layers such as Data Discovery, Data Classification, IAM, PAM, Encryption, DLP, DSPM, DAM, DDR, SIEM, SOC and Zero Trust to work together.

In corporate data security the fundamental aim is now not only:

"Let us encrypt the data."

or:

"Let us prevent the data going outside."

this.

The modern approach must be able to answer all of these questions:

Which data do we have?

Where is the sensitive data located?

How has this data been classified?

Who is the owner of the data?

Who can access this data?

Do they really need to access it?

Is the data being encrypted?

Who is running which database query?

Is the data being carried to a USB drive, e-mail, web, SaaS or an AI platform?

Is abnormal behavior taking place on sensitive data?

Which data does an AI Agent access and which operations does it carry out?

When an active data threat is created how quickly can we detect it?

When risky behavior is detected can we intervene automatically or semi-automatically?

All of these questions being answered together creates a real Enterprise Data Security Architecture.

What Is Corporate Data Security?

Corporate data security is the protection of the data the organization has not only against unauthorized access; but against risks such as wrong use, data leakage, over-authorization, insider threat, ransomware, credential compromise, cloud misconfiguration, Shadow Data, Shadow AI and AI Agent originated risks.

For this reason Data Security is not only storage security.

Data:

Inside a database,

On a file server,

On an endpoint,

In the Microsoft 365 environment,

On cloud storage,

In a SaaS application,

Inside a backup,

In a data lake,

In a source code repository,

Inside e-mail,

In an AI knowledge base,

Inside a vector database,

In a RAG system,

Inside AI Agent Memory

can be located.

A modern Data Security Architecture must be able to evaluate this distributed data structure in a single security perspective.

The Biggest Problem in Data Security: You Cannot Protect the Data You Do Not See

The first principle of a corporate data security architecture is quite simple:

You Cannot Protect What You Cannot See.

If an organization does not know where the sensitive data it has is located it is extremely difficult for it to apply the correct security controls to this data.

For example the organization's customer database can be protected.

However, the same database's:

Excel export,

old backup,

developer test copy,

SharePoint copy,

cloud storage copy

can be located in different environments.

For this reason the first layer of the Data Security Architecture must be Data Discovery.

Layer 1: Data Discovery – Finding the Sensitive Data

Data Discovery aims to detect where sensitive information is located by scanning the data repositories inside the organization.

These scans:

Databases

File Servers

Endpoints

Cloud Storage

SaaS

Microsoft 365

Data Lakes

Backups

Repositories

AI Data Stores

can be carried out on different environments such as these.

The aim is not only to create a file inventory.

The real aim is:

"Which sensitive data is where?"

to answer this question.

Sensitive Data Discovery

During Sensitive Data Discovery:

Personal Data

Financial Data

Customer Data

Credentials

Source Code

Trade Secrets

HR Data

Health Data

Contracts

Intellectual Property

information types such as these can be detected.

These discovery results form the foundation for the other security controls.

What Is Shadow Data?

Data copies that the security or IT teams do not know about, that are not managed or that have gone out of control can be called Shadow Data.

For example an old export of the production database can be located inside a forgotten cloud bucket.

This data can be less protected than the active system.

In terms of DSPM Shadow Data is an important risk area.

Dark Data

Data that has not been used for a long time but is still stored can be evaluated as Dark Data.

Dark Data may not produce business value but can create exposure during a breach.

For this reason Data Minimization is an important part of security.

Layer 2: Data Classification – Understanding the Value of the Data

Data Discovery finds the data.

Data Classification, on the other hand:

"How sensitive is this data?"

answers this question.

An example classification model:

Public

Internal

Confidential

Restricted

can be in this way.

Every classification level requires a different security policy.

Public Data

Public Data is data where there is no harm in it being disclosed to the public.

For example a published corporate brochure.

The security controls can be lighter than the other levels.

Internal Data

Internal Data is data created to be used inside the organization but that is not public.

For example internal procedures or internal announcements.

Confidential Data

Confidential Data is information that in the case of unauthorized disclosure can harm the organization.

For example:

Contracts

Financial Reports

Customer Information

Business Plans.

Restricted Data

Restricted Data can be the data category that requires the highest protection.

For example:

Critical Personal Data

Authentication Secrets

Private Keys

Highly Sensitive Financial Data

Strategic Trade Secrets.

For this data stricter access, encryption and monitoring controls must be applied.

Classification Policy Enforcement

Classification must not be only a label.

The label must change security behavior.

For example:

Restricted

↓

Encryption Required

External Sharing Blocked

USB Copy Blocked

Privileged Access Monitored

DDR High-Sensitivity Monitoring

policies such as these can be triggered.

This is the Classification-Driven Security approach.

Layer 3: Data Ownership – Determining the Owner of the Data

Every critical dataset must have a business owner.

The security team on its own:

"Who must access it?"

cannot give this decision.

The Data Owner knows the business context.

For example the HR Data Owner:

HR Director.

The Finance Data Owner:

Finance Department.

The Customer Data Owner:

Relevant Business Unit.

Data Ownership is the foundation of access governance.

What Does the Data Owner Do?

The Data Owner:

Can determine the classification.

Can give access approval.

Can determine the retention requirement.

Can carry out Access Reviews.

Contributes to the data sharing policies.

In this way Data Security stops being only an IT responsibility.

Layer 4: IAM and IGA – Who Can Access Which Data?

The data has been discovered.

It has been classified.

The owner has been determined.

Now the critical question:

Who can access it?

IAM and IGA come into play here.

While Identity and Access Management manages user identities and authentication processes Identity Governance and Administration supports the access lifecycle and governance processes.

Least Privilege

A user must have only the minimum permissions necessary to do their duty.

This is the Least Privilege principle.

For example a Finance user may not have to access the whole customer database.

The access scope must be limited according to the business need.

Need-to-Know

A user being able to access technically does not mean that they need to access it in terms of the business.

The Need-to-Know approach:

"Does this user really need to know this data?"

asks this question.

RBAC

Role-Based Access Control manages permissions over the role.

For example:

HR Specialist

Finance Analyst

Sales Manager.

This provides operational simplicity.

However, very broad roles can create excessive access.

ABAC

Attribute-Based Access Control while giving the decision:

User Attribute

Data Classification

Department

Device

Location

Time

Risk

can use attributes such as these.

For example:

User = Finance

Data = Restricted

Device = Managed

Location = Corporate

MFA = Strong

if it is so access can be allowed.

Access Review

Permissions must not be accepted as permanent.

With a Periodic Access Review the Data Owner:

"Must this user still access this data?"

must evaluate this question.

Unused permissions must be revoked.

Permission Creep

As a user changes department if the old permissions are not removed wide access is created over time.

This is known as Permission Creep.

With AI adoption Permission Creep can create a more serious risk because AI can discover within seconds the data the user can access but could not find before.

Layer 5: PAM – Controlling Privileged Data Accesses

Database Administrator,

System Administrator,

Cloud Administrator

privileged users such as these can have wide permissions on critical data.

For this reason privileged access requires a separate control layer.

PAM – Privileged Access Management meets this need.

What Does PAM Provide for Data Security?

PAM:

Credential Vaulting

Session Management

Session Recording

Approval

JIT Access

Password Rotation

can provide controls such as these.

In this way privileged access becomes more visible and controlled.

Just-in-Time Access

Instead of a privileged permission being kept open continuously it can be given temporarily when necessary.

For example a DBA receives an elevated privilege only during maintenance.

When the task finishes the permission is revoked.

This reduces the standing privilege risk.

Zero Standing Privilege

Zero Standing Privilege targets permanent privileged permissions being removed as much as possible.

This can reduce the compromised privileged account impact.

Layer 6: Encryption – Making the Data Unreadable

Encryption is one of the fundamental technical controls of the Data Security Architecture.

Encryption:

Data at Rest

Data in Transit

and in appropriate architectures:

Data in Use

can be evaluated for these.

But encryption on its own is not Data Security.

Data at Rest Encryption

Data stored on a disk, a database, a backup and cloud storage can be encrypted.

For example:

Full Disk Encryption

Database Encryption

TDE

Object Storage Encryption

Backup Encryption.

Data in Transit Encryption

Data carried over the network must be protected with secure protocols such as TLS.

This reduces the interception risk.

Data in Use

During data processing protection is more complex.

Technologies such as Confidential Computing and a Trusted Execution Environment can provide Data in Use protection in certain use cases.

KMS and HSM

The security of encryption does not depend only on the algorithm.

How are the keys managed?

A KMS and an HSM play a critical role here.

The Key Lifecycle:

Generation

Storage

Distribution

Rotation

Revocation

Destruction

must cover these stages.

Why Is Encryption Not Enough on Its Own?

If a user has authorized access to the database they can query the TDE encrypted database.

The database engine decrypts the data for the user.

For this reason:

Encryption

Access Control

DAM

DDR

must be evaluated together.

Layer 7: DLP – Controlling Where the Data Goes

DLP – Data Loss Prevention aims to detect and prevent sensitive data being carried outside the organization or to an unauthorized destination.

DLP:

Endpoint

E-Mail

Web

Network

Cloud

SaaS

can be applied on these channels.

Endpoint DLP

Endpoint DLP:

USB Copy

Clipboard

Print

Browser Upload

File Copy

can monitor user actions such as these.

For example:

Restricted File

USB Copy

=

Block.

E-Mail DLP

If a sensitive attachment is being sent to an external recipient the policy:

Warn

Justify

Encrypt

Quarantine

Block

can apply these.

Cloud DLP

Sensitive data sharing on Microsoft 365 and other SaaS platforms can be controlled.

For example:

Confidential File

Anonymous Public Link

=

Blocked.

AI DLP

Modern DLP architectures must cover AI channels too.

For example:

Restricted Source Code

Public Generative AI

=

Block.

Prompt,

file upload,

clipboard

and AI tool usage must be taken into the Data Security scope.

What Is the Limit of DLP?

DLP is mostly strong on a policy violation or data movement.

However, if a user is accessing sensitive data as authorized and has not yet taken the data outside DLP may not always see the threat at an early stage.

Here DDR gains importance.

Layer 8: DSPM – Data Security Posture Management

DSPM – Data Security Posture Management is the modern Data Security approach that aims to analyze the organization's sensitive data posture continuously.

DSPM looks for answers to these questions:

Where is the Sensitive Data?

Who can access it?

Is there public exposure?

Are excessive permissions present?

Is the data encrypted?

Is there Shadow Data?

Is a misconfiguration present?

Why Is DSPM Important?

Traditional security can be asset-centric.

DSPM, on the other hand, brings a data-centric perspective.

For example:

Cloud Bucket Public.

This is a configuration issue.

However, if Restricted Customer Data is located inside the bucket the risk is much higher.

DSPM combines the configuration risk with the data sensitivity.

DSPM + IAM

DSPM:

"800 users can access this sensitive dataset."

can say this.

IGA:

"Which of these users' access is really necessary?"

can manage this question.

This integration provides excessive access reduction.

DSPM + DLP

DSPM finds the sensitive data.

DLP controls the movement of this data.

A simple model:

DSPM → Where is the Data?

DLP → Where is the Data Going?

However, for active threat detection one more layer is required:

DDR → What Is Happening to the Data Right Now?

Layer 9: DAM – Database Activity Monitoring

An important part of corporate critical data is located inside databases.

For this reason database activity requires separate visibility.

DAM – Database Activity Monitoring, on the database:

Queries

Logins

Privilege Changes

Schema Changes

Bulk Exports

Administrative Actions

monitors activities such as these.

Why Is DAM Necessary?

A DBA can be authorized.

However, them exporting the whole customer table at 03:00 at night may not be normal.

Authentication:

Valid.

Permission:

Allowed.

Behavior:

Suspicious.

DAM makes this activity visible.

DAM + PAM

PAM:

"Who opened the DBA session?"

answers this question.

DAM:

"Which SQL queries did this session run on the database?"

answers this question.

Together privileged database security strengthens.

DAM + Classification

A DAM event only as:

"SELECT executed."

must not be evaluated.

If the classification context is added:

"User executed bulk SELECT on Restricted Customer Data."

it becomes this.

This is a much more meaningful security event.

Layer 10: DDR – Data Detection and Response

One of the most critical development areas of modern Data Security Architecture is the DDR – Data Detection and Response approach.

DDR aims to detect the risky behaviors taking place on sensitive data during runtime and where necessary to trigger response actions.

DSPM analyzes the posture.

DLP controls the data movement.

DAM monitors the database activity.

DDR, on the other hand, using the data context and behavior signals coming from these:

"Is a real threat behavior towards sensitive data taking place right now?"

focuses on this question.

What Is DDR?

Data Detection and Response is the Data Security approach aimed at detecting scenarios such as:

Unusual Data Access

Bulk Download

Mass Retrieval

Data Exfiltration

Suspicious Database Query

Insider Threat

Compromised Identity Data Access

AI Agent Data Abuse

by continuously analyzing sensitive data access and usage behaviors.

The fundamental difference of DDR is that it puts data at the centre of threat detection.

The Difference Between Traditional Detection and DDR

A traditional security alert:

"The user made an unusual login."

The DDR perspective:

"After the unusual login the user carried out a download 100 times the normal on Restricted Customer Data."

The second event is more meaningful in terms of business impact.

The Fundamental Questions of DDR

DDR tries to answer these questions:

Which identity?

Which sensitive data?

How much data?

Which action?

Which source?

Which destination?

Is the behavior normal?

Is the identity risky?

Is the data going outside?

Is a response required?

This combination of context creates Data-Centric Threat Detection.

DSPM + DDR

DSPM shows the posture.

DDR shows the runtime activity.

For example:

DSPM:

Restricted Data in Cloud Storage.

Access:

350 Users.

DDR:

User X suddenly downloads 25,000 files.

This can be a high-risk data threat.

DLP + DDR

DLP:

The user is carrying out an external upload.

DDR:

The same user accessed 40,000 sensitive records in the last 15 minutes.

Together the Data Exfiltration confidence rises.

DAM + DDR

DAM:

DBA executes bulk customer query.

DDR:

The query volume is 200 times higher than the user baseline.

This can be an Insider Threat or compromised DBA account indicator.

ITDR + DDR

ITDR:

The identity can be compromised.

DDR:

The compromised identity is carrying out mass retrieval on Restricted Data.

This shows the data impact of the identity threat.

EDR + DDR

EDR:

It detected a malicious process on the endpoint.

DDR:

The same endpoint is carrying out mass access on sensitive files.

This can be a ransomware or exfiltration incident.

DDR + SIEM

DDR events can be transferred to the SIEM.

The SIEM:

Identity

Endpoint

Network

Cloud

DLP

DAM

PAM

DDR

can create an attack story by correlating these signals.

DDR + SOAR

A high-confidence DDR event can trigger an automatic response.

For example:

Bulk Restricted Data Access

Compromised Identity

External Upload

=

Revoke Session

Block Upload

Isolate Endpoint

Open Incident.

This is the transition from Data Detection to Data Response.

Layer 11: Insider Threat Protection

The internal threat is a natural part of the Data Security Architecture.

A Malicious Employee,

a Negligent User,

a Compromised Account,

a Privileged Insider,

a Third-Party User,

a Service Account,

an AI Agent

can cause a sensitive data risk.

For this reason Insider Threat must be handled as the common use case of the whole architecture instead of a separate product.

Insider Threat Detection

A strong model:

Identity Context

Data Sensitivity

Behavior

Data Volume

Destination

Privilege

=

Insider Data Risk

can be thought of in this way.

Low-and-Slow Exfiltration

An insider does not always download millions of records at once.

They can take out a small amount of data every day.

Historical behavior analysis and DDR can help to detect this pattern.

Departing Employee Risk

For users in the leaving period risk-based monitoring can be applied.

For example if a user starts to clone source code repositories they have never accessed before an investigation can be required.

However, monitoring must be carried out within the scope of privacy and legal governance.

Layer 12: Zero Trust Data Security

Zero Trust is not only a network architecture.

It must be applied to Data Security too.

The fundamental principle:

Never Trust, Always Verify.

A user is not accepted as automatically trusted because they are on the internal network.

Access:

Identity

Device

Data

Context

Behavior

Risk

is evaluated over these.

Zero Trust Data Access

An example policy:

User = Finance Analyst.

Data = Restricted.

Device = Managed.

MFA = Phishing-Resistant.

Location = Trusted.

Risk = Low.

Action = Read.

Result:

Allow.

However:

Device = Unmanaged.

Risk = High.

Action = Export.

Result:

Deny.

This is context-aware Data Security.

Continuous Authorization

After a user logs in they must not be accepted as trusted throughout the whole session.

If the risk changes the access can be reevaluated.

For example when DDR detects high-risk behavior:

Step-Up Authentication

Session Revocation

Data Access Restriction

can be applied.

Layer 13: SIEM and SOC – Data Security Operations

Data Security controls produce a large amount of telemetry.

These events must be connected to the operational security process.

The SIEM:

DLP

DSPM

DAM

DDR

IAM

PAM

ITDR

EDR

Cloud

SaaS

can correlate these events centrally.

Data Security SOC Use Cases

Important scenarios for the SOC:

Sensitive Data Bulk Download

Database Bulk Export

Restricted File External Sharing

USB Data Copy

Personal Cloud Upload

Sensitive Data to Public AI

Compromised Identity + Sensitive Data Access

Privileged User Anomaly

Service Account Data Access Spike

AI Agent Bulk Retrieval

AI Agent External Data Transfer

Shadow Data Exposure

Public Sensitive Cloud Storage

use cases such as these.

Data-Centric SOC

A traditional SOC:

IP,

Endpoint,

Malware,

Account

can carry out an investigation over these.

A Data-Centric SOC adds this question:

"Which data was at risk during this incident?"

This strengthens the business impact analysis.

Layer 14: SOAR and Automated Data Response

Every Data Security incident must not wait for a manual response.

For high-confidence incidents automated actions can be applied.

For example:

Revoke Session

Disable Sharing Link

Block USB

Block Upload

Terminate Database Session

Revoke API Token

Disable AI Agent

Isolate Endpoint

Require MFA

actions such as these can be applied.

Adaptive Data Security

The most advanced Data Security Architecture uses risk-adaptive policies instead of a static policy.

For example:

Normal User + Internal Data → Allow.

High-Risk User + Confidential Data → Step-Up MFA.

Compromised User + Restricted Data → Block.

High-Risk AI Agent + External Destination → Disable Tool.

This is the Adaptive Data Security model.

Layer 15: AI Data Security

A modern Data Security Architecture can no longer evaluate AI separately.

LLM,

RAG,

Vector Database,

AI Agent,

Prompt Logs,

Agent Memory,

AI Tools

must be taken into the Data Security scope.

AI Data Flow

An example:

User

↓

Prompt

↓

AI Agent

↓

RAG

↓

Vector Database

↓

Corporate Data

↓

LLM

↓

Tool Call

↓

External / Internal System.

Every hop inside this chain requires a security control.

Permission-Aware RAG

AI must not retrieve a document the user cannot access.

The original permissions must be preserved at the retrieval layer.

This is one of the most important controls of AI Data Security.

AI Agent Least Privilege

The agent only the necessary:

Tools

Data

Actions

Destinations

must have permissions over these.

This is the Agentic Least Privilege approach.

AI Agent + DDR

DDR can monitor the data behavior of an AI Agent.

For example:

The agent normally retrieves 500 records.

Suddenly:

500,000 records.

This anomaly can be high-risk.

AI Agent + DLP

If the agent is trying to send Restricted Data to an external API a DLP policy can block this.

This is the machine-to-machine Data Loss Prevention use case.

AI Agent Kill Switch

For critical agents an emergency disable capability must be present.

The Security Team when necessary the:

Agent Identity

Token

Tool Access

Data Access

External Connectivity

must be able to revoke these authorizations.

How Must a Corporate Data Security Architecture Look?

If we simplify the modern architecture:

DATA SOURCES

Database

File Server

Endpoint

Microsoft 365

SaaS

Cloud

Backup

Data Lake

Source Code

AI / RAG / Vector DB

↓

DATA DISCOVERY

↓

DATA CLASSIFICATION

↓

DSPM

↓

DATA OWNERSHIP & GOVERNANCE

↓

IAM / IGA / PAM

↓

ENCRYPTION / KMS / HSM

↓

DLP + DAM

↓

DDR

↓

ZERO TRUST / CONTINUOUS AUTHORIZATION

↓

SIEM / SOC

↓

SOAR / AUTOMATED RESPONSE

it can be thought of in this way.

However, this is not a completely linear architecture.

The layers must share data with each other continuously.

The Modern Data Security Control Loop

A more correct model is a feedback loop:

Discover

↓

Classify

↓

Understand Exposure

↓

Control Access

↓

Protect Data

↓

Monitor Usage

↓

Detect Threat

↓

Respond

↓

Reassess

↓

Improve

This is the continuously working Data Security lifecycle.

Discover

Which data is present?

Is there Shadow Data?

Has a new SaaS repository been created?

Has a new AI vector store been created?

Discovery must be continuous.

Classify

The sensitivity of new data must be determined.

Classification can be dynamic.

For example when customer data is added inside a document the classification can change.

Understand Exposure

DSPM:

Who can access it?

Is there public exposure?

Are there excessive permissions?

Is encryption missing?

evaluates these questions.

Control Access

IAM, IGA and PAM:

Who can access it?

For how long?

Which privilege?

manage these questions.

Protect

Encryption and DLP:

provide protection on data storage and movement.

Monitor

DAM, DLP, Cloud Audit and application telemetry provide data usage visibility.

Detect

DDR, UEBA, ITDR and the SIEM detect risky behavior.

Respond

A response can be applied over DLP, IAM, PAM, SOAR and endpoint controls.

Reassess

After an incident:

Permissions,

Policies,

Classification,

Data Location,

Risk Score

are reevaluated.

This provides continuous improvement.

The Risk-Based Approach in Data Security Architecture

Every piece of data must not be protected at the same level.

A public brochure and a customer identity database do not have to have the same controls.

The security investment must be prioritized according to the data value and the risk.

A simple model:

Risk = Data Sensitivity × Exposure × Threat × Business Impact

can be thought of in this way.

This does not have to be a mathematical standard formula; it expresses the risk prioritization logic.

The Crown Jewels Approach

First the organization's most critical data assets defined as Crown Jewels can be determined.

For example:

Customer Database

Source Code

Financial Systems

Authentication Secrets

Strategic Documents

Personal Data

Critical Operational Data.

The Data Security programme can first be matured on these assets.

Where Must a Data Security Programme Start?

The most frequently made mistake is trying to deploy dozens of security technologies at the same time.

A more correct beginning:

1. Determine the Critical Data.

2. Carry out Data Discovery.

3. Create a Classification.

4. Determine the Data Owners.

5. Analyze the Access Exposure.

6. Reduce excessive permissions.

7. Create an Encryption baseline.

8. Control the movement with DLP.

9. Monitor the database activity with DAM.

10. Evaluate the posture continuously with DSPM.

11. Detect active data threats with DDR.

12. Operationalize it with the SIEM/SOC.

13. Speed up the response with SOAR.

14. Include AI data flows in the same model.

This phased approach is more sustainable.

Phase 1 – Visibility

The aim:

"Where is the data?"

Data Discovery

Data Inventory

Classification

DSPM.

Phase 2 – Access Governance

The aim:

"Who can access it?"

IAM

IGA

Access Review

Least Privilege

PAM.

Phase 3 – Protection

The aim:

"How is the data protected?"

Encryption

KMS

DLP

Masking

Tokenization.

Phase 4 – Monitoring

The aim:

"What is happening on the data?"

DAM

DLP Telemetry

Cloud Audit

SaaS Activity.

Phase 5 – Detection & Response

The aim:

"Is there an active threat?"

DDR

UEBA

ITDR

SIEM

SOC

SOAR.

Phase 6 – Adaptive Data Security

The aim:

"When the risk changes can the security controls adapt automatically?"

Continuous Authorization

Risk-Based DLP

Dynamic Access

Automated Response

AI Agent Controls.

This is a high maturity level.

Data Security and Ransomware

Ransomware is not only an endpoint security problem.

The attacker can exfiltrate the sensitive data before the encryption.

This is the double extortion risk.

The Data Security Architecture:

Mass File Access

Bulk Download

Unusual SMB Activity

Sensitive Data Exfiltration

must detect behaviors such as these.

DDR can provide important context here.

Data Security and Backup

Backup is a part of Data Security.

Inside the backup a full copy of the production data can be located.

For this reason the backup:

Encrypted

Access-Controlled

Immutable

Monitored

must be these.

Backup credentials must be protected within the scope of privileged security.

Data Security and Disaster Recovery

The DR environment can contain the same data as production.

However, the security controls can sometimes be weaker.

DR databases and backups must be taken into the Data Discovery scope.

Data Security and DevSecOps

Developers can copy production data to a test environment.

This is risky.

For test environments:

Masking

Synthetic Data

Tokenization

can be applied.

The secrets inside the source code must be scanned separately.

Data Security and API Security

The API is the modern data access layer.

If the API authorization is weak sensitive data exposure can be created.

API security:

Authentication

Authorization

Rate Limiting

Data Filtering

Logging

DLP

must be evaluated together with these.

Data Security and SaaS

SaaS platforms can store a large amount of corporate data.

Security teams:

External Sharing

Public Links

OAuth Apps

Third-Party Integrations

Data Downloads

Shadow SaaS

must monitor these subjects.

Data Security and the Cloud

Cloud Data Security requires shared responsibility.

The cloud provider can provide infrastructure security.

However, the customer:

Data Classification

IAM

Encryption Configuration

Public Exposure

DLP

Monitoring

can be responsible for areas such as these.

DSPM can increase cloud data posture visibility.

Multi-Cloud Data Security

AWS,

Azure,

Google Cloud,

SaaS

and on-prem environments can be used together.

If separate data visibility is created for every platform blind spots can occur.

The Data Security Architecture must provide unified visibility as much as possible.

Data Security and Third-Party Risk

Data can be shared with suppliers, consultants and business partners.

For this reason Third-Party Data Access:

Time-Bound

Purpose-Limited

Monitored

must be these.

When the contract finishes the access must be revoked.

Data Security and Privacy

Data Security and Data Privacy are not the same concept.

Data Security:

Protects the data.

Data Privacy:

Handles for which purposes and within which rules personal data is processed.

However, the two disciplines intersect strongly.

KVKK and Data Security

In terms of the protection of personal data technical and organizational measures such as access control, logging, encryption, data minimization, secure disposal and monitoring can be important.

However, using a certain technology does not mean KVKK compliance on its own.

Data Security controls must be evaluated according to the risk and the nature of the processing activities.

GDPR and Data Security

Within the scope of GDPR too the appropriate technical and organizational measures approach is important for personal data protection.

Controls such as encryption, access control and monitoring can be part of a risk-based security programme.

However, compliance is not provided only with a technology deployment.

PCI DSS and Data Security

For environments where payment card data is located access control, encryption, logging and monitoring carry critical importance.

Technologies such as DLP and DAM can contribute to cardholder data exposure being controlled.

The exact requirements must be evaluated separately according to the relevant scope and the valid version of the standard.

Data Security Governance

Without technology governance remains incomplete.

Without governance technology grows uncontrolled.

For this reason a Data Security Steering structure can be created.

The participants:

Information Security

IT

Data Owners

Privacy

Legal

Risk

Internal Audit

Business Units

AI Governance

can be these.

Data Security Policy

A corporate Data Security Policy can cover at least these areas:

Data Classification

Data Ownership

Access Control

Encryption

Data Sharing

DLP

Retention

Backup

Third-Party Sharing

Cloud

AI Usage

Incident Response

Secure Disposal.

Data Security Standards

The policy is the high-level rule.

A standard, on the other hand, determines applicable technical requirements.

For example:

Restricted Data must be encrypted at rest.

Restricted Data external sharing prohibited.

Privileged database activity monitored.

Public AI upload prohibited for Restricted Data.

This creates measurable security requirements.

Exception Management

The business may not always be able to fully comply with the security standard.

An exception process must be present.

An exception:

Owner

Reason

Risk

Compensating Control

Expiration Date

Approval

must contain these.

Permanent exceptions must not be created.

Data Security Metrics

It is difficult to manage a programme you cannot measure.

The Data Security KPIs:

Sensitive Data Coverage

Classification Coverage

Unknown Data Owners

Public Sensitive Data Stores

Unencrypted Sensitive Data

Excessive Permissions

Dormant Access

DLP Violations

External Sharing

DAM High-Risk Queries

DDR High-Risk Alerts

Bulk Download Events

Data Exfiltration Attempts

AI Sensitive Prompt Events

AI Agent Risk Events

Mean Time to Detect

Mean Time to Respond

metrics such as these can be these.

Sensitive Data Coverage

What percentage of the critical data is within the discovery scope?

For example:

Databases 100%.

Cloud Storage 95%.

SaaS 60%.

This shows the coverage gaps.

Classification Coverage

How much of the sensitive data has been classified correctly?

Unknown or unlabeled data can create a risk.

Access Exposure Metric

How many users can access Restricted data?

Is this number decreasing over time?

This is an important metric of the Least Privilege programme.

DDR Detection Coverage

Which critical data sources are within the runtime threat monitoring scope?

Database?

Cloud?

SaaS?

Endpoint?

AI?

The coverage must be measured.

False Positive Rate

If DDR and DLP produce too many false positives analyst fatigue is created.

Policy tuning and behavior baselines must be optimized continuously.

MTTD and MTTR

Mean Time to Detect:

How quickly is a data threat detected?

Mean Time to Respond:

After the threat is detected how quickly is containment applied?

These two metrics can show the Data Security Operations maturity.

The Most Frequently Made Mistakes in Corporate Data Security

The first mistake is seeing Data Security only as DLP.

The second mistake is deploying security controls without knowing where the sensitive data is.

The third mistake is evaluating Data Classification only as a document label project.

The fourth mistake is giving all users broad permissions.

The fifth mistake is not monitoring privileged users sufficiently.

The sixth mistake is applying encryption and neglecting key management.

The seventh mistake is evaluating database activity limited only to native logs.

The eighth mistake is not carrying out remediation despite the posture being found with DSPM.

The ninth mistake is applying DLP only on e-mail.

The tenth mistake is thinking that active data threat visibility is sufficient without DDR.

The eleventh mistake is ignoring Shadow Data.

The twelfth mistake is leaving backups and DR copies outside the Data Security scope.

The thirteenth mistake is not taking AI, RAG, vector databases and Agent Memory into the Data Security scope.

The fourteenth mistake is giving AI Agents broad permissions.

The fifteenth mistake is operating Data Security tools in a silo without SIEM/SOC integration.

The sixteenth mistake is giving every security event the same risk level.

The seventeenth mistake is not defining the Data Owner responsibility.

The eighteenth mistake is establishing the security architecture once and accepting it as completed.

Corporate Data Security Checklist

• Is a Data Security Strategy present?
• Is a Data Security Policy present?
• Are the Data Owners defined?
• Has the Critical Data been determined?
• Is a Crown Jewels inventory present?
• Is Data Discovery being applied?
• Is Structured Data being scanned?
• Is Unstructured Data being scanned?
• Is Cloud Data being scanned?
• Is SaaS Data being scanned?
• Is Shadow Data being detected?
• Is Dark Data being determined?
• Is Data Classification being applied?
• Is a Public/Internal/Confidential/Restricted model present?
• Does the classification trigger security policies?
• Is IAM being applied?
• Is IGA being applied?
• Is Least Privilege being applied?
• Is Need-to-Know being applied?
• Are Access Reviews being carried out?
• Is Permission Creep being measured?
• Is Dormant Access being removed?
• Is PAM present?
• Are the privileged credentials inside a vault?
• Is JIT Access being applied?
• Is Zero Standing Privilege being evaluated?
• Is Data at Rest encrypted?
• Is Data in Transit encrypted?
• Are the Encryption Keys being managed centrally?
• Is KMS/HSM usage being evaluated?
• Is Key Rotation being applied?
• Is the backup encrypted?
• Is DLP active on the endpoint?
• Is E-Mail DLP present?
• Is Web Upload being controlled?
• Are USB controls being applied?
• Is SaaS DLP present?
• Is AI DLP being applied?
• Is DSPM monitoring the sensitive data posture?
• Is Public Sensitive Data being detected?
• Are Excessive Permissions being found with DSPM?
• Is DAM active on the critical databases?
• Is privileged SQL activity being monitored?
• Are Bulk Queries being detected?
• Is DDR being applied?
• Is DDR monitoring sensitive data behavior?
• Are Bulk Downloads being detected?
• Is Mass Retrieval being detected?
• Are Data Exfiltration use cases present?
• Is Low-and-Slow Exfiltration being monitored?
• Is DDR integrated with DLP?
• Is DDR integrated with DSPM?
• Is DDR integrated with DAM?
• Is DDR integrated with ITDR?
• Is DDR using EDR context?
• Are Insider Threat use cases present?
• Are Service Accounts being monitored?
• Are Machine Identities in the inventory?
• Is Third-Party Access being monitored?
• Is Zero Trust Data Access being applied?
• Is Continuous Authorization being evaluated?
• Is the SIEM receiving Data Security telemetry?
• Does the SOC have Data-Centric use cases?
• Does SOAR have Data Security response playbooks?
• Is Automated Session Revocation possible?
• Is Automated Upload Blocking possible?
• Are the AI Systems in the inventory?
• Is Shadow AI being detected?
• Are the RAG Data Sources in the inventory?
• Is Permission-Aware RAG being applied?
• Are Vector Databases in the Data Security scope?
• Are the AI Agent identities defined?
• Are the AI Agent permissions Least Privilege?
• Is Agent Tool Access limited?
• Is Agent Data Access limited?
• Are the Agent External Destinations being controlled?
• Is AI Agent DDR monitoring present?
• Is an AI Agent Kill Switch present?
• Are the Prompt Logs being protected?
• Is Agent Memory being protected?
• Is the AI Data Lineage known?
• Is Data Retention being applied?
• Is Secure Disposal being applied?
• Are the Data Security KPIs being measured?
• Is the MTTD being measured?
• Is the MTTR being measured?
• Is the Data Security Architecture being reviewed regularly?

Corporate Data Security Maturity Model

Level 1 – Reactive Data Security: The organization does not know exactly where the data is. Security comes into play after an event. Access and sharing controls are scattered.

Level 2 – Controlled Data Security: Data Classification, encryption, IAM and basic DLP are applied. Basic protection is created for critical data.

Level 3 – Data-Centric Security: With Data Discovery, DSPM, IGA, PAM and DAM the data location, sensitivity, access and usage become more visible. Least Privilege starts to be applied systematically.

Level 4 – Data Detection and Response: With DDR, UEBA, ITDR, SIEM and SOC integrations the runtime threats on sensitive data are detected. Human and machine identities are monitored together.

Level 5 – Adaptive Zero Trust Data Security: Classification, DSPM, IAM/PAM, DLP, DAM, DDR, AI Data Security, SIEM and SOAR share real-time risk context. Access and protection policies change dynamically according to the identity, data sensitivity, behavior and destination risk.

The maturity journey:

Know the Data

↓

Classify the Data

↓

Control Access

↓

Protect the Data

↓

Monitor the Data

↓

Detect Data Threats

↓

Respond

↓

Adapt

proceeds in this way.

Frequently Asked Questions

What is corporate data security?

Corporate data security is the whole of the technical and governance processes that ensure that the data the organization has is discovered, classified, its accesses controlled, encrypted, its movements monitored and protected against active threats.

What is a Data Security Architecture?

A Data Security Architecture is the data-centred security architecture where security layers such as Data Discovery, Classification, IAM, PAM, Encryption, DLP, DSPM, DAM, DDR, SIEM, SOC and Zero Trust work in an integrated way.

Where must a data security project start?

The first step for most organizations is the critical data being determined and Data Discovery being carried out. It is difficult to create an effective security policy for data whose location is not known.

Why is Data Classification important?

Classification determines the sensitivity level of the data and enables security controls such as encryption, access, DLP, sharing and monitoring to be applied according to the risk level.

What is DSPM?

Data Security Posture Management is the data security approach that continuously analyzes where sensitive data is, who can access it and which exposure or configuration risks are present.

What is DLP?

Data Loss Prevention is the security approach aimed at detecting and preventing sensitive data being carried in an uncontrolled way over channels such as e-mail, endpoint, USB, web, SaaS, cloud or AI.

What is DAM?

Database Activity Monitoring is the security technology that monitors the queries, logins, privilege changes, bulk exports and administrative activities carried out on the database.

What is DDR?

Data Detection and Response is the data security approach that aims to detect inside the data context the unusual access, bulk download, mass retrieval, data exfiltration and similar active threat behaviors taking place on sensitive data and to trigger response processes.

What is the difference between DSPM and DDR?

DSPM focuses predominantly on the Data Security Posture: where is the sensitive data, who can access it and what is the exposure? DDR, on the other hand, focuses on runtime behavior: is a suspicious activity taking place on the sensitive data right now?

What is the difference between DLP and DDR?

DLP mostly controls the movement of sensitive data over certain channels policy-based. DDR, on the other hand, focuses on detecting abnormal and potentially threatening behaviors by analyzing data access and usage behavior.

What is the difference between DAM and DDR?

DAM provides database activity visibility. DDR, on the other hand, tries to understand the active data threat by evaluating different data signals including database activity with behavior and sensitivity context.

If there is encryption is DLP necessary?

In most corporate environments yes. Encryption can protect stored or transmitted data but an authorized user can transfer the data outside after opening it. DLP helps to control this data movement.

If there is encryption is DAM necessary?

Encryption does not prevent authorized database queries. DAM can be used to monitor which operations authorized or privileged users carry out on the database.

What is Zero Trust Data Security?

It is the Data Security approach that aims for data access decisions to be given dynamically by continuously evaluating the identity, device, data sensitivity, behavior and risk context.

What is AI Data Security?

It is the Data Security discipline aimed at protecting the data AI components such as LLM, RAG, AI Agent, vector database, prompt logs and Agent Memory access and process.

Can DDR be used for an AI Agent?

Yes. The DDR approach can be used in detecting behaviors such as unusual bulk retrieval, unexpected repository access or external data transfer that the AI Agent carries out on sensitive data.

Must DLP, DSPM, DAM and DDR be used together?

Every organization's need is different but these technologies solve different problems. DSPM handles the data posture, DLP the data movement, DAM the database activity and DDR the runtime data threats. When they are used together more holistic Data Security visibility can be provided.

Why is the SIEM important for Data Security?

The SIEM helps to understand the whole of the incident by correlating the security events coming from different sources such as DLP, DAM, DDR, IAM, PAM, EDR and the cloud.

What does the SOC do in Data Security?

The SOC monitors data threats, investigates alerts, evaluates the identity and data context and where necessary carries out the containment and incident response processes.

Conclusion: Modern Data Security Is Not Storing the Data but Controlling the Whole Lifecycle of the Data

Corporate Data Security in the past was mostly handled over independent security controls such as encryption, database permissions and DLP.

However, modern IT environments are much more complex.

Data is no longer only inside the database.

Data:

Is in the cloud.

Is in SaaS.

Is on the endpoint.

Is in the backup.

Is in the developer environment.

Is inside Microsoft 365.

Is moving over an API.

Is in the AI prompt.

Is inside a vector database.

Is in the RAG context.

Is inside AI Agent Memory.

And not only employees access this data but:

Applications,

Service Accounts,

Third Parties,

Automation Bots,

Machine Identities

and:

AI Agents

are accessing it.

For this reason at the centre of the modern Data Security Architecture now not only the firewall or the storage but:

DATA

must be placed.

The fundamental chain of a corporate data security architecture:

Data Discovery

↓

Data Classification

↓

Data Ownership

↓

DSPM

↓

IAM / IGA / PAM

↓

Encryption / KMS

↓

DLP

↓

DAM

↓

DDR

↓

Zero Trust

↓

SIEM / SOC

↓

SOAR / Automated Response

can be thought of in this way.

In this chain the duty of every layer is different.

Data Discovery: Which data do we have?

Data Classification: How sensitive is the data?

Data Ownership: Who is responsible for this data?

DSPM: Where is the data and how exposed is it?

IAM / IGA: Who can access it?

PAM: How are the privileged accesses controlled?

Encryption: Is the data being made unreadable?

DLP: Where is the data going?

DAM: What is being done on the database?

DDR: Is there a threat behavior on the sensitive data right now?

Zero Trust: Must we still trust this access?

SIEM / SOC: What does the whole of the incident tell?

SOAR: How quickly can we intervene in the threat?

Here the essence of modern Data Security is these questions being answered not independently of each other but inside the same data context.

A user logging in at 02:00 at night on its own may not be an incident.

However:

Identity Risk = High

Data Classification = Restricted

Bulk Database Query

25,000 File Download

External Cloud Upload

when it is so a completely different security picture appears.

Data-Centric Security aims to create this picture.

Together with AI this model is becoming even more important.

Because the data access chain of the future will not be only:

Human → Application → Data

it will not be this.

The new model:

Human → AI Agent → Tool → API → Application → Data

and even:

AI Agent → AI Agent → Tool → Data

can proceed in this way.

For this reason the Data Security Architecture of the future has to cover not only human users but the whole of Human + Machine + AI identities.

The ultimate goal of corporate data security is not to lock all the data.

Excessive security can make the business unable to work.

The real goal is:

To ensure that the right identity, at the right time, under the right device and risk conditions, for the right purpose, accesses only the necessary sensitive data with the necessary minimum authorization; that the data is protected throughout its lifecycle; that all critical data activities are visible; and that when abnormal behavior takes place the threat can be detected as early as possible before the data is taken outside and intervened in.

For this reason if it is necessary to summarize the whole of the series in a single sentence:

Modern Corporate Data Security is a continuous, data-centred and risk-based security architecture that finds sensitive data with Data Discovery, makes sense of it with Data Classification, makes the exposure visible with DSPM, manages the access with IAM/IGA/PAM, protects the data with Encryption, controls the data movement with DLP, monitors the database activities with DAM, detects active data threats with DDR, verifies the access continuously with Zero Trust and analyzes and intervenes in the events with SIEM/SOC/SOAR.