Overview
Data Classification and Handling is the process of identifying, labeling, and applying handling requirements to company data based on its sensitivity and access risk. It ensures that access controls and protection measures align with SOC 2 CC6 requirements for logical access and data protection.
Step-by-Step Process
Define data classification scheme
The Security Lead defines the official data classification levels (e.g., Public, Internal, Confidential, Restricted) and associated handling requirements. The output is an approved data classification standard aligned to SOC 2 CC6.5 and CC6.7.
Role: Security Lead
Identify in-scope data types
The Security Lead, with input from system owners, identifies data types processed, stored, or transmitted by the organization, including customer data and credentials. The output is an inventory of in-scope data types mapped to systems.
Role: Security Lead
Classify data by sensitivity
System owners assign a classification level to each data type based on confidentiality and access risk criteria. The output is a completed data classification register with owner and classification fields populated.
Role: System Owner
Define handling and access rules
The Security Lead documents handling requirements for each classification, including access restrictions, encryption, storage, and sharing rules. The output is a data handling matrix linked to access control standards.
Role: Security Lead
Implement access controls
IT or system owners configure logical access controls in systems to enforce the defined handling rules. The output is system configurations that restrict access based on data classification.
Role: IT Manager
Communicate and train employees
The Security Lead publishes the classification policy and notifies employees of their responsibilities for handling data. The output is a dated communication or training record acknowledging awareness.
Role: Security Lead
Review and update classifications annually
The Security Lead reviews data classifications and handling rules at least annually or upon major system changes. The output is an updated classification register with review date and approver noted.
Role: Security Lead
What You Need Before Starting
- Approved information security policy
- List of systems and applications in scope for SOC 2
- Access to data inventory or system architecture documentation
- Administrative access to documentation or GRC tools
Evidence Your Auditor Expects
- Data classification policy document with approval date
- Completed data classification register showing classifications and last review date
- Screenshot of system access settings enforcing classification-based restrictions (timestamp visible)
- Employee communication or training record dated within the audit period
How This Looks In Your Tools
Drata
In Drata, navigate to Controls > CC6 and select the control related to Data Classification or Data Handling. Open the control and click Evidence > Upload Evidence to attach the data classification policy and register.
Go to Policies > Information Security to ensure the data classification policy is marked as Approved and shows an approval date. Use the Systems tab to link systems to data types and add notes describing applied classifications.
During annual review, update the evidence by clicking Replace Evidence and uploading the revised register with the current review date, ensuring the control status remains “Implemented.”
Confluence
In Confluence, go to the Security or Compliance space and create a page titled “Data Classification and Handling Policy.” Use a table to define classification levels and handling rules, then publish the page.
Create a child page called “Data Classification Register” and list data types, systems, owners, and classifications. Use Page Properties to record the last review date and approver.
Use the Page History feature to show annual review activity and export the page to PDF for audit evidence, ensuring the export date is visible.
Spreadsheet
Create a spreadsheet with tabs for “Classification Scheme” and “Data Classification Register.” Include columns for data type, system, owner, classification level, and last reviewed date.
Store the spreadsheet in a controlled-access location (e.g., SharePoint or Google Drive) and restrict editing to the Security Lead. Use file version history to track updates.
For annual review, update the review date column and save a PDF copy with the current date to an audit evidence folder.
Common Audit Findings
- Data not formally classified
- This occurs when organizations rely on informal knowledge rather than documented classifications. Prevent it by maintaining a centralized, approved classification register reviewed annually.
- Handling rules not enforced in systems
- Auditors find this when documented rules do not match actual access configurations. Prevent it by validating system access settings against the handling matrix during reviews.
- No evidence of annual review
- This happens when updates are made but not dated or approved. Prevent it by recording review dates and approvers directly in the register or tool.
- Employees unaware of data handling expectations
- This results from policies not being communicated or acknowledged. Prevent it by sending annual communications or training and retaining dated proof.