# RateRight Data Protection Specification

**Document Version:** 1.0  
**Last Updated:** [To be updated upon implementation]  
**Owner:** RateRight Technical Team  
**Classification:** Confidential

## 1. Introduction

This Data Protection Specification outlines the technical implementation requirements for protecting personal information within RateRight's construction worker marketplace platform. This specification ensures compliance with the Australian Privacy Act 1988, Australian Privacy Principles (APPs), Privacy (Tax File Number) Rule 2015, and the Notifiable Data Breaches scheme.

## 2. Scope

This specification applies to:
- All RateRight applications and systems
- Third-party integrations and APIs
- Data storage and transmission
- Access controls and authentication
- Monitoring and logging systems
- Backup and disaster recovery systems

## 3. Architecture Overview

### 3.1 System Components
```
┌─────────────────────────────────────────────────────────────┐
│                     Client Applications                      │
├─────────────────────────────────────────────────────────────┤
│                    API Gateway Layer                         │
├─────────────────────────────────────────────────────────────┤
│              Application Services Layer                       │
│  ┌─────────────┬─────────────┬─────────────┬─────────────┐ │
│  │User Service │Job Service  │Payment Svc  │Profile Svc  │ │
│  └─────────────┴─────────────┴─────────────┴─────────────┘ │
├─────────────────────────────────────────────────────────────┤
│                    Data Access Layer                         │
├─────────────────────────────────────────────────────────────┤
│              Encrypted Database Storage                       │
│  ┌─────────────┬─────────────┬─────────────┬─────────────┐ │
│  │User DB      │Job DB       │Payment DB   │Audit DB     │ │
│  └─────────────┴─────────────┴─────────────┴─────────────┘ │
└─────────────────────────────────────────────────────────────┘
```

### 3.2 Data Classification

#### Level 1 - Highly Sensitive
- Tax File Numbers (TFNs)
- Bank account details
- Government identifiers (passport, driver's license)
- Biometric data
- Health information

#### Level 2 - Sensitive
- Personal identification information
- Employment history
- Police check results
- Superannuation details
- ABN information

#### Level 3 - Internal
- User preferences
- Platform usage analytics
- Communication logs
- Device information

#### Level 4 - Public
- Public job postings
- Company profiles (public sections)
- General platform information

## 4. Encryption Requirements

### 4.1 Data at Rest Encryption

#### Database Encryption
- **Algorithm:** AES-256-GCM
- **Key Management:** AWS KMS or Azure Key Vault
- **Implementation:** Transparent Data Encryption (TDE)
- **Rotation:** Annual key rotation with quarterly review

#### Field-Level Encryption for Sensitive Data
```sql
-- Example for TFN field encryption
CREATE TABLE worker_profiles (
    id UUID PRIMARY KEY,
    tfn_encrypted VARBINARY(512),  -- Encrypted TFN
    tfn_hash VARCHAR(64),           -- Hashed TFN for searching
    created_at TIMESTAMP,
    updated_at TIMESTAMP
);
```

#### File Storage Encryption
- **Documents:** AES-256-CBC with unique keys per file
- **Key Management:** Separate key for each document
- **Storage:** Encrypted S3 buckets or equivalent
- **Access:** Signed URLs with expiration (max 15 minutes)

### 4.2 Data in Transit Encryption

#### TLS Configuration
- **Minimum Version:** TLS 1.3
- **Cipher Suites:** 
  - TLS_AES_256_GCM_SHA384
  - TLS_CHACHA20_POLY1305_SHA256
- **Certificate:** Extended Validation (EV) SSL certificate
- **HSTS:** Enabled with max-age of 1 year
- **Certificate Pinning:** Implemented in mobile applications

#### API Communication
```json
{
  "security": {
    "transportSecurity": {
      "tlsVersion": "1.3",
      "cipherSuites": ["TLS_AES_256_GCM_SHA384"],
      "requireClientCertificate": false,
      "enableHSTS": true
    }
  }
}
```

### 4.3 Key Management

#### Key Hierarchy
```
Master Key (HSM)
    ├── Data Encryption Key (DEK)
    │   └── Database Encryption Key
    │   └── File Storage Key
    ├── Key Encryption Key (KEK)
    │   └── Backup Encryption Key
    │   └── Archive Encryption Key
    └── Tokenization Key
        └── TFN Tokenization Key
```

#### Key Rotation Schedule
- **Master Key:** Every 365 days
- **DEK:** Every 90 days
- **KEK:** Every 180 days
- **Tokenization Keys:** Every 30 days

## 5. Access Control Framework

### 5.1 Authentication Requirements

#### Multi-Factor Authentication (MFA)
- **Requirement:** All privileged accounts and external users
- **Methods:**
  - TOTP (Time-based One-Time Password)
  - SMS (with fallback restrictions)
  - Hardware tokens for administrators
- **Implementation:** 30-day grace period for enrollment

#### Password Policy
```yaml
password_policy:
  min_length: 14
  complexity: "high"
  require_uppercase: true
  require_lowercase: true
  require_numbers: true
  require_special_chars: true
  history_count: 12
  max_age_days: 90
  lockout_attempts: 5
  lockout_duration_minutes: 30
```

### 5.2 Role-Based Access Control (RBAC)

#### Role Definitions
```json
{
  "roles": {
    "admin": {
      "permissions": ["all"],
      "mfa_required": true,
      "session_timeout": 30
    },
    "support_agent": {
      "permissions": ["read:user", "read:job", "update:ticket"],
      "mfa_required": true,
      "session_timeout": 60
    },
    "worker": {
      "permissions": ["read:own_profile", "update:own_profile", "read:job"],
      "mfa_required": false,
      "session_timeout": 120
    },
    "contractor": {
      "permissions": ["read:worker_profile", "post:job", "manage:own_jobs"],
      "mfa_required": false,
      "session_timeout": 120
    }
  }
}
```

#### Principle of Least Privilege
- Default deny-all approach
- Just-in-time access for sensitive operations
- Quarterly access reviews
- Automatic de-provisioning upon role change

### 5.3 Data Access Controls

#### Field-Level Security
```sql
-- Example: TFN access control
CREATE FUNCTION can_access_tfn(user_id UUID, accessing_user_id UUID)
RETURNS BOOLEAN AS $$
BEGIN
    RETURN EXISTS (
        SELECT 1 FROM user_roles 
        WHERE user_id = accessing_user_id 
        AND role IN ('admin', 'payroll_processor')
        AND is_active = true
    );
END;
$$ LANGUAGE plpgsql;
```

#### Row-Level Security (RLS)
- Implement RLS for all user data tables
- Automatic application of WHERE clauses based on user context
- Audit logging of all RLS bypasses

## 6. Data Storage Architecture

### 6.1 Database Security

#### PostgreSQL Security Configuration
```sql
-- Enable SSL
ssl = on
ssl_cert_file = 'server.crt'
ssl_key_file = 'server.key'
ssl_ca_file = 'root.crt'

-- Connection security
ssl_ciphers = 'TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256'
ssl_prefer_server_ciphers = on
ssl_ecdh_curve = 'prime256v1'

-- Logging
log_connections = on
log_disconnections = on
log_statement = 'all'
log_min_duration_statement = 1000
```

#### MongoDB Security Configuration
```javascript
// Security settings
security:
  authorization: enabled
  keyFile: /etc/mongodb-keyfile
  javascriptEnabled: false

// Encryption at rest
encryption:
  enableEncryption: true
  encryptionKeyFile: /etc/mongodb-encryption-keyfile
```

### 6.2 Segregation of Sensitive Data

#### TFN Storage Architecture
```
┌─────────────────┐     ┌──────────────────┐     ┌─────────────────┐
│   Application   │────▶│  Tokenization    │────▶│  Secure Vault   │
│     Layer       │     │     Service      │     │    (HSM/KMS)    │
└─────────────────┘     └──────────────────┘     └─────────────────┘
        │                        │                        │
        ▼                        ▼                        ▼
┌─────────────────┐     ┌──────────────────┐     ┌─────────────────┐
│   Reference     │     │   Tokenized      │     │  Encrypted TFN  │
│   Database      │     │     TFN ID       │     │   Storage       │
└─────────────────┘     └──────────────────┘     └─────────────────┘
```

**Implementation Requirements:**
- TFN values are tokenized with format-preserving tokens
- Original TFN encrypted and stored in separate secure vault
- No direct database access to TFN storage
- All access through audited API calls

## 7. Monitoring and Logging

### 7.1 Security Event Logging

#### Required Log Events
- All authentication attempts (success and failure)
- Authorization failures
- Data access to sensitive information
- Administrative actions
- Configuration changes
- System errors and exceptions

#### Log Format Standard
```json
{
  "timestamp": "2024-01-15T10:30:45.123Z",
  "level": "INFO",
  "event_type": "DATA_ACCESS",
  "user_id": "user_123",
  "session_id": "sess_456",
  "resource_type": "TFN",
  "resource_id": "token_789",
  "action": "READ",
  "result": "SUCCESS",
  "ip_address": "203.0.113.42",
  "user_agent": "Mozilla/5.0...",
  "correlation_id": "corr_abc123"
}
```

### 7.2 Audit Trail Requirements

#### Immutable Audit Logs
- Write-once storage for audit logs
- Cryptographic signing of log entries
- Retention period: 7 years minimum
- Quarterly integrity verification

#### Real-time Monitoring
- SIEM (Security Information and Event Management) integration
- Automated alerting for suspicious activities
- ML-based anomaly detection
- 24/7 security operations center (SOC) monitoring

### 7.3 Privacy Monitoring

#### Access Pattern Analysis
```python
# Example: Detect unusual TFN access patterns
def detect_anomalous_tfn_access(user_id, timeframe_hours=1):
    access_count = get_tfn_access_count(user_id, timeframe_hours)
    baseline = get_user_baseline(user_id, 'tfn_access')
    
    if access_count > baseline * 3:
        trigger_alert('unusual_tfn_access', {
            'user_id': user_id,
            'access_count': access_count,
            'baseline': baseline
        })
```

## 8. Data Retention and Deletion

### 8.1 Automated Retention Policy

#### Retention Schedule
```yaml
retention_policies:
  user_profiles:
    retention_period: "7_years"
    trigger: "last_activity"
    action: "anonymize"
    
  tfn_records:
    retention_period: "7_years"
    trigger: "last_employment"
    action: "secure_delete"
    verification_required: true
    
  payment_records:
    retention_period: "7_years"
    trigger: "transaction_date"
    action: "archive_then_delete"
    
  audit_logs:
    retention_period: "7_years"
    trigger: "creation_date"
    action: "immutable_storage"
```

### 8.2 Secure Deletion Process

#### Multi-step Deletion Protocol
1. **Mark for Deletion:** Soft delete with 30-day grace period
2. **Verification:** Manual review for sensitive data
3. **Secure Deletion:** Cryptographic erasure of encrypted data
4. **Key Destruction:** Destruction of associated encryption keys
5. **Confirmation:** Audit log entry and deletion certificate

#### Deletion API Implementation
```python
class SecureDeletionService:
    def delete_user_data(self, user_id: str) -> DeletionCertificate:
        # Step 1: Verify authorization
        if not self.auth_service.can_delete_data(current_user, user_id):
            raise UnauthorizedException()
        
        # Step 2: Retrieve all user data locations
        data_locations = self.data_mapper.find_all_user_data(user_id)
        
        # Step 3: Secure deletion process
        deletion_log = []
        for location in data_locations:
            if location.classification == "TFN":
                self.tfn_service.secure_delete(location)
            else:
                self.crypto_service.delete_with_key_destruction(location)
            deletion_log.append(location)
        
        # Step 4: Generate deletion certificate
        certificate = DeletionCertificate(
            user_id=user_id,
            timestamp=datetime.utcnow(),
            deleted_items=deletion_log,
            signed_by=self.key_service.sign(certificate_data)
        )
        
        return certificate
```

## 9. API Security

### 9.1 Authentication and Authorization

#### OAuth 2.0 Implementation
```json
{
  "security": {
    "oauth2": {
      "flows": {
        "authorizationCode": {
          "authorizationUrl": "https://auth.rateright.com/oauth/authorize",
          "tokenUrl": "https://auth.rateright.com/oauth/token",
          "scopes": {
            "profile:read": "Read user profile",
            "profile:write": "Update user profile",
            "tfn:read": "Read TFN information",
            "jobs:manage": "Manage job postings"
          }
        }
      }
    }
  }
}
```

#### Rate Limiting
```yaml
rate_limits:
  default:
    requests_per_minute: 60
    requests_per_hour: 1000
  
  sensitive_endpoints:
    "/api/v1/tfn/*":
      requests_per_minute: 5
      requests_per_hour: 50
    
    "/api/v1/users/*/bank-details":
      requests_per_minute: 10
      requests_per_hour: 100
```

### 9.2 Input Validation and Sanitization

#### Validation Rules
```javascript
// Example: TFN validation
const tfnValidation = {
  pattern: /^\d{3}-\d{3}-\d{3}$/,
  sanitize: (input) => input.replace(/[^\d]/g, ''),
  encrypt: true,
  audit_log: true
};

// Example: Bank account validation
const bankValidation = {
  bsb: {
    pattern: /^\d{3}-\d{3}$/,
    validate: (bsb) => isValidBSB(bsb)
  },
  accountNumber: {
    minLength: 6,
    maxLength: 10,
    encrypt: true
  }
};
```

## 10. Third-Party Integration Security

### 10.1 Due Diligence Requirements

#### Security Assessment Checklist
- [ ] SOC 2 Type II certification
- [ ] ISO 27001 compliance
- [ ] Data residency guarantees
- [ ] Encryption standards verification
- [ ] Incident response procedures
- [ ] Insurance coverage verification

#### Contract Requirements
```yaml
third_party_requirements:
  data_processing:
    encryption_at_rest: "AES-256"
    encryption_in_transit: "TLS_1.3"
    access_controls: "RBAC_MFA"
    audit_logging: "required"
    
  incident_response:
    notification_time: "24_hours"
    investigation_support: "required"
    remediation_timeline: "72_hours"
    
  compliance:
    privacy_act_compliance: "required"
    ndb_scheme_compliance: "required"
    tfn_rule_compliance: "required"
```

### 10.2 API Integration Security

#### Secure Integration Pattern
```python
class SecureThirdPartyClient:
    def __init__(self, service_name: str):
        self.service_name = service_name
        self.credentials = self._load_credentials(service_name)
        self.session = self._create_secure_session()
    
    def send_sensitive_data(self, data: dict) -> Response:
        # Encrypt data before sending
        encrypted_data = self.crypto_service.encrypt(
            data, 
            key_id=self.credentials['encryption_key_id']
        )
        
        # Sign the request
        signature = self._sign_request(encrypted_data)
        
        # Send with audit logging
        self.audit_service.log_outbound_request(
            service=self.service_name,
            data_classification=data.get('classification'),
            correlation_id=self.correlation_id
        )
        
        return self.session.post(
            self.credentials['endpoint'],
            json=encrypted_data,
            headers={'X-Signature': signature}
        )
```

## 11. Incident Response

### 11.1 Privacy Incident Classification

#### Severity Levels
- **Critical (P1):** TFN or financial data breach, >1000 affected users
- **High (P2):** Personal information breach, <1000 affected users
- **Medium (P3):** Limited personal information exposure
- **Low (P4):** Potential privacy violation, no data exposure

### 11.2 Response Procedures

#### Data Breach Response Playbook
```yaml
incident_response:
  detection:
    automated_monitoring: true
    manual_reporting: "security@rateright.com"
    sla: "15_minutes"
    
  containment:
    immediate_actions:
      - "isolate_affected_systems"
      - "preserve_evidence"
      - "notify_incident_team"
    sla: "1_hour"
    
  assessment:
    determine_eligible_data_breach: true
    assess_risk_of_harm: true
    document_findings: true
    sla: "24_hours"
    
  notification:
    oaic_notification: "72_hours_max"
    individual_notification: "as_soon_as_practicable"
    stakeholder_notification: "24_hours"
```

### 11.3 Forensic Procedures

#### Evidence Preservation
```bash
#!/bin/bash
# Evidence collection script

# Create forensic image
dd if=/dev/suspicious_volume of=/evidence/volume_image.dd bs=4M
cp /evidence/volume_image.dd /evidence/backup_image.dd

# Generate hash for integrity
sha256sum /evidence/volume_image.dd > /evidence/image_hash.txt

# Collect memory dump (if applicable)
volatility -f memory_dump.raw --profile=LinuxUbuntu20x64 linux_pslist > /evidence/processes.txt

# Preserve logs
cp -r /var/log/* /evidence/logs/
cp /var/lib/postgresql/*/log/* /evidence/db_logs/
```

## 12. Compliance Monitoring

### 12.1 Automated Compliance Checks

#### Daily Compliance Reports
```python
class ComplianceChecker:
    def run_daily_checks(self) -> ComplianceReport:
        report = ComplianceReport()
        
        # Check encryption status
        report.encryption_status = self.check_all_encrypted()
        
        # Verify access controls
        report.access_control_violations = self.check_access_violations()
        
        # Check data retention compliance
        report.retention_violations = self.check_retention_policy()
        
        # Verify audit logging
        report.audit_log_gaps = self.check_audit_completeness()
        
        # Check TFN handling compliance
        report.tfn_compliance = self.check_tfn_security()
        
        return report
```

### 12.2 Quarterly Security Reviews

#### Review Checklist
- [ ] Access control matrix review
- [ ] Encryption key rotation verification
- [ ] Third-party security assessment
- [ ] Incident response drill
- [ ] Privacy impact assessment
- [ ] Staff training completion
- [ ] Compliance gap analysis
- [ ] Risk register update

### 12.3 Privacy Impact Assessments

#### PIA Trigger Events
- New system implementation
- Significant system changes
- New data collection initiatives
- Third-party integrations
- Cross-border data transfers

#### PIA Template Requirements
```markdown
1. Project Description
2. Data Flow Mapping
3. Privacy Risk Assessment
4. Compliance Gap Analysis
5. Mitigation Strategies
6. Residual Risk Acceptance
7. Ongoing Monitoring Plan
```

## 13. Implementation Roadmap

### Phase 1: Foundation (Months 1-2)
- [ ] Implement base encryption framework
- [ ] Deploy access control system
- [ ] Establish audit logging
- [ ] Implement basic monitoring

### Phase 2: Enhancement (Months 3-4)
- [ ] Deploy TFN-specific security controls
- [ ] Implement automated retention policies
- [ ] Deploy advanced monitoring
- [ ] Establish incident response procedures

### Phase 3: Optimization (Months 5-6)
- [ ] Complete third-party integration security
- [ ] Implement ML-based anomaly detection
- [ ] Deploy compliance automation
- [ ] Conduct comprehensive security testing

### Phase 4: Maintenance (Ongoing)
- [ ] Regular security updates
- [ ] Continuous monitoring and tuning
- [ ] Quarterly compliance reviews
- [ ] Annual security assessments

## 14. Success Metrics

### 14.1 Security KPIs
- Mean Time to Detect (MTTD): < 15 minutes
- Mean Time to Respond (MTTR): < 1 hour
- Data breach incidents: 0 per quarter
- Vulnerability remediation: < 72 hours for critical
- Encryption coverage: 100% for sensitive data

### 14.2 Compliance KPIs
- Privacy compliance score: > 95%
- Audit findings: < 5 per quarter
- Staff training completion: 100%
- Policy adherence: > 98%
- Third-party compliance: 100% verified

## 15. Review and Updates

This specification must be reviewed:
- Quarterly by the security team
- Annually by external security auditors
- Upon significant system changes
- Following security incidents
- When regulatory requirements change

---

**Document Approval:**
- Technical Lead: [To be signed]
- Security Officer: [To be signed]
- Privacy Officer: [To be signed]
- Legal Counsel: [To be signed]

**Next Review Date:** [To be scheduled annually]