1. Purpose
The purpose of this Data Inventory Template is to help the organization identify, document, classify, understand, and manage the information and data it collects, processes, stores, transfers, shares, and deletes.
A data inventory helps the organization answer:
- What data do we have?
- Where does it come from?
- Where is it stored?
- Who uses it?
- Why do we use it?
- Who can access it?
- Who do we share it with?
- How long do we retain it?
- What security protections are applied?
- What risks and regulatory requirements apply?
The inventory should support both information security risk management and, where applicable, privacy and regulatory compliance.
2. Scope
The inventory may cover:
- Customer data
- Employee data
- Applicant data
- Supplier/vendor data
- Financial information
- Authentication information
- Business information
- Source code and technical information
- Security logs
- Audit information
- Contracts
- Marketing information
- Support information
- Application data
- Database records
- Cloud storage
- Backup data
- Data processed by SaaS applications
- Data processed by third parties
- Paper or physical records where relevant
The level of detail should be proportionate to the organization’s size, complexity, risks, and applicable requirements.
3. Data Inventory Record
Each significant data set or data category should have a record.
| Field | Description |
|---|---|
| Data ID | Unique identifier |
| Data/Information Name | Name of the data set |
| Data Category | Customer, employee, financial, technical, etc. |
| Description | What the data contains |
| Business Process | Process using the data |
| Data Owner | Person responsible for the data |
| System/Application | Application processing the data |
| Storage Location | Database, cloud storage, SaaS, physical location, etc. |
| Data Source | Where the data originates |
| Data Subjects/Individuals | Customers, employees, suppliers, users, etc. |
| Information Classification | Public/Internal/Confidential/Restricted, or organizational scheme |
| Personal Data | Yes/No |
| Sensitive Data | Yes/No, based on applicable definition |
| Customer Data | Yes/No |
| Financial Data | Yes/No |
| Security/Credential Data | Yes/No |
| Criticality | Critical/High/Medium/Low |
| Confidentiality Requirement | Low/Medium/High |
| Integrity Requirement | Low/Medium/High |
| Availability Requirement | Low/Medium/High |
| Processing Purpose | Why the data is used |
| Access Roles | Who can access it |
| Privileged Access | Yes/No |
| Internal Sharing | Departments/users receiving data |
| External Sharing | Third parties receiving data |
| Third-Party Processor | Relevant supplier |
| Data Location | Country/region/cloud region |
| Data Transfer | Cross-border transfer, if applicable |
| Encryption | At rest/in transit/other |
| Authentication/Access Control | Security controls |
| Logging/Monitoring | Relevant monitoring |
| Backup | Backup requirements |
| Retention Period | How long data is retained |
| Disposal Method | How data is deleted/destroyed |
| Related Asset ID | Link to Asset Inventory |
| Related Risk ID | Link to Risk Register |
| Related Requirement | Legal/regulatory/contractual requirement |
| Related Control | Relevant security/privacy control |
| Last Reviewed | Date |
| Next Review | Date |
| Status | Active/Archived/Deleted/etc. |
| Evidence/Reference | Supporting record |
4. Data Categories
Organizations should define categories appropriate to their business.
Example
| Data Category | Examples |
|---|---|
| Customer Data | Customer name, account details, support information |
| Employee Data | Employee records, payroll information |
| Authentication Data | User IDs, authentication metadata |
| Financial Data | Invoices, payment records |
| Technical Data | IP addresses, system configurations |
| Security Data | Logs, alerts, security events |
| Business Data | Contracts, proposals, business plans |
| Source Code | Application source code and repositories |
| Supplier Data | Supplier contacts and contracts |
| Marketing Data | Leads, campaign information |
| Audit Data | Audit evidence and assessment records |
5. Data Classification
Each data set should be assigned an appropriate classification.
For example:
| Classification | Typical Example | Protection |
|---|---|---|
| Public | Public website content | Basic integrity protection |
| Internal | Internal procedures | Authorized employee access |
| Confidential | Customer information | Restricted access and appropriate encryption |
| Restricted | Credentials, encryption keys | Strong access controls and enhanced protection |
These classification levels are examples. The organization should define its own classification scheme and handling requirements.
6. Data Owner
Every important data set should have an accountable owner.
The Data Owner should be responsible for:
- Understanding the purpose of the data.
- Confirming business use.
- Determining appropriate classification.
- Identifying authorized users.
- Supporting risk assessment.
- Defining retention requirements.
- Reviewing access requirements.
- Supporting data deletion/archiving decisions.
- Ensuring the inventory remains accurate.
The Data Owner does not necessarily perform the technical administration of the data.
7. Data Source
The organization should document where data originates.
Possible sources include:
- Customer registration
- Website forms
- Mobile applications
- APIs
- Employees
- Suppliers
- Business partners
- Public sources
- Customer integrations
- Internal systems
- Cloud services
- Third-party SaaS applications
Example
Customer email address
Source → Customer signup form
↓
Application → SaaS platform
↓
Database → AWS RDS
↓
Support → Customer support platform
↓
Backup → AWS backup environment
8. Data Flow
Where appropriate, document how important data moves through the organization.
A simple data flow may be:
Customer → Web Application → API → AWS Application → RDS → Backup → Support SaaS
For more sensitive or complex processing, maintain a formal Data Flow Diagram.
The data inventory should identify the relevant systems and services involved in the flow.
9. Data Storage Location
Record where data is stored.
Examples:
- AWS RDS
- Amazon S3
- Azure SQL
- Google Cloud Storage
- Microsoft 365
- GitHub
- Salesforce
- HR platform
- Customer support platform
- Employee laptop
- Physical records
For cloud environments, consider recording:
- Cloud provider
- Account/subscription
- Region
- Service
- Environment
- Storage type
10. Data Processing Purpose
The organization should document why the data is processed.
Examples:
| Data | Purpose |
|---|---|
| Customer account information | Provide SaaS service |
| Customer support information | Resolve support requests |
| Employee information | Employment administration |
| Security logs | Security monitoring and investigation |
| Payment information | Billing and payment processing |
| Marketing contact information | Marketing communications |
| Authentication information | User authentication and account security |
The purpose should be sufficiently specific to understand the business need.
11. Access and Use
Document who can access important data.
Example:
| Data | Users/Roles | Access |
|---|---|---|
| Customer database | Engineering/DBA | Privileged |
| Customer support data | Support Team | Business access |
| Employee records | HR | Restricted |
| Security logs | Security Team | Restricted |
| Source code | Engineering | Authorized developers |
| Financial records | Finance | Restricted |
Access should follow:
Need-to-Know → Least Privilege → Authorized Access → Periodic Review
12. Data Sharing
Identify internal and external data sharing.
Internal Sharing
Examples:
- Engineering
- Finance
- HR
- Customer Support
- Security
- Management
External Sharing
Examples:
- Cloud providers
- SaaS providers
- Payment providers
- Auditors
- Consultants
- Customers
- Regulators
- Government authorities
- Business partners
For significant third-party sharing, record the applicable supplier/security/privacy requirements.
13. Third-Party Data Processing
Where a supplier or service provider processes organizational data, record:
- Supplier
- Service
- Data processed
- Purpose
- Data classification
- Data location
- Security assessment
- Contract
- Data processing agreement, where applicable
- Incident notification requirements
- Retention
- Deletion/return requirements
- Supplier review date
Example
Customer Support SaaS
Customer name, email address, support tickets and attachments
↓
Customer Support Platform
↓
Third-party processor
↓
Support team access
The SaaS Application Register and Supplier Security Assessment should contain the corresponding supplier information.
14. Data Location and Cross-Border Transfer
Where relevant, record where data is stored or processed.
Example:
| Data | Provider | Region | Cross-Border Processing |
|---|---|---|---|
| Customer Data | AWS | Mumbai | No |
| Customer Support | SaaS Provider | United States | Yes |
| Employee Data | HR Platform | India | No |
| Source Code | GitHub | Provider-controlled | Review required |
Cross-border transfer requirements depend on the applicable laws, contractual commitments, data type, and jurisdictions involved.
The data inventory should therefore identify potential transfers rather than assuming that every transfer is prohibited or permitted.
15. Data Security Controls
For important data sets, record applicable security controls.
Examples include:
- Encryption at rest
- Encryption in transit
- MFA
- RBAC
- Least privilege
- Network restrictions
- Backup
- Logging
- Monitoring
- DLP
- Data masking
- Tokenization
- Secure deletion
- Vulnerability management
- Access reviews
Example
Customer Database
Classification → Confidential
↓
Encryption → Enabled
↓
Access → RBAC
↓
Privileged Access → MFA
↓
Monitoring → CloudTrail/CloudWatch and database monitoring
↓
Backup → Automated backup
↓
Review → Periodic access/security review
16. Data Retention
The organization should define appropriate retention periods based on:
- Business requirements
- Legal requirements
- Regulatory requirements
- Contractual requirements
- Security requirements
- Operational requirements
Example:
| Data | Retention | Reason |
|---|---|---|
| Customer account data | Defined by service/business requirement | Service delivery |
| Security logs | Defined by security requirements | Monitoring/investigation |
| Employee records | Defined by applicable requirements | Employment administration |
| Contracts | Defined by legal/business requirements | Legal/business record |
| Temporary files | Short-term | Operational need |
Retention periods should not be copied from generic templates without confirming their applicability.
17. Data Disposal
When data reaches the end of its retention period, the organization should determine whether it should be:
- Deleted
- Anonymized
- Archived
- Returned
- Securely destroyed
Disposal should consider:
- Primary systems
- Backups
- Replicas
- Archives
- SaaS platforms
- Third-party processors
- Physical media
Evidence may include:
- Deletion logs
- System records
- Supplier deletion confirmation
- Disposal certificates
- Approved deletion tickets
18. Data Lifecycle
A practical data lifecycle is:
Collect/Create → Classify → Store → Use → Share → Monitor → Retain → Archive/Delete → Verify
For sensitive information:
Identify → Classify → Protect → Access → Monitor → Retain → Securely Dispose
The lifecycle should be connected to the organization’s asset lifecycle and information security processes.
19. AWS SaaS Example
Consider a SaaS company providing a customer analytics platform.
Data Set
Customer Account Data
| Field | Example |
|---|---|
| Data ID | DATA-001 |
| Data | Customer account information |
| Source | Customer registration |
| System | SaaS application |
| Storage | AWS RDS |
| Classification | Confidential |
| Owner | Customer Operations/Business Owner |
| Technical Custodian | Engineering |
| Criticality | High |
| Personal Data | Yes, where applicable |
| Access | Support + authorized operations |
| Privileged Access | Engineering/DBA |
| Encryption | Enabled |
| Backup | Automated |
| Monitoring | Security monitoring |
| Third Parties | Relevant cloud/SaaS providers |
| Retention | Defined by applicable business/legal requirements |
| Disposal | Secure deletion |
| Related Risk | R-001 |
| Related Asset | AST-001 |
| Review | Periodic |
20. Data Inventory vs Asset Inventory
These records are related but serve different purposes.
| Asset Inventory | Data Inventory |
|---|---|
| What assets exist? | What data exists? |
| Servers | Customer data |
| Applications | Employee data |
| Cloud resources | Financial data |
| Laptops | Security logs |
| SaaS applications | Support information |
| Network infrastructure | Source/business information |
| Security systems | Personal/sensitive information |
Example:
Asset: AWS RDS database
Data: Customer account information stored in that database
Therefore:
Data → Stored/Processed by Asset → Protected by Controls
21. Data Inventory and Risk Management
The Data Inventory should feed into the organization’s risk management process.
Example:
Customer Data
↓
Stored in AWS RDS
↓
Confidential
↓
Unauthorized access risk
↓
MFA + RBAC + encryption + monitoring + access reviews
↓
Risk Register
↓
Risk treatment
↓
Evidence
This helps ensure that security controls are based on actual information and business risks.
22. Data Inventory and Privacy
Where personal data is involved, the Data Inventory can support privacy activities such as:
- Data mapping
- Records of processing
- Privacy impact assessments
- Data subject rights processes
- Retention management
- Processor management
- Data transfer assessments
- Breach response
- Privacy notices
However, a Data Inventory is not automatically the same thing as a Record of Processing Activities (RoPA).
A RoPA may require additional privacy-specific information depending on the applicable law.
23. Data Inventory Review Process
The inventory should be reviewed:
- Periodically
- When new applications are introduced
- When new data is collected
- When business processes change
- When systems are migrated
- When suppliers change
- When data locations change
- After significant incidents
- When legal/regulatory requirements change
- Before retiring significant systems
Review Workflow
Identify Change → Assess Data Impact → Update Inventory → Review Security/Privacy Requirements → Update Risk/Controls → Approve Where Required → Retain Evidence
24. Data Discovery and Reconciliation
The organization should periodically compare the Data Inventory against actual systems.
For example:
Data Inventory
Customer data → AWS RDS
Actual Environment
AWS RDS
S3
Customer Support SaaS
Analytics Platform
Backup Environment
If the organization discovers customer data being stored in an additional system, the inventory should be updated and the new processing/storage location assessed.
25. Shadow Data
The organization should consider the possibility of data being stored outside approved systems.
Examples:
- Employee using personal cloud storage
- Customer data copied into spreadsheets
- Production data copied to development
- Customer information stored in an unauthorized AI tool
- Sensitive information shared through personal messaging applications
A practical process is:
Detect → Identify Data → Assess Risk → Restrict/Approve → Move/Delete → Update Inventory → Monitor
26. Data in Development and Test Environments
Production data should not automatically be copied into development or testing environments.
Before using production data in non-production environments, consider:
- Business justification
- Data classification
- Privacy requirements
- Access restrictions
- Masking/anonymization
- Security controls
- Retention
- Deletion
Where possible, use synthetic or appropriately anonymized test data.
27. Backup Data
Backups should also be considered in the Data Inventory where relevant.
Document:
- What data is backed up
- Backup location
- Backup owner
- Retention period
- Encryption
- Access restrictions
- Recovery requirements
- Supplier/cloud provider
- Secure deletion requirements
Deleting data from a production database does not necessarily mean that all backup copies have immediately disappeared.
28. Data Inventory Roles
Data Owner
- Defines business purpose.
- Confirms data classification.
- Supports access decisions.
- Supports retention requirements.
- Reviews the data record.
System/Application Owner
- Identifies where data is processed.
- Ensures appropriate technical controls.
- Supports system changes.
Security/ISMS Manager
- Ensures security requirements are considered.
- Links data to risk management.
- Supports reviews and audits.
Privacy/Legal
Where applicable:
- Determines privacy/legal requirements.
- Reviews processing activities.
- Supports data transfer and retention requirements.
- Advises on regulatory obligations.
IT/Cloud/Engineering
- Maintains technical information.
- Implements security controls.
- Supports data discovery and deletion.
Employees
- Handle organizational data according to security and privacy requirements.
- Report unauthorized data storage or sharing.
29. Audit Evidence
An auditor may select a data set and trace:
Data → Owner → Classification → System → Storage → Access → Security Controls → Risk → Retention → Disposal
Possible evidence includes:
- Data Inventory
- Asset Inventory
- Data Flow Diagram
- Access reviews
- Risk Register
- Security configurations
- Encryption configuration
- Backup records
- Supplier assessments
- Contracts
- Retention schedules
- Deletion records
- Privacy assessments
- Incident records
- Internal audit records
30. Common Mistakes
Mistake 1 — Creating a list of data without locations
Knowing that “customer data” exists is not enough. The organization should understand where it is stored and processed.
Mistake 2 — Ignoring third-party systems
Customer or employee data may exist in SaaS platforms, cloud services, support systems, and external processors.
Mistake 3 — Treating the inventory as a one-time exercise
Data environments change continuously.
Mistake 4 — Not identifying owners
Important data should have accountable ownership.
Mistake 5 — Ignoring backups
Data may continue to exist in backup systems after deletion from primary systems.
Mistake 6 — Mixing production and test data
Production data in development environments can introduce significant security and privacy risks.
Mistake 7 — Assuming all data requires the same protection
Protection should be proportionate to classification, risk, business value, and applicable requirements.
Mistake 8 — Confusing Data Inventory with RoPA
A data inventory supports privacy management but may not contain all information required for a formal RoPA.
31. Startup-Friendly Minimum Data Inventory
A startup can begin with a simple spreadsheet containing:
| Data ID | Data | Owner | System | Location | Classification | Personal Data | Users | Third Party | Retention | Risk | Status |
|---|---|---|---|---|---|---|---|---|---|---|---|
| DATA-001 | Customer Account Data | Operations | SaaS App | AWS RDS | Confidential | Yes | Support/Engineering | AWS | Defined | R-001 | Active |
| DATA-002 | Employee Records | HR | HR SaaS | SaaS Provider | Confidential | Yes | HR | HR Provider | Defined | R-002 | Active |
| DATA-003 | Source Code | Engineering | GitHub | Cloud | Confidential | No | Engineering | GitHub | Business requirement | R-003 | Active |
| DATA-004 | Security Logs | Security | SIEM | Cloud | Confidential | Possible | Security | SIEM Provider | Defined | R-004 | Active |
The inventory can later be integrated into a GRC, privacy management, CMDB, or data discovery platform as the organization grows.
32. Quick Data Inventory Checklist
| Check | Yes/No | Evidence |
|---|---|---|
| Is important organizational data identified? | ||
| Is the data owner assigned? | ||
| Is the source of data documented? | ||
| Is the processing purpose documented? | ||
| Is the data classification defined? | ||
| Is the system/application identified? | ||
| Is the storage location known? | ||
| Are data flows understood where necessary? | ||
| Are authorized users identified? | ||
| Are third-party processors identified? | ||
| Are external sharing arrangements documented? | ||
| Is data location known? | ||
| Are security controls identified? | ||
| Is encryption addressed where appropriate? | ||
| Are backup requirements understood? | ||
| Is retention defined? | ||
| Is secure disposal defined? | ||
| Are related risks identified? | ||
| Are applicable legal/regulatory requirements identified? | ||
| Is the inventory periodically reviewed? | ||
| Is the inventory updated after significant changes? |
33. Relationship with Other ISMS Documents
The Data Inventory should connect with:
Information & Asset Inventory
→ What assets process or store the data?
Asset Ownership Register
→ Who owns the asset?
Asset Classification Procedure
→ How is the information classified?
Risk Assessment
→ What could happen to the data?
Risk Treatment Plan
→ What protection is required?
Access Control Policy
→ Who can access the data?
SaaS Application Register
→ Which third-party applications process the data?
Supplier Security Assessment
→ How are external processors assessed?
Data Retention/Deletion Procedure
→ How long is data retained and how is it deleted?
Incident/Breach Response
→ What happens if the data is compromised?
Privacy/RoPA Records
→ What additional privacy information is required?
The overall relationship is:
Data → Owner → Classification → Location → Processing → Access → Sharing → Risk → Controls → Retention → Disposal → Evidence
34. Final Principle
A useful Data Inventory should allow the organization to answer five basic questions:
What data do we have?
Where is it?
Who uses it?
How is it protected?
When and how is it removed?
The practical lifecycle is:
Discover → Identify → Classify → Map → Assess → Protect → Monitor → Retain → Review → Delete → Verify → Improve
The objective is not to create an unnecessarily large spreadsheet. The objective is to maintain enough visibility to understand the organization’s important information, its movement through systems and suppliers, its security risks, and the controls required to protect it.