How to Find Where Personal Data Lives Across Your AWS Infrastructure

Ask an engineering team where customer personal data lives in AWS and you will usually get a short answer.

RDS.

Maybe S3.

Possibly DynamoDB.

Then someone checks the architecture diagram.

Then someone remembers the warehouse.

Then someone mentions CloudWatch.

Then somebody says:

"We also have an old export bucket."

This is the problem.

Personal data is not stored in one AWS service.

It spreads across application databases, replicas, backups, object storage, logs, analytics pipelines, test environments, exports and temporary files.

A DPDP data map built from architecture diagrams alone will miss some of it.

Our broader DPDP data mapping guide covers the full discovery problem. This article focuses specifically on how an engineering team can find personal data across AWS.

Start with the AWS surface

Before scanning for PII, inventory the places where PII can exist.

At minimum:

• RDS
• Aurora
• DynamoDB
• Redshift
• OpenSearch
• S3
• EBS snapshots
• RDS snapshots
• AWS Backup
• CloudWatch Logs
• CloudTrail
• Lambda logs
• ECS / EKS workloads
• SQS / SNS payloads
• Kinesis streams
• Glue jobs and catalogs
• Athena results
• Secrets Manager
• Parameter Store
• Staging and development accounts

You do not need to assume every service contains personal data.

You do need a process for proving which ones do.

Step 1: Find the source systems

Start with systems of record.

Typical examples:

RDS PostgreSQL
RDS MySQL
Aurora
DynamoDB

For each database:

• List schemas
• List tables
• List columns
• Identify primary identifiers
• Identify columns likely to contain personal data
• Identify foreign-key relationships
• Identify JSON and unstructured fields

The first scan should use schema intelligence, not only content matching.

If the schema contains:

email
phone
aadhaar_number
pan_number
date_of_birth

you already have useful signals before reading a record.

Step 2: Scan by column name

Column names are a high-signal discovery technique.

Examples:

email
mobile
phone
full_name
address
dob
date_of_birth
aadhaar
pan
passport
upi
account_number
customer_id

Build an India-aware taxonomy.

Identity

• Aadhaar-related identifiers
• PAN
• Passport
• Voter ID

Contact

• Email
• Mobile
• Address

Financial

• Bank account information
• UPI identifiers
• Payment references

Location

• GPS coordinates
• Address

Technical and behavioural

• IP address
• Device identifiers
• Session identifiers
• Event identifiers

Then add context.

A customer_id may not be personal data by itself.

It becomes personal data when it can be linked to an identifiable individual.

Step 3: Use value-level detection

Schema names are not enough.

A column called:

metadata

can contain an entire customer profile.

A JSON field might contain:

{
  "name": "Asha Rao",
  "phone": "9876543210",
  "pan": "ABCDE1234F"
}

A notes field might contain:

Customer called from 9876543210 and provided a new address.

You need value-level detection for ambiguous and unstructured fields.

Use a combination of:

• Pattern matching
• Structured validation
• Entity recognition
• Sampling
• Context-aware classification

Do not rely on one detector.

Step 4: Scan S3 properly

S3 is where many data maps break.

It is often treated as:

"File storage."

It is actually a collection of data stores with different lifecycles and owners.

Inventory:

• Bucket
• Region
• Tags
• Prefixes
• File types
• Lifecycle rules
• Encryption
• Access controls
• Versioning
• Replication
• Cross-account access

Then identify likely personal-data files:

• CSV
• JSON
• Parquet
• Avro
• XLSX
• PDF
• DOCX
• Images
• Exports
• Backups
• Reports

Do not scan every object at full depth immediately.

Start with metadata and sampling.

Then deepen scanning where risk is high.

Step 5: Find the exports nobody remembers

Search specifically for names containing:

export
backup
dump
customer
users
kyc
transactions
report
analytics
snapshot

Common examples:

s3://company-prod-exports/
s3://company-old-migration/
s3://analytics-daily/
s3://support-export/
s3://legacy-backups/

The highest-risk bucket is often not the main production bucket.

It is the one created for a one-time migration and never deleted.

Step 6: Scan CloudWatch and application logs

Logs are frequently overlooked.

A request may contain:

email
phone
user_id
address
request body
response body

The logging system then stores it.

Inventory:

• CloudWatch log groups
• Retention periods
• Application logs
• API Gateway logs
• Lambda logs
• ECS container logs

The final DPDP Rules require specified personal data, traffic data and logs used for the listed security purposes to be retained for at least one year, after which they are to be erased unless another law requires longer retention. DPDP Rules 2025

That does not mean every log should be retained forever.

It means you need deliberate log-retention architecture.

Step 7: Inspect analytics pipelines

A common architecture:

Application
   ↓
Event tracking
   ↓
Kinesis / streaming
   ↓
S3 / Redshift
   ↓
BI / dashboards

The production database may be well governed.

The analytics pipeline may not be.

Search for:

• user_id
• email
• device_id
• IP
• location
• event metadata
• free-text payloads

Then ask whether the data is actually necessary.

Analytics is one of the easiest places for personal data to accumulate because adding instrumentation is easy.

Step 8: Scan backups and snapshots

A database can be clean while its snapshots still contain the old data.

Inventory:

• RDS snapshots
• EBS snapshots
• AWS Backup
• Cross-region copies
• Cross-account copies
• Long-term archives

Then document how deletion is handled.

You may not be able to surgically rewrite every historical backup.

That makes it even more important to define a controlled backup strategy and prevent deleted data from simply reappearing in active environments after restoration.

Step 9: Check non-production

This is one of the biggest blind spots.

Production data gets copied into:

staging
QA
development
local
data science
demo

Then nobody remembers.

Scan:

• Staging databases
• QA databases
• Developer snapshots
• Shared exports
• Local fixtures
• Test S3 buckets

The best fix is not "scan more."

It is:

stop copying raw production personal data into environments that do not need it.

Use:

• Synthetic data
• Masked data
• Tokenised data
• Minimized datasets

Where production data is genuinely required, document why.

Step 10: Inspect IAM

Knowing where PII exists is only half the problem.

Know who can access it.

For every major data store, ask:

• Who can read?
• Who can write?
• Who can export?
• Who can administer?
• Is access role-based?
• Are shared credentials used?
• Are access events logged?
• Are privileged actions reviewed?

Rule 6 requires appropriate access controls and visibility into access through logs, monitoring and review. DPDP Rules 2025

Discovery without access context gives you an incomplete risk picture.

Step 11: Connect the AWS finding to business context

Finding:

prod-db.customer_profiles.email

is only the beginning.

Add:

Purpose:
Account communication

Data Principal:
Customer

Processor:
Email provider

Retention:
Purpose-based / applicable requirement

Erasure:
Account deletion workflow

Owner:
Platform team

That is what turns a technical scan into a DPDP data map.

A practical AWS discovery stack

You can build discovery from four layers.

AWS-native signals

Discover:

• Accounts
• Regions
• Resources
• Buckets
• Databases
• Logs
• IAM
• Snapshots

Content discovery

Inspect:

• Database schemas
• Representative rows
• Object samples
• Logs
• Exports

PII detection

Combine:

• Column heuristics
• Pattern matching
• India-specific identifier validation
• NER for unstructured text

Context enrichment

Attach:

• Purpose
• Ownership
• Processor
• Retention
• Deletion mechanism

The strength is in combining all four.

A simple architecture

AWS Accounts
     │
     ├── RDS / Aurora
     ├── DynamoDB
     ├── S3
     ├── Redshift
     ├── CloudWatch
     ├── Backup
     └── Analytics
           │
           ↓
      Discovery Layer
           │
     ┌─────┼─────┐
     ↓     ↓     ↓
 Schema  Pattern  NER
 Scan    Scan     Scan
     └─────┼─────┘
           ↓
       PII Findings
           ↓
     Business Context
           ↓
       Data Inventory
           ↓
      DPDP Workflows

What not to do

Don't scan once and stop.

Infrastructure changes.

Don't scan only production.

Backups and non-production often contain forgotten copies.

Don't scan only column names.

Unstructured data will defeat you.

Don't treat every match as a violation.

A technical finding needs business context.

Don't dump findings into a spreadsheet and declare victory.

The output needs ownership, action and lifecycle.

The self-test

Take one real user.

Ask:

1. Can you identify every AWS resource that may contain their personal data?
2. Can you identify copies in analytics?
3. Can you identify copies in logs?
4. Can you identify relevant backups and snapshots?
5. Can you identify non-production copies?
6. Can you identify who can access those systems?
7. Can you explain the purpose of every material copy?
8. Can you describe how the data would be deleted or retained?

If engineers need to manually search five AWS accounts to answer these questions, the discovery process is not operational yet.

Where Privra fits

Privra continuously discovers personal data across infrastructure instead of relying on a one-time spreadsheet.

For AWS environments, that means finding PII across databases, storage, analytics, logs, backups and supporting systems, then attaching the business context needed to turn those findings into DPDP remediation.

The objective is not to produce a giant list of PII.

It is to answer:

Where does our personal data live right now, and what should happen to it?

Talk to Privra about continuous data discovery.

This article is general information, not legal advice. Legal requirements and Privra's recommended implementation practices are intentionally distinguished.