Data Classification
Overview
Data classification is a foundational security practice that establishes clear guidelines for handling different types of information. MenoTime uses a four-tier classification system that determines access controls, encryption requirements, retention policies, and disposal procedures.
Key Principle: Classify all data at creation or import. Handle each classification level according to its requirements.
Classification Levels
MenoTime data is classified into four categories based on sensitivity and regulatory requirements:
1. Public
Definition: Information that can be freely shared and does not require confidentiality.
Examples: - Marketing materials and brochures - Published research papers and blog posts - General company news and announcements - Product documentation - Public API specifications - Educational content (non-proprietary)
Sensitivity: Low Business Impact if Compromised: Minimal
Handling Requirements: - No encryption required - Can be shared externally without approval - Can be published on public websites - No need for access controls - Open-source licensing permissible
Storage Location: - Public websites - GitHub public repositories - AWS S3 public buckets - Email without restrictions
2. Internal
Definition: Information that is confidential to MenoTime but does not contain patient data or highly sensitive business secrets.
Examples: - Employee directory and contact information - Internal documentation and wiki articles - Meeting notes (non-confidential) - Code repositories (non-critical) - Internal processes and procedures - Vendor contracts and pricing (non-sensitive) - Internal financial reports - Sales and marketing materials (internal only)
Sensitivity: Medium Business Impact if Compromised: Moderate
Handling Requirements: - Encryption at rest (standard encryption sufficient) - Encryption in transit (HTTPS/TLS 1.2+) - Access limited to MenoTime employees only - Must have confidentiality agreement in place - Cannot be shared with external parties without approval - Should not be published to public repositories
Storage Location: - Internal wikis and documentation systems - GitHub private repositories - Shared drives with access controls - Internal communication tools (Slack, Teams) - AWS S3 private buckets with encryption
Retention: Per data type (typically 1-3 years after last use) Disposal: Standard deletion or data shredding
3. Confidential
Definition: Business-critical information that must be protected from unauthorized access.
Examples: - Source code for proprietary features - Architectural designs and system specifications - API keys and credentials (should be in Secrets Manager instead) - Business strategy and competitive analysis - Customer lists and contact information - Pricing strategies and financial projections - Partnership agreements - Security audit reports and vulnerability assessments - Database schemas and infrastructure configurations - Internal security policies and procedures
Sensitivity: High Business Impact if Compromised: Serious
Handling Requirements: - Encryption at rest: AES-256 with customer-managed KMS keys - Encryption in transit: TLS 1.2+ with certificate pinning for sensitive connections - Access control: Multi-factor authentication (MFA) required - Least privilege: Users have access only to data they need - Logging: All access logged and audited - Data retention: Strictly limited duration (delete when no longer needed) - Third-party sharing: Prohibited without legal approval and Data Processing Agreement - Destruction: Cryptographic shredding or secure wiping required - Employee access: Subject to role-based restrictions
Storage Location: - AWS Secrets Manager (for credentials) - Encrypted storage with KMS - Private GitHub repositories with branch protection - Restricted-access filing systems (Google Drive, OneDrive) - Password-protected documents
Access Control: - Read: Only necessary employees and contractors - Write: Limited to system owners or administrators - Delete: Only authorized administrators
Retention: Until no longer business necessary (typically 3-7 years) Disposal: Cryptographic deletion; AWS S3 secure delete; document shredding
4. Restricted (PHI - Protected Health Information)
Definition: Patient health information and other highly sensitive regulated data that requires maximum protection under HIPAA and other privacy laws.
Examples: - Patient names, medical record numbers, health plan IDs - Diagnoses, symptoms, treatment plans, medications - Lab results, imaging reports, clinical assessments - Dates of service and appointment schedules - Contact information (email, phone) linked to patient identity - Insurance information and claims data - Genetic or biometric data linked to patients - Menopause severity scores or other patient identifiers - De-identified data linked to re-identification codes - Patient-submitted forms and consent documents - Audio/video recordings of patient consultations
Sensitivity: Extremely High Business Impact if Compromised: HIPAA breach, regulatory penalties, loss of trust, legal liability
Handling Requirements:
Authentication & Access Control: - Multi-factor authentication (MFA) required - Role-based access control (RBAC) enforced - Only users with PHI access authorization can retrieve data - Service-to-service IAM authentication - Database access via IAM database authentication (no passwords) - Principle of least privilege strictly enforced - Quarterly access reviews to validate necessity - Offboarding: Access revoked within 24 hours of employee termination
Encryption: - At rest: AES-256 encryption with KMS key rotation (annual minimum) - In transit: TLS 1.2+ only (no HTTP, no unencrypted protocols) - Encryption keys: Customer-managed KMS keys, never AWS-managed keys - Key rotation: Automatic annual rotation; manual rotation upon suspected compromise
Audit & Monitoring: - CloudTrail: All API calls and access attempts logged - CloudWatch: Real-time monitoring for unauthorized access attempts - Database audit logs: pgAudit for all PHI database operations - Log retention: Minimum 12 months for compliance audits - Alert triggers: Alerts for batch PHI access, unusual access patterns, failed login attempts - Monthly reports: Review of PHI access logs and anomalies
Data Protection: - No email: PHI never transmitted via unencrypted email - Secure file transfer: SFTP, encrypted HTTPS, or Secrets Manager only - No third-party tools: No unvetted SaaS tools access PHI unless BAA signed - Approved providers: Only SaaS providers with executed Business Associate Agreements - Data minimization: Collect and retain only necessary PHI - De-identification: Use Safe Harbor method for analytics and research
Transmission Rules: - No cloud storage: No Google Drive, Dropbox, OneDrive (use encrypted AWS S3) - No messaging apps: No Slack, Teams, email, text message transmission - Approved methods: SFTP, Secrets Manager retrieval via API, AWS RDS connection - VPN required: All remote access to PHI systems via corporate VPN
Storage: - Dedicated database: Separate RDS instance with network isolation - Private subnets: Database in private VPC subnet, no internet access - Encrypted backups: All database backups encrypted with KMS - Immutable: No deletion without audit trail; soft deletes preferred - Separate from code: Never commit to Git; only accessible via API
Backup & Recovery: - Backup frequency: Continuous backups with RTO/RPO targets - Backup encryption: All backups encrypted with KMS - Backup retention: Minimum 30 days; maximum 1 year for compliance holds - Restore testing: Quarterly backup restoration testing - Disaster recovery: Cross-region replication for availability
Deletion & Retention: - Retention policy: Delete PHI after 7 years (or per BAA requirements) - Cryptographic deletion: KMS key destruction to ensure data is unrecoverable - Secure deletion: AWS RDS automated backups deleted after retention period - Deletion audit: Log all PHI deletions with reason and approver
Vendor Management: - BAA required: All third parties handling PHI must have signed BAA - Vendor audits: Annual security assessment of PHI vendors - Sub-processors: Any subcontractors must also have BAA
Incident Response: - Breach notification: 60-day notification requirement under HIPAA - Internal escalation: Immediate escalation to Security Officer and Privacy Officer - Patient notification: Required if unauthorized disclosure occurs - Regulatory reporting: Notification to HHS and healthcare provider partners - Post-incident review: Root cause analysis within 30 days
Training & Compliance: - Mandatory training: All staff handling PHI must complete HIPAA training - Annual recertification: HIPAA training renewed annually - Consequences: Non-compliance results in disciplinary action - Third-party training: Vendors must certify HIPAA compliance
Storage Location: - AWS RDS PostgreSQL (private subnet, encrypted, IAM authentication) - Encrypted S3 buckets (if temporary storage only; typically in RDS) - Never on laptops, external drives, or personal devices - Never in Git repositories or version control
Access Control: - Read: Only users with explicit PHI access authorization - Write: Only authorized clinical staff or system operators - Delete: Only authorized administrators with audit trail - Export: Restricted to secure SFTP or encrypted file download
Retention: Per healthcare provider BAA or HIPAA requirements (typically 6-7 years) Disposal: Cryptographic shredding; AWS RDS deletion with encrypted backups removed
Data Classification Examples
| Data Type | Classification | Why? | How to Handle |
|---|---|---|---|
| Marketing website | Public | Intended for all audiences | Publish freely |
| Employee handbook | Internal | Confidential to company, not sensitive | Share with employees only |
| Database credentials | Confidential | Compromise grants unauthorized system access | Store in Secrets Manager |
| API authentication keys | Confidential | Compromise allows API abuse | Store in Secrets Manager |
| Source code (non-core) | Confidential | Proprietary but not PHI-critical | GitHub private repo with MFA |
| Security audit results | Confidential | Vulnerability information sensitive | Restricted to security team |
| Patient diagnosis data | Restricted | HIPAA-protected PHI | Encrypt at rest/transit, limited access |
| Patient contact info | Restricted | Linked to identity, HIPAA-protected | Encrypt, access controls, audit logs |
| De-identified aggregate data | Internal | No longer HIPAA-protected after Safe Harbor | Standard protection sufficient |
| Internal blog | Internal | Confidential but non-sensitive | Accessible to employees, not public |
Data Labeling and Marking
All data must be labeled according to its classification. Labeling helps employees understand sensitivity and make correct handling decisions.
Digital Data Labeling
Sensitive file naming convention:
[CLASSIFICATION]_[Description]_[Date]
Examples:
- CONFIDENTIAL_AWS_RootKeys_2024-01.txt
- INTERNAL_EmployeeDirectory_Q4_2024.csv
- RESTRICTED_PatientData_ExportLog_2024-01-15.xlsx
Physical Document Labeling
Print the classification on physical documents:
[RESTRICTED: PHI - HANDLE SECURELY]
Patient Data Summary Report
Date: January 15, 2024
Do not photocopy, distribute, or leave unattended
Email Labeling
Include classification in email subjects:
Subject: [CONFIDENTIAL] Q1 2024 Financial Projections
Subject: [INTERNAL] Team Retreat Schedule Update
Subject: [RESTRICTED] Patient Data Analysis Results
Code/Artifact Labeling
In source code comments or documentation:
# [CONFIDENTIAL] - AWS IAM Policy for Production Access
# Not for public distribution. Store credentials in Secrets Manager.
Data Handling by Classification
Access Control Matrix
| Classification | Employee Access | Contractor Access | Public Access | Requires MFA |
|---|---|---|---|---|
| Public | Yes | Yes | Yes | No |
| Internal | Yes | Limited | No | No |
| Confidential | Role-based | If BAA signed | No | Yes |
| Restricted (PHI) | Role-based | No | No | Yes |
Encryption Requirements
| Classification | At Rest | In Transit | Key Management |
|---|---|---|---|
| Public | Optional | HTTP OK | N/A |
| Internal | Standard | HTTPS | AWS-managed keys OK |
| Confidential | AES-256 with KMS | TLS 1.2+ | Customer-managed KMS keys |
| Restricted | AES-256 with KMS | TLS 1.2+ | Customer-managed KMS keys; rotate annually |
Sharing and Distribution
| Classification | Share Internally | Share Externally | Requires Approval | Requires NDA |
|---|---|---|---|---|
| Public | Yes | Yes | No | No |
| Internal | Yes | No | No | No |
| Confidential | Yes | Limited | Yes | Yes |
| Restricted | No (except authorized) | No | Security Officer | Yes (BAA required) |
Retention Periods
| Classification | Default Retention | Archive Duration | Destruction Method |
|---|---|---|---|
| Public | As needed | N/A | Standard deletion |
| Internal | 3 years | 1 year | Overwrite or deletion |
| Confidential | 7 years | 2 years | Cryptographic shredding |
| Restricted (PHI) | Per BAA (typically 6-7 years) | 2 years | Cryptographic shredding via KMS deletion |
Handling Restricted (PHI) Data
If You Have Access to PHI
- Understand its sensitivity — PHI is the highest sensitivity data
- Access only what you need — Principle of least privilege
- Never share unnecessarily — Keep PHI confidential
- Log access — All access is logged in CloudTrail and database audit logs
- Report problems — If you see unusual access, report immediately
- Dispose securely — Never delete without authorization; use cryptographic deletion
PHI Access Responsibilities
You are responsible for:
- ✓ Protecting PHI from unauthorized access
- ✓ Encrypting PHI in transit and at rest
- ✓ Logging all PHI access attempts
- ✓ Monitoring for unauthorized access
- ✓ Reporting breaches or suspicious activity immediately
- ✓ Complying with HIPAA Security Rule requirements
- ✓ Completing annual HIPAA training
- ✓ Not sharing credentials or access with colleagues
- ✓ Destroying PHI when no longer needed
You are NOT responsible for:
- ✗ Making decisions about data retention (ask Privacy Officer)
- ✗ Approving vendor access to PHI (Security Officer decides)
- ✗ Disclosing PHI to external parties (only Privacy Officer can approve)
- ✗ Investigating HIPAA breaches (Security Officer handles)
Reclassification
Data may need reclassification if its sensitivity changes. Examples:
- Internal data becomes public — Publish to website
- Confidential data becomes internal — No longer proprietary
- PHI becomes de-identified — Apply Safe Harbor method
- Data is no longer sensitive — Downgrade classification
Reclassification Process:
- Request reclassification from data owner or Privacy Officer
- Document the reason and justification
- Obtain approval from Security Officer
- Update data labels and storage location if needed
- Audit trail of reclassification decision retained
Non-Compliance and Violations
Mishandling data according to its classification can result in:
- First violation: Warning and mandatory training
- Repeated violations: Suspension of data access privileges
- Severe violations: Disciplinary action up to termination
- Regulatory violations: HIPAA fines up to $1.5M per violation category
Examples of violations:
- ✗ Emailing PHI without encryption
- ✗ Sharing Confidential data without approval
- ✗ Storing PHI on personal laptop
- ✗ Leaving Restricted documents unattended
- ✗ Accessing PHI outside job function
- ✗ Taking screenshots of PHI
- ✗ Discussing PHI in public areas
Questions and Escalations
Data Classification Questions: Contact the Privacy Officer at privacy@timelessbiotech.com
Suspected Violations: Contact the Security Officer at security@timelessbiotech.com
HIPAA Compliance Questions: Contact the Privacy Officer or Security Officer
Questions? Contact the Security Officer at security@timelessbiotech.com or the Privacy Officer at privacy@timelessbiotech.com.